[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309 Joost VandeVondele changed: What|Removed |Added CC||Joost.VandeVondele at mat ||dot ethz.ch --- Comment #44 from Joost VandeVondele 2013-02-22 08:31:11 UTC --- (In reply to comment #43) > 400.perlbench fails with a global-buffer-overflow which clang does not detect. I'm wondering if the failure goes away compiled with -O0 instead ?
[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309 --- Comment #45 from Kostya Serebryany 2013-02-22 08:36:14 UTC --- > I'm wondering if the failure goes away compiled with -O0 instead ? No, the failure is still present with -O0
[Bug libfortran/30162] [4.7/4.8 Regression] Unformatted sequential I/O with named pipes does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162 --- Comment #55 from Tobias Burnus 2013-02-22 08:54:30 UTC --- (In reply to comment #54) > I'd suggest to close the unformatted sequential part of this PR as WONTFIX. > [...] Should we document in http://gcc.gnu.org/onlinedocs/gfortran/ that I/O via pipes (and other nonseekable devices) is only supported for STREAM and for FORMATTED+SEQUENTIAL?
[Bug sanitizer/56393] SIGSEGV when -fsanitize=address and dynamic lib with global objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393 --- Comment #20 from Takaki Makino 2013-02-22 09:01:30 UTC --- I understand why dynamic libasan is important. Still it seems for me -static-libasan can be default, except when -shared is given. (just because I have no idea how the shared case could be solved...)
[Bug c++/56421] Non-matching overload produces template substitution error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56421 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek 2013-02-22 09:08:53 UTC --- Also with trunk: c.C: In instantiation of ‘struct Foo’: c.C:6:41: required by substitution of ‘template typename Foo::type foo(int) [with S = ]’ c.C:10:12: required from here c.C:2:28: error: ‘int’ is not a class, struct, or union type typedef typename S::type type; ^ For that , see PR56377.
[Bug rtl-optimization/56131] [4.8 regression] gcc.dg/pr56035.c ICEs gcc on sparc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56131
--- Comment #14 from vries at gcc dot gnu.org 2013-02-22 10:30:06 UTC ---
Steven,
thanks for the comments.
> Nothing even trying to look at the CFG after freeing it, so the looks at
> BLOCK_FOR_INSN in delete_insn are non-sense.
AFAIU now from
http://gcc.gnu.org/onlinedocs/gccint/Maintaining-the-CFG.html#Maintaining-the-CFG,
BLOCK_FOR_INSN == NULL shows whether the CFG has been freed or not, so I'd say
it makes sense to test for equality of BLOCK_FOR_INSN when non-NULL.
> Looking for the basic block
> anywhere at all at this point makes no sense,
If I understand you correctly with 'this point' you mean 'after the CFG has
been freed'?
> basic block contents and
> boundaries are not maintained and may be scrambled enough to make even
> the basic block notes unreliable.
OK. I've added a comment in insn-notes.def in the patch below to make that more
explicit.
> Also, "If the label is not marked with a bb, assume it's the same bb"
> is wrong if the label is a marker for a constant pool or a jump table.
OK, fixed in patch below.
Does this patch address all your concerns?
...
Index: gcc/insn-notes.def
===
--- gcc/insn-notes.def (revision 195874)
+++ gcc/insn-notes.def (working copy)
@@ -70,7 +70,9 @@ INSN_NOTE (CALL_ARG_LOCATION)
/* Record the struct for the following basic block. Uses
NOTE_BASIC_BLOCK. FIXME: Redundant with the basic block pointer
- now included in every insn. */
+ now included in every insn. NOTE: If there's no CFG anymore, in other
words,
+ if BLOCK_FOR_INSN () == NULL, NOTE_BASIC_BLOCK cannot be considered
reliable
+ anymore. */
INSN_NOTE (BASIC_BLOCK)
/* Mark the inflection point in the instruction stream where we switch
Index: gcc/cfgrtl.c
===
--- gcc/cfgrtl.c (revision 195874)
+++ gcc/cfgrtl.c (working copy)
@@ -135,7 +135,7 @@ delete_insn (rtx insn)
if (! can_delete_label_p (insn))
{
const char *name = LABEL_NAME (insn);
- basic_block bb, label_bb = BLOCK_FOR_INSN (insn);
+ basic_block bb = BLOCK_FOR_INSN (insn);
rtx bb_note = NEXT_INSN (insn);
really_delete = false;
@@ -144,15 +144,13 @@ delete_insn (rtx insn)
NOTE_DELETED_LABEL_NAME (insn) = name;
/* If the note following the label starts a basic block, and the
- label is a member of the same basic block, interchange the two.
- If the label is not marked with a bb, assume it's the same bb. */
+ label is a member of the same basic block, interchange the two. */
if (bb_note != NULL_RTX
&& NOTE_INSN_BASIC_BLOCK_P (bb_note)
- && (label_bb == NOTE_BASIC_BLOCK (bb_note)
- || label_bb == NULL))
+ && bb != NULL
+ && bb == BLOCK_FOR_INSN (bb_note))
{
reorder_insns_nobb (insn, insn, bb_note);
- bb = NOTE_BASIC_BLOCK (bb_note);
BB_HEAD (bb) = bb_note;
if (BB_END (bb) == bb_note)
BB_END (bb) = insn;
...
[Bug c++/51707] [c++11] constexpr constructor cannot initialize const reference member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51707 Martin von Gagern changed: What|Removed |Added CC||Martin.vGagern at gmx dot ||net --- Comment #1 from Martin von Gagern 2013-02-22 10:32:08 UTC --- I get this same error message in a much more complicated situation. I'll simply assume that it's the same thing I'm seeing, but will try to remember running my example through any fix proposed for this issue here.
[Bug c++/56421] Non-matching overload produces template substitution error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56421 --- Comment #2 from Jonathan Wakely 2013-02-22 10:42:05 UTC --- Isn't G++ correct? Foo::type exists unconditionally, so SFINAE doesn't apply. The invalid type is not in the immediate context of the substitution. To make this work you would have to only define Foo::type if S::type exists.
[Bug c++/56421] Non-matching overload produces template substitution error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56421 --- Comment #3 from Daniel Krügler 2013-02-22 10:59:28 UTC --- (In reply to comment #2) > Isn't G++ correct? Foo::type exists unconditionally, so SFINAE doesn't apply. > The invalid type is not in the immediate context of the substitution. This was my initial reaction, too, but there is one point in this example where I need to find clarification: Both foo() templates have a *different* function parameter lists (one void, one with int). I'm yet unsure (due to lack of time studying whether 14.8.2 requires to check first parameter compatibility in the call context or not).
[Bug fortran/55356] ICE with TRANSFER of C_NULL_PTR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55356 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||burnus at gcc dot gnu.org Resolution||DUPLICATE --- Comment #1 from Tobias Burnus 2013-02-22 11:19:13 UTC --- Seems to be a duplicate of PR 56079 (which admittedly has been filled later than this bug). Thanks for the report. *** This bug has been marked as a duplicate of bug 56079 ***
[Bug fortran/56079] [4.7/4.8 Regression] ICE with C_PTR renaming and TRANSFER
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56079 Tobias Burnus changed: What|Removed |Added CC||juno.krahn at nih dot gov --- Comment #5 from Tobias Burnus 2013-02-22 11:19:13 UTC --- *** Bug 55356 has been marked as a duplicate of this bug. ***
[Bug target/36798] internal compiler error: in arm_expand_binop_builtin, at config/arm/arm.c:12548
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36798 Nick Clifton changed: What|Removed |Added Status|NEW |RESOLVED CC||nickc at gcc dot gnu.org Resolution||DUPLICATE --- Comment #9 from Nick Clifton 2013-02-22 12:38:36 UTC --- Closed because this is a duplicate bug report. *** This bug has been marked as a duplicate of bug 35294 ***
[Bug target/35294] iwmmxt intrinsics, internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35294 Nick Clifton changed: What|Removed |Added CC||gfan at sta dot samsung.com --- Comment #19 from Nick Clifton 2013-02-22 12:38:36 UTC --- *** Bug 36798 has been marked as a duplicate of this bug. ***
[Bug target/36966] arm iwmmxt builtin problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36966 Nick Clifton changed: What|Removed |Added Status|NEW |RESOLVED CC||nickc at gcc dot gnu.org Resolution||DUPLICATE --- Comment #5 from Nick Clifton 2013-02-22 12:40:42 UTC --- Duplicate bug report. *** This bug has been marked as a duplicate of bug 35294 ***
[Bug target/35294] iwmmxt intrinsics, internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35294 Nick Clifton changed: What|Removed |Added CC||eliot at sonic dot net --- Comment #20 from Nick Clifton 2013-02-22 12:40:42 UTC --- *** Bug 36966 has been marked as a duplicate of this bug. ***
[Bug bootstrap/56424] New: [4.8 Regression] bootstrap fails in libada, gnat1 asserts in declare_return_variable, at tree-inline.c:2833
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56424 Bug #: 56424 Summary: [4.8 Regression] bootstrap fails in libada, gnat1 asserts in declare_return_variable, at tree-inline.c:2833 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: rai...@emrich-ebersheim.de CC: hubi...@gcc.gnu.org Host: x86_64-w64-mingw32 Target: x86_64-w64-mingw32 Build: x86_64-w64-mingw32 Native bootstrap on x86_64-w64-mingw32 fails in stage3. /SCRATCH/tmp.WFOaDArHyR/gcc-4.8.0/gcc-4.8.0/./gcc/xgcc -B/SCRATCH/tmp.WFOaDArHyR/gcc-4.8.0/gcc-4.8.0/./gcc/ -L/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.8.0/x86_64-w64-mingw32/lib -L/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.8.0/mingw/lib -isystem /opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.8.0/x86_64-w64-mingw32/include -isystem /opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.8.0/mingw/include -B/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.8.0/x86_64-w64-mingw32/bin/ -B/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.8.0/x86_64-w64-mingw32/lib/ -isystem /opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.8.0/x86_64-w64-mingw32/include -isystem /opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.8.0/x86_64-w64-mingw32/sys-include -c -g -O2-W -Wall -gnatpg -nostdinc a-nllcef.ads -o a-nllcef.o in declare_return_variable, at tree-inline.c:2833make[6]: *** [a-nllcef.o] Error 1 caused by the fixes for PR55797 revison 195750, 195751.
[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #46 from Jakub Jelinek 2013-02-22
13:09:10 UTC ---
(In reply to comment #43)
> 400.perlbench fails with a global-buffer-overflow which clang does not detect.
> I did not investigate why. It could be a gcc false positive or clang false
> negative.
On which file/function the global-buffer-overflow was? Can you send me the
asan diagnostics?
> 464.h264ref is VERY slow, I did not look why.
And it didn't fail on that:
for (dd=d[k=0]; k<16; dd=d[++k])
{
satd += (dd < 0 ? -dd : dd);
}
or have you fixed that up in your SPEC sources?
[Bug rtl-optimization/56131] [4.8 regression] gcc.dg/pr56035.c ICEs gcc on sparc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56131 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #15 from Jakub Jelinek 2013-02-22 13:17:48 UTC --- Does that fix both this PR and the PR56242 regression? It looks reasonable to me.
[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #47 from Kostya Serebryany 2013-02-22
13:52:12 UTC ---
(In reply to comment #46)
> (In reply to comment #43)
> > 400.perlbench fails with a global-buffer-overflow which clang does not
> > detect.
> > I did not investigate why. It could be a gcc false positive or clang false
> > negative.
>
> On which file/function the global-buffer-overflow was? Can you send me the
> asan diagnostics?
Interestingly, the symbolization/debuginfo seems to be completely broken :(
% g++ -g -fsanitize=address ./use-after-free.cc -static-libasan ; ./a.out 2>&1
| grep '#0'
#0 0x4179c2 (/home/kcc/tmp/a.out+0x4179c2)
#0 0x40f18a (/home/kcc/tmp/a.out+0x40f18a)
#0 0x40f26a (/home/kcc/tmp/a.out+0x40f26a)
% addr2line -f -e ./a.out 0x4179c2 0x40f18a 0x40f26a
main
??:0
free
??:0
malloc
??:0
%
==580== ERROR: AddressSanitizer: global-buffer-overflow on address
0x0078e2a5 at pc 0x4e47d7 bp 0x7fffa2fbc7b0 sp 0x7fffa2fbc7a8
READ of size 1 at 0x0078e2a5 thread T0
#0 0x4e47d6 in PerlIO_find_layer
(benchspec/CPU2006/400.perlbench/run/run_base_train_z./perlbench_base.z+0x4e47d6)
#1 0x4e63e6 in PerlIO_default_buffer
(benchspec/CPU2006/400.perlbench/run/run_base_train_z./perlbench_base.z+0x4e63e6)
#2 0x4e678e in PerlIO_default_layers
(benchspec/CPU2006/400.perlbench/run/run_base_train_z./perlbench_base.z+0x4e678e)
#3 0x4e7a41 in PerlIO_resolve_layers
(benchspec/CPU2006/400.perlbench/run/run_base_train_z./perlbench_base.z+0x4e7a41)
#4 0x4e8145 in PerlIO_openn
(benchspec/CPU2006/400.perlbench/run/run_base_train_z./perlbench_base.z+0x4e8145)
#5 0x4f5d32 in PerlIO_open
(benchspec/CPU2006/400.perlbench/run/run_base_train_z./perlbench_base.z+0x4f5d32)
#6 0x4dd808 in S_open_script
(benchspec/CPU2006/400.perlbench/run/run_base_train_z./perlbench_base.z+0x4dd808)
#7 0x4d3be6 in S_parse_body
(benchspec/CPU2006/400.perlbench/run/run_base_train_z./perlbench_base.z+0x4d3be6)
#8 0x4d2a4b in perl_parse
(benchspec/CPU2006/400.perlbench/run/run_base_train_z./perlbench_base.z+0x4d2a4b)
#9 0x4f6ee8 in main
(benchspec/CPU2006/400.perlbench/run/run_base_train_z./perlbench_base.z+0x4f6ee8)
#10 0x7fd3a245376c (/lib/x86_64-linux-gnu/libc.so.6+0x2176c)
#11 0x4037d8
(benchspec/CPU2006/400.perlbench/run/run_base_train_z./perlbench_base.z+0x4037d8)
0x0078e2a5 is located 0 bytes to the right of global variable '*.LC50
(perlio.c)' (0x78e2a0) of size 5
'*.LC50 (perlio.c)' is ascii string 'unix'
SUMMARY: AddressSanitizer: global-buffer-overflow ??:0 PerlIO_find_layer
>
> > 464.h264ref is VERY slow, I did not look why.
>
> And it didn't fail on that:
> for (dd=d[k=0]; k<16; dd=d[++k])
> {
> satd += (dd < 0 ? -dd : dd);
> }
> or have you fixed that up in your SPEC sources?
Interestingly, no. I haven't touched SPEC sources here.
Maybe gcc does full unroll thus eliminating the buggy read (I did not check).
[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309 --- Comment #48 from Joost VandeVondele 2013-02-22 13:55:16 UTC --- (In reply to comment #47) > > Interestingly, the symbolization/debuginfo seems to be completely broken :( > I've tried compiling with -gdwarf-3 , with some luck
[Bug sanitizer/56425] New: debug info is broken with -fsanitize=address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56425 Bug #: 56425 Summary: debug info is broken with -fsanitize=address Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer AssignedTo: unassig...@gcc.gnu.org ReportedBy: k...@gcc.gnu.org CC: do...@gcc.gnu.org, dvyu...@gcc.gnu.org, ja...@gcc.gnu.org, k...@gcc.gnu.org r196201 addr2line can not properly symbolize asan-ified binaries % g++ -gdwarf-3 -fsanitize=address ./use-after-free.cc -static-libasan ; ./a.out 2>&1 | grep '#0' #0 0x4179c2 (/home/kcc/tmp/a.out+0x4179c2) #0 0x40f18a (/home/kcc/tmp/a.out+0x40f18a) #0 0x40f26a (/home/kcc/tmp/a.out+0x40f26a) % addr2line -f -e ./a.out 0x4179c2 0x40f18a 0x40f26a main /home/kcc/tmp/./use-after-free.cc:22 free ??:0 malloc ??:0 % g++ -g -fsanitize=address ./use-after-free.cc -static-libasan ; ./a.out 2>&1 | grep '#0' #0 0x4179c2 (/home/kcc/tmp/a.out+0x4179c2) #0 0x40f18a (/home/kcc/tmp/a.out+0x40f18a) #0 0x40f26a (/home/kcc/tmp/a.out+0x40f26a) % addr2line -f -e ./a.out 0x4179c2 0x40f18a 0x40f26a main ??:0 free ??:0 malloc ??:0 %
[Bug middle-end/56344] ICE for program with very large structs returned by value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56344
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #3 from Marek Polacek 2013-02-22
14:28:02 UTC ---
Richi, for the middle-end part, do you mean something like this? I've used
error () instead of sorry (), but of course I can change that back.
--- gcc/calls.c.mp2013-02-22 15:24:58.655086818 +0100
+++ gcc/calls.c2013-02-22 15:25:09.737117963 +0100
@@ -3037,6 +3037,12 @@ expand_call (tree exp, rtx target, int i
{
rtx before_arg = get_last_insn ();
+ if (adjusted_args_size.constant >= (1 << 31))
+{
+ error ("passing too large argument on stack");
+ break;
+}
+
if (store_one_arg (&args[i], argblock, flags,
adjusted_args_size.var != 0,
reg_parm_stack_space)
[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309 --- Comment #49 from Kostya Serebryany 2013-02-22 14:29:27 UTC --- with -gdwarf-3: ==11621== ERROR: AddressSanitizer: global-buffer-overflow on address 0x0078e2a5 at pc 0x4e47d7 bp 0x7fff553d4cc0 sp 0x7fff553d4cb8 READ of size 1 at 0x0078e2a5 thread T0 #0 0x4e47d6 in PerlIO_find_layer perlio.c:751 #1 0x4e63e6 in PerlIO_default_buffer perlio.c:1015 #2 0x4e678e in PerlIO_default_layers perlio.c:1113 #3 0x4e7a41 in PerlIO_resolve_layers perlio.c:1433 #4 0x4e8145 in PerlIO_openn perlio.c:1519 #5 0x4f5c08 in PerlIO_fdopen perlio.c:4745 #6 0x4e68a3 in PerlIO_stdstreams perlio.c:1150 #7 0x4f5b46 in Perl_PerlIO_stdin perlio.c:4686 #8 0x4dd7ee in S_open_script perl.c:3348 #9 0x4d3be6 in S_parse_body perl.c:1718 #10 0x4d2a4b in perl_parse perl.c:1312 #11 0x4f6ee8 in main perlmain.c:96 #12 0x7f686f32576c in __libc_start_main libc-start.c:226 #13 0x4037d8 in _start ??:0 0x0078e2a5 is located 0 bytes to the right of global variable '*.LC50 (perlio.c)' (0x78e2a0) of size 5 '*.LC50 (perlio.c)' is ascii string 'unix'
[Bug sanitizer/56425] debug info is broken with -fsanitize=address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56425 --- Comment #1 from Kostya Serebryany 2013-02-22 14:29:57 UTC --- clarification: -gdwarf-3 seems to work, but -g is broken
[Bug middle-end/56344] ICE for program with very large structs returned by value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56344 --- Comment #4 from Marek Polacek 2013-02-22 14:33:37 UTC --- Or probably s/break/continue/, in that case we'd issue error () on every ill-sized parameter. And of course, it's completely untested.
[Bug sanitizer/56425] debug info is broken with -fsanitize=address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56425 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Jakub Jelinek 2013-02-22 14:35:45 UTC --- Your addr2line is too old. Do your binutils include the 2012-04-26 Mark Wielaard fix? -gdwarf-3 will compile use-after-free.o as DWARF-3, but with -static-libasan libasan.a is of course compiled with the default (which is DWARF-4), thus if addr2line doesn't grok DWARF-4 properly, you need to upgrade it.
[Bug sanitizer/56425] debug info is broken with -fsanitize=address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56425 --- Comment #3 from Kostya Serebryany 2013-02-22 14:37:06 UTC --- ah yea, sorry. I use vanilla addr2line from ubuntu 12.04
[Bug inline-asm/56148] [4.8 Regression] inline asm matching constraint with different mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56148
Frank Mehnert changed:
What|Removed |Added
CC||fm3 at os dot
||inf.tu-dresden.de
--- Comment #14 from Frank Mehnert 2013-02-22
14:39:44 UTC ---
(In reply to comment #0)
> void
> foo (void)
> {
> unsigned char e[16];
> unsigned long a, b, c, d;
> __asm__ __volatile__ ("" : "=d" (a), "=&c" (c), "=&D" (d), "=&a" (b)
>: "0" (-1U), "mr" (e), "1" (128 >> 5), "2" (e), "3" (-1U));
> }
>
> is rejected since LRA merge on x86_64-linux at -O2:
> rh905862.i: In function ‘foo’:
> rh905862.i:6:3: error: ‘asm’ operand has impossible constraints
>__asm__ __volatile__ ("" : "=d" (a), "=&c" (c), "=&D" (d), "=&a" (b)
>^
>
> The testcase is questionable, because a, c and b are DImode, while -1U, 128 >>
> 5
> and -1U are all SImode using 0/1/3 constraints matching those DImodes.
> But we accept it with reload or with -O0 even with LRA.
Glad that gcc-4.8 does now behave as before but I would also like to understand
what is questionable about this testcase. How to improve it?
[Bug c++/54440] [c++11] g++ prematurely applying rule that a template parameter pack cannot be followed by a template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54440 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-02-22 AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Jason Merrill 2013-02-22 14:48:06 UTC --- Created attachment 29523 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29523 patch Here's a patch for after 4.8 branches.
[Bug tree-optimization/56426] New: Segmentation fault in find_var_scev_info, at tree-scalar-evolution.c:358
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56426
Bug #: 56426
Summary: Segmentation fault in find_var_scev_info, at
tree-scalar-evolution.c:358
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: antoine.balest...@gmail.com
Using GCC 4.8.0 as of 20130222 :
$ cat scev.c
int a, *c;
void f(void)
{
int b = 0;
for(a = 0;; a++)
if(--b)
{
if(a)
lbl:
a++;
c = &b;
goto lbl;
}
}
$ xgcc -w -O2 scev.c
scev.c: In function ‘f’:
scev.c:3:6: internal compiler error: Segmentation fault
void f(void)
^
0x8f89ef crash_signal
../../srcdir/gcc/toplev.c:332
0xe1228f htab_find_slot
../../srcdir/libiberty/hashtab.c:712
0x98caf5 find_var_scev_info
../../srcdir/gcc/tree-scalar-evolution.c:358
0x98f999 get_scalar_evolution
../../srcdir/gcc/tree-scalar-evolution.c:559
0x98f999 analyze_scalar_evolution(loop*, tree_node*)
../../srcdir/gcc/tree-scalar-evolution.c:1963
0xa00287 infer_loop_bounds_from_signedness
../../srcdir/gcc/tree-ssa-loop-niter.c:2887
0xa00287 infer_loop_bounds_from_undefined
../../srcdir/gcc/tree-ssa-loop-niter.c:2944
0xa00287 estimate_numbers_of_iterations_loop
../../srcdir/gcc/tree-ssa-loop-niter.c:3340
0xa00287 estimate_numbers_of_iterations_loop(loop*)
../../srcdir/gcc/tree-ssa-loop-niter.c:3302
0xa015e4 estimate_numbers_of_iterations()
../../srcdir/gcc/tree-ssa-loop-niter.c:3534
0xa01aa7 tree_ssa_loop_bounds
../../srcdir/gcc/tree-ssa-loop.c:432
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
[Bug c++/56419] [4.8 regression] transactions in for-loops disappear
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56419 --- Comment #3 from Aldy Hernandez 2013-02-22 14:54:32 UTC --- Proposed patch: http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01058.html
[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #50 from Kostya Serebryany 2013-02-22
14:54:24 UTC ---
reproducer:
#include
#include
int foo(const char *x, const char *y, int len) {
return memcmp(x, y, len);
}
int main() {
printf("%d\n", foo("perlio", "unix", 6));
}
clang does not report a warning here, but gcc does.
This is a gray area for me, not sure if we should treat this as a buggy code.
on one hand, memcmp gets size=6, while one of the buffers is smaller.
otoh, the first bytes of the strings are different and memcmp should not read
the rest.
I vaguely remember some similar case where we decided that the code is correct.
Anyone?
[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #51 from Jakub Jelinek 2013-02-22
15:01:08 UTC ---
Looks like a real SPEC bug to me.
PerlIO_funcs *
PerlIO_find_layer(pTHX_ const char *name, STRLEN len, int load)
{
IV i;
if ((SSize_t) len <= 0)
len = strlen(name);
for (i = 0; i < PL_known_layers->cur; i++) {
PerlIO_funcs *f = PL_known_layers->array[i].funcs;
if (memEQ(f->name, name, len) && f->name[len] == 0) {
PerlIO_debug("%.*s => %p\n", (int) len, name, (void*)f);
return f;
}
}
memEQ is memcmp, and my reading of ISO C99 or
http://pubs.opengroup.org/onlinepubs/9699919799/functions/memcmp.html is that
it is a bug to call memcmp ("abcdef", "defg", 6). A valid memcmp
implementation could preread all bytes from both arrays (of the given length)
and only then compare. And, at least some implementations (e.g. glibc
string/memcmp.c) does that if the two strings aren't starting at the same
address modulo size of word.
[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
Jakub Jelinek changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org
--- Comment #52 from Jakub Jelinek 2013-02-22
15:03:31 UTC ---
CCing Joseph for expert opinion on whether memcmp ("abcdef", "qrst", 6); is
valid C99.
[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #53 from Kostya Serebryany 2013-02-22
15:06:25 UTC ---
The interceptor we have is conservative:
INTERCEPTOR(int, memcmp, const void *a1, const void *a2, uptr size) {
if (!asan_inited) return internal_memcmp(a1, a2, size);
ENSURE_ASAN_INITED();
unsigned char c1 = 0, c2 = 0;
const unsigned char *s1 = (const unsigned char*)a1;
const unsigned char *s2 = (const unsigned char*)a2;
uptr i;
for (i = 0; i < size; i++) {
c1 = s1[i];
c2 = s2[i];
if (c1 != c2) break;
}
ASAN_READ_RANGE(s1, Min(i + 1, size));
ASAN_READ_RANGE(s2, Min(i + 1, size));
return CharCmp(c1, c2);
}
looks like gcc partially inlines memcmp and
bypasses out conservative interceptor.
We could make the interceptor more strict (ASAN_READ_RANGE(s2, size);).
I am trying to remember why we didn't do this...
[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309 --- Comment #54 from Jakub Jelinek 2013-02-22 15:13:34 UTC --- gcc instruments many of the builtins inline, on the assumption that the builtins are often expanded inline and thus the interceptor might not be called at all. Either it isn't, or is and the gcc instrumentation is done in addition to the interceptor's instrumentation.
[Bug bootstrap/56258] Please upgrade doc/*.texi to the latest texinfo package(s)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56258 Jack Howarth changed: What|Removed |Added CC||howarth at nitro dot ||med.uc.edu --- Comment #10 from Jack Howarth 2013-02-22 15:19:19 UTC --- Posted patches of remaining bootstrap fixes for gcc-4_7-branch and gcc-4_6-branch... http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01059.html http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01060.html
[Bug c++/56395] [4.7/4.8 Regression] ICE, Segmentation fault in tsubst
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56395 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug c/56368] GCC Configure tests failed for name lister when building from combined tree (GCC+Binutils)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56368 --- Comment #2 from Karlson2k 2013-02-22 15:44:42 UTC --- Created attachment 29524 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29524 Patch for configure for correct work with combined tree Apply patch + regenerate configure
[Bug c++/56359] [4.8 regression] Bogus "error: no matching function for call to ..."
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56359 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug middle-end/55308] /usr/ports/lang/gcc48/work/build/sparc64-portbld-freebsd10.0/libstdc++-v3/src/.libs/libstdc++.so.6: Undefined symbol "__emutls_v._ThreadRuneLocale"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55308 --- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE 2013-02-22 15:48:00 UTC --- There seems to be something totally confused here: when linking libgcc_s.so, there's a reference to libstdc++.so: [...] lc && rm -f /libgcc_s.so && if [ -f /libgcc_s.so.1 ]; then mv -f /libgcc_s.so.1 /libgcc_s.so.1.backup; else true; fi && mv /libgcc_s.so.1.tmp /libgcc_s.so.1 && ln -s libgcc_s.so.1 /libgcc_s.so /usr/ports/lang/gcc48/work/build/sparc64-portbld-freebsd10.0/libstdc++-v3/src/.libs/libstdc++.so.6: Undefined symbol "__emutls_v._ThreadRuneLocale" gmake[3]: *** [libgcc_s.so] Error 1 This cannot be right, at least this won't happen during a regular gcc build. You first need to find out which object/shared object references this undefined symbol. Only after this analysis is done, we can come to further conclusions. If you have already done the analysis, you should include the results in the PR. Apart from that, tls_as_opt="-32 --fatal-warnings" is in the non-Solaris gas sections of configure.ac and has been there even before my patch to improve Solaris/SPARC TLS support. What assembler does this build use? I suppose it is some version of gas, in which case I've got a hard time believing that it doesn't support -32. If this is a completely different assembler, you'll have to add support for the options it does and doesn't understand, and perhaps even more to properly enable native TLS. Rainer
[Bug tree-optimization/56426] [4.8 Regression] Segmentation fault in find_var_scev_info, at tree-scalar-evolution.c:358
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56426 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-02-22 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |4.8.0 Summary|Segmentation fault in |[4.8 Regression] |find_var_scev_info, at |Segmentation fault in |tree-scalar-evolution.c:358 |find_var_scev_info, at ||tree-scalar-evolution.c:358 Ever Confirmed|0 |1 --- Comment #1 from Marek Polacek 2013-02-22 15:49:02 UTC --- Confirmed. Started with http://gcc.gnu.org/viewcvs?view=revision&revision=195879
[Bug c/56368] GCC Configure tests failed for name lister when building from combined tree (GCC+Binutils)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56368 --- Comment #3 from Karlson2k 2013-02-22 15:49:37 UTC --- Seems that string objdir=$lt_cv_objdir was put to object directory detection script by mistake. 'objdir' is used in configure only for AR and NM and used in the same way like in 'Makefile'. My simple patch correct the this problem and correct configure errors.
[Bug c++/56377] [4.8 Regression] template args in substitution-failure diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56377 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug c/56371] When building GCC from combined tree, configure is making wrong assumptions about 'gas' and 'ld'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56371
--- Comment #2 from Karlson2k 2013-02-22 15:59:56 UTC ---
There is bug in configure script. Just before 'checking linker for .hidden
support', configure detect ld version by:
if test $in_tree_ld != yes ; then
ld_ver=`$gcc_cv_ld --version 2>/dev/null | sed 1q`
if echo "$ld_ver" | grep GNU > /dev/null; then
if test x"$ld_is_gold" = xyes; then
[... cut ...]
fi
ld_date=`echo $ld_ver | sed -n
's,^.*\([2-9][0-9][0-9][0-9]\)[-]*\([01][0-9]\)[-]*\([0-3][0-9]\).*$,\1\2\3,p'`
ld_vers_major=`expr "$ld_vers" : '\([0-9]*\)'`
ld_vers_minor=`expr "$ld_vers" : '[0-9]*\.\([0-9]*\)'`
ld_vers_patch=`expr "$ld_vers" : '[0-9]*\.[0-9]*\.\([0-9]*\)'`
else
case "${target}" in
[... cut ...]
esac
fi
fi
But in tree ld version is not detected at all!
Just a few lines later:
if test $in_tree_ld = yes ; then
gcc_cv_ld_hidden=no
if test "$gcc_cv_gld_major_version" -eq 2 -a "$gcc_cv_gld_minor_version" -ge
13 -o "$gcc_cv_gld_major_version" -gt 2 \
&& test $in_tree_ld_is_elf = yes; then
gcc_cv_ld_hidden=yes
fi
else
configure make some assumption about ld basing on lv version.
As ld is build before run of gcc's configure, all detection could be unified
for in-tree ld and external ld.
[Bug sanitizer/56393] SIGSEGV when -fsanitize=address and dynamic lib with global objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393
--- Comment #21 from Jakub Jelinek 2013-02-22
16:07:46 UTC ---
Author: jakub
Date: Fri Feb 22 16:07:36 2013
New Revision: 196222
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196222
Log:
PR sanitizer/56393
* config/gnu-user.h (LIBASAN_EARLY_SPEC): Link in libasan_preinit.o
if not linking a shared library.
* lib/asan-dg.exp (asan_link_flags): Add
-B${gccpath}/libsanitizer/asan/ to flags.
* asan/Makefile.am (nodist_toolexeclib_HEADERS): Set to
libasan_preinit.o.
(libasan_preinit.o): Depend on asan_preinit.o.
* asan/Makefile.in: Regenerated.
* asan/asan_preinit.cc: New file, synced from upstream.
* asan/asan_rtl.cc: Remove preinit stuff, synced from upstream.
Added:
trunk/libsanitizer/asan/asan_preinit.cc
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/gnu-user.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/lib/asan-dg.exp
trunk/libsanitizer/ChangeLog
trunk/libsanitizer/asan/Makefile.am
trunk/libsanitizer/asan/Makefile.in
trunk/libsanitizer/asan/asan_rtl.cc
[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309 --- Comment #55 from joseph at codesourcery dot com 2013-02-22 16:10:49 UTC --- I believe the arguments to memcmp must point to objects with at least the given number of bytes. (For strcmp, they must point to NUL-terminated strings. For strncmp, they must point to objects that either have at least the given number of bytes or have bytes present up to a NUL within that number of bytes - there's no guarantee that comparison stops early when characters differ except for not reading after a NUL. By comparison, the array passed to memchr may be shorter than the given length if a matching character is found early - see the wording added in C11 for memchr for alignment with POSIX. But memcmp has no such special rule.)
[Bug c++/56421] Non-matching overload produces template substitution error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56421 --- Comment #4 from Jonathan Wakely 2013-02-22 16:24:42 UTC --- I think 13.3 [over.match] ¶2 and 13.3.1 [over.match.funcs] ¶7 say the function template specialization must be generated before the number of arguments is checked to see if the candidate function is viable.
[Bug inline-asm/56148] [4.8 Regression] inline asm matching constraint with different mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56148 --- Comment #15 from Vladimir Makarov 2013-02-22 16:30:33 UTC --- Author: vmakarov Date: Fri Feb 22 16:30:22 2013 New Revision: 196223 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196223 Log: 2013-02-22 Vladimir Makarov PR inline-asm/56148 * lra-constraints.c (process_alt_operands): Reload operand conflicting with earlier clobber only if no more other conflicting operands. Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c
[Bug rtl-optimization/56131] [4.8 regression] gcc.dg/pr56035.c ICEs gcc on sparc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56131 --- Comment #16 from Steven Bosscher 2013-02-22 16:33:58 UTC --- (In reply to comment #14) Yes, iff the CFG hasn't been freed, looking at BLOCK_FOR_INSN is of course OK. I was referring to the situation after freeing the CFG. Adding that comment to insn-notes.def seems like a good idea. The patch looks reasonable. Does it fix bug 56242?
[Bug c++/35022] [4.6/4.7/4.8 Regression] ICE with parameter pack in template constant parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35022 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.6.4 |4.8.0 --- Comment #15 from Jason Merrill 2013-02-22 17:53:05 UTC --- This ICE seems to be fixed in 4.8, and perhaps earlier; it only shows up with checking enabled anyway. I'm creating a separate bug for the rejects-valid.
[Bug c++/56427] New: [C++11] template template parameter template parameter pack that depends on another parameter pack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56427 Bug #: 56427 Summary: [C++11] template template parameter template parameter pack that depends on another parameter pack Classification: Unclassified Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org CC: chris.fair...@gmail.com, dgre...@gcc.gnu.org, ism...@donmez.ws, ja...@gcc.gnu.org, reich...@gcc.gnu.org Depends on: 54440, 35022 +++ This bug was initially created as a clone of Bug #35022 +++ This code snippet should be accepted: template class X> void foo(X<0>); but it fails with sorry, unimplemented: use of ‘type_pack_expansion’ in template This is related to bug 54440.
[Bug c++/56421] Non-matching overload produces template substitution error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56421 --- Comment #5 from Kristian Spangsege 2013-02-22 18:04:41 UTC --- (In reply to comment #4) > I think 13.3 [over.match] ¶2 and 13.3.1 [over.match.funcs] ¶7 say the > function > template specialization must be generated before the number of arguments is > checked to see if the candidate function is viable. Not so. Function templates must not be instantiated unless the number of arguments match. [C++11: 13.3/2]: - First, a subset of the candidate functions (those that have the proper number of arguments and meet certain other conditions) is selected to form a set of viable functions (13.3.2). - Then the best viable function is selected based on the implicit conversion sequences (13.3.3.1) needed to match each argument to the corresponding parameter of each viable function. [C++11: 13.3.1/7]: In each case where a candidate is a function template, candidate function template specializations are generated using template argument deduction (14.8.3, 14.8.2). Those candidates are then handled as candidate functions in the usual way.
[Bug target/11180] [avr-gcc] Optimization decrease performance of struct assignment.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11180 Georg-Johann Lay changed: What|Removed |Added Priority|P2 |P4 Severity|enhancement |normal
[Bug c++/56421] Non-matching overload produces template substitution error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56421 --- Comment #6 from Jonathan Wakely 2013-02-22 18:47:55 UTC --- (In reply to comment #5) > Function templates must not be instantiated unless the number of arguments > match. Where does the standard say that? > [C++11: 13.3/2]: > > - First, a subset of the candidate functions (those that have the proper > number > of arguments and meet certain other conditions) is selected to form a set of > viable functions (13.3.2). You've quoted this out of context, the preceding sentence says "But, once the candidate functions and argument lists have been identified, the selection of the best function is the same in all cases:" i.e. identifying the candidate functions happens before considering the number of arguments. 13.3.1 describes how the set of candidate functions (including function template specializations) is found, then 13.3.2 describes how the number of arguments is considered in order to find the subset of candidate functions that are viable. Also see 14.8.3 [temp.over]/1 "The complete set of candidate functions includes all the synthesized declarations and all of the non-template overloaded functions of the same name." "The complete set" is the set *before* the number of arguments is considered to find the viable subset. To synthesize the declaration Foo::type must be known, and that type results in an error. That's how I read it anyway, I guess I'll leave this for someone else to interpret.
[Bug fortran/56385] [4.6/4.7/4.8 Regression] [OOP] ICE with allocatable function result in a procedure-pointer component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56385 --- Comment #5 from janus at gcc dot gnu.org 2013-02-22 19:48:15 UTC --- Author: janus Date: Fri Feb 22 19:48:11 2013 New Revision: 196227 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196227 Log: 2013-02-22 Janus Weil PR fortran/56385 * trans-array.c (structure_alloc_comps): Handle procedure-pointer components with allocatable result. 2013-02-22 Janus Weil PR fortran/56385 * gfortran.dg/proc_ptr_comp_37.f90: New. Added: branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/proc_ptr_comp_37.f90 Modified: branches/gcc-4_7-branch/gcc/fortran/ChangeLog branches/gcc-4_7-branch/gcc/fortran/trans-array.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug c++/56428] New: [C++11] "is not a constant expression" when comparing non-type template argument to nullptr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56428
Bug #: 56428
Summary: [C++11] "is not a constant expression" when comparing
non-type template argument to nullptr
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
struct A { };
template
struct Builder
{
static A build() { return A(); }
};
template
A f()
{
return Builder::build();
}
A g();
int main()
{
f< &g >();// OK
f< nullptr >(); // OK
f< &f >(); // ERROR
}
a.cc: In instantiation of 'A f() [with A (* F)() = f<0u>]':
a.cc:22:20: required from here
a.cc:13:41: error: '(f<0u> != 0u)' is not a constant expression
return Builder::build();
^
a.cc:13:41: note: in template argument for type 'bool'
[Bug fortran/55117] Programs fails to read namelist (contains derived types objects)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55117 Tilo Schwarz changed: What|Removed |Added CC||t...@tilo-schwarz.de --- Comment #11 from Tilo Schwarz 2013-02-22 20:57:50 UTC --- Hi, I ran into this today and tried to produce a small test case from my big namelist problem. program namelist type d1 integer :: j = 0 end type d1 type d2 type(d1) k end type d2 type d3 type(d2) d(2) end type d3 type(d3) der namelist /nmlst/ der read (*, nml = nmlst) print nmlst end program namelist Running above program on all two line combinations of the namelist gives different errors using 4.7.2 and gcc version 4.8.0 20130222 (experimental) (GCC) (Details below). Observations: - If type d3 uses 'type(d1) d(2)' instead of 'type(d2) d(2)', the problem goes away. - If the trailing %J is removed in the namelist, the problem goes away. - If two separate members are used instead of the array 'type(d2) d(2)', the problem goes away. Details of namelist variations: % cat namelist.txt; echo ---; prg_namelist_bug < namelist.txt &NMLST / --- &NMLST DER%D(1)%K%J= 0, DER%D(2)%K%J= 0, / % cat namelist.txt; echo ---; prg_namelist_bug < namelist.txt &NMLST DER%D(1)%K%J = 1, / --- &NMLST DER%D(1)%K%J= 1, DER%D(2)%K%J= 0, / % cat namelist.txt; echo ---; prg_namelist_bug < namelist.txt &NMLST DER%D(2)%K%J = 2, / --- &NMLST DER%D(1)%K%J= 2, DER%D(2)%K%J= 0, / % cat namelist.txt; echo ---; prg_namelist_bug < namelist.txt &NMLST DER%D(1)%K%J = 1, DER%D(2)%K%J = 2, / --- &NMLST DER%D(1)%K%J= 2, DER%D(2)%K%J= 0, / % cat namelist.txt; echo ---; prg_namelist_bug < namelist.txt &NMLST DER%D(2)%K%J = 2, DER%D(1)%K%J = 1, / --- &NMLST DER%D(1)%K%J= 1, DER%D(2)%K%J= 0, / If the last component %J is removed in the namelist, the problem goes away: % cat namelist.txt; echo ---; prg_namelist_bug < namelist.txt &NMLST DER%D(1)%K = 1, / --- &NMLST DER%D(1)%K%J= 1, DER%D(2)%K%J= 0, / % cat namelist.txt; echo ---; prg_namelist_bug < namelist.txt &NMLST DER%D(2)%K = 2, / --- &NMLST DER%D(1)%K%J= 0, DER%D(2)%K%J= 2, / % cat namelist.txt; echo ---; prg_namelist_bug < namelist.txt &NMLST DER%D(1)%K = 1, DER%D(2)%K = 2, / --- &NMLST DER%D(1)%K%J= 1, DER%D(2)%K%J= 2, / % cat namelist.txt; echo ---; prg_namelist_bug < namelist.txt &NMLST DER%D(2)%K = 2, DER%D(1)%K = 1, / --- &NMLST DER%D(1)%K%J= 1, DER%D(2)%K%J= 2, / Regards, Tilo
[Bug c++/56243] [4.8 regression] ICE in tree check: expected field_decl, have identifier_node in fixed_type_or_null, at cp/class.c:6645
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56243 --- Comment #2 from Jason Merrill 2013-02-22 21:02:04 UTC --- Any news on this bug? It's one of only a few P1 regressions left.
[Bug c++/56429] New: [C++11] Explicitly defaulted private constructor is not private
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56429
Bug #: 56429
Summary: [C++11] Explicitly defaulted private constructor is
not private
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
class A
{
A() = default;
};
struct B : A { };
B b;
This should be rejected, but 4.6, 4.7 and 4.8 accept it.
(4.4 also accepts it, while 4.5 rejects it for a different reason.)
[Bug c++/56421] Non-matching overload produces template substitution error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56421 --- Comment #7 from Daniel Krügler 2013-02-22 22:01:18 UTC --- (In reply to comment #4) > I think 13.3 [over.match] ¶2 and 13.3.1 [over.match.funcs] ¶7 say the > function > template specialization must be generated before the number of arguments is > checked to see if the candidate function is viable. After a cross-check with the core language group I completely agree with Jonathan and exactly because of the paragraphs he quoted. Further-on, the example is ill-formed, but no diagnostics required, as of [temp.inst]p6: "If the overload resolution process can determine the correct function to call without instantiating a class template definition, it is unspecified whether that instantiation actually takes place." This sentence explains the implementation divergence (Thanks to Richard Smith for reminding me to this part).
[Bug c++/56421] Non-matching overload produces template substitution error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56421 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #8 from Jonathan Wakely 2013-02-22 22:17:06 UTC --- Thanks, Daniel.
[Bug c++/56395] [4.7/4.8 Regression] ICE, Segmentation fault in tsubst
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56395 --- Comment #8 from Jason Merrill 2013-02-22 22:24:05 UTC --- Author: jason Date: Fri Feb 22 22:23:56 2013 New Revision: 196228 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196228 Log: PR c++/56395 * tree.c (strip_typedefs): Strip typedefs from TYPENAME_TYPE template args. Added: trunk/gcc/testsuite/g++.dg/template/typename19.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c
[Bug c++/56359] [4.8 regression] Bogus "error: no matching function for call to ..."
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56359 --- Comment #2 from Jason Merrill 2013-02-22 22:24:26 UTC --- Author: jason Date: Fri Feb 22 22:24:10 2013 New Revision: 196229 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196229 Log: PR c++/56359 * call.c (can_convert_arg): Discard access checks. Added: trunk/gcc/testsuite/g++.dg/template/access25.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c
[Bug c++/56377] [4.8 Regression] template args in substitution-failure diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56377 --- Comment #3 from Jason Merrill 2013-02-22 22:24:40 UTC --- Author: jason Date: Fri Feb 22 22:24:27 2013 New Revision: 196230 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196230 Log: PR c++/56377 * pt.c (fn_type_unification): Use explicit args in template instantiation context. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/40405] [4.6/4.7/4.8 Regression] ICE with invalid initialization of template member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40405 --- Comment #7 from Jason Merrill 2013-02-22 22:24:52 UTC --- Author: jason Date: Fri Feb 22 22:24:40 2013 New Revision: 196231 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196231 Log: PR c++/40405 * pt.c (push_template_decl_real): Set DECL_INTERFACE_KNOWN if we got the wrong number of template parms. Added: trunk/gcc/testsuite/g++.dg/template/error49.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/56395] [4.7/4.8 Regression] ICE, Segmentation fault in tsubst
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56395 --- Comment #9 from Jason Merrill 2013-02-22 22:26:19 UTC --- Author: jason Date: Fri Feb 22 22:26:08 2013 New Revision: 196232 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196232 Log: PR c++/56395 * tree.c (strip_typedefs): Strip typedefs from TYPENAME_TYPE template args. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/template/typename19.C Modified: branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/tree.c
[Bug c++/40405] [4.6/4.7/4.8 Regression] ICE with invalid initialization of template member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40405 --- Comment #8 from Jason Merrill 2013-02-22 22:26:38 UTC --- Author: jason Date: Fri Feb 22 22:26:20 2013 New Revision: 196233 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196233 Log: PR c++/40405 * pt.c (push_template_decl_real): Set DECL_INTERFACE_KNOWN if we got the wrong number of template parms. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/template/error49.C Modified: branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/pt.c
[Bug libstdc++/56430] New: In __airy: return-statement with a value, in function returning 'void'.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56430 Bug #: 56430 Summary: In __airy: return-statement with a value, in function returning 'void'. Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: 3dw...@verizon.net Created attachment 29525 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29525 Patch removing return of number from void function (returning from other functions). In __airy, an internal implementation function inside include/tr1/modified_bessel_func.tcc, there was a return of a number from a void function. This function was not used obviously - it was intended for a future extension that is slated for 4.9. It seems sensible to me however to fix the bug. This function is being used in new development. There's no reason to let it lie and there is little risk in fixing it. Testing the attached patch on x86_64-linux.
[Bug libstdc++/56430] In __airy: return-statement with a value, in function returning 'void'.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56430 --- Comment #1 from Ed Smith-Rowland <3dw4rd at verizon dot net> 2013-02-22 22:33:37 UTC --- Created attachment 29526 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29526 Patch with better test case. Added checks for new template functions.
[Bug rtl-optimization/56131] [4.8 regression] gcc.dg/pr56035.c ICEs gcc on sparc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56131 --- Comment #17 from vries at gcc dot gnu.org 2013-02-22 22:37:04 UTC --- > patch below. Bootstrapped and reg-tested on x86_64 (ada inclusive).
[Bug fortran/55117] Programs fails to read namelist (contains derived types objects)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55117 --- Comment #12 from Tilo Schwarz 2013-02-22 22:40:11 UTC --- (In reply to comment #11) > Running above program on all two line combinations of the namelist gives > different errors using > 4.7.2 and > gcc version 4.8.0 20130222 (experimental) (GCC) > (Details below). What I meant here was, that the namelist variations give different errors, not that 4.7.2 and 4.8.0 give different errors. Tilo
[Bug c++/56421] Non-matching overload produces template substitution error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56421 --- Comment #9 from Kristian Spangsege 2013-02-22 23:09:59 UTC --- Daniell, would you do me the favour of explaining exactly why you think my example is ill-formed?
[Bug c++/56421] Non-matching overload produces template substitution error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56421 --- Comment #10 from Kristian Spangsege 2013-02-22 23:11:13 UTC --- Daniel - excuse me :-)
[Bug c++/56421] Non-matching overload produces template substitution error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56421 --- Comment #11 from Jonathan Wakely 2013-02-22 23:20:28 UTC --- as explained in comment 6
[Bug libstdc++/56430] In __airy: return-statement with a value, in function returning 'void'.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56430 --- Comment #2 from Paolo Carlini 2013-02-22 23:23:16 UTC --- Normally we don't keep around functions like this. The issue is better resolved by simply removing it, for 4.8.0 and a corresponding patch is preapproved. In the future please don't open this kind of issue about internal details, just send a patch to the mailing list, thanks in advance.
[Bug c++/56421] Non-matching overload produces template substitution error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56421 --- Comment #12 from Kristian Spangsege 2013-02-22 23:38:47 UTC --- Yes, so far so good, but where does the standard say that if synthesis fails for a particular candidate function template declaration, during overload resolution, then the code is ill-formed?
[Bug tree-optimization/54000] [4.6/4.7/4.8 Regression] Performance breakdown for gcc-4.{6,7} vs. gcc-4.5 using std::vector in matrix vector multiplication (IVopts / inliner)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54000
Steven Bosscher changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
Summary|[4.6/4.7/4.8|[4.6/4.7/4.8 Regression]
|Regression][IVOPTS] |Performance breakdown for
|Performance breakdown for |gcc-4.{6,7} vs. gcc-4.5
|gcc-4.{6,7} vs. gcc-4.5 |using std::vector in matrix
|using std::vector in matrix |vector multiplication
|vector multiplication |(IVopts / inliner)
--- Comment #9 from Steven Bosscher 2013-02-22
23:40:35 UTC ---
(In reply to comment #8)
> Thanks for the reduced testcase. The innermost loops compare as follows:
>
> 4.5:
>
> .L7:
> movsd (%rbx,%rcx), %xmm0
> addq$8, %rcx
> mulsd 0(%rbp,%rdx), %xmm0
> addq$8, %rdx
> cmpq$24, %rdx
> addsd %xmm0, %xmm1
> movsd %xmm1, (%rsi)
> jne .L7
4.8 r196182 with "--param early-inlining-insns=2" (2 x the default value):
.L13:
movsd (%rdx), %xmm0
addq$8, %rdx
mulsd (%rsi,%rax), %xmm0
addq$8, %rax
cmpq$24, %rax
addsd %xmm0, %xmm1
movsd %xmm1, 8(%rdi,%rcx)
jne .L13
>
> 4.7:
>
> .L13:
> movq64(%rsp), %rdi
> movq80(%rsp), %rdx
> addq%rcx, %rdi
> addq%r8, %rdx
> movsd -8(%rax,%rdi), %xmm0
> mulsd (%rsi,%rax), %xmm0
> addq$8, %rax
> cmpq$24, %rax
> addsd (%rdx), %xmm0
> movsd %xmm0, (%rdx)
> jne .L13
This is similar to what 4.8 r196182 produces without inliner tweaks:
.L18:
movq%rcx, %rdi
addq64(%rsp), %rdi
movq%r8, %rdx
addq80(%rsp), %rdx
movsd -8(%rax,%rdi), %xmm0
mulsd (%rsi,%rax), %xmm0
addq$8, %rax
cmpq$24, %rax
addsd (%rdx), %xmm0
movsd %xmm0, (%rdx)
jne .L18
> so we seem to have a register allocation / spilling issue here as well
> as a bad induction variable choice. GCC 4.8 is not any better here.
All true, but in the end it looks like an inliner heuristics issue first
(as also suggested by comment #3).
[Bug tree-optimization/54000] [4.6/4.7/4.8 Regression] Performance breakdown for gcc-4.{6,7} vs. gcc-4.5 using std::vector in matrix vector multiplication (IVopts / inliner)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54000 --- Comment #10 from Steven Bosscher 2013-02-22 23:42:03 UTC --- (In reply to comment #9) > 4.8 r196182 with "--param early-inlining-insns=2" (2 x the default value): "--param early-inlining-insns=22"
[Bug go/56431] New: -lpthread should be added to -lgo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56431 Bug #: 56431 Summary: -lpthread should be added to -lgo Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go AssignedTo: i...@airs.com ReportedBy: hjl.to...@gmail.com Depends on: 56353 +++ This bug was initially created as a clone of Bug #56353 +++ libjava.jni/invocation/PR16923.c behaves differently, depending on linking with gold or ld. _Jv_RegisterClasses is weak reference and libgcj.so isn't on the linker command line. Since libgcj.so isn't on the linker command line, gold resolves _Jv_RegisterClasses to 0 and ld silently resolves it to _Jv_RegisterClasses in libgcj.so: [hjl@gnu-13 testsuite]$ readelf -sWr /tmp/PR16923.gold | grep _Jv_RegisterClasses 8: 0 NOTYPE WEAK DEFAULT UND _Jv_RegisterClasses 37: 0 NOTYPE WEAK DEFAULT UND _Jv_RegisterClasses [hjl@gnu-13 testsuite]$ readelf -sWr /tmp/PR16923.bfd | grep _Jv_RegisterClasses 00600cd0 00090007 R_X86_64_JUMP_SLOT 004005e0 _Jv_RegisterClasses + 0 9: 004005e0 0 FUNCWEAK DEFAULT UND _Jv_RegisterClasses 59: 004005e0 0 FUNCWEAK DEFAULT UND _Jv_RegisterClasses [hjl@gnu-13 testsuite]$] -lgo has the same issue. With the bfd linker, I got [hjl@gnu-mic-2 go]$ ld --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /lib/../lib/crt1.o /lib/../lib/crti.o /export/build/gnu/gcc-asan/build-x86_64-linux/gcc/testsuite/go/../../32/crtbegin.o -L/export/build/gnu/gcc-asan/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libgo -L/export/build/gnu/gcc-asan/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libgo/.libs -L/export/build/gnu/gcc-asan/build-x86_64-linux/gcc/testsuite/go/../../32 -L/lib/../lib -L/usr/lib/../lib -L/export/build/gnu/gcc-asan/build-x86_64-linux/gcc/testsuite/go/../.. array-1.o -lgobegin -lgo -lm --wrap=pthread_create -lgcc_s -lgcc -lc -lgcc_s -lgcc /export/build/gnu/gcc-asan/build-x86_64-linux/gcc/testsuite/go/../../32/crtend.o /lib/../lib/crtn.o ld: /export/build/gnu/gcc-asan/build-x86_64-linux/gcc/testsuite/go/../../32/libgcc.a(generic-morestack.o): undefined reference to symbol 'pthread_sigmask@@GLIBC_2.0' ld: note: 'pthread_sigmask@@GLIBC_2.0' is defined in DSO /lib/libpthread.so.0 so try adding it to the linker command line /lib/libpthread.so.0: could not read symbols: Invalid operation [hjl@gnu-mic-2 go]$ gold links, but it generates 51: 0 NOTYPE WEAK DEFAULT UND pthread_sigmask It means that go executables generated by bfd ld and gold may behave differently. Go driver should add -lpthread to -lgo if libgo.so is linked against libpthread.so.
[Bug c++/56421] Non-matching overload produces template substitution error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56421
--- Comment #13 from Kristian Spangsege
2013-02-22 23:46:04 UTC ---
Jonathan,
"The complete set" is the set *before* the number of arguments is considered to
find the viable subset. To synthesize the declaration Foo::type must be
known, and that type results in an error.
Why then is the following accepted (replaced "Foo::type" with "S::type"):
template struct Foo {
typedef typename S::type type;
};
template void foo();
template typename S::type foo(int);
int main()
{
foo();
}
[Bug c++/56421] Non-matching overload produces template substitution error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56421 --- Comment #14 from Kristian Spangsege 2013-02-23 00:02:55 UTC --- Jonathan, you say that: "Foo::type exists unconditionally, so SFINAE doesn't apply. The invalid type is not in the immediate context of the substitution." Could you point me to the relevant section(s) in the standard?
[Bug c++/56421] Non-matching overload produces template substitution error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56421 --- Comment #15 from Jonathan Wakely 2013-02-23 00:29:17 UTC --- [temp.deduct]/8 This is not the right place to learn C++, please use the gcc-help mailing list or another site.
[Bug c++/56421] Non-matching overload produces template substitution error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56421 --- Comment #16 from Jonathan Wakely 2013-02-23 00:31:00 UTC --- Or see http://isocpp.org/forums
[Bug c++/56421] Non-matching overload produces template substitution error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56421 --- Comment #17 from Kristian Spangsege 2013-02-23 01:35:02 UTC --- Dude, you are insulting my ego! :-) Anyway, thanks for pointing me to [temp.deduct]/8. SFINAE certainly does not apply in my example.
[Bug c++/56395] [4.7/4.8 Regression] ICE, Segmentation fault in tsubst
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56395 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from Jason Merrill 2013-02-23 01:58:54 UTC --- Fixed.
[Bug c++/56377] [4.8 Regression] template args in substitution-failure diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56377 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Jason Merrill 2013-02-23 01:59:20 UTC --- Fixed.
[Bug c++/56359] [4.8 regression] Bogus "error: no matching function for call to ..."
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56359 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Jason Merrill 2013-02-23 01:59:30 UTC --- Fixed.
[Bug c++/40405] [4.6/4.7/4.8 Regression] ICE with invalid initialization of template member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40405 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution||FIXED Target Milestone|4.6.4 |4.7.3 --- Comment #9 from Jason Merrill 2013-02-23 01:59:53 UTC --- Fixed for 4.7.3.
[Bug go/56432] New: libgo check should behave like the check target for all other target libraries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56432
Bug #: 56432
Summary: libgo check should behave like the check target for
all other target libraries
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
AssignedTo: i...@airs.com
ReportedBy: d...@gcc.gnu.org
the libgo testsuite unfortunately works not the same as all other testsuites
for the target libraries do work. Usually if you do want to test a multilib
build, you call
RUNTESTFLAGS="--target_board=unix\{,-m32,-mx32\}" make -k check
and only the check target for the default multilib is called. The check target
doesn't descend into the multilib directories. libgo however descends into the
non-default multilib targets and calls check there too. And then with the above
RUNTESTFLAGS, every go test is called nine times instead of three times, and
apparently fails the other six times.
Otoh, running the test without RUNTESTFLAGS, and having at least a multilib
which can't be run on the current kernel, tries to run all multilib
configurations, and fails every test in these (this is a common use case on
build daemon machines running kernels of an older release).
Please let libgo behave the same as the other target libraries for the check
target, even it does introduce some delta.
[Bug middle-end/55308] /usr/ports/lang/gcc48/work/build/sparc64-portbld-freebsd10.0/libstdc++-v3/src/.libs/libstdc++.so.6: Undefined symbol "__emutls_v._ThreadRuneLocale"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55308 --- Comment #8 from N8GCBP7SHNBTI79GINADGKJPRTLOCO2A at cmx dot ietfng.org 2013-02-23 03:13:27 UTC --- If I do not remove the -32 from configure and do a straight build out of the ports tree, I see this in my gcc/config.log: configure:23478: checking assembler for thread-local storage support configure:23491: /usr/local/bin/as -32 --fatal-warnings -o conftest.o conftest.s >&5 Assembler messages: Fatal error: selected target format 'elf32-sparc-freebsd' unknown configure:23494: $? = 1 configure: failed program was .section ".tdata","awT",@progbits foo:.long 25 .text sethi %tgd_hi22(foo), %o0 This appears to be the root cause of everything going south with the error Anton gave at the start of this thread, as xgcc is built without support for TLS, as I said in comment 2. I am at a loss to explain the error in comment 5, except to suggest that possibly some of the wrong lines were mutated (I did not check carefully; the actual patch I am using is available at https://github.com/nwf/nwf-patches/blob/master/freebsd-ports/gcc48-patch-sparc64-tls-fix and should apply with no complaints; I simply place it in my ports tree as /usr/ports/lang/gcc48/files/patch-sparc64-tls-fix and let the make magic do its magic.) "/usr/local/bin/as --version" says GNU assembler (GNU Binutils) 2.23.1 Copyright 2012 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `sparc64-portbld-freebsd9.1'. And unhelpfully its --target-help does indeed suggest that it knows about -32, but even invoking just "as -32" yields the "selected target format unknown" message above. "/usr/local/bin/objdump -H" says, among many other things, /usr/local/bin/objdump: supported targets: elf64-sparc-freebsd elf64-sparc elf32-sparc a.out-sunos-big elf64-little elf64-big elf32-little elf32-big plugin srec symbolsrec verilog tekhex binary ihex /usr/local/bin/objdump: supported architectures: sparc sparc:sparclet sparc:sparclite sparc:v8plus sparc:v8plusa sparc:sparclite_le sparc:v9 sparc:v9a sparc:v8plusb sparc:v9b plugin which may reveal something: there is no elf32-sparc-freebsd on that list... and indeed, looking inside the binutils sources, I see that there is special handling in bfd/elf64-sparc.c for FreeBSD that is absent in bfd/elf32-sparc.c. The story appears to be the same in the in-FreeBSD version of binutils in /usr/src. In fact, the only occurrence of "elf32-sparc-freebsd" at all binutils is in gas/config/tc-sparc.h, which seems like something of a bug in its own right. (Which I have filed, at http://sourceware.org/bugzilla/show_bug.cgi?id=15178 ) That said, all the binaries on my system (which is, as far as I know, relatively stock FreeBSD 9-STABLE) are ELF 64, not ELF 32, and so, fundamentally, I don't understand why configure is testing for the ability to build a 32 bit binary rather than the assembler's default. Possibly some systems require that; binutils on FreeBSD on sparc appears to require its negation. Does that help shed any light on the situation? Anything I've overlooked? Thanks. --nwf;
[Bug middle-end/56433] New: ICE in expand_asm_operands, at stmt.c:910
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56433
Bug #: 56433
Summary: ICE in expand_asm_operands, at stmt.c:910
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@gcc.gnu.org
Created attachment 29527
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29527
preprocessed source
seen with trunk 195917, works with 4.7 branch, fails with Linaro branch,
buildings without -O doesn't show the issue.
$ gcc -c -marm -mfpu=neon -O1 -c dxa.i
In file included from
/scratch/packages/tmp/4.8/libav-0.8.5/libavutil/intreadwrite.h:60:0,
from
/scratch/packages/tmp/4.8/libav-0.8.5/libavformat/dxa.c:22:
/scratch/packages/tmp/4.8/libav-0.8.5/libavutil/arm/intreadwrite.h: In function
'dxa_read_packet':
/scratch/packages/tmp/4.8/libav-0.8.5/libavutil/arm/intreadwrite.h:45:5:
internal compiler error: in expand_asm_operands, at stmt.c:910
__asm__ ("ldr %0, %1" : "=r"(v) : "m"(*(const uint32_t *)p));
^
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug c++/56403] [4.6/4.7/4.8 Regression] internal compiler error: in build_zero_init_1, at cp/init.c:279
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56403 --- Comment #6 from Jason Merrill 2013-02-23 05:22:22 UTC --- (In reply to comment #4) > Alternatively build_zero_init_1 could use RECORD_OR_UNION_CODE_P (TREE_CODE > (type)) instead of CLASS_TYPE_P (type). That makes sense to me.
[Bug middle-end/56433] [4.8 Regression] ICE in expand_asm_operands, at stmt.c:910
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56433 --- Comment #1 from Andrew Pinski 2013-02-23 05:23:08 UTC --- AV_RN32(buf + 5)) I bet http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00965.html fixes this issue too.
[Bug c/56434] New: document that __attribute__((__malloc__)) assumes returned pointer has BIGGEST_ALIGNMENT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56434 Bug #: 56434 Summary: document that __attribute__((__malloc__)) assumes returned pointer has BIGGEST_ALIGNMENT Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: c...@pobox.com The docs say that __attribute__((__malloc__)) only has one effect: informing the compiler that returned pointers do not alias other pointers. But reading the compiler output, and then reading gcc source code, proves that it also has a second effect: informing the compiler that returned pointers are aligned to BIGGEST_ALIGNMENT. To quote expand_call: /* The return value from a malloc-like function is a pointer. */ if (TREE_CODE (rettype) == POINTER_TYPE) mark_reg_pointer (temp, BIGGEST_ALIGNMENT); This should be added to the documentation. As a side issue, BIGGEST_ALIGNMENT changes on the i386 target depending on whether -mavx is specified (128 vs. 256). Is it really a good idea for gcc to assume different things about the behavior of malloc() depending on -mavx? It seems that perhaps an alignment of 128 should always be conferred on malloc on the i386 platform, regardless of -mavx? What would the new target macro be? SMALLEST_BIGGEST_ALIGNMENT? :)
