gcc -std=c89 wrongly predefines the macro `i386'. gcc -ansi correctly does not define it. gcc -std=c99 has the same bug. -std=c89 should act exactly the same as -ansi. I previously reported this to gcc-bugs in April; and am now reporting it again to get it in the GNATS database. http://gcc.gnu.org/ml/gcc-bugs/2000-04/msg00433.html Release: 2.96 Environment: System: Linux decomino 2.2.17 #1 Mon Sep 4 20:22:16 UTC 2000 i686 unknown Architecture: i686 host: i686-pc-linux-gnu build: i686-pc-linux-gnu target: i686-pc-linux-gnu
State-Changed-From-To: open->suspended State-Changed-Why: I've fixed the specific problem I described in this PR. However, there are many places in the specs in the config directory with the same problem (checking only for -ansi), and all of these need to be fixed before the underlying issue behind this PR can be considered solved. It seems the best way of handling this may be as part of a redesign of specs and the driver / front end / cpp interface, so that these macros can naturally depend on the internal determination of whether the mode is strict standard or not, rather than on an independent specification in the specs.
From: jsm28@gcc.gnu.org To: gcc-gnats@gcc.gnu.org, jsm28@cam.ac.uk, nobody@gcc.gnu.org Cc: Subject: Re: c/545 Date: 11 Jan 2001 13:27:45 -0000 Synopsis: -std=c89 defines macros it shouldn't State-Changed-From-To: open->suspended State-Changed-By: jsm28 State-Changed-When: Thu Jan 11 05:27:45 2001 State-Changed-Why: I've fixed the specific problem I described in this PR. However, there are many places in the specs in the config directory with the same problem (checking only for -ansi), and all of these need to be fixed before the underlying issue behind this PR can be considered solved. It seems the best way of handling this may be as part of a redesign of specs and the driver / front end / cpp interface, so that these macros can naturally depend on the internal determination of whether the mode is strict standard or not, rather than on an independent specification in the specs. http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=545&database=gcc
Responsible-Changed-From-To: unassigned->neil Responsible-Changed-Why: Working on a fix as part of a switch handling overhaul.
State-Changed-From-To: suspended->analyzed State-Changed-Why: No longer suspended.
Responsible-Changed-From-To: neil->unassigned Responsible-Changed-Why: Not mine.
Responsible-Changed-From-To: unassigned->neil Responsible-Changed-Why: Mine. Slowly going through config/ fixing all this stuff properly.
There's been some serious switch handling overhauls; what's the status of this? Currently it's a vague bug with no testcase, so I don't like it. :-)
Subject: Re: -std=c89 defines macros it shouldn't neroden at gcc dot gnu dot org wrote:- > PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org. > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=545 > > > > ------- Additional Comments From neroden at gcc dot gnu dot org 2003-07-05 20:51 ------- > There's been some serious switch handling overhauls; what's the status of this? > Currently it's a vague bug with no testcase, so I don't like it. :-) It's nothing to do with switches, it's a config/ spec problem. It's way better than it used to be, but it's still a bug. Neil.
Subject: Re: -std=c89 defines macros it shouldn't On Sat, 5 Jul 2003, neil at daikokuya dot co dot uk wrote: > > ------- Additional Comments From neroden at gcc dot gnu dot org 2003-07-05 20:51 ------- > > There's been some serious switch handling overhauls; what's the status of this? > > Currently it's a vague bug with no testcase, so I don't like it. :-) > > It's nothing to do with switches, it's a config/ spec problem. It's way > better than it used to be, but it's still a bug. Indeed, the basic test is to grep for "ansi" in config/. Any reference in specs that doesn't also check for "std=c" and "std=i" is a bug. (Most if not all references should actually move from specs to code executed in cc1 that checks flag_iso; only where there's some reason it needs to stay in specs should the std=c and std=i checks be added there.)
Current files with "ansi" references in specs: svr4.h sol2.h ptx4.h rs6000/sysv4.h rs6000/aix.h rs6000/aix41.h rs6000/aix43.h rs6000/aix51.h rs6000/aix52.h m68k/m68k-none.h m68k/hp320.h i386/sco5.h i386/cygwin.h i370/linux.h cris/linux.h So it's persistent on unpopular triplets, as usual. Though cygwin is a surprise.
Subject: Re: -std=c89 defines macros it shouldn't neroden at gcc dot gnu dot org wrote:- > PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org. > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=545 > > > > ------- Additional Comments From neroden at gcc dot gnu dot org 2003-07-12 05:00 ------- > Current files with "ansi" references in specs: Note that this gets some of the remaining ones, but there are others without ansi references too. Neil.
Let's try to get this one by 3.4, or at least improve the situation some more.
Subject: Re: -std=c89 defines macros it shouldn't neroden at gcc dot gnu dot org wrote:- > PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org. > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=545 > > > neroden at gcc dot gnu dot org changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Last reconfirmed|0000-00-00 00:00:00 |2003-07-14 03:46:16 > date| | > Target Milestone|--- |3.4 > > > ------- Additional Comments From neroden at gcc dot gnu dot org 2003-07-14 03:46 ------- > Let's try to get this one by 3.4, or at least improve the situation some more. Feel free - 3.4 is already a lot better than 3.3. Neil.
Pushing to 3.5.
PR 26052 is the bug for cgwin.
Not much has changed. For r131688: ./ptx4.h ./sol2.h ./svr4.h ./cris/aout.h ./rs6000/aix53.h ./rs6000/sysv4.h ./rs6000/aix51.h ./rs6000/aix.h ./rs6000/aix52.h ./rs6000/aix43.h ./rs6000/aix41.h ./i386/sco5.h ./i386/cygwin.h
(In reply to Ben Elliston from comment #16) > Not much has changed. For r131688: > > ./ptx4.h > ./svr4.h > ./cris/aout.h > ./rs6000/aix53.h > ./rs6000/aix51.h > ./rs6000/aix52.h > ./rs6000/aix43.h > ./rs6000/aix41.h > ./i386/sco5.h This first batch of headers no longer exists. > ./sol2.h In this header, the check for "ansi" also checks for "std=c" and "std=i" so I think that means it should be considered fixed. > ./rs6000/sysv4.h This header no longer references "ansi" so it can be ignored. > ./rs6000/aix.h > ./i386/cygwin.h These last 2 headers still need to be fixed.