[Bug middle-end/79720] [5/6/7 Regression] complex division different at compile time / runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79720 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #11 from Jakub Jelinek --- (In reply to Marc Glisse from comment #10) > (In reply to Thomas Koenig from comment #7) > > We also do a quite complex (sorry for the pun) and expensive > > division routine, just in order not to lose any bits of precision. > > If the compile-time simplification does not match that, it is > > simply buggy. > > If anything, I expect that the compile-time evaluation (using MPC) is more > precise than what you get by chaining real add/sub/mul/div, even if that's a > relatively expensive routine to reduce errors. Yeah, exactly. But then this is really NOTABUG. The compile time evaluation needs to be .5ulp precise, not emulate whatever precision issues the library has.
[Bug c++/79588] [7 Regression] ICE in warn_for_restrict with -Wrestrict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79588 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Fixed.
[Bug middle-end/79396] [5/6 Regression] ICE (verify_flow_info failed) with -fnon-call-exceptions -O2 -march=haswell
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79396 Jakub Jelinek changed: What|Removed |Added Summary|[5/6/7 Regression] ICE |[5/6 Regression] ICE |(verify_flow_info failed) |(verify_flow_info failed) |with -fnon-call-exceptions |with -fnon-call-exceptions |-O2 -march=haswell |-O2 -march=haswell --- Comment #15 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug c/79692] [7 Regression] -Wformat-overflow false positive with unknown width
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79692 --- Comment #3 from Franz Sirl --- I can confirm that the patch fixes both the submitted testcase and the original code. Thanks for your efforts.
[Bug tree-optimization/79690] IVOPTs drops gs: prefix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79690 --- Comment #6 from Richard Biener --- Author: rguenth Date: Mon Feb 27 08:50:09 2017 New Revision: 245751 URL: https://gcc.gnu.org/viewcvs?rev=245751&root=gcc&view=rev Log: 2017-02-27 Richard Biener PR tree-optimization/79690 * tree-vect-stmts.c (vectorizable_store): Use vector type built from the DR with address-space. * gcc.target/i386/pr79690.c: New testcase. Added: trunk/gcc/testsuite/gcc.target/i386/pr79690.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-stmts.c
[Bug tree-optimization/45397] [5/6 Regression] Issues with integer narrowing conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45397 --- Comment #31 from Richard Biener --- Author: rguenth Date: Mon Feb 27 08:51:28 2017 New Revision: 245752 URL: https://gcc.gnu.org/viewcvs?rev=245752&root=gcc&view=rev Log: 2017-02-27 Richard Biener PR tree-optimization/45397 * tree-ssa-pre.c (eliminate_insert): Handle BIT_AND_EXPR. * tree-ssa-sccvn.c (valueized_wider_op): New helper. (visit_nary_op): Add pattern matching for CSEing sign-changed or truncated operations with wider ones. * gcc.dg/tree-ssa/pr45397.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr45397.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-pre.c trunk/gcc/tree-ssa-sccvn.c
[Bug tree-optimization/45397] [5/6 Regression] Issues with integer narrowing conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45397 Richard Biener changed: What|Removed |Added Known to work||7.0 --- Comment #32 from Richard Biener --- Regression fixed on trunk.
[Bug tree-optimization/79690] IVOPTs drops gs: prefix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79690 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Richard Biener --- Fixed for GCC 7.
[Bug middle-end/79720] [5/6/7 Regression] complex division different at compile time / runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79720 --- Comment #12 from Thomas Koenig --- (In reply to Jakub Jelinek from comment #11) > Yeah, exactly. But then this is really NOTABUG. The compile time > evaluation needs to be .5ulp precise, not emulate whatever precision issues > the library has. When -fcx-fortran-rules is active(by default in Fortran, or when explicitly specified by the user) we generate inline code. The issue is the same then.
[Bug tree-optimization/79716] memset followed by overwrite not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79716 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-27 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. The issue is that DSE does not track variable-size stores like this and thus stmt_kills_ref_p (temp, ref) returns false for memcpy and the ref for memset (which ends up with unknown size).
[Bug fortran/71838] ICE with OpenCoarrays on submodule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71838 --- Comment #13 from Anton Shterenlikht --- The latest I have is: gcc6-devel-6.3.1.s20161229 lang/gcc6-devel gcc7-devel-7.0.0.s20170101 lang/gcc7-devel ATM I've no time to build gcc myself. I'll wait for gerald@ to update these ports and will try again. Thanks! Anton
[Bug tree-optimization/79715] hand-rolled strdup with unused result not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79715 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-27 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. DSE doesn't know about STRCPY (and other similar builtins).
[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
--- Comment #13 from Jakub Jelinek ---
(In reply to Bernd Edlinger from comment #12)
> Hi,
>
> I don't know if it helps, but on the assembler level there are only two
> instructions that need to be moved to make the test case pass:
That of course helps a lot, that is what I was trying to narrow through the
hacks.
Before sched1 there is:
(insn 598 595 1707 67 (set (mem/c:QI (plus:SI (reg/f:SI 102 sfp)
(const_int -19 [0xffed])) [98 MEM[(struct
parser_binder *)&D.616009 + 5B]+0 S1 A8])
(subreg:QI (reg:SI 505) 0)) 192 {*arm_movqi_insn}
(expr_list:REG_DEAD (reg:SI 505)
(nil)))
...
(insn 604 603 605 67 (set (reg/f:SI 692)
(plus:SI (reg/f:SI 102 sfp)
(const_int -20 [0xffec])))
"/usr/include/boost/function/function_template.hpp":998 4 {*arm_addsi3}
(nil))
(insn 605 604 606 67 (parallel [
(set (reg:SI 0 r0)
(mem/c:SI (reg/f:SI 692) [19 MEM[(struct function4
*)&D.616009].D.542442.functor+0 S4 A32]))
(set (reg:SI 1 r1)
(mem/c:SI (plus:SI (reg/f:SI 692)
(const_int 4 [0x4])) [19 MEM[(struct function4
*)&D.616009].D.542442.functor+4 S4 A32]))
(set (reg:SI 2 r2)
(mem/c:SI (plus:SI (reg/f:SI 692)
(const_int 8 [0x8])) [19 MEM[(struct function4
*)&D.616009].D.542442.functor+8 S4 A32]))
]) "/usr/include/boost/function/function_template.hpp":998 364 {*ldm3_}
(nil))
(current trunk, the above command line options, no patches), so ignoring strict
aliasing, there is a must alias in between the middle mem in insn 605 and the
mem insn 598 stores to.
Now if I do:
break sched_analyze_2 if x->code == MEM && insn->u2.insn_uid == 605
run
continue
then x is:
(mem/c:SI (plus:SI (reg/f:SI 692)
(const_int 4 [0x4])) [19 MEM[(struct function4
*)&D.616009].D.542442.functor+4 S4 A32])
and deps->pending_write_mems is:
(expr_list:REG_DEP_TRUE (mem/f/c:SI (plus:SI (reg/f:SI 102 sfp)
(const_int -264 [0xfef8])) [18 tmp.D.542442.vtable+0 S4
A64])
(expr_list:REG_DEP_TRUE (mem/c:QI (plus:SI (reg/f:SI 102 sfp)
(const_int -19 [0xffed])) [98 MEM[(struct
parser_binder *)&D.616009 + 5B]+0 S1 A8])
(nil)))
This then calls true_dependence with mem:
(mem/c:QI (plus:SI (reg/f:SI 102 sfp)
(const_int -19 [0xffed])) [98 MEM[(struct parser_binder
*)&D.616009 + 5B]+0 S1 A8])
x:
(mem/c:SI (plus:SI (reg/f:SI 692)
(const_int 4 [0x4])) [19 MEM[(struct function4
*)&D.616009].D.542442.functor+4 S4 A32])
and we return 0 because of:
2931 if (mems_in_disjoint_alias_sets_p (x, mem))
2932return 0;
In *.optimized dump I believe this is:
MEM[(struct parser_binder *)&D.616009 + 5B] = 93;
value_283 = (size_t) &stored_vtable.base;
value_284 = value_283 | 1;
value.75_285 = (struct vtable_base *) value_284;
MEM[(struct function4 *)&D.616009].D.542442.vtable = value.75_285;
MEM[(struct &)&tmp] ={v} {CLOBBER};
tmp.D.542442.vtable = value.75_285;
tmp.D.542442.functor = MEM[(struct function4 *)&D.616009].D.542442.functor;
insn 598 is that MEM[(struct parser_binder *)&D.616009 + 5B] = 93; and insn 605
(ldm3_) is the load for the structure assignment
tmp.D.542442.functor = MEM[(struct function4 *)&D.616009].D.542442.functor;
Richard, could you please have a look from the alias oracle POV?
[Bug target/79712] Clang smarter about unrolling in fhourstones benchmark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79712 Richard Biener changed: What|Removed |Added Keywords||missed-optimization --- Comment #7 from Richard Biener --- Note that GCC doesn't do traditional unrolling by default and if enabled via -funroll-loops it does a lousy job (which is why it is _not_ enabled by default). GCC merely unrolls as part of other transforms (those applying are then the cost model).
[Bug target/79709] Subobtimal code with -mavx and explicit vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79709 --- Comment #5 from Richard Biener --- Best split this bug into BIT_INSERT_EXPR foldings (yeah, those mentioned are missing) and the ira/reload issue.
[Bug tree-optimization/79721] Scalar evolution introduces signed overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79721
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-02-27
CC||rguenth at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
SCCP currently guards doing everything in unsigned arithmetic with
/* If def's type has undefined overflow and there were folded
casts, rewrite all stmts added for def into arithmetics
with defined overflow behavior. */
if (folded_casts && ANY_INTEGRAL_TYPE_P (TREE_TYPE (def))
&& TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (def)))
{
but here folded_casts is false. Clearly the above is bogus as it doesn't take
into account that computing the final value replacement involves association.
So the "fix" would be to unconditionally rewrite the expression to use unsigned
arithmetic (even for ! TYPE_OVERFLOW_UNDEFINED, which should have been
TYPE_OVERFLOW_WRAPS anyway).
[Bug tree-optimization/77536] Vectorizer not maintaining relationship of relative block frequencies in absence of real profile data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77536 --- Comment #7 from amker at gcc dot gnu.org --- Author: amker Date: Mon Feb 27 10:20:36 2017 New Revision: 245754 URL: https://gcc.gnu.org/viewcvs?rev=245754&root=gcc&view=rev Log: PR tree-optimization/77536 * tree-ssa-loop-manip.c (niter_for_unrolled_loop): New function. (tree_transform_and_unroll_loop): Use above function to compute the estimated niter of unrolled loop and use it when scaling profile. Also use count info rather than frequency if it's non-zero. * tree-ssa-loop-manip.h niter_for_unrolled_loop(): New declaration. * tree-vect-loop.c (scale_profile_for_vect_loop): New function. (vect_transform_loop): Call above function. gcc/testsuite * gcc.dg/vect/pr79347.c: Revise testing string. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/pr79347.c trunk/gcc/tree-ssa-loop-manip.c trunk/gcc/tree-ssa-loop-manip.h trunk/gcc/tree-vect-loop.c
[Bug fortran/71838] ICE with OpenCoarrays on submodule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71838 --- Comment #14 from paul.richard.thomas at gmail dot com --- Hi Anton, Did you take on board that it is the procedure dummy argument that causes the problem? A viable workaround is to: s/procedure( cgca_clvgs_abstract ) :: sub/external :: sub/ Cheers Paul On 27 February 2017 at 09:58, mexas at bristol dot ac.uk wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71838 > > --- Comment #13 from Anton Shterenlikht --- > > The latest I have is: > > gcc6-devel-6.3.1.s20161229 lang/gcc6-devel > gcc7-devel-7.0.0.s20170101 lang/gcc7-devel > > ATM I've no time to build gcc myself. > I'll wait for gerald@ to update these ports and will try again. > > Thanks! > > Anton > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You are the assignee for the bug.
[Bug middle-end/79720] [5/6/7 Regression] complex division different at compile time / runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79720 --- Comment #13 from Marc Glisse --- (In reply to Thomas Koenig from comment #12) > When -fcx-fortran-rules is active(by default in Fortran, > or when explicitly specified by the user) we generate inline > code. The issue is the same then. What exactly do you want to happen? That gcc generates code that can evaluate complex division within .5ulp at runtime? That would be super slow...
[Bug tree-optimization/79716] memset followed by overwrite not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79716 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- If we want to do something about this, we should do it regardless if user wrote it as p = malloc (n); memset (p, 0, n); or p = calloc (n, 1); or p = calloc (1, n); - if such a calloc is followed by overwriting all bytes in it, we can transform the calloc back to malloc. We need to be careful about padding bits though.
[Bug target/79709] Subobtimal code with -mavx and explicit vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79709 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- For the BIT_INSERT_EXPR foldings, the question is if we want to handle them one by one even when there is undefined value in the first one, or if in that case we should fold only if we eliminate all the undefined values from there and get a constant VECTOR_CST.
[Bug target/70465] [5/6 Regression] Poor code for x87 asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70465 Jakub Jelinek changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #22 from Jakub Jelinek --- Fixed.
[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
--- Comment #14 from Richard Biener ---
Seems to be
void move_assign(function10& f)
{
if (&f == this)
return;
{ try {
if (!f.empty()) {
this->vtable = f.vtable;
if (this->has_trivial_copy_and_destroy())
this->functor = f.functor;
^^^
for the aggregate copy but lineno info looks confused for the aliasing store.
It points at
operator=(Functor f)
{
self_type(f).swap(*this);
return *this;
}
the boost code for function looks quite convoluted with its vtable handling...
It looks like ESRA creates that piecewise store, but it's hard to track down
exactly where it comes from. Example transform looks like
+ char f$p$subject$subject$right$ch;
struct parser_binder f;
bool D.611696;
struct parser_binder f;
@@ -15343,7 +11698,8 @@
[100.00%]:
<&0x7f50d29d3d70> f = f;
- <&0x7f50d29d3dc0> f = f;
+ <&0x7f50d2a16050> f$p$subject$subject$right$ch_16 = MEM[(struct
parser_binder *)&f + 1B];
+ <&0x7f50d2a160a0> MEM[(struct parser_binder *)&f + 1B] =
f$p$subject$subject$right$ch_16;
<&0x7f50d2a14240> _13 = boost::detail::function::has_empty_target (&f);
there's no offset 5 one at this point so inlining eventually comes up with
[100.00%]:
<&0x7f50d2a16b40> f = f;
<&0x7f50d2a314b0> f$1_39 = MEM[(struct parser_binder *)&f + 1B];
<&0x7f50d2a16b90> f$1_11 = f$1_39;
<&0x7f50d2a16be0> MEM[(struct &)&D.573835] ={v} {CLOBBER};
<&0x7f50d2a16c30> MEM[(struct function_base *)&D.573835].vtable = 0B;
<&0x7f50d2a16c80> MEM[(struct parser_binder *)&f + 1B] = f$1_11;
<&0x7f50d2a28bd0> _12 = boost::detail::function::has_empty_target (&f);
<&0x7f50d2a16cd0> if (_12 != 0)
goto ; [46.00%]
else
goto ; [54.00%]
[54.00%]:
<&0x7f50d2a16d20> MEM[(struct parser_binder *)&D.573835 + 5B] = f$1_11;
note that .original shows
size_t value = (size_t) &stored_vtable.base;
<>;
<;
;
and thus questionable casts.
The question ultimatively boils down to validity of the testcase.
[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
--- Comment #15 from Richard Biener ---
w/o SRA the cases look like
[48.23%]:
<&0x7f3d13ec30f0> f = f;
<&0x7f3d13ec3140> MEM[(struct parser_binder *)&D.614964 + 4B] = f;
<&0x7f3d13ec3190> value_405 = (size_t) &stored_vtable.base;
<&0x7f3d1f70cdc0> value_406 = value_405 | 1;
<&0x7f3d13ec31e0> value.90_407 = (struct vtable_base *) value_406;
<&0x7f3d13ec3230> MEM[(struct function4 *)&D.614964].D.547000.vtable =
value.90_407;
<&0x7f3d13ebd9b0> MEM[(struct &)&tmp] ={v} {CLOBBER};
<&0x7f3d13ec3370> tmp.D.547000.vtable = value.90_407;
<&0x7f3d13ec3460> tmp.D.547000.functor = MEM[(struct function4
*)&D.614964].D.547000.functor;
<&0x7f3d13ec35f0> MEM[(struct function4 *)&D.614964].D.547000.vtable = 0B;
<&0x7f3d13f06d70> _135 = MEM[(struct vtable_base * *)this_10(D) + 144B];
<&0x7f3d13f06dc0> if (_135 != 0B)
which look similar from TBAA perspective (parser_binder vs. function4). Might
not miscompile because of pure luck of course.
[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
--- Comment #16 from Jakub Jelinek ---
With -Wsystem-headers there are various warnings, e.g.
/usr/include/boost/function/function_template.hpp:572:11: warning: placement
new constructing an object of type
‘boost::spirit::qi::detail::parser_binder >,
boost::spirit::qi::literal_char > >, mpl_::bool_ >’ and size ‘2’ in a region of type ‘char’ and
size ‘1’ [-Wplacement-new=]
new (reinterpret_cast(&functor.data)) FunctionObj(f);
^~~
/usr/include/boost/function/function_base.hpp:308:13: warning: placement new
constructing an object of type
‘boost::detail::function::functor_manager_common >,
boost::spirit::qi::literal_char > >, mpl_::bool_ > >::functor_type {aka
boost::spirit::qi::detail::parser_binder >,
boost::spirit::qi::literal_char > >, mpl_::bool_ >}’ and size ‘2’ in a region of type ‘char’ and
size ‘1’ [-Wplacement-new=]
new (reinterpret_cast(&out_buffer.data))
functor_type(*in_functor);
^
etc.
[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
--- Comment #17 from Jakub Jelinek ---
But if I change:
-mutable char data;
+mutable char data[sizeof (void *) + 2 * sizeof (bool)];
so that the union field occupies the size of some other union members, the
warning is gone, but I still see:
add r5, sp, #292
...
ldm r5, {r0, r1, r2}
...
strbr6, [sp, #293]
[Bug fortran/79676] [submodules] Compilation/linking error when module procedures PRIVATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79676 --- Comment #2 from Adam Hirst --- Could this be related? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846#c14 > Paul Thomas 2015-07-16 14:52:58 UTC > OK - this compiles and runs if the PRIVATE statement is removed. As soon as I > return to the privacy issue, I will check that this testcase is OK.
[Bug c++/79414] [7 Regression] internal compiler error after "error: expected unqualified-id at end of input"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79414 --- Comment #3 from Paolo Carlini --- Fixed in r245440. I'm adding a testcase and closing the bug.
[Bug target/79722] New: Missed opportunity for fused multiply/add with avx2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79722
Bug ID: 79722
Summary: Missed opportunity for fused multiply/add with avx2
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Created attachment 40835
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40835&action=edit
Output of gcc -Ofast -mavx2 -S -o bar-gcc.s bar.c
The test case is the same as PR 79709:
typedef double v4do __attribute__((vector_size (32)));
typedef long int v4i __attribute__((vector_size (32)));
#define VSET(vect,val) do { vect[0]=val; vect[1]=val; vect[2]=val; vect[3]=val;
} while (0)
void foo(v4do cx, v4do cy, v4i *r)
{
v4do x, y, xn, yn;
v4i add, res;
v4do two, four;
long int done;
VSET(res, 0L);
VSET(two, 2.0);
VSET(four, 4.0);
x = cx;
y = cy;
done = 0;
while (1)
{
xn = x*x - y*y + cx;
yn = two*x*y + cy;
add = xn+xn + yn*yn < four;
res += add;
if (add[0] == 0 || add[1] == 0 || add[2] || add[3])
break;
x = xn;
y = yn;
}
*r = res;
}
With gcc, the inner loop is tranlsated into
.L13:
vpextrq $1, %xmm2, %rax
testq %rax, %rax
je .L2
vextracti128$0x1, %ymm2, %xmm2
vmovq %xmm2, %rax
testq %rax, %rax
jne .L2
vpextrq $1, %xmm2, %rax
vmovapd %ymm4, %ymm3
testq %rax, %rax
jne .L2
.L3:
vmulpd %ymm3, %ymm3, %ymm4
vmulpd %ymm9, %ymm3, %ymm3
vaddpd %ymm0, %ymm4, %ymm4
vmulpd %ymm7, %ymm3, %ymm3
vsubpd %ymm10, %ymm4, %ymm4
vaddpd %ymm1, %ymm3, %ymm9
vaddpd %ymm4, %ymm4, %ymm2
vmulpd %ymm9, %ymm9, %ymm10
vaddpd %ymm10, %ymm2, %ymm2
vcmpltpd%ymm6, %ymm2, %ymm2
vmovq %xmm2, %rax
vpaddq %ymm2, %ymm8, %ymm8
testq %rax, %rax
jne .L13
icc -O3 -march=core-avx2 -S results in
..B1.6: # Preds ..B1.5
# Execution count [6.94e-01]
vmovdqa %ymm11, %ymm5 #27.7
# LOE rbx rdi r12 r13 r14 r15 ymm0 ymm1 ymm2
ymm3 ymm4 ymm5 ymm6 ymm7
..B1.2: # Preds ..B1.6 ..B1.1
# Execution count [1.69e+00]
vmovaps %ymm4, %ymm11 #21.24
vfmsub213pd %ymm6, %ymm4, %ymm11#21.24
vfmsub231pd %ymm5, %ymm5, %ymm11#21.24
vmulpd%ymm3, %ymm5, %ymm5 #22.16
vaddpd%ymm11, %ymm11, %ymm8 #23.16
vfmadd213pd %ymm7, %ymm5, %ymm4 #22.22
vfmadd231pd %ymm4, %ymm4, %ymm8 #23.24
vcmpltpd %ymm2, %ymm8, %ymm9 #23.29
vandpd%ymm9, %ymm1, %ymm10 #23.29
vmovups %ymm10, -64(%rsp) #23.7
vpaddq%ymm10, %ymm0, %ymm0 #24.7
cmpq $0, -64(%rsp) #25.21
je..B1.7# Prob 20% #25.21
# LOE rbx rdi r12 r13 r14 r15 ymm0 ymm1 ymm2
ymm3 ymm4 ymm6 ymm7 ymm11
..B1.3: # Preds ..B1.2
# Execution count [1.36e+00]
cmpq $0, -56(%rsp) #25.36
je..B1.7# Prob 20% #25.36
# LOE rbx rdi r12 r13 r14 r15 ymm0 ymm1 ymm2
ymm3 ymm4 ymm6 ymm7 ymm11
..B1.4: # Preds ..B1.3
# Execution count [1.08e+00]
cmpq $0, -48(%rsp) #25.45
jne ..B1.7# Prob 20% #25.45
# LOE rbx rdi r12 r13 r14 r15 ymm0 ymm1 ymm2
ymm3 ymm4 ymm6 ymm7 ymm11
..B1.5: # Preds ..B1.4
# Execution count [8.67e-01]
cmpq $0, -40(%rsp) #25.55
je..B1.6# Prob 80% #25.55
# LOE rbx rdi r12 r13 r14 r15 ymm0 ymm1 ymm2
ymm3 ymm4 ymm6 ymm7 ymm11
where icc uses eight double precision floating point operations
vs. gcc's ten.
[Bug c++/79414] [7 Regression] internal compiler error after "error: expected unqualified-id at end of input"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79414 --- Comment #4 from paolo at gcc dot gnu.org --- Author: paolo Date: Mon Feb 27 11:55:19 2017 New Revision: 245756 URL: https://gcc.gnu.org/viewcvs?rev=245756&root=gcc&view=rev Log: 2017-02-27 Paolo Carlini PR c++/79414 * g++.dg/parse/crash67.C: New. Added: trunk/gcc/testsuite/g++.dg/parse/crash67.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/79414] [7 Regression] internal compiler error after "error: expected unqualified-id at end of input"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79414 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Paolo Carlini --- Done.
[Bug target/79722] Missed opportunity for fused multiply/add with avx2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79722 --- Comment #1 from Thomas Koenig --- Created attachment 40836 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40836&action=edit Output of icc -O3 -march=core-avx2 -S -o bar-intel.s bar.c
[Bug target/79722] Missed opportunity for fused multiply/add with avx2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79722 Thomas Koenig changed: What|Removed |Added Keywords||missed-optimization Target||x86_64-pc-linux-gnu Version|unknown |7.0.1 Severity|normal |enhancement
[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
--- Comment #18 from Jakub Jelinek ---
(In reply to Richard Biener from comment #14)
> Seems to be
>
> void move_assign(function10& f)
> {
> if (&f == this)
> return;
>
> { try {
> if (!f.empty()) {
> this->vtable = f.vtable;
> if (this->has_trivial_copy_and_destroy())
> this->functor = f.functor;
> ^^^
Indeed.
> for the aggregate copy but lineno info looks confused for the aliasing store.
> It points at
>
> operator=(Functor f)
> {
> self_type(f).swap(*this);
> return *this;
> }
The inline location of the aliasing store is:
In function ‘bool boost::detail::function::basic_vtable4::assign_to(FunctionObj, boost::detail::function::function_buffer&,
boost::detail::function::function_obj_tag) const [with FunctionObj =
boost::spirit::qi::detail::parser_binder >,
boost::spirit::qi::literal_char > >, mpl_::bool_ >; R = bool; T0 =
__gnu_cxx::__normal_iterator >&;
T1 = const __gnu_cxx::__normal_iterator >&; T2 =
boost::spirit::context&,
boost::fusion::nil_>, boost::fusion::vector<> >&; T3 = const
boost::spirit::qi::char_class >&]’,
inlined from ‘void boost::function4::assign_to(Functor)
[with Functor =
boost::spirit::qi::detail::parser_binder >,
boost::spirit::qi::literal_char > >, mpl_::bool_ >; R = bool; T0 =
__gnu_cxx::__normal_iterator >&;
T1 = const __gnu_cxx::__normal_iterator >&; T2 =
boost::spirit::context&,
boost::fusion::nil_>, boost::fusion::vector<> >&; T3 = const
boost::spirit::qi::char_class >&]’ at
/usr/include/boost/function/function_template.hpp:498:45,
inlined from ‘boost::function4::function4(Functor,
typename boost::enable_if_c<(! boost::is_integral::value), int>::type)
[with Functor =
boost::spirit::qi::detail::parser_binder >,
boost::spirit::qi::literal_char > >, mpl_::bool_ >; R = bool; T0 =
__gnu_cxx::__normal_iterator >&;
T1 = const __gnu_cxx::__normal_iterator >&; T2 =
boost::spirit::context&,
boost::fusion::nil_>, boost::fusion::vector<> >&; T3 = const
boost::spirit::qi::char_class >&]’ at
/usr/include/boost/function/function_template.hpp:727:7,
inlined from ‘boost::function::function(Functor,
typename boost::enable_if_c<(! boost::is_integral::value), int>::type)
[with Functor =
boost::spirit::qi::detail::parser_binder >,
boost::spirit::qi::literal_char > >, mpl_::bool_ >; R = bool; T0 =
__gnu_cxx::__normal_iterator >&;
T1 = const __gnu_cxx::__normal_iterator >&; T2 =
boost::spirit::context&,
boost::fusion::nil_>, boost::fusion::vector<> >&; T3 = const
boost::spirit::qi::char_class >&]’ at
/usr/include/boost/function/function_template.hpp:1073:16,
inlined from ‘boost::spirit::qi::rule&
boost::spirit::qi::operator%=(boost::spirit::qi::rule&, Expr&&) [with Expr = const
boost::proto::exprns_::expr >&,
boost::proto::exprns_::expr, 0> >, 2>&>, 1>; Iterator =
__gnu_cxx::__normal_iterator >;
T1 = std::__cxx11::basic_string(); T2 =
boost::proto::exprns_::expr >, 0>; T3 =
boost::spirit::unused_type; T4 = boost::spirit::unused_type]’ at
/usr/include/boost/function/function_template.hpp:1126:5,
inlined from ‘path_expression_grammar::path_expression_grammar()
[with Iterator = __gnu_cxx::__normal_iterator >]’ at /tmp/rh1422456.C:36:5:
That is:
template
bool assign_to(F f, function_buffer& functor) const
{
typedef typename get_function_tag::type tag;
return assign_to(f, functor, tag());
}
and
template
function4(Functor f
,typename boost::enable_if_c<
!(is_integral::value),
int>::type = 0
) :
function_base()
{
this->assign_to(f);
}
and
template
function(Functor f
,typename boost::enable_if_c<
!(is_integral::value),
int>::type = 0
) :
base_type(f)
{
}
and
operator=(Functor f)
{
self_type(f).swap(*this);
return *this;
}
and
attr %= +(char_ - ']');
but there is no location for the innermost inlined frame :(.
[Bug target/79722] Missed opportunity for fused multiply/add with avx2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79722 --- Comment #2 from Marc Glisse --- -mavx2 does not enable fma. Did you try with -mfma, or with a suitable -march flag?
[Bug tree-optimization/79723] New: Another case of dropped gs: prefix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79723
Bug ID: 79723
Summary: Another case of dropped gs: prefix
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: me at manueljacob dot de
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
void memset_pattern_seg_gs(unsigned char * __seg_gs *s, long n) {
for (long i = 0; i < n; ++i)
s[i] = 0;
}
On x86-64, gcc -O3 emits this instruction, missing the gs: prefix:
movaps %xmm0, -16(%rdx)
It works when replacing "unsigned char *" with "long", even though they have
the same size and alignment.
[Bug target/79722] Missed opportunity for fused multiply/add with avx2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79722 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Thomas Koenig --- (In reply to Marc Glisse from comment #2) > -mavx2 does not enable fma. Did you try with -mfma, or with a suitable > -march flag? You're right, that fixes it. Resolving as invalid.
[Bug c++/79681] [6/7 Regression] ICE with constexpr and bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79681 --- Comment #3 from Jakub Jelinek --- A problem with that information loss due to make_bit_field_ref and its callers during folding is that there could e.g. be multiple fields that fall into the range (e.g. inside of union) etc. The IMHO best fix would be to stop doing constexpr evaluation on folded functions (i.e. copy constexpr function bodies before folding), or perhaps we could change make_bit_field_ref so that it attempts to use as many COMPONENT_REFs/ARRAY_REFs from orig_inner as possible, maybe just see if orig_inner is a bit field with DECL_BIT_FIELD_REPRESENTATIVE and if the bitpos + bitsize could be used for that.
[Bug target/57353] unrecognizable insn in decLibrary.c, ICE in extract_insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57353 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||segher at gcc dot gnu.org Resolution|--- |INVALID --- Comment #3 from Segher Boessenkool --- Closing then.
[Bug ada/79724] New: please respect calling gnat tools configured with --program-suffix and --program-prefix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79724 Bug ID: 79724 Summary: please respect calling gnat tools configured with --program-suffix and --program-prefix Product: gcc Version: 6.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Target Milestone: --- currently --program-suffix and --program-prefix are not respected by the various ada tools. They might be installed correctly with the configured prefix and suffix, but internally tools are called without prefix and suffix (e.g. gnatmake still calls /bin/gcc, which might point to another version of gcc not having ada installed). Debian/Ubuntu had a patch to resolve this, and to call the tools with the suffix name, however for some occasions it would append the suffix twice (any hint what is wrong with the patch would be appreciated). The current patch: https://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-7/debian/patches/ada-gcc-name.diff?revision=9242&view=markup Problems caused with this patch: https://bugs.debian.org/814978 """ Due to the Debian patch ada-gcc-name.diff the name of gcc becomes gcc-5-5 instead of gcc-5. This is easily shown with: /usr/bin/gnatchop -v fc51b00.a where fcb51b.a is located at src/gcc/testsuite/ada/acats/support/ (same when run as a shell command) GNATCHOP 5.3.1 Copyright (C) 1998-2015, Free Software Foundation, Inc. gcc-5-5: installation problem, executable not found no source files written However, issuing the command directly via path works: gnatchop -v fc51b00.a GNATCHOP 5.3.1 Copyright (C) 1998-2015, Free Software Foundation, Inc. /usr/bin/gcc-5 -c -x ada -gnats -gnatu fc51b00.a splitting fc51b00.a into: fc51b00.ads with: which gnatchop /usr/bin/gnatchop """ So two issues: what causes the duplication of the suffix, and how to generalize the tool names to include the prefix and the suffix?
[Bug c/79725] New: Sinking opportunity missed if complex type is changed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79725
Bug ID: 79725
Summary: Sinking opportunity missed if complex type is changed
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: drraph at gmail dot com
Target Milestone: ---
Consider:
#include
complex double f(complex double x[]) {
complex float p = 1.0;
for (int i = 0; i < 100; i++)
p = x[i];
return p;
}
This compiles using -O3 -march=core-avx2 -ffast-math to:
f:
lea rax, [rdi+1600]
.L2:
vmovupd ymm0, YMMWORD PTR [rdi]
vmovupd ymm5, YMMWORD PTR [rdi+32]
sub rdi, -128
vmovupd ymm1, YMMWORD PTR [rdi-64]
vmovupd ymm4, YMMWORD PTR [rdi-32]
vunpcklpd ymm2, ymm0, ymm5
vunpckhpd ymm0, ymm0, ymm5
vunpcklpd ymm3, ymm1, ymm4
vunpckhpd ymm1, ymm1, ymm4
vpermpd ymm2, ymm2, 216
vpermpd ymm3, ymm3, 216
vpermpd ymm0, ymm0, 216
vpermpd ymm1, ymm1, 216
vcvtpd2ps xmm2, ymm2
vcvtpd2ps xmm3, ymm3
vcvtpd2ps xmm0, ymm0
vcvtpd2ps xmm1, ymm1
vinsertf128 ymm2, ymm2, xmm3, 0x1
vinsertf128 ymm1, ymm0, xmm1, 0x1
cmp rax, rdi
jne .L2
vextractf128xmm2, ymm2, 0x1
vextractf128xmm1, ymm1, 0x1
vshufps xmm0, xmm2, xmm2, 255
vshufps xmm1, xmm1, xmm1, 255
vcvtss2sd xmm0, xmm0, xmm0
vzeroupper
vcvtss2sd xmm1, xmm1, xmm1
ret
More efficient would be:
f: # @f
vmovsd xmm0, qword ptr [rdi + 1584] # xmm0 = mem[0],zero
vmovsd xmm1, qword ptr [rdi + 1592] # xmm1 = mem[0],zero
vcvtsd2ss xmm0, xmm0, xmm0
vcvtsd2ss xmm1, xmm1, xmm1
vcvtss2sd xmm0, xmm0, xmm0
vcvtss2sd xmm1, xmm1, xmm1
ret
If we change the line complex float p = 1.0; to complex double p = 1.0; then
the sinking happens correctly.
[Bug libfortran/78379] Processor-specific versions for matmul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78379 --- Comment #24 from Thomas Koenig --- Could be a good idea to add a version with -mfma to the flags for AVX2. I'll see what I can do. It might be too late for gcc 7, and I also don't have an AVX2 machine to test on. Might also be a good idea to include this for AVX512F (if it is automatically included).
[Bug c++/79681] [6/7 Regression] ICE with constexpr and bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79681
--- Comment #4 from Jakub Jelinek ---
I was thinking about
--- fold-const.c.jj12017-02-17 18:29:24.0 +0100
+++ fold-const.c2017-02-27 14:49:13.816203253 +0100
@@ -3862,6 +3862,39 @@ make_bit_field_ref (location_t loc, tree
{
tree result, bftype;
+ /* Attempt to use DECL_BIT_FIELD_REPRESENTATIVE as BIT_FIELD_REF
+ base if possible during FE folding. */
+ if (in_gimple_form
+ && TREE_CODE (orig_inner) == COMPONENT_REF
+ && (DECL_BIT_FIELD_REPRESENTATIVE (TREE_OPERAND (orig_inner, 1))
+ != NULL_TREE))
+{
+ tree repr = DECL_BIT_FIELD_REPRESENTATIVE (TREE_OPERAND (orig_inner,
1));
+ tree ninner = build3 (COMPONENT_REF, TREE_TYPE (repr),
+ TREE_OPERAND (orig_inner, 0), repr, NULL_TREE);
+ machine_mode nmode;
+ HOST_WIDE_INT nbitsize, nbitpos;
+ tree noffset;
+ int nunsignedp, nreversep, nvolatilep = 0;
+ tree base = get_inner_reference (ninner, &nbitsize, &nbitpos,
+ &noffset, &nmode, &nunsignedp,
+ &nreversep, &nvolatilep);
+ if (base == inner
+ && noffset == NULL_TREE
+ && nbitsize >= bitsize
+ && nbitpos <= bitpos
+ && bitpos + bitsize <= nbitpos + nbitsize
+ && !reversep
+ && !nreversep
+ && !nvolatilep)
+ {
+ inner = ninner;
+ bitpos -= nbitpos;
+ }
+ else
+ ggc_free (ninner);
+}
+
alias_set_type iset = get_alias_set (orig_inner);
if (iset == 0 && get_alias_set (inner) != iset)
inner = fold_build2 (MEM_REF, TREE_TYPE (inner),
which quite often just starts using the representative instead of using
BIT_FIELD_REF. Unfortunately constexpr.c isn't prepared to handle that either.
[Bug c++/79681] [6/7 Regression] ICE with constexpr and bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79681 --- Comment #5 from Jakub Jelinek --- Of course !in_gimple_form.
[Bug tree-optimization/79725] Sinking opportunity missed if blocked by dead stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79725
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2017-02-27
Component|c |tree-optimization
Summary|Sinking opportunity missed |Sinking opportunity missed
|if complex type is changed |if blocked by dead stmt
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
We seem to be quite unlucky with initial IL:
p = __complex__ (1.0e+0, 0.0);
{
int i;
i = 0;
goto ;
:
_1 = (long unsigned int) i;
_2 = _1 * 16;
_3 = x + _2;
D.2523 = *_3;
_4 = REALPART_EXPR ;
_5 = (float) _4;
_6 = IMAGPART_EXPR ;
_7 = (float) _6;
p = COMPLEX_EXPR <_5, _7>;
i = i + 1;
:
if (i <= 99) goto ; else goto ;
:
}
p.0 = p;
_8 = REALPART_EXPR ;
_9 = (double) _8;
_10 = IMAGPART_EXPR ;
_11 = (double) _10;
D.2524 = COMPLEX_EXPR <_9, _11>;
return D.2524;
this causes a PHI node for p inside the loop and the uses partly vanish
after threading. But before sinking we still have a dead expression that
blocks the sinking because we do
static bool
statement_sink_location (gimple *stmt, basic_block frombb,
gimple_stmt_iterator *togsi)
{
...
/* Return if there are no immediate uses of this stmt. */
if (has_zero_uses (DEF_FROM_PTR (def_p)))
return false;
it's understandable we don't want to deal with dead code but in this case
it's "premature compile-time optimization" ;) (OTOH we just crash if
we remove that check).
PRE figured out the redundancy in
_5 = (float) _4;
_7 = (float) _6;
p_18 = COMPLEX_EXPR <_5, _7>;
i_19 = i_24 + 1;
if (i_19 != 100)
goto ; [98.99%]
else
goto ; [1.01%]
[98.00%]:
goto ; [100.00%]
[1.00%]:
_9 = (double) _5;
_11 = (double) _7;
_14 = COMPLEX_EXPR <_9, _11>;
and made p_18 unused but left the dead p_18 around (it's not its job to do the
DCE).
If you change complex float to complex double the initial IL doesn't contain
the decomposition and the situation is much easier.
I'll have a look to mitigate this in sinking for GCC 8.
[Bug c++/79681] [6/7 Regression] ICE with constexpr and bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79681 --- Comment #6 from Jakub Jelinek --- Created attachment 40837 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40837&action=edit gcc7-pr79681.patch This seems to work though.
[Bug c/79726] New: Type conversion not vectorisde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79726
Bug ID: 79726
Summary: Type conversion not vectorisde
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: drraph at gmail dot com
Target Milestone: ---
Consider:
double f(double x[]) {
float p = 1.0;
for (int i = 0; i < 16; i++)
p += x[i];
return p;
}
gcc with -O3 -march=core-avx2 -ffast-math gives:
f:
vmovsd xmm0, QWORD PTR .LC0[rip]
vaddsd xmm0, xmm0, QWORD PTR [rdi]
vcvtsd2ss xmm0, xmm0, xmm0
vcvtss2sd xmm0, xmm0, xmm0
vaddsd xmm0, xmm0, QWORD PTR [rdi+8]
vcvtsd2ss xmm0, xmm0, xmm0
vcvtss2sd xmm0, xmm0, xmm0
vaddsd xmm0, xmm0, QWORD PTR [rdi+16]
vcvtsd2ss xmm0, xmm0, xmm0
vcvtss2sd xmm0, xmm0, xmm0
vaddsd xmm0, xmm0, QWORD PTR [rdi+24]
vcvtsd2ss xmm0, xmm0, xmm0
vcvtss2sd xmm0, xmm0, xmm0
vaddsd xmm0, xmm0, QWORD PTR [rdi+32]
vcvtsd2ss xmm0, xmm0, xmm0
vcvtss2sd xmm0, xmm0, xmm0
vaddsd xmm0, xmm0, QWORD PTR [rdi+40]
vcvtsd2ss xmm0, xmm0, xmm0
vcvtss2sd xmm0, xmm0, xmm0
vaddsd xmm0, xmm0, QWORD PTR [rdi+48]
vcvtsd2ss xmm0, xmm0, xmm0
vcvtss2sd xmm0, xmm0, xmm0
vaddsd xmm0, xmm0, QWORD PTR [rdi+56]
vcvtsd2ss xmm0, xmm0, xmm0
vcvtss2sd xmm0, xmm0, xmm0
vaddsd xmm0, xmm0, QWORD PTR [rdi+64]
vcvtsd2ss xmm0, xmm0, xmm0
vcvtss2sd xmm0, xmm0, xmm0
vaddsd xmm0, xmm0, QWORD PTR [rdi+72]
vcvtsd2ss xmm0, xmm0, xmm0
vcvtss2sd xmm0, xmm0, xmm0
vaddsd xmm0, xmm0, QWORD PTR [rdi+80]
vcvtsd2ss xmm0, xmm0, xmm0
vcvtss2sd xmm0, xmm0, xmm0
vaddsd xmm0, xmm0, QWORD PTR [rdi+88]
vcvtsd2ss xmm0, xmm0, xmm0
vcvtss2sd xmm0, xmm0, xmm0
vaddsd xmm0, xmm0, QWORD PTR [rdi+96]
vcvtsd2ss xmm0, xmm0, xmm0
vcvtss2sd xmm0, xmm0, xmm0
vaddsd xmm0, xmm0, QWORD PTR [rdi+104]
vcvtsd2ss xmm0, xmm0, xmm0
vcvtss2sd xmm0, xmm0, xmm0
vaddsd xmm0, xmm0, QWORD PTR [rdi+112]
vcvtsd2ss xmm0, xmm0, xmm0
vcvtss2sd xmm0, xmm0, xmm0
vaddsd xmm0, xmm0, QWORD PTR [rdi+120]
vcvtsd2ss xmm0, xmm0, xmm0
vcvtss2sd xmm0, xmm0, xmm0
ret
.LC0:
.long 0
.long 1072693248
However more efficient would be:
f:
vcvtpd2ps xmm0, YMMWORD PTR [rdi] #4.5
vcvtpd2ps xmm1, YMMWORD PTR [32+rdi]#4.5
vcvtpd2ps xmm2, YMMWORD PTR [64+rdi]#4.5
vcvtpd2ps xmm3, YMMWORD PTR [96+rdi]#4.5
vaddpsxmm4, xmm0, xmm1 #2.11
vaddpsxmm5, xmm2, xmm3 #2.11
vaddpsxmm6, xmm4, xmm5 #2.11
vmovhlps xmm7, xmm6, xmm6 #2.11
vaddpsxmm8, xmm6, xmm7 #2.11
vshufps xmm9, xmm8, xmm8, 245 #2.11
vaddssxmm10, xmm8, xmm9 #2.11
vaddssxmm0, xmm10, DWORD PTR .L_2il0floatpacket.0[rip] #2.11
vcvtss2sd xmm0, xmm0, xmm0 #5.10
vzeroupper #5.10
ret #5.10
.L_2il0floatpacket.0:
.long 0x3f80
[Bug tree-optimization/79723] Another case of dropped gs: prefix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79723
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2017-02-27
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
;; MEM[(unsigned char * *)vectp_s.11_53] = { 0, 0 };
(insn 34 33 35 (set (reg:V2DI 125)
(const_vector:V2DI [
(const_int 0 [0])
(const_int 0 [0])
])) "t.c":3 -1
(nil))
(insn 35 34 0 (set (mem:V2DI (reg/f:DI 108 [ vectp_s.12 ]) [1 MEM[(unsigned
char * *)vectp_s.11_53]+0 S16 A128])
(reg:V2DI 125)) "t.c":3 -1
(nil))
the MEM_EXPR again has wrong type, only the pointer arg has the address-space
qualifier.
The issue is we pun pointers to scalars in get_vectype_for_scalar_type_and_size
and that loses address-space info.
[Bug target/69617] PowerPC/e6500: Atomic byte/halfword operations not properly supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69617 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-27 CC||segher at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Segher Boessenkool --- rs6000.h has /* Byte/char syncs were added as phased in for ISA 2.06B, but are not present in power7, so conditionalize them on p8 features. TImode syncs need quad memory support. */ #define TARGET_SYNC_HI_QI (TARGET_QUAD_MEMORY \ || TARGET_QUAD_MEMORY_ATOMIC \ || TARGET_DIRECT_MOVE) so someone needs to update this to work for the *500 cores as well.
[Bug tree-optimization/79726] Missing optimisation: Type conversion not vectorised in simple additive reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79726 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-27 Component|c |tree-optimization Blocks||53947 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. We do not handle widen-sum reduction for floating-point (or in general "complex" expressions). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug c++/79727] New: -Wimplicit-fallthrough=3 doesn't seem to match any comments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79727
Bug ID: 79727
Summary: -Wimplicit-fallthrough=3 doesn't seem to match any
comments
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sgunderson at bigfoot dot com
Target Milestone: ---
Hi,
I can't get the supposed fallthrough comments (on
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html) to work:
gcc version 7.0.1 20170226 (experimental) [trunk revision 245744] (Debian
20170226-1)
atum17:~> cat test.cc
#include
#include
int main(int argc, char **argv)
{
switch (argc) {
case 2:
printf("something\n");
// -fallthrough
case 3:
printf("whatever\n");
break;
}
}
atum17:~> /usr/lib/gcc-snapshot/bin/g++ -Wimplicit-fallthrough=3 -c test.cc
test.cc: In function 'int main(int, char**)':
test.cc:8:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
printf("something\n");
~~^~~
test.cc:10:2: note: here
case 3:
^~~~
I've tried a variety of the other patterns that are supposed to match, but I
can't get it to work on level 3. Level 2 appears to work as documented.
[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
--- Comment #19 from Jakub Jelinek ---
The MEM[(struct parser_binder *)&D.614964 + 4B] = f;'s ultimate origin is:
if (D.589607 != 0B)
{
iftmp.77 = try
{
MEM[(struct parser_binder *)D.589607] = f;
^^ This stmt
}
catch
{
operator delete (D.589607, NON_LVALUE_EXPR );
}, (struct parser_binder *) D.589607;;
}
else
{
iftmp.77 = (struct parser_binder *) D.589607;
}
from:
template
void
assign_functor(FunctionObj f, function_buffer& functor, mpl::true_)
const
{
new (reinterpret_cast(&functor.data)) FunctionObj(f);
}
which looks like a placement new into that mutable char data; field of
boost::detail::function::function_buffer, and then the whole union is copied
including the placement new created data in there. No idea if that is valid
C++.
[Bug c++/79727] -Wimplicit-fallthrough=3 doesn't seem to match any comments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79727 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- I don't see a bug; // -fallthrough warns because it doesn't match any of regexps in the manual for the level =3 (it has a space at the beginning). "//-fallthrough" doesn't warn.
[Bug rtl-optimization/64081] [5/6/7 Regression] r217827 prevents RTL loop unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081 Jeffrey A. Law changed: What|Removed |Added Target Milestone|5.5 |8.0 --- Comment #61 from Jeffrey A. Law --- Punting to gcc-8. The patch needs additional work and Aldy is poking at something else at this point. The Aldy's analysis of the AIX issue should allow this to be pushed forward in the gcc-8 development cycle.
[Bug target/79544] vec_sra (unsigned long long,foo) generating vsrd instead of vsrad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79544 --- Comment #2 from Pat Haugen --- Author: pthaugen Date: Mon Feb 27 16:06:13 2017 New Revision: 245762 URL: https://gcc.gnu.org/viewcvs?rev=245762&root=gcc&view=rev Log: PR target/79544 * config/rs6000/rs6000-c.c (struct altivec_builtin_types): Use VSRAD for arithmetic shift of unsigned V2DI. * gcc.target/powerpc/pr79544.c: New. Added: trunk/gcc/testsuite/gcc.target/powerpc/pr79544.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000-c.c trunk/gcc/testsuite/ChangeLog
[Bug c/79728] New: ice in setup_pressure_classes, at ira.c:912
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79728
Bug ID: 79728
Summary: ice in setup_pressure_classes, at ira.c:912
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
The following two lines of code:
$ more bug340.c
register a __asm__("xmm0");
fn1() {}
$
does this with a build of gcc trunk from revision 245750.
bug340.c:2:1: internal compiler error: in setup_pressure_classes, at ira.c:912
fn1() {}
^~~
0x9ed9e8 setup_pressure_classes
../../trunk/gcc/ira.c:912
0x9ed9e8 setup_allocno_and_important_classes
../../trunk/gcc/ira.c:1068
0x9ed9e8 find_reg_classes
../../trunk/gcc/ira.c:1428
0x9ed9e8 ira_init()
../../trunk/gcc/ira.c:1727
This seems to have been going wrong since sometime before revision 236961.
[Bug target/71749] Define _REENTRANT on ARC when -pthread is passed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71749 Claudiu Zissulescu changed: What|Removed |Added CC||claziss at gmail dot com --- Comment #1 from Claudiu Zissulescu --- This is not the place to propose patches. If you want, you can make rework your patch on the current gcc and propose it to gcc-patches. Please cc me to quickly review your patch. Thanks, Claudiu
[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
Jakub Jelinek changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment #20 from Jakub Jelinek ---
I believe this all boils down to:
inline void* operator new(__SIZE_TYPE__, void *p) { return p; }
struct A { A (float x) : f (x) {} float f; };
struct B
{
int x;
union U
{
int a;
char b[sizeof (float)];
} u;
int y;
};
__attribute__((noinline, noclone)) void
bar (B &x, B &y)
{
if (x.x != 0 || x.y != 3 || y.x != 0 || y.y != 3)
__builtin_abort ();
float f;
__builtin_memcpy (&f, x.u.b, sizeof (float));
if (f != 3.5f)
__builtin_abort ();
__builtin_memcpy (&f, y.u.b, sizeof (float));
if (f != 3.5f)
__builtin_abort ();
}
__attribute__((noinline, noclone))
B *
baz (B &x)
{
return &x;
}
__attribute__((noinline, noclone)) void
foo (float x)
{
B b { 0, {}, 3 }, c;
B *p = baz (b);
new (b.u.b) A (x);
c = *p;
bar (*p, c);
}
int
main ()
{
foo (3.5f);
}
which fails also on x86_64-linux at -O2. And that testcase regressed with
r223126. Now whether this is valid C++, no idea, placement new is messy.
[Bug c++/70057] duplicate integer overflow diagnostic in constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70057
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-02-27
Ever confirmed|0 |1
Known to fail||5.3.0, 6.3.0, 7.0
--- Comment #3 from Martin Sebor ---
Confirmed. In GCC 6 and 7 the C++ front end issues not just one or two but
three diagnostics for the test case in comment #0:
$ cat t.C && gcc -S -Wall -Wextra -Wpedantic t.C
template struct S { };
S<(__INT_MAX__ + 1)> s;
t.C:2:16: warning: integer overflow in expression [-Woverflow]
S<(__INT_MAX__ + 1)> s;
^
t.C:2:20: error: overflow in constant expression [-fpermissive]
S<(__INT_MAX__ + 1)> s;
^
t.C:2:20: error: overflow in constant expression [-fpermissive]
t.C:2:20: note: in template argument for type ‘int’
[Bug c/79677] Weird handling of -Werror=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79677
Orion Poplawski changed:
What|Removed |Added
CC||orion at cora dot nwra.com
--- Comment #5 from Orion Poplawski ---
With gcc 7.0.1-0.10.fc26 I'm starting to see errors like:
cc1plus: error: -Wformat-security ignored without -Wformat
[-Werror=format-security]
If this is intended, we're going to need to fix redhat-rpm-config to change:
%__global_compiler_flags -O2 -g -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches %{_hardened_cflags}
to add -Wformat.
[Bug target/79729] New: ICE in ix86_print_operand, at config/i386/i386.c:18231
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79729
Bug ID: 79729
Summary: ICE in ix86_print_operand, at config/i386/i386.c:18231
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gerhard.steinmetz.fort...@t-online.de
Target Milestone: ---
Affects versions down to 4.9.
Reduced from ./gcc.target/sh/pr21255-3.c :
$ cat z1.c
double
f ()
{
double r;
asm ("mov %S1,%S0; mov %R1,%R0" : "=r" (r) : "i" (20));
return r;
}
$ gcc-7-20170226 -c z1.c
z1.c: In function 'f':
z1.c:7:1: internal compiler error: in ix86_print_operand, at
config/i386/i386.c:18231
}
^
0xf79218 ix86_print_operand(_IO_FILE*, rtx_def*, int)
../../gcc/config/i386/i386.c:18231
0x8e118c output_operand(rtx_def*, int)
../../gcc/final.c:3891
0x8e1c67 output_asm_insn(char const*, rtx_def**)
../../gcc/final.c:3788
0x8e3a2d final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../gcc/final.c:2667
0x8e40a2 final(rtx_insn*, _IO_FILE*, int)
../../gcc/final.c:2051
0x8e4859 rest_of_handle_final
../../gcc/final.c:4489
0x8e4859 execute
../../gcc/final.c:4562
[Bug c/79677] Weird handling of -Werror=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79677 --- Comment #7 from Jakub Jelinek --- Or perhaps makefiles filtering away -Wall or using -Wno-all.
[Bug c/79730] New: ICE tree check: expected var_decl, have function_decl in finish_decl, at c/c-decl.c:5063
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79730
Bug ID: 79730
Summary: ICE tree check: expected var_decl, have function_decl
in finish_decl, at c/c-decl.c:5063
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gerhard.steinmetz.fort...@t-online.de
Target Milestone: ---
Affects versions down to 4.9 (configured with --enable-checking=yes) :
$ cat z1.c
register int x() asm ("x");
$ cat z2.c
register float x() asm ("x()");
$ gcc-7-20170226 -c z1.c
z1.c:1:14: error: invalid storage class for function 'x'
register int x() asm ("x");
^
z1.c:1:1: internal compiler error: tree check: expected var_decl, have
function_decl in finish_decl, at c/c-decl.c:5063
register int x() asm ("x");
^~~~
0xea2fcc tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:9815
0x668f71 tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc/tree.h:3064
0x668f71 finish_decl(tree_node*, unsigned int, tree_node*, tree_node*,
tree_node*)
../../gcc/c/c-decl.c:5063
0x6cf8b6 c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:1971
0x6d87fb c_parser_external_declaration
../../gcc/c/c-parser.c:1468
0x6d9259 c_parser_translation_unit
../../gcc/c/c-parser.c:1348
0x6d9259 c_parse_file()
../../gcc/c/c-parser.c:18173
0x737b02 c_common_parse_file()
../../gcc/c-family/c-opts.c:1107
[Bug c/79731] New: ICE: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79731
Bug ID: 79731
Summary: ICE: verify_gimple failed
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gerhard.steinmetz.fort...@t-online.de
Target Milestone: ---
Affects version 7 at -Os, -O1 or higher.
$ cat z1.c
typedef unsigned V __attribute__ ((vector_size (8)));
V
foo (unsigned x, V v)
{
do {
v %= x;
x = 1;
} while (v[1]);
return v;
}
void fn2 ()
{
V x = foo (5, (V) { 0, 1 });
if (x[0] || x[1] || x[2] || x[3]);
}
$ gcc-7-20170226 -O2 -c z1.c
z1.c: In function 'fn2':
z1.c:11:6: error: position plus size exceeds size of referenced object in
BIT_FIELD_REF
void fn2 ()
^~~
BIT_FIELD_REF
z1.c:14:28: note: in statement
if (x[0] || x[1] || x[2] || x[3]);
~^~~
_4 = BIT_FIELD_REF ;
z1.c:11:6: internal compiler error: verify_gimple failed
void fn2 ()
^~~
0xc40f16 verify_gimple_in_cfg(function*, bool)
../../gcc/tree-cfg.c:5266
0xb1a203 execute_function_todo
../../gcc/passes.c:1966
0xb1ab35 execute_todo
../../gcc/passes.c:2016
[Bug c/79677] Weird handling of -Werror=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79677
--- Comment #6 from Jakub Jelinek ---
(In reply to Orion Poplawski from comment #5)
> With gcc 7.0.1-0.10.fc26 I'm starting to see errors like:
>
> cc1plus: error: -Wformat-security ignored without -Wformat
> [-Werror=format-security]
>
> If this is intended, we're going to need to fix redhat-rpm-config to change:
>
> %__global_compiler_flags -O2 -g -pipe -Wall -Werror=format-security
> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
> --param=ssp-buffer-size=4 -grecord-gcc-switches %{_hardened_cflags}
>
> to add -Wformat.
Well, -Wformat is implied by -Wall, so it must be packages doing -Wno-format or
similar. -Wformat -Wformat-security -Wno-format used to warn in the past,
-Wformat -Werror=format-security -Wno-format used to be quite due to a bug, but
now errors out.
We have one instance of this problem in gcc too:
AS_IF([test $enable_build_format_warnings = no],
[wf_opt=-Wno-format],[wf_opt=])
Guess we want there:
AS_IF([test $enable_build_format_warnings = no],
[wf_opt="-Wno-format -Wno-format-security -Wno-format-y2k
-Wno-format-extra-args -Wno-format-zero-length
-Wno-format-nonliteral"],[wf_opt=])
[Bug c/79730] ICE tree check: expected var_decl, have function_decl in finish_decl, at c/c-decl.c:5063
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79730 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-02-27 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- I'll have a look.
[Bug c/79677] Weird handling of -Werror=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79677 --- Comment #8 from Orion Poplawski --- Created attachment 40838 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40838&action=edit /builddir/build/BUILD/cmake-3.7.2/Utilities/KWIML/test/test.c /usr/lib64/ccache/gcc -DKWIML_LANGUAGE_C -DKWIML_LANGUAGE_CXX -I/builddir/build/BUILD/cmake-3.7.2/build/Utilities -I/builddir/build/BUILD/cmake-3.7.2/Utilities -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -Wno-format -std=gnu11 -o CMakeFiles/kwiml_test.dir/test.c.o -c /builddir/build/BUILD/cmake-3.7.2/Utilities/KWIML/test/test.c cc1: error: -Wformat-security ignored without -Wformat [-Werror=format-security] cc1: some warnings being treated as errors I don't see any extra options myself.
[Bug c/79732] New: ICE in set_ssa_default_def, at tree-dfa.c:327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79732
Bug ID: 79732
Summary: ICE in set_ssa_default_def, at tree-dfa.c:327
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gerhard.steinmetz.fort...@t-online.de
Target Milestone: ---
With a mismatch (int/void), down to at least 4.8,
at -Os, -O1 or higher. No ICE seen with 4.9 :
$ cat z1.c
int bar () __attribute__ ((alias ("foo")));
void foo () { }
int main () { return bar(); }
$ gcc-7-20170226 -O2 -c z1.c
z1.c: In function 'main':
z1.c:3:22: internal compiler error: Segmentation fault
int main () { return bar(); }
^
0xbf9f9f crash_signal
../../gcc/toplev.c:337
0xc4fe42 set_ssa_default_def(function*, tree_node*, tree_node*)
../../gcc/tree-dfa.c:327
0xc7e012 expand_call_inline
../../gcc/tree-inline.c:4790
0xc7f4a4 gimple_expand_calls_inline
../../gcc/tree-inline.c:4868
0xc7f4a4 optimize_inline_calls(tree_node*)
../../gcc/tree-inline.c:5008
0x1328d91 early_inliner(function*)
../../gcc/ipa-inline.c:2721
[Bug c/79677] Weird handling of -Werror=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79677 --- Comment #9 from Orion Poplawski --- Ah, just got the -Wno-format
[Bug c++/79734] New: ICE: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79734
Bug ID: 79734
Summary: ICE: verify_gimple failed
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gerhard.steinmetz.fort...@t-online.de
Target Milestone: ---
With version 6/7 (on x86_64 GNU/Linux).
Reduced from ./g++.dg/ext/vector27.C :
$ cat z1.cc
typedef float vecf __attribute__ ((vector_size (4 * sizeof (float;
void g (vecf *a, vecf *b)
{
*a = (*a < 1 && !(*b > 2)) ? *a + *b : 3;
}
$ gcc-7-20170226 -c z1.cc
$ gcc-7-20170226 -mavx512vl -c z1.cc
z1.cc: In function 'void g(vecf*, vecf*)':
z1.cc:2:6: error: mode size of non-integral result does not match field size of
BIT_FIELD_REF
void g (vecf *a, vecf *b)
^
BIT_FIELD_REF <_3, 8, 0>
z1.cc:4:16: note: in statement
*a = (*a < 1 && !(*b > 2)) ? *a + *b : 3;
^
_16 = BIT_FIELD_REF <_3, 8, 0>;
z1.cc:2:6: error: mode size of non-integral result does not match field size of
BIT_FIELD_REF
void g (vecf *a, vecf *b)
^
BIT_FIELD_REF <_17, 8, 0>
z1.cc:4:16: note: in statement
*a = (*a < 1 && !(*b > 2)) ? *a + *b : 3;
^
_18 = BIT_FIELD_REF <_17, 8, 0>;
z1.cc:2:6: error: mode size of non-integral result does not match field size of
BIT_FIELD_REF
void g (vecf *a, vecf *b)
^
BIT_FIELD_REF <_3, 8, 8>
z1.cc:4:16: note: in statement
*a = (*a < 1 && !(*b > 2)) ? *a + *b : 3;
^
_21 = BIT_FIELD_REF <_3, 8, 8>;
z1.cc:2:6: error: mode size of non-integral result does not match field size of
BIT_FIELD_REF
void g (vecf *a, vecf *b)
^
BIT_FIELD_REF <_22, 8, 8>
z1.cc:4:16: note: in statement
*a = (*a < 1 && !(*b > 2)) ? *a + *b : 3;
^
_23 = BIT_FIELD_REF <_22, 8, 8>;
z1.cc:2:6: error: mode size of non-integral result does not match field size of
BIT_FIELD_REF
void g (vecf *a, vecf *b)
^
BIT_FIELD_REF <_3, 8, 16>
z1.cc:4:16: note: in statement
*a = (*a < 1 && !(*b > 2)) ? *a + *b : 3;
^
_26 = BIT_FIELD_REF <_3, 8, 16>;
z1.cc:2:6: error: mode size of non-integral result does not match field size of
BIT_FIELD_REF
void g (vecf *a, vecf *b)
^
BIT_FIELD_REF <_27, 8, 16>
z1.cc:4:16: note: in statement
*a = (*a < 1 && !(*b > 2)) ? *a + *b : 3;
^
_28 = BIT_FIELD_REF <_27, 8, 16>;
z1.cc:2:6: error: mode size of non-integral result does not match field size of
BIT_FIELD_REF
void g (vecf *a, vecf *b)
^
BIT_FIELD_REF <_3, 8, 24>
z1.cc:4:16: note: in statement
*a = (*a < 1 && !(*b > 2)) ? *a + *b : 3;
^
_31 = BIT_FIELD_REF <_3, 8, 24>;
z1.cc:2:6: error: mode size of non-integral result does not match field size of
BIT_FIELD_REF
void g (vecf *a, vecf *b)
^
BIT_FIELD_REF <_32, 8, 24>
z1.cc:4:16: note: in statement
*a = (*a < 1 && !(*b > 2)) ? *a + *b : 3;
^
_33 = BIT_FIELD_REF <_32, 8, 24>;
z1.cc:2:6: internal compiler error: verify_gimple failed
void g (vecf *a, vecf *b)
^
0xe2dfc6 verify_gimple_in_cfg(function*, bool)
../../gcc/tree-cfg.c:5266
0xd0f823 execute_function_todo
../../gcc/passes.c:1966
0xd10155 execute_todo
../../gcc/passes.c:2016
[Bug c/79733] New: ICE in int_mode_for_mode, at stor-layout.c:406
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79733 Bug ID: 79733 Summary: ICE in int_mode_for_mode, at stor-layout.c:406 Product: gcc Version: 7.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- With testfile ./gcc.target/i386/avx512f-kortestw-2.c, down to version 4.9, at -Os|1|2|3 and with one of -mavx512f -mavx512pf -mavx512er -mavx512cd -mavx512vl -mavx512bw -mavx512dq -mavx512ifma -mavx512vbmi $ gcc-7-20170226 -O2 -mavx512f -c avx512f-kortestw-1.c In file included from .../gcc/x86_64-pc-linux-gnu/7.0.1/include/immintrin.h:45:0, from avx512f-kortestw-1.c:5: .../gcc/x86_64-pc-linux-gnu/7.0.1/include/avx512fintrin.h: In function 'avx512f_test': .../gcc/x86_64-pc-linux-gnu/7.0.1/include/avx512fintrin.h:10095:10: internal compiler error: in int_mode_for_mode, at stor-layout.c:406 return (__mmask16) __builtin_ia32_kortestchi ((__mmask16) __A, ^~~ (__mmask16) __B); 0xbe8a9f int_mode_for_mode(machine_mode) ../../gcc/stor-layout.c:406 0x8bccae emit_move_via_integer ../../gcc/expr.c:3289 0x8c9a7a emit_move_insn_1(rtx_def*, rtx_def*) ../../gcc/expr.c:3670 0x8c9dd4 emit_move_insn(rtx_def*, rtx_def*) ../../gcc/expr.c:3738 0x8ad0f2 copy_to_reg(rtx_def*) ../../gcc/explow.c:585 0xf6d4d1 ix86_expand_builtin ../../gcc/config/i386/i386.c:37800 0x793606 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int) ../../gcc/builtins.c:6362 0x8c5a14 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/expr.c:10810 0x8d1be6 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool, tree_node*) ../../gcc/expr.c:5552 0x8d37d0 expand_assignment(tree_node*, tree_node*, bool) ../../gcc/expr.c:5321 0x7b7cfa expand_call_stmt ../../gcc/cfgexpand.c:2656 0x7b7cfa expand_gimple_stmt_1 ../../gcc/cfgexpand.c:3571 0x7b7cfa expand_gimple_stmt ../../gcc/cfgexpand.c:3737 0x7b998e expand_gimple_basic_block ../../gcc/cfgexpand.c:5744 0x7bfa56 execute ../../gcc/cfgexpand.c:6357
[Bug c/79730] ICE tree check: expected var_decl, have function_decl in finish_decl, at c/c-decl.c:5063
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79730 --- Comment #2 from Marek Polacek --- Started with commit 2be90eed86f43591d0e182b258156356abb7f18f Author: rguenth Date: Wed Jul 6 14:05:54 2011 + 2011-07-06 Richard Guenther PR tree-optimization/49645 * c-decl.c (finish_decl): Also set DECL_HARD_REGISTER for global register variables. * tree-ssa-sccvn.c (vn_reference_op_eq): Disregard differences in type qualification here ... (copy_reference_ops_from_ref): ... not here. (vn_reference_lookup_3): ... or here. (copy_reference_ops_from_ref): Record decl bases as MEM[&decl]. (vn_reference_lookup): Do the lookup with a valueized ao-ref. * g++.dg/tree-ssa/pr8781.C: Disable SRA. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@175916 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug c/79730] [5/6/7 Regression] ICE tree check: expected var_decl, have function_decl in finish_decl, at c/c-decl.c:5063
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79730 Marek Polacek changed: What|Removed |Added Keywords||error-recovery, ||ice-on-invalid-code Target Milestone|--- |5.5 Summary|ICE tree check: expected|[5/6/7 Regression] ICE tree |var_decl, have |check: expected var_decl, |function_decl in|have function_decl in |finish_decl, at |finish_decl, at |c/c-decl.c:5063 |c/c-decl.c:5063
[Bug c/79731] [7 Regression] ICE: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79731 Marek Polacek changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-27 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |7.0 Summary|ICE: verify_gimple failed |[7 Regression] ICE: ||verify_gimple failed Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Started with r236630.
[Bug c/79732] [5/6/7 Regression] ICE in set_ssa_default_def, at tree-dfa.c:327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79732 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-27 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |5.5 Summary|ICE in set_ssa_default_def, |[5/6/7 Regression] ICE in |at tree-dfa.c:327 |set_ssa_default_def, at ||tree-dfa.c:327 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Started with r211356.
[Bug c/79732] [5/6/7 Regression] ICE in set_ssa_default_def, at tree-dfa.c:327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79732 --- Comment #2 from Marek Polacek --- No warning issued, but it doesn't look valid?
[Bug c/79733] ICE in int_mode_for_mode, at stor-layout.c:406
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79733 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- I don't see this ICE.
[Bug c/79677] Weird handling of -Werror=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79677
--- Comment #10 from Orion Poplawski ---
I'm not sure how I'm practically supposed to handle this. In this case, for
one sub-directory upstream adds -Wno-format to the flags:
./Utilities/KWIML/test/CMakeLists.txt:set(CMAKE_${lang}_FLAGS
"${CMAKE_${lang}_FLAGS} -Wno-format")
Is this still a bug in gcc?
[Bug c++/79734] [6/7 Regression] ICE: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79734 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-27 CC||mpolacek at gcc dot gnu.org Summary|ICE: verify_gimple failed |[6/7 Regression] ICE: ||verify_gimple failed Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Started with r231553.
[Bug c++/79734] [6/7 Regression] ICE: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79734 Marek Polacek changed: What|Removed |Added Target Milestone|--- |6.4
[Bug c/79677] Weird handling of -Werror=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79677
--- Comment #11 from Jakub Jelinek ---
It is not a GCC bug, the general rule is that the options that enable
suboptions don't change those (either way) if that option has been specified
explicitly.
So, -Wformat -Wformat-security -Wno-format does not disable -Wformat-security,
but e.g. disables -Wformat-y2k because that option has not been set explicitly.
So, either you change that
set(CMAKE_${lang}_FLAGS "${CMAKE_${lang}_FLAGS} -Wno-format")
to
set(CMAKE_${lang}_FLAGS "${CMAKE_${lang}_FLAGS} -Wno-format
-Wno-format-security")
or e.g. strip off -Werror=format-security from RPM_OPT_FLAGS.
[Bug c/79677] Weird handling of -Werror=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79677 --- Comment #12 from Orion Poplawski --- Adding -Wno-format-security does indeed work. Thank you.
[Bug c/79733] ICE in int_mode_for_mode, at stor-layout.c:406
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79733 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Indeed, not reproduceable here either. That test is invoked with -O2 -mavx512f every time anyone does make check on x86_64-linux (unless using prehistoric binutils).
[Bug c/79731] [7 Regression] ICE: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79731 Jakub Jelinek changed: What|Removed |Added Keywords|ice-on-valid-code |error-recovery Priority|P3 |P4 CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- This is invalid code.
[Bug c/79731] [7 Regression] ICE: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79731 Jakub Jelinek changed: What|Removed |Added Keywords|error-recovery |ice-checking Priority|P4 |P3 --- Comment #3 from Jakub Jelinek --- While it is invalid, the diagnostics is just in checking. I guess we should leave that to -Warray-bounds diagnostics and just not try to optimize the UB in there.
[Bug target/79729] ICE in ix86_print_operand, at config/i386/i386.c:18231
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79729 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Jakub Jelinek --- Dup of a bug you've filed yourself. *** This bug has been marked as a duplicate of bug 79559 ***
[Bug target/79559] [5/6 Regression] ICE in ix86_print_operand, at config/i386/i386.c:18189
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79559 --- Comment #6 from Jakub Jelinek --- *** Bug 79729 has been marked as a duplicate of this bug. ***
[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
--- Comment #21 from rguenther at suse dot de ---
On February 27, 2017 5:46:44 PM GMT+01:00, "jakub at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
>
>Jakub Jelinek changed:
>
> What|Removed |Added
>
>CC||redi at gcc dot gnu.org
>
>--- Comment #20 from Jakub Jelinek ---
>I believe this all boils down to:
>inline void* operator new(__SIZE_TYPE__, void *p) { return p; }
>struct A { A (float x) : f (x) {} float f; };
>struct B
>{
> int x;
> union U
> {
>int a;
>char b[sizeof (float)];
> } u;
> int y;
>};
>
>__attribute__((noinline, noclone)) void
>bar (B &x, B &y)
>{
> if (x.x != 0 || x.y != 3 || y.x != 0 || y.y != 3)
>__builtin_abort ();
> float f;
> __builtin_memcpy (&f, x.u.b, sizeof (float));
> if (f != 3.5f)
>__builtin_abort ();
> __builtin_memcpy (&f, y.u.b, sizeof (float));
> if (f != 3.5f)
>__builtin_abort ();
>}
>
>__attribute__((noinline, noclone))
>B *
>baz (B &x)
>{
> return &x;
>}
>
>__attribute__((noinline, noclone)) void
>foo (float x)
>{
> B b { 0, {}, 3 }, c;
> B *p = baz (b);
> new (b.u.b) A (x);
> c = *p;
> bar (*p, c);
>}
>
>int
>main ()
>{
> foo (3.5f);
>}
>
>which fails also on x86_64-linux at -O2. And that testcase regressed
>with
>r223126. Now whether this is valid C++, no idea, placement new is
>messy.
We have one or two duplicates that were resolved invalid. We can't reasonably
support this in the ME anyway and the lvalue used to access this is not one of
those listed compatible with A.
[Bug bootstrap/77661] --enable-maintainer-mode causes in-tree-build of MPC to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77661 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-27 CC||tkoenig at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Thomas Koenig --- Same thing happened to me. Is it possible to get the patch committed?
[Bug c++/79735] New: C++14: syntax error in attribute deprecated silently ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79735
Bug ID: 79735
Summary: C++14: syntax error in attribute deprecated silently
ignored
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: becker.bernd at gmx dot net
Target Milestone: ---
A malformed deprecated attribute expression is silently ignored. g++ compiles
to a.out and does neither show the deprecated warning nor an error. In the
following code if the closing parenthesis is left out the deprecated warning
disappears, a.out is generated but no error is shown:
#include
class [[deprecated("some text")]] Test {
};
int main( int, char**) {
Test t;
return 0;
}
Correct output is (German locale):
/local/gcc7/bin/g++ --std=c++14 test.cpp
test.cpp: In Funktion »int main(int, char**)«:
test.cpp:7:8: Warnung: »Test« ist veraltet: some text
[-Wdeprecated-declarations]
Test t;
^
test.cpp:3:35: Anmerkung: hier deklariert
class [[deprecated("some text")]] Test {
^~~~
changing line 3 to this ( missing ')' ):
class [[deprecated("some text"]] Test {
results into a successful compile run without warning.
I observed the same problem with gcc 5.4 and
g++-6 (SUSE Linux) 6.2.1 20160826 [gcc-6-branch revision 239773]
[Bug c++/79735] C++14: syntax error in attribute deprecated silently ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79735 --- Comment #1 from Bernd Becker --- Filed based on g++ (GCC) 7.0.1 20170226 (experimental)
[Bug target/79559] [5/6 Regression] ICE in ix86_print_operand, at config/i386/i386.c:18189
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79559 --- Comment #7 from Gerhard Steinmetz --- Using version gcc-7-20170226, above cases compile on my environment, too. But pr79729 does not (yes, appending to this pr would have been better).
[Bug c/66970] Add __has_builtin() macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66970 kim.walisch at gmail dot com changed: What|Removed |Added CC||kim.walisch at gmail dot com --- Comment #6 from kim.walisch at gmail dot com --- > Why do you need this? 1) Because clang already supports it and people like myself would like to simplify their code i.e. have a single macro for both GCC and clang. 2) Without this macro one needs to check if a __builtin_* macro exists using the build system (Autotools, CMake) which requires more complicated code or one needs a nasty macro which checks the __GNUC__ and __GNUC_MINOR__ versions. The __has_attribute() macro is much more elegant than the other two options. > You still need to check for older versions of the > compilers (which don't support __has_attribute()) anyways. Not everybody needs to support old compiler versions. My company regularly upgrades to the latest Linux version. After such an upgrade we are allowed to use new compiler features. There are also lots of developers out there who only care if their program compiles with a fairly recent compiler (e.g. not older than 5 years). If GCC would implement __has_attribute() today than it would become very useful in just a few years.
[Bug c++/71568] Inexplicable error: "X is inaccessible within this context" for a public member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71568 --- Comment #5 from Jason Merrill --- Author: jason Date: Mon Feb 27 20:17:17 2017 New Revision: 245763 URL: https://gcc.gnu.org/viewcvs?rev=245763&root=gcc&view=rev Log: PR c++/71568 - SFINAE forming pointer to member function * init.c (build_offset_ref): Check the return value of perform_or_defer_access_check. Added: trunk/gcc/testsuite/g++.dg/cpp0x/sfinae58.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/init.c
[Bug c++/71568] Inexplicable error: "X is inaccessible within this context" for a public member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71568 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.0 --- Comment #6 from Jason Merrill --- I decided that it's safe enough.
[Bug c++/79736] New: Please submit a full bug report: unable to create precompiled headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79736 Bug ID: 79736 Summary: Please submit a full bug report: unable to create precompiled headers Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: x800x800 at email dot cz Target Milestone: --- g++ is unable to precompile header file from PCL library. The eader file hdr.h contains only one line to reproduce problem: "#include " and command is "g++ -I /opt/pcl/pcl-1.8/include/pcl-1.8/ -I /usr/include/eigen3/ -I /usr/include/vtk-5.10/ hdr.h". Compiler is g++ 5.4 in the Ubuntu 16.04, PCL library 1.8 and 1.7 has the same problem. The full compiler output is: In file included from /usr/include/eigen3/Eigen/Geometry:44:0, from /opt/pcl/include/pcl-1.8/pcl/correspondence.h:47, from /opt/pcl/include/pcl-1.8/pcl/visualization/pcl_visualizer.h:42, from stdafx.h:10: /usr/include/eigen3/Eigen/src/Geometry/Transform.h: In instantiation of ‘Eigen::Transform::Transform(const Eigen::Transform<_Scalar, Dim, Mode, OtherOptions>&) [with int OtherOptions = 0; _Scalar = float; int _Dim = 3; int _Mode = 2; int _Options = 0]’: /usr/include/eigen3/Eigen/src/Geometry/Transform.h:312:10: required by substitution of ‘template Eigen::Transform::Transform(const Eigen::Transform<_Scalar, Dim, Mode, OtherOptions>&) [with int OtherOptions = 0]’ /opt/pcl/include/pcl-1.8/pcl/common/eigen.h:354:14: required from here /usr/include/eigen3/Eigen/src/Geometry/Transform.h:312:10: internal compiler error: Segmentation fault inline Transform(const Transform& other) ^ Please submit a full bug report, with preprocessed source if appropriate. See for instructions.
[Bug tree-optimization/79737] New: wrong code at -O2 and -O3 on x86_64-linux-gnu (in both 32-bit and 64-bit modes)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79737
Bug ID: 79737
Summary: wrong code at -O2 and -O3 on x86_64-linux-gnu (in both
32-bit and 64-bit modes)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
This appears to be a recent regression.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.1 20170227 (experimental) [trunk revision 245750] (GCC)
$
$ gcc-trunk -Os small.c; ./a.out
0
$ gcc-trunk -O2 small.c; ./a.out
31
$
--
int printf (const char *, ...);
#pragma pack(1)
struct S
{
int b:18;
int c:1;
int d:24;
int e:15;
int f:14;
} i;
int g, j, k;
static struct S h;
void fn1 ()
{
for (j = 0; j < 6; j++)
k = 0;
for (; k < 3; k++)
{
struct S m = { 5, 0, -5, 9, 5 };
h = m;
if (g)
i = m;
h.e = 0;
}
}
int main ()
{
fn1 ();
printf ("%d\n", h.e);
return 0;
}
[Bug web/79738] New: Documentation for __attribute__((const)) slightly misleading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79738
Bug ID: 79738
Summary: Documentation for __attribute__((const)) slightly
misleading
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: web
Assignee: unassigned at gcc dot gnu.org
Reporter: m-gccbugs at bodyfour dot uk
Target Milestone: ---
Looking at the description of __attribute__((const)) at:
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes
"Basically this is just slightly more strict class than the pure attribute
below, since function is not allowed to read global memory."
That's almost correct -- it's not allowed to read memory that can change. You
could argue that "global" implies the .data space, but to a lay programmer it
would suggest you can't do any memory reads except on your own stack.
To take a trivial example, it's fine for this to be ((const)):
static const int TABLE[] = { 1, 2, 3 };
extern int lookup(unsigned x) __attribute__((const));
int lookup(unsigned x)
{
return TABLE[x];
}
...and if fact, -Wsuggest-attribute=const will warn if you don't have the
attribute there.
I suggest amending the documentation to say "...is not allowed to read from any
memory location whose contents can change between calls"
[Bug tree-optimization/79737] wrong code at -O2 and -O3 on x86_64-linux-gnu (in both 32-bit and 64-bit modes)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79737 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-27 CC||mpolacek at gcc dot gnu.org Version|unknown |7.0 Target Milestone|--- |7.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Since r241649 the program prints 255 and since r241779 it prints 31.
[Bug fortran/79739] New: ICE with some interesting code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79739 Bug ID: 79739 Summary: ICE with some interesting code Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jvdelisle at gcc dot gnu.org Target Milestone: --- Three files. While testing some threading concept. Note: This is not an actual coarray program. Compile with: gfortran -fopenmp cafmain.f90 cafi.f90 caf.f90 Compiles and runs fine with gfortran 6.3, Latest trunk fails on compile. cafi.f90: module cafi !! Implement ../libcaf.h, mapping each imagee to an OpenMP thread use iso_c_binding, only : c_int,c_char,c_ptr implicit none private public :: this_image public :: num_images public :: caf_init public :: caf_finalize character(len=8,kind=c_char), parameter :: prefix="_gfortran_" interface module subroutine caf_init(argc,argv) bind(C,name="_gfortran_caf_init") !! Fork all threads implicit none type(c_ptr), value :: argc, argv end subroutine module subroutine caf_finalize() bind(C,name="_gfortran_caf_finalize") !! Join all threads implicit none end subroutine module subroutine caf_register() bind(C,name="_gfortran_caf_register") !! Register implicit none end subroutine module function this_image() bind(C,name="_gfortran_caf_this_image") result(image_num) !! Return the thread number as the image number implicit none integer(c_int) :: image_num end function module function num_images() bind(C,name="_gfortran_caf_num_images") result(num_images_) !! Return the number of threads as the number of images implicit none integer(c_int) :: num_images_ end function end interface end module cafi caf.f90: submodule(cafi) cafimp implicit none contains module procedure caf_init end procedure module procedure caf_finalize end procedure module procedure this_image use omp_lib, only : omp_get_thread_num image_num = omp_get_thread_num() + 1 end procedure module procedure num_images use omp_lib, only : omp_get_num_threads num_images_ = omp_get_num_threads() end procedure module procedure caf_register end procedure end submodule caf_main.f90: module cafomp use cafi public :: cafrun procedure(), pointer :: myapp interface module function cafrun (cafapp) procedure(), pointer :: cafapp end function end interface contains function cafrun(cafapp) integer :: cafrun !$omp parallel call cafapp !$omp end parallel cafrun = 0 end function end module cafomp program hello use cafomp implicit none integer :: run myapp => userstuff run = cafrun ( myapp ) contains subroutine userstuff print *, "Greetings from image ",this_image()," of ",num_images() end subroutine end program
