[Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488 --- Comment #2 from Ralf Corsepius ralf_corsepius at rtems dot org 2012-03-12 06:21:42 UTC --- Created attachment 26876 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26876 *.i of the file triggering the ICE This *.i was created from today's (ca. 2012-03-12 05:00 UTC) gcc from gcc-4_7-branch ../gcc-4.7.0-RC-20120302/configure --prefix=/opt/rtems-4.11 --bindir=/opt/rtems-4.11/bin --exec_prefix=/opt/rtems-4.11 --includedir=/opt/rtems-4.11/include --libdir=/opt/rtems-4.11/lib --libexecdir=/opt/rtems-4.11/libexec --mandir=/opt/rtems-4.11/share/man --infodir=/opt/rtems-4.11/share/info --datadir=/opt/rtems-4.11/share --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=avr-rtems4.11 --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --verbose --with-newlib --with-system-zlib --disable-nls --without-included-gettext --disable-win32-registry --enable-version-specific-runtime-libs --enable-threads --disable-lto --disable-plugin --enable-newlib-io-c99-formats --enable-newlib-iconv --enable-languages=c ... make ... /builddir/build/BUILD/rtems-4.11-avr-rtems4.11-gcc-4.7.0/build/./gcc/xgcc -B/builddir/build/BUILD/rtems-4.11-avr-rtems4.11-gcc-4.7.0/build/./gcc/ -nostdinc -B/builddir/build/BUILD/rtems-4.11-avr-rtems4.11-gcc-4.7.0/build/avr-rtems4.11/tiny-stack/newlib/ -isystem /builddir/build/BUILD/rtems-4.11-avr-rtems4.11-gcc-4.7.0/build/avr-rtems4.11/tiny-stack/newlib/targ-include -isystem /builddir/build/BUILD/rtems-4.11-avr-rtems4.11-gcc-4.7.0/gcc-4.7.0-RC-20120302/newlib/libc/include -B/opt/rtems-4.11/avr-rtems4.11/bin/ -B/opt/rtems-4.11/avr-rtems4.11/lib/ -isystem /opt/rtems-4.11/avr-rtems4.11/include -isystem /opt/rtems-4.11/avr-rtems4.11/sys-include -mmcu=at90s2313 -DPACKAGE_NAME=\newlib\ -DPACKAGE_TARNAME=\newlib\ -DPACKAGE_VERSION=\1.20.0\ -DPACKAGE_STRING=\newlib\ 1.20.0\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE_URL=\\ -I. -I../../../../../../gcc-4.7.0-RC-20120302/newlib/libc/posix -Os -DPREFER_SIZE_OVER_SPEED -mcall-prologues -D_COMPILING_NEWLIB -DMALLOC_PROVIDED -DEXIT_PROVIDED -DSIGNAL_PROVIDED -DREENTRANT_SYSCALLS_PROVIDED -DHAVE_NANOSLEEP -DHAVE_BLKSIZE -DHAVE_FCNTL -DHAVE_ASSERT_FUNC -D_NO_GETLOGIN -D_NO_GETPWENT -D_NO_GETUT -D_NO_GETPASS -D_NO_SIGSET -D_NO_WORDEXP -D_NO_POPEN -fno-builtin -D_GNU_SOURCE -g -O2 -c -o lib_a-glob.o `test -f 'glob.c' || echo '../../../../../../gcc-4.7.0-RC-20120302/newlib/libc/posix/'`glob.c ../../../../../../gcc-4.7.0-RC-20120302/newlib/libc/posix/glob.c: In function 'glob': ../../../../../../gcc-4.7.0-RC-20120302/newlib/libc/posix/glob.c:206:1: error: unrecognizable insn: (insn/f 305 304 306 2 (set (reg:QI 28 r28) (plus:QI (reg:QI 28 r28) (const_int -2050 [0xf7fe]))) ../../../../../../gcc-4.7.0-RC-20120302/newlib/libc/posix/glob.c:160 -1 (expr_list:REG_CFA_ADJUST_CFA (set (reg/f:HI 28 r28) (plus:HI (reg/f:HI 28 r28) (const_int -2050 [0xf7fe]))) (nil))) ../../../../../../gcc-4.7.0-RC-20120302/newlib/libc/posix/glob.c:206:1: internal compiler error: in extract_insn, at recog.c:2123 One-tree-style bootstrap (comprising newlib), using avr-rtems4.11-binutils-2.22, newlib-1.20 + rtems patches (glob.c is part of newlib) on fedora-16-x86_64.
[Bug ada/52110] s-osinte.ads:447:09: clockid_t conflicts with declaration at line 194
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52110 --- Comment #8 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-03-12 06:46:41 UTC --- Build is successful with pragma Volatile in lieu of the Atomic. However, test results appear similar: http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg01197.html OK, let's use pragma Volatile anyway, it's the closest approximation we have.
[Bug tree-optimization/50346] Function call foils VRP/jump-threading of redundant predicate on struct member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50346 --- Comment #9 from rguenther at suse dot de rguenther at suse dot de 2012-03-12 08:56:40 UTC --- On Wed, 7 Mar 2012, scovich at gmail dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50346 --- Comment #8 from Ryan Johnson scovich at gmail dot com 2012-03-07 14:28:29 UTC --- (In reply to comment #7) On Wed, 7 Mar 2012, scovich at gmail dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50346 --- Comment #6 from Ryan Johnson scovich at gmail dot com 2012-03-07 13:31:19 UTC --- (In reply to comment #5) On Wed, 12 Oct 2011, scovich at gmail dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50346 --- Comment #4 from Ryan Johnson scovich at gmail dot com 2011-10-12 12:40:25 UTC --- (In reply to comment #3) Well, it's a tree optimization issue. It's simple - the local aggregate f escapes the function via the member function call to baz: bb 5: foo::baz (f); and as our points-to analysis is not flow-sensitive for memory/calls this causes f to be clobbered by the call to bar Is flow-sensitive analysis within single functions prohibitively expensive? All the papers I can find talk about whole-program analysis, where it's very expensive in both time and space; the best I could find (CGO'11 best paper) gets it down to 20-30ms and 2-3MB per kLoC for up to ~300kLoC. It would need a complete rewrite, it isn't integratable into the current solver (which happens to be shared between IPA and non-IPA modes). That makes sense... Wild idea: would it be possible to annotate references as escaped or not escaped yet ? Anything global or passed into the function would be marked as escaped, while anything allocated locally would start out as not escaped; assigning to an escaped location or passing to a function would mark it as escaped if it wasn't already. The status could be determined in linear time using local information only (= scalable), and would benefit strongly as inlining (IPA or not) eliminates escape points. Well, you can compute the clobber/use sets of individual function calls, IPA PTA computes a simple mod-ref analysis this way. You can also annotate functions whether they make arguments escape or whether it reads from them or clobbers them. The plan is to do some simple analysis and propagate that up the callgraph, similar to pure-const analysis. The escape part could be integrated there. That sounds really slick to have in general... but would it actually catch the test case above? What you describe seems to depend on test() having information about foo::baz() -- which it does not -- while analyzing the body of test() could at least identify the part of f's lifetime where it cannot possibly have escaped. Or does the local analysis come for free once those IPA changes are in place? No, the local analysis is what makes the IPA changes free ;) Of course the local analysis would need to be flow sensitive. Richard.
[Bug fortran/52542] Procedure with a Bind (C) named interface does not inherit the Bind (C)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52542 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-03-12 09:03:57 UTC --- Author: burnus Date: Mon Mar 12 09:03:49 2012 New Revision: 185215 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185215 Log: 2012-03-12 Tobias Burnus bur...@net-b.de PR fortran/52542 * decl.c (match_procedure_decl): If the interface is bind(C), the procedure is as well. 2012-03-12 Tobias Burnus bur...@net-b.de PR fortran/52542 * gfortran.dg/proc_ptr_35.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/proc_ptr_35.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/52548] missed PRE optimization when function call follows to-be hoisted variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52548
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords|alias |missed-optimization
Component|middle-end |tree-optimization
--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-12
09:50:05 UTC ---
(In reply to comment #1)
(In reply to comment #0)
The bark() function call is in the same basic block as z = hoist + 4. I
wild
guess is that hoist isn't anticipatable at the *end* of the BB beginning
with
z = hoist + 4. Splitting BB's at function calls may improve PRE. Just a
guess...
What is anticipated at the end of BB is uninteresting. It is computed but not
stored (only needed to compute ANTIC_IN, see compute_antic_aux).
You can check the ANTIC sets and AVAIL_OUT set with -fdump-tree-pre-details.
The value for the expression hoist+4 should be in EXP_GEN of the basic block
with the call, and in AVAIL_OUT of the basic block with y=hoist+4. But this
isn't the case here:
* the value representative for y=hoist+4 is y.2_3-{plus_expr,hoist.1_2,4}
* the value representative for z=hoist+4 is y.2_5-{plus_expr,hoist.1_2,4}
(the name of the representative is y instead of z, probably due to
copyrename)
* SCCVN finds Value numbers:(...)y.2_5=y.2_3, as expected
* y.2_3 is in AVAIL_OUT of the then-block, as expected
* {plus_expr,hoist.1_2,4} is in EXP_GEN of the block with the call, as
expected
* {plus_expr,hoist.1_2,4} is *not* in ANTIC_IN of the block with the call!
This is strange because ANTIC_IN = ANTIC_OUT U EXP_GEN - TMP_GEN
That's simply because ANTIC_IN in reality is clean (ANTIC_OUT U EXP_GEN -
TMP_GEN) and clean () removes all values that are clobbered in that block
(and EXP_GEN is at BB granularity, so inside-BB flow is ignored).
Thus indeed, splitting blocks can improve things here, as would
on-the-fly construction of EXP_GEN/TMP_GEN and doing clean () on its
way when we compute ANTIC_IN. Of course that would be more expensive
if we are iterating.
Note that the way we clean () for memory PRE is ugly anyway, probably
not really envisioned by the original paper (which I bet didn't deal
with aliasing ...)
[Bug middle-end/52450] FAIL: gcc.dg/torture/pr52402.c at -O1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52450 --- Comment #7 from rguenther at suse dot de rguenther at suse dot de 2012-03-12 09:55:54 UTC --- On Sun, 11 Mar 2012, danglin at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52450 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Component|target |middle-end --- Comment #6 from John David Anglin danglin at gcc dot gnu.org 2012-03-11 23:59:26 UTC --- Test is xfailed on trunk. Please note that this is an optimization bug as the test doesn't fail at -O0. While struct T is packed, I don't believe that this implies that its address is misaligned. i is the first field in T. Thus, its address shouldn't be misaligned on a big endian target. Is that so? If so then the testcase is invalid.
[Bug middle-end/52450] FAIL: gcc.dg/torture/pr52402.c at -O1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52450 --- Comment #8 from rguenther at suse dot de rguenther at suse dot de 2012-03-12 09:58:02 UTC --- On Mon, 12 Mar 2012, rguenther at suse dot de wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52450 --- Comment #7 from rguenther at suse dot de rguenther at suse dot de 2012-03-12 09:55:54 UTC --- On Sun, 11 Mar 2012, danglin at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52450 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Component|target |middle-end --- Comment #6 from John David Anglin danglin at gcc dot gnu.org 2012-03-11 23:59:26 UTC --- Test is xfailed on trunk. Please note that this is an optimization bug as the test doesn't fail at -O0. While struct T is packed, I don't believe that this implies that its address is misaligned. i is the first field in T. Thus, its address shouldn't be misaligned on a big endian target. Is that so? If so then the testcase is invalid. Btw, alignof () of a packed struct type is 1 (it could be nested in another packed struct). Richard.
[Bug tree-optimization/52533] [4.8 Regression] ice in remove_range_assertions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52533 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-03-12 10:04:41 UTC --- Author: jakub Date: Mon Mar 12 10:04:34 2012 New Revision: 185219 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185219 Log: PR tree-optimization/52533 * tree-vrp.c (register_edge_assert_for_2): Use double_int type for mask, only handle shifts by non-zero in-range shift count, for LE_EXPR and GT_EXPR if new_val is maximum, don't add the assertion. * gcc.c-torture/compile/pr52533.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr52533.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #67 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-03-12 10:15:39 UTC --- The patch in comment #64 fixes the failures reported in pr52516 but introduces many regressions: === gfortran Summary for unix/-m64 === # of expected passes41076 # of unexpected failures92 # of expected failures56 # of unresolved testcases12 # of unsupported tests71 === gfortran Summary === # of expected passes81865 # of unexpected failures184 # of expected failures112 # of unresolved testcases24 # of unsupported tests280 The failing tests are FAIL: gfortran.dg/alloc_comp_assign_10.f90 -O0 (internal compiler error) FAIL: gfortran.dg/alloc_comp_basics_2.f90 -O0 (internal compiler error) FAIL: gfortran.dg/alloc_comp_initializer_1.f90 -O0 (internal compiler error) FAIL: gfortran.dg/dependency_25.f90 -O0 (internal compiler error) FAIL: gfortran.dg/dependency_37.f90 -O (internal compiler error) FAIL: gfortran.dg/typebound_proc_20.f90 -O (internal compiler error) FAIL: gfortran.dg/whole_file_31.f90 -O (internal compiler error) FAIL: gfortran.dg/lto/pr45586 f_lto_pr45586_0.o assemble, -O0 -flto -flto-partition=none (internal compiler error) and the internal compiler errors are /opt/gcc/work/gcc/testsuite/gfortran.dg/alloc_comp_assign_10.f90: In function 'tao_program': /opt/gcc/work/gcc/testsuite/gfortran.dg/alloc_comp_assign_10.f90:48:0: internal compiler error: in fold_convert_loc, at fold-const.c:2016 ... but I suspect it would not fix the Fortran -flto ICEs in PR51765 (which happen on pristine trunk, much to the same issue I suppose). confirmed AFACT: === gfortran Summary for unix/-m64/-flto === # of expected passes40973 # of unexpected failures186 # of expected failures56 # of unresolved testcases12 # of unsupported tests71 === gfortran Summary === # of expected passes81659 # of unexpected failures372 # of expected failures112 # of unresolved testcases24 # of unsupported tests280
[Bug tree-optimization/52533] [4.8 Regression] ice in remove_range_assertions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52533 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-03-12 10:15:39 UTC --- Fixed.
[Bug c++/52558] New: write introduction incorrect wrt the C++11 memory model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52558
Bug #: 52558
Summary: write introduction incorrect wrt the C++11 memory
model
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: francesco.zappa.narde...@gmail.com
The program below:
int g_1 = 1;
int g_2 = 0;
int func_1(void) {
int l;
for (l = 0; (l != 4); l++) {
if (g_1)
return l;
for (g_2 = 0; (g_2 = 26); ++g_2)
;
}
}
int main (int argc, char* argv[]) {
func_1();
}
is miscompiled by
gcc -v : gcc version 4.7.0 20120215 (experimental) (GCC)
(a recent svn snapshot) on x86-64 when -O2 is passed.
Observe that the inner loop of func_1 is never executed, and this program
should never perform any read/write to g_2. This means that func_1 might be
executed in a thread in parallel with another thread that performs:
g_2 = 42;
printf (%d,g_2)
The resulting system is data-race free and the only value that should be
printed is 42.
However gcc -O2 generates the following x86-64 assembler for func_1:
func_1:
movlg_1(%rip), %edx
movlg_2(%rip), %eax
testl %edx, %edx
jne .L2
movl$0, g_2(%rip)
ret
.L2:
movl%eax, g_2(%rip)
xorl%eax, %eax
ret
and this code always performs a write to g_2. If this asm code runs in
parallel with g_2 = 42; printf g_2, then the system might also print 0: this
behaviour is introduced by the compiler and should not have happened.
The command line to generate the assembler above is:
$ g++ -std=c++11 read_and_write_introduced.c -O2 -S
It might be the case that in the C++11 memory model it is safe for the compiler
to introduce a write provided that there is an earlier write to the same
location, but this testcase shows that introducing a write is unsafe whenever
there are no previous writes.
I labelled this as g++, but the bug will also affect the (future) c11 memory
model.
For reference:
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/riob/zappanar/tools/gcc-bin/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-src/configure --prefix=/home/zappanar/tools/gcc-bin
--with-gmp=/home/zappanar/tools/lib/ --with-mpfr=/home/zappanar/tools/lib/
--with-mpc=/home/zappanar/tools/lib/ --enable-languages=c,c++
Thread model: posix
gcc version 4.7.0 20120215 (experimental) (GCC)
[Bug fortran/52559] New: [4.8 Regression] Spurious \x00 in error messages
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52559 Bug #: 52559 Summary: [4.8 Regression] Spurious \x00 in error messages Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: fxcoud...@gcc.gnu.org Regression, probably due to: http://gcc.gnu.org/ml/fortran/2012-03/msg00015.html There is now a spurious \x00 in the error messages: allocate(t::o)\x00 1 Error: Type of entity at (1) is type incompatible with typespec
[Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488
Georg-Johann Lay gjl at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Priority|P3 |P4
Status|WAITING |NEW
Version|unknown |4.7.0
Target Milestone|--- |4.7.1
--- Comment #3 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-03-12
11:11:49 UTC ---
Confirmed for the followin test case
void bar (char*);
void foo (void)
{
char c[2000];
bar (c);
}
and compiled with
$ avr-gcc sp.c -S -mmcu=attiny2313
The program should not run into ICE, there should be a proper error message.
[Bug tree-optimization/51721] -Warray-bounds false positives and inconsistencies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51721 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2012-03-12 11:12:55 UTC --- Author: jakub Date: Mon Mar 12 11:12:49 2012 New Revision: 185222 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185222 Log: PR tree-optimization/51721 * tree-vrp.c (register_edge_assert_for_2): Add asserts for unsvar if (int) unsvar cmp CST. * gcc.dg/tree-ssa/vrp64.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp64.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug c/52560] New: if (r == -1) causes 'assuming signed overflow does not occur when simplifying conditional to constant'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52560 Bug #: 52560 Summary: if (r == -1) causes 'assuming signed overflow does not occur when simplifying conditional to constant' Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: rjo...@redhat.com Here is the reproducer: wget 'http://oirase.annexia.org/strict-overflow-warning.i.xz' unxz strict-overflow-warning.i.xz gcc -std=gnu99 -O2 -Wstrict-overflow -c strict-overflow-warning.i The warning is: inspect_fs_unix.c: In function ‘check_fstab’: inspect_fs_unix.c:1075:6: warning: assuming signed overflow does not occur when simplifying conditional to constant [-Wstrict-overflow] However the code doesn't look like anything should be simplified, or a warning: n_app_md_devices = map_app_md_devices (g, app_map); if (n_app_md_devices == -1) goto error; where map_app_md_devices is a function that returns an int: static int map_app_md_devices (guestfs_h *g, Hash_table **map); and n_app_md_devices is also an int. I've tried this on several versions of gcc: gcc (GCC) 4.7.0 20120308 (Red Hat 4.7.0-0.19) Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. (for further build info, go to: http://koji.fedoraproject.org/koji/buildinfo?buildID=305760 and click 'build logs') Same thing with this gcc from Ubuntu 11.10: $ gcc --version gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. We think this first started happening in gcc 4.5.1.
[Bug fortran/52552] [OOP] ICE when trying to allocate non-allocatable object giving a dynamic type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52552 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-03-12 11:24:23 UTC --- More details: For gfc_match_allocate (match.c), one has: 3538 if (!gfc_type_compatible (tail-expr-ts, ts)) and then in gfc_type_compatible: (gdb) p ts1-type $6 = BT_CLASS (gdb) p ts2-type $7 = BT_DERIVED (gdb) p ts1-u.derived-components $10 = (gfc_component *) 0x16da1f0 (gdb) p ts1-u.derived-components-ts.u.derived $12 = (gfc_symbol *) 0x0 Which is used for: 4848 if (is_class1 is_derived2) 4849 return gfc_type_is_extension_of(ts1-u.derived-components-ts.u.derived, 4850 ts2-u.derived); Due to the lacking ALLOCATE, tail-expr-ts.u.derived-attr.is_class == 1 Thus, one should check it. The question is only where: In gfc_match_allocate or in gfc_type_compatible?
[Bug fortran/52552] [OOP] ICE when trying to allocate non-allocatable object giving a dynamic type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52552 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2012-03-12 11:29:25 UTC --- (In reply to comment #2) Due to the lacking ALLOCATE, tail-expr-ts.u.derived-attr.is_class == 1 I wanted to say that is_class is not set (i.e. the expression above is false).
[Bug c++/52561] New: GCC is not throwing error if only one character '#' is written in a line.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52561 Bug #: 52561 Summary: GCC is not throwing error if only one character '#' is written in a line. Classification: Unclassified Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: singhserv...@gmail.com Hi, Gcc is not giving compilation error if character # is left alone in a line. It can be followed by comments. below is any example. Example 1: #include stdio.h # #include pthread.h #include iostream SOME CODE HERE Example 2: #include stdio.h #//#include vector.h #include pthread.h #include iostream SOME CODE HERE Thanks, Servesh Singh singhserv...@gmail.com
[Bug preprocessor/52561] GCC is not throwing error if only one character '#' is written in a line.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52561 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Component|c++ |preprocessor --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-03-12 11:42:08 UTC --- The C++ standard clearly says: A preprocessing directive of the form # new-line has no effect. It also allows the second form, which matches this in the grammar: # non-directive
[Bug libstdc++/52562] New: [C++11] Most type_info functions not noexcept
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52562 Bug #: 52562 Summary: [C++11] Most type_info functions not noexcept Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: daniel.krueg...@googlemail.com gcc 4.8.0 20120302 (experimental) in C++11 mode rejects the following program: //-- #include typeinfo templateclass T T lval() noexcept; static_assert(noexcept(lvalstd::type_info().name()), ); static_assert(noexcept(lvalstd::type_info().before(lvalstd::type_info())), ); static_assert(noexcept(lvalstd::type_info() == lvalstd::type_info()), ); static_assert(noexcept(lvalstd::type_info() != lvalstd::type_info()), ); //-- All four static assertions fail, because the corresponding member functions are not declared as noexcept contrary to the library specification in 18.7.1 [type.info].
[Bug libstdc++/52562] [C++11] Most type_info functions not noexcept
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52562 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-03-12 Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-03-12 12:02:01 UTC --- Oops, good catch.
[Bug c/52560] if (r == -1) causes 'assuming signed overflow does not occur when simplifying conditional to constant'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52560 --- Comment #1 from jim at meyering dot net 2012-03-12 12:30:20 UTC --- Created attachment 26877 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26877 50-line reproducer
[Bug tree-optimization/46728] GCC does not generate fmadd for pow (x, 0.75)+y on powerpc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46728 --- Comment #16 from William J. Schmidt wschmidt at gcc dot gnu.org 2012-03-12 12:37:11 UTC --- (In reply to comment #15) I see this test failing on powerpc-apple-darwin8 (32b G4, ppc7400): http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg01296.html Is this specific to 64b, or should it also work for 32b ppc? It looks like these tests should be skipped for darwin. The last three failures are due to a lack of __builtin_cbrt for that target. The execution failures are due to -fpowerpc-gpopt which apparently generates an illegal instruction for that target. I'll modify these tests to add skips for powerpc*-*-darwin*.
[Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488 --- Comment #4 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-03-12 12:37:24 UTC --- Created attachment 26878 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26878 pr52488.diff Does this patch fix the ICE for you?
[Bug target/52555] [4.6/4.7 Regression] ICE unrecognizable insn with -ffast-math and __attribute__((optimize(xx)))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52555 --- Comment #1 from Roman Kononov roman at binarylife dot net 2012-03-12 12:51:20 UTC --- It broke in r165823.
[Bug libstdc++/52562] [C++11] Most type_info functions not noexcept
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52562 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-03-12 12:54:26 UTC --- Let's do this now, yes, seems straightforward.
[Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-03-12 12:55:14 UTC --- + size_max = (1 GET_MODE_BITSIZE (GET_MODE (my_fp))) - 1; + if (size = size_max) Do you have a guarantee that GET_MODE_BITSIZE here is never 32 or more? (1 GET_MODE_BITSIZE (GET_MODE (my_fp))) - 1 is GET_MODE_MASK (GET_MODE (my_fp)). And, why = ? Subtracting 255 for 8-bit fp or 65535 for 16-bit fp should still work.
[Bug target/52499] avr MODE_CODE_BASE_REG_CLASS enum conversion problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52499 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added CC||gjl at gcc dot gnu.org --- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-03-12 13:13:37 UTC --- Why are there two incompatible representations of register classes in the first place, i.e. enum reg_class and reg_class_t? for example TARGET_MEMORY_MOVE_COST TARGET_REGISTER_MOVE_COST request reg_class_t confused
[Bug preprocessor/52561] GCC is not throwing error if only one character '#' is written in a line.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52561 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-12 13:14:50 UTC --- .
[Bug libstdc++/52562] [C++11] Most type_info functions not noexcept
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52562 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Target Milestone|--- |4.7.1
[Bug target/52499] avr MODE_CODE_BASE_REG_CLASS enum conversion problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52499 --- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-03-12 13:21:25 UTC --- Created attachment 26879 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26879 pr52499.diff: tentative patch Does this patch work for you?
[Bug tree-optimization/52560] if (r == -1) causes 'assuming signed overflow does not occur when simplifying conditional to constant'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52560 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2012-03-12 Component|c |tree-optimization Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-12 13:22:32 UTC --- It certainly inlines the function, does not figures out the loop does not run and then computes n's value-range as is [0, +INF(OVF)] and thus when simplifying the return value comparison against -1 it says it assumes that n++ does not wrap. Looks ok to me, though it is all because of dead code and thus a missed VRP of some sort.
[Bug fortran/52559] [4.8 Regression] Spurious \x00 in error messages
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52559 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug target/52555] [4.6/4.7/4.8 Regression] ICE unrecognizable insn with -ffast-math and __attribute__((optimize(xx)))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52555 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.4 Summary|[4.6/4.7 Regression] ICE|[4.6/4.7/4.8 Regression] |unrecognizable insn with|ICE unrecognizable insn |-ffast-math and |with -ffast-math and |__attribute__((optimize(xx) |__attribute__((optimize(xx) |)) |))
[Bug target/52499] avr MODE_CODE_BASE_REG_CLASS enum conversion problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52499 --- Comment #3 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org 2012-03-12 13:25:38 UTC --- (In reply to comment #1) Why are there two incompatible representations of register classes in the first place, i.e. enum reg_class and reg_class_t? enum reg_class is a target specific type, thus it is not suitable for target hooks, which should have a type that is independent of any particular target.
[Bug c/52554] Variable called $1 causes invalid asm to be generated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52554 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||accepts-invalid CC||jsm28 at gcc dot gnu.org Component|target |c --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-12 13:28:05 UTC --- C does not allow an identifier to start with a dollar. But we even accept the program with -std=c99 -pedantic-errors.
[Bug libstdc++/52562] [C++11] Most type_info functions not noexcept
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52562 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2012-03-12 13:43:35 UTC --- Do I understand correctly that in N3291 the destructor lost the explicit noexcept simply because of core/1123? In that case I think that in GCC we should mark it temporarily noexcept and then remove it in mainline when c++/50043 will be addressed (I mean to work on it over the next weeks). 4_7-branch will not change anymore.
[Bug libstdc++/52562] [C++11] Most type_info functions not noexcept
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52562 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-03-12 13:50:05 UTC --- Uhm, too much has to be tweaked elsewhere if the destructor is marked noexcept. Let's leave it alone for now (c++/50043 will reconsider the issue).
[Bug c++/52553] [4.6 Regression] Internal compiler error on build Parma Polyhedra Library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52553 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-03-12 Known to work||4.5.1, 4.7.0 Target Milestone|--- |4.6.4 Summary|Internal compiler error on |[4.6 Regression] Internal |build Parma Polyhedra |compiler error on build |Library |Parma Polyhedra Library Ever Confirmed|0 |1 Known to fail||4.6.2, 4.6.3 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-12 13:56:30 UTC --- Confirmed.
[Bug testsuite/52563] New: FAIL: gcc.dg/tree-ssa/scev-[3,4].c scan-tree-dump-times optimized a 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52563 Bug #: 52563 Summary: FAIL: gcc.dg/tree-ssa/scev-[3,4].c scan-tree-dump-times optimized a 1 Classification: Unclassified Product: gcc Version: tree-ssa Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassig...@gcc.gnu.org ReportedBy: izamya...@gmail.com CC: jiangning@arm.com Target: x86_64-unknown-linux-gnu Fails appeared after revision 185129: 2012-03-09 Jiangning Liu jiangning@arm.com tree-scalar-evolution (interpret_rhs_expr): generate chrec for array reference and component reference. (analyze_scalar_evolution_for_address_of): New. 2012-03-09 Jiangning Liu jiangning@arm.com gcc.dg/tree-ssa/scev-3.c: New. gcc.dg/tree-ssa/scev-4.c: New. Probably some simple misprint in tests - there are 2 a in dumps...
[Bug testsuite/52563] FAIL: gcc.dg/tree-ssa/scev-[3,4].c scan-tree-dump-times optimized a 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52563 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Target|x86_64-unknown-linux-gnu|x86_64-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2012-03-12 Ever Confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-03-12 14:00:49 UTC --- Also seen on x86_64-apple-darwin10 with -m64.
[Bug c/52549] [4.8 Regression] ice in pointer_diff
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52549 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-03-12 Target Milestone|--- |4.8.0 Summary|ice in pointer_diff |[4.8 Regression] ice in ||pointer_diff Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-12 14:01:55 UTC --- Confirmed.
[Bug tree-optimization/52548] missed PRE optimization when function call follows to-be hoisted variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52548 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-12 14:02:59 UTC --- As discussed, EXP_GEN can be cleaned from invalid mems at generation time, mem-cleaning should happen separately from clean (), and applied to ANTIC_OUT instead. Mine for now, but don't hold your breath.
[Bug libstdc++/52562] [C++11] Most type_info functions not noexcept
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52562 --- Comment #5 from Daniel Krügler daniel.kruegler at googlemail dot com 2012-03-12 14:06:51 UTC --- (In reply to comment #3) Do I understand correctly that in N3291 the destructor lost the explicit noexcept simply because of core/1123? I don't know for the reason in the stdlib++ change, but the library removed all explicit throw()/noexcept() specifications on destructors replacing it by the single general rule of [res.on.exception.handling] p4: Every destructor in the C++ standard library shall behave as if it had a non-throwing exception specification. which was introduced during noexcept-ification.
[Bug middle-end/52547] Internal compiler Error in create_tmp_var in gimplify.c:465
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52547 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-03-12 CC||jakub at gcc dot gnu.org Ever Confirmed|0 |1 Known to fail||4.4.0, 4.6.3, 4.7.0 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-12 14:07:03 UTC --- src/stinger-utils.c:440:7: warning: ISO C forbids nested functions [-pedantic] so the testcase is probably out-of-scope for OpenMP. Didn't ever work, so no regression.
[Bug c++/52536] internal compiler error: Illegal instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52536 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-12 14:08:42 UTC --- Please try with at least GC 4.4.6.
[Bug c/52534] gcc doesn't detect incorrect expression in call to va_start
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52534 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||accepts-invalid Status|UNCONFIRMED |NEW Last reconfirmed||2012-03-12 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-12 14:10:12 UTC --- Confirmed.
[Bug target/52530] [4.8 regression] Many 64-bit execution failures on Solaris 10/11 with Sun as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52530 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #11 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-12 14:11:18 UTC --- Fixed.
[Bug rtl-optimization/52528] combine bug (powerpc testcase)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52528 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-12 14:14:14 UTC --- Fixed.
[Bug c++/52527] When using '-g', get an ICE: seg fault in add_name_attribute (called by modified_type_die)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52527 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-03-12 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-12 14:14:59 UTC --- Waiting for a testcase.
[Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488 --- Comment #6 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-03-12 14:15:48 UTC --- (In reply to comment #5) + size_max = (1 GET_MODE_BITSIZE (GET_MODE (my_fp))) - 1; + if (size = size_max) Do you have a guarantee that GET_MODE_BITSIZE here is never 32 or more? Yes, Pmode is HImode is 16 bits. For 8-bit SP targets only the lower 8 bits of the SP hard register are changed which saves some bytes of code and avoids writing the SP_H register which is not present on these devices. For teh latter case, mode is QImode. (1 GET_MODE_BITSIZE (GET_MODE (my_fp))) - 1 is GET_MODE_MASK (GET_MODE (my_fp)). Not exactly; the latter is unsigned. And, why = ? Subtracting 255 for 8-bit fp or 65535 for 16-bit fp should still work. This line saturates to 255 instead of to 256 because the next line effectively does size = size % 256 which would yield size = 0 for specific values. This lead to yet another ICE because it results in SP = SP insn which does not exist. I tried to keep the change minimal. Therefore, the patch uses 255 instead of 256. As of the hardware layout of these small devices, there is already some margin for sane memory sizes resp. SP offsets: The device in question has a RAM of 128 bytes located at 0x60..0xbf. The next bigger devices have 256 bytes of RAM located at 0x60..0x15f and RAM crosses the 0x100 border so that these devices use a 16-bit SP. My intention was to be conservative and not to put too much effort and changes to support insane code that definitely breaks if executed. avr-gcc 4.7 implements PR51345 which result in new multilib variants for tiny devices with only 8-bit SP. newlib derives its build configury from -print-multi-directory or whatever and tries to build insane code with 2050 bytes of stack for device(s) with only 128 bytes of RAM.
[Bug middle-end/52525] compiler segmentation fault when building OpenMP code with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52525 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-12 14:16:00 UTC --- As the last 4.4.x release is nearly complete and the branch is then closed marking as fixed in 4.5.
[Bug testsuite/52563] FAIL: gcc.dg/tree-ssa/scev-[3,4].c scan-tree-dump-times optimized a 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52563 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-12 14:19:58 UTC --- We now perform store motion for the address computation as expected. The question is what the testcase was for (I suppose final-value-replacement non-optimization) and eventually disable lim on them.
[Bug c/52554] Variable called $1 causes invalid asm to be generated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52554 --- Comment #2 from Andreas Schwab sch...@linux-m68k.org 2012-03-12 14:22:00 UTC --- 6.4.2.1 says that an identifier may contain other implementation-defined characters.
[Bug gcov-profile/49484] gcov crash if two(or more) forks happen at the same time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49484 --- Comment #14 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-12 14:23:32 UTC --- Author: rguenth Date: Mon Mar 12 14:23:27 2012 New Revision: 185231 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185231 Log: 2012-03-12 Richard Guenther rguent...@suse.de * gthr.h (__GTHREAD_MUTEX_INIT_FUNCTION): Adjust specification. * gthr-posix.h (__GTHREAD_MUTEX_INIT_FUNCTION): Define. (__gthread_mutex_init_function): New function. * gthr-single.h (__GTHREAD_MUTEX_INIT_FUNCTION): Define. PR gcov/49484 * libgcov.c: Include gthr.h. (__gcov_flush_mx): New global variable. (init_mx, init_mx_once): New functions. (__gcov_flush): Protect self with a mutex. (__gcov_fork): Re-initialize mutex after forking. * unwind-dw2-fde.c: Change condition under which to use __GTHREAD_MUTEX_INIT_FUNCTION. Modified: trunk/libgcc/ChangeLog trunk/libgcc/gthr-posix.h trunk/libgcc/gthr-single.h trunk/libgcc/gthr.h trunk/libgcc/libgcov.c trunk/libgcc/unwind-dw2-fde.c
[Bug gcov-profile/49484] gcov crash if two(or more) forks happen at the same time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49484 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #15 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-12 14:25:08 UTC --- Fixed for GCC 4.8.
[Bug fortran/52564] New: Accepts invalid: Missing I/O list after comma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52564 Bug #: 52564 Summary: Accepts invalid: Missing I/O list after comma Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: w...@earthlink.net In the following test case, gfortran does not diagnose the missing I/O list after the comma in the print statement: program printbug print *, 'hello world' ! the following line should not compile: print *, end program Other compilers do diagnose it. First noticed on 4.6.1, but is also a problem with 4.8 snapshot.
[Bug fortran/52564] Accepts invalid: Missing I/O list after comma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52564
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||accepts-invalid, diagnostic
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-03-12
CC||burnus at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-03-12
14:39:18 UTC ---
Confirm. I tried 5 other compilers and all (but g95) report unconditionally an
error.
From the standard:
R912 print-stmt is PRINT format [ , output-item-list ]
Thus, without the comma, i.e.
PRINT *
the program is valid.
* * *
From io.c:
match_io (io_kind k)
...
get_io_list:
...
if (gfc_match_eos () != MATCH_YES)
{
if (comma_flag gfc_match_char (',') != MATCH_YES)
...
m = match_io_list (k, io_code);
if (m == MATCH_ERROR)
goto cleanup;
if (m == MATCH_NO)
goto syntax;
If one looks at match_io_list, one finds:
if (gfc_match_eos () == MATCH_YES)
return MATCH_YES;
[Bug c++/52558] write introduction incorrect wrt the C++11 memory model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52558 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-03-12 CC||aldyh at gcc dot gnu.org, ||amacleod at redhat dot com, ||rguenth at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-03-12 14:52:57 UTC --- Richi, is this something that should also be fixed for 4.7 as well? There is a write to g_2 that is introduced on paths that did not have it. So this is not just a load/load data race.
[Bug gcov-profile/49484] gcov crash if two(or more) forks happen at the same time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49484 --- Comment #16 from Jonathan Wakely redi at gcc dot gnu.org 2012-03-12 15:00:46 UTC --- If a target defines _GTHREAD_USE_MUTEX_INIT_FUNC in lisbtdc++-v3/config/os/.../os_defines.h then following this patch line 80 in gthr-posix.h will redefine __GTHREAD_MUTEX_INIT_FUNCTION and there will be two conflicting definitions of __gthread_mutex_init_function on lines 749 and 757
[Bug c++/52558] write introduction incorrect wrt the C++11 memory model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52558 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-12 15:01:36 UTC --- (In reply to comment #1) Richi, is this something that should also be fixed for 4.7 as well? There is a write to g_2 that is introduced on paths that did not have it. So this is not just a load/load data race. No, we don't want to fix this for 4.7 as this is not a regression. Yes, LIM only avoids introducing traps, not data-races. This was discussed in the past already, btw, and we do not want to generally disallow this optimization. [The C++ memory model is stupid here, it should not treat every variable raceable but only specially marked ones, oh well ...] There will be very many other passes that are affected by this, and even more very many passes that will be affected by load data-races. You will for example slow down SPEC CPU 2006 quite a bit (though technically it does not include C++11 benchmarks).
[Bug libstdc++/52562] [C++11] Most type_info functions not noexcept
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52562 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2012-03-12 15:02:51 UTC --- To clarify, nothing ever changed in libstdc++ as far as the type_info destructor is concerned. That said, I'm not sure to fully understand why we have the as-if in p4, or, in other terms, what it does add *beyond* core/1123.
[Bug c++/52565] New: __builtin_va_arg(va, double); may fall on cortex-m3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52565
Bug #: 52565
Summary: __builtin_va_arg(va, double); may fall on cortex-m3
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ramon.zambe...@bluewin.ch
Created attachment 26880
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26880
source and full outputs
Compiling this:
extern double vargTest(const char* format, ...);
#include stdarg.h
int main(void) {
vargTest(%f, (double) 1.23456);
while (1)
;
}
double vargTest(const char* format, ...) {
__gnuc_va_list vaList;
__builtin_va_start(vaList, format);
double value = __builtin_va_arg(vaList, double);
return value;
}
void _exit(){
}
Produces:
80d8 main:
80d8:b580 push{r7, lr}
80da:af00 addr7, sp, #0
80dc:f248 4008 movwr0, #33800; 0x8408
80e0:f2c0 movtr0, #0
80e4:a302 addr3, pc, #8; (adr r3, 80f0 main+0x18)
80e6:e9d3 2300 ldrdr2, r3, [r3]
80ea:f000 f805 bl80f8 vargTest
80ee:e7fe b.n80ee main+0x16
80f0:fc8f3238 .word0xfc8f3238
80f4:3ff3c0c1 .word0x3ff3c0c1
80f8 vargTest:
80f8:b40f push{r0, r1, r2, r3}
80fa:b480 push{r7}
80fc:b085 subsp, #20
80fe:af00 addr7, sp, #0
8100:f107 031c add.wr3, r7, #28
8104:607b strr3, [r7, #4]
8106:687b ldrr3, [r7, #4]
8108:f103 0307 add.wr3, r3, #7
810c:f023 0307 bic.wr3, r3, #7
8110:f103 0208 add.wr2, r3, #8
8114:607a strr2, [r7, #4]
8116:e9d3 2300 ldrdr2, r3, [r3]
811a:e9c7 2302 strdr2, r3, [r7, #8]
811e:e9d7 2302 ldrdr2, r3, [r7, #8]
8122:4610 movr0, r2
8124:4619 movr1, r3
8126:f107 0714 add.wr7, r7, #20
812a:46bd movsp, r7
812c:bc80 pop{r7}
812e:b004 addsp, #16
8130:4770 bxlr
8132:bf00 nop
The instruction at 0x810c forces the address used for the ldrd to be alligned
to an 8 bytes boundary. The problem is that the double parameter is passed on
register r2-r3 and pushed on the stack at the entry point of vargTest
function. Since the stack is aligned on 4 bytes boundary only the double value
may be misaligned and as a consequence the __builtin_va_arg(vaList, double)
function fails to retrive the correct value.
Is this a bug?
[Bug gcov-profile/49484] gcov crash if two(or more) forks happen at the same time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49484 --- Comment #17 from Jonathan Wakely redi at gcc dot gnu.org 2012-03-12 15:06:52 UTC --- (In reply to comment #16) If a target defines _GTHREAD_USE_MUTEX_INIT_FUNC in e.g. this will break Tru64 (until Rainer removes support for it) http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/config/os/osf/os_defines.h?view=markuppathrev=184108
[Bug gcov-profile/49484] gcov crash if two(or more) forks happen at the same time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49484 --- Comment #18 from Jonathan Wakely redi at gcc dot gnu.org 2012-03-12 15:10:29 UTC --- Also, gthr.h says the signature should be: void __GTHREAD_MUTEX_INIT_FUNCTION (__gthread_mutex_t *)
[Bug libstdc++/52562] [C++11] Most type_info functions not noexcept
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52562 --- Comment #7 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2012-03-12 15:12:47 UTC --- Author: paolo Date: Mon Mar 12 15:12:40 2012 New Revision: 185235 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185235 Log: 2012-03-12 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/52562 * libsupc++/typeinfo (type_info::name, before, operator==, operator!=): Mark noexcept in C++11 mode. * libsupc++/tinfo.cc (type_info::operator==): Adjust. * libsupc++/tinfo2.cc (type_info::before): Likewise. * testsuite/18_support/type_info/52562.cc: New. Added: trunk/libstdc++-v3/testsuite/18_support/type_info/52562.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/libsupc++/tinfo.cc trunk/libstdc++-v3/libsupc++/tinfo2.cc trunk/libstdc++-v3/libsupc++/typeinfo
[Bug c++/52558] write introduction incorrect wrt the C++11 memory model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52558 --- Comment #3 from Andrew Macleod amacleod at redhat dot com 2012-03-12 15:24:35 UTC --- Created attachment 26881 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26881 Testcase for simulate-threads I've modified the testcase so that it runs in gcc.dg/simulate-thread as a pass/fail. Clearly it currently fails, although its interesting because at -O3 it passes again!! The second pass of DOM undoes the extra write! It does fail the testsuite at -O2 as expected. This diff can be applied to add it to simulate threads.
[Bug gcov-profile/49484] gcov crash if two(or more) forks happen at the same time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49484 --- Comment #19 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-12 15:27:46 UTC --- (In reply to comment #18) Also, gthr.h says the signature should be: void __GTHREAD_MUTEX_INIT_FUNCTION (__gthread_mutex_t *) I don't understand this? The current define is pre-existing #ifdef _GTHREAD_USE_MUTEX_INIT_FUNC # undef __GTHREAD_MUTEX_INIT # define __GTHREAD_MUTEX_INIT_FUNCTION __gthread_mutex_init_function #endif I suppose it simply forgets to undef __GTHREAD_MUTEX_INIT_FUNCTION like the _GTHREAD_USE_RECURSIVE_MUTEX_INIT_FUNC does. I have no access to the weird platforms (but asked for help three month ago and again a week ago). Please open new bugs for issues you spot. Btw, the gthr-posix.h path with _GTHREAD_USE_MUTEX_INIT_FUNC could have never worked as there was no __gthread_mutex_init_function available in gthr-posix.h. Or how was that supposed to work?
[Bug c++/52558] write introduction incorrect wrt the C++11 memory model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52558 --- Comment #4 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-03-12 15:29:06 UTC --- No, we don't want to fix this for 4.7 as this is not a regression. Yes, LIM only avoids introducing traps, not data-races. This was discussed in the past already, btw, and we do not want to generally disallow this optimization. [The C++ memory model is stupid here, it should not treat every variable raceable but only specially marked ones, oh well ...] There will be very many other passes that are affected by this, and even more very many passes that will be affected by load data-races. You will for example slow down SPEC CPU 2006 quite a bit (though technically it does not include C++11 benchmarks). I thought we ignored *load* data races, but still cared about introducing write data races. This test case has both. I don't understand why we would allow introducing writes on paths that did not have it, but I will defer to you.
[Bug c++/52558] write introduction incorrect wrt the C++11 memory model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52558 --- Comment #5 from rguenther at suse dot de rguenther at suse dot de 2012-03-12 15:32:48 UTC --- On Mon, 12 Mar 2012, aldyh at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52558 --- Comment #4 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-03-12 15:29:06 UTC --- No, we don't want to fix this for 4.7 as this is not a regression. Yes, LIM only avoids introducing traps, not data-races. This was discussed in the past already, btw, and we do not want to generally disallow this optimization. [The C++ memory model is stupid here, it should not treat every variable raceable but only specially marked ones, oh well ...] There will be very many other passes that are affected by this, and even more very many passes that will be affected by load data-races. You will for example slow down SPEC CPU 2006 quite a bit (though technically it does not include C++11 benchmarks). I thought we ignored *load* data races, but still cared about introducing write data races. This test case has both. I don't understand why we would allow introducing writes on paths that did not have it, but I will defer to you. Why should we avoid them if we know they cannot cause problems? This will happen for every loop where we do not know if it iterates at least once. Store-motion is a very important optimization. Richard.
[Bug middle-end/52450] FAIL: gcc.dg/torture/pr52402.c at -O1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52450 --- Comment #9 from John David Anglin danglin at gcc dot gnu.org 2012-03-12 15:33:38 UTC --- Author: danglin Date: Mon Mar 12 15:33:32 2012 New Revision: 185239 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185239 Log: PR target/52450 * gcc.dg/torture/pr52402.c: Skip execution on 32-bit hppa*-*-hpux*. Modified: branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr52402.c
[Bug c++/52558] write introduction incorrect wrt the C++11 memory model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52558 --- Comment #6 from Aldy Hernandez aldyh at redhat dot com 2012-03-12 15:42:45 UTC --- On 03/12/12 10:32, rguenther at suse dot de wrote: es, but still cared about introducing write data races. This test case has both. I don't understand why we would allow introducing writes on paths that did not have it, but I will defer to you. Why should we avoid them if we know they cannot cause problems? This will happen for every loop where we do not know if it iterates at least once. Store-motion is a very important optimization. Richard. They won't cause problems in a single threaded environment, but will cause problems in a multi threaded environment. Even if you're writing the value g_2 originally had, another thread may have written to g_2 right before. Just to get this straight, am I to assume that the default code generation for GCC is a single threaded environment? I just want to make sure I get these variants right in my head, and can properly separate what is and is not allowed in default GCC, and what only pertains to the C11 memory model (or transactional stuff). Thanks.
[Bug c++/52558] write introduction incorrect wrt the C++11 memory model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52558 --- Comment #7 from rguenther at suse dot de rguenther at suse dot de 2012-03-12 15:45:39 UTC --- On Mon, 12 Mar 2012, aldyh at redhat dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52558 --- Comment #6 from Aldy Hernandez aldyh at redhat dot com 2012-03-12 15:42:45 UTC --- On 03/12/12 10:32, rguenther at suse dot de wrote: es, but still cared about introducing write data races. This test case has both. I don't understand why we would allow introducing writes on paths that did not have it, but I will defer to you. Why should we avoid them if we know they cannot cause problems? This will happen for every loop where we do not know if it iterates at least once. Store-motion is a very important optimization. Richard. They won't cause problems in a single threaded environment, but will cause problems in a multi threaded environment. Even if you're writing the value g_2 originally had, another thread may have written to g_2 right before. Yes, that's clear to me. Just to get this straight, am I to assume that the default code generation for GCC is a single threaded environment? I just want to make sure I get these variants right in my head, and can properly separate what is and is not allowed in default GCC, and what only pertains to the C11 memory model (or transactional stuff). It certainly is, though we are getting more careful about this stuff in recent years and generally only read data-races are ok. Richard.
[Bug libstdc++/52562] [C++11] Most type_info functions not noexcept
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52562 --- Comment #8 from Daniel Krügler daniel.kruegler at googlemail dot com 2012-03-12 15:46:42 UTC --- (In reply to comment #6) There exists a compiler problem with noexcept and non-trivial destructor declarations as described in bug 50043 and in bug 51295. This fix should automagically ensure that std::type_infos destructor get's an assumed noexcept(true) exception specification. The additional library wording exists to ensure that independent of any implied destructor exception specification of base classes or members of library internals all destructors of library types needs to behave as noexcept. But given the current definition of std::type_info there is no reason why an explicit noexcept(true) specification should be required.
[Bug c++/52558] write introduction incorrect wrt the C++11 memory model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52558 --- Comment #8 from Andrew Macleod amacleod at redhat dot com 2012-03-12 15:50:13 UTC --- We can still perform store motion out of a loop, we just can't put the store on a path which is executed if the loop isn't executed. In this case, we actually made the code *slower*. Before LIM, there was a load of g1, a compare and return. movlg_1(%rip), %edx xorl%eax, %eax testl %edx, %edx jne .L1 .L4: addl$1, %eax movl$0, g_2(%rip) cmpl$4, %eax jne .L4 .L1: rep ret LIM makes it have a load of g_1, a load of g_2 and a store to g_2 before returning. .cfi_startproc movlg_1(%rip), %edx movlg_2(%rip), %eax testl %edx, %edx jne .L2 movl$0, g_2(%rip) ret .L2: movl%eax, g_2(%rip) xorl%eax, %eax ret -O3 corrects this mistake and returns it to the more optimal results. I would argue this testcase shows LIM actually making the code worse in this case as well.
[Bug gcov-profile/49484] gcov crash if two(or more) forks happen at the same time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49484 --- Comment #20 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-12 15:52:34 UTC --- I suppose Index: libgcc/gthr-posix.h === --- libgcc/gthr-posix.h (revision 185232) +++ libgcc/gthr-posix.h (working copy) @@ -77,7 +77,6 @@ typedef struct timespec __gthread_time_t #ifdef _GTHREAD_USE_MUTEX_INIT_FUNC # undef __GTHREAD_MUTEX_INIT -# define __GTHREAD_MUTEX_INIT_FUNCTION __gthread_mutex_init_function #endif #ifdef _GTHREAD_USE_RECURSIVE_MUTEX_INIT_FUNC # undef __GTHREAD_RECURSIVE_MUTEX_INIT would fix it?
[Bug gcov-profile/49484] gcov crash if two(or more) forks happen at the same time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49484 --- Comment #21 from Jonathan Wakely redi at gcc dot gnu.org 2012-03-12 15:54:46 UTC --- (In reply to comment #19) (In reply to comment #18) Also, gthr.h says the signature should be: void __GTHREAD_MUTEX_INIT_FUNCTION (__gthread_mutex_t *) I don't understand this? The current define is pre-existing #ifdef _GTHREAD_USE_MUTEX_INIT_FUNC # undef __GTHREAD_MUTEX_INIT # define __GTHREAD_MUTEX_INIT_FUNCTION __gthread_mutex_init_function #endif I suppose it simply forgets to undef __GTHREAD_MUTEX_INIT_FUNCTION like the _GTHREAD_USE_RECURSIVE_MUTEX_INIT_FUNC does. No, that was intentional. Before your commit gthr-posix.h never defined __GTHREAD_MUTEX_INIT_FUNCTION (because all POSIX targets define PTHREAD_MUTEX_INITIALIZER) so there was no need to undef it. However, gthr-posix.h sometimes defines __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION (because not all POSIX targets provide PTHREAD_RECURSIVE_MUTEX_INITIALIZER) so I needed to undef it before (re-)defining it. I could have alternatively done: #ifndef __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION #define __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION ... #endif But I chose to just #undef it then #define it. I have no access to the weird platforms (but asked for help three month ago and again a week ago). Yes, sorry, I don't subscribe to gcc-patches so only saw it when the change was committed. Please open new bugs for issues you spot. OK, will do. Btw, the gthr-posix.h path with _GTHREAD_USE_MUTEX_INIT_FUNC could have never worked as there was no __gthread_mutex_init_function available in gthr-posix.h. Or how was that supposed to work? I added __gthread_mutex_init_function, that's why it's there twice now. Your patch added another copy of it right below mine! But my change was only made a month ago: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183955 So when you first prepared your patch it was correct. Now it's not.
[Bug c++/52558] write introduction incorrect wrt the C++11 memory model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52558 --- Comment #10 from Aldy Hernandez aldyh at redhat dot com 2012-03-12 15:56:30 UTC --- On 03/12/12 10:45, rguenther at suse dot de wrote: Just to get this straight, am I to assume that the default code generation for GCC is a single threaded environment? I just want to make sure I get these variants right in my head, and can properly separate what is and is not allowed in default GCC, and what only pertains to the C11 memory model (or transactional stuff). It certainly is, though we are getting more careful about this stuff in recent years and generally only read data-races are ok. Richard. Ah, ok. Now it's clear. I was confused because in a previous thread months ago you had mentioned that read data-races were ok, but write data-races were not, whereas here we are even allowing write data races. Understood. Thanks.
[Bug c++/52558] write introduction incorrect wrt the C++11 memory model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52558 --- Comment #9 from rguenther at suse dot de rguenther at suse dot de 2012-03-12 15:55:27 UTC --- On Mon, 12 Mar 2012, amacleod at redhat dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52558 --- Comment #8 from Andrew Macleod amacleod at redhat dot com 2012-03-12 15:50:13 UTC --- We can still perform store motion out of a loop, we just can't put the store on a path which is executed if the loop isn't executed. In this case, we actually made the code *slower*. Before LIM, there was a load of g1, a compare and return. movlg_1(%rip), %edx xorl%eax, %eax testl %edx, %edx jne .L1 .L4: addl$1, %eax movl$0, g_2(%rip) cmpl$4, %eax jne .L4 .L1: rep ret LIM makes it have a load of g_1, a load of g_2 and a store to g_2 before returning. .cfi_startproc movlg_1(%rip), %edx movlg_2(%rip), %eax testl %edx, %edx jne .L2 movl$0, g_2(%rip) ret .L2: movl%eax, g_2(%rip) xorl%eax, %eax ret -O3 corrects this mistake and returns it to the more optimal results. I would argue this testcase shows LIM actually making the code worse in this case as well. Usually loops are executed ;) At least that is what we assume if we don't know better. But yes, splitting the exit block(s) is a solution, so, if you fix this please go this way. Richard.
[Bug gcov-profile/49484] gcov crash if two(or more) forks happen at the same time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49484 --- Comment #22 from Jonathan Wakely redi at gcc dot gnu.org 2012-03-12 15:56:07 UTC --- (In reply to comment #20) I suppose Index: libgcc/gthr-posix.h === --- libgcc/gthr-posix.h (revision 185232) +++ libgcc/gthr-posix.h (working copy) @@ -77,7 +77,6 @@ typedef struct timespec __gthread_time_t #ifdef _GTHREAD_USE_MUTEX_INIT_FUNC # undef __GTHREAD_MUTEX_INIT -# define __GTHREAD_MUTEX_INIT_FUNCTION __gthread_mutex_init_function #endif #ifdef _GTHREAD_USE_RECURSIVE_MUTEX_INIT_FUNC # undef __GTHREAD_RECURSIVE_MUTEX_INIT would fix it? That fixes half the problem, then there's still the duplicate __gthread_mutex_init_function on line 749. That should be defined unconditionally, but according to the spec in gthr.h should return void
[Bug gcov-profile/49484] gcov crash if two(or more) forks happen at the same time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49484 --- Comment #23 from rguenther at suse dot de rguenther at suse dot de 2012-03-12 16:02:34 UTC --- On Mon, 12 Mar 2012, redi at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49484 --- Comment #22 from Jonathan Wakely redi at gcc dot gnu.org 2012-03-12 15:56:07 UTC --- (In reply to comment #20) I suppose Index: libgcc/gthr-posix.h === --- libgcc/gthr-posix.h (revision 185232) +++ libgcc/gthr-posix.h (working copy) @@ -77,7 +77,6 @@ typedef struct timespec __gthread_time_t #ifdef _GTHREAD_USE_MUTEX_INIT_FUNC # undef __GTHREAD_MUTEX_INIT -# define __GTHREAD_MUTEX_INIT_FUNCTION __gthread_mutex_init_function #endif #ifdef _GTHREAD_USE_RECURSIVE_MUTEX_INIT_FUNC # undef __GTHREAD_RECURSIVE_MUTEX_INIT would fix it? That fixes half the problem, then there's still the duplicate __gthread_mutex_init_function on line 749. That should be defined unconditionally, but according to the spec in gthr.h should return void Darn... I'm preparing a patch for testing overnight (if you beat me to it, the obvious patch is pre-approved, removing my copy of __gthread_mutex_init_function and making yours defined unconditionally). Richard.
[Bug libstdc++/52562] [C++11] Most type_info functions not noexcept
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52562 --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com 2012-03-12 16:09:25 UTC --- Ok, ok, so everything boils down to 50043, as I thought.
[Bug preprocessor/52566] New: #include in c++ namespace scope doesn't work properly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52566
Bug #: 52566
Summary: #include in c++ namespace scope doesn't work properly
Classification: Unclassified
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: shi...@gmail.com
# gcc --version
gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
3 source files: ns1.h ns2.h test.cpp
-
ns1.h:
#pragma once
class A
{
};
-
ns2.h:
#pragma once
class A
{
};
-
test.cpp:
namespace NS1
{
#include ns1.h
}
namespace NS2
{
#include ns2.h
}
int main()
{
NS2::A a;
return 0;
}
-
# touch * // important step, let ns1.h and ns2.h have same modification time
# gcc test.cpp
test.cpp: In function 'int main()':
test.cpp:11: error: 'A' is not a member of 'NS2'
test.cpp:11: error: expected ';' before 'a'
# gcc -c -E test.cpp
# 1 test.cpp
# 1 built-in
# 1 command-line
# 1 test.cpp
namespace NS1
{
# 1 ns1.h 1
class A
{
};
# 4 test.cpp 2
}
namespace NS2
{
}
int main()
{
NS2::A a;
return 0;
}
The NS2::A declaration isn't included in namespace NS2
[Bug tree-optimization/52560] if (r == -1) causes 'assuming signed overflow does not occur when simplifying conditional to constant'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52560 --- Comment #3 from Richard W.M. Jones rjones at redhat dot com 2012-03-12 16:30:45 UTC --- I see that this is actually a bug in our code. I pushed the following fix to libguestfs: https://github.com/libguestfs/libguestfs/commit/d66dd2260c724bdfe57a8595aac37c8e9173cee5
[Bug preprocessor/52566] #include in c++ namespace scope doesn't work properly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52566 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-03-12 16:30:32 UTC --- this has nothing to do with namespace scope, it's #pragma once confusing two separate files as one
[Bug c++/50594] Option -fwhole-program discards replaced new operator for std::string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50594 David Fang fang at csl dot cornell.edu changed: What|Removed |Added CC||fang at csl dot cornell.edu --- Comment #25 from David Fang fang at csl dot cornell.edu 2012-03-12 16:31:03 UTC --- Seeing this failing on powerpc-darwin8. http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg01296.html Log shows failed assertion: Executing on host: /Volumes/Isolde/fink.build/gcc47-4.7.0-0.rc1.1/darwin_objdir/./gcc/g++ -shared-libgcc -B/Volumes/Isolde/fink.build/gcc47-4.7.0-0.rc1.1/darwin_objdir/./gcc -nostdinc++ -L/Volumes/Isolde/fink.build/gcc47-4.7.0-0.rc1.1/darwin_objdir/powerpc-apple-darwin8.11.0/libstdc++-v3/src -L/Volumes/Isolde/fink.build/gcc47-4.7.0-0.rc1.1/darwin_objdir/powerpc-apple-darwin8.11.0/libstdc++-v3/src/.libs -B/sw/lib/gcc4.7/powerpc-apple-darwin8.11.0/bin/ -B/sw/lib/gcc4.7/powerpc-apple-darwin8.11.0/lib/ -isystem /sw/lib/gcc4.7/powerpc-apple-darwin8.11.0/include -isystem /sw/lib/gcc4.7/powerpc-apple-darwin8.11.0/sys-include -B/Volumes/Isolde/fink.build/gcc47-4.7.0-0.rc1.1/darwin_objdir/powerpc-apple-darwin8.11.0/./libstdc++-v3/src/.libs -g -O2 -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2 -g -O2 -DLOCALEDIR=. -nostdinc++ -I/Volumes/Isolde/fink.build/gcc47-4.7.0-0.rc1.1/darwin_objdir/powerpc-apple-darwin8.11.0/libstdc++-v3/include/powerpc-apple-darwin8.11.0 -I/Volumes/Isolde/fink.build/gcc47-4.7.0-0.rc1.1/darwin_objdir/powerpc-apple-darwin8.11.0/libstdc++-v3/include -I/Volumes/Isolde/fink.build/gcc47-4.7.0-0.rc1.1/gcc-4.7.0-RC-20120302/libstdc++-v3/libsupc++ -I/Volumes/Isolde/fink.build/gcc47-4.7.0-0.rc1.1/gcc-4.7.0-RC-20120302/libstdc++-v3/include/backward -I/Volumes/Isolde/fink.build/gcc47-4.7.0-0.rc1.1/gcc-4.7.0-RC-20120302/libstdc++-v3/testsuite/util /Volumes/Isolde/fink.build/gcc47-4.7.0-0.rc1.1/gcc-4.7.0-RC-20120302/libstdc++-v3/testsuite/18_support/50594.cc -fwhole-program ./libtestc++.a -L/sw/lib -liconv -lm -o ./50594.exe (timeout = 600) PASS: 18_support/50594.cc (test for excess errors) Setting LD_LIBRARY_PATH to :/Volumes/Isolde/fink.build/gcc47-4.7.0-0.rc1.1/darwin_objdir/gcc:/Volumes/Isolde/fink.build/gcc47-4.7.0-0.rc1.1/darwin_objdir/powerpc-apple-darwin8.11.0/./libstdc++-v3/../libgomp/.libs:/Volumes/Isolde/fink.build/gcc47-4.7.0-0.rc1.1/darwin_objdir/powerpc-apple-darwin8.11.0/./libstdc++-v3/src/.libs::/Volumes/Isolde/fink.build/gcc47-4.7.0-0.rc1.1/darwin_objdir/gcc:/Volumes/Isolde/fink.build/gcc47-4.7.0-0.rc1.1/darwin_objdir/powerpc-apple-darwin8.11.0/./libstdc++-v3/../libgomp/.libs:/Volumes/Isolde/fink.build/gcc47-4.7.0-0.rc1.1/darwin_objdir/powerpc-apple-darwin8.11.0/./libstdc++-v3/src/.libs /Volumes/Isolde/fink.build/gcc47-4.7.0-0.rc1.1/gcc-4.7.0-RC-20120302/libstdc++-v3/testsuite/18_support/50594.cc:64: failed assertion `user_new_called' FAIL: 18_support/50594.cc execution test
[Bug c++/52299] GCC warns on compile time division by zero erroneously
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52299 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Target Milestone|--- |4.8.0 --- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com 2012-03-12 16:59:20 UTC --- On it.
[Bug target/51871] FAIL: gcc.c-torture/execute/20010122-1.c execution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51871 --- Comment #8 from John David Anglin danglin at gcc dot gnu.org 2012-03-12 17:00:18 UTC --- Author: danglin Date: Mon Mar 12 17:00:01 2012 New Revision: 185251 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185251 Log: Backport for mainline 2012-01-28 John David Anglin dave.ang...@nrc-cnrc.gc.ca PR target/51871 * config/pa/pa.c (pa_return_addr_rtx): Add support for PA2.0 export stubs. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/pa/pa.c
[Bug middle-end/50232] [4.7 Regression] reorg.c:3971: undefined reference to `make_return_insns'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50232 --- Comment #9 from John David Anglin danglin at gcc dot gnu.org 2012-03-12 17:08:28 UTC --- Author: danglin Date: Mon Mar 12 17:08:20 2012 New Revision: 185252 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185252 Log: Backport from mainline 2011-09-03 John David Anglin dave.ang...@nrc-cnrc.gc.ca PR Bug middle-end/50232 * config/pa/pa.md (return): Define return insn pattern. (epilogue): Use it when no epilogue is needed. * config/pa/pa.c (pa_can_use_return_insn): New function. * config/pa/pa-protos.h (pa_can_use_return_insn): Declare. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/pa/pa-protos.h branches/gcc-4_6-branch/gcc/config/pa/pa.c branches/gcc-4_6-branch/gcc/config/pa/pa.md
[Bug preprocessor/52566] #include in c++ namespace scope doesn't work properly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52566 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-03-12 17:09:37 UTC --- You either should have different content of the two headers, or don't use #pragma once, or you need to have different timestamps. In order to support symlinks/hardlinks and also lame filesystems that lack them, the preprocessor only looks at file sizes/timestamps and content if there are multiple #pragma once (or #import) headers.
[Bug target/52555] [4.6/4.7/4.8 Regression] ICE unrecognizable insn with -ffast-math and __attribute__((optimize(xx)))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52555 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added CC||jsm28 at gcc dot gnu.org --- Comment #2 from Uros Bizjak ubizjak at gmail dot com 2012-03-12 17:11:35 UTC --- (In reply to comment #1) It broke in r165823. Author: jsm28 Date: Fri Oct 22 12:14:45 2010 New Revision: 165823 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165823 Log: * target.h (enum opt_levels, struct default_options): New. * target.def (handle_ofast): Remove hook. (target_option.optimization): Change to target_option.optimization_table. ... Adding CC.
[Bug rtl-optimization/52148] [4.7 regression] ICE: in spill_failure, at reload1.c:2120
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52148 --- Comment #5 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-03-12 17:35:48 UTC --- Author: gjl Date: Mon Mar 12 17:35:43 2012 New Revision: 185253 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185253 Log: PR target/52148 * config/avr/avr.c (avr_out_movmem): Fix typo in output template for the case ADDR_SPACE_FLASH and AVR_HAVE_LPMX introduced in r184615 from 2012-02-28. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.c
[Bug c++/52567] New: constant expression not recognized as being constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52567
Bug #: 52567
Summary: constant expression not recognized as being constant
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: l_be...@yahoo.com
when trying to compile the following simple c++ code fragment, gcc gives error
error: field initializer is not constant
class RSpans {
public:
static const int max_span = (131)-1;
};
[Bug target/49868] Implement named address space to place/access data in flash memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49868 --- Comment #17 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-03-12 17:55:36 UTC --- Author: gjl Date: Mon Mar 12 17:55:30 2012 New Revision: 185255 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185255 Log: PR target/49868 * gcc.target/avr/torture/addr-space-1.h: New file. * gcc.target/avr/torture/addr-space-g.h: New test. * gcc.target/avr/torture/addr-space-0.h: New test. * gcc.target/avr/torture/addr-space-1.h: New test. * gcc.target/avr/torture/addr-space-x.h: New test. Added: trunk/gcc/testsuite/gcc.target/avr/torture/addr-space-1-0.c trunk/gcc/testsuite/gcc.target/avr/torture/addr-space-1-1.c trunk/gcc/testsuite/gcc.target/avr/torture/addr-space-1-g.c trunk/gcc/testsuite/gcc.target/avr/torture/addr-space-1-x.c trunk/gcc/testsuite/gcc.target/avr/torture/addr-space-1.h Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/52499] avr MODE_CODE_BASE_REG_CLASS enum conversion problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52499 --- Comment #4 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-03-12 18:05:15 UTC --- Author: gjl Date: Mon Mar 12 18:05:11 2012 New Revision: 185256 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185256 Log: PR target/52499 * config/avr/avr.c (avr_mode_code_base_reg_class): Change return type from reg_class_t to enum reg_class. * config/avr/avr-protos.h (avr_mode_code_base_reg_class): Ditto. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr-protos.h trunk/gcc/config/avr/avr.c
[Bug c++/52567] constant expression not recognized as being constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52567 --- Comment #1 from Marc Glisse marc.glisse at normalesup dot org 2012-03-12 18:10:16 UTC --- 131 overflows and is thus not a constant. Try maybe 1LL31 ?
[Bug other/52545] output.h: SECTION_EXCLUDE flag clobbers SECTION_MACH_DEP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52545 --- Comment #6 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-03-12 18:22:08 UTC --- Author: gjl Date: Mon Mar 12 18:22:01 2012 New Revision: 185259 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185259 Log: PR other/52545 * output.h (SECTION_EXCLUDE, SECTION_MACH_DEP): Don't use SECTION_MACH_DEP reserved bits for SECTION_EXCLUDE. Modified: trunk/gcc/ChangeLog trunk/gcc/output.h
[Bug tree-optimization/46728] GCC does not generate fmadd for pow (x, 0.75)+y on powerpc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46728 --- Comment #17 from William J. Schmidt wschmidt at gcc dot gnu.org 2012-03-12 18:26:52 UTC --- Author: wschmidt Date: Mon Mar 12 18:26:48 2012 New Revision: 185260 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185260 Log: 2012-03-12 Bill Schmidt wschm...@linux.vnet.ibm.com PR tree-optimization/46728 * gcc.target/powerpc/pr46728-4.c: Skip for powerpc*-*-darwin*. * gcc.target/powerpc/pr46728-5.c: Likewise. * gcc.target/powerpc/pr46728-8.c: Likewise. * gcc.target/powerpc/pr46728-10.c: Likewise. * gcc.target/powerpc/pr46728-11.c: Likewise. * gcc.target/powerpc/pr46728-13.c: Likewise. * gcc.target/powerpc/pr46728-14.c: Likewise. * gcc.target/powerpc/pr46728-15.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/powerpc/pr46728-10.c trunk/gcc/testsuite/gcc.target/powerpc/pr46728-11.c trunk/gcc/testsuite/gcc.target/powerpc/pr46728-13.c trunk/gcc/testsuite/gcc.target/powerpc/pr46728-14.c trunk/gcc/testsuite/gcc.target/powerpc/pr46728-15.c trunk/gcc/testsuite/gcc.target/powerpc/pr46728-4.c trunk/gcc/testsuite/gcc.target/powerpc/pr46728-5.c trunk/gcc/testsuite/gcc.target/powerpc/pr46728-8.c
[Bug c++/52567] constant expression not recognized as being constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52567 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-03-12 18:28:55 UTC --- Or even 1U, afaics.
[Bug target/52568] New: suboptimal __builtin_shuffle on cycles with AVX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52568
Bug #: 52568
Summary: suboptimal __builtin_shuffle on cycles with AVX
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: marc.gli...@normalesup.org
Hello,
I compiled the following with -O3 (or -Os) and -mavx
#include x86intrin.h
__m256d left(__m256d x){
__m256i mask={1,2,3,0};
return __builtin_shuffle(x,mask);
}
(by the way, for some reason, gcc insists that 'mask' is set but not used with
-Wall)
and got:
vunpckhpd%xmm0, %xmm0, %xmm3
vmovapd%xmm0, %xmm1
vextractf128$0x1, %ymm0, %xmm0
vmovaps%xmm0, %xmm2
vunpckhpd%xmm0, %xmm0, %xmm0
vunpcklpd%xmm1, %xmm0, %xmm1
vunpcklpd%xmm2, %xmm3, %xmm0
vinsertf128$0x1, %xmm1, %ymm0, %ymm0
ret
That doesn't really match the code I currently use to do this:
#ifdef __AVX2__
__m256d d=_mm256_permute4x64_pd(x,1+2*4+3*16+0*64);
#else
__m256d b=_mm256_shuffle_pd(x,x,5);
__m256d c=_mm256_permute2f128_pd(b,b,1);
__m256d d=_mm256_blend_pd(b,c,10);
#endif
Could something recognizing this permutation pattern (and the right cyclic
shift) be added? I know there are too many shuffles to hand-code them all, but
cycles seem like they shouldn't be too uncommon.
With -mavx2, I get a single vpermq, which is close enough to the expected
vpermpd.
