[GCC PR55056] Re: [RFC patch] testsuite: Workaround issues with GCC 4.8.0pre + gdb.trace new KFAIL
Hi! To highlight this issue again, http://gcc.gnu.org/PR55056, now that Debian testing has switched to GCC 4.8: On Sun, 3 Feb 2013 18:27:21 +0100, Jan Kratochvil jan.kratoch...@redhat.com wrote: gdb/testsuite/ 2013-02-02 Jan Kratochvil jan.kratoch...@redhat.com Workaround GCC PR debug/55056 and GDB PR server/15081. * gdb.base/restore.c (caller3): Protect l1 by GCC_PR_55056 #ifdef. (caller4): Protect l1 and l2 by GCC_PR_55056 #ifdef. (caller5): Protect l1, l2 and l3 by GCC_PR_55056 #ifdef. * gdb.base/restore.exp: New variable opts. Test caller3, caller4 and caller5 for l1, l2 and l3. New prepare_for_testing. * gdb.base/store.c (wack_longest, wack_float, wack_double) (wack_doublest): Protect l and r by GCC_PR_55056 #ifdef. * gdb.base/store.exp: New variable opts. Test longest, float, double and doublest functions for l and r. New prepare_for_testing. * gdb.trace/collection.c (reglocal_test_func): Protect locf and locd by GCC_PR_55056 #ifdef. Protect locar by GDB_PR_15081 #ifdef. * gdb.trace/unavailable.c: Likewise. * gdb.trace/collection.exp: New variable opts. Test reglocal_test_func for locf, locd and locar. New prepare_for_testing. (gdb_collect_locals_test): Increase list size to 43. * gdb.trace/unavailable.exp: Likewise. As far as I can tell, no consensus has yet been reached about the approach to fix this issue discussed in this thread. (I have not looked at the proposed patch in detail.) I had already been configuring my native GDB builds with CC=gcc-4.8 CXX=g++-4.8, and naively assumed the same compiler as specified on the configure command-line would be used for the GDB testsuite -- which is not true, as it now turns out. Is this to be considered a bug in the GDB build/test harness? Anyway, upon Debian testing/unstable just switching the default system compiler from 4.7 to 4.8, the following new FAILs appear in my native x86 GNU/Linux and GNU/Hurd testing: --- [...]/gdb.base2/gdb.sum +++ [...]/gdb.base2/gdb.sum @@ -1395,31 +1395,31 @@ PASS: gdb.base/restore.exp: run to caller3 PASS: gdb.base/restore.exp: caller3 calls callee1; tbreak callee PASS: gdb.base/restore.exp: caller3 calls callee1; continue to callee PASS: gdb.base/restore.exp: caller3 calls callee1; return callee now -PASS: gdb.base/restore.exp: caller3 calls callee1; return restored l1 to 32492 +FAIL: gdb.base/restore.exp: caller3 calls callee1; return restored l1 to 32492 PASS: gdb.base/restore.exp: caller3 calls callee1; return restored l2 to 32493 PASS: gdb.base/restore.exp: caller3 calls callee1; return restored l3 to 32494 PASS: gdb.base/restore.exp: caller3 calls callee2; tbreak callee PASS: gdb.base/restore.exp: caller3 calls callee2; continue to callee PASS: gdb.base/restore.exp: caller3 calls callee2; return callee now -PASS: gdb.base/restore.exp: caller3 calls callee2; return restored l1 to 32492 +FAIL: gdb.base/restore.exp: caller3 calls callee2; return restored l1 to 32492 PASS: gdb.base/restore.exp: caller3 calls callee2; return restored l2 to 32493 PASS: gdb.base/restore.exp: caller3 calls callee2; return restored l3 to 32494 PASS: gdb.base/restore.exp: caller3 calls callee3; tbreak callee PASS: gdb.base/restore.exp: caller3 calls callee3; continue to callee PASS: gdb.base/restore.exp: caller3 calls callee3; return callee now -PASS: gdb.base/restore.exp: caller3 calls callee3; return restored l1 to 32492 +FAIL: gdb.base/restore.exp: caller3 calls callee3; return restored l1 to 32492 PASS: gdb.base/restore.exp: caller3 calls callee3; return restored l2 to 32493 PASS: gdb.base/restore.exp: caller3 calls callee3; return restored l3 to 32494 PASS: gdb.base/restore.exp: caller3 calls callee4; tbreak callee PASS: gdb.base/restore.exp: caller3 calls callee4; continue to callee PASS: gdb.base/restore.exp: caller3 calls callee4; return callee now -PASS: gdb.base/restore.exp: caller3 calls callee4; return restored l1 to 32492 +FAIL: gdb.base/restore.exp: caller3 calls callee4; return restored l1 to 32492 PASS: gdb.base/restore.exp: caller3 calls callee4; return restored l2 to 32493 PASS: gdb.base/restore.exp: caller3 calls callee4; return restored l3 to 32494 PASS: gdb.base/restore.exp: caller3 calls callee5; tbreak callee PASS: gdb.base/restore.exp: caller3 calls callee5; continue to callee PASS: gdb.base/restore.exp: caller3 calls callee5; return callee now -PASS: gdb.base/restore.exp: caller3 calls callee5; return restored l1 to 32492 +FAIL: gdb.base/restore.exp: caller3 calls callee5; return restored l1 to 32492 PASS: gdb.base/restore.exp: caller3 calls callee5; return restored l2 to 32493 PASS: gdb.base/restore.exp: caller3 calls callee5; return restored l3 to 32494 PASS: gdb.base/restore.exp:
Re: [GCC PR55056] Re: [RFC patch] testsuite: Workaround issues with GCC 4.8.0pre + gdb.trace new KFAIL
On Fri, 14 Jun 2013 15:02:47 +0200, Thomas Schwinge wrote: On Sun, 3 Feb 2013 18:27:21 +0100, Jan Kratochvil jan.kratoch...@redhat.com wrote: gdb/testsuite/ 2013-02-02 Jan Kratochvil jan.kratoch...@redhat.com Workaround GCC PR debug/55056 and GDB PR server/15081. * gdb.base/restore.c (caller3): Protect l1 by GCC_PR_55056 #ifdef. (caller4): Protect l1 and l2 by GCC_PR_55056 #ifdef. (caller5): Protect l1, l2 and l3 by GCC_PR_55056 #ifdef. * gdb.base/restore.exp: New variable opts. Test caller3, caller4 and caller5 for l1, l2 and l3. New prepare_for_testing. * gdb.base/store.c (wack_longest, wack_float, wack_double) (wack_doublest): Protect l and r by GCC_PR_55056 #ifdef. * gdb.base/store.exp: New variable opts. Test longest, float, double and doublest functions for l and r. New prepare_for_testing. * gdb.trace/collection.c (reglocal_test_func): Protect locf and locd by GCC_PR_55056 #ifdef. Protect locar by GDB_PR_15081 #ifdef. * gdb.trace/unavailable.c: Likewise. * gdb.trace/collection.exp: New variable opts. Test reglocal_test_func for locf, locd and locar. New prepare_for_testing. (gdb_collect_locals_test): Increase list size to 43. * gdb.trace/unavailable.exp: Likewise. As far as I can tell, no consensus has yet been reached about the approach to fix this issue discussed in this thread. (I have not looked at the proposed patch in detail.) I have found now I posted the testsuite workaround for GDB http://sourceware.org/ml/gdb-patches/2013-01/msg00688.html but it has never been checked-in (neither in Fedora) which explains why you see PASS-FAIL (which I also see on Fedora 19). Jan
Re: Hurd port for GCC Go
Hi! On Thu, 13 Jun 2013 10:39:58 +0200, I wrote: On Wed, 12 Jun 2013 15:36:39 +0200, Svante Signell svante.sign...@gmail.com wrote: On Tue, 2013-06-11 at 10:31 +0200, Thomas Schwinge wrote: On Fri, 07 Jun 2013 11:14:31 +0200, Svante Signell svante.sign...@gmail.com wrote: Attached are patches to enable gccgo to build properly on Debian GNU/Hurd on gcc-4.7 (4.7.3-4). Thanks! I've begun integrating them into my GCC tree (based on upstream GCC trunk, so some changes to be done to your patches), and get it in a state for Fotis to base his GSoC work on. Where to find your GCC tree? Only locally at the moment; will find a place to publish it. As the .git directory weighs in the order of 1 GiB, I don't just want to push that onto darnassus (for example); even if we told people to first clone the upstream Git repository and only then add darnassus as an additional remote, I bet some would forget doing that. Hmm, it seems that I might be able to host Git branches upstream, so I'll explore that: http://gcc.gnu.org/wiki/GitMirror#Git-only_branches. I have now pushed my working branch to tschwinge/t/hurd/go, and will update this from time to time, both for integrating further changes (my own as well as those that you send me), and merge in GCC trunk changes. On that branch, use something like »git diff :/refs/top-bases/baseline« to diff your working tree against the branch's base. When reviewing the commit history on that branch, it may be helpful to exclude any bulk merges from trunk, so use something like »git log HEAD ^origin/trunk«. Fotis and Svante, please base any futher work for the Hurd port for GCC Go on that branch. Send patches by email, for now. I got as far as having GCC Go compiling with GCC trunk sources; more to come later. Also I had problems to tracing this commit: http://git.savannah.gnu.org/cgit/hurd/glibc.git/commit/?h=t/context_functionsid=018259d791f1ced4b2ced88c393cc74de15006ed. I did not find anything related to context_functions at http://git.savannah.gnu.org/cgit/hurd/glibc.git/ Follow »[...]« in the Branches section to see all branches. Anyway, it's a TopGit branch, http://www.gnu.org/software/hurd/source_repositories/glibc.html, so for getting a patch out of that, you'll need to diff the top of that branch against its base branch, using »tg patch t/context_functions« if you have TopGit installed, or something like »git diff top-bases/t/context_functions t/context_functions« manually. Furthermore, for testing purposes, is it straight-forward to add the new functions getcontext/setcontext/makecontext*/movecontext to the debian sources, e.g. 2.13-39+hurd.3 or 2.17-6 (when that is released?). It is, and Samuel is already building 2.17-3+hurd.4 packages, so you might just wait for these to appear on debian-ports. These packages are available now. Thanks Samuel! Grüße, Thomas pgp93l2K5nxkI.pgp Description: PGP signature
GNU Tools Cauldron 2013 - Schedule
An update on this year's Cauldron. The schedule is now available at http://gcc.gnu.org/wiki/cauldron2013 We will start on Fri 12/Jul at 19:00. Presentations will run Sat all day and Sun until about 17:00. We have a very packed schedule, so it is unlikely that we will be able to add more presentations. However, we will have additional rooms for impromptu meetings, if needed. Diego.
Re: Hurd port for GCC Go
On Fri, 2013-06-14 at 16:42 +0200, Thomas Schwinge wrote: Hi! On Thu, 13 Jun 2013 10:39:58 +0200, I wrote: On Wed, 12 Jun 2013 15:36:39 +0200, Svante Signell svante.sign...@gmail.com wrote: On Tue, 2013-06-11 at 10:31 +0200, Thomas Schwinge wrote: On Fri, 07 Jun 2013 11:14:31 +0200, Svante Signell svante.sign...@gmail.com wrote: Attached are patches to enable gccgo to build properly on Debian GNU/Hurd on gcc-4.7 (4.7.3-4). Thanks! I've begun integrating them into my GCC tree (based on upstream GCC trunk, so some changes to be done to your patches), and get it in a state for Fotis to base his GSoC work on. ... I have now pushed my working branch to tschwinge/t/hurd/go, and will update this from time to time, both for integrating further changes (my own as well as those that you send me), and merge in GCC trunk changes. On that branch, use something like »git diff :/refs/top-bases/baseline« to diff your working tree against the branch's base. When reviewing the commit history on that branch, it may be helpful to exclude any bulk merges from trunk, so use something like »git log HEAD ^origin/trunk«. Fotis and Svante, please base any futher work for the Hurd port for GCC Go on that branch. Send patches by email, for now. I got as far as having GCC Go compiling with GCC trunk sources; more to come later. Sorry, I'm not fluent in git. Which command to use to check out your branch tschwinge/t/hurd/go? Cannot find it at http://git.savannah.gnu.org/cgit/hurd/glibc.git/
Instruction scheduling question
I have an instruction scheduling question I was hoping someone could help me
with. Specifically, I am trying to figure out where and how GCC is deciding
to move the add of a constant to a register above the use of that register and
then changing the register usage by change the offsets associated with it.
For example, I am compiling the following memcpy code for MIPS:
void *memcpy_word_ptr(int * __restrict d, int * __restrict s, unsigned int n )
{
int i;
for(i=0; in; i++) *d++ = *s++;
return d;
}
Using -fno-tree-loop-distribute-patterns -funroll-loops -O3,
the main loop I get is:
.L4:
lw $13,0($7)
addiu $7,$7,32
addiu $3,$3,32
addiu $8,$8,8
lw $12,-28($7)
lw $14,-24($7)
lw $15,-20($7)
lw $24,-16($7)
lw $5,-12($7)
lw $25,-8($7)
lw $9,-4($7)
sw $13,-32($3)
sw $12,-28($3)
sw $14,-24($3)
sw $15,-20($3)
sw $24,-16($3)
sw $5,-12($3)
sw $25,-8($3)
bne $8,$6,.L4
sw $9,-4($3)
Now, if I turn off instruction scheduling (-fno-schedule-insns
-fno-schedule-insns2), I get:
.L4:
lw $11,0($7)
sw $11,0($3)
lw $12,4($7)
sw $12,4($3)
lw $13,8($7)
sw $13,8($3)
lw $14,12($7)
sw $14,12($3)
lw $5,16($7)
sw $5,16($3)
lw $15,20($7)
sw $15,20($3)
lw $24,24($7)
sw $24,24($3)
addiu $3,$3,32
addiu $7,$7,32
lw $25,-4($7)
addiu $8,$8,8
bne $8,$6,.L4
sw $25,-4($3)
The part of the scheduling change that I am interested in is the change in
where the addiu instruction occurs and the related changes from the positive
offsets to the negative offsets. Can anyone tell me where the code that
decides to do that is? Extra bonus points for any answer not including the
word 'reload'.
Steve Ellcey
sell...@mips.com
Re: Instruction scheduling question
The part of the scheduling change that I am interested in is the change in where the addiu instruction occurs and the related changes from the positive offsets to the negative offsets. Can anyone tell me where the code that decides to do that is? Extra bonus points for any answer not including the word 'reload'. Very likely in sched-deps.c:find_modifiable_mems and related functions. -- Eric Botcazou
Re: Instruction scheduling question
On Sat, 2013-06-15 at 00:06 +0200, Eric Botcazou wrote: The part of the scheduling change that I am interested in is the change in where the addiu instruction occurs and the related changes from the positive offsets to the negative offsets. Can anyone tell me where the code that decides to do that is? Extra bonus points for any answer not including the word 'reload'. Very likely in sched-deps.c:find_modifiable_mems and related functions. That looks like the right place. It seems to be triggered by the DONT_BREAK_DEPENDENCIES flag in the haifa scheduler. As an experiment, I added DONT_BREAK_DEPENDENCIES to the scheduling flags and it no longer did that transformation. Thanks. Steve Ellcey sell...@mips.com
Libitm issues porting to POWER8 HTM
I'm currently implementing support for hardware transactional memory in the rs6000 backend for POWER8. Things seem to be mostly working, but I have run into a few issues I'm wondering whether other people are seeing. For me, all of the libitm execution test cases in libitm/testsuite/libitm.c/ compile and execute without error, except for reentrant.c, which hangs for me. My gdb hasn't been ported to support HTM on Power yet, so debugging has been slow, but what I've learned is, that my tbegin. instruction succeeds, but I fail the test (meaning someone has the write lock) at beginend.cc:200: if (unlikely(serial_lock.is_write_locked())) htm_abort(); ...so we abort the transaction. The failure is not persistent, so we do not break out of the loop due to: if (!htm_abort_should_retry(ret)) break; We then fall into the following code, where we hang trying to get the read lock: serial_lock.read_lock(tx); I have yet to track down who has the write lock and why, but I am working towards that. Talking with Andreas, he said he is seeing the same failure on S390, so I'm wondering whether this might be a generic libitm issue and it might hit Intel too. Does anyone know whether this executes correctly on Intel hardware with RTM? I'll note that if I hack the call to htm_abort_should_retry(ret) so that we break of of the loop and fallback to SW TM, then the test case executes correctly. Secondly, many of the test cases in libitm/testsuite/libitm.c++/ fail to build for me when I use -static with the following error: /home/bergner/gcc/install/gcc-fsf-mainline-htm/lib64/libitm.a(method-serial.o):(.opd+0x1098): multiple definition of `__cxa_pure_virtual' /home/bergner/gcc/install/gcc-fsf-mainline-htm/lib64/libstdc++.a(pure.o):(.opd+0x0): first defined here collect2: error: ld returned 1 exit status The comment in method-serial.cc says it's trying to avoid a dependency on libstdc++. Is the __cxa_pure_virtual workaround in method-serial.cc supposed to work with -static? Finially, when compiling (static or non-static) static-ctor.C, I'm seeing: /home/bergner/gcc/gcc-fsf-mainline-htm/libitm/testsuite/libitm.c++/static_ctor.C:12:18: error: unsafe function call 'void __cxa_guard_release(long long int*)' within 'transaction_safe' function static int y = x; ^ /home/bergner/gcc/gcc-fsf-mainline-htm/libitm/testsuite/libitm.c++/static_ctor.C:12:18: error: unsafe function call 'int __cxa_guard_acquire(long long int*)' within 'transaction_safe' function Does x86 not get calls to __cxa_guard_acquire and __cxa_guard_release for this access, so it doesn't see this error? To be honest, I'm not sure what we're supposed to do with this error. Peter
[Bug middle-end/57586] ICE when expanding volatile asm using unaligned pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57586 Alan Modra amodra at gmail dot com changed: What|Removed |Added Status|WAITING |ASSIGNED CC||amodra at gmail dot com Component|target |middle-end Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com Severity|major |normal
[Bug fortran/57596] Wrong code for allocatable deferred-length strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57596 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org --- Author: burnus Date: Fri Jun 14 07:41:42 2013 New Revision: 200084 URL: http://gcc.gnu.org/viewcvs?rev=200084root=gccview=rev Log: 2013-06-14 Tobias Burnus bur...@net-b.de PR fortran/57596 * trans-decl.c (gfc_trans_deferred_vars): Honor OPTIONAL for nullify and deferred-strings' length variable. 2013-06-14 Tobias Burnus bur...@net-b.de PR fortran/57596 * gfortran.dg/deferred_type_param_9.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/deferred_type_param_9.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/57596] Wrong code for allocatable deferred-length strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57596 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org --- FIXED on the trunk (4.9). Thanks for the report!
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 Bug 45170 depends on bug 57596, which changed state. Bug 57596 Summary: Wrong code for allocatable deferred-length strings http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57596 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED
[Bug target/57608] [4.8/4.9 Regression] wrong code for expression at -O3 on x86_64-linux-gnu with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57608 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-14 CC||jakub at gcc dot gnu.org Summary|wrong code for expression |[4.8/4.9 Regression] wrong |at -O3 on x86_64-linux-gnu |code for expression at -O3 |with -m32 |on x86_64-linux-gnu with ||-m32 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r193553.
[Bug target/57608] [4.8/4.9 Regression] wrong code for expression at -O3 on x86_64-linux-gnu with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57608 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.2
[Bug target/57608] [4.8/4.9 Regression] wrong code for expression at -O3 on x86_64-linux-gnu with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57608 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||hubicka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org --- mine :(
[Bug tree-optimization/57608] [4.8/4.9 Regression] wrong code for expression at -O3 on x86_64-linux-gnu with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57608 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Target||i?86-*-* CC||rguenth at gcc dot gnu.org Component|target |tree-optimization --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- I'm sure PRE is only the enabler, not the culprit here, is it?
[Bug c++/57599] result of dynamic_castcv T is just T
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57599 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 4.9.0.
[Bug c++/57593] Friendship not extended into friend member-declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57593 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- If a defect report has been submitted, then we should add its number to the Subject of this bug and suspend it immediately. Do you have the number?
[Bug c++/57599] result of dynamic_castcv T is just T
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57599 --- Comment #7 from Andrey Belevantsev abel at gcc dot gnu.org --- (In reply to Paolo Carlini from comment #6) Fixed for 4.9.0. Do you plan to backport this to 4.7 and 4.8?
[Bug bootstrap/57604] LRA related bootstrap comparison failure on s390x --with-arch=zEC12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57604 --- Comment #1 from Andreas Krebbel krebbel at gcc dot gnu.org --- This is caused by a miscompilation of cp/lex.c: #define DEF_OPERATOR(NAME, CODE, MANGLING, ARITY, ASSN_P)\ sprintf (buffer, ISALPHA (NAME[0]) ? operator %s : operator%s, NAME); \ identifier = get_identifier (buffer);\ ... The problem is that during LRA an add insn is being generated which is placed between the ISALPHA check and the conditional load for the format string. The ADD which is generated clobbers the condition code why DSE later removes the ISALPHA check completely. When generating the ADD LRA probably needs to check whether it will break dataflow. On S/390 we can do such address calculations without clobbering CC by using the load address instruction. Unfortunately la cannot be used for generic add patterns when generating 32 bit code since it only deals with the lower 31 bits. Breakpoint 1, make_insn_raw (pattern=0x3fff6195580) at /home/andreas/clean/gcc-head/gcc/emit-rtl.c:3651 3651 insn = rtx_alloc (INSN); (gdb) p debug_rtx(pattern) (parallel [ (set (reg:DI 3022) (plus:DI (reg/f:DI 34 %fp) (const_int 176 [0xb0]))) (clobber (reg:CC 33 %cc)) ]) $1 = void (gdb) bt #0 make_insn_raw (pattern=0x3fff6195580) at /home/andreas/clean/gcc-head/gcc/emit-rtl.c:3651 #1 0x805b4578 in emit_insn (x=0x3fff6195580) at /home/andreas/clean/gcc-head/gcc/emit-rtl.c:4736 #2 0x807d5e74 in lra_emit_add (x=0x3fff7a079c0, y=0x3fff78754c0, z=0x3fff632a630) at /home/andreas/clean/gcc-head/gcc/lra.c:266 #3 0x807d656e in lra_emit_move (x=0x3fff7a079c0, y=0x3fff6199600) at /home/andreas/clean/gcc-head/gcc/lra.c:415 #4 0x807eb7fa in curr_insn_transform() () #5 0x807ed45c in lra_constraints(bool) () #6 0x807dc616 in lra (f=0x816a46f0) at /home/andreas/clean/gcc-head/gcc/lra.c:2278 #7 0x807845a6 in do_reload () at /home/andreas/clean/gcc-head/gcc/ira.c:4641 #8 0x8078485e in rest_of_handle_reload () at /home/andreas/clean/gcc-head/gcc/ira.c:4753 #9 0x8085a4b2 in execute_one_pass (pass=0x81359060 pass_reload) at /home/andreas/clean/gcc-head/gcc/passes.c:2337 #10 0x8085a76a in execute_pass_list (pass=0x81359060 pass_reload) at /home/andreas/clean/gcc-head/gcc/passes.c:2389 #11 0x8085a7b8 in execute_pass_list (pass=0x813597d0 pass_rest_of_compilation) at /home/andreas/clean/gcc-head/gcc/passes.c:2390 #12 0x804ece5e in expand_function (node=0x3fff62f1130) at /home/andreas/clean/gcc-head/gcc/cgraphunit.c:1582 #13 0x804ed418 in expand_all_functions () at /home/andreas/clean/gcc-head/gcc/cgraphunit.c:1686 #14 0x804ee00c in compile () at /home/andreas/clean/gcc-head/gcc/cgraphunit.c:2020 #15 0x804ee1f0 in finalize_compilation_unit () at /home/andreas/clean/gcc-head/gcc/cgraphunit.c:2097 #16 0x802667fc in cp_write_global_declarations () at /home/andreas/clean/gcc-head/gcc/cp/decl2.c:4356 #17 0x80966c06 in compile_file () at /home/andreas/clean/gcc-head/gcc/toplev.c:558 #18 0x809697e8 in do_compile () at /home/andreas/clean/gcc-head/gcc/toplev.c:1872 #19 0x809699c4 in toplev_main (argc=32, argv=0x3fff138) at /home/andreas/clean/gcc-head/gcc/toplev.c:1948 #20 0x004f6a8ec30c in __libc_start_main () from /lib64/libc.so.6 #21 0x801335aa in _start () (gdb)
[Bug tree-optimization/57358] segmentation fault with attribute(optimize(O0))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57358 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-06/msg00666.htm ||l --- Comment #4 from Martin Jambor jamborm at gcc dot gnu.org --- I have submitted a fix for the 4.8 branch here: http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00663.html and for the current trunk here: http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00666.html
[Bug tree-optimization/57539] [4.9 Regression] ice in ipa_edge_duplication_hook
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57539 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-06/msg00661.htm ||l --- Comment #4 from Martin Jambor jamborm at gcc dot gnu.org --- I have submitted the fix to the mailing list: http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00661.html
[Bug c++/57599] result of dynamic_castcv T is just T
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57599 --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com --- No, because isn't a regression. If you care a lot about that, just ask on the mailing list.
[Bug c++/48453] [C++0x] Invalid reference initialization via explicit conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48453 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- It would be nice to have a DR # for this. In any case, if in practice the compiler is already Ok, we can probably close it, right?
[Bug c++/48632] Internal compiler error when using OpenMP with template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48632 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com --- I suppose we can close this.
[Bug fortran/57508] [4.8/4.9 Regression] [OOP] Intrinsic assignment+defined-assignment for comps: PROCEDURE attribute of '_F.DA0' conflicts with VARIABLE attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57508 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org --- Author: burnus Date: Fri Jun 14 11:24:27 2013 New Revision: 200089 URL: http://gcc.gnu.org/viewcvs?rev=200089root=gccview=rev Log: 2013-06-14 Tobias Burnus bur...@net-b.de PR fortran/57508 * resolve.c (get_temp_from_expr): Don't copy function result attributes to temporary. 2013-06-14 Tobias Burnus bur...@net-b.de PR fortran/57508 * gfortran.dg/defined_assignment_7.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/defined_assignment_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/57508] [4.8/4.9 Regression] [OOP] Intrinsic assignment+defined-assignment for comps: PROCEDURE attribute of '_F.DA0' conflicts with VARIABLE attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57508 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org --- FIXED - now also on the trunk; GCC 4.8 was fixed in comment 4. At the end, the same patch was applied to the trunk as on the branch, cf. http://gcc.gnu.org/ml/fortran/2013-06/msg00086.html
[Bug fortran/49074] [OOP] Defined assignment w/ CLASS arrays: Incomplete error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49074 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Version|4.7.0 |4.9.0 Resolution|--- |FIXED --- Comment #13 from Mikael Morin mikael at gcc dot gnu.org --- FIXED again.
[Bug bootstrap/57609] New: S/390 ESA mode bootstrap failure since r197266
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57609 Bug ID: 57609 Summary: S/390 ESA mode bootstrap failure since r197266 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: krebbel at gcc dot gnu.org cc1 -fpreprocessed libgcc2.i -quiet -dumpbase libgcc2.c -mlong-double-128 -mesa -m31 -march=g5 -auxbase-strip _negdi2.o -g -g -g -O2 -O2 -O2 -Wextra -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version -fbuilding-libgcc -fno-stack-protector -fPIC -fvisibility=hidden -o libgcc2.s Program received signal SIGSEGV, Segmentation fault. 0x70685820 in ?? () (gdb) bt #0 0x70685820 in ?? () #1 0x006cc074 in fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) () #2 0x00714c20 in fold(tree_node*) () #3 0x00537e0c in c_fully_fold_internal(tree_node*, bool, bool*, bool*) () #4 0x00538998 in c_fully_fold(tree_node*, bool, bool*) () #5 0x004e81ba in build_function_call_vec(unsigned int, tree_node*, vectree_node*, va_gc, vl_embed*, vectree_node*, va_gc, vl_embed*) () #6 0x004fd24e in c_parser_postfix_expression_after_primary(c_parser*, unsigned int, c_expr) () #7 0x004f57e8 in c_parser_postfix_expression(c_parser*) () #8 0x004f6b4c in c_parser_unary_expression(c_parser*) () #9 0x004fb0ac in c_parser_cast_expression(c_parser*, c_expr*) () #10 0x004fb2a6 in c_parser_binary_expression(c_parser*, c_expr*, c_parser_prec) () #11 0x004fba44 in c_parser_conditional_expression(c_parser*, c_expr*) () #12 0x004fc00c in c_parser_expr_no_commas(c_parser*, c_expr*) () #13 0x004fc49c in c_parser_expression(c_parser*) () #14 0x004f588a in c_parser_postfix_expression(c_parser*) () #15 0x004f6b4c in c_parser_unary_expression(c_parser*) () #16 0x004fb0ac in c_parser_cast_expression(c_parser*, c_expr*) () #17 0x004fb2a6 in c_parser_binary_expression(c_parser*, c_expr*, c_parser_prec) () #18 0x004fba44 in c_parser_conditional_expression(c_parser*, c_expr*) () #19 0x004fc00c in c_parser_expr_no_commas(c_parser*, c_expr*) () #20 0x004fc49c in c_parser_expression(c_parser*) () #21 0x004fc924 in c_parser_expression_conv(c_parser*) () #22 0x00505784 in c_parser_statement_after_labels(c_parser*) () #23 0x00502528 in c_parser_compound_statement_nostart(c_parser*) () #24 0x00502ce0 in c_parser_compound_statement(c_parser*) () #25 0x00503936 in c_parser_declaration_or_fndef(c_parser*, bool, bool, bool, bool, bool, tree_node**) () #26 0x005083fc in c_parser_external_declaration(c_parser*) () #27 0x00508d02 in c_parse_file() () #28 0x0054e950 in c_common_parse_file() () #29 0x008e2650 in compile_file() () #30 0x008e485a in toplev_main(int, char**) () #31 0x7dd008e6 in __libc_start_main (main=0x4aca88 main, argc=33, ubp_av=0x7fffef44, init=optimized out, fini=0xd11ecc __libc_csu_fini, rtld_fini=0x7dfef84c _dl_fini, stack_end=0x7fffeed8) at libc-start.c:226 #32 0x004acbd6 in _start ()
[Bug c++/48453] [C++0x] [DR 1287] Invalid reference initialization via explicit conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48453 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Summary|[C++0x] Invalid reference |[C++0x] [DR 1287] Invalid |initialization via explicit |reference initialization |conversion |via explicit conversion --- Comment #5 from Jason Merrill jason at gcc dot gnu.org --- Added DR 1287 reference. I'm inclined to leave the bug suspended until that issue is resolved.
[Bug c++/57593] Friendship not extended into friend member-declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57593
--- Comment #2 from David Krauss potswa at mac dot com ---
The maintainer (Mike Miller at EDG) said simply that he will add it to the
list, but as far as I know a number isn't assigned until the new list is
drafted. The title is access granted by friendship to class-scope friend
declaration. (But I suppose he could take a liberty and remove the redundant
class-scope.)
Regardless of any possible defect, GCC is inconsistent. The change in access
applies to certain declarations, not others, but GCC is applying it to parts of
certain declarations (seemingly only the function body is excluded). To be
consistent with the current standard, the only choices are to allow all 3
examples or disallow all 3. The latter choice would be a nasty breaking change.
If it helps, here is the text of DR submission.
Friendship is not transitive, but it does grant access to member declarations
of the befriended class. ([class.friend]/2) And a friend is declared by a
member-declaration. Is a grammatical member-declaration with the friend
specifier still a member declaration?
class c {
class n {};
friend struct s;
};
struct s {
friend class c::n; // 1
friend c::n g(); // 2
friend void f() { c::n(); } // 3
};
If a friend member-declaration is not a member declaration, then it is
impossible to grant access to a private nested class (1) or a function composed
from a type specified using a private nested class (2). Both GCC and Clang
allow these examples.
If a friend member-declaration is a member declaration, then it implements one
degree of transitive friendship, if it is also a definition (3). Clang accepts
this example, but GCC rejects it.
Friends are enough like members that the access should apply. One common
application is operator . A manipulator proxy class may need access from its
insertion operator to its client's restricted members. Another application is
to define a function that would otherwise be a nonstatic member but receives a
container or smart pointer, not a direct reference to the object. These are the
most common cases for the inline friend definition syntax. They are found by
ADL so the namespace-scope declaration may be omitted.
Working around by befriending the pseudo-member friend may be troublesome as it
may violate separation of concerns, form undesired associated classes for ADL,
or require forming a declaration which may use inconvenient nested types or
reduplicated SFINAE.
Although access control isn't really a security mechanism, no exploit would
be opened by granting access because a friend can always delegate to a static
member anyway.
Proposed resolution:
Modify [class.friend]:
… can be accessed in the base-specifiers, member-declarations, and definitions
of members of the befriended class.
Is there any context within a class-specifier where access control is performed
besides its base-specifiers and member-declarations? It doesn't seem to apply
to name lookup in the template-name of a partial or explicit specialization,
but I can't find the spec. Perhaps it should be:
… can be accessed in the class-specifier and definitions of members of the
befriended class.
[Bug c++/57593] Friendship not extended into friend member-declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57593 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Ok. Please, when you have a number, send it here. In any case, I suppose we'd rather prefer to have a resolution in order to act, otherwise we are not sure in which way we want to resolve any inconsistency.
[Bug c++/48453] [C++0x] [DR 1287] Invalid reference initialization via explicit conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48453 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com --- Ok, thanks.
[Bug c++/48453] [C++0x] [DR 1287] Invalid reference initialization via explicit conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48453 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com --- Oh, by the way, the status is ready.
[Bug c++/57610] New: Result of conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57610 Bug ID: 57610 Summary: Result of conversion Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: o_kniemeyer at maxon dot net
[Bug c++/57610] Result of conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57610 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- .
[Bug c++/57610] Result of conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57610 --- Comment #2 from Ole Kniemeyer o_kniemeyer at maxon dot net --- Created attachment 30301 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30301action=edit cpp file (without any #includes) which shows the bug
[Bug c++/57610] Reference initialized with temporary instead of sub-object of conversion result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57610 Ole Kniemeyer o_kniemeyer at maxon dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #3 from Ole Kniemeyer o_kniemeyer at maxon dot net --- In the example X can be converted to B which is a derived class of A. When an A reference is initialized with an X object, the result of the X::operator B() should be used directly for the A reference, but GCC creates a temporary A object and initializes this by copy-construction from the conversion result. At least if the classes use virtual functions, this leads to wrong results.
[Bug c++/57610] Reference initialized with temporary instead of sub-object of conversion result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57610 --- Comment #4 from Ole Kniemeyer o_kniemeyer at maxon dot net --- As I commented in the cpp example, the C++11 standard shows exactly this example in sections 8.5.3. So this is definitely a bug according to C++11. I think the GCC behaviour is correct according to older C++11 standards.
[Bug c++/57610] Reference initialized with temporary instead of sub-object of conversion result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57610 --- Comment #5 from Ole Kniemeyer o_kniemeyer at maxon dot net --- Ops, sorry, of course I meant ... to older C++ standards.
[Bug fortran/56136] [OOP] ICE on lhs-reallocation of an object with overloaded (elemental) assignment operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56136 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||mikael.morin at sfr dot fr --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- This PR seems to have been fixed between revisions 200062 and 200078 (r200069?).
[Bug fortran/57611] New: [Fortran-Dev Regression] Too much memory allocated (gfortran.dg/coarray_lib_alloc_2.f90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57611 Bug ID: 57611 Summary: [Fortran-Dev Regression] Too much memory allocated (gfortran.dg/coarray_lib_alloc_2.f90) Product: gcc Version: fortran-dev Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Blocks: 56818 The following should be: yy._data.base_addr = (void * restrict) __builtin_malloc (1); however, it is yy._data.base_addr = (void * restrict) __builtin_malloc (128); type t end type t class(t), allocatable :: yy(:) allocate(yy(2)) end Similarly for coarrays, cf. gfortran.dg/coarray_lib_alloc_2.f90: class(t), allocatable :: xx[:], yy(:)[:] allocate(yy(2)[*], stat=stat, errmsg=errmsg) which gives xx._data.base_addr = _gfortran_caf_register (72, 1, xx._data.token, stat.0, errmsg, 200); yy._data.base_addr = _gfortran_caf_register (192, 1, yy._data.token, stat.2, errmsg, 200); The first arguments should be 1 instead of 72/192. As the email at http://gcc.gnu.org/ml/fortran/2013-06/msg00071.html indicates, there seems to be some pointer involved as the size varies between 32 and 64 bit systems.
[Bug c/57612] New: add builtin to assert that expression does not have side effects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57612 Bug ID: 57612 Summary: add builtin to assert that expression does not have side effects Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tromey at gcc dot gnu.org It would sometimes be useful to be able to assert that an expression does not have side effects. For example, this would be very nice to have for macros which expand their arguments more than once: #define multi_expand(x) __builtin_assert_no_side_effects(x) + (x) Specifically, this builtin would check its argument and give an error if the argument had an assignment or a call to a function which is neither const nor pure. The builtin would evaluate to the value of its argument.
[Bug lto/57613] New: [LTO] error multiple definition symbol for local symbol
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57613
Bug ID: 57613
Summary: [LTO] error multiple definition symbol for local
symbol
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: dimhen at gmail dot com
$ cat foo.i
void foo()
{
}
$ gcc -fpreprocessed -flto -c foo.i
$ ld -m elf_x86_64 -r -o hidden.o --whole-archive foo.o --no-whole-archive
$ objcopy -G bar hidden.o
$ cp hidden.o hidden2.o
$ gcc -flto hidden.o hidden2.o
hidden2.o (symbol from plugin): In function `foo':
(.text+0x0): multiple definition of `foo'
hidden.o (symbol from plugin):(.text+0x0): first defined here
/lib/../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status
$ nm hidden.o
t foo
0001 C __gnu_lto_v1
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc_current/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/dimhen/src/gcc_current/configure
--prefix=/usr/local/gcc_current --with-multilib-list=m64
--enable-checking=yes,df,fold,rtl,tree --enable-languages=c,c++,lto
--enable-plugin --with-tune=native --with-arch=native
--enable-version-specific-runtime-libs
Thread model: posix
gcc version 4.9.0 20130614 (experimental) [trunk revision 200088] (GCC)
gcc-4.8.1 from Fedora 19 FAIL too
$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-isl=/builddir/build/BUILD/gcc-4.8.1-20130603/obj-x86_64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.8.1-20130603/obj-x86_64-redhat-linux/cloog-install
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.1 20130603 (Red Hat 4.8.1-1) (GCC)
[Bug c++/57614] New: Friend declaration and qualified class member access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57614
Bug ID: 57614
Summary: Friend declaration and qualified class member access
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roger.ferrer at bsc dot es
In the snippet below, a weird interaction happens between two overloaded friend
declarations and a class member access using a qualified id-expression.
// -- test.cc
class A
{
protected:
int s;
public:
A();
};
class B : public A
{
protected:
public:
B();
// By reversing the order of these two declarations
// you can change the location of the error
friend void foo(B , int);
friend void foo(B , B b);
};
void foo(B a, int)
{
// This is only fine if this function was the first friend declared
a.A::s = 3;
// Always fine
a.s = 3;
}
void foo(B a, B b)
{
// This is only fine if this function was the first friend declared
a.A::s = 3;
// Always fine
a.s = 3;
}
// -- end of test.cc
g++ is 4.7.3
$ g++ -c test.cc
test.cc: In function ‘void foo(B, B)’:
test.cc:4:7: error: ‘int A::s’ is protected
test.cc:32:7: error: within this context
If we reverse the order of the friend declarations we can change the error
location.
$ g++ -c test.cc
test.cc: In function ‘void foo(B, int)’:
test.cc:4:7: error: ‘int A::s’ is protected
test.cc:24:7: error: within this context
The error seems to happen with the second overloaded friend declaration.
This problem can be worked around if the id-expression of the class member
access is unqualified.
[Bug c++/57610] Reference initialized with temporary instead of sub-object of conversion result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57610 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #6 from Daniel Krügler daniel.kruegler at googlemail dot com --- 1) Your example code is a bit misleading, because irrespective of your concerns the compiler is allowed to create one copy of B (and thus of A) when returning the B value as result of the function call. You cannot rely on that the compiler will not create at one copy and that is not related to this issue. 2) The core language was considering to change exactly this wording you mention, see http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1287 The part related to the example was deferred and my understanding is that http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1650 is now focusing on class prvalues during reference-binding sub-part. My suggestion is to suspend this bug until this core issue CWG 1650 has been resolved.
[Bug c++/57610] Reference initialized with temporary instead of sub-object of conversion result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57610 --- Comment #7 from Ole Kniemeyer o_kniemeyer at maxon dot net --- OK, thanks for your comments. I wasn't aware of the ongoing discussion about this issue (I was referring to the the draft version N3376 of the C++11 standard). A B-copy would be OK, but as I said copying B into A is not a good idea if those classes have virtual functions. The N3376 wording would be much better for such cases. In my case A is an interface (with dummy implementations of the virtual functions), B an implementation of A and X an unrelated class with conversion operator to B. Now if a function has a const A parameter (so it works with the interface), N3376 allows me to pass an X object to this function by implicitly creating a temporary B object which makes X look like an A. With the variant discussed in the links you posted this wouldn't work (copying B into A makes no sense).
[Bug target/57615] New: power8 support does not deal with -mquad-memory -mno-vsx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57615
Bug ID: 57615
Summary: power8 support does not deal with -mquad-memory
-mno-vsx
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: meissner at gcc dot gnu.org
Created attachment 30302
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30302action=edit
Function to show the problem.
If you compile the Advance Toolchain dl-lookup.c with the following options:
-m64 dl-lookup.c -c -std=gnu99 -fgnu89-inline -O3 -Wall -Winline
-Wwrite-strings -fmerge-all-constants -frounding-math -g -mcpu=power8
-mlong-double-128 -finline-limit=2000 -Wstrict-prototypes -mlong-double-128
-fpic -fexceptions -fasynchronous-unwind-tables -ffixed-32 -ffixed-33
-ffixed-34 -ffixed-35 -ffixed-36 -ffixed-37 -ffixed-38 -ffixed-39 -ffixed-40
-ffixed-41 -ffixed-42 -ffixed-43 -ffixed-44 -ffixed-45 -ffixed-46 -ffixed-47
-ffixed-48 -ffixed-49 -ffixed-50 -ffixed-51 -ffixed-52 -ffixed-53 -ffixed-54
-ffixed-55 -ffixed-56 -ffixed-57 -ffixed-58 -ffixed-59 -ffixed-60 -ffixed-61
-ffixed-62 -ffixed-63 -ffixed-v0 -ffixed-v1 -ffixed-v10 -ffixed-v11 -ffixed-v12
-ffixed-v13 -ffixed-v14 -ffixed-v15 -ffixed-v16 -ffixed-v17 -ffixed-v18
-ffixed-v19 -ffixed-v2 -ffixed-v20 -ffixed-v21 -ffixed-v22 -ffixed-v23
-ffixed-v24 -ffixed-v25 -ffixed-v26 -ffixed-v27 -ffixed-v28 -ffixed-v29
-ffixed-v3 -ffixed-v30 -ffixed-v31 -ffixed-v4 -ffixed-v5 -ffixed-v6 -ffixed-v7
-ffixed-v8 -ffixed-v9 -ffixed-vrsave -ffixed-vscr -mno-altivec -mno-vsx
It fails with the message:
dl-lookup.c: In function ‘_dl_lookup_symbol_x’:
dl-lookup.c:854:1: error: could not split insn
(insn:TI 1693 4115 1696 (set (reg:TI 10 10 [orig:838 val2 ] [838])
(mem/c:TI (reg/f:DI 18 18 [889]) [19 val2+0 S16 A128])) dl-lookup.c:976
454 {*movti_ppc64}
(expr_list:REG_DEAD (reg/f:DI 18 18 [889])
(expr_list:REG_EQUIV (mem/c:TI (reg/f:DI 22 22 [874]) [19 val+0 S16
A128])
(nil
dl-lookup.c:854:1: internal compiler error: in final_scan_insn, at final.c:2887
This is due to the fact that I did not think about somebody having quad memory
enabled but not VSX instructions. The non-VSX movti 64-bit insn always does a
# to split the insn, but the split function will not split it since it could
be handled by a lq instruction.
The fix is to use the function rs6000_output_move_128bit to properly generate
lq/stq if it is safe to do so.
[Bug target/57615] power8 support does not deal with -mquad-memory -mno-vsx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57615 Michael Meissner meissner at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-06-14 CC||bergner at gcc dot gnu.org, ||dje.gcc at gmail dot com Assignee|unassigned at gcc dot gnu.org |meissner at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/57615] power8 support does not deal with -mquad-memory -mno-vsx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57615 --- Comment #1 from Michael Meissner meissner at gcc dot gnu.org --- Created attachment 30303 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30303action=edit Proposed patch to fix problem
[Bug fortran/52347] -Wno-tabs -Wall -Wno-tabs still warns about tabs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52347 Simon Richter Simon.Richter at hogyros dot de changed: What|Removed |Added CC||Simon.Richter at hogyros dot de --- Comment #2 from Simon Richter Simon.Richter at hogyros dot de --- In 4.8, this causes build failures for me: $ g++ -g -Wall -W -Werror -Wno-unused -I. -o stage1/tree_bison_lex.o -c tree_bison_lex.cpp tree_bison_lex.cpp:1744:13: error: unused parameter 'yyscanner' [-Werror=unused-parameter] As can be guessed from the name, this is a file that is generated from flex, which is why I've added -Wno-unused for this file specifically. 4.7 did not warn.
[Bug fortran/46459] ICE (segfault): Invalid read in compare_actual_formal [error recovery]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46459 --- Comment #5 from Mikael Morin mikael at gcc dot gnu.org --- The initial test doesn't lead to a segfault any more. It is now rejected with: comment_0.f90:7.8: call sub(1) 1 Error: Explicit interface required for 'sub' at (1): volatile argument However, the following variant is also rejected with the same error: call sub(1) contains subroutine sub(j) integer, volatile :: j end subroutine sub end
[Bug libstdc++/53477] pretty printer fails with: Python Exception type 'exceptions.IndexError' list index out of range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53477
Tomasz Gajewski tomga at wp dot pl changed:
What|Removed |Added
CC||tomga at wp dot pl
--- Comment #8 from Tomasz Gajewski tomga at wp dot pl ---
The testcase can be reduced to:
#include map
typedef std::mapint, int IntToIntMap;
int main()
{
IntToIntMap amap;
IntToIntMap mapref = amap;
amap[1] = 1;
return 0;
}
and the problem is with map references. Executing on line with 'amap[1] = 1;'
commands to print 'amap' and 'mapref' I get:
(gdb) set python print-stack full
(gdb) p mapref
Traceback (most recent call last):
File /home/tomga/devel/gdb-scripts/python/libstdcxx/v6/printers.py, line
438, in children
rep_type = find_type(self.val.type, '_Rep_type')
File /home/tomga/devel/gdb-scripts/python/libstdcxx/v6/printers.py, line
52, in find_type
field = typ.fields()[0]
IndexError: list index out of range
$3 = std::map with 0 elements
(gdb) p amap
$4 = std::map with 0 elements
I get this with:
$ g++ --version
g++ (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3
...
$ gdb --version
GNU gdb (GDB) 7.5.91.20130417-cvs-ubuntu
...
Pretty printers from svn://gcc.gnu.org/svn/gcc/trunk/libstdc++-v3/python
(currently latest revision: 200105.
Currently I don't know how to debug this further.
[Bug fortran/57616] New: Support -fsanitize=undefined in Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57616 Bug ID: 57616 Summary: Support -fsanitize=undefined in Fortran Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org The newly being added patches for -fsanitize=undefined are partially done in the the FE. Thus, we need to add some Fortran support for them. Seemingly, the following should be handled: * Integer divide by zero * Invalid bit shifts Fortran 2008 has for shift: 13.7.50 DSHIFTL (I, J, SHIFT) 13.7.51 DSHIFTR (I, J, SHIFT) ... SHIFT shall be of type integer. It shall be nonnegative and less than or equal to BIT_SIZE (I) if I is of type integer; otherwise, it shall be less than or equal to BIT_SIZE (J). 13.7.84 ISHFT (I, SHIFT) ... SHIFT shall be of type integer. The absolute value of SHIFT shall be less than or equal to BIT_SIZE (I). 13.7.85 ISHFTC (I, SHIFT [, SIZE]) ... SIZE (optional) shall be of type integer. The value of SIZE shall be positive and shall not exceed BIT SIZE (I). 13.7.150 SHIFTA (I, SHIFT) 13.7.151 SHIFTL (I, SHIFT) 13.7.151 SHIFTR (I, SHIFT) ... SHIFT shall be of type integer. It shall be nonnegative and less than or equal to BIT SIZE (I).
[Bug c/57490] ICE on c-c++-common/cilk-plus/AN/an-if.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57490 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target|sparc*-sun-solaris2.* |*-*-solaris2.* Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-14 CC||ro at gcc dot gnu.org Target Milestone|--- |4.9.0 Ever confirmed|0 |1 --- Comment #1 from Rainer Orth ro at gcc dot gnu.org --- As of 2013-06-14 (r200089), I see the following ICE on both Solaris/SPARC and Solaris/x86, can be reproduced with x86_64-unknown-linux-gnu x i386-pc-solaris2.10 cross compiler: % cc1 -fpreprocessed an-if.i -quiet -fcilkplus -o an-if.s /vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/cilk-plus/AN/an-if.c: In function 'main': /vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/cilk-plus/AN/an-if.c:14:9: internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:2042 int i = 0; ^ 0x7884f7 gimplify_var_or_parm_decl /vol/gcc/src/hg/trunk/local/gcc/gimplify.c:2042 0x790c18 gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**, bool (*)(tree_node*), int) /vol/gcc/src/hg/trunk/local/gcc/gimplify.c:7565 0x7a2980 gimplify_modify_expr /vol/gcc/src/hg/trunk/local/gcc/gimplify.c:4851 0x790b6f gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**, bool (*)(tree_node*), int) /vol/gcc/src/hg/trunk/local/gcc/gimplify.c:7160 0x797758 gimplify_stmt(tree_node**, gimple_statement_d**) /vol/gcc/src/hg/trunk/local/gcc/gimplify.c:5692 0x79a5d3 gimplify_and_add /vol/gcc/src/hg/trunk/local/gcc/gimplify.c:327 0x79a5d3 gimplify_decl_expr /vol/gcc/src/hg/trunk/local/gcc/gimplify.c:1468 0x790629 gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**, bool (*)(tree_node*), int) /vol/gcc/src/hg/trunk/local/gcc/gimplify.c:7327 0x797758 gimplify_stmt(tree_node**, gimple_statement_d**) /vol/gcc/src/hg/trunk/local/gcc/gimplify.c:5692 0x790e33 gimplify_statement_list /vol/gcc/src/hg/trunk/local/gcc/gimplify.c:1521 0x790e33 gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**, bool (*)(tree_node*), int) /vol/gcc/src/hg/trunk/local/gcc/gimplify.c:7549 0x797758 gimplify_stmt(tree_node**, gimple_statement_d**) /vol/gcc/src/hg/trunk/local/gcc/gimplify.c:5692 0x79786a gimplify_body(tree_node*, bool) /vol/gcc/src/hg/trunk/local/gcc/gimplify.c:8193 0x797d82 gimplify_function_tree(tree_node*) /vol/gcc/src/hg/trunk/local/gcc/gimplify.c:8325 0x621c77 analyze_function /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:630 0x624399 analyze_functions /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:914 0x624b07 finalize_compilation_unit() /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2088 0x4e7092 c_write_global_declarations() /vol/gcc/src/hg/trunk/local/gcc/c/c-decl.c:10118 Preprocessed testcase attached. Balaji, could you please have a look. At least on Solaris/x86, this is the last remaining cilkplus testsuite failure (Solaris/SPARC bootstrap still running). Rainer
[Bug c/57490] ICE on c-c++-common/cilk-plus/AN/an-if.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57490 --- Comment #2 from Rainer Orth ro at gcc dot gnu.org --- Created attachment 30304 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30304action=edit preprocessed testcase
[Bug target/57615] power8 support does not deal with -mquad-memory -mno-vsx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57615 Michael Meissner meissner at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Michael Meissner meissner at gcc dot gnu.org --- Fixed in subversion id 200107.
[Bug c++/57617] New: OpenMP critical does not seem to synchronise correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57617 Bug ID: 57617 Summary: OpenMP critical does not seem to synchronise correctly Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nmm1 at cam dot ac.uk Created attachment 30305 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30305action=edit Gzipped tar file of sources, command to run the test and output There are some ancient problems that match this (e.g. 45025), but I can't find a new one. I have written a portable, multi-interface memory consistency checker for some common 'atomic' paradigms, and one of my tests finds that gcc -fopenmp isn't behaving. In the attached files, look for 'NOT expected' in output - I will report the store/load one separately. Regrettably, there is no documentation yet and this is not stripped down, but the code is structured so that the relevant function's assembler can be inspected (with -O0 at least). I ran commands to generate output. If you find a bug in my code, I shan't be surprised :-(
[Bug c++/57618] New: OpenMP atomic read and write are not sequentially consistent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57618 Bug ID: 57618 Summary: OpenMP atomic read and write are not sequentially consistent Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nmm1 at cam dot ac.uk See bug 57617 for the data and more description. But the same program finds that OpenMP atomic read and write are not sequentially consistent. That will assuredly cause wrong answers when yer everage programmer attempts to use them. But should they be? If you can decode any specification on this matter from what OpenMP are pleased to call a standard, you are more intelligent than I am. So is this a bug, a gotcha or a feature?
[Bug fortran/52347] -Wno-tabs -Wall -Wno-tabs still warns about tabs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52347 --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Simon Richter from comment #2) In 4.8, this causes build failures for me: $ g++ -g -Wall -W -Werror -Wno-unused -I. -o stage1/tree_bison_lex.o -c tree_bison_lex.cpp tree_bison_lex.cpp:1744:13: error: unused parameter 'yyscanner' [-Werror=unused-parameter] Could you attach a self-contained preprocessed testcase? See http://gcc.gnu.org/bugs/
[Bug libstdc++/57619] New: std::unordered_map and std::unordered_multimap::insert invoking std::pair move constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57619
Bug ID: 57619
Summary: std::unordered_map and std::unordered_multimap::insert
invoking std::pair move constructor
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: gdjss2728 at gmail dot com
The following code is invoking the std::pair move constructor:
int main ()
{
std::unordered_mapstd::string, std::string mymap;
std::unordered_multimapstd::string, std::string mymultimap;
std::pairstd::string, std::string mypair{std::string(key),
std::string(value)};
mymultimap.insert(mypair); // std::pair move constructor invoked here
mymap.insert(mypair); // strings already moved out!
}
This seems related to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53657.
As far as I can tell, overload resolution is choosing `insert(_Pair __x)`
over `insert(const value_type __x)`. Since this is an lvalue, the latter
should be chosen. This happens for std::unordered_map::insert and
std::unordered_multimap::insert.
[Bug libstdc++/57619] std::unordered_map and std::unordered_multimap::insert invoking std::pair move constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57619
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-06-14
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Jesse Good from comment #0)
The following code is invoking the std::pair move constructor:
Complete testcase:
#include unordered_map
#include string
#include cassert
int main ()
{
std::unordered_multimapstd::string, std::string mymultimap;
std::pairstd::string, std::string mypair{std::string(key),
std::string(value)};
mymultimap.insert(mypair); // std::pair move constructor invoked here
assert( mypair.first.length() mypair.second.length() );
}
As far as I can tell, overload resolution is choosing `insert(_Pair __x)`
over `insert(const value_type __x)`. Since this is an lvalue, the latter
should be chosen.
Calling that overload is correct, the problem is that it uses std::move() not
std::forward_Pair
[Bug c++/57620] New: Phantom terminator confuses raw string literal parsing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57620 Bug ID: 57620 Summary: Phantom terminator confuses raw string literal parsing. Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: crowl at google dot com The first example of C++11 section 2.14.5 paragraph 5 confuses the scanner. $ cat test.cc const char *phantom_terminator = Ra( )\ a )a; $ xg++ -std=c++11 -g -O2 -c test.cc test.cc:4:3: warning: missing terminating character [enabled by default] )a; ^ test.cc:4:1: error: missing terminating character )a; ^ test.cc:4:1: error: expected ',' or ';' before ')' token
[Bug c++/57163] Link failure with thread_local
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57163 Marcel Meyer meyerm at fs dot tum.de changed: What|Removed |Added CC||meyerm at fs dot tum.de --- Comment #2 from Marcel Meyer meyerm at fs dot tum.de --- Confirmed for gcc 4.8.1.
[Bug c++/57163] Link failure with thread_local
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57163 --- Comment #3 from Marcel Meyer meyerm at fs dot tum.de --- Please have a look at bug #55800 .
[Bug c++/55800] Link failure with thread_local in unnamed namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55800 Marcel Meyer meyerm at fs dot tum.de changed: What|Removed |Added CC||meyerm at fs dot tum.de --- Comment #1 from Marcel Meyer meyerm at fs dot tum.de --- Confirmed for 4.8.1 (using -std=c++11). Seems to be the same as bug #57163.
[Bug c++/51413] Broken diagnostic with __builtin_offsetof
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51413 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 4.9.0.
[Bug libstdc++/57619] std::unordered_map and std::unordered_multimap::insert invoking std::pair move constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57619 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Target Milestone|--- |4.8.2 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Let's fix this.
[Bug fortran/52347] -Wno-tabs -Wall -Wno-tabs still warns about tabs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52347
--- Comment #4 from Simon Richter Simon.Richter at hogyros dot de ---
Testcase is simple:
$ cat tt.cpp
void bar(int baz) { }
$ g++-4.7 -c -W -Wall -Werror -Wno-unused tt.cpp
$ g++-4.8 -c -W -Wall -Werror -Wno-unused tt.cpp
tt.cpp:1:6: error: unused parameter ‘baz’ [-Werror=unused-parameter]
void bar(int baz) { }
^
cc1plus: all warnings being treated as errors
[Bug rtl-optimization/57451] Incorrect debug ranges emitted for -freorder-blocks-and-partition -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57451
--- Comment #4 from Cary Coutant ccoutant at gcc dot gnu.org ---
The problem is a lexical block in main() that appears to be getting split by
-freorder-blocks-and-partition, but when debug info is emitted during
rest_of_handle_final(), this particular lexical block still appears to be a
single block -- BLOCK_FRAGMENT_CHAIN is NULL, so the DWARF output code decides
that it can emit a DW_AT_low_pc/high_pc pair instead of a DW_AT_ranges. The
DW_AT_high_pc is now being output relative to DW_AT_low_pc, so we see an
assembly expression .LBE14 - .LBB14, which are labels attached to the block
start and block end, and should be in the same section.
Here's the block:
(gdb) p stmt
$1 = (tree) 0x75f4c4b0
(gdb) pt
warning: Expression is not an assignment (and might have no effect)
block 0x75f4c4b0 asm_written used
vars var_decl 0x7608bc78 e
type reference_type 0x7609b930 type record_type 0x7608e9d8
MyException
sizes-gimplified unsigned DI
size integer_cst 0x75f24dc0 constant 64
unit size integer_cst 0x75f24de0 constant 8
align 64 symtab 0 alias set -1 canonical type 0x7609b930
readonly tree_1 tree_3 unsigned decl_5 DI file pr49115.C line 21 col 25
size integer_cst 0x75f24dc0 64 unit size integer_cst 0x75f24de0 8
align 64 context function_decl 0x76096f00 main
supercontext block 0x760c00f0 asm_written used
vars var_decl 0x7608bb48 data type record_type 0x7608ec78
Data
used tree_1 tree_3 decl_5 SI file pr49115.C line 18 col 8
size integer_cst 0x75f42140 constant 32
unit size integer_cst 0x75f42160 constant 4
align 128 context function_decl 0x76096f00 main
(reg/v:SI 64 [ data ])
supercontext block 0x75f4c550 asm_written used supercontext
function_decl 0x76096f00 main
subblocks block 0x75f4c500 asm_written used vars var_decl
0x7608bb48 data supercontext block 0x75f4c550 subblocks block
0x75f4c4b0 chain block 0x760c00f0
(gdb) p stmt-block
$2 = {base = {code = BLOCK, side_effects_flag = 0, constant_flag = 0,
addressable_flag = 0,
volatile_flag = 0, readonly_flag = 0, asm_written_flag = 1, nowarning_flag
= 0, visited = 0,
used_flag = 1, nothrow_flag = 0, static_flag = 0, public_flag = 0,
private_flag = 0,
protected_flag = 0, deprecated_flag = 0, default_def_flag = 0, u = {bits =
{lang_flag_0 = 0,
lang_flag_1 = 0, lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0,
lang_flag_5 = 0,
lang_flag_6 = 0, saturating_flag = 0, unsigned_flag = 0, packed_flag =
0, user_align = 0,
nameless_flag = 1, spare0 = 0, spare1 = 0, address_space = 0}, length =
2048,
version = 2048}}, chain = 0x0, abstract_flag = 0, block_num = 14, locus =
0,
vars = 0x7608bc78, nonlocalized_vars = 0x0, subblocks = 0x0, supercontext
= 0x760c00f0,
abstract_origin = 0x0, fragment_origin = 0x0, fragment_chain = 0x0}
Here's the fragment of assembly code between .LBB14 and .LBE14:
.LBB14:
# pr49115.C:21
.loc 1 21 0
call__cxa_begin_catch
.LVL7:
call__cxa_end_catch
.LVL8:
.p2align 4,,5
# SUCC: 3 [100.0%] count:1
jmp .L15
.cfi_endproc
.section.text.unlikely
.cfi_startproc
.cfi_personality 0x3,__gxx_personality_v0
.cfi_lsda 0x3,.LLSDAC4
# BLOCK 6 freq:5000 seq:4
# PRED: 4 [50.0%] (CROSSING,CAN_FALLTHRU)
.L14:
.cfi_def_cfa_offset 16
.p2align 4,,8
.LEHB1:
# SUCC:
call_Unwind_Resume
.LEHE1:
.LVL9:
.LBE14:
.LBE15:
.cfi_endproc
You can see that the block from .LBB14 to .LBE14 has been split across two
sections. In order for dwarf2out to generate the proper debug info,
BLOCK_FRAGMENT_CHAIN(stmt) needs to be non-NULL. I'm not sure why that's not
happening when the block is split.
[Bug libstdc++/57619] std::unordered_map and std::unordered_multimap::insert invoking std::pair move constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57619 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Known to fail||4.8.1 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed mainline and 4.8.2.
[Bug c++/57620] Phantom terminator confuses raw string literal parsing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57620 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Maybe Jakub can have a look.
[Bug c++/52762] Firefox 11 segfault with gcc 4.7 (-O3 -march=corei7-avx)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52762 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com --- Feedback not forthcoming.
[Bug c++/53099] Internal compiler error on short testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53099 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.8.0, 4.9.0 Resolution|--- |FIXED --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Can't reproduce with the released 4.8.0, current 4_8-branch and mainline. If somebody can, please provide further details and re-open, thanks.
[Bug c/57621] New: -Og
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57621
Bug ID: 57621
Summary: -Og
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: naruse at airemix dot jp
Folloing program is to verify func's argument is not larger than 3 at compile
time.
And this program uses valid argument 0.
Threfore I want the code is compiled without error.
This idea works on -O, -O1, -O2, -O3, -Os.
But on -Og, it fails with attribute error.
Of course it is not what I want, but is this intended behavior?
% cat og.c
#include stdio.h
int ruby$safe_level$4(void) __attribute__((error($SAFE=4 is obsolete)));
#define func(a) (__builtin_constant_p(a) (a) 3) ? ruby$safe_level$4() :
(a)
struct foo {
int n;
};
void show(struct foo *p) {
printf(%d\n, func(p-n));
}
void hoge(void) {
struct foo f;
f.n = 0;
show(f);
}
int main(void) {
hoge();
return 0;
}
% gcc49 -O og.c ./a.out
0
% gcc49 -Og og.c ./a.out
og.c: In function 'show':
og.c:9:11: error: call to 'ruby$safe_level$4' declared with attribute error:
$SAFE=4 is obsolete
printf(%d\n, func(p-n));
^
% gcc49 -v
Using built-in specs.
COLLECT_GCC=gcc49
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc49/gcc/x86_64-portbld-freebsd9.1/4.9.0/lto-wrapper
Target: x86_64-portbld-freebsd9.1
Configured with: ./../gcc-4.9-20130526/configure --disable-nls
--libdir=/usr/local/lib/gcc49 --libexecdir=/usr/local/libexec/gcc49
--program-suffix=49 --with-as=/usr/local/bin/as --with-gmp=/usr/local
--with-gxx-include-dir=/usr/local/lib/gcc49/include/c++/
--with-ld=/usr/local/bin/ld --with-libiconv-prefix=/usr/local
--with-pkgversion='FreeBSD Ports Collection' --with-system-zlib
--disable-libgcj --enable-languages=c,c++,objc,fortran --prefix=/usr/local
--mandir=/usr/local/man --infodir=/usr/local/info/gcc49
--build=x86_64-portbld-freebsd9.1
Thread model: posix
gcc version 4.9.0 20130526 (experimental) (FreeBSD Ports Collection)
% uname -a
FreeBSD windy.airemix.net 9.1-RELEASE-p3 FreeBSD 9.1-RELEASE-p3 #0: Mon Apr 29
18:27:25 UTC 2013
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
Re: [PATCH][RFC] Re-write LTO type merging again, do tree merging
On Fri, 14 Jun 2013, Jan Hubicka wrote: Ok, not streaming and comparing TREE_USED gets it improved to I will try to gather better data tomorrow. My mozilla build died on disk space, but according to stats we are now at about 7GB of GGC memory after merging. I was playing with the following patch that implements testing whether types are same in my (probably naive and wrong) understanding of ODR rule in C++ So i can confirm that we now need 3GB of TMP space instead of 8GB with earlier version of patch. I will compare to mainline tomorrow, but I think it is about the same. phase opt and generate : 96.39 ( 9%) usr 40.45 (45%) sys 136.91 (12%) wall 271042 kB ( 7%) ggc phase stream in : 457.87 (43%) usr 8.38 ( 9%) sys 466.44 (40%) wall 3798844 kB (93%) ggc phase stream out: 509.39 (48%) usr 40.82 (46%) sys 550.88 (48%) wall7149 kB ( 0%) ggc ipa cp : 13.62 ( 1%) usr 5.00 ( 6%) sys 18.61 ( 2%) wall 425204 kB (10%) ggc ipa inlining heuristics : 60.52 ( 6%) usr 36.15 (40%) sys 96.71 ( 8%) wall 1353370 kB (33%) ggc ipa lto decl in : 346.94 (33%) usr 5.49 ( 6%) sys 352.60 (31%) wall7042 kB ( 0%) ggc ipa lto decl out: 481.19 (45%) usr 23.28 (26%) sys 504.68 (44%) wall 0 kB ( 0%) ggc TOTAL :1063.6789.65 1154.26 4078436 kB So we are still bound by streaming. I am running -flto-report overnight. My ODR patch finds 36377 matches and also weird looking mismatches of type: record_type 0x7fbd30d46dc8 sockaddr_storage BLK size integer_cst 0x7fbd416bc1e0 type integer_type 0x7fbd415660a8 bitsizetype constant 1024 unit size integer_cst 0x7fbd416bc700 type integer_type 0x7fbd41566000 sizetype constant 128 align 64 symtab 0 alias set -1 canonical type 0x7fbd30f0bc78 fields field_decl 0x7fbd30e99ed8 ss_family type integer_type 0x7fbd3b98c000 sa_family_t public unsigned HI size integer_cst 0x7fbd41555fe0 constant 16 unit size integer_cst 0x7fbd4156a000 constant 2 align 16 symtab 0 alias set -1 canonical type 0x7fbd41566540 precision 16 min integer_cst 0x7fbd4156a020 0 max integer_cst 0x7fbd41555fc0 65535 unsigned nonlocal HI file /usr/include/bits/socket.h line 189 col 0 size integer_cst 0x7fbd41555fe0 16 unit size integer_cst 0x7fbd4156a000 2 align 16 offset_align 128 offset integer_cst 0x7fbd41555d60 constant 0 bit offset integer_cst 0x7fbd41555de0 constant 0 context record_type 0x7fbd30d46dc8 sockaddr_storage chain field_decl 0x7fbd30e99000 __ss_align type integer_type 0x7fbd415667e0 long unsigned int unsigned nonlocal DI file /usr/include/bits/socket.h line 190 col 0 size integer_cst 0x7fbd41555d20 constant 64 unit size integer_cst 0x7fbd41555d40 constant 8 align 64 offset_align 128 offset integer_cst 0x7fbd41555d60 0 bit offset integer_cst 0x7fbd41555d20 64 context record_type 0x7fbd30d46dc8 sockaddr_storage chain field_decl 0x7fbd30e99e40 __ss_padding context translation_unit_decl 0x7fbd30cbc2e0 D.967968 chain type_decl 0x7fbd30d47da8 sockaddr_storage record_type 0x7fbd30f0bc78 sockaddr_storage BLK size integer_cst 0x7fbd416bc1e0 type integer_type 0x7fbd415660a8 bitsizetype constant 1024 unit size integer_cst 0x7fbd416bc700 type integer_type 0x7fbd41566000 sizetype constant 128 align 64 symtab 0 alias set -1 canonical type 0x7fbd30f0bc78 fields field_decl 0x7fbd30ef9558 ss_family type integer_type 0x7fbd3b98c000 sa_family_t public unsigned HI size integer_cst 0x7fbd41555fe0 constant 16 unit size integer_cst 0x7fbd4156a000 constant 2 align 16 symtab 0 alias set -1 canonical type 0x7fbd41566540 precision 16 min integer_cst 0x7fbd4156a020 0 max integer_cst 0x7fbd41555fc0 65535 unsigned HI file /usr/include/bits/socket.h line 189 col 0 size integer_cst 0x7fbd41555fe0 16 unit size integer_cst 0x7fbd4156a000 2 align 16 offset_align 128 offset integer_cst 0x7fbd41555d60 constant 0 bit offset integer_cst 0x7fbd41555de0 constant 0 context record_type 0x7fbd30f0bc78 sockaddr_storage chain field_decl 0x7fbd30ef94c0 __ss_align type integer_type 0x7fbd415667e0 long unsigned int unsigned DI file /usr/include/bits/socket.h line 190 col 0 size integer_cst 0x7fbd41555d20 constant 64 unit size integer_cst 0x7fbd41555d40 constant 8 align 64 offset_align 128 offset integer_cst 0x7fbd41555d60 0 bit offset integer_cst 0x7fbd41555d20 64 context record_type 0x7fbd30f0bc78 sockaddr_storage chain field_decl 0x7fbd30ef9428 __ss_padding context translation_unit_decl 0x7fbd30ea9f18 D.936417 pointer_to_this pointer_type 0x7fbd30f0bd20 chain type_decl 0x7fbd30ea9398 D.938243 that
Re: expand_expr tweaks to fix PR57134
On Thu, Jun 13, 2013 at 10:45:38AM +0200, Richard Biener wrote:
On Wed, Jun 12, 2013 at 4:48 AM, Alan Modra amo...@gmail.com wrote:
The following patch fixes PR57134 by
a) excluding bitfield expansion when EXPAND_MEMORY, and
b) passing down the EXPAND_MEMORY modifier in a couple of places where
this does not currently happen on recursive calls to expand_expr().
I suppose it also fixes PR57586 which looks similar?
Not completely. It cures the ICE, but you still get output number 0
not directly addressable. The reason being that expand_asm_operands
isn't asking for a mem. It should I guess, and also not specify
EXPAND_WRITE on an inout parameter. Bootstrapped and regression
tested powerpc64-linux.
PR middle-end/57586
* stmt.c (expand_asm_operands): Call expand_expr with
EXPAND_MEMORY for output operands that disallow regs. Don't
use EXPAND_WRITE on inout operands.
Index: gcc/stmt.c
===
--- gcc/stmt.c (revision 200083)
+++ gcc/stmt.c (working copy)
@@ -807,7 +807,10 @@ expand_asm_operands (tree string, tree outputs, tr
|| ! allows_reg
|| is_inout)
{
- op = expand_expr (val, NULL_RTX, VOIDmode, EXPAND_WRITE);
+ op = expand_expr (val, NULL_RTX, VOIDmode,
+ !allows_reg ? EXPAND_MEMORY
+ : !is_inout ? EXPAND_WRITE
+ : EXPAND_NORMAL);
if (MEM_P (op))
op = validize_mem (op);
Ok with a testcase and mentioning PR57586 in the changelog.
gcc.dg/compile/pr57134.c added.
--
Alan Modra
Australia Development Lab, IBM
Re: target.h uses insn-codes.h
On Fri, Jun 14, 2013 at 4:31 AM, Mike Stump mikest...@comcast.net wrote: When doing a -j16 build of top of the trunk from a little while ago, with our wide-int patches in it, I hit: g++ -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -Ilto -I../../gcc/gcc -I../../gcc/gcc/lto -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/bid -I../libdecnumber -I../../gcc/gcc/../libbacktrace ../../gcc/gcc/lto/lto-partition.c -o lto/lto-partition.o In file included from ../../gcc/gcc/lto-streamer.h:30:0, from ../../gcc/gcc/lto/lto-object.c:27: ../../gcc/gcc/target.h:52:24: fatal error: insn-codes.h: No such file or directory compilation terminated. make[3]: *** [lto/lto-object.o] Error 1 make[3]: *** Waiting for unfinished jobs In file included from ../../gcc/gcc/lto-streamer.h:30:0, from ../../gcc/gcc/lto/lto-partition.c:27: ../../gcc/gcc/target.h:52:24: fatal error: insn-codes.h: No such file or directory compilation terminated. make[3]: *** [lto/lto-partition.o] Error 1 to my untrained eye, it seems we are missing: diff --git a/gcc/Makefile.in b/gcc/Makefile.in index a098040..a9f4dee 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -841,7 +841,7 @@ EXCEPT_H = except.h $(HASHTAB_H) TARGET_DEF = target.def target-hooks-macros.h C_TARGET_DEF = c-family/c-target.def target-hooks-macros.h COMMON_TARGET_DEF = common/common-target.def target-hooks-macros.h -TARGET_H = $(TM_H) target.h $(TARGET_DEF) insn-modes.h +TARGET_H = $(TM_H) target.h $(TARGET_DEF) insn-modes.h insn-codes.h C_TARGET_H = c-family/c-target.h $(C_TARGET_DEF) COMMON_TARGET_H = common/common-target.h $(INPUT_H) $(COMMON_TARGET_DEF) MACHMODE_H = machmode.h mode-classes.def insn-modes.h I think insn-codes.h falls in to the same or easier class (no stamp file for it) than insn-modes.h, so, I think this is ok; but would be nice to have someone review it. I checked trunk, and I don't see any thing that would ensure insn-codes.h is done before target.h is used. Ok? Ok. Thanks, Richard.
Re: GCC does not support *mmintrin.h with function specific opts
On Fri, Jun 14, 2013 at 4:52 AM, Sriraman Tallam tmsri...@google.com wrote: On Thu, Jun 13, 2013 at 12:40 PM, Jan Hubicka hubi...@ucw.cz wrote: * tree-inline.c (expand_call_inline): Allow the error to be flagged in early inline pass. * ipa-inline.c (inline_always_inline_functions): Pretend always_inline functions are inlined during failures to flag an error. * gcc.target/i386/inline_error.c: New test. This patch is OK if it passes testing. Two tests gcc.c-torture/compile/pr43791.c and pr44043.c are failing because of always_inline functions being present that cannot be inlined and the compiler is now generating error messages. I will fix them and resend the patch. Quick look - pr43791.c is not expected to work at -O0, so skip -O0 for example by guarding the whole thing with #if __OPTIMIZED__ 0. Similar for pr44043.c. That we didn't error at -O0 before is a bug. Eventually I was suggesting to error if we end up outputting the body of an always_inline function, that is, any uses remain (including indirect calls or address-takens which is where we do not error right now). Richard. Thanks Sri Thanks for your patience! Honza
Re: [PATCH][RFC] Re-write LTO type merging again, do tree merging
On Fri, 14 Jun 2013, Jan Hubicka wrote: Ok, not streaming and comparing TREE_USED gets it improved to I will try to gather better data tomorrow. My mozilla build died on disk space, but according to stats we are now at about 7GB of GGC memory after merging. I was playing with the following patch that implements testing whether types are same in my (probably naive and wrong) understanding of ODR rule in C++ So i can confirm that we now need 3GB of TMP space instead of 8GB with earlier version of patch. I will compare to mainline tomorrow, but I think it is about the same. phase opt and generate : 96.39 ( 9%) usr 40.45 (45%) sys 136.91 (12%) wall 271042 kB ( 7%) ggc phase stream in : 457.87 (43%) usr 8.38 ( 9%) sys 466.44 (40%) wall 3798844 kB (93%) ggc phase stream out: 509.39 (48%) usr 40.82 (46%) sys 550.88 (48%) wall7149 kB ( 0%) ggc ipa cp : 13.62 ( 1%) usr 5.00 ( 6%) sys 18.61 ( 2%) wall 425204 kB (10%) ggc ipa inlining heuristics : 60.52 ( 6%) usr 36.15 (40%) sys 96.71 ( 8%) wall 1353370 kB (33%) ggc ipa lto decl in : 346.94 (33%) usr 5.49 ( 6%) sys 352.60 (31%) wall7042 kB ( 0%) ggc ipa lto decl out: 481.19 (45%) usr 23.28 (26%) sys 504.68 (44%) wall 0 kB ( 0%) ggc TOTAL :1063.6789.65 1154.26 4078436 kB So we are still bound by streaming. I am running -flto-report overnight. My ODR patch finds 36377 matches and also weird looking mismatches of type: record_type 0x7fbd30d46dc8 sockaddr_storage BLK size integer_cst 0x7fbd416bc1e0 type integer_type 0x7fbd415660a8 bitsizetype constant 1024 unit size integer_cst 0x7fbd416bc700 type integer_type 0x7fbd41566000 sizetype constant 128 align 64 symtab 0 alias set -1 canonical type 0x7fbd30f0bc78 fields field_decl 0x7fbd30e99ed8 ss_family type integer_type 0x7fbd3b98c000 sa_family_t public unsigned HI size integer_cst 0x7fbd41555fe0 constant 16 unit size integer_cst 0x7fbd4156a000 constant 2 align 16 symtab 0 alias set -1 canonical type 0x7fbd41566540 precision 16 min integer_cst 0x7fbd4156a020 0 max integer_cst 0x7fbd41555fc0 65535 unsigned nonlocal HI file /usr/include/bits/socket.h line 189 col 0 size integer_cst 0x7fbd41555fe0 16 unit size integer_cst 0x7fbd4156a000 2 align 16 offset_align 128 offset integer_cst 0x7fbd41555d60 constant 0 bit offset integer_cst 0x7fbd41555de0 constant 0 context record_type 0x7fbd30d46dc8 sockaddr_storage chain field_decl 0x7fbd30e99000 __ss_align type integer_type 0x7fbd415667e0 long unsigned int unsigned nonlocal DI file /usr/include/bits/socket.h line 190 col 0 size integer_cst 0x7fbd41555d20 constant 64 unit size integer_cst 0x7fbd41555d40 constant 8 align 64 offset_align 128 offset integer_cst 0x7fbd41555d60 0 bit offset integer_cst 0x7fbd41555d20 64 context record_type 0x7fbd30d46dc8 sockaddr_storage chain field_decl 0x7fbd30e99e40 __ss_padding context translation_unit_decl 0x7fbd30cbc2e0 D.967968 chain type_decl 0x7fbd30d47da8 sockaddr_storage record_type 0x7fbd30f0bc78 sockaddr_storage BLK size integer_cst 0x7fbd416bc1e0 type integer_type 0x7fbd415660a8 bitsizetype constant 1024 unit size integer_cst 0x7fbd416bc700 type integer_type 0x7fbd41566000 sizetype constant 128 align 64 symtab 0 alias set -1 canonical type 0x7fbd30f0bc78 fields field_decl 0x7fbd30ef9558 ss_family type integer_type 0x7fbd3b98c000 sa_family_t public unsigned HI size integer_cst 0x7fbd41555fe0 constant 16 unit size integer_cst 0x7fbd4156a000 constant 2 align 16 symtab 0 alias set -1 canonical type 0x7fbd41566540 precision 16 min integer_cst 0x7fbd4156a020 0 max integer_cst 0x7fbd41555fc0 65535 unsigned HI file /usr/include/bits/socket.h line 189 col 0 size integer_cst 0x7fbd41555fe0 16 unit size integer_cst 0x7fbd4156a000 2 align 16 offset_align 128 offset integer_cst 0x7fbd41555d60 constant 0 bit offset integer_cst 0x7fbd41555de0 constant 0 context record_type 0x7fbd30f0bc78 sockaddr_storage chain field_decl 0x7fbd30ef94c0 __ss_align type integer_type 0x7fbd415667e0 long unsigned int unsigned DI file /usr/include/bits/socket.h line 190 col 0 size integer_cst 0x7fbd41555d20 constant 64 unit size integer_cst 0x7fbd41555d40 constant 8 align 64 offset_align 128 offset integer_cst 0x7fbd41555d60 0 bit offset integer_cst 0x7fbd41555d20 64 context record_type 0x7fbd30f0bc78 sockaddr_storage chain field_decl 0x7fbd30ef9428 __ss_padding context translation_unit_decl 0x7fbd30ea9f18
Re: GCC does not support *mmintrin.h with function specific opts
On Fri, Jun 14, 2013 at 4:52 AM, Sriraman Tallam tmsri...@google.com wrote: On Thu, Jun 13, 2013 at 12:40 PM, Jan Hubicka hubi...@ucw.cz wrote: * tree-inline.c (expand_call_inline): Allow the error to be flagged in early inline pass. * ipa-inline.c (inline_always_inline_functions): Pretend always_inline functions are inlined during failures to flag an error. * gcc.target/i386/inline_error.c: New test. This patch is OK if it passes testing. Two tests gcc.c-torture/compile/pr43791.c and pr44043.c are failing because of always_inline functions being present that cannot be inlined and the compiler is now generating error messages. I will fix them and resend the patch. Quick look - pr43791.c is not expected to work at -O0, so skip -O0 for example by guarding the whole thing with #if __OPTIMIZED__ 0. Similar for pr44043.c. That we didn't error at -O0 before is a bug. Eventually I was suggesting to error if we end up outputting the body of an always_inline function, that is, any uses remain (including indirect calls or address-takens which is where we do not error right now). Well, as dicussed earlier, this will make kernel folks crazy, since they define inline to be always inline and likes to take address of that function. (of course that is crazy already) Honza Richard. Thanks Sri Thanks for your patience! Honza
Re: GCC does not support *mmintrin.h with function specific opts
On Fri, Jun 14, 2013 at 10:43:34AM +0200, Richard Biener wrote: On Fri, Jun 14, 2013 at 4:52 AM, Sriraman Tallam tmsri...@google.com wrote: On Thu, Jun 13, 2013 at 12:40 PM, Jan Hubicka hubi...@ucw.cz wrote: * tree-inline.c (expand_call_inline): Allow the error to be flagged in early inline pass. * ipa-inline.c (inline_always_inline_functions): Pretend always_inline functions are inlined during failures to flag an error. * gcc.target/i386/inline_error.c: New test. This patch is OK if it passes testing. Two tests gcc.c-torture/compile/pr43791.c and pr44043.c are failing because of always_inline functions being present that cannot be inlined and the compiler is now generating error messages. I will fix them and resend the patch. Quick look - pr43791.c is not expected to work at -O0, so skip -O0 for example by guarding the whole thing with #if __OPTIMIZED__ 0. Similar for pr44043.c. That we didn't error at -O0 before is a bug. Eventually I was suggesting to error if we end up outputting the body of an always_inline function, that is, any uses remain (including indirect calls or address-takens which is where we do not error right now). Well, for indirect calls/address-takens and gnu_inline style extern inline always_inline, it should be fine if we just emit calls to the library function, otherwise you'd break a lot of code, because glibc uses always_inline heavily for -D_FORTIFY_SOURCE wrapper inlines, open argument checking etc. But that body supposedly doesn't inherit the always_inline attribute. Jakub
Re: [PATCH] DATA_ALIGNMENT vs. DATA_ABI_ALIGNMENT (PR target/56564)
On Fri, Jun 14, 2013 at 08:18:19AM +0930, Alan Modra wrote:
On Thu, Jun 13, 2013 at 05:42:17PM +0200, Jakub Jelinek wrote:
On Fri, Jun 14, 2013 at 01:07:01AM +0930, Alan Modra wrote:
@@ -5774,10 +5818,11 @@ offsettable_ok_by_alignment (rtx op, HOST_WIDE_INT
type = TREE_TYPE (decl);
dalign = TYPE_ALIGN (type);
+ dalign = DATA_ABI_ALIGNMENT (type, dalign);
if (CONSTANT_CLASS_P (decl))
dalign = CONSTANT_ALIGNMENT (decl, dalign);
else
- dalign = DATA_ALIGNMENT (decl, dalign);
+ dalign = DATA_ALIGNMENT (type, dalign);
if (dsize == 0)
{
What is this code trying to do? Shouldn't it just use DECL_ALIGN
which should be set to the right value from get_variable_alignment?
I mean, if !decl_binds_to_current_def_p (decl), then using DATA_ALIGNMENT
or CONSTANT_ALIGNMENT (for anything but actually emitting the var into
object, or just as an optimization hint that very likely the decl will be
aligned enough, but not guaranteed), which are optimization, is wrong
(an ABI problem).
It is handling !DECL_P trees, which must be local. I know I saw
STRING_CST here when I wrote offsettable_ok_by_alignment, hence the
use of CONSTANT_ALIGNMENT. I'm not so sure about the need for
DATA_ALIGNMENT now, but if it was correct before then we ought to
be using both DATA_ABI_ALIGNMENT and DATA_ALIGNMENT after your
changes.
Yeah, then it makes sense. Sorry for not looking up earlier that this is
the !DECL_P case.
As for the
typedef int vec_align __attribute__ ((vector_size(16), aligned(32)));
vec_align x = { 0, 0, 0, 0 };
changes, that is ABI changing bugfix, so the question is, are you fine with
breaking the ABI (between 4.8 and 4.9, or if you wanted to backport it to
4.8 too (I certainly plan to backport the non-ppc DATA_ABI_ALIGNMENT changes
to 4.8.2, already am using it in our compilers))? The other option is
to fix the ABI, but keep things backwards ABI compatible. That would be
done by decreasing the alignment as it used to do before in DATA_ABI_ALIGNMENT,
and increasing it to the desirable level only in DATA_ALIGNMENT. That has
the effect that when emitting the decls into assembly e.g. the above will
now be correctly 32 byte aligned, but accesses to such decl in compiler
generated code will only assume that alignment if
decl_binds_to_current_def_p, otherwise they will keep assuming the old
(broken) lowered alignment. At least for 4.8 backport IMHO that would be a
better idea (but of course would need big comment explaning it).
Jakub
Re: expand_expr tweaks to fix PR57134
On Fri, Jun 14, 2013 at 10:38 AM, Alan Modra amo...@gmail.com wrote:
On Thu, Jun 13, 2013 at 10:45:38AM +0200, Richard Biener wrote:
On Wed, Jun 12, 2013 at 4:48 AM, Alan Modra amo...@gmail.com wrote:
The following patch fixes PR57134 by
a) excluding bitfield expansion when EXPAND_MEMORY, and
b) passing down the EXPAND_MEMORY modifier in a couple of places where
this does not currently happen on recursive calls to expand_expr().
I suppose it also fixes PR57586 which looks similar?
Not completely. It cures the ICE, but you still get output number 0
not directly addressable. The reason being that expand_asm_operands
isn't asking for a mem. It should I guess, and also not specify
EXPAND_WRITE on an inout parameter. Bootstrapped and regression
tested powerpc64-linux.
It looks reasonable to me, but I'm not too familiar with EXPAND_MEMORY
vs. EXPAND_WRITE.
Btw, I wonder if for strict-alignment targets asm()s can expect aligned
memory if they request an asm input with m? Thus, do we eventually
have to copy a known unaligned mem to aligned scratch memory before
passing it to a m input? Do we maybe have to do the same even for
m outputs? Or is this all simply undefined and asm()s have to handle
arbitrary alignment of memory operands (well, those that appear
at runtime, of course).
Richard.
PR middle-end/57586
* stmt.c (expand_asm_operands): Call expand_expr with
EXPAND_MEMORY for output operands that disallow regs. Don't
use EXPAND_WRITE on inout operands.
Index: gcc/stmt.c
===
--- gcc/stmt.c (revision 200083)
+++ gcc/stmt.c (working copy)
@@ -807,7 +807,10 @@ expand_asm_operands (tree string, tree outputs, tr
|| ! allows_reg
|| is_inout)
{
- op = expand_expr (val, NULL_RTX, VOIDmode, EXPAND_WRITE);
+ op = expand_expr (val, NULL_RTX, VOIDmode,
+ !allows_reg ? EXPAND_MEMORY
+ : !is_inout ? EXPAND_WRITE
+ : EXPAND_NORMAL);
if (MEM_P (op))
op = validize_mem (op);
Ok with a testcase and mentioning PR57586 in the changelog.
gcc.dg/compile/pr57134.c added.
--
Alan Modra
Australia Development Lab, IBM
Re: [RFC] Inconsistency in ordering vector widening operations on big-endian targets?
Alan Modra wrote: On Wed, Jun 12, 2013 at 04:22:46PM +0100, Tejas Belagod wrote: From the IR above, it seems that result of widening the high part (vect__12.6_40) is being stored at offset 0 from _29 and result of widening the low part goes into *(_29 + 16). Shouldn't this be the other way around? Big-endian targets store the high part of multi-byte values at the low address. Why should vectors be different? True. But the memory order of individual elements cannot be changed. I did a bit more digging into this and realized this was because of the big-endian representation of vectors in gcc where the order of lanes are reversed. I will need to fix up my back-end to reflect this reverse ordering. Thanks for your input. Tejas.
[PATCH GCC]Fix PR57540, try to choose scaled_offset address mode when expanding array reference
Hi,
As reported in pr57540, gcc chooses bad address mode, resulting in A)
invariant part of address expression is not kept or hoisted; b) additional
computation which should be encoded in address expression. The reason is
when gcc runs into addr+offset (which is invalid) during expanding, it
pre-computes the entire address and accesses memory unit using MEM[reg].
Yet we can force addr into register and try to generate reg+offset which
is valid for targets like ARM. By doing this, we can:
1) keep addr in loop invariant form and hoist it later;
2) saving additional computation by taking advantage of scaled addressing
mode;
This issue has substantial impact for ARM mode, and also benefits Thumb2
although not so much as ARM mode. For example from the bug entry, assembly
code like:
blt .L3
.L5:
add lr, sp, #2064loop invariant
add r2, r2, #1
add r3, lr, r3, asl #2
ldr r3, [r3, #-2064]
cmp r3, #0
bge .L5
uxtbr2, r2
can be optimized into:
blt .L3
.L5:
add r2, r2, #1
ldr r3, [sp, r3, asl #2]
cmp r3, #0
bge .L5
uxtbr2, r2
Bootstrap and test on x86/arm, any comments?
Thanks.
bin
2013-06-13 Bin Cheng bin.ch...@arm.com
PR target/57540
* emit-rtl.c (offset_address): Try to force ADDR into register and
generate reg+offset if addr+offset is invalid.
Index: gcc/emit-rtl.c
===
--- gcc/emit-rtl.c (revision 199949)
+++ gcc/emit-rtl.c (working copy)
@@ -2175,15 +2175,20 @@ offset_address (rtx memref, rtx offset, unsigned H
/* At this point we don't know _why_ the address is invalid. It
could have secondary memory references, multiplies or anything.
+ Yet we can try to force addr into register, in order to catch
+ the scaled addressing opportunity as reg + scaled_offset.
- However, if we did go and rearrange things, we can wind up not
+ Otherwise, if we did go and rearrange things, we can wind up not
being able to recognize the magic around pic_offset_table_rtx.
This stuff is fragile, and is yet another example of why it is
- bad to expose PIC machinery too early. */
+ bad to expose PIC machinery too early. We may also wind up not
+ being able to recognize the scaled addressing pattern.
+
+ It won't hurt because the address here is invalid and we are
+ going to pre-compute it anyway. */
if (! memory_address_addr_space_p (GET_MODE (memref), new_rtx,
attrs.addrspace)
- GET_CODE (addr) == PLUS
- XEXP (addr, 0) == pic_offset_table_rtx)
+ GET_CODE (addr) == PLUS)
{
addr = force_reg (GET_MODE (addr), addr);
new_rtx = simplify_gen_binary (PLUS, address_mode, addr, offset);
Re: [PATCH] DATA_ALIGNMENT vs. DATA_ABI_ALIGNMENT (PR target/56564)
On Fri, Jun 14, 2013 at 10:59:52AM +0200, Jakub Jelinek wrote:
On Fri, Jun 14, 2013 at 08:18:19AM +0930, Alan Modra wrote:
It is handling !DECL_P trees, which must be local. I know I saw
STRING_CST here when I wrote offsettable_ok_by_alignment, hence the
use of CONSTANT_ALIGNMENT. I'm not so sure about the need for
DATA_ALIGNMENT now, but if it was correct before then we ought to
be using both DATA_ABI_ALIGNMENT and DATA_ALIGNMENT after your
changes.
Yeah, then it makes sense. Sorry for not looking up earlier that this is
the !DECL_P case.
Your comment prodded me into looking at whether the !DECL_P code is
needed in 4.9, and it looks like we never see !DECL_P trees..
Bootstrap and regression tests all langs on powerpc64 didn't hit a
gcc_unreachable() I put there, both with -fsection-anchors and
-fno-section-anchors. David, please consider that piece of the patch
retracted.
As for the
typedef int vec_align __attribute__ ((vector_size(16), aligned(32)));
vec_align x = { 0, 0, 0, 0 };
changes, that is ABI changing bugfix, so the question is, are you fine with
breaking the ABI (between 4.8 and 4.9, or if you wanted to backport it to
4.8 too (I certainly plan to backport the non-ppc DATA_ABI_ALIGNMENT changes
to 4.8.2, already am using it in our compilers))? The other option is
to fix the ABI, but keep things backwards ABI compatible. That would be
done by decreasing the alignment as it used to do before in
DATA_ABI_ALIGNMENT,
and increasing it to the desirable level only in DATA_ALIGNMENT. That has
the effect that when emitting the decls into assembly e.g. the above will
now be correctly 32 byte aligned, but accesses to such decl in compiler
generated code will only assume that alignment if
decl_binds_to_current_def_p, otherwise they will keep assuming the old
(broken) lowered alignment. At least for 4.8 backport IMHO that would be a
better idea (but of course would need big comment explaning it).
I see your point, but for there to be a real problem we'd need
a) A library exporting such a type with (supposed) increased
alignment, and,
b) gcc would need to make use of the increased alignment.
(a) must be rare or non-existent or you'd think we would have had a
bug report about lack of user alignment in vector typedefs. The code
has been like this since 2001-11-07, so users have had a long time to
discover it. (Of course, this is an argument for just ignoring the
bug too.)
(b) doesn't happen in the rs6000 backend as far as I'm aware. Do you
know whether there is some optimisation based on alignment in generic
parts of gcc? A quick test like
typedef int vec_align __attribute__ ((vector_size(16), aligned(32)));
vec_align x = { 0, 0, 0, 0 };
long f1 (void)
{
return (long) x -32;
}
static int y __attribute__ ((aligned(32)));
long f2 (void)
{
return (long) y -32;
}
shows the -32 in both functions isn't optimised away.
--
Alan Modra
Australia Development Lab, IBM
Re: [PATCH] DATA_ALIGNMENT vs. DATA_ABI_ALIGNMENT (PR target/56564)
On Fri, Jun 14, 2013 at 08:12:02PM +0930, Alan Modra wrote:
As for the
typedef int vec_align __attribute__ ((vector_size(16), aligned(32)));
vec_align x = { 0, 0, 0, 0 };
changes, that is ABI changing bugfix, so the question is, are you fine with
breaking the ABI (between 4.8 and 4.9, or if you wanted to backport it to
4.8 too (I certainly plan to backport the non-ppc DATA_ABI_ALIGNMENT changes
to 4.8.2, already am using it in our compilers))? The other option is
to fix the ABI, but keep things backwards ABI compatible. That would be
done by decreasing the alignment as it used to do before in
DATA_ABI_ALIGNMENT,
and increasing it to the desirable level only in DATA_ALIGNMENT. That has
the effect that when emitting the decls into assembly e.g. the above will
now be correctly 32 byte aligned, but accesses to such decl in compiler
generated code will only assume that alignment if
decl_binds_to_current_def_p, otherwise they will keep assuming the old
(broken) lowered alignment. At least for 4.8 backport IMHO that would be a
better idea (but of course would need big comment explaning it).
I see your point, but for there to be a real problem we'd need
a) A library exporting such a type with (supposed) increased
alignment, and,
b) gcc would need to make use of the increased alignment.
(a) must be rare or non-existent or you'd think we would have had a
bug report about lack of user alignment in vector typedefs. The code
has been like this since 2001-11-07, so users have had a long time to
discover it. (Of course, this is an argument for just ignoring the
bug too.)
It doesn't have to be an exported symbol from a library, it is enough to
compile some objects using one compiler and other objects using another
compiler, then link into the same library.
(b) doesn't happen in the rs6000 backend as far as I'm aware. Do you
know whether there is some optimisation based on alignment in generic
parts of gcc? A quick test like
Tons of them, the DECL_ALIGN value is used say by get_pointer_alignment,
vectorizer assumptions, is added to MEM_ATTRS, so anything looking at
alignment in RTL can optimize too.
typedef int vec_align __attribute__ ((vector_size(16), aligned(32)));
vec_align x = { 0, 0, 0, 0 };
long f1 (void)
{
return (long) x -32;
}
Try (long) x 31; ? That x -32 not being optimized into x
is guess a missed optimization.
Consider if you put:
typedef int vec_align __attribute__ ((vector_size(16), aligned(32)));
vec_align x = { 0, 0, 0, 0 };
into one TU and compile with gcc 4.8.1, then
typedef int vec_align __attribute__ ((vector_size(16), aligned(32)));
extern vec_align x;
long f1 (void)
{
return (long) x 31;
}
in another TU and compile with gcc trunk after your patch. I bet
it will be optimized into return 0; by the trunk + your patch compiler,
while the alignment will be actually just 16 byte.
Jakub
Re: [Patch, Fortran] PR57508 - Fix ICE/Reject-valid issue with get_temp_from_expr (intrinsic assignment with defined assignment)
Le 13/06/2013 19:56, Tobias Burnus a écrit : Mikael Morin wrote: This fixes the problem, but shouldn't the fix be in gfc_expr_attr instead? I tried it - but it does not work: In many case, one actually needs a function, e.g. for procedure pointers or for C_FUNLOC. Thus, I had to add an additional flag to tell whether the function or the function result it needed. But instead of adding a Boolean flag to 55 calls, which can be false in 54 case and true in 1, I think that the original patch is better. It's the only case where not an attribute it checked - but where attributes are copied. Thus, is the original patch okay? Or do you have a better proposal?http://gcc.gnu.org/ml/fortran/2013-06/msg00027.html Sorry, I didn't see what the problem really was. Yes, the original patch is OK. Mikael
Re: [patch] reimplement -fstrict-volatile-bitfields
On Wed, Jun 12, 2013 at 11:59 PM, Sandra Loosemore san...@codesourcery.com wrote: Background: on ARM and some other targets, the ABI requires that volatile bit-fields be accessed atomically in a mode that corresponds to the declared type of the field, which conflicts with GCC's normal behavior of doing accesses in a mode that might correspond to the size of a general-purpose register, the size of the bit-field, or the bit range corresponding to the C++ memory model. This is what the -fstrict-volatile-bitfields flag does, and it is the default on ARM and other targets where the ABI requires this behavior. Both the original patch that added -fstrict-volatile-bitfields support and a subsequent followup patch that tried to unbreak handling of packed structures (where fields might not be properly aligned to do the single access otherwise mandated by -fstrict-volatile-bitfields) only handled bit-field reads, and not writes. Last year I submitted a patch we've had locally for some time to extend the existing implementation to writes, but it was rejected on the grounds that the current implementation is too broken to fix or extend. I didn't have time then to start over from scratch, and meanwhile, the bug reports about -fstrict-volatile-bitfields have continued to pile up. So let's try again to fix this, this time working from the ground up. From last year's discussion, it seemed that there were two primary objections to the current implementation: (1) It was seen as inappropriate that warnings about conflicts between unaligned fields and -fstrict-volatile-bitfields were being emitted during expand. It was suggested that any diagnostics ought to be emitted by the various language front ends instead. (2) The way packed fields are being detected is buggy and an abstraction violation, and passing around a packedp flag to all the bit-field expand functions is ugly. And, my own complaints about the current implementation: (3) Users expect packed structures to work even on targets where -fstrict-volatile-bitfields is the default, so the compiler shouldn't generate code for accesses to unaligned fields that either faults at run time due to the unaligned access or silently produces an incorrect result (e.g., by only accessing part of the bit-field), with or without a warning at compile time. (4) There's pointless divergence between the bit-field store and extract code that has led to a number of bugs. I've come up with a new patch that tries to address all these issues. For problem (1), I've eliminated the warnings from expand. I'm not opposed to adding them back to the front ends, as previously suggested, but given that they were only previously implemented for reads and not writes and that it was getting the different-warning-for-packed-fields behavior wrong in some cases, getting rid of the warnings is at least as correct as adding them for bit-field writes, too. ;-) I've killed the packedp flag from item (2) completely too. For problem (3), my reading of the ARM ABI document is that the requirements for atomic access to volatile bit-fields only apply to bit-fields that are aligned according to the ABI requirements. If a user has used GCC extensions to create a non-ABI-compliant packed structure where an atomic bit-field access of the correct size is not possible or valid on the target, then GCC ought to define some reasonable access behavior for those bit-fields too as a further extension -- whether or not it complies with the ABI requirements for unpacked structures -- rather than just generating invalid code. In particular, generating the access using whatever technique it would fall back to if -fstrict-volatile-bitfields didn't apply, in cases where it *cannot* be applied, seems perfectly reasonable to me. To address problem (4), I've tried to make the code for handling -fstrict-volatile-bitfields similar in the read and write cases. I think there is probably more that can be done here in terms of refactoring some of the now-common code and changing the interfaces to be more consistent as well, but I think it would be more clear to separate changes that are just code cleanup from those that are intended to change behavior. I'm willing to work on code refactoring as a followup patch if the maintainers recommend or require that. I've regression tested the attached patch on arm-none-eabi as well as bootstrapping and regression testing on x86_64-linux-gnu. I also did some spot testing on mipsisa32r2-sde-elf. I verified that all the new test cases pass on these targets with this patch. Without the patch, I saw these failures: pr23623.c: ARM, x86_64, MIPS pr48784-1.c: ARM, x86_64, MIPS pr48784-2.c: none pr56341-1.c: ARM, MIPS pr56341-2.c: none pr56997-1.c: ARM pr56997-2.c: ARM, MIPS pr56997-3.c: ARM, MIPS volatile-bitfields-3.c: ARM, x86_64, MIPS Here are some comments on specific parts of the patch. The meat
[C++ Patch] PR 51413
Hi,
maybe we can resolve this one too, it remained assigned to me too much time.
Currently the diagnostic is completely broken:
cannot apply ‘offsetof’ to member function ‘#‘indirect_ref’ not
supported by dump_decl#declaration error’
Given the usual issues with prettyprinting expressions, I think we can
still make good progress along the way of the below (which is also quite
close to what ICC does, for example). What do you think? I took the
wording directly from the documentation.
Tested x86_64-linux.
Thanks,
Paolo.
//
/cp
2013-06-14 Paolo Carlini paolo.carl...@oracle.com
PR c++/51413
* semantics.c (finish_offsetof): Handle INDIRECT_REF as expr.
/testsuite
2013-06-14 Paolo Carlini paolo.carl...@oracle.com
PR c++/51413
* g++.dg/ext/builtin-offsetof1.C: New.
Index: cp/semantics.c
===
--- cp/semantics.c (revision 200088)
+++ cp/semantics.c (working copy)
@@ -3690,10 +3690,17 @@ finish_offsetof (tree expr)
|| TREE_CODE (TREE_TYPE (expr)) == METHOD_TYPE
|| TREE_TYPE (expr) == unknown_type_node)
{
- if (TREE_CODE (expr) == COMPONENT_REF
- || TREE_CODE (expr) == COMPOUND_EXPR)
- expr = TREE_OPERAND (expr, 1);
- error (cannot apply %offsetof% to member function %qD, expr);
+ if (TREE_CODE (expr) == INDIRECT_REF)
+ error (second operand of %offsetof% is neither a single
+ identifier nor a sequence of member accesses and
+ array references);
+ else
+ {
+ if (TREE_CODE (expr) == COMPONENT_REF
+ || TREE_CODE (expr) == COMPOUND_EXPR)
+ expr = TREE_OPERAND (expr, 1);
+ error (cannot apply %offsetof% to member function %qD, expr);
+ }
return error_mark_node;
}
if (REFERENCE_REF_P (expr))
Index: testsuite/g++.dg/ext/builtin-offsetof1.C
===
--- testsuite/g++.dg/ext/builtin-offsetof1.C(revision 0)
+++ testsuite/g++.dg/ext/builtin-offsetof1.C(working copy)
@@ -0,0 +1,9 @@
+// PR c++/51413
+// { dg-options -w }
+
+struct A
+{
+ static void foo();
+};
+
+int i = __builtin_offsetof(A, foo[1]); // { dg-error neither a single
identifier nor a sequence of member accesses and array references }
[AArch64] Support for SMLAL/SMLSL/UMLAL/UMLSL
Hello, This patch adds support to SMLAL/SMLSL/UMLAL/UMLSL instructions and adds tests for the same. Regression test run for aarch64-none-elf with no regressions. OK? ~VP --- gcc/ChangeLog 2013-06-14 Vidya Praveen vidyaprav...@arm.com * config/aarch64/aarch64-simd.md (*aarch64_sumlal_lomode): New pattern to support SMLAL,UMLAL instructions. * config/aarch64/aarch64-simd.md (*aarch64_sumlal_himode): New pattern to support SMLAL2,UMLAL2 instructions. * config/aarch64/aarch64-simd.md (*aarch64_sumlsl_lomode): New pattern to support SMLSL,UMLSL instructions. * config/aarch64/aarch64-simd.md (*aarch64_sumlsl_himode): New pattern to support SMLSL2,UMLSL2 instructions. * config/aarch64/aarch64-simd.md (*aarch64_sumlalmode): New pattern to support SMLAL/UMLAL instructions for 64 bit vector modes. * config/aarch64/aarch64-simd.md (*aarch64_sumlslmode): New pattern to support SMLSL/UMLSL instructions for 64 bit vector modes. gcc/testsuite/ChangeLog 2013-06-14 Vidya Praveen vidyaprav...@arm.com * gcc.target/aarch64/vect_smlal_1.c: New file.diff --git a/gcc/config/aarch64/aarch64-simd.md b/gcc/config/aarch64/aarch64-simd.md index e5990d4..8589476 100644 --- a/gcc/config/aarch64/aarch64-simd.md +++ b/gcc/config/aarch64/aarch64-simd.md @@ -1190,6 +1190,104 @@ ;; Widening arithmetic. +(define_insn *aarch64_sumlal_lomode + [(set (match_operand:VWIDE 0 register_operand =w) +(plus:VWIDE + (mult:VWIDE + (ANY_EXTEND:VWIDE (vec_select:VHALF + (match_operand:VQW 2 register_operand w) + (match_operand:VQW 3 vect_par_cnst_lo_half ))) + (ANY_EXTEND:VWIDE (vec_select:VHALF + (match_operand:VQW 4 register_operand w) + (match_dup 3 + (match_operand:VWIDE 1 register_operand 0)))] + TARGET_SIMD + sumlal\t%0.Vwtype, %2.Vhalftype, %4.Vhalftype + [(set_attr simd_type simd_mlal) + (set_attr simd_mode MODE)] +) + +(define_insn *aarch64_sumlal_himode + [(set (match_operand:VWIDE 0 register_operand =w) +(plus:VWIDE + (mult:VWIDE + (ANY_EXTEND:VWIDE (vec_select:VHALF + (match_operand:VQW 2 register_operand w) + (match_operand:VQW 3 vect_par_cnst_hi_half ))) + (ANY_EXTEND:VWIDE (vec_select:VHALF + (match_operand:VQW 4 register_operand w) + (match_dup 3 + (match_operand:VWIDE 1 register_operand 0)))] + TARGET_SIMD + sumlal2\t%0.Vwtype, %2.Vtype, %4.Vtype + [(set_attr simd_type simd_mlal) + (set_attr simd_mode MODE)] +) + +(define_insn *aarch64_sumlsl_lomode + [(set (match_operand:VWIDE 0 register_operand =w) +(minus:VWIDE + (match_operand:VWIDE 1 register_operand 0) + (mult:VWIDE + (ANY_EXTEND:VWIDE (vec_select:VHALF + (match_operand:VQW 2 register_operand w) + (match_operand:VQW 3 vect_par_cnst_lo_half ))) + (ANY_EXTEND:VWIDE (vec_select:VHALF + (match_operand:VQW 4 register_operand w) + (match_dup 3))] + TARGET_SIMD + sumlsl\t%0.Vwtype, %2.Vhalftype, %4.Vhalftype + [(set_attr simd_type simd_mlal) + (set_attr simd_mode MODE)] +) + +(define_insn *aarch64_sumlsl_himode + [(set (match_operand:VWIDE 0 register_operand =w) +(minus:VWIDE + (match_operand:VWIDE 1 register_operand 0) + (mult:VWIDE + (ANY_EXTEND:VWIDE (vec_select:VHALF + (match_operand:VQW 2 register_operand w) + (match_operand:VQW 3 vect_par_cnst_hi_half ))) + (ANY_EXTEND:VWIDE (vec_select:VHALF + (match_operand:VQW 4 register_operand w) + (match_dup 3))] + TARGET_SIMD + sumlsl2\t%0.Vwtype, %2.Vtype, %4.Vtype + [(set_attr simd_type simd_mlal) + (set_attr simd_mode MODE)] +) + +(define_insn *aarch64_sumlalmode + [(set (match_operand:VWIDE 0 register_operand =w) +(plus:VWIDE + (mult:VWIDE +(ANY_EXTEND:VWIDE + (match_operand:VDW 1 register_operand w)) +(ANY_EXTEND:VWIDE + (match_operand:VDW 2 register_operand w))) + (match_operand:VWIDE 3 register_operand 0)))] + TARGET_SIMD + sumlal\t%0.Vwtype, %1.Vtype, %2.Vtype + [(set_attr simd_type simd_mlal) + (set_attr simd_mode MODE)] +) + +(define_insn *aarch64_sumlslmode + [(set (match_operand:VWIDE 0 register_operand =w) +(minus:VWIDE + (match_operand:VWIDE 1 register_operand 0) + (mult:VWIDE +(ANY_EXTEND:VWIDE + (match_operand:VDW 2 register_operand w)) +(ANY_EXTEND:VWIDE + (match_operand:VDW 3 register_operand w)] + TARGET_SIMD + sumlsl\t%0.Vwtype, %2.Vtype, %3.Vtype + [(set_attr simd_type simd_mlal) + (set_attr simd_mode MODE)] +) + (define_insn
Re: [AArch64] Support for SMLAL/SMLSL/UMLAL/UMLSL
On 14/06/13 14:55, Vidya Praveen wrote: Hello, This patch adds support to SMLAL/SMLSL/UMLAL/UMLSL instructions and adds tests for the same. Regression test run for aarch64-none-elf with no regressions. OK? ~VP --- gcc/ChangeLog 2013-06-14 Vidya Praveen vidyaprav...@arm.com * config/aarch64/aarch64-simd.md (*aarch64_sumlal_lomode): New pattern to support SMLAL,UMLAL instructions. * config/aarch64/aarch64-simd.md (*aarch64_sumlal_himode): New pattern to support SMLAL2,UMLAL2 instructions. * config/aarch64/aarch64-simd.md (*aarch64_sumlsl_lomode): New pattern to support SMLSL,UMLSL instructions. * config/aarch64/aarch64-simd.md (*aarch64_sumlsl_himode): New pattern to support SMLSL2,UMLSL2 instructions. * config/aarch64/aarch64-simd.md (*aarch64_sumlalmode): New pattern to support SMLAL/UMLAL instructions for 64 bit vector modes. * config/aarch64/aarch64-simd.md (*aarch64_sumlslmode): New pattern to support SMLSL/UMLSL instructions for 64 bit vector modes. Convention is that we say what changed in the changelog entry and write the justification in the covering email summary. Therefore in instances like this where you are defining a new pattern in is sufficient to write simply. * config/aarch64/aarch64-simd.md (*aarch64_sumlal_lomode): Define. gcc/testsuite/ChangeLog 2013-06-14 Vidya Praveen vidyaprav...@arm.com * gcc.target/aarch64/vect_smlal_1.c: New file. Otherwise this is OK. You should apply for write access to the tree. Follow the instruction on the WIKI here: http://gcc.gnu.org/svnwrite.html#authenticated Cheers /Marcus
Re: [PATCH] DATA_ALIGNMENT vs. DATA_ABI_ALIGNMENT (PR target/56564)
On Fri, Jun 14, 2013 at 12:54:40PM +0200, Jakub Jelinek wrote:
On Fri, Jun 14, 2013 at 08:12:02PM +0930, Alan Modra wrote:
I see your point, but for there to be a real problem we'd need
a) A library exporting such a type with (supposed) increased
alignment, and,
b) gcc would need to make use of the increased alignment.
(a) must be rare or non-existent or you'd think we would have had a
bug report about lack of user alignment in vector typedefs. The code
has been like this since 2001-11-07, so users have had a long time to
discover it. (Of course, this is an argument for just ignoring the
bug too.)
It doesn't have to be an exported symbol from a library, it is enough to
compile some objects using one compiler and other objects using another
compiler, then link into the same library.
OK.
Try (long) x 31; ? That x -32 not being optimized into x
is guess a missed optimization.
Huh, trust me to hit another bug. :)
Consider if you put:
typedef int vec_align __attribute__ ((vector_size(16), aligned(32)));
vec_align x = { 0, 0, 0, 0 };
into one TU and compile with gcc 4.8.1, then
typedef int vec_align __attribute__ ((vector_size(16), aligned(32)));
extern vec_align x;
long f1 (void)
{
return (long) x 31;
}
in another TU and compile with gcc trunk after your patch. I bet
it will be optimized into return 0; by the trunk + your patch compiler,
while the alignment will be actually just 16 byte.
Right. Counterpoint is that gcc made exactly the same sort of error
across TUs and even in the same TU prior to my change. eg.
typedef int vec_align __attribute__ ((vector_size(16), aligned(32)));
vec_align x = { 0, 0, 0, 0 };
long f1 (void) { return (long)x 31; }
int y __attribute__ ((vector_size(16), aligned(32))) = { 0, 0, 0, 0 };
long f2 (void) { return (long)y 31; }
compiles to
.L.f1:
li 3,0
blr
..
.L.f2:
li 3,0
blr
..
.globl y
.lcomm y,16,32
.type y, @object
.globl x
.lcomm x,16,16
.type x, @object
.ident GCC: (GNU) 4.7.2 20120921 (Red Hat 4.7.2-2)
My implementation of rs6000_data_alignment therefore doesn't introduce
a *new* ABI incompatibility. I question whether it is worth
complicating rs6000_data_alignment, especially since your suggestion
of using the older buggy alignment in DATA_ABI_ALIGNMENT then
increasing in DATA_ALIGNMENT isn't as simple as it sounds. We're
not talking about some fixed increase in DATA_ALIGNMENT but what we
want is the value of alignment before DATA_ABI_ALIGNMENT. Perhaps
that could be retrieved from TYPE_ALIGN (type) and
MAX_OFILE_ALIGNMENT, but that would make our DATA_ALIGNMENT the only
target to need such tricks.
--
Alan Modra
Australia Development Lab, IBM
Re: [AArch64] Support for SMLAL/SMLSL/UMLAL/UMLSL
On 14/06/13 15:33, Marcus Shawcroft wrote: On 14/06/13 14:55, Vidya Praveen wrote: Hello, This patch adds support to SMLAL/SMLSL/UMLAL/UMLSL instructions and adds tests for the same. Regression test run for aarch64-none-elf with no regressions. OK? ~VP --- gcc/ChangeLog 2013-06-14 Vidya Praveen vidyaprav...@arm.com * config/aarch64/aarch64-simd.md (*aarch64_sumlal_lomode): New pattern to support SMLAL,UMLAL instructions. * config/aarch64/aarch64-simd.md (*aarch64_sumlal_himode): New pattern to support SMLAL2,UMLAL2 instructions. * config/aarch64/aarch64-simd.md (*aarch64_sumlsl_lomode): New pattern to support SMLSL,UMLSL instructions. * config/aarch64/aarch64-simd.md (*aarch64_sumlsl_himode): New pattern to support SMLSL2,UMLSL2 instructions. * config/aarch64/aarch64-simd.md (*aarch64_sumlalmode): New pattern to support SMLAL/UMLAL instructions for 64 bit vector modes. * config/aarch64/aarch64-simd.md (*aarch64_sumlslmode): New pattern to support SMLSL/UMLSL instructions for 64 bit vector modes. Convention is that we say what changed in the changelog entry and write the justification in the covering email summary. Therefore in instances like this where you are defining a new pattern in is sufficient to write simply. * config/aarch64/aarch64-simd.md (*aarch64_sumlal_lomode): Define. I tend to prefer New pattern. over Define. on the grounds that it tells me that this is a pattern, not a constraint or some other construct. Also, there's no need to repeat the file name each time, or put the leading '*' on the pattern name. You can also list more than one function at the same time if it has the same description, and use 'Likewise' when this extends to multiple lines. Finally, don't over-indent continuation lines. So: 2013-06-14 Vidya Praveen vidyaprav...@arm.com * config/aarch64/aarch64-simd.md (aarch64_sumlal_lomode): New pattern. (aarch64_sumlal_himode, aarch64_sumlsl_lomode): Likewise. (aarch64_sumlsl_himode, aarch64_sumlalmode): Likewise. etc.
Re: [AArch64] Support for SMLAL/SMLSL/UMLAL/UMLSL
On 14/06/13 16:01, Richard Earnshaw wrote: On 14/06/13 15:33, Marcus Shawcroft wrote: On 14/06/13 14:55, Vidya Praveen wrote: [...] to support SMLAL/UMLAL instructions for 64 bit vector modes. * config/aarch64/aarch64-simd.md (*aarch64_sumlslmode): New pattern to support SMLSL/UMLSL instructions for 64 bit vector modes. Convention is that we say what changed in the changelog entry and write the justification in the covering email summary. Tmsg00853.htmlherefore in instances like this where you are defining a new pattern in is sufficient to write simply. * config/aarch64/aarch64-simd.md (*aarch64_sumlal_lomode): Define. I tend to prefer New pattern. over Define. on the grounds that it tells me that this is a pattern, not a constraint or some other construct. Also, there's no need to repeat the file name each time, or put the leading '*' on the pattern name. You can also list more than one function at the same time if it has the same description, and use 'Likewise' when this extends to multiple lines. Finally, don't over-indent continuation lines. So: 2013-06-14 Vidya Praveen vidyaprav...@arm.com * config/aarch64/aarch64-simd.md (aarch64_sumlal_lomode): New pattern. (aarch64_sumlal_himode, aarch64_sumlsl_lomode): Likewise. (aarch64_sumlsl_himode, aarch64_sumlalmode): Likewise. etc. Thanks Marcus/Richard for the recommendations. After changes: gcc/ChangeLog 2013-06-14 Vidya Praveen vidyaprav...@arm.com * config/aarch64/aarch64-simd.md (aarch64_sumlal_lomode): New pattern. (aarch64_sumlal_himode, aarch64_sumlsl_lomode): Likewise. (aarch64_sumlsl_himode, aarch64_sumlalmode): Likewise. (aarch64_sumlslmode): Likewise. gcc/testsuite/ChangeLog 2013-06-14 Vidya Praveen vidyaprav...@arm.com * gcc.target/aarch64/vect_smlal_1.c: New file. ~VP
Re: [Fortran-Dev] Merge trunk into the branch
First: I did another trunk to branch merge (Revision 200091). Dominique Dhumieres wrote: The failures for coarray_lib_alloc_2.f90 and coarray_lib_alloc_3.f90 are fixed with the followin patch: I think that's a bug in the compiler (on the branch). A derived type without any components should only allocate a single byte. I have filled PR57611. Tobias
Added myself to MAINTAINERS (Write After Approval)
2013-06-14 Vidya Praveen vidyaprav...@arm.com * MAINTAINERS (Write After Approval): Add myself. Index: MAINTAINERS === --- MAINTAINERS (revision 200091) +++ MAINTAINERS (working copy) @@ -487,6 +487,7 @@ Paul Pluzhnikovppluzhni...@google.com Marek Polacek pola...@redhat.com Antoniu Popantoniu@gmail.com +Vidya Praveen vidyaprav...@arm.com Vladimir Prus vladi...@codesourcery.com Yao Qi y...@codesourcery.com Jerry Quinnjlqu...@optonline.net
Re: [patch] reimplement -fstrict-volatile-bitfields
On 06/14/2013 06:31 AM, Richard Biener wrote:
I think we can split the patch up, so let me do piecewise approval of changes.
The changes that remove the packedp flag passing around and remove
the warning code are ok. The store_bit_field_1 change is ok, as is
the similar extract_bit_field_1 change (guard the other register copying path).
Please split those out and commit them separately (I suppose they are
strict progressions in testing).
I will work on splitting the patch, but I feel a little uncomfortable
about starting to commit it piecewise without some more clear indication
that this is the right direction. Otherwise we'll just be back in the
situation where things are still inconsistent and broken, but in a
different way than before.
That leaves a much smaller set of changes for which I have one comment
for now:
@@ -4508,6 +4508,16 @@ get_bit_range (unsigned HOST_WIDE_INT *b
gcc_assert (TREE_CODE (exp) == COMPONENT_REF);
+ /* If -fstrict-volatile-bitfields was given and this is a volatile
+ access, then we must ignore any DECL_BIT_FIELD_REPRESENTATIVE and
+ do the access in the mode of the field. */
+ if (TREE_THIS_VOLATILE (exp)
+ flag_strict_volatile_bitfields 0)
+{
+ *bitstart = *bitend = 0;
+ return;
+}
with the past reviews where I said the implementation was broken anyway
I was hinting at that DECL_BIT_FIELD_REPRESENTATIVE should simply
be chosen in a way to adhere to flag_strict_volatile_bitfields. I had the
impression that this alone should be enough to implement strict volatile
bitfields correctly and no code in the backend would need to check
for flag_strict_volatile_bitfields. I may of course be wrong here, as
-fstrict-volatile-bitfields may apply to cases where the bitfield is _not_
declared volatile but only the decl? Thus,
struct X {
int i : 3;
};
volatile struct X x;
Is x.i an access that needs to adhere to strict volatile bitfield accesses?
Yes, exactly; see the new pr23623.c test case included with the patch,
for instance. Or the volatile bitfield access could be through a
volatile-qualified pointer, as in the volatile-bitfields-3.c test case.
Bernd Schmidt and I had some internal discussion about this and
neither of us saw how messing with DECL_BIT_FIELD_REPRESENTATIVE could
help where the field is not declared volatile but the object being
referenced is.
Note that IIRC whether you short-cut get_bit_range in the above way
you still get the access to use the mode of the FIELD_DECL.
As I noted in my previous message, the pr23623.c test case was failing
on all the targets I tried without this patch hunk, so the access was
clearly not using the mode of the FIELD_DECL without it.
If the above constitutes a strict volatile bitfield access then the very
correct implementation of strict volatile bitfield accesses is to
adjust the memory accesses the frontends generate (consider
LTO and a TU compiled with -fstrict-volatile-bitfields and another TU
compiled with -fno-strict-volatile-bitfields). Which it probably does
reasonably well already (setting TREE_THIS_VOLATILE on the
outermost bit-field COMPONENT_REF). If that is not preserved
then converting the accesses to BIT_FIELD_REFs is another
possibility. That said, the behavior of GIMPLE IL should not change
dependent on a compile flag.
I am kind of lost, here. -fstrict-volatile-bitfields is a code
generation option, not a front end option, and it seems like LTO should
not need any special handling here any more than it does for any of the
gazillion other code generation options supported by GCC.
-Sandra
