New blank line after 'all warnings being treated as errors'
After -Werror is triggered, we are now emitting an extra blank line that we were not emitting before. Was this change intentional? Does anyone recognize this? $ cat a.cc char c = 257; $ g++-4.4.3 -c -o /dev/null -Werror a.cc cc1plus: warnings being treated as errors a.cc:1: error: overflow in implicit constant conversion $ But with trunk, I get: $ ~/gcc-trunk/native/bin/g++ -c -o /dev/null -Werror a.cc a.cc:1:10: error: overflow in implicit constant conversion [-Werror=overflow] cc1plus: all warnings being treated as errors [... extra blank line ...] $ It looks odd. Should we change it back to the old way? (maybe I just missed the documentation on the change). Thanks. Diego.
Re: Liqin Chen now maintainer of SCORE port
Mark Mitchell 写于 2011-03-02 07:20:46: > Liqin -- > > The GCC SC has appointed you the maintainer of the SCORE back-end. > * MAINTAINERS: Update myself as score backend maintainer, update my e-mail address. committed to trunk. Thanks, --liqin Index: MAINTAINERS === --- MAINTAINERS (revision 170862) +++ MAINTAINERS (working copy) @@ -91,6 +91,7 @@ rx port Nick Clifton nickc@redh s390 port Hartmut Penner hpen...@de.ibm.com s390 port Ulrich Weigand uweig...@de.ibm.com s390 port Andreas Krebbel andreas.kreb...@de.ibm.com +score port Chen Liqin liqin@gmail.com sh portAlexandre Oliva aol...@redhat.com sh portKaz Kojima kkoj...@gcc.gnu.org sparc port Richard Henderson r...@redhat.com @@ -408,7 +409,6 @@ Terry Laurenzo tlaure...@gmail.com Marc Lehmann p...@goof.com James Lemkejwle...@juniper.net Kriang Lerdsuwanakij lerds...@users.sourceforge.net -Chen Liqin liqin.c...@sunplusct.com Sa Liu sa...@de.ibm.com Ralph Loader r...@ihug.co.nz Gabor Loki l...@inf.u-szeged.hu
Re: pr45055 on non-scheduling targets...
On Tue, 15 Feb 2011, DJ Delorie wrote: > > pr45055 tests a scheduling fix, but on targets that don't support > scheduling (like m32c-elf), gcc emits a warning that scheduling is not > supported. This warning causes the test to fail. How do we bypass > these types of test cases? I don't see a suitable effective_target > for scheduling. Add the missing predicate and use it? > FAIL: gcc.dg/pr45055.c (test for excess errors) brgds, H-P
gcc-4.5-20110310 is now available
Snapshot gcc-4.5-20110310 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20110310/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch revision 170852 You'll find: gcc-4.5-20110310.tar.bz2 Complete GCC (includes all of below) MD5=6b392197fc6d655f20c36fb3857b8b1b SHA1=04f43f367021e889b4f2305f7eb5a61a798ac8b7 gcc-core-4.5-20110310.tar.bz2C front end and core compiler MD5=bb7bb6fe565164770afba4a0120ec461 SHA1=0a5ff0bb2bd22412075e90d897baa0388e8f1c11 gcc-ada-4.5-20110310.tar.bz2 Ada front end and runtime MD5=f46d613dd2228bc7e3f711c8ac980be9 SHA1=845319bc721c7c3fd1150ba53ab09bdbd389b081 gcc-fortran-4.5-20110310.tar.bz2 Fortran front end and runtime MD5=09b48a9d3c78a2bd8f85a99f101a17bf SHA1=ffbafb3b975fb4d97f2fbf10c352500a856de2b5 gcc-g++-4.5-20110310.tar.bz2 C++ front end and runtime MD5=76b9a8092ad897d5ce6b5ac17ededb4c SHA1=432f63528e864b690dfd036c13888513e945502d gcc-go-4.5-20110310.tar.bz2 Go front end and runtime MD5=ddf0183a6168873be07b8e96b2733eee SHA1=86ff65720f6280d818af3d54ba7f6a76a3e4e0de gcc-java-4.5-20110310.tar.bz2Java front end and runtime MD5=a5711d15a3654ea33d976ead79b5f10a SHA1=1b37e3a6dd59400b89d4e4f7f4af173df24d94d1 gcc-objc-4.5-20110310.tar.bz2Objective-C front end and runtime MD5=df660e2324db18a3667208ecbb2d15e4 SHA1=bba8ff2fdde97c9b3c2477852707da44aa979303 gcc-testsuite-4.5-20110310.tar.bz2 The GCC testsuite MD5=229bdc287276af92b105e3734f2ab2cc SHA1=bc1750dd3c801f8f49c4b7f19fee0eea7389e0e8 Diffs from 4.5-20110303 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 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.
Re: Handling strictness in {predicates,constraints}.md [was: Re: Converting CRIS to constraints.md]
> From: Eric Botcazou > Date: Thu, 10 Mar 2011 18:42:14 +0100 > SPARC had exactly the same pattern as the 'U' constraint of MMIX. It now > uses > reload_in_progress || reload_completed instead (in memory_ok_for_ldd). Nathan suggested that; great confirmation! Thanks. brgds, H-P
Re: Handling strictness in {predicates,constraints}.md [was: Re: Converting CRIS to constraints.md]
> I haven't ran into that problem; all the targets I've converted to
> constraints.md haven't had constraints that changed based on strictness.
> I think the right thing to do is depend on
> reload_{in_progress,completed}
> (cf. rs6000/predicates.md:volatile_memory_operand), but I freely admit
> this is a part of the compiler that I'm not familiar with.
SPARC had exactly the same pattern as the 'U' constraint of MMIX. It now uses
reload_in_progress || reload_completed instead (in memory_ok_for_ldd).
--
Eric Botcazou
Re: Handling strictness in {predicates,constraints}.md [was: Re: Converting CRIS to constraints.md]
> Date: Thu, 10 Mar 2011 17:55:38 +0100
> From: Paolo Bonzini
> On 03/10/2011 04:47 PM, Nathan Froyd wrote:
> > [moving to gcc@ to get input from a wider audience]
> >
> > On Thu, Mar 10, 2011 at 06:47:20AM +0100, Hans-Peter Nilsson wrote:
> >>> From: Nathan Froyd
> >>> On Thu, Mar 10, 2011 at 04:02:27AM +0100, Hans-Peter Nilsson wrote:
> >> Hm. Speaking of macros with semantics different depending on
> >> REG_OK_STRICT being defined (should be just register and address
> >> constraints), how do you do that in constraints.md?
> > ... knowing how to deal with strictness would help a great deal.
>
> I guess you can leave everything in the target header and use a macro.
> This basically depends on the constraint checks being always in a header
> (tm_constrs.h).
Yah, I'd already tried that, defining constraints like
+(define_constraint "R"
+ "An operand to BDAP or BIAP"
+ (match_test "EXTRA_CONSTRAINT_R (op)"))
with the definition of EXTRA_CONSTRAINT_R still in cris.h, but I
get what seems to be a strict-related fallout (the inner mem
should have been a register):
/tmp/constrmd/gccobj/./gcc/xgcc -B/tmp/constrmd/gccobj/./gcc/ -nostdinc
-B/tmp/constrmd/gccobj/cris-elf/v10/newlib/ -isystem
/tmp/constrmd/gccobj/cris-elf/v10/newlib/targ-include -isystem
/tmp/constrmd/gcc/newlib/libc/include
-B/tmp/constrmd/gccobj/cris-elf/v10/libgloss/cris
-L/tmp/constrmd/gccobj/cris-elf/v10/libgloss/libnosys
-L/tmp/constrmd/gcc/libgloss/cris -B/tmp/constrmd/pre/cris-elf/bin/
-B/tmp/constrmd/pre/cris-elf/lib/ -isystem /tmp/constrmd/pre/cris-elf/include
-isystem /tmp/constrmd/pre/cris-elf/sys-include -march=v10 -mbest-lib-options
-DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
-DPACKAGE_VERSION=\"1.18.0\" -DPACKAGE_STRING=\"newlib\ 1.18.0\"
-DPACKAGE_BUGREPORT=\"\" -I. -I/tmp/constrmd/gcc/newlib/libc/stdlib
-DHAVE_RENAME -D_USE_WRITE -DCOMPACT_CTYPE -fno-builtin -g -O2 -march=v10
-mbest-lib-options -c -o lib_a-gdtoa-gethex.o `test -f 'gdtoa-gethex.c' || echo
'/tmp/constrmd/gcc/newlib/libc/stdlib/'`gdtoa-gethex.c
/tmp/constrmd/gcc/newlib/libc/stdlib/gdtoa-gethex.c: In function '__gethex':
/tmp/constrmd/gcc/newlib/libc/stdlib/gdtoa-gethex.c:353:1: error: insn does not
satisfy its constraints:
(insn 171 170 172 14 (parallel [
(set (reg:QI 9 r9 [orig:283 prephitmp.192 ] [283])
(mem:QI (plus:SI (reg/v/f:SI 1 r1 [orig:65 s0 ] [65])
(mem/c:SI (plus:SI (reg/f:SI 14 sp)
(const_int 40 [0x28])) [9 %sfp+-32 S4 A8])) [0
*s_81+0 S1 A8]))
(set (reg/v/f:SI 0 r0 [orig:34 s ] [34])
(plus:SI (reg/v/f:SI 1 r1 [orig:65 s0 ] [65])
(mem/c:SI (plus:SI (reg/f:SI 14 sp)
(const_int 40 [0x28])) [9 %sfp+-32 S4 A8])))
]) /tmp/constrmd/gcc/newlib/libc/stdlib/gdtoa-gethex.c:173 21
{*mov_sideqi}
(nil))
/tmp/constrmd/gcc/newlib/libc/stdlib/gdtoa-gethex.c:353:1: internal compiler
error: in reload_cse_simplify_operands, at postreload.c:403
and even if it had worked, a happens-to-work solution like this
seems a bit brittle, but worth trying.
I think I'll have to rework the macros used in the constraints
to not depend on REG_OK_STRICT or something. Anyway, postponed
for now, revisit in 4.7.
brgds, H-P
Re: RFC: target hook to reverse bitfield allocations
> And I think the adjustments should not be done after the fact in > finish_record_layout, but rather right in place_field, where also > the fields alignment and mode are properly tracked. It would be a lot harder to keep track of which bits are allocated and which aren't if we do it in place_field. The current algorithm always allocates bits in monotonic sequence.
Re: Handling strictness in {predicates,constraints}.md [was: Re: Converting CRIS to constraints.md]
On 03/10/2011 04:47 PM, Nathan Froyd wrote:
[moving to gcc@ to get input from a wider audience]
On Thu, Mar 10, 2011 at 06:47:20AM +0100, Hans-Peter Nilsson wrote:
From: Nathan Froyd
On Thu, Mar 10, 2011 at 04:02:27AM +0100, Hans-Peter Nilsson wrote:
PS. If you really feel for it, I won't stop you converting MMIX. :)
Heh. I looked at doing MMIX; I think the only tricky thing might be
dealing with the 'U' constraint.
Hm. Speaking of macros with semantics different depending on
REG_OK_STRICT being defined (should be just register and address
constraints), how do you do that in constraints.md? I looked
around but haven't found the answer. I guess you've bumped into
that problem a few times now, or some converted target will find
out the hard way?
(Please CC any reply to gcc@)
I haven't ran into that problem; all the targets I've converted to
constraints.md haven't had constraints that changed based on strictness.
I think the right thing to do is depend on
reload_{in_progress,completed}
(cf. rs6000/predicates.md:volatile_memory_operand), but I freely admit
this is a part of the compiler that I'm not familiar with.
In fact, I think the only targets remaining for constraints.md are
(besides h8300, which I haven't received an ack on yet) are:
- mmix ('U' dependent on strictness);
- cris (all interesting constraints based on strictness, I think);
- m32c (tedious to convert due to m32c-specific encode_pattern).
so knowing how to deal with strictness would help a great deal.
I guess you can leave everything in the target header and use a macro.
This basically depends on the constraint checks being always in a header
(tm_constrs.h).
Paolo
Handling strictness in {predicates,constraints}.md [was: Re: Converting CRIS to constraints.md]
[moving to gcc@ to get input from a wider audience]
On Thu, Mar 10, 2011 at 06:47:20AM +0100, Hans-Peter Nilsson wrote:
> > From: Nathan Froyd
> > On Thu, Mar 10, 2011 at 04:02:27AM +0100, Hans-Peter Nilsson wrote:
> > > PS. If you really feel for it, I won't stop you converting MMIX. :)
> >
> > Heh. I looked at doing MMIX; I think the only tricky thing might be
> > dealing with the 'U' constraint.
>
> Hm. Speaking of macros with semantics different depending on
> REG_OK_STRICT being defined (should be just register and address
> constraints), how do you do that in constraints.md? I looked
> around but haven't found the answer. I guess you've bumped into
> that problem a few times now, or some converted target will find
> out the hard way?
>
> (Please CC any reply to gcc@)
I haven't ran into that problem; all the targets I've converted to
constraints.md haven't had constraints that changed based on strictness.
I think the right thing to do is depend on
reload_{in_progress,completed}
(cf. rs6000/predicates.md:volatile_memory_operand), but I freely admit
this is a part of the compiler that I'm not familiar with.
In fact, I think the only targets remaining for constraints.md are
(besides h8300, which I haven't received an ack on yet) are:
- mmix ('U' dependent on strictness);
- cris (all interesting constraints based on strictness, I think);
- m32c (tedious to convert due to m32c-specific encode_pattern).
so knowing how to deal with strictness would help a great deal.
-Nathan
Re: latent issues with stack_ties on ppc ?
Olivier Hainque wrote:
> do we still have a latent problem in this case ?
I believe we do. Here is a C testcase recreating one problematic
situation artificially
char mysym;
char * volatile g;
void foo (long x)
{
char volatile s [x];
register char * volatile ptr asm("11");
asm volatile ("" : : : "25");
ptr = &mysym;
g = ptr;
}
With a recent mainline configured for powerpc-wrs-vxworks,
./cc1 t.c -O2 generates
...
addi 11,31,48
stw 0,g@l(9)
mr 1,11 <===
lwz 0,4(11)
lwz 25,-28(11) <===
mtlr 0
lwz 31,-4(11)
blr
the stack pointer restore was moved prior to the registers restore ops,
despite an attempt at preventing that (as required by the ABI) from
emit_prologue:
(note 39 24 40 2 NOTE_INSN_EPILOGUE_BEG)
(insn 40 39 41 2 (set (reg:SI 11 11)
(plus:SI (reg/f:SI 31 31)
(const_int 48 [0x30]))) t.c:11 -1
...
(insn 43 42 44 2 (set (reg:SI 25 25)
(mem/c:SI (plus:SI (reg:SI 11 11)
(const_int -28 [0xffe4])) [3 S4 A8])) t.c:11 -1
...
(insn 45 44 46 2 (set (mem/c:BLK (reg/f:SI 1 1) [3 A8]) <===
(unspec:BLK [ <===
(mem/c:BLK (reg/f:SI 1 1) [3 A8]) <===
(insn/f 46 45 47 2 (set (reg/f:SI 1 1)
(reg:SI 11 11)) t.c:11 -1
In the specific case at hand, there's no mem access dependence
established between insns 45 and 43, so both 45 and 46 are allowed to
move up.
While I see what's going on in the dependency computation here, I'm not
sure whether the correction should be in this area or if the mem accesses
are not supposed to be claimed conflicting anyway, in which case the stack
tie insn should be adjusted.
Olivier
Re: RFC: target hook to reverse bitfield allocations
Hi, On Wed, 9 Mar 2011, DJ Delorie wrote: > To avoid having two completely independent definitions of the > peripheral register structures, would it be acceptable to add a target > hook to tell gcc to reverse the bitfields? This can be done in > finish_record_layout() by adjusting bit offsets, but is only defined > for targets where switching bitfield base types starts a new > allocation (i.e. "long x:4;" and "char x;" can't overlap) or where the > user is careful to avoid such a situation. Not going into the debate about sensibility of such a mean, but IMHO: there is nothing target specific about this, hence no target hook. It should be an attribute on either the struct type, or even on the individual FIELD_DECLs (which doesn't necessarily mean the use has to annotate each field, how that attribute is going to be set via frontends means, i.e. a real attribute on the fields, or on the type, or via pragmas isn't interesting for the design of this thing). And I think the adjustments should not be done after the fact in finish_record_layout, but rather right in place_field, where also the fields alignment and mode are properly tracked. Ciao, Michael.
