[Bug ipa/58329] [4.9 Regression] ld: Invalid symbol type for plabel (.libs/libstdc++.lax/libc++11convenience.a/system_error.o, std::error_category::default_error_condition(int) const [clone .localalia
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58329 --- Comment #10 from Jan Hubicka --- OK, I made similar patch on trip to Pisa. I think correct is to return NULL and make callers handle it - it does not make sense to consider non-local label to be local alias. I will test it and commit Honza
[Bug ipa/58345] ICE with SIGFPE at -O1 on x86_64-linux-gnu (affecting trunk and 4.8)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58345
Mikael Pettersson changed:
What|Removed |Added
CC||mikpe at it dot uu.se
--- Comment #1 from Mikael Pettersson ---
I can reproduce with 4.8 and trunk. Crashes due to division by zero in
fold_array_ctor_reference:
/* And offset within the access. */
inner_offset = offset % (elt_size.to_uhwi () * BITS_PER_UNIT);
Program received signal SIGFPE, Arithmetic exception.
0x005e2448 in fold_array_ctor_reference (ctor=0x77627ca8,
ctor=0x77627ca8, from_decl=0x77535be0, size=0, offset=0,
type=0x77645540)
at /mnt/scratch/gcc-4.9-20130901/gcc/gimple-fold.c:2816
2816 inner_offset = offset % (elt_size.to_uhwi () * BITS_PER_UNIT);
(gdb) print elt_size
$1 = {low = 0, high = 0}
(gdb) q
Note that the test case has a static array of an empty struct type.
[Bug middle-end/50385] missed-optimization: jump to __builtin_unreachable() not removed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50385 --- Comment #2 from Marc Glisse --- This seems to work on current trunk. Can you confirm, and if so close the PR? (well, we may want to add the testcases)
[Bug ipa/58346] ICE with SIGFPE at -O1 and above on x86_64-linux-gnu (affecting trunk, 4.8, 4.7, and 4.6)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58346
Mikael Pettersson changed:
What|Removed |Added
CC||mikpe at it dot uu.se
--- Comment #1 from Mikael Pettersson ---
Crashes with division-by-zero in the exact same spot as the PR58345 test case
does. However this test case also crashes 4.7 and 4.6.
Program received signal SIGFPE, Arithmetic exception.
0x005e2448 in fold_array_ctor_reference (ctor=0x77627ca8,
ctor=0x77627ca8, from_decl=0x77535be0, size=0, offset=0,
type=0x77645540)
at /mnt/scratch/gcc-4.9-20130901/gcc/gimple-fold.c:2816
2816 inner_offset = offset % (elt_size.to_uhwi () * BITS_PER_UNIT);
(gdb) list
2811 if (index_type)
2812access_index = access_index.ext (TYPE_PRECISION (index_type),
2813 TYPE_UNSIGNED (index_type));
2814
2815 /* And offset within the access. */
2816 inner_offset = offset % (elt_size.to_uhwi () * BITS_PER_UNIT);
2817
2818 /* See if the array field is large enough to span whole access. We
do not
2819 care to fold accesses spanning multiple array indexes. */
2820 if (inner_offset + size > elt_size.to_uhwi () * BITS_PER_UNIT)
(gdb) print elt_size
$1 = {low = 0, high = 0}
(gdb) q
[Bug tree-optimization/58359] New: __builtin_unreachable prevents vectorization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58359
Bug ID: 58359
Summary: __builtin_unreachable prevents vectorization
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
void f(int*q){
int*p=(int*)__builtin_assume_aligned(q,32);
for(int i=0;i<(1<<20);++i){
if(p+i==0)__builtin_unreachable();
p[i]=i;
}
}
If I remove the line with __builtin_unreachable, this is vectorized at -O3. But
as is, we have control flow in the loop and the vectorizer won't even try.
[Bug libstdc++/58358] search_n has a Complexity violation for random access iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358 Paolo Carlini changed: What|Removed |Added CC||chris at bubblescope dot net --- Comment #2 from Paolo Carlini --- This isn't the original HP/SGI algorithm, and was supposed to be an optimization, probably often is, but we can't violate the requirements so easily. Luckily Chris is around, let's ask him to look into this.
[Bug libstdc++/58358] [4.7/4.8/4.9 Regression] search_n has a Complexity violation for random access iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358 Paolo Carlini changed: What|Removed |Added Summary|search_n has a Complexity |[4.7/4.8/4.9 Regression] |violation for random access |search_n has a Complexity |iterator|violation for random access ||iterator --- Comment #3 from Paolo Carlini --- And this is a regression, old but still a regression. If we can't fix the new algorithm easily enough, we may have to return to the old one.
[Bug c++/58360] New: gcc crashes on boost::adaptors::transformed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58360 Bug ID: 58360 Summary: gcc crashes on boost::adaptors::transformed Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: vanyacpp at gmail dot com Created attachment 30763 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30763&action=edit gcc-crash-on-boost-adaptors-transformed I tried to use boost::adaptors::transformed and gcc crashed. Preprocessed code attached. Compile with -std=c++11. Version 4.7.3 (Ubuntu x64). Boost 1.48.
[Bug c++/58360] gcc crashes on boost::adaptors::transformed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58360 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.8.0, 4.9.0 Resolution|--- |FIXED --- Comment #1 from Paolo Carlini --- This is a Dup of many other issues. In any case, mainline and 4.8.x don't crash.
[Bug c++/57472] internal compiler error: in finish_member_declaration, at cp/semantics.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57472 tim blechmann changed: What|Removed |Added Attachment #30227|0 |1 is obsolete|| --- Comment #3 from tim blechmann --- Created attachment 30764 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30764&action=edit reduced testcase
[Bug libstdc++/58358] [4.7/4.8/4.9 Regression] search_n has a Complexity violation for random access iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358 --- Comment #4 from Chris Jefferson --- Just to say I see this, and fortunately it's not hard to keep the optimisation and meet the complexity requirements. Expect patch later today.
[Bug libstdc++/58358] [4.7/4.8/4.9 Regression] search_n has a Complexity violation for random access iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358 --- Comment #5 from Paolo Carlini --- Great, thanks Chris.
[Bug target/58361] New: Wrong floating point code generated for ARM target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58361
Bug ID: 58361
Summary: Wrong floating point code generated for ARM target
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: power at pobox dot sk
Created attachment 30765
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30765&action=edit
Preprocessed example code
Example code:
-
#include
static const float LANCE_SPEED = 0.5f;
float posx = 0.0f, posy = 0.0f;
float _deg = 0.0f;
float test(int cnt) {
float sp;
if (cnt < 10)
sp = LANCE_SPEED * cnt / 10;
else
sp = LANCE_SPEED;
float degSin = sin(_deg);
float degCos = cos(_deg);
posx += degSin * sp;
posy += degCos * sp;
return sp;
}
-
Compiling the example code with parameters "-c -O2 -pipe -march=armv7-a
-mcpu=cortex-a8 -mtune=cortex-a8 -mfpu=vfpv3 -mfloat-abi=softfp" generates
wrong code for the case when the input parameter is 10 or more.
The preprocessed source is in the attachment.
The result of "objdump -S -r" is:
-
shot2.o: file format elf32-littlearm
Disassembly of section .text:
:
0:e359 cmpr0, #9
4:e92d4010 push{r4, lr}
8:ed2d8b02 vpush{d8}
c:ceb68a00 vmovgt.f32s16, #96; 0x60
10:e24dd008 subsp, sp, #8
14:def27a04 vmovle.f32s15, #36; 0x24
18:de080a10 vmovles16, r0
1c:eeba8aef vcvt.f32.s32s16, s16, #1
20:de888a27 vdivle.f32s16, s16, s15
24:e59f403c ldrr4, [pc, #60]; 68
28:e28d1004 addr1, sp, #4
2c:e1a0200d movr2, sp
30:e594 ldrr0, [r4]
34:ebfe bl0
34: R_ARM_CALLsincosf
38:edd47a01 vldrs15, [r4, #4]
3c:ed947a02 vldrs14, [r4, #8]
40:eddd6a00 vldrs13, [sp]
44:ee067a88 vmla.f32s14, s13, s16
48:eddd6a01 vldrs13, [sp, #4]
4c:ee180a10 vmovr0, s16
50:ee467a88 vmla.f32s15, s13, s16
54:ed847a02 vstrs14, [r4, #8]
58:edc47a01 vstrs15, [r4, #4]
5c:e28dd008 addsp, sp, #8
60:ecbd8b02 vpop{d8}
64:e8bd8010 pop{r4, pc}
68: .word0x
68: R_ARM_ABS32.bss
-
The instruction at address c assigns the value 0.5f to register s16, and the
instruction at address 1c changes the value in register s16 (but it shouldn't,
in case r0 > 9).
I'm using a GCC crosscompiler for ARM linux (running on x64 linux) - gcc
version 4.7.3.
The result of "gcc -v" is:
-
Using built-in specs.
COLLECT_GCC=/opt/pandora/arm-2013.06.10/bin/pandora-gcc
COLLECT_LTO_WRAPPER=/opt/pandora/arm-2013.06.10/bin/../libexec/gcc/arm-cortex_a8-linux-gnueabi/4.7.3/lto-wrapper
Target: arm-cortex_a8-linux-gnueabi
Configured with: /home/roman/toolchain/.build/src/gcc-4.7.3/configure
--build=x86_64-build_unknown-linux-gnu --host=x86_64-build_unknown-linux-gnu
--target=arm-cortex_a8-linux-gnueabi
--prefix=/home/roman/x-tools/arm-cortex_a8-linux-gnueabi
--with-sysroot=/home/roman/x-tools/arm-cortex_a8-linux-gnueabi/arm-cortex_a8-linux-gnueabi/sysroot
--enable-languages=c,c++,d --with-arch=armv7-a --with-cpu=cortex-a8
--with-tune=cortex-a8 --with-fpu=vfpv3 --with-float=softfp
--with-pkgversion='crosstool-NG hg+unknown-20130627.210751'
--enable-__cxa_atexit --disable-libmudflap --disable-libgomp --disable-libssp
--disable-libquadmath --disable-libquadmath-support
--with-gmp=/home/roman/toolchain/.build/arm-cortex_a8-linux-gnueabi/buildtools
--with-mpfr=/home/roman/toolchain/.build/arm-cortex_a8-linux-gnueabi/buildtools
--with-mpc=/home/roman/toolchain/.build/arm-cortex_a8-linux-gnueabi/buildtools
--with-ppl=/home/roman/toolchain/.build/arm-cortex_a8-linux-gnueabi/buildtools
--with-cloog=/home/roman/toolchain/.build/arm-cortex_a8-linux-gnueabi/buildtools
--with-libelf=/home/roman/toolchain/.build/arm-cortex_a8-linux-gnueabi/buildtools
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm
-L/home/roman/toolchain/.build/arm-cortex_a8-linux-gnueabi/buildtools/lib
-lpwl' --enable-threads=posix --enable-target-optspace --disable-nls
--disable-multilib
--with-local-prefix=/home/roman/x-tools/arm-cortex_a8-linux-gnueabi/arm-cortex_a8-linux-gnueabi/sysroot
--enable-c99 --enable-long-long
Thread model: posix
gcc version 4.7.3 (crosstool-NG hg+unknown-20130627.210751)
-
[Bug c++/54941] do not print line/column numbers for :0:0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54941 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-09-08 CC|paolo.carlini at oracle dot com| Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Target Milestone|--- |4.9.0 Ever confirmed|0 |1 --- Comment #2 from Paolo Carlini --- Mine.
[Bug c++/58362] New: Wrong column number for unused parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58362
Bug ID: 58362
Summary: Wrong column number for unused parameter
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
void f (long s) { }
y.cc:1:6: warning: unused parameter 's' [-Wunused-parameter]
void f (long s) { }
^
Note the column information, which should point to s instead.
I tried the following:
--- function.c(revision 202365)
+++ function.c(working copy)
@@ -4997,21 +4997,22 @@ use_return_register (void)
void
do_warn_unused_parameter (tree fn)
{
tree decl;
for (decl = DECL_ARGUMENTS (fn);
decl; decl = DECL_CHAIN (decl))
if (!TREE_USED (decl) && TREE_CODE (decl) == PARM_DECL
&& DECL_NAME (decl) && !DECL_ARTIFICIAL (decl)
&& !TREE_NO_WARNING (decl))
- warning (OPT_Wunused_parameter, "unused parameter %q+D", decl);
+ warning_at (DECL_SOURCE_LOCATION (decl), OPT_Wunused_parameter,
+ "unused parameter %q+D", decl);
}
/* Generate RTL for the end of the current function. */
void
expand_function_end (void)
{
rtx clobber_after;
/* If arg_pointer_save_area was referenced only from a nested
And I checked in gdb, the first argument of warning_at has the right column
information, but it is ignored :-(
[Bug c++/58362] Wrong column number for unused parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58362 --- Comment #1 from Paolo Carlini --- Maybe it's just me, but I don't understand what -ignored- means in this context, could you please explain?
[Bug libstdc++/58358] [4.7/4.8/4.9 Regression] search_n has a Complexity violation for random access iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358 --- Comment #6 from Chris Jefferson --- I have a patch I believe fixes this, but trunk doesn't currently build on my machine (Bug 58340). I'll wait for that to get fixed. It is annoying there is still separate predicate and non-predicate copies of every function.
[Bug c++/58362] Wrong column number for unused parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58362 --- Comment #2 from Marc Glisse --- (In reply to Paolo Carlini from comment #1) > Maybe it's just me, but I don't understand what -ignored- means in this > context, could you please explain? It means that the diagnostic machinery takes the column information from somewhere else (I didn't really understand where) instead of using the one from the loc parameter.
[Bug libstdc++/58358] [4.7/4.8/4.9 Regression] search_n has a Complexity violation for random access iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358 --- Comment #7 from Paolo Carlini --- Yes, bootstrap is known to be broken, you can do: update -r202295 tree-ssa-threadedge.c
[Bug bootstrap/58340] [4.9 regression] gcc/cp/pt.c:7064:1: internal compiler error: in propagate_threaded_block_debug_into, at tree-ssa-threadedge.c:623
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58340 Jan Hubicka changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #12 from Jan Hubicka --- I am now seeing this ICE (in the same file) on x86_64-linux, too.
[Bug libstdc++/58358] [4.7/4.8/4.9 Regression] search_n has a Complexity violation for random access iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358 --- Comment #8 from Paolo Carlini --- About the duplication, you may want to review what Francois posted to the mailing list a few days ago and send your comments. Personally, I agree it would be very nice to avoid the duplication, but at the same time when I discussed the topic with Howard a few years ago he explained that there are some tricky details, in particular vs proxy-iterators, we want to be really sure that nothing breaks vs those, the "natural" idea of using std::less & co doesn't work, a beefed up version is required (this is horrible IMHO, but we may have to live with it). Again, if you are interested, please have a look to that patch. Thanks!
[Bug bootstrap/58340] [4.9 regression] gcc/cp/pt.c:7064:1: internal compiler error: in propagate_threaded_block_debug_into, at tree-ssa-threadedge.c:623
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58340 --- Comment #13 from Paolo Carlini --- Yeah Honza, all of us :(
[Bug c++/58362] Wrong column number for unused parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58362 --- Comment #3 from Paolo Carlini --- Oh I see, but that should be rather easy to track down.
[Bug libstdc++/58358] [4.7/4.8/4.9 Regression] search_n has a Complexity violation for random access iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358 --- Comment #9 from Daniel Krügler --- (In reply to Paolo Carlini from comment #8) > About the duplication, you may want to review what Francois posted to the > mailing list a few days ago and send your comments. Personally, I agree it > would be very nice to avoid the duplication, but at the same time when I > discussed the topic with Howard a few years ago he explained that there are > some tricky details, in particular vs proxy-iterators, we want to be really > sure that nothing breaks vs those, the "natural" idea of using std::less & > co doesn't work, a beefed up version is required (this is horrible IMHO, but > we may have to live with it). Shouldn't the library be able to use the new diamond operators (specializations in void) that use perfect forwarding for both arguments and result? User-code cannot specialize these operations.
[Bug bootstrap/58340] [4.9 regression] gcc/cp/pt.c:7064:1: internal compiler error: in propagate_threaded_block_debug_into, at tree-ssa-threadedge.c:623
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58340
--- Comment #14 from Jan Hubicka ---
I use the following workaround for time being.
Honza
Index: tree-ssa-threadedge.c
===
--- tree-ssa-threadedge.c(revision 202364)
+++ tree-ssa-threadedge.c(working copy)
@@ -1015,8 +1015,9 @@ thread_across_edge (gimple dummy_cond,
tmp = find_edge (taken_edge->src, path[path.length () - 1]->dest);
if (!tmp || phi_args_equal_on_edges (tmp, path[path.length () - 1]))
{
-propagate_threaded_block_debug_into (path[path.length () - 1]->dest,
- taken_edge->dest);
+if (path[path.length () - 1]->dest != taken_edge->dest)
+ propagate_threaded_block_debug_into (path[path.length () - 1]->dest,
+ taken_edge->dest);
register_jump_thread (path, true);
}
}
[Bug libstdc++/58358] [4.7/4.8/4.9 Regression] search_n has a Complexity violation for random access iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358 --- Comment #10 from Paolo Carlini --- Daniel, please send your comment to the mailing list, Francois wants to know. In any case, note that we want to have something for C++98 too, otherwise we can't really remove the duplicates. Or maybe those aren't *that* new, sorry I'm in the middle of too many other things ;) Anyway, this discussion is off topic here.
[Bug c++/54941] do not print line/column numbers for :0:0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54941 --- Comment #3 from paolo at gcc dot gnu.org --- Author: paolo Date: Sun Sep 8 14:30:27 2013 New Revision: 202366 URL: http://gcc.gnu.org/viewcvs?rev=202366&root=gcc&view=rev Log: 2013-09-08 Paolo Carlini PR c++/54941 * diagnostic.c (diagnostic_build_prefix): When s.file is "" don't output line and column numbers. /testsuite 2013-09-08 Paolo Carlini PR c++/54941 * g++.dg/overload/new1.C: Adjust. Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/diagnostic.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/overload/new1.C
[Bug c++/54941] do not print line/column numbers for :0:0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54941 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Paolo Carlini --- Done.
[Bug bootstrap/58340] [4.9 regression] gcc/cp/pt.c:7064:1: internal compiler error: in propagate_threaded_block_debug_into, at tree-ssa-threadedge.c:623
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58340 --- Comment #15 from Paolo Carlini --- Thanks Honza, I simply reverted Jeff' commit in my tree.
[Bug libstdc++/58358] [4.7/4.8/4.9 Regression] search_n has a Complexity violation for random access iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358 --- Comment #11 from Marc Glisse --- (In reply to Daniel Krügler from comment #9) > Shouldn't the library be able to use the new diamond operators > (specializations in void) that use perfect forwarding for both arguments and > result? User-code cannot specialize these operations. Perfect forwarding was never perfect, I wish that name hadn't stuck. http://gcc.gnu.org/ml/libstdc++/2012-06/msg00066.html
[Bug c++/58362] Wrong column number for unused parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58362 --- Comment #4 from Paolo Carlini --- The damage happens at error.c:3435. Should we just use "%qD", no '+' ?
[Bug c++/58362] Wrong column number for unused parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58362 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #5 from Manuel López-Ibáñez --- (In reply to Paolo Carlini from comment #4) > The damage happens at error.c:3435. Should we just use "%qD", no '+' ? Yes. And this is the reason I am against the magic +/# for location info. Unless you know (and keep remembering) the diagnostic machinery very well, the + doesn't mean anything and it is easy to miss, whereas "warning_at(DECL_SOURCE_LOCATION(decl)" seems pretty self-evident to me.
[Bug bootstrap/58340] [4.9 regression] gcc/cp/pt.c:7064:1: internal compiler error: in propagate_threaded_block_debug_into, at tree-ssa-threadedge.c:623
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58340 --- Comment #16 from Jeffrey A. Law --- Jan's patch papers over the problem of incorrect initialization of "found". I expect to be able to run through the formalities necessary to install the fix tonight. Reverting until I take care of things tonight is the better option.
[Bug c++/58362] Wrong column number for unused parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58362 --- Comment #6 from Marc Glisse --- (In reply to Paolo Carlini from comment #4) > The damage happens at error.c:3435. Yes, location_of replaces the declaration of the argument with that of the function :-( > Should we just use "%qD", no '+' ? I don't think I ever understood what '+' meant, or found the relevant doc. But the comment in front of location_of seems to agree with your solution. And indeed it works.
[Bug fortran/58331] [OOP] Bogus rank checking with explicit-/assumed-size arrays and CLASS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58331 Tobias Burnus changed: What|Removed |Added Keywords||wrong-code --- Comment #2 from Tobias Burnus --- Actually, the patch is sufficient as one then runs into a tree checking error: class_array_20.f90:21:0: error: non-trivial conversion at assignment struct array1_unknown struct array2_integer(kind=4) if one looks at the dump, one sees that the actual argument still sends the array descriptor - but it shouldn't: parm.7.dim[0].lbound = 1; ... parm.7.data = (void *) &b[0]; class.6._data = parm.7; mysub (&class.6, &C.1946); Thus, the test case also doesn't work for rank == 1, if one checks the value. TODO * Sends in _data the array data, not the descriptor * Add a test case for the coindexed part of the patch below. * Augment the test case in comment 0 with a value check Updated patch: --- a/gcc/fortran/interface.c +++ b/gcc/fortran/interface.c @@ -2135 +2135,5 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual, - || (actual->rank != 0 && !(is_elemental || formal->attr.dimension)) + || (actual->rank != 0 + && !(is_elemental + || (formal->ts.type != BT_CLASS && formal->attr.dimension) + || (formal->ts.type == BT_CLASS + && CLASS_DATA (formal)->attr.dimension))) @@ -2142 +2146,4 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual, - || (actual->rank == 0 && formal->attr.dimension + || (actual->rank == 0 + && (formal->attr.dimension + || (formal->ts.type == BT_CLASS + && CLASS_DATA (formal)->attr.dimension)) @@ -2150 +2157,4 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual, - else if (actual->rank != 0 && (is_elemental || formal->attr.dimension)) + else if (actual->rank != 0 + && (is_elemental || formal->attr.dimension + || (formal->ts.type == BT_CLASS + && CLASS_DATA (formal)->attr.dimension)))
[Bug c++/58362] Wrong column number for unused parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58362 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-08 Ever confirmed|0 |1 --- Comment #7 from Paolo Carlini --- Testing of C++ succeeded. I will test C too and in case will submit. I guess Honza can approve the patch.
[Bug c++/58362] Wrong column number for unused parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58362 Paolo Carlini changed: What|Removed |Added CC||hubicka at ucw dot cz --- Comment #8 from Paolo Carlini --- Honza can you review gcc/function.c changes?
[Bug c++/58363] New: Confusing error message for uncalled explicit destructor in expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58363
Bug ID: 58363
Summary: Confusing error message for uncalled explicit
destructor in expression
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ambrus at math dot bme.hu
Created attachment 30766
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30766&action=edit
Preprocessed C++ source producing the bug
Dear gcc maintainers,
Gcc gives a confusing error message for the attached incorrect C++ code. This
code uses explicit destructor call syntax but without the call parenthesis, as
in “m.~f” (where f is a type), inside an expression.
I am using gcc 4.8.1 amd64-linux, and the command line is “g++ -v -Wall -O
destroy.ii” . See the exact error messages below.
A correct error message might be “destroy.c:6:8: error: pseudo-destructor is
not called”.
$ cat destroy.ii
# 1 "destroy.cxx"
# 1 ""
# 1 "destroy.cxx"
struct l {};
template void operator+(l x, int y);
typedef unsigned short f;
int main() {
f m = 2;
l() + m.~f;
return 0;
}
$ g++ -v -Wall -O destroy.ii
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/gcc481/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.8.1/configure --prefix=/usr/local/gcc481
-with-gmp=/usr/local -with-mpfr=/usr/local -with-mpc=/usr/local
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.8.1 (GCC)
COLLECT_GCC_OPTIONS='-v' '-Wall' '-O' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
/usr/local/gcc481/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/cc1plus
-fpreprocessed destroy.ii -quiet -dumpbase destroy.ii -mtune=generic
-march=x86-64 -auxbase destroy -O -Wall -version -o /tmp/cc5XA0SF.s
GNU C++ (GCC) version 4.8.1 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.1, GMP version 5.0.1, MPFR version 3.0.0-p3,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=127409
GNU C++ (GCC) version 4.8.1 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.1, GMP version 5.0.1, MPFR version 3.0.0-p3,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=127409
Compiler executable checksum: 47191b782ec6877222820ebb50c2fe12
destroy.cxx: In function ‘int main()’:
destroy.cxx:6:6: error: no match for ‘operator+’ (operand types are ‘l’ and
‘void’)
l() + m.~f;
^
destroy.cxx:6:6: note: candidate is:
destroy.cxx:2:22: note: template void operator+(l, int)
template void operator+(l x, int y);
^
destroy.cxx:2:22: note: template argument deduction/substitution failed:
destroy.cxx:6:11: note: cannot convert ‘f.#‘var_decl’ not supported by
dump_type#::~’ (type ‘void’) to type ‘int’
l() + m.~f;
^
$
[Bug libstdc++/58358] [4.7/4.8/4.9 Regression] search_n has a Complexity violation for random access iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358 --- Comment #12 from Marc Glisse --- Chris, did you consider applying this optimized code to bidirectional iterators and not just random access iterators? We may end up doing a few more ++/-- than necessary, but not by more than a factor 2 I believe, and we would often save many calls to the predicate. Something may also be doable for forward iterators, but that's more complicated for less gain and couldn't share the same code.
[Bug c/58364] New: likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58364
Bug ID: 58364
Summary: likely wrong code bug
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: regehr at cs dot utah.edu
CC: chenyang at cs dot utah.edu
regehr@john-home ~/z/reduce/r107 $ gcc -O0 small.c ; ./a.out
regehr@john-home ~/z/reduce/r107 $ gcc -O1 small.c ; ./a.out
x
regehr@john-home ~/z/reduce/r107 $ cat small.c
int printf(const char *, ...);
int x3 (int x4) {
return x4 < 0 ? 1 : x4;
}
int x0 = 1, x1, x2;
int main (void) {
if (x3(x0 > x2 == (x1 = 0))) {
printf("x\n");
}
return 0;
}
regehr@john-home ~/z/reduce/r107 $ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/regehr/z/compiler-install/gcc-r202341-install/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/regehr/z/compiler-source/gcc/configure
--prefix=/home/regehr/z/compiler-install/gcc-r202341-install
--enable-languages=c,c++ --disable-multilib
Thread model: posix
gcc version 4.9.0 20130906 (experimental) (GCC)
[Bug c/58365] New: likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58365
Bug ID: 58365
Summary: likely wrong code bug
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: regehr at cs dot utah.edu
CC: chenyang at cs dot utah.edu
regehr@john-home ~/z/reduce/r109 $ clang -O small.c ; ./a.out
0
regehr@john-home ~/z/reduce/r109 $ gcc -O small.c ; ./a.out
0
regehr@john-home ~/z/reduce/r109 $ gcc -Os small.c ; ./a.out
1
regehr@john-home ~/z/reduce/r109 $ cat small.c
int printf(const char *, ...);
struct x0 {
volatile int x1;
int x2;
int x3;
int x4;
int x5;
} x6;
static struct x0 x7, x8;
int x9 = 1;
char x10();
static struct x0 x11() {
if (x10())
return x6;
return x7;
}
char x10() { return x9; }
int main() {
x8 = x11();
x6.x2 = 1;
printf("%d\n", x8.x2);
return 0;
}
regehr@john-home ~/z/reduce/r109 $ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/regehr/z/compiler-install/gcc-r202341-install/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/regehr/z/compiler-source/gcc/configure
--prefix=/home/regehr/z/compiler-install/gcc-r202341-install
--enable-languages=c,c++ --disable-multilib
Thread model: posix
gcc version 4.9.0 20130906 (experimental) (GCC)
regehr@john-home ~/z/reduce/r109 $
[Bug libstdc++/58358] [4.7/4.8/4.9 Regression] search_n has a Complexity violation for random access iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358 --- Comment #13 from Chris Jefferson --- Created attachment 30767 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30767&action=edit Bug patch Patch attached. This features: 1) As well as checking backwards when we find a match, check forwards too. Improve so we never do more than n checks in an array of size n. 2) Improve the existing tester (which tries all arrays up to length 15) to check the number of predicate calls. 3) Add the test included in this bug as a new test, just for completeness.
[Bug libstdc++/58358] [4.7/4.8/4.9 Regression] search_n has a Complexity violation for random access iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358 --- Comment #14 from Chris Jefferson --- (In reply to Marc Glisse from comment #12) > Chris, did you consider applying this optimized code to bidirectional > iterators and not just random access iterators? We may end up doing a few > more ++/-- than necessary, but not by more than a factor 2 I believe, and we > would often save many calls to the predicate. Something may also be doable > for forward iterators, but that's more complicated for less gain and > couldn't share the same code. I considered this, but as you say this would slow things down in some cases, and I've found bugs which cause slowdowns in any situation tend to have serious problems getting accepted.
[Bug rtl-optimization/58365] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58365 Marc Glisse changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-08 Component|c |rtl-optimization Ever confirmed|0 |1 --- Comment #1 from Marc Glisse --- Confirmed, from 4.6 to trunk. The .optimized dump looks ok (basically the same for -O2 and -Os), the dumps become very different at expansion (didn't check if the error appears in expand or later).
[Bug tree-optimization/58364] [4.8/4.9 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58364 Marc Glisse changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-08 Component|c |tree-optimization Summary|likely wrong code bug |[4.8/4.9 Regression] likely ||wrong code bug Ever confirmed|0 |1 --- Comment #1 from Marc Glisse --- Something strange seems to happen in reassoc.
[Bug c++/58366] New: thread_local class containing bound function leads to : "Illegal instruction: 4"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58366 Bug ID: 58366 Summary: thread_local class containing bound function leads to : "Illegal instruction: 4" Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jbcoe at me dot com Created attachment 30768 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30768&action=edit small program illustrating crash I've struggled to pare this bug down to a smaller example but noticed that invocation of a thread_local random number generating functor in GCC 4.8.1 caused a regular, though not always reproducible, crash that I did not see in Clang 3.3. Both thread_local and use of std::bind seem to be necessary to reproduce the crash. Code was compiled with -std=c++11
[Bug c++/58300] ICE: in decide_is_symbol_needed, at cgraphunit.c:233 with -fvtable-verify=preinit on invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58300 --- Comment #9 from ctice at gcc dot gnu.org --- Author: ctice Date: Sun Sep 8 21:58:07 2013 New Revision: 202371 URL: http://gcc.gnu.org/viewcvs?rev=202371&root=gcc&view=rev Log: Fix PR 58300: Re-order events with -fvtable-verify=preinit flag, so constructor init function is not written to assembly file until after call to cgraph_process_new_functions. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/vtable-class-hierarchy.c
[Bug c++/58300] ICE: in decide_is_symbol_needed, at cgraphunit.c:233 with -fvtable-verify=preinit on invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58300 Caroline Tice changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Caroline Tice --- See other comments.
[Bug c++/58366] invocation of thread_local class containing bound function leads to : "Illegal instruction: 4"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58366 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-09-08 Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini --- Which kind of crash? And which target? On x86_64-linux, I built (and ran 10-20 times) your snippet with: g++ GCC4.8Issues.cpp -std=c++11 -pthread and various optimization levels, with 4.8.0, current 4.8.x and current mainline and nothing special happened.
stl_list undefined error in compiling mysql
All, Got the following error in compiling the latest version of mysql (mysql-5.6.13). I'm not sure if this is a gcc problem or a mysql problem, but it looked very standard library related, so I thought I'd point it out here. I look at the stl_list.h file and see it is in an #if block, with #if __cplusplus >= 201103L # evaluating as false even though the version of gcc is 4.8.1. Doing a: gcc -dM -E /tmp/test.p shows __cplusplus defined as: #define __cplusplus 199711L which is clearly wrong for 4.8.1 (isn't it?) Any assistance on parsing or dealing with this error would be very much appreciated - just tried the alternate block in stl_ist.h without success. Ed ../../innobase/libinnobase.a(fil0fil.cc.o): In function `std::list >::_M_insert(std::_List_iterator, char co nst* const&)': /pub/tools/centos_64/include/c++/4.8.1/bits/stl_list.h:1554: undefined reference to `std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)' ../../../sql/libsql.a(handler.cc.o): In function `std::list >::_M_insert(std::_List_iterator, char const* co nst&)': /pub/tools/centos_64/include/c++/4.8.1/bits/stl_list.h:1554: undefined reference to `std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)' /pub/tools/centos_64/include/c++/4.8.1/bits/stl_list.h:1554: undefined reference to `std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)' ../../../sql/libsql.a(mysqld.cc.o): In function `std::list >::_M_insert(std::_List_iterator, THD* const&)': /pub/tools/centos_64/include/c++/4.8.1/bits/stl_list.h:1554: undefined reference to `std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)' ../../../sql/libsql.a(mysqld.cc.o): In function `std::list >::_M_erase(std::_List_iterator)': /pub/tools/centos_64/include/c++/4.8.1/bits/stl_list.h:1570: undefined reference to `std::__detail::_List_node_base::_M_unhook()' ../../../sql/libbinlog.a(binlog.cc.o): In function `std::list >::_M_insert(std::_List_iterator, std::string const&)': /pub/tools/centos_64/include/c++/4.8.1/bits/stl_list.h:1554: undefined reference to `std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)' /pub/tools/centos_64/include/c++/4.8.1/bits/stl_list.h:1554: undefined reference to `std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)' /pub/tools/centos_64/include/c++/4.8.1/bits/stl_list.h:1554: undefined reference to `std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)' /pub/tools/centos_64/include/c++/4.8.1/bits/stl_list.h:1554: undefined reference to `std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)'
[Bug tree-optimization/58364] [4.8/4.9 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58364 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |4.8.2 --- Comment #2 from Jakub Jelinek --- Started with r193028 . I'll have a look.
[Bug middle-end/57748] [4.7/4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #34 from Bernd Edlinger ---
Hmm, this was looking like a working example ((if it is valid C at all)),
but after some thougt, I saw now it exposes a data store race:
#include
#include
typedef long long V
__attribute__ ((vector_size (2 * sizeof (long long)), may_alias));
union x
{
long long a;
float b;
} __attribute__((aligned(1))) ;
struct s
{
union x xx[0];
V x;
} __attribute__((packed));
void __attribute__((noinline, noclone))
foo(struct s * x)
{
x->xx[0].a = -1;
x->xx[0].b = 3.14;
x->x[1] = 0x123456789ABCDEF;
}
int
main()
{
struct s ss;
memset(&ss, 0, sizeof(ss));
foo (&ss);
printf("%f %llX\n", ss.xx[0].b, ss.xx[0].a);
printf("%llX %llX\n", ss.x[0], ss.x[1]);
}
the resulting code is:
foo:
.LFB23:
.cfi_startproc
movdqu (%rdi), %xmm0
movabsq $-4294967296, %rdx
movq.LC1(%rip), %xmm1
psrldq $8, %xmm0
punpcklqdq %xmm0, %xmm1
movdqu %xmm1, (%rdi)
movdqu (%rdi), %xmm2
movdqa %xmm2, -24(%rsp)
movq-24(%rsp), %rax
andq%rdx, %rax
orq $1078523331, %rax
movq%rax, -24(%rsp)
movdqa -24(%rsp), %xmm3
movdqu %xmm3, (%rdi)
movdqu (%rdi), %xmm0
movhps .LC2(%rip), %xmm0
movdqu %xmm0, (%rdi)
ret
Which shows all read/write accesses are 16 byte at a time and this creates
a forbidden data store race.
Looks like I shot my own patch down now :-)
[Bug rtl-optimization/58365] [4.7/4.8/4.9 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58365 Jakub Jelinek changed: What|Removed |Added Target Milestone|4.8.2 |4.7.4
[Bug rtl-optimization/58365] [4.7/4.8/4.9 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58365 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||mkuvyrkov at gcc dot gnu.org Target Milestone|--- |4.8.2 Summary|likely wrong code bug |[4.7/4.8/4.9 Regression] ||likely wrong code bug --- Comment #2 from Jakub Jelinek --- Works still with r162588, fails with r162597, revisions in between those two don't build, so can't be bisected more. But it must be one of the GCSE changes in that range.
[Bug bootstrap/58304] gcc dev branch compilation Failed at libstdc++-v3 (used gcc 4.7.3 to compile)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58304 Harsha changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #8 from Harsha --- As Paolo stated, this error may be due to intermediate code sync up and compilation. But was not seen in later code sync. Therefore closing this case.
