[Bug preprocessor/60492] Using the L#param in a macro fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60492 --- Comment #6 from J.R. Heisey jr at heisey dot org --- Really? What rule would make this behavior expected?
[Bug c++/60517] warning/error for taking address of member of a temporary object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
--- Comment #3 from Marc Glisse glisse at gcc dot gnu.org ---
(In reply to Manuel López-Ibáñez from comment #2)
(In reply to Marc Glisse from comment #1)
I see in the dump:
# .MEM_4 = VDEF .MEM_8
D.2272 ={v} {CLOBBER};
# VUSE .MEM_4
_5 = MEM[(doubleD.39 *)D.2272];
which looks like something we could warn about in the middle-end.
Could you elaborate? My middle-end foo is not as good as it used to be.
_5 = MEM[(doubleD.39 *)D.2272];
says we are reading something inside variable D.2272. And right in the previous
instruction:
D.2272 ={v} {CLOBBER};
we clobbered the content of that variable, so what we are reading is nonsense.
These clobbers are specifically added to indicate when variables die (like your
temporary).
And we don't need to rely on the clobber being exactly the previous
instruction. The state of the memory (VUSE) when we execute the last
instruction was defined (VDEF) by the clobber instruction, typically
walk_aliased_vdefs would help you find the last instructions that touched
something related to the variable (get_ref_base_and_extent to get the variable
maybe?), the visitor would always stop, recording if the instruction was a
clobber, and you would check if all branches (or one branch for a -Wmaybe- type
of warning?) stopped on a clobber. Some passes may record enough information to
make the walk unnecessary, but I am not sure. And you may want to record
objects you have already warned about, to avoid flooding if a dead variable is
used a lot.
Now that I am describing it, there may already be code that does the same thing
for use-after-free or other cases?
Anyway, a hard part would be deciding in which pass to warn. And turning this
vague description (assuming it makes at least a bit of sense) into something
that actually works. And finding a right compromise between false positives and
false negatives. The usual...
[Bug preprocessor/60492] Using the L#param in a macro fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60492 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- E.g. in ISO C99, 6.10.3.2, you can read that #s is replaced by a single preprocessing token, but the mere fect that L immediately precedes it doesn't make it a part of the same preprocessing token. For wide character literals, the L needs to be part of the same preprocessing token as the string after it.
[Bug libstdc++/60521] New: std::lock_guard ignores adopt_lock strategy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60521
Bug ID: 60521
Summary: std::lock_guard ignores adopt_lock strategy
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: turchanov at farpost dot com
lock_guard created with constructor lock_guard::lock_guard(mutex_type m,
adopt_lock_t tag) must adopt already locked mutex. But current implementation
ignores completely this fact and tries to lock passed mutex unconditionally:
templatetypename _Mutex
class lock_guard {
...
lock_guard(mutex_type __m, adopt_lock_t) : _M_device(__m)
{ } // calling thread owns mutex
...
};
and given the fact that mutex type is not a recursive mutex this code sequence
produces a dead-lock:
mutex mtx;
mtx.lock();
lock_guardmutex guard(mtx, adopt_lock); // -- deadlocks!
[Bug target/60520] stack adjustment are not merged anymore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60520
--- Comment #5 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to H.J. Lu from comment #4)
This change:
diff --git a/gcc/function.c b/gcc/function.c
index a61e475..3b6718f 100644
--- a/gcc/function.c
+++ b/gcc/function.c
@@ -6238,6 +6238,7 @@ thread_prologue_and_epilogue_insns (void)
}
/* Now duplicate the tails. */
if (!bitmap_empty_p (bb_tail))
+ {
FOR_EACH_BB_REVERSE_FN (bb, cfun)
{
basic_block copy_bb, tbb;
@@ -6304,6 +6305,17 @@ thread_prologue_and_epilogue_insns (void)
if (bitmap_empty_p (bb_tail))
break;
}
+
+ /* Basic blocks may have been changed. Merge each basic block
+with its successor if possible. */
+ FOR_EACH_BB_FN (bb, cfun)
+ if (single_succ_p (bb))
+ {
+ basic_block succ_bb = single_succ (bb);
+ if (can_merge_blocks_p (bb, succ_bb))
+ merge_blocks (bb, succ_bb);
+ }
+ }
}
fail_shrinkwrap:
seems to work.
We have cfg_cleanup for this, no?
[Bug ipa/60518] [4.9 Regression] ICE: in verify_loop_structure, at cfgloop.c:1647
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60518 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-03-14 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |4.9.0 Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed, mine.
[Bug fortran/60522] New: WHERE construct causes an ICE in gfc_trans_where_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60522 Bug ID: 60522 Summary: WHERE construct causes an ICE in gfc_trans_where_2 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: roger.ferrer at bsc dot es Hi, the following code ! -- test.f90 subroutine foo(a, b) implicit none integer, dimension(:), intent(inout) :: a integer, dimension(:), intent(in) :: b where (b(:) 0) a(lbound(a, 1):ubound(a, 1)) = b(lbound(b, 1):ubound(b, 1)) * b(lbound(b, 1):ubound(b, 1)) end where end subroutine foo ! -- end of test.f90 causes an ICE if optimization is enabled: $ gfortran -c test.f90 -O test.f90: In function ‘foo’: test.f90:6:0: internal compiler error: in gfc_trans_where_2, at fortran/trans-stmt.c:4550 where (B(:) 0) ^ Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.8/README.Bugs for instructions. The problem goes away if the assignment is of the (equivalent) form: a(:) = b(:) * b(:) or a = b * b or if optimization is disabled. Kind regards,
[Bug libstdc++/60521] std::lock_guard ignores adopt_lock strategy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60521
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed||2014-03-14
Ever confirmed|0 |1
Severity|blocker |normal
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Sergei Turchanov from comment #0)
lock_guard(mutex_type __m, adopt_lock_t) : _M_device(__m)
{ } // calling thread owns mutex
Where in that code do you think it locks the mutex?
[Bug target/60520] stack adjustment are not merged anymore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60520 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Furthermore, it is already fixed since r208551.
[Bug lto/59468] [4.9 Regression] ICE on invalid C++ code with LTO in gimple_get_virt_method_for_binfo, at gimple-fold.c:3224
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59468 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org --- Seems to be fixed now. Please reopen if there is some reason you wanted to keep this open.
[Bug target/60520] stack adjustment are not merged anymore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60520 --- Comment #7 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Jakub Jelinek from comment #6) Furthermore, it is already fixed since r208551. Indeed, the fix for PR57320 also fixed this one.
[Bug c/60523] New: Warning flag for octal literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60523 Bug ID: 60523 Summary: Warning flag for octal literals Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: david at westcontrol dot com It would be nice if there were a warning flag that triggered on octal literals. Octal literals are rarely used in modern C and C++ code, but can easily be introduced by mistake - int x = 050; appears at first reading to set x to 50, but in C and C++ the leading 0 means it is interpreted as octal and therefore sets x to 40 (decimal). As octal literals are seldom useful, and often confusing or accidental, they are banned by coding standards like MISRA. But as they are part of the language defined by the C and C++ standards, and are used in some existing code, they obviously cannot be removed. As a compromise, I would like to propose the introduction of a warning flags -Woctal which would produce a diagnostic message when a literal is interpreted as an octal number. Of preference, this would be included in -Wextra (it probably should not be in -Wall, since octal literals are valid C and C++).
[Bug c/60523] Warning flag for octal literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60523 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Octal literals are very useful for expressing unix/posix file modes like 0777 or even 0666. So having the warning part of eith -Wall or -Wextra does not make sense.
[Bug fortran/60522] WHERE construct causes an ICE in gfc_trans_where_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60522 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-14 CC||tkoenig at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed. The ICE goes away when compiling with -fno-frontend-optimize. The test compiles with r171100 (2011-03-17) and gives the ICE with r171653 (2011-03-29). The changes of frontend-passes.c in this range are r171653, r171575, and r171207.
[Bug ipa/60518] [4.9 Regression] ICE: in verify_loop_structure, at cfgloop.c:1647
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60518
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org ---
Ok, so it's branch_prob()s call of split_block that splits the common latch of
loops 1 and 2
bb 3: (header loop 1)
bb 4: (header loop 2, latch loop 2 and 1)
_2 = fn1 ();
if (_2 != 0)
goto bb 4;
else
goto bb 3;
the cfghook adjusts the latch of loop 2 properly (bb4s loop father is 2)
but fails to notice that bb4 is also the latch of loop 1 ... so this
CFG hook loop handling only handles this correctly if we have simple
latches (because there the latch always belongs to its loop).
Fix:
Index: gcc/cfghooks.c
===
--- gcc/cfghooks.c (revision 208536)
+++ gcc/cfghooks.c (working copy)
@@ -510,9 +510,13 @@ split_block (basic_block bb, void *i)
if (current_loops != NULL)
{
+ edge_iterator ei;
+ edge e;
add_bb_to_loop (new_bb, bb-loop_father);
- if (bb-loop_father-latch == bb)
- bb-loop_father-latch = new_bb;
+ /* Identify all loops bb may have been the latch of and adjust them. */
+ FOR_EACH_EDGE (e, ei, new_bb-succs)
+ if (e-dest-loop_father-latch == bb)
+ e-dest-loop_father-latch = new_bb;
}
res = make_single_succ_edge (bb, new_bb, EDGE_FALLTHRU);
[Bug target/59396] [avr] Wrong warning with ISR() and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59396 --- Comment #9 from Georg-Johann Lay gjl at gcc dot gnu.org --- Author: gjl Date: Fri Mar 14 09:27:19 2014 New Revision: 208562 URL: http://gcc.gnu.org/viewcvs?rev=208562root=gccview=rev Log: PR target/59396 * config/avr/avr.c (avr_set_current_function): Pass function name through default_strip_name_encoding before sanity checking instead of skipping the first char of the assembler name. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.c
[Bug target/59396] [avr] Wrong warning with ISR() and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59396 --- Comment #10 from Georg-Johann Lay gjl at gcc dot gnu.org --- Author: gjl Date: Fri Mar 14 09:41:51 2014 New Revision: 208564 URL: http://gcc.gnu.org/viewcvs?rev=208564root=gccview=rev Log: Backport from 2014-03-14 trunk r208562. PR target/59396 * config/avr/avr.c (avr_set_current_function): Pass function name through default_strip_name_encoding before sanity checking instead of skipping the first char of the assembler name. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/avr/avr.c
[Bug ada/60504] [4.9 regression] many Ada testsuite regressions with gcc-4.9-20140309 on armv5tel-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60504 --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Nothing obvious stands out. I presume that exceptions cannot be caught? OK, it's presumably http://gcc.gnu.org/ml/gcc/2013-12/msg00157.html but no ARM maintainer has stepped in yet. :-( Try this: Index: config/arm/arm.h === --- config/arm/arm.h(revision 208561) +++ config/arm/arm.h(working copy) @@ -937,13 +937,13 @@ extern int arm_arch_crc; #ifndef ARM_TARGET2_DWARF_FORMAT #define ARM_TARGET2_DWARF_FORMAT DW_EH_PE_pcrel +#endif /* ttype entries (the only interesting data references used) use TARGET2 relocations. */ #define ASM_PREFERRED_EH_DATA_FORMAT(code, data) \ (((code) == 0 (data) == 1 ARM_UNWIND_INFO) ? ARM_TARGET2_DWARF_FORMAT \ : DW_EH_PE_absptr) -#endif /* The native (Norcroft) Pascal compiler for the ARM passes the static chain as an invisible last argument (possible since varargs don't exist in
[Bug target/59396] [avr] Wrong warning with ISR() and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59396 --- Comment #11 from Georg-Johann Lay gjl at gcc dot gnu.org --- Author: gjl Date: Fri Mar 14 09:52:07 2014 New Revision: 208565 URL: http://gcc.gnu.org/viewcvs?rev=208565root=gccview=rev Log: Backport from 2014-03-14 trunk r208562. PR target/59396 * config/avr/avr.c (avr_set_current_function): Pass function name through default_strip_name_encoding before sanity checking instead of skipping the first char of the assembler name. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/avr/avr.c
[Bug debug/60524] New: Typedef information bypassed in dwarf2 function parameter information when it is 'const'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60524
Bug ID: 60524
Summary: Typedef information bypassed in dwarf2 function
parameter information when it is 'const'
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: wpk at culm dot net
For following code:
typedef unsigned char Bar[12];
void foo(Bar *bar) {}
void fooconst(const Bar *bar) {}
compiled with gcc -gdwarf-2 -c, readelf -wi shows the foolowing dwarf-2 info:
For typedef Bar:
12d: Abbrev Number: 2 (DW_TAG_typedef)
2e DW_AT_name: Bar
32 DW_AT_decl_file : 1
33 DW_AT_decl_line : 1
34 DW_AT_type: 0x38
138: Abbrev Number: 3 (DW_TAG_array_type)
39 DW_AT_type: 0x4f
3d DW_AT_sibling : 0x48
For 'foo' function:
156: Abbrev Number: 6 (DW_TAG_subprogram)
(...)
58 DW_AT_name: foo
(...)
278: Abbrev Number: 7 (DW_TAG_formal_parameter)
79 DW_AT_name: bar
(...)
7f DW_AT_type: 0x87
(...)
187: Abbrev Number: 8 (DW_TAG_pointer_type)
88 DW_AT_byte_size : 8
89 DW_AT_type: 0x2d
This points to DW_TAG_typedef for 'Bar'
But for 'fooconst':
18d: Abbrev Number: 9 (DW_TAG_subprogram)
(...)
8f DW_AT_name: (indirect string, offset: 0x5c): fooconst
(...)
2af: Abbrev Number: 7 (DW_TAG_formal_parameter)
b0 DW_AT_name: bar
(..)
b6 DW_AT_type: 0xbe
(..)
1be: Abbrev Number: 8 (DW_TAG_pointer_type)
bf DW_AT_byte_size : 8
c0 DW_AT_type: 0x38
This points directly to unsigned char[12], completely bypassing typedef Bar
info.
GCC version info:
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.8.1-10ubuntu9' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu9)
[Bug target/59396] [avr] Wrong warning with ISR() and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59396 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Priority|P4 |P5 Status|NEW |RESOLVED Known to work||4.8.1, 4.8.3 Version|4.8.3 |4.8.2 Resolution|--- |FIXED Target Milestone|--- |4.8.3 Known to fail||4.8.2 --- Comment #12 from Georg-Johann Lay gjl at gcc dot gnu.org --- Fixed in 4.8.3.
[Bug c++/60517] warning/error for taking address of member of a temporary object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
--- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Marc Glisse from comment #3)
(In reply to Manuel López-Ibáñez from comment #2)
(In reply to Marc Glisse from comment #1)
I see in the dump:
# .MEM_4 = VDEF .MEM_8
D.2272 ={v} {CLOBBER};
# VUSE .MEM_4
_5 = MEM[(doubleD.39 *)D.2272];
which looks like something we could warn about in the middle-end.
Could you elaborate? My middle-end foo is not as good as it used to be.
_5 = MEM[(doubleD.39 *)D.2272];
says we are reading something inside variable D.2272. And right in the
previous instruction:
D.2272 ={v} {CLOBBER};
we clobbered the content of that variable, so what we are reading is
nonsense. These clobbers are specifically added to indicate when variables
die (like your temporary).
Where is the clobber added? The closer to the FE that we warn, the better
diagnostic we can generate. I'm not very concerned about maybe-branches, since
I expect most bugs to appear in temporaries created in the middle of
expressions (such as a.getB().getA().x), where no branching occurs.
[Bug c/60523] Warning flag for octal literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60523 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- I agree with Andrew - if we are ever to implement -Woctal, making it a part of -Wextra doesn't sound sensible. Especially with -Werror it'd be a pain.
[Bug lto/60461] [4.9 Regression] LTO linking error at -Os (and above) on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60461 --- Comment #6 from Martin Jambor jamborm at gcc dot gnu.org --- Author: jamborm Date: Fri Mar 14 10:49:05 2014 New Revision: 208566 URL: http://gcc.gnu.org/viewcvs?rev=208566root=gccview=rev Log: 2014-03-13 Martin Jambor mjam...@suse.cz PR lto/60461 * ipa-prop.c (ipa_modify_call_arguments): Fix iteration condition and simplify it. testsuite/ * gcc.dg/lto/pr60461_0.c: New test. Added: trunk/gcc/testsuite/gcc.dg/lto/pr60461_0.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-prop.c trunk/gcc/testsuite/ChangeLog
[Bug c/60523] Warning flag for octal literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60523 --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org --- I would suggest that you implement this as a plugin. Plugins are particularly useful for enforcing this type of coding standards. If you make a generally useful plugin like one enforcing MISRA standards, it could be distributed with GCC in order to serve as a testcase for the plugins framework.
[Bug target/60525] New: [4.9 Regression] ICE: in final_scan_insn, at final.c:2952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60525
Bug ID: 60525
Summary: [4.9 Regression] ICE: in final_scan_insn, at
final.c:2952
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
markus@x4 libgcc % cat test.i
typedef struct
{
long w[2];
} UINT128;
extern UINT128 a[];
int b, c, f, g, h, i, l, m, o, p, q;
double d;
UINT128 j, k, t;
long n, r;
unsigned long s;
fn1 (UINT128 *p1, UINT128 p2, UINT128 p3)
{
int e;
if (p2.w[1])
p1-w[0] = p3.w[0];
e = d + p2.w[0];
if (p3.w[1])
c = e;
p1-w[1] = b;
}
fn2 ()
{
UINT128 u;
fn1 (t, j, k);
u = a[l];
int v, w;
o = t.w[0] 1;
w = u.w[1] 32;
n = t.w[0] * u.w[0];
q = r;
r = r + s + (n 32);
v = q + r 1;
r = o * u.w[0];
q = o * w;
r = r + s + (n 32);
m = q + r;
p = u.w[1] 32;
r = u.w[1];
s = 0;
r = r + t.w[1] + n;
i = v;
o = t.w[0];
h = k.w[1] * k.w[0];
g = j.w[1];
f = j.w[0];
}
markus@x4 libgcc % gcc -march=amdfam10 -O2 -c test.i
test.i: In function ‘fn2’:
test.i:47:1: error: could not split insn
}
^
(insn:TI 31 30 32 5 (parallel [
(set (reg:DF 22 xmm1 [orig:142 D.1904 ] [142])
(float:DF (mem/c:DI (plus:DI (reg/f:DI 7 sp)
(const_int -16 [0xfff0])) [7 %sfp+-16
S8 A64])))
(clobber (mem/c:DI (plus:DI (reg/f:DI 7 sp)
(const_int -8 [0xfff8])) [0 S8 A64]))
]) test.i:16 219 {*floatdidf2_sse_with_temp}
(nil))
test.i:47:1: internal compiler error: in final_scan_insn, at final.c:2952
0x82e4c8 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/gcc/rtl-error.c:109
0x6a9d5a final_scan_insn(rtx_def*, _IO_FILE*, int, int, int*)
../../gcc/gcc/final.c:2952
0x6a9fb6 final(rtx_def*, _IO_FILE*, int)
../../gcc/gcc/final.c:2023
0x6aa1e5 rest_of_handle_final
../../gcc/gcc/final.c:4427
0x6aa1e5 execute
../../gcc/gcc/final.c:4502
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
{standard input}: Assembler messages:
{standard input}: Error: open CFI at the end of file; missing .cfi_endproc
directive
[Bug target/60525] [4.9 Regression] ICE: in final_scan_insn, at final.c:2952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60525 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||rth at gcc dot gnu.org --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Started with r208556.
[Bug c/60523] Warning flag for octal literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60523 --- Comment #5 from David Brown david at westcontrol dot com --- I agree that warnings to match something like the MISRA coding standards would be best done as a plugin. But I believe that in this case, warning on octal literals would be quite a small addition to the main gcc code. I am not familiar enough with the gcc source code to implement it myself (like many people, I blame lack of time) - I therefore registered this enhancement request in the hope that someone was /is/ familiar with this part of gcc would be able to make the change quickly and easily.
[Bug c++/60517] warning/error for taking address of member of a temporary object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
--- Comment #5 from Marc Glisse glisse at gcc dot gnu.org ---
(In reply to Manuel López-Ibáñez from comment #4)
Where is the clobber added?
front-end, I expect (sorry, I'm trying to get something to work on windows and
don't have my usual sources at hand).
The closer to the FE that we warn, the better
diagnostic we can generate.
Then do it in the front-end and ignore my message ;-)
I'm not very concerned about maybe-branches, since
I expect most bugs to appear in temporaries created in the middle of
expressions (such as a.getB().getA().x), where no branching occurs.
An exemple I have in mind is (pseudo):
ref id(ref x){return x;}
ref fun(){return id(temporary);}
where the function call hides that we are returning a reference to a temporary
(id could return a reference to a global object, for all fun knows) and we know
more after inlining (I need id inlined into fun, and either fun inlined into
something that uses its returned ref (so my previous technique works) or I
would need a different (middle-end) warning that detects return local_var,
which seems even easier except that it would give a lot of duplicates with
front-end warnings).
[Bug c/60484] [4.7/4.8/4.9 Regression] -fdump-rtl-expand and attribute optimize gives incorrect dump file path
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60484 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-14 CC||mpolacek at gcc dot gnu.org Summary|-fdump-rtl-expand and |[4.7/4.8/4.9 Regression] |attribute optimize gives|-fdump-rtl-expand and |incorrect dump file path|attribute optimize gives ||incorrect dump file path Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed. GCC 4.4 works.
[Bug target/60525] [4.9 Regression] ICE: in final_scan_insn, at final.c:2952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60525 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |4.9.0
[Bug lto/60461] [4.9 Regression] LTO linking error at -Os (and above) on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60461 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug ipa/60518] [4.9 Regression] ICE: in verify_loop_structure, at cfgloop.c:1647
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60518 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Fri Mar 14 12:54:25 2014 New Revision: 208567 URL: http://gcc.gnu.org/viewcvs?rev=208567root=gccview=rev Log: 2014-03-14 Richard Biener rguent...@suse.de PR middle-end/60518 * cfghooks.c (split_block): Properly adjust all loops the block was a latch of. * g++.dg/pr60518.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/pr60518.C Modified: trunk/gcc/ChangeLog trunk/gcc/cfghooks.c trunk/gcc/testsuite/ChangeLog
[Bug ipa/60518] [4.9 Regression] ICE: in verify_loop_structure, at cfgloop.c:1647
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60518 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-checking, ||ice-on-valid-code Priority|P3 |P1 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug middle-end/60484] [4.7/4.8/4.9 Regression] -fdump-rtl-expand and attribute optimize gives incorrect dump file path
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60484 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Component|c |middle-end Target Milestone|--- |4.7.4
[Bug middle-end/60484] [4.7/4.8/4.9 Regression] -fdump-rtl-expand and attribute optimize gives incorrect dump file path
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60484 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- (In reply to Marek Polacek from comment #1) Confirmed. GCC 4.4 works. Well, seems 4.4 puts the dump file in $PWD.
[Bug middle-end/60484] [4.7/4.8/4.9 Regression] -fdump-rtl-expand and attribute optimize gives incorrect dump file path
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60484 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Anyway, this is because finish_options is called for every optimize attribute (handle_optimize_attribute-parse_optimize_attribute-decode_options-finish_options) + one more time for command line options and every time it adds the directory prefix. I guess we should add the directory prefix just once.
[Bug ipa/58721] [4.9 Regression] The subroutine perdida is no longer inlined in fatigue.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58721 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #19 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 32347 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32347action=edit gcc49-pr58721.patch Untested patch.
[Bug fortran/60526] New: [4.7/4.8/4.9 Regression] Accepts-invalid: Variable name same as type name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60526 Bug ID: 60526 Summary: [4.7/4.8/4.9 Regression] Accepts-invalid: Variable name same as type name Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: janus at gcc dot gnu.org The following program is supposed to be invalid: type X end type type(X) :: X end 4.6 rejects it with: type(X) :: X 1 Error: Symbol 'x' at (1) cannot have a type 4.7, 4.8 and trunk however accept it happily. I think that is yet another regression caused by the constructor implementation in 4.7.
[Bug target/60525] [4.9 Regression] ICE: in final_scan_insn, at final.c:2952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60525 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-03-14 Assignee|unassigned at gcc dot gnu.org |rth at gcc dot gnu.org Ever confirmed|0 |1
[Bug fortran/60526] [4.7/4.8/4.9 Regression] Accepts-invalid: Variable name same as type name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60526 --- Comment #1 from janus at gcc dot gnu.org --- See also https://groups.google.com/forum/?fromgroups#!topic/comp.lang.fortran/ZZ0iPFE7TFk for a discussion of ifort's behavior (which is the other way round than gfortran's: it used to accept it but now rejects it).
[Bug c++/53711] Wunused-function should warn for functions in the unnamed namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53711 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Fri Mar 14 15:20:28 2014 New Revision: 208569 URL: http://gcc.gnu.org/viewcvs?rev=208569root=gccview=rev Log: PR c++/53711 * d++.dg/warn/anonymous-namespace-6.C: New test. Added: trunk/gcc/testsuite/g++.dg/warn/anonymous-namespace-6.C
[Bug c++/60517] warning/error for taking address of member of a temporary object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517 --- Comment #6 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Marc Glisse from comment #5) I would need a different (middle-end) warning that detects return local_var, To confirm this, I looked at the last dangling reference I debugged, recompiled it with -O3 -fkeep-inline-functions, and a grep for return in the .optimized dump showed: return one; return one; return D.495451.c_; (where one is a global variable, but D.495451 is a local variable) so even this trivial version of the warning would be useful.
[Bug middle-end/60484] [4.7/4.8/4.9 Regression] -fdump-rtl-expand and attribute optimize gives incorrect dump file path
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60484 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 32348 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32348action=edit gcc49-pr60484.patch Untested fix. Alternatively, e.g. finish_options could guard it also with loc == UNKNOWN_LOCATION (for calls other than the first one loc should be some real locus).
[Bug c/60527] New: Incorrectly removed if statement while doing int arithmetics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60527
Bug ID: 60527
Summary: Incorrectly removed if statement while doing int
arithmetics
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: nicklas.ekstrand at sonymobile dot com
Created attachment 32349
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32349action=edit
Test program modtest.c
In the following code:
static int getZ() {
int tmp;
Z = Z * A + B;
tmp = Z;
if (tmp == INT_MIN)
tmp++;
if (tmp 0)
tmp = -tmp;
return tmp % MEMSIZE;
}
The if-statement tmp==INT_MIN is optimized away when using -O2 or higher, e.g.,
$ gcc -Wall -Wextra -g -O2 modtest.c -o pc_modtest -lrt
$ ./pc_modtest
arr=0x7fc1608be010
i=0 A=945 B=411
z1=231029 z2=-7483648
Segmentation fault
When using -O0 the problem doesn't happen and the program will not cause a
segmentation fault.
[Bug middle-end/60484] [4.7/4.8/4.9 Regression] -fdump-rtl-expand and attribute optimize gives incorrect dump file path
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60484 --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- I've just regtested a similar patch, so it looks good.
[Bug c/60527] Incorrectly removed if statement while doing int arithmetics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60527 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- You have an integer overflow in your code which is why the comparisons are being removed. if (tmp == INT_MIN) Can never happen because B is always a positive constant (411), so tmp has a range of [INT_MIN+411. INT_MAX]. The only way to get INT_MIN is if you had an overflow and overflows in C are undefined.
[Bug middle-end/60484] [4.7/4.8/4.9 Regression] -fdump-rtl-expand and attribute optimize gives incorrect dump file path
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60484 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug target/60520] stack adjustment are not merged anymore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60520 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED CC||rth at gcc dot gnu.org Resolution|FIXED |--- --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org --- Supposedly csa pass could remove sp additions followed by setting of sp to something not based on sp?
[Bug rtl-optimization/60508] [4.8/4.9 Regression] internal compiler error: in lra_set_insn_recog_data, at lra.c:1082
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60508 --- Comment #3 from Vladimir Makarov vmakarov at gcc dot gnu.org --- Author: vmakarov Date: Fri Mar 14 16:34:57 2014 New Revision: 208570 URL: http://gcc.gnu.org/viewcvs?rev=208570root=gccview=rev Log: 2014-03-14 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/60508 * lra-constraints.c (get_reload_reg): Add new parameter in_subreg_p. (process_addr_reg, simplify_operand_subreg, curr_insn_transform): Pass the new parameter values. 2014-03-14 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/60508 * gcc.target/i386/pr60508.c: New. Added: trunk/gcc/testsuite/gcc.target/i386/pr60508.c Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c trunk/gcc/testsuite/ChangeLog
[Bug c++/60517] warning/error for taking address of member of a temporary object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517 --- Comment #7 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Marc Glisse from comment #6) (In reply to Marc Glisse from comment #5) I would need a different (middle-end) warning that detects return local_var, To confirm this, I looked at the last dangling reference I debugged, recompiled it with -O3 -fkeep-inline-functions, and a grep for return in the .optimized dump showed: return one; return one; return D.495451.c_; (where one is a global variable, but D.495451 is a local variable) so even this trivial version of the warning would be useful. To avoid duplicates, the front-end could just return something else, like NULL, when it detects this case (I guess the behavior is undefined and we can do whatever we want, no?).
[Bug target/60528] New: MIPS GCC puts out complex constant incorrectly when in big-endian mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60528
Bug ID: 60528
Summary: MIPS GCC puts out complex constant incorrectly when in
big-endian mode
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sje at gcc dot gnu.org
CC: rsandifo at gcc dot gnu.org
Target: mips-*-*
The included test program prints out:
x = 0.634964 1.298458
x = inf inf
on MIPS instead of:
x = 0.634964 1.298458
x = 0.182506 1.163916
To reproduce the problem you need to compile the program with no optimization
(-O0) and in big-endian mode. Little endian mode seems fine. When I compare
the assembly language output to an earlier 4.8.1 GCC, the latest GCC output
contains the following code to store the complex constant passed in to csinh:
$LC0:
.word1071927711
.word3624173458
.word1073006203
.word1962331215
Earlier GCC compilers that worked contained:
$LC0:
.word1071927711
.word-670793838
.word1073006203
.word1962331215
Test case:
#include stdio.h
#include complex.h
#include math.h
int main()
{
double complex x;
x = 0.63496391478473613 + 1.2984575814159773I;
printf(x = %f %f\n, creal(x), cimag(x));
x = csinh(x);
printf(x = %f %f\n, creal(x), cimag(x));
return 0;
}
[Bug target/60525] [4.9 Regression] ICE: in final_scan_insn, at final.c:2952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60525 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- It also breaks nearly every test in SPEC 2k and 2k6 ;)
[Bug ipa/58721] [4.9 Regression] The subroutine perdida is no longer inlined in fatigue.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58721
--- Comment #20 from Jakub Jelinek jakub at gcc dot gnu.org ---
Unfortunately the patch regresses abi_check in libstdc++, libstdc++.so.6 now
because of the patch exports
_ZNSt12system_errorC1ESt10error_codeRKSs@@GLIBCXX_3.4.11
_ZNSt12system_errorC2ESt10error_codeRKSs@@GLIBCXX_3.4.11
symbols.
This is caused by wastly different inlining decisions (and the decisions don't
look like an improvement to me) on thread.cc.
Debugging this, I'm seeing this is caused by Honza's predict.c changes.
E.g. quite often we have tree_predict_by_opcode called on
__gthrw___pthread_key_create != 0. When we call expr_expected_value_1 on
this,
it returns a NE_EXPR (__gthrw___pthread_key_create is weakref), but with
TREE_CONSTANT set on it. That is reasonable, the comparison will be either
always true, or always false, but without explicit __builtin_expect from the
user I actually don't see a reason why we should predict it as always true.
So, I wonder if we shouldn't do on top of the #c19 patch:
--- gcc/predict.c.jj2014-03-14 13:16:15.0 +0100
+++ gcc/predict.c2014-03-14 17:49:11.686411889 +0100
@@ -2066,7 +2066,7 @@ tree_predict_by_opcode (basic_block bb)
visited = BITMAP_ALLOC (NULL);
val = expr_expected_value_1 (boolean_type_node, op0, cmp, op1, visited,
predictor);
BITMAP_FREE (visited);
- if (val TREE_CONSTANT (val))
+ if (val TREE_CODE (val) == INTEGER_CST)
{
if (predictor == PRED_BUILTIN_EXPECT)
{
That change seems to slightly improve the inlining decisions on thread.ii, e.g.
_ZN9__gnu_cxxL27__exchange_and_add_dispatchEPii.part.1.constprop.11 seems to be
inlined again, but _ZNSt12system_errorC1ESt10error_codeRKSs and
_ZNSt12system_errorC2ESt10error_codeRKSs are still no longer inlined.
Comparing to gcc with all the patches but all the predict.c #c19 and the above
bits reverted, I see that (looking at -m32 -O2 ...) the
_ZNSt12system_errorC1ESt10error_codeRKSs function (the other symbol is an alias
to it) is 601 bytes long and
_ZNSt6thread15_M_start_threadESt10shared_ptrINS_10_Impl_baseEE caller
406 bytes long with the predict.c changes and
_ZNSt6thread15_M_start_threadESt10shared_ptrINS_10_Impl_baseEE is 889 bytes
long with the predict.c changes reverted (the
_ZNSt12system_errorC1ESt10error_codeRKSs function is inlined then).
So, size wise it is a win to inline it, but not significant, and the function
is in any case larger than the caller.
Honza, your thoughts on this?
[Bug c++/60517] warning/error for taking address of member of a temporary object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517 --- Comment #8 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #7) To avoid duplicates, the front-end could just return something else, like NULL, when it detects this case (I guess the behavior is undefined and we can do whatever we want, no?). I guess... Then we might as well introduce a call to __builtin_unreachable right before the return, at the same time as we replace the return value.
[Bug c/60523] Warning flag for octal literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60523 --- Comment #6 from joseph at codesourcery dot com joseph at codesourcery dot com --- Octal literals are also used in macro definitions from system headers, so care would be needed that a warning doesn't apply to those. Such a warning should of course not apply to 0 (and maybe more generally should not apply to any octal constant consisting of some number of leading 0s followed by at most one nonzero digit, as those have the same value whether interpreted as octal or as decimal).
[Bug target/60525] [4.9 Regression] ICE: in final_scan_insn, at final.c:2952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60525 --- Comment #3 from Richard Henderson rth at gcc dot gnu.org --- Created attachment 32350 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32350action=edit proposed patch In the description for the patch in question, I mentioned how during stage1 we could clean up all these patterns to rely on LRA. The fact that this pr was filed immediately suggests that the current setup is quite difficult to follow. Cleaning this up now instead of waiting for stage1 would seem to be the way to make sure we get all the cases right.
[Bug fortran/60529] New: internal compiler error with allocatable sub-component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60529 Bug ID: 60529 Summary: internal compiler error with allocatable sub-component Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: carlos.a.cruz at nasa dot gov Using the following compiler release: GNU Fortran (GCC) 4.9.0 20140309 (experimental) on the following reproducer: --- module T_mod implicit none type :: TS integer, allocatable :: i(:) end type TS type :: T ! The following line causes an internal compiler error. type (TS) :: s(1) ! The following line does not: !type (TS), allocatable :: s(:) end type T contains subroutine insert(this) class(T) :: this end subroutine insert end module T_mod --- yields an internal compiler error: repro.F90: In function ‘__final_t_mod_T’: repro.F90:19:0: internal compiler error: in gfc_conv_descriptor_data_get, at fortran/trans-array.c:145 end module T_mod ^ 0x511048 ??? ../sysdeps/x86_64/elf/start.S:113 I am running on a Linux cluster: Linux discover28 2.6.32.54-0.3-default #1 SMP 2012-01-27 17:38:56 +0100 x86_64 x86_64 x86_64 GNU/Linux Note that the internal compiler error does not occur with two earlier releases of gfortran: GNU Fortran (GCC) 4.9.0 20140105 (experimental) GNU Fortran (GCC) 4.8.1
[Bug middle-end/60484] [4.7/4.8/4.9 Regression] -fdump-rtl-expand and attribute optimize gives incorrect dump file path
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60484 --- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Fri Mar 14 17:58:52 2014 New Revision: 208571 URL: http://gcc.gnu.org/viewcvs?rev=208571root=gccview=rev Log: PR middle-end/60484 * common.opt (dump_base_name_prefixed): New Variable. * opts.c (finish_options): Don't prepend directory to x_dump_base_name if x_dump_base_name_prefixed is already set, set it at the end. Modified: trunk/gcc/ChangeLog trunk/gcc/common.opt trunk/gcc/opts.c
[Bug c++/60517] warning/error for taking address of member of a temporary object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added CC||glisse at gcc dot gnu.org --- Comment #9 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #7) To avoid duplicates, the front-end could just return something else, like NULL, when it detects this case (I guess the behavior is undefined and we can do whatever we want, no?). Actually, for a function that returns a reference, we may also want to warn if we detect that it is returning NULL. And a function returning a pointer could be marked returns_nonnull. In both cases we would be introducing a new warning, more confusing than a duplicate. But there are probably small variations on this idea that would work.
[Bug middle-end/60484] [4.7/4.8/4.9 Regression] -fdump-rtl-expand and attribute optimize gives incorrect dump file path
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60484 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug ipa/58721] [4.9 Regression] The subroutine perdida is no longer inlined in fatigue.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58721 --- Comment #22 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #20) Unfortunately the patch regresses abi_check in libstdc++, libstdc++.so.6 now because of the patch exports _ZNSt12system_errorC1ESt10error_codeRKSs@@GLIBCXX_3.4.11 _ZNSt12system_errorC2ESt10error_codeRKSs@@GLIBCXX_3.4.11 symbols. Those will not be exported now.
[Bug ipa/58721] [4.9 Regression] The subroutine perdida is no longer inlined in fatigue.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58721 --- Comment #21 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Fri Mar 14 18:10:59 2014 New Revision: 208572 URL: http://gcc.gnu.org/viewcvs?rev=208572root=gccview=rev Log: PR ipa/58721 * config/abi/pre/gnu.ver (GLIBCXX_3.4.11): Remove unused pattern for _ZNSt12system_errorC* symbols which are not exported on any target. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/abi/pre/gnu.ver
[Bug target/60525] [4.9 Regression] ICE: in final_scan_insn, at final.c:2952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60525 --- Comment #4 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Richard Henderson from comment #3) Created attachment 32350 [details] proposed patch In the description for the patch in question, I mentioned how during stage1 we could clean up all these patterns to rely on LRA. The fact that this pr was filed immediately suggests that the current setup is quite difficult to follow. Cleaning this up now instead of waiting for stage1 would seem to be the way to make sure we get all the cases right. Your patch doesn't bootstrap: /var/tmp/gcc_build_dir/./gcc/xgcc -B/var/tmp/gcc_build_dir/./gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -march=native -O3 -pipe -O2 -march=native -O3 -pipe -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fpic -mlong-double-80 -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fpic -mlong-double-80 -I. -I. -I../.././gcc -I../../../gcc/libgcc -I../../../gcc/libgcc/. -I../../../gcc/libgcc/../gcc -I../../../gcc/libgcc/../include -I../../../gcc/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o _fixunssfdi.o -MT _fixunssfdi.o -MD -MP -MF _fixunssfdi.dep -DL_fixunssfdi -c ../../../gcc/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS ../../../gcc/libgcc/libgcc2.c: In function ‘__fixunssfti’: ../../../gcc/libgcc/libgcc2.c:1492:1: error: unrecognizable insn: } ^ (insn 103 102 36 7 (set (reg:V2DF 22 xmm1 [104]) (vec_merge:V4SF (vec_duplicate:V4SF (float:SF (mem/c:DI (plus:DI (reg/f:DI 7 sp) (const_int -16 [0xfff0])) [3 %sfp+-8 S8 A64]))) (reg:V2DF 22 xmm1 [104]) (const_int 1 [0x1]))) ../../../gcc/libgcc/libgcc2.c:1449 -1 (nil)) ../../../gcc/libgcc/libgcc2.c:1492:1: internal compiler error: in extract_insn, at recog.c:2241 Please submit a full bug report, with preprocessed source if appropriate
[Bug lto/60530] New: openssh-6.5p1 can't be built with lto - revision 208516
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60530 Bug ID: 60530 Summary: openssh-6.5p1 can't be built with lto - revision 208516 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: nheghathivhistha at gmail dot com Created attachment 32351 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32351action=edit Un-reduced preprocessed source file gzipped The only one object file causing the erro from -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect1.o sshconnect2.o mux.o roaming_common.o roaming_client.o is ssh.o. x86_64-pc-linux-gnu-gcc -o ssh ssh.i -L. -Lopenbsd-compat/ -flto=4 -fuse-linker-plugin -Wl,--as-needed -Wl,-O2 -Wl,-flto -O2 -ggdb -pipe -march=native -mtune=native -mno-3dnow -mno-sse4.2 -mno-avx -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -fstack-protector-strong -flto=4 -fuse-linker-plugin -Wl,--as-needed -Wl,-O2 -Wl,-flto -O2 -ggdb -pipe -march=native -mtune=native -mno-3dnow -mno-sse4.2 -mno-avx -pie -lssh -lopenbsd-compat -lssl -lcrypto -ldl -lutil -lz -lnsl -lcrypt -lresolv -lpthread umac.c:1193:3: warning: type of 'umac_ctx' does not match original declaration } umac_ctx; ^ ./umac.c:1193:3: note: previously declared here } umac_ctx; ^ /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-alpha20140311/../../../../x86_64-pc-linux-gnu/bin/ld: /tmp/ccKc90pS.ltrans0.ltrans.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC /tmp/ccKc90pS.ltrans0.ltrans.o: error adding symbols: Bad value collect2: error: ld returned 1 exit status
[Bug lto/60530] openssh-6.5p1 can't be built with lto - revision 208516
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60530 --- Comment #1 from David Kredba nheghathivhistha at gmail dot com --- When system libraries are removed, ssh.i file links to ssh file: x86_64-pc-linux-gnu-gcc -o ssh ssh.i -L. -Lopenbsd-compat/ -flto=4 -fuse-linker-plugin -Wl,--as-needed -Wl,-O2 -Wl,-flto -O2 -ggdb -pipe -march=native -mtune=native -mno-3dnow -mno-sse4.2 -mno-avx -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -fstack-protector-strong -flto=4 -fuse-linker-plugin -Wl,--as-needed -Wl,-O2 -Wl,-flto -O2 -ggdb -pipe -march=native -mtune=native -mno-3dnow -mno-sse4.2 -mno-avx -r -nostdlib ls -l ssh -rw-r--r-- 1 root root 129751 Mar 14 19:21 ssh
[Bug lto/60530] openssh-6.5p1 can't be built with lto - revision 208516
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60530 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com --- (In reply to David Kredba from comment #0) Created attachment 32351 [details] Un-reduced preprocessed source file gzipped The only one object file causing the erro from -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect1.o sshconnect2.o mux.o roaming_common.o roaming_client.o is ssh.o. x86_64-pc-linux-gnu-gcc -o ssh ssh.i -L. -Lopenbsd-compat/ -flto=4 -fuse-linker-plugin -Wl,--as-needed -Wl,-O2 -Wl,-flto -O2 -ggdb -pipe -march=native -mtune=native -mno-3dnow -mno-sse4.2 -mno-avx -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -fstack-protector-strong -flto=4 -fuse-linker-plugin -Wl,--as-needed -Wl,-O2 -Wl,-flto -O2 -ggdb -pipe -march=native -mtune=native -mno-3dnow -mno-sse4.2 -mno-avx -pie -lssh -lopenbsd-compat -lssl -lcrypto -ldl -lutil -lz -lnsl -lcrypt -lresolv -lpthread umac.c:1193:3: warning: type of 'umac_ctx' does not match original declaration } umac_ctx; ^ ./umac.c:1193:3: note: previously declared here } umac_ctx; ^ /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-alpha20140311/../../../../x86_64-pc- linux-gnu/bin/ld: /tmp/ccKc90pS.ltrans0.ltrans.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC /tmp/ccKc90pS.ltrans0.ltrans.o: error adding symbols: Bad value collect2: error: ld returned 1 exit status When -pie is used, you need to add -fpie.
[Bug c/57821] 'array is too large' error is missing when sizetype overflows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57821 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Known to fail||4.9.0 --- Comment #10 from John David Anglin danglin at gcc dot gnu.org --- On hppa2.0w-hp-hpux11.11 with 4.9.0, the error has changed: Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /te st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/large-size-array-6.c -fno-diagnostics-show- caret -fdiagnostics-color=never -O2 -S -o large-size-array-6.s(timeout = 300) spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /test/gnu/gcc/gc c/gcc/testsuite/gcc.dg/large-size-array-6.c -fno-diagnostics-show-caret -fdiagno stics-color=never -O2 -S -o large-size-array-6.s /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/large-size-array-6.c:6:3: internal compil er error: in tree_to_uhwi, at tree.h:3653
[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678 --- Comment #33 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Fri Mar 14 19:06:54 2014 New Revision: 208573 URL: http://gcc.gnu.org/viewcvs?rev=208573root=gccview=rev Log: PR c++/58678 * search.c (dfs_get_pure_virtuals): Treat the destructor of an abstract class as pure. Added: trunk/gcc/testsuite/g++.dg/ipa/devirt-30.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/search.c
[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #34 from Jason Merrill jason at gcc dot gnu.org --- (In reply to David Kredba from comment #31) Calligra-2.8.0 is now affected too Does the patch I just checked in fix Calligra? If not, please reopen the bug with a testcase.
[Bug fortran/60522] [4.7/4.8/4.9 Regression] WHERE construct causes an ICE in gfc_trans_where_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60522 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Summary|WHERE construct causes an |[4.7/4.8/4.9 Regression] |ICE in gfc_trans_where_2|WHERE construct causes an ||ICE in gfc_trans_where_2 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Forgot to mark the PR as a regression. The ICE is due to the gcc_unreachable at default: gcc_unreachable (); meaning that cnext-op has not one of the expected values in the switch.
[Bug target/60032] [4.9 regression] ICE in reload_cse_simplify_operands, at postreload.c:411
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60032 --- Comment #9 from Michael Meissner meissner at gcc dot gnu.org --- Author: meissner Date: Fri Mar 14 19:36:18 2014 New Revision: 208574 URL: http://gcc.gnu.org/viewcvs?rev=208574root=gccview=rev Log: 2014-03-12 Michael Meissner meiss...@linux.vnet.ibm.com Back port from trunk 2013-04-25 Alan Modra amo...@gmail.com PR target/57052 * config/rs6000/rs6000.md (rotlsi3_internal7): Rename to rotlsi3_internal7le and condition on !BYTES_BIG_ENDIAN. (rotlsi3_internal8be): New BYTES_BIG_ENDIAN insn. Repeat for many other rotate/shift and mask patterns using subregs. Name lshiftrt insns. (ashrdisi3_noppc64): Rename to ashrdisi3_noppc64be and condition on WORDS_BIG_ENDIAN. 2013-06-07 Alan Modra amo...@gmail.com * config/rs6000/rs6000.c (rs6000_option_override_internal): Don't override user -mfp-in-toc. (offsettable_ok_by_alignment): Consider just the current access rather than the whole object, unless BLKmode. Handle CONSTANT_POOL_ADDRESS_P constants that lack a decl too. (use_toc_relative_ref): Allow CONSTANT_POOL_ADDRESS_P constants for -mcmodel=medium. * config/rs6000/linux64.h (SUBSUBTARGET_OVERRIDE_OPTIONS): Don't override user -mfp-in-toc or -msum-in-toc. Default to -mno-fp-in-toc for -mcmodel=medium. 2013-06-18 Alan Modra amo...@gmail.com * config/rs6000/rs6000.h (enum data_align): New. (LOCAL_ALIGNMENT, DATA_ALIGNMENT): Use rs6000_data_alignment. (DATA_ABI_ALIGNMENT): Define. (CONSTANT_ALIGNMENT): Correct comment. * config/rs6000/rs6000-protos.h (rs6000_data_alignment): Declare. * config/rs6000/rs6000.c (rs6000_data_alignment): New function. 2013-07-11 Ulrich Weigand ulrich.weig...@de.ibm.com * config/rs6000/rs6000.md (*tls_gd_lowTLSmode:tls_abi_suffix): Require GOT register as additional operand in UNSPEC. (*tls_ld_lowTLSmode:tls_abi_suffix): Likewise. (*tls_got_dtprel_lowTLSmode:tls_abi_suffix): Likewise. (*tls_got_tprel_lowTLSmode:tls_abi_suffix): Likewise. (*tls_gdTLSmode:tls_abi_suffix): Update splitter. (*tls_ldTLSmode:tls_abi_suffix): Likewise. (tls_got_dtprel_TLSmode:tls_abi_suffix): Likewise. (tls_got_tprel_TLSmode:tls_abi_suffix): Likewise. 2014-01-23 Pat Haugen pthau...@us.ibm.com * config/rs6000/rs6000.c (rs6000_option_override_internal): Don't force flag_ira_loop_pressure if set via command line. 2014-02-06 Alan Modra amo...@gmail.com PR target/60032 * config/rs6000/rs6000.c (rs6000_secondary_memory_needed_mode): Only change SDmode to DDmode when lra_in_progress. Modified: branches/ibm/gcc-4_8-branch/gcc/ChangeLog.ibm branches/ibm/gcc-4_8-branch/gcc/config/rs6000/linux64.h branches/ibm/gcc-4_8-branch/gcc/config/rs6000/rs6000-protos.h branches/ibm/gcc-4_8-branch/gcc/config/rs6000/rs6000.c branches/ibm/gcc-4_8-branch/gcc/config/rs6000/rs6000.h branches/ibm/gcc-4_8-branch/gcc/config/rs6000/rs6000.md
[Bug target/57052] missed optimization with rotate and mask
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57052 --- Comment #2 from Michael Meissner meissner at gcc dot gnu.org --- Author: meissner Date: Fri Mar 14 19:36:18 2014 New Revision: 208574 URL: http://gcc.gnu.org/viewcvs?rev=208574root=gccview=rev Log: 2014-03-12 Michael Meissner meiss...@linux.vnet.ibm.com Back port from trunk 2013-04-25 Alan Modra amo...@gmail.com PR target/57052 * config/rs6000/rs6000.md (rotlsi3_internal7): Rename to rotlsi3_internal7le and condition on !BYTES_BIG_ENDIAN. (rotlsi3_internal8be): New BYTES_BIG_ENDIAN insn. Repeat for many other rotate/shift and mask patterns using subregs. Name lshiftrt insns. (ashrdisi3_noppc64): Rename to ashrdisi3_noppc64be and condition on WORDS_BIG_ENDIAN. 2013-06-07 Alan Modra amo...@gmail.com * config/rs6000/rs6000.c (rs6000_option_override_internal): Don't override user -mfp-in-toc. (offsettable_ok_by_alignment): Consider just the current access rather than the whole object, unless BLKmode. Handle CONSTANT_POOL_ADDRESS_P constants that lack a decl too. (use_toc_relative_ref): Allow CONSTANT_POOL_ADDRESS_P constants for -mcmodel=medium. * config/rs6000/linux64.h (SUBSUBTARGET_OVERRIDE_OPTIONS): Don't override user -mfp-in-toc or -msum-in-toc. Default to -mno-fp-in-toc for -mcmodel=medium. 2013-06-18 Alan Modra amo...@gmail.com * config/rs6000/rs6000.h (enum data_align): New. (LOCAL_ALIGNMENT, DATA_ALIGNMENT): Use rs6000_data_alignment. (DATA_ABI_ALIGNMENT): Define. (CONSTANT_ALIGNMENT): Correct comment. * config/rs6000/rs6000-protos.h (rs6000_data_alignment): Declare. * config/rs6000/rs6000.c (rs6000_data_alignment): New function. 2013-07-11 Ulrich Weigand ulrich.weig...@de.ibm.com * config/rs6000/rs6000.md (*tls_gd_lowTLSmode:tls_abi_suffix): Require GOT register as additional operand in UNSPEC. (*tls_ld_lowTLSmode:tls_abi_suffix): Likewise. (*tls_got_dtprel_lowTLSmode:tls_abi_suffix): Likewise. (*tls_got_tprel_lowTLSmode:tls_abi_suffix): Likewise. (*tls_gdTLSmode:tls_abi_suffix): Update splitter. (*tls_ldTLSmode:tls_abi_suffix): Likewise. (tls_got_dtprel_TLSmode:tls_abi_suffix): Likewise. (tls_got_tprel_TLSmode:tls_abi_suffix): Likewise. 2014-01-23 Pat Haugen pthau...@us.ibm.com * config/rs6000/rs6000.c (rs6000_option_override_internal): Don't force flag_ira_loop_pressure if set via command line. 2014-02-06 Alan Modra amo...@gmail.com PR target/60032 * config/rs6000/rs6000.c (rs6000_secondary_memory_needed_mode): Only change SDmode to DDmode when lra_in_progress. Modified: branches/ibm/gcc-4_8-branch/gcc/ChangeLog.ibm branches/ibm/gcc-4_8-branch/gcc/config/rs6000/linux64.h branches/ibm/gcc-4_8-branch/gcc/config/rs6000/rs6000-protos.h branches/ibm/gcc-4_8-branch/gcc/config/rs6000/rs6000.c branches/ibm/gcc-4_8-branch/gcc/config/rs6000/rs6000.h branches/ibm/gcc-4_8-branch/gcc/config/rs6000/rs6000.md
[Bug target/60525] [4.9 Regression] ICE: in final_scan_insn, at final.c:2952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60525 --- Comment #5 from Richard Henderson rth at gcc dot gnu.org --- (In reply to Markus Trippelsdorf from comment #4) -march=native For what host?
[Bug target/60525] [4.9 Regression] ICE: in final_scan_insn, at final.c:2952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60525 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Attachment #32350|0 |1 is obsolete|| --- Comment #6 from Richard Henderson rth at gcc dot gnu.org --- Created attachment 32352 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32352action=edit second patch Testing showed some -m32 failures requiring minor tweaks.
[Bug target/60525] [4.9 Regression] ICE: in final_scan_insn, at final.c:2952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60525 --- Comment #7 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Richard Henderson from comment #5) (In reply to Markus Trippelsdorf from comment #4) -march=native For what host? Like in comment0: -march=amdfam10
[Bug fortran/60522] [4.7/4.8/4.9 Regression] WHERE construct causes an ICE in gfc_trans_where_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60522
Mikael Morin mikael at gcc dot gnu.org changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #3 from Mikael Morin mikael at gcc dot gnu.org ---
BLOCK constructs are not allowed inside WHERE constructs.
Thus, the common function optimization should not create a BLOCK to hold the
temporary variables, at least not inside WHERE.
Another possible fix, the following patch disables the optimization inside
WHERE.
diff --git a/gcc/fortran/frontend-passes.c b/gcc/fortran/frontend-passes.c
index 52bd700..dc641de 100644
--- a/gcc/fortran/frontend-passes.c
+++ b/gcc/fortran/frontend-passes.c
@@ -630,9 +630,16 @@ static int
cfe_code (gfc_code **c, int *walk_subtrees ATTRIBUTE_UNUSED,
void *data ATTRIBUTE_UNUSED)
{
- current_code = c;
- inserted_block = NULL;
- changed_statement = NULL;
+ /* BLOCK constructs cannot appear inside WHERE blocks; as the optimization
+ may introduce the former we disable it inside the latter. */
+ if ((*c)-op == EXEC_WHERE)
+*walk_subtrees = 0;
+ else
+{
+ current_code = c;
+ inserted_block = NULL;
+ changed_statement = NULL;
+}
return 0;
}
[Bug target/60520] stack adjustment are not merged anymore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60520 --- Comment #11 from H.J. Lu hjl.tools at gmail dot com --- Created attachment 32353 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32353action=edit A patch This patch checks LEAVE and remove stack deallocation. It removes 5 stack deallocations in cc1plus on Linux/i686.
[Bug c++/60531] New: template function not resolved when comparing functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60531
Bug ID: 60531
Summary: template function not resolved when comparing
functions
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: harald at gigawatt dot nl
template typename T void f();
int main() { fint == fint; }
is rejected with
test.cc: In function ‘int main()’:
test.cc:2:24: error: invalid operands of types ‘unresolved overloaded function
type’ and ‘unresolved overloaded function type’ to binary ‘operator==’
int main() { fint == fint; }
I see no reason why this would be invalid, and it is accepted by all other
compilers I was able to test (clang, Intel, Sun, MSVC), but it is rejected by
GCC at least as far back as 4.3.
[Bug fortran/60392] Problem with TRANSPOSE and CONTIGUOUS dummy arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60392 --- Comment #7 from Mikael Morin mikael at gcc dot gnu.org --- Author: mikael Date: Fri Mar 14 21:28:59 2014 New Revision: 208581 URL: http://gcc.gnu.org/viewcvs?rev=208581root=gccview=rev Log: fortran/ PR fortran/60392 * trans-array.c (gfc_conv_array_parameter): Don't reuse the descriptor if it has transposed dimensions. testsuite/ PR fortran/60392 * gfortran.dg/transpose_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/transpose_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/60392] Problem with TRANSPOSE and CONTIGUOUS dummy arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60392 --- Comment #8 from Mikael Morin mikael at gcc dot gnu.org --- Fixed on trunk.
[Bug fortran/60392] Problem with TRANSPOSE and CONTIGUOUS dummy arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60392 --- Comment #9 from Alexander Vogt a.vogt at fulguritus dot com --- Thanks a lot!
[Bug c++/60532] New: [4.9 Regression] r208573 causes Firefox build failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60532 Bug ID: 60532 Summary: [4.9 Regression] r208573 causes Firefox build failure Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org CC: jason at gcc dot gnu.org With --enable-checking=release I get with r208573: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x77e27840 (LWP 12914)] 0x00e3f6d0 in dfs_get_pure_virtuals(tree_node*, void*) () (gdb) bt #0 0x00e3f6d0 in dfs_get_pure_virtuals(tree_node*, void*) () #1 0x00e3e302 in get_pure_virtuals(tree_node*) () #2 0x00d087e2 in finish_struct_1(tree_node*) () #3 0x00d002a1 in finish_struct(tree_node*, tree_node*) () #4 0x00c6bc58 in cp_parser_class_specifier_1(cp_parser*) [clone .lto_priv.4355] () #5 0x00c5e2ef in cp_parser_decl_specifier_seq(cp_parser*, int, cp_decl_specifier_seq*, int*) [clone .lto_priv.3863] () #6 0x00c5c7e0 in cp_parser_block_declaration(cp_parser*, bool) [clone .lto_priv.4014] () #7 0x00c5bc1d in cp_parser_declaration(cp_parser*) [clone .lto_priv.4104] () #8 0x00c5b8d8 in cp_parser_declaration_seq_opt(cp_parser*) [clone .lto_priv.4092] () #9 0x00c7a56b in cp_parser_namespace_definition(cp_parser*) [clone .lto_priv.3836] () #10 0x00c5be8c in cp_parser_declaration(cp_parser*) [clone .lto_priv.4104] () #11 0x00c5b8d8 in cp_parser_declaration_seq_opt(cp_parser*) [clone .lto_priv.4092] () #12 0x00c41683 in c_parse_file() () #13 0x00c10ab2 in c_common_parse_file() () #14 0x00c10921 in compile_file() [clone .lto_priv.2466] () #15 0x00b56e02 in toplev_main(int, char**) () #16 0x77756fb0 in __libc_start_main () from /lib/libc.so.6 #17 0x00b511c7 in _start () Reducing.
[Bug c++/60532] [4.9 Regression] r208573 causes Firefox build failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60532
--- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
markus@x4 libopus % test.ii
class A
{
~A ();
};
class B : A
{
virtual void m () = 0;
};
markus@x4 libopus % g++ -c test.ii
test.ii:5:7: internal compiler error: Segmentation fault
class B : A
^
Please submit a full bug report,
[Bug fortran/60522] [4.7/4.8/4.9 Regression] WHERE construct causes an ICE in gfc_trans_where_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60522 --- Comment #4 from Thomas Koenig tkoenig at gcc dot gnu.org --- (In reply to Mikael Morin from comment #3) BLOCK constructs are not allowed inside WHERE constructs. Thus, the common function optimization should not create a BLOCK to hold the temporary variables, at least not inside WHERE. Possible. Another possible fix, the following patch disables the optimization inside WHERE. Not preferred, I'd like to continue the optimization. I'll take a look.
[Bug c++/60532] [4.9 Regression] r208573 causes Firefox build failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60532 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-03-15 Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678 --- Comment #35 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Sat Mar 15 01:39:03 2014 New Revision: 208586 URL: http://gcc.gnu.org/viewcvs?rev=208586root=gccview=rev Log: PR c++/60532 PR c++/58678 * search.c (get_pure_virtuals): Handle abstract dtor here. (dfs_get_pure_virtuals): Not here. Added: trunk/gcc/testsuite/g++.dg/other/abstract6.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/search.c
[Bug c++/60532] [4.9 Regression] r208573 causes Firefox build failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60532 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Fixed.
[Bug c++/60532] [4.9 Regression] r208573 causes Firefox build failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60532 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Sat Mar 15 01:39:03 2014 New Revision: 208586 URL: http://gcc.gnu.org/viewcvs?rev=208586root=gccview=rev Log: PR c++/60532 PR c++/58678 * search.c (get_pure_virtuals): Handle abstract dtor here. (dfs_get_pure_virtuals): Not here. Added: trunk/gcc/testsuite/g++.dg/other/abstract6.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/search.c
[Bug libstdc++/60521] std::lock_guard ignores adopt_lock strategy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60521
Sergei Turchanov turchanov at farpost dot com changed:
What|Removed |Added
Version|4.8.3 |4.4.7
--- Comment #2 from Sergei Turchanov turchanov at farpost dot com ---
My bad! I did not correctly specified target GCC version which should really be
4.4.7 and thus code snippet from mutex is
...
lock_guard(mutex_type __m, adopt_lock_t __a) : _M_device(__m)
{ _M_device.lock(); }
...
which does attempt to lock a mutex.
Now as I see this bug is fixed in mainline so the question is do you plan any
new releases in 4.4.x branch?
[Bug rtl-optimization/60533] New: [4.8/4.9 regression] Error introduced by bb-reorder at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60533 Bug ID: 60533 Summary: [4.8/4.9 regression] Error introduced by bb-reorder at -O3 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: wschmidt at gcc dot gnu.org CC: ebotcazou at gcc dot gnu.org Host: powerpc64-unknown-linux-gnu Target: powerpc64-unknown-linux-gnu Build: powerpc64-unknown-linux-gnu For GCC 4.8 and current trunk, compiling the attached test case with g++ -O3 produces an executable that fails with a memory access violation. I've tracked this down to the bb-reorder phase, which breaks up a lifetime of general register 6 by moving its definition and one of its uses very far apart. Since r6 is a volatile register, the call clobbers its value, eventually resulting in a bogus address. The error is introduced into this function: ;; Function unsigned int vigra::labelVolume(SrcIterator, SrcShape, SrcAccessor,\ DestIterator, DestAccessor, Neighborhood3D, EqualityFunctor) [with SrcIterator\ = vigra::StridedMultiIterator3u, int, const int, const int*; SrcAccessor = \ vigra::StandardConstValueAccessorint; SrcShape = vigra::TinyVectorlong int, \ 3; DestIterator = vigra::StridedMultiIterator3u, int, int, int*; DestAccess\ or = vigra::StandardValueAccessorint; Neighborhood3D = vigra::Neighborhood3DS\ ix::NeighborCode3D; EqualityFunctor = std::equal_toint] (_ZN5vigra11labelVolu\ meINS_20StridedMultiIteratorILj3EiRKiPS2_EENS_26StandardConstValueAccessorIiEEN\ S_10TinyVectorIlLi3EEENS1_ILj3EiRiPiEENS_21StandardValueAccessorIiEENS_17Neighb\ orhood3DSix14NeighborCode3DESt8equal_toIiEEEjT_T1_T0_T2_T3_T4_T5_, funcdef_no=5\ 419, decl_uid=81154, cgraph_uid=1943) I'm also attaching the dumps from before and after the bb-reorder phase. In the 225r.rtl_dce dump, r6 is defined by insn 266 in block 25, and used by insn 268 in block 25 and insn 283 in block 26. Block 26 has block 25 as its only predecessor. Following bb-reorder, insns 266 and 268 are now in block 12, but insn 283 is in block 87, a great distance away. As a result, r6 is now upward exposed by insn 283 in block 87, which has blocks 12 and 86 as predecessors. Block 86 ends with a call in insn 887, which clobbers the volatile register r6. So along the path from block 86 to block 87, insn 283 is guaranteed to see garbage in r6. There is nothing in the prior graph corresponding to a path from block 86 to block 87; this bogus path was introduced by the block reordering. (Apologies for the size of the preprocessed test case. I tried to reduce it with multidelta but kept hanging my machine partway through.)
[Bug rtl-optimization/60533] [4.8/4.9 regression] Error introduced by bb-reorder at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60533 --- Comment #1 from Bill Schmidt wschmidt at gcc dot gnu.org --- Created attachment 32354 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32354action=edit Dump before bb-reorder
[Bug rtl-optimization/60533] [4.8/4.9 regression] Error introduced by bb-reorder at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60533 --- Comment #2 from Bill Schmidt wschmidt at gcc dot gnu.org --- Created attachment 32355 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32355action=edit Dump after bb-reorder
[Bug target/60525] [4.9 Regression] ICE: in final_scan_insn, at final.c:2952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60525 --- Comment #9 from Richard Henderson rth at gcc dot gnu.org --- Author: rth Date: Sat Mar 15 03:24:11 2014 New Revision: 208587 URL: http://gcc.gnu.org/viewcvs?rev=208587root=gccview=rev Log: PR target/60525 * config/i386/i386.md (floathiX87MODEF2): Delete expander; rename define_insn from *floathiX87MODEF2_i387; allow nonimmediate_operand. (*floathiX87MODEF2_i387_with_temp): Remove. (floathi splitters): Remove. (floatSWI48xxf2): New pattern. (floatSWI48MODEF2): Rename from floatSWI48xX87MODEF2. Drop code that tried to handle DImode for 32-bit, but which was excluded by the pattern's condition. Drop allocation of stack temporary. (*floatsiMODEF2_vector_mixed_with_temp): Remove. (*floatSWI48MODEF2_mixed_with_temp): Remove. (*floatSWI48MODEF2_mixed_interunit): Remove. (*floatSWI48MODEF2_mixed_nointerunit): Remove. (*floatsiMODEF2_vector_sse_with_temp): Remove. (*floatSWI48MODEF2_sse_with_temp): Remove. (*floatSWI48MODEF2_sse_interunit): Remove. (*floatSWI48MODEF2_sse_nointerunit): Remove. (*floatSWI48xX87MODEF2_i387_with_temp): Remove. (*floatSWI48xX87MODEF2_i387): Remove. (all float _with_temp splitters): Remove. (*floatSWI48xMODEF2_i387): New pattern. (*floatSWI48MODEF2_sse): New pattern. (float TARGET_USE_VECTOR_CONVERTS splitters): Merge them. (float TARGET_SSE_PARTIAL_REG_DEPENDENCY splitters): Merge them. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md
[Bug rtl-optimization/60533] [4.8/4.9 regression] Error introduced by bb-reorder at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60533 --- Comment #4 from Bill Schmidt wschmidt at gcc dot gnu.org --- Created attachment 32357 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32357action=edit Second half of test case
[Bug rtl-optimization/60533] [4.8/4.9 regression] Error introduced by bb-reorder at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60533 --- Comment #3 from Bill Schmidt wschmidt at gcc dot gnu.org --- Created attachment 32356 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32356action=edit First half of test case Sorry, have to split the test case into two pieces; please catenate to reproduce.
[Bug target/60525] [4.9 Regression] ICE: in final_scan_insn, at final.c:2952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60525 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Richard Henderson rth at gcc dot gnu.org --- Fixed.
