[Bug c/47882] Incorrect array subscript is above array bounds warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47882 --- Comment #2 from Anders Waldenborg anders at 0x63 dot nu 2011-02-25 08:51:47 UTC --- Is there a specific patch that fixes this problem? So I can backport the fix to 4.3.
[Bug target/46655] invalid '.line 0' directive emitted with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655 --- Comment #24 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2011-02-25 09:49:30 UTC --- (In reply to comment #23) Using your suggestion for gmake bootstrap STAGE1_FLAGS=-0 gets me much further in the build. The problem has moved to building libgomp, and the failure appears to be due to the fact that AIX nm needs nm -B to be compatible with the AIX ld. This acutally looks like bug#33637.
[Bug target/46655] invalid '.line 0' directive emitted with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655 --- Comment #25 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2011-02-25 09:53:57 UTC --- Ohw, and then there is bug#47032 (caused by bug#46481) you might stumble upon in libgfortran.
[Bug c/47892] New: Fails to vectorize comparison code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47892
Summary: Fails to vectorize comparison code
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jeremysal...@gmail.com
I have the following function
#define PIO6 0.523598776
#define SA5 2.74201854577e-06
#define SA4 -1.98410347969e-04
#define SA3 8.3320429e-03
#define SA2 -1.666e-01
static void bestseries9(float * __restrict__ arr,int len) {
for(int i=0; ilen; i++) {
float or=arr[i];
float orig=or / 3*(orPIO6);
float sqr=orig*orig;
arr[i]=orig*(1+sqr*(SA2+sqr*(SA3+sqr*(SA4+SA5*sqr;
arr[i]=arr[i]*(1+(orPIO6)*(2-4*arr[i]*arr[i]));
}
}
which should be vectorized, but it is not. If I turn on verbose vectorization,
it says that there is a conditional in the loop, and so it won't vectorize it.
[Bug c/47892] Fails to vectorize comparison code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47892 --- Comment #1 from jeremysalwen at gmail dot com 2011-02-25 10:19:58 UTC --- Note, even when switching to floating point constants: #define PIO6 0.523598776f #define SA5 2.74201854577e-06f #define SA4 -1.98410347969e-04f #define SA3 8.3320429e-03f #define SA2 -1.666e-01f and adding the option -fno-tree-pre it still won't vectorize
[Bug c/47892] Fails to vectorize comparison code, if-conversion fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47892 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.25 10:22:06 CC||rguenth at gcc dot gnu.org, ||spop at gcc dot gnu.org Summary|Fails to vectorize |Fails to vectorize |comparison code |comparison code, ||if-conversion fails Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-25 10:22:06 UTC --- We vectorize on trunk with -fno-tree-pre and float constants. Without -fno-tree-pre if-conversion is confused and on the 4.5 branch it doesn't if-convert if (or_10 5.2359879016876220703125e-1) goto bb 7; else goto bb 8; bb 7: bb 8: # iftmp.1_3 = PHI 1.0e+0(7), 0.0(6)
[Bug c/47892] Fails to vectorize comparison code, if-conversion fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47892
--- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-25
10:24:21 UTC ---
Testcase:
#define PIO6 0.523598776f
#define SA5 2.74201854577e-06f
#define SA4 -1.98410347969e-04f
#define SA3 8.3320429e-03f
#define SA2 -1.666e-01f
void bestseries9(float * __restrict__ arr,int len)
{
int i;
for(i=0; ilen; i++)
{
float or=arr[i];
float orig=or / 3*(orPIO6);
float sqr=orig*orig;
arr[i]=orig*(1+sqr*(SA2+sqr*(SA3+sqr*(SA4+SA5*sqr;
arr[i]=arr[i]*(1+(orPIO6)*(2-4*arr[i]*arr[i]));
}
}
[Bug c/47892] Fails to vectorize comparison code, if-conversion fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47892 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-25 10:31:49 UTC --- Ok, we vectorize on trunk only if I only make the PIO6 float. Otherwise if-conversion does not handle (even with -fno-tree-pre) if (or_10 5.2359879016876220703125e-1) goto bb 5; else goto bb 6; bb 5: orig_14 = or_10 * 3.33432674407958984375e-1; sqr_15 = __builtin_powf (orig_14, 2.0e+0); D.2699_19 = sqr_15 * 2.742018523349543102085590362548828125e-6; D.2700_20 = D.2699_19 + -1.98410343728028237819671630859375e-4; D.2701_21 = D.2700_20 * sqr_15; D.2702_22 = D.2701_21 + 8.32836627960205078125e-3; D.2703_23 = D.2702_22 * sqr_15; D.2704_24 = D.2703_23 + -1.667163372039794921875e-1; D.2705_25 = D.2704_24 * sqr_15; D.2706_26 = D.2705_25 + 1.0e+0; D.2707_27 = D.2706_26 * orig_14; bb 6: # iftmp.1_3 = PHI 1.0e+0(5), 0.0(4) # D.2707_59 = PHI D.2707_27(5), 0.0(4) D.2713_41 = __builtin_powf (D.2707_59, 2.0e+0); D.2714_42 = D.2713_41 * 4.0e+0; D.2715_43 = 2.0e+0 - D.2714_42; D.2716_44 = D.2715_43 * iftmp.1_3; I think if-conversion does not handle multiple PHIs in the merge block at all.
[Bug c/47892] Fails to vectorize comparison code, if-conversion fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47892 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-25 10:37:40 UTC --- PRE makes that better and we have bb 4: # i_39 = PHI i_47(7), 0(3) D.2691_6 = (long unsigned int) i_39; D.2692_7 = D.2691_6 * 4; D.2693_9 = arr_8(D) + D.2692_7; or_10 = MEM[(float *)D.2693_9]; if (or_10 5.2359879016876220703125e-1) goto bb 5; else goto bb 6; bb 5: orig_14 = or_10 * 3.33432674407958984375e-1; sqr_15 = __builtin_powf (orig_14, 2.0e+0); D.2699_19 = sqr_15 * 2.742018523349543102085590362548828125e-6; D.2700_20 = D.2699_19 + -1.98410343728028237819671630859375e-4; D.2701_21 = D.2700_20 * sqr_15; D.2702_22 = D.2701_21 + 8.32836627960205078125e-3; D.2703_23 = D.2702_22 * sqr_15; D.2704_24 = D.2703_23 + -1.667163372039794921875e-1; D.2705_25 = D.2704_24 * sqr_15; D.2706_26 = D.2705_25 + 1.0e+0; D.2707_27 = D.2706_26 * orig_14; D.2731_72 = __builtin_powf (D.2707_27, 2.0e+0); pretmp.11_75 = D.2731_72 * 4.0e+0; pretmp.11_77 = 2.0e+0 - pretmp.11_75; pretmp.11_81 = pretmp.11_77 + 1.0e+0; pretmp.11_83 = D.2707_27 * pretmp.11_81; bb 6: # prephitmp.12_84 = PHI pretmp.11_83(5), 0.0(4) MEM[(float *)D.2693_9] = prephitmp.12_84; i_47 = i_39 + 1; if (len_5(D) i_47) goto bb 7; else goto bb 8; if-conversion does not handle sqr_15 = __builtin_powf (orig_14, 2.0e+0); which we produce as canonicalization of x * x with -funsafe-math-optimizations.
[Bug c++/46341] [C++0X] ICE: in cxx_eval_vec_init_1, at cp/semantics.c:6362
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46341 Marc Glisse marc.glisse at normalesup dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Marc Glisse marc.glisse at normalesup dot org 2011-02-25 10:42:04 UTC --- I can't reproduce it anymore, it was likely fixed at the same time as one of the other constexpr bugs.
[Bug tree-optimization/47890] [4.5/4.6 Regression] internal compiler error: in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:1186
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47890 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.25 10:42:33 Target Milestone|--- |4.5.3 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-25 10:42:33 UTC --- Confirmed.
[Bug c++/47873] Multiple Inheritance - Covariant Virtual Function - Segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47873 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-02-25 10:47:00 UTC --- do you think you could make the example more confusing? maybe if you named every namespace, class and member function the same, instead of only doing that for most of them? ;)
[Bug lto/47871] lto1: internal compiler error: in list_length, at tree.c:2089
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47871 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-25 10:48:55 UTC --- It seems to work for me. Can you double-check?
[Bug fortran/47878] [4.6 Regression] 187.facerec miscompares
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47878 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #26 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-25 10:49:33 UTC --- Works again.
[Bug c++/33518] invalid Koenig lookup/incorrect SFINAE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33518 Marc Glisse marc.glisse at normalesup dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Marc Glisse marc.glisse at normalesup dot org 2011-02-25 10:49:33 UTC --- Can't reproduce with 4.6.
[Bug c++/33518] invalid Koenig lookup/incorrect SFINAE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33518 --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com 2011-02-25 10:54:37 UTC --- Ideally, we should figure in which release has been fixed. Do you think the small testcase in Comment #3 summarizes well the issue? Apparently works with 4.5.x too.
[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #25 from Tobias Burnus burnus at gcc dot gnu.org 2011-02-25 10:57:32 UTC --- I think the build bug is now FIXED; thus: Please shout loudly if there you still encounter a build failure! TO BE DONE: The HP-UX (et al.?) compile warning regarding the _r functions and _REENTRANT, cf. comment 20 and comment 23.
[Bug c/47892] Fails to vectorize comparison code, if-conversion fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47892 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-25 10:57:30 UTC --- On trunk fixed with a patch as simple as Index: gcc/tree-if-conv.c === *** gcc/tree-if-conv.c (revision 170466) --- gcc/tree-if-conv.c (working copy) *** if_convertible_stmt_p (gimple stmt, VEC *** 702,707 --- 702,711 case GIMPLE_ASSIGN: return if_convertible_gimple_assign_stmt_p (stmt, refs); + case GIMPLE_CALL: + return (gimple_call_fndecl (stmt) + (gimple_call_flags (stmt) (ECF_PURE|ECF_CONST))); + default: /* Don't know what to do with 'em so don't do anything. */ if (dump_file (dump_flags TDF_DETAILS))
[Bug c/47892] Fails to vectorize comparison code, if-conversion fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47892 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org |
[Bug c++/33518] invalid Koenig lookup/incorrect SFINAE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33518 --- Comment #9 from Marc Glisse marc.glisse at normalesup dot org 2011-02-25 11:05:58 UTC --- (In reply to comment #8) Ideally, we should figure in which release has been fixed. Do you think the small testcase in Comment #3 summarizes well the issue? Apparently works with 4.5.x too. Honestly, I don't even know the rules about which namespace to consider in overload resolution well enough to determine which behavior is correct. I reported it years ago because of the inconsistency caused by unrelated code. Then I tested today (the original test, not the short one from the comments) and couldn't reproduce (and the result seemed to agree with EDG and Oracle). Maybe I should have left it to someone more knowledgeable to close it...
[Bug c++/47873] Multiple Inheritance - Covariant Virtual Function - Segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47873 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-02-25 11:08:07 UTC --- this doesn't segfault with 4.5 I have a reduced version with no stdlib or c++0x dependencies, and with less confusing naming - will attach shortly
[Bug c++/33518] invalid Koenig lookup/incorrect SFINAE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33518 --- Comment #10 from Jonathan Wakely redi at gcc dot gnu.org 2011-02-25 11:13:07 UTC --- Clang accepts it too. It was probably fixed in 4.5 by Jason implementing the extended SFINAE rules
[Bug tree-optimization/45470] [4.6 Regression] ICE: verify_flow_info failed: BB 2 can not throw but has an EH edge with -ftree-vectorize -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45470 --- Comment #12 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-02-25 11:18:17 UTC --- Author: ebotcazou Date: Fri Feb 25 11:18:14 2011 New Revision: 170492 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170492 Log: PR tree-optimization/45470 * tree-vect-data-refs.c (vect_analyze_data_refs): Fail if a statement can throw internally only. * tree-vect-stmts.c (vectorizable_call): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-data-refs.c trunk/gcc/tree-vect-stmts.c
[Bug c++/47873] Multiple Inheritance - Covariant Virtual Function - Segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47873 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Attachment #23448|0 |1 is obsolete|| --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-02-25 11:37:37 UTC --- Created attachment 23465 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23465 reduced testcase reduced testcase which removes c++0x and libstdc++ dependencies, removes the java-style access control, re-indents and renames some of the identically-named namespaces, classes and function to make it slightly more readable
[Bug c++/47873] [4.6 Regression] Multiple Inheritance - Covariant Virtual Function - Segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47873 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.25 11:38:32 Summary|Multiple Inheritance - |[4.6 Regression] Multiple |Covariant Virtual Function |Inheritance - Covariant |- Segfault |Virtual Function - Segfault Ever Confirmed|0 |1 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2011-02-25 11:38:32 UTC --- confirmed, no crash with 4.5 or earlier
[Bug middle-end/47893] New: [4.6 Regression] 4.6 miscompiles mesa on i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47893 Summary: [4.6 Regression] 4.6 miscompiles mesa on i686 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: wrong-code Severity: blocker Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org Target: i686-linux Created attachment 23466 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23466 mesa.c The following testcase (distilled from http://bugzilla.redhat.com/679924 ) is miscompiled on i?86 (and x86_64 -m32). The problem is that struct S is 20 bytes long (why doesn't mesa pack the bitfield structs better is beyond me) and is returned indirectly via caller provided memory. The assembly shows: callfn1 # testl %eax, %eax # movl%eax, -4664(%ebp) #, %sfp ... leal-4680(%ebp), %eax #, callfn2 # ... cmpl%ebx, -4664(%ebp) # i, %sfp i.e. the return value from fn1 (variable c) is spilled into %ebp-4664, but fn2 is given as struct S return slot %ebp-4680, so when it returns it overwrites some 16 bytes reserved for the return value and the variable c as well.
[Bug libfortran/47894] New: Documentation text for VERIFY intrinsic function is wrong.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47894 Summary: Documentation text for VERIFY intrinsic function is wrong. Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: thenl...@users.sourceforge.net The documentation states: Verifies that all the characters in a SET are present in a STRING. but this should read: Verifies that no other characters than those in a SET are present in a STRING. or: Verifies that all the characters in STRING are present in a SET. Also, the sentence: If all characters of SET are found in STRING, the result is zero. again is wrong and should read: If no characters not in SET are found in STRING, the result is zero. or If only characters from SET are found in STRING, the result is zero. or If all characters of STRING are found in SET, the result is zero. or, as in Fortran 2008: The value of the result is zero if each character in STRING is in SET or if STRING has zero length. The headline is also misleading: VERIFY — Scan a string for the absence of a set of characters because the string is actually scanned for the absence (or presence) of characters NOT in SET (mathematically, that's a complement of SET, which is also a set, but confusing to read) Maybe it should read: VERIFY — Scan a string for the absence of characters not in a set or, as in Fortran 2008: Search for a character not in a given set.
[Bug middle-end/47893] [4.6 Regression] 4.6 miscompiles mesa on i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47893 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-25 12:48:38 UTC --- Seems to be caused by http://gcc.gnu.org/viewcvs?root=gccview=revrev=159480
[Bug middle-end/47893] [4.6 Regression] 4.6 miscompiles mesa on i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47893 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.25 12:51:14 Target Milestone|--- |4.6.0 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-25 12:51:14 UTC --- Confirmed.
[Bug middle-end/47893] [4.6 Regression] 4.6 miscompiles mesa on i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47893 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Known to work||4.6.0 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Known to fail||4.5.2 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-25 12:56:15 UTC --- Looking into it...
[Bug c++/47873] [4.6 Regression] virtual Inheritance - Covariant Virtual Function - Segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47873
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
Summary|[4.6 Regression] Multiple |[4.6 Regression] virtual
|Inheritance - Covariant |Inheritance - Covariant
|Virtual Function - Segfault |Virtual Function - Segfault
--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2011-02-25
13:07:26 UTC ---
minimal testcase with no namespaces or multiple inheritance
the segfault goes away if Ent is an empty class or if virtual inheritance isn't
used
struct Base
{
virtual ~Base(){}
virtual Base This() { return *this; }
};
struct Ent : virtual Base
{
void *m_Body;
Ent This() { return *this; }
virtual Ent body()
{
return This();
}
};
struct Msg : virtual Ent
{
Msg()
{
body();
}
Msg This() { return *this; }
};
int main()
{
Msg m;
return 0;
}
miscompiled by gcc-4.6-20110219 snapshot
Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0 0x in ?? ()
#1 0x004007ff in Ent::body (this=0x7fffe598) at bug.cc:17
#2 0x004009ca in Msg::Msg (this=0x7fffe590,
__in_chrg=value optimized out, __vtt_parm=value optimized out)
at bug.cc:27
#3 0x00400719 in main () at bug.cc:35
[Bug c/22133] In MinGW trailling slash forward not allowed in include path
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22133 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING CC||ktietz at gcc dot gnu.org --- Comment #8 from Kai Tietz ktietz at gcc dot gnu.org 2011-02-25 13:15:01 UTC --- (In reply to comment #0) For a detailed description of this bug see: https://sourceforge.net/tracker/?func=detailatid=102435aid=1053052group_id=2435 In short the file c-incpath.c (near line 331) needs to be modified to remove the trailing slash if HAVE_DOS_BASED_FILE_SYSTEM is true. It seems on newer windows systems the trailing slash starts to become a problem. My current makefiles all have trailing slashes for each include path to support compilers that require the trailing slash. As a result I can't upgrade to the latest MinGW gcc build. I classified this as minor since it effects portability of code. Does the patch from Nathan Froyd fixed the issue for you? My tests have shown that issue is solved by it, but I would like that you can confirm this.
[Bug middle-end/47895] New: usage of __attribute__ ((__target__ (xyz))) with buitins
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47895
Summary: usage of __attribute__ ((__target__ (xyz))) with
buitins
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch
I would like to generate code for multiple targets from the same source when
using builtins
(
I think that this issue has been discussed before for instance in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39840
)
I have code as in the example below that compiles only with -mavx.
In such a case it will use AVX instruction for all functions including the one
targetted for sse3
while I would like to obtain an object file that I can run on multiple
platform.
This problem occurs only when builtins are used: standard c code is correctly
emitted accordingly to the target provided that the minimal -m is used.
Is there any preprocessor flag to activate all intrinsics and builtins in
x86intrin.h?
-
example
#include x86intrin.h
float __attribute__ ((__target__ (sse3))) sum3(float const * __restrict__ x,
float const * __restrict__ y, float const * __restrict__ z) {
__m128 sum = _mm_setzero_ps();
for (int i=0; i!=1024; i+=4)
sum += _mm_add_ps(_mm_loadu_ps(z+i),
_mm_mul_ps(_mm_loadu_ps(x+i),_mm_loadu_ps(y+i)) );
sum = _mm_hadd_ps(sum,sum);
sum = _mm_hadd_ps(sum,sum);
float ret;
_mm_store_ss(ret,sum);
return ret;
}
float __attribute__ ((__target__ (avx))) sumv(float const * __restrict__ x,
float const * __restrict__ y, float const * __restrict__ z) {
__m256 sum = _mm256_setzero_ps();
for (int i=0; i!=1024; i+=8)
sum += _mm256_add_ps(_mm256_loadu_ps(z+i),
_mm256_mul_ps(_mm256_loadu_ps(x+i),_mm256_loadu_ps(y+i))
);
sum = _mm256_hadd_ps(sum,sum);
sum = _mm256_hadd_ps(sum,sum);
sum = _mm256_hadd_ps(sum,sum);
float ret[8];
_mm256_store_ps(ret,sum);
return ret[0];
}
[Bug libfortran/47567] Wrong output for small absolute values with F editing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567 --- Comment #26 from Thomas Henlich thenlich at users dot sourceforge.net 2011-02-25 13:58:51 UTC --- Created attachment 23467 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23467 Programmatic test case for multiple formats
[Bug libfortran/47567] Wrong output for small absolute values with F editing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567 Thomas Henlich thenlich at users dot sourceforge.net changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #27 from Thomas Henlich thenlich at users dot sourceforge.net 2011-02-25 14:00:18 UTC --- Way to go, still not quite right... print '(f3.0)', -1E-6 ! = -0. print '(f0.0)', -1E-6 ! = ** expected -0. Comprehensive testcase attached.
[Bug libstdc++/47433] libstdc++ parallel mode calls std::swap explicitely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47433 --- Comment #15 from singler at gcc dot gnu.org singler at gcc dot gnu.org 2011-02-25 14:04:48 UTC --- Author: singler Date: Fri Feb 25 14:04:40 2011 New Revision: 170494 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170494 Log: 2011-02-25 Johannes Singler sing...@kit.edu PR libstdc++/47433 * include/parallel/losertree.h (_LoserTree::__delete_min_insert): Do not qualify swap with std:: for value type, but include a using directive instead. (_LoserTreeUnguarded::__delete_min_insert): Likewise. * include/parallel/balanced_quicksort.h (__qsb_divide): Use std::iter_swap instead of std::swap. (__qsb_local_sort_with_helping): Likewise. * include/parallel/partition.h (__parallel_partition): Likewise. (__parallel_nth_element): Likewise. Modified: branches/gcc-4_5-branch/libstdc++-v3/ChangeLog branches/gcc-4_5-branch/libstdc++-v3/include/parallel/balanced_quicksort.h branches/gcc-4_5-branch/libstdc++-v3/include/parallel/losertree.h branches/gcc-4_5-branch/libstdc++-v3/include/parallel/partition.h
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246
Andreas Krebbel krebbel at gcc dot gnu.org changed:
What|Removed |Added
CC||krebbel at gcc dot gnu.org
--- Comment #4 from Andreas Krebbel krebbel at gcc dot gnu.org 2011-02-25
14:08:20 UTC ---
I also see uninit-13.c failing on s390x.
The warning here is also emitted for line 7 while being expected in
line 8.
4 typedef _Complex float C;
5 C foo()
6 {
7C f;
8__imag__ f = 0; /* { dg-warning is used unconditional } */
9return f;
10 }
The question is why do we expect the warning in line 8 at all?! To me
it makes sense to either emit the warning on the uninitialized use -
that would be the return f; in line 9 or emit it for the declaration
of the uninitialized variable - that would be line 7 then.
To my understanding line 8 is the only one not directly related to the
warning.
warn_uninit in tree-ssa.c seems to implement exactly this. It uses
either the location of the using gimple expression if available or it
falls back to the var decl. On s390x I see the var decl being used as
location while for x86_64 there is a stmt having its own location which
is used instead.
x86_64: uninit-13.c.083t.dce2:
foo ()
{
float f$real;
C f;
bb 2:
[gcc/testsuite/gcc.dg/uninit-13.c : 8:14] f_3 = COMPLEX_EXPR f$real_5(D),
0.0;
return f_3;
}
s390x: uninit-13.i.083t.dce2
foo ()
{
float f$real;
bb 2:
REALPART_EXPR retval = f$real_6(D);
[gcc/testsuite/gcc.dg/uninit-13.c : 9:3] IMAGPART_EXPR retval = 0.0;
[gcc/testsuite/gcc.dg/uninit-13.c : 9:3] return retval;
}
Before dce2 the line with the COMPLEX_EXPR exists also on s390x:
s390x: uninit-13.i.082t.reassoc1:
foo ()
{
float f$real;
C f;
float D.2702;
bb 2:
[gcc/testsuite/gcc.dg/uninit-13.c : 8:14] f$real_2 = f$real_6(D);
[gcc/testsuite/gcc.dg/uninit-13.c : 8:14] f_3 = COMPLEX_EXPR f$real_6(D),
0.0;
REALPART_EXPR retval = f$real_6(D);
[gcc/testsuite/gcc.dg/uninit-13.c : 9:3] IMAGPART_EXPR retval = 0.0;
[gcc/testsuite/gcc.dg/uninit-13.c : 9:3] return retval;
}
I think first we should fix the testcase - moving the warning one line
up and then find a way to fix the x86_64 problem. To me it currently
looks like this is a testcase bug.
[Bug middle-end/47895] usage of __attribute__ ((__target__ (xyz))) with buitins
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47895 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-25 14:44:27 UTC --- A way easier and more portable way is to split your source into multiple compilation units and use appropriate flags to compile them.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-25 14:51:22 UTC --- At what point does the direct access to IMAGPARTretval appear? That looks like the bug. Why isn't a temporary used for this? Does s390 return the complex number in memory?
[Bug middle-end/47893] [4.6 Regression] 4.6 miscompiles mesa on i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47893 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||bernds at gcc dot gnu.org, ||law at gcc dot gnu.org AssignedTo|jakub at gcc dot gnu.org|unassigned at gcc dot ||gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-25 15:40:22 UTC --- Ugh, this is ugly. The problem is that Bernd's changes conflict with the way assign_stack_temp_for_type/combine_temp_slots works. Both are now parallel lists of stack slot information, but they aren't aware of each other. So, when assign_stack_temp_for_type is called to allocate slot for 12 byte long 16 byte aligned slot (for fn7 return value), this internally calls assign_stack_local (why we CEIL_ROUND the size to 16 in that case is something I don't understand). assign_stack_local_1 sees the current frame offset is not 16 byte aligned, so it eats 8 bytes for alignment and 16 bytes for the actual stack slot. assign_stack_local_1 then calls add_frame_space for the extra 8 bytes, so that it can be used by something else later (by assign_stack_local_1) - this is Bernd's new code. But in assign_stack_temp_for_type it tracks the allocation in struct temp_slot, and there it records the whole stack block including whatever padding had to be made again (i.e. 24 bytes in this case). If assign_stack_local called from here will actually return something from the queued frame space slots, then frame_offset_old == frame_offset and thus it will do really weird things, that is something that needs to be fixed too, but is not something that happens in this case (I'd say if frame_offset_old == frame_offset and it wasn't BLKmode with size 0, then it should record as size/full_size just the requested size and nothing else). In this testcase afterwards assign_stack_temp_for_type is called for 20 byte BLKmode requesting 16 byte alignment, and as this is -fno-strict-aliasing, it chooses that it could share the temp slot with the above allocated one and as its size/full_size was 24, it just uses it. Nothing informs the frame_space list about this though and thus it will happily give that slot again during reload.
[Bug other/47869] fatal error: build/gencondmd.c: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47869 Ralf Wildenhues rwild at gcc dot gnu.org changed: What|Removed |Added CC||rwild at gcc dot gnu.org --- Comment #1 from Ralf Wildenhues rwild at gcc dot gnu.org 2011-02-25 15:52:14 UTC --- Which make version are you using? How exactly did you invoke make (-jN)? Thanks.
[Bug middle-end/47893] [4.6 Regression] 4.6 miscompiles mesa on i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47893
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-25
16:06:14 UTC ---
I guess not including the space added in add_frame_space by the
assign_stack_local_1 call in temp_slot's size/full_size, while it would be easy
to do (just walk the beginning of the frame_space list looking for slots that
overlap with what we'd like to include in size/full_size), would result in too
big stack wastage (e.g. in the given testcase suddenly the fn7 and fn2 return
slot couldn't be shared, even when it isn't clear if something would actually
like to use it or not). Similarly not queuing anything into frame_space lists
when assign_stack_local is called from within assign_stack_temp_for_type would
kill most of the savings Bernds' original patch had.
Perhaps we could add pointers from temp_slots to frame_space list and back,
when deciding to reuse an earlier temp_slot in assign_stack_temp_for_type we'd
walk the referenced list and remove frame_space entries that overlap it and
similarly when assign_stack_local_1 decides it wants to use a frame_space we'd
decrease size/full_size of the temp_slot that overlaps it.
We could of course try to prefer frame_space slots that don't overlap any
temp_slots.
Or perhaps don't try to use frame_space slots until virtuals_instantiated,
assuming assign_stack_temp_for_type/assign_stack_temp/assign_temp aren't called
after virtuals_instantiated is set, then we could just have links from
temp_slots to frame_space and not vice versa.
OT, on the other side, perhaps add_frame_space could be called e.g. for the
padding inserted in expand_used_vars by:
/* If the target requires that FRAME_OFFSET be aligned, do it. */
if (STACK_ALIGNMENT_NEEDED)
{
HOST_WIDE_INT align = PREFERRED_STACK_BOUNDARY / BITS_PER_UNIT;
if (!FRAME_GROWS_DOWNWARD)
frame_offset += align - 1;
frame_offset = -align;
}
and perhaps also without -fstack-protector for inter-variable padding
(alloc_stack_frame_space - with -fstack-protector it would be a security risk
to place spills above any arrays). But this OT isn't stage 4 matter.
[Bug middle-end/47893] [4.6 Regression] 4.6 miscompiles mesa on i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47893 --- Comment #6 from Bernd Schmidt bernds at gcc dot gnu.org 2011-02-25 16:10:55 UTC --- (In reply to comment #5) Similarly not queuing anything into frame_space lists when assign_stack_local is called from within assign_stack_temp_for_type would kill most of the savings Bernds' original patch had. I think that's worth trying though. I can't think of any other good solution at the moment short of reverting the whole thing.
[Bug middle-end/47893] [4.6 Regression] 4.6 miscompiles mesa on i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47893 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added CC||law at redhat dot com --- Comment #7 from Jeffrey A. Law law at redhat dot com 2011-02-25 16:40:56 UTC --- My temptation would be to revert until someone can get in there and design things so that we either have a single list or there's clear rules for manipulating objects in each list and reflecting the necessary information back and forth. Even with Jakub's suggestions my worry is other similar, subtle bugs are in there and will bite us later.
[Bug target/46898] libgcc build failure on lm32-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46898 --- Comment #9 from Sebastien Bourdeauducq lekernel at gcc dot gnu.org 2011-02-25 16:40:52 UTC --- I ran git bisect for this. Here is the result: 74897bc755ddcb5ff67a91570c83e910ed950c7c is the first bad commit commit 74897bc755ddcb5ff67a91570c83e910ed950c7c Author: rth rth@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Thu Aug 5 15:39:54 2010 + PR 45189 Unbreak ia64 build after last dwarf2out.c change. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@162917 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug tree-optimization/47890] [4.5/4.6 Regression] internal compiler error: in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:1186
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47890 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||irar at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-25 16:43:11 UTC --- Ira, Index: gcc/tree-vect-loop.c === *** gcc/tree-vect-loop.c(revision 170492) --- gcc/tree-vect-loop.c(working copy) *** get_initial_def_for_induction (gimple iv *** 2886,2891 --- 2886,2894 gimple_assign_set_lhs (new_stmt, induc_def); si = gsi_start_bb (bb); gsi_insert_before (si, new_stmt, GSI_SAME_STMT); + set_vinfo_for_stmt (new_stmt, + new_stmt_vec_info (new_stmt, loop_vinfo, NULL)); + STMT_VINFO_RELATED_STMT (vinfo_for_stmt (new_stmt)) = induction_phi; } return induc_def; fixes this for me, but I'm not familiar with how this related stmt stuff works, so can you please double-check? Thanks.
[Bug target/47715] [x32] TLS doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47715 --- Comment #7 from H.J. Lu hjl.tools at gmail dot com 2011-02-25 16:56:12 UTC --- Thread pointer really should be 32bit in x32.
[Bug middle-end/47893] [4.6 Regression] 4.6 miscompiles mesa on i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47893 --- Comment #8 from Bernd Schmidt bernds at gcc dot gnu.org 2011-02-25 17:24:15 UTC --- (In reply to comment #7) My temptation would be to revert until someone can get in there and design things so that we either have a single list or there's clear rules for manipulating objects in each list and reflecting the necessary information back and forth. Even with Jakub's suggestions my worry is other similar, subtle bugs are in there and will bite us later. We're not actually calling assign_stack_temp after the assign phase, are we? IMO we can set a flag once we expect to only call assign_stack_local, and start using the frame_space list after that point. There'll be no worries about inconsistent lists.
[Bug middle-end/47893] [4.6 Regression] 4.6 miscompiles mesa on i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47893 --- Comment #9 from Bernd Schmidt bernds at gcc dot gnu.org 2011-02-25 17:25:13 UTC --- Created attachment 23468 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23468 Test patch Does this fix it?
[Bug target/46898] libgcc build failure on lm32-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46898 --- Comment #10 from Joel Sherrill joel at gcc dot gnu.org 2011-02-25 17:30:46 UTC --- Richard I added this to you since I think Sebastian's bisect turned up a patch by you.
[Bug rtl-optimization/47862] Incorrect code for spilling a vector register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47862 --- Comment #3 from Pat Haugen pthaugen at gcc dot gnu.org 2011-02-25 17:36:03 UTC --- The following fixes the problem by changing the save mode for FP regs to V2DF mode for TARGET_VSX. But I have questions/concerns on this that need more digging: - I believe this will affect all FP reg saves, which will be overkill for SF/DF modes since we'll be allocating 16 bytes and doing full vector store/load. Can we modify save/restore code on the fly to use the appropriate size? - Any issues wrt stack slot reuse (i.e. can't reuse smaller slot for vector save)? Index: gcc/config/rs6000/rs6000.h === --- gcc/config/rs6000/rs6000.h (revision 170438) +++ gcc/config/rs6000/rs6000.h (working copy) @@ -1005,6 +1005,12 @@ extern unsigned rs6000_pointer_size; #define HARD_REGNO_NREGS(REGNO, MODE) rs6000_hard_regno_nregs[(MODE)][(REGNO)] +/* Ensure vector modes are handled correctly in FP regs for VSX */ +#define HARD_REGNO_CALLER_SAVE_MODE(REGNO, NREGS, MODE)\ + (TARGET_VSX FP_REGNO_P (REGNO)\ + ? V2DFmode \ + : choose_hard_reg_mode ((REGNO), (NREGS), false)) + #define HARD_REGNO_CALL_PART_CLOBBERED(REGNO, MODE)\ (((TARGET_32BIT TARGET_POWERPC64 \ (GET_MODE_SIZE (MODE) 4) \
[Bug middle-end/47893] [4.6 Regression] 4.6 miscompiles mesa on i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47893
--- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-25
17:39:36 UTC ---
I guess that would break pa, because then
else if (!STACK_ALIGNMENT_NEEDED)
{
...
}
will be executed whenever record_alignment_slots is false, even for non-zero
sizes or non-BLKmode.
Other than that, I think it would be better to change the bool argument into an
enum, after all we need just 3 variants, reduce_alignment_ok
record_alignment_slots (for caller-save), !reduce_alignment_ok
record_alignment_slots (for assign_stack_local) and !reduce_alignment_ok
!record_alignment_slots (for assign_stack_temp_for_type).
I'm currently running x86_64-linux and i686-linux bootstraps/regtests gathering
statistics, so far from the partial numbers I have a patch like that isn't
going to pessimize stuff too much, add_frame_space from within
assign_stack_temp_for_type accounts for like .5% of all add_frame_space calls
(and similarly in the number of bytes thus recorded).
[Bug target/46655] invalid '.line 0' directive emitted with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655 --- Comment #26 from David Edelsohn dje at gcc dot gnu.org 2011-02-25 17:52:21 UTC --- Richard, Did you look at the list of sites providing pre-built binaries for AIX listed on the GCC website: http://gcc.gnu.org/install/binaries.html There are multiple options who provide much newer versions of GCC than the ones included in the AIX Toolbox. - David
[Bug target/47852] crash with g++ -lpthread on irix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47852 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.02.25 18:31:39 CC||ro at gcc dot gnu.org AssignedTo|unassigned at gcc dot |ro at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.6.0 Ever Confirmed|0 |1 --- Comment #1 from Rainer Orth ro at gcc dot gnu.org 2011-02-25 18:31:39 UTC --- Mine. As suspected, libstdc++.so needs to be linked with -lpthread since emutls uses pthread_* functions, while libc provides only stubs for some of them. I'll regtest the corresponding trivial patch over the weekend.
[Bug middle-end/47893] [4.6 Regression] 4.6 miscompiles mesa on i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47893 --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-25 18:43:20 UTC --- Created attachment 23469 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23469 statistics gathering patch With this patch I got fncnt array summaries from i686-linux bootstrap/regtest: 56916 0 24380 27 96234 201 125938 699 1065459 5040 and from x86_64-linux bootstrap/regtest: 65358 0 11038 11 55139 84 91377 3184 701567 25806 This shows that assign_stack_temp_for_type is really never called during bootstrap/regtest after virtual reg instantiation and at least for i386 add_frame_space is called just in ~ .5% of cases (and similarly for the size). On x86_64 it happens more often, in ~ 3.5% of cases (haven't unfortunately tracked which of those successes to save something were from assign_stack_temp_for_type frame_space areas though. Thus, I think the proposed patch is the right way to go.
[Bug target/46898] libgcc build failure on lm32-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46898 --- Comment #11 from Sebastien Bourdeauducq lekernel at gcc dot gnu.org 2011-02-25 18:49:46 UTC --- Actually, Jon's patch (http://gcc.gnu.org/ml/gcc-patches/2010-10/msg02561.html) fixes this one problem introduced by Richard's commit. But after Jon's patch is applied, the next commit to break LM32 is: 5ae82d58486a4ee6a9a7d5ca5fef2b43c2d53eb4 is the first bad commit commit 5ae82d58486a4ee6a9a7d5ca5fef2b43c2d53eb4 Author: jsm28 jsm28@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Wed Sep 29 14:49:14 2010 + gcc: * optc-gen.awk: Generate global_options initializer instead of individual variables. Add x_ prefix to names of structure members. * opth-gen.awk: Generate gcc_options structure. Add x_ prefix to names of structure members. * doc/tm.texi.in (HARD_FRAME_POINTER_IS_FRAME_POINTER, HARD_FRAME_POINTER_IS_ARG_POINTER): Document. * doc/tm.texi: Regenerate. * alias.c: Use HARD_FRAME_POINTER_IS_FRAME_POINTER * builtins.c: Use HARD_FRAME_POINTER_IS_ARG_POINTER. * c-parser.c (disable_extension_diagnostics, restore_extension_diagnostics): Update names of cpp_options members. * combine.c: Use HARD_FRAME_POINTER_IS_FRAME_POINTER * common.opt (fcompare-debug-second): Don't use Var. * config/alpha/alpha.h (target_flags): Remove. * config/arm/arm.h (HARD_FRAME_POINTER_IS_FRAME_POINTER, HARD_FRAME_POINTER_IS_ARG_POINTER): Define. * config/bfin/bfin.h (target_flags): Remove. * config/cris/cris.h (target_flags): Remove. * config/i386/i386-c.c (ix86_pragma_target_parse): Update names of cl_target_option members. * config/i386/i386.c (ix86_force_align_arg_pointer): Remove. (ix86_function_specific_print, ix86_valid_target_attribute_tree, ix86_can_inline_p): Update names of cl_target_option members. * config/i386/i386.h (ix86_isa_flags): Remove. * config/lm32/lm32.h (target_flags): Remove. * config/mcore/mcore.h (mcore_stack_increment): Remove. * config/mcore/mcore.md (addsi3): Remove extern declaration of flag_omit_frame_pointer. * config/mep/mep.h (target_flags): Remove. * config/mips/mips.h (HARD_FRAME_POINTER_IS_FRAME_POINTER, HARD_FRAME_POINTER_IS_ARG_POINTER): Define. * config/mmix/mmix.h (target_flags): Remove. * config/rs6000/rs6000.h (rs6000_xilinx_fpu, flag_pic, flag_expensive_optimizations): Remove. * config/s390/s390.h (flag_pic): Remove. * config/score/score-conv.h (target_flags): Remove. * config/sh/sh.h (sh_fixed_range_str): Remove. * config/spu/spu.h (target_flags, spu_fixed_range_string): Remove. * dbxout.c: Use HARD_FRAME_POINTER_IS_ARG_POINTER * df-scan.c: Use HARD_FRAME_POINTER_IS_FRAME_POINTER. * diagnostic.c (diagnostic_initialize): Update names of diagnostic_context members. * diagnostic.h (diagnostic_context): Rename inhibit_warnings and warn_system_headers. (diagnostic_report_warnings_p): Update for new names. * dwarf2out.c: Use HARD_FRAME_POINTER_IS_ARG_POINTER * emit-rtl.c: Use HARD_FRAME_POINTER_IS_FRAME_POINTER and HARD_FRAME_POINTER_IS_ARG_POINTER. * flags.h (flag_compare_debug): Declare. * ira.c: Use HARD_FRAME_POINTER_IS_FRAME_POINTER * opts.c (flag_compare_debug): Define. (common_handle_option): Update names of diagnostic_context members. Handle -fcompare-debug-second. (fast_math_flags_struct_set_p): Update names of cl_optimization members. * reginfo.c: Use HARD_FRAME_POINTER_IS_FRAME_POINTER. * regrename.c: Use HARD_FRAME_POINTER_IS_FRAME_POINTER. * reload.c: Use HARD_FRAME_POINTER_IS_FRAME_POINTER. * reload1.c: Use HARD_FRAME_POINTER_IS_FRAME_POINTER. * resource.c: Use HARD_FRAME_POINTER_IS_FRAME_POINTER. * rtl.h (HARD_FRAME_POINTER_IS_FRAME_POINTER, HARD_FRAME_POINTER_IS_ARG_POINTER): Define and use. * sel-sched.c: Use HARD_FRAME_POINTER_IS_FRAME_POINTER * stmt.c: Use HARD_FRAME_POINTER_IS_ARG_POINTER. gcc/c-family: * c-common.c (c_cpp_error): Update names of diagnostic_context members. * c-cppbuiltin.c (c_cpp_builtins_optimize_pragma): Update names of cl_optimization members. * c-opts.c (warning_as_error_callback, c_common_handle_option, sanitize_cpp_opts, finish_options): Update names of cpp_options members. gcc/fortran: * cpp.c (cpp_define_builtins): Update names of gfc_option_t members. (gfc_cpp_post_options): Update names of cpp_options members. (cb_cpp_error): Update names of diagnostic_context members. * f95-lang.c (gfc_init_builtin_functions): Update names of gfc_option_t members. *
[Bug target/46898] libgcc build failure on lm32-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46898 --- Comment #12 from Sebastien Bourdeauducq lekernel at gcc dot gnu.org 2011-02-25 19:04:07 UTC --- ok... breaks it, but with a syntax error (seems to have been fixed in the meantime), not for the cc1 segfault we're looking for.
[Bug tree-optimization/47896] New: wrong code with -O -fno-early-inlining -fipa-pta -fno-tree-dominator-opts -fno-tree-forwprop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47896 Summary: wrong code with -O -fno-early-inlining -fipa-pta -fno-tree-dominator-opts -fno-tree-forwprop Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 23470 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23470 auto-reduced testcase Output: $ g++ -O -fno-early-inlining -fipa-pta -fno-tree-dominator-opts -fno-tree-forwprop testcase.C $ ./a.out Aborted Testcase was reduced from g++.dg/torture/pr37922.C, which fails with: $ g++ -O -fno-early-inlining -fipa-pta -fschedule-insns2 -fno-tree-dominator-opts -fno-tree-forwprop -funroll-loops pr37922.ii $ ./a.out Aborted Tested revisions: r170489 - fail
[Bug middle-end/47893] [4.6 Regression] 4.6 miscompiles mesa on i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47893 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-25 19:09:54 UTC --- Created attachment 23471 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23471 gcc46-pr47893.patch Updated patch, so far just lightly tested that it fixes this bug.
[Bug target/46898] libgcc build failure on lm32-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46898 --- Comment #13 from Sebastien Bourdeauducq lekernel at gcc dot gnu.org 2011-02-25 19:24:24 UTC --- Author: lekernel Date: Fri Feb 25 19:24:20 2011 New Revision: 170502 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170502 Log: 2011-02-25 Sebastien Bourdeauducq sebast...@milkymist.org PR gcc/46898 * config/lm32/lm32.md (ashrsi3): Added needed variable. 2011-02-25 Jon Beniston j...@beniston.com PR gcc/46898 * config/lm32/lm32.h (INCOMING_RETURN_ADDR_RTX): New. * config/lm32/lm32.md (ashlsi3): Remove unused variable. * config/lm32/lm32.c (TARGET_EXCEPT_UNWIND_INFO): New. (lm32_block_move_inline): Add type cast to remove warning. (lm32_expand_prologue): Generate fp in a way compatible with dwarf2out. (gen_int_relational): Move declarations to start of function. Modified: trunk/gcc/ChangeLog trunk/gcc/config/lm32/lm32.c trunk/gcc/config/lm32/lm32.h trunk/gcc/config/lm32/lm32.md
[Bug target/46898] libgcc build failure on lm32-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46898 --- Comment #14 from Sebastien Bourdeauducq lekernel at gcc dot gnu.org 2011-02-25 19:26:31 UTC --- This gets the C compiler to build; if C++ is enabled, this triggers the cc1 segfault above.
[Bug c++/47897] New: [C++0x] static const member variable is not constant expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47897
Summary: [C++0x] static const member variable is not constant
expression
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: fl...@flast.jp
GCC4.6.0(with C++0x mode) reject static const member variable depending
template parameter type.
testcase.C
template typename T, T N
struct S
{
static const T value = N;
typedef S T, value + 1 next;
};
It seems caused by r170488 (git: cfa61f8435164f3205d70c7e1c5038b2d881aa1d).
In other case, GCC accepts codes.
For example:
testcase.C (accepted)
template int N
struct S
{
static const int value = N;
typedef S value + 1 next;
};
---
Another case:
testcase.C (accepted)
template typename T, T N
struct S
{
static constexpr T value = N;
typedef S T, value + 1 next;
};
---
[Bug target/47403] [x32] TLS doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47403 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2011-02-25 21:23:10 UTC --- Dup. *** This bug has been marked as a duplicate of bug 47715 ***
[Bug target/47715] [x32] TLS doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47715 --- Comment #8 from H.J. Lu hjl.tools at gmail dot com 2011-02-25 21:23:10 UTC --- *** Bug 47403 has been marked as a duplicate of this bug. ***
[Bug target/47715] [x32] TLS doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47715 --- Comment #9 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-02-25 21:25:24 UTC --- Author: hjl Date: Fri Feb 25 21:25:20 2011 New Revision: 170504 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170504 Log: Use ptr_mode instead of Pmode with UNSPEC_TP. 2011-02-25 H.J. Lu hongjiu...@intel.com PR target/47715 * config/i386/i386.c (get_thread_pointer): Use ptr_mode instead of Pmode with UNSPEC_TP. * config/i386/i386.md (tp_seg): Removed. (*load_tp_mode): Replace :P with :PTR. (*add_tp_mode): Likewise. (*load_tp_x32): New. Modified: branches/x32/gcc/ChangeLog.x32 branches/x32/gcc/config/i386/i386.c branches/x32/gcc/config/i386/i386.md
[Bug target/47898] New: error: unable to find a register to spill in class 'FPUL_REGS'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47898
Summary: error: unable to find a register to spill in class
'FPUL_REGS'
Product: gcc
Version: 4.3.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mcnic...@austin.ibm.com
Created attachment 23472
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23472
Small testcase.
I get the following error when using gcc to cross compile
to an SH4 target.
# /opt/sh4/bin/sh4-linux-gcc -c -O1 sh4-gcc.c
sh4-gcc.c: In function 'xml_transport_parser':
sh4-gcc.c:104: error: unable to find a register to spill in class 'FPUL_REGS'
sh4-gcc.c:104: error: this is the insn:
(insn 199 198 200 18 sh4-gcc.c:76 (set (mem/s/j:QI (plus:SI (reg:SI 77 fr13
[320])
(reg:SI 76 fr12 [orig:240 D.2212 ] [240])) [0 name S1 A8])
(reg:QI 1 r1 [284])) 182 {movqi_i} (expr_list:REG_DEAD (reg:QI 1 r1
[284])
(expr_list:REG_DEAD (reg:SI 76 fr12 [orig:240 D.2212 ] [240])
(nil
sh4-gcc.c:104: confused by earlier errors, bailing out
The problem only seems to happen with -O1.
Here is the information about my compiler:
#sh4-linux-gcc -v
Using built-in specs.
Target: sh4-linux
Configured with: /usr/src/BUILD/gcc/configure --prefix=/opt/sh4
--target=sh4-linux --with-cpu=sh4a --with-multilib-list=sh4a,sh4a-nofpu
--enable-incomplete-targets --disable-nls --disable-libssp --disable-libgomp
--disable-libmudflap --enable-shared --enable-languages=c,c++ --enable-cross
--enable-__cxa_atexit --enable-threads=posix --with-sysroot=/opt/sh4/crossroot
Thread model: posix
gcc version 4.3.4 [gcc-4_3-branch revision 152973] (GCC)
Attached is a small test case.
[Bug target/47898] error: unable to find a register to spill in class 'FPUL_REGS'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47898 --- Comment #1 from Dan McNichol mcnichol at austin dot ibm.com 2011-02-25 21:49:02 UTC --- Created attachment 23473 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23473 Preprocessor output for testcase Attaching preprocessor output.
[Bug lto/47497] [4.6 Regression] SPEC CPU 2006 failed to link with LTO -fuse-linker-plugin -fwhole-program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47497 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|WAITING CC||steven at gcc dot gnu.org --- Comment #10 from Steven Bosscher steven at gcc dot gnu.org 2011-02-25 23:04:07 UTC --- No test case available. Please, someone, provide a test case so that those unlucky souls without access to SPEC2k6 can try to help debug this problem.
[Bug target/38598] MIPS extendsidi2 does not have a LO alternative
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38598 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||pinskia at gcc dot gnu.org --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2011-02-25 23:05:55 UTC --- (In reply to comment #1) I have a patch, but it isn't appropriate at this stage in the 4.4 cycle. It has been over 2 years since this comment was added, what happened to the patch? Could you at least attach it to the bug if you still have it around?
[Bug middle-end/47691] [4.6 Regression] ICE: in create_linear_expr_from_tree, at graphite-sese-to-poly.c:1138 with -fgraphite-identity -ffast-math -fno-tree-scev-cprop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47691 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #1 from Steven Bosscher steven at gcc dot gnu.org 2011-02-25 23:07:32 UTC --- I'll see if I can turn this test case into a C test case, to maybe raise this to P1.
[Bug middle-end/47691] [4.6 Regression] ICE: in create_linear_expr_from_tree, at graphite-sese-to-poly.c:1138 with -fgraphite-identity -ffast-math -fno-tree-scev-cprop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47691 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.02.25 23:07:52 Ever Confirmed|0 |1
[Bug target/19201] [m68k] Inefficient code for array accesses (from old PROBLEMS)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19201 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WONTFIX --- Comment #11 from Steven Bosscher steven at gcc dot gnu.org 2011-02-25 23:12:26 UTC --- No response from m68k maintainers for almost 2.5 years. This just clutters my bug searches. WONTFIX seems the most logical way out.
[Bug target/19204] [m68k] pea can force reloads that cause inefficient code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19204 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WONTFIX --- Comment #4 from Steven Bosscher steven at gcc dot gnu.org 2011-02-25 23:13:04 UTC --- No response from m68k maintainers for more than 5 years. That may be a record. This just clutters my bug searches. WONTFIX seems the most logical way out.
[Bug target/19205] [m68k] avoid converting INDEX to SI mode if a narrower mode suffices
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19205 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WONTFIX --- Comment #5 from Steven Bosscher steven at gcc dot gnu.org 2011-02-25 23:13:35 UTC --- No response from m68k maintainers for more than 5 years. This just clutters my bug searches. WONTFIX seems the most logical way out.
[Bug target/45026] Empty function compiles to many loads and stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45026 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.25 23:15:12 Ever Confirmed|0 |1
[Bug target/45808] FreeBSD: -pthread is handled incompletely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45808 --- Comment #7 from gerald at gcc dot gnu.org gerald at gcc dot gnu.org 2011-02-25 23:15:51 UTC --- Author: gerald Date: Fri Feb 25 23:15:48 2011 New Revision: 170505 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170505 Log: PR target/45808 * config/freebsd-spec.h (FBSD_LIB_SPEC): Handle the shared case. Update copyright years. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config/freebsd-spec.h
[Bug tree-optimization/42963] [4.5 Regression] Redundant switch labels not cleaned up anymore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42963 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Known to work|| Resolution||WONTFIX --- Comment #8 from Steven Bosscher steven at gcc dot gnu.org 2011-02-25 23:17:00 UTC --- Will not be fixed for GCC 4.5. No need to keep this open.
[Bug middle-end/45310] ICE: verify_stmts failed: Dead STMT in EH table with -O1 -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45310 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from Steven Bosscher steven at gcc dot gnu.org 2011-02-25 23:19:08 UTC --- If this pops up somewhere again, let's put that in a new PR with a test case. This particular issue is closed.
[Bug target/19201] [m68k] Inefficient code for array accesses (from old PROBLEMS)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19201 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|RESOLVED|NEW Resolution|WONTFIX | --- Comment #12 from Andreas Schwab sch...@linux-m68k.org 2011-02-25 23:58:09 UTC --- Not a reason to close them.
[Bug target/19204] [m68k] pea can force reloads that cause inefficient code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19204 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|RESOLVED|NEW Resolution|WONTFIX | --- Comment #5 from Andreas Schwab sch...@linux-m68k.org 2011-02-25 23:58:10 UTC --- Not a reason to close them.
[Bug target/19205] [m68k] avoid converting INDEX to SI mode if a narrower mode suffices
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19205 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|RESOLVED|NEW Resolution|WONTFIX | --- Comment #6 from Andreas Schwab sch...@linux-m68k.org 2011-02-25 23:58:10 UTC --- Not a reason to close them.
[Bug c++/47897] [4.6 Regression][C++0x] static const member variable is not constant expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47897 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.26 00:13:26 CC||jason at gcc dot gnu.org Target Milestone|--- |4.6.0 Summary|[C++0x] static const member |[4.6 Regression][C++0x] |variable is not constant|static const member |expression |variable is not constant ||expression Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-02-26 00:13:26 UTC --- Urgh, I can confirm this. Jason, can you have a look?
[Bug target/19204] [m68k] pea can force reloads that cause inefficient code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19204 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|NEW |SUSPENDED --- Comment #6 from Steven Bosscher steven at gcc dot gnu.org 2011-02-26 00:17:55 UTC --- Also fine, not closed. Great to see that you pay enough attention to stop the reporter from closing his own PRs. I wish you would be just as fast with actually doing something about them. It is not even clear whether these problems still exist! If this still not OK with you, I suggest you do something about these 15+ years old problems, or close these and re-file under your own account. They may not bother you but I don't want them anymore in my list.
[Bug target/19201] [m68k] Inefficient code for array accesses (from old PROBLEMS)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19201 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|NEW |SUSPENDED --- Comment #13 from Steven Bosscher steven at gcc dot gnu.org 2011-02-26 00:17:54 UTC --- Also fine, not closed. Great to see that you pay enough attention to stop the reporter from closing his own PRs. I wish you would be just as fast with actually doing something about them. It is not even clear whether these problems still exist! If this still not OK with you, I suggest you do something about these 15+ years old problems, or close these and re-file under your own account. They may not bother you but I don't want them anymore in my list.
[Bug target/19205] [m68k] avoid converting INDEX to SI mode if a narrower mode suffices
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19205 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|NEW |SUSPENDED --- Comment #7 from Steven Bosscher steven at gcc dot gnu.org 2011-02-26 00:17:56 UTC --- Also fine, not closed. Great to see that you pay enough attention to stop the reporter from closing his own PRs. I wish you would be just as fast with actually doing something about them. It is not even clear whether these problems still exist! If this still not OK with you, I suggest you do something about these 15+ years old problems, or close these and re-file under your own account. They may not bother you but I don't want them anymore in my list.
[Bug c/47899] New: ICE in get_loop_body, at cfgloop.c:831
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47899
Summary: ICE in get_loop_body, at cfgloop.c:831
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reg...@cs.utah.edu
CC: cheny...@cs.utah.edu
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
regehr@home:~/volatile/bugs/tmp351$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/mnt/z/z/compiler-install/gcc-r170512-install/libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/mnt/z/z/compiler-install/gcc-r170512-install
--program-prefix=r170512- --enable-languages=c,c++
Thread model: posix
gcc version 4.6.0 20110226 (experimental) (GCC)
regehr@home:~/volatile/bugs/tmp351$ current-gcc -O -funroll-loops small.c -o
small
small.c: In function ‘main’:
small.c:53:1: internal compiler error: in get_loop_body, at cfgloop.c:831
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
regehr@home:~/volatile/bugs/tmp351$ cat small.c
static unsigned
foo (unsigned ui1, unsigned ui2)
{
return ui1 - ui2;
}
static unsigned g_5[3][1][9] = {
};
static short g_17;
static short *g_80[4] = {
g_17, g_17, g_17, g_17
};
static short **g_79[5] = {
g_80[1], g_80[1], g_80[1], g_80[1], g_80[1]
};
static int g_132;
static short ***volatile g = g_79[1];
static unsigned g_566;
static void func_1 (void)
{
lbl_777:*g;
for (; g; g += 0)
for (; g; g += 1)
{
for (;;)
{
}
}
lbl_802:if (g_566)
goto lbl_777;
for (g_132 = 0; g_132 = 0; g_132 = foo (g_132, 1))
{
if (g_5[+3][+1][+9] || **g)
{
for (; g; g += 1)
{
}
}
else
goto lbl_802;
}
}
int main (int argc, char *argv[])
{
func_1 ();
}
[Bug lto/47900] New: Missed optimization with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47900 Summary: Missed optimization with LTO Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: d.g.gorbac...@gmail.com Created attachment 23474 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23474 Testcase
