[Bug c++/57168] New: [graphite] -fgraphite-identity breaks app-office/libreoffice-3.6.6.2 OpenXML filter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57168 Bug #: 57168 Summary: [graphite] -fgraphite-identity breaks app-office/libreoffice-3.6.6.2 OpenXML filter Classification: Unclassified Product: gcc Version: 4.7.2 URL: https://bugs.gentoo.org/show_bug.cgi?id=429766 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: de.tec...@gmail.com Earlier, libreoffice used to ask for the format of the document, now it says the file is corrupt and suggests to repair.
[Bug c++/57167] New: [graphite] Virtualbox 4.2.2 and above wont work with multiple CPUs.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57167 Bug #: 57167 Summary: [graphite] Virtualbox 4.2.2 and above wont work with multiple CPUs. Classification: Unclassified Product: gcc Version: 4.7.2 URL: https://bugs.gentoo.org/show_bug.cgi?id=432412 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: de.tec...@gmail.com Virtualbox when compiled with Graphite with the following compiler options -- -march=native -O2 -fomit-frame-pointer -floop-interchange -floop-strip-mine -floop-block -fgraphite-identity Fails to run the virtual machine when it's having multiple CPUs. i.e. it only works when CPU is set to 1 in number. If I've set it to multiple, the kernel hangs.
[Bug c/57166] New: Manual no longer documents -Wmissing-noreturn alias for -Wsuggest-attribute=noreturn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57166
Bug #: 57166
Summary: Manual no longer documents -Wmissing-noreturn alias
for -Wsuggest-attribute=noreturn
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@joshtriplett.org
Older versions of GCC had an option -Wmissing-noreturn, which acts like
-Wsuggest-attribute=noreturn does now. Current versions of GCC seem to accept
that option as an alias for -Wsuggest-attribute=noreturn, to the point where
the warnings generated by -Wmissing-noreturn get attributed to
-Wsuggest-attribute=noreturn:
error: function might be candidate for attribute 'noreturn'
[-Werror=suggest-attribute=noreturn]
However, if the compiler command line has -Wmissing-noreturn on it,
-Wno-suggest-attribute=noreturn will not turn it back off; only
-Wno-missing-noreturn will do that. The same applies in reverse. Test case:
$ cat test.c
void f(void)
{
while (1)
;
}
int main(void)
{
f();
return 0;
}
$ gcc -Wall -Wsuggest-attribute=noreturn -Wno-suggest-attribute=noreturn test.c
-o /dev/null
$ gcc -Wall -Wmissing-noreturn -Wno-suggest-attribute=noreturn test.c -o
/dev/null
test.c: In function ‘f’:
test.c:1:6: warning: function might be candidate for attribute ‘noreturn’
[-Wsuggest-attribute=noreturn]
$ gcc -Wall -Wmissing-noreturn -Wno-missing-noreturn test.c -o /dev/null
$ gcc -Wall -Wsuggest-attribute=noreturn -Wno-missing-noreturn test.c -o
/dev/null
test.c: In function ‘f’:
test.c:1:6: warning: function might be candidate for attribute ‘noreturn’
[-Wsuggest-attribute=noreturn]
The GCC manual should continue to document the alias -Wmissing-noreturn as long
as it continues to work (just as it currently documents
-Wmissing-format-attribute in addition to -Wsuggest-attribute=format).
In addition, I'd suggest that the -Wno-* forms of either option should cancel
out the other, since otherwise looking at the warning attribution supplied by
GCC and adding the corresponding -Wno-* for that option will not turn off the
warning.
[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57074
--- Comment #15 from Alan Modra 2013-05-04 01:21:50
UTC ---
With this patch I'm still seeing odd trees in place_block_symbol(). In the
following, the type is the correct size (168 bytes), but the var_decl size too
small (48 bytes). place_block_symbol() uses the var_decl size. Hmm, I reckon
that's a bug in place_block_symbol(). Shouldn't it be using DECL_INITIAL size?
unit size
align 64 symtab 0 alias set 20 canonical type 0xf6072b80 fields
pointer_to_this >
BLK
size
unit size
align 64 symtab 0 alias set 20 canonical type 0xf61115c0
domain
DI
size
unit size
align 64 symtab 0 alias set -1 canonical type 0xf6111560 precision
64 min max >
pointer_to_this >
constant addressable asm_written static ignored BLK file
/home/amodra/src/gcc-current/libjava/classpath/gnu/java/awt/dnd/peer/gtk/GtkDragSourceContextPeer.java
line 0 col 0
size
constant 384>
unit size
constant 48>
align 64 initial
(mem/c:BLK (symbol_ref:DI
("_atable_syms_gnu_java_awt_dnd_peer_gtk_GtkDragSourceContextPeer") [flags
0x82] ) [20
_atable_syms_gnu_java_awt_dnd_peer_gtk_GtkDragSourceContextPeer+0 S48 A64])
chain >
[Bug c++/57163] Link failure with thread_local
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57163
Paolo Carlini changed:
What|Removed |Added
Summary|Link failure with |Link failure with
|thread_local|thread_local
|std::default_random_engine |
--- Comment #1 from Paolo Carlini 2013-05-04
00:07:33 UTC ---
In any case the actual std::default_random_engine doesn't play any special
role: the same error happens including, as test.h, something like
namespace std
{
struct default_random_engine
{
default_random_engine() { }
int operator()() { return 1; }
};
}
[Bug gcov-profile/57165] New: ICE when using -fprofile-use in cgraph.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57165 Bug #: 57165 Summary: ICE when using -fprofile-use in cgraph.c Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile AssignedTo: unassig...@gcc.gnu.org ReportedBy: asha...@gcc.gnu.org Created attachment 30030 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30030 gcda and source files to trigger the ICE. Please look at the attached tarball. To reproduce: g++ -fprofile-use -o client_side_detection_service.o client_side_detection_service.ii -O2 -fprofile-correction -Wno-error -c -fno-strict-aliasing -fno-exceptions This reproduces with gcc-4.7.3.
[Bug c++/53745] [C++11] Poor diagnostic for ill-formed narrowing conversion in enumerator initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53745 Paolo Carlini changed: What|Removed |Added CC||vvnic.holas at gmail dot ||com --- Comment #4 from Paolo Carlini 2013-05-03 23:23:15 UTC --- *** Bug 57164 has been marked as a duplicate of this bug. ***
[Bug c++/57164] enumerator value -1 is too large for underlying type ‘unsigned int’
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57164 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Paolo Carlini 2013-05-03 23:23:15 UTC --- Dup. *** This bug has been marked as a duplicate of bug 53745 ***
[Bug c++/57164] enumerator value -1 is too large for underlying type ‘unsigned int’
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57164 --- Comment #1 from Nicholas 2013-05-03 21:24:03 UTC --- (assuming 32-bit ints and two's complement)
[Bug c++/57164] New: enumerator value -1 is too large for underlying type ‘unsigned int’
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57164
Bug #: 57164
Summary: enumerator value -1 is too large for underlying type
‘unsigned int’
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vvnic.ho...@gmail.com
Having an enumerator with a negative value in an enumeration with an unsigned
underlying type produces a compilation error.
enum A : unsigned {
B = -1
};
nicholas@ubuntu:~$ g++ test.cpp -std=c++11
test.cpp:2:7: error: enumerator value -1 is too large for underlying type
‘unsigned int’
B = -1
^
Same error if any other unsigned type is used, or if a scoped enumeration is
used.
As per §7.2.5: "If the underlying type is fixed, the type of each enumerator
prior to the closing brace is the underlying type and the constant-expression
in the enumerator-definition shall be a _converted constant expression_ of the
underlying type (5.19)" (emphasis added)
As per §5.19.3: "A converted constant expression of type T is an expression,
implicitly converted to a prvalue of type T, where the converted expression is
a core constant expression and the implicit conversion sequence contains only
user-defined conversions, lvalue-to-rvalue conversions (4.1), integral
promotions (4.5), and _integral conversions_ (4.7) other than narrowing
conversions (8.5.4)." (emphasis added)
As per §4.7.2 "If the destination type is unsigned, the resulting value is the
least unsigned integer congruent to the source integer"
In other words, the above snippet should be equivalent to:
enum A : unsigned {
B = 4294967295
};
[Bug fortran/56743] Namelist bug with comment and no blank
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56743 --- Comment #5 from Jerry DeLisle 2013-05-03 20:32:51 UTC --- I have a patch testing that fixes the items identified in the attachment of Comment #4 by accepting them as extension.
[Bug bootstrap/57154] [4.9 Regression] Bootstrap broken for powerpc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57154 Bill Schmidt changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #14 from Bill Schmidt 2013-05-03 20:21:26 UTC --- Fixed by: 2013-05-03 Teresa Johnson PR bootstrap/57154 * sched-rgn.c (compute_dom_prob_ps): Ensure accumulated probabilities do not exceed REG_BR_PROB_BASE. Thanks again.
[Bug rtl-optimization/57159] Latent bug in RTL GCSE/PRE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57159 --- Comment #5 from jules at gcc dot gnu.org 2013-05-03 20:05:19 UTC --- Actually the last paragraph might not make sense -- insn 16/17's *operands* are not available at the end of the BB, but only if the REG_EQUAL note contents are substituted for the insn pattern. But that's kind of what happens in hash_scan_set, so I think the overall idea's right.
[Bug rtl-optimization/57159] Latent bug in RTL GCSE/PRE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57159
--- Comment #4 from jules at gcc dot gnu.org 2013-05-03 19:56:33 UTC ---
Created attachment 30029
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30029
Before/after dumps
Here are some before/after dumps taken from the out-of-tree port. Notice how in
the "before" pre dump, the results of insns 27 and 28 are considered to be
equivalent to the results of insns 16 and 17, despite the store (insn 18)
making that equivalence invalid -- this is the misoptimisation alluded to
earlier.
This happens because oprs_available_p mistakenly thinks that insn 16/17's
results are available at the end of their BB, because oprs_unchanged_p ->
load_killed_in_block_p -> mems_conflict_for_gcse_p -> find_rtx_in_ldst finds a
load/store that it thinks it can deal with ("(mem/s:SI (reg/v/f:SI 68 [ iter
]))"), but actually that mem is used (in the REG_EQUAL note, as extracted by
hash_scan_set) in a way that it cannot handle.
[Bug target/57150] GCC when targeting power7 spills long double using VSX instructions.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57150 --- Comment #4 from Michael Meissner 2013-05-03 19:18:21 UTC --- Created attachment 30028 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30028 Patch to use scalar modes for TF/TD caller saves.
[Bug rtl-optimization/57159] Latent bug in RTL GCSE/PRE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57159 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #3 from Jeffrey A. Law 2013-05-03 18:29:13 UTC --- It'd really help if you could add the .cprop1 & .pre dumps before/after your change.
[Bug bootstrap/57154] [4.9 Regression] Bootstrap broken for powerpc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57154 --- Comment #13 from Bill Schmidt 2013-05-03 17:32:05 UTC --- Teresa, thanks for the prompt fix!
[Bug tree-optimization/57149] [4.8/4.9 Regression] wrong -Wmaybe-uninitialized warning with -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57149 Jakub Jelinek changed: What|Removed |Added Summary|[4.8 Regression] wrong |[4.8/4.9 Regression] wrong |-Wmaybe-uninitialized |-Wmaybe-uninitialized |warning with -Os|warning with -Os --- Comment #4 from Jakub Jelinek 2013-05-03 17:19:19 UTC --- Started with http://gcc.gnu.org/r190339
[Bug tree-optimization/57149] [4.8 Regression] wrong -Wmaybe-uninitialized warning with -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57149
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek 2013-05-03
17:00:43 UTC ---
I'd say the problem comes from the
int retval = retval;
in isr_tr_complete_low, which is supposedly inlined into the function
containing err = istr_tr_complete_low (mEp);
At least replacing that with retval = 0; makes the warning go away.
Reduced testcase for -Os -Wall:
struct A { struct A *a, *b; };
struct D { struct A e; };
struct E { unsigned char f; struct { struct A e; } g; };
struct F { struct E i[32]; };
extern int fn0 (void);
extern int fn1 (struct E *, struct D *);
static inline __attribute__ ((always_inline)) int
fn2 (const struct A *x)
{
return x->a == x;
}
static int
fn3 (struct E *x)
{
struct D *l, *m;
int retval = retval;
if (fn2 (&x->g.e))
return 0;
for (l = (struct D *) x->g.e.a, m = (struct D *) l->e.a; &l->e != &x->g.e; l
= m, m = (struct D *) m->e.a)
retval = fn1 (x, l);
return retval;
}
void
fn4 (struct F *x, unsigned k)
{
unsigned i;
for (i = 0; i < k; i++)
{
struct E *y = &x->i[i];
int err = -22;
err = fn3 (y);
if (y->f == 0)
{
if (err > 0)
err = fn0 ();
if (err < 0)
fn0 ();
}
}
}
I believe if fn2 returns zero, then the for body will be run at least once, but
perhaps it isn't simplified as such early enough.
[Bug c++/57038] Latest libreoffice compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038 --- Comment #14 from Martin Liška 2013-05-03 17:00:19 UTC --- Created attachment 30027 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30027 Build log1
[Bug c++/57038] Latest libreoffice compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038 --- Comment #13 from Martin Liška 2013-05-03 16:59:42 UTC --- I attached build log where compilation is aborted after calling add_symbol_to_partition_1 of FieldCacheImpl.o. If it is not useful, please tell me how to provide more verbose details? Thanks, Martin
[Bug c++/57038] Latest libreoffice compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038 --- Comment #12 from Jan Hubicka 2013-05-03 16:48:41 UTC --- > Hi, >you are right, the symbol is also missing in FieldCacheImpl.o. > > Unlike FieldCacheImpl.o, propagg.o really contains symbol: > _ZNSt11_Tuple_implILm0EJRKiEEC1Ev > > I'm going to attach preprocessed propagg.c, hope it will help. Hmm, still not there when I compile propagg.c (renamed to propagg.ii) myself. Perhaps this file is compiled with other options? It really uses weakrefs though, so it still may be weakref bug. Honza
[Bug tree-optimization/57144] [4.9 regression] mpfr miscompiled after r198413
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57144 --- Comment #3 from Jeffrey A. Law 2013-05-03 16:37:34 UTC --- I've checked in a patch to the trunk which should fix this problem. If you could verify on ia64 it would be greatly appreciated.
[Bug bootstrap/57154] [4.9 Regression] Bootstrap broken for powerpc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57154 --- Comment #12 from Teresa Johnson 2013-05-03 16:24:33 UTC --- My powerpc bootstrap completed successfully. Sent patch out for review. Teresa On Fri, May 3, 2013 at 9:03 AM, sje at gcc dot gnu.org wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57154 > > --- Comment #11 from Steve Ellcey 2013-05-03 > 16:03:48 UTC --- > My mips build seems to be working with the patch. It has gotten past the > point > where it died last night but the complete bootstrap isn't finished yet. > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You are on the CC list for the bug.
[Bug c++/57163] New: Link failure with thread_local std::default_random_engine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57163
Bug #: 57163
Summary: Link failure with thread_local
std::default_random_engine
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jleahy+...@gmail.com
Created attachment 30026
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30026
Preprocessed input files
Output of gcc -v:
Thread model: posix
gcc version 4.8.0 (GCC)
Target: x86_64-unknown-linux-gnu
Input file test.cpp:
#include
extern thread_local std::default_random_engine rng;
int main() { return rng(); }
Input file test2.cpp:
#include
thread_local std::default_random_engine rng;
Command line and output:
g++ -std=c++11 -c test.cpp && g++ -std=c++11 -c test2.cpp && g++ -std=c++11
test.o test2.o
test.o:test.cpp:function _ZTW3rng: error: undefined reference to '_ZTH3rng'
collect2: error: ld returned 1 exit status
Complete preprocessed output attached. I can't reproduce this with a single
translation unit.
[Bug bootstrap/57154] [4.9 Regression] Bootstrap broken for powerpc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57154 --- Comment #11 from Steve Ellcey 2013-05-03 16:03:48 UTC --- My mips build seems to be working with the patch. It has gotten past the point where it died last night but the complete bootstrap isn't finished yet.
[Bug bootstrap/57154] [4.9 Regression] Bootstrap broken for powerpc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57154 --- Comment #10 from Teresa Johnson 2013-05-03 15:41:14 UTC --- Hi Steve! Can you confirm whether the patch I just sent also fixes the mips failure? Thanks, Teresa On Fri, May 3, 2013 at 8:40 AM, sje at gcc dot gnu.org wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57154 > > Steve Ellcey changed: > >What|Removed |Added > > CC||sje at gcc dot gnu.org > > --- Comment #8 from Steve Ellcey 2013-05-03 15:40:07 > UTC --- > I am seeing this on mips-mti-linux-gnu as well. > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You are on the CC list for the bug.
[Bug bootstrap/57154] [4.9 Regression] Bootstrap broken for powerpc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57154 --- Comment #9 from Teresa Johnson 2013-05-03 15:40:16 UTC --- The problem is that with the rounding divide, an odd numbered probability being propagated along a 50-50 branch will be rounded up along both edges, resulting in 1 higher probability being propagated along the graph than with the earlier truncating divide. The algorithm in sched-rgn.c is propagating the probabilities along the whole cfg, and when these edges merge, we have 10001 as the accumulated probability, which is higher than REG_BR_PROB_BASE. The following patch fixes this for the attached test case: Index: sched-rgn.c === --- sched-rgn.c (revision 198581) +++ sched-rgn.c (working copy) @@ -1442,6 +1442,8 @@ compute_dom_prob_ps (int bb) bitmap_set_bit (pot_split[bb], EDGE_TO_BIT (out_edge)); prob[bb] += combine_probabilities (prob[pred_bb], in_edge->probability); + if (prob[bb] > REG_BR_PROB_BASE) + prob[bb] = REG_BR_PROB_BASE; } bitmap_set_bit (dom[bb], bb); I am now testing with the full powerpc bootstrap build. This was the only additional use of combine_probabilities in my patch, so there shouldn't be any other issues like this. Will send the patch for review once the bootstrap completes. Teresa On Fri, May 3, 2013 at 8:10 AM, tejohnson at google dot com wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57154 > > --- Comment #7 from Teresa Johnson 2013-05-03 > 15:10:50 UTC --- > Thanks for the test case - reproduced with my stage1 compiler on gcc110. > Teresa > > On Fri, May 3, 2013 at 8:02 AM, dje at gcc dot gnu.org > wrote: >> >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57154 >> >> --- Comment #6 from David Edelsohn 2013-05-03 >> 15:02:18 UTC --- >> Created attachment 30022 >> --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30022 >> Testcase >> >> Testcase from Anton Blanchard transferred from PR 57161 >> >> # gcc -O2 -c foo.c >> foo.c: In function 'testcase': >> foo.c:40:1: internal compiler error: in check_probability, at >> basic-block.h:941 >> } >> ^ >> 0x105bb57b check_probability >> ../../gcc/gcc/basic-block.h:941 >> 0x105bb57b check_probability >> ../../gcc/gcc/sched-rgn.c:3247 >> 0x105bb57b combine_probabilities >> ../../gcc/gcc/basic-block.h:950 >> 0x105bb57b compute_dom_prob_ps >> ../../gcc/gcc/sched-rgn.c:1444 >> 0x105bb57b sched_rgn_local_init(int) >> ../../gcc/gcc/sched-rgn.c:3291 >> 0x105bd393 schedule_region >> ../../gcc/gcc/sched-rgn.c:2984 >> 0x105bd393 schedule_insns >> ../../gcc/gcc/sched-rgn.c:3384 >> 0x105bd393 schedule_insns() >> ../../gcc/gcc/sched-rgn.c:3363 >> 0x105bdbb3 rest_of_handle_sched >> ../../gcc/gcc/sched-rgn.c:3577 >> >> -- >> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email >> --- You are receiving this mail because: --- >> You are on the CC list for the bug. > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You are on the CC list for the bug.
[Bug bootstrap/57154] [4.9 Regression] Bootstrap broken for powerpc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57154 Steve Ellcey changed: What|Removed |Added CC||sje at gcc dot gnu.org --- Comment #8 from Steve Ellcey 2013-05-03 15:40:07 UTC --- I am seeing this on mips-mti-linux-gnu as well.
[Bug c++/57038] Latest libreoffice compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038 --- Comment #11 from Martin Liška 2013-05-03 15:22:15 UTC --- Created attachment 30025 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30025 Preprocessed propag.c
[Bug c++/57025] Solaris g++ defines __STDC_VERSION__=199901L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57025 Martin Liška changed: What|Removed |Added CC||marxin.liska at gmail dot ||com --- Comment #6 from Martin Liška 2013-05-03 15:21:23 UTC --- (In reply to comment #5) > Created attachment 30024 [details] > Preprocessed propagg.c Sorry for attaching file to wrong bug.
[Bug c++/57025] Solaris g++ defines __STDC_VERSION__=199901L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57025 --- Comment #5 from Martin Liška 2013-05-03 15:20:17 UTC --- Created attachment 30024 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30024 Preprocessed propagg.c
[Bug c++/57038] Latest libreoffice compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038 --- Comment #10 from Martin Liška 2013-05-03 15:19:08 UTC --- Hi, you are right, the symbol is also missing in FieldCacheImpl.o. Unlike FieldCacheImpl.o, propagg.o really contains symbol: _ZNSt11_Tuple_implILm0EJRKiEEC1Ev I'm going to attach preprocessed propagg.c, hope it will help. Martin
[Bug bootstrap/57154] [4.9 Regression] Bootstrap broken for powerpc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57154 --- Comment #7 from Teresa Johnson 2013-05-03 15:10:50 UTC --- Thanks for the test case - reproduced with my stage1 compiler on gcc110. Teresa On Fri, May 3, 2013 at 8:02 AM, dje at gcc dot gnu.org wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57154 > > --- Comment #6 from David Edelsohn 2013-05-03 > 15:02:18 UTC --- > Created attachment 30022 > --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30022 > Testcase > > Testcase from Anton Blanchard transferred from PR 57161 > > # gcc -O2 -c foo.c > foo.c: In function 'testcase': > foo.c:40:1: internal compiler error: in check_probability, at > basic-block.h:941 > } > ^ > 0x105bb57b check_probability > ../../gcc/gcc/basic-block.h:941 > 0x105bb57b check_probability > ../../gcc/gcc/sched-rgn.c:3247 > 0x105bb57b combine_probabilities > ../../gcc/gcc/basic-block.h:950 > 0x105bb57b compute_dom_prob_ps > ../../gcc/gcc/sched-rgn.c:1444 > 0x105bb57b sched_rgn_local_init(int) > ../../gcc/gcc/sched-rgn.c:3291 > 0x105bd393 schedule_region > ../../gcc/gcc/sched-rgn.c:2984 > 0x105bd393 schedule_insns > ../../gcc/gcc/sched-rgn.c:3384 > 0x105bd393 schedule_insns() > ../../gcc/gcc/sched-rgn.c:3363 > 0x105bdbb3 rest_of_handle_sched > ../../gcc/gcc/sched-rgn.c:3577 > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You are on the CC list for the bug.
[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57074 --- Comment #14 from Jakub Jelinek 2013-05-03 15:05:55 UTC --- $ readelf -Ws obj627/i686-pc-linux-gnu/libjava/.libs/*.so.* | grep _atable_syms_gnu_classpath_tools_keytool_Main.ShutdownHook 9864: 00359ca824 OBJECT LOCAL DEFAULT 23 _atable_syms_gnu_classpath_tools_keytool_Main$ShutdownHook 9864: 00359ca824 OBJECT LOCAL DEFAULT 23 _atable_syms_gnu_classpath_tools_keytool_Main$ShutdownHook $ readelf -Ws obj629/i686-pc-linux-gnu/libjava/.libs/*.so.* | grep _atable_syms_gnu_classpath_tools_keytool_Main.ShutdownHook 9864: 0035bc6036 OBJECT LOCAL DEFAULT 23 _atable_syms_gnu_classpath_tools_keytool_Main$ShutdownHook 9864: 0035bc6036 OBJECT LOCAL DEFAULT 23 _atable_syms_gnu_classpath_tools_keytool_Main$ShutdownHook obj627 is trunk without this patch, obj629 with this patch.
[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57074 Jakub Jelinek changed: What|Removed |Added Attachment #30010|0 |1 is obsolete|| --- Comment #13 from Jakub Jelinek 2013-05-03 15:03:27 UTC --- Created attachment 30023 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30023 gcc49-pr57074.patch Updated patch, this so far bootstrapped on i686-linux, x86_64-linux bootstrap and regtests on both still pending.
[Bug bootstrap/57154] [4.9 Regression] Bootstrap broken for powerpc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57154 --- Comment #6 from David Edelsohn 2013-05-03 15:02:18 UTC --- Created attachment 30022 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30022 Testcase Testcase from Anton Blanchard transferred from PR 57161 # gcc -O2 -c foo.c foo.c: In function 'testcase': foo.c:40:1: internal compiler error: in check_probability, at basic-block.h:941 } ^ 0x105bb57b check_probability ../../gcc/gcc/basic-block.h:941 0x105bb57b check_probability ../../gcc/gcc/sched-rgn.c:3247 0x105bb57b combine_probabilities ../../gcc/gcc/basic-block.h:950 0x105bb57b compute_dom_prob_ps ../../gcc/gcc/sched-rgn.c:1444 0x105bb57b sched_rgn_local_init(int) ../../gcc/gcc/sched-rgn.c:3291 0x105bd393 schedule_region ../../gcc/gcc/sched-rgn.c:2984 0x105bd393 schedule_insns ../../gcc/gcc/sched-rgn.c:3384 0x105bd393 schedule_insns() ../../gcc/gcc/sched-rgn.c:3363 0x105bdbb3 rest_of_handle_sched ../../gcc/gcc/sched-rgn.c:3577
[Bug bootstrap/57154] [4.9 Regression] Bootstrap broken for powerpc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57154 --- Comment #5 from Teresa Johnson 2013-05-03 15:01:51 UTC --- Couldn't reproduce on x86_64, so I am on gcc110 trying to get a bootstrap compiler build going to reproduce. Also see the dup with testcase (again doesn't reproduce on x86_64, so I will try this on gcc110 as soon as I get the compiler built). Thanks, Teresa On Fri, May 3, 2013 at 4:45 AM, wschmidt at gcc dot gnu.org wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57154 > > --- Comment #2 from Bill Schmidt 2013-05-03 > 11:45:06 UTC --- > There is a powerpc64 pool machine available. I believe it's gcc110. > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You are on the CC list for the bug.
[Bug bootstrap/57154] [4.9 Regression] Bootstrap broken for powerpc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57154 David Edelsohn changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-03 CC||dje at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #4 from David Edelsohn 2013-05-03 14:58:24 UTC --- Confirmed.
[Bug bootstrap/57154] [4.9 Regression] Bootstrap broken for powerpc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57154 David Edelsohn changed: What|Removed |Added CC||anton at samba dot org --- Comment #3 from David Edelsohn 2013-05-03 14:53:51 UTC --- *** Bug 57161 has been marked as a duplicate of this bug. ***
[Bug middle-end/57161] ICE in in check_probability, at basic-block.h:941
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57161 David Edelsohn changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||dje at gcc dot gnu.org Resolution||DUPLICATE --- Comment #3 from David Edelsohn 2013-05-03 14:53:51 UTC --- Duplicate. *** This bug has been marked as a duplicate of bug 57154 ***
[Bug c++/57038] Latest libreoffice compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038 --- Comment #9 from Jan Hubicka 2013-05-03 14:19:22 UTC --- Hi, I can not find any symbol ZNSt11_Tuple_implILm0EJRKPN6lucene5index11IndexReaderEEEC1Ev in the preprocessed file you added. Can you check if the symbol appears in LTO symbol table for you in that .o object? Did you preprocessed it with the same -D options? Honza
[Bug tree-optimization/57156] miscompilation of call to _mm_cmpeq_epi8(a, a) or _mm_comtrue_epu8(a, a) with uninitialized a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57156
Matthias Kretz changed:
What|Removed |Added
Component|target |tree-optimization
--- Comment #7 from Matthias Kretz 2013-05-03 14:13:30
UTC ---
(In reply to comment #6)
> The standard says that using uninitialized variables invoke undefined
> behavior.
Is this §4.1p1: Lvalue-to-rvalue conversion?
"[...] if the object is uninitialized, a program that necessitates this
conversion has undefined behavior"
> That doesn't magically exclude types that are not explicitely
> covered by the standard.
True.
> You cannot translate optimized assembler back to C in this way.
>
> Well, you can. Sth like
>
> register int a asm("eax");
> int zero = a ^ a;
>
> should do it.
Interesting. But then I'd rather use:
int a;
asm("xor %0,%0":"=r"(a));
so that GCC can determine what register to use. I wanted to avoid this, though.
Because with inline asm I expect that the compiler does not know how cheap this
call really is.
Still, I'm wondering how _mm_comtrue_epu8 is meant to be used. The intrinsic
returns 11...1 independent of the input. It shouldn't have any arguments in the
first place, but it does. And just passing it anything doesn't work reliably...
[Bug target/57106] [4.8/4.9 Regression] -fcompare-debug failure with -O2 -fschedule-insns -funroll-all-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57106 Uros Bizjak changed: What|Removed |Added Status|NEW |ASSIGNED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-05/msg00131.htm ||l AssignedTo|unassigned at gcc dot |ubizjak at gmail dot com |gnu.org | --- Comment #5 from Uros Bizjak 2013-05-03 14:01:55 UTC --- Patch at [1]. [1] http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00131.html
[Bug tree-optimization/57051] Optimization regression in 4.8.0 from 4.7.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57051 Jakub Jelinek changed: What|Removed |Added Target Milestone|4.8.1 |--- Summary|[4.8 Regression]|Optimization regression in |Optimization regression in |4.8.0 from 4.7.2 |4.8.0 from 4.7.2|
[Bug tree-optimization/57051] [4.8 Regression] Optimization regression in 4.8.0 from 4.7.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57051 --- Comment #6 from Jakub Jelinek 2013-05-03 13:57:52 UTC --- Author: jakub Date: Fri May 3 13:16:13 2013 New Revision: 198580 URL: http://gcc.gnu.org/viewcvs?rev=198580&root=gcc&view=rev Log: Backported from mainline 2013-04-26 Jakub Jelinek PR tree-optimization/57051 * fold-const.c (const_binop): Handle VEC_LSHIFT_EXPR and VEC_RSHIFT_EXPR if shift count is a multiple of element bitsize. 2013-04-12 Marc Glisse * fold-const.c (fold_binary_loc): Call const_binop also for mixed vector-scalar operations. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/fold-const.c The testcase should now no longer regress, keeping open for Richard's SCEV investigation.
[Bug tree-optimization/57162] New: Ofast does not make use of avx while O3 does
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57162
Bug #: 57162
Summary: Ofast does not make use of avx while O3 does
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch
in a trivial 4x4 matmul Ofast code looks worse than O3 for avx
cat matmul.cc
alignas(32) float a[4][4];
alignas(32) float b[4][4];
alignas(32) float c[4][4];
void matmul() {
for (int i=0;i!=4;++i)
for (int j=0;j!=4;++j) {
float sum=0;
for (int k=0;k!=4;++k)
sum += a[i][k]*b[k][j];
c[i][j]=sum;
}
}
c++ -O3 -march=corei7-avx -mavx2 -std=c++11 -S matmul.cc
.text
.align 4,0x90
.globl __Z6matmulv
__Z6matmulv:
LFB0:
vmovss8+_b(%rip), %xmm4
vmovss_b(%rip), %xmm7
vinsertps$0x10, 12+_b(%rip), %xmm4, %xmm0
vmovss24+_b(%rip), %xmm1
vmovss16+_b(%rip), %xmm4
vinsertps$0x10, 4+_b(%rip), %xmm7, %xmm5
vmovlhps%xmm0, %xmm5, %xmm5
vmovss40+_b(%rip), %xmm7
vinsertf128$1, %xmm5, %ymm5, %ymm5
vinsertps$0x10, 28+_b(%rip), %xmm1, %xmm0
vinsertps$0x10, 20+_b(%rip), %xmm4, %xmm3
vmovss32+_b(%rip), %xmm1
vmovlhps%xmm0, %xmm3, %xmm3
vmovss56+_b(%rip), %xmm4
vinsertf128$1, %xmm3, %ymm3, %ymm3
vinsertps$0x10, 44+_b(%rip), %xmm7, %xmm0
vmovss48+_b(%rip), %xmm6
vinsertps$0x10, 36+_b(%rip), %xmm1, %xmm2
vmovlhps%xmm0, %xmm2, %xmm2
vinsertps$0x10, 60+_b(%rip), %xmm4, %xmm0
vxorps%xmm4, %xmm4, %xmm4
vinsertf128$1, %xmm2, %ymm2, %ymm2
vinsertps$0x10, 52+_b(%rip), %xmm6, %xmm1
vmovlhps%xmm0, %xmm1, %xmm1
vmovaps_a(%rip), %ymm0
vinsertf128$1, %xmm1, %ymm1, %ymm1
vpermilps$0, %ymm0, %ymm7
vmulps%ymm5, %ymm7, %ymm7
vaddps%ymm4, %ymm7, %ymm7
vpermilps$85, %ymm0, %ymm6
vmulps%ymm3, %ymm6, %ymm6
vaddps%ymm6, %ymm7, %ymm7
vpermilps$170, %ymm0, %ymm6
vmulps%ymm2, %ymm6, %ymm6
vpermilps$255, %ymm0, %ymm0
vmulps%ymm1, %ymm0, %ymm0
vaddps%ymm6, %ymm7, %ymm6
vaddps%ymm0, %ymm6, %ymm0
vmovaps%ymm0, _c(%rip)
vmovaps32+_a(%rip), %ymm0
vpermilps$0, %ymm0, %ymm6
vmulps%ymm5, %ymm6, %ymm5
vaddps%ymm4, %ymm5, %ymm4
vpermilps$85, %ymm0, %ymm5
vmulps%ymm3, %ymm5, %ymm3
vaddps%ymm3, %ymm4, %ymm3
vpermilps$170, %ymm0, %ymm4
vmulps%ymm2, %ymm4, %ymm2
vpermilps$255, %ymm0, %ymm0
vmulps%ymm1, %ymm0, %ymm1
vaddps%ymm2, %ymm3, %ymm2
vaddps%ymm1, %ymm2, %ymm0
vmovaps%ymm0, 32+_c(%rip)
vzeroupper
and
c++ -Ofast -march=corei7-avx -mavx2 -std=c++11 -S matmul.cc
Vincenzos-MacBook-Pro:vectorize innocent$ cat matmul.s
.text
.align 4,0x90
.globl __Z6matmulv
__Z6matmulv:
LFB0:
vmovaps16+_a(%rip), %xmm1
vmovaps48+_a(%rip), %xmm0
vmovaps_a(%rip), %xmm4
vmovaps32+_a(%rip), %xmm2
vbroadcastss32+_b(%rip), %xmm6
vshufps$136, %xmm1, %xmm4, %xmm3
vshufps$221, %xmm1, %xmm4, %xmm4
vbroadcastss36+_b(%rip), %xmm5
vshufps$136, %xmm0, %xmm2, %xmm1
vshufps$221, %xmm0, %xmm2, %xmm2
vbroadcastss40+_b(%rip), %xmm7
vshufps$136, %xmm1, %xmm3, %xmm0
vshufps$221, %xmm1, %xmm3, %xmm3
vshufps$136, %xmm2, %xmm4, %xmm1
vshufps$221, %xmm2, %xmm4, %xmm2
vmulps%xmm6, %xmm3, %xmm6
vbroadcastss48+_b(%rip), %xmm4
vmulps%xmm5, %xmm3, %xmm5
vmulps%xmm7, %xmm3, %xmm7
vmulps%xmm4, %xmm2, %xmm4
vaddps%xmm4, %xmm6, %xmm6
vbroadcastss16+_b(%rip), %xmm4
vmulps%xmm4, %xmm1, %xmm4
vaddps%xmm4, %xmm6, %xmm6
vbroadcastss_b(%rip), %xmm4
vmulps%xmm4, %xmm0, %xmm4
vaddps%xmm4, %xmm6, %xmm6
vbroadcastss52+_b(%rip), %xmm4
vmulps%xmm4, %xmm2, %xmm4
vaddps%xmm4, %xmm5, %xmm5
vbroadcastss20+_b(%rip), %xmm4
vmulps%xmm4, %xmm1, %xmm4
vaddps%xmm4, %xmm5, %xmm5
vbroadcastss4+_b(%rip), %xmm4
vmulps%xmm4, %xmm0, %xmm4
vaddps%xmm4, %xmm5, %xmm4
vbroadcastss56+_b(%rip), %xmm5
vmulps%xmm5, %xmm2, %xmm5
vaddps%xmm5, %xmm7, %xmm7
vbroadcastss24+_b(%rip), %xmm5
vmulps%xmm5, %xmm1, %xmm5
vaddps%xmm5, %xmm7, %xmm7
vbroadcastss8+_b(%rip), %xmm5
vmulps%xmm5, %xmm0, %xmm5
vaddps%xmm5, %xmm7, %xmm5
vbroadcastss44+_b(%rip), %xmm7
vmulps%xmm7, %xmm3, %xmm3
vbroadcastss60+_b(%rip), %xmm7
vmulps%xmm7,
[Bug rtl-optimization/57130] [4.8/4.9 Regression] Incorrect "and --> extract" conversion in combine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57130 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Jakub Jelinek 2013-05-03 13:56:59 UTC --- Author: jakub Date: Fri May 3 12:56:12 2013 New Revision: 198579 URL: http://gcc.gnu.org/viewcvs?rev=198579&root=gcc&view=rev Log: PR rtl-optimization/57130 * combine.c (make_compound_operation) : Pass SET instead of COMPARE as in_code to the recursive call if needed. * gcc.c-torture/execute/pr57130.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr57130.c Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/testsuite/ChangeLog Author: jakub Date: Fri May 3 13:19:51 2013 New Revision: 198581 URL: http://gcc.gnu.org/viewcvs?rev=198581&root=gcc&view=rev Log: PR rtl-optimization/57130 * combine.c (make_compound_operation) : Pass SET instead of COMPARE as in_code to the recursive call if needed. * gcc.c-torture/execute/pr57130.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/execute/pr57130.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/combine.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug lto/57084] 483. xalancbmk run fails with -O2 -flto for i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57084
--- Comment #4 from Martin Jambor 2013-05-03
13:45:28 UTC ---
(In reply to comment #3)
> > @@ -1993,6 +1994,18 @@ ipa_intraprocedural_devirtualization (gi
> >token = OBJ_TYPE_REF_TOKEN (otr);
> >fndecl = gimple_get_virt_method_for_binfo (tree_low_cst (token, 1),
> > binfo);
> > + if (!fndecl)
> > +return NULL_TREE;
> > +
> > + callee = cgraph_get_node (fndecl);
> > + if (!callee || callee->global.inlined_to)
> > +{
> > + if (!canonicalize_constructor_val (fndecl, NULL)
> fndecl = canonicalize_constructor_val (fndecl, NULL)
> Why do you need TREE_PUBLIC check?
Well, as I wrote in the comment above, I basically copied the code
what you added to ipa_make_edge_direct_to_target in February this
year. The comment there says that "In the case of static functions we
are out of luck, since we already removed its body." BTW, we also
only check canonicalize_constructor_val return value for non-NULL-ness
in that function.
Anyway, this was just a proof of concept patch. I suppose that we'll
want to put this functionality to a separate function and call it from
both ipa_make_edge_direct_to_target and eliminate_bb (in
tree-ssa-pre.c). I wonder what name to give it to it though,
especially given that cgraph_get_create_real_symbol_node already exits
(but unlike what is required IIUC cannot return NULL).
cgraph_make_fndecl_callable?
[Bug middle-end/57161] ICE in in check_probability, at basic-block.h:941
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57161 --- Comment #2 from Anton Blanchard 2013-05-03 13:17:31 UTC --- A bisect hit this commit: 2013-05-02 Teresa Johnson * loop-unswitch.c (unswitch_loop): Use helper routines with rounding divides. * cfg.c (update_bb_profile_for_threading): Ditto. * tree-inline.c (copy_bb): Ditto. (copy_edges_for_bb): Ditto. (initialize_cfun): Ditto. (copy_cfg_body): Ditto. (expand_call_inline): Ditto. * ipa-inline-analysis.c (estimate_edge_size_and_time): Ditto. (estimate_node_size_and_time): Ditto. (inline_merge_summary): Ditto. * cgraphclones.c (cgraph_clone_edge): Ditto. (cgraph_clone_node): Ditto. * sched-rgn.c (compute_dom_prob_ps): Ditto. (compute_trg_info): Ditto.
[Bug c++/57038] Latest libreoffice compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038 --- Comment #8 from Martin Liška 2013-05-03 13:07:56 UTC --- Flags: g++ -DCPPU_ENV=gcc3 -DLIBO_INTERNAL_ONLY -DLINUX -DNDEBUG -DOPTIMIZE -DOSL_DEBUG_LEVEL=0 -DSOLAR_JAVA -DSUPD=410 -DUNIX -DUNX -DX86_64 -D_PTHREADS -D_REENTRANT -DRTL_USING -DSYSTEM_ZLIB -Dclucene_shared_EXPORTS -Dclucene_core_EXPORTS -Dclucene_contribs_lib_EXPORTS -flto -fno-fat-lto-objects -fuse-linker-plugin -O2 -DHAVE_GCC_VISIBILITY_FEATURE -fvisibility=hidden -Wall -Wendif-labels -Wextra -Wundef -Wunused-macros -fmessage-length=0 -fno-common -pipe -fvisibility-inlines-hidden -DLIBO_MERGELIBS -fPIC -Wshadow -Woverloaded-virtual -Wnon-virtual-dtor -std=gnu++0x -DEXCEPTIONS_ON -fexceptions -fno-enforce-eh-specs -O2 -w -c $W/UnpackedTarball/clucene/src/core/CLucene/search/FieldCacheImpl.cpp -o $W/GenCxxObject/UnpackedTarball/clucene/src/core/CLucene/search/FieldCacheImpl.o -MMD -MT $W/GenCxxObject/UnpackedTarball/clucene/src/core/CLucene/search/FieldCacheImpl.o -MP -MF $W/Dep/GenCxxObject/UnpackedTarball/clucene/src/core/CLucene/search/FieldCacheImpl.d_ -I$W/UnpackedTarball/clucene/src/core/CLucene/search/ -I$W/UnpackedTarball/clucene/inc/internal -I$W/UnpackedTarball/clucene/src/core -I$W/UnpackedTarball/clucene/src/contribs-lib -I$W/UnpackedTarball/clucene/src/shared -I$S/include -I$O/inc/external -I$O/inc -I/opt/sun-jdk-1.6.0.34/include -I/opt/sun-jdk-1.6.0.34/include/linux -I$S/config_host&& mv $W/Dep/GenCxxObject/UnpackedTarball/clucene/src/core/CLucene/search/FieldCacheImpl.d_ $W/Dep/GenCxxObject/UnpackedTarball/clucene/src/core/CLucene/search/FieldCacheImpl.d
[Bug c++/57038] Latest libreoffice compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038 --- Comment #7 from Jan Hubicka 2013-05-03 13:03:32 UTC --- Hmm, not weakref but really weak alias of external function. This seems even more weird. What are the flags used to compile the .o file? Honza
[Bug middle-end/57161] ICE in in check_probability, at basic-block.h:941
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57161 --- Comment #1 from Anton Blanchard 2013-05-03 12:53:49 UTC --- Created attachment 30021 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30021 Testcase
[Bug middle-end/57161] New: ICE in in check_probability, at basic-block.h:941
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57161 Bug #: 57161 Summary: ICE in in check_probability, at basic-block.h:941 Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: an...@samba.org I'm getting an ICE with the following testcase on a ppc64 target. passes on gcc version 4.9.0 20130501 (experimental) (GCC) fails on gcc version 4.9.0 20130503 (experimental) (GCC) # gcc -O2 -c foo.c foo.c: In function 'testcase': foo.c:40:1: internal compiler error: in check_probability, at basic-block.h:941 } ^ 0x105bb57b check_probability ../../gcc/gcc/basic-block.h:941 0x105bb57b check_probability ../../gcc/gcc/sched-rgn.c:3247 0x105bb57b combine_probabilities ../../gcc/gcc/basic-block.h:950 0x105bb57b compute_dom_prob_ps ../../gcc/gcc/sched-rgn.c:1444 0x105bb57b sched_rgn_local_init(int) ../../gcc/gcc/sched-rgn.c:3291 0x105bd393 schedule_region ../../gcc/gcc/sched-rgn.c:2984 0x105bd393 schedule_insns ../../gcc/gcc/sched-rgn.c:3384 0x105bd393 schedule_insns() ../../gcc/gcc/sched-rgn.c:3363 0x105bdbb3 rest_of_handle_sched ../../gcc/gcc/sched-rgn.c:3577
[Bug c++/57038] Latest libreoffice compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038 --- Comment #6 from Martin Liška 2013-05-03 12:44:44 UTC --- Created attachment 30020 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30020 FieldCacheImpl.c
[Bug c++/57038] Latest libreoffice compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038 --- Comment #5 from Martin Liška 2013-05-03 12:43:56 UTC --- Looks like the problem has many occurrences in CLucene: _ZNSt11_Tuple_implILm0EJRKPN6lucene5index11IndexReaderEEEC1Ev/146876 (_ZNSt11_Tuple_implILm0EJRKPN6lucene5index11IndexReaderEEEC1Ev) @0x2b58d3925be0 Type: function Visibility: prevailing_def_ironly_exp public weak artificial References: _ZNSt11_Tuple_implILm0EIRKPN6lucene5index11IndexReaderEEEC1Ev/146875 (alias) Referring: Read from file: /home/marxin/Programming/libreoffice/workdir/unxlngx6.pro/GenCxxObject/UnpackedTarball/clucene/src/core/CLucene/search/FieldCacheImpl.o Availability: overwritable Function flags: analyzed finalized alias Alias of __comp_ctor (asm: _ZNSt11_Tuple_implILm0EIRKPN6lucene5index11IndexReaderEEEC1Ev) Called by: Calls: _ZNSt11_Tuple_implILm0EIRKPN6lucene5index11IndexReaderEEEC1Ev/146875 (__comp_ctor ) @0x2b58d3925d10 Type: function Visibility: external public visibility_specified References: Referring: _ZNSt11_Tuple_implILm0EJRKPN6lucene5index11IndexReaderEEEC1Ev/146876 (alias) Read from file: /home/marxin/Programming/libreoffice/workdir/unxlngx6.pro/GenCxxObject/UnpackedTarball/clucene/src/core/CLucene/search/FieldCacheImpl.o Availability: not_available Function flags: Called by: Calls: I've just uploaded preprocessed FieldCacheImpl.c. Martin
[Bug fortran/57160] New: short-circuit IF only with -ffrontend-optimize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57160 Bug #: 57160 Summary: short-circuit IF only with -ffrontend-optimize Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@mat.ethz.ch it would be nice to have the short-circuit evaluation of IF statements only if -ffrontend-optimize is in place. It would help to capture (at -O0) bugs like: MODULE M1 TYPE T1 LOGICAL :: T=.TRUE. END TYPE T1 CONTAINS SUBROUTINE S1(m) TYPE(T1), POINTER :: m IF (ASSOCIATED(m) .AND. m%T) THEN WRITE(6,*) "X" ENDIF END SUBROUTINE END MODULE USE M1 TYPE(T1), POINTER :: m=>NULL() CALL S1(m) END where I would like the code to segfault.
[Bug libstdc++/54577] deque::erase() still takes iterator instead of const_iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54577 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-05-03 AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Ever Confirmed|0 |1 --- Comment #5 from Paolo Carlini 2013-05-03 12:40:22 UTC --- Can do this soon. AFAICS only the sequence containers are still wrong vs C++11.
[Bug rtl-optimization/57159] Latent bug in RTL GCSE/PRE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57159 Richard Biener changed: What|Removed |Added CC||stevenb.gcc at gmail dot ||com --- Comment #2 from Richard Biener 2013-05-03 12:31:27 UTC --- Patches should go to gcc-patches. Eventually Steven knows this code best.
[Bug target/57156] miscompilation of call to _mm_cmpeq_epi8(a, a) or _mm_comtrue_epu8(a, a) with uninitialized a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57156
--- Comment #6 from Richard Biener 2013-05-03
12:27:05 UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> > I wouldn't know how to counter this for the _mm_cmpeq_epi8 case
>
> Actually, I have yet to find something in the standard that says using an
> uninitialized __m128 is undefined behavior. ;)
> Thus the only standard that would define the rules here would be Intel's, no?
> And from reading their docs I understand that calling an intrinsics maps to
> the
> behavior you'd get when using the associated instruction. In this case
> comparing any XMM register with itself will result in what I expect.
The standard says that using uninitialized variables invoke undefined
behavior. That doesn't magically exclude types that are not explicitely
covered by the standard. Doing
int a;
_Bool true = a == a;
is undefined as well, so is
int a;
int zero = a ^ a;
You cannot translate optimized assembler back to C in this way.
Well, you can. Sth like
register int a asm("eax");
int zero = a ^ a;
should do it.
[Bug libstdc++/57158] std::list.erase(const_iterator pos) not implemented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57158 --- Comment #3 from Matt Clarkson 2013-05-03 12:21:22 UTC --- Thanks, glad it's been reported.
[Bug c/57157] Poor optimization of portable rotate idiom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57157 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-03 Ever Confirmed|0 |1 --- Comment #1 from Richard Biener 2013-05-03 12:21:04 UTC --- Confirmed.
[Bug lto/57084] 483. xalancbmk run fails with -O2 -flto for i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57084
--- Comment #3 from Jan Hubicka 2013-05-03 12:17:20 UTC
---
> @@ -1993,6 +1994,18 @@ ipa_intraprocedural_devirtualization (gi
>token = OBJ_TYPE_REF_TOKEN (otr);
>fndecl = gimple_get_virt_method_for_binfo (tree_low_cst (token, 1),
> binfo);
> + if (!fndecl)
> +return NULL_TREE;
> +
> + callee = cgraph_get_node (fndecl);
> + if (!callee || callee->global.inlined_to)
> +{
> + if (!canonicalize_constructor_val (fndecl, NULL)
fndecl = canonicalize_constructor_val (fndecl, NULL)
Why do you need TREE_PUBLIC check?
Honza
[Bug c++/57038] Latest libreoffice compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038 --- Comment #4 from Jan Hubicka 2013-05-03 12:15:48 UTC --- > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038 > > --- Comment #3 from Martin Liška 2013-05-03 > 11:20:00 UTC --- > lto-partition.c:265 (add_symbol_to_partition) > > c++filt: > std::_Tuple_impl<0ul, int const&>::_Tuple_impl() > > dump_symtab_node: > _ZNSt11_Tuple_implILm0EJRKiEEC1Ev/281156 (_ZNSt11_Tuple_implILm0EJRKiEEC1Ev) > @0x7f5a9bc5fab0 > Type: function > Visibility: prevailing_def_ironly_exp public weak artificial OK, so weakref alias bug apparently. Can you please attach the preprocessed /home/marxin/Programming/libreoffice/workdir/unxlngx6.pro/CxxObject/comphelper/source/property/propagg.o? Honza
[Bug target/47769] [missed optimization] use of btr (bit test and reset)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47769 Paolo Carlini changed: What|Removed |Added Status|WAITING |NEW
[Bug rtl-optimization/57159] Latent bug in RTL GCSE/PRE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57159 --- Comment #1 from jules at gcc dot gnu.org 2013-05-03 11:56:53 UTC --- Created attachment 30019 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30019 patch
[Bug rtl-optimization/57159] New: Latent bug in RTL GCSE/PRE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57159
Bug #: 57159
Summary: Latent bug in RTL GCSE/PRE
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ju...@gcc.gnu.org
Created attachment 30018
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30018
testcase
We encountered a wrong-code bug in an out-of-tree port (4.6-based, though the
affected code doesn't appear to have changed that much) in target-independent
code, though I have not been able to reproduce the problem on a
currently-supported target. The port in question is unusual in that it allows
read-modify-write arithmetic directly on memory locations (for some operations,
at least).
That means that during RTL expansion, the compiler may attach REG_EQUAL notes
to insns that contain memory operands:
(insn 16 15 17 (set (reg:SI 70)
(mem/s:SI (reg/v/f:SI 68 [ iter ]) [3 iter_4(D)->xhv_riter+0 S4 A32]))
hvmin.c:32 -1
(nil))
(insn 17 16 0 (set (reg:SI 56 [ D.4066 ])
(plus:SI (reg:SI 70)
(const_int 1 [0x1]))) hvmin.c:32 -1
(expr_list:REG_EQUAL (plus:SI (mem/s:SI (reg/v/f:SI 68 [ iter ]) [3
iter_4(D)->xhv_riter+0 S4 A32])
(const_int 1 [0x1]))
(nil)))
That in itself is not a problem, but certain parts of gcse.c's PRE code examine
only the instruction itself (e.g. when building tables of "interesting" memory
locations -- compute_ld_motion_mems), whereas other parts pay attention to the
REG_EQUAL note (hash_scan_set). That means that memory references which are
"too complicated" for PRE to handle properly can leak through to later parts of
the algorithm and cause misoptimisations -- in the case of the attached file,
the increment in the loop is optimised away, and the loop spins forever.
The fix then is to prevent "complicated" memory references which may be present
in REG_EQUAL notes from being considered for load motion, by stopping them from
being added to the relevant tables to start with. That's what the attached
patch does, and it works for us -- though without a way of reproducing the bug
on mainline, it's not quite obvious that it should be applied there.
Interestingly, on x86 (which also allows read-modify-write operations), it
looks like the bug is latent because a normal addition clobbers the flags
register:
(insn 28 91 94 4 (parallel [
(set (reg:SI 60 [ D.2122 ])
(plus:SI (reg:SI 74 [ iter_4(D)->xhv_riter ])
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
]) hvmin.c:32 252 {*addsi_1}
(expr_list:REG_DEAD (reg:SI 74 [ iter_4(D)->xhv_riter ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_EQUAL (plus:SI (mem/s:SI (reg/v/f:DI 72 [ iter ]) [3
iter_4(D)->xhv_riter+0 S4 A32])
(const_int 1 [0x1]))
(nil)
This is apparently sufficient to prevent the misoptimisation (probably because
of want_to_gcse_p's call to can_assign_to_reg_without_clobbers_p). I tried to
reproduce on m68k also, but addsi patterns are expanded differently there so
the failing condition doesn't trigger.
[Bug target/57106] [4.8/4.9 Regression] -fcompare-debug failure with -O2 -fschedule-insns -funroll-all-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57106 Uros Bizjak changed: What|Removed |Added Component|rtl-optimization|target --- Comment #4 from Uros Bizjak 2013-05-03 11:53:35 UTC --- Target issue.
[Bug rtl-optimization/57106] [4.8/4.9 Regression] -fcompare-debug failure with -O2 -fschedule-insns -funroll-all-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57106 Uros Bizjak changed: What|Removed |Added CC||ubizjak at gmail dot com, ||ysrumyan at gmail dot com --- Comment #3 from Uros Bizjak 2013-05-03 11:49:51 UTC --- The dependence in i386.c:add_parameter_dependencies adds dependence of the instruction with wrong index. Proposed patch: --cut here-- Index: i386.c === --- i386.c (revision 198569) +++ i386.c (working copy) @@ -24662,7 +24662,7 @@ add_parameter_dependencies (rtx call, rtx head) /* Add output depdendence between two function arguments if chain of output arguments contains likely spilled HW registers. */ if (is_spilled) - add_dependence (last, insn, REG_DEP_OUTPUT); + add_dependence (first_arg, insn, REG_DEP_OUTPUT); first_arg = last = insn; } else --cut here-- CC'd author.
[Bug target/47769] [missed optimization] use of btr (bit test and reset)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47769 --- Comment #5 from Matthias Kretz 2013-05-03 11:45:49 UTC --- Another ping. The bug status is still WAITING...
[Bug bootstrap/57154] [4.9 Regression] Bootstrap broken for powerpc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57154 --- Comment #2 from Bill Schmidt 2013-05-03 11:45:06 UTC --- There is a powerpc64 pool machine available. I believe it's gcc110.
[Bug tree-optimization/57027] [4.9 Regression] ICE in gimple_assign_rhs_code, at gimple.h:2022
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57027 --- Comment #6 from dave.anglin at bell dot net 2013-05-03 11:27:33 UTC --- On 3-May-13, at 6:11 AM, amylaar at gcc dot gnu.org wrote: > The preprocessed testcase from the first attachment fails needs a > different > > sanity check in convert_mult_to_fma, which I have added in this > amended patch. Yes, I just found that build still fails with first patch at same place. Will try amended patch. -- John David Anglindave.ang...@bell.net
[Bug c++/57038] Latest libreoffice compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038 --- Comment #3 from Martin Liška 2013-05-03 11:20:00 UTC --- lto-partition.c:265 (add_symbol_to_partition) c++filt: std::_Tuple_impl<0ul, int const&>::_Tuple_impl() dump_symtab_node: _ZNSt11_Tuple_implILm0EJRKiEEC1Ev/281156 (_ZNSt11_Tuple_implILm0EJRKiEEC1Ev) @0x7f5a9bc5fab0 Type: function Visibility: prevailing_def_ironly_exp public weak artificial References: _ZNSt11_Tuple_implILm0EIRKiEEC1Ev/281155 (alias) Referring: Read from file: /home/marxin/Programming/libreoffice/workdir/unxlngx6.pro/CxxObject/comphelper/source/property/propagg.o Availability: overwritable Function flags: analyzed finalized alias Alias of __comp_ctor (asm: _ZNSt11_Tuple_implILm0EIRKiEEC1Ev) Called by: Calls: After iterating on lto-partition.c:274 add_symbol_to_partition_1 is called for the following node, where assert was reached: c++filt: dump_symtab_node: _ZNSt11_Tuple_implILm0EIRKiEEC1Ev/281155 (__comp_ctor ) @0x7f5a9bc5fbe0 Type: function Visibility: external public visibility_specified References: Referring: _ZNSt11_Tuple_implILm0EJRKiEEC1Ev/281156 (alias) Read from file: /home/marxin/Programming/libreoffice/workdir/unxlngx6.pro/CxxObject/comphelper/source/property/propagg.o Availability: not_available Function flags: Called by: Calls: Thanks, Martin
[Bug tree-optimization/57027] [4.9 Regression] ICE in gimple_assign_rhs_code, at gimple.h:2022
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57027 --- Comment #5 from Richard Biener 2013-05-03 10:53:50 UTC --- (In reply to comment #4) > Created attachment 30016 [details] > amended patch > > Using an i686-px-linux-gnu X hppa64-hp-hpux11.11 cross compiler, I've > verified that the previous patch fixes the gcc.c-torture/compile/991202-1.c > and gcc.dg/pr52132.c failures. The gcc.dg/pr41345.c compare-debug failure > happens independent of my code in convert_mult_to_fma. > I can't run the gcc.dg/torture/vec-cvt-1.c tests on my cross for lack of > header > files. > > The preprocessed testcase from the first attachment fails needs a different > sanity check in convert_mult_to_fma, which I have added in this amended patch. Patch looks good.
[Bug c++/57155] casting to const reference error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57155 --- Comment #3 from Jonathan Wakely 2013-05-03 10:51:10 UTC --- Keep reading 5.4, you didn't get to the bit about type conversions.
[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57074 --- Comment #12 from Alan Modra 2013-05-03 10:47:22 UTC --- Created attachment 30017 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30017 Use .org instead of padding in section anchor block This one ensures that offsets of emitted items exactly match the values calculated in place_block_symbol(). Right now that means we die building libjava with lots of "Error: attempt to move .org backwards" from gas.
[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57074 --- Comment #11 from Alan Modra 2013-05-03 10:42:12 UTC --- No, of course that doesn't work. We make references into the section anchor block as .LANCHORn+offset, so the items in the block must be exactly where place_block_symbol() expects them to be.
[Bug libstdc++/57158] std::list.erase(const_iterator pos) not implemented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57158 --- Comment #2 from Paolo Carlini 2013-05-03 10:36:15 UTC --- Matter of priorities. Note that unordered and associative containers and forward_list are already fine.
[Bug libstdc++/54577] deque::erase() still takes iterator instead of const_iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54577 Jonathan Wakely changed: What|Removed |Added CC||mattyclarkson at gmail dot ||com --- Comment #4 from Jonathan Wakely 2013-05-03 10:36:00 UTC --- *** Bug 57158 has been marked as a duplicate of this bug. ***
[Bug libstdc++/57158] std::list.erase(const_iterator pos) not implemented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57158 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Jonathan Wakely 2013-05-03 10:36:00 UTC --- yes, this is known and documented: http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2011 *** This bug has been marked as a duplicate of bug 54577 ***
[Bug c++/57155] casting to const reference error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57155 --- Comment #2 from rockeet 2013-05-03 10:35:53 UTC --- In this case, C++ shouldn't create a temporal object and bound the const ref to it. The C++ standard (C++11) says: 5.2.1 Subscripting [expr.sub] 1 A postfix expression followed by an expression in square brackets is a postfix expression. One of the expres- sions shall have the type “pointer to T” and the other shall have unscoped enumeration or integral type. The result is an lvalue of type “T.” The type “T” shall be a completely-defined object type.61The expression E1[E2] is identical (by definition) to *((E1)+(E2)) [Note: see 5.3 and 5.7 for details of * and + and 8.3.4 for details of arrays. —end note ] 5.3.1 Unary operators [expr.unary.op] 1 The unary * operator performs indirection: the expression to which it is applied shall be a pointer to an object type, or a pointer to a function type and the result is an lvalue referring to the object or function to which the expression points. If the type of the expression is “pointer to T,” the type of the result is “T.” [Note: a pointer to an incomplete type (other than cv void) can be dereferenced. The lvalue thus obtained can be used in limited ways (to initialize a reference, for example); this lvalue must not be converted to a prvalue, see 4.1. —end note ] 5.4 Explicit type conversion (cast notation) [expr.cast] 1 The result of the expression (T) cast-expression is of type T. The result is an lvalue if T is an lvalue reference type or an rvalue reference to function type and an xvalue if T is an rvalue reference to object type; otherwise the result is a prvalue. [Note: if T is a non-class type that is cv-qualified, the cv-qualifiers are ignored when determining the type of the resulting prvalue; see 3.10. —end note ]
[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 CC||paolo.carlini at oracle dot ||com --- Comment #1 from Paolo Carlini 2013-05-03 10:32:45 UTC --- I'm wondering: does it *ever* make sense to print 0 as column? Otherwise we could just tweak diagnostic_build_prefix.
[Bug libstdc++/57158] New: std::list.erase(const_iterator pos) not implemented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57158
Bug #: 57158
Summary: std::list.erase(const_iterator pos) not implemented
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mattyclark...@gmail.com
#include
int main() {
std::list list;
list.emplace_back(15);
list.emplace_back(14);
list.erase(list.begin()); // OK
list.erase(list.cbegin()); // Not implemented
return 0;
}
As per 23.3.5.4 of the standard.
The other containers need implementations too.
Not the end of the world and it might be already on your roadmap for the
library.
[Bug tree-optimization/57027] [4.9 Regression] ICE in gimple_assign_rhs_code, at gimple.h:2022
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57027 Jorn Wolfgang Rennecke changed: What|Removed |Added Attachment #30004|0 |1 is obsolete|| --- Comment #4 from Jorn Wolfgang Rennecke 2013-05-03 10:11:24 UTC --- Created attachment 30016 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30016 amended patch Using an i686-px-linux-gnu X hppa64-hp-hpux11.11 cross compiler, I've verified that the previous patch fixes the gcc.c-torture/compile/991202-1.c and gcc.dg/pr52132.c failures. The gcc.dg/pr41345.c compare-debug failure happens independent of my code in convert_mult_to_fma. I can't run the gcc.dg/torture/vec-cvt-1.c tests on my cross for lack of header files. The preprocessed testcase from the first attachment fails needs a different sanity check in convert_mult_to_fma, which I have added in this amended patch.
[Bug middle-end/57073] __builtin_powif (-1.0, k) should be optimized to "1.0 - 2.0 * (K%2)"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57073 --- Comment #9 from Tobias Burnus 2013-05-03 09:58:20 UTC --- After some discussion with Jakub and Richard - and after doing some code reads, I think it is best do handle this in tree-ssa-math-opts.c (search for gimple_expand_builtin_powi and BUILT_IN_POWI). For the code insertion, asan.c's build_check_stmt can serve as template.
[Bug middle-end/57147] [4.9 Regression]: setjmp call and if body wrongly elided (function runs off early end)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57147
--- Comment #5 from Richard Biener 2013-05-03
09:57:17 UTC ---
A similar testcase is for not 'const' but 'noreturn' discovery which should
end up purging the fallthru edge.
struct __jmp_buf_tag {};
typedef struct __jmp_buf_tag jmp_buf[1];
extern int _setjmp (struct __jmp_buf_tag __env[1]);
jmp_buf g_return_jmp_buf;
void SetNaClSwitchExpectations (void)
{
__builtin_longjmp (g_return_jmp_buf, 1);
}
void TestSyscall(void)
{
SetNaClSwitchExpectations();
_setjmp (g_return_jmp_buf);
}
which triggers a similar bug in remove_fallthru_edge ...
[Bug target/57156] miscompilation of call to _mm_cmpeq_epi8(a, a) or _mm_comtrue_epu8(a, a) with uninitialized a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57156 --- Comment #5 from Matthias Kretz 2013-05-03 09:56:00 UTC --- (In reply to comment #4) > I wouldn't know how to counter this for the _mm_cmpeq_epi8 case Actually, I have yet to find something in the standard that says using an uninitialized __m128 is undefined behavior. ;) Thus the only standard that would define the rules here would be Intel's, no? And from reading their docs I understand that calling an intrinsics maps to the behavior you'd get when using the associated instruction. In this case comparing any XMM register with itself will result in what I expect.
[Bug c++/53540] C++11: using fails to be equivalent to typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53540 Paolo Carlini changed: What|Removed |Added CC||paul at preney dot ca --- Comment #10 from Paolo Carlini 2013-05-03 09:54:21 UTC --- *** Bug 54309 has been marked as a duplicate of this bug. ***
[Bug c++/54309] [C++11] type alias accessing class template typename
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54309 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.8.0, 4.9.0 Resolution||DUPLICATE --- Comment #6 from Paolo Carlini 2013-05-03 09:54:21 UTC --- Thus this works in the released 4.8.0. *** This bug has been marked as a duplicate of bug 53540 ***
[Bug c++/53846] [c++11] memory exhaustion on simple recursive function template that uses decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53846 --- Comment #4 from Paolo Carlini 2013-05-03 09:47:02 UTC --- It would be nice to either track down which patch fixed it (I vaguely remember something but I'm not sure) or have a testcase failing quickly and sharply.
[Bug middle-end/57147] [4.9 Regression]: setjmp call and if body wrongly elided (function runs off early end)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57147 --- Comment #4 from Richard Biener 2013-05-03 09:46:45 UTC --- It's fixup_cfg that removes the abnormal edge after ipa-pure-const figures that SetNaClSwitchExpectations () is const. And it's gimple_purge_dead_abnormal_call_edges that removes the abnormal edge despite it being fallthru as well. That results in the CFG to end in a dead point here and things go downhill.
[Bug target/57156] miscompilation of call to _mm_cmpeq_epi8(a, a) or _mm_comtrue_epu8(a, a) with uninitialized a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57156 --- Comment #4 from Matthias Kretz 2013-05-03 09:37:58 UTC --- (In reply to comment #3) > I think this is undefined code as you use a uninitialized. I wouldn't know how to counter this for the _mm_cmpeq_epi8 case, but for _mm_comtrue_epu8? How am I supposed to use this intrinsic?
[Bug c++/54318] [C++11] Bogus "template instantiation depth exceeds maximum" error + segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54318 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.8.0, 4.9.0 Resolution||FIXED --- Comment #3 from Paolo Carlini 2013-05-03 09:37:35 UTC --- Done.
[Bug middle-end/57147] [4.9 Regression]: setjmp call and if body wrongly elided (function runs off early end)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57147
--- Comment #3 from Richard Biener 2013-05-03
09:24:45 UTC ---
Reduced testcase, miscompiles at -O.
struct __jmp_buf_tag {};
typedef struct __jmp_buf_tag jmp_buf[1];
extern int _setjmp (struct __jmp_buf_tag __env[1]);
jmp_buf g_return_jmp_buf;
void SetNaClSwitchExpectations(void)
{
}
void TestSyscall(void)
{
SetNaClSwitchExpectations();
_setjmp (g_return_jmp_buf);
}
[Bug libgcc/57085] Segmentation Fault when building a c file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57085 synergye at codefi dot re changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #13 from synergye at codefi dot re 2013-05-03 09:23:52 UTC --- This is now fixed upstream. I don't know what actually fixed it, but syncing today and doing a fresh toolchain build allowed contents.c to build without an ICE. Thank you.
[Bug c++/54318] [C++11] Bogus "template instantiation depth exceeds maximum" error + segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54318 --- Comment #2 from Paolo Carlini 2013-05-03 09:20:10 UTC --- Too late for 4.7.x, but let me add the testcase to the testsuite, to be safe.
[Bug c/57157] New: Poor optimization of portable rotate idiom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57157
Bug #: 57157
Summary: Poor optimization of portable rotate idiom
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ni...@lysator.liu.se
The standard rotate idiom,
(x << n) | (x >> (32 - n))
is recognized by gcc (for concreteness, I discuss only the case that x
is an uint32_t here).
However, this is portable C only for n in the range 0 < n < 32. For n
== 0, we get x >> 32 which gives undefined behaviour according to the
C standard (6.5.7, Bitwise shift operators). To portably support n ==
0, one has to write the rotate as something like
(x << n) | (x >> ((-n) & 31))
And this is apparently not recognized by gcc. I compiled this test
program with "gcc -O3 -c -save-temps rot.c". Using gcc-4.6.3 on
GNU/Linux x86_64 (ubuntu):
typedef unsigned int uint32_t;
/* Allows 0 < n < 32 (n == 0 gives undefined behaviour) */
uint32_t
rot1(unsigned n, uint32_t x)
{
return (x << n) | (x >> (32 - n));
}
/* Allows 0 <= n < 32 */
uint32_t
rot2(unsigned n, uint32_t x)
{
return (x << n) | (x >> ((- n) & 31));
}
Generated assembler
.file"rot.c"
.text
.p2align 4,,15
.globlrot1
.typerot1, @function
rot1:
.LFB0:
.cfi_startproc
movl%esi, %eax
movl%edi, %ecx
roll%cl, %eax
ret
.cfi_endproc
.LFE0:
.sizerot1, .-rot1
.p2align 4,,15
.globlrot2
.typerot2, @function
rot2:
.LFB1:
.cfi_startproc
movl%edi, %ecx
movl%esi, %eax
negl%ecx
shrl%cl, %eax
movl%edi, %ecx
sall%cl, %esi
orl%esi, %eax
ret
.cfi_endproc
.LFE1:
.sizerot2, .-rot2
.ident"GCC: (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3"
.section.note.GNU-stack,"",@progbits
The desired result is of course to get a rotl instruction also for
rot2, instead of the combination of negl, shrl, sall, and orl.
Applying the above portability fix to my ROTL32 macro in GNU Nettle
results in a slowdown of almost 20% for cast128. This function depends
a lot on key-dependant rotates, where rotation counts of zero will
happen for some keys.
[Bug target/57156] miscompilation of call to _mm_cmpeq_epi8(a, a) or _mm_comtrue_epu8(a, a) with uninitialized a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57156 --- Comment #3 from Andrew Pinski 2013-05-03 09:16:20 UTC --- I think this is undefined code as you use a uninitialized.
[Bug target/57156] miscompilation of call to _mm_cmpeq_epi8(a, a) or _mm_comtrue_epu8(a, a) with uninitialized a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57156 --- Comment #2 from Matthias Kretz 2013-05-03 09:15:33 UTC --- The failure disappears with -fno-tree-ccp
[Bug c++/57044] The following code won't compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57044 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #9 from Paolo Carlini 2013-05-03 09:12:43 UTC --- Fixed then.
