[Bug libstdc++/77776] C++17 std::hypot implementation is poor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6 --- Comment #6 from Matthias Kretz --- (In reply to Marc Glisse from comment #4) > Your "reference" number seems strange. Why not do the computation with > double (or long double or mpfr) or use __builtin_hypotf? Note that it > changes the value. Doh. (I didn't know the builtin exists. But use of (long) double should have been a no-brainer.) I guess my point was the precision of the input to sqrt not the result of sqrt. The sqrt makes that error almost irrelevant, though. My numerical analysis skills are not good enough to argue for what approach is better. But intuitively, keeping the information of the `amax` mantissa for the final multiplication around might actually make that approach slightly better (if the input to the sqrt were precise that wouldn't be true, though - but it never is). > How precise is hypot supposed to be? I know it is supposed to try and avoid > spurious overflow/underflow, but I am not convinced that it should aim for > correct rounding. That's a good question for all of / . Any normative wording on that question would be (welcome) news to me. AFAIK precision is left completely as QoI. So, except for the Annex F requirements (which we can drop with -ffast-math), let's implement all of as `return 0;`. ;-) > (I see that you are using clang in that godbolt link, with gcc I need to > mark the global variables with "extern const" to get a similar asm) Thanks for the hint. I switched to clang when GCC started to produce code instead of constants in the asm. (I also like the unicode identifier support in clang ;-))
[Bug tree-optimization/88739] [7/8/9 Regression] Big-endian union bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739 --- Comment #39 from rguenther at suse dot de --- On Wed, 9 Jan 2019, wilco at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739 > > --- Comment #34 from Wilco --- > With just the expr.c patch the gcc regression tests all pass on big-endian > AArch64. Interestingly this includes the new torture test, ie. it does not > trigger the union bug. Does it still pass if you apply the tree-ssa-sccvn.c patch or does that break things again? I'm somewhat confused that only the expr.c fix is enough...
[Bug c/88774] Qualification of parameters does not change a function type: Bug or standard defect?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88774 --- Comment #2 from Jonathan Wakely --- Yes, that's consistent with how C++ handles top-level cv-qualifiers in function parameters.
[Bug tree-optimization/88739] [7/8/9 Regression] Big-endian union bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #40 from rguenther at suse dot de ---
On Wed, 9 Jan 2019, rsandifo at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
>
> rsandifo at gcc dot gnu.org changed:
>
>What|Removed |Added
>
> CC||rsandifo at gcc dot gnu.org
>
> --- Comment #35 from rsandifo at gcc dot gnu.org gnu.org> ---
> Yeah, the expr.c patch makes the original testcase work, but we still fail
> for:
>
> #include
> typedef unsigned int U32;
> typedef unsigned short U16;
> typedef unsigned char U8;
>
> typedef struct MEM_HEAD_4DW
> {
> /* first word */
> U32 b11 : 1;
> U32 b12 : 3;
> U32 b13 : 3;
> U32 b14 : 1;
> U32 b15 : 16;
> U32 b16 : 8;
>
> /* second word */
> U32 b21 : 16;
> U32 b22 : 1;
> U32 b23 : 4;
> U32 b24 : 11;
>
> /* third word */
> U32 b31 : 32;
>
> /* fourth word */
> U32 b30AddrL : 30;
> U32 b2AddrType: 2;
> }MEM_REQ_HEAD_4DW;
>
> typedef union HEAD_DW4_UNION
> {
> MEM_REQ_HEAD_4DW strMemHead;
> U32 aulValue[4];
> U16 ausValue[8];
> U8 aucValue[16];
> }HEAD_REQ_DW4_UNION;
>
>
>
> U32 Test_func(U32 ulAddr)
> {
> HEAD_REQ_DW4_UNION unData;
>
> unData.strMemHead.b30AddrL= ulAddr >> 2;
> unData.strMemHead.b2AddrType = 0;
> printf("unData.ausValue[6]=0x%x\r\n",unData.ausValue[6]); // why get
> 0x0 instead of 0x1 ?
>
> return 0;
> }
>
> int main()
>
> {
> Test_func(0x10224);
> return 0;
> }
>
> Like Wilco says, the torture test seems to pass with an unpatched compiler
> (but
> seems like a good thing to have anyway).
Yeah, the torture test fails to have the "large" store being a bitfield
one. I'll see if I can reasonably extend the testcase to covert this
case. Or rather add variants of the testcase.
Richard.
[Bug libstdc++/88782] Crash when mixing make_shared from gcc <= 8.2 with make_shared from gcc >= 8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88782 --- Comment #1 from Jonathan Wakely --- That's wrong in exactly the cases r266380 was meant to solve.
[Bug libstdc++/88782] Crash when mixing make_shared from gcc <= 8.2 with make_shared from gcc >= 8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88782 --- Comment #2 from Jonathan Wakely --- I think I might need to rename _S_ti() so that old callers will get an old definition of it that matches what they expect, and new callers of the new function won't care what _S_ti() does.
[Bug tree-optimization/88739] [7/8/9 Regression] Big-endian union bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #41 from rguenther at suse dot de ---
On Wed, 9 Jan 2019, rsandifo at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
>
> --- Comment #38 from rsandifo at gcc dot gnu.org gnu.org> ---
> Created attachment 45392
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45392&action=edit
> patch that changes get_ref_base_and_extent for bare SSA_NAMEs
>
> (In reply to Wilco from comment #37)
> > (In reply to rsand...@gcc.gnu.org from comment #35)
> > > Yeah, the expr.c patch makes the original testcase work, but we still fail
> > > for:
> >
> > That's the folding in ccp1 after inlining, which will require a similar fix.
> > There are likely more places that need to be fixed to handle the 'short' bit
> > types.
>
> Yeah, seems like a can of worms.
>
> The expr.c approach treats a reference to an N-bit integer in an
> M>N-bit mode is relative to M rather than N (i.e. it's relative
> to the addressable storage.) So maybe the point this goes wrong
> is when we ask for get_ref_base_and_extent on a bare 30-bit SSA_NAME
> (no component accesses) and get back an offset of 0. If everything's
> relative to the addressable storage then maybe it should be 2 for
> big-endian?
>
> The attached patch does that and seems to pass all three tests
> in the PR so far. I'll give a spin overnight just in case
> it's at least vaguely sensible.
I considered this. I guess we need to document this somewhere
though. Incidentially the GIMPLE verifier already does
if (!AGGREGATE_TYPE_P (TREE_TYPE (op))
&& maybe_gt (size + bitpos,
tree_to_poly_uint64 (TYPE_SIZE (TREE_TYPE
(op)
{
error ("position plus size exceeds size of referenced object
in "
"BIT_FIELD_REF");
return true;
}
so it uses TYPE_SIZE and not TYPE_PREICISON to verify the bounds of
the BIT_FIELD_REF access.
That said we should probably have exhaustive testing on this.
Maybe simply try to add GIMPLE testcases exercising the
BIT_FIELD_REF of bit-precision entities case.
I also wonder whether for the GIMPLE checking we want to verify
that for bit-precision OP the extracted range is within what
is valid (which depends on endianess then?).
[Bug tree-optimization/88775] [8/9 Regression] Optimize std::string assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88775 --- Comment #2 from Jonathan Wakely --- Probably not. I don't think sanitizers flag the unspecified comparisons, so we could just always do the uintptr_t comparisons for C++98/11. The patch looks good to me.
[Bug tree-optimization/87314] pointless comparison of malloc result to a string not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87314
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #4 from Richard Biener ---
Created attachment 45399
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45399&action=edit
patch for the string cases
OK, these special cases could be handled easily. They should already
be covered by
/* When the addresses are not directly of decls compare base and offset.
This implements some remaining parts of fold_comparison address
comparisons but still no complete part of it. Still it is good
enough to make fold_stmt not regress when not dispatching to fold_binary.
*/
(for cmp (simple_comparison)
(simplify
(cmp (convert1?@2 addr@0) (convert2? addr@1))
(with
but we fall into
(if (equal == 0
&& DECL_P (base0) && DECL_P (base1)
/* If we compare this as integers require equal offset. */
&& (!INTEGRAL_TYPE_P (TREE_TYPE (@2))
|| known_eq (off0, off1)))
(switch
(if (cmp == EQ_EXPR)
{ constant_boolean_node (false, type); })
(if (cmp == NE_EXPR)
{ constant_boolean_node (true, type); })
which only handles decl vs. decl.
I'm not sure how to handle "foo" ==/!= "foo" though, dependent on string
merging they could be either equal or not equal. I guess similar
for "foobar"+3 and "bar"?
So sth like the attached which is conservative about string-merging (delaying
to runtime).
[Bug tree-optimization/88775] [8/9 Regression] Optimize std::string assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88775 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |8.3
[Bug tree-optimization/88786] New: Expand vector copysign (and xorsign) operations in the vectoriser
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88786 Bug ID: 88786 Summary: Expand vector copysign (and xorsign) operations in the vectoriser Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ktkachov at gcc dot gnu.org CC: rsandifo at gcc dot gnu.org Target Milestone: --- Currently every target defines the copysign optab for vector modes to emit very similar sequences of extracting the sign bit in RTL. This leads to almost identical code for AArch64 Adv SIMD, SVE, aarch32 NEON etc. We should teach the vectoriser to expand a vector copysign operation at the tree level to benefit from more optimisations early on. Care needs to be taken to make sure the xorsign optimisation (currently done late in widen_mult) still triggers for vectorised code. This will allow us to a lot of duplicate code in the MD patterns and only implement them if the target can actually do a smarter sequence than the default. This is similar in principle to the multiplication-by-constant expansion we already do in tree-vect-patterns.c See, for example, the gcc.target/aarch64/vect-xorsign_exec.c testcase for the kind of input for this.
[Bug c++/88787] New: [9 regression] C++ constexpr seems to not get expanded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88787 Bug ID: 88787 Summary: [9 regression] C++ constexpr seems to not get expanded Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tnfchris at gcc dot gnu.org Target Milestone: --- Target: arm-none-linux-gnueabihf The following testcases from libstdc++ have started failing in the past few days on trunk: FAIL: 27_io/filesystem/operations/last_write_time.cc execution test FAIL: 30_threads/future/cons/constexpr.cc scan-assembler-not _ZNSt6futureIiEC2Ev FAIL: 30_threads/future/cons/constexpr.cc scan-assembler-not _ZNSt6futureIvEC2Ev FAIL: 30_threads/shared_future/cons/constexpr.cc scan-assembler-not _ZNSt13shared_futureIiEC2Ev FAIL: 30_threads/shared_future/cons/constexpr.cc scan-assembler-not _ZNSt13shared_futureIvEC2Ev Looking into the tests, it seems that the expression is not evaluated at compile time as expected anymore but instead are being created dynamically. e.g. the code contains the inline constructor and destructors and calls to them.
[Bug c/88568] [7/8/9 Regression] 'dllimport' no longer implies 'extern' in C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88568 --- Comment #8 from jon_y <10walls at gmail dot com> --- I've used a linux hosted mingw toolchain to build a mingw toolchain from the same sources, it seems to be working fine. I've only enabled C and C++.
[Bug tree-optimization/88775] [8/9 Regression] Optimize std::string assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88775 --- Comment #3 from Richard Biener --- So the if (__x.7_6 < __y.8_7) goto ; [50.00%] else goto ; [50.00%] [local count: 38463891]: if (__x.7_6 > __y.8_7) goto ; [50.00%] else goto ; [50.00%] fails to merge to != because at the time we run ifcombine it still looks like _4 = _3 > "hello"; _5 = __builtin_constant_p (_4); if (_5 != 0) goto ; [34.00%] else goto ; [66.00%] [local count: 708669605]: __x.5_6 = (long unsigned int) "hello"; __y.6_7 = (long unsigned int) _3; _8 = __x.5_6 < __y.6_7; [local count: 1073741824]: # _9 = PHI <_4(2), _8(3)> if (_9 != 0) goto ; [50.00%] else goto ; [50.00%] [local count: 536870913]: _10 = _3 < "hello"; _11 = __builtin_constant_p (_10); if (_11 != 0) goto ; [34.00%] else goto ; [66.00%] [local count: 354334802]: __x.5_12 = (long unsigned int) _3; __y.6_13 = (long unsigned int) "hello"; _14 = __x.5_12 < __y.6_13; [local count: 536870913]: # _15 = PHI <_10(5), _14(6)> if (_15 != 0) goto ; [50.00%] else goto ; [50.00%] but maybe that is what Jakubs patch fixes.
[Bug libstdc++/88782] [8/9 Regression] Crash when mixing make_shared from gcc <= 8.2 with make_shared from gcc >= 8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88782 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-01-10 Known to work||8.2.0 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Summary|Crash when mixing |[8/9 Regression] Crash when |make_shared from gcc <= 8.2 |mixing make_shared from gcc |with make_shared from gcc |<= 8.2 with make_shared |>= 8.3 |from gcc >= 8.3 Ever confirmed|0 |1 Known to fail||8.2.1, 9.0
[Bug ipa/88788] New: [9 Regression] Infinite loop in malloc_candidate_p_1 since r264838
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88788 Bug ID: 88788 Summary: [9 Regression] Infinite loop in malloc_candidate_p_1 since r264838 Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: compile-time-hog Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: marxin at gcc dot gnu.org, prathamesh3492 at gcc dot gnu.org Target Milestone: --- Created attachment 45400 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45400&action=edit test-case Since the revision the testcase (isolated from libstorage-ng) causes timeout (300s), which the previous revision compiled the test-case in ~150s. Command: $ g++ spinning2.ii -c -O2 -Wno-deprecated-declarations
[Bug ipa/88788] [9 Regression] Infinite loop in malloc_candidate_p_1 since r264838
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88788
Martin Liška changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED |NEW
Known to work||8.2.0
Keywords||needs-reduction
Last reconfirmed||2019-01-10
Ever confirmed|0 |1
Target Milestone|--- |9.0
Known to fail||9.0
--- Comment #1 from Martin Liška ---
Patch that can trigger ICE:
diff --git a/gcc/ipa-pure-const.c b/gcc/ipa-pure-const.c
index ba0c7c2d83e..3481719aa9d 100644
--- a/gcc/ipa-pure-const.c
+++ b/gcc/ipa-pure-const.c
@@ -878,8 +878,10 @@ check_retval_uses (tree retval, gimple *stmt)
}
static bool
-malloc_candidate_p_1 (function *fun, tree retval, gimple *ret_stmt, bool ipa)
+malloc_candidate_p_1 (function *fun, tree retval, gimple *ret_stmt, bool ipa,
+ int depth)
{
+ gcc_assert (depth < 40);
cgraph_node *node = cgraph_node::get_create (fun->decl);
if (!check_retval_uses (retval, ret_stmt))
@@ -925,7 +927,7 @@ malloc_candidate_p_1 (function *fun, tree retval, gimple
*ret_stmt, bool ipa)
gimple *arg_def = SSA_NAME_DEF_STMT (arg);
if (is_a (arg_def))
{
- if (!malloc_candidate_p_1 (fun, arg, phi, ipa))
+ if (!malloc_candidate_p_1 (fun, arg, phi, ipa, depth + 1))
DUMP_AND_RETURN ("nested phi fail")
continue;
}
@@ -987,7 +989,7 @@ malloc_candidate_p (function *fun, bool ipa)
|| TREE_CODE (TREE_TYPE (retval)) != POINTER_TYPE)
DUMP_AND_RETURN("Return value is not SSA_NAME or not a pointer type.")
- if (!malloc_candidate_p_1 (fun, retval, ret_stmt, ipa))
+ if (!malloc_candidate_p_1 (fun, retval, ret_stmt, ipa, 0))
return false;
}
I'll try to reduce that.
[Bug libfortran/88776] Namelist read from stdin: loss of data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88776 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-10 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Confirmed from at least 4.3.1 up to trunk (9.0).
[Bug c++/88789] New: epiphany: memory_resource.cc:235:62: error: static assertion failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88789 Bug ID: 88789 Summary: epiphany: memory_resource.cc:235:62: error: static assertion failed Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: sebastian.hu...@embedded-brains.de Target Milestone: --- Build fails in libstdc++ currently: libtool: compile: /home/user/rtems-source-builder/rtems/build/epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1/build/./gcc/xgcc -shared-libgcc -B/home/user/rtems-source-builder/rtems/build/epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1/build/./gcc -nostdinc++ -L/home/user/rtems-source-builder/rtems/build/epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1/build/epiphany-rtems6/libstdc++-v3/src -L/home/user/rtems-source-builder/rtems/build/epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1/build/epiphany-rtems6/libstdc++-v3/src/.libs -L/home/user/rtems-source-builder/rtems/build/epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1/build/epiphany-rtems6/libstdc++-v3/libsupc++/.libs -nostdinc -B/home/user/rtems-source-builder/rtems/build/epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1/build/epiphany-rtems6/newlib/ -isystem /home/user/rtems-source-builder/rtems/build/epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1/build/epiphany-rtems6/newlib/targ-include -isystem /home/user/rtems-source-builder/rtems/build/epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1/gnu-mirror-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885/newlib/libc/include -B/home/user/install/rtems/6/epiphany-rtems6/bin/ -B/home/user/install/rtems/6/epiphany-rtems6/lib/ -isystem /home/user/install/rtems/6/epiphany-rtems6/include -isystem /home/user/install/rtems/6/epiphany-rtems6/sys-include -I/home/user/rtems-source-builder/rtems/build/epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1/gnu-mirror-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885/libstdc++-v3/../libgcc -I/home/user/rtems-source-builder/rtems/build/epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1/build/epiphany-rtems6/libstdc++-v3/include/epiphany-rtems6 -I/home/user/rtems-source-builder/rtems/build/epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1/build/epiphany-rtems6/libstdc++-v3/include -I/home/user/rtems-source-builder/rtems/build/epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1/gnu-mirror-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885/libstdc++-v3/libsupc++ -std=gnu++17 -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=cow-string-inst.lo -fimplicit-templates -g -O2 -c ../../../../../gnu-mirror-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885/libstdc++-v3/src/c++17/cow-string-inst.cc -o cow-string-inst.o ../../../../../gnu-mirror-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885/libstdc++-v3/src/c++17/memory_resource.cc: In member function 'void std::pmr::monotonic_buffer_resource::_M_new_buffer(std::size_t, std::size_t)': ../../../../../gnu-mirror-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885/libstdc++-v3/src/c++17/memory_resource.cc:235:62: error: static assertion failed 235 | static_assert(alignof(monotonic_buffer_resource::_Chunk) == 1); | ~~~^~~~
[Bug other/88790] New: No warning for misleading indentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88790
Bug ID: 88790
Summary: No warning for misleading indentation
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
-Wmisleading-indentation does not warn for
===
void f(void)
{
}
}
===
(as Daniel (on cc:) found), but not even for
===
void f(void)
{
}
===
Is there a reason for that?
[Bug tree-optimization/88775] [8/9 Regression] Optimize std::string assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88775 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-10 Ever confirmed|0 |1 --- Comment #4 from Richard Biener --- (In reply to Richard Biener from comment #3) > _4 = _3 > "hello"; > _5 = __builtin_constant_p (_4); > if (_5 != 0) > goto ; [34.00%] > else > goto ; [66.00%] > >[local count: 708669605]: > __x.5_6 = (long unsigned int) "hello"; > __y.6_7 = (long unsigned int) _3; > _8 = __x.5_6 < __y.6_7; > >[local count: 1073741824]: > # _9 = PHI <_4(2), _8(3)> > if (_9 != 0) > goto ; [50.00%] > else > goto ; [50.00%] which is a somewhat awkward pattern. I think that VN should really be able to value-number _4 and _8 the same eliding this crap. Let me see to do that. OK, that helps _a lot_.
[Bug other/88790] No warning for misleading indentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88790 --- Comment #1 from Segher Boessenkool --- (I couldn't add that cc:, Daniel doesn't have a bugzilla account yet).
[Bug tree-optimization/88775] [8/9 Regression] Optimize std::string assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88775
--- Comment #5 from Richard Biener ---
Created attachment 45401
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45401&action=edit
VN patch
Turns f() into just
[local count: 1073741824]:
_3 = &MEM[(struct basic_string *)s_2(D)].D.18989._M_local_buf;
MEM[(struct _Alloc_hider *)s_2(D)]._M_p = _3;
MEM[(size_type *)s_2(D) + 8B] = 0;
MEM[(char_type &)s_2(D) + 16] = 0;
if (_3 != "hello")
goto ; [75.00%]
else
goto ; [25.00%]
[local count: 805306369]:
__builtin_memcpy (_3, "hello", 5);
goto ; [100.00%]
[local count: 134217728]:
__builtin_memcpy ("hello", &MEM[(void *)"hello" + 5B], 5);
[local count: 1073741824]:
MEM[(size_type *)s_2(D) + 8B] = 5;
MEM[(char_type &)s_2(D) + 21] = 0;
return s_2(D);
[Bug target/88789] epiphany: memory_resource.cc:235:62: error: static assertion failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88789 Jonathan Wakely changed: What|Removed |Added Keywords||build --- Comment #1 from Jonathan Wakely --- That type has these members: unsigned char _M_canary; unsigned char _M_size; unsigned char _M_align; unsigned char _M_next[sizeof(_Chunk*)]; So it should have the same alignment as an unsigned char, no?
[Bug c++/88787] [9 regression] C++ constexpr seems to not get expanded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88787 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-10 CC||ktkachov at gcc dot gnu.org Version|unknown |9.0 Ever confirmed|0 |1 Known to fail||9.0 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed.
[Bug c/88568] [7/8/9 Regression] 'dllimport' no longer implies 'extern' in C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88568 --- Comment #9 from Jakub Jelinek --- Author: jakub Date: Thu Jan 10 10:44:46 2019 New Revision: 267799 URL: https://gcc.gnu.org/viewcvs?rev=267799&root=gcc&view=rev Log: PR c/88568 * attribs.c (handle_dll_attribute): Clear TREE_STATIC after setting DECL_EXTERNAL. * gcc.dg/pr88568.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr88568.c Modified: trunk/gcc/ChangeLog trunk/gcc/attribs.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/88775] [8/9 Regression] Optimize std::string assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88775 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Thu Jan 10 10:56:56 2019 New Revision: 267800 URL: https://gcc.gnu.org/viewcvs?rev=267800&root=gcc&view=rev Log: PR tree-optimization/88775 * include/bits/stl_function.h (greater<_Tp*>::operator(), less<_Tp*>::operator(), greater_equal<_Tp*>::operator(), less_equal<_Tp*>::operator()): Use __builtin_is_constant_evaluated instead of __builtin_constant_p if available. Don't bother with the pointer comparison in C++11 and earlier. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_function.h
[Bug libgcc/88772] Exception handling configured mode does not match the one finally used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88772
--- Comment #4 from Andoni ---
(In reply to Eric Botcazou from comment #3)
> > I just wiped the build to start a clean build from scratch, but I remember
> > checking this and it was "no". I can confirm it in ~1 hour
>
> Can you confirm that we're talking about the 32-bit multilib of libgcc here?
> Then, if the answer was "no", we need to understand why. The check is
> simple:
>
> dnl Check if the compiler is configured for setjmp/longjmp exceptions.
> AC_DEFUN([GCC_CHECK_SJLJ_EXCEPTIONS],
> [AC_CACHE_CHECK([whether the compiler is configured for setjmp/longjmp
> exceptions],
> ac_cv_sjlj_exceptions,
> [AC_COMPILE_IFELSE(
> [AC_LANG_PROGRAM(
> [[#ifdef __USING_SJLJ_EXCEPTIONS__
> this will fail
> #endif]],
> [[int i;]])],
> [ac_cv_sjlj_exceptions=no],
> [ac_cv_sjlj_exceptions=yes])])])
>
> Can you run it manually with -m32?
For 64bits the result is "no":
643 configure:4751: checking whether the compiler is configured for
setjmp/longjmp exceptions
644 configure:4769: x86_64-w64-mingw32-gcc
-L/home/andoni/mingw/windows/multilib/x86_64-w64-mingw32/lib
-L/home/andoni/mingw/windows/multilib/mingw/lib -isystem /home
/andoni/mingw/windows/multilib/x86_64-w64-mingw32/include -isystem
/home/andoni/mingw/windows/multilib/mingw/include-c -Wall -g -O2
-DWINVER=0x0600 -D_WIN32_ WINNT=0x0600 conftest.c >&5
645 conftest.c: In function 'main':
646 conftest.c:30:5: warning: unused variable 'i' [-Wunused-variable]
647 int i;
648 ^
649 configure:4769: $? = 0
650 configure:4776: result: no
for 32 bits the result is "yes":
631 configure:4751: checking whether the compiler is configured for
setjmp/longjmp exceptions
632 configure:4769: x86_64-w64-mingw32-gcc
-L/home/andoni/mingw/windows/multilib/x86_64-w64-mingw32/lib
-L/home/andoni/mingw/windows/multilib/mingw/lib -isystem /home
/andoni/mingw/windows/multilib/x86_64-w64-mingw32/include -isystem
/home/andoni/mingw/windows/multilib/mingw/include -m32 -c -Wall -g -O2
-DWINVER=0x0600 -D_WIN 32_WINNT=0x0600 conftest.c >&5
633 conftest.c:25:11: error: unknown type name 'this'
634this will fail
635^~~~
636 conftest.c:25:21: error: expected '=', ',', ';', 'asm' or '__attribute__'
before 'fail'
637this will fail
638 ^~~~
639 configure:4769: $? = 1
[...]
674 configure:4776: result: yes
For 32 bits the final EH model being used is Dwarf2:
340 # Additional sources to handle exceptions; overridden by targets as needed.
341 LIB2ADDEH = $(srcdir)/unwind-dw2.c $(srcdir)/unwind-dw2-fde.c \
342 $(srcdir)/unwind-sjlj.c $(srcdir)/unwind-c.c
What I understand is happening in a multilib build is that for 64 it chooses
SEH because ac_cv_sjlj_exceptions is not "yes" but for 32, it chooses dw2
instead of SJLJ for the same reason, because ac_cv_sjlj_exceptions is not
"yes":
if test x$ac_cv_sjlj_exceptions = xyes; then
tmake_eh_file="i386/t-sjlj-eh"
elif test "${host_address}" = 32; then
# biarch -m32 with --disable-sjlj-exceptions
tmake_eh_file="i386/t-dw2-eh"
md_unwind_header=i386/w32-unwind.h
else
tmake_eh_file="i386/t-seh-eh"
fi
What should happen in a mutilib build is that if the user configured without
passing any specific options for EH, the 32 bits target should be forced to be
configured with --enable-sjlj-exceptions.
[Bug target/88777] [9 Regression] Out-of-range offsets building glibc test-tgmath2.c for hppa-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88777 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0
[Bug libstdc++/88782] [8/9 Regression] Crash when mixing make_shared from gcc <= 8.2 with make_shared from gcc >= 8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88782 Richard Biener changed: What|Removed |Added Keywords||ABI Priority|P3 |P1 Target Milestone|--- |8.3
[Bug c/88568] [7/8 Regression] 'dllimport' no longer implies 'extern' in C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88568 Jakub Jelinek changed: What|Removed |Added Summary|[7/8/9 Regression] |[7/8 Regression] |'dllimport' no longer |'dllimport' no longer |implies 'extern' in C |implies 'extern' in C --- Comment #10 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug middle-end/88784] Middle end is missing some optimizations about unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88784 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-10 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. Similar for singed and X > Y && X != INT_MIN, etc. ifcombine is one place to fix (maybe_fold_and_comparisons and friends), match.pd in case this gets lowered to BIT_AND/IOR.
[Bug rtl-optimization/88785] [9 Regression] ICE in as_a, at machmode.h:353
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88785 Richard Biener changed: What|Removed |Added Target||x86_64-*-*, i?86-*-* Target Milestone|--- |9.0 Summary|ICE in as_a, at |[9 Regression] ICE in as_a, |machmode.h:353 |at machmode.h:353
[Bug tree-optimization/88786] Expand vector copysign (and xorsign) operations in the vectoriser
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88786 --- Comment #1 from Richard Biener --- I think it's a bit too low-level and having the higher-level op benefits later optimizations (match.pd patterns, etc.)
[Bug c++/88787] [9 regression] C++ constexpr seems to not get expanded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88787 Richard Biener changed: What|Removed |Added Keywords||rejects-valid Target Milestone|--- |9.0
[Bug c++/88787] [9 regression] C++ constexpr seems to not get expanded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88787 --- Comment #2 from Jonathan Wakely --- (In reply to Tamar Christina from comment #0) > The following testcases from libstdc++ have started failing in the past few > days on trunk: > > FAIL: 27_io/filesystem/operations/last_write_time.cc execution test This one is unrelated to the others. It fails for all 32-bit targets, see https://gcc.gnu.org/ml/libstdc++/2019-01/msg00033.html
[Bug sanitizer/88791] New: ASAN deadlocks in threaded application
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88791 Bug ID: 88791 Summary: ASAN deadlocks in threaded application Product: gcc Version: 7.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: dominik.stras...@onespin-solutions.com 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, marxin at gcc dot gnu.org Target Milestone: --- I have a threaded application which shows random crashes with ASAN. This is unfortunate but does not bother me too much. What is bothering me is that ASAN deadlocks after crashes. It looks like __asan::ReportDeadlySignal tries to acquire the __asan::thread_registry_placeholder lock which is already held by __sanitizer::ThreadRegistry::FinishThread Here are the two partial backtraces form my application: This is the thread which crashes: Thread 13 (Thread 0x7f35b94cc700 (LWP 53461)): #0 atomic_exchange<__sanitizer::atomic_uint32_t> (mo=__sanitizer::memory_order_acquire, v=2, a=0x7f35f05f8cb8 <__asan::thread_registry_placeholder+24>) at ../../../../gcc-7.4.0/libsanitizer/sanitizer_common/sanitizer_atomic_clang.h:66 #1 __sanitizer::BlockingMutex::Lock (this=0x7f35f05f8cb8 <__asan::thread_registry_placeholder+24>) at ../../../../gcc-7.4.0/libsanitizer/sanitizer_common/sanitizer_linux.cc:525 #2 0x7f35f037bf76 in Lock (this=) at ../../../../gcc-7.4.0/libsanitizer/sanitizer_common/sanitizer_thread_registry.h:84 #3 StartReporting (this=0x7f35c13e0f5f) at ../../../../gcc-7.4.0/libsanitizer/asan/asan_report.cc:225 #4 __asan::ScopedInErrorReport::ScopedInErrorReport (this=0x7f35c13e0f5f, fatal=) at ../../../../gcc-7.4.0/libsanitizer/asan/asan_report.cc:120 #5 0x7f35f0378970 in __asan::ReportDeadlySignal (signo=signo@entry=11, sig=...) at ../../../../gcc-7.4.0/libsanitizer/asan/asan_report.cc:251 #6 0x7f35f0377b12 in __asan::AsanOnDeadlySignal (signo=11, siginfo=0x7f35c13e1bf0, context=0x7f35c13e1ac0) at ../../../../gcc-7.4.0/libsanitizer/asan/asan_posix.cc:99 #7 #8 0x7f35f0398e17 in __sanitizer::ThreadContextBase::ThreadContextBase (this=0x7f35c469d000, tid=52) at ../../../../gcc-7.4.0/libsanitizer/sanitizer_common/sanitizer_thread_registry.cc:20 #9 0x7f35f037f1a2 in AsanThreadContext (tid=52, this=) at ../../../../gcc-7.4.0/libsanitizer/asan/asan_thread.h:42 #10 __asan::GetAsanThreadContext (tid=52) at ../../../../gcc-7.4.0/libsanitizer/asan/asan_thread.cc:55 #11 0x7f35f0399217 in __sanitizer::ThreadRegistry::CreateThread (this=0x7f35f05f8ca0 <__asan::thread_registry_placeholder>, user_id=0, detached=, parent_tid=41, arg=0x7f35ba4f7550) at ../../../../gcc-7.4.0/libsanitizer/sanitizer_common/sanitizer_thread_registry.cc:129 #12 0x7f35f037f2f8 in __asan::AsanThread::Create (start_routine=start_routine@entry=0x7f35d06f5785 , arg=arg@entry=0x616f0680, parent_tid=41, stack=stack@entry=0x7f35ba4f75e0, detached=) at ../../../../gcc-7.4.0/libsanitizer/asan/asan_thread.cc:90 #13 0x7f35f02cf2a4 in __interceptor_pthread_create (thread=0x616f07f0, attr=, start_routine=0x7f35d06f5785 , arg=0x616f0680) at ../../../../gcc-7.4.0/libsanitizer/asan/asan_interceptors.cc:264 #14 0x7f35d06f8453 in SYSTEM::DetachedThread::start (this=0x616f0680) at mythread.C:491 #15 0x7f35d06f7e8f in SYSTEM::DetachedThread::startAndWait (threads=...) at mythread.C:427 This is another thread: Thread 11 (Thread 0x7f35b9cf9700 (LWP 53463)): #0 atomic_exchange<__sanitizer::atomic_uint32_t> (mo=__sanitizer::memory_order_acquire, v=2, a=0x7f35f05f8cb8 <__asan::thread_registry_placeholder+24>) at ../../../../gcc-7.4.0/libsanitizer/sanitizer_common/sanitizer_atomic_clang.h:66 #1 __sanitizer::BlockingMutex::Lock (this=0x7f35f05f8cb8 <__asan::thread_registry_placeholder+24>) at ../../../../gcc-7.4.0/libsanitizer/sanitizer_common/sanitizer_linux.cc:525 #2 0x7f35f03998b5 in GenericScopedLock (mu=0x7f35f05f8cb8 <__asan::thread_registry_placeholder+24>, this=) at ../../../../gcc-7.4.0/libsanitizer/sanitizer_common/sanitizer_mutex.h:177 #3 __sanitizer::ThreadRegistry::FinishThread (this=0x7f35f05f8ca0 <__asan::thread_registry_placeholder>, tid=42) at ../../../../gcc-7.4.0/libsanitizer/sanitizer_common/sanitizer_thread_registry.cc:251 #4 0x7f35f037f6f7 in __asan::AsanThread::Destroy (this=0x7f35b6d9d000) at ../../../../gcc-7.4.0/libsanitizer/asan/asan_thread.cc:109 #5 0x7f35cf574c22 in __nptl_deallocate_tsd () from /lib64/libpthread.so.0 #6 0x7f35cf574e33 in start_thread () from /lib64/libpthread.so.0 #7 0x7f35ce0bbbad in clone () from /lib64/libc.so.6 So to me it looks like both threads try to lock __asan::thread_registry_placeholder
[Bug tree-optimization/88775] [8/9 Regression] Optimize std::string assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88775 --- Comment #7 from Richard Biener --- So after the patch we have __x.5_4 = (long unsigned int) "hello"; __y.6_5 = (long unsigned int) _3; if (__x.5_4 != __y.6_5) goto ; [75.00%] else goto ; [25.00%] [local count: 805306369]: __builtin_memcpy (_3, "hello", 5); goto ; [100.00%] [local count: 268435456]: if (_3 >= &MEM[(void *)"hello" + 5B]) goto ; [50.00%] else goto ; [50.00%] where we fail to elide this condition. Well, in theory "hello" could be followed by "hello", thus in .str "hello\0hello\0" and thus the condition could be true. Somehow w/o the libstdc++ patch this condition either doesn't appear or is elided.
[Bug target/88648] [7/8/9 Regression] Force unified syntax for inline assembly not functional (-masm-syntax-unified)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88648 --- Comment #3 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Thu Jan 10 11:36:42 2019 New Revision: 267804 URL: https://gcc.gnu.org/viewcvs?rev=267804&root=gcc&view=rev Log: ARM: fix -masm-syntax-unified (PR88648) This allows to use unified asm syntax when compiling for the ARM instruction. This matches documentation and seems what the initial patch was intended doing when the flag got added. 2019-01-10 Stefan Agner PR target/88648 * config/arm/arm.c (arm_option_override_internal): Force opts->x_inline_asm_unified to true only if TARGET_THUMB2_P. * gcc.target/arm/pr88648-asm-syntax-unified.c: Add test to check if -masm-syntax-unified gets applied properly. Added: trunk/gcc/testsuite/gcc.target/arm/pr88648-asm-syntax-unified.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/testsuite/ChangeLog
[Bug target/88648] [7/8 Regression] Force unified syntax for inline assembly not functional (-masm-syntax-unified)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88648 ktkachov at gcc dot gnu.org changed: What|Removed |Added Known to work||9.0 Summary|[7/8/9 Regression] Force|[7/8 Regression] Force |unified syntax for inline |unified syntax for inline |assembly not functional |assembly not functional |(-masm-syntax-unified) |(-masm-syntax-unified) Known to fail|9.0 | --- Comment #4 from ktkachov at gcc dot gnu.org --- Fixed on trunk.
[Bug tree-optimization/88775] [8/9 Regression] Optimize std::string assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88775
--- Comment #8 from Jakub Jelinek ---
"hello" string literal surely can be followed by anything else, but don't we
consider it UB?
int
foo (void)
{
int a = 0;
for (int i = 0; i < 32; i++)
a += "hello"[i];
return a;
}
warning: iteration 6 invokes undefined behavior
[-Waggressive-loop-optimizations]
a += "hello"[i];
~~~^~~
So,
__builtin_memcpy (xyz, &MEM[(void *)"hello" + 5B], 5);
is the same kind of UB.
Note, I don't see any:
__builtin_memcpy ("hello", ..., 5);
in my IL, that would be another UB unless string literals are writable.
[Bug tree-optimization/88792] New: [9 Regression] wrong-code in RPO VN since r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88792
Bug ID: 88792
Summary: [9 Regression] wrong-code in RPO VN since r263875
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
Isolated from vim package:
$ cat r.c
int one = 1;
char
__attribute__((noipa))
foo(char v)
{
int modec;
if (one)
{
modec = ((v < 'A' || v > 'Z') ? v : v + ('a' - 'A'));
if (modec != 't' && modec != 'c' && modec != 'g')
modec = 0;
}
else
modec = 'g';
return modec;
}
int main(int argc, char **argv)
{
char c = 't';
int r = foo (c);
__builtin_printf ("called for '%c', returned: %c\n", c, r);
if (r != c)
__builtin_abort ();
return 0;
}
$ gcc -O2 r.c -O2 && ./a.out
called for 't', returned:
Aborted (core dumped)
[Bug tree-optimization/88792] [9 Regression] wrong-code in RPO VN since r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88792 Martin Liška changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-10 Known to work||8.2.0 Target Milestone|--- |9.0 Ever confirmed|0 |1 Known to fail||9.0
[Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574 --- Comment #27 from Jan Hubicka --- Author: hubicka Date: Thu Jan 10 11:54:26 2019 New Revision: 267805 URL: https://gcc.gnu.org/viewcvs?rev=267805&root=gcc&view=rev Log: PR tree-optimization/85574 Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/tree-ssa-uncprop.c
[Bug tree-optimization/88792] [9 Regression] wrong-code in RPO VN since r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88792 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #1 from Richard Biener --- Mine.
[Bug rtl-optimization/88785] [9 Regression] ICE in as_a, at machmode.h:353
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88785 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-01-10 CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1
[Bug ipa/88788] [9 Regression] Infinite loop in malloc_candidate_p_1 since r264838
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88788 --- Comment #2 from prathamesh3492 at gcc dot gnu.org --- Sorry for the breakage, I will take a look. Regards, Prathamesh
[Bug target/88785] [9 Regression] ICE in as_a, at machmode.h:353
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88785 --- Comment #1 from Jakub Jelinek --- Guess latent since r214091.
[Bug target/88785] [9 Regression] ICE in as_a, at machmode.h:353
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88785 --- Comment #2 from Jakub Jelinek --- Created attachment 45402 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45402&action=edit gcc9-pr88785.patch Untested fix.
[Bug target/88789] epiphany: memory_resource.cc:235:62: error: static assertion failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88789 --- Comment #2 from Sebastian Huber --- I am not an epiphany expert. I just noticed this while testing the GCC builds for RTEMS.
[Bug tree-optimization/88792] [9 Regression] wrong-code in RPO VN since r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88792 --- Comment #2 from Richard Biener --- OK, I see what goes wrong.
[Bug lto/71959] [OpenACC] lto1: ICE in inline_read_section, at ipa-fnsummary.c:3314
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71959 --- Comment #11 from jules at gcc dot gnu.org --- Author: jules Date: Thu Jan 10 12:32:03 2019 New Revision: 267806 URL: https://gcc.gnu.org/viewcvs?rev=267806&root=gcc&view=rev Log: Add testcase from PR71959 libgomp/ PR lto/71959 * testsuite/libgomp.oacc-c++/pr71959-aux.cc: New. * testsuite/libgomp.oacc-c++/pr71959.C: New. Added: trunk/libgomp/testsuite/libgomp.oacc-c++/pr71959-aux.cc trunk/libgomp/testsuite/libgomp.oacc-c++/pr71959.C Modified: trunk/libgomp/ChangeLog
[Bug ipa/88788] [9 Regression] Infinite loop in malloc_candidate_p_1 since r264838
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88788 --- Comment #3 from Martin Liška --- (In reply to prathamesh3492 from comment #2) > Sorry for the breakage, I will take a look. > > Regards, > Prathamesh Wait, I have almost reduced test-case.
[Bug fortran/88750] [9 Regression] runtime error in statically linked binaries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #34 from Iain Sandoe ---
(In reply to Jürgen Reuter from comment #33)
> (In reply to Iain Sandoe from comment #32)
> > (In reply to Jürgen Reuter from comment #31)
> > > Then I get tons of duplicate symbol lines.
> >
> > ah well, not so simple then,
So .. I think things behave as expected .. like so:
$ cat op-new.C
#include
extern int *foo ();
int main() {
int *p2 = new (std::nothrow) int[10];
int *px = foo ();
delete[] p2;
delete[] px;
}
$ cat foo.C
#include
int *foo () {
int *p2 = new (std::nothrow) int[10];
if (p2)
p2[3] = 10;
return p2;
}
===
/opt/iains/PR88750/bin/g++ foo.C -shared -o libfoo.dylib
^^^ that makes a shared lib that references the libstdc++.dylib
/opt/iains/PR88750/bin/g++ op-new.C -L. -lfoo -o op-sh
^^ builds a "normal" C++ program that resolves the operator new [] from the
shared libstdc++.
/opt/iains/PR88750/bin/gcc -xc++ op-new.C
-Wl,-force_load,x86_64-apple-darwin16/libstdc++-v3/src/.libs/libstdc++.a -L.
-lfoo -o o-sta
(the path to the static instance is local there only because i patched the
operator new [] to print out which version was called.)
^^^ builds a program that uses the "o-sta" as the libstdc++ and resolves both
the call in main *and* the call in libfoo.dylib from the instance in o-sta.
=
So, whatever else might be wrong - it is nothing to do with the warning that ld
emits.
[Bug ipa/88788] [9 Regression] Infinite loop in malloc_candidate_p_1 since r264838
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88788 --- Comment #4 from Martin Liška --- Created attachment 45403 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45403&action=edit reduced test-case
[Bug libgcc/88772] Exception handling configured mode does not match the one finally used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88772
--- Comment #5 from Eric Botcazou ---
> For 64bits the result is "no":
> 643 configure:4751: checking whether the compiler is configured for
> setjmp/longjmp exceptions
> 644 configure:4769: x86_64-w64-mingw32-gcc
> -L/home/andoni/mingw/windows/multilib/x86_64-w64-mingw32/lib
> -L/home/andoni/mingw/windows/multilib/mingw/lib -isystem /home
> /andoni/mingw/windows/multilib/x86_64-w64-mingw32/include -isystem
> /home/andoni/mingw/windows/multilib/mingw/include-c -Wall -g -O2
> -DWINVER=0x0600 -D_WIN32_ WINNT=0x0600 conftest.c >&5
> 645 conftest.c: In function 'main':
> 646 conftest.c:30:5: warning: unused variable 'i' [-Wunused-variable]
> 647 int i;
> 648 ^
> 649 configure:4769: $? = 0
> 650 configure:4776: result: no
As expected.
> for 32 bits the result is "yes":
> 631 configure:4751: checking whether the compiler is configured for
> setjmp/longjmp exceptions
> 632 configure:4769: x86_64-w64-mingw32-gcc
> -L/home/andoni/mingw/windows/multilib/x86_64-w64-mingw32/lib
> -L/home/andoni/mingw/windows/multilib/mingw/lib -isystem /home
> /andoni/mingw/windows/multilib/x86_64-w64-mingw32/include -isystem
> /home/andoni/mingw/windows/multilib/mingw/include -m32 -c -Wall -g -O2
> -DWINVER=0x0600 -D_WIN 32_WINNT=0x0600 conftest.c >&5
> 633 conftest.c:25:11: error: unknown type name 'this'
> 634this will fail
> 635^~~~
> 636 conftest.c:25:21: error: expected '=', ',', ';', 'asm' or
> '__attribute__' before 'fail'
> 637this will fail
> 638 ^~~~
> 639 configure:4769: $? = 1
> [...]
> 674 configure:4776: result: yes
As expected.
> For 32 bits the final EH model being used is Dwarf2:
>
> 340 # Additional sources to handle exceptions; overridden by targets as
> needed.
> 341 LIB2ADDEH = $(srcdir)/unwind-dw2.c $(srcdir)/unwind-dw2-fde.c \
> 342 $(srcdir)/unwind-sjlj.c $(srcdir)/unwind-c.c
>
>
> What I understand is happening in a multilib build is that for 64 it chooses
> SEH because ac_cv_sjlj_exceptions is not "yes" but for 32, it chooses dw2
> instead of SJLJ for the same reason, because ac_cv_sjlj_exceptions is not
> "yes":
> if test x$ac_cv_sjlj_exceptions = xyes; then
> tmake_eh_file="i386/t-sjlj-eh"
> elif test "${host_address}" = 32; then
> # biarch -m32 with --disable-sjlj-exceptions
> tmake_eh_file="i386/t-dw2-eh"
> md_unwind_header=i386/w32-unwind.h
> else
> tmake_eh_file="i386/t-seh-eh"
> fi
But you said above that the result is "yes" for 32-bit, so how come the test:
x$ac_cv_sjlj_exceptions = xyes;
is false? Does it help to rewrite it into just:
$ac_cv_sjlj_exceptions = yes;
like in libgcc/configure.ac?
[Bug ipa/88788] [9 Regression] Infinite loop in malloc_candidate_p_1 since r264838
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88788 --- Comment #5 from prathamesh3492 at gcc dot gnu.org --- (In reply to Martin Liška from comment #4) > Created attachment 45403 [details] > reduced test-case Thanks!
[Bug tree-optimization/88775] [8/9 Regression] Optimize std::string assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88775
--- Comment #9 from Richard Biener ---
Created attachment 45404
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45404&action=edit
VRP patch
This makes VRP register asserts for the pointer variants. This doesn't help
until after ifcombine because we throw the asserts away if they are not
EQ/NE_EXPR but after ifcombine DOM then manages to optimize the testcase nicely
again. After the libstdc++ patch and dom2:
__attribute__((abi_tag ("cxx11"), flatten))
f ()
{
const size_type __nleft;
char[16] * _3;
long unsigned int __x.5_4;
long unsigned int __y.6_5;
char * _12;
[local count: 1073741824]:
_3 = &MEM[(struct basic_string *)s_2(D)].D.18989._M_local_buf;
MEM[(struct _Alloc_hider *)s_2(D)]._M_p = _3;
MEM[(size_type *)s_2(D) + 8B] = 0;
MEM[(char_type &)s_2(D) + 16] = 0;
__x.5_4 = (long unsigned int) "hello";
__y.6_5 = (long unsigned int) _3;
if (__x.5_4 != __y.6_5)
goto ; [75.00%]
else
goto ; [25.00%]
[local count: 805306369]:
__builtin_memcpy (_3, "hello", 5);
goto ; [100.00%]
[local count: 67108864]:
__builtin_memcpy ("hello", &MEM[(void *)"hello" + 5B], 5);
[local count: 1073741824]:
MEM[(size_type *)s_2(D) + 8B] = 5;
_12 = MEM[(char * *)s_2(D)];
MEM[(char_type &)_12 + 5] = 0;
return s_2(D);
}
[Bug ipa/88702] [7/8/9 regression] We do terrible job optimizing IsHTMLWhitespace from Firefox
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88702
--- Comment #7 from Martin Liška ---
Just for the record, when rewriting the code with switch:
int IsHTMLWhitespace(int aChar) {
switch (aChar) {
case 0x0009:
case 0x000A:
case 0x000C:
case 0x000D:
case 0x0020:
return 1;
default:
return 0;
}
}
one gets a nice bit-test eventually:
[local count: 1073741824]:
_4 = (unsigned int) aChar_2(D);
if (_4 > 32)
goto ; [20.00%]
else
goto ; [80.00%]
:
_6 = 1 << _4;
_7 = _6 & 4294981120;
_8 = _7 != 0;
_5 = (int) _8;
[local count: 1073741824]:
# _1 = PHI <_5(3), 0(2)>
return _1;
[Bug tree-optimization/88775] [8/9 Regression] Optimize std::string assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88775
--- Comment #10 from Jakub Jelinek ---
I get pretty much the same thing with:
--- gcc/match.pd.jj 2019-01-07 17:59:24.100931144 +0100
+++ gcc/match.pd2019-01-10 14:45:31.870509916 +0100
@@ -1660,6 +1660,19 @@ (define_operator_list COND_TERNARY
(if (TREE_INT_CST_LOW (@1) & 1)
{ constant_boolean_node (cmp == NE_EXPR, type); })))
+/* Turn (uintptr_t) ptr1 != (uintptr_t) ptr2 comparison into just
+ ptr1 != ptr2. Don't do that for non-equality comparisons. */
+(for cmp (eq ne)
+ (simplify
+ (cmp (convert@2 @0) (convert @1))
+ (if (ANY_INTEGRAL_TYPE_P (TREE_TYPE (@2))
+ && POINTER_TYPE_P (TREE_TYPE (@0))
+ && POINTER_TYPE_P (TREE_TYPE (@1))
+ && TYPE_PRECISION (TREE_TYPE (@2)) >= TYPE_PRECISION (TREE_TYPE (@0))
+ && ((GIMPLE && types_compatible_p (TREE_TYPE (@0), TREE_TYPE (@1)))
+ || (GENERIC && TREE_TYPE (@0) == TREE_TYPE (@1
+ (cmp @0 @1
+
/* Arguments on which one can call get_nonzero_bits to get the bits
possibly set. */
(match with_possible_nonzero_bits
(well, even without the (unsigned long) casts). Isn't this better or do we
want both patches?
[Bug c/30475] assert(int+100 > int) optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475 Marian changed: What|Removed |Added CC||marian.buschsieweke at ovgu dot de --- Comment #57 from Marian --- Sorry for posting to this ancient bugreport. Is there a way to get a warning when code get optimized out based on undefined behavior? I bet that at least 90% of the C developers out there would be completely surprised that signed integer overflow is actually undefined behavior. And at least 99% of the C developers out there would not spot the bug in http://ptrace.fefe.de/int.c spending significant time and energy. So being able to get a warning for that would be highly appreciated tool to help finding and fixing those bugs. Kind regards, Marian PS: Please also consider to enable this warning with `-Wall -Wextra -pedantic`. I bet that 99% of the cases the compiler can optimize code out because of this undefined behavior the code has a bug in some bound checks.
[Bug libgcc/88772] Exception handling configured mode does not match the one finally used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88772 --- Comment #6 from Andoni --- (In reply to Eric Botcazou from comment #5) > > But you said above that the result is "yes" for 32-bit, so how come the test: > > x$ac_cv_sjlj_exceptions = xyes; > > is false? Does it help to rewrite it into just: > > $ac_cv_sjlj_exceptions = yes; > > like in libgcc/configure.ac? I see what you mean. "config.log" do report for 32 bits "ac_cv_sjlj_exceptions=yes" I don't understand why this check fails than. It's either a problem with the order in which it's done (although I checked and it's correct) or an issue in how the value is checked. I will test several option, with quites, without prepending the x, etc... and I will report back.
[Bug c/30475] assert(int+100 > int) optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475 --- Comment #58 from Andreas Schwab --- -Wstrict-overflow=1 is enabled by -Wall.
[Bug tree-optimization/88775] [8/9 Regression] Optimize std::string assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88775 --- Comment #11 from Jakub Jelinek --- Created attachment 45405 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45405&action=edit gcc9-pr88775.patch Full patch.
[Bug tree-optimization/88793] New: Document that __attribute__ ((cold)) is not equivalent to __builtin_except because of optimization for size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88793 Bug ID: 88793 Summary: Document that __attribute__ ((cold)) is not equivalent to __builtin_except because of optimization for size Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Target Milestone: --- The documentation says this: 'cold' The 'cold' attribute on functions is used to inform the compiler that the function is unlikely to be executed. The function is optimized for size rather than speed and on many targets it is placed into a special subsection of the text section so all cold functions appear close together, improving code locality of non-cold parts of program. The paths leading to calls of cold functions within code are marked as unlikely by the branch prediction mechanism. It is thus useful to mark functions used to handle unlikely conditions, such as 'perror', as cold to improve optimization of hot functions that do call marked functions in rare occasions. However, optimizing for size is a very big hammer and causes substantial performance issues on i386 and x86-64 due to string function inlining. As a result, the cold attribute is only suitable for code that is basically never executed. For other cases, like repeated execution which only happens in an unlikely configuration, it is inappropriate. The documentation does not make this clear enough, and programmers use __attribute__ ((cold)) and the propagation into call sites as a more convenient alternative for __builtin_expect, leading to performance issues. The referenced downstream bug concerns some old GCC version where GCC incorrectly inferred cold code regions from __builtin_expect. I'm including it here to indicate that the distinction matters in practice.
[Bug target/88794] New: fixupimm intrinsics are unusable [9.0 regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88794
Bug ID: 88794
Summary: fixupimm intrinsics are unusable [9.0 regression]
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: kretz at kde dot org
Target Milestone: ---
Target: x86_64-*-*, i?86-*-*
Test case:
```
#include
__m128 f(__m128 x, __m128 &y) {
y = _mm_fixupimm_ps(x, _mm_set1_epi32(0x), 0x00);
return x;
}
__m128 g(__m128 x, __m128 &y) {
y = _mm_mask_fixupimm_ps(y, -1, x, _mm_set1_epi32(0x), 0x00);
return x;
}
__m128 h(__m128 x, __m128 &y, __mmask16 k) {
y = _mm_mask_fixupimm_ps(y, k, x, _mm_set1_epi32(0x), 0x00);
return x;
}
```
The function f (cf. https://godbolt.org/z/f6u-GI) only compiles with GCC 9;
none of GCC 8, clang, or ICC accept f. If one adds `y, ` as first argument to f
it compiles on non-GCC9 (cf. https://godbolt.org/z/rqPT15).
Besides the incompatibility, fixupimm is unusable on GCC9, because the
functions f and g produce garbage in y.
This was introduced in r265827.
[Bug lto/84995] Documentation gcc-ar and gcc-ranlib vs {libdir}/bfd-plugins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84995 Дилян Палаузов changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #7 from Дилян Палаузов --- Why doesn’t GCC “make install” put the linker plugin under $libdir/bfd-plugins and how are program ./configure’s supposed to be written in a way, that LTO works with both Clang and GCC?
[Bug target/88794] [9 Regression] fixupimm intrinsics are unusable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88794 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-10 CC||hjl.tools at gmail dot com, ||jakub at gcc dot gnu.org, ||xguo at gcc dot gnu.org Target Milestone|--- |9.0 Summary|fixupimm intrinsics are |[9 Regression] fixupimm |unusable [9.0 regression] |intrinsics are unusable Ever confirmed|0 |1
[Bug tree-optimization/88793] Document that __attribute__ ((cold)) is not equivalent to __builtin_except because of optimization for size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88793 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #1 from Alexander Monakov --- (In reply to Florian Weimer from comment #0) > However, optimizing for size is a very big hammer and causes substantial > performance issues on i386 and x86-64 due to string function inlining. As a > result, the cold attribute is only suitable for code that is basically never > executed. For other cases, like repeated execution which only happens in an > unlikely configuration, it is inappropriate. Can you please clarify exactly what issues? If you mean inline 'rep stosb/movsb', their overhead is on the order of 30 cycles, and I don't see what is inappropriate about it.
[Bug fortran/50410] [7/8/9 Regression] ICE in record_reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410 --- Comment #32 from Dominique d'Humieres --- Some of the tests in this PR are fixed by the patch at https://gcc.gnu.org/ml/fortran/2019-01/msg00065.html
[Bug bootstrap/88450] [9 regression] ICE in stage 2 compiler while configuring libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88450 --- Comment #21 from Bence Szabó --- Bootstrap succeeds with trunk + gcc9-pr88450.patch. Ran gcc testsuite, all stackalignment tests pass and so does the test added by r266345. The CPU was an Intel Coffee Lake so avx and avx2 is supported but avx512 is not.
[Bug bootstrap/88714] [9 regression] bootstrap comparison failure on armv7l since r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714 --- Comment #6 from Jakub Jelinek --- The profile_estimate difference is a bug introduced in r191883 and later extended in r193821 I have a fix for, but it can be ignored, it should have went into the combine dump instead.
[Bug tree-optimization/88771] [9 Regression] Misleading -Werror=array-bounds error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88771 --- Comment #7 from Martin Sebor --- Yes, that's exactly right.
[Bug c++/88787] [9 regression] C++ constexpr seems to not get expanded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88787 --- Comment #3 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #2) > (In reply to Tamar Christina from comment #0) > > The following testcases from libstdc++ have started failing in the past few > > days on trunk: > > > > FAIL: 27_io/filesystem/operations/last_write_time.cc execution test > > This one is unrelated to the others. It fails for all 32-bit targets, see > https://gcc.gnu.org/ml/libstdc++/2019-01/msg00033.html This is fixed at r267811
[Bug c++/88795] New: ICE on class-template argument deduction if non-type parameter has indirection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88795
Bug ID: 88795
Summary: ICE on class-template argument deduction if non-type
parameter has indirection
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: programmer at posteo dot de
Target Milestone: ---
The following code (compiled with g++ -std=c++17 -Wall -Wextra) causes an
internal compiler error (ICE) with all GCC versions on godbolt starting from
7.1. Clang compiles fine.
// CODE START
template
struct Array {};
template
struct Foo {
static constexpr int size() {
return size_;// this indirection causes the ICE
}
template
Foo(U, Array) {}
};
template
Foo(U, Array) -> Foo;
int main() {
Array arr{};
Foo foo{2.0, arr};
}
// CODE END
Below I post the error messages from godbolt in order to make it easier to find
this report. See also https://godbolt.org/z/Nb-3YM
GCC 9.0.0 20190109: internal compiler error: tree check: expected tree_list,
have error_mark in type_hash_canon_hash, at tree.c:6811
GCC 8.2.0: internal compiler error: in type_unification_real, at cp/pt.c:20206
GCC 8.1.0: internal compiler error: in type_unification_real, at cp/pt.c:20148
[...] mmap: Invalid argument
GCC 7.4.0: internal compiler error: in type_unification_real, at cp/pt.c:19294
GCC 7.3.0: internal compiler error: in type_unification_real, at cp/pt.c:19239
[...] mmap: Invalid argument
GCC 7.2.0: internal compiler error: in type_unification_real, at cp/pt.c:19209
[...] mmap: Invalid argument
GCC 7.1.0: internal compiler error: in type_unification_real, at cp/pt.c:19127
[...] mmap: Invalid argument
[Bug middle-end/84877] Local stack copy of BLKmode parameter on the stack is not aligned when the requested alignment exceeds MAX_SUPPORTED_STACK_ALIGNMENT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84877 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Thu Jan 10 15:44:16 2019 New Revision: 267812 URL: https://gcc.gnu.org/viewcvs?rev=267812&root=gcc&view=rev Log: PR middle-end/84877 PR bootstrap/88450 * function.c (assign_stack_local_1): Revert the 2018-11-21 changes. (assign_parm_setup_block): Do the argument slot realignment here instead. Modified: trunk/gcc/ChangeLog trunk/gcc/function.c
[Bug bootstrap/88450] [9 regression] ICE in stage 2 compiler while configuring libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88450 --- Comment #22 from Jakub Jelinek --- Author: jakub Date: Thu Jan 10 15:44:16 2019 New Revision: 267812 URL: https://gcc.gnu.org/viewcvs?rev=267812&root=gcc&view=rev Log: PR middle-end/84877 PR bootstrap/88450 * function.c (assign_stack_local_1): Revert the 2018-11-21 changes. (assign_parm_setup_block): Do the argument slot realignment here instead. Modified: trunk/gcc/ChangeLog trunk/gcc/function.c
[Bug bootstrap/88450] [9 regression] ICE in stage 2 compiler while configuring libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88450 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #23 from Jakub Jelinek --- Fixed.
[Bug c/30475] assert(int+100 > int) optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475 --- Comment #59 from Marian --- Thanks for the fast replay wget http://ptrace.fefe.de/int.c gcc -Wstrict-overflow=1 -Wall -Wextra -pedantic -o int int.c does not produce a warning (except for the missing `#include `) on gcc 8.2.0 on Alpine Linux for me, nor on GCC 8.2.1 20181127 an Arch Linux.
[Bug tree-optimization/81452] warn on realloc(p, 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81452 --- Comment #4 from Eric Gallager --- (In reply to Martin Sebor from comment #3) > There is -Walloc-zero. If we want a separate knob for just it then maybe > -Wrealloc-zero. Oh right, -Walloc-zero, I forgot about that one. It triggers so rarely that it's probably safe to keep this proposed warning under that single flag.
[Bug libstdc++/80762] is_constructible gives hard error with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80762 --- Comment #4 from Jonathan Wakely --- Author: redi Date: Thu Jan 10 16:06:49 2019 New Revision: 267815 URL: https://gcc.gnu.org/viewcvs?rev=267815&root=gcc&view=rev Log: PR libstdc++/80762 avoid ambiguous __constructible_from Ensure we don't try to instantiate __is_constructible_from, because there are two partial specializations that are equally good matches. Backport from mainline 2018-12-12 Jonathan Wakely PR libstdc++/80762 * include/bits/fs_path.h (path::_Path): Use remove_cv_t and is_void. * include/experimental/bits/fs_path.h (path::_Path): Likewise. * testsuite/27_io/filesystem/path/construct/80762.cc: New test. * testsuite/experimental/filesystem/path/construct/80762.cc: New test. Added: branches/gcc-8-branch/libstdc++-v3/testsuite/27_io/filesystem/path/construct/80762.cc branches/gcc-8-branch/libstdc++-v3/testsuite/experimental/filesystem/path/construct/80762.cc Modified: branches/gcc-8-branch/libstdc++-v3/ChangeLog branches/gcc-8-branch/libstdc++-v3/include/bits/fs_path.h branches/gcc-8-branch/libstdc++-v3/include/experimental/bits/fs_path.h
[Bug tree-optimization/88793] Document that __attribute__ ((cold)) is not equivalent to __builtin_except because of optimization for size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88793
--- Comment #2 from Florian Weimer ---
(In reply to Alexander Monakov from comment #1)
> (In reply to Florian Weimer from comment #0)
> > However, optimizing for size is a very big hammer and causes substantial
> > performance issues on i386 and x86-64 due to string function inlining. As a
> > result, the cold attribute is only suitable for code that is basically never
> > executed. For other cases, like repeated execution which only happens in an
> > unlikely configuration, it is inappropriate.
>
> Can you please clarify exactly what issues? If you mean inline 'rep
> stosb/movsb', their overhead is on the order of 30 cycles, and I don't see
> what is inappropriate about it.
The startup overhead isn't the problem. The asymptotic performance is really
bad, too. (I hope I didn't botch my test, though. It's vaguely based on
what's attached to the downstream bug.)
For len == 5000, I get a factor of 60 difference in favor of glibc 2.28's
strlen. For len == 30, it's still a factor of 11 in favor of strlen. This is
on a machine with a i7-8650U, so a fairly recent CPU with erms.
#include
#include
#include
#include
#include
static size_t len = 30;
static char *buffer;
static int count = 1;
__attribute__ ((weak))
size_t
call_strlen (const char *s)
{
return strlen (s);
}
__attribute__ ((weak, cold))
size_t
slow_strlen (const char *s)
{
return strlen (s);
}
__attribute__ ((weak))
size_t
call_slow_strlen (const char *s)
{
return slow_strlen (s);
}
static void
bench (const char *what, size_t (*fptr) (const char *))
{
struct timespec start;
if (clock_gettime (CLOCK_MONOTONIC, &start) != 0)
err (1, "clock_gettime");
for (int i = 0; i < count; ++i)
fptr (buffer);
struct timespec end;
if (clock_gettime (CLOCK_MONOTONIC, &end) != 0)
err (1, "clock_gettime");
double delta = (end.tv_sec - start.tv_sec) * 1e9;
delta += end.tv_nsec - start.tv_nsec;
printf ("%s: %f ns/call\n", what, delta / count);
}
int
main (void)
{
buffer = malloc (len + 1);
if (buffer == NULL)
err (1, "malloc");
memset (buffer, 'a', len);
buffer[len] = 0;
for (int i = 0; i < 10; i++)
{
bench ("strlen", call_strlen);
bench ("strlen (cold)", call_slow_strlen);
}
free (buffer);
return 0;
}
[Bug target/87007] [8/9 Regression] 10% slowdown with -march=skylake-avx512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87007 --- Comment #5 from H.J. Lu --- The current patch is posted at https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00298.html
[Bug libstdc++/80762] is_constructible gives hard error with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80762 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |8.3 --- Comment #5 from Jonathan Wakely --- Fixed for GCC 8.3
[Bug libstdc++/80762] is_constructible gives hard error with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80762 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jonathan Wakely --- .
[Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574 --- Comment #28 from Jan Hubicka --- Author: hubicka Date: Thu Jan 10 16:53:39 2019 New Revision: 267817 URL: https://gcc.gnu.org/viewcvs?rev=267817&root=gcc&view=rev Log: Backported from mainline 2019-01-02 Richard Biener PR ipa/85574 * ipa-icf.h (sem_item_optimizer::sort_congruence_split): Declare. * ipa-icf.c (sem_item_optimizer::sort_congruence_split): New function. (sem_item_optimizer::do_congruence_step_f): Sort the congruence set after UIDs before splitting them. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/ipa-icf.c branches/gcc-8-branch/gcc/ipa-icf.h
[Bug tree-optimization/88763] Better Output for Loop Unswitching
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88763 --- Comment #10 from David Malcolm --- Created attachment 45406 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45406&action=edit Followup patch to try to dump why a condition can't be unswitched within a loop
[Bug tree-optimization/88763] Better Output for Loop Unswitching
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88763
--- Comment #11 from David Malcolm ---
Thanks for the testcase.
(In reply to David Malcolm from comment #10)
> Created attachment 45406 [details]
> Followup patch to try to dump why a condition can't be unswitched within a
> loop
This is a followup patch (on top of the one in comment #6), which tries to dump
the desired information from comment #7.
On the testcase from comment #9, it gives:
$ ./xgcc -B. -c /tmp/t.c -O2 -funswitch-loops -fopt-info-loop-all
/tmp/t.c:17:9: missed: within this loop...
/tmp/t.c:5:7: missed: ...cannot unswitch condition: if (_16 > 5)
/tmp/t.c:3:11: missed: ...as condition is not invariant within loop; modified
here by: _16 = flag_37 + 2;
/tmp/t.c:17:9: missed: within this loop...
/tmp/t.c:17:9: missed: ...cannot unswitch condition: if (j_11 != 250)
/tmp/t.c:17:34: missed: ...as condition is not invariant within loop; modified
here by: j_11 = j_34 + 1;
i.e. it's emitting 3 messages per unswitchable condition, highlighting each of:
* the loop
* the condition
* the problematic statement
The -fsave-optimization-record version of this dump also captures the function
name (and the inlining chain, for inlined statements, such as that of the
condition within the "calc" inlined within "main"):
{
"count": {
"quality": "guessed_local",
"value": 106300.0
},
"function": "main",
"impl_location": {
"file": "../../src/gcc/tree-ssa-loop-unswitch.c",
"function": "dump_unswitchable_condition",
"line": 198
},
"inlining_chain": [
{
"fndecl": "calc"
},
{
"fndecl": "main",
"site": {
"column": 25,
"file": "/tmp/t.c",
"line": 19
}
}
],
"kind": "failure",
"location": {
"column": 7,
"file": "/tmp/t.c",
"line": 5
},
"message": [
"...cannot unswitch condition: ",
{
"location": {
"column": 7,
"file": "/tmp/t.c",
"line": 5
},
"stmt": "if (_16 > 5)\n"
}
],
"pass": "0x3a33250"
},
How does this look?
FWIW, this is feeling like gcc 10 material.
[Bug tree-optimization/88793] Document that __attribute__ ((cold)) is not equivalent to __builtin_except because of optimization for size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88793 --- Comment #3 from Alexander Monakov --- (In reply to Florian Weimer from comment #2) > The startup overhead isn't the problem. The asymptotic performance is > really bad, too. (I hope I didn't botch my test, though. It's vaguely > based on what's attached to the downstream bug.) > > For len == 5000, I get a factor of 60 difference in favor of glibc 2.28's > strlen. For len == 30, it's still a factor of 11 in favor of strlen. This > is on a machine with a i7-8650U, so a fairly recent CPU with erms. As noted in the referenced bug, erms does not accelerate scasb and cmpsb (only movs and stos), so strlen and memcmp/strcmp are among the most extreme examples. I wrongly assumed gcc did not use scasb to implement strlen inline. I think it's fair to raise the question if gcc should not use scasb/cmpsb by default (I thought there was a bug for that but apparently there isn't?). I doubt it supports the original point about attribute-cold being inappropriate. If gcc is making a poor decision in cold regions, it will be making the same poor decision everywhere under -Os, and it's fair to demand that such decisions are revisited and improved (-Os is not "minimize size at all costs").
[Bug bootstrap/88714] [9 regression] bootstrap comparison failure on armv7l since r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-01-10
Ever confirmed|0 |1
--- Comment #7 from Jakub Jelinek ---
As for the rest, seems that when tree-ssa-sccvn.c is compiled by the
stage1-gcc/ with -g -O2 -fno-checking -gtoggle options (among others), it emits
something, while when compiled with stage2-gcc/ it emits something different.
Copying tree-ssa-sccvn.o from stage1-gcc/ (prev-gcc) into stage2-gcc/ (gcc) and
rebuilding cc1 makes it generate the same assembly and same -fdump-tree-pre-all
dump for sort.i as stage1-gcc/ generates, otherwise there are differences like:
-exp_gen[6] := { countp_30 (0022), {mem_ref<0B>,countp_30}@.MEM_25 (0007),
{mem_ref<4294967292B>,countp_30}@.MEM_80 (0008), {plus_expr,_10,_11} (0009),
{pointer_plus_expr,countp_30,4} (0033) }
+exp_gen[6] := { countp_30 (0022), {mem_ref<0B>,countp_30}@.MEM_25 (0007), _11
(0008), {plus_expr,_10,_11} (0009), {pointer_plus_expr,countp_30,4} (0033) }
and various others later on.
[Bug c/88774] Qualification of parameters does not change a function type: Bug or standard defect?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88774 Anders Granlund changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Anders Granlund --- Ok. Thanks for the answers.
[Bug c++/88795] ICE on class-template argument deduction if non-type parameter has indirection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88795 Marek Polacek changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-10 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Started with r240765.
[Bug libstdc++/77776] C++17 std::hypot implementation is poor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6 --- Comment #7 from emsr at gcc dot gnu.org --- What does this do? auto __hi_exp = __hi & simd<_T, _Abi>(std::numeric_limits<_T>::infinity()); // no error Sorry, I have no simd knowlege yet. Anyway, doesn't the large scale risk overflow if a, b are large? I guess I'm lost.
[Bug ipa/88788] [9 Regression] Infinite loop in malloc_candidate_p_1 since r264838
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88788 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- The endless recursion isn't just one issue, by walking all PHI arguments recursively this way it can be also extremely compile time expensive even if you avoid recursion on the PHIs currently being processed.
[Bug tree-optimization/88763] Better Output for Loop Unswitching
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88763 --- Comment #12 from Marius Messerschmidt --- I think this messages look really good! I believe that this contains everything required to actually work on improving automatic unswitching, thank you very much! Do you think that there is a chance that this will be included in GCC9?
[Bug bootstrap/88714] [9 regression] bootstrap comparison failure on armv7l since r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714 --- Comment #8 from Jakub Jelinek --- Note, the stage1-gcc compiled tree-ssa-sccvn.o is identical no matter whether -fno-checking or -fchecking=1 was used, and doesn't fail -fcompare-debug with either, so it is simply that something is miscompiled somewhere. BTW, stage3-gcc/cc1 results in the same sort.s as stage1-gcc/cc1, only stage2-gcc/cc1 is different (if it contains the stage1-gcc/cc1plus compiled and optimized tree-ssa-sccvn.o). Guess we want a side-by-side debugging sessions in the debugger of stage2-gcc/cc1 on sort.i when it has tree-ssa-sccvn.o built by the host compiler and when it has -O2 -fno-checking -g tree-ssa-sccvn.o built by the stage1 cc1plus.
[Bug c++/88787] [9 regression] C++ constexpr seems to not get expanded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88787 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Guess it must be one of the dozens or more issues with have with constexpr and the ARM EABI cdtors returning this.
[Bug tree-optimization/88771] [9 Regression] Misleading -Werror=array-bounds error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88771 --- Comment #8 from Alexander Monakov --- Yeah, on GCC users' side I think there's a demand for both: treating UB as unreachable (e.g. on tiny systems with heavy program size constraints) and transforming UB to a trap briefly annotated with source location information. In this particular testcase the warning looks like a false positive because it's emitted on a copy of the original statement that is only called on a specialized path, if f==-1 (and will surely invoke UB there). In general I'm afraid it's impossible to say which copy is specialized (e.g. when you unswitch a loop neither of the two copies is more "specific" than the original), but perhaps here VRP threading could set some TREE_NO_WARNING flags reasonably? I think it might have been asked already, but isn't it possible to emit such warnings before CFG transformations may have taken place?
[Bug rtl-optimization/88796] New: -fstack-protector* kills RTL DSE opportunities
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88796
Bug ID: 88796
Summary: -fstack-protector* kills RTL DSE opportunities
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
Marek has noticed that the gcc.target/i386/pr87370.c testcase FAILs when built
with -fstack-protector-strong (
make check-gcc
RUNTESTFLAGS='--target_board=unix\{-m64,-m64/-fstack-protector-strong\}
i386.exp=pr87370.c'
). It isn't a wrong-code, but seems quite severe anyway. Before the RTL DSE
pass, the dumps look roughly comparable, except that there is the store to the
stack canary at the beginning and read from the stack canary at the end of the
function. In DSE dump for f2 function, one can see without
-fstack-protector-strong:
starting the processing of deferred insns
ending the processing of deferred insns
df_analyze called
**scanning insn=5
mems_found = 0, cannot_delete = true
**scanning insn=14
mem: (plus:DI (reg/f:DI 19 frame)
(const_int -16 [0xfff0]))
after canon_rtx address: (plus:DI (reg/f:DI 19 frame)
(const_int -16 [0xfff0]))
gid=0 offset=-16
processing const base store gid=0[-16..0)
mems_found = 1, cannot_delete = false
**scanning insn=11
mems_found = 0, cannot_delete = true
**scanning insn=12
mems_found = 0, cannot_delete = false
Locally deleting insn 14
deferring deletion of insn with uid = 14.
group 0 is frame related group 0(16+0): n 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11,
12, 13, 14, 15, 16 p
starting the processing of deferred insns
ending the processing of deferred insns
df_analyze called
df_worklist_dataflow_doublequeue: n_basic_blocks 3 n_edges 2 count 3 (1)
but with -fstack-protector-strong instead:
starting the processing of deferred insns
ending the processing of deferred insns
df_analyze called
**scanning insn=4
mem: (const_int 40 [0x28])
after canon_rtx address: (const_int 40 [0x28])
after cselib_expand address: (const_int 40 [0x28])
after canon_rtx address: (const_int 40 [0x28])
varying cselib base=1:4426 offset = 0
processing cselib load mem:(mem/f:DI (const_int 40 [0x28]) [4
MEM[( long unsigned int *)40B]+0 S8 A64 AS1])
mem: (plus:DI (reg/f:DI 19 frame)
(const_int -8 [0xfff8]))
after canon_rtx address: (plus:DI (reg/f:DI 19 frame)
(const_int -8 [0xfff8]))
gid=0 offset=-8
processing const base store gid=0[-8..0)
mems_found = 1, cannot_delete = true
**scanning insn=7
mems_found = 0, cannot_delete = true
**scanning insn=24
mem: (plus:DI (reg/f:DI 19 frame)
(const_int -32 [0xffe0]))
after canon_rtx address: (plus:DI (reg/f:DI 19 frame)
(const_int -32 [0xffe0]))
gid=0 offset=-32
processing const base store gid=0[-32..-16)
trying store in insn=4 gid=0[-8..0)
mems_found = 1, cannot_delete = false
**scanning insn=13
mems_found = 0, cannot_delete = true
**scanning insn=15
mem: (const_int 40 [0x28])
after canon_rtx address: (const_int 40 [0x28])
after cselib_expand address: (const_int 40 [0x28])
after canon_rtx address: (const_int 40 [0x28])
varying cselib base=1:4426 offset = 0
processing cselib load mem:(mem/f:DI (const_int 40 [0x28]) [4
MEM[( long unsigned int *)40B]+0 S8 A64 AS1])
processing cselib load against insn 24
removing from active insn=24 has store
processing cselib load against insn 4
removing from active insn=4 has store
adding wild read, volatile or barrier.
mems_found = 0, cannot_delete = true
**scanning insn=16
mems_found = 0, cannot_delete = true
**scanning insn=17
mem: (symbol_ref:DI ("__stack_chk_fail") [flags 0x41] )
after canon_rtx address: (symbol_ref:DI ("__stack_chk_fail") [flags 0x41]
)
gid=1 offset=0
processing const load gid=1[0..1)
**scanning insn=20
mems_found = 0, cannot_delete = false
group 0 is frame related group 0(24+0): n 1, 2, 3, 4, 5, 6, 7, 8, 17, 18, 19,
20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32 p
group 1(0+0): n p
starting the processing of deferred insns
ending the processing of deferred insns
df_analyze called
doing global processing
df_worklist_dataflow_doublequeue: n_basic_blocks 5 n_edges 4 count 5 (1)
So, the
(insn 15 13 16 2 (parallel [
(set (reg:CCZ 17 flags)
(unspec:CCZ [
(mem/v/f/c:DI (plus:DI (reg/f:DI 19 frame)
(const_int -8 [0xfff8])) [3
D.1950+0 S8 A64])
(mem/f:DI (const_int 40 [0x28]) [4
MEM[( long unsigned int *)40B]+0 S8 A64 AS1])
] UNSPEC_SP_TEST))
(clobber (scratch:DI))
]) "pr87370.c":30:1 978 {stack_protect_test_di}
(nil))
stack canary read invalidates the opportunity to remove the dead
(insn 24 7 13 2 (set (mem/c:V1TI (plus:DI (reg/f:DI 1
[Bug rtl-optimization/88796] -fstack-protector* kills RTL DSE opportunities
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88796 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-10 CC||ebotcazou at gcc dot gnu.org, ||law at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Ever confirmed|0 |1
