[Bug target/82182] m68k slow code: u16/u8 division calls divsi3

2019-06-17 Thread cand at gmx dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82182

--- Comment #2 from Lauri Kasanen  ---
It may be a few weeks before I can test newer gcc.

[Bug inline-asm/90907] Binary crashes if both asm() and __thread are used in the same code

2019-06-17 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90907

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|c   |inline-asm
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
Toplevel inline-asm is in a specific section.  You need to push the new section
and change back to the original one.  In this case, the current section when
the inline-asm is used is the TLS section which is marked as not executable.

[Bug middle-end/80791] [8/9/10 regression] test case gcc.dg/sms-1.c fail2 starting with r247885

2019-06-17 Thread linkw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80791

--- Comment #25 from Kewen Lin  ---
Author: linkw
Date: Tue Jun 18 05:08:02 2019
New Revision: 272405

URL: https://gcc.gnu.org/viewcvs?rev=272405=gcc=rev
Log:

Add one target hook predict_doloop_p, it return true if we can predict it
is possible to use a low-overhead loop, it can help ivopts to make some
better decisions.

PR middle-end/80791
* target.def (predict_doloop_p): New hook.
* targhooks.h (default_predict_doloop_p): New declaration.
* targhooks.c (default_predict_doloop_p): New function.
* doc/tm.texi.in (TARGET_PREDICT_DOLOOP_P): New hook.
* doc/tm.texi: Regenerate.
* config/rs6000/rs6000.c (rs6000_predict_doloop_p): New function.
(TARGET_PREDICT_DOLOOP_P): New macro.
* tree-ssa-loop-ivopts.c (generic_predict_doloop_p): New function.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/doc/tm.texi
trunk/gcc/doc/tm.texi.in
trunk/gcc/target.def
trunk/gcc/targhooks.c
trunk/gcc/targhooks.h
trunk/gcc/tree-ssa-loop-ivopts.c

[Bug c/90907] New: Binary crashes if both asm() and __thread are used in the same code

2019-06-17 Thread fujim...@clear-code.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90907

Bug ID: 90907
   Summary: Binary crashes if both asm() and __thread are used in
the same code
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fujim...@clear-code.com
  Target Milestone: ---

Created attachment 46494
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46494=edit
Preprocessed file for the reproduction code

Condier the following code:

__thread int x;
asm (
".global foo\n"
"foo:\n"
"  ret"
);
void foo(void);
int main(){foo();}

GCC (all of 6.3.0, 7.4.0, 8.3.0 and 9.1.0) fails to compile this code
properly and the resulting executable crashes with a segmentation fault.

$ gcc foo.c
$ ./a.out
Segmentation fault

An interesting thing is that moving __thread line after asm() fixes
the issue. Indeed, I can confirm that the following (slightly-tweaked)
code works fine with GCC 9.1.0.

asm (
".global foo\n"
"foo:\n"
"  ret"
);
void foo(void);
__thread int x;
int main(){foo();}

This suggests that something is wrong with GCC's code generation for
__thread.

$ gcc foo-reordered.c
$ ./a.out && echo $?
0

I can reproduce this bug on the following platforms:

* Debian 9.8 (x64:Intel i5-7200U)
* Ubuntu 18.04 (aarch64:Cavium ThunderX 88XX)

The exact build option for the GCC version I used is:

$ gcc-9 -v
Using built-in specs.
COLLECT_GCC=gcc-9
COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/9/lto-wrapper
Target: aarch64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
9.1.0-2ubuntu2~18.04' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-9
--program-prefix=aarch64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-libquadmath --disable-libquadmath-support --enable-plugin
--enable-default-pie --with-system-zlib --with-target-system-zlib=auto
--enable-multiarch --enable-fix-cortex-a53-843419 --disable-werror
--enable-checking=release --build=aarch64-linux-gnu --host=aarch64-linux-gnu
--target=aarch64-linux-gnu
Thread model: posix
gcc version 9.1.0 (Ubuntu 9.1.0-2ubuntu2~18.04)

[Bug tree-optimization/90906] diagnose returning pointers to freed memory

2019-06-17 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90906

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-06-18
 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=80532
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed. Related to bug 80532

[Bug c++/60223] [c++11] ICE with C++11-style default template parameter

2019-06-17 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60223

Marek Polacek  changed:

   What|Removed |Added

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

[Bug fortran/90890] segfault on LHS memory reallocation

2019-06-17 Thread bharat.mahajan at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90890

--- Comment #6 from Bharat Mahajan  ---
(In reply to Steve Kargl from comment #5)
> You got lucky.  You gave the compiler invalid code.  It can do
> anything with the code (including giving you a result that you
> may expect).
> 

Ok I see. I checked with ifort team and ifort also gives a warning in this case
if appropriate option is used. And the correct way was to allocate 'a' to 0
size and then use it in order to avoid calls to 'allocated()' inside a loop. I
didn't know that was an option in Fortran. Thanks for the clarifications!

[Bug tree-optimization/90905] missing -Wreturn-local-addr returning a local std::string::c_str()

2019-06-17 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90905

--- Comment #2 from Martin Sebor  ---
The separate enhancement is pr90906.

[Bug tree-optimization/90905] missing -Wreturn-local-addr returning a local std::string::c_str()

2019-06-17 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90905

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
An analogous test case with std::vector or other containers is, of course, not
diagnosed at all because the warning only looks for locally declared variables
and not pointers to allocated memory that has been freed.  That's a separate
enhancement (pr90905).

[Bug tree-optimization/90906] New: diagnose returning pointers to freed memory

2019-06-17 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90906

Bug ID: 90906
   Summary: diagnose returning pointers to freed memory
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC doesn't diagnose returning a freed pointer as in the function below:

  void* f (void *p)
  {
__builtin_free (p);
// ...
return p;
  }

It could, by performing an analysis similar to -Wreturn-local-addr.  The
detection would make it possible to find among other things bugs in C++ code
due to returning pointers into local containers, such as:

  #include 

  int* f ()
  {
std::vector v (3, 5);
return v.data ();
  }

[Bug c++/61738] ICE using template template parameters and template aliases

2019-06-17 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61738

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #1 from Marek Polacek  ---
Fixed by r261709.  I've recently added another test for this, so not adding
this one.

[Bug tree-optimization/90905] New: missing -Wreturn-local-addr returning a local std::string::c_str()

2019-06-17 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90905

Bug ID: 90905
   Summary: missing -Wreturn-local-addr returning a local
std::string::c_str()
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Compiling function f0 below on its own triggers a -Wreturn-local-addr for the
return statement as one would expect.  But compiling the equivalent f1 fails to
trigger the same warning.  Worse yet, compiling both functions in the samne
translatin unit suppresses the warning for f0.

#include 

#if F0

const char s[] = "abc";

const char* f0 ()
{
  std::string str (s);
  return str.c_str ();
}

#endif

#if F1

const char *p = "def";

const char* f1 ()
{
  std::string str (p);
  return str.c_str ();
}

#endif

[Bug target/87281] qsort checking ICE in ia64_reorg building libgo

2019-06-17 Thread jason.duerstock at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87281

--- Comment #10 from Jason Duerstock  ---
(I assume I don't need to run build-libraries again...)

$ ~/glibc/scripts/build-many-glibcs.py --replace-sources bmg checkout
gcc-vcs-mainline
configure.ac:80: installing 'build-aux/compile'
configure.ac:46: installing 'build-aux/config.guess'
configure.ac:46: installing 'build-aux/config.sub'
configure.ac:26: installing 'build-aux/install-sh'
configure.ac:26: installing 'build-aux/missing'
Makefile.am: installing './INSTALL'
Makefile.am: installing 'build-aux/depcomp'
Makefile.am:32: installing 'build-aux/mdate-sh'
doc/Makefrag.am:106: warning: user target '$(srcdir)/doc/version.texi' defined
here ...
Makefile.am:155:   'doc/Makefrag.am' included from here
/usr/share/automake-1.16/am/texi-vers.am: ... overrides Automake target
'$(srcdir)/doc/version.texi' defined here
Makefile.am:32: installing 'build-aux/texinfo.tex'
parallel-tests: installing 'build-aux/test-driver'
configure.ac:25: installing 'build-aux/compile'
configure.ac:9: installing 'build-aux/config.guess'
configure.ac:9: installing 'build-aux/config.sub'
configure.ac:14: installing 'build-aux/install-sh'
configure.ac:14: installing 'build-aux/missing'
Makefile.am: installing './INSTALL'
Makefile.am: installing 'build-aux/depcomp'
configure.ac: installing 'build-aux/ylwrap'
parallel-tests: installing 'build-aux/test-driver'

$ ~/glibc/scripts/build-many-glibcs.py --full-gcc bmg compilers ia64-linux-gnu
PASS: compilers-ia64-linux-gnu check-host-libraries
PASS: compilers-ia64-linux-gnu binutils rm
PASS: compilers-ia64-linux-gnu binutils mkdir
PASS: compilers-ia64-linux-gnu binutils configure
PASS: compilers-ia64-linux-gnu binutils build
PASS: compilers-ia64-linux-gnu binutils install
PASS: compilers-ia64-linux-gnu binutils cleanup
PASS: compilers-ia64-linux-gnu linux rm
PASS: compilers-ia64-linux-gnu linux mkdir
PASS: compilers-ia64-linux-gnu linux install-headers
PASS: compilers-ia64-linux-gnu linux cleanup
PASS: compilers-ia64-linux-gnu gcc-first rm
PASS: compilers-ia64-linux-gnu gcc-first mkdir
PASS: compilers-ia64-linux-gnu gcc-first configure
PASS: compilers-ia64-linux-gnu gcc-first build
PASS: compilers-ia64-linux-gnu gcc-first install
PASS: compilers-ia64-linux-gnu gcc-first cleanup
PASS: compilers-ia64-linux-gnu glibc ia64-linux-gnu rm
PASS: compilers-ia64-linux-gnu glibc ia64-linux-gnu mkdir
PASS: compilers-ia64-linux-gnu glibc ia64-linux-gnu configure
PASS: compilers-ia64-linux-gnu glibc ia64-linux-gnu build
PASS: compilers-ia64-linux-gnu glibc ia64-linux-gnu install
PASS: compilers-ia64-linux-gnu glibc ia64-linux-gnu mkdir-lib
PASS: compilers-ia64-linux-gnu glibc ia64-linux-gnu cleanup
PASS: compilers-ia64-linux-gnu gcc rm
PASS: compilers-ia64-linux-gnu gcc mkdir
PASS: compilers-ia64-linux-gnu gcc configure
PASS: compilers-ia64-linux-gnu gcc build
PASS: compilers-ia64-linux-gnu gcc install
PASS: compilers-ia64-linux-gnu gcc cleanup
PASS: compilers-ia64-linux-gnu done
$

[Bug target/87281] qsort checking ICE in ia64_reorg building libgo

2019-06-17 Thread joseph at codesourcery dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87281

--- Comment #9 from joseph at codesourcery dot com  ---
When using "build-many-glibcs  checkout" to check out the source 
tree, you need to specify "gcc-vcs-mainline" after "checkout" to get GCC 
trunk sources checked out instead of the default of GCC 9 branch.

[Bug c++/61490] accepts-invalid: qualified-name in friend function definition

2019-06-17 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61490

Marek Polacek  changed:

   What|Removed |Added

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

[Bug fortran/90903] Implement runtime checks for bit manipulation intrinsics

2019-06-17 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90903

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-06-17
 Ever confirmed|0   |1

[Bug other/90904] New: vec assignment and copying undefined

2019-06-17 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90904

Bug ID: 90904
   Summary: vec assignment and copying undefined
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Compiling the following function succeeds but running the code crashes with the
stack trace below.  The problem is that even though it owns (allocates and
deallocates) its own memory in its ctor and dtor, the auto_vec class fails to
define the copy assignment operator (or copy constructor) to allocate memory
for the copy.  As a result, a compiler-generated copy assignment and copy ctor
are provided which simply copy the pointer to memory owned by the original to
the other object.  That results in a double free upon destruction of the
original.

  void f (void)
  {
auto_vec a;
a.safe_push (1);
auto_vec b;
b = a;
if (a.length () != b.length ())
  abort ();
  }

free(): double free detected in tcache 2
...
0x111471e crash_signal
gcc/toplev.c:326
0x97fd04 void va_heap::release(vec*&)
gcc/vec.h:311
0x97fb77 vec::release()
gcc/vec.h:1690
0x9fd84f auto_vec::~auto_vec()
gcc/vec.h:1463


The vec base class provides a copy() member function to copy the data that one
would hope to be able to use to copy auto_vec instances.  Regrettably, the copy
function returns a vec class so it cannot be used to copy the derived auto_vec.
 The vec base too fails to provide a user-defined copy ctor so it's also unsafe
to copy using the expected syntax.

[Bug ipa/90889] snapshot 20190614 fails to build Ada with LTO

2019-06-17 Thread jamborm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90889

--- Comment #11 from Martin Jambor  ---
OK, I found the edge which is now ignored but should not be, it was one level
above what I originally tried.  I have proposed a fix in:

https://gcc.gnu.org/ml/gcc-patches/2019-06/msg00986.html

[Bug fortran/90903] Implement runtime checks for bit manipulation intrinsics

2019-06-17 Thread anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90903

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||diagnostic
   Priority|P3  |P5
   Severity|normal  |enhancement

[Bug fortran/90903] New: Implement runtime checks for bit manipulation intrinsics

2019-06-17 Thread anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90903

Bug ID: 90903
   Summary: Implement runtime checks for bit manipulation
intrinsics
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anlauf at gcc dot gnu.org
  Target Milestone: ---

The Fortran standard imposes constraints on some arguments (e.g. SHIFT) on the
bit manipulation intrinsics (e.g. SHIFTR/SHIFTL/SHIFTA, ISHFT, IBSET/IBCLR).
There are compile-time checks, but so far no runtime checks.

It would be useful to have runtime check to catch undefined behavior.

This requires a new option, e.g. -fcheck=bits (analogous to what NAG provides).

[Bug driver/90902] New: collect2 does not propagate gcc -wrapper far enough to wrap ld

2019-06-17 Thread fche at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90902

Bug ID: 90902
   Summary: collect2 does not propagate gcc -wrapper far enough to
wrap ld
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fche at redhat dot com
  Target Milestone: ---

We have a situation where we need to debug an ld run, which is invoked via
g++/collect2.  g++ -wrapper gdb,--args works well enough to spawn a gdb for the
collect2 process, but not well enough that the collect2 fork/exec of ld is also
wrapped.  Please consider adding this capability.

[Bug c++/90858] Pointer to member is treated as non-constexpr

2019-06-17 Thread m.cencora at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90858

--- Comment #1 from m.cencora at gmail dot com ---
Here is another repoducer, that does not use std::variant:

#include 
#include 
#include 

struct Base
{
int a;

template 
static constexpr auto for_all_data_members(F&& func)
{
return func(::a); 
}
};

struct MyStruct
{
int a;
int b;
Base c;

template 
static constexpr auto for_all_data_members(F&& func)
{
return func(
::a
  , ::b
#ifndef FIX_COMPILATION
  , ::c
#endif
); 
}
};

constexpr void serialize(int val)
{}

template 
struct SerializeAll
{
const Class & object;

template 
constexpr void operator()(Args ...args)
{
(serialize(object.*args), ...);
}
};

template 
constexpr void serialize(const T& obj)
{
return T::for_all_data_members(SerializeAll{obj});
}

constexpr bool test(const MyStruct& v)
{
serialize(v);
return true;
}

static_assert(test(MyStruct{}), "");

[Bug target/82182] m68k slow code: u16/u8 division calls divsi3

2019-06-17 Thread jason.duerstock at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82182

Jason Duerstock  changed:

   What|Removed |Added

 CC||jason.duerstock at gmail dot 
com

--- Comment #1 from Jason Duerstock  ---
Does this still happen for you in 7.4.0?

[Bug c++/60680] unqualified-id expected, gcc fails to diagnose and accepts invalid

2019-06-17 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60680

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
This is now rejected:

60680.C: In function ‘int main()’:
60680.C:2:3: error: expected primary-expression before ‘int’
2 |   int(*) = 0;
  |   ^~~

[Bug target/62055] missed optimization: recognize fnabs (FP negative absolute value) (x86-64)

2019-06-17 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62055

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #7 from Uroš Bizjak  ---
Fixed.

[Bug target/62055] missed optimization: recognize fnabs (FP negative absolute value) (x86-64)

2019-06-17 Thread uros at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62055

--- Comment #6 from uros at gcc dot gnu.org ---
Author: uros
Date: Mon Jun 17 18:40:22 2019
New Revision: 272396

URL: https://gcc.gnu.org/viewcvs?rev=272396=gcc=rev
Log:
PR target/62055
* config/i386/i386.md (*nabstf2_1): New insn pattern.
(*nabs2_1): Ditto.
(nabs sse-reg splitter): New splitter.
* config/i386/sse.md (*nabs2): New insn_and_split pattern.

testsuite/ChangeLog:

PR target/62055
* gcc.target/i386/fnabs.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/fnabs.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog

[Bug c++/86521] [8 Regression] GCC 8 selects incorrect overload of ref-qualified conversion operator template

2019-06-17 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86521

Marek Polacek  changed:

   What|Removed |Added

 CC||h2+bugs at fsfe dot org

--- Comment #11 from Marek Polacek  ---
*** Bug 90897 has been marked as a duplicate of this bug. ***

[Bug c++/90897] user defined conversion operators ambiguous in GCC8, but not GCC7 and GCC9

2019-06-17 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90897

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Marek Polacek  ---
Fixed by r269667.  So a dup of 86521.

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

[Bug c++/60352] [C++11] Bogus "error: conflicting declaration 'auto i'"

2019-06-17 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60352

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-06-17
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Marek Polacek  ---
Confirmed.

[Bug c++/83820] No diagnostic issued for noreturn attribute specifier with an argument list

2019-06-17 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83820

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
Fixed for GCC 10.

[Bug c++/83820] No diagnostic issued for noreturn attribute specifier with an argument list

2019-06-17 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83820

--- Comment #4 from Marek Polacek  ---
Author: mpolacek
Date: Mon Jun 17 18:26:07 2019
New Revision: 272395

URL: https://gcc.gnu.org/viewcvs?rev=272395=gcc=rev
Log:
PR c++/83820 - excessive attribute arguments not detected.
* parser.c (cp_parser_std_attribute): Detect excessive arguments.

* g++.dg/cpp0x/gen-attrs-67.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/gen-attrs-67.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/90885] GCC should warn about 2^16 and 2^32 and 2^64

2019-06-17 Thread dominik.b.czarnota+bugzilla at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90885

Dominik Czarnota  changed:

   What|Removed |Added

 CC||dominik.b.czarnota+bugzilla
   ||@gmail.com

--- Comment #19 from Dominik Czarnota  ---
Also what if:

1. Someone does it through DEFINEs as in:
```
#define COMPUTING_BASE 2
#define BITS 32
// and later use
COMPUTING_BASE ^ (BITS-1)
```
I guess we will warn.

2. Someone does it through constexpr variables in C++, as in:
```
constexpr int COMPUTING_BASE = 2;
constexpr int BITS = 32;
// and later use
COMPUTING_BASE ^ (BITS-1)
```
This probably happens on a different level than the above, so we probably won't
warn as it doesn't use integer literals?

3. Someone *really wants it*?
Maybe there should be a way to inform the compiler, e.g. via a comment to
suppress the warning for a given line? For example:
```
printf("%d\n", 2^32 /* explicit-xor */);
```

Offtopic: if you care about adding more warnings in tragic situations, you
might also want to look at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88000
;)

[Bug c++/90885] GCC should warn about 2^16 and 2^32 and 2^64

2019-06-17 Thread david.bolvansky at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90885

Dávid Bolvanský  changed:

   What|Removed |Added

 CC||david.bolvansky at gmail dot 
com

--- Comment #18 from Dávid Bolvanský  ---
-Wxor-as-pow ? :)

[Bug c++/90885] GCC should warn about 2^16 and 2^32 and 2^64

2019-06-17 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90885

--- Comment #17 from Marc Glisse  ---
(In reply to Jonathan Wakely from comment #12)
> What about -Wxor-used-as-pow ?

-Wxor-power (or -Wpower-xor)?

[Bug debug/90901] New: Debug information broken when compiled with gdwarf-split

2019-06-17 Thread rajpal.gusain at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90901

Bug ID: 90901
   Summary: Debug information broken when compiled with
gdwarf-split
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rajpal.gusain at gmail dot com
  Target Milestone: ---

% g++ --version
g++ (GCC) 8.3.0

% gdb --version
GNU gdb (GDB) 8.3

% readelf --version
GNU readelf (GNU Binutils) 2.32

I couldn't reproduce this issue on a small test case which seems to work fine.
When I build executable with gdwarf-split option, it looks like debug
information is broken. And when I do the same but with Clang, I don't see any
issue with debug information.


Issue :
When I loaded my binary in gdb, it failed to put breakpoint with error message
like this

this=.dwo]>

I thought that I should check if there is any problem in debug information, and
I tried to read it using readelf and I got errors there too (pasted only few,
there are many more which seem to be similar)

readelf: Error:  Unknown macro opcode 8b seen
readelf: Error:  Unknown macro opcode c2 seen
readelf: Error:  Unknown macro opcode ec seen
readelf: Error:  Unknown macro opcode c7 seen
readelf: Error:  Unknown macro opcode 60 seen
readelf: Error:  Unknown macro opcode 5f seen
readelf: Error:  Unknown macro opcode ba seen
readelf: Error: DW_MACRO_start_file used, but no .debug_line offset provided.
readelf: Error:  Unknown macro opcode 8d seen
readelf: Error:  Unknown macro opcode 9e seen
readelf: Error:  Unknown macro opcode b6 seen
readelf: Error:  Unknown macro opcode e3 seen
readelf: Error:  Unknown macro opcode 92 seen
readelf: Error:  Unknown macro opcode cd seen
readelf: Error:  Unknown macro opcode 8d seen
readelf: Error:  Unknown macro opcode 2e seen
readelf: Error:  Unknown macro opcode bc seen
readelf: Error:  Unknown macro opcode 51 seen
readelf: Error: .debug_macro section not zero terminated
readelf: Error:  Unknown macro opcode c7 seen
readelf: Error:  Unknown macro opcode f9 seen
readelf: Error:  Unknown macro opcode e3 seen
readelf: Error:  Unknown macro opcode 2b seen
readelf: Error:  Unknown macro opcode f9 seen
readelf: Error: .debug_macro section not zero terminated

I'm not sure if information is good enough to nail down the issue. I'm happy to
provide more information if it helps fix this issue quickly.

[Bug middle-end/90898] [8/9/10 Regression] ICE in insert_clobber_before_stack_restore, at tree-ssa-ccp.c:2112

2019-06-17 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90898

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |middle-end

--- Comment #1 from Andrew Pinski  ---
I wish __builtin_stack_save was never exposed to the user.  If it was being
created now, it would have been an internal function instead of a builtin.

[Bug c/90900] New: [8/9/10 Regression] ICE in copy_rtx, at rtl.c:376

2019-06-17 Thread gs...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90900

Bug ID: 90900
   Summary: [8/9/10 Regression] ICE in copy_rtx, at rtl.c:376
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with gcc-8 (before 20180525) :


$ cat z1.c
void f (int a)
{
  void *x = &
  #pragma omp parallel
  if (a)
{ lab: __builtin_unreachable(); }
  x;
}


$ gcc-7 -c z1.c -fopenmp -O2 -g
$
$ gcc-10-20190609 -c z1.c -fopenmp -O2
$
$ gcc-10-20190609 -c z1.c -fopenmp -O2 -g
during RTL pass: expand
z1.c: In function 'f':
z1.c:1:6: internal compiler error: in copy_rtx, at rtl.c:376
1 | void f (int a)
  |  ^
0xa2661a copy_rtx(rtx_def*)
../../gcc/rtl.c:376
0x6cb65d expand_debug_expr
../../gcc/cfgexpand.c:4403
0x6cb848 expand_debug_expr
../../gcc/cfgexpand.c:4980
0x6d537a expand_debug_locations
../../gcc/cfgexpand.c:5455
0x6d537a execute
../../gcc/cfgexpand.c:6525

[Bug c/90899] New: [8/9/10 Regression] ICE in add_to_same_comdat_group, at symtab.c:459

2019-06-17 Thread gs...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90899

Bug ID: 90899
   Summary: [8/9/10 Regression] ICE in add_to_same_comdat_group,
at symtab.c:459
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with gcc-8 (before 20180525) :


$ cat z1.c
__attribute__ ((target_clones ("default", "arch=slm")))
static int f () { return 0; }
__attribute__ ((alias ("f")))
__typeof (f) g;


$ gcc-7 -c z1.c
$
$ gcc-10-20190616 -c z1.c
during IPA pass: targetclone
z1.c:4:1: internal compiler error: in add_to_same_comdat_group, at symtab.c:459
4 | __typeof (f) g;
  | ^~~~
0x6f12ac symtab_node::add_to_same_comdat_group(symtab_node*)
../../gcc/symtab.c:459
0x12446ee create_dispatcher_calls
../../gcc/multiple_target.c:161
0x12446ee ipa_target_clone
../../gcc/multiple_target.c:523
0x12446ee execute
../../gcc/multiple_target.c:555

[Bug c/90898] New: [8/9/10 Regression] ICE in insert_clobber_before_stack_restore, at tree-ssa-ccp.c:2112

2019-06-17 Thread gs...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90898

Bug ID: 90898
   Summary: [8/9/10 Regression] ICE in
insert_clobber_before_stack_restore, at
tree-ssa-ccp.c:2112
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to gcc-4.7, gcc-4.6 compiles it :
(gcc-10 compiles with -O0, and of course with int*)


$ cat z1.c
void f (int p)
{
  p = __builtin_stack_save ();
  int a[({ {} 2; })];
}


$ cat z2.c
void f (int p)
{
  p = __builtin_stack_save ();
  int a[({ void h() {} 2; })];
}


$ gcc-10-20190616 -c z1.c -O2
z1.c: In function 'f':
z1.c:3:5: warning: assignment to 'int' from 'void *' makes integer from pointer
without a cast [-Wint-conversion]
3 |   p = __builtin_stack_save ();
  | ^
during GIMPLE pass: ccp
z1.c:5:1: internal compiler error: in insert_clobber_before_stack_restore, at
tree-ssa-ccp.c:2112
5 | }
  | ^
0xd5f26d insert_clobber_before_stack_restore
../../gcc/tree-ssa-ccp.c:2112
0xd5faf1 insert_clobbers_for_var
../../gcc/tree-ssa-ccp.c:2159
0xd5faf1 ccp_folder::fold_stmt(gimple_stmt_iterator*)
../../gcc/tree-ssa-ccp.c:2312
0xdf3426 substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
../../gcc/tree-ssa-propagate.c:1082
0x14b5527 dom_walker::walk(basic_block_def*)
../../gcc/domwalk.c:312
0xdf2895 substitute_and_fold_engine::substitute_and_fold(basic_block_def*)
../../gcc/tree-ssa-propagate.c:1194
0xd56f74 ccp_finalize
../../gcc/tree-ssa-ccp.c:991
0xd56f74 do_ssa_ccp
../../gcc/tree-ssa-ccp.c:2504
0xd56f74 execute
../../gcc/tree-ssa-ccp.c:2547

[Bug lto/90889] snapshot 20190614 fails to build Ada with LTO

2019-06-17 Thread jamborm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90889

--- Comment #10 from Martin Jambor  ---
OK, this is new: The problem is that topological ordering on which
IPA-CP operates is bogus, reverting Martin's r272115 restored Ada LTO
bootstrap for me.

I however tried breakpointing in IPA-CP's ignore_edge at the one edge
I assumed would be problematic and it did not return true, so I have
to look a bit further.

[Bug libfortran/77278] Use LTO for libgfortran

2019-06-17 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278

--- Comment #29 from Thomas Koenig  ---
Created attachment 46493
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46493=edit
Patch to put all libgfortran functions into a namespace

This is something we should be doing as part of making libgfortran
LTO-compatible.  It adds all resolved library function to the libgfortran
namespace.

This does not work (i.e. causes regressions) because of functions like
pack, unpack, cshift etc where we call the same function with
different types of arguments.  We should be calling this via
gfc_array_char.  For example, here's eoshift0.c:

static void
eoshift0 (gfc_array_char * ret, const gfc_array_char * array,
  index_type shift, const char * pbound, int which, index_type size,
  const char *filler, index_type filler_len)

[...]

[Bug c++/90885] GCC should warn about 2^16 and 2^32 and 2^64

2019-06-17 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90885

--- Comment #16 from Eric Gallager  ---
I think David's original suggestion of -Wexclusive-or is the best name so far.

[Bug tree-optimization/70841] reassoc fails to handle FP division

2019-06-17 Thread clyon at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70841

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #4 from Christophe Lyon  ---
Can this be achieved in match.pd?

[Bug bootstrap/90873] [10 regression] -Wmaybe-uninitialized warning in gcc/tree-ssa-forwprop.c breaks 32-bit bootstrap

2019-06-17 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90873

--- Comment #10 from Jan Hubicka  ---
Author: hubicka
Date: Mon Jun 17 15:43:23 2019
New Revision: 272390

URL: https://gcc.gnu.org/viewcvs?rev=272390=gcc=rev
Log:
PR bootstrap/90873.
* tree-ssa-alias.c (indirect_ref_may_alias_decl_p): Fix
TMR index check.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-alias.c

[Bug tree-optimization/71026] Missing division optimizations

2019-06-17 Thread clyon at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71026

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #13 from Christophe Lyon  ---
(In reply to Wilco from comment #12)
> It looks the only case left to do is f5:
> 
> x * C <= 0.0 -> x <= 0.0 if C >= 1.0
> x * C <= 0.0 -> x < FLT_MIN/C if C < 1.0

Commit r266142 (from #c11) added this to match.pd:
 (for cmp (lt le gt ge)
  neg_cmp (gt ge lt le)
  /* Simplify (x * C1) cmp C2 -> x cmp (C2 / C1), where C1 != 0.  */
  (simplify
   (cmp (mult @0 REAL_CST@1) REAL_CST@2)
   (with
{ tree tem = const_binop (RDIV_EXPR, type, @2, @1); }
(if (tem
 && !(REAL_VALUE_ISINF (TREE_REAL_CST (tem))
 || (real_zerop (tem) && !real_zerop (@1
 (switch
  (if (real_less (, TREE_REAL_CST_PTR (@1)))
   (cmp @0 { tem; }))
  (if (real_less (TREE_REAL_CST_PTR (@1), ))
   (neg_cmp @0 { tem; })))

Doesn't || (real_zerop (tem) && !real_zerop (@1)) prevent
> x * C <= 0.0 -> x <= 0.0 if C >= 1.0
from happening?

[Bug bootstrap/90873] [10 regression] -Wmaybe-uninitialized warning in gcc/tree-ssa-forwprop.c breaks 32-bit bootstrap

2019-06-17 Thread hubicka at ucw dot cz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90873

--- Comment #9 from Jan Hubicka  ---
Hi,
I am testing rather obvious fix

* tree-ssa-alias.c (indirect_ref_may_alias_decl_p): Fix TMR check.
Index: tree-ssa-alias.c
===
--- tree-ssa-alias.c(revision 272383)
+++ tree-ssa-alias.c(working copy)
@@ -1535,7 +1535,7 @@ indirect_ref_may_alias_decl_p (tree ref1
   if (((TREE_CODE (base1) != TARGET_MEM_REF
|| (!TMR_INDEX (base1) && !TMR_INDEX2 (base1)))
&& (TREE_CODE (dbase2) != TARGET_MEM_REF
-  || (!TMR_INDEX (dbase2) && !TMR_INDEX2 (base2
+  || (!TMR_INDEX (dbase2) && !TMR_INDEX2 (dbase2
   && same_type_for_tbaa (TREE_TYPE (base1), TREE_TYPE (dbase2)) == 1
   && (TREE_CODE (TREE_TYPE (base1)) != ARRAY_TYPE
  || (TYPE_SIZE (TREE_TYPE (base1))

[Bug c++/66944] ICE on static thread_local member in class template

2019-06-17 Thread Laurent.Rineau__gcc at normalesup dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66944

--- Comment #9 from Laurent Rineau  
---
I still get the compilation error with gcc version 9.1.1.

[Bug tree-optimization/80738] dead first stmt in a=0;a=b;b=0 whatever the aliasing

2019-06-17 Thread david at doublewise dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80738

--- Comment #2 from David Stone  ---
*** Bug 90888 has been marked as a duplicate of this bug. ***

[Bug middle-end/90888] std::swap bad code gen -- alias analysis insufficient to remove dead store

2019-06-17 Thread david at doublewise dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90888

David Stone  changed:

   What|Removed |Added

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

--- Comment #3 from David Stone  ---
I agree this is a duplicate of the other bug. Closing this one.

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

[Bug c++/90897] New: user defined conversion operators ambiguous in GCC8, but not GCC7 and GCC9

2019-06-17 Thread h2+bugs at fsfe dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90897

Bug ID: 90897
   Summary: user defined conversion operators ambiguous in GCC8,
but not GCC7 and GCC9
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: h2+bugs at fsfe dot org
  Target Milestone: ---

The rather simple example below fails to build on GCC8 in C++17 mode, but
passes on GCC7, GCC9 and trunk in C++17 mode. It fails on all compilers in
C++14 mode.

Tested versions:
g++7 (FreeBSD Ports Collection) 7.4.0
g++8 (FreeBSD Ports Collection) 8.3.0
g++9 (FreeBSD Ports Collection) 9.1.0
g++10 (FreeBSD Ports Collection) 10.0.0 20190602 (experimental)

Apparently the code is correct for C++17, but GCC8 was not updated accordingly?

Thanks for your help!

struct S2
{
constexpr S2() = default;
constexpr S2(S2 const &) = default;
constexpr S2(S2 &&) = default;
constexpr S2& operator=(S2 const &) = default;
constexpr S2& operator=(S2 &&) = default;

constexpr S2 (int const &) {}
};

struct S
{
operator int()
{
return 3;
}

operator S2()
{
return S2{};
}
};

int main()
{
S2 s = static_cast(S{});
}

[Bug libstdc++/90887] [10 Regression] r272186 causes -fcompare-debug failure

2019-06-17 Thread burnus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90887

--- Comment #8 from Tobias Burnus  ---
Still debugging.

I add tons of 'printf' and the first difference which shows up is the following
call:

check_return_expr -> build_non_dependent_expr (with flag == 2) ->
fold_non_dependent_expr -> fold_non_dependent_expr_template

This call only happens with -g0 and not with -g3. (With -g0 there are 507 and
with -g3 487 calls to check_return_expr.)


However, as register_symbol-calling is not called, this is not the culprit for
the symbol_order difference.


The register_symbol-calling change for std::_PCC<, _T1,
_T2>::_ConstructiblePair()

goes via:

#0  symtab_node::register_symbol (this=0x7fffeba9c168) at
../../gcc/symtab.c:379
#1  0x00ba17b9 in cgraph_node::create(tree_node*) () at
../../gcc/cgraph.c:523
#2  0x00ba15e1 in cgraph_node::get_create(tree_node*) () at
../../gcc/cgraph.c:545
#3  0x00af8611 in c_genericize(tree_node*) () at
../../gcc/c-family/c-gimplify.c:152
#4  0x00916ea8 in cp_genericize(tree_node*) () at
../../gcc/cp/cp-gimplify.c:1809
#5  0x00952d82 in finish_function(bool) () at ../../gcc/cp/decl.c:16277
#6  0x00a259a4 in instantiate_decl(tree_node*, bool, bool) () at
../../gcc/cp/pt.c:24810
#7  0x008f8d21 in instantiate_cx_fn_r(tree_node**, int*, void*) () at
../../gcc/cp/constexpr.c:5301
#8  0x01279e55 in walk_tree_1(tree_node**, tree_node* (*)(tree_node**,
int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*,
tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) () at ../../gcc/tree.c:12151
#9  0x0127a736 in walk_tree_1(tree_node**, tree_node* (*)(tree_node**,
int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*,
tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) () at ../../gcc/tree.h:3698
#10 0x0127d102 in walk_tree_without_duplicates_1
(tp=tp@entry=0x7fffbc18, func=func@entry=0x8f8af0
, data=data@entry=0x0,
lh=0xa7c8f0  >*)>) at ../../gcc/tree.c:12502
#11 0x00903a03 in instantiate_constexpr_fns (t=) at
../../gcc/cp/constexpr.c:5325
#12 cxx_eval_outermost_constant_expr(tree_node*, bool, bool, bool, tree_node*)
() at ../../gcc/cp/constexpr.c:5397
#13 0x00907f2a in fold_non_dependent_expr_template(tree_node*, int,
bool) () at ../../gcc/cp/constexpr.c:5685
#14 0x0090804f in fold_non_dependent_expr (t=t@entry=0x7fffebaca810,
complain=complain@entry=0,
manifestly_const_eval=manifestly_const_eval@entry=false) at
../../gcc/cp/constexpr.c:5731
#15 0x00a0616e in build_non_dependent_expr(tree_node*) () at
../../gcc/cp/pt.c:26665
#16 0x00a927d2 in build_x_binary_op(op_location_t const&, tree_code,
tree_node*, tree_code, tree_node*, tree_code, tree_node**, int) () at
../../gcc/cp/typeck.c:4188
#17 0x00a19937 in tsubst_copy_and_build(tree_node*, tree_node*, int,
tree_node*, bool, bool) [clone .part.0] () at ../../gcc/tree.h:3698
#18 0x00a26358 in tsubst_copy_and_build
(integral_constant_expression_p=true, function_p=false, in_decl=0x0,
complain=0, args=, t=0x7fffeba65488) at ../../gcc/cp/pt.c:18261
#19 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) [clone .part.0]
() at ../../gcc/cp/pt.c:17937
#20 0x00a2c1d4 in tsubst_expr (integral_constant_expression_p=true,
in_decl=, complain=, args=,
t=) at ../../gcc/cp/pt.c:17029
#21 tsubst_template_arg (in_decl=, complain=,
args=, t=) at ../../gcc/cp/pt.c:11554
#22 tsubst_template_arg (t=, args=,
complain=, in_decl=) at ../../gcc/cp/pt.c:11542
#23 0x00a33843 in tsubst_template_args(tree_node*, tree_node*, int,
tree_node*) () at ../../gcc/cp/pt.c:12590
#24 0x00a38067 in tsubst_aggr_type(tree_node*, tree_node*, int,
tree_node*, int) () at ../../gcc/tree.h:3312
#25 0x00a1fa1e in tsubst(tree_node*, tree_node*, int, tree_node*) () at
../../gcc/cp/pt.c:15032
#26 0x00a46632 in type_unification_real(tree_node*, tree_node*,
tree_node*, tree_node* const*, unsigned int, int, unification_kind_t,
vec**, bool) () at
../../gcc/tree.h:3312
#27 0x00a47139 in fn_type_unification(tree_node*, tree_node*,
tree_node*, tree_node* const*, unsigned int, tree_node*, unification_kind_t,
int, conversion**, bool, bool) () at ../../gcc/tree.h:3198
#28 0x008cbd37 in add_template_candidate_real(z_candidate**,
tree_node*, tree_node*, tree_node*, tree_node*, vec const*, tree_node*, tree_node*, tree_node*, int, tree_node*,
unification_kind_t, int) () at ../../gcc/cp/call.c:3318
#29 0x008cc6bd in add_template_candidate (complain=0,
strict=DEDUCE_CALL, flags=1, conversion_path=0x7fffebd58208,
access_path=0x7fffebd58208, return_type=0x0, arglist=,
first_arg=,
explicit_targs=0x0, ctype=0x7fffebd9e0a8, tmpl=,
candidates=0x7fffc478) at ../../gcc/cp/call.c:5727
#30 add_candidates(tree_node*, tree_node*, vec
const*, tree_node*, tree_node*, bool, tree_node*, tree_node*, int,
z_candidate**, int) [clone .part.0] () at 

[Bug bootstrap/90873] [10 regression] -Wmaybe-uninitialized warning in gcc/tree-ssa-forwprop.c breaks 32-bit bootstrap

2019-06-17 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90873

--- Comment #8 from H.J. Lu  ---
(In reply to Christophe Lyon from comment #7)
> git bisect tells me that this commit (r272273) causes a regression on
> arm-linux-gnueabihf
> 
> FAIL: ext/random/normal_mv_distribution/operators/serialize.cc (test for
> excess errors)
> 
> 
> /libstdc++-v3/testsuite/ext/random/normal_mv_distribution/operators/
> serialize.cc:38: internal compiler error: tree check: expected
> target_mem_ref, have var_decl in indirect_ref_may_alias_decl_p, at
> tree-ssa-alias.c:1399
> 0x5d5c59 tree_check_failed(tree_node const*, char const*, int, char const*,
> ...)
> /gcc/tree.c:9899
> 0xf369f8 tree_check(tree_node*, char const*, int, char const*, tree_code)
> /gcc/tree.h:3197
> 0xf369f8 indirect_ref_may_alias_decl_p
> /gcc/tree-ssa-alias.c:1399
> 0xf36d85 refs_may_alias_p_2
> /gcc/tree-ssa-alias.c:1689
> 0xf36d85 refs_may_alias_p_1(ao_ref*, ao_ref*, bool)
> /gcc/tree-ssa-alias.c:1710
> 0x923c38 rtx_refs_may_alias_p
> /gcc/alias.c:368
> 0x928cb6 true_dependence_1
> /gcc/alias.c:2976
> 0xb1ca07 compute_transp(rtx_def const*, int, simple_bitmap_def**,
> bitmap_head*, bitmap_head*, vec*)
> /gcc/gcse-common.c:175
> 0xb16e9a compute_local_properties
> /gcc/gcse.c:699
> 0xb1a8e4 compute_pre_data
> /gcc/gcse.c:1866
> 0xb1a8e4 one_pre_gcse_pass
> /gcc/gcse.c:2616
> 0xb1a8e4 execute_rtl_pre
> /gcc/gcse.c:4024
> 0xb1a8e4 execute
> /gcc/gcse.c:4068
> Please submit a full bug report,

This may be related to PR 90896.

[Bug libstdc++/90281] utf-8 encoded std::filesystem::path can not be converted to utf-16.

2019-06-17 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90281

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Mon Jun 17 15:03:46 2019
New Revision: 272389

URL: https://gcc.gnu.org/viewcvs?rev=272389=gcc=rev
Log:
PR libstdc++/90281 Fix string conversions for filesystem::path

Fix several bugs in the encoding conversions for filesystem::path that
prevent conversion of Unicode characters outside the Basic Multilingual
Plane, and prevent returning basic_string specializations with
alternative allocator types.

The std::codecvt_utf8 class template is not suitable for UTF-16
conversions because it uses UCS-2 instead. For conversions between UTF-8
and UTF-16 either std::codecvt or
codecvt_utf8_utf16 must be used.

The __str_codecvt_in and __str_codecvt_out utilities do not
return false on a partial conversion (e.g. for invalid or incomplete
Unicode input). Add new helpers that treat partial conversions as
errors, and use them for all filesystem::path conversions.

PR libstdc++/90281 Fix string conversions for filesystem::path
* include/bits/fs_path.h (u8path) [_GLIBCXX_FILESYSTEM_IS_WINDOWS]:
Use codecvt_utf8_utf16 instead of codecvt_utf8. Use
__str_codecvt_in_all to fail for partial conversions and throw on
error.
[!_GLIBCXX_FILESYSTEM_IS_WINDOWS && _GLIBCXX_USE_CHAR8_T]
(path::_Cvt): Add explicit specialization.
[_GLIBCXX_FILESYSTEM_IS_WINDOWS] (path::_Cvt::_S_wconvert): Remove
overloads.
[_GLIBCXX_FILESYSTEM_IS_WINDOWS] (path::_Cvt::_S_convert): Use
if-constexpr instead of dispatching to _S_wconvert. Use codecvt
instead of codecvt_utf8. Use __str_codecvt_in_all and
__str_codecvt_out_all.
[!_GLIBCXX_FILESYSTEM_IS_WINDOWS] (path::_Cvt::_S_convert): Use
codecvt instead of codecvt_utf8. Use __str_codecvt_out_all.
(path::_S_str_convert) [_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Use
codecvt_utf8_utf16 instead of codecvt_utf8. Construct return values
with allocator. Use __str_codecvt_out_all. Fallthrough to POSIX code
after converting to UTF-8.
(path::_S_str_convert): Use codecvt instead of codecvt_utf8. Use
__str_codecvt_in_all.
(path::string): Fix initialization of string types with different
allocators.
(path::u8string) [_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Use
codecvt_utf8_utf16 instead of codecvt_utf8. Use __str_codecvt_out_all.
* include/bits/locale_conv.h (__do_str_codecvt): Reorder static and
runtime conditions.
(__str_codecvt_out_all, __str_codecvt_in_all): New functions that
return false for partial conversions.
* include/experimental/bits/fs_path.h (u8path):
[_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Implement correctly for mingw.
[_GLIBCXX_FILESYSTEM_IS_WINDOWS] (path::_Cvt::_S_wconvert): Add
missing handling for char8_t. Use codecvt and codecvt_utf8_utf16
instead of codecvt_utf8. Use __str_codecvt_in_all and
__str_codecvt_out_all.
[!_GLIBCXX_FILESYSTEM_IS_WINDOWS] (path::_Cvt::_S_convert): Use
codecvt instead of codecvt_utf8. Use __str_codecvt_out_all.
(path::string) [_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Use
codecvt_utf8_utf16 instead of codecvt_utf8. Construct return values
with allocator. Use __str_codecvt_out_all and __str_codecvt_in_all.
(path::string) [!_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Use
__str_codecvt_in_all.
(path::u8string) [_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Use
codecvt_utf8_utf16 instead of codecvt_utf8. Use __str_codecvt_out_all.
* src/c++17/fs_path.cc (path::_S_convert_loc): Use
__str_codecvt_in_all.
* src/filesystem/path.cc (path::_S_convert_loc): Likewise.
* testsuite/27_io/filesystem/path/construct/90281.cc: New test.
* testsuite/27_io/filesystem/path/factory/u8path.cc: New test.
* testsuite/27_io/filesystem/path/native/string.cc: Test with empty
strings and with Unicode characters outside the basic multilingual
plane.
* testsuite/27_io/filesystem/path/native/alloc.cc: New test.
* testsuite/experimental/filesystem/path/construct/90281.cc: New test.
* testsuite/experimental/filesystem/path/factory/u8path.cc: New test.
* testsuite/experimental/filesystem/path/native/alloc.cc: New test.
* testsuite/experimental/filesystem/path/native/string.cc: Test with
empty strings and with Unicode characters outside the basic
multilingual plane.

Added:
   
branches/gcc-9-branch/libstdc++-v3/testsuite/27_io/filesystem/path/construct/90281.cc
branches/gcc-9-branch/libstdc++-v3/testsuite/27_io/filesystem/path/factory/
   
branches/gcc-9-branch/libstdc++-v3/testsuite/27_io/filesystem/path/factory/u8path.cc
  - copied, changed from r272374,
branches/gcc-9-branch/libstdc++-v3/testsuite/27_io/filesystem/path/native/string.cc
   

[Bug middle-end/90896] New: [10 Regression] internal compiler error indirect_ref_may_alias_decl_p

2019-06-17 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90896

Bug ID: 90896
   Summary: [10 Regression] internal compiler error
indirect_ref_may_alias_decl_p
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---
Target: i686

On i686, r272370 failed to build 403.gcc in SPEC CPU 2006 with LTO:

gcc -m32  -O3 -funroll-loops -msse2 -mfpmath=sse -ffast-math -fwhole-program
-flto=jobserver -fuse-linker-plugin  alloca.o asprintf.o vasprintf.o
c-parse.o c-lang.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o
c-convert.o c-aux-info.o c-common.o c-format.o c-semantics.o c-objc-common.o
main.o cpplib.o cpplex.o cppmacro.o cppexp.o cppfiles.o cpphash.o cpperror.o
cppinit.o cppdefault.o line-map.o mkdeps.o prefix.o version.o mbchar.o alias.o
bb-reorder.o bitmap.o builtins.o caller-save.o calls.o cfg.o cfganal.o
cfgbuild.o cfgcleanup.o cfglayout.o cfgloop.o cfgrtl.o combine.o conflict.o
convert.o cse.o cselib.o dbxout.o debug.o dependence.o df.o diagnostic.o
doloop.o dominance.o dwarf2asm.o dwarf2out.o dwarfout.o emit-rtl.o except.o
explow.o expmed.o expr.o final.o flow.o fold-const.o function.o gcse.o genrtl.o
ggc-common.o global.o graph.o haifa-sched.o hash.o hashtable.o hooks.o ifcvt.o
insn-attrtab.o insn-emit.o insn-extract.o insn-opinit.o insn-output.o
insn-peep.o insn-recog.o integrate.o intl.o jump.o langhooks.o lcm.o lists.o
local-alloc.o loop.o obstack.o optabs.o params.o predict.o print-rtl.o
print-tree.o profile.o real.o recog.o reg-stack.o regclass.o regmove.o
regrename.o reload.o reload1.o reorg.o resource.o rtl.o rtlanal.o rtl-error.o
sbitmap.o sched-deps.o sched-ebb.o sched-rgn.o sched-vis.o sdbout.o sibcall.o
simplify-rtx.o ssa.o ssa-ccp.o ssa-dce.o stmt.o stor-layout.o stringpool.o
timevar.o toplev.o tree.o tree-dump.o tree-inline.o unroll.o varasm.o varray.o
vmsdbgout.o xcoffout.o ggc-page.o i386.o xmalloc.o xexit.o hashtab.o
safe-ctype.o splay-tree.o xstrdup.o md5.o fibheap.o xstrerror.o concat.o
partition.o hex.o lbasename.o getpwd.o ucbqsort.o -lm-o gcc
...
during RTL pass: rtl pre
reload.c: In function 'find_reloads.constprop':
reload.c:4285:1: internal compiler error: tree check: expected target_mem_ref,
have var_decl in indirect_ref_may_alias_decl_p, at tree-ssa-alias.c:1476
 4285 | }
  | ^
0x6dcbd7 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../src-trunk/gcc/tree.c:9897
0x69aa48 tree_check(tree_node*, char const*, int, char const*, tree_code)
../../src-trunk/gcc/tree.h:3197
0x69aa48 indirect_ref_may_alias_decl_p
../../src-trunk/gcc/tree-ssa-alias.c:1476
0xd6281d refs_may_alias_p_2
../../src-trunk/gcc/tree-ssa-alias.c:1758
0xd6281d refs_may_alias_p_1(ao_ref*, ao_ref*, bool)
../../src-trunk/gcc/tree-ssa-alias.c:1787
0x7e6ea8 rtx_refs_may_alias_p
../../src-trunk/gcc/alias.c:365
0x7eacfb true_dependence_1
../../src-trunk/gcc/alias.c:2976
0x9ac43a compute_transp(rtx_def const*, int, simple_bitmap_def**, bitmap_head*,
bitmap_head*, vec*)
../../src-trunk/gcc/gcse-common.c:175
0x9a6c10 compute_local_properties
../../src-trunk/gcc/gcse.c:696
0x9aa5d0 compute_pre_data
../../src-trunk/gcc/gcse.c:1866
0x9aa5d0 one_pre_gcse_pass
../../src-trunk/gcc/gcse.c:2616
0x9aa5d0 execute_rtl_pre
../../src-trunk/gcc/gcse.c:4024
0x9aa5d0 execute
../../src-trunk/gcc/gcse.c:4068
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[4]: *** [/tmp/ccytEa9c.mk:17: /tmp/gcc.I7fAJf.ltrans5.ltrans.o] Error 1
make[4]: *** Waiting for unfinished jobs
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.

The same thing happened with 176.gcc in SPEC CPU 2000.

[Bug libstdc++/90281] utf-8 encoded std::filesystem::path can not be converted to utf-16.

2019-06-17 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90281

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Mon Jun 17 14:19:04 2019
New Revision: 272385

URL: https://gcc.gnu.org/viewcvs?rev=272385=gcc=rev
Log:
PR libstdc++/90281 Fix string conversions for filesystem::path

Fix several bugs in the encoding conversions for filesystem::path that
prevent conversion of Unicode characters outside the Basic Multilingual
Plane, and prevent returning basic_string specializations with
alternative allocator types.

The std::codecvt_utf8 class template is not suitable for UTF-16
conversions because it uses UCS-2 instead. For conversions between UTF-8
and UTF-16 either std::codecvt or
codecvt_utf8_utf16 must be used.

The __str_codecvt_in and __str_codecvt_out utilities do not
return false on a partial conversion (e.g. for invalid or incomplete
Unicode input). Add new helpers that treat partial conversions as
errors, and use them for all filesystem::path conversions.

PR libstdc++/90281 Fix string conversions for filesystem::path
* include/bits/fs_path.h (u8path) [_GLIBCXX_FILESYSTEM_IS_WINDOWS]:
Use codecvt_utf8_utf16 instead of codecvt_utf8. Use
__str_codecvt_in_all to fail for partial conversions and throw on
error.
[!_GLIBCXX_FILESYSTEM_IS_WINDOWS && _GLIBCXX_USE_CHAR8_T]
(path::_Cvt): Add explicit specialization.
[_GLIBCXX_FILESYSTEM_IS_WINDOWS] (path::_Cvt::_S_wconvert): Remove
overloads.
[_GLIBCXX_FILESYSTEM_IS_WINDOWS] (path::_Cvt::_S_convert): Use
if-constexpr instead of dispatching to _S_wconvert. Use codecvt
instead of codecvt_utf8. Use __str_codecvt_in_all and
__str_codecvt_out_all.
[!_GLIBCXX_FILESYSTEM_IS_WINDOWS] (path::_Cvt::_S_convert): Use
codecvt instead of codecvt_utf8. Use __str_codecvt_out_all.
(path::_S_str_convert) [_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Use
codecvt_utf8_utf16 instead of codecvt_utf8. Construct return values
with allocator. Use __str_codecvt_out_all. Fallthrough to POSIX code
after converting to UTF-8.
(path::_S_str_convert): Use codecvt instead of codecvt_utf8. Use
__str_codecvt_in_all.
(path::string): Fix initialization of string types with different
allocators.
(path::u8string) [_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Use
codecvt_utf8_utf16 instead of codecvt_utf8. Use __str_codecvt_out_all.
* include/bits/locale_conv.h (__do_str_codecvt): Reorder static and
runtime conditions.
(__str_codecvt_out_all, __str_codecvt_in_all): New functions that
return false for partial conversions.
* include/experimental/bits/fs_path.h (u8path):
[_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Implement correctly for mingw.
[_GLIBCXX_FILESYSTEM_IS_WINDOWS] (path::_Cvt::_S_wconvert): Add
missing handling for char8_t. Use codecvt and codecvt_utf8_utf16
instead of codecvt_utf8. Use __str_codecvt_in_all and
__str_codecvt_out_all.
[!_GLIBCXX_FILESYSTEM_IS_WINDOWS] (path::_Cvt::_S_convert): Use
codecvt instead of codecvt_utf8. Use __str_codecvt_out_all.
(path::string) [_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Use
codecvt_utf8_utf16 instead of codecvt_utf8. Construct return values
with allocator. Use __str_codecvt_out_all and __str_codecvt_in_all.
(path::string) [!_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Use
__str_codecvt_in_all.
(path::u8string) [_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Use
codecvt_utf8_utf16 instead of codecvt_utf8. Use __str_codecvt_out_all.
* src/c++17/fs_path.cc (path::_S_convert_loc): Use
__str_codecvt_in_all.
* src/filesystem/path.cc (path::_S_convert_loc): Likewise.
* testsuite/27_io/filesystem/path/construct/90281.cc: New test.
* testsuite/27_io/filesystem/path/factory/u8path.cc: New test.
* testsuite/27_io/filesystem/path/native/string.cc: Test with empty
strings and with Unicode characters outside the basic multilingual
plane.
* testsuite/27_io/filesystem/path/native/alloc.cc: New test.
* testsuite/experimental/filesystem/path/construct/90281.cc: New test.
* testsuite/experimental/filesystem/path/factory/u8path.cc: New test.
* testsuite/experimental/filesystem/path/native/alloc.cc: New test.
* testsuite/experimental/filesystem/path/native/string.cc: Test with
empty strings and with Unicode characters outside the basic
multilingual plane.

Added:
trunk/libstdc++-v3/testsuite/27_io/filesystem/path/construct/90281.cc
trunk/libstdc++-v3/testsuite/27_io/filesystem/path/factory/
trunk/libstdc++-v3/testsuite/27_io/filesystem/path/factory/u8path.cc
  - copied, changed from r272381,
trunk/libstdc++-v3/testsuite/27_io/filesystem/path/native/string.cc
trunk/libstdc++-v3/testsuite/27_io/filesystem/path/native/alloc.cc
   

[Bug c++/90885] GCC should warn about 2^16 and 2^32 and 2^64

2019-06-17 Thread tg at mirbsd dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90885

Thorsten Glaser  changed:

   What|Removed |Added

 CC||tg at mirbsd dot org

--- Comment #15 from Thorsten Glaser  ---
-Wexp sounds like experimental

[Bug c++/88245] Wrong location for "explicitly defaulted here"

2019-06-17 Thread mbelivea at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88245

--- Comment #3 from Matthew Beliveau  ---
The location for the note message is getting reset in cp/method.c
(synthesize_method), line 894, here:

  if (!DECL_INHERITED_CTOR (fndecl))
DECL_SOURCE_LOCATION (fndecl)
  = DECL_SOURCE_LOCATION (TYPE_NAME (DECL_CONTEXT (fndecl)));

I found that the fndecl had the right location for the note going into the
function but then it was reset to something that it never was before. So since
we are testing with explicitly defaulted functions, maybe we shouldn't reset
the location? 

A possible fix would be this:

  if (!DECL_INHERITED_CTOR (fndecl) && !DECL_DEFAULTED_FN(fndecl))
DECL_SOURCE_LOCATION (fndecl)
  = DECL_SOURCE_LOCATION (TYPE_NAME (DECL_CONTEXT (fndecl)));

This would make sure the location for explicitly defaulted functions wouldn't
be reset here, and make the test case work has intended. However, I'm not
entirely sure if this is the appropriate fix

[Bug middle-end/90779] Fortran array initialization in offload regions

2019-06-17 Thread ams at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90779

--- Comment #14 from Andrew Stubbs  ---
(In reply to Jakub Jelinek from comment #7)
> if I compile just the first TU without the foo () call in there, and 
> .global .align 4 .u32 var$lto_priv$1[1] = { 5 };
> .global .align 4 .u32 var$lto_priv$0[1] = { 5 };
> if I compile both, so there is some magic that makes these global and
> uglified so that there can be multiple such vars.
> No idea where that happens, whether it is NVPTX specific etc.

That ".global" doesn't refer to the object linkage; it refers to the "global"
memory region, as opposed to the "shared" or "local" memory.

In fact the compiler still regards the variable as "not public".

[Bug c++/90754] [10 Regression] ICE: tree check: expected tree that contains ‘decl minimal’ structure, have ‘tree_list’ in lookup_type_scope_1, at cp/name-lookup.c:6492 since r271912

2019-06-17 Thread nathan at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90754

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #2 from Nathan Sidwell  ---
Fixed r272384.

[Bug c++/90754] [10 Regression] ICE: tree check: expected tree that contains ‘decl minimal’ structure, have ‘tree_list’ in lookup_type_scope_1, at cp/name-lookup.c:6492 since r271912

2019-06-17 Thread nathan at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90754

--- Comment #3 from Nathan Sidwell  ---
Author: nathan
Date: Mon Jun 17 13:46:59 2019
New Revision: 272384

URL: https://gcc.gnu.org/viewcvs?rev=272384=gcc=rev
Log:
[PR c++/90754] name lookup ICE

https://gcc.gnu.org/ml/gcc-patches/2019-06/msg00952.html
PR c++/90754
* name-lookup.c (lookup_type_scope_1): Calll qualify_lookup before
checking context.

PR c++/90754
* g++.dg/lookup/pr90754.C: New.

Added:
trunk/gcc/testsuite/g++.dg/lookup/pr90754.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/90895] __attribute__((warning(""))) doesn't work for dynamically dispatched calls to virtual functions

2019-06-17 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90895

--- Comment #1 from Jonathan Wakely  ---
Of course, if the code is optimized then no warnigns are issued at all, because
b.f() and b2.g() get inlined to nothing, and so no calls to the functions
remain.

[Bug c++/90895] New: __attribute__((warning(""))) doesn't work for dynamically dispatched calls to virtual functions

2019-06-17 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90895

Bug ID: 90895
   Summary: __attribute__((warning(""))) doesn't work for
dynamically dispatched calls to virtual functions
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

struct Base
{
   __attribute__((warning("called f"))) void f() { }
   __attribute__((warning("called g"))) virtual void g() { }
};

void f(Base& b)
{
  b.f(); // warns
  b.g();

  Base b2;
  b2.g(); // warns
}


warn.cc: In function 'void f(Base&)':
warn.cc:9:6: warning: call to 'Base::f' declared with attribute warning: called
f [-Wattribute-warning]
9 |   b.f(); // warns
  |   ~~~^~
warn.cc:13:7: warning: call to 'Base::g' declared with attribute warning:
called g [-Wattribute-warning]
   13 |   b2.g(); // warns
  |   ^~

It seems reasonable for users to expect b.g() to trigger the warning, even
though the call might actually resolve to an overrider in a derived class.

[Bug target/62055] missed optimization: recognize fnabs (FP negative absolute value) (x86-64)

2019-06-17 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62055

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
   Target Milestone|--- |10.0

[Bug target/62055] missed optimization: recognize fnabs (FP negative absolute value) (x86-64)

2019-06-17 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62055

Uroš Bizjak  changed:

   What|Removed |Added

  Attachment #46464|0   |1
is obsolete||

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

Patch in testing.

[Bug target/90620] Microblaze: ICE similar to bug 16267

2019-06-17 Thread giulio.benetti at micronovasrl dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90620

--- Comment #1 from Giulio Benetti  ---
This ICE happens also building Qt5 with Gcc 8.x

[Bug target/88834] [SVE] Poor addressing mode choices for LD2 and ST2

2019-06-17 Thread rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88834

--- Comment #22 from rsandifo at gcc dot gnu.org  
---
(In reply to kugan from comment #21)
> (In reply to Christophe Lyon from comment #20)
> > Hi Kugan,
> > 
> > The new test fails with -mabi=ilp32:
> > FAIL: gcc.target/aarch64/pr88834.c scan-assembler-times \\tld2w\\t{z[0-9]+.s
> > - z[0-9]+.s}, p[0-7]/z, \\[x[0-9]+, x[0-9]+, lsl 2\\]\\n 2
> > FAIL: gcc.target/aarch64/pr88834.c scan-assembler-times \\tst2w\\t{z[0-9]+.s
> > - z[0-9]+.s}, p[0-7], \\[x[0-9]+, x[0-9]+, lsl 2\\]\\n 1
> 
> Thanks Christophe. In the back-end, when we use ILP32, we don't accept
> SImode ops if like:
> 
> (plus:SI (mult:SI (reg:SI 91)
> (const_int 4 [0x4]))
> (reg:SI 90))
> 
> While we would accept Pmode. My question is, should we care about ILP32 for
> SVE? If so we need to fix this. Otherwise, we can run the test for LP64.

We care, but I don't think anyone's actively working on it.

I agree it's a generic ILP32 problem though.  We already disable
scan-assembler matching in sve/ for similar reasons, so I think the
easiest fix is to move both pr88834.c and pr88838.c from aarch64/ to
aarch64/sve/.  Sorry for not noticing that they were in the "wrong"
directory during the reviews.

Note that after moving, the dg-options for both tests should just
be "-O3", without "-S" or "-march=...".

[Bug middle-end/64242] Longjmp expansion incorrect

2019-06-17 Thread wilco at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64242

--- Comment #33 from Wilco  ---
Author: wilco
Date: Mon Jun 17 11:25:12 2019
New Revision: 272382

URL: https://gcc.gnu.org/viewcvs?rev=272382=gcc=rev
Log:
Improve PR64242 testcase

Clear the input array to avoid the testcase accidentally
passing with an incorrect frame pointer.

Committed as obvious.

testsuite/
PR middle-end/64242
* gcc.c-torture/execute/pr64242.c: Improve test.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.c-torture/execute/pr64242.c

[Bug target/88834] [SVE] Poor addressing mode choices for LD2 and ST2

2019-06-17 Thread kugan at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88834

--- Comment #21 from kugan at gcc dot gnu.org ---
(In reply to Christophe Lyon from comment #20)
> Hi Kugan,
> 
> The new test fails with -mabi=ilp32:
> FAIL: gcc.target/aarch64/pr88834.c scan-assembler-times \\tld2w\\t{z[0-9]+.s
> - z[0-9]+.s}, p[0-7]/z, \\[x[0-9]+, x[0-9]+, lsl 2\\]\\n 2
> FAIL: gcc.target/aarch64/pr88834.c scan-assembler-times \\tst2w\\t{z[0-9]+.s
> - z[0-9]+.s}, p[0-7], \\[x[0-9]+, x[0-9]+, lsl 2\\]\\n 1

Thanks Christophe. In the back-end, when we use ILP32, we don't accept SImode
ops if like:

(plus:SI (mult:SI (reg:SI 91)
(const_int 4 [0x4]))
(reg:SI 90))

While we would accept Pmode. My question is, should we care about ILP32 for
SVE? If so we need to fix this. Otherwise, we can run the test for LP64.

[Bug libstdc++/90887] [10 Regression] r272186 causes -fcompare-debug failure

2019-06-17 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90887

--- Comment #7 from Jakub Jelinek  ---
I guess the more interesting are the backtrace frames not shown, why it
compiler decided to instantiate it just without (resp. with) -g (or -g3 or
whatever you are using) and not the other.  Is it some hash table traversal
from which it is invoked, or what other reason.

[Bug libstdc++/90887] [10 Regression] r272186 causes -fcompare-debug failure

2019-06-17 Thread burnus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90887

--- Comment #6 from Tobias Burnus  ---
(In reply to Jakub Jelinek from comment #5)
> Which of those 3, or all of them?

At the end, I see changes in all of them - but I am not sure whether all of
them in all lines.


If I add a 'printf' to gcc/cgraph.h's symbol_table::register_symbol (which
bumps 'order' alias symbol_order), the no-debug version has the following 11
additional symbols at some point; the first being:

symbol_table::register_symbol: order=3774 name=static constexpr bool
std::_PCC<, _T1, _T2>::_ConstructiblePair() [with _U1 =
std::_Rb_tree_node_base*; _U2 = std::_Rb_tree_node_base*; bool  =
true; _T1 = std::_Rb_tree_node_base*; _T2 = std::_Rb_tree_node_base*]


This one comes from   gcc-trunk/include/c++/10.0.0/bits/stl_pair.h:100:29
and the backtrace is:

#0  symtab_node::register_symbol (this=0x7fffeba9b168) at
../../gcc/symtab.c:379
#1  0x00ba00e9 in cgraph_node::create(tree_node*) () at
../../gcc/cgraph.c:523
#2  0x00b9ff11 in cgraph_node::get_create(tree_node*) () at
../../gcc/cgraph.c:545
#3  0x00af6f51 in c_genericize(tree_node*) () at
../../gcc/c-family/c-gimplify.c:152
#4  0x00916498 in cp_genericize(tree_node*) () at
../../gcc/cp/cp-gimplify.c:1809
#5  0x00952312 in finish_function(bool) () at ../../gcc/cp/decl.c:16272
#6  0x00a24cc4 in instantiate_decl(tree_node*, bool, bool) () at
../../gcc/cp/pt.c:24794
#7  0x008f869d in instantiate_cx_fn_r(tree_node**, int*, void*) () at
../../gcc/cp/constexpr.c:5296


A bit later, I see lines for -g3 only, which come in addition for
'std::_Vector_base

[Bug target/65248] Copy relocation against protected symbol doesn't work

2019-06-17 Thread maskray at google dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65248

Fangrui Song  changed:

   What|Removed |Added

 CC||maskray at google dot com

--- Comment #13 from Fangrui Song  ---
Ping (I hope this can be reopened)

Since we have R_*_GOTPCRELX now, we should fix the protected data issue
properly (by deleting the default HAVE_LD_PIE_COPYRELOC=1 behavior introduced
in gcc 5).

See https://gcc.gnu.org/ml/gcc/2019-05/msg00215.html

[Bug other/89863] [meta-bug] Issues that cppcheck finds that gcc misses

2019-06-17 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863
Bug 89863 depends on bug 90874, which changed state.

Bug 90874 Summary: trunk/gcc/ipa-utils.h:243: possible cut-n-paste error ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90874

   What|Removed |Added

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

[Bug ipa/90874] trunk/gcc/ipa-utils.h:243: possible cut-n-paste error ?

2019-06-17 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90874

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
Fixed.

[Bug ipa/90874] trunk/gcc/ipa-utils.h:243: possible cut-n-paste error ?

2019-06-17 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90874

--- Comment #3 from Martin Liška  ---
Author: marxin
Date: Mon Jun 17 09:03:26 2019
New Revision: 272378

URL: https://gcc.gnu.org/viewcvs?rev=272378=gcc=rev
Log:
Remove dead code (PR ipa/90874).

2019-06-17  Martin Liska  

PR ipa/90874
* ipa-utils.h (odr_type_p): Remove dead code.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-utils.h

[Bug c++/90885] GCC should warn about 2^16 and 2^32 and 2^64

2019-06-17 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90885

--- Comment #14 from Richard Biener  ---
(In reply to David Malcolm from comment #11)
> Warning for "2 ^ INT" seems reasonable, maybe just for that (I think I agree
> with comment #6).
> 
> Not sure what to call it: "-Wexclusive-or"???

-Wexp[onential] or -Wpow[er]?

[Bug target/88952] The asm operator modifiers for rs6000 should be documented like they are for x86

2019-06-17 Thread christopher.leonard at abaco dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88952

--- Comment #13 from Christopher Leonard  
---
(In reply to Segher Boessenkool from comment #12)
> the oldest GCC still supported is GCC 7.

Apologies if it was not clear, but I am just reporting the issue for posterity
and it was not easy for me to check on a newer version at the time.

If you are wondering why people use old versions of GCC, my usecase is working
on a codebase where consistent output is desirable over new features or
bugfixes, going back to when 4.x was new.

[Bug tree-optimization/90892] [9/10 regression] -O2 miscompiles __builtin_strncmp with string containing '\0'

2019-06-17 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90892

--- Comment #3 from Martin Liška  ---
I've got a patch candidate that I've been testing.

[Bug libstdc++/90887] [10 Regression] r272186 causes -fcompare-debug failure

2019-06-17 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90887

--- Comment #5 from Jakub Jelinek  ---
(In reply to Tobias Burnus from comment #4)
> Looking at the .gdk files, the difference is (only) in the 
>   ;; Function 
> lines where
>   funcdef_no=9263, cgraph_uid=3950, symbol_order=5009
> differ in their numeric value.
> 
> (As it depends on this odd library patch and on passing the full path
> instead of a relative path, it points to some indirect effect.)

Which of those 3, or all of them?
For one of them, pick the smallest different values and in the code that assign
those counters try to find out where they are assigned differently (different
numbers for the fndecl with the same name) and why.
If say funcdef_no differs, it might help to add a debugging dump to say stderr
in allocate_struct_function when current_function_funcdef_no =
get_next_funcdef_no (); is done, printing the fndecl say using
dump_generic_stmt and the current_function_funcdef_no that got set.  For the
other counters similarly, depending on which you'll look at.  That would allow
you to spot the very first difference in those, then just debug why some
function has been created only with -g and not without or vice versa.

[Bug libstdc++/90887] [10 Regression] r272186 causes -fcompare-debug failure

2019-06-17 Thread burnus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90887

--- Comment #4 from Tobias Burnus  ---
Looking at the .gdk files, the difference is (only) in the 
  ;; Function 
lines where
  funcdef_no=9263, cgraph_uid=3950, symbol_order=5009
differ in their numeric value.

(As it depends on this odd library patch and on passing the full path instead
of a relative path, it points to some indirect effect.)

[Bug lto/90889] snapshot 20190614 fails to build Ada with LTO

2019-06-17 Thread hubicka at ucw dot cz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90889

--- Comment #9 from Jan Hubicka  ---
> The gcc_unreachable in ipcp_verify_propagated_values gets tripped over
> if there is a TOP lattice in any of the IPA-CP scalar constant
> propagation lattices after the propagation.
> 
> All non-local nodes get all their lattices set to VARIABLE and all
> local nodes should either be removed by unreachable code or get
> another lattice value from their callers.  Therefore, this assert
> triggers when a function should have been removed by unreachable node
> removal or if IPA-CP has a bad notion of about locality of a node,
> usually the former.

Yep, in the dumps I also included the callgraph dump from previous
pass so you can check if there is a dead node in it.

Honza

[Bug lto/90889] snapshot 20190614 fails to build Ada with LTO

2019-06-17 Thread jamborm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90889

Martin Jambor  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org

--- Comment #8 from Martin Jambor  ---
(In reply to Jan Hubicka from comment #3)
> The failing check is Martin (Jambor's) sanity check of ipa-cp, so I am
> adding him to CC: at very first glance it looks like ipa bug exposed by LTO.
> 

The gcc_unreachable in ipcp_verify_propagated_values gets tripped over
if there is a TOP lattice in any of the IPA-CP scalar constant
propagation lattices after the propagation.

All non-local nodes get all their lattices set to VARIABLE and all
local nodes should either be removed by unreachable code or get
another lattice value from their callers.  Therefore, this assert
triggers when a function should have been removed by unreachable node
removal or if IPA-CP has a bad notion of about locality of a node,
usually the former.

Yesterday I ran out of space in /tmp when trying to bootstrap Ada, I
will try again today and have a quick look.

[Bug bootstrap/90873] [10 regression] -Wmaybe-uninitialized warning in gcc/tree-ssa-forwprop.c breaks 32-bit bootstrap

2019-06-17 Thread clyon at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90873

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #7 from Christophe Lyon  ---
git bisect tells me that this commit (r272273) causes a regression on
arm-linux-gnueabihf

FAIL: ext/random/normal_mv_distribution/operators/serialize.cc (test for excess
errors)


/libstdc++-v3/testsuite/ext/random/normal_mv_distribution/operators/serialize.cc:38:
internal compiler error: tree check: expected target_mem_ref, have var_decl in
indirect_ref_may_alias_decl_p, at tree-ssa-alias.c:1399
0x5d5c59 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/gcc/tree.c:9899
0xf369f8 tree_check(tree_node*, char const*, int, char const*, tree_code)
/gcc/tree.h:3197
0xf369f8 indirect_ref_may_alias_decl_p
/gcc/tree-ssa-alias.c:1399
0xf36d85 refs_may_alias_p_2
/gcc/tree-ssa-alias.c:1689
0xf36d85 refs_may_alias_p_1(ao_ref*, ao_ref*, bool)
/gcc/tree-ssa-alias.c:1710
0x923c38 rtx_refs_may_alias_p
/gcc/alias.c:368
0x928cb6 true_dependence_1
/gcc/alias.c:2976
0xb1ca07 compute_transp(rtx_def const*, int, simple_bitmap_def**, bitmap_head*,
bitmap_head*, vec*)
/gcc/gcse-common.c:175
0xb16e9a compute_local_properties
/gcc/gcse.c:699
0xb1a8e4 compute_pre_data
/gcc/gcse.c:1866
0xb1a8e4 one_pre_gcse_pass
/gcc/gcse.c:2616
0xb1a8e4 execute_rtl_pre
/gcc/gcse.c:4024
0xb1a8e4 execute
/gcc/gcse.c:4068
Please submit a full bug report,

[Bug tree-optimization/80738] dead first stmt in a=0;a=b;b=0 whatever the aliasing

2019-06-17 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80738

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Created attachment 46491
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46491=edit
broken prototype

So I think DSE could try to handle this.  When it sees

 *a = 0;
 _1 = *b;
 *a = _1;
 *b = 0;

looking for uses of the first store it will arrive at the load from b.
With looking at the immediate use(s) from _1 it could check whether
it arrives at a store with the same VUSE that would look killing and
if so disregard the use.  The following implements this but it needs
sanitizing for the case of possible partial overlaps...  It also
only looks at the immediate next stores and would be confused by
intermediate unrelated ones.

[Bug ada/80590] [8/9/10 regression] non-bootstrap build failure of Ada runtime

2019-06-17 Thread charlet at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80590

Arnaud Charlet  changed:

   What|Removed |Added

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

--- Comment #22 from Arnaud Charlet  ---
"Fixed" as best as possible on 8, 9 and 10 branches. Would be great if you
could confirm that Tom!

[Bug ada/80590] [8/9/10 regression] non-bootstrap build failure of Ada runtime

2019-06-17 Thread charlet at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80590

--- Comment #21 from Arnaud Charlet  ---
Author: charlet
Date: Mon Jun 17 07:35:02 2019
New Revision: 272374

URL: https://gcc.gnu.org/viewcvs?rev=272374=gcc=rev
Log:
PR ada/80590

* exp_ch9.adb (Expand_N_Delay_Relative_Statement): Swap the two
conditions to avoid a unnecessary exception propagation in the default
case.


Modified:
branches/gcc-9-branch/gcc/ada/ChangeLog
branches/gcc-9-branch/gcc/ada/exp_ch9.adb

[Bug ada/80590] [8/9/10 regression] non-bootstrap build failure of Ada runtime

2019-06-17 Thread charlet at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80590

--- Comment #20 from Arnaud Charlet  ---
Author: charlet
Date: Mon Jun 17 07:34:04 2019
New Revision: 272373

URL: https://gcc.gnu.org/viewcvs?rev=272373=gcc=rev
Log:
PR ada/80590

* exp_ch9.adb (Expand_N_Delay_Relative_Statement): Swap the two
conditions to avoid a unnecessary exception propagation in the default
case.


Modified:
branches/gcc-8-branch/gcc/ada/ChangeLog
branches/gcc-8-branch/gcc/ada/exp_ch9.adb

[Bug ada/80590] [8/9/10 regression] non-bootstrap build failure of Ada runtime

2019-06-17 Thread charlet at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80590

--- Comment #19 from Arnaud Charlet  ---
Author: charlet
Date: Mon Jun 17 07:32:14 2019
New Revision: 272372

URL: https://gcc.gnu.org/viewcvs?rev=272372=gcc=rev
Log:
PR ada/80590

* exp_ch9.adb (Expand_N_Delay_Relative_Statement): Swap the two
conditions to avoid a unnecessary exception propagation in the default
case.


Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/exp_ch9.adb

[Bug libstdc++/90887] [10 Regression] r272186 causes -fcompare-debug failure

2019-06-17 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90887

--- Comment #3 from Jonathan Wakely  ---
If the compiler itself used std::to_string and that function had a bug, I can
see how it might cause this, but that function is C++11 so GCC can't use it
anyway.

[Bug ada/80590] [8/9/10 regression] non-bootstrap build failure of Ada runtime

2019-06-17 Thread charlet at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80590

Arnaud Charlet  changed:

   What|Removed |Added

 Status|SUSPENDED   |NEW
 CC||charlet at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |charlet at gcc dot 
gnu.org

--- Comment #18 from Arnaud Charlet  ---
To summarize the problem on this PE: the issue is that GNAT switched from SJLJ
to ZCX exception handling from GCC 7 to GCC 8, causing these inconsistencies
that can only be resolved via a full bootstrap, or by using the newly built
compiler to build new compilers.

If you enable bootstrap, the problem will disappear without changing sources.

Now in order to help you move forward more easily, I'm also going to commit a
change that hides/workaround the issue at least for the files you mentioned
(g-exptty and co) that will avoid an unnecessary exception propagation in the
compiler when handling the "delay" construct.

I'll commit the change on branches 8, 9 and trunk.

Would be great if you could confirm that this unblocks the situation, and would
be
great to reenable Ada in your builds.

Arno

[Bug c++/90754] [10 Regression] ICE: tree check: expected tree that contains ‘decl minimal’ structure, have ‘tree_list’ in lookup_type_scope_1, at cp/name-lookup.c:6492 since r271912

2019-06-17 Thread reichelt at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90754

Volker Reichelt  changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org

--- Comment #1 from Volker Reichelt  ---
Nathan, as your patch broke this, would you mind having a look?

[Bug libstdc++/90887] [10 Regression] r272186 causes -fcompare-debug failure

2019-06-17 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90887

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Well, libstdc++ can't be the right component, because a -fcompare-debug failure
necessarily is a compiler bug.
That said, we don't have a reproducer.
Can you reproduce with -E -fdirectives-only preprocessing and then compiling
that preprocessed source named whatever.C?

[Bug c++/90894] New: maybe_unused attribute is ignored on function parameters in explicitly instantiated templates

2019-06-17 Thread gcc at mattwhitlock dot name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90894

Bug ID: 90894
   Summary: maybe_unused attribute is ignored on function
parameters in explicitly instantiated templates
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at mattwhitlock dot name
  Target Milestone: ---

/* BEGIN bug.cpp */

template 
struct Base {
void func(int);
};

struct Derived : Base<0> { };

template 
void Base::func([[maybe_unused]] int n) { }  // WARNING

template class Base<0>;

/*-*/

template 
void func(int);

template void func<0>(int);

template 
void func([[maybe_unused]] int n) { }  // WARNING

/* END bug.cpp */


$ g++ -c -Wunused-parameter bug.cpp
bug.cpp: In instantiation of 'void Base::func(int) [with int X = 0]':
bug.cpp:11:16:   required from here
bug.cpp:9:6: warning: 'maybe_unused' attribute directive ignored [-Wattributes]
9 | void Base::func([[maybe_unused]] int n) { }  // WARNING
  |  ^~~
bug.cpp:3:12: warning: unused parameter 'n' [-Wunused-parameter]
3 |  void func(int);
  |^~~
bug.cpp: In instantiation of 'void func(int) [with int X = 0]':
bug.cpp:18:26:   required from here
bug.cpp:21:6: warning: 'maybe_unused' attribute directive ignored
[-Wattributes]
   21 | void func([[maybe_unused]] int n) { }  // WARNING
  |  ^~~~
bug.cpp:16:11: warning: unused parameter 'n' [-Wunused-parameter]
   16 | void func(int);
  |   ^~~


The first part of the test case (above the dashed line) demonstrates the
problem on a class template. Note that the warning disappears if the Derived
class definition is removed or is moved below the class template member
function definition.

The second part of the test case (below the dashed line) demonstrates the
problem on a function template. Note that the warning disappears if the
explicit function template instantiation is moved below the function template
definition.

[Bug libstdc++/90887] [10 Regression] r272186 causes -fcompare-debug failure

2019-06-17 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90887

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-06-17
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
I can't reproduce that..

[Bug tree-optimization/90892] [9/10 regression] -O2 miscompiles __builtin_strncmp with string containing '\0'

2019-06-17 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90892

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |9.2

[Bug tree-optimization/90892] [9/10 regression] -O2 miscompiles __builtin_strncmp with string containing '\0'

2019-06-17 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90892

--- Comment #2 from Richard Biener  ---
Confirmed.  We turn it into _8 = __builtin_strcmp (, "A\x00"); and then
inline-expansion to RTL compares beyond the literal zero.

I think turning it into strcmp is wrong.

[Bug tree-optimization/90892] [9/10 regression] -O2 miscompiles __builtin_strncmp with string containing '\0'

2019-06-17 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90892

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-06-17
 CC||marxin at gcc dot gnu.org,
   ||qinzhao at gcc dot gnu.org
  Known to work||8.3.0
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1
  Known to fail||10.0, 9.1.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r262636. Let me fix that.

[Bug libstdc++/90887] [10 Regression] r272186 causes -fcompare-debug failure

2019-06-17 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90887

Richard Biener  changed:

   What|Removed |Added

   Keywords||build
  Component|other   |libstdc++
   Target Milestone|--- |10.0

[Bug ipa/90874] trunk/gcc/ipa-utils.h:243: possible cut-n-paste error ?

2019-06-17 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90874

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-06-17
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Let me fix it.