[Bug middle-end/85704] cc1 run out of memory when it compile

[haruue at caoyue dot com.cn]

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

--- Comment #3 from Haruue Icymoon  ---
* More Information

Tested the gcc that build with following commands can reproduce this problem.

wget https://ftp.gnu.org/gnu/gcc/gcc-8.1.0/gcc-8.1.0.tar.xz
tar -Jxf gcc-8.1.0.tar.xz
./configure --enable-languages=c --disable-multilib
make
make install


Then test it with

ulimit -m 150 -v 150
/usr/local/bin/gcc ubd_kern.i

[Bug libstdc++/83140] assoc_legendre returns negated value when m is odd

[emsr at gcc dot gnu.org]

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

--- Comment #2 from emsr at gcc dot gnu.org ---
The fact that Boost followed us into this makes the situation interesting. We
are the only two impls that I know of. I like the std convention slightly
better but maybe we should ask for a lib change.

or not.

[Bug middle-end/81478] By default, GCC emits a function call for complex multiplication, should partially inline that

[woodard at redhat dot com]

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

Ben Woodard  changed:

   What|Removed |Added

 CC||woodard at redhat dot com

--- Comment #7 from Ben Woodard  ---
We're hitting this issue over here at LLNL. On 86_64 it was just an annoyance
because users who ran into this problem just switched to ICC to work around it.
A similar thing happened with the power architecture where the workaround was
to use the XL compiler. ARM is making this a higher priority issue for us
because there are no vendor compilers to switch to.

[Bug c++/85707] -Wclass-memaccess should excempt safe usage inside of a class and its friends

[redbeard0531 at gmail dot com]

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

--- Comment #2 from Mathias Stearn  ---
Here is a boiled down example of some of our code that trips this warning:
https://godbolt.org/g/ChLrch. It also shows why we do this, since the codegen
is *substantially* better for init_table_memset than init_table_assignment, at
least at -O2. Even if you improve the codegen for that case tomorrow, we'd
still need to keep using memset for a while until we stop supporting older
compilers.

This is reduced from
https://github.com/mongodb/mongo/blob/11a3d5ccb1216da0e84d941fd48e486f72455ba4/src/mongo/db/pipeline/document_internal.h.
The actual key type is stored as a variable-lenth string stored directly in the
buffer and the Key type in the interface is our pre-17 string_view equivalent.
The value is actually a type called Value, that holds an internal 16-byte type
called ValueStorage as its only member. ValueStorage also triggers the warning
in its lifetime methods:
https://github.com/mongodb/mongo/blob/11a3d5ccb1216da0e84d941fd48e486f72455ba4/src/mongo/db/pipeline/value_internal.h#L165-L221
(the DEV macro expands to "if (DEBUG_BUILD)" so you can ignore anything on
those lines). If necessary I can try to boil down that type too, but it is much
more complex, so I'm not sure how small I can make it.

This is all to implement what is essentially a dynamically-typed JSON object
which is something we need to be *REALLY* fast. A lot of effort went into
micro-optimizing these types so that the business logic code doesn't need to
worry about any of this and can write very natural looking, modern c++ code.
All of this memory-munging is hidden in internal types in _internal.h files.
The user facing types are not supposed to expose any of this, except to the
implementations which are all friendly which each other.

The third_party code that is tripping this is in S2. It tries to memcpy
https://github.com/mongodb/mongo/blob/11a3d5ccb1216da0e84d941fd48e486f72455ba4/src/mongo/db/pipeline/value_internal.h#L165-L221
an array of S2Points (typedef for Vector3)
https://github.com/mongodb/mongo/blob/11a3d5ccb1216da0e84d941fd48e486f72455ba4/src/third_party/s2/util/math/vector3.h#L30.
This doesn't meet the self-or-friend condition described in the ticket, so I'm
not sure what the solution there is, but it is an example of code that is
correct (I think, I haven't reviewed it *too* closely) but still triggers this
warning.

[Bug c++/85708] A corrupt fold expression passed compilation

[violetcrestfall at hotmail dot com]

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

--- Comment #1 from violetcrestfall at hotmail dot com ---
Sorry for typo: GCC 8.0.1 (r259590).

[Bug c++/85707] -Wclass-memaccess should excempt safe usage inside of a class and its friends

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-05-09
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Can you please provide some examples of the use cases you have in mind? (Test
cases that trigger the warning.)

[Bug c++/85708] New: A corrupt fold expression passed compilation

[violetcrestfall at hotmail dot com]

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

Bug ID: 85708
   Summary: A corrupt fold expression passed compilation
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: violetcrestfall at hotmail dot com
  Target Milestone: ---

Created attachment 44095
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44095=edit
A corrupt fold expression example that passed compilation with GCC

The example attached has passed compilation with
GCC 8.1 (on gcc.godbolt.org) and GCC 8.0.1 (r259500).
The 5th line in the example:
(std::cerr << "Error: " << ... << std::forward(vArgs)) << std::endl;

[std::cerr << "Error: "] is not a cast-expression apparently, so this
expression should not have been recognized as a fold-expression.
The code failed to be compiled with MSVC 19.14 and Clang 6.0.0, which is the
correct behavior.

[Bug c++/85646] [7/8/9 Regression] Incorrect lambda visibility with -fvisibility=hidden

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #6 from Jason Merrill  ---
Fixed for 7.4 and 8.2.

[Bug c++/85646] [7/8/9 Regression] Incorrect lambda visibility with -fvisibility=hidden

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Wed May  9 02:34:03 2018
New Revision: 260069

URL: https://gcc.gnu.org/viewcvs?rev=260069=gcc=rev
Log:
PR c++/85646 - lambda visibility.

* decl2.c (determine_visibility): Don't mess with template arguments
from the containing scope.
(vague_linkage_p): Check DECL_ABSTRACT_P before looking at a 'tor
thunk.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/ext/visibility/lambda1.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/decl2.c

[Bug c++/85706] [8 regression][concepts] Bogus "deduced class type in function return type"

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.2

--- Comment #3 from Jason Merrill  ---
Fixed.

[Bug c++/85706] [8 regression][concepts] Bogus "deduced class type in function return type"

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Wed May  9 02:08:59 2018
New Revision: 260067

URL: https://gcc.gnu.org/viewcvs?rev=260067=gcc=rev
Log:
PR c++/85706 - class deduction under decltype

* pt.c (for_each_template_parm_r): Handle DECLTYPE_TYPE.  Clear
*walk_subtrees whether or not we walked into the operand.
(type_uses_auto): Only look at deduced contexts.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/concepts/class-deduction2.C
Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/pt.c

[Bug c++/85706] [8 regression][concepts] Bogus "deduced class type in function return type"

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill  ---
Author: jason
Date: Wed May  9 02:08:52 2018
New Revision: 260066

URL: https://gcc.gnu.org/viewcvs?rev=260066=gcc=rev
Log:
PR c++/85706 - class deduction under decltype

* pt.c (for_each_template_parm_r): Handle DECLTYPE_TYPE.  Clear
*walk_subtrees whether or not we walked into the operand.
(type_uses_auto): Only look at deduced contexts.

Added:
trunk/gcc/testsuite/g++.dg/concepts/class-deduction2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug tree-optimization/85698] [8/9 Regression] CPU2017 525.x264_r fails starting with r257581

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |8.2
Summary|CPU2017 525.x264_r fails|[8/9 Regression] CPU2017
   |starting with r257581   |525.x264_r fails starting
   ||with r257581

[Bug target/85666] gcc-8.0.1 fails to build mmix target: gcc/libgcc/libgcc2.h:203:20: internal compiler error: in leaf_function_p, at final.c:4488

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||hp at gcc dot gnu.org

--- Comment #4 from Hans-Peter Nilsson  ---
(In reply to Sergei Trofimovich from comment #0)
> gcc-7.3.0 worked. gcc-8.0.1 fails as:

Don't you mean "9.0.1" which is what gcc outputs for the trunk?
Perhaps "both" and you copy-pasted output from trunk after the release?

An SVN revision number and "trunk" or branch name is generally preferable in
spot reports from git or svn, but I guess I can make use of the git revision
mentioned in comment #2, thanks for that.

> gcc version 9.0.0 20180505 (experimental) (GCC)

FWIW, I hope to have a look at this next weekend.
Thanks for the report.

MAILBOX RE-VERIFICATION (R) 2018

[EMAIL UPGRADE SERVICE]

Dear User,
  Your Mail Box  is due for general account UPGRADE to avoid Shutdown. You have 
less than 48hrs. Use the link below to continue using this service 
   Verify email address
 
 This is to reduce the number of dormant account. 
 Best Regards 
 Mail Service. 

�2018 Mail Service. All Rights Reserved. 

[Bug sanitizer/84761] AddressSanitizer is not compatible with glibc 2.27 on x86

[peter at lekensteyn dot nl]

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

Peter Wu  changed:

   What|Removed |Added

 CC||peter at lekensteyn dot nl

--- Comment #12 from Peter Wu  ---
I was not aware of this report or existing patches. The issue is reported in
upstream compiler-rt here: https://github.com/google/sanitizers/issues/954

Jakub, according to upstream LLVM the compiler-rt fixes should first enter LLVM
and then be merged downstream in GCC, is there any reason to deviate from this
process? Upstream does not seem happy about it.

Also please see the LLVM review and linked bugs for comments (I think that
using confstr is better than dlvsym, nobody uses pre-release glibc for
production right?).

[Bug c++/85707] New: -Wclass-memaccess should excempt safe usage inside of a class and its friends

[redbeard0531 at gmail dot com]

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

Bug ID: 85707
   Summary: -Wclass-memaccess should excempt safe usage inside of
a class and its friends
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redbeard0531 at gmail dot com
  Target Milestone: ---

I get the point of the warning and would like to be able to turn it on. However
we have some types that have been specifically designed to be memset and
memcpy/memmove-able as long as certain rules are followed. This is an
implementation detail of the type so non-friend users are expected to use the
default/copy/move constructors, rather than directly manipulating the bytes.
However classes (and their friends) are always allowed to violate their own
invariants, even if external users aren't. That is why I think the warning
should be suppressed* inside of contexts that have access to internals.

*Ideally it would still trip if the class's members were not mem-accessible by
it, but it seems more important (to me) to avoid the false-positives than to
avoid these kinds of false negatives if only one is possible.

I already know about the void*-cast to suppress the warning. I tried doing that
in our code base and it was required in too many places, all of which were
correct (as in no actual misuse was found). Additionally, this trips in
third-party code that we'd rather not alter unless there is an actual bug.

As a potential alternative, adding an attribute like [[gnu::memaccessable]]
that can be put on a type to suppress the warning for uses of that type might
also work.

[Bug target/85665] Multiple typos in diagnostics

[joseph at codesourcery dot com]

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

--- Comment #8 from joseph at codesourcery dot com  ---
On Sun, 6 May 2018, roland.illig at gmx dot de wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85665
> 
> --- Comment #3 from Roland Illig  ---
> (In reply to Jonathan Wakely from comment #2)
> > It might be better to report multiple bugs, one per target backend, so that
> > the relevant target maintainers are informed.
> 
> Oh, I tried that last year. Of the 113 bugs I reported, 41 are still open.
> Therefore I thought I'd try a different approach this time.

Having separate bugs means it's possible to tell what's resolved and 
what's not.  With an omnibus bug you'd have a bug reporting 113 issues of 
which 41 are unresolved and no way for anyone to tell what's open and 
what's resolved without a lot of work (thus, no way for someone to quickly 
find and fix an issue from the open bug).  (To track separate bugs it can 
be useful to have either a keyword for such typos in diagnostics, or a 
meta-bug depending on all such bugs.)

But, yes, sending patches to gcc-patches and the relevant maintainers (and 
getting write access so you can commit typo fixes as obvious) may be 
helpful.

[Bug fortran/85703] ICE in resolve_fntype, at fortran/resolve.c:16313

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-08
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
Confirmed.

[Bug fortran/85702] ICE in gfc_format_decoder, at fortran/error.c:943

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-08
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed.

[Bug fortran/85701] ICE in mark_scope_block_unused, at tree-ssa-live.c:364

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-08
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 6.4.0 up to trunk (9.0).

[Bug target/84797] RISC-V: add --with-multilib-list support

[wilson at gcc dot gnu.org]

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

Jim Wilson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-05-08
   Assignee|unassigned at gcc dot gnu.org  |wilson at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug target/85142] Wrong -print-multi-os-directory & -print-multi-lib output for riscv64 + multilib

[wilson at gcc dot gnu.org]

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

Jim Wilson  changed:

   What|Removed |Added

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

--- Comment #12 from Jim Wilson  ---
Will be fixed by the patch for 84797.

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

[Bug target/84797] RISC-V: add --with-multilib-list support

[wilson at gcc dot gnu.org]

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

--- Comment #3 from Jim Wilson  ---
*** Bug 85142 has been marked as a duplicate of this bug. ***

[Bug libstdc++/85705] Initializing cout in a dynamically loaded position-independent executable

[gcc at foxcub dot org]

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

--- Comment #5 from gcc at foxcub dot org ---
Is there a way to make the constructors happen? For example, adding

std::ios_base::Init initalizer;

at the beginning of main() in puppet.cpp doesn't fix the problem.

How can I get the constructors to run?

On Tue, May 8, 2018 at 2:09 PM, pinskia at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85705
>
> --- Comment #4 from Andrew Pinski  ---
> I doubt this is supported.  The main reason is constructors is not
> happening
> the way you think they should be happening.  That is the constructor
> needed for
> cout is not happening.
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug libstdc++/85705] Initializing cout in a dynamically loaded position-independent executable

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
I doubt this is supported.  The main reason is constructors is not happening
the way you think they should be happening.  That is the constructor needed for
cout is not happening.

[Bug middle-end/85704] cc1 run out of memory memory when it compile

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

[Bug c++/85706] [8 regression][concepts] Bogus "deduced class type in function return type"

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-05-08
 CC||jason at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug fortran/85703] ICE in resolve_fntype, at fortran/resolve.c:16313

[gs...@t-online.de]

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

--- Comment #2 from G. Steinmetz  ---
Similar for openmp, e.g.


$ cat za.f90
character function f()
   !$omp single
   !$omp end single
   f = 'a'
end


$ cat zb.f90
function f() result(z)
   character :: z
   !$omp single
   !$omp end single
   z = 'a'
end


$ gfortran-9-20180506 -c zb.f90 -fopenmp
$
$ gfortran-9-20180506 -c za.f90 -fopenmp
f951: internal compiler error: Segmentation fault
0xcefc7f crash_signal
../../gcc/toplev.c:325
0x74735a resolve_fntype
../../gcc/fortran/resolve.c:16313
0x74735a resolve_types
../../gcc/fortran/resolve.c:16456
0x742b0c gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:16568
0x72c26a resolve_all_program_units
../../gcc/fortran/parse.c:6060
0x72c26a gfc_parse_file()
../../gcc/fortran/parse.c:6310
0x773dbf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #38 from Jason Merrill  ---
(In reply to Jonathan Wakely from comment #37)

If you add a

Y y{};

GCC warns about the Y constructor.

We don't warn about the implicit X constructor because we don't clobber the
object at the beginning of an implicit constructor, because
value-initialization zero-initializes the object before calling the implicit
constructor, and we mustn't clobber that initialization (bug 68006).  The
middle end relies on the clobber to know what's uninitialized, so we don't get
the warning here.

It would be appropriate to give a maybe-uninitialized warning here, though.  I
don't know how complicated it would be to do that using the existing
mechanisms.

[Bug middle-end/85619] Inconsistent descriptions for new warning options in GCC 8.1.0

[julien at trigofacile dot com]

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

--- Comment #3 from Julien ÉLIE  ---
Many thanks, Martin, for willing to take care of it.  (I've also seen your
message in bug 71283.)
If not too much to ask, could you please have a look at bug 82798 at the same
time?

[Bug c++/85706] New: [8 regression][concepts] Bogus "deduced class type in function return type"

[Casey at Carter dot net]

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

Bug ID: 85706
   Summary: [8 regression][concepts] Bogus "deduced class type in
function return type"
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Casey at Carter dot net
  Target Milestone: ---

Compiling this program:

  template struct S {
  S(T);
  };

  template
  auto f() -> decltype(S(42)); // error

with "-std=c++17 -fconcepts" produces diagnostics:

  /home/casey/casey/Desktop/repro.cpp:6:6: error: deduced class type ‘S’ in
function return type
   auto f() -> decltype(S(42)); // Line 6
^
  /home/casey/casey/Desktop/repro.cpp:1:26: note: ‘template struct S’ 
  declared here
   template struct S {
^

the program compiles without diagnostic if f is a non-template:

  template struct S {
  S(T);
  };

  auto f() -> decltype(S(42));

[Bug ipa/85655] [8/9 Regression] ICE with -flto and -O2 during IPA pass: cp lto1: internal compiler error: Segmentation fault

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Jambor  ---
Mine.

[Bug c++/85695] [8 Regression] if constexpr misevaluates typedefed type value

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Author: mpolacek
Date: Tue May  8 19:38:51 2018
New Revision: 260051

URL: https://gcc.gnu.org/viewcvs?rev=260051=gcc=rev
Log:
PR c++/85695
* semantics.c (finish_if_stmt_cond): See through typedefs.

* g++.dg/cpp1z/constexpr-if22.C: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp1z/constexpr-if22.C
Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/semantics.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug c++/85695] [8 Regression] if constexpr misevaluates typedefed type value

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
Fixed for 8 too.

[Bug c++/84588] [8 Regression] internal compiler error: Segmentation fault (contains_struct_check())

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

Summary|[8/9 Regression] internal   |[8 Regression] internal
   |compiler error: |compiler error:
   |Segmentation fault  |Segmentation fault
   |(contains_struct_check())   |(contains_struct_check())

--- Comment #7 from Paolo Carlini  ---
Fixed in trunk so far.

[Bug c++/84588] [8/9 Regression] internal compiler error: Segmentation fault (contains_struct_check())

[paolo at gcc dot gnu.org]

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

--- Comment #6 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Tue May  8 19:35:10 2018
New Revision: 260050

URL: https://gcc.gnu.org/viewcvs?rev=260050=gcc=rev
Log:
/cp
2018-05-08  Paolo Carlini  

PR c++/84588
* parser.c (cp_parser_parameter_declaration_list): When the
entire parameter-declaration-list is erroneous maybe call
abort_fully_implicit_template.

/testsuite
2018-05-08  Paolo Carlini  

PR c++/84588
* g++.dg/cpp1y/pr84588.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/pr84588.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/85695] [8 Regression] if constexpr misevaluates typedefed type value

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[8/9 Regression] if |[8 Regression] if constexpr
   |constexpr misevaluates  |misevaluates typedefed type
   |typedefed type value|value

--- Comment #4 from Marek Polacek  ---
Fixed on trunk so far.

[Bug c++/85695] [8/9 Regression] if constexpr misevaluates typedefed type value

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Tue May  8 19:30:57 2018
New Revision: 260049

URL: https://gcc.gnu.org/viewcvs?rev=260049=gcc=rev
Log:
PR c++/85695
* semantics.c (finish_if_stmt_cond): See through typedefs.

* g++.dg/cpp1z/constexpr-if22.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/constexpr-if22.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/85705] Initializing cout in a dynamically loaded position-independent executable

[gcc at foxcub dot org]

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

--- Comment #3 from gcc at foxcub dot org ---
Created attachment 44094
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44094=edit
Makefile

[Bug libstdc++/85705] Initializing cout in a dynamically loaded position-independent executable

[gcc at foxcub dot org]

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

--- Comment #2 from gcc at foxcub dot org ---
Created attachment 44093
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44093=edit
puppet-lib.cpp

[Bug libstdc++/85705] Initializing cout in a dynamically loaded position-independent executable

[gcc at foxcub dot org]

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

--- Comment #1 from gcc at foxcub dot org ---
Created attachment 44092
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44092=edit
puppet.cpp

[Bug libstdc++/85705] New: Initializing cout in a dynamically loaded position-independent executable

[gcc at foxcub dot org]

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

Bug ID: 85705
   Summary: Initializing cout in a dynamically loaded
position-independent executable
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at foxcub dot org
  Target Milestone: ---

Created attachment 44091
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44091=edit
main.cpp

I build a position-independent executable (puppet.cpp attached), dynamically
load it via dlopen, get its main via dlsym, and call it. This works fine, as
long as this PIE doesn't use iostream, specifically cout. If it does, the code
segfaults with the stack trace below.

If I do roughly the same thing, but compile puppet.cpp as a shared library
(puppet-lib.cpp, renaming main to f), everything works fine.

The sources are attached. Backtrace is below.

This problem occurs only on Linux; on a Mac this works fine.

The culprit seems to be the initialization of cout. Its addresses reported from
main.cpp and puppet-lib.cpp are the same, but it differs in puppet.cpp.

Is there a way to work around this problem?

Thanks.
Dmitriy


Output:
0x55f327a180e0
Hello from main
0x55f327a180e0
Hello from shared library puppet
0x7f1d966e5060
[1]11996 segmentation fault (core dumped)  ./main

Program received signal SIGSEGV, Segmentation fault.
0x7795da56 in std::ostream::sentry::sentry (this=0x7fffe070,
__os=...) at
/build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/ostream.tcc:46
46 
/build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/ostream.tcc:
No such file or directory.
(gdb) back
#0  0x7795da56 in std::ostream::sentry::sentry (this=0x7fffe070,
__os=...) at
/build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/ostream.tcc:46
#1  0x7795e109 in std::__ostream_insert
(__out=..., __s=__s@entry=0x76ce0bf9 "Hello from puppet", __n=17)
at
/build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/ostream_insert.h:76
#2  0x7795e5a9 in std::operator<<  (__out=...,
__s=0x76ce0bf9 "Hello from puppet")
at
/build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/char_traits.h:320
#3  0x76ce0aef in main (argc=0, argv=0x0) at puppet.cpp:6
#4  0x51ca in main () at main.cpp:43

[Bug middle-end/85704] cc1 run out of memory memory when it compile

[haruue at caoyue dot com.cn]

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

Haruue Icymoon  changed:

   What|Removed |Added

 CC||haruue at caoyue dot com.cn

--- Comment #2 from Haruue Icymoon  ---
Created attachment 44090
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44090=edit
The preprocessed source, compressed with gzip

With -save-temps, It generated preprocessed source normally, no diff with the
output of -E.

But the assembler source and elfs can't be generated normally.

The size of preprocessed source is larger than 1000KB so I gzip it.

[Bug middle-end/85704] cc1 run out of memory memory when it compile

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||memory-hog
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-05-08
  Component|c   |middle-end
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Can you provide the preprocessed source (that is if you add -save-temps is the
memory usage high)?

[Bug c/85704] New: cc1 run out of memory memory when it compile

[haruue at caoyue dot com.cn]

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

Bug ID: 85704
   Summary: cc1 run out of memory memory when it compile
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haruue at caoyue dot com.cn
  Target Milestone: ---

Created attachment 44089
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44089=edit
The output of strace

I run out of memory when I try to build linux-usermode 4.16.7 with gcc 8.1.0.


* The operation to reproduce the problem: 
wget http://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.16.tar.xz
wget https://cdn.kernel.org/pub/linux/kernel/v4.x/patch-4.16.7.xz
tar -Jxf linux-4.16.tar.xz
xz -d patch-4.16.7.xz
cd linux-4.16/
patch -p1 -i ../patch-4.16.7
make ARCH=um defconfig
ulimit -m 150 -v 150
make ARCH=um

Then, when it compiles the arch/um/drivers/ubd_kern.c, GCC got into stuck and
exhausts 1.5GB memory in little time.


* Source code of arch/um/drivers/ubd_kern.c in linux kernel tree:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/um/drivers/ubd_kern.c


* The actual command invoked is following:
gcc -Wp,-MD,arch/um/drivers/.ubd_kern.o.d \
-nostdinc \
-isystem \
/usr/lib/gcc/x86_64-pc-linux-gnu/8.1.0/include \
-I./arch/um/include \
-I./arch/um/include/generated \
-I./include \
-I./arch/um/include/uapi \
-I./arch/um/include/generated/uapi \
-I./include/uapi \
-I./include/generated/uapi \
-include \
./include/linux/kconfig.h \
-D__KERNEL__ \
-m64 \
-I./arch/x86/um \
-I./arch/x86/include \
-I./arch/x86/include/uapi \
-I./arch/x86/include/generated \
-I./arch/x86/include/generated/uapi \
-Wall \
-Wundef \
-Wstrict-prototypes \
-Wno-trigraphs \
-fno-strict-aliasing \
-fno-common \
-fshort-wchar \
-Werror-implicit-function-declaration \
-Wno-format-security \
-std=gnu89 \
-fno-PIE \
-mcmodel=large \
-fno-builtin \
-m64 \
-funit-at-a-time \
-D__arch_um__ \
-I./arch/um/include/shared \
-I./arch/x86/um/shared \
-I./arch/um/include/shared/skas \
-Dvmap=kernel_vmap \
-Dlongjmp=kernel_longjmp \
-Dsetjmp=kernel_setjmp \
-Din6addr_loopback=kernel_in6addr_loopback \
-Din6addr_any=kernel_in6addr_any \
-Dstrrchr=kernel_strrchr \
-D_LARGEFILE64_SOURCE \
-Derrno=kernel_errno \
-Dsigprocmask=kernel_sigprocmask \
-Dmktime=kernel_mktime \
-fno-delete-null-pointer-checks \
-Wno-frame-address \
-Wno-format-truncation \
-Wno-format-overflow \
-Wno-int-in-bool-context \
-Os \
-Wno-maybe-uninitialized \
--param=allow-store-data-races=0 \
-DCC_HAVE_ASM_GOTO \
-Wframe-larger-than=1024 \
-fno-stack-protector \
-Wno-unused-but-set-variable \
-Wno-unused-const-variable \
-fno-omit-frame-pointer \
-fno-optimize-sibling-calls \
-fno-var-tracking-assignments \
-g \
-Wdeclaration-after-statement \
-Wno-pointer-sign \
-fno-strict-overflow \
-fno-merge-all-constants \
-fmerge-constants \
-fno-stack-check \
-fconserve-stack \
-Werror=implicit-int \
-Werror=strict-prototypes \
-Werror=date-time \
-Werror=incompatible-pointer-types \
-Werror=designated-init \
-Wno-packed-not-aligned \
-DKBUILD_BASENAME='"ubd_kern"' \
-DKBUILD_MODNAME='"ubd"' \
-c -o \
arch/um/drivers/ubd_kern.o \
arch/um/drivers/ubd_kern.c;


I feel sorry because I know little about gcc implementation. I attached the
strace output of above gcc command. It seem that gcc just mmap more and more
memory before memory run out.

And everything is OK in GCC 7.3.1. 

Is this a bug of gcc or just some problem in the kernel code?

Re: Reduntant move

[Andrew Pinski]

On Tue, May 8, 2018 at 11:07 AM, Dávid Bolvanský
 wrote:
> Hello,
>
> Code example:
> #include 
>
> char * a(int e) {
> char * s;
> switch (e) {
> case 0:
> s = "0";
> break;
> case 1:
> s = "1";
> break;
> case 2:
> s = "2";
> break;
> default:
> s = "def";
> break;
> }
>
> return s;
> }
>
>
> GCC 8.1:
> a:
>   mov eax, OFFSET FLAT:.LC0
>   cmp edi, 2
>   ja .L1
>   mov edi, edi  <-- redundant?

Is a zero extend from edi to rdi.  Yes it is written as a mov but it
causes the cleaning of the top 32bits of rdi.

Thanks,
Andrew

PS gcc-bugs@ is really for the automated bugzilla emails so sending it
to gcc-bugs@ might not get that much attention.

>   mov rax, QWORD PTR CSWTCH.0[0+rdi*8]
> .L1:
>   ret


http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail;
target="_blank">https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png;
alt="" width="46" height="29" style="width: 46px; height: 29px;"
/>
Virus-free. http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail;
target="_blank" style="color: #4453ea;">www.avg.com

[Bug fortran/85703] New: ICE in resolve_fntype, at fortran/resolve.c:16313

[gs...@t-online.de]

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

Bug ID: 85703
   Summary: ICE in resolve_fntype, at fortran/resolve.c:16313
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to gfortran-5 :


$ cat z1.f90
character function f()
   !$acc parallel loop reduction(+:a)
   do i = 1, 4
   end do
   !$acc end parallel loop
end


$ gfortran-9-20180506 -c z1.f90 -fopenacc
f951: internal compiler error: Segmentation fault
0xb9e99f crash_signal
../../gcc/toplev.c:325
0x71c4fa resolve_fntype
../../gcc/fortran/resolve.c:16313
0x71c4fa resolve_types
../../gcc/fortran/resolve.c:16456
0x717cac gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:16568
0x70140a resolve_all_program_units
../../gcc/fortran/parse.c:6060
0x70140a gfc_parse_file()
../../gcc/fortran/parse.c:6310
0x74832f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/85703] ICE in resolve_fntype, at fortran/resolve.c:16313

[gs...@t-online.de]

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

--- Comment #1 from G. Steinmetz  ---

Compiles with result type changed to real or integer, etc.

$ cat z2.f90
real function f()
   !$acc parallel loop reduction(+:a)
   do i = 1, 4
   end do
   !$acc end parallel loop
end


Compiles with explicit result declaration :

$ cat z3.f90
function f() result(z)
   character :: z
   integer :: i
   !$acc parallel loop reduction(+:a)
   do i = 1, 4
   end do
   !$acc end parallel loop
end

[Bug fortran/85702] New: ICE in gfc_format_decoder, at fortran/error.c:943

[gs...@t-online.de]

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

Bug ID: 85702
   Summary: ICE in gfc_format_decoder, at fortran/error.c:943
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to gfortran-5 :


$ cat z1.f90
subroutine s
   !$acc wait(*)
end


$ gfortran-9-20180506 -c z1.f90 -fopenacc
0xb9e99f crash_signal
../../gcc/toplev.c:325
0x6a6007 gfc_format_decoder
../../gcc/fortran/error.c:943
0x12f5cb3 pp_format(pretty_printer*, text_info*)
../../gcc/pretty-print.c:1375
0x12eecbb diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc/diagnostic.c:984
0x6a5f37 gfc_error_opt
../../gcc/fortran/error.c:1308
0x6a74d0 gfc_error(char const*, ...)
../../gcc/fortran/error.c:1337
0x6ef41f gfc_match_oacc_wait()
../../gcc/fortran/openmp.c:2181
0x6f69d9 match_word_omp_simd
../../gcc/fortran/parse.c:93
0x6f6d51 match_word
../../gcc/fortran/parse.c:61
0x6f6d51 decode_oacc_directive
../../gcc/fortran/parse.c:697
0x6fc32f next_free
../../gcc/fortran/parse.c:1215
0x6fc32f next_statement
../../gcc/fortran/parse.c:1462
0x6fde0c parse_spec
../../gcc/fortran/parse.c:3670
0x6ffdd3 parse_progunit
../../gcc/fortran/parse.c:5667
0x7016c4 gfc_parse_file()
../../gcc/fortran/parse.c:6214
0x74832f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/85701] New: ICE in mark_scope_block_unused, at tree-ssa-live.c:364

[gs...@t-online.de]

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

Bug ID: 85701
   Summary: ICE in mark_scope_block_unused, at tree-ssa-live.c:364
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With invalid code (s is not a variable) (but compiles with -g) :


$ cat z1.f90
subroutine s
   !$acc declare copy(s)
end


$ cat z2.f90
subroutine s
   !$acc declare present(s)
end


$ gfortran-9-20180506 -c z1.f90 -fopenacc -O0 -g
$
$ gfortran-9-20180506 -c z1.f90 -fopenacc -O0
during RTL pass: expand
z1.f90:1:0:

 subroutine s

internal compiler error: Segmentation fault
0xb9e99f crash_signal
../../gcc/toplev.c:325
0x7fca10 clear_tree_used
../../gcc/cfgexpand.c:1725
0x80881a expand_used_vars
../../gcc/cfgexpand.c:2052
0x80a922 execute
../../gcc/cfgexpand.c:6292


$ gfortran-9-20180506 -c z1.f90 -fopenacc -O1
during GIMPLE pass: ssa
z1.f90:1:0:

 subroutine s

internal compiler error: Segmentation fault
0xb9e99f crash_signal
../../gcc/toplev.c:325
0xc9c6c1 mark_scope_block_unused
../../gcc/tree-ssa-live.c:364
0xc9c6ef mark_scope_block_unused
../../gcc/tree-ssa-live.c:368
0xc9d5c1 remove_unused_locals()
../../gcc/tree-ssa-live.c:719
0xada764 execute_function_todo
../../gcc/passes.c:1972
0xadb0a9 execute_todo
../../gcc/passes.c:2048

Reduntant move

[Dávid Bolvanský]

Hello,

Code example:
#include 

char * a(int e) {
char * s;
switch (e) {
case 0:
s = "0";
break;
case 1:
s = "1";
break;
case 2:
s = "2";
break;
default:
s = "def";
break;
}

return s;
}


GCC 8.1:
a:
  mov eax, OFFSET FLAT:.LC0
  cmp edi, 2
  ja .L1
  mov edi, edi  <-- redundant?
  mov rax, QWORD PTR CSWTCH.0[0+rdi*8]
.L1:
  ret

[Bug tree-optimization/85698] CPU2017 525.x264_r fails starting with r257581

[pthaugen at gcc dot gnu.org]

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

--- Comment #1 from Pat Haugen  ---
Looks like benchmark fails when x264_src/common/dct.c is compiled with r257581.

[Bug tree-optimization/85651] Invalid -Warray-bounds warning with -O3

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=55881

--- Comment #5 from Martin Sebor  ---
Pr55881 tracks the pragma diagnostic bug.

[Bug tree-optimization/85651] Invalid -Warray-bounds warning with -O3

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
I'm afraid the pragma problem is an independent bug that affects many/most
middle-end warnings (see, for example, the test case below).  It will require a
different and likely more involved change.

$ cat u.c && gcc -O2 -S -Wall u.c
int f (int i)
{
  return "123"[i];
}

int g (void)
{
#pragma GCC diagnostic ignored "-Warray-bounds"
  return f (4);
}
u.c: In function ‘g’:
u.c:3:15: warning: array subscript 4 is above array bounds of ‘char[4]’
[-Warray-bounds]
   return "123"[i];
  ~^~~

[Bug c++/85363] Throwing exception from member constructor (brace initializer vs initializer list)

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
In C++11, .eh optimizes out the catch, so the exception is never caught.  That
is because lower_catch doesn't think that the region may throw
(eh_region_may_contain_throw).

After further poking it seems the cause is that P::P () is marked as
TREE_NOTHROW, which seems incorrect, because it calls X::X() which calls init()
with throw.  That TREE_NOTHROW is set in finish_function:

  /* If this function can't throw any exceptions, remember that.  */
  if (!processing_template_decl
  && !cp_function_chain->can_throw
  && !flag_non_call_exceptions
  && !decl_replaceable_p (fndecl))
TREE_NOTHROW (fndecl) = 1;

[Bug tree-optimization/85700] Spurious -Wstringop-truncation warning with strncat

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
Let me look into it.

[Bug tree-optimization/85700] Spurious -Wstringop-truncation warning with strncat

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-08
 CC||msebor at gcc dot gnu.org
  Component|c++ |tree-optimization
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  Strncat is handled in maybe_diag_stxncpy_trunc() the same way as
strncpy and the approach doesn't seem right for the former.  The following test
case shows the inconsistency.  (The difference between C and C++ is due to the
C  defining strncat as a macro which suppresses the warning due to
-Wno-system-headers; in C++, strncat is defined as a function so
-Wno-system-headers has no effect on calls to it.)

$ cat u.c && gcc -O2 -S -Wall -ftrack-macro-expansion=0 /build/tmp/u.c
#define strncat __builtin_strncat
#define strlen __builtin_strlen

char a[4], b[4];

void f1 (void)
{
  strncat (a, "1", sizeof a - strlen (a) - 1);   // no warning (good)
}

void f2 (void)
{
  strncat (a, "12", sizeof a - strlen (a) - 1);  // bogus -Wstringop-truncation
}

void fx (void)
{
  strncat (a, b, sizeof a - strlen (a) - 1); // bogus -Wstringop-truncation
}

/build/tmp/u.c: In function ‘f2’:
/build/tmp/u.c:13:3: warning: ‘__builtin_strncat’ output may be truncated
copying between 0 and 3 bytes from a string of length 2 [-Wstringop-truncation]
   strncat (a, "12", sizeof a - strlen (a) - 1);  // bogus
-Wstringop-truncation
   ^~~~
/build/tmp/u.c: In function ‘fx’:
/build/tmp/u.c:18:3: warning: ‘__builtin_strncat’ output may be truncated
copying between 0 and 3 bytes from a string of length 3 [-Wstringop-truncation]
   strncat (a, b, sizeof a - strlen (a) - 1); // bogus
-Wstringop-truncation
   ^

[Bug tree-optimization/85651] Invalid -Warray-bounds warning with -O3

[gburca-gnu at ebixio dot com]

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

--- Comment #3 from Gabriel Burca  ---
Does that also fix the issue with the ignored diagnostic pragmas?

[Bug c++/85695] [8/9 Regression] if constexpr misevaluates typedefed type value

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug tree-optimization/85693] Generation of SAD (Sum of Absolute Difference) instruction

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #4 from Uroš Bizjak  ---
Target specific testcase that checks psadbw insn generation committed.

[Bug tree-optimization/85693] Generation of SAD (Sum of Absolute Difference) instruction

[uros at gcc dot gnu.org]

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

--- Comment #3 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue May  8 16:48:43 2018
New Revision: 260047

URL: https://gcc.gnu.org/viewcvs?rev=260047=gcc=rev
Log:
PR target/85693
* gcc.target/i386/pr85693.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr85693.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/85700] New: Spurious -Wstringop-truncation warning with strncat

[lopresti at gmail dot com]

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

Bug ID: 85700
   Summary: Spurious -Wstringop-truncation warning with strncat
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lopresti at gmail dot com
  Target Milestone: ---

Test program:

---
#include 
#include 

char buf1[256];

void append(const char *s)
{
  std::strncat(buf1, s, sizeof(buf1) - strlen(buf1) - 1);
}

void doit(int err)
{
  char tmp[256];
  std::snprintf(tmp, sizeof(tmp), " errno %d (%s)",
err, std::strerror(err));
  append(tmp);
}
---

Compile with "g++ -O3 -Wall -c test.cc".


Expected results:

No warning, as the documentation says for this idiomatic use of strncat().


Actual results:

In function ‘void append(const char*)’,
inlined from ‘void doit(int)’ at test.cc:16:9:
test.cc:8:15: warning: ‘char* strncat(char*, const char*, size_t)’ output may
b\
e truncated copying between 0 and 255 bytes from a string of length 255
[-Wstri\
ngop-truncation]
   std::strncat(buf1, s, sizeof(buf1) - strlen(buf1) - 1);
   ^~


Note that a similar program in C does not trigger the warning.

[Bug c++/85695] [8/9 Regression] if constexpr misevaluates typedefed type value

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
This fixes it:

--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -736,7 +736,7 @@ finish_if_stmt_cond (tree cond, tree if_stmt)
   && !instantiation_dependent_expression_p (cond)
   /* Wait until instantiation time, since only then COND has been
 converted to bool.  */
-  && TREE_TYPE (cond) == boolean_type_node)
+  && strip_typedefs (TREE_TYPE (cond)) == boolean_type_node)
 {
   cond = instantiate_non_dependent_expr (cond);
   cond = cxx_constant_value (cond, NULL_TREE);

[Bug target/85683] [8 Regression] GCC 8 stopped using RMW (Read Modify Write) instructions on x86[_64]

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8/9 Regression] GCC 8  |[8 Regression] GCC 8
   |stopped using RMW (Read |stopped using RMW (Read
   |Modify Write) instructions  |Modify Write) instructions
   |on x86[_64] |on x86[_64]

--- Comment #6 from Jakub Jelinek  ---
Fixed for GCC9 so far, will backport to 8.2 after a while.

[Bug target/85683] [8/9 Regression] GCC 8 stopped using RMW (Read Modify Write) instructions on x86[_64]

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Tue May  8 16:17:34 2018
New Revision: 260045

URL: https://gcc.gnu.org/viewcvs?rev=260045=gcc=rev
Log:
PR target/85683
* config/i386/i386.md: Add peepholes for mem {+,-,&,|,^}= x; mem != 0
after cmpelim optimization.

* gcc.target/i386/pr49095.c: Add -masm=att to dg-options.  Add
scan-assembler-times checking that except for [fh]*xor other functions
don't use any load instructions.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr49095.c

[Bug tree-optimization/85694] Generation of vectorized AVG (Average) instruction

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #2)
> Hmm, but if you have 255 + 255 + 1 then you need to use pavgw at least,
> otherwise the vectorization isn't semantically equivalent?  Or do the
> instructions compute
> the intermediate results in greater precision than 8 bits?  The specification
> doesn't seem to tell.
> 
> Can you clarify?

According to [1], intermediate result has 9 bit precision for pavgb and 17bit
precision for pavgw.

[1] http://www.felixcloutier.com/x86/PAVGB:PAVGW.html

[Bug c++/85695] [8/9 Regression] if constexpr misevaluates typedefed type value

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |8.2

--- Comment #1 from Jonathan Wakely  ---
Started with r258756

PR c++/84854
* semantics.c (finish_if_stmt_cond): Check if the type of the
condition
is boolean.

* g++.dg/cpp1z/constexpr-if15.C: New test.
* g++.dg/cpp1z/constexpr-if16.C: New test.

[Bug tree-optimization/85699] [9 regression] gcc.dg/nextafter-2.c fail

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8 regression]  |[9 regression]
   |gcc.dg/nextafter-2.c fail   |gcc.dg/nextafter-2.c fail

--- Comment #1 from Jakub Jelinek  ---
First of all, this test isn't present on 8 branch at all, only trunk.
And, this exact testcase uses -fno-builtin and thus tests the library, so if it
fails, likely your libc is buggy.
Which exact subtest fails for you?
E.g. replace
#define CHECK(x) if (!(x)) __builtin_abort ()
with
#define CHECK(x) if (!(x)) __builtin_printf ("bug at %d %s\n", __LINE__, #x);
and see what it prints?

[Bug c++/85695] if constexpr misevaluates typedefed type value

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-08
 Ever confirmed|0   |1

[Bug tree-optimization/85699] New: [8 regression] gcc.dg/nextafter-2.c fail

[andrey.y.guskov at intel dot com]

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

Bug ID: 85699
   Summary: [8 regression] gcc.dg/nextafter-2.c fail
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrey.y.guskov at intel dot com
  Target Milestone: ---

r259921 triggers this:

spawn -ignore SIGHUP /work/gcc/xgcc -B/work/gcc/
/source/gcc/testsuite/gcc.dg/nextafter-2.c -fno-diagnostics-show-caret
-fdiagnostics-color=never -O2 -fno-builtin -lm -o ./nextafter-2.exe
PASS: gcc.dg/nextafter-2.c (test for excess errors)
spawn [open ...]
FAIL: gcc.dg/nextafter-2.c execution test

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=haswell --with-cpu=haswell

[Bug tree-optimization/85698] New: CPU2017 525.x264_r fails starting with r257581

[pthaugen at gcc dot gnu.org]

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

Bug ID: 85698
   Summary: CPU2017 525.x264_r fails starting with r257581
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pthaugen at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org, segher at kernel dot 
crashing.org,
wschmidt at gcc dot gnu.org
  Target Milestone: ---
  Host: powerpc64le-unknown-linux-gnu
Target: powerpc64le-unknown-linux-gnu
 Build: powerpc64le-unknown-linux-gnu

Benchmark miscompares starting with given revision. Options used for building
the benchmark are "-O3 -mcpu=power8". I did discover that adding -funroll-loops
changes behavior such that the benchmark passes.

Continuing to see if I can narrow down to a specific file that's miscompiled...

[Bug target/85697] New: At -Os nontrivial ctor does not use SSE to zero

[msharov at users dot sourceforge.net]

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

Bug ID: 85697
   Summary: At -Os nontrivial ctor does not use SSE to zero
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msharov at users dot sourceforge.net
  Target Milestone: ---

struct alignas(16) A {
A (void) :a(0),b(0),c(0),d(0) {}
int a,b,c,d;
};
__attribute__((noinline)) void UseA (A& a) { a.a=1; }

int main (void)
{
A a {};
UseA (a);
return a.a;
}

-Os -march=native on Haswell, generates:

main:
subq$16, %rsp
movq%rsp, %rdi
movq$0, (%rsp)
movq$0, 8(%rsp)
call_Z4UseAR1A
movl(%rsp), %eax
addq$16, %rsp
ret

Using 16 bytes to zero A with 2 movq. With -O3:

main:
subq$24, %rsp
vpxor   %xmm0, %xmm0, %xmm0
movq%rsp, %rdi
vmovaps %xmm0, (%rsp)
call_Z4UseAR1A
movl(%rsp), %eax
addq$24, %rsp
ret

using only 9 bytes for pxor/movaps. With -mno-avx it is 7 bytes for
xorps/movaps. With multiple objects of type A, the savings would be even
greater, since only one pxor would be needed for all and only 4 bytes per
object for zeroing.

Removing A constructor also results in SSE instruction use.

[Bug ipa/85103] [8/9 Regression] Performance regressions on SPEC with r257582

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-08
 Ever confirmed|0   |1

--- Comment #9 from David Edelsohn  ---
Confirmed.

[Bug tree-optimization/85692] Two source permute not used for vector initialization

[linux at carewolf dot com]

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

--- Comment #5 from Allan Jensen  ---
Created attachment 44088
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44088=edit
suggested patch

[Bug tree-optimization/85692] Two source permute not used for vector initialization

[linux at carewolf dot com]

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

--- Comment #4 from Allan Jensen  ---
Note I already posted a patch on gcc-patches myself. It is very similar to
yours

[Bug tree-optimization/85694] Generation of vectorized AVG (Average) instruction

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Hmm, but if you have 255 + 255 + 1 then you need to use pavgw at least,
otherwise the vectorization isn't semantically equivalent?  Or do the
instructions compute
the intermediate results in greater precision than 8 bits?  The specification
doesn't seem to tell.

Can you clarify?

[Bug tree-optimization/85694] Generation of vectorized AVG (Average) instruction

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||x86_64-*-*, i?86-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-08
 CC||rguenth at gcc dot gnu.org
 Blocks||53947
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  Note that in C you are writing 'int' arithmetic which we do not
shorten which confuses us enough to vectorize this with 'int' operations.

The main part, missed pavgb vectorization, is confirmed as well though with
more intelligent vectorization using v16qi vectors combine could come to
the rescue as well here (4 insn combine, so not very likely - also needs
unconditional shift / division support for v16qi).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug c/85696] OpenMP with variably modified and default(none) won't compile

[gcc-bugzilla at zulan dot net]

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

--- Comment #2 from gcc-bugzilla at zulan dot net ---
Created attachment 44087
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44087=edit
minimal example

[Bug c/85696] OpenMP with variably modified and default(none) won't compile

[gcc-bugzilla at zulan dot net]

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

gcc-bugzilla at zulan dot net changed:

   What|Removed |Added

  Attachment #44085|0   |1
is obsolete||

--- Comment #1 from gcc-bugzilla at zulan dot net ---
Created attachment 44086
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44086=edit
pologies, wrong gcc version. The error of 8.1.0 is exactly the same though.

[Bug c/85696] New: OpenMP with variably modified and default(none) won't compile

[gcc-bugzilla at zulan dot net]

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

Bug ID: 85696
   Summary: OpenMP with variably modified and default(none) won't
compile
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugzilla at zulan dot net
  Target Milestone: ---

Created attachment 44085
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44085=edit
gcc -v (Archlinux)

The following trivial code

void foo(int n, int a[][n])
{
#pragma omp parallel shared(a) default(none)
a[23][0] = 42;
}

fails to compile:

$ gcc -c -fopenmp minimal.c 
minimal.c: In function ‘foo’:
minimal.c:3:6: error: ‘n.0’ not specified in enclosing ‘parallel’
 a[23][0] = 42;
  ^
minimal.c:2:9: error: enclosing ‘parallel’
 #pragma omp parallel shared(a) default(none)
 ^~~

It appears that there is an internal copy n.0 of n to compute the index to any
further access to a. This internal copy is not handled properly in the
default(none) parallel region.

Interestingly in the 004t.gimple pass, it is actually listed as shared(n.0):

#pragma omp parallel default(none) shared(a) shared(n.0)


The bug exists at least since 4.8 and was first reported at
https://stackoverflow.com/q/47081274/620382

[Bug c++/85634] [8/9 Regression] ICE in tsubst_copy, at cp/pt.c:15483

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #6 from Jason Merrill  ---
Here in the template we initialize a pointer with a function name, which is
looked up to an overload set that never gets marked as persistent, which trips
the assert when we go to substitute that initializer.  Nathan, how should this
work?

[Bug tree-optimization/85693] Generation of SAD (Sum of Absolute Difference) instruction

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #2 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #1)
> We already do?

Oh... indeed. I was looking at system compiler output... X(

[Bug tree-optimization/85692] Two source permute not used for vector initialization

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Untested patch:

--- gcc/tree-ssa-forwprop.c.jj  2018-01-04 22:08:04.492684761 +0100
+++ gcc/tree-ssa-forwprop.c 2018-05-08 16:07:09.356121105 +0200
@@ -2004,7 +2004,7 @@ simplify_vector_constructor (gimple_stmt
 {
   gimple *stmt = gsi_stmt (*gsi);
   gimple *def_stmt;
-  tree op, op2, orig, type, elem_type;
+  tree op, op2, orig[2], type, elem_type;
   unsigned elem_size, i;
   unsigned HOST_WIDE_INT nelts;
   enum tree_code code, conv_code;
@@ -2023,7 +2023,8 @@ simplify_vector_constructor (gimple_stmt
   elem_size = TREE_INT_CST_LOW (TYPE_SIZE (elem_type));

   vec_perm_builder sel (nelts, nelts, 1);
-  orig = NULL;
+  orig[0] = NULL;
+  orig[1] = NULL;
   conv_code = ERROR_MARK;
   maybe_ident = true;
   FOR_EACH_VEC_SAFE_ELT (CONSTRUCTOR_ELTS (op), i, elt)
@@ -2063,25 +2064,35 @@ simplify_vector_constructor (gimple_stmt
return false;
   op1 = gimple_assign_rhs1 (def_stmt);
   ref = TREE_OPERAND (op1, 0);
-  if (orig)
+  unsigned int j;
+  for (j = 0; j < 2; ++j)
{
- if (ref != orig)
-   return false;
-   }
-  else
-   {
- if (TREE_CODE (ref) != SSA_NAME)
-   return false;
- if (! VECTOR_TYPE_P (TREE_TYPE (ref))
- || ! useless_type_conversion_p (TREE_TYPE (op1),
- TREE_TYPE (TREE_TYPE (ref
-   return false;
- orig = ref;
+ if (!orig[j])
+   {
+ if (TREE_CODE (ref) != SSA_NAME)
+   return false;
+ if (! VECTOR_TYPE_P (TREE_TYPE (ref))
+ || ! useless_type_conversion_p (TREE_TYPE (op1),
+ TREE_TYPE (TREE_TYPE (ref
+   return false;
+ if (j && !useless_type_conversion_p (TREE_TYPE (orig[0]),
+  TREE_TYPE (ref)))
+   return false;
+ orig[j] = ref;
+ break;
+   }
+ else if (ref == orig[j])
+   break;
}
+  if (j == 2)
+   return false;
+
   unsigned int elt;
   if (maybe_ne (bit_field_size (op1), elem_size)
  || !constant_multiple_p (bit_field_offset (op1), elem_size, ))
return false;
+  if (j)
+   elt += nelts;
   if (elt != i)
maybe_ident = false;
   sel.quick_push (elt);
@@ -2089,14 +2100,14 @@ simplify_vector_constructor (gimple_stmt
   if (i < nelts)
 return false;

-  if (! VECTOR_TYPE_P (TREE_TYPE (orig))
+  if (! VECTOR_TYPE_P (TREE_TYPE (orig[0]))
   || maybe_ne (TYPE_VECTOR_SUBPARTS (type),
-  TYPE_VECTOR_SUBPARTS (TREE_TYPE (orig
+  TYPE_VECTOR_SUBPARTS (TREE_TYPE (orig[0]
 return false;

   tree tem;
   if (conv_code != ERROR_MARK
-  && (! supportable_convert_operation (conv_code, type, TREE_TYPE (orig),
+  && (! supportable_convert_operation (conv_code, type, TREE_TYPE
(orig[0]),
   , _code)
  || conv_code == CALL_EXPR))
 return false;
@@ -2104,16 +2115,16 @@ simplify_vector_constructor (gimple_stmt
   if (maybe_ident)
 {
   if (conv_code == ERROR_MARK)
-   gimple_assign_set_rhs_from_tree (gsi, orig);
+   gimple_assign_set_rhs_from_tree (gsi, orig[0]);
   else
-   gimple_assign_set_rhs_with_ops (gsi, conv_code, orig,
+   gimple_assign_set_rhs_with_ops (gsi, conv_code, orig[0],
NULL_TREE, NULL_TREE);
 }
   else
 {
   tree mask_type;

-  vec_perm_indices indices (sel, 1, nelts);
+  vec_perm_indices indices (sel, orig[1] ? 2 : 1, nelts);
   if (!can_vec_perm_const_p (TYPE_MODE (type), indices))
return false;
   mask_type
@@ -2124,16 +2135,19 @@ simplify_vector_constructor (gimple_stmt
   GET_MODE_SIZE (TYPE_MODE (type
return false;
   op2 = vec_perm_indices_to_tree (mask_type, indices);
+  if (!orig[1])
+   orig[1] = orig[0];
   if (conv_code == ERROR_MARK)
-   gimple_assign_set_rhs_with_ops (gsi, VEC_PERM_EXPR, orig, orig, op2);
+   gimple_assign_set_rhs_with_ops (gsi, VEC_PERM_EXPR, orig[0],
+   orig[1], op2);
   else
{
  gimple *perm
-   = gimple_build_assign (make_ssa_name (TREE_TYPE (orig)),
-  VEC_PERM_EXPR, orig, orig, op2);
- orig = gimple_assign_lhs (perm);
+   = gimple_build_assign (make_ssa_name (TREE_TYPE (orig[0])),
+  VEC_PERM_EXPR, orig[0], orig[1], op2);
+ orig[0] = 

[Bug c++/85695] New: if constexpr misevaluates typedefed type value

[msharov at users dot sourceforge.net]

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

Bug ID: 85695
   Summary: if constexpr misevaluates typedefed type value
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msharov at users dot sourceforge.net
  Target Milestone: ---

template 
struct integral_constant {
using value_type = T;
static constexpr const value_type value = v;
constexpr operator value_type (void) const { return value; }
};
template  struct is_trivial
: public integral_constant {};

template 
T clone_object (const T& p)
{
if constexpr (is_trivial::value)
return p;
else
return p.clone();
}
int main (void) { return clone_object(0); }

This fails to compile: "error: request for member ‘clone’ in ‘p’". The strange
part is that changing the type of integral_constant::value to T makes it work,
as  does using is_trivial() in the conditional, invoking the cast operator.
For some reason, value_type is evaluated differently if it is a variable or
return value, and differently from T.

[Bug tree-optimization/85694] New: Generation of vectorized AVG (Average) instruction

[ubizjak at gmail dot com]

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

Bug ID: 85694
   Summary: Generation of vectorized AVG (Average) instruction
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---

As mentioned in [1], page 12, following code:

--cut here--
#define N 1024

unsigned char src1[N], src2[N], dst[N];

void foo (void)
{
  int i;

  for (i = 0; i < N; i++)
dst[i] = (src1[i] + src2[i] + 1) >> 1;
}
--cut here--

should vectorize with pavgb instruction.

[1]
http://llvm.org/devmtg/2018-04/slides/Das-An%20Introduction%20to%20AMD%20Optimizing%20Compiler.pdf

[Bug tree-optimization/85693] Generation of SAD (Sum of Absolute Difference) instruction

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
We already do?

> ./cc1 -quiet t.c -O3 -fdump-tree-vect-details -I include
> grep psadbw t.s
psadbw  pix2(%rax), %xmm0

[Bug tree-optimization/85693] New: Generation of SAD (Sum of Absolute Difference) instruction

[ubizjak at gmail dot com]

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

Bug ID: 85693
   Summary: Generation of SAD (Sum of Absolute Difference)
instruction
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---

As mentioned in [1], page 7, following code:

--cut here--
#include 

#define N 1024

unsigned char pix1[N], pix2[N];

int foo (void)
{
  int i_sum = 0;
  int i;

  for (i = 0; i < N; i++)
i_sum += abs (pix1[i] - pix2[i]);

  return i_sum;
}
--cut here--

should vectorize to psadbw instruction.

[1]
http://llvm.org/devmtg/2018-04/slides/Das-An%20Introduction%20to%20AMD%20Optimizing%20Compiler.pdf

[Bug libstdc++/85672] [9 Regression] error: redefinition of 'constexpr long double std::abs(long double)'

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #14 from Jonathan Wakely  ---
This should be fixed now.

[Bug target/85616] ARM target using -O2 may cause unaligned access

[denis_second at hotmail dot com]

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

Denis Roux  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #6 from Denis Roux  ---
Ok this is a fair assumption from gcc and the result makes total sense. Using
the suggested new type provides code with expected result.

Thank you for taking the time and providing valuable input regarding this
issue.

[Bug tree-optimization/85615] [8 Regression] ICE at -O2 and above on valid code on x86_64-linux-gnu: in dfs_enumerate_from, at cfganal.c:1197

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
  Known to fail||8.1.0

--- Comment #9 from Richard Biener  ---
Fixed.

[Bug tree-optimization/85597] [6/7/8 Regression] internal compiler error: in compute_live_loop_exits, at tree-ssa-loop-manip.c:229

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Tue May  8 13:33:54 2018
New Revision: 260044

URL: https://gcc.gnu.org/viewcvs?rev=260044=gcc=rev
Log:
2018-05-08  Richard Biener  

Backport from mainline
2018-05-04  Richard Biener  

PR middle-end/85588
* fold-const.c (negate_expr_p): Restrict negation of operand
zero of a division to when we know that can happen without
overflow.
(fold_negate_expr_1): Likewise.

* gcc.dg/torture/pr85588.c: New testcase.
* gcc.dg/torture/pr57656.c: Use dg-additional-options.

2018-05-03  Richard Biener  

PR tree-optimization/85615
* tree-ssa-threadupdate.c (thread_block_1): Only allow exits
to loops not nested in BBs loop father to avoid creating multi-entry
loops.

* gcc.dg/torture/pr85615.c: New testcase.

2018-05-02  Richard Biener  

PR middle-end/85567
* gimplify.c (gimplify_save_expr): When in SSA form allow
SAVE_EXPRs to compute to SSA vars.

* gcc.dg/torture/pr85567.c: New testcase.

2018-05-02  Richard Biener  

PR tree-optimization/85597
* tree-vect-stmts.c (vectorizable_operation): For ternary SLP
do not use split vect_get_vec_defs call but call vect_get_slp_defs
directly.

* gcc.dg/vect/pr85597.c: New testcase.

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr85567.c
branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr85588.c
branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr85615.c
branches/gcc-8-branch/gcc/testsuite/gcc.dg/vect/pr85597.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/fold-const.c
branches/gcc-8-branch/gcc/gimplify.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr57656.c
branches/gcc-8-branch/gcc/tree-ssa-threadupdate.c
branches/gcc-8-branch/gcc/tree-vect-stmts.c

[Bug tree-optimization/85615] [8 Regression] ICE at -O2 and above on valid code on x86_64-linux-gnu: in dfs_enumerate_from, at cfganal.c:1197

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Tue May  8 13:33:54 2018
New Revision: 260044

URL: https://gcc.gnu.org/viewcvs?rev=260044=gcc=rev
Log:
2018-05-08  Richard Biener  

Backport from mainline
2018-05-04  Richard Biener  

PR middle-end/85588
* fold-const.c (negate_expr_p): Restrict negation of operand
zero of a division to when we know that can happen without
overflow.
(fold_negate_expr_1): Likewise.

* gcc.dg/torture/pr85588.c: New testcase.
* gcc.dg/torture/pr57656.c: Use dg-additional-options.

2018-05-03  Richard Biener  

PR tree-optimization/85615
* tree-ssa-threadupdate.c (thread_block_1): Only allow exits
to loops not nested in BBs loop father to avoid creating multi-entry
loops.

* gcc.dg/torture/pr85615.c: New testcase.

2018-05-02  Richard Biener  

PR middle-end/85567
* gimplify.c (gimplify_save_expr): When in SSA form allow
SAVE_EXPRs to compute to SSA vars.

* gcc.dg/torture/pr85567.c: New testcase.

2018-05-02  Richard Biener  

PR tree-optimization/85597
* tree-vect-stmts.c (vectorizable_operation): For ternary SLP
do not use split vect_get_vec_defs call but call vect_get_slp_defs
directly.

* gcc.dg/vect/pr85597.c: New testcase.

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr85567.c
branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr85588.c
branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr85615.c
branches/gcc-8-branch/gcc/testsuite/gcc.dg/vect/pr85597.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/fold-const.c
branches/gcc-8-branch/gcc/gimplify.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr57656.c
branches/gcc-8-branch/gcc/tree-ssa-threadupdate.c
branches/gcc-8-branch/gcc/tree-vect-stmts.c

[Bug tree-optimization/85588] [6/7/8 Regression] -fwrapv miscompilation

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
Author: rguenth
Date: Tue May  8 13:33:54 2018
New Revision: 260044

URL: https://gcc.gnu.org/viewcvs?rev=260044=gcc=rev
Log:
2018-05-08  Richard Biener  

Backport from mainline
2018-05-04  Richard Biener  

PR middle-end/85588
* fold-const.c (negate_expr_p): Restrict negation of operand
zero of a division to when we know that can happen without
overflow.
(fold_negate_expr_1): Likewise.

* gcc.dg/torture/pr85588.c: New testcase.
* gcc.dg/torture/pr57656.c: Use dg-additional-options.

2018-05-03  Richard Biener  

PR tree-optimization/85615
* tree-ssa-threadupdate.c (thread_block_1): Only allow exits
to loops not nested in BBs loop father to avoid creating multi-entry
loops.

* gcc.dg/torture/pr85615.c: New testcase.

2018-05-02  Richard Biener  

PR middle-end/85567
* gimplify.c (gimplify_save_expr): When in SSA form allow
SAVE_EXPRs to compute to SSA vars.

* gcc.dg/torture/pr85567.c: New testcase.

2018-05-02  Richard Biener  

PR tree-optimization/85597
* tree-vect-stmts.c (vectorizable_operation): For ternary SLP
do not use split vect_get_vec_defs call but call vect_get_slp_defs
directly.

* gcc.dg/vect/pr85597.c: New testcase.

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr85567.c
branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr85588.c
branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr85615.c
branches/gcc-8-branch/gcc/testsuite/gcc.dg/vect/pr85597.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/fold-const.c
branches/gcc-8-branch/gcc/gimplify.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr57656.c
branches/gcc-8-branch/gcc/tree-ssa-threadupdate.c
branches/gcc-8-branch/gcc/tree-vect-stmts.c

[Bug middle-end/85567] [7/8 Regression] internal compiler error: in gimplify_modify_expr, at gimplify.c:5797 when using sincos()

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Tue May  8 13:33:54 2018
New Revision: 260044

URL: https://gcc.gnu.org/viewcvs?rev=260044=gcc=rev
Log:
2018-05-08  Richard Biener  

Backport from mainline
2018-05-04  Richard Biener  

PR middle-end/85588
* fold-const.c (negate_expr_p): Restrict negation of operand
zero of a division to when we know that can happen without
overflow.
(fold_negate_expr_1): Likewise.

* gcc.dg/torture/pr85588.c: New testcase.
* gcc.dg/torture/pr57656.c: Use dg-additional-options.

2018-05-03  Richard Biener  

PR tree-optimization/85615
* tree-ssa-threadupdate.c (thread_block_1): Only allow exits
to loops not nested in BBs loop father to avoid creating multi-entry
loops.

* gcc.dg/torture/pr85615.c: New testcase.

2018-05-02  Richard Biener  

PR middle-end/85567
* gimplify.c (gimplify_save_expr): When in SSA form allow
SAVE_EXPRs to compute to SSA vars.

* gcc.dg/torture/pr85567.c: New testcase.

2018-05-02  Richard Biener  

PR tree-optimization/85597
* tree-vect-stmts.c (vectorizable_operation): For ternary SLP
do not use split vect_get_vec_defs call but call vect_get_slp_defs
directly.

* gcc.dg/vect/pr85597.c: New testcase.

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr85567.c
branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr85588.c
branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr85615.c
branches/gcc-8-branch/gcc/testsuite/gcc.dg/vect/pr85597.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/fold-const.c
branches/gcc-8-branch/gcc/gimplify.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr57656.c
branches/gcc-8-branch/gcc/tree-ssa-threadupdate.c
branches/gcc-8-branch/gcc/tree-vect-stmts.c

[Bug libstdc++/85672] [9 Regression] error: redefinition of 'constexpr long double std::abs(long double)'

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely  ---
Author: redi
Date: Tue May  8 13:05:04 2018
New Revision: 260043

URL: https://gcc.gnu.org/viewcvs?rev=260043=gcc=rev
Log:
PR libstdc++/85672 #undef _GLIBCXX_USE_FLOAT128 when not supported

Restore the behaviour in GCC 8 and earlier where _GLIBCXX_USE_FLOAT128
is not defined when configure detects support is missing. This avoids
having three states where the macro is either 1, 0, or undefined.

PR libstdc++/85672
* include/Makefile.am [!ENABLE_FLOAT128]: Change c++config.h entry
to #undef _GLIBCXX_USE_FLOAT128 instead of defining it to zero.
* include/Makefile.in: Regenerate.
* include/bits/c++config (_GLIBCXX_USE_FLOAT128): Move definition
within conditional block.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/Makefile.am
trunk/libstdc++-v3/include/Makefile.in
trunk/libstdc++-v3/include/bits/c++config

[Bug tree-optimization/61502] == comparison on "one-past" pointer gives wrong result

[Peter.Sewell at cl dot cam.ac.uk]

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

--- Comment #29 from Peter Sewell  ---
On 8 May 2018 at 08:22, rguenth at gcc dot gnu.org  wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
>
> --- Comment #25 from Richard Biener  ---
> (In reply to Harald van Dijk from comment #22)
> > (In reply to Andrew Pinski from comment #21)
> > > Invalid as mentioned a few times already but never actually closed
> until now.
> >
> > I posted a strictly conforming program that with GCC does not behave as
> > required by the standard. The issue is valid, even if the original test
> case
> > is not.
>
> If you are talking about the one in comment#12 then this is the same issue
> as present in a few other "similar" bugs where GCC propagates conditional
> equivalences (for example the linked PR65752):
>
>   v = 
>   p = v;
>   x = 2, y = 1;
>   if (p ==  + 1)
> *p = 2;
>
> is turned into
>
>   v = 
>   p = v;
>   x = 2, y = 1;
>   if (p ==  + 1)
> *( + 1) = 2;
>
> by GCC and the store is then no longer possibly aliasing y.
>
> Conditional equivalences are a difficult thing to exploit for optimization
> and there's some work in progress for the standard regarding to pointer
> provenance which IIRC says that the comparison result of  ==  + 1
> returns an unspecified value.  Not sure if that helps us


FYI, the current state of that work in progress is here:

https://cdn.rawgit.com/C-memory-object-model-study-group/c-mom-sg/master/notes/cmom-0001-2018-05-04-sewell-clarifying-provenance-v4.html

and comments from a GCC perspective would be much appreciated.
It's been informed by useful discussion at the recent WG14 and EuroLLVM
meetings.

Our current proposal indeed makes that comparison an unspecified value -
more
generally, allowing any pointer equality comparison to either take
provenance
into account or not - exactly because we see GCC do so in some cases.
If that isn't important for optimisation, returning to a fully concrete
semantics
for == would be a simpler choice.

but then the
> only way our for GCC for this particular issue would be to never actually
> propagate conditional equivalences.
>

(Conceivably it could be allowed where the compiler can see that the two
have the same provenance.  We've no idea how useful that would be.)


>
> Sth that might be worth investigating, but within the current structure of
> the optimization passes that apply this transform it's impossible to decide
> whether a value resulted from conditional equivalences or not...  I'm also
> not sure to what extent simplification results using a conditional
> predicate
> like p ==  + 1 are affected as well.
>
> IMHO it's a defect in the language if
>
>   p = 
>   if (p ==  + 1)
> *p = 2;
>
> is valid but
>
>   p = 
>   if (p ==  + 1)
> *( + 1) = 2;
>
> is invoking undefined behavior.  Or at least a very uncomfortable situation
> for a compiler writer.  IMHO the pointer provenance work making the
> comparison having unspecified result doesn't really help since that doesn't
> make it invoke undefined behavior.
>

It's not clear how this could be resolved. For the source-language
semantics,
if one wants to be able to do provenance-based alias analysis, we don't see
any clean way in which the second could be allowed.
And forbidding the first would need one to make == of pointers with
different
provenances UB, which we imagine would break a lot of C code.

That said, in general the intermediate-language semantics might be quite
different
from the C-source-language semantics (as we discover in discussion with
Nuno Lopes
and his colleagues about their LLVM semantics), so long as it implements
the source
semantics.

Peter, Kayvan, Victor


>
> --
> You are receiving this mail because:
> You reported the bug.
>

[Bug target/85572] faster code for absolute value of __v2di

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Fixed for gcc 9+.

[Bug target/85480] zero extension from xmm to zmm via _mm512_insert???x? not optimized

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Jakub Jelinek  ---
Fixed for GCC9+.

[Bug target/85317] missing constant propagation on _mm(256)_movemask_*

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Jakub Jelinek  ---
Fixed for GCC 9+.