[Bug middle-end/82742] New: ICE on valid code at -O3: verify_flow_info failed

[su at cs dot ucdavis.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82742

Bug ID: 82742
   Summary: ICE on valid code at -O3: verify_flow_info failed
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

This seems to be a recent regression. 

$ gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 8.0.0 20171026 (experimental) [trunk revision 254125] (GCC)
$
$ gcctk -O2 small.c; ./a.out
$ gcc-7.2.0 -O3 small.c; ./a.out
$
$ gcctk -O3 small.c
small.c: In function ‘i’:
small.c:31:1: error: non-cold basic block 18 reachable only by paths crossing
the cold partition
 }
 ^
during RTL pass: bbro
small.c:31:1: internal compiler error: verify_flow_info failed
0x7f53e6 verify_flow_info()
../../gcc-source-trunk/gcc/cfghooks.c:263
0x80d104 checking_verify_flow_info
../../gcc-source-trunk/gcc/cfghooks.h:198
0x80d104 cfg_layout_finalize()
../../gcc-source-trunk/gcc/cfgrtl.c:4304
0x13788c9 execute
../../gcc-source-trunk/gcc/bb-reorder.c:2601
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$


--


int a, b, c, d;
static int e = 1;

void i (int);

char f (unsigned char g, int h)
{ 
  return g > (255 >> h) ? 0 : h;
}

void j (int g, int h)
{ 
  d = 0;
}

int k (int g)
{ 
  i (g);
  return a;
}

void i (int g)
{ 
  while (1)
{ 
  if (!b)
break;
  while (c)
j (k (f (d, g && e)), d);
}
}

int main ()
{ 
  i (0);
  return 0;
}

[Bug c++/82734] -Wignored-qualifiers is maybe too strict when using decltype

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82734

--- Comment #1 from Andrew Pinski  ---
Why can't you use std::remove_cv here?

[Bug debug/59515] -Og doesn't generate out-of-line copies of inline functions like -O0 does

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59515

--- Comment #3 from Andrew Pinski  ---
Maybe -fkeep-inline-functions ?

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[chrisj at rtems dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #44 from Chris Johns  ---
(In reply to Jonathan Wakely from comment #42)
> I think something else is going on here, and not a race condition in the
> makefile.

I agree. I see the failure after a few files have been built.

> 
> This would be more acceptable:
> 

I tried this change and it did not fix the issue for me. The patch I used on
gcc-7.2.0 is:

https://devel.rtems.org/attachment/ticket/3171/darwin-apfs-gcc-libstdc%2B%2B-bug-81797-redi-2.diff

[Bug fortran/29600] [F03] MINLOC and MAXLOC take an optional KIND argument

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29600

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #16 from Jerry DeLisle  ---
(In reply to Thomas Koenig from comment #15)
> Out of ideas at the moment, unassigning myself.

Without looking at your attempts, it seems one could parse in the scanner for
whether there is this optional argumanet. If not, set it to NULL and in that
case do what we do now, otherwise do a kind conversion.  Is this what you
tried?

Runtime would just check for the parameter and do it tat way. 

Or are you trying to inline this or do it all in the frontend?

[Bug c++/82081] Tail call optimisation of noexcept function leads to exception allowed through

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82081

Jonathan Wakely  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
 Resolution|INVALID |---

--- Comment #6 from Jonathan Wakely  ---
I think the code is valid, and should terminate.

[Bug tree-optimization/81028] GCC miscompiles placement new

[ch3root at openwall dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81028

Alexander Cherepanov  changed:

   What|Removed |Added

 CC||ch3root at openwall dot com

--- Comment #6 from Alexander Cherepanov  ---
Seems to be an exact dup of bug 57359.

Clang bug -- https://bugs.llvm.org/show_bug.cgi?id=21725 .

[Bug c++/82081] Tail call optimisation of noexcept function leads to exception allowed through

[pdziepak at quarnos dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82081

--- Comment #5 from Paweł Dziepak  ---
Is it really undefined? n4700 states in 18.4/5:

Whenever an exception is thrown and the search for a handler (18.3) encounters
the outermost block of a function with a non-throwing exception specification,
the function std::terminate() is called (18.5.1).

[Bug c++/82081] Tail call optimisation of noexcept function leads to exception allowed through

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82081

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Andrew Pinski  ---
Actually I was wrong. What changes in c++17 is throw () becomes the same as
noexcept and no longer has the runtime catch. 

So is invalid and undefined at runtime.

[Bug c++/82081] Tail call optimisation of noexcept function leads to exception allowed through

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82081

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-10-26
 Ever confirmed|0   |1

--- Comment #3 from Andrew Pinski  ---
C++11 until c++17 does not require the unwinding for except.  This changed with
c++17.  Can you try with -std=c++17 (or -std=gnu++17)?

[Bug c++/82741] Optimisations may cause noexcept specifier to be ignored

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82741

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Andrew Pinski  ---
Dup of bug 82081

*** This bug has been marked as a duplicate of bug 82081 ***

[Bug c++/82081] Tail call optimisation of noexcept function leads to exception allowed through

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82081

Andrew Pinski  changed:

   What|Removed |Added

 CC||pdziepak at quarnos dot org

--- Comment #2 from Andrew Pinski  ---
*** Bug 82741 has been marked as a duplicate of this bug. ***

[Bug c++/82741] New: Optimisations may cause noexcept specifier to be ignored

[pdziepak at quarnos dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82741

Bug ID: 82741
   Summary: Optimisations may cause noexcept specifier to be
ignored
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pdziepak at quarnos dot org
  Target Milestone: ---

On x86_64:

  gcc version 7.2.1 20170915 (Red Hat 7.2.1-2) (GCC) 

The following code results in noexcept being ignored if optimisations are
enabled.

--
volatile bool should_throw = false;

[[gnu::noinline]]
void foo() {
if (should_throw) {
throw 42;
}
}

[[gnu::noinline]]
void bar() noexcept {
should_throw = true;
foo();
}

int main() {
try {
foo();
bar();
foo();
} catch (...) { }
}
--

When compiled with -O1 or higher exception thrown from bar() doesn't cause
std::terminate to be called.

bar() is compiled to:

00400730 :
  400730:   c6 05 2a 09 20 00 01movb   $0x1,0x20092a(%rip)#
601061 
  400737:   eb c7   jmp400700 

[Bug rtl-optimization/82683] Combine: GCC generates bad code with -tune=thunderx2t99

[sje at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82683

--- Comment #11 from Steve Ellcey  ---
I think I see where this is going wrong but I don't know what to do about it.
In try_combine, line 3288 we have i2 and i3 of:

(insn 18 16 19 3 (set (reg:DI 91)
(ashift:DI (reg:DI 83 [ _26 ])
(const_int 2 [0x2]))) "x.i":31 674 {*aarch64_ashl_sisd_or_int_di3}
 (expr_list:REG_DEAD (reg:DI 83 [ _26 ])
(nil)))
(insn 19 18 20 3 (set (reg/f:DI 78 [ _7 ])
(plus:DI (reg/f:DI 76 [ _4 ])
(reg:DI 91))) "x.i":31 94 {*adddi3_aarch64}
 (expr_list:REG_DEAD (reg:DI 91)
(expr_list:REG_DEAD (reg/f:DI 76 [ _4 ])
(nil

After that if statement we have i2 and i3 looking like:

(insn 18 16 19 3 (set (reg:DI 91)
(ashift:DI (reg:DI 83 [ _26 ])
(const_int 2 [0x2]))) "x.i":31 674 {*aarch64_ashl_sisd_or_int_di3}
 (expr_list:REG_DEAD (reg:DI 83 [ _26 ])
(nil)))
(insn 19 18 20 3 (set (reg/f:DI 78 [ _7 ])
(plus:DI (ashift:DI (reg:DI 83 [ _26 ])
(const_int 2 [0x2]))
(reg/f:DI 76 [ _4 ]))) "x.i":31 94 {*adddi3_aarch64}
 (expr_list:REG_DEAD (reg:DI 91)
(expr_list:REG_DEAD (reg/f:DI 76 [ _4 ])
(nil


There is the bogus REG_DEAD of 83 on insn 18.  I don't know where or how this
should be fixed up though.

[Bug c++/82740] New: [concepts] requires clause evaluated early

[Casey at Carter dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82740

Bug ID: 82740
   Summary: [concepts] requires clause evaluated early
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Casey at Carter dot net
  Target Milestone: ---

Created attachment 42483
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42483=edit
Repro

Trunk as of 20170825 miscompiles this program
(https://wandbox.org/permlink/70zH8c8JMQZMDUas):

template
concept bool C = requires(const T& t) { t.foo(); };

template
struct Base {
constexpr T const& derived() const { return static_cast(*this); }
constexpr bool bar() const requires
#ifndef WORKAROUND
requires(const T& t) { t.foo(); }
#else
C
#endif
{ derived().foo(); return true; }
};

template
struct Derived : Base {
constexpr void foo() const {}
};

int main() {
static_assert(Derived{}.bar());
}

with diagnostics:

prog.cc: In instantiation of 'struct Base':
prog.cc:17:8:   required from 'struct Derived'
prog.cc:22:32:   required from here
prog.cc:9:34: error: invalid use of incomplete type 'const struct Derived'
 requires(const T& t) { t.foo(); }
~~^~~
prog.cc:17:8: note: declaration of 'struct Derived'
 struct Derived : Base {
^~~

despite that N4700 [temp.inst]/16
(http://eel.is/c++draft/temp.spec#temp.inst-16) specifies that:

The partial-concept-ids and requires-clause of a template specialization or
member function are not instantiated along with the specialization or function
itself, even for a member function of a local class; substitution into the
atomic constraints formed from them is instead performed as specified in
[temp.constr.decl] and [temp.constr.atomic] when determining whether the
constraints are satisfied. [ Note: The satisfaction of constraints is
determined during name lookup or overload resolution ([over.match]). — end note
]

(Note that the text of [temp.inst]/16 in the Concepts TS is similar.)

If WORKAROUND is defined, replacing the ad hoc requirement with an identical
named concept, the program compiles without diagnostics.

[Bug rtl-optimization/82683] Combine: GCC generates bad code with -tune=thunderx2t99

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82683

--- Comment #10 from Segher Boessenkool  ---
reg-notes.def says

/* The value in REG dies in this insn (i.e., it is not needed past
   this insn).  If REG is set in this insn, the REG_DEAD note may,
   but need not, be omitted.  */
REG_NOTE (DEAD)

so the notes should have gone to insn 20 here, not insn 21 (which
is a new r83).  Or deleted altogether.

[Bug libstdc++/82739] New: Sort is 30% slower compared to gcc44 on presorted array

[rogerio.souza at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82739

Bug ID: 82739
   Summary: Sort is 30% slower compared to gcc44 on presorted
array
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rogerio.souza at gmail dot com
  Target Milestone: ---

In 2013 a bug was filed to fix a large performance degradation on
reverse-sorted array, which got fixed:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437

However there is near 60% performance degradation with GCC 7.2.0 compared to
GCC 4.4.5, this time when running std::sort on a forward-sorted array.

Here is the testcase:

sort.cpp
===
#include 
#include 

using namespace std;

int main()
{
  const int num = 10;   
  std::vector v;  
  v.reserve(num);

  for(int i=0;i!=num;++i) v.push_back(i);
  sort(v.begin(), v.end());
//  std::sort(std::begin(v), std::end(v));
}
===

Compilation Line: g++ -O3 sort.cpp -o sort
Run: time ./sort

# Server details
$ uname -a
Linux server 2.6.18-194.el5 #1 SMP Tue Mar 16 21:52:39 EDT 2010 x86_64 x86_64
x86_64 GNU/Linux

Results:

gcc version 4.1.2
real0m25.511s
user0m23.960s
sys 0m1.301s

gcc version 4.4.5
real0m20.241s
user0m18.716s
sys 0m1.328s

gcc version 4.8.3
real0m26.742s
user0m25.167s
sys 0m1.314s

gcc version 6.3.0
real0m33.911s
user0m32.312s
sys 0m1.266s

gcc version 7.2.0 
real0m31.916s
user0m30.308s
sys 0m1.299s

Is there any way to improve the run-time performance?

[Bug fortran/82471] Reorder loop for unfavorable index ordering in DO CONCURRENT and FORALL

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82471

--- Comment #10 from Thomas Koenig  ---
Created attachment 42482
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42482=edit
Here's a first attempt...

[Bug fortran/82709] f2008 complex%re and %im not yet implemented

[harper at msor dot vuw.ac.nz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82709

--- Comment #2 from harper at msor dot vuw.ac.nz ---
Apologies - I did not find bug 40196 when I was looking for possible 
duplicates of my bug 82709.

On Tue, 24 Oct 2017, dominiq at lps dot ens.fr wrote:

> Date: Tue, 24 Oct 2017 23:51:55 +
> From: dominiq at lps dot ens.fr 
> To: John Harper 
> Subject: [Bug fortran/82709] f2008 complex%re and %im not yet implemented
> Resent-Date: Wed, 25 Oct 2017 12:52:22 +1300 (NZDT)
> Resent-From: 
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82709
>
> Dominique d'Humieres  changed:
>
>   What|Removed |Added
> 
> Status|UNCONFIRMED |RESOLVED
> Resolution|--- |DUPLICATE
>
> --- Comment #1 from Dominique d'Humieres  ---
> Dup.
>
> *** This bug has been marked as a duplicate of bug 40196 ***
>
> -- 
> You are receiving this mail because:
> You reported the bug.
>


-- John Harper, School of Mathematics and Statistics
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail john.har...@vuw.ac.nz phone (+64)(4)463 5276 fax (+64)(4)463 5045

[Bug rtl-optimization/82692] [8 Regression] Ordered comparisons used for unordered built-ins

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82692

Uroš Bizjak  changed:

   What|Removed |Added

  Attachment #42479|0   |1
is obsolete||

--- Comment #20 from Uroš Bizjak  ---
Created attachment 42481
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42481=edit
WIP 2 patch

[Bug tree-optimization/82707] ICE in verify_gimple_in_cfg at tree-cfg.c:5395

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82707

Tom de Vries  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #13 from Tom de Vries  ---
Patch committed, marking resolved-fixed.

[Bug tree-optimization/82707] ICE in verify_gimple_in_cfg at tree-cfg.c:5395

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82707

--- Comment #12 from Tom de Vries  ---
Author: vries
Date: Thu Oct 26 20:09:24 2017
New Revision: 254120

URL: https://gcc.gnu.org/viewcvs?rev=254120=gcc=rev
Log:
Fix unsharing of GIMPLE_OMP_{SINGLE,TARGET,TEAMS} in gimple_copy

2017-10-26  Tom de Vries  

PR tree-optimization/82707
* gimple.c (gimple_copy): Fix unsharing of
GIMPLE_OMP_{SINGLE,TARGET,TEAMS}.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple.c

[Bug other/82738] New: [meta-bug] issues with the -Og optimization level

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82738

Bug ID: 82738
   Summary: [meta-bug] issues with the -Og optimization level
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egallager at gcc dot gnu.org
Depends on: 59515, 59658, 63440, 65244, 68836, 71864, 78394, 78685
  Target Milestone: ---

http://gcc.gnu.org/ml/gcc-patches/2017-10/msg01972.html proposed changing the
default optimization level to -Og. I replied saying there were bugs with it I'd
like to see fixed first. This bug is to track those other bugs.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59515
[Bug 59515] -Og doesn't generate out-of-line copies of inline functions like
-O0 does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59658
[Bug 59658] Document -f* flags enabled by -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63440
[Bug 63440] -Og does enable -fmerge-constants too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65244
[Bug 65244] Bogus -Wmaybe-uninitialized warning with posix_memalign() and -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68836
[Bug 68836] GCC can't properly emit debug info for function arguments in a
back-trace when using -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71864
[Bug 71864] x86_64-w64-mingw32, ICE when '-Og' & '-mssse3' are used
simultaneously
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78394
[Bug 78394] False positives of maybe-uninitialized with -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78685
[Bug 78685] -Og generates too many ""s

[Bug target/82735] _mm256_zeroupper does not invalidate previously computed registers

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82735

--- Comment #3 from Marc Glisse  ---
Actually, what CSE1 does might be fine, and it is LRA that should have noticed
that the register it assigned was clobbered, so it should have spilled (or
better rematerialized). Assuming the i386 backend does say that this unspec
clobbers the registers, which I am not seeing right now (but I may not be
looking in the right place).

[Bug target/82735] _mm256_zeroupper does not invalidate previously computed registers

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82735

Marc Glisse  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-10-26
 Ever confirmed|0   |1

--- Comment #2 from Marc Glisse  ---
CSE1 happily turns uses of the second constant, loaded after vzeroupper, into
uses of the first constant, loaded before, ignoring the fact that vzeroupper
clobbers (the upper part of) all avx registers.

[Bug preprocessor/58687] "#line __LINE__ ..." changes subsequent line numbers

[mtewoodbury at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687

--- Comment #35 from Max TenEyck Woodbury  ---
True, none of the specifically listed maintainers have commented on
this version of the patch.  There are three people listed and a
general reference to all C and C++ front end maintainers.  It is
possible that they are not even aware of this discussion.

You are -not- listed specifically as a libcpp maintainer, only as a
general C front end maintainer specializing in soft-fp, i18n,
documentation and option handling.  On the other hand your name does
appear in the libcpp ChangeLog and I presume jsm28 is your committer
ID.  Your code looks good in general.

I do appreciate your helping me clarify my arguments.  I have indeed
been sloppy in my phrasing on more than one occasion.  On the other
hand, you have -not- addressed the main reason for adding this change:
this alternate implementation of #line __LINE__ is useful while the
current implementation is not.  As noted in an earlier comment, it
could -help- address at least two other issues currently being
discussed in other reports.

On 10/26/17, joseph at codesourcery dot com  wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
>
> --- Comment #34 from joseph at codesourcery dot com  dot com> ---
> None of the other preprocessor maintainers have commented on this bug in
> the past four years to disagree with my view of the natural identification
> of the current line for this __LINE__ token.  Unless any comment soon I
> think we can take there to be consensus on my interpretation, i.e. that
> this is INVALID and the existing interpretation is the most appropriate
> one.
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug c/67224] UTF-8 support for identifier names in GCC

[spoa at eircom dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224

spoa at eircom dot net  changed:

   What|Removed |Added

 CC||spoa at eircom dot net

--- Comment #23 from spoa at eircom dot net  ---
An important patch. Is there a similar patch for versions later than 5.2.0 of
gcc?  I'm looking for gcc-7.2.1-2 patch for unicode idenfifiers.

[Bug c++/82737] Compiler segfault on compilation of a certain file (full cause unknown) (file too large for upload, link provided)

[brycm001 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82737

Matti Bryce  changed:

   What|Removed |Added

 Target||x86_64-w64-mingw32
URL||https://bitbucket.org/TheEd
   ||enCrazy/gassim/src/293fc159
   ||13df18c79026d4a7084d9d21e3d
   ||53597/_share_gcc_bug/Manage
   ||r.cpp.i?at=master
   ||r=file-view-default
 CC||brycm001 at gmail dot com
   Host||x86_64-w64-mingw32
  Alias||Segfault, on, 7.2.0, MSYS2,
   ||mingw-w64, debug, symbols
  Known to fail||7.2.0

--- Comment #1 from Matti Bryce  ---
Important note: This bug does not appear to occur without -g as a flag (debug)

[Bug c++/82737] New: Compiler segfault on compilation of a certain file (full cause unknown) (file too large for upload, link provided)

[brycm001 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82737

Bug ID: 82737
   Summary: Compiler segfault on compilation of a certain file
(full cause unknown) (file too large for upload, link
provided)
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: brycm001 at gmail dot com
  Target Milestone: ---

This is a bug that manifests itself in a segfault on an attempt to compile
Manager.cpp from my GasSim project on MinGW-w64 MSYS2, over Windows 10 64-bit.

GCC version: 7.2.0

Output of gcc -v:
--

Using built-in specs.
COLLECT_GCC=C:\msys64\mingw64\bin\gcc.exe
COLLECT_LTO_WRAPPER=C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-7.2.0/configure --prefix=/mingw64
--with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
--with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include
--libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64
--with-tune=generic --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada
--enable-shared --enable-static --enable-libatomic --enable-threads=posix
--enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-time=yes
--disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check
--enable-lto --enable-libgomp --disable-multilib --enable-checking=release
--disable-rpath --disable-win32-registry --disable-nls --disable-werror
--disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64
--with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64
--with-pkgversion='Rev1, Built by MSYS2 project'
--with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as
--with-gnu-ld
Thread model: posix
gcc version 7.2.0 (Rev1, Built by MSYS2 project)

--

My .i file is (far) too big to be uploaded directly, so I'm going to give you a
link to where I added it on my git repo:
https://bitbucket.org/TheEdenCrazy/gassim/raw/293fc15913df18c79026d4a7084d9d21e3d53597/_share_gcc_bug/Manager.cpp.i

--

Error message when running from cmake:

C:\msys64\mingw64\bin\cmake.exe --build C:\repos\gassim\cmake-build-debug
--target GasSim -- -j 4
[  3%] Built target Boxer
[ 37%] Built target glfw
Scanning dependencies of target GasSim
[ 41%] Building CXX object CMakeFiles/GasSim.dir/src/Control/Manager.cpp.obj
[ 41%] Building CXX object CMakeFiles/GasSim.dir/src/main.cpp.obj
[ 41%] Building CXX object
CMakeFiles/GasSim.dir/src/Control/DebugHandlers.cpp.obj
C:\repos\gassim\src\Control\Manager.cpp: In function 'std::__cxx11::string
control::_getGLDebugTypeString(GLenum, GLenum, GLuint, const string&)':
C:\repos\gassim\src\Control\Manager.cpp:181:5: internal compiler error:
Segmentation fault
 }
 ^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
mingw32-make.exe[3]: *** [CMakeFiles\GasSim.dir\build.make:113:
CMakeFiles/GasSim.dir/src/Control/Manager.cpp.obj] Error 1
mingw32-make.exe[2]: *** [CMakeFiles\Makefile2:68: CMakeFiles/GasSim.dir/all]
Error 2
mingw32-make.exe[1]: *** [CMakeFiles\Makefile2:80: CMakeFiles/GasSim.dir/rule]
Error 2
mingw32-make.exe: *** [Makefile:185: GasSim] Error 2



CMake & make command that produces this error:
"cmake -G "MSYS Makefiles" /c/repos/GasSim -DCMAKE_BUILD_TYPE=Debug"

then 

"make -j4 src/Control/Manager.cpp.obj"



Raw build command:
"/C/msys64/mingw64/bin/g++.exe  -DEIGEN_DONT_ALIGN -DGLM_ENABLE_EXPERIMENTAL
-I/C/repos/gassim/include -I/C/repos/gassim/ext/glm -I/C/msys64/mingw64/include
-I/C/repos/gassim/ext/glad/include -I/C/repos/gassim/ext/CEGUI/cegui/include
-I/C/repos/gassim/ext/Boxer/include -I/C/repos/gassim/ext/glfw/include  -O2
-static-libstdc++ -g   -std=gnu++1z -o
CMakeFiles/GasSim.dir/src/Control/Manager.cpp.obj -c
/C/repos/gassim/src/Control/Manager.cpp"

(I removed eigen from the project though, so the -DEIGEN_DONT_ALIGN part is
irrelevant)

-

Error message on running the single file target:

"
make -f CMakeFiles/GasSim.dir/build.make
CMakeFiles/GasSim.dir/src/Control/Manager.cpp.obj
make[1]: Entering directory '/home/Matti/build/GasSim'
Building CXX object CMakeFiles/GasSim.dir/src/Control/Manager.cpp.obj
/C/msys64/mingw64/bin/g++.exe  -DEIGEN_DONT_ALIGN -DGLM_ENABLE_EXPERIMENTAL
-I/C/repos/gassim/include -I/C/repos/gassim/ext/glm -I/C/msys64/mingw64/include
-I/C/repos/gassim/ext/glad/include -I/C/repos/gassim/ext/CEGUI/cegui/include
-I/C/repos/gassim/ext/Boxer/include -I/C/repos/gassim/ext/glfw/include  -O2
-static-libstdc++ -g   -std=gnu++1z -o
CMakeFiles/GasSim.dir/src/Control/Manager.cpp.obj -c
/C/repos/gassim/src/Control/Manager.cpp

[Bug fortran/81758] [7/8 Regression] [OOP] Broken vtab

[liakhdi at ornl dot gov]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81758

--- Comment #21 from DIL  ---
Greatly appreciate!

[Bug fortran/81758] [7/8 Regression] [OOP] Broken vtab

[paul.richard.thomas at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81758

--- Comment #20 from paul.richard.thomas at gmail dot com  ---
Hi Dmitry,

I will persist with 81758 until I have a satisfactory testcase and
then I promise that I will move to 80850.

Cheers

Paul

On 26 October 2017 at 15:20, liakhdi at ornl dot gov
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81758
>
> --- Comment #19 from DIL  ---
> Hi Paul,
>
> Great, thanks a lot! That was pretty quick. Upon a chance, as there is still a
> momentum :), could you please take a brief look at bug #80850 to see whether 
> it
> may be related since you mentioned "allocation with source" in the previous
> comment? That's exactly what 80850 is about. If fails to allocate a previously
> nullified pointer with a sourced allocate(), complaining that the pointer is
> already allocated. From what I could deduce from valgrind, somehow the code
> produced by the sourced allocate() here encounters a corrupted internal 
> pointer
> representation. If you need any debugging information/screenshots from me, I
> will be happy to provide (I did not really see an easy way to reduce the 
> code).
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug c++/82736] -Wl not wrapping all functions call

[federico.kircheis at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82736

--- Comment #4 from Federico Kircheis  ---
Thank you very much for your feedback.

With "-static" or "-static-libstdc++" i got the expected (at least for me)
result.

I guess that I'll need to register to https://sourceware.org/bugzilla/ to ask
if the behavior is correct, since it would be nice if it would work without
linking statically.

[Bug other/82704] GCC fails to download prerequisites on busybox distro (unrecognized sha512sum --check)

[keno at juliacomputing dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82704

--- Comment #2 from Keno Fischer  ---
Well, the script has a separate code path for Darwin anyway, since Darwin's
sha512sum is spelled `shasum -a 512`, but `shasum` also supports `-c` (as well
as `--check`).

[Bug middle-end/78809] Inline strcmp with small constant strings

[paolo.carlini at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-10-26
 CC|qing.zhao at oracle dot com|
   Assignee|unassigned at gcc dot gnu.org  |qing.zhao at oracle dot 
com
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #19 from Paolo Carlini  ---
Qing is on it.

[Bug c++/82736] -Wl not wrapping all functions call

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82736

--- Comment #3 from Jonathan Wakely  ---
This might also be due to how glibc defines the clock_gettime symbol (as a weak
alias for its internal __clock_gettime), in which case it would still belong in
https://sourceware.org/bugzilla/ but for glibc not binutils.

[Bug c++/82736] -Wl not wrapping all functions call

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82736

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Jonathan Wakely  ---
(In reply to Federico Kircheis from comment #0)
> AFAIK, std::chrono::system_clock::now(); uses clock_gettime internally.

That depends. Sometimes it uses a system call directly. Sometimes it uses
gettimeofday(). Sometimes it just uses time().

Anyway, as Andrew says, this has nothing to do with GCC. The library has an
undefined reference to clock_gettime, what the linker does with that depends on
the linker, not GCC. Try https://sourceware.org/bugzilla/

[Bug target/82735] _mm256_zeroupper does not invalidate previously computed registers

[marcin.slusarz at intel dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82735

--- Comment #1 from Marcin Ślusarz  ---
Heh, there are really stupid bugs in both files. Thankfully they don't change
the outcome.

Updated code:
$ cat main.c 
#include 
#include 

void test(char *dest);

int main()
{
char buf[64];
memset(buf, 0x2, 64);
test(buf);
for (int i = 0; i < 32; ++i)
printf("%d ", buf[i]);
printf("\n");
return 0;
}
$ cat zeroupper.c 
#include 

void test(char *dest)
{
__m256i ymm1 = _mm256_set1_epi8((char)0x1);
_mm256_storeu_si256((__m256i *)(dest + 32), ymm1);
_mm256_zeroupper();
__m256i ymm2 = _mm256_set1_epi8((char)0x1);
_mm256_storeu_si256((__m256i *)dest, ymm2);
}

Still the output is:
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

[Bug preprocessor/58687] "#line __LINE__ ..." changes subsequent line numbers

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687

--- Comment #34 from joseph at codesourcery dot com  ---
None of the other preprocessor maintainers have commented on this bug in 
the past four years to disagree with my view of the natural identification 
of the current line for this __LINE__ token.  Unless any comment soon I 
think we can take there to be consensus on my interpretation, i.e. that 
this is INVALID and the existing interpretation is the most appropriate 
one.

[Bug c++/82736] -Wl not wrapping all functions call

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82736

--- Comment #1 from Andrew Pinski  ---
First -Wl, options just pass directly to the linker.  That means these options
are linker options and not gcc options.  The linker which are most likely using
is the gnu linker, please this to them.  But what I suspect this is not a bug
and you would to use -static option to get the behavior you want.

[Bug c/82723] Collisions with standard library not detected by linker

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82723

--- Comment #4 from Andrew Pinski  ---
Again this is not a gcc issue. It is a linker issue.  You are most likely using
binutils for the linker.

Second this has been this behavior ever since the elf format came about 20
years ago.

[Bug c/82723] Collisions with standard library not detected by linker

[berck.nash at wdc dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82723

--- Comment #3 from Berck Nash  ---
I can see that someone might want to do this, but it certainly doesn't seem
like it should be default behavior.  I think it's a bit absurd to expect an end
user to know the names of every function called by every library function.  It
seems like, by default, a collision should be reported.  Additionally, even if
this is a feature, there isn't even check to see if the functions have
compatible parameter lists, which can make for some disastrous mistakes...

[Bug c++/82736] New: -Wl not wrapping all functions call

[federico.kircheis at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82736

Bug ID: 82736
   Summary: -Wl not wrapping all functions call
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: federico.kircheis at gmail dot com
  Target Milestone: ---

AFAIK, std::chrono::system_clock::now(); uses clock_gettime internally.

For various reasons (unit testing), I would like to "mock" time calls, so I
tried to use the -Wl option, but it does not seem to work as expected.

Given the following program:

#include 
#include 
#include 

extern "C" {
#if USE_WRAP
int __wrap_clock_gettime(clockid_t, struct timespec *tp) {
#else
int clock_gettime(clockid_t, struct timespec *tp) {
#endif
*tp = {};
tp->tv_sec = 123;
return 0;
}
}

int main(){
clockid_t clk_id{};
struct timespec tp;
auto res = clock_gettime(clk_id, );

assert(res == 0);
assert(tp.tv_sec == 123);

auto now = std::chrono::system_clock::now();
auto now_t = std::chrono::system_clock::to_time_t(now);
assert(now_t == 123);
}
---

When executing "g++ -std=c++11 main.cpp && ./a.out" the program runs and
returns 0, while when executing "g++ -std=c++11 -DUSE_WRAP
"-Wl,-wrap=clock_gettime" main.cpp && ./a.out" the program crashes with "int
main(): Assertion `now_c == 123' failed.".


AFAIK the version compiled without the macro USE_WRAP is UB , even if it works.
Therefore I would prefer to use the "-Wl" compiler option.

The statement "assert(tp.tv_sec == 123);" assures that the "mocked" version of
the function is called. This happens in both cases.


I've also tried to implement wrapping functions for time() and gettimeofday()
(with and without the wrap option), but it did not made any difference.

I've also tried to compile those functions in a shared library, but it did not
made a difference either.

I would like to find a robust way for wrapping all OS functions call for
querying what time it is and eventually call the original function through
dlsym(RTLD_NEXT, funcname)).
Simply overwriting them seems to work, but is AFAIK UB.
Using "-Wl" works too, but only if using the C functions, not when using
std::chrono.

If it may be somehow relevant, clang++ (version 3.8.1-24) behaves exactly the
same way.

[Bug sanitizer/81148] UBSAN: two more false positives

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81148

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #18 from Richard Biener  ---
Fixed meanwhile.

[Bug c/82735] New: _mm256_zeroupper does not invalidate previously computed registers

[marcin.slusarz at intel dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82735

Bug ID: 82735
   Summary: _mm256_zeroupper does not invalidate previously
computed registers
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marcin.slusarz at intel dot com
  Target Milestone: ---

$ cat main.c 
#include 
#include 

void test(char *dest);

int main()
{
char buf[32];
memset(buf, 0x2, 32);
test(buf);
for (int i = 0; i < 32; ++i)
printf("%d ", buf[i]);
printf("\n");
}
$ cat zeroupper.c 
#include 

void test(char *dest)
{
__m256i ymm1 = _mm256_set1_epi8((char)0x1);
_mm256_storeu_si256((__m256i *)dest + 32, ymm1);
_mm256_zeroupper();
__m256i ymm2 = _mm256_set1_epi8((char)0x1);
_mm256_storeu_si256((__m256i *)dest, ymm2);
}
$ gcc -c -std=c99 -O2 main.c
$ gcc -c -std=c99 -O2 zeroupper.c -mavx
$ gcc zeroupper.o main.o -o zeroupper
$ ./zeroupper
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Expected output is:
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

I can reproduce it on gcc 4.9, 5.4.1, 6.3.0 and 7.2.1.
gcc 4.6.4 is not affected.
clang 3.5, 3.8, 3.9 and 4.0 produce the expected output.

[Bug rtl-optimization/82396] [8 Regression] qsort comparator non-negative on sorted output: 4 in ready_sort_real in haifa scheduler

[wilco at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82396

Wilco  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #15 from Wilco  ---
Fixed, temporary workaround removed.

[Bug middle-end/82407] [8 Regression][meta-bug] qsort_chk fallout tracking

[wilco at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82407
Bug 82407 depends on bug 82396, which changed state.

Bug 82396 Summary: [8 Regression] qsort comparator non-negative on sorted 
output: 4 in ready_sort_real in haifa scheduler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82396

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

[Bug fortran/81758] [7/8 Regression] [OOP] Broken vtab

[liakhdi at ornl dot gov]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81758

--- Comment #19 from DIL  ---
Hi Paul,

Great, thanks a lot! That was pretty quick. Upon a chance, as there is still a
momentum :), could you please take a brief look at bug #80850 to see whether it
may be related since you mentioned "allocation with source" in the previous
comment? That's exactly what 80850 is about. If fails to allocate a previously
nullified pointer with a sourced allocate(), complaining that the pointer is
already allocated. From what I could deduce from valgrind, somehow the code
produced by the sourced allocate() here encounters a corrupted internal pointer
representation. If you need any debugging information/screenshots from me, I
will be happy to provide (I did not really see an easy way to reduce the code).

[Bug target/82713] [8 Regression] ICE in ix86_builtin_vectorization_cost, at config/i386/i386.c:44475

[andrey.y.guskov at intel dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82713

--- Comment #4 from Andrey Guskov  ---
Option set:
-with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-shared
--enable-host-shared --enable-clocale=gnu --enable-cloog-backend=isl
--enable-languages=c,c++,fortran,jit,lto -with-arch=slm --with-cpu=slm

[Bug tree-optimization/81661] [7/8 Regression] ICE in gimplify_modify_expr, at gimplify.c:5638

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81661

--- Comment #5 from Richard Biener  ---
One possibility is instead of using

 may_be_zero ? 0 : niter

as niter for code-generation use

 (may_be_zero ? 0 : 1) * niter

This avoids the gimplification issue.  We assemble this as

call__addvsi3
movl%eax, %esi
subl%ebp, %esi
cmpl%ebp, %eax
setge   %al
movzbl  %al, %eax
imull   %eax, %esi

so it definitely is ugly (we're lacking any pattern matching on this
turning it back to a COND_EXPR).  And of course we're then unconditionally
emitting a possibly trapping expression into the IL.

For the case in question SCEV analysis knows the expression is executed
if the loop is entered (otherwise it would have rewritten it to unsigned
arithmetic).  Also the niter expression is usually similar to the
condition operators.

So I think a solution boils down to the consumer doing sth more intelligent
than building a COND_EXPR and later expecting to just code-gen that via
force_gimple_operand.  For the vectorizer this could mean a workaround
like storing niter away somewhere and using a new SSA name for the
niter part in the COND_EXPR and making sure to emit the definition for it
in the correct place.  Or going the multiplication way suggested above
for maybe trapping niter (note that tree_could_trap_p doesn't work
recursively, the gimplifier has generic_expr_could_trap_p for this).

Which also means a solution could be to simply not vectorize
loops with IV operations that might trap.

[Bug target/82713] [8 Regression] ICE in ix86_builtin_vectorization_cost, at config/i386/i386.c:44475

[andrey.y.guskov at intel dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82713

Andrey Guskov  changed:

   What|Removed |Added

 CC||andrey.y.guskov at intel dot 
com

--- Comment #3 from Andrey Guskov  ---
r254012 also triggers gcc.target/i386/pr61403.c:

PASS: gcc.target/i386/pr61403.c (test for excess errors)
FAIL: gcc.target/i386/pr61403.c scan-assembler blend

[Bug rtl-optimization/82677] Many projects (linux, coreutils, GMP, gcrypt, openSSL, etc) are misusing asm(divq/divl) etc, potentially resulting in faulty/unintended optimisations

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82677

--- Comment #11 from rguenther at suse dot de  ---
On Thu, 26 Oct 2017, nisse at lysator dot liu.se wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82677
> 
> Niels Möller  changed:
> 
>What|Removed |Added
> 
>  CC||nisse at lysator dot liu.se
> 
> --- Comment #10 from Niels Möller  ---
> Out of curiosity, how is this handled for division instructions generated by
> gcc, with no __asm__ involved? E.g., consider
> 
> int foo(int d) {
>   int r = 1234567;
>   if (d != 0)
> r = r / d;
>   return r;
> }
> 
> On an architecture where the div instruction doesn't raise any exception on
> divide by zero, this function could be compiled to a division instruction +
> conditional move, without any branch instruction. Right?
> 
> But on most architectures, that optimization would be invalid, and the 
> compiler
> must somehow know that. Is that a property on the representation of division
> expression? Or is it tied to some property of the instruction pattern for the
> divide instruction?
> 
> My question really is: What would it take to mark an __asm__ expression so 
> that
> it's treated in the same way as a plain C division?

The division is possibly trapping (due to special value of zero) and thus
is never hoisted out of a conditional region.

Similar to a pointer dereference where the pointer may be zero btw.

[Bug rtl-optimization/82677] Many projects (linux, coreutils, GMP, gcrypt, openSSL, etc) are misusing asm(divq/divl) etc, potentially resulting in faulty/unintended optimisations

[nisse at lysator dot liu.se]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82677

Niels Möller  changed:

   What|Removed |Added

 CC||nisse at lysator dot liu.se

--- Comment #10 from Niels Möller  ---
Out of curiosity, how is this handled for division instructions generated by
gcc, with no __asm__ involved? E.g., consider

int foo(int d) {
  int r = 1234567;
  if (d != 0)
r = r / d;
  return r;
}

On an architecture where the div instruction doesn't raise any exception on
divide by zero, this function could be compiled to a division instruction +
conditional move, without any branch instruction. Right?

But on most architectures, that optimization would be invalid, and the compiler
must somehow know that. Is that a property on the representation of division
expression? Or is it tied to some property of the instruction pattern for the
divide instruction?

My question really is: What would it take to mark an __asm__ expression so that
it's treated in the same way as a plain C division?

[Bug middle-end/81659] ICE in verify_dominators, at dominance.c:1184

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81659

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-10-26
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Testing patch.

[Bug c++/82734] New: -Wignored-qualifiers is maybe too strict when using decltype

[sylvestre at debian dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82734

Bug ID: 82734
   Summary: -Wignored-qualifiers is maybe too strict when using
decltype
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sylvestre at debian dot org
  Target Milestone: ---

With the following code:
#include 
#include 

void foo() {
  const int BLOCK_SIZE = 42;
  static_assert(
BLOCK_SIZE <
  static_cast(INT32_MAX));
}


# g++-7 -c -Wall -Wignored-qualifiers foo.cpp
# g++-8 -c -Wall -Wignored-qualifiers foo.cpp
foo.cpp: In function 'void foo()':
foo.cpp:9:50: warning: type qualifiers ignored on cast result type
[-Wignored-qualifiers]
   static_cast(INT32_MAX));
  ^


Either:
* The warning is too strict. In some cases, I don't control what BLOCK_SIZE can
be and the const isn't a big deal
* I should have in the warning the definition of BLOCK_SIZE to have an idea of
what is going on.

[Bug libstdc++/63466] sstream is very slow

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63466

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #5 from Jonathan Wakely  ---
The C code:

$ time ./tstream-c < testfile 

real0m0.058s
user0m0.055s
sys 0m0.003s

My rewrite without  from comment 4:

$ time ./a.out < testfile 

real0m0.095s
user0m0.089s
sys 0m0.006s


So I still don't think there's anything to "fix" here. If you don't need the
full flexibility of a stringstream (and new variables to hold copies of the
input, rather than splitting in in-place) then don't do it that way.

[Bug other/82327] [7 Regression] ICE in equal_mem_array_ref_p, at tree-ssa-scopedtables.c:429 (i686-linux-gnu)

[doko at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82327

Matthias Klose  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #8 from Matthias Klose  ---
closing

[Bug debug/82425] [8 regression] gcc.dg/guality/inline-params-2.c fail

[andrey.y.guskov at intel dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82425

Andrey Guskov  changed:

   What|Removed |Added

 CC||rguenther at suse dot de

--- Comment #1 from Andrey Guskov  ---
Added Richard to CC.

[Bug rtl-optimization/82729] adjacent small objects can be initialized with a single store (but aren't for char a[] = "a")

[peter at cordes dot ca]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82729

--- Comment #5 from Peter Cordes  ---
(In reply to Jakub Jelinek from comment #4)
> As for this exact ones, I'm now working on GIMPLE store merging
> improvements, but that of course won't handle this case.
> For RTL I had code to handle this at RTL DSE time, see PR22141 and
> https://gcc.gnu.org/ml/gcc-patches/2009-09/msg01745.html
> The problem was that the patch caused performance regressions on PowerPC and
> it was hard to find a good cost model for it.  Of course, for -Os the cost
> model would be quite simple, but although you count instructions, you were
> reporting this for -O3.

Yeah, fewer total stores, fewer instructions, and smaller code size *is* what
makes this better for performance.  An 8-byte store that doesn't cross a
cache-line boundary has nearly identical cost to a 1-byte store at least on
Intel.

x86 is robust with overlapping stores, although store-forwarding only works for
loads that get all their data from one store (and even then some CPUs have some
alignment restrictions for the load relative to the store).  Still, that
generally means that fewer wider stores are better, because most CPUs can
forward from a 4B store to a byte reload of any of those 4 bytes.


> Doing this at GIMPLE time is impossible, because it is extremely complex
> where exactly the variables are allocated, depends on many flags etc. (e.g.
> -fsanitize=address allocates pads in between them, some targets allocate
> them from top to bottom, others the other way around, ...),

Allocation order is fixed for a given target?  Ideally we'd allocate locals to
pack them together well to avoid wasted padding, and/or put ones used together
next to each other for possible SIMD (including non-loop XMM stuff like a pair
of `double`s or copying a group of integer locals into a struct).  (In case of
a really large local array, you want variables used together in the same page
and same cache line.)

Considering all the possibilities might be computationally infeasible though,
especially if the typical gains are small.

> -fstack-protector* might protect some but not others and thus allocate in
> different buckets, alignment could play roles etc.

Anyway, sounds like it would make more sense to look for possibilities likes
this in RTL when deciding how to lay out the local variables.  For x86 it seems
gcc sorts them by size?  Changing the order of declaration changes the order of
the stores, but not the locations.

[Bug fortran/81758] [7/8 Regression] [OOP] Broken vtab

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81758

--- Comment #18 from Paul Thomas  ---
Created attachment 42480
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42480=edit
A patch that fixes the problem

Following your tip, Dimtry, this does the job and regtests OK.

Will fix up a testcase tonight. My attempts so far have not encapsulated the
level of complexity need to reproduce the problem :-)

Cheers

Paul

[Bug tree-optimization/82732] malloc+zeroing other than memset not optimized to calloc, so asm output is malloc+memset

[peter at cordes dot ca]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82732

--- Comment #3 from Peter Cordes  ---
(In reply to Marc Glisse from comment #2)
> If you use size_t consistently (for size and i), then the resulting code is
> a call to calloc.

Ah interesting.

With a compile-time constant size and -O3 we get calloc as well, even with the
original types, so that's a good thing.

[Bug libstdc++/65018] Use secure_getenv when available

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65018

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||easyhack
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-10-26
 Ever confirmed|0   |1

[Bug rtl-optimization/82729] adjacent small objects can be initialized with a single store (but aren't for char a[] = "a")

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82729

--- Comment #4 from Jakub Jelinek  ---
(In reply to Peter Cordes from comment #2)
> Are bug reports like this useful at all?  It seems that a good fraction of
> the missed-optimization bugs I file are things that gcc doesn't really have
> the infrastructure to find.  I'm hoping it's helping to improve gcc in the
> long run, at least.  I guess I could try to learn more about gcc internals
> to find out why it misses them on my own before filing, but either way it
> seems potentially useful to document efficient asm possibilities even if
> gcc's current design makes it hard to take advantage.

I think they are useful, even if some of them just are never resolved, some
perhaps take a few years, thanks for the reports.  For some of the reports
we'll find out we have the infrastructure and can do it easily, for others it
is possible to add infrastructure etc., but some will remain hard if we want to
keep the compiler maintainable and supporting multiple architectures, in some
cases fixing something requires very early detailed knowledge about
architecture when we have at that point only approximate costs tuned from big
amounts of code, etc.

As for this exact ones, I'm now working on GIMPLE store merging improvements,
but that of course won't handle this case.
For RTL I had code to handle this at RTL DSE time, see PR22141 and
https://gcc.gnu.org/ml/gcc-patches/2009-09/msg01745.html
The problem was that the patch caused performance regressions on PowerPC and it
was hard to find a good cost model for it.  Of course, for -Os the cost model
would be quite simple, but although you count instructions, you were reporting
this for -O3.
Doing this at GIMPLE time is impossible, because it is extremely complex where
exactly the variables are allocated, depends on many flags etc. (e.g.
-fsanitize=address allocates pads in between them, some targets allocate them
from top to bottom, others the other way around, ...), -fstack-protector* might
protect some but not others and thus allocate in different buckets, alignment
could play roles etc.

[Bug rtl-optimization/82729] adjacent small objects can be initialized with a single store (but aren't for char a[] = "a")

[peter at cordes dot ca]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82729

--- Comment #3 from Peter Cordes  ---
Oh also, why is MSP430 using 3 byte-stores instead of a mov.w + mov.b for
storing ab[]?  (on the godbolt link in the initial report)


   # msp430-gcc 6.2.1.16) 6.2.1 20161212
MOV.W   #25185, 6(R1)
MOV.W   #99, 8(R1)   # abc[]

MOV.B   #97, 3(R1)
MOV.B   #98, 4(R1)
MOV.B   #0, 5(R1)# ab[]

MOV.B   #97, 1(R1)
MOV.B   #0, 2(R1)# a[]

Even if alignment is required (IDK), either the first two or last two mov.b
instructions for ab[] could combine into a mov.w, like is done for abc[].  Is
that a target bug?

MSP430 is on Godbolt and it's not a RISC with word size > largest immediate, so
I was looking at it to see if it was just an x86 missed optimization.

Like I was saying for ARM, gcc seems to do a poor job on many RISC ISAs with
this, given the redundancy between strings.

[Bug rtl-optimization/82692] [8 Regression] Ordered comparisons used for unordered built-ins

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82692

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com

--- Comment #19 from Uroš Bizjak  ---
Created attachment 42479
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42479=edit
WIP patch

This is a WIP patch that tags all unorederd compares with:

(unspec [(const_int 0)] UNSPEC_NOTRAP)

WIP patch, because there is SSE subst pattern that involves CCFPU mode. This
mode will be removed, and I have to figure out what the subst does...

[Bug target/82703] [7/8 Regression] Wrong addition of std::array components with -O2 -ftree-loop-vectorize -ftree-slp-vectorize (works fine with -O2)

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82703

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
Created attachment 42478
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42478=edit
gcc7-pr82703.patch

The fix (untested so far) is simple, i386 backend, please meet
avoid_constant_pool_references.  While that function existed already when
maybe_get_pool_constant was introduced, at that point it didn't delegitimize
addresses, which is presumably the point why it has been added.  But it does
now.  On the other side, maybe_get_pool_constant didn't bother with mode
changes.  In particular, the issue here is we have a (mem:V2DF) that
get_pool_constant returns a (const_vector:V1TI) for and sees that all but the
first element (there are no such ones) are zeros, so it must be zero extended.
Of course, any other kind of VCE could have similar issues, e.g. if (mem:V4SF)
has (const_vector:V2DF) pool and the second DF is 0, but second 32-bits of the
first DF are not, etc.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #43 from Jonathan Wakely  ---
(In reply to Misty De Meo from comment #41)
> I requested a suggestion from Apple as to how to fix this, and was directed
> to the developer technical support page:
> https://developer.apple.com/support/technical/ Would you like me to file a
> support request, or would a GCC developer like to do that?

It would be great if you could do so, thanks.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #42 from Jonathan Wakely  ---
(In reply to Campbell from comment #40)
> Yes, the problem is known to be specific to APFS, due to the finer
> resolution of timestamps.

Is it?

Why should timestamp resolution cause ENOENT errors?

I'm now testing this myself on a darwin system, and with some additional
annotations in the Makefile I see this:

GENERATING PCH x86_64-apple-darwin17.0.0/bits/stdc++.h.gch/O2ggnu++0x.gch Jeu
26 oct 12:09:21 2017
/Users/fx/devel/gcc_trunk/libstdc++-v3/include/precompiled/stdc++.h:117:10:
fatal error: unordered_map: No such file or directory
 #include 
  ^~~
compilation terminated.

So the time just before starting the PCH compilation is 12:09:21, but the
"missing" symlink has a timestamp 4 seconds earlier than that:

% stat x86_64-apple-darwin17.0.0/libstdc++-v3/include/unordered_map
16777224 4818396244 lrwxr-xr-x 1 fx staff 0 64 "Oct 26 12:09:17 2017" "Oct 26
12:09:17 2017" "Oct 26 12:09:17 2017" "Oct 26 12:09:17 2017" 4194304 0 0
x86_64-apple-darwin17.0.0/libstdc++-v3/include/unordered_map

How does a finer timestamp resolution mean that a symlink created 4 seconds ago
is no longer readable?

I think something else is going on here, and not a race condition in the
makefile.

> Why is .NOTPARALLEL not an acceptable solution, until a more thorough
> solution is found? Is it actually possible to have an even reliably
> measurably longer build time due to .NOTPARALLEL? It fixes the problem,
> albeit in an overly conservative way. It would be much worse for it to
> continue to not work at all.

Because it's a hack that penalizes every target to paper over a problem that is
only affecting one target. If we make that change I seriously doubt anybody's
ever going to revisit the issue to solve it properly.

This would be more acceptable:

diff --git a/libstdc++-v3/configure.ac b/libstdc++-v3/configure.ac
index 270dcbaf723..b14bb1ed79d 100644
--- a/libstdc++-v3/configure.ac
+++ b/libstdc++-v3/configure.ac
@@ -467,6 +467,12 @@ AM_CONDITIONAL(BUILD_PDF,
   test $ac_cv_prog_DBLATEX = "yes" &&
   test $ac_cv_prog_PDFLATEX = "yes")

+case "$build" in
+ *-*-darwin* ) glibcxx_include_dir_notparallel=yes ;;
+ * ) glibcxx_include_dir_notparallel=no ;;
+esac
+AM_CONDITIONAL(INCLUDE_DIR_NOTPARALLEL,
+   test $glibcxx_include_dir_notparallel = "yes")

 # Propagate the target-specific source directories through the build chain.
 ATOMICITY_SRCDIR=config/${atomicity_dir}
diff --git a/libstdc++-v3/include/Makefile.am
b/libstdc++-v3/include/Makefile.am
index 2c4d193d0a4..1479679705a 100644
--- a/libstdc++-v3/include/Makefile.am
+++ b/libstdc++-v3/include/Makefile.am
@@ -1479,3 +1479,7 @@ $(decimal_headers): ; @:
 $(ext_headers): ; @:
 $(experimental_headers): ; @:
 $(experimental_bits_headers): ; @:
+if INCLUDE_DIR_NOTPARALLEL
+# See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
+.NOTPARALLEL:
+endif

[Bug target/82733] [8 regression] FAIL: math/test-double-y0 (with qNaN input)

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82733

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Uroš Bizjak  ---
Dup.

*** This bug has been marked as a duplicate of bug 82692 ***

[Bug rtl-optimization/82692] [8 Regression] Ordered comparisons used for unordered built-ins

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82692

Uroš Bizjak  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #18 from Uroš Bizjak  ---
*** Bug 82733 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/82729] adjacent small objects can be initialized with a single store (but aren't for char a[] = "a")

[peter at cordes dot ca]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82729

--- Comment #2 from Peter Cordes  ---
(In reply to Richard Biener from comment #1)
> The issue is we have no merging of stores at the RTL level and the GIMPLE
> level doesn't know whether the variables will end up allocated next to each
> other.

Are bug reports like this useful at all?  It seems that a good fraction of the
missed-optimization bugs I file are things that gcc doesn't really have the
infrastructure to find.  I'm hoping it's helping to improve gcc in the long
run, at least.  I guess I could try to learn more about gcc internals to find
out why it misses them on my own before filing, but either way it seems
potentially useful to document efficient asm possibilities even if gcc's
current design makes it hard to take advantage.


Anyway, could GIMPLE notice that multiple small objects are being written and
hint to RTL that it would be useful to allocate them in a certain way?  (And
give RTL a merged store that RTL would have to split if it decides not to?)

Or a more conservative approach could still be an improvement.  Can RTL realize
that it can use 4-byte stores that overlap into not-yet-initialized or
otherwise dead memory?

For -march=haswell  or generic we get 

movl$97, %edx
movl$25185, %eax   # avoid an LCP stall on Nehalem or earlier
movw%dx, 7(%rsp)
... lea
movl$6513249, 12(%rsp)
movw%ax, 9(%rsp)
movb$0, 11(%rsp)

This is pretty bad for code-size, and this would do the same thing with no
merging between objects, just knowing when to allow overlap into other objects.

movl   $0x61, 7(%rsp)# imm32 still shorter than a mov imm32 ->
reg and 16-bit store
movl $0x6261, 9(%rsp)
movl   $0x636261, 12(%rsp)


(Teaching gcc that mov $imm16 is safe on Sandybridge-family is a separate bug,
I guess.  It's only other instructions with an imm16 that LCP stall, unlike on
Nehalem and earlier where mov $imm16 is a problem too.  Silvermont marks
instruction lengths in the cache to avoid LCP stalls entirely, and gcc knows
that.)

[Bug target/82733] [8 regression] FAIL: math/test-double-y0 (with qNaN input)

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82733

--- Comment #2 from H.J. Lu  ---
This may be caused by r253986.

[Bug target/82725] [8 Regression] [i386] internal compiler error: in change_address_1, at emit-rtl.c:2162

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82725

--- Comment #2 from Uroš Bizjak  ---
(In reply to Martin Liška from comment #1)
> Looks it's related just to i386 target. Can't reproduce with
> x86_64-linux-gnu and -m32.

I can trigger the failure with cc1plus on x86_64-linux-gnu, without -m32:


(gdb) down
#2  0x00ce9cac in change_address_1 (memref=0x2e9238a0,
mode=E_DImode, addr=0x2e90bf00, validate=1, inplace=false)
at ../../git/gcc/gcc/emit-rtl.c:2162
2162gcc_assert (memory_address_addr_space_p (mode, addr, as));
(gdb) p mode
$1 = E_DImode
(gdb) p as
$2 = 1 '\001'
(gdb) p debug_rtx (addr)
(const:DI (plus:DI (unspec:DI [
(symbol_ref:DI ("_ZZ7tempDirvE5cache") [flags 0x2a] )
] UNSPEC_NTPOFF)
(const_int 8 [0x8])))
$3 = void

[Bug target/82733] [8 regression] FAIL: math/test-double-y0 (with qNaN input)

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82733

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-10-26
 CC||ubizjak at gmail dot com
  Component|c   |target
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
It miscompiled:

double
__y0 (double x)
{
  if (__builtin_expect (islessequal (x, 0.0) || isgreater (x, X_TLOSS), 0)
  && _LIB_VERSION != _IEEE_)
{
  if (x < 0.0)
{
  /* d = zero/(x-x) */
  __feraiseexcept (FE_INVALID);
  return __kernel_standard (x, x, 9);
}
  else if (x == 0.0)
{
  /* d = -one/(x-x) */
  __feraiseexcept (FE_DIVBYZERO);
  return __kernel_standard (x, x, 8);
}
  else if (_LIB_VERSION != _POSIX_)
/* y0(x>X_TLOSS) */
return __kernel_standard (x, x, 35);
}

  return __ieee754_y0 (x);
}

Good:

   0x77a57140 <+0>: pxor   %xmm1,%xmm1
   0x77a57144 <+4>: ucomisd %xmm0,%xmm1

mxcsr  0x1f82   [ DE IM DM ZM OM UM PM ]

Bad:

   0x77a55624 <+4>: pxor   %xmm1,%xmm1
   0x77a55628 <+8>: comisd %xmm0,%xmm1

mxcsr  0x1f83   [ IE DE IM DM ZM OM UM PM ]
  ^^ This is set.

[Bug tree-optimization/82732] malloc+zeroing other than memset not optimized to calloc, so asm output is malloc+memset

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82732

--- Comment #2 from Marc Glisse  ---
If you use size_t consistently (for size and i), then the resulting code is a
call to calloc.

[Bug rtl-optimization/82488] UBSAN in gcc/expr.c:4098:17: runtime error: signed integer overflow: 0 - -9223372036854775808 cannot be represented in type 'long int'

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82488

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-10-26
Version|unknown |8.0
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed on several gfortran test with an instrumented compiler:

gcc/expr.c:4098:17: runtime error: signed integer overflow: 0 -
-9223372036854775808 cannot be represented in type 'long long int'

for

gfortran.dg/actual_array_constructor_1.f90
gfortran.dg/associate_1.f03
gfortran.dg/auto_char_dummy_array_1.f90
gfortran.dg/auto_char_dummy_array_3.f90
gfortran.dg/auto_save_1.f90
gfortran.dg/block_2.f08
gfortran.dg/bounds_check_strlen_5.f90
gfortran.dg/dependent_decls_1.f90
gfortran.dg/elemental_subroutine_9.f90
gfortran.dg/init_flag_9.f90
gfortran.dg/large_integer_kind_1.f90
gfortran.dg/large_real_kind_1.f90
gfortran.dg/pr46588.f90
gfortran.dg/pr55330.f90
gfortran.dg/string_ctor_1.f90
gfortran.dg/string_length_1.f90
gfortran.dg/transfer_intrinsic_5.f90
gfortran.dg/trim_1.f90
gfortran.dg/widechar_2.f90
gfortran.dg/widechar_intrinsics_4.f90
gfortran.dg/widechar_intrinsics_6.f90 -fbackslash
gfortran.dg/widechar_intrinsics_9.f90
gfortran.dg/gomp/pr69281.f90 -fopenmp -fstack-arrays
gfortran.dg/ieee/ieee_8.f90
gfortran.fortran-torture/compile/implicit_1.f90

[Bug tree-optimization/82732] malloc+zeroing other than memset not optimized to calloc, so asm output is malloc+memset

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82732

--- Comment #1 from Marc Glisse  ---
We do recognize the memset early enough. What we fail to recognize is that the
size argument to malloc is the same as the length of the memset:

  _1 = (long unsigned int) size_8(D);
  _2 = _1 * 4;
  p_11 = malloc (_2);
  if (size_8(D) != 0)
goto ; [85.00%] [count: INV]
  else
goto ; [15.00%] [count: INV]

   [12.75%] [count: INV]:
  _18 = size_8(D) + 4294967295;
  _21 = (sizetype) _18;
  _7 = _21 + 1;
  _6 = _7 * 4;
  __builtin_memset (p_11, 0, _6);

VRP could be taught to simplify (unsigned long)(u-1)+1 to (unsigned long)u for
unsigned int u non-zero (though there is no VRP between ldist and strlen), or
we could try to generate some simpler code in ldist...

[Bug c/82733] New: [8 regression] FAIL: math/test-double-y0 (with qNaN input)

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82733

Bug ID: 82733
   Summary: [8 regression] FAIL: math/test-double-y0 (with qNaN
input)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---
Target: x86

On x86, GCC 8 r254052 caused:

FAIL: math/test-double-y0
FAIL: math/test-double-y1
FAIL: math/test-double-yn
FAIL: math/test-float-y0
FAIL: math/test-float-y1
FAIL: math/test-float-yn
FAIL: math/test-ldouble-y0
FAIL: math/test-ldouble-y1

in glibc testsuite.  The failure looks like:

testing double (without inline functions)
Failure: y0 (qNaN): Exception "Invalid operation" set
Failure: y0 (-qNaN): Exception "Invalid operation" set
Failure: y0_downward (qNaN): Exception "Invalid operation" set
Failure: y0_downward (-qNaN): Exception "Invalid operation" set
Failure: y0_towardzero (qNaN): Exception "Invalid operation" set
Failure: y0_towardzero (-qNaN): Exception "Invalid operation" set
Failure: y0_upward (qNaN): Exception "Invalid operation" set
Failure: y0_upward (-qNaN): Exception "Invalid operation" set

[Bug target/82717] [RISCV] Default value of the -mabi option doesn't match documentation

[asb at lowrisc dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82717

--- Comment #5 from Alex Bradbury  ---
(In reply to palmer from comment #4)

> """
> @item -mabi=@var{ABI-string}
> @opindex mabi
> Specify integer and floating-point calling convention.  @var{ABI-string}
> contains two parts: the size of integer types and the registers used for
> floating-point types.  For example "-march=rv64ifd -mabi=lp64d" means that
> "long" and pointers are 64-bit (implicitly defining "int" to be 32-bit), and
> that floating-point values up to 64 bits wide are passed in F registers. 
> Contrast this with "-march=rv64ifd -mabi=lp64f", which still allows the
> compiler to generate code that uses the F and D extensions but only allows
> floating-point values up to 32 bits long to be passed in registers; or
> "-march=rv64ifd -mabi=lp64", in which no floating-point arguments will be
> passed in registers.
> 
> The default for this argument is system dependent, users who want a specific
> calling convention should specify one explicitly.  The valid calling
> conventions are: ilp32, ilp32f, ilp32d, lp64, lp64f, and lp64d.  Some
> calling conventions are impossible to implement on some ISAs: for example,
> "-march=rv32if -mabi=ilp32d" is invalid because the ABI requires 64-bit
> values be passed in F registers, but F registers are only 32 bits wide.
> """

Looks great to me!

[Bug tree-optimization/82732] New: malloc+zeroing other than memset not optimized to calloc, so asm output is malloc+memset

[peter at cordes dot ca]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82732

Bug ID: 82732
   Summary: malloc+zeroing other than memset not optimized to
calloc, so asm output is malloc+memset
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter at cordes dot ca
  Target Milestone: ---

#include 
#include 

int *foo(unsigned size)
{
int *p = malloc(size*sizeof(int));
//memset(p,0, size*sizeof(int));

for (unsigned i=0; i

[Bug libffi/28036] libffi executable stack (missing .note.GNU-stack on .o files)

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28036

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #6 from Andrew Pinski  ---
(In reply to Eric Gallager from comment #4)
> Seeing as this bug is about how libffi is used by gcj, and gcj has been
> removed from gcc, does it still need to stay open? Or does it affect other
> users of libffi in gcc, too? (e.g. go)

Go uses libffi still.

[Bug libffi/28036] libffi executable stack (missing .note.GNU-stack on .o files)

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28036

Eric Gallager  changed:

   What|Removed |Added

   Keywords||patch
 Status|NEW |WAITING
 CC||pinskia at gcc dot gnu.org

--- Comment #5 from Eric Gallager  ---
(In reply to Eric Gallager from comment #4)
> Seeing as this bug is about how libffi is used by gcj, and gcj has been
> removed from gcc, does it still need to stay open? Or does it affect other
> users of libffi in gcc, too? (e.g. go)

Changing status to WAITING until there's an answer.

[Bug other/79872] document placeholder %K in gcc-internal-format

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79872

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-10-26
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
(In reply to Roland Illig from comment #0)
> In config/aarch64/aarch64.c I found this code:
> 
> error ("%Klane %wd out of range %wd - %wd", exp, lane, low, high - 1);
> 
> It seems wrong to me that there is no space after the %K.
> 
> The gettext documentation doesn't mention the %K specifier at all.
> (https://savannah.gnu.org/bugs/index.php?50461)
> 
> Please work together with the gettext people to create current and correct
> documentation for the gcc-internal-format.

Confirmed.

[Bug target/82703] [7/8 Regression] Wrong addition of std::array components with -O2 -ftree-loop-vectorize -ftree-slp-vectorize (works fine with -O2)

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82703

--- Comment #5 from Jakub Jelinek  ---
Reduced testcase in C, -O2 -fno-tree-sra -ftree-vectorize aborts,
-O2, or -O2 -ftree-vectorize, or -O2 -fno-tree-sra doesn't.

/* PR target/82703 */
/* { dg-do run } */
/* { dg-options "-O2 -fno-tree-sra -ftree-vectorize" } */

__attribute__((noinline, noclone)) void
compare (const double *p, const double *q)
{
  for (int i = 0; i < 3; ++i)
if (p[i] != q[i])
  __builtin_abort ();
}

double vref[3] = { 4, 4, 4 };

int
main ()
{
  double v1[3] = { 1, 2, 3 };
  double v2[3] = { 3, 2, 1 };
  double v3[3];
  __builtin_memcpy (v3, v1, sizeof (v1));
  for (int i = 0; i < 3; ++i)
v3[i] += v2[i];
  for (int i = 0; i < 3; ++i)
v1[i] += v2[i];
  compare (v3, vref);
  return 0;
}

[Bug target/82731] New: _mm256_set_epi8(array[offset[0]], array[offset[1]], ...) byte gather makes slow code, trying to zero-extend all the uint16_t offsets first and spilling them.

[peter at cordes dot ca]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82731

Bug ID: 82731
   Summary: _mm256_set_epi8(array[offset[0]], array[offset[1]],
...) byte gather makes slow code, trying to
zero-extend all the uint16_t offsets first and
spilling them.
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: missed-optimization, ssemmx
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter at cordes dot ca
  Target Milestone: ---
Target: x86_64-*-*, i?86-*-*

#include "immintrin.h"
#include "inttypes.h"

__m256i gather(char *array, uint16_t *offset) {

  return _mm256_set_epi8(array[offset[0]], array[offset[1]], array[offset[2]],
array[offset[3]], array[offset[4]], array[offset[5]], array[offset[6]],
array[offset[7]],
  array[offset[8]],array[offset[9]],array[offset[10]],array[offset[11]],
array[offset[12]], array[offset[13]], array[offset[14]], array[offset[15]], 
  array[offset[16]],array[offset[17]], array[offset[18]],
array[offset[19]], array[offset[20]], array[offset[21]], array[offset[22]],
array[offset[23]], 
  array[offset[24]],array[offset[25]],array[offset[26]], array[offset[27]],
array[offset[28]], array[offset[29]], array[offset[30]],array[offset[31]]);
}

https://stackoverflow.com/questions/46881656/avx2-byte-gather-with-uint16-indices-into-a-m256i

https://godbolt.org/g/LEVVwt


pushq   %rbp
movq%rsp, %rbp
pushq   %r15
pushq   %r14
pushq   %r13
pushq   %r12
pushq   %rbx
andq$-32, %rsp
subq$40, %rsp
movzwl  40(%rsi), %eax
... # more movzwl
movq%rax, 32(%rsp)   # spill
movzwl  38(%rsi), %eax   # and reuse
... # more movzwl
movzwl  46(%rsi), %r8d
movq%rax, 24(%rsp)   # spill
movzwl  36(%rsi), %eax
movzwl  42(%rsi), %edx
movq%rax, 16(%rsp)
movzwl  34(%rsi), %eax
...

...
vpinsrb $1, (%rdi,%r9), %xmm6, %xmm6
vpinsrb $1, (%rdi,%rcx), %xmm5, %xmm5
movq24(%rsp), %rcx  # more reloading
vpunpcklwd  %xmm6, %xmm3, %xmm3
movzbl  (%rdi,%rcx), %edx   # and using as a gather index
movq8(%rsp), %rcx
vpunpcklwd  %xmm5, %xmm1, %xmm1
vpunpckldq  %xmm3, %xmm2, %xmm2
vmovd   %edx, %xmm0
movzbl  (%rdi,%rcx), %edx
vpinsrb $1, (%rdi,%rbx), %xmm0, %xmm0

I think gcc is missing the point of vpinsrb, and making too many separate dep
chains which it then has to shuffle together.  It doesn't have such good
throughput on any CPUs that you need more than 2 or 3 dep chains to max out its
1 or 2 per clock throughput.

But the main point here is doing all the zero-extension of offset[0..31] before
doing *any* of the loads from array[], running out of registers and spilling.

See also discussion on that SO question about byte gathers and possibilities
for VPGATHERDD being maybe worth it on Skylake.

[Bug other/69561] MULTILIB_EXCLUSIONS is not documented

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69561

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-10-26
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed, grepping the sources show that it only shows up in Makefiles but not
any of the documentation files.

[Bug target/82730] New: extra store/reload of an XMM for every byte extracted

[peter at cordes dot ca]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82730

Bug ID: 82730
   Summary: extra store/reload of an XMM for every byte extracted
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: missed-optimization, ssemmx
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter at cordes dot ca
  Target Milestone: ---
Target: x86_64-*-*, i?86-*-*

#include 
#include 
#include 

void p128_as_u8hex(__m128i in) {
_Alignas(16) uint8_t v[16];
_mm_store_si128((__m128i*)v, in);

printf("v16.u8: %#x %#x %#x %#x | %#x %#x %#x %#x | %#x %#x %#x %#x | %#x
%#x %#x %#x\n",
   v[0], v[1],  v[2],  v[3],  v[4],  v[5],  v[6],  v[7],
   v[8], v[9], v[10], v[11], v[12], v[13], v[14], v[15]);
}

https://godbolt.org/g/yoikq9
-O3  (or -march= anything with -mno-sse4 for pextrb)

subq$288, %rsp   # 288 bytes!!!
movl$.LC0, %edi
movaps  %xmm0, 8(%rsp)   # store
movdqa  8(%rsp), %xmm6   # reload twice...
movdqa  8(%rsp), %xmm1
movaps  %xmm6, 184(%rsp) # spill somewhere else
movzbl  199(%rsp), %eax  # v[15]
movaps  %xmm1, 264(%rsp)
movzbl  8(%rsp), %esi# v[0]
movaps  %xmm1, 248(%rsp)
...
pushq   %rax # v[15]

movdqa  16(%rsp), %xmm7
movaps  %xmm7, 176(%rsp)
movzbl  190(%rsp), %eax
pushq   %rax # v[14]

movdqa  24(%rsp), %xmm0
movaps  %xmm0, 168(%rsp)
movzbl  181(%rsp), %eax
pushq   %rax
...
xorl%eax, %eax
callprintf
addq$376, %rsp
ret

This is pretty hilariously bad, especially compared to the scalar code that
gcc6.3 produces:

subq$32, %rsp
movq%xmm0, %r9
movq%xmm0, %rcx
# ok this is a bit silly vs. a scalar mov.
# very few CPUs can do parallel movq so there's a resource-conflict
anyway making this no better than a GP->GP mov
movaps  %xmm0, 8(%rsp)
movq16(%rsp), %rax# high half
shrq$32, %r9
shrq$16, %rcx
movq%xmm0, %r8
movq%xmm0, %rdx
movzbl  %cl, %ecx
movzbl  %r8b, %esi
movzbl  %dh, %edx # using dh to save on shifts
movzbl  %r9b, %r9d
shrl$24, %r8d
movq%rax, %rdi
shrq$56, %rdi
pushq   %rdi
...

Not perfect (related to bug 67072), but at least doesn't do a chain of vector
copies all over the place.



OTOH, we could vectorize the unpack and store to stack memory in 16B chunks. 
This is much more profitable for 32-bit mode, where all args are stack args,
and where a 16B vector holds 4 args instead of 2.  e.g. movzxbd or 2-step
punpck with zeros.

For printing as 32-bit or 64-bit integers, we can just store the vector to the
stack instead of getting each element out separately!  (Should I report that as
a separate missed optimization, for 

void p128_as_u32hex(__m128i in) {
//const uint32_t *v = (const uint32_t*) 
alignas(16) uint32_t v[4];
_mm_store_si128((__m128i*)v, in);
printf("v4.u32: %#x %#x %#x %#x\n", v[0], v[1], v[2], v[3]);
}

where we get (with gcc -O3 -m32)

pshufd  $255, %xmm0, %xmm1
movd%xmm1, %eax
movdqa  %xmm0, %xmm1
pushl   %eax
punpckhdq   %xmm0, %xmm1
movd%xmm1, %eax
pshufd  $85, %xmm0, %xmm1
pushl   %eax
...

instead of a single movaps store.  Or for printing as uint64_t, we get

movhps  %xmm0, 20(%esp)
pushl   24(%esp)
pushl   24(%esp)
movq%xmm0, 28(%esp)
pushl   32(%esp)
pushl   32(%esp)

[Bug target/82703] [7/8 Regression] Wrong addition of std::array components with -O2 -ftree-loop-vectorize -ftree-slp-vectorize (works fine with -O2)

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82703

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
On the trunk this went away with r247048 (if it is STV, that just means it went
latent). And it started with r239378.

[Bug tree-optimization/82707] ICE in verify_gimple_in_cfg at tree-cfg.c:5395

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82707

--- Comment #11 from Jakub Jelinek  ---
Comment on attachment 42477
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42477
More minimal patch

Ok, thanks.  Not really happy this C++ification has been introduced, but now we
have to live with that.

[Bug tree-optimization/82707] ICE in verify_gimple_in_cfg at tree-cfg.c:5395

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82707

Tom de Vries  changed:

   What|Removed |Added

  Attachment #42476|0   |1
is obsolete||

--- Comment #10 from Tom de Vries  ---
Created attachment 42477
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42477=edit
More minimal patch

(In reply to Jakub Jelinek from comment #9)
> Comment on attachment 42476 [details]
> Updated tentative patch
> 
> Both TEAMS and SINGLE don't have any inlines that actually need gomp_teams
> or gomp_single, they accept just gimple.

That's not entirely correct. We have:
...
static inline void gimple_omp_single_set_clauses (gomp_single *omp_single_stmt,
tree clauses);
static inline void gimple_omp_teams_set_clauses (gomp_teams *omp_teams_stmt,
tree clauses);
...

I'll commit updated patch after testing.

[Bug tree-optimization/82707] ICE in verify_gimple_in_cfg at tree-cfg.c:5395

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82707

--- Comment #9 from Jakub Jelinek  ---
Comment on attachment 42476
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42476
Updated tentative patch

Both TEAMS and SINGLE don't have any inlines that actually need gomp_teams or
gomp_single, they accept just gimple.  So for those please just avoid the {}s
and as_a, just do:
case GIMPLE_OMP_SINGLE:
  t = unshare_expr (gimple_omp_single_clauses (stmt));
  gimple_omp_single_set_clauses (copy, t);
  goto copy_omp_body;
etc.

For TARGET it is indeed needed for target_set_data_arg, so keep that one as is.
Preapproved with that change.

[Bug tree-optimization/82707] ICE in verify_gimple_in_cfg at tree-cfg.c:5395

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82707

Tom de Vries  changed:

   What|Removed |Added

  Attachment #42475|0   |1
is obsolete||

--- Comment #8 from Tom de Vries  ---
Created attachment 42476
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42476=edit
Updated tentative patch

(In reply to Jakub Jelinek from comment #5)
> If the problem is missing unsharing, then I think many other constructs have
> the same problem and need their clauses to be unshared too. So, in addition
> to TARGET also SINGLE and TEAMS.

This updated patch also handles SINGLE and TEAMS.

[Bug c++/82561] [8 regression] crash on internal compiler error: in cp_tree_equal, at cp/tree.c:3778

[sylvestre at debian dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82561

Sylvestre Ledru  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #8 from Sylvestre Ledru  ---
I cannot reproduce it with 
g++-8 (Debian 8-20171023-1) 8.0.0 20171023 (experimental) [trunk revision
253997]

closing, sorry for the noise.

[Bug tree-optimization/82707] ICE in verify_gimple_in_cfg at tree-cfg.c:5395

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82707

--- Comment #7 from Jakub Jelinek  ---
Ah, in that case it is hard to reproduce with single/teams, because usually
those don't appear in try/finally cleanup actions.  That said, gimple_copy is
used in many other spots.  But, if you want, just deal with target and I'll
handle the rest incrementally.

[Bug tree-optimization/82707] ICE in verify_gimple_in_cfg at tree-cfg.c:5395

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82707

--- Comment #6 from Tom de Vries  ---
(In reply to Jakub Jelinek from comment #5)
> If the problem is missing unsharing,

Minimal example (with c compiler and -fexceptions):
...
extern void bar (void);

void foo (void)
{
  int e[8];
#pragma acc declare create (e)

  bar ();
}
...

At eh_opt, we have the map-delete clause in a finally:
...
  try
{
  .omp_data_arr.2.e = 
  #pragma omp target oacc_declare map(force_alloc:e [len: 32])
  .omp_data_arr.2 = {CLOBBER};
  bar ();
  goto ;
}
  finally
{
  .omp_data_arr.5.e = 
  #pragma omp target oacc_declare map(delete:e)
  .omp_data_arr.5 = {CLOBBER};
  e = {CLOBBER};
}
...

Then at eh, we see that it has been copied:
...
  .omp_data_arr.2.e = 
  #pragma omp target oacc_declare map(force_alloc:e [len: 32])
  .omp_data_arr.2 = {CLOBBER};
  bar ();
  goto ;
  :
  .omp_data_arr.5.e = 
  #pragma omp target oacc_declare map(delete:e)
  .omp_data_arr.5 = {CLOBBER};
  e = {CLOBBER};
  goto ;
  :
  return;
  :
  .omp_data_arr.5.e = 
  #pragma omp target oacc_declare map(delete:e)
  .omp_data_arr.5 = {CLOBBER};
  e = {CLOBBER};
  resx 1
...

The copy is done using gimple_copy. The patch to gimple_copy fixes the ICE by
unsharing the tree parts of GIMPLE_OMP_TARGET (apart from
gimple_omp_target_child_fn, which is a FUNCTION_DECL, which AFAIU can be
shared).

[Bug libfortran/82233] [6/7/8 Regression] execute_command_line causes program to stop when command fails (or does not exist)

[clyon at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82233

--- Comment #24 from Christophe Lyon  ---
(In reply to Thomas Koenig from comment #21)
> [...]
> but I am not sure that waitpid is available on all systems;
> this is more likely to break things than fix things.
> 
I tried simpler things (just calling wait()), but since you have this concern,
I agree it's not worth pursuing.

> What you could to to reduce the amount of noise that you see is
> sleep for a second; just insert
> 
>   CALL SLEEP(1)
> 
> before the END statement of the test case, locally in your tree.
> This could help. I don't want to do this for everybody (test times
> being long enough as they are), but for most cases, this should
> be enough.

For the time being, it's much simpler for me to handle the 127 return code in
my testcase execution wrapper.

Thanks for the help.

[Bug tree-optimization/82726] ICE in verify_ssa during GIMPLE pass: pcom

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82726

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-10-26
Version|unknown |8.0
   Target Milestone|8.0 |---
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Confirmed.

[Bug rtl-optimization/82729] adjacent small objects can be initialized with a single store (but aren't for char a[] = "a")

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82729

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-10-26
  Component|tree-optimization   |rtl-optimization
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
The issue is we have no merging of stores at the RTL level and the GIMPLE level
doesn't know whether the variables will end up allocated next to each other.

[Bug target/82725] [8 Regression] [i386] internal compiler error: in change_address_1, at emit-rtl.c:2162

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82725

Richard Biener  changed:

   What|Removed |Added

 Target||i?86-*-*
   Target Milestone|--- |8.0

[Bug c/82723] Collisions with standard library not detected by linker

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82723

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Richard Biener  ---
As said this is unfortunately how it is supposed to work (you are interposing a
libc symbol).

[Bug c++/82722] [7 Regression] ICE in finish_member_declaration, at cp/semantics.c:2984

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82722

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.3