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 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.
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
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);
}
with -O2 -fno-omit-frame-pointer, f1 will be implicitly use:
__attribute__((optimize("O2", "no-gcse")))
and this implicit -O2 will override the explicit -fno-omit-frame-pointer.
So f1 will be compiled without a frame pointer but f2 will be compiled
with one.
Is this really what we want? If so, I think it's subtle enough to be
worth documenting. It certainly isn't what I was expecting after
reading the current documentation.
Richard
[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.
Re: Documentation and behaviour of the "optimize" attribute
On Fri, Jan 2, 2009 at 12:36 PM, Richard Sandiford
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)
> {
>bar (1);
>bar (2);
> }
>
> with -O2 -fno-omit-frame-pointer, f1 will be implicitly use:
>
> __attribute__((optimize("O2", "no-gcse")))
>
> and this implicit -O2 will override the explicit -fno-omit-frame-pointer.
> So f1 will be compiled without a frame pointer but f2 will be compiled
> with one.
>
> Is this really what we want? If so, I think it's subtle enough to be
> worth documenting. It certainly isn't what I was expecting after
> reading the current documentation.
IMHO this is a bug. And IMHO this optimize attribute went way over what was
reasonable to implement as a start - leading to all of these
interesting problems.
Richard.
> Richard
>
RE: [IRA] New register allocator question
I found if I define a new register class that covers both GR_REGS and PR_REGS,
the issue can be solved. New IRA spill the predicate register to general
regsister first instead of memory. Is this right approach?
#define IRA_COVER_CLASSES \
{ \
GRPR_REGS, M_REGS, BXBC_REGS, LIM_REG_CLASSES \
}
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On
> Behalf Of Bingfeng Mei
> Sent: 02 January 2009 11:50
> To: gcc@gcc.gnu.org
> Cc: Vladimir Makarov
> Subject: [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.
>
>
>
Re: Compiler turns off warnings unexpectedly
On Thu, Jan 01, 2009 at 03:11:52AM +0100, Jan Engelhardt wrote: > > On Thursday 2009-01-01 03:05, Andrew Pinski wrote: > >On Wed, Dec 31, 2008 at 9:02 PM, Jan Engelhardt 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. Likely related to PR37902. Jakub
Re: Documentation and behaviour of the "optimize" attribute
On Fri, Jan 2, 2009 at 4:05 AM, Richard Guenther
wrote:
> On Fri, Jan 2, 2009 at 12:36 PM, Richard Sandiford
> 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)
>> {
>>bar (1);
>>bar (2);
>> }
>>
>> with -O2 -fno-omit-frame-pointer, f1 will be implicitly use:
>>
>> __attribute__((optimize("O2", "no-gcse")))
>>
>> and this implicit -O2 will override the explicit -fno-omit-frame-pointer.
>> So f1 will be compiled without a frame pointer but f2 will be compiled
>> with one.
>>
>> Is this really what we want? If so, I think it's subtle enough to be
>> worth documenting. It certainly isn't what I was expecting after
>> reading the current documentation.
>
> IMHO this is a bug. And IMHO this optimize attribute went way over what was
> reasonable to implement as a start - leading to all of these
> interesting problems.
>
Also see:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37565
--
H.J.
writing md rules for fixed-point conversion
I am working toward efficient support of some of the sfixed point types on avr architecture. I started out by writing an assembly library to handle all of the conversions to and from various fixed point, integer, and floating point types. In many cases the functions are only 1 or 2 instructions, so I would like to implement them in the machine descriptor language so there isn't a function call needed, and the registers can be used more efficiently. I was able to get addition of fixed point rules working, eg: (define_insn "addqq3" [(set (match_operand:QQ 0 "register_operand" "=r") (plus:QQ (match_operand:QQ 1 "register_operand" "%0") (match_operand:QQ 2 "register_operand" "r")))] "" "add %0,%2" [(set_attr "length" "1") (set_attr "cc" "set_czn")]) This rule works correctly and adds numbers. The problem is I can't get conversions to work, and I'm wondering if something is missing in the compiler elsewhere. Here is what I tried: (define_insn "fractqiqq" [(set (match_operand:QQ 0 "register_operand" "=r") (fract_convert:QQ (match_operand:QI 1 "register_operand" "0")))] "" "clr %0" [(set_attr "length" "1") (set_attr "cc" "set_czn")]) However, it always generates "rcall __fractqiqq" so it isn't using my rule. I also found that the fixed point conversions specified at "http://gcc.gnu.org/onlinedocs/gccint/Conversions.html"; are not used by any backend currently, so I don't have any examples to work with. Has anyone used any of the following in machine description? fract_convert sat_fract unsigned_fract_convert unsigned_sat_fract I would like some examples. Thanks, Sean
gcc-4.4-20090102 is now available
Snapshot gcc-4.4-20090102 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090102/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 143016 You'll find: gcc-4.4-20090102.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20090102.tar.bz2 C front end and core compiler gcc-ada-4.4-20090102.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20090102.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20090102.tar.bz2 C++ front end and runtime gcc-java-4.4-20090102.tar.bz2 Java front end and runtime gcc-objc-4.4-20090102.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20090102.tar.bz2The GCC testsuite Diffs from 4.4-20081226 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 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.
