Is this code in gcc 4.3.1 valid C or is Sun compiler wrong ?? - Solaris

This is a discussion on Is this code in gcc 4.3.1 valid C or is Sun compiler wrong ?? - Solaris ; On 2008-07-23 08:22:59 -0700, Riot Nrrrd said: > When can we see this "fix" you speak of, Andrew? Do we have to wait > for GCC 4.3.2? (I don't speak CVS or SVN) Never mind - I see you posted ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 28 of 28

Thread: Is this code in gcc 4.3.1 valid C or is Sun compiler wrong ??

  1. Re: Is this code in gcc 4.3.1 valid C or is Sun compiler wrong ??

    On 2008-07-23 08:22:59 -0700, Riot Nrrrd said:

    > When can we see this "fix" you speak of, Andrew? Do we have to wait
    > for GCC 4.3.2? (I don't speak CVS or SVN)


    Never mind - I see you posted the fix(es) to gcc-patches.

    So it looks like your patches for both c-common.c *and* tree.c to
    split the macros are necessary to work around this issue. Right?
    (Anything else?)



  2. Re: Is this code in gcc 4.3.1 valid C or is Sun compiler wrong ??

    Riot Nrrrd™ wrote:

    > How ironic, building GCC on SunOS/Solaris used to be one of the
    > canonical GCC ports. Now a release can come out and no one even
    > bothers to test bootstrapping it with Sun Studio 12 anymore?


    After an alful lot of f***ing about I mananged to build the latest gcc
    (4.3.1), but not starting with Sun Studio - only gcc.


    I think if I recall correctly I used 3.x (supplied with Solaris in
    /usr/sfw/bin) to build 4.x, then used that to build 4.y, and that to
    build 4.z....

    Looking in /usr/local on my system I have several directories with gcc
    in them (versions 4.2.0, 4.2.2, 4.2.4 and 4.3.1).

    It seems a bit hit and miss finding what version will compile some other
    version on Solaris. If it don't compile, try to find another version and
    compile that. It's clear there is little quality control on Solaris, so
    it's anyones guess what will work and what will not.

    Anyway, this is what I finally used to build 4.3.1, but I can't recall
    the compiler version I used.

    $ gcc -v
    Using built-in specs.
    Target: sparc-sun-solaris2.10
    Configured with: ../gcc-4.3.1/configure --prefix=/usr/local
    --with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld
    --with-ld=/usr/local/bin/ld --enable-languages=c,c++,fortran
    --with-gmp=/usr/local --with-mpfr=/usr/local
    --with-libiconv-prefix=/usr/local
    Thread model: posix
    gcc version 4.3.1 (GCC


    Note I build this using the GNU linker and assembler, not the Sun ones.
    That was mainly since I need to compile some code with GNUisms, which
    make use of GNU-specific linker options.


  3. Re: Is this code in gcc 4.3.1 valid C or is Sun compiler wrong ??

    In gnu.gcc.help Riot Nrrrd? wrote:
    > On 2008-07-23 08:22:59 -0700, Riot Nrrrd said:


    > > When can we see this "fix" you speak of, Andrew? Do we have to wait
    > > for GCC 4.3.2? (I don't speak CVS or SVN)


    > Never mind - I see you posted the fix(es) to gcc-patches.


    > So it looks like your patches for both c-common.c *and* tree.c to
    > split the macros are necessary to work around this issue. Right?
    > (Anything else?)


    I think that's it. The only real way to be absolutely sure is to pull
    the changes from SVN, though.

    http://gcc.gnu.org/viewcvs?view=rev&revision=137413

    Andrew.

  4. Re: Is this code in gcc 4.3.1 valid C or is Sun compiler wrong ??

    On 2008-07-30 19:30:29 -0700, Andrew Haley
    said:

    > In gnu.gcc.help Riot Nrrrd? wrote:
    >> On 2008-07-23 08:22:59 -0700, Riot Nrrrd said:

    >
    >>> When can we see this "fix" you speak of, Andrew? Do we have to wait
    >>> for GCC 4.3.2? (I don't speak CVS or SVN)

    >
    >> Never mind - I see you posted the fix(es) to gcc-patches.

    >
    >> So it looks like your patches for both c-common.c *and* tree.c to
    >> split the macros are necessary to work around this issue. Right?
    >> (Anything else?)

    >
    > I think that's it. The only real way to be absolutely sure is to pull
    > the changes from SVN, though.
    >
    > http://gcc.gnu.org/viewcvs?view=rev&revision=137413


    Andrew,

    With your patches I got much further, but ran aground on this:

    gmake[5]: Entering directory
    `/var/tmp/gcc-4.3.1/sparc-sun-solaris2.9/sparcv9/libjava'
    gmake[5]: warning: -jN forced in submake: disabling jobserver mode.
    gmake -j 2 create-headers
    gmake[6]: Entering directory
    `/var/tmp/gcc-4.3.1/sparc-sun-solaris2.9/sparcv9/libjava'
    gmake[6]: warning: -jN forced in submake: disabling jobserver mode.
    here=`pwd`; cd /usr/gnu/src/gcc-4.3.1/libjava/classpath/lib; \
    find gnu java javax org sun -name .svn -prune -o -name
    '*.class' -print | \
    /var/tmp/gcc-4.3.1/sparc-sun-solaris2.9/libjava/scripts/jar
    -cfM@ $here/libgcj-4.3.1.jar
    echo > gcjh.stamp
    gmake[6]: Leaving directory
    `/var/tmp/gcc-4.3.1/sparc-sun-solaris2.9/sparcv9/libjava'

    [...]

    echo /usr/gnu/src/gcc-4.3.1/libjava/classpath/lib/java/util/*.class >
    java/util.list
    gmake[5]: *** No rule to make target
    `classpath/external/jsr166/java/util/concurrent/atomic/AtomicMarkableReference.java',
    needed by
    `java/util/concurrent/atomic.list'. Stop.
    gmake[5]: *** Waiting for unfinished jobs....
    echo
    /usr/gnu/src/gcc-4.3.1/libjava/classpath/lib/java/util/concurrent/*.class
    > java/util/concurrent.list

    gmake[5]: Leaving directory
    `/var/tmp/gcc-4.3.1/sparc-sun-solaris2.9/sparcv9/libjava'
    gmake[4]: *** [all-recursive] Error 1
    gmake[4]: Leaving directory
    `/var/tmp/gcc-4.3.1/sparc-sun-solaris2.9/sparcv9/libjava'
    gmake[3]: *** [multi-do] Error 1
    gmake[3]: Leaving directory `/var/tmp/gcc-4.3.1/sparc-sun-solaris2.9/libjava'
    gmake[2]: *** [all-multi] Error 2
    gmake[2]: Leaving directory `/var/tmp/gcc-4.3.1/sparc-sun-solaris2.9/libjava'
    gmake[1]: *** [all-target-libjava] Error 2
    gmake[1]: Leaving directory `/var/tmp/gcc-4.3.1'
    gmake: *** [bootstrap] Error 2

    So I checked the source directory:

    [14:49] solaris9:/<9+>concurrent/atomic % pwd
    /usr/src/gnu/gcc-4.3.1/libjava/classpath/external/jsr166/java/util/concurrent/atomic

    [14:49]

    solaris9:/<9+>concurrent/atomic % ls AtomicMarkableReference*
    AtomicMarkableReference.jav

    Great, so the file is there but the extension is wrong! I checked the
    original GCC 4.3.1 tarball:

    [14:52] solaris9:/<2>src/tarfiles % gtar -tzpf gcc-4.3.1.tar.gz | grep
    AtomicMarkableReference.jav
    gcc-4.3.1/libjava/classpath/external/jsr166/java/util/concurrent/atomic/AtomicMarkableReference.jav

    How

    the heck does a mis-named file get past QC into the GCC distribution???


  5. Re: Is this code in gcc 4.3.1 valid C or is Sun compiler wrong ??

    On 2008-08-06 14:54:37 -0700, Riot Nrrrd™ said:

    > With your patches I got much further, but ran aground on this:
    >
    > echo /usr/gnu/src/gcc-4.3.1/libjava/classpath/lib/java/util/*.class >
    > java/util.list
    > gmake[5]: *** No rule to make target
    > `classpath/external/jsr166/java/util/concurrent/atomic/AtomicMarkableReference.java',
    > needed by
    > `java/util/concurrent/atomic.list'. Stop.
    > [14:49] solaris9:/<9+>concurrent/atomic % pwd
    > /usr/src/gnu/gcc-4.3.1/libjava/classpath/external/jsr166/java/util/concurrent/atomic


    [14:49]
    solaris9:/<9+>concurrent/atomic
    >
    > % ls AtomicMarkableReference*
    > AtomicMarkableReference.jav
    >
    > Great, so the file is there but the extension is wrong! I checked the
    > original GCC 4.3.1 tarball:
    >
    > [14:52] solaris9:/<2>src/tarfiles % gtar -tzpf gcc-4.3.1.tar.gz | grep
    > AtomicMarkableReference.jav
    > gcc-4.3.1/libjava/classpath/external/jsr166/java/util/concurrent/atomic/AtomicMarkableReference.jav


    How
    >
    > the heck does a mis-named file get past QC into the GCC distribution???


    Ignore this post (arggh, Unison doesn't implement Cancel), I was being
    retarded.

    I thought I'd unbundled the source with GNU tar and apparently I
    hadn't, and ran aground on the 100 character filename limit and some of
    the src files got their names chopped off. Nuked the whole lot and
    re-extracted. Stay tuned ...


  6. Re: Is this code in gcc 4.3.1 valid C or is Sun compiler wrong ??

    On Jul 23, 10:22 am, Riot Nrrrd™ wrote:
    > On 2008-07-10 07:02:07 -0700, Andrew Haley
    > said:
    >
    >
    >
    > > In gnu.gcc.help Dave wrote:
    > >> Andrew Haley wrote:
    > >>> In gnu.gcc.help Andrew Haley wrote:
    > >>>> In gnu.gcc.help Thad Smith wrote:

    >
    > >>>>> The code invokes the macro with a missing first argument. That is valid
    > >>>>> C99, but undefined in C90 (see the recent CLC thread on "empty macro
    > >>>>> arguments").
    > >>>> Yes, you're right. This is a bug: empty macro arguments were
    > >>>> undefined in C89, but it was a common extension even then. I'll fix
    > >>>> this.

    >
    > >>> I have fixed it, and I have added a warning to gcc so that
    > >>> if anyone ever uses empty macro arguments in the gcc source
    > >>> the build will abort, even when building with gcc.

    >
    > >> It's good to hear it is fixed, but there seems to be an overall
    > >> problem with gcc in that features are added, but it is difficult to
    > >> build on non-Linux systems. Building on SPARC is no easy task, with
    > >> one having to go to great lengths to find the right version of gcc
    > >> to build it with (Sun's compilers are incapable of building gcc).

    >
    > > Well, that's bad. Our official position is that gcc needs an ISO-C89
    > > compiler to build, and any use of language extensions to C89 in gcc
    > > sources is a bug.

    >
    > > For any problem bootstrapping gcc with Sun's compilers the question is
    > > whether Sun's tools are deficient in some way or gcc is incorrect. In
    > > this particular case there wasn't any question, so I fixed gcc.

    >
    > >> Is it any wonder that places that keep Solaris binaries (Blastwave,
    > >> Sunfreeware) don't regularly update gcc like they do other
    > >> programs. It must seems too difficult/problematic to build, so
    > >> people don't bother.

    >
    > > We want people to be able to build gcc on their systems. However some
    > > ports are unmaintained simply because no gcc maintainer uses them.
    > > The only way we can fix that is to ask people who do use these systems
    > > to help us.

    >
    > How ironic, building GCC on SunOS/Solaris used to be one of the
    > canonical GCC ports. Now a release can come out and no one even
    > bothers to test bootstrapping it with Sun Studio 12 anymore?
    >
    > I am trying to build 4.3.1 on Solaris 9 SPARC and am running into this
    > exact same problem (using Sun Studio 12 to do the initial bootstrap
    > phase).
    >
    > One thing I hadn't seen mentioned in this thread is the "-xc99"
    > switch to Sun Studio 12's "cc", but trying this (CC="cc -xc99" before
    > "configure") still fails, in one of two ways:
    >
    > (1) If you try using "-xc99" Sun's compilers treat it as "-xc99=all",
    > and they don't support "-xc99=libs" (part of "all") on Solaris 9.
    >
    > (2) If you try using "-xc99=all,no_lib" it "compiles" but again returns
    > the same error as the O.P. got, i.e. it looks like this directive was
    > essentially a NOP instruction. Same thing for "-xc99=none" as well.
    >
    > It looks like there is no way to trick the Sun Studio 12 C compiler to
    > compile that one "gcc/c-common.c" file due to this macro. Not on
    > Solaris 9 for SPARC, at least.
    >
    > When can we see this "fix" you speak of, Andrew? Do we have to wait
    > for GCC 4.3.2? (I don't speak CVS)


    Once again the stupid linux weenies claiming to know all about
    everything, who cann't get software written without adding their own
    little bit of extension to fundamental tools. Of course when they add
    their own little tweak it breaks every other tool. As usual the
    response is "My tweak should have been part of the definition they
    just didn't listen to me" I run into this more and more. A major
    scientific package won't compile on anything but DeadRat because the
    developers made use of all sorts of DeadRat-only features. Net result
    it won't run on SUSE and you cann't compile it on anything but DeadRat
    without rewriting majors chunks of it.

  7. Re: Is this code in gcc 4.3.1 valid C or is Sun compiler wrong ??

    mommycalled@gmail.com wrote:
    > On Jul 23, 10:22 am, Riot Nrrrd™ wrote:
    >> On 2008-07-10 07:02:07 -0700, Andrew Haley
    >> said:
    >>
    >>
    >>
    >>> In gnu.gcc.help Dave wrote:
    >>>> Andrew Haley wrote:
    >>>>> In gnu.gcc.help Andrew Haley wrote:
    >>>>>> In gnu.gcc.help Thad Smith wrote:
    >>>>>>> The code invokes the macro with a missing first argument. That is valid
    >>>>>>> C99, but undefined in C90 (see the recent CLC thread on "empty macro
    >>>>>>> arguments").
    >>>>>> Yes, you're right. This is a bug: empty macro arguments were
    >>>>>> undefined in C89, but it was a common extension even then. I'll fix
    >>>>>> this.
    >>>>> I have fixed it, and I have added a warning to gcc so that
    >>>>> if anyone ever uses empty macro arguments in the gcc source
    >>>>> the build will abort, even when building with gcc.
    >>>> It's good to hear it is fixed, but there seems to be an overall
    >>>> problem with gcc in that features are added, but it is difficult to
    >>>> build on non-Linux systems. Building on SPARC is no easy task, with
    >>>> one having to go to great lengths to find the right version of gcc
    >>>> to build it with (Sun's compilers are incapable of building gcc).
    >>> Well, that's bad. Our official position is that gcc needs an ISO-C89
    >>> compiler to build, and any use of language extensions to C89 in gcc
    >>> sources is a bug.
    >>> For any problem bootstrapping gcc with Sun's compilers the question is
    >>> whether Sun's tools are deficient in some way or gcc is incorrect. In
    >>> this particular case there wasn't any question, so I fixed gcc.
    >>>> Is it any wonder that places that keep Solaris binaries (Blastwave,
    >>>> Sunfreeware) don't regularly update gcc like they do other
    >>>> programs. It must seems too difficult/problematic to build, so
    >>>> people don't bother.
    >>> We want people to be able to build gcc on their systems. However some
    >>> ports are unmaintained simply because no gcc maintainer uses them.
    >>> The only way we can fix that is to ask people who do use these systems
    >>> to help us.

    >> How ironic, building GCC on SunOS/Solaris used to be one of the
    >> canonical GCC ports. Now a release can come out and no one even
    >> bothers to test bootstrapping it with Sun Studio 12 anymore?
    >>
    >> I am trying to build 4.3.1 on Solaris 9 SPARC and am running into this
    >> exact same problem (using Sun Studio 12 to do the initial bootstrap
    >> phase).
    >>
    >> One thing I hadn't seen mentioned in this thread is the "-xc99"
    >> switch to Sun Studio 12's "cc", but trying this (CC="cc -xc99" before
    >> "configure") still fails, in one of two ways:
    >>
    >> (1) If you try using "-xc99" Sun's compilers treat it as "-xc99=all",
    >> and they don't support "-xc99=libs" (part of "all") on Solaris 9.
    >>
    >> (2) If you try using "-xc99=all,no_lib" it "compiles" but again returns
    >> the same error as the O.P. got, i.e. it looks like this directive was
    >> essentially a NOP instruction. Same thing for "-xc99=none" as well.
    >>
    >> It looks like there is no way to trick the Sun Studio 12 C compiler to
    >> compile that one "gcc/c-common.c" file due to this macro. Not on
    >> Solaris 9 for SPARC, at least.
    >>
    >> When can we see this "fix" you speak of, Andrew? Do we have to wait
    >> for GCC 4.3.2? (I don't speak CVS)

    >
    > Once again the stupid linux weenies claiming to know all about
    > everything, who cann't get software written without adding their own
    > little bit of extension to fundamental tools. Of course when they add
    > their own little tweak it breaks every other tool. As usual the
    > response is "My tweak should have been part of the definition they
    > just didn't listen to me" I run into this more and more. A major
    > scientific package won't compile on anything but DeadRat because the
    > developers made use of all sorts of DeadRat-only features. Net result
    > it won't run on SUSE and you cann't compile it on anything but DeadRat
    > without rewriting majors chunks of it.


    Well, complete creative freedom and standards don't mix too well. Since
    a Linux package that rhymes with DeadRat is free and not terribly fussy
    about what hardware it runs on, using the software in question should
    not be too great a hardship! The copy I bought, years ago, cost me $100
    US for which I got about 10 CD-ROMS with executable software, sources,
    and some documentation. If I had wanted to, I could have downloaded it
    for free but with no support. "Support" consisted of about 25 GB of
    patches over the course of a year.



    Or, if you just CAN'T STAND IT, you can do the major rewrite. . . .

  8. Re: Is this code in gcc 4.3.1 valid C or is Sun compiler wrong ??

    On Aug 8, 2:07 pm, "Richard B. Gilbert"
    wrote:
    > mommycal...@gmail.com wrote:
    > > On Jul 23, 10:22 am, Riot Nrrrd™ wrote:
    > >> On 2008-07-10 07:02:07 -0700, Andrew Haley
    > >> said:

    >
    > >>> In gnu.gcc.help Dave wrote:
    > >>>> Andrew Haley wrote:
    > >>>>> In gnu.gcc.help Andrew Haley wrote:
    > >>>>>> In gnu.gcc.help Thad Smith wrote:
    > >>>>>>> The code invokes the macro with a missing first argument. That is valid
    > >>>>>>> C99, but undefined in C90 (see the recent CLC thread on "empty macro
    > >>>>>>> arguments").
    > >>>>>> Yes, you're right. This is a bug: empty macro arguments were
    > >>>>>> undefined in C89, but it was a common extension even then. I'll fix
    > >>>>>> this.
    > >>>>> I have fixed it, and I have added a warning to gcc so that
    > >>>>> if anyone ever uses empty macro arguments in the gcc source
    > >>>>> the build will abort, even when building with gcc.
    > >>>> It's good to hear it is fixed, but there seems to be an overall
    > >>>> problem with gcc in that features are added, but it is difficult to
    > >>>> build on non-Linux systems. Building on SPARC is no easy task, with
    > >>>> one having to go to great lengths to find the right version of gcc
    > >>>> to build it with (Sun's compilers are incapable of building gcc).
    > >>> Well, that's bad. Our official position is that gcc needs an ISO-C89
    > >>> compiler to build, and any use of language extensions to C89 in gcc
    > >>> sources is a bug.
    > >>> For any problem bootstrapping gcc with Sun's compilers the question is
    > >>> whether Sun's tools are deficient in some way or gcc is incorrect. In
    > >>> this particular case there wasn't any question, so I fixed gcc.
    > >>>> Is it any wonder that places that keep Solaris binaries (Blastwave,
    > >>>> Sunfreeware) don't regularly update gcc like they do other
    > >>>> programs. It must seems too difficult/problematic to build, so
    > >>>> people don't bother.
    > >>> We want people to be able to build gcc on their systems. However some
    > >>> ports are unmaintained simply because no gcc maintainer uses them.
    > >>> The only way we can fix that is to ask people who do use these systems
    > >>> to help us.
    > >> How ironic, building GCC on SunOS/Solaris used to be one of the
    > >> canonical GCC ports. Now a release can come out and no one even
    > >> bothers to test bootstrapping it with Sun Studio 12 anymore?

    >
    > >> I am trying to build 4.3.1 on Solaris 9 SPARC and am running into this
    > >> exact same problem (using Sun Studio 12 to do the initial bootstrap
    > >> phase).

    >
    > >> One thing I hadn't seen mentioned in this thread is the "-xc99"
    > >> switch to Sun Studio 12's "cc", but trying this (CC="cc -xc99" before
    > >> "configure") still fails, in one of two ways:

    >
    > >> (1) If you try using "-xc99" Sun's compilers treat it as "-xc99=all",
    > >> and they don't support "-xc99=libs" (part of "all") on Solaris 9.

    >
    > >> (2) If you try using "-xc99=all,no_lib" it "compiles" but again returns
    > >> the same error as the O.P. got, i.e. it looks like this directive was
    > >> essentially a NOP instruction. Same thing for "-xc99=none" as well.

    >
    > >> It looks like there is no way to trick the Sun Studio 12 C compiler to
    > >> compile that one "gcc/c-common.c" file due to this macro. Not on
    > >> Solaris 9 for SPARC, at least.

    >
    > >> When can we see this "fix" you speak of, Andrew? Do we have to wait
    > >> for GCC 4.3.2? (I don't speak CVS)

    >
    > > Once again the stupid linux weenies claiming to know all about
    > > everything, who cann't get software written without adding their own
    > > little bit of extension to fundamental tools. Of course when they add
    > > their own little tweak it breaks every other tool. As usual the
    > > response is "My tweak should have been part of the definition they
    > > just didn't listen to me" I run into this more and more. A major
    > > scientific package won't compile on anything but DeadRat because the
    > > developers made use of all sorts of DeadRat-only features. Net result
    > > it won't run on SUSE and you cann't compile it on anything but DeadRat
    > > without rewriting majors chunks of it.

    >
    > Well, complete creative freedom and standards don't mix too well. Since
    > a Linux package that rhymes with DeadRat is free and not terribly fussy
    > about what hardware it runs on, using the software in question should
    > not be too great a hardship! The copy I bought, years ago, cost me $100
    > US for which I got about 10 CD-ROMS with executable software, sources,
    > and some documentation. If I had wanted to, I could have downloaded it
    > for free but with no support. "Support" consisted of about 25 GB of
    > patches over the course of a year.
    >
    > Or, if you just CAN'T STAND IT, you can do the major rewrite. . . .


    DeadRat not fussy!!! I'd like some of the stuff you're smoke'n

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2