[Bug c++/57053] New: inaccurate message for ambiguous calls when in fact there is not valid candidate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57053
Bug #: 57053
Summary: inaccurate message for ambiguous calls when in fact
there is not valid candidate
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: akim.demai...@gmail.com
Hi all,
This is not a genuine bug report, I just wanted to point out that the error
message is not as clear as it could be: G++ uses "ambiguity" both to name the
situation where there are too many candidates, or not enough (ie. 0). In the
latter case, it would be more appropriate that there _no_ viable candidate,
instead of an "ambiguity".
My €0.02, meant to be useful.
$ cat foo.cc
int foo(int*);
int foo(char*);
int bar(int);
int main ()
{
foo(0);
foo(1);
bar("foo");
}
$ g++-mp-4.8 /tmp/foo.cc
/tmp/foo.cc: In function 'int main()':
/tmp/foo.cc:8:8: error: call of overloaded 'foo(int)' is ambiguous
foo(0);
^
/tmp/foo.cc:8:8: note: candidates are:
/tmp/foo.cc:1:5: note: int foo(int*)
int foo(int*);
^
/tmp/foo.cc:2:5: note: int foo(char*)
int foo(char*);
^
/tmp/foo.cc:9:8: error: call of overloaded 'foo(int)' is ambiguous
foo(1);
^
/tmp/foo.cc:9:8: note: candidates are:
/tmp/foo.cc:1:5: note: int foo(int*)
int foo(int*);
^
/tmp/foo.cc:1:5: note: no known conversion for argument 1 from 'int' to
'int*'
/tmp/foo.cc:2:5: note: int foo(char*)
int foo(char*);
^
/tmp/foo.cc:2:5: note: no known conversion for argument 1 from 'int' to
'char*'
/tmp/foo.cc:10:12: error: invalid conversion from 'const char*' to 'int'
[-fpermissive]
bar("foo");
^
/tmp/foo.cc:4:5: error: initializing argument 1 of 'int bar(int)'
[-fpermissive]
int bar(int);
^
For the records, clang.
$ clang++ /tmp/foo.cc
/tmp/foo.cc:8:3: error: call to 'foo' is ambiguous
foo(0);
^~~
/tmp/foo.cc:1:5: note: candidate function
int foo(int*);
^
/tmp/foo.cc:2:5: note: candidate function
int foo(char*);
^
/tmp/foo.cc:9:3: error: no matching function for call to 'foo'
foo(1);
^~~
/tmp/foo.cc:1:5: note: candidate function not viable: no known conversion from
'int' to
'int *' for 1st argument
int foo(int*);
^
/tmp/foo.cc:2:5: note: candidate function not viable: no known conversion from
'int' to
'char *' for 1st argument
int foo(char*);
^
/tmp/foo.cc:10:3: error: no matching function for call to 'bar'
bar("foo");
^~~
/tmp/foo.cc:4:5: note: candidate function not viable: no known conversion from
'const char [4]' to 'int' for 1st argument
int bar(int);
^
3 errors generated.
$
(Also, please note that the fact that G++ gives a signature (int foo(int)) is
somewhat misleading, as 0 and 1 do not behave equally here.)
[Bug c++/57053] inaccurate message for ambiguous calls when in fact there is not valid candidate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57053 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-24 CC||manu at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Manuel López-Ibáñez 2013-04-24 07:49:59 UTC --- I think you are right. There are also other issues with this output: printing foo(int) as you say is not very helpful, the use of error: for explanatory notes, and what is "near match"?
[Bug c/57051] Optimization regression in 4.8.0 from 4.7.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57051 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek 2013-04-24 08:05:49 UTC --- I can see it too; if we when using 4.8 use -O3 -fno-tree-vectorize, the code is the same as with 4.7.
[Bug tree-optimization/57051] Optimization regression in 4.8.0 from 4.7.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57051 --- Comment #2 from Marek Polacek 2013-04-24 08:10:21 UTC --- Well, one thing differs, 4.7 with -O3 aligns 'total' to .align 16 whereas 4.8 with -O3 -fno-tree-vectorize has .align 4
[Bug testsuite/57050] FAIL: gcc.c-torture/execute/pr56982.c compilation, -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57050 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-04-24 Blocks||56982 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Richard Biener 2013-04-24 08:17:03 UTC --- Not sure. I verified that a slightly adjusted testcase still fails and thus use jmp_buf, as other unguarded setjmp testcases do.
[Bug testsuite/57050] FAIL: gcc.c-torture/execute/pr56982.c compilation, -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57050 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #2 from Richard Biener 2013-04-24 08:22:02 UTC --- Author: rguenth Date: Wed Apr 24 08:21:04 2013 New Revision: 198218 URL: http://gcc.gnu.org/viewcvs?rev=198218&root=gcc&view=rev Log: 2013-04-24 Richard Biener PR testsuite/57050 * gcc.c-torture/execute/pr56982.c: Avoid sigjmp_buf use. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/execute/pr56982.c
[Bug tree-optimization/57051] [4.8/4.9 Regression] Optimization regression in 4.8.0 from 4.7.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57051
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work||4.7.3
Version|unknown |4.8.0
Keywords||missed-optimization
Last reconfirmed||2013-04-24
CC||glisse at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
Ever Confirmed|0 |1
Summary|Optimization regression in |[4.8/4.9 Regression]
|4.8.0 from 4.7.2|Optimization regression in
||4.8.0 from 4.7.2
Target Milestone|--- |4.8.1
--- Comment #3 from Richard Biener 2013-04-24
08:30:06 UTC ---
It seems scev_cprop doesn't do its job here.
(get_scalar_evolution
(scalar = total.1_8)
(scalar_evolution = {pretmp_14, +, _6 + 10}_1))
that's ok - SCCP doesn't provide any info in dumps, but I suppose it
fails to compute the number of iterations here(!?).
And we don't constant-fold the vectorized code:
pretmp_14 = total;
vect_total.18_44 = { 40, 60, 80, 100 } v>> 64;
vect_total.18_45 = vect_total.18_44 + { 40, 60, 80, 100 };
vect_total.18_46 = vect_total.18_45 v>> 32;
vect_total.18_47 = vect_total.18_46 + vect_total.18_45;
stmp_total.17_48 = BIT_FIELD_REF ;
vect_total.19_49 = stmp_total.17_48 + pretmp_14;
total.1_9 = vect_total.19_49 + 80;
total.1_20 = vect_total.19_49 + 170;
total = total.1_20;
because we do not constant-fold vector shifts. Two ways to attack the
problem (SCCP failure needs to be analyzed). In 4.7 SCCP works.
[Bug target/57052] missed optimization with rotate and mask
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57052 Alan Modra changed: What|Removed |Added Target||powerpc-linux Status|UNCONFIRMED |ASSIGNED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-04/msg01370.htm ||l Keywords||missed-optimization Last reconfirmed||2013-04-24 AssignedTo|unassigned at gcc dot |amodra at gmail dot com |gnu.org | Ever Confirmed|0 |1
[Bug c++/56915] [4.9 regression] ICE in symtab_add_to_same_comdat_group, at symtab.c:383
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56915 --- Comment #5 from Paolo Carlini 2013-04-24 09:16:20 UTC --- Normally patches go to gcc-patches.
[Bug c/57054] New: Compilation with -O3 passes, with -O2 fails (ARM/NEON)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57054 Bug #: 57054 Summary: Compilation with -O3 passes, with -O2 fails (ARM/NEON) Classification: Unclassified Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: nizamov.shaw...@gmail.com While learning ARM/NEON I found what seems to be a bug in GCC/ARM. The compilation of the same function fails with: == gcc -c -fPIC -fwrapv -O2 -fno-strict-aliasing -I/usr/include/python2.7 -march=armv7-a -mfpu=neon -mtune=cortex-a8 -fomit-frame-pointer -save-temps bug.c == and succeeds when -O2 is changed to -O3. The error message is: == In file included from bug.c:1:0: /usr/lib/gcc/arm-linux-gnueabihf/4.7/include/arm_neon.h: In function ‘streamV’: /usr/lib/gcc/arm-linux-gnueabihf/4.7/include/arm_neon.h:4994:48: error: argument must be a constant /usr/lib/gcc/arm-linux-gnueabihf/4.7/include/arm_neon.h:4994: confused by earlier errors, bailing out == It seems that problem is connected with these intrinsics: vget_lane_u8(vector, lane) vgetq_lane_u16(vector, lane) when the "lane" is specified as a variable, and not as a constant. == gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.7/lto-wrapper Target: arm-linux-gnueabihf Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.7.3-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libitm --enable-plugin --with-system-zlib --enable-objc-gc --with-cloog --enable-cloog-backend=ppl --disable-cloog-version-check --disable-ppl-version-check --enable-multiarch --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-werror --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf Thread model: posix gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1) == I am using the Beagleboard XM, with a Ubuntu Raring on it (kernel is custom compiled).
[Bug c/57054] Compilation with -O3 passes, with -O2 fails (ARM/NEON)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57054 --- Comment #1 from nizamov.shawkat at gmail dot com 2013-04-24 09:22:59 UTC --- Created attachment 29926 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29926 save-temps
[Bug c/57054] Compilation with -O3 passes, with -O2 fails (ARM/NEON)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57054 --- Comment #2 from nizamov.shawkat at gmail dot com 2013-04-24 09:23:48 UTC --- Created attachment 29927 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29927 Preprocessed source stored into file, please attach this to your bugreport.
[Bug middle-end/57003] gcc-4.8.0 breaks -O2 optimization with Wine(64) - links/info/bisect of commits included
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57003 Bernd Schmidt changed: What|Removed |Added CC||bernds at gcc dot gnu.org --- Comment #13 from Bernd Schmidt 2013-04-24 09:25:47 UTC --- We need at least preprocessed source of the failing code, produced with gcc -E.
[Bug c++/57041] [4.7/4.8/4.9 Regression] ICE in lookup_field_1, at cp/search.c:376 (with dot-prefixed structure initialisation)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57041 --- Comment #4 from Paolo Carlini 2013-04-24 09:28:19 UTC --- This is a Dup of testcase in Comment #2 of PR55365.
[Bug c++/56915] [4.9 regression] ICE in symtab_add_to_same_comdat_group, at symtab.c:383
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56915 --- Comment #6 from Shixiong 2013-04-24 09:36:13 UTC --- (In reply to comment #5) yes, I know that. I just want to let the bug submitter have a try. > Normally patches go to gcc-patches.
[Bug c++/56973] crash when capturing variables in nested lambdas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56973 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-24 Blocks||54367 Ever Confirmed|0 |1
[Bug c++/56970] SFINAE does not apply correctly to sizeof.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56970 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-04-24 AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Ever Confirmed|0 |1 --- Comment #2 from Paolo Carlini 2013-04-24 10:01:53 UTC --- Seems simple: missing propagation of complain.
[Bug c++/56970] SFINAE does not apply correctly to sizeof.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56970 Paolo Carlini changed: What|Removed |Added Severity|major |normal
[Bug tree-optimization/57051] [4.8/4.9 Regression] Optimization regression in 4.8.0 from 4.7.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57051 --- Comment #4 from Jakub Jelinek 2013-04-24 10:44:13 UTC --- Created attachment 29928 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29928 gcc49-pr57051.patch It isn't that hard to fold VEC_RSHIFT_EXPR, at least for the cases where the shift count is a multiple of element bitsize (the only case where GCC actually ever emits VEC_RSHIFT_EXPR right now). Untested (beyond checking this is folded into store of 450 again).
[Bug middle-end/57055] New: Incorrect CFG after transactional memory passes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57055 Bug #: 57055 Summary: Incorrect CFG after transactional memory passes Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: enkovich@gmail.com Transactional passes do not set cfun->calls_setjmp to true and do not fix CFG accordingly after adding __builtin__ITM_beginTransaction call having ECF_RETURNS_TWICE flag set. It leads to inconsistency which may be revealed with special calls flags recomputation. If I add DCE pass after transactional memory then flags are recomputed and CFG check fails because of call statements in the middle of basic block. Thus DCE pass after transactional memory causes ~250 new fails in 'make check'. Tried on 'gcc version 4.9.0 20130422 (experimental) (GCC)'
[Bug middle-end/57055] Incorrect CFG after transactional memory passes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57055 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek 2013-04-24 13:15:46 UTC --- I think the TM code was taking care of edges so far, so either this TM shouldn't be handled as ECF_RETURNS_TWICE for the purposes of the ab edge creation code added recently by Richard, or we should handle it like any other returns_twice.
[Bug c++/57038] Latest libreoffice compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #1 from Jan Hubicka 2013-04-24
13:35:36 UTC ---
Hmm, the failing test is:
/* Be sure that we never try to duplicate partitioned symbol
or add external symbol. */
gcc_assert (c != SYMBOL_EXTERNAL
&& (c == SYMBOL_DUPLICATE || !symbol_partitioned_p (node)));
now the caller is:
for (i = 0; i < n_nodes; i++)
{
if (symbol_partitioned_p ((symtab_node) order[i]))
continue;
current_order = order[i]->symbol.order;
if (!flag_toplevel_reorder)
while (varpool_pos < n_varpool_nodes
&& varpool_order[varpool_pos]->symbol.order < current_order)
{
if (!symbol_partitioned_p ((symtab_node)
varpool_order[varpool_pos]))
add_symbol_to_partition (partition, (symtab_node)
varpool_order[varpool_pos]);
varpool_pos++;
}
add_symbol_to_partition (partition, (symtab_node) order[i]);
total_size -= inline_summary (order[i])->size;
So what can fail here? Symbol_partitioned_p should be false because of the
firs ttest in loop. So one should conclude that c==SYMBOL_EXTERNAL that is
weird given that the order array is populated only with SYMBOL_PARTITIONED
items.
Can you, please, figure out what is value of c and symbol_partitioned_p test?
Honza
[Bug target/56797] [4.8 Regression] internal compiler error: in extract_insn, at recog.c:2150
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56797 --- Comment #3 from gretay at gcc dot gnu.org 2013-04-24 14:17:52 UTC --- Author: gretay Date: Fri Apr 19 12:55:26 2013 New Revision: 198091 URL: http://gcc.gnu.org/viewcvs?rev=198091&root=gcc&view=rev Log: 2013-04-19 Greta Yorsh PR target/56797 * config/arm/arm.c (load_multiple_sequence): Require SP as base register for loads if SP is in the register list. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c
[Bug target/56797] [4.8 Regression] internal compiler error: in extract_insn, at recog.c:2150
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56797 --- Comment #4 from gretay at gcc dot gnu.org 2013-04-24 14:18:04 UTC --- Author: gretay Date: Wed Apr 24 10:43:41 2013 New Revision: 198220 URL: http://gcc.gnu.org/viewcvs?rev=198220&root=gcc&view=rev Log: 2013-04-24 Greta Yorsh Backported from mainline. PR target/56797 * config/arm/arm.c (load_multiple_sequence): Require SP as base register for loads if SP is in the register list. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/arm/arm.c
[Bug target/56797] [4.8 Regression] internal compiler error: in extract_insn, at recog.c:2150
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56797 gretay at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from gretay at gcc dot gnu.org 2013-04-24 14:18:50 UTC --- Fixed.
[Bug bootstrap/57028] [4.9 regression] Fortran bootstrap fails due to missing zlib.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57028 gretay at gcc dot gnu.org changed: What|Removed |Added CC||gretay at gcc dot gnu.org, ||jb at gcc dot gnu.org --- Comment #1 from gretay at gcc dot gnu.org 2013-04-24 15:09:11 UTC --- Bootstrap fails with a similar error message on arm-linux (ubuntu) without that package.
[Bug bootstrap/57028] [4.9 regression] Fortran bootstrap fails due to missing zlib.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57028 Janne Blomqvist changed: What|Removed |Added AssignedTo|unassigned at gcc dot |jb at gcc dot gnu.org |gnu.org | --- Comment #2 from Janne Blomqvist 2013-04-24 15:28:52 UTC --- Thanks for notifying, this is certainly due to my patch to compress fortran module files. However, I'm a bit lost. I thought zlib was needed in any case as java and lto already use it. Furthermore, we have a copy of zlib in-tree already, shouldn't that be used unless --with-system-zlib is specified to configure (in which the user assumes responsibility for providing zkib.h)? Any ideas?
[Bug c++/56970] SFINAE does not apply correctly to sizeof.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56970 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.8.1 --- Comment #3 from Paolo Carlini 2013-04-24 15:43:16 UTC --- Fixed mainline and 4.8.1.
[Bug middle-end/57003] gcc-4.8.0 breaks -O2 optimization with Wine(64) - links/info/bisect of commits included
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57003 --- Comment #14 from Kirill Smirnov 2013-04-24 16:06:41 UTC --- Created attachment 29929 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29929 gcc -E output. Attached gcc -E output. Lines around 22354 are being investigated.
[Bug target/57056] New: Missed optimization of finite finite builtin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57056
Bug #: 57056
Summary: Missed optimization of finite finite builtin
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nel...@seznam.cz
Created attachment 29930
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29930
benchmark
Hi,
Current builtin finite is slower on attached benchmark than my version.
It also needs to load 64bit constants which is not friendly to code size.
My version is:
int finite4(double x)
{
uint64_t lx;
EXTRACT_WORDS64(lx,x);
lx=lx>>52;
return ((lx&0x7ff)!=0x7ff);
}
Most of uses of isfinite()/finite() function are in condition so I benchmark
finite in condition.
Benchmark is run by
for i in `seq 0 7`; do echo finite$i; gcc finite_bench.c -O3 -Wall -W
-fno-builtin-finite -Dfinite=finite$i; for j in `seq 1 8`; do /usr/bin/time -f
"%U" ./a.out; done; done
[Bug target/57057] New: Bad optimization on x86 for minps and maxps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57057 Bug #: 57057 Summary: Bad optimization on x86 for minps and maxps Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: math...@gaunard.com When optimization -O1 or greater is enabled, minps and maxps will incorrectly deal with nan values. icc gives the correct result. See the attached C testcase, with -O0 it displays the correct result: res1 = (1.00 1.00 1.00 1.00) res2 = (-nan -nan -nan -nan) res3 = (1.00 1.00 1.00 1.00) res4 = (-nan -nan -nan -nan) With -O1 it displays res1 = (1.00 1.00 1.00 1.00) res2 = (1.00 1.00 1.00 1.00) res3 = (-nan -nan -nan -nan) res4 = (-nan -nan -nan -nan) The same also happens with the double-precision and AVX variants.
[Bug target/57057] Bad optimization on x86 for minps and maxps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57057 --- Comment #1 from Mathias Gaunard 2013-04-24 16:42:23 UTC --- Created attachment 29931 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29931 bad optimisation testcase
[Bug c++/53721] [C++11] "this" not allowed in trailing return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53721 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution||FIXED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.9.0 --- Comment #2 from Jason Merrill 2013-04-24 16:48:00 UTC --- Fixed for 4.9.
[Bug rtl-optimization/57003] [4.8/4.9 Regression] gcc-4.8.0 breaks -O2 optimization with Wine(64) - links/info/bisect of commits included
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57003 Jakub Jelinek changed: What|Removed |Added Status|WAITING |NEW Component|middle-end |rtl-optimization Target Milestone|--- |4.8.1 Summary|gcc-4.8.0 breaks -O2|[4.8/4.9 Regression] |optimization with Wine(64) |gcc-4.8.0 breaks -O2 |- links/info/bisect of |optimization with Wine(64) |commits included|- links/info/bisect of ||commits included --- Comment #15 from Jakub Jelinek 2013-04-24 16:50:21 UTC --- Ah, ok, I can see it. To look at 22354 it helps to sed -i 's/^# .*$//', then look for 22354 in the dump. Seems the code is still correct at *.ce3 pass, Bernd's optimization kicks in during RA time before that and the pseudo holding buffer is assigned to %rdi before the call memcpy and assumed to live in %rax right after the call. But cprop_hardreg breaks this, changes the %rax after the memcpy call into %rdi, even when %rdi is call clobbered register, and even the call pattern contains (clobber (reg:DI 5 di)) and REG_DEAD note for the same register.
[Bug bootstrap/57028] [4.9 regression] Fortran bootstrap fails due to missing zlib.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57028 --- Comment #3 from Mikael Pettersson 2013-04-24 16:54:41 UTC --- As far as I understand it, there are two issues: 1. zlib isn't built unless some explicitly enabled component demands it; in my case (on x86_64) zlib was built since I had java enabled, but nothing in Fortran appears to declare a dependency on zlib. Maybe gcc/fortran/config-lang.in is the place to declare that? 2. The in-tree zlib isn't added automatically to include and library paths, components need to check for with_system_zlib and adjust their paths accordingly, c.f. libjava/configure.ac.
[Bug target/57054] Compilation with -O3 passes, with -O2 fails (ARM/NEON)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57054 Andrew Pinski changed: What|Removed |Added Keywords||error-recovery, ||ice-on-invalid-code Component|c |target --- Comment #3 from Andrew Pinski 2013-04-24 17:35:45 UTC --- The error message is correct, according to the ARM manual these intrinsic require a constant value. The reason why it works at -O3 is because the loop is fully unrolled.
[Bug libgcc/57058] New: Bootstrap problems on AIX (libgcc configure, 64-bit)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57058
Bug #: 57058
Summary: Bootstrap problems on AIX (libgcc configure, 64-bit)
Classification: Unclassified
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: schnet...@gmail.com
I am trying to bootstrap gcc 4.7.3 on AIX. Both xlc and gcc 4.2.0 are
pre-installed. The main issue I encountered is that I need to use the option
"-maix64" when building with gcc, as I otherwise encounter assembler errors
about ".llong" (but that's fine since I want to use 64 bits anyway).
I encountered a problem when the stage 1 compiler tries to build libgcc. The
stage 1 compiler still needs to use -maix64. However, libgcc's configure script
seems to ignore all ways in which I could add this to CFLAGS (BOOT_CFLAGS,
CFLAGS_FOR_TARGET). The symptoms are errors about ".llong", since the stage 1
compiler doesn't use -maix64.
I believe this is due to an error in the following lines from libgcc's
configure.ac:
{{{
AC_CACHE_CHECK([whether to use setjmp/longjmp exceptions],
[libgcc_cv_lib_sjlj_exceptions],
[AC_LANG_CONFTEST(
[AC_LANG_SOURCE([
void bar ();
void clean (int *);
void foo ()
{
int i __attribute__ ((cleanup (clean)));
bar();
}
])])
CFLAGS_hold=$CFLAGS
CFLAGS="--save-temps -fexceptions"
libgcc_cv_lib_sjlj_exceptions=unknown
AS_IF([ac_fn_c_try_compile],
[if grep _Unwind_SjLj_Resume conftest.s >/dev/null 2>&1; then
libgcc_cv_lib_sjlj_exceptions=yes
elif grep _Unwind_Resume conftest.s >/dev/null 2>&1; then
libgcc_cv_lib_sjlj_exceptions=no
fi])
CFLAGS=$CFLAGS_hold
rm -f conftest*
])
}}}
Note that these lines unconditionally set CFLAGS before compiling a test
program. Instead, they should presumably be adding to CFLAGS. When changing the
offending line to
CFLAGS="$CFLAGS --save-temps -fexceptions"
the bootstrap went past this problem.
[Bug bootstrap/57059] New: Host configuration of loose_warn breaks for build components for Canadian crosses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57059 Bug #: 57059 Summary: Host configuration of loose_warn breaks for build components for Canadian crosses Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: rmansfi...@qnx.com When the building a canadian cross with a build compiler that is gcc 4.6 or older, the build cannot compile the build tools as configure will detect that the cross compiler has support for -Wno-narrowing, and will try to pass it along in the BUILD_CXXFLAGS. e.g. g++ -c-DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc -I../../gcc/build -I../../gcc/../include -I../../gcc/../libcpp/include -I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc/../libbacktrace \ -o build/genconstants.o ../../gcc/genconstants.c cc1plus: error: unrecognized command line option "-Wno-narrowing" make[3]: *** [build/genconstants.o] Error 1 $ grep acx_cv_prog_cc_warning__Wnarrowing gcc/config.log acx_cv_prog_cc_warning__Wnarrowing=yes
[Bug rtl-optimization/57003] [4.8/4.9 Regression] gcc-4.8.0 breaks -O2 optimization with Wine(64) - links/info/bisect of commits included
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57003
--- Comment #16 from Jakub Jelinek 2013-04-24
18:24:23 UTC ---
Reduced testcase (non-runtime, but one can see that %rdi which should be
clobbered by the memcpy call is used immediately after the memcpy call).
Probably wouldn't be too hard to turn this into an executable testcase, by
adding some noinline/noclone attributes, define bar, baz functions, and in main
initialize b.
const unsigned short *b, *c;
unsigned bar (void);
unsigned short *baz (unsigned long);
void __attribute__ ((ms_abi))
test (void)
{
unsigned d;
unsigned short *e;
if ((d = bar ()))
{
e = baz (d * sizeof (unsigned short) + 20);
__builtin_memcpy (e, b, d * sizeof (unsigned short));
c = e;
}
}
The ms_abi attribute seems to be essential for this, so perhaps something is
broken in the ms ABI support or when mixing the two ABIs?
[Bug bootstrap/57059] [4.8/4.9 Regression] Host configuration of loose_warn breaks for build components for Canadian crosses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57059 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Version|4.9.0 |4.8.0 Keywords||build Last reconfirmed||2013-04-24 Ever Confirmed|0 |1 Summary|Host configuration of |[4.8/4.9 Regression] Host |loose_warn breaks for build |configuration of loose_warn |components for Canadian |breaks for build components |crosses |for Canadian crosses Target Milestone|--- |4.8.1 --- Comment #1 from Andrew Pinski 2013-04-24 18:37:06 UTC --- Confirmed. I ran into this also but with 4.8.0.
[Bug target/57056] Missed optimization of finite finite builtin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57056 --- Comment #1 from Marc Glisse 2013-04-24 18:43:08 UTC --- Some relevant links: PR 56944 http://sourceware.org/bugzilla/show_bug.cgi?id=15384 http://sourceware.org/ml/libc-alpha/2013-04/msg00568.html Note that on my core2 laptop, it is not obvious that this would be a speed improvement (I see a very small slowdown, but those are all very close anyway). Code size might be an easier way to judge.
[Bug rtl-optimization/57003] [4.8/4.9 Regression] gcc-4.8.0 breaks -O2 optimization with Wine(64) - links/info/bisect of commits included
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57003
--- Comment #17 from Jakub Jelinek 2013-04-24
18:45:28 UTC ---
Runtime testcase for -O2, works with -O2 -fno-cprop-registers.
It doesn't fail always, but around in 50% of cases, and heavily depends on what
glibc is in use and what CPU too (as contemporary glibc's have IFUNC memcpy and
select implementations based on cpuid).
#define N 2001
unsigned short *b, *c, *d;
__attribute__ ((noinline, noclone)) unsigned
bar (void)
{
asm volatile ("" : : : "memory");
return N;
}
__attribute__ ((noinline, noclone)) unsigned short *
baz (unsigned long x)
{
if (x != N * sizeof (unsigned short) + 20)
__builtin_abort ();
asm volatile ("" : : : "memory");
return d;
}
__attribute__ ((ms_abi, noinline, noclone))
foo (void)
{
unsigned d;
unsigned short *e;
if ((d = bar ()))
{
e = baz (d * sizeof (unsigned short) + 20);
__builtin_memcpy (e, b, d * sizeof (unsigned short));
c = e;
}
}
int
main ()
{
unsigned short a[2 * N];
int i;
for (i = 0; i < 2 * N; i++)
a[i] = i + 1;
b = a;
d = a + N;
asm volatile ("" : : : "memory");
foo ();
for (i = 0; i < N; i++)
if (a[i] != i + 1 || a[i + N] != i + 1)
__builtin_abort ();
if (c != a + N)
__builtin_abort ();
return 0;
}
[Bug c++/56859] alignas() fails in template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56859
Ruben Van Boxem changed:
What|Removed |Added
CC||vanboxem.ruben at gmail dot
||com
--- Comment #3 from Ruben Van Boxem
2013-04-24 19:09:57 UTC ---
Another simple case that fails (even without instantiation) is:
template
struct aligned_storage
{
using type = struct { alignas(alignment) unsigned char data[size]; };
};
from http://en.cppreference.com/w/cpp/types/aligned_storage
The error is:
error: requested alignment is not an integer constant
using type = struct { alignas(alignment) unsigned char data[size]; };
^
[Bug libstdc++/57060] New: std::this_thread::get_id() == std::thread::id::id() without -pthread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57060
Bug #: 57060
Summary: std::this_thread::get_id() == std::thread::id::id()
without -pthread
Classification: Unclassified
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
#include
#include
int main()
{
std::thread::id me = std::this_thread::get_id();
std::thread::id nobody;
assert( me != nobody );
}
This program should always succeed, but on GNU/Linux when not linking to
libpthread.so the return value of pthread_self() is pthread_t(0) i.e. the same
as the value set by the default-constructor of std::thread::id
One solution would be to use a different value for the default-constructed
value, possibly -1 if that cannot be a value pthread_t value.
We still have the issue I described at
http://gcc.gnu.org/ml/libstdc++/2011-03/msg00068.html regarding using
pthread_equal() on invalid thread IDs, which could be handled by making
operator== check for the invalid value and avoid a call to pthread_equal.
[Bug c/57061] New: [patch] gcc-4.7.3 has declarations after statements and fails to compile on old systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57061 Bug #: 57061 Summary: [patch] gcc-4.7.3 has declarations after statements and fails to compile on old systems Classification: Unclassified Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: williamba...@hotmail.com Created attachment 29932 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29932 patch to fix compile errors in gcc-4.7.3 gcc-4.7.3 has declarations after statements and fails to compile on old systems, for example, gcc-2.96 on Red Hat Linux 7.1. The attached patch fixes the errors. William
[Bug bootstrap/57028] [4.9 regression] Fortran bootstrap fails due to missing zlib.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57028 Janne Blomqvist changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-04/msg01464.htm ||l --- Comment #4 from Janne Blomqvist 2013-04-24 20:03:17 UTC --- Patch at http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01464.html .
[Bug middle-end/57061] [patch] gcc-4.7.3 has declarations after statements and fails to compile on old systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57061 Andrew Pinski changed: What|Removed |Added Keywords||build Status|UNCONFIRMED |RESOLVED Component|c |middle-end Resolution||FIXED Target Milestone|--- |4.7.4 --- Comment #1 from Andrew Pinski 2013-04-24 20:23:54 UTC --- Fixed by: Author: ebotcazou Date: Sun Apr 21 08:02:06 2013 New Revision: 198114 URL: http://gcc.gnu.org/viewcvs?rev=198114&root=gcc&view=rev Log: * cfgexpand.c (avoid_complex_debug_insns): Fix C++ism. cp/ * parser.c (cp_parser_late_return_type_opt): Likewise. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/cfgexpand.c branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/parser.c
[Bug target/56866] gcc 4.7.x/gcc-4.8.x with '-O3 -march=bdver2' misscompiles glibc-2.17/crypt/sha512.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56866
--- Comment #13 from Winfried Magerl 2013-04-24
20:58:13 UTC ---
Hi,
On Wed, Apr 17, 2013 at 09:49:15PM +, glisse at gcc dot gnu.org wrote:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56866
>
> --- Comment #12 from Marc Glisse 2013-04-17
> 21:49:15 UTC ---
> (In reply to comment #11)
> > If fixing broken gcc's XOP/FMA/FMA4-extensions on AMD-CPUs depends on my
> > ability to extract a stand-alone-test from glibc-testsuite then I'm
> > realy sorry for not having the necessary skills (as already stated).
>
> Skills can be learned, and the best way is through practice. Ideally someone
> with the right combination of knowledge, hardware and free time would look at
> it, and you seem to be the closest currently ;-)
Please ask me again in 17 years when I'm hopefully finished
with regular work. Easter-Holidays might give you the wrong
for my available spare time...
> > Why not simply using the failing test-cases from gcc-testsuite
> > which are all standalone and depends on XOP:
>
> Good idea. I suggest you pick a simple one:
>
> > +FAIL: gcc.target/i386/sse2-mul-1.c execution test
>
> it looks like a list of several tests in a row. If you can first replace the
> aborts with printf to determine the first one that fails, then remove
> everything after that point, you have already narrowed the issue quite a bit.
> Then you can try to simplify what remains. Ideally, you would get a program
> small enough that posting the dumps would show the obvious issue. Do make
> sure
> while reducing the program that it still works correctly without the bdver2
> option.
I've done some basic checks and according to gdb the first abort()
triggers with unmodified code. Replacing abort() with printf() does no
longer trigger the if-clause and the next abort() was called.
I've add a small tar-file with a simple shell-scipt check.sh which
builds two binaries with no-xop and xop as options. Tested with
self-build "gcc (GCC) 4.8.1 20130421" and stock OpenSuSE-12.3-compiler
"gcc (GCC) 4.7.2 20130108".
Searching for xop in bugzilla shows that there are bugs refering
to xop/sse2-mul-1.c/bdver2 but it looks like there's no real
progress in this area.
If you're waiting on me to become a c-developer we might have to
live with broken xop/fam/fam4-extension for the next 17 years.
For my self-build home-linux which is mostly a hobby I can live
with this simple patch:
--- gcc-4.8-noxop/gcc/config/i386/i386.c.orig 2013-04-12 20:49:09.181351855
+0200
+++ gcc-4.8-noxop/gcc/config/i386/i386.c2013-04-12 23:15:09.112185980
+0200
@@ -2976,9 +2976,9 @@
{"bdver2", PROCESSOR_BDVER2, CPU_BDVER2,
PTA_64BIT | PTA_MMX | PTA_SSE | PTA_SSE2 | PTA_SSE3
| PTA_SSE4A | PTA_CX16 | PTA_ABM | PTA_SSSE3 | PTA_SSE4_1
- | PTA_SSE4_2 | PTA_AES | PTA_PCLMUL | PTA_AVX | PTA_FMA4
- | PTA_XOP | PTA_LWP | PTA_BMI | PTA_TBM | PTA_F16C
- | PTA_FMA | PTA_PRFCHW | PTA_FXSR | PTA_XSAVE},
+ | PTA_SSE4_2 | PTA_AES | PTA_PCLMUL | PTA_AVX
+ | PTA_LWP | PTA_BMI | PTA_TBM | PTA_F16C
+ | PTA_PRFCHW | PTA_FXSR | PTA_XSAVE},
{"bdver3", PROCESSOR_BDVER3, CPU_BDVER3,
PTA_64BIT | PTA_MMX | PTA_SSE | PTA_SSE2 | PTA_SSE3
| PTA_SSE4A | PTA_CX16 | PTA_ABM | PTA_SSSE3 | PTA_SSE4_1
I'm still wondering why the extensions where enabled when the test-suite
shows 179 additinal FAIL in 36 different c-files (current gcc-4.8.branch).
If I can help testing feel free to send me an e-mail.
regards
winfried
[Bug other/57062] New: genattrtab reports errors in wrong file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57062 Bug #: 57062 Summary: genattrtab reports errors in wrong file Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: seg...@gcc.gnu.org genattrtab.c keeps track of the line number of all insns it reads (in struct insn_def), but not the file name. It reads all files before doing most work, and then whenever it calls error_with_line() that reports the last file read, not the file with the error.
[Bug c++/57063] New: Valid static_cast from data member to rvalue reference fails to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57063
Bug #: 57063
Summary: Valid static_cast from data member to rvalue reference
fails to compile
Classification: Unclassified
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ts...@mail.ru
G++ 4.8-20130418 fails to compile the following well-formed code:
using T = int;
struct X
{
T &&f()
{
return static_cast(value);
}
T &&value;
};
int main() {}
It issues the following error at the line with static_cast:
cannot bind ‘T {aka int}’ lvalue to ‘T&& {aka int&&}’
return static_cast(value);
Command line: g++ test.cpp -std=c++11 -pedantic -v
Output:
==
Using built-in specs.
COLLECT_GCC=../builds/gcc-4.8-20130418/target/bin/g++
COLLECT_LTO_WRAPPER=../builds/gcc-4.8-20130418/target/libexec/gcc/i686-pc-linux-gnu/4.8.1/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../Downloads/gcc_install/gcc-4.8-20130418/configure
--prefix=../builds/gcc-4.8-20130418/target --enable-languages=c,c++
--disable-werror
Thread model: posix
gcc version 4.8.1 20130418 (prerelease) (GCC)
COLLECT_GCC_OPTIONS='-std=c++11' '-Wpedantic' '-v' '-shared-libgcc'
'-mtune=generic' '-march=pentiumpro'
../builds/gcc-4.8-20130418/target/libexec/gcc/i686-pc-linux-gnu/4.8.1/cc1plus
-quiet -v -D_GNU_SOURCE test.cpp -quiet -dumpbase test.cpp -mtune=generic
-march=pentiumpro -auxbase test -Wpedantic -std=c++11 -version -o
/tmp/cc8uNbtW.s
GNU C++ (GCC) version 4.8.1 20130418 (prerelease) (i686-pc-linux-gnu)
compiled by GNU C version 4.8.1 20130418 (prerelease), GMP version 5.1.1,
MPFR version 3.1.2, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"../builds/gcc-4.8-20130418/target/lib/gcc/i686-pc-linux-gnu/4.8.1/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
../builds/gcc-4.8-20130418/target/lib/gcc/i686-pc-linux-gnu/4.8.1/../../../../include/c++/4.8.1
../builds/gcc-4.8-20130418/target/lib/gcc/i686-pc-linux-gnu/4.8.1/../../../../include/c++/4.8.1/i686-pc-linux-gnu
../builds/gcc-4.8-20130418/target/lib/gcc/i686-pc-linux-gnu/4.8.1/../../../../include/c++/4.8.1/backward
../builds/gcc-4.8-20130418/target/lib/gcc/i686-pc-linux-gnu/4.8.1/include
/usr/local/include
../builds/gcc-4.8-20130418/target/include
../builds/gcc-4.8-20130418/target/lib/gcc/i686-pc-linux-gnu/4.8.1/include-fixed
/usr/include
End of search list.
GNU C++ (GCC) version 4.8.1 20130418 (prerelease) (i686-pc-linux-gnu)
compiled by GNU C version 4.8.1 20130418 (prerelease), GMP version 5.1.1,
MPFR version 3.1.2, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 0f47b9d9fd89a439a6a420b23c88ecfa
test.cpp: In member function ‘T&& X::f()’:
test.cpp:7:39: error: cannot bind ‘T {aka int}’ lvalue to ‘T&& {aka int&&}’
return static_cast(value);
^
[Bug c++/57063] Valid static_cast from data member to rvalue reference fails to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57063
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-04-24
Ever Confirmed|0 |1
--- Comment #1 from Paolo Carlini 2013-04-24
21:44:16 UTC ---
The alias declaration doesn't play a role:
struct X
{
int&& f()
{
return static_cast(value);
}
int&& value;
};
[Bug libstdc++/56905] [C++11][DR 1130] std::copy_exception should be removed or no longer be used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56905 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.9.0 --- Comment #3 from Jonathan Wakely 2013-04-24 22:05:45 UTC --- Fixed on trunk by the following commit. Author: redi Date: Wed Apr 24 22:00:16 2013 New Revision: 198265 URL: http://gcc.gnu.org/viewcvs?rev=198265&root=gcc&view=rev Log: PR libstdc++/56905 * libsupc++/exception_ptr.h (copy_exception): Deprecate and move implementation to make_exception_ptr. * include/std/future (_State_base::_M_break_promise): Replace copy_exception with make_exception_ptr. * testsuite/18_support/exception_ptr/move.cc: Likewise. * testsuite/18_support/exception_ptr/rethrow_exception.cc: Likewise. * testsuite/30_threads/future/members/get2.cc: Likewise. * testsuite/30_threads/promise/members/set_exception.cc: Likewise. * testsuite/30_threads/promise/members/set_exception2.cc: Likewise. * testsuite/30_threads/promise/members/set_value2.cc: Likewise. * testsuite/30_threads/shared_future/members/get2.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/future trunk/libstdc++-v3/libsupc++/exception_ptr.h trunk/libstdc++-v3/testsuite/18_support/exception_ptr/move.cc trunk/libstdc++-v3/testsuite/18_support/exception_ptr/rethrow_exception.cc trunk/libstdc++-v3/testsuite/30_threads/future/members/get2.cc trunk/libstdc++-v3/testsuite/30_threads/promise/members/set_exception.cc trunk/libstdc++-v3/testsuite/30_threads/promise/members/set_exception2.cc trunk/libstdc++-v3/testsuite/30_threads/promise/members/set_value2.cc trunk/libstdc++-v3/testsuite/30_threads/shared_future/members/get2.cc
[Bug target/56716] during gcc 4.8.0 build on Cygwin: bid128_fma.c:4460:1: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56716 Greg changed: What|Removed |Added CC||gccbugzi...@tru-traffic.com --- Comment #4 from Greg 2013-04-24 23:53:15 UTC --- (In reply to comment #3) > Author: rguenth > Date: Wed Mar 27 15:10:50 2013 > New Revision: 197165 > > URL: http://gcc.gnu.org/viewcvs?rev=197165&root=gcc&view=rev > Log: > 2013-03-27 Richard Biener > > PR tree-optimization/56716 > * tree-ssa-structalias.c (perform_var_substitution): Adjust > dumping for ref nodes. > > Modified: > trunk/gcc/ChangeLog > trunk/gcc/tree-ssa-structalias.c > > Fixed the issue on trunk. Back to analysis. I get the same error, and merging revision 197165 from trunk into my working-directory for gcc-4_8-branch revision 198253 did not fix the error on my system. This error occured during one of the stages while building gcc, revision 198065, checked out from svn://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch for MinGW32, Windows 7 Pro 64-bit SP1. The error also occurs with revisions 198027 and 198253 -- that is, the error has been occuring with revisions for at least these past 7 days. The error persists after I merged revision 197165 from trunk into my working-directory for gcc-4_8-branch revision 198253.
[Bug c++/57064] New: [clarification requested] Which overload with ref-qualifier should be called?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57064
Bug #: 57064
Summary: [clarification requested] Which overload with
ref-qualifier should be called?
Classification: Unclassified
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thi...@kde.org
I'm not sure this is a bug. I am requesting clarification on the behaviour.
>From the C++11 standard (13.3.3.2 [over.ics.rank] p 3):
struct A {
void p() &;
void p() &&;
};
void f()
{
A a;
a.p();
A().p();
}
GCC 4.8.1 correctly calls the lvalue-ref overload first, then the rvalue
overload second.
Now suppose the following function:
void g(A &&a)
{
a.p();
}
Which overload should GCC call? This is my request for clarification. I
couldn't find anything specific in the standard that would help explain one way
or the other.
Intuitively, it would be the rvalue overload, but gcc calls the lvalue overload
instead. Making it:
std::move(a).p();
Does not help.
[Bug c++/57064] [clarification requested] Which overload with ref-qualifier should be called?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57064
--- Comment #1 from Thiago Macieira 2013-04-25 00:45:00
UTC ---
Here's why I'm asking:
QString has members like:
QString arg(int, [other parameters]) const;
Which are used like so:
return QString("%1 %2 %3 %4").arg(42).arg(47).arg(-42).arg(-47);
// returns "42 47 -42 -47"
Right now, each call creates a new temporary, which is required to do memory
allocation. I'd like to avoid the new temporaries by simply reusing the
existing ones:
QString arg(int, [...]) const &; // returns a new copy
QString &&arg(int, [...]) &&; // modifies this object, return *this;
When these two overloads are present, every other call will be to rvalue-ref
and the others to lvalue-ref. That is, the first call (right after the
constructor) calls arg()&&, which returns an rvalue-ref. The next call will be
to arg()&, which returns a temporary, making the third call to arg()&& again.
I can get the desired behaviour by using the overloads:
QString arg(int, [...]) const &; // returns a new copy
QString arg(int, [...]) &&; // returns a moved temporary via return
std::move(*this);
However, the side-effect of that is that we still have 4 temporaries too many,
albeit empty (moved-out) ones. You can see this by counting the number of calls
to the destructor:
$ ~/gcc4.8/bin/g++ -fverbose-asm -fno-exceptions -fPIE -std=c++11 -S -o -
-I$QTOBJDIR/include /tmp/test.cpp | grep -B1 call.*QStringD
movq%rax, %rdi # tmp82,
call_ZN7QStringD1Ev@PLT #
--
movq%rax, %rdi # tmp83,
call_ZN7QStringD1Ev@PLT #
--
movq%rax, %rdi # tmp84,
call_ZN7QStringD1Ev@PLT #
--
movq%rax, %rdi # tmp85,
call_ZN7QStringD1Ev@PLT #
[Bug c++/57064] [clarification requested] Which overload with ref-qualifier should be called?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57064 --- Comment #2 from Thiago Macieira 2013-04-25 00:45:39 UTC --- This was a self-compiled, pristine GCC gcc version 4.8.1 20130420 (prerelease) (GCC) trunk at 198107
[Bug c++/57064] [clarification requested] Which overload with ref-qualifier should be called?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57064
--- Comment #3 from Thiago Macieira 2013-04-25 00:53:20
UTC ---
One more note. Given:
void p(A &);
void p(A &&);
void f(A &&a)
{
p(a);
}
like the member function case, this calls p(A &). It's slightly surprising at
first glance, but is a known and documented case.
Unlike the member function case, if you do
p(std::move(a));
it will call p(A &&).
[Bug target/57017] «Error: expecting string instruction after `rep'» in code w/o inline assembly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57017 --- Comment #8 from Alan Aversa 2013-04-25 02:53:02 UTC --- I upgraded to binutils 2.23.52.0.1 and the problem went away.
[Bug libstdc++/57065] New: incorrect default allocator template for debug and profile unordered_map
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57065 Bug #: 57065 Summary: incorrect default allocator template for debug and profile unordered_map Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: theonetrueke...@yahoo.com In libstdc++-v3/include/debug/unordered_map and libstdc++-v3/include/profile/unorderd_map, the unordered_map template is defined as: template, typename _Pred = std::equal_to<_Key>, typename _Alloc = std::allocator<_Key> > class unordered_map however, the correct definition (as reflected in bits/unordered_map.h) is: * @param Pred Predicate function object type, defaults to equal_to. * @param Alloc Allocator type, defaults to allocator. * * The resulting value type of the container is std::pair. */ template, class _Pred = std::equal_to<_Key>, class _Alloc = std::allocator > > class unordered_map note that the comment is wrong, but the code is correct. See also: http://www.cplusplus.com/reference/unordered_map/unordered_map/ which matches the definition in bits/unordered_map.h As far as I can tell, this error has existed since gcc 4.3.
[Bug c++/57064] [clarification requested] Which overload with ref-qualifier should be called?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57064
--- Comment #4 from Marc Glisse 2013-04-25 06:19:35
UTC ---
(In reply to comment #0)
> Now suppose the following function:
>
> void g(A &&a)
> {
> a.p();
> }
>
> Which overload should GCC call? This is my request for clarification. I
> couldn't find anything specific in the standard that would help explain one
> way
> or the other.
>
> Intuitively, it would be the rvalue overload, but gcc calls the lvalue
> overload
> instead.
As you note in a further comment, a named rvalue reference acts as an lvalue.
> Making it:
>
> std::move(a).p();
>
> Does not help.
It does for me...
[Bug c++/57064] [clarification requested] Which overload with ref-qualifier should be called?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57064 --- Comment #5 from Marc Glisse 2013-04-25 06:34:03 UTC --- (In reply to comment #4) > (In reply to comment #0) > > Making it: > > > > std::move(a).p(); > > > > Does not help. > > It does for me... Note that I only tested 4.9, it could be something missing in the backport.
[Bug c++/57064] [clarification requested] Which overload with ref-qualifier should be called?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57064
--- Comment #6 from Thiago Macieira 2013-04-25 06:51:33
UTC ---
void f(A &&a)
{
std::move(a).p();
}
_Z1fO1A:
.cfi_startproc
jmp _ZNR1A1pEv@PLT #
.cfi_endproc
Then this looks like a bug in 4.8.1.
But then are we in agreement that a.p() in that function above should call the
lvalue-ref overload? It does make the feature sligthly less useful for me. It
would require writing:
return std::move(std::move(std::move(std::move(QString("%1 %2 %3 %4")
.arg(42))
.arg(47))
.arg(-42))
.arg(-47));
