headers
Jan Engelhardt | 1 Jan 2009 03:02
Picon

Compiler turns off warnings unexpectedly

Hi,

I have here an (attached) testcase which unexpectedly turns off 
warnings. Compiling it using `gcc test.c -c -Wall` (or test.i) gives:

test.c: In function ‘pam_sm_authenticate’:
test.c:6: warning: implicit declaration of function ‘undef’

What I would have expected:

test.c: In function ‘pam_sm_authenticate’:
test.c:6: warning: implicit declaration of function ‘undef’
test.c: In function ‘pam_sm_authenticate’:
test.c:11: warning: implicit declaration of function ‘undef2’

Compiler in use:

openSUSE 11.1
Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info 
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib 
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada 
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3 
--enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/ 
--with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap 
--with-slibdir=/lib --with-system-zlib --enable-__cxa_atexit 
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch 
--enable-version-specific-runtime-libs --program-suffix=-4.3 
--enable-linux-futex --without-system-libunwind --with-cpu=generic
(Continue reading)

Permalink | Reply | 5 comments |
headers
Andrew Pinski | 1 Jan 2009 03:05
Picon

Re: Compiler turns off warnings unexpectedly

On Wed, Dec 31, 2008 at 9:02 PM, Jan Engelhardt <jengelh <at> medozas.de> wrote:
> Hi,
>
>
> I have here an (attached) testcase which unexpectedly turns off
> warnings. Compiling it using `gcc test.c -c -Wall` (or test.i) gives:
>
> test.c: In function 'pam_sm_authenticate':
> test.c:6: warning: implicit declaration of function 'undef'

This works on the trunk but fails on the 4.3 branch.

Thanks,
Andrew Pinski
Permalink | Reply | 4 comments |
headers
Jan Engelhardt | 1 Jan 2009 03:11
Picon

Re: Compiler turns off warnings unexpectedly


On Thursday 2009-01-01 03:05, Andrew Pinski wrote:
>On Wed, Dec 31, 2008 at 9:02 PM, Jan Engelhardt <jengelh <at> medozas.de> wrote:
>> Hi,
>>
>>
>> I have here an (attached) testcase which unexpectedly turns off
>> warnings. Compiling it using `gcc test.c -c -Wall` (or test.i) gives:
>>
>> test.c: In function 'pam_sm_authenticate':
>> test.c:6: warning: implicit declaration of function 'undef'
>
>This works on the trunk but fails on the 4.3 branch.

gcc 4.1 also produces the expected output (implicit declaration undef2),
so it seems like a recent regression.
Permalink | Reply | 3 comments |
headers
Perry Smith | 1 Jan 2009 16:00
Picon
Gravatar

Building gcc on AIX 5.3 TL08

I just discovered that the build sequence for gcc on AIX version 5.3,  
what is called "TL08" fails.  The first symptom is options.h has  
double defines in it.

e.g.

redeclaration of enumerator 'OPT_d'

But even after that is fixed by hand, there are other issues.

Switching from AIX's awk or nawk to GNU's awk (gawk) solves the issues.

I first tried building gcc 4.0.2 and then tried gcc 4.2.0.  Both had  
the same issues.  I know that I have built gcc (using gcc) on AIX 5.3  
before but it must have been an older level of AIX.

Perry
Ease Software, Inc. ( http://www.easesoftware.com )

Low cost SATA Disk Systems for IBMs p5, pSeries, and RS/6000 AIX systems
Permalink | Reply | 0 comments |
headers
gccadmin | 1 Jan 2009 23:50
Picon
Favicon

gcc-4.3-20090101 is now available

Snapshot gcc-4.3-20090101 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20090101/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 142999

You'll find:

gcc-4.3-20090101.tar.bz2              Complete GCC (includes all of below)

gcc-core-4.3-20090101.tar.bz2         C front end and core compiler

gcc-ada-4.3-20090101.tar.bz2          Ada front end and runtime

gcc-fortran-4.3-20090101.tar.bz2      Fortran front end and runtime

gcc-g++-4.3-20090101.tar.bz2          C++ front end and runtime

gcc-java-4.3-20090101.tar.bz2         Java front end and runtime

gcc-objc-4.3-20090101.tar.bz2         Objective-C front end and runtime

gcc-testsuite-4.3-20090101.tar.bz2    The GCC testsuite

Diffs from 4.3-20081225 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.3
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dodji Seketeli | 2 Jan 2009 10:34
Picon
Favicon

Re: Compiler turns off warnings unexpectedly

Jan Engelhardt a écrit :
> On Thursday 2009-01-01 03:05, Andrew Pinski wrote:
>> On Wed, Dec 31, 2008 at 9:02 PM, Jan Engelhardt <jengelh <at> medozas.de> wrote:
>>> Hi,
>>>
>>>
>>> I have here an (attached) testcase which unexpectedly turns off
>>> warnings. Compiling it using `gcc test.c -c -Wall` (or test.i) gives:
>>>
>>> test.c: In function 'pam_sm_authenticate':
>>> test.c:6: warning: implicit declaration of function 'undef'
>> This works on the trunk but fails on the 4.3 branch.
> 
> gcc 4.1 also produces the expected output (implicit declaration undef2),
> so it seems like a recent regression.

I guess filling a bug at http://gcc.gnu.org/bugzilla about this 
regression would help.

Thanks.
Permalink | Reply | 1 comment |
headers
Paolo Bonzini | 2 Jan 2009 12:04
Picon
Gravatar

Re: Compiler turns off warnings unexpectedly


>>>> I have here an (attached) testcase which unexpectedly turns off
>>>> warnings. Compiling it using `gcc test.c -c -Wall` (or test.i) gives:
>>>>
>>>> test.c: In function 'pam_sm_authenticate':
>>>> test.c:6: warning: implicit declaration of function 'undef'
>>> This works on the trunk but fails on the 4.3 branch.
>>
>> gcc 4.1 also produces the expected output (implicit declaration undef2),
>> so it seems like a recent regression.
> 
> I guess filling a bug at http://gcc.gnu.org/bugzilla about this
> regression would help.

As would adding the reduced testcase to the testsuite for trunk to
ensure we don't regress again. :-)

Will do so next week if nobody beats me to it.

Paolo
Permalink | Reply | 0 comments |
headers
Richard Sandiford | 2 Jan 2009 12:36

Documentation and behaviour of the "optimize" attribute

Hi,

Sorry in advance if this going over old ground.  And if not, sorry
for the somewhat negative message ;), but ...  I think the current
documentation and/or behaviour of the "optimize" attribute are a little
confusing.

The current behaviour is that, if __attribute__((optimize(...))) does
not specify an optimisation level (-Ox), we act as though the prevailing
-Ox level had been restated.  So:

  __attribute__((optimize("no-gcse")))

behaves like:

  __attribute__((optimize("Ox", "no-gcse")))

where Ox is the current optimisation level.  This means that if you
compile:

  void bar (int);
  void __attribute__((optimize("no-gcse"))) f1 (void)
  {
    bar (1);
    bar (2);
  }
  void f2 (void)
  {
    bar (1);
    bar (2);
(Continue reading)

Permalink | Reply | 3 comments |
headers
Bingfeng Mei | 2 Jan 2009 12:50
Favicon

[IRA] New register allocator question

Hello,
I recently ported our GCC to new IRA by following mainline development.  The only interface I added is
IRA_COVER_CLASSES. Our architecture has predicate register file. When predicate register has to be
spilled, the new IRA produces inferior code to the old register allocator.  The old allocator first tries
to spill to general register file, which is far cheaper on our architecture than spilling to memory. The
IRA always spills the predicate register to memory directly.

#define IRA_COVER_CLASSES           \
{              \
  GR_REGS, PR_REGS, M_REGS, BXBC_REGS, LIM_REG_CLASSES      \
}

Apart from above macro, what other interfaces/parameters I can tune to change this behaviour in new IRA? 
Thanks in advance.

Happy New Year,
Bingfeng Mei

Broadcom UK.
Permalink | Reply | 3 comments |
headers
Richard Guenther | 2 Jan 2009 13:05
Picon

Re: Documentation and behaviour of the "optimize" attribute

On Fri, Jan 2, 2009 at 12:36 PM, Richard Sandiford
<rdsandiford <at> googlemail.com> wrote:
> Hi,
>
> Sorry in advance if this going over old ground.  And if not, sorry
> for the somewhat negative message ;), but ...  I think the current
> documentation and/or behaviour of the "optimize" attribute are a little
> confusing.
>
> The current behaviour is that, if __attribute__((optimize(...))) does
> not specify an optimisation level (-Ox), we act as though the prevailing
> -Ox level had been restated.  So:
>
>  __attribute__((optimize("no-gcse")))
>
> behaves like:
>
>  __attribute__((optimize("Ox", "no-gcse")))
>
> where Ox is the current optimisation level.  This means that if you
> compile:
>
>  void bar (int);
>  void __attribute__((optimize("no-gcse"))) f1 (void)
>  {
>    bar (1);
>    bar (2);
>  }
>  void f2 (void)
>  {
(Continue reading)

Permalink | Reply | 2 comments |

Gmane