[Bug fortran/64244] [4.8/4.9/5 Regression] ICE at class.c:236 when using non_overridable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64244 --- Comment #7 from janus at gcc dot gnu.org --- Author: janus Date: Tue Dec 16 08:15:38 2014 New Revision: 218776 URL: https://gcc.gnu.org/viewcvs?rev=218776root=gccview=rev Log: 2014-12-16 Janus Weil ja...@gcc.gnu.org PR fortran/64244 * resolve.c (resolve_typebound_call): New argument to pass out the non-overridable attribute of the specific procedure. (resolve_typebound_subroutine): Get overridable flag from resolve_typebound_call. 2014-12-16 Janus Weil ja...@gcc.gnu.org PR fortran/64244 * gfortran.dg/typebound_call_26.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/typebound_call_26.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/64244] [4.8/4.9/5 Regression] ICE at class.c:236 when using non_overridable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64244 --- Comment #8 from janus at gcc dot gnu.org --- The bug should be fixed on trunk with r218776. Ondrej, in case your test code is part of a larger code base, do you have the possibility to test it with gfortran trunk?
[Bug tree-optimization/64326] New: ICE at -O3 on x86_64-linux-gnu in check_probability, at basic-block.h:581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64326
Bug ID: 64326
Summary: ICE at -O3 on x86_64-linux-gnu in check_probability,
at basic-block.h:581
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code causes an ICE when compiled with the current gcc trunk at
-O3 on x86_64-linux-gnu in both 32-bit and 64-bit modes.
It is a regression from 4.9.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 5.0.0 20141215 (experimental) [trunk revision 218731] (GCC)
$
$ gcc-trunk -O2 -c small.c
$ gcc-4.9 -O3 -c small.c
$
$ gcc-trunk -O3 -c small.c
small.c: In function ‘fn2’:
small.c:11:1: internal compiler error: in check_probability, at
basic-block.h:581
fn2 ()
^
0xc9da16 check_probability
../../gcc-trunk/gcc/basic-block.h:581
0xc9b165 check_probability
../../gcc-trunk/gcc/tree.h:2893
0xc9b165 combine_probabilities
../../gcc-trunk/gcc/basic-block.h:590
0xc9b165 slpeel_tree_peel_loop_to_edge
../../gcc-trunk/gcc/tree-vect-loop-manip.c:1382
0xc9b504 vect_do_peeling_for_loop_bound(_loop_vec_info*, tree_node*,
tree_node*, unsigned int, bool)
../../gcc-trunk/gcc/tree-vect-loop-manip.c:1773
0xc8bef7 vect_transform_loop(_loop_vec_info*)
../../gcc-trunk/gcc/tree-vect-loop.c:5907
0xcaa3f7 vectorize_loops()
../../gcc-trunk/gcc/tree-vectorizer.c:491
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.
$
int a, b, c, d, e, f[5][2];
char g;
int
fn1 ()
{
return d c ? 0 : 1;
}
int
fn2 ()
{
int h;
for (;;)
for (; e;)
{
int i, j;
h = a ? 1 : b;
if (h || fn1 () ^ g - 682)
{
for (i = 0; i 5; i++)
for (j = 0; j 2; j++)
f[i][j] = 0;
return 0;
}
}
}
[Bug tree-optimization/64326] [5 Regression] ICE at -O3 on x86_64-linux-gnu in check_probability, at basic-block.h:581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64326 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-16 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |5.0 Summary|ICE at -O3 on |[5 Regression] ICE at -O3 |x86_64-linux-gnu in |on x86_64-linux-gnu in |check_probability, at |check_probability, at |basic-block.h:581 |basic-block.h:581 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug middle-end/64327] New: ../../gcc/gcc/rtlanal.c:4881:48: runtime error: shift exponent 4294967295 is too large for 64-bit type 'long unsigned int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64327 Bug ID: 64327 Summary: ../../gcc/gcc/rtlanal.c:4881:48: runtime error: shift exponent 4294967295 is too large for 64-bit type 'long unsigned int' Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org CC: dmalcolm at gcc dot gnu.org Running bootstrap-ubsan on x86_64 shows many instances of: ../../gcc/gcc/rtlanal.c:4881:48: runtime error: shift exponent 4294967295 is too large for 64-bit type 'long unsigned int'
[Bug fortran/56459] Wrongly rejects TYPE(CHARACTER*1,) (with comma)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56459 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org --- Closed as WONTFIX For the IR, see http://j3-fortran.org/doc/year/14/14-006A.txt: NUMBER: F08/0097 TITLE: Is the optional comma allowed in TYPE(CHARACTER*...)? KEYWORD: TYPE, CHARACTER DEFECT TYPE: Erratum STATUS: In F2008 Corrigendum 3 QUESTION: Consider CHARACTER*1, A TYPE(CHARACTER*1,) B The optional comma in the declaration of B looks ugly. Is this deliberate? ANSWER: No, this syntax was inadvertently allowed. An edit is provided to remove it. EDITS to 10-007r1: [51:26+] 4.3.1.1, after C406, insert new constraint C406a (R403) In TYPE(intrinsic-type-spec) the intrinsic-type-spec shall not end with a comma. SUBMITTED BY: Malcolm Cohen HISTORY: 13-285m201 F08/0097 submitted - passed by J3 meeting 13-313m202 Passed by J3 letter ballot 13-297 N1994 m202 Passed by WG5 ballot 7 N1991/92/94 N2002 m203 In F2008 Corrigendum 3
[Bug middle-end/64309] if (1 (1 n)) not simplified to if (n == 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64309 --- Comment #13 from rguenther at suse dot de rguenther at suse dot de --- On December 15, 2014 10:11:13 PM CET, glisse at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64309 --- Comment #12 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Marc Glisse from comment #11) ((pow2p)(pow2n))!=0 - p==n Oups, it wasn't supposed to be the same power of 2, so: (((1k)p)((1l)n))!=0 - p==n+(l-k) (k and l are constants) As others noted the transforms are only generally beneficial if they feed comparisons. Otherwise we may of course want to find a canonical form, but possibly that shouldn't be a comparison unless expansion knows how to undo this and rewrite them as bit operation. Richard.
[Bug tree-optimization/64326] [5 Regression] ICE at -O3 on x86_64-linux-gnu in check_probability, at basic-block.h:581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64326 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug ipa/64325] [5 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64325 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 CC||hubicka at gcc dot gnu.org Target Milestone|--- |5.0
[Bug rtl-optimization/64323] [5 Regression] LRA: ICE when compiling newlib for ARM.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64323 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||ra Target||arm-eabi CC||vmakarov at gcc dot gnu.org Target Milestone|--- |5.0 Summary|LRA: ICE when compiling |[5 Regression] LRA: ICE |newlib for ARM. |when compiling newlib for ||ARM.
[Bug rtl-optimization/64323] [5 Regression] LRA: ICE when compiling newlib for ARM.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64323 --- Comment #1 from christophe.lyon at st dot com --- Maybe this was fixed by Vladimir's commit r218760?
[Bug tree-optimization/64326] [5 Regression] ICE at -O3 on x86_64-linux-gnu in check_probability, at basic-block.h:581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64326 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Started with r211725.
[Bug tree-optimization/64322] More optimize opportunity for constant folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64322
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-12-16
Ever confirmed|0 |1
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
Well, I rather wonder how the store to an otherwise unused value can affect
the code. It doesn't on the GIMPLE level. I suppose RTL somehow invalidly
thinks that after b = 0; c = 0; b is still zero (so it only considers the
two volatiles aliasing but doesn't consider the b volatile).
It seems to be combine optimizing the case with c = 0, not sure why it doens't
with c = 0x100L. Ah, the large constant is split to a reg.
Difference:
-Successfully matched this instruction:
-(set (reg:DI 98)
-(ashift:DI (reg:DI 94 [ D.1849 ])
-(const_int 1 [0x1])))
-Successfully matched this instruction:
-(set (reg:DI 97 [ a ])
-(const_int 0 [0]))
-allowing combination of insns 10, 11 and 12
-original costs 4 + 3 + 0 = 0
-replacement costs 6 + 4 = 10
-deferring deletion of insn with uid = 10.
-modifying insn i211: {r98:DI=r94:DI0x1;clobber flags:CC;}
Otherwise I agree with Jakub that VRP should be enhanced (it's weak with
handling non-initeger-VR_RANGES for most codes).
But combine probably exposes a RTL simplification so I wonder if we can
add a similar one (after figuring out which one applies) on the GIMPLE level.
Confirmed (at -O2 both codes are bad).
[Bug tree-optimization/64322] More optimize opportunity for constant folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64322
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org ---
For VRP I'm thinking of (completely untested):
--- gcc/tree-vrp.c.jj2014-12-01 14:57:30.0 +0100
+++ gcc/tree-vrp.c2014-12-16 10:17:27.543111649 +0100
@@ -2434,6 +2434,7 @@ extract_range_from_binary_expr_1 (value_
code != MAX_EXPR
code != PLUS_EXPR
code != MINUS_EXPR
+ code != RSHIFT_EXPR
(vr0.type == VR_VARYING
|| vr1.type == VR_VARYING
|| vr0.type != vr1.type
@@ -2948,6 +2949,15 @@ extract_range_from_binary_expr_1 (value_
{
if (code == RSHIFT_EXPR)
{
+ /* Even if vr0 is VARYING or otherwise not usable, we can derive
+ useful ranges just from the shift count. E.g.
+ x 63 for signed 64-bit x is always [-1, 0]. */
+ if (vr0.type != VR_RANGE || symbolic_range_p (vr0))
+{
+ vr0.type = type = VR_RANGE;
+ vr0.min = vrp_val_min (expr_type);
+ vr0.max = vrp_val_max (expr_type);
+}
extract_range_from_multiplicative_op_1 (vr, code, vr0, vr1);
return;
}
[Bug tree-optimization/64319] add alias runtime check to remove load after load redundancy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64319 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||alias, missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-16 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- The interesting problem to solve is of course which disabiguation checks to insert (and where). And whether there is really a net positive effect in runtime (surley not code-size). Probably making this a value-profiling would make sense? As for the missed optimization with the conditonal code here the issue is that points-to information is not flow-sensitive (or rather only in sofar as SSA defs are flow-sensitive). bb 2: if (a_3(D) == b_4(D)) goto bb 3; else goto bb 4; ... bb 4: *a_3(D) = 1; _12 = *b_4(D); _13 = _12 + 1; *b_4(D) = _13; _15 = *a_3(D); And of course our points-to code doesn't look at conditionals at all to derive alias information (it couldn't associate it with SSA names later anyway). It would need to add explicit IL similar to VRP (but that does it only temporarily), and it also would require to teach the solver of a constraint that makes two pointers non-equal (not sure if doable at all). For the a == b case we manage to copy-propagate both to equal values in DOM and thus optimize the loads and later DSE the redundant store. We could use the recently added facility to record explicit non-dependences which is also flow-sensitive (recorded on actual memory references) when adding the alias check or from code (DOM?) that figures out non-equivalence. [see MR_DEPENDENCE_CLIQE / MR_DEPENDENCE_BASE] I see this as two bugs - one to generate runtime disambiguation code, possibly directed by profiling, and one to actually make use of present runtime alias checks. Confirmed.
[Bug tree-optimization/63568] Missed optimization (a ~mask) | (b mask) = a ^ ((a ^ b) mask)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63568 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |5.0 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- I'll try to come up with a match-and-simplify simplification.
[Bug lto/64043] [5 Regression] ICE (segfault) with LTO: in tree_check/tree.h:2758 get_binfo_at_offset/tree.c:11914
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64043 --- Comment #11 from Andreas Schwab sch...@linux-m68k.org --- This breaks ada: $ gcc/gnatmake --GCC=gcc/xgcc --GNATBIND=gcc/gnatbind --GNATLINK=gcc/gnatlink -cargs -Bgcc/ -largs '--GCC=gcc/xgcc -Bgcc' -margs --RTS=ia64-suse-linux/./libada -f ../gcc/testsuite/gnat.dg/lto8.adb -gnatws -flto -lm -o ./lto8.exe gcc/xgcc -c -I../gcc/testsuite/gnat.dg/ -Bgcc/ --RTS=ia64-suse-linux/./libada -gnatws -flto -lm -I- ../gcc/testsuite/gnat.dg/lto8.adb gcc/xgcc -c -I../gcc/testsuite/gnat.dg/ -Bgcc/ --RTS=ia64-suse-linux/./libada -gnatws -flto -lm -I- ../gcc/testsuite/gnat.dg/lto8_pkg.adb gcc/gnatbind --RTS=ia64-suse-linux/./libada -x lto8.ali gcc/gnatlink lto8.ali --GCC=gcc/xgcc -Bgcc -flto -o ./lto8.exe ../gcc/testsuite/gnat.dg/lto8_pkg.ads: In function ‘lto8_pkg___elabs’: ../gcc/testsuite/gnat.dg/lto8_pkg.ads:4:1: internal compiler error: in expand_gimple_stmt_1, at cfgexpand.c:3420 package Lto8_Pkg is ^ 0x4026d36f expand_gimple_stmt_1 ../../gcc/cfgexpand.c:3420 0x4026e52f expand_gimple_stmt ../../gcc/cfgexpand.c:3447 0x4027014f expand_gimple_basic_block ../../gcc/cfgexpand.c:5280 0x4027453f execute ../../gcc/cfgexpand.c:5889 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. lto-wrapper: fatal error: /usr/local/gcc/test/Build/gcc/xgcc returned 1 exit status
[Bug tree-optimization/64328] New: addr_equal-1.c fails execution.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64328 Bug ID: 64328 Summary: addr_equal-1.c fails execution. Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: belagod at gcc dot gnu.org FAIL: gcc.dg/addr_equal-1.c execution test $ aarch64-none-elf-gcc /work/dev/arm/src/gcc/gcc/testsuite/gcc.dg/addr_equal-1.c -O2 -lm -mcmodel=tiny -fPIC -o foo.exe fails on AArch64. This test was introduced by this patch: https://gcc.gnu.org/ml/gcc-patches/2014-12/msg00613.html The specific test that's failing is if (!__builtin_constant_p (def_var0 == def_var1)) abort(); where def_var0 and def_var1 are globals declared in the same translation unit. When compiled with fPIC, how much can we know about their addresses at compile-time for the above test to pass? Is this test valid?
[Bug rtl-optimization/64323] [5 Regression] LRA: ICE when compiling newlib for ARM.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64323 --- Comment #2 from Hale Wang Hale.Wang at arm dot com --- (In reply to christophe.lyon from comment #1) Maybe this was fixed by Vladimir's commit r218760? Yes, it's fixed by Vladimir's commit r218760. Thank you very much. This issue could be marked as fixed now.
[Bug rtl-optimization/64323] [5 Regression] LRA: ICE when compiling newlib for ARM.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64323 Hale Wang Hale.Wang at arm dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Hale Wang Hale.Wang at arm dot com --- Already fixed by Vladimir's commit r218760
[Bug tree-optimization/64322] More optimize opportunity for constant folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64322
--- Comment #4 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #3)
For VRP I'm thinking of (completely untested):
--- gcc/tree-vrp.c.jj 2014-12-01 14:57:30.0 +0100
+++ gcc/tree-vrp.c2014-12-16 10:17:27.543111649 +0100
@@ -2434,6 +2434,7 @@ extract_range_from_binary_expr_1 (value_
code != MAX_EXPR
code != PLUS_EXPR
code != MINUS_EXPR
+ code != RSHIFT_EXPR
(vr0.type == VR_VARYING
|| vr1.type == VR_VARYING
|| vr0.type != vr1.type
@@ -2948,6 +2949,15 @@ extract_range_from_binary_expr_1 (value_
{
if (code == RSHIFT_EXPR)
{
+ /* Even if vr0 is VARYING or otherwise not usable, we can derive
+ useful ranges just from the shift count. E.g.
+ x 63 for signed 64-bit x is always [-1, 0]. */
+ if (vr0.type != VR_RANGE || symbolic_range_p (vr0))
+ {
+ vr0.type = type = VR_RANGE;
+ vr0.min = vrp_val_min (expr_type);
+ vr0.max = vrp_val_max (expr_type);
+ }
Yeah, that should work. We should probably simply handle all operation
codes that do not explicitely handle non-simple VR_RANGEs by promoting
all operands that way (also handle the single-VR_UNDEFINED op case and
VR_VARYING generally that way). The DIV and MOD_EXPR cases look like
they would benefit from that.
extract_range_from_multiplicative_op_1 (vr, code, vr0, vr1);
return;
}
[Bug tree-optimization/64322] More optimize opportunity for constant folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64322
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Richard Biener from comment #4)
(In reply to Jakub Jelinek from comment #3)
For VRP I'm thinking of (completely untested):
--- gcc/tree-vrp.c.jj 2014-12-01 14:57:30.0 +0100
+++ gcc/tree-vrp.c 2014-12-16 10:17:27.543111649 +0100
@@ -2434,6 +2434,7 @@ extract_range_from_binary_expr_1 (value_
code != MAX_EXPR
code != PLUS_EXPR
code != MINUS_EXPR
+ code != RSHIFT_EXPR
(vr0.type == VR_VARYING
|| vr1.type == VR_VARYING
|| vr0.type != vr1.type
@@ -2948,6 +2949,15 @@ extract_range_from_binary_expr_1 (value_
{
if (code == RSHIFT_EXPR)
{
+ /* Even if vr0 is VARYING or otherwise not usable, we can derive
+useful ranges just from the shift count. E.g.
+x 63 for signed 64-bit x is always [-1, 0]. */
+ if (vr0.type != VR_RANGE || symbolic_range_p (vr0))
+ {
+ vr0.type = type = VR_RANGE;
+ vr0.min = vrp_val_min (expr_type);
+ vr0.max = vrp_val_max (expr_type);
+ }
Yeah, that should work. We should probably simply handle all operation
codes that do not explicitely handle non-simple VR_RANGEs by promoting
all operands that way (also handle the single-VR_UNDEFINED op case and
VR_VARYING generally that way). The DIV and MOD_EXPR cases look like
they would benefit from that
DIV and MOD already handle it (DIV quite similarly to this). And from the list
of codes that extract_range_from_binary_expr_1 handles, I think RSHIFT_EXPR is
the only one that (for certain VR_RANGEs of one argument) can decrease a
VR_VARYING into something narrower and didn't handle arbitrary ranges of the
other operand yet.
[Bug c++/64329] New: Crash when returning reference from lambda with deduced type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64329
Bug ID: 64329
Summary: Crash when returning reference from lambda with
deduced type
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: will at benfold dot com
Created attachment 34289
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34289action=edit
Preprocessed source
I believe the program below is valid and correct, but I see heap corruption at
the end of main() (in std::map::~map) when I allow the compiler to deduce
return type of the lambda.
Both the parameters to apply() are still alive when the returned lambda is
invoked, so fn(arg) should safely return a valid const ref to a tuple. If the
return type for the lambda is given explicitly (see comments in code) then
everything is fine, whether it's returning by value or by const ref.
Compiling with -Wall --std=c++11 -O0 -g3; optimisation level seems to make no
difference.
#include functional
#include map
#include string
#include tuple
typedef std::tuplestd::string, std::string, double Result;
typedef std::mapint, Result Argument;
typedef std::functionconst Result (const Argument ) Function;
std::functionResult () apply (const Argument arg, const Function fn)
{
// No trouble with any of these...
// return [fn, arg]() - Result { return fn(arg); };
// return [fn, arg]() - const Result { return fn(arg); };
// return [fn, arg](){ Result r = fn(arg); return r;
};
// But this causes heap corruption
return [fn, arg](){ return fn(arg); };
}
const Result func (const Argument arg)
{
// std::map::at returns a const ref
return arg.at(0);
}
int main (int argc, char *argv[])
{
Argument arg;
arg[0] = Result(, a, 0);
Function f = func;
auto g = apply(arg, f);
g();
return 0;
}
Using built-in specs.
COLLECT_GCC=/software/thirdparty/gcc/4.9.1-0.el6_64/bin/g++
COLLECT_LTO_WRAPPER=/software/thirdparty/gcc/4.9.1-0.el6_64/libexec/gcc/x86_64-unknown-linux-gnu/4.9.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/software/thirdparty/gcc/4.9.1-0.el6_64
--with-system-zlib --enable-shared --enable-threads=posix --enable-laguages=all
--with-ppl --with-cloog --disable-multilib
Thread model: posix
gcc version 4.9.1 (GCC)
[Bug sanitizer/64265] [5 Regression] r217669 broke tsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64265 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #25 from Jakub Jelinek jakub at gcc dot gnu.org --- The regression is fixed. For the EH support, patch has been posted, but that is not a fix for a regression, but enhancement.
[Bug rtl-optimization/64291] [5 Regression] Miscompile t-div in GMP's testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64291 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-16 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r217587.
[Bug rtl-optimization/64291] [5 Regression] Miscompile t-div in GMP's testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64291 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #3) Started with r217587. Oops, sorry for typo, r217588.
[Bug sanitizer/64330] New: [ASAN] Bogus AddressSanitizer: odr-violation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64330
Bug ID: 64330
Summary: [ASAN] Bogus AddressSanitizer: odr-violation
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org,
mpolacek at gcc dot gnu.org
I have in a C++ header file (foo.h):
class Foo {
public:
static const unsigned short AlignRight;
static const unsigned short AlignBottom;
...
};
And in its C++ file (foo.cc):
const unsigned shortFoo::AlignRight = 2;
const unsigned shortFoo::AlignTop = 1;
const unsigned shortFoo::AlignBottom = 2;
I fail to see a reason why that's a violation of the One Definition Rule (ORD),
but ASAN fails with:
==9056==ERROR: AddressSanitizer: odr-violation (0x04b4dbc0):
[1] size=2 'AlignRight' foo.cc:23:22
[2] size=2 'AlignBottom' foo.cc:25:22
These globals were registered at these points:
[1]:
#0 0x4daa56 in __asan_register_globals
../../../../libsanitizer/asan/asan_globals.cc:217
#1 0x4b0c6ac in __libc_csu_init (foo+0x4b0c6ac)
#2 0x3761c1ecef in __libc_start_main (/lib64/libc.so.6+0x3761c1ecef)
[Bug sanitizer/64330] [ASAN] Bogus AddressSanitizer: odr-violation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64330 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Looks like a dup of PR63888.
[Bug rtl-optimization/64331] New: regcprop propagates registers noted as REG_DEAD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64331
Bug ID: 64331
Summary: regcprop propagates registers noted as REG_DEAD
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: senthil_kumar.selvaraj at atmel dot com
Created attachment 34290
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34290action=edit
Source file
For the AVR target, compiling the attached source file with -O1 results in code
like this
snip
or r20,r21
or r20,r22
or r20,r23
breq .L1
ldd r24,Z+4
ldd r25,Z+5
ldd r26,Z+6
ldd r27,Z+7
cp r20,r24
cpc r21,r25
cpc r22,r26
cpc r23,r27
/snip
Register R20 was clobbered first up, but is used to compare against R24.
fdump-rtl-all-raw showed that cprop_hardreg is the culprit. In pass *.ce3
snip
(insn 7 4 8 2 (set (reg:SI 16 r16 [orig:43 D.1617 ] [43])
(reg/v:SI 20 r20 [orig:46 x ] [46])) reduced.c:12 94 {*movsi}
(nil))
...
(insn 13 12 14 3 (parallel [
(set (cc0)
(compare (reg/v:SI 20 r20 [orig:46 x ] [46])
(const_int 0 [0])))
(clobber (scratch:QI))
]) reduced.c:17 413 {*cmpsi}
(expr_list:REG_DEAD (reg/v:SI 20 r20 [orig:46 x ] [46])
(nil)))
...
(insn 17 16 18 4 (parallel [
(set (cc0)
(compare (reg:SI 16 r16 [orig:43 D.1617 ] [43])
(reg:SI 24 r24 [orig:48 t_3(D)-b ] [48])))
(clobber (scratch:QI))
]) reduced.c:20 413 {*cmpsi}
(expr_list:REG_DEAD (reg:SI 24 r24 [orig:48 t_3(D)-b ] [48])
(expr_list:REG_DEAD (reg:SI 16 r16 [orig:43 D.1617 ] [43])
(nil
/snip
into
snip
;; Function foo (foo, funcdef_no=0, decl_uid=1599, cgraph_uid=0,
symbol_order=0)
insn 17: replaced reg 16 with 20
rescanning insn with uid = 17.
..
(insn 17 16 18 4 (parallel [
(set (cc0)
(compare (reg:SI 20 r20 [orig:43 D.1617 ] [43])
(reg:SI 24 r24 [orig:48 t_3(D)-b ] [48])))
(clobber (scratch:QI))
]) reduced.c:20 413 {*cmpsi}
(expr_list:REG_DEAD (reg:SI 24 r24 [orig:48 t_3(D)-b ] [48])
(expr_list:REG_DEAD (reg:SI 16 r16 [orig:43 D.1617 ] [43])
(nil
/snip
The AVR backend, on seeing that reg:SI r20 is dead in insn 13, emits code that
clobbers r20, and this breaks the read in insn 17.
[Bug rtl-optimization/64331] regcprop propagates registers noted as REG_DEAD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64331 --- Comment #1 from Senthil Kumar Selvaraj senthil_kumar.selvaraj at atmel dot com --- Created attachment 34291 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34291action=edit Assembly
[Bug target/61296] Excessive alignment in ix86_data_alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296
--- Comment #8 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to Jakub Jelinek from comment #7)
See discussions when I've added DATA_ABI_ALIGNMENT.
DATA_ABI_ALIGNMENT was added for PR 56564:
/* Similar to DATA_ALIGNMENT, but for the cases where the ABI mandates
some alignment increase, instead of optimization only purposes. E.g.
AMD x86-64 psABI says that variables with array type larger than 15 bytes
must be aligned to 16 byte boundaries.
If this macro is not defined, then ALIGN is used. */
#define DATA_ABI_ALIGNMENT(TYPE, ALIGN) \
ix86_data_alignment ((TYPE), (ALIGN), false)
and ix86_data_alignment was changed by
https://gcc.gnu.org/ml/gcc-patches/2014-01/msg01086.html
There is a discussion we should always align to DATA_ABI_ALIGNMENT:
https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01435.html
My question was Should we limit DATA_ALIGNMENT to MAX (ABI alignment,
natural alignment)?
GCC will only use the excessive alignment with locally defined data,
which has no psABI implications:
[hjl@gnu-6 pr61296]$ cat z.c
struct foo
{
char i[128];
};
struct foo x = { 1 };
struct foo y = { 1 };
struct foo z = { 1 };
void
bar ()
{
int i;
for (i = 0; i sizeof (x.i); i++)
x.i[i] = y.i[i] + z.i[i];
}
[hjl@gnu-6 pr61296]$ /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O3 -mavx2 -S z.c -fPIC
[hjl@gnu-6 pr61296]$ cat z.s
.filez.c
.section.text.unlikely,ax,@progbits
.LCOLDB0:
.text
.LHOTB0:
.p2align 4,,15
.globlbar
.typebar, @function
bar:
.LFB0:
.cfi_startproc
leaq8(%rsp), %r10
.cfi_def_cfa 10, 0
movqy@GOTPCREL(%rip), %rdi
andq$-32, %rsp
pushq-8(%r10)
pushq%rbp
.cfi_escape 0x10,0x6,0x2,0x76,0
movq%rsp, %rbp
pushq%r12
pushq%r10
.cfi_escape 0xf,0x3,0x76,0x70,0x6
.cfi_escape 0x10,0xc,0x2,0x76,0x78
movq%rdi, %r10
pushq%rbx
.cfi_escape 0x10,0x3,0x2,0x76,0x68
negq%r10
andl$31, %r10d
je.L7
movqx@GOTPCREL(%rip), %r8
movqz@GOTPCREL(%rip), %r9
movl%r10d, %esi
xorl%eax, %eax
xorl%edx, %edx
movl$128, %r11d
.p2align 4,,10
.p2align 3
.L3:
movzbl(%rdi,%rax), %ecx
addl$1, %edx
addb(%r9,%rax), %cl
movb%cl, (%r8,%rax)
movl%r11d, %ecx
addq$1, %rax
subl%edx, %ecx
cmpl%r10d, %edx
jne.L3
movl%edx, %eax
movl%ecx, %ebx
movl$96, %r11d
movl$3, %r12d
.L2:
leaq(%r9,%rax), %rdx
leaq(%rdi,%rax), %r10
addq%r8, %rax
cmpl$4, %r12d
vmovdqu(%rdx), %xmm0
vinserti128$0x1, 16(%rdx), %ymm0, %ymm0
vpaddb(%r10), %ymm0, %ymm0
vmovups%xmm0, (%rax)
vextracti128$0x1, %ymm0, 16(%rax)
vmovdqu32(%rdx), %xmm0
vinserti128$0x1, 48(%rdx), %ymm0, %ymm0
vpaddb32(%r10), %ymm0, %ymm0
vmovups%xmm0, 32(%rax)
vextracti128$0x1, %ymm0, 48(%rax)
vmovdqu64(%rdx), %xmm0
vinserti128$0x1, 80(%rdx), %ymm0, %ymm0
vpaddb64(%r10), %ymm0, %ymm0
vmovups%xmm0, 64(%rax)
vextracti128$0x1, %ymm0, 80(%rax)
jne.L4
vmovdqu96(%rdx), %xmm0
vinserti128$0x1, 112(%rdx), %ymm0, %ymm0
vpaddb96(%r10), %ymm0, %ymm0
vmovups%xmm0, 96(%rax)
vextracti128$0x1, %ymm0, 112(%rax)
.L4:
leal(%r11,%rsi), %eax
subl%r11d, %ecx
cmpl%r11d, %ebx
leal(%rax,%rcx), %esi
je.L10
.p2align 4,,10
.p2align 3
.L5:
movslq%eax, %rdx
addl$1, %eax
movzbl(%r9,%rdx), %ecx
addb(%rdi,%rdx), %cl
cmpl%esi, %eax
movb%cl, (%r8,%rdx)
jne.L5
.L10:
vzeroupper
popq%rbx
popq%r10
.cfi_remember_state
.cfi_def_cfa 10, 0
popq%r12
popq%rbp
leaq-8(%r10), %rsp
.cfi_def_cfa 7, 8
ret
.p2align 4,,10
.p2align 3
.L7:
.cfi_restore_state
movl$128, %r11d
movl$4, %r12d
movl$128, %ebx
xorl%eax, %eax
movl$128, %ecx
xorl%esi, %esi
movqx@GOTPCREL(%rip), %r8
movqz@GOTPCREL(%rip), %r9
jmp.L2
.cfi_endproc
.LFE0:
.sizebar, .-bar
.section.text.unlikely
.LCOLDE0:
.text
.LHOTE0:
.globlz
.data
.align 64
.typez, @object
.sizez, 128
z:
.byte1
.zero127
.globly
.align 64
.typey, @object
.sizey, 128
y:
.byte1
.zero127
.globlx
.align 64
.typex, @object
.sizex, 128
x:
.byte1
.zero127
.identGCC: (GNU) 5.0.0 20141205 (experimental)
.section.note.GNU-stack,,@progbits
Do you have a testcase to show decreasing DATA_ALIGNMENT would break
backwards compatibility with older gcc versions?
Our data show that
[Bug target/61296] Excessive alignment in ix86_data_alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to H.J. Lu from comment #8) Do you have a testcase to show decreasing DATA_ALIGNMENT would break backwards compatibility with older gcc versions? Older GCC versions used DATA_ALIGNMENT (what is now DATA_ABI_ALIGNMENT) on MEM_ALIGN etc., and gradually more and more optimizations relied on it, even when the data was defined in some other compilation unit or was comdat or could be interposed. See e.g. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56564#c9
[Bug target/61296] Excessive alignment in ix86_data_alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296 --- Comment #10 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Jakub Jelinek from comment #9) (In reply to H.J. Lu from comment #8) Do you have a testcase to show decreasing DATA_ALIGNMENT would break backwards compatibility with older gcc versions? Older GCC versions used DATA_ALIGNMENT (what is now DATA_ABI_ALIGNMENT) on MEM_ALIGN etc., and gradually more and more optimizations relied on it, even when the data was defined in some other compilation unit or was comdat or could be interposed. See e.g. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56564#c9 I still don't see that limit DATA_ALIGNMENT to MAX (ABI alignment, natural alignment) will cause additional ABI problems which don't exist today.
[Bug sanitizer/64330] [ASAN] Bogus AddressSanitizer: odr-violation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64330
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
||marxin at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org ---
It is related, but in this case it looks like IPA-ICF bug to me, unless the C++
standard allows what G++ does since r216305.
struct S
{
static const unsigned short a;
static const unsigned short b;
static const unsigned short c;
};
#ifdef A
const unsigned short S::a = 2;
const unsigned short S::b = 1;
const unsigned short S::c = 2;
#endif
#ifdef B
int
main ()
{
if (S::a == S::c)
__builtin_abort ();
}
#endif
With g++ -O2 -o test test.C -DA -DB it succeeds, but with
g++ -O2 -c test.C -o testa.o -DA; g++ -O2 -o test -DB test.C testa.o
it fails. Works with -fno-ipa-icf. Without looking at the IPA-ICF patch, just
looking at what it generates, it sounds like it is checking TREE_ADDRESSABLE on
the variables and if they aren't addressable and are const, merges them. That
is fine if you are in LTO and can see all TUs that could ever access those
vars, but if you can't inspect all the TUs that could take the address of it,
as in the second case, but it could very well be even LTO compiled binary that
links against a shared library that references those symbols, I think you can't
merge the variables (unless -fmerge-all-constants).
[Bug middle-end/63568] Missed optimization (a ~mask) | (b mask) = a ^ ((a ^ b) mask)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63568
--- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org ---
FWIW, I used this to check the whether the transformation is correct:
int
main ()
{
for (int i = -1000; i 1000; ++i)
for (int a = -1000; a 1000; ++a)
for (int b = -1000; b 1000; ++b)
{
int x = (a ~i) | (b i);
int y = a ^ ((a ^ b) i);
//__builtin_printf (%d %d\n, x, y);
if (x != y)
__builtin_abort ();
}
}
[Bug target/61296] Excessive alignment in ix86_data_alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296 --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org --- If you hit the assumption beyond what ABI mandates on some public symbol issue in some older GCC version, then sure, if you have that public symbol defined by ICC, it will misbehave. But, if it is compiled with current GCC without your proposed changes, it will work fine, newer GCCs don't assume anything beyond ABI mandates alignments, unless they control the definition and uses bind locally to it, but still align as optimization as much or more as older GCC used to align. With your proposed changes that would be no longer true. What is so hard to understand on it?
[Bug middle-end/63568] Missed optimization (a ~mask) | (b mask) = a ^ ((a ^ b) mask)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63568 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 --- Not necessarily 3 vs. 4 ops, many targets have andnot instruction and can do it also in 3 ops.
[Bug target/61296] Excessive alignment in ix86_data_alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296 --- Comment #12 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Jakub Jelinek from comment #11) If you hit the assumption beyond what ABI mandates on some public symbol issue in some older GCC version, then sure, if you have that public symbol defined by ICC, it will misbehave. But, if it is compiled with current GCC without your proposed changes, it will work fine, newer GCCs don't assume anything beyond ABI mandates alignments, unless they control the definition and uses bind locally to it, but still align as optimization as much or more as older GCC used to align. With your proposed changes that would be no longer true. What is so hard to understand on it? What is the maximum alignment the older GCCs may assume?
[Bug target/61296] Excessive alignment in ix86_data_alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296 --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org --- Read the sources? It really depends on many factors.
[Bug tree-optimization/64330] [5 Regression] IPA-ICF merges const exported vars that could be addressable in other TUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64330
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-12-16
Component|sanitizer |tree-optimization
Target Milestone|--- |5.0
Summary|[ASAN] Bogus|[5 Regression] IPA-ICF
|AddressSanitizer: |merges const exported vars
|odr-violation |that could be addressable
||in other TUs
Ever confirmed|0 |1
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org ---
sem_variable *
sem_variable::parse (varpool_node *node, bitmap_obstack *stack)
{
tree decl = node-decl;
bool readonly = TYPE_P (decl) ? TYPE_READONLY (decl) : TREE_READONLY (decl);
bool can_handle = readonly (DECL_VIRTUAL_P (decl)
|| !TREE_ADDRESSABLE (decl));
So it indeed doesn't consider the case when the variable is accessible by other
TUs where the variable could be addressable in them.
[Bug middle-end/63568] Missed optimization (a ~mask) | (b mask) = a ^ ((a ^ b) mask)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63568 --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- True. E.g. on my x86_64 i7 Nehalem I see (using ./cc1 -quiet -O2 qq.c -mbmi) andn%edi, %edx, %edi andl%edx, %esi movl%edi, %eax orl %esi, %eax ret for return (a ~m) | (b m); and xorl%edi, %esi movl%edi, %eax andl%esi, %edx xorl%edx, %eax ret for return a ^ ((a ^ b) m);
[Bug middle-end/63568] Missed optimization (a ~mask) | (b mask) = a ^ ((a ^ b) mask)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63568 --- Comment #6 from rguenther at suse dot de rguenther at suse dot de --- On Tue, 16 Dec 2014, mpolacek at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63568 --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- True. E.g. on my x86_64 i7 Nehalem I see (using ./cc1 -quiet -O2 qq.c -mbmi) andn%edi, %edx, %edi andl%edx, %esi movl%edi, %eax orl %esi, %eax ret for return (a ~m) | (b m); and xorl%edi, %esi movl%edi, %eax andl%esi, %edx xorl%edx, %eax ret for return a ^ ((a ^ b) m); The former is also better for instruction level parallelism - but that just asks for a clever enough expander / combiner that can generate that from the latter. I think on GIMPLE we want to canoncalize to the variant with less (gimple) operations. single-use restrictions may apply (with the lack of a global unified combine / CSE phase)
[Bug target/64331] regcprop propagates registers noted as REG_DEAD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64331 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||avr Component|rtl-optimization|target --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Sounds like a target bug.
[Bug rtl-optimization/64291] [5 Regression] Miscompile t-div in GMP's testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64291 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-*-*, i?86-*-* Priority|P3 |P1 CC||vmakarov at gcc dot gnu.org
[Bug testsuite/64328] addr_equal-1.c fails execution.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64328 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Component|tree-optimization |testsuite --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- I think they can be resolved to the same declaration and an alias to it. Thus the testcase should be guarded with nopic.
[Bug fortran/63473] [4.9/5 Regression] Memory leak with ALLOCATABLE, INTENT(OUT) dummy arguments.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63473 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-16 CC||janus at gcc dot gnu.org Version|4.8.2 |4.9.1 Summary|Memory leak with|[4.9/5 Regression] Memory |ALLOCATABLE, INTENT(OUT)|leak with ALLOCATABLE, |dummy arguments.|INTENT(OUT) dummy ||arguments. Ever confirmed|0 |1 --- Comment #2 from janus at gcc dot gnu.org --- Confirmed. ==13675== 800 bytes in 40 blocks are definitely lost in loss record 2 of 3 ==13675==at 0x4A069EE: malloc (vg_replace_malloc.c:270) ==13675==by 0x400CF0: __testmodule_MOD_create_mytype (test_allocarg.f90:15) ==13675==by 0x400B74: __testmodule_MOD_allocate_mytype (test_allocarg.f90:24) ==13675==by 0x400E47: MAIN__ (test_allocarg.f90:40) ==13675==by 0x400E94: main (test_allocarg.f90:33) This one I see with all gfortran versions I tried (4.4.7, 4.6.4, 4.7.4, 4.8.3, 4.9.1, trunk). ==13675== 1,360 (960 direct, 400 indirect) bytes in 1 blocks are definitely lost in loss record 3 of 3 ==13675==at 0x4A069EE: malloc (vg_replace_malloc.c:270) ==13675==by 0x4009DA: __testmodule_MOD_allocate_mytype (test_allocarg.f90:22) ==13675==by 0x400E47: MAIN__ (test_allocarg.f90:40) ==13675==by 0x400E94: main (test_allocarg.f90:33) This one only seems to occur with 4.9 and trunk, i.e. it's a regression.
[Bug other/64278] [5 Regression] /sreal.c:254:22: error: call of overloaded 'abs(const int64_t)' is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64278 --- Comment #2 from Martin Liška marxin at gcc dot gnu.org --- Author: marxin Date: Tue Dec 16 14:55:29 2014 New Revision: 218779 URL: https://gcc.gnu.org/viewcvs?rev=218779root=gccview=rev Log: Fix for PR ipa/64278 * sreal.c (sreal::operator*): Replace std::abs with absu_hwi. Modified: trunk/gcc/ChangeLog trunk/gcc/sreal.c
[Bug other/64278] [5 Regression] /sreal.c:254:22: error: call of overloaded 'abs(const int64_t)' is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64278 Martin Liška marxin at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Liška marxin at gcc dot gnu.org --- Resolved.
[Bug target/64240] [5.0 Regression][AArch64] SMS-3.c causes runtime exception(segfault).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64240 --- Comment #6 from fyang at gcc dot gnu.org --- Author: fyang Date: Tue Dec 16 14:58:03 2014 New Revision: 218780 URL: https://gcc.gnu.org/viewcvs?rev=218780root=gccview=rev Log: + PR rtl-optimization/64240 + * ddg.c (mark_mem_use): Check *iter instead of *x. Added: trunk/gcc/testsuite/gcc.dg/sms-12.c Modified: trunk/gcc/ChangeLog trunk/gcc/ddg.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/63473] [4.9/5 Regression] Memory leak with ALLOCATABLE, INTENT(OUT) dummy arguments.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63473 --- Comment #3 from janus at gcc dot gnu.org --- Here is a slightly compactified test case: program testprogram implicit none type :: mytype_type integer, allocatable :: i(:) end type integer :: n type(mytype_type), allocatable :: array(:) do n = 1, 2 print *, allocated(array) call allocate_mytype(array) end do contains subroutine allocate_mytype(array) type(mytype_type), allocatable, intent(out) :: array(:) integer :: i allocate(array(10)) do i = 1, 10 allocate(array(i)%i(5)) array(i)%i = 0 end do end subroutine end With 4.9.1, valgrind shows: ==31043== HEAP SUMMARY: ==31043== in use at exit: 880 bytes in 21 blocks ==31043== total heap usage: 43 allocs, 22 frees, 13,201 bytes allocated ==31043== ==31043== 200 bytes in 10 blocks are definitely lost in loss record 2 of 3 ==31043==at 0x4C2ABA0: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==31043==by 0x400BC6: allocate_mytype.2336 (test.f90:21) ==31043==by 0x400EF3: MAIN__ (test.f90:11) ==31043==by 0x400F40: main (test.f90:9) ==31043== ==31043== 680 (480 direct, 200 indirect) bytes in 1 blocks are definitely lost in loss record 3 of 3 ==31043==at 0x4C2ABA0: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==31043==by 0x4009A1: allocate_mytype.2336 (test.f90:19) ==31043==by 0x400EF3: MAIN__ (test.f90:11) ==31043==by 0x400F40: main (test.f90:9) ==31043== ==31043== LEAK SUMMARY: ==31043==definitely lost: 680 bytes in 11 blocks ==31043==indirectly lost: 200 bytes in 10 blocks ==31043== possibly lost: 0 bytes in 0 blocks ==31043==still reachable: 0 bytes in 0 blocks ==31043== suppressed: 0 bytes in 0 blocks The first message (200 bytes) occurs with all gfortran versions I tried (and only in the second loop execution). The second message (680 bytes) occurs only with 4.9 upwards (and already in the first loop execution).
[Bug fortran/63473] [4.9/5 Regression] Memory leak with ALLOCATABLE, INTENT(OUT) dummy arguments.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63473 --- Comment #4 from janus at gcc dot gnu.org --- (In reply to janus from comment #3) The second message (680 bytes) occurs only with 4.9 upwards (and already in the first loop execution). Actually I think this is not a real regression, but rather a change in behavior which is in line with the Fortran 2008 standard (variables in the main program automatically get the SAVE attribute, and thus are not auto-deallocated). One can get rid of that valgrind message, by explicitly deallocating the array at the end of the main program, so that the test case becomes: program testprogram implicit none type :: mytype_type integer, allocatable :: i(:) end type integer :: n type(mytype_type), allocatable :: array(:) do n = 1, 2 print *, allocated(array) call allocate_mytype(array) end do deallocate(array) contains subroutine allocate_mytype(array) type(mytype_type), allocatable, intent(out) :: array(:) integer :: i allocate(array(10)) do i = 1, 10 allocate(array(i)%i(5)) array(i)%i = 0 end do end subroutine end With this version, one only gets: ==31267== 200 bytes in 10 blocks are definitely lost in loss record 1 of 1 ==31267==at 0x4C2ABA0: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==31267==by 0x400BC6: allocate_mytype.2336 (test.f90:23) ==31267==by 0x400EF6: MAIN__ (test.f90:11) ==31267==by 0x401008: main (test.f90:14)
[Bug tree-optimization/64319] add alias runtime check to remove load after load redundancy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64319 --- Comment #2 from Brian Grayson b.grayson at samsung dot com --- alignd() in m88ksim from SPECint95 is a poster child for this kind of optimization -- it receives several pointers to portions of FP representations, and then operates on them via code like this: ... *amantlo = 1; *amantlo |= *amanthi 31; *amanthi = 1; ... In this case, there may actually be a code-space reduction(!) with dynamic disambiguation, because gcc has to insert so many redundant loads and stores in the general case that are not needed in either of the two forks. That may make a handy stand-alone real-world testcase.
[Bug fortran/63473] Memory leak with ALLOCATABLE, INTENT(OUT) dummy arguments.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63473
janus at gcc dot gnu.org changed:
What|Removed |Added
Summary|[4.9/5 Regression] Memory |Memory leak with
|leak with ALLOCATABLE, |ALLOCATABLE, INTENT(OUT)
|INTENT(OUT) dummy |dummy arguments.
|arguments. |
--- Comment #5 from janus at gcc dot gnu.org ---
-fdump-tree-original shows the following:
if (array.data != 0B)
{
__builtin_free ((void *) array.data);
}
array.data = 0B;
allocate_mytype (array);
So: Before the call to 'allocate_mytype', the array itself is being
auto-deallocated, but its components are not!
[Bug fortran/64321] -ffixed-line-length-none doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64321 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #1 from janus at gcc dot gnu.org --- It actually works for me, at least when putting the test case into a .f file. Is it possibly that your file has an f90 extension (meaning it's actually free format)? Would it be a bad idea to introduce a flag like -fline-length-none, which sets the line length both for fixed and free format?
[Bug target/61296] Excessive alignment in ix86_data_alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
CC||kirill.yukhin at intel dot com
--- Comment #14 from H.J. Lu hjl.tools at gmail dot com ---
I got
[hjl@gnu-6 pr61296]$ cat a.c
struct foo
{
char i[128];
};
struct foo x = { 1 };
[hjl@gnu-6 pr61296]$ make a.s
/export/build/gnu/gcc-misc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-misc/build-x86_64-linux/gcc/ -O3 -mavx2 -S a.c
[hjl@gnu-6 pr61296]$ cat a.s
.filea.c
.globlx
.data
.align 64
.typex, @object
.sizex, 128
x:
.byte1
.zero127
.identGCC: (GNU) 5.0.0 20141216 (experimental)
.section.note.GNU-stack,,@progbits
[hjl@gnu-6 pr61296]$
Which older GCC expects 64-byte alignment here? We should limit
DATA_ALIGNMENT to the maximum alignment actually expected by the
older GCC, which I believe is 32 byte, and have an option to limit
DATA_ALIGNMENT to MAX (ABI alignment, natural alignment).
[Bug c++/64332] New: gcc/g++ handles system_header differently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64332 Bug ID: 64332 Summary: gcc/g++ handles system_header differently Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: a3at.mail at gmail dot com Created attachment 34292 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34292action=edit warning-constructor-attribute-ignored.tgz Digging through one or compilation errors, after doing this: #define __constructor __attribute__((constructor)) I turned out that gcc/g++ have different behaviours for system_header pragma. Here is a simple example (also archived in attach): $ head *.[ch] == c.h == #define __constructor __attribute__((constructor)) == c-impl.h == #pragma GCC system_header typedef void (*__cb_type)(void *); int foo(__cb_type __constructor); == main.c == #include c.h #include c-impl.h $ gcc -c main.c $ gcc -Wall -Wextra -Wpedantic -Wattributes -c main.c $ g++ -c main.c In file included from main.c:1:0: c.h:1:50: warning: ‘constructor’ attribute ignored [-Wattributes] #define __constructor __attribute__((constructor)) $ clang++-3.5 -c main.c clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated $ clang-3.5 -c main.c $ g++ --version g++ (Debian 4.9.1-16) 4.9.1 Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Is this desired behavior?
[Bug rtl-optimization/64286] Redundant extend removal ignores vector element type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64286 --- Comment #1 from Igor Zamyatin izamyatin at gmail dot com --- Perhaps something like below to restrict ree for such cases? diff --git a/gcc/ree.c b/gcc/ree.c index 3376901..92370ea 100644 --- a/gcc/ree.c +++ b/gcc/ree.c @@ -1004,6 +1004,11 @@ add_removable_extension (const_rtx expr, rtx_insn *insn, struct df_link *defs, *def; ext_cand *cand; + if (!SCALAR_INT_MODE_P (GET_MODE (dest)) + (GET_MODE_UNIT_PRECISION (mode) != + GET_MODE_UNIT_PRECISION (GET_MODE (XEXP (src, 0) +return; + /* First, make sure we can get all the reaching definitions. */ defs = get_defs (insn, XEXP (src, 0), NULL); if (!defs)
[Bug fortran/64321] -ffixed-line-length-none doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64321 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org --- Close as WORKSFORME. Yes, I seemingly had a .f90 file without -ffixed-form, when testing https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01289.html - and while busy checking some other issues, I didn't closely inspect this patch. I do not see a real need for a unified option.
[Bug target/64331] regcprop propagates registers noted as REG_DEAD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64331 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-16 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Right, RTL passes aren't required to maintain REG_DEAD/REG_UNUSED notes, it's the job of the DF framework. And this is not done automatically, the consumers of the notes must request it by means of df_note_add_problem prior to calling the DF analyzer.
[Bug c++/61189] ICE with __builtin_return_address() in noexcept lambda on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61189 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-16 Ever confirmed|0 |1 --- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org --- Issue is related to the assert at line 9964 in config/i386/i386.c in ix86_compute_frame_layout: 'gcc_assert (preferred_alignment = stack_alignment_needed);'. The preferred_alignment is 16, but the stack_alignment_needed is just 4. The preferred_alignment is by default for all x86/x64 targets always PREFERRED_STACK_BOUNDARY_DEFAULT (means 128 bit=16 bytes). So crtl-stack_alignment_needed is 32, and crtl-preferred_stack_boundary is 128. A work-a-round is to use -mpreferred-stack-boundary=2 option. This prevents that check fails. So question is: Where stack_alignment_needed is set to something less then preferred_stack_boundary
[Bug fortran/64244] [4.8/4.9/5 Regression] ICE at class.c:236 when using non_overridable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64244 --- Comment #9 from Ondřej Čertík ondrej.certik at gmail dot com --- Janus, thanks a lot for fixing this! Yes, it's part of a large code base. I'll try the trunk soon.
[Bug c++/64332] gcc/g++ handles system_header differently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64332 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- I don't think it is system header which is being handled differently, rather I think it is warning for attribute is being handled differently.
[Bug fortran/64244] [4.8/4.9/5 Regression] ICE at class.c:236 when using non_overridable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64244 --- Comment #10 from janus at gcc dot gnu.org --- (In reply to Ondřej Čertík from comment #9) Janus, thanks a lot for fixing this! You're welcome! Yes, it's part of a large code base. I'll try the trunk soon. That would be great. Since this bug is a regression, I plan to backport the fix to the 4.8 and 4.9 branches. But before that it would be good to make sure that no further problems appear. I think the NON_OVERRIDABLE attribute is not incredibly well-tested at this point.
[Bug c++/61189] ICE with __builtin_return_address() in noexcept lambda on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61189 --- Comment #3 from lh_mouse lh_mouse at 126 dot com --- Thanks Kai. It seems to be exactly the same reason that causes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62152. Maybe we should merge them?
[Bug c++/64332] gcc/g++ handles system_header differently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64332 --- Comment #2 from Azat a3at.mail at gmail dot com --- On Tue, Dec 16, 2014 at 04:46:28PM +, pinskia at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64332 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- I don't think it is system header which is being handled differently, rather I think it is warning for attribute is being handled differently. Maybe... I didn't check this.
[Bug c++/61189] ICE with __builtin_return_address() in noexcept lambda on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61189 --- Comment #4 from Kai Tietz ktietz at gcc dot gnu.org --- *** Bug 62152 has been marked as a duplicate of this bug. ***
[Bug c++/62152] ICE caused by using __builtin_ia32_pause() inside C++11 noexcept functions on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62152 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktietz at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Kai Tietz ktietz at gcc dot gnu.org --- Duplicate *** This bug has been marked as a duplicate of bug 61189 ***
[Bug c++/64332] gcc/g++ handles system_header differently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64332
--- Comment #3 from Azat a3at.mail at gmail dot com ---
On Tue, Dec 16, 2014 at 07:50:48PM +0300, Azat Khuzhin wrote:
--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org ---
I don't think it is system header which is being handled differently,
rather I
think it is warning for attribute is being handled differently.
Maybe... I didn't check this.
I've checked this and you are right:
$ head main.c c-impl.h # the same is in attach
== main.c ==
#include c-impl.h
== c-impl.h ==
#pragma GCC system_header
static inline int foo(int foo)
{
}
$ gcc -Wall -Wextra -Wpedantic -Wattributes -c main.c
$ g++ -Wall -Wextra -Wpedantic -Wattributes -c main.c
Now drop system_header:
$ head main.c c-impl.h
== main.c ==
#include c-impl.h
== c-impl.h ==
static inline int foo(int foo)
{
}
$ gcc -Wall -Wextra -Wpedantic -Wattributes -c main.c
In file included from main.c:1:0:
c-impl.h: In function ‘foo’:
c-impl.h:3:1: warning: no return statement in function returning non-void
[-Wreturn-type]
}
^
c-impl.h:1:27: warning: unused parameter ‘foo’ [-Wunused-parameter]
static inline int foo(int foo)
^
$ g++ -Wall -Wextra -Wpedantic -Wattributes -c main.c
In file included from main.c:1:0:
c-impl.h: In function ‘int foo(int)’:
c-impl.h:3:1: warning: no return statement in function returning non-void
[-Wreturn-type]
}
^
c-impl.h: At global scope:
c-impl.h:1:27: warning: unused parameter ‘foo’ [-Wunused-parameter]
static inline int foo(int foo)
^
[Bug c/64332] wrong location for Wattributes warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64332 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-16 CC||manu at gcc dot gnu.org Component|c++ |c Summary|gcc/g++ handles |wrong location for |system_header differently |Wattributes warning Ever confirmed|0 |1 --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org --- The difference that you see is because of macro expansion and bad location info in the C FE. This testcase makes it clear: $ cat test.c #define __constructor __attribute__((constructor)) typedef void (*__cb_type)(void *); int foo(__cb_type __constructor); $ cc1 -Wattributes test.c test.c:3:1: warning: ‘constructor’ attribute ignored [-Wattributes] int foo(__cb_type __constructor); ^ $ cc1plus -Wattributes test.c test.c:1:50: warning: ‘constructor’ attribute ignored [-Wattributes] #define __constructor __attribute__((constructor)) ^ test.c:3:19: note: in expansion of macro ‘__constructor’ int foo(__cb_type __constructor); ^ The C FE does not point to __constructor (3:1 vs 3:19), thus it doesn't realize this comes from a macro expansion, thus (in your testcase) the system_header is applied. The C++ FE sees that the attribute actually appears in 1:50 and not 3:19, thus in your testcase the pragma system_header does not apply. Whether the correct behavior is that the system_header applies to the definition or to the expansion location, I am not sure. However, the bad location of the C FE is clearly a bug.
[Bug c/64332] wrong location for Wattributes warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64332 --- Comment #5 from Azat a3at.mail at gmail dot com --- On Tue, Dec 16, 2014 at 05:16:41PM +, manu at gcc dot gnu.org wrote: The C FE does not point to __constructor (3:1 vs 3:19), thus it doesn't realize this comes from a macro expansion, thus (in your testcase) the system_header is applied. The C++ FE sees that the attribute actually appears in 1:50 and not 3:19, thus in your testcase the pragma system_header does not apply. Hm.. good to know, thanks for pointing me out! Whether the correct behavior is that the system_header applies to the definition or to the expansion location, I am not sure. However, the bad location of the C FE is clearly a bug. Maybe gcc will behave like clang in this case?
[Bug fortran/64244] [4.8/4.9/5 Regression] ICE at class.c:236 when using non_overridable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64244 --- Comment #11 from Ondřej Čertík ondrej.certik at gmail dot com --- On Tue, Dec 16, 2014 at 9:47 AM, janus at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64244 --- Comment #10 from janus at gcc dot gnu.org --- (In reply to Ondřej Čertík from comment #9) Janus, thanks a lot for fixing this! You're welcome! Yes, it's part of a large code base. I'll try the trunk soon. That would be great. Since this bug is a regression, I plan to backport the fix to the 4.8 and 4.9 branches. But before that it would be good to make sure that no further problems appear. I think the NON_OVERRIDABLE attribute is not incredibly well-tested at this point. I can compile 4.9.2 from source without problems, but when I follow the same procedure with the latest trunk (I used: https://github.com/gcc-mirror/gcc), I get: https://gist.github.com/certik/bbb96383e540efc8d6a3 And the part of config.log says: https://gist.github.com/certik/a308dbc6a26d12888ee6 i.e. the relevant error seems to be: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found So my system (RHEL6) libstdc++ library might be incompatible with the trunk, but I don't see why gcc couldn't compile. Any ideas how to fix this?
[Bug ipa/63851] [5 Regression] ipa-icf miscompiles gfortran.dg/assumed_rank_(8|9|10).f90 at -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63851 --- Comment #5 from Martin Liška marxin at gcc dot gnu.org --- Yes, IPA ICF should respect 'restrict' attribute. May I ask you to rerun test suite with applied: diff --git a/gcc/ipa-icf-gimple.c b/gcc/ipa-icf-gimple.c index ec0290a..98f38ee 100644 --- a/gcc/ipa-icf-gimple.c +++ b/gcc/ipa-icf-gimple.c @@ -185,6 +185,9 @@ bool func_checker::compatible_types_p (tree t1, tree t2, if (TREE_CODE (t1) != TREE_CODE (t2)) return return_false_with_msg (different tree types); + if (TYPE_RESTRICT (t1) != TYPE_RESTRICT (t2)) +return return_false_with_msg (restrict flags are different); + if (!types_compatible_p (t1, t2)) return return_false_with_msg (types are not compatible); Thanks, Martin
[Bug sanitizer/61591] Undefined behavior sanitizer does not catch builtin_unreachable's from impossible devirtualization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61591 --- Comment #10 from Martin Jambor jamborm at gcc dot gnu.org --- Honza, given what you wrote in https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01033.html do you want to take over this bug?
[Bug c/61280] GCC 4.8.2 suppresses -Wsign-compare caused by macro defined in system header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61280
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||manu at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
This seems fixed in GCC 5.0 since now the preprocessed output tracks the
system-header bit within macros:
# 1 test.c
# 1 built-in
# 1 command-line
# 1 test.c
# 1 test.h 1
# 2 test.h 3
# 2 test.c 2
int foo(int i, unsigned j) { return
# 2 test.c 3
((
# 2 test.c
i
# 2 test.c 3
) (
# 2 test.c
j
# 2 test.c 3
))
# 2 test.c
; }
[Bug middle-end/64313] [5 Regression] gcc.dg/torture/builtin-explog-1.c fails on bare-metal targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64313 --- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot com --- In the case of expf, if it's used or known to be available in a linked library then it can be assumed to have the required semantics (since it's reserved by ISO C90). If it's used it can also be assumed to be available (if not used, its availability depends on targetm.libc_has_function). In the case of exp10, a function exp10 can only be assumed to have the required semantics if either (a) -std=gnu* is used, so exp10 (not just __builtin_exp10) is built in, or (b) exp10 is declared in system headers (e.g. -std=c99 -D_GNU_SOURCE). Availability can be assumed if, in addition to the conditions for the semantics, (a) it is used or (b) targetm.libc_has_function says it's available (well, except that there is no relevant enum function_class value for exp10). (log10 is standard C90. exp10 would be defined by draft TS 18661-4 to be available if __STDC_WANT_IEC_60559_FUNCS_EXT__.)
[Bug c/64332] wrong location for Wattributes warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64332 --- Comment #6 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Azat from comment #5) Whether the correct behavior is that the system_header applies to the definition or to the expansion location, I am not sure. However, the bad location of the C FE is clearly a bug. Maybe gcc will behave like clang in this case? How does Clang behave? For example, what happens when you don't use system_header in your testcase? and when you use it, but also add -Wsystem-headers? What happens if the system_header #pragma is moved to c.h? Trying to guess a correct behavior from a single testcase is quite hard. Clang may work in this case, but may fail in another case.. My intuition is that whether the warning is printed or not depends on the way the macro unwinder works. We have an open bug about that already PR55252, but no one has tried to change it yet.
[Bug ipa/63851] [5 Regression] ipa-icf miscompiles gfortran.dg/assumed_rank_(8|9|10).f90 at -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63851 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- Yes, IPA ICF should respect 'restrict' attribute. May I ask you to rerun test suite with applied: My machine is busy regtesting 4.8.4, but a quick test shows that your patch indeed fixes this PR. More testing tonight. Thanks for the fix.
[Bug go/61322] gccgo: spurious incompatible type for field 2 in struct construction error [GoSmith]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61322 Chris Manghane cmang at google dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Chris Manghane cmang at google dot com --- (In reply to Chris Manghane from comment #1) I'm unable to reproduce this on gcc version 5.0.0 20141210 (experimental) (GCC).
[Bug go/61316] gccgo: spurious incompatible types in assignment error [GoSmith]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61316 Chris Manghane cmang at google dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Chris Manghane cmang at google dot com --- Fixed.
[Bug tree-optimization/64330] [5 Regression] IPA-ICF merges const exported vars that could be addressable in other TUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64330 --- Comment #4 from Kostya Serebryany kcc at gcc dot gnu.org --- So, maybe the ODR checker in the current form is not that useless. Sorry, couldn't resist :)
[Bug tree-optimization/64330] [5 Regression] IPA-ICF merges const exported vars that could be addressable in other TUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64330 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Kostya Serebryany from comment #4) So, maybe the ODR checker in the current form is not that useless. Sorry, couldn't resist :) But it isn't really an ODR checker. Here it complains if two different symbols share the same storage. Which is fine if they aren't address taken and can't be address taken elsewhere.
[Bug middle-end/64309] if (1 (1 n)) not simplified to if (n == 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64309 --- Comment #14 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Tue Dec 16 18:29:01 2014 New Revision: 218787 URL: https://gcc.gnu.org/viewcvs?rev=218787root=gccview=rev Log: PR middle-end/64309 * match.pd: Add ((1 A) 1) != 0 - A == 0 and ((1 A) 1) == 0 - A != 0. * gcc.dg/pr64309.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr64309.c Modified: trunk/gcc/ChangeLog trunk/gcc/match.pd trunk/gcc/testsuite/ChangeLog
[Bug go/61264] gccgo: ICE in __normal_iterator [GoSmith]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61264
Chris Manghane cmang at google dot com changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2014-12-16
CC||cmang at google dot com
Assignee|ian at airs dot com|cmang at google dot com
Ever confirmed|0 |1
--- Comment #1 from Chris Manghane cmang at google dot com ---
This can be reproduced with
package main
func main() {
struct{ f int }{}.f++
}
which isn't a valid program although it is a minimal case of the provided
reproducer.
Another (valid) way to produce this would be
package main
func main() {
map[int]int{}[0]++
}
[Bug middle-end/64313] [5 Regression] gcc.dg/torture/builtin-explog-1.c fails on bare-metal targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64313 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org --- This very likely affects all newlib targets.
[Bug middle-end/64309] if (1 (1 n)) not simplified to if (n == 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64309 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #15 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed, up to some point.
[Bug go/61273] gccgo: ICE in Unsafe_type_conversion_expression::do_get_backend [GoSmith]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61273 --- Comment #1 from ian at gcc dot gnu.org ian at gcc dot gnu.org --- Author: ian Date: Tue Dec 16 18:53:46 2014 New Revision: 218788 URL: https://gcc.gnu.org/viewcvs?rev=218788root=gccview=rev Log: PR go/61273 compiler: Send statements should contextually permit composite literals. Modified: trunk/gcc/go/gofrontend/parse.cc trunk/gcc/go/gofrontend/parse.h
[Bug testsuite/64328] addr_equal-1.c fails execution.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64328 --- Comment #2 from Jan Hubicka hubicka at ucw dot cz --- Indeed, the testcase is meant to be nopic. I will check how to test for that in dg. Honza
[Bug go/61264] gccgo: ICE in __normal_iterator [GoSmith]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61264 --- Comment #2 from ian at gcc dot gnu.org ian at gcc dot gnu.org --- Author: ian Date: Tue Dec 16 19:14:54 2014 New Revision: 218789 URL: https://gcc.gnu.org/viewcvs?rev=218789root=gccview=rev Log: PR go/61264 compiler: Fix copying behavior for empty composite literals. Modified: trunk/gcc/go/gofrontend/expressions.cc
[Bug target/61296] Excessive alignment in ix86_data_alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296 --- Comment #15 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Jakub Jelinek from comment #13) Read the sources? It really depends on many factors. There are int max_align_compat = optimize_size ? BITS_PER_WORD : MIN (256, MAX_OFILE_ALIGNMENT); With -Os, we aren't compatible with the older GCC anyway.
[Bug fortran/54687] Use gcc option machinery for gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54687 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org --- Missed the PR number for the commit r218790: 2014-12-16 Tobias Burnus bur...@net-b.de PR fortran/54687 * lang.opt (fsecond-underscore, frecord-marker=8, frecord-marker=4, frealloc-lhs, freal-8-real-16, freal-8-real-10, freal-8-real-4, freal-4-real-16, freal-4-real-10, freal-4-real-8, fprotect-parens, fstack-arrays, fmax-stack-var-size=, fmax-subrecord-length=, ffrontend-optimize, ffree-line-length-, ffixed-line-length-, finteger-4-integer-8, fdefault-real-8, fdefault-integer-8, fdefault-double-8): Add Var() and Init(). * gfortran.h (gfc_option_t): Remove moved flags. * options.c (gfc_init_options, gfc_handle_option): Ditto. (gfc_post_options): Update for name change. * decl.c (gfc_match_old_kind_spec, gfc_match_kind_spec): Handle flag-name change. * frontend-passes.c (gfc_run_passes): Ditto. * module.c (use_iso_fortran_env_module): Ditto. * primary.c (match_integer_constant, match_real_constant): Ditto. * resolve.c (resolve_ordinary_assign): Ditto. * scanner.c (gfc_next_char_literal, load_line): Ditto. * trans-array.c (gfc_trans_allocate_array_storage, gfc_conv_resolve_dependencies, gfc_trans_auto_array_allocation, gfc_conv_ss_startstride): Ditto. * trans-common.c (gfc_sym_mangled_common_id): Ditto. * trans-decl.c (gfc_sym_mangled_function_id, create_main_function): Ditto. * trans-expr.c (gfc_conv_expr_op, gfc_conv_procedure_call, arrayfunc_assign_needs_temporary, gfc_trans_arrayfunc_assign, gfc_trans_assignment_1): Ditto. * trans-stmt.c (gfc_trans_allocate): Ditto. * trans-types.c (gfc_init_kinds): Ditto.
[Bug testsuite/64328] addr_equal-1.c fails execution.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64328
--- Comment #3 from Tejas Belagod belagod at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #2)
Indeed, the testcase is meant to be nopic. I will check how to test for
that in dg.
Honza
{ dg-require-effective-target nonpic } ?
[Bug bootstrap/64320] Missing config.h during findcomp.cc compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64320 --- Comment #1 from Rich Townsend townsend at astro dot wisc.edu --- OK, it seems that this bug comes from building with srcdir == objdir. If I build in a separate directory, then the problem goes away. As an aside, I hadn't realized that using srcdir == objdir is generally discouraged (see, e.g., https://gcc.gnu.org/install/configure.html). Is this a recent change, or have I always been doing it wrong?
[Bug middle-end/63568] Missed optimization (a ~mask) | (b mask) = a ^ ((a ^ b) mask)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63568 --- Comment #7 from Oleg Endo olegendo at gcc dot gnu.org --- If you decide not to do the transform at the tree level, please change this to a target PR and assign it to me.
[Bug c++/64333] New: C++14 constexpr gives wrong results when a looping constexpr function is evaluated twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64333
Bug ID: 64333
Summary: C++14 constexpr gives wrong results when a looping
constexpr function is evaluated twice
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
CC: jason at redhat dot com
#include initializer_list
constexpr int max(std::initializer_listint ints)
{
int ret = *(ints.begin());
for (int i = 0; i ints.size(); ++i) {
if (*(ints.begin()+i) ret) {
ret = *(ints.begin()+i);
}
}
return ret;
}
int main()
{
constexpr int z = max({7,6,5,4,3,2,1});
constexpr int z2 = max({5,4,3,2,1});
static_assert(z == 7, );
static_assert(z2 == 5, );
}
z2 is 7. There's something fishy going on here. :)
[Bug fortran/54687] Use gcc option machinery for gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54687 --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org --- Author: burnus Date: Tue Dec 16 20:44:45 2014 New Revision: 218792 URL: https://gcc.gnu.org/viewcvs?rev=218792root=gccview=rev Log: 2014-12-16 Tobias Burnus bur...@net-b.de PR fortran/54687 * gfortran.h (gfc_option_t): Remove flags which now have a Var(). * lang.opt (flag-aggressive_function_elimination, flag-align_commons, flag-all_intrinsics, flag-allow_leading_underscore, flag-automatic, flag-backslash, flag-backtrace, flag-blas_matmul_limit, flag-cray_pointer, flag-dollar_ok, flag-dump_fortran_original, flag-dump_fortran_optimized, flag-external_blas, flag-f2c, flag-implicit_none, flag-max_array_constructor, flag-module_private, flag-pack_derived, flag-range_check, flag-recursive, flag-repack_arrays, flag-sign_zero, flag-underscoring): Add Var() and, where applicable, Enum(). * options.c (gfc_init_options, gfc_post_options, gfc_handle_option): Update for *.opt changes. * arith.c: Update for flag-variable name changes. * array.c: Ditto. * cpp.c: Ditto. * decl.c: Ditto. * expr.c: Ditto. * f95-lang.c: Ditto. * frontend-passes.c: Ditto. * intrinsic.c: Ditto. * io.c: Ditto. * match.c: Ditto. * module.c: Ditto. * parse.c: Ditto. * primary.c: Ditto. * resolve.c: Ditto. * scanner.c: Ditto. * simplify.c: Ditto. * symbol.c: Ditto. * trans-array.c: Ditto. * trans-common.c: Ditto. * trans-decl.c: Ditto. * trans-expr.c: Ditto. * trans-intrinsic.c: Ditto. * trans-openmp.c: Ditto. * trans-types.c: Ditto. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/arith.c trunk/gcc/fortran/array.c trunk/gcc/fortran/cpp.c trunk/gcc/fortran/decl.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/f95-lang.c trunk/gcc/fortran/frontend-passes.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/io.c trunk/gcc/fortran/lang.opt trunk/gcc/fortran/match.c trunk/gcc/fortran/module.c trunk/gcc/fortran/options.c trunk/gcc/fortran/parse.c trunk/gcc/fortran/primary.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/scanner.c trunk/gcc/fortran/simplify.c trunk/gcc/fortran/symbol.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-common.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/fortran/trans-openmp.c trunk/gcc/fortran/trans-types.c
[Bug fortran/64244] [4.8/4.9/5 Regression] ICE at class.c:236 when using non_overridable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64244 --- Comment #12 from janus at gcc dot gnu.org --- (In reply to Ondřej Čertík from comment #11) So my system (RHEL6) libstdc++ library might be incompatible with the trunk, but I don't see why gcc couldn't compile. Any ideas how to fix this? Unfortunately I have no idea. It might possibly help to use --disable-bootstrap or --disable-multilib when configuring (just guessing here). In general, if you have trouble building GCC, you might get help from gcc-h...@gcc.gnu.org (or, for Fortran-related things: fort...@gcc.gnu.org). Note that some people offer nightly builds of the GCC trunk, see https://gcc.gnu.org/wiki/GFortranBinaries.
[Bug middle-end/63568] Missed optimization (a ~mask) | (b mask) = a ^ ((a ^ b) mask)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63568 --- Comment #8 from Marek Polacek mpolacek at gcc dot gnu.org --- (In reply to Oleg Endo from comment #7) If you decide not to do the transform at the tree level, please change this to a target PR and assign it to me. I have a patch that does the transformation on match-and-simplify. Let's see if it can make it in...
[Bug target/53513] [SH] Add support for fpchg insn and improve fenv support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513 --- Comment #46 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Tue Dec 16 21:28:59 2014 New Revision: 218793 URL: https://gcc.gnu.org/viewcvs?rev=218793root=gccview=rev Log: gcc/testsuite/ PR target/53513 * gcc.target/sh/fpchg.c: Rename to ... * gcc.target/sh/pr53513-1.c: ... this. Adjust test case to work for -m4a and -m4a-single. Added: trunk/gcc/testsuite/gcc.target/sh/pr53513-1.c Removed: trunk/gcc/testsuite/gcc.target/sh/fpchg.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug go/61246] gccgo: ICE in do_determine_types [GoSmith]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61246 --- Comment #3 from ian at gcc dot gnu.org ian at gcc dot gnu.org --- Author: ian Date: Tue Dec 16 21:36:53 2014 New Revision: 218794 URL: https://gcc.gnu.org/viewcvs?rev=218794root=gccview=rev Log: PR go/61246 compiler: Switch expression comparisons should be boolean typed. Modified: trunk/gcc/go/gofrontend/statements.cc
[Bug target/54089] [SH] Refactor shift patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089 --- Comment #32 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Tue Dec 16 21:37:42 2014 New Revision: 218795 URL: https://gcc.gnu.org/viewcvs?rev=218795root=gccview=rev Log: gcc/testsuite/ PR target/54089 * gcc.target/sh/pr54089-1.c: Change optimization level from -O1 to -O2. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/sh/pr54089-1.c
