[Bug target/50683] GCC compiles MPFR 3.1.0 wrongly on sparc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50683 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||WORKSFORME --- Comment #8 from Eric Botcazou 2011-10-19 07:00:06 UTC --- The problem will be fixed in the upcoming binutils 2.22 release.
[Bug middle-end/48087] [4.5/4.6/4.7 Regression] -Wall -Werror adds warnings over and above those generated by -Wall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48087 --- Comment #13 from rguenther at suse dot de 2011-10-19 07:48:30 UTC --- On Wed, 19 Oct 2011, manu at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48087 > > --- Comment #12 from Manuel López-Ibáñez 2011-10-19 > 01:44:12 UTC --- > I think the problem is the seen_error() test in gimple_push_cleanup. I am > guessing that it does some kind of "folding" that is skipped when an error has > been issued. There are two issues here: > > 1) Warnings converted to errors are not real errors, that is, the program is > still valid and we could in principle do whatever stuff we would do for a > valid > program. We could do s/seen_error/seen_any_error/, and then add > seen_real_error > (program_is_invalid). I bet most of the cases using seen_any_error, actually > mean program_is_invalid. I suppose that's reasonable.
[Bug tree-optimization/50789] New: Gather vectorization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50789
Bug #: 50789
Summary: Gather vectorization
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: hjl.to...@gmail.com, i...@gcc.gnu.org,
kirill.yuk...@intel.com
This is to track progress on vectorization using AVX2 v*gather* instructions.
The instructions allow plain unconditional gather, e.g.:
#define N 1024
float f[N];
int k[N];
float *l[N];
int **m[N];
float
f1 (void)
{
int i;
float g = 0.0;
for (i = 0; i < N; i++)
g += f[k[i]];
return g;
}
float
f2 (float *p)
{
int i;
float g = 0.0;
for (i = 0; i < N; i++)
g += p[k[i]];
return g;
}
float
f3 (void)
{
int i;
float g = 0.0;
for (i = 0; i < N; i++)
g += *l[i];
return g;
}
int
f4 (void)
{
int i;
int g = 0;
for (i = 0; i < N; i++)
g += **m[i];
return g;
}
should be able to vectorize all 4 loops. In f1/f2 it would use non-zero base
(the vector would contain just indexes into some array, which vgather sign
extends and adds to base), in f3/f4 it would use zero base - the vectors would
be vectors of pointers (resp. uintptr_t).
To vectorize the above I'm afraid we'd need to modify tree-data-ref.c as well
as tree-vect-data-ref.c, because the memory accesses aren't affine and already
dr_analyze_innermost gives up on those, doesn't fill in any of the DR_* stuff.
Perhaps with some flag and when the base resp. offset has vdef in the same loop
we could mark it somehow and at least fill in the other fields. It would
probably make alias decisions (in tree-vect-data-ref.c?) harder. Any ideas?
What is additionally possible is to conditionalize loads, either affine or not.
So something like:
for (i = 0; i < N; i++)
{
c = 6;
if (a[i] > 24)
c = b[i];
d[i] = c + e[i];
}
for the affine conditional accesses where the vector could be just { 0, 1, 2,
3, ... } but the mask from the comparison.
[Bug c++/41103] g++-4.3/4.4 generates wrong code on x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41103 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011-10-19 Ever Confirmed|0 |1 --- Comment #7 from Richard Guenther 2011-10-19 07:51:48 UTC --- Unlikely, it hasn't been properly analyzed and boost code is a mess. There are known issues with PTA and pointer-in-integer tricks. Use GCC 4.6.1 which should have this fixed. So, please try 4.5.3 and/or 4.6.1.
[Bug tree-optimization/50789] Gather vectorization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50789 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-10-19 CC||rguenth at gcc dot gnu.org Ever Confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Richard Guenther 2011-10-19 08:09:48 UTC --- Yeah, it would be a data-reference that doesn't quite fit into existing sets. The aliasing could be dealt with (just don't assume anything about the index). This sort of pattern happens in SPEC FP 2006 I think in a Fortran benchmark.
[Bug rtl-optimization/50788] [4.7 Regression] ICE: in merge_overlapping_regs, at regrename.c:318 with -mavx -fpeel-loops -fstack-protector-all and __builtin_ia32_maskloadpd256
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50788 Richard Guenther changed: What|Removed |Added Component|target |rtl-optimization Target Milestone|--- |4.7.0
[Bug lto/50786] temporary files not cleaned up on LTO errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50786 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011-10-19 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2011-10-19 08:13:48 UTC --- It's lto-wrapper that is supposed to cleanup the ltrans.o files generated by WPA stage. Maybe you mean different files though?
[Bug tree-optimization/50784] [4.7 regression] internal compiler error: segmentation fault in cgraph.c:327
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50784 Richard Guenther changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Target Milestone|--- |4.7.0
[Bug rtl-optimization/50782] optimize pragma not applying fast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50782 --- Comment #4 from Richard Guenther 2011-10-19 08:16:34 UTC --- The interaction of the optimize attribute/pragma with inlining are "interesting". For some options we prohibit inlining (but only for the target attribute/pragma I think), otherwise the callee inherits the settings of the caller - sometimes partly.
[Bug tree-optimization/50780] [4.7 Regression] ICE: verify_gimple failed: invalid operands in ternary operation with -ftree-vectorize -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50780 Richard Guenther changed: What|Removed |Added Keywords||ice-checking Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-10-19 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2011-10-19 08:18:44 UTC --- Hmm. Probably not properly "verified" in 4.6. Mine.
[Bug target/50779] always_inline function fails to inline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50779 Richard Guenther changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |WAITING Last reconfirmed||2011-10-19 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther 2011-10-19 08:21:35 UTC --- Please provide the error output. I suppose it is about the ProFileParser class methods. Does the error go away when removing the dllexport attribute?
[Bug bootstrap/50778] [4.7 Regression] Bootstrap failure on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50778 Richard Guenther changed: What|Removed |Added CC||dodji at gcc dot gnu.org Target Milestone|--- |4.7.0
[Bug c++/50785] [C++0x][constexpr] static constexpr double undefined reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50785 --- Comment #2 from Jonathan Wakely 2011-10-19 08:34:45 UTC --- The definition is required, see [class.static.data] p3 "A static data member of literal type can be declared in the class definition with the constexpr specifier; [...] The member shall still be defined in a namespace scope if it is odr-used (3.2) in the program and the namespace scope definition shall not contain an initializer."
[Bug target/50350] [4.6 Regression] ICE (segfault) in canonicalize_float_value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50350 --- Comment #7 from Jakub Jelinek 2011-10-19 08:46:11 UTC --- Author: jakub Date: Wed Oct 19 08:45:45 2011 New Revision: 180179 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180179 Log: PR target/50350 Backport from mainline 2011-09-27 Richard Sandiford PR middle-end/50386 PR middle-end/50326 * tree-sra.c (build_ref_for_model): Use the type of the field as the type of the COMPONENT_REF. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/tree-sra.c
[Bug bootstrap/50326] [4.7 regression] ICE in set_lattice_value, at tree-ssa-ccp.c:456
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50326 --- Comment #13 from Jakub Jelinek 2011-10-19 08:46:12 UTC --- Author: jakub Date: Wed Oct 19 08:45:45 2011 New Revision: 180179 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180179 Log: PR target/50350 Backport from mainline 2011-09-27 Richard Sandiford PR middle-end/50386 PR middle-end/50326 * tree-sra.c (build_ref_for_model): Use the type of the field as the type of the COMPONENT_REF. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/tree-sra.c
[Bug tree-optimization/50789] Gather vectorization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50789 --- Comment #2 from Ira Rosen 2011-10-19 08:47:03 UTC --- (In reply to comment #0) > To vectorize the above I'm afraid we'd need to modify tree-data-ref.c as well > as tree-vect-data-ref.c, because the memory accesses aren't affine and already > dr_analyze_innermost gives up on those, doesn't fill in any of the DR_* stuff. > Perhaps with some flag and when the base resp. offset has vdef in the same > loop > we could mark it somehow and at least fill in the other fields. It would > probably make alias decisions (in tree-vect-data-ref.c?) harder. Any ideas? We have something similar for SLP: if an access is not affine we just fill in what we can. But I don't really understand what can be filled in for f3/f4. I don't think any data dependence decision is possible for f3 and f4, since we can't prove anything. But in all the examples there are no stores, and we don't care about read-read. In f1 and f2 we know the base so, assuming no overflow, we can handle stores to a different array. > > What is additionally possible is to conditionalize loads, either affine or > not. Can't we treat it as an unconditional load for the dr analysis purposes?
[Bug libgomp/50386] [4.7 Regression] libgomp.h:87:5: error: unnamed struct/union that defines no instances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50386 --- Comment #9 from Jakub Jelinek 2011-10-19 08:46:12 UTC --- Author: jakub Date: Wed Oct 19 08:45:45 2011 New Revision: 180179 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180179 Log: PR target/50350 Backport from mainline 2011-09-27 Richard Sandiford PR middle-end/50386 PR middle-end/50326 * tree-sra.c (build_ref_for_model): Use the type of the field as the type of the COMPONENT_REF. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/tree-sra.c
[Bug bootstrap/50778] [4.7 Regression] Bootstrap failure on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50778 --- Comment #2 from Dominique d'Humieres 2011-10-19 09:00:43 UTC --- I have bootstrapped revision 180100 on powerpc-apple-darwin9 configured with ../work/configure --prefix=/opt/gcc/gcc4.7w --enable-languages=c,c++,fortran,objc,obj-c++,java,ada,lto --with-gmp=/sw --with-libiconv-prefix=/usr --with-system-zlib --with-cloog=/sw --enable-lto --enable-cloog-backend=isl after reverting revisions 180081 to 180086, and 180090. Unless someone come with a fix before, I'll try to restore the revisions one by one to narrow the range, but each bootstrap takes ~14 hours, so don't hold your breath!-).
[Bug tree-optimization/50789] Gather vectorization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50789
--- Comment #3 from Jakub Jelinek 2011-10-19
09:02:26 UTC ---
(In reply to comment #2)
> We have something similar for SLP: if an access is not affine we just fill in
> what we can. But I don't really understand what can be filled in for f3/f4.
Well, we should be able to at least use TBAA in that case:
void
f5 (void)
{
int i;
for (i = 0; i < N; i++)
k[i] += *l[i];
}
should be vectorizable too, as l[i] can't overlap k[i] (normal data dep) and
*l[i], being float read, can't alias with k[i] either (int).
Similarly perhaps:
void
f6 (float *__restrict f, float *__restrict *__restrict l)
{
int i;
for (i = 0; i < N; i++)
f[i] += *l[i];
}
(though that one unlikely very soon).
With these gather accesses we can't do any runtime alias checking before the
loop, either we can prove there is no alias, or we can't vectorize.
> Can't we treat it as an unconditional load for the dr analysis purposes?
For that surely, but the conditional loads have other problems for the
vectorizer, currently that means control flow within the loop. We'd need to
transform it (perhaps temporarily or using pattern recognizer) to something
without control flow that would still be clear on that the load is only
conditional.
[Bug target/50350] [4.6 Regression] ICE (segfault) in canonicalize_float_value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50350 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #8 from Jakub Jelinek 2011-10-19 09:03:23 UTC --- Hopefully fixed.
[Bug tree-optimization/50735] [4.7 Regression] gcc.dg/torture/vector-2.c:52:1: ICE: verify_ssa failed at -O1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50735 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Jakub Jelinek 2011-10-19 09:04:17 UTC --- Fixed.
[Bug tree-optimization/50746] [4.7 Regression] FAIL: gcc.dg/vect/pr37482.c (internal compiler error) on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50746 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #10 from Dominique d'Humieres 2011-10-19 09:05:13 UTC --- The failures are gone at revision 180100 with the the revisions given in pr50778 reverted and the patch of revision 180106. So I am closing this pr as fixed.
[Bug target/50766] Binutils 2.22.51 rejects bmi2 pext operation with memory operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50766 Uros Bizjak changed: What|Removed |Added CC||hjl.tools at gmail dot com, ||kirill.yukhin at intel dot ||com --- Comment #1 from Uros Bizjak 2011-10-19 09:04:49 UTC --- CC author ob BMI2 intrinsics.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #119 from Jan Hubicka 2011-10-19 09:22:01 UTC --- Some up to date perfomrance data. WPA peaks 3.1GB in TOP now. (3261 virt). Overall compile time is 4m32s real, 21m14 user. GGC memory is GC 2248537k -> 1727826k WPA time report: callgraph optimization : 1.68 ( 1%) usr 0.00 ( 0%) sys 1.70 ( 1%) wall 16008 kB (11%) ggc varpool construction: 0.66 ( 0%) usr 0.02 ( 0%) sys 0.68 ( 0%) wall 55300 kB (39%) ggc ipa cp : 1.70 ( 1%) usr 0.09 ( 1%) sys 1.79 ( 1%) wall 75845 kB (53%) ggc ipa lto gimple out : 9.40 ( 6%) usr 0.91 (10%) sys 10.36 ( 6%) wall 0 kB ( 0%) ggc ipa lto decl in : 45.99 (29%) usr 1.66 (19%) sys 47.95 (28%) wall 3285797 kB (2315%) ggc ipa lto decl out: 35.61 (22%) usr 1.65 (19%) sys 37.23 (22%) wall 0 kB ( 0%) ggc ipa lto cgraph I/O : 3.73 ( 2%) usr 0.22 ( 2%) sys 3.95 ( 2%) wall 621046 kB (438%) ggc ipa lto decl merge : 5.75 ( 4%) usr 0.00 ( 0%) sys 5.75 ( 3%) wall 803 kB ( 1%) ggc ipa lto cgraph merge: 2.79 ( 2%) usr 0.02 ( 0%) sys 2.81 ( 2%) wall 27731 kB (20%) ggc inline heuristics : 31.32 (19%) usr 0.13 ( 1%) sys 31.48 (18%) wall 252282 kB (178%) ggc TOTAL : 161.21 8.82 170.40 141952 kB (i.e. 60% of overall compilation time and about 1/3 if streaming in 1/3 of straming out and 1/5th for inliner). oprofile of streaming in: 9467 6.8109 lto1 htab_find_slot_with_hash 9036 6.5008 lto1 inflate_fast 6608 4.7540 libc-2.11.1.so memset 6256 4.5008 libc-2.11.1.so _int_malloc 6243 4.4914 lto1 pointer_map_insert 5694 4.0965 lto1 lto_input_tree 5014 3.6072 lto1 gt_ggc_mx_lang_tree_node 4522 3.2533 lto1 streamer_read_tree_bitfields 4463 3.2108 lto1 ggc_set_mark 4087 2.9403 opreport /usr/bin/opreport 3661 2.6339 lto1 ggc_internal_alloc_stat 3475 2.5000 lto1 streamer_read_uhwi 2508 1.8043 lto1 gimple_type_eq 2418 1.7396 lto1 streamer_read_tree_body 2310 1.6619 libc-2.11.1.so memcpy 2292 1.6489 lto1 streamer_tree_cache_insert_1 2255 1.6223 libc-2.11.1.so memcmp 2119 1.5245 lto1 ht_lookup_with_hash 1902 1.3684 lto1 iterative_hash_hashval_t 1885 1.3561 lto1 lto_fixup_types 1884 1.3554 libc-2.11.1.so _int_free 1872 1.3468 lto1 uniquify_nodes 1842 1.3252 lto1 htab_expand 1825 1.3130 oprofiled/usr/bin/oprofiled 1813 1.3043 lto1 adler32 1734 1.2475 lto1 htab_hash_string 1509 1.0856 libc-2.11.1.so _IO_vfscanf 1470 1.0576 libc-2.11.1.so malloc_consolidate pointer map and htab is mostly type merging still, I believe. oprofile of inliner: 8772 37.9215 lto1 edge_badness 5532 23.9149 lto1 do_estimate_growth_1 1647 7.1200 lto1 update_caller_keys 1484 6.4154 lto1 can_inline_edge_p 744 3.2163 lto1 estimate_calls_size_and_time.isra.32 509 2.2004 lto1 estimate_edge_size_and_time.constprop.65 495 2.1399 lto1 fibheap_consolidate 267 1.1542 lto1 fibheap_extr_min_node 210 0.9078 lto1 cgraph_maybe_hot_edge_p I.e. easy to handle by taming down amout of heap updating. Stream out: 3371119.7166 lto1 lto1 varpool_node_for_asm 13947 8.1572 lto1 lto1 decl_assembler_name_equal 8873 5.1896 lto1 lto1 pointer_map_insert 8765 5.1264 lto1 lto1 linemap_lookup 6809 3.9824 lto1 lto1 lto_output_tree 4931 2.8840 lto1 lto1 inflate_fast 4718 2.7594 lto1 lto1 streamer_write_uhwi_stream 3521 2.0593 lto1 lto1 streamer_tree_cache_insert_1 3340 1.9535 lto1 lto1 splay_tree_splay 3293 1.9260 lto1 lto1 streamer_pack_tree_bitfields 3210 1.8774 libc-2.11.1.so libc-2.11.1.so memcpy 3175 1.8570 libc-2.11.1.so libc-2.11.1.so
[Bug target/50766] Binutils 2.22.51 rejects bmi2 pext operation with memory operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50766 --- Comment #2 from Yukhin Kirill 2011-10-19 09:37:17 UTC --- Hi, this is obviously a bug (introduced by me). Memory operand in GCC notation must occur at first place.
[Bug target/50766] Binutils 2.22.51 rejects bmi2 pext operation with memory operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50766 --- Comment #3 from Yukhin Kirill 2011-10-19 09:38:22 UTC --- Created attachment 25553 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25553 Patch I am testing it by now
[Bug tree-optimization/50789] Gather vectorization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50789
Ira Rosen changed:
What|Removed |Added
CC||irar at il dot ibm.com
--- Comment #4 from Ira Rosen 2011-10-19 09:38:06 UTC
---
(In reply to comment #3)
> (In reply to comment #2)
> > We have something similar for SLP: if an access is not affine we just fill
> > in
> > what we can. But I don't really understand what can be filled in for f3/f4.
>
> Well, we should be able to at least use TBAA in that case:
> void
> f5 (void)
> {
> int i;
> for (i = 0; i < N; i++)
> k[i] += *l[i];
> }
> should be vectorizable too, as l[i] can't overlap k[i] (normal data dep) and
> *l[i], being float read, can't alias with k[i] either (int).
I meant that we can't decompose *l[i] any further.
> With these gather accesses we can't do any runtime alias checking before the
> loop, either we can prove there is no alias, or we can't vectorize.
Agreed.
>
> > Can't we treat it as an unconditional load for the dr analysis purposes?
>
> For that surely, but the conditional loads have other problems for the
> vectorizer, currently that means control flow within the loop. We'd need to
> transform it (perhaps temporarily or using pattern recognizer) to something
> without control flow that would still be clear on that the load is only
> conditional.
Something like this
http://gcc.gnu.org/ml/gcc-patches/2010-11/msg00304.html ?
[Bug target/50766] Binutils 2.22.51 rejects bmi2 pext operation with memory operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50766 --- Comment #4 from Uros Bizjak 2011-10-19 09:46:50 UTC --- (In reply to comment #2) > Hi, > this is obviously a bug (introduced by me). > Memory operand in GCC notation must occur at first place. Please note that gcc also supports Intel notation with -masm=intel. Probably you need to introduce multiple variants of assembler languages syntax into insn templates. Please see "Instruction output" section in GCC Internals manual.
[Bug target/50766] Binutils 2.22.51 rejects bmi2 pext operation with memory operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50766 --- Comment #5 from Yukhin Kirill 2011-10-19 09:48:51 UTC --- (In reply to comment #4) > (In reply to comment #2) > > Hi, > > this is obviously a bug (introduced by me). > > Memory operand in GCC notation must occur at first place. > > Please note that gcc also supports Intel notation with -masm=intel. Probably > you need to introduce multiple variants of assembler languages syntax into > insn > templates. Please see "Instruction output" section in GCC Internals manual. Thanks, I'll verify it as well
[Bug target/50779] always_inline function fails to inline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50779 --- Comment #3 from Ruben Van Boxem 2011-10-19 10:17:54 UTC --- Sorry about that: m:\Development\source\qtcreator\src\shared\proparser\profileparser.cpp: In member function 'void ProFileParser::leaveScope(ushort*&)': m:\Development\source\qtcreator\src\shared\proparser\profileparser.cpp:203:6: sorry, unimplemented: inlining failed in call to 'void ProFileParser::putBlockLen(ushort*&, uint)': function not inlinable m:\Development\source\qtcreator\src\shared\proparser\profileparser.cpp:813:31: sorry, unimplemented: called from here m:\Development\source\qtcreator\src\shared\proparser\profileparser.cpp:198:6: sorry, unimplemented: inlining failed in call to 'void ProFileParser::putTok(ushort*&, ushort)': function not inlinable m:\Development\source\qtcreator\src\shared\proparser\profileparser.cpp:816:38: sorry, unimplemented: called from here And yes, the error does go away if I comment out ProfileParser's "PROPARSER_EXPORT" qualifier.
[Bug target/50779] always_inline function fails to inline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50779 --- Comment #4 from Richard Guenther 2011-10-19 10:23:37 UTC --- So it's probably similar to ELF platforms using a weak always-inline function. Thus a conflict in marking it replacable at link-time and inlinable. If dllexport does not have this semantic then there is something to be fixed, otherwise not.
[Bug target/50779] always_inline function fails to inline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50779 --- Comment #5 from Ruben Van Boxem 2011-10-19 10:37:37 UTC --- There's this on msdn about inline and dllexport: http://msdn.microsoft.com/en-us/library/xa0d9ste.aspx On top of this, MSVC allows its __forceinline to be used in a dllexport context, so I would assume GCC could do the same thing in this case.
[Bug c++/38761] %s substituted with regular word can't be properly translated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38761 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED CC|gcc-bugs at gcc dot | |gnu.org, paolo.carlini at | |oracle dot com | AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com --- Comment #8 from Paolo Carlini 2011-10-19 10:54:19 UTC --- I just checked 0.18.1 and is still unable to extract from conditional expressions. I guess we want to add a few more G_(), as also pointed out elsewhere. I'll do it.
[Bug bootstrap/50778] [4.7 Regression] Bootstrap failure on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50778 --- Comment #3 from Dodji Seketeli 2011-10-19 10:55:28 UTC --- Could I have ssh access to one of the boxes that fail?
[Bug target/50733] avr-gcc 4.3.5 generates incorrect code when using PROGMEM macro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50733 Jan Waclawek changed: What|Removed |Added CC||wek at host dot sk --- Comment #1 from Jan Waclawek 2011-10-19 11:01:13 UTC --- You cannot access variables placed into FLASH using the PROGMEM macro simply by their name as if they would be normal variables (which are located in RAM). You have to use dedicated functions such as pgm_read_byte() prototyped in Please refer to the relevant portions of avr-libc user manual http://www.nongnu.org/avr-libc/user-manual/pgmspace.html and/or the PROGMEM tutorial on avrfreaks.net http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=38003&start=all&postdays=0&postorder=asc
[Bug translation/40872] String not extracted for translation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED CC|gcc-bugs at gcc dot gnu.org |paolo.carlini at oracle dot ||com AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com --- Comment #22 from Paolo Carlini 2011-10-19 11:07:22 UTC --- Mine.
[Bug fortran/50790] New: ICE in copy_constant on divide by expression that evaluates to zero
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50790 Bug #: 50790 Summary: ICE in copy_constant on divide by expression that evaluates to zero Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: jonathan.h...@stfc.ac.uk The following code produces an ICE for me: program test implicit none integer :: i i = 3 print *, "chk", 3/(i-i) end program test This should presumably produce Error: Division by zero at compile time (or run time if we're not being clever). Produced with: GNU Fortran (Debian 4.6.1-4) 4.6.1 Copyright (C) 2011 Free Software Foundation, Inc. Thanks, Jonathan.
[Bug target/34352] Multi-line descriptions are not picked up for translation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34352 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #3 from Manuel López-Ibáñez 2011-10-19 12:05:00 UTC --- Göran, you seem to care about these things. As you see, the main GCC devs, do not. So if you really want to get this fixed, you have to submit patches. This particular kind of issue is so trivial that you don't need a copyright assignment. Just send a patch to gcc-patches@. I am pretty sure that if you put js...@gcc.gnu.org in the CC and ask him to commit it for you, he will. If he doesn't, you write directly to me and I will commit it in your name. Send a patch for each .opt file were you find the problem. If you know awk, maybe you could propose a patch to the genopt awk scripts to detect this issue automatically and fix it.
[Bug target/50310] [4.7 Regression] ICE: in gen_vcondv2div2df, at config/i386/sse.md:1435 with -O -ftree-vectorize and __builtin_isunordered()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50310 --- Comment #16 from Ulrich Weigand 2011-10-19 12:17:41 UTC --- Author: uweigand Date: Wed Oct 19 12:17:35 2011 New Revision: 180184 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180184 Log: PR target/50310 * config/spu/spu.c (spu_emit_vector_compare): Support unordered floating-point comparisons. Modified: trunk/gcc/ChangeLog trunk/gcc/config/spu/spu.c
[Bug bootstrap/50778] [4.7 Regression] Bootstrap failure on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50778 --- Comment #4 from Iain Sandoe 2011-10-19 12:22:04 UTC --- (In reply to comment #3) > Could I have ssh access to one of the boxes that fail? unfortunately, I can't do that - company boxes here afflicted by company policy; Jack Howarth seems to be able to - I think he might have a PPC box still. Otherwise we can offer to try and answer specific questions; I've got other fails in struc-layout etc. that are bus errors in libcpp: e.g. Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x _cpp_pop_context (pfile=0x41806600) at /GCC/gcc-live-trunk/libcpp/macro.c:2139 2139 pfile->context->next = NULL; (gdb) bt #0 _cpp_pop_context (pfile=0x41806600) at /GCC/gcc-live-trunk/libcpp/macro.c:2139 #1 0x00937b44 in cpp_get_token_1 (pfile=0x14, location=0xbfffedac) at /GCC/gcc-live-trunk/libcpp/macro.c:2328 #2 0x00937684 in enter_macro_context (pfile=0xbfffedac, node=0x4204e160, result=0x41809a00, location=1242616) at /GCC/gcc-live-trunk/libcpp/macro.c:2074 #3 0x00937b44 in cpp_get_token_1 (pfile=0x41806600, location=0xbfffef08) at /GCC/gcc-live-trunk/libcpp/macro.c:2328 #4 0x000ac398 in preprocess_file (pfile=0x41806600) at /GCC/gcc-live-trunk/gcc/c-family/c-ppoutput.c:177 #5 0x000aa450 in c_common_init () at /GCC/gcc-live-trunk/gcc/c-family/c-opts.c:1090 #6 0x0004cb98 in c_objc_common_init () at /GCC/gcc-live-trunk/gcc/c-objc-common.c:64 #7 0x006594b0 in toplev_main (argc=25, argv=0x0) at /GCC/gcc-live-trunk/gcc/toplev.c:1757 #8 0x2464 in start () Current language: auto; currently c++ (in case that's a hint).
[Bug c++/50785] [C++0x][constexpr] static constexpr double undefined reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50785 Paolo Carlini changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #3 from Paolo Carlini 2011-10-19 12:34:23 UTC --- Let's double check with Jason, the last line of the Description is a bit upsetting. Seems also related to PR50087 / note that -O "fixes" it.
[Bug c++/50785] [C++0x][constexpr] static constexpr double undefined reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50785 --- Comment #4 from Jonathan Wakely 2011-10-19 12:43:59 UTC --- test::value is an lvalue, binding a reference to it is an odr-use (1*test::value) produces an rvalue, the reference is not bound to test::value, so it is not odr-used
[Bug c++/50785] [C++0x][constexpr] static constexpr double undefined reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50785 --- Comment #5 from Jonathan Wakely 2011-10-19 12:46:00 UTC --- and I assume -O eliminates the reference binding due to inlining and value propagation this all seems normal for a missing definition of a static const member, like dozens of other invalid PRs
[Bug rtl-optimization/50340] [4.7 Regression] Fails to build SPEC 2000 176.gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50340 --- Comment #3 from Alexander Monakov 2011-10-19 12:46:48 UTC --- Author: amonakov Date: Wed Oct 19 12:46:44 2011 New Revision: 180186 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180186 Log: 2011-10-19 Andrey Belevantsev PR rtl-optimization/50340 * sel-sched-ir.c (update_target_availability): LHS register availability is not known if the unavailable LHS of the other expression is a different register. * gcc.dg/pr50340.c: New. Added: trunk/gcc/testsuite/gcc.dg/pr50340.c Modified: trunk/gcc/ChangeLog trunk/gcc/sel-sched-ir.c trunk/gcc/testsuite/ChangeLog
[Bug c++/50785] [C++0x][constexpr] static constexpr double undefined reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50785 --- Comment #6 from Paolo Carlini 2011-10-19 12:47:47 UTC --- I agree, I agree.
[Bug translation/40872] String not extracted for translation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872 --- Comment #23 from paolo at gcc dot gnu.org 2011-10-19 12:46:48 UTC --- Author: paolo Date: Wed Oct 19 12:46:42 2011 New Revision: 180185 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180185 Log: 2011-10-19 Paolo Carlini PR c++/38761 PR c++/40872 * decl.c (duplicate_decls, make_typename_type, grokdeclarator): Use G_() in error message strings to facilitate translation. * semantics.c (finish_id_expression): Likewise. * parser.c (cp_parser_nested_name_specifier_opt, cp_parser_parameter_declaration): Likewise. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/parser.c trunk/gcc/cp/semantics.c
[Bug rtl-optimization/50340] [4.7 Regression] Fails to build SPEC 2000 176.gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50340 Alexander Monakov changed: What|Removed |Added Priority|P1 |P3 Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Alexander Monakov 2011-10-19 12:47:49 UTC --- Fixed.
[Bug c++/38761] %s substituted with regular word can't be properly translated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38761 --- Comment #9 from paolo at gcc dot gnu.org 2011-10-19 12:46:47 UTC --- Author: paolo Date: Wed Oct 19 12:46:42 2011 New Revision: 180185 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180185 Log: 2011-10-19 Paolo Carlini PR c++/38761 PR c++/40872 * decl.c (duplicate_decls, make_typename_type, grokdeclarator): Use G_() in error message strings to facilitate translation. * semantics.c (finish_id_expression): Likewise. * parser.c (cp_parser_nested_name_specifier_opt, cp_parser_parameter_declaration): Likewise. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/parser.c trunk/gcc/cp/semantics.c
[Bug c++/38761] %s substituted with regular word can't be properly translated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38761 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #10 from Paolo Carlini 2011-10-19 12:53:07 UTC --- Fixed.
[Bug c++/50785] [C++0x] static constexpr double undefined reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50785
--- Comment #8 from Daniel Krügler
2011-10-19 12:54:24 UTC ---
I agree that the test case should require the definition of the static member,
the actual reason being that the constraint in 3.2 p2,
"[..] unless it is an object that satisfies the requirements for appearing in a
constant expression [..]"
is not satisfied, because the operator* of complex is not constexpr. Changing
the reference to std::complex by
template
struct complex {
private:
T data[2];
public:
constexpr complex(T r = 0, T i = 0) : data{r, i} {}
constexpr T real() { return data[0]; }
constexpr T imag() { return data[1]; }
};
template
constexpr complex operator*(const complex& lhs, const T& rhs)
{
return complex(lhs.real() * rhs, lhs.imag() * rhs);
}
also fixes the initial problem, because now the expression
complex(0,1)*test::value
satisfies the criteria to appear in a constant expression.
But I think that the replacement code
complex x = complex(0,1)*(1*test::value);
should also require the definition of test::value. It could be, that the
compiler now reduces the scope of the analysis to the sub-expression
(1*test::value). If so, this is either a compiler defect or a core language
defect, I'm not sure. It is arguable that the description
"[..] unless it is an object that satisfies the requirements for appearing in a
constant expression [..]"
is somewhat misleading, because it focuses on the object and not on the
expression where it is part of. This could be related to CWG #712 in this case.
[Bug c++/50791] internal compiler error in dependent_type_p_r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50791 --- Comment #1 from yar at sibnet dot ru 2011-10-19 12:52:47 UTC --- Created attachment 2 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=2 Similar code, not causing crash
[Bug c++/50791] internal compiler error in dependent_type_p_r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50791 --- Comment #2 from yar at sibnet dot ru 2011-10-19 12:54:59 UTC --- The code in first attachment make cc1plus stack overflow. The code in second attachment doesn't. Backtrace: #0 dependent_type_p (type=0xb7f22960) at ../../gcc/cp/pt.c:17459 #1 0x080766ec in dependent_type_p_r (type=0xb7f22cc0) at ../../gcc/cp/pt.c:17371 #2 dependent_type_p (type=0xb7f22cc0) at ../../gcc/cp/pt.c:17484 #3 0x08076772 in dependent_type_p_r (type=0xb7f22960) at ../../gcc/cp/pt.c:17448 #4 dependent_type_p (type=0xb7f22960) at ../../gcc/cp/pt.c:17484 #5 0x080766ec in dependent_type_p_r (type=0xb7f22cc0) at ../../gcc/cp/pt.c:17371 #6 dependent_type_p (type=0xb7f22cc0) at ../../gcc/cp/pt.c:17484 #7 0x08076772 in dependent_type_p_r (type=0xb7f22960) at ../../gcc/cp/pt.c:17448 #8 dependent_type_p (type=0xb7f22960) at ../../gcc/cp/pt.c:17484 #9 0x080766ec in dependent_type_p_r (type=0xb7f22cc0) at ../../gcc/cp/pt.c:17371 #10 dependent_type_p (type=0xb7f22cc0) at ../../gcc/cp/pt.c:17484 <...> #261894 dependent_type_p (type=0xb7f22cc0) at ../../gcc/cp/pt.c:17484 #261895 0x08076772 in dependent_type_p_r (type=0xb7f22960) at ../../gcc/cp/pt.c:17448 #261896 dependent_type_p (type=0xb7f22960) at ../../gcc/cp/pt.c:17484 #261897 0x080766ec in dependent_type_p_r (type=0xb7f22cc0) at ../../gcc/cp/pt.c:17371 #261898 dependent_type_p (type=0xb7f22cc0) at ../../gcc/cp/pt.c:17484 #261899 0x08076772 in dependent_type_p_r (type=0xb7f22960) at ../../gcc/cp/pt.c:17448 #261900 dependent_type_p (type=0xb7f22960) at ../../gcc/cp/pt.c:17484 #261901 0x080766ec in dependent_type_p_r (type=0xb7f22cc0) at ../../gcc/cp/pt.c:17371 #261902 dependent_type_p (type=0xb7f22cc0) at ../../gcc/cp/pt.c:17484 #261903 0x08076772 in dependent_type_p_r (type=0xb7f22960) at ../../gcc/cp/pt.c:17448 #261904 dependent_type_p (type=0xb7f22960) at ../../gcc/cp/pt.c:17484 #261905 0x080766ec in dependent_type_p_r (type=0xb7f22cc0) at ../../gcc/cp/pt.c:17371 #261906 dependent_type_p (type=0xb7f22cc0) at ../../gcc/cp/pt.c:17484 #261907 0x08076772 in dependent_type_p_r (type=0xb7f22960) at ../../gcc/cp/pt.c:17448 #261908 dependent_type_p (type=0xb7f22960) at ../../gcc/cp/pt.c:17484 #261909 0x080766ec in dependent_type_p_r (type=0xb7f22cc0) at ../../gcc/cp/pt.c:17371 #261910 dependent_type_p (type=0xb7f22cc0) at ../../gcc/cp/pt.c:17484 #261911 0x08076772 in dependent_type_p_r (type=0xb7f22960) at ../../gcc/cp/pt.c:17448 #261912 dependent_type_p (type=0xb7f22960) at ../../gcc/cp/pt.c:17484 #261913 0x080769f8 in dependent_template_arg_p (arg=0xb7f22960) at ../../gcc/cp/pt.c:17903 #261914 0x08076a89 in any_dependent_template_arguments_p (args=0xb7f2b3d4) at ../../gcc/cp/pt.c:17979 #261915 0x080775e8 in uses_template_parms (t=0xb7f2b3d4) at ../../gcc/cp/pt.c:7045 #261916 0x08077931 in register_specialization (spec=0xb7f2c100, tmpl=0xb7ec6c98, args=0xb7f2b3d4, is_friend=0 '\000', hash=1919156452) at ../../gcc/cp/pt.c:1280 #261917 0x08079a68 in tsubst_decl (t=0xb7f1c200, args=0xb7f2b3b8, complain=0) at ../../gcc/cp/pt.c:9214 #261918 0x0808a9a6 in instantiate_template (tmpl=0xb7ec6c98, orig_args=0xb7f2b3b8, complain=0) at ../../gcc/cp/pt.c:13082 #261919 0x08053221 in add_template_candidate_real (candidates=0xbfffe5d8, tmpl=0xb7ec6c98, ctype=0x0, explicit_targs=0x0, first_arg=0x0, arglist=0xb7f24a78, return_type=0x0, access_path=0x0, conversion_path=0x0, flags=3, obj=0x0, strict=DEDUCE_CALL) at ../../gcc/cp/call.c:2536 #261920 0x08053487 in add_template_candidate (fns=0xb7f24a8c, args=0xb7f24a78, explicit_targs=0x0, template_only=0 '\000', conversion_path=0x0, access_path=0x0, flags=3, candidates=0xbfffe5d8) at ../../gcc/cp/call.c:2612 #261921 add_candidates (fns=0xb7f24a8c, args=0xb7f24a78, explicit_targs=0x0, template_only=0 '\000', conversion_path=0x0, access_path=0x0, flags=3, candidates=0xbfffe5d8) at ../../gcc/cp/call.c:4118 #261922 0x08059fa7 in build_new_op (code=BIT_IOR_EXPR, flags=3, arg1=0xb7ea4488, arg2=0xb7f271cc, arg3=0x0, overloaded_p=0xbfffe74f "", complain=3) at ../../gcc/cp/call.c:4248 #261923 0x080c3c7b in build_x_binary_op (code=BIT_IOR_EXPR, arg1=0xb7ea4488, arg1_code=ERROR_MARK, arg2=, arg2_code=ERROR_MARK, overloaded_p=0xbfffe74f "", complain=3) at ../../gcc/cp/typeck.c:3490 #261924 0x080b2acb in cp_parser_binary_expression (parser=0xb7f25410, cast_p=, no_toplevel_fold_p=0 '\000', prec=PREC_NOT_OPERATOR, pidk=0x0) at ../../gcc/cp/parser.c:6464 #261925 0x080b2c77 in cp_parser_assignment_expression (parser=, cast_p=, pidk=) at ../../gcc/cp/parser.c:6561 #261926 0x080b31a1 in cp_parser_constant_expression (parser=0xb7f25410, allow_non_constant_p=1 '\001', non_constant_p=0xbfffe85e "") at ../../gcc/cp/parser.c:6786 #261927 0x080b34df in cp_parser_initializer_clause (parser=, non_constant_p=0xbfffe85e "") at ../../gcc/cp/parser.c:15512 #261928 0x080afbca in cp_parser_init_declarator (parser=0xb7f25410, decl_specifiers=0xbfffe894, checks=0x0, function_definiti
[Bug translation/40872] String not extracted for translation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #24 from Paolo Carlini 2011-10-19 12:53:46 UTC --- Fixed.
[Bug c++/50791] New: internal compiler error in dependent_type_p_r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50791 Bug #: 50791 Summary: internal compiler error in dependent_type_p_r Classification: Unclassified Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: y...@sibnet.ru Created attachment 25554 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25554 Code, causing crash
[Bug c++/50785] [C++0x][constexpr] static constexpr double undefined reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50785 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #7 from Paolo Carlini 2011-10-19 12:50:34 UTC --- I think the important message to vehicle to the users - correct me if I'm wrong - is that constexpr isn't "miraculous" from this point of view, old-style static and C++11 static constexpr data members both generally require out of class definitions.
[Bug tree-optimization/50768] [4.7 Regression] ICE: in execute_todo, at passes.c:1731 with -O2 -ftracer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50768 --- Comment #2 from Richard Guenther 2011-10-19 12:59:27 UTC --- Author: rguenth Date: Wed Oct 19 12:59:21 2011 New Revision: 180187 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180187 Log: 2011-10-19 Richard Guenther PR middle-end/50768 * gimple-fold.c (gimplify_and_update_call_from_tree): Rewrite. * gcc.dg/torture/pr50768.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr50768.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-fold.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/50768] [4.7 Regression] ICE: in execute_todo, at passes.c:1731 with -O2 -ftracer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50768 Richard Guenther changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Richard Guenther 2011-10-19 13:00:31 UTC --- Fixed.
[Bug c++/50785] [C++0x] static constexpr double undefined reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50785
--- Comment #9 from Jonathan Wakely 2011-10-19
13:04:29 UTC ---
(In reply to comment #8)
> I agree that the test case should require the definition of the static member,
> the actual reason being that the constraint in 3.2 p2,
>
> "[..] unless it is an object that satisfies the requirements for appearing in
> a
> constant expression [..]"
The rest of the sentence is relevant:
"... and the lvalue-to-rvalue conversion (4.1) is immediately applied."
> is not satisfied, because the operator* of complex is not constexpr.
I disagree. It is odr-used because the lvalue-to-rvalue conversions is not
immediately applied.
In (1*test::value) the lvalue-to-rvalue conversion is immediately applied.
> Changing
> the reference to std::complex by
>
> template
> struct complex {
> private:
> T data[2];
> public:
> constexpr complex(T r = 0, T i = 0) : data{r, i} {}
> constexpr T real() { return data[0]; }
> constexpr T imag() { return data[1]; }
> };
>
> template
> constexpr complex operator*(const complex& lhs, const T& rhs)
> {
> return complex(lhs.real() * rhs, lhs.imag() * rhs);
> }
>
> also fixes the initial problem, because now the expression
>
> complex(0,1)*test::value
>
> satisfies the criteria to appear in a constant expression.
It is the _object_ (i.e. test:value) that needs to satisfy the criteria for
appearing in a constant expression, not the expression containing it.
test::value satisfies the criteria.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #120 from Jan Hubicka 2011-10-19 13:05:25 UTC --- weakref reorg saves about 15 seconds, so we have total WPA time 145s and decl out at 19s (13%). Honza
[Bug c++/50785] [C++0x] static constexpr double undefined reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50785 --- Comment #10 from Daniel Krügler 2011-10-19 13:07:44 UTC --- (In reply to comment #9) > I disagree. It is odr-used because the lvalue-to-rvalue conversions is not > immediately applied. > > In (1*test::value) the lvalue-to-rvalue conversion is immediately applied. I tend to agree. My first impression was that the core language is unclear here, but after some rethought I think the core language is clear and your argumentation chain is convincing to me.
[Bug target/50766] Binutils 2.22.51 rejects bmi2 pext operation with memory operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50766 --- Comment #6 from Yukhin Kirill 2011-10-19 13:09:30 UTC --- Thread on gcc-patches ML: http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01719.html
[Bug c++/50791] [c++0x] internal compiler error in dependent_type_p_r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50791 Jonathan Wakely changed: What|Removed |Added Keywords||ice-on-invalid-code Known to work||4.7.0 Summary|internal compiler error in |[c++0x] internal compiler |dependent_type_p_r |error in dependent_type_p_r Known to fail||4.6.1 --- Comment #3 from Jonathan Wakely 2011-10-19 13:08:58 UTC --- You forgot to mention -std=c++0x (please follow the http://gcc.gnu.org/bugs/ instructions) This seems to be fixed on trunk
[Bug translation/48638] gcc/plugin.c: "inacessible" -> "inaccessible"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48638 --- Comment #1 from paolo at gcc dot gnu.org 2011-10-19 13:20:29 UTC --- Author: paolo Date: Wed Oct 19 13:20:22 2011 New Revision: 180188 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180188 Log: 2011-10-19 Roland Stigge PR translation/48638 * plugin.c (add_new_plugin): Fix typo in fatal_error message. 2011-10-19 Roland Stigge PR translation/49517 * config/rx/rx.c (rx_print_operand): Fix typo in warning message. /cp 2011-10-19 Roland Stigge PR translation/49704 * semantics.c (potential_constant_expression_1): Use "AST" instead of "ast" in sorry message. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rx/rx.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/plugin.c
[Bug translation/49517] Translation string typo in config/rx/rx.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49517 --- Comment #1 from paolo at gcc dot gnu.org 2011-10-19 13:20:28 UTC --- Author: paolo Date: Wed Oct 19 13:20:22 2011 New Revision: 180188 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180188 Log: 2011-10-19 Roland Stigge PR translation/48638 * plugin.c (add_new_plugin): Fix typo in fatal_error message. 2011-10-19 Roland Stigge PR translation/49517 * config/rx/rx.c (rx_print_operand): Fix typo in warning message. /cp 2011-10-19 Roland Stigge PR translation/49704 * semantics.c (potential_constant_expression_1): Use "AST" instead of "ast" in sorry message. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rx/rx.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/plugin.c
[Bug translation/49704] gcc/cp/semantics.c: "unexpected ast"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49704 --- Comment #3 from paolo at gcc dot gnu.org 2011-10-19 13:20:29 UTC --- Author: paolo Date: Wed Oct 19 13:20:22 2011 New Revision: 180188 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180188 Log: 2011-10-19 Roland Stigge PR translation/48638 * plugin.c (add_new_plugin): Fix typo in fatal_error message. 2011-10-19 Roland Stigge PR translation/49517 * config/rx/rx.c (rx_print_operand): Fix typo in warning message. /cp 2011-10-19 Roland Stigge PR translation/49704 * semantics.c (potential_constant_expression_1): Use "AST" instead of "ast" in sorry message. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rx/rx.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/plugin.c
[Bug translation/48638] gcc/plugin.c: "inacessible" -> "inaccessible"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48638 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #2 from Paolo Carlini 2011-10-19 13:21:51 UTC --- Fixed.
[Bug translation/49704] gcc/cp/semantics.c: "unexpected ast"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49704 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #4 from Paolo Carlini 2011-10-19 13:23:00 UTC --- Fixed for 4.7.0.
[Bug translation/49517] Translation string typo in config/rx/rx.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49517 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #2 from Paolo Carlini 2011-10-19 13:22:21 UTC --- Fixed.
[Bug translation/47912] translatable string typo: params.def:869: "paritition"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47912 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME Target Milestone|--- |4.7.0 --- Comment #1 from Paolo Carlini 2011-10-19 13:25:55 UTC --- Moot in mainline. Please double check, anyway.
[Bug c++/39409] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39409 David Edelsohn changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #4 from David Edelsohn 2011-10-19 13:32:52 UTC --- I assume the user has GCC 4.2.0 installed because that was the version available from IBM AIX Toolbox. Prebuilt binaries of more recent versions of GCC are available. I do not have GCC 4.2.0 available to test. GCC 4.1.3 compiles the file. GCC 4.2.4 complains about a deprecated convesion: warning: deprecated conversion from string constant to 'char*' GCC 4.3.x and above fail with errors and warnings in the libstdc++ header files. None of the versions of GCC to which I have access crash with an ICE. I believe that this was a bug in the .0 release that was fixed in a later update.
[Bug c++/50793] New: G++ doesn't value-initialize all members of non-trivial type in default argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50793
Bug #: 50793
Summary: G++ doesn't value-initialize all members of
non-trivial type in default argument
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: ja...@gcc.gnu.org
struct NonTrivial
{
NonTrivial() { }
};
struct S
{
NonTrivial nt;
int i;
};
int f(S s = S())
{
s.i = 0xdeadbeef;
return s.i;
}
int g(S s = S())
{
return s.i;
}
int main()
{
f(); // make stack dirty
if ( g() )
__builtin_abort();
}
This should not abort, the default argument of g() should be value-initialized,
which means:
C++03) if T is a non-union class type without a user-declared constructor, then
every non-static data member and base-class component of T is
value-initialized;
C++11) if T is a (possibly cv-qualified) non-union class type without a
user-provided constructor, then the object is zero-initialized and, if T’s
implicitly-declared default constructor is non-trivial, that constructor is
called.
If the implicitly-declared constructor S::S() is trivial, then S::i is
zero-initialized as expected. When S::S() is non-trivial,
NonTrivial::NonTrivial() is called correctly, but S::i is not zero-initialized.
N.B. the test does not fail if the default argument uses list-init, S{}
This was identified by my -Wmeminit patch for PR 2972 which identified
uninitialized data when doing:
std::vector v;
v.resize(1);
[Bug bootstrap/50777] [4.7 regression] bootstrap fails on Solaris 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50777 Rainer Orth changed: What|Removed |Added Status|NEW |ASSIGNED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-10/msg01726.htm ||l AssignedTo|unassigned at gcc dot |ro at gcc dot gnu.org |gnu.org | --- Comment #4 from Rainer Orth 2011-10-19 14:19:24 UTC --- Mine, patch submitted.
[Bug target/50705] Wrong assembly generated for bitwise AND for ppc 476
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50705
--- Comment #11 from SK 2011-10-19 14:22:16
UTC ---
FILE::
/mm/page_alloc.c:5363
flags -> 0x3
HASH_EARLY - > 0x1
CODE::
if (flags & HASH_EARLY)
Assembly:
70307c44: fe 0f e0 54 rlwinm r0,r7,1,31,31
r7 = 0x3 = 0011 (bits 0...31. So, bit 30 ==
1 and bit 31 == 1).
HASH_EARLY should ideally be seen by the compiler as
0001 (bits 0...31. So, bit 31 == 1).
So, if in Little Endian mode, then in PowerPC terms the above "if" is testing
bit 31 of the flags field.
In which case, the compiler should be generating assembly as: rlwinm
r0,r7,0,31,31
However, it appears the compiler sees HASH_EARLY as 1000
(bits 0...31. So, bit 0 == 1).
So, if in Little Endian mode, then in PowerPC terms the above "if" is testing
bit 0 of the flags field.
In which case, the compiler is generating assembly as: rlwinm r0,r7,1,31,31
CODE::
MMU_FTR_TYPE_47x has 0x40
cur_cpu_spec->mmu_features -> 0x140040
static inline int mmu_has_feature(unsigned long feature) {
return(cur_cpu_spec->mmu_features & feature); }
Assembly:
andis. r10,r11,512
What the above assembly instruction does is basically this: r10 = r11 & (512 <<
16) = r11 & 0x0200 (i.e. bit 6 is getting tested).
Now, where does 512 come from? Let's look at MMU_FTR_TYPE_47x:
MMU_FTR_TYPE_47x should ideally be seen by the compiler as
0100 (bits 0...31. So, bit 25 == 1).
So, if in Little Endian mode, then in PowerPC terms the above "&" operation is
testing bit 25 of the cur_cpu_spec->mmu_features field.
In which case, the compiler should be generating assembly as: andi. r10,r11,64
However, it appears the compiler sees MMU_FTR_TYPE_47x as 0010
(bits 0...31. So, bit 6 == 1).
So, if in Little Endian mode, then in PowerPC terms the above "&" is testing
bit 6 of the cur_cpu_spec->mmu_features field.
In which case, the compiler is generating assembly as: andis. r10,r11,512
++
Therefore it appears that constants are being interrupted wrongly i.e as a
mirror image.
Few Observations:
1) After I compile a small piece of code and run " file " the output
is
ELF 32-bit LSB executable, PowerPC, Versoin 1 (SYSV), dynamically linked (uses
shared libs), for GNU/Linux 2.6.39, not stripped
2) __LITTLE_ENDIAN is defined.
3) Though the above 2 are true the machine is still working in Big Endian.
confirmed by writing 1 into b and reading a[0]. which reads 0.
union endian{
unsigned int b;
unsigned char a[4] ;
}
++
[Bug target/50794] New: [picochip] incorrect implementation of ashrsi3 for negative numbers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50794 Bug #: 50794 Summary: [picochip] incorrect implementation of ashrsi3 for negative numbers Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: paulo.ma...@csr.com I was looking at the ashrsi3 implementation in picochip and I find something odd. I think it would generate incorrect results for negative numbers. Note, however that I have not tested the code, so this is through inspection only. Picochip ashrsi3.c contains the following piece of code: /* Given a word of sign bits, shift back left to create the destination sign bits. */ wordOfSignBits = __builtin_asri(value.s.high, 15); signWord = wordOfSignBits << reverseCount; result.s.high |= signWord; Note however that wordOfSignBits should be 0x for negative value.s.high and 0x for positive value.s.high. However, this will either be 0x for positive value.s.high or 0x0001 for negative value.s.high. This is because value.s.high is unsigned, so arithmetic shift will be performed as if on an unsigned value and the word will never contain the expected value. Replacing the above by: /* Given a word of sign bits, shift back left to create the destination sign bits. */ + HItype topword = value.s.high; + wordOfSignBits = __builtin_asri(topword, 15); - wordOfSignBits = __builtin_asri(value.s.high, 15); signWord = wordOfSignBits << reverseCount; result.s.high |= signWord;
[Bug lto/50786] temporary files not cleaned up on LTO errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50786 --- Comment #2 from Andi Kleen 2011-10-19 14:40:53 UTC --- I'm not 100% sure which stage generates them, but I have lots of cc*.o and some others (.res etc.) left over after the LTRANS failure. After two failures in a row i always have a full /.
[Bug tree-optimization/50717] [4.7 Regression] Silent code gen fault with incorrect widening of multiply
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50717 Andrew Stubbs changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Andrew Stubbs 2011-10-19 14:41:19 UTC --- The bug is now fixed.
[Bug tree-optimization/50780] [4.7 Regression] ICE: verify_gimple failed: invalid operands in ternary operation with -ftree-vectorize -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50780 --- Comment #2 from Richard Guenther 2011-10-19 14:54:41 UTC --- Author: rguenth Date: Wed Oct 19 14:54:34 2011 New Revision: 180192 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180192 Log: 2011-10-19 Richard Guenther PR middle-end/50780 * tree-ssa-forwprop.c (forward_propagate_into_cond): Verify the condition is properly gimple before using it. * tree-eh (stmt_could_throw_1_p): Properly extract the operation type from comparisons. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-eh.c trunk/gcc/tree-ssa-forwprop.c
[Bug tree-optimization/50780] [4.7 Regression] ICE: verify_gimple failed: invalid operands in ternary operation with -ftree-vectorize -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50780 Richard Guenther changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Richard Guenther 2011-10-19 14:55:29 UTC --- Fixed.
[Bug target/50447] [avr] Better support of AND, OR, XOR and PLUS with constant integers for 16- and 32-bit values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50447 --- Comment #6 from Georg-Johann Lay 2011-10-19 14:59:05 UTC --- Author: gjl Date: Wed Oct 19 14:59:00 2011 New Revision: 180193 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180193 Log: PR target/50447 * config/avr/avr.md (cc): New alternative out_plus_noclobber. (adjust_len): Ditto. (addhi3): Don't pipe through short; use gen_int_mode instead. Prior to reload, expand to gen_addhi3_clobber. (*addhi3): Use avr_out_plus_noclobber if applicable, use out_plus_noclobber in cc and adjust_len attribute. (addhi3_clobber): 2 new RTL peepholes. (addhi3_clobber): New insn. * config/avr/avr-protos.h: (avr_out_plus_noclobber): New prototype. * config/avr/avr.c (avr_out_plus_noclobber): New function. (notice_update_cc): Handle CC_OUT_PLUS_NOCLOBBER. (avr_out_plus_1): Tweak if only MSB is +/-1 and other bytes are 0. Set cc0 to set_zn for adiw on 16-bit values. (adjust_insn_length): Handle ADJUST_LEN_OUT_PLUS_NOCLOBBER. (expand_epilogue): No need to add 0 to frame_pointer_rtx. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr-protos.h trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.md
[Bug bootstrap/50778] [4.7 Regression] Bootstrap failure on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50778 --- Comment #5 from Dominique d'Humieres 2011-10-19 15:01:47 UTC --- > Could I have ssh access to one of the boxes that fail? I can give you access to my (slowww) G5 if you mail me your ssh key.
[Bug target/50733] avr-gcc 4.3.5 generates incorrect code when using PROGMEM macro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50733 --- Comment #2 from marcos_vc at coel dot com.br 2011-10-19 15:02:10 UTC --- In that case avr-gcc should print an error/warning when one try to access variables that way. I'm newbie for this specific target and this code compiles without any error or warning.
[Bug lto/50786] temporary files not cleaned up on LTO errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50786 --- Comment #3 from Richard Guenther 2011-10-19 15:18:21 UTC --- cc*.o files are supposed to be cleaned up by the driver(s). Are you sure you are not using -save-temps? ;)
[Bug middle-end/50790] ICE in copy_constant on divide by expression that evaluates to zero
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50790
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
Component|fortran |middle-end
--- Comment #1 from Tobias Burnus 2011-10-19
15:23:55 UTC ---
-fdump-tree-original:
static integer(kind=4) C.1534 = 3 / 0;
_gfortran_transfer_integer_write (&dt_parm.0, &C.1534, 4);
It gives with 4.7 the ICE:
internal compiler error: in copy_constant, at varasm.c:3031
I think it is - at least in general - not be detectable in the front end but
only in the ME.
A similar C test case works (cf. below for a simpler version); I think there is
no compiler option to print a warning -- at least -Wall -Wextra don't.
int
main ()
{
int i = 3;
printf ("%d\n", 3/(i-i));
return 0;
}
[Bug lto/50786] temporary files not cleaned up on LTO errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50786 --- Comment #4 from Andi Kleen 2011-10-19 15:28:07 UTC --- I'm not, this was a normal lto bootstrap without any special flags
[Bug middle-end/48087] [4.5/4.6/4.7 Regression] -Wall -Werror adds warnings over and above those generated by -Wall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48087 --- Comment #14 from Paolo Carlini 2011-10-19 15:39:08 UTC --- Thanks for explaining the seen_error mechanism, which I didn't know, but there is something I still don't understand here. Consider PR49508 (I'm interested because I opened it ;) : in that case we have only real errors, and then a bugus warning. I don't see how fiddling with something at beginning of gimple_push_cleanup could deal with such cases, and indeed if I hack it to remove the early return, the warning triggers exactly in the same way. Or maybe all this just indicated that PR49508 really is a different issue, but I'm not convinced...
[Bug tree-optimization/50763] [4.7 Regression] ICE: verify_gimple failed: missing PHI def with -ftree-tail-merge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50763 --- Comment #6 from vries at gcc dot gnu.org 2011-10-19 15:48:38 UTC --- Created attachment 25556 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25556 Updated patch, tries to keep dominance info up-to-date.
[Bug middle-end/49310] [4.7 Regression] Compile time hog in var-tracking emit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49310 --- Comment #10 from Alexandre Oliva 2011-10-19 15:50:04 UTC --- Author: aoliva Date: Wed Oct 19 15:50:00 2011 New Revision: 180194 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180194 Log: PR debug/49310 * var-tracking.c (loc_exp_dep, onepart_aux): New structs. (variable_part): Replace offset with union. (enum onepart_enum, onepart_enum_t): New. (variable_def): Drop cur_loc_changed, add onepart. (value_chain_def, const_value_chain): Remove. (VAR_PART_OFFSET, VAR_LOC_1PAUX): New macros, with checking. (VAR_LOC_DEP_LST, VAR_LOC_DEP_LSTP): New macros. (VAR_LOC_FROM, VAR_LOC_DEPTH, VAR_LOC_DEP_VEC): Likewise. (value_chain_pool, value_chains): Remove. (dropped_values): New. (struct parm_reg): Only if HAVE_window_save. (vt_stack_adjustments): Don't record register arguments. (dv_as_rtx): New. (dv_onepart_p): Return a onepart_enum_t. (onepart_pool): New. (dv_pool): Remove. (dv_from_rtx): New. (variable_htab_free): Release onepart aux data. Reset flags. (value_chain_htab_hash, value_chain_htab_eq): Remove. (unshare_variable): Use onepart field. Propagate onepart aux data or offset. Drop cur_loc_changed. (val_store): Cope with NULL insn. Rephrase dump output. Check for unsuitable locs. Add FIXME on using cselib locs. (val_reset): Remove FIXME of unfounded concerns. (val_resolve): Check for unsuitable locs. Add FIXME on using cselib locs. (variable_union): Use onepart field, adjust access to offset. (NO_LOC_P): New. (VALUE_CHANGED, DECL_CHANGED): Update doc. (set_dv_changed): Clear NO_LOC_P when changed. (find_loc_in_1pdv): Use onepart field. (intersect_loc_chains): Likewise. (unsuitable_loc): New. (loc_cmp): Keep ENTRY_VALUEs at the end of the loc list. (add_value_chain, add_value_chains): Remove. (add_cselib_value_chains, remove_value_chain): Likewise. (remove_value_chains, remove_cselib_value_chains): Likewise. (canonicalize_loc_order_check): Use onepart. Drop cur_loc_changed. (canonicalize_values_star, canonicalize_vars_star): Use onepart. (variable_merge_over_cur): Likewise. Adjust access to offset. Drop cur_loc_changed. (variable_merge_over_src): Use onepart field. (remove_duplicate_values): Likewise. (variable_post_merge_new_vals): Likewise. (find_mem_expr_in_1pdv): Likewise. (dataflow_set_preserve_mem_locs): Likewise. Drop cur_loc_changed and value chains. (dataflow_set_remove_mem_locs): Likewise. Use VAR_LOC_FROM. (variable_different_p): Use onepart field. Move onepart test out of the loop. (argument_reg_set): Drop. (add_uses, add_stores): Preserve but do not record in dynamic tables equivalences for ENTRY_VALUEs and CFA_based addresses. Avoid unsuitable address expressions. (EXPR_DEPTH): Unlimit. (EXPR_USE_DEPTH): Repurpose PARAM_MAX_VARTRACK_EXPR_DEPTH. (prepare_call_arguments): Use DECL_RTL_IF_SET. (dump_var): Adjust access to offset. (variable_from_dropped, recover_dropped_1paux): New. (variable_was_changed): Drop cur_loc_changed. Use onepart. Preserve onepart aux in empty_var. Recover empty_var and onepart aux from dropped_values. (find_variable_location_part): Special-case onepart. Adjust access to offset. (set_slot_part): Use onepart. Drop cur_loc_changed. Adjust access to offset. Initialize onepaux. Drop value chains. (delete_slot_part): Drop value chains. Use VAR_LOC_FROM. (VEC (variable, heap), VEC (rtx, stack)): Define. (expand_loc_callback_data): Drop dummy, cur_loc_changed, ignore_cur_loc. Add expanding, pending, depth. (loc_exp_dep_alloc, loc_exp_dep_clear): New. (loc_exp_dep_insert, loc_exp_dep_set): New. (notify_dependents_of_resolved_value): New. (update_depth, vt_expand_var_loc_chain): New. (vt_expand_loc_callback): Revamped. (resolve_expansions_pending_recursion): New. (INIT_ELCD, FINI_ELCD): New. (vt_expand_loc): Use the new macros above. Drop ignore_cur_loc parameter, adjust all callers. (vt_expand_loc_dummy): Drop. (vt_expand_1pvar): New. (emit_note_insn_var_location): Operate on non-debug decls only. Revamp multi-part cur_loc recomputation and one-part expansion. Drop cur_loc_changed. Adjust access to offset. (VEC (variable, heap)): Drop. (changed_variables_stack, changed_values_stack): Drop. (check_changed_vars_0, check_changed_vars_1): Remove. (check_changed_vars_2, check_changed_vars_3): Remove. (values_to_stack, remove_value_from_changed_variables): New. (notify_dependents_of_changed_value, process_changed_values): New. (emit_notes_for_changes): Revamp onepart updates. (emit_notes_for_differences_1): Use onepart. Drop cur_loc_changed and value chains. Propagate onepaux. Recover empty_var and onepaux from dropped_values. (emit_notes_for_differences_2): Drop value chains. (emit_notes_in_bb): Adjust. (vt_emit_notes): Drop value chains, changed_variables_stack. Initialize and release dropped_values. (create_entry_value): Revamp. (vt_add_function_parameter): Use new interface. (note_register_arguments): Remove. (vt_initialize): Drop value chains and register arguments. (vt_finalize): Drop value cha
[Bug middle-end/50795] New: [4.7 Regression] FAIL: gcc.dg/tree-ssa/builtin-expect-[1234].c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50795 Bug #: 50795 Summary: [4.7 Regression] FAIL: gcc.dg/tree-ssa/builtin-expect-[1234].c Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/x86, revision 180114 gave FAIL: gcc.dg/tree-ssa/builtin-expect-1.c scan-tree-dump-times gimple "builtin_expect[^\n]*, 0\);\n[^\n]*if" 2 FAIL: gcc.dg/tree-ssa/builtin-expect-2.c scan-tree-dump-times gimple "builtin_expect[^\n]*, 0\);\n[^\n]*if" 2 FAIL: gcc.dg/tree-ssa/builtin-expect-3.c scan-tree-dump-times gimple "builtin_expect[^\n]*, 0\);\n[^\n]*if" 2 FAIL: gcc.dg/tree-ssa/builtin-expect-4.c scan-tree-dump-times gimple "builtin_expect[^\n]*, 0\);\n[^\n]*if" 2 Revision 180105 is OK.
[Bug lto/50796] New: [4.7 Regression] FAIL: gcc.dg/plugin/plugindir[1234].c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50796 Bug #: 50796 Summary: [4.7 Regression] FAIL: gcc.dg/plugin/plugindir[1234].c Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/x86, revision 180189 gave FAIL: gcc.dg/plugin/plugindir1.c (test for excess errors) FAIL: gcc.dg/plugin/plugindir2.c (test for excess errors) FAIL: gcc.dg/plugin/plugindir3.c (test for excess errors) FAIL: gcc.dg/plugin/plugindir4.c (test for excess errors) Revision 180187 is OK.
[Bug middle-end/48087] [4.5/4.6/4.7 Regression] -Wall -Werror adds warnings over and above those generated by -Wall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48087 --- Comment #15 from Paolo Carlini 2011-10-19 15:53:01 UTC --- On this PR, removing the early return *works*, we have two non-bogus warnings with -Wall and two errors with -Werror. Maybe we should really proceed one PR at a time, re-open PR49508. Now, in detail: do I understand correctly that you are proposing we would use the new seen_real_errors *only* in gimple_push_cleanup? (at the moment I also honestly don't know how to tell errors from warnings from real errors, but of course can figure out myself)
[Bug lto/50786] temporary files not cleaned up on LTO errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50786 --- Comment #5 from Richard Guenther 2011-10-19 15:55:22 UTC --- You would need to debug this then - generally the drivers clean up after them (and I remember testing this, at least for the non-failing case ...)
[Bug bootstrap/50777] [4.7 regression] bootstrap fails on Solaris 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50777 --- Comment #5 from Rainer Orth 2011-10-19 16:02:35 UTC --- Author: ro Date: Wed Oct 19 16:02:30 2011 New Revision: 180195 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180195 Log: Properly test for madvise on Solaris 10 (PR bootstrap/50777) PR bootstrap/50777 * configure.ac: Save and restore CXXFLAGS around gcc_AC_CHECK_DECLS uses. Check for madvise() declaration with g++ if --enable-build-with-cxx. * configure: Regenerate. * config.in: Regenerate. * ggc-page.c (USING_MADVISE): Also check HAVE_DECL_MADVISE. Modified: trunk/gcc/ChangeLog trunk/gcc/config.in trunk/gcc/configure (contents, props changed) trunk/gcc/configure.ac trunk/gcc/ggc-page.c
[Bug middle-end/50795] [4.7 Regression] FAIL: gcc.dg/tree-ssa/builtin-expect-[1234].c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50795 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-10-19 CC||ktietz at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Dominique d'Humieres 2011-10-19 16:03:47 UTC --- A patch has been posted at http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01613.html .
[Bug bootstrap/50777] [4.7 regression] bootstrap fails on Solaris 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50777 Rainer Orth changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Rainer Orth 2011-10-19 16:21:35 UTC --- Fixed for 4.7.0.
[Bug tree-optimization/50769] [4.7 Regression] ICE: in phi_alternatives_equal, at tree-cfgcleanup.c:355 with -O2 -fno-delete-null-pointer-checks -fno-guess-branch-probability -fipa-pta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50769 --- Comment #4 from vries at gcc dot gnu.org 2011-10-19 16:29:52 UTC --- Author: vries Date: Wed Oct 19 16:29:42 2011 New Revision: 180197 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180197 Log: 2011-10-19 Tom de Vries PR tree-optimization/50769 * tree-ssa-tail-merge.c (replace_block_by): Calculate phi_vuse2 unconditionally. Handle case that phi_vuse2 is not an SSA_NAME. Add dummy argument .MEM to phi when increasing number of arguments of phi by redirecting edges to the block with phi. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-tail-merge.c
[Bug tree-optimization/50769] [4.7 Regression] ICE: in phi_alternatives_equal, at tree-cfgcleanup.c:355 with -O2 -fno-delete-null-pointer-checks -fno-guess-branch-probability -fipa-pta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50769 vries at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from vries at gcc dot gnu.org 2011-10-19 16:32:35 UTC --- patch checked in, marking fixed.
[Bug c++/50785] [C++0x] static constexpr double undefined reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50785
--- Comment #11 from trashyankes at wp dot pl 2011-10-19 16:35:06 UTC ---
it will be possible to add better waring/error in this case?
is complicity misleading when you use `static const` or `static constexpr` for
long time and when you try get ref that value you get error.
its get very weird when you have two lines that use it and only one give error.
code:
struct test
{
static const int z = 6;
static constexpr double t = 0.001;
};
template
T ref(const T& i)
{
return i;
}
template
T value(const T i)
{
return i;
}
int main()
{
value(test::z);
value(test::t);
ref(test::z); //error
ref(test::t); //error
}
until today i thought this code is correct.
maybe some info when you try take ref from const static objects?
[Bug bootstrap/50777] [4.7 regression] bootstrap fails on Solaris 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50777 --- Comment #7 from Sean McGovern 2011-10-19 16:39:15 UTC --- Thanks for the fix, bootstrapping that revision now. -- Sean McG. --Original Message-- From: ro at gcc dot gnu.org To: McGovern, Sean Subject: [Bug bootstrap/50777] [4.7 regression] bootstrap fails on Solaris 10 Sent: Oct 19, 2011 12:21 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50777 Rainer Orth changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Rainer Orth 2011-10-19 12:21:35 EDT --- Fixed for 4.7.0.
[Bug c++/50785] [C++0x] static constexpr double undefined reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50785 --- Comment #12 from Jonathan Wakely 2011-10-19 16:58:05 UTC --- (In reply to comment #11) > it will be possible to add better waring/error in this case? Not easily, the error you get is from the linker. This has been discussed MANY times in other bugzilla reports, search for PRs with status=RESOLVED and the words "static const undefined reference" > maybe some info when you try take ref from const static objects? No, because there is nothing wrong with doing that as long as you have a definition for the member. I do not want the compiler to complain when I write correct code just to remind people who write incorrect code not to forget something.
[Bug debug/49459] attribute((mode(byte))) in a typedef produces wrong debug information
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49459 Paul Koning changed: What|Removed |Added Known to fail||4.1.2 --- Comment #2 from Paul Koning 2011-10-19 17:00:09 UTC --- I see the same issue as far back as 4.1.2. As I mentioned, it works in 3.3.3. I compared readelf outputs. The difference is that in 3.3.3 the typedef points to a DW_TAG_base_type entry, which supplies the size of 1 -- but also makes the type look like "unsigned char" instead of enum. That at least doesn't break the debugger but it isn't ideal either. <1><6d>: Abbrev Number: 6 (DW_TAG_variable) <6e> DW_AT_name: foo <72> DW_AT_decl_file : 1 <73> DW_AT_decl_line : 4 <74> DW_AT_type: <0x3a> <78> DW_AT_external: 1 <79> DW_AT_location: 5 byte block: 3 1 0 0 0 (DW_OP_addr: 1) <1><3a>: Abbrev Number: 4 (DW_TAG_typedef) <3b> DW_AT_name: e1 <3e> DW_AT_decl_file : 1 <3f> DW_AT_decl_line : 1 <40> DW_AT_type: <0x44> <1><44>: Abbrev Number: 5 (DW_TAG_base_type) <45> DW_AT_name: (indirect string, offset: 0x0): unsigned char <49> DW_AT_byte_size : 1 <4a> DW_AT_encoding: 8(unsigned char)
