[Bug target/91913] New: ICE in extract_constrain_insn, at recog.c:2211

[marxin at gcc dot gnu.org]

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

Bug ID: 91913
   Summary: ICE in extract_constrain_insn, at recog.c:2211
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: ktkachov at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: armv7-linux-gnueabi

Following is causing ICE:

$ ./arm-linux-gnueabi-gfortran
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/string_ctor_1.f90 -Ofast
--param max-cse-insns=0 -fno-schedule-insns -fsanitize=null
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/string_ctor_1.f90:16:0:

   16 | end subroutine
  | 
Error: insn does not satisfy its constraints:
(insn 288 197 200 25 (parallel [
(set (reg:CC 100 cc)
(compare:CC (reg/f:SI 6 r6 [150])
(const_int 0 [0])))
(set (reg/f:SI 13 sp)
(reg/f:SI 6 r6 [150]))
])
"/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/string_ctor_1.f90":15:0
168 {*movsi_compare0}
 (expr_list:REG_ARGS_SIZE (const_int 0 [0])
(nil)))
during RTL pass: cprop_hardreg
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/string_ctor_1.f90:16:0:
internal compiler error: in extract_constrain_insn, at recog.c:2211
0x5a14af _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/rtl-error.c:108
0x5a14d5 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/rtl-error.c:118
0x5a09dc extract_constrain_insn(rtx_insn*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/recog.c:2211
0xa962c7 copyprop_hardreg_forward_1
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/regcprop.c:805
0xa96fa5 execute
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/regcprop.c:1374
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$ ./arm-linux-gnueabi-gfortran -v
Using built-in specs.
COLLECT_GCC=./arm-linux-gnueabi-gfortran
COLLECT_LTO_WRAPPER=/home/marxin/BIG/bin/arm/dev/shm/buildbot/install/gcc/bin/../libexec/gcc/arm-linux-gnueabi/10.0.0/lto-wrapper
Target: arm-linux-gnueabi
Configured with:
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/configure
--enable-languages=c,c++,fortran --disable-bootstrap --disable-libsanitizer
--disable-multilib --enable-checking=release
--prefix=/dev/shm/buildbot/install/gcc --target=arm-linux-gnueabi
--with-as=/usr/bin/arm-suse-linux-gnueabi-as
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.0 20190925 (experimental)
f2e61afa97856a6c96f6093c13f74e447084be3a (GCC

[Bug libstdc++/91910] Debug mode: there is a racing condition between destructors of iterator and the associated container.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-26
 Ever confirmed|0   |1

--- Comment #3 from Jonathan Wakely  ---
(In reply to Andrew Pinski from comment #1)
> Seems like this is a bug in the testcase rather than libstdc++.
> 
> >exemplifying concurrent destruction of iterator and container
> That seems like a disaster waiting to happen.  Because once the container is
> gone, the iterator is also considered gone.  If you did this in a normal
> code without threads it would be invalid to do in that order anyways.

Nonsense. It's totally fine for an iterator to be destroyed after the container
it referred to has gone:

  {
std::set::iterator iter;
{
  std::set s;
  iter = s.begin();
} // s.~set() runs here
  }  // iter.~iterator() runs here

The concurrent case is no different. The iterator's destructor does not access
the container in normal mode, and so there is no data race when the two
constructors run concurrently. In debug mode **we** have introduced spooky
action at a distance, whereby the container and iterator modify each other.
**We** are responsible for making that happen correctly and safely, not the
user.

It would be completely absurd to expect users to lock mutexes around
destruction of every iterator to synchronize it with destruction of the
container.

This is a bug.

[Bug tree-optimization/91885] [9/10 Regression] ICE when compiling SPEC 2017 blender benchmark with -O3 -fprofile-generate

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Author: marxin
Date: Thu Sep 26 07:40:09 2019
New Revision: 276141

URL: https://gcc.gnu.org/viewcvs?rev=276141&root=gcc&view=rev
Log:
Add TODO_update_ssa for SLP BB vectorization (PR tree-optimization/91885).

2019-09-26  Martin Liska  

PR tree-optimization/91885
* tree-vectorizer.c (try_vectorize_loop_1):
Add TODO_update_ssa_only_virtuals similarly to what slp
pass does.
2019-09-26  Martin Liska  

PR tree-optimization/91885
* gcc.dg/pr91885.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr91885.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vectorizer.c

[Bug libstdc++/91910] Debug mode: there is a racing condition between destructors of iterator and the associated container.

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Specifically, [res.on.data.races] p7 in the standard says we need to protect
the container's internal state from data races.

[Bug tree-optimization/91885] [9 Regression] ICE when compiling SPEC 2017 blender benchmark with -O3 -fprofile-generate

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||10.0
Summary|[9/10 Regression] ICE when  |[9 Regression] ICE when
   |compiling SPEC 2017 blender |compiling SPEC 2017 blender
   |benchmark with -O3  |benchmark with -O3
   |-fprofile-generate  |-fprofile-generate
  Known to fail|10.0|

--- Comment #4 from Martin Liška  ---
Fixed on trunk so far.

[Bug c/91914] New: Invalid strlen optimization

[joerg.rich...@pdv-fs.de]

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

Bug ID: 91914
   Summary: Invalid strlen optimization
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joerg.rich...@pdv-fs.de
  Target Milestone: ---

cat > t.c <
#include 

struct stringpool_t
{
char stringpool_str4[sizeof("Foo")];
char stringpool_str5[sizeof("Bar")];
};

static const struct stringpool_t stringpool_contents = {
  "Foo",
  "Bar",
};

#define stringpool ((const char *) &stringpool_contents)

int main( int argc, char** argv )
{
  printf( "%zu\n", strlen( stringpool + 4 ) );
  volatile int idx = 4;
  printf( "%zu\n", strlen( stringpool + idx ) );
  return 0;
}
EOF

gcc -o t t.c -Wall

## Output:
3
0

The first strlen() has the warning "offset '4' outside bounds 
of constant string [-Warray-bounds]".  I think this is a wrong 
warning, because of the cast to char*. But the strlen() result is okay.

The second strlen() returns 0.  This is more serious as this results in wrong
code.

The stringpool-code is generated by gperf.

[Bug c++/91369] Implement P0784R7: constexpr new

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 46946
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46946&action=edit
gcc10-pr91369.patch

Current WIP patch.

[Bug c++/91369] Implement P0784R7: constexpr new

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Still need to add further testcase coverage and finish cookie support, but I
ran into something that looks like a bug in the C++ standard.

[dcl.constexpr]/3 says:
if the function is a constructor or destructor, its class shall not have any
virtual base classes;
[dcl.constexpr]/5 says:
The definition of a constexpr destructor whose function-body is not = delete
shall additionally satisfy the following requirement:
- for every subobject of class type or (possibly multi-dimensional) array
thereof, that class type shall have a constexpr destructor.
[class.dtor]/8 says:
A destructor is trivial if it is not user-provided and if:
- the destructor is not virtual,
- all of the direct base classes of its class have trivial destructors, and
- for all of the non-static data members of its class that are of class type
(or array thereof), each such class has a trivial destructor.
[class.dtor]/9 says:
A defaulted destructor is a constexpr destructor if it satisfies the
requirements for a constexpr destructor ([dcl.constexpr]).
[ Note: In particular, a trivial destructor is a constexpr destructor.
— end note ]

Now, consider the g++.old-deja/g++.mike/p12306a.C or g++.dg/abi/empty7.C
testcases in -std=c++2a modes, let's say the first one:

class a {
public:
int i;
};

class g : virtual public a {
};

class b : virtual public a {
int j;
};

class c : public g, public b {
};

class d {
public:
virtual class b* get() {return 0;}
};

class f : public d {
public:
virtual class b* get() {return &_c;}
c _c;
};

int main(void) {
f D;
b* bp=D.get();
D._c.i = 42;
return &D._c.i != &bp->i;
}

The patch ICEs on this, because the implicit f::~f () is considered trivial
(there are no virtual destructors in the testcase, nor any user-provided
destructors),
but it isn't a constexpr destructor, because while f doesn't have virtual
bases, a non-static data member of f (_c) has virtual bases and thus c::~c ()
is not a constexpr destructor and because of that f::~f () can't be a constexpr
destructor either.

So, is the [class.dtor]/9 note just incorrect and should be removed, or
clarified somehow?  I believe it shouldn't affect what actually is a literal
type or not, because
the constructor of a class without virtual bases which has a non-static data
member that has virtual bases can't be constexpr either.

On the compiler side, it would mean the trivial destructor quick bail-out
checks wouldn't actually work for when we ask whether the destructor is
constexpr, though we could keep it perhaps in the literal_type_p checking, at
least as long as a subobject with virtual bases really always forces
non-constexpr constructors.

[Bug tree-optimization/91909] [10 regression] gcc.dg/vect/vect-cond-4.c fails on armeb after r275898

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-09-26
 CC||rsandifo at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I can't get the test to even vectorize.

> ./cc1 -quiet -I include vect-cond-4.c -fdump-tree-vect-details 
> -fdump-tree-optimized -O2 -ftree-vectorize -mfpu=neon -fopt-info-vec -w

using a cc1-cross configured as

/tmp/trunk/configure --target=armeb-none-linux-gnueabihf --with-mode=arm
--with-cpu=cortex-a9 --with-fpu=neon-fp16

So you have to provide more detail (preferably at least the cc1 command-line
used if that is enough and also exposes configure-time choices).

Maybe Richard is also set up for actual make check on armeb ...

[Bug c/91914] [9 Regression] Invalid strlen optimization

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-26
 CC||msebor at gcc dot gnu.org
  Known to work||10.0, 8.3.0
   Target Milestone|--- |9.3
Summary|Invalid strlen optimization |[9 Regression] Invalid
   ||strlen optimization
 Ever confirmed|0   |1
  Known to fail||9.2.0

--- Comment #1 from Martin Liška  ---
Apparently only GCC 9 branch is affected. Started with r262958 and was fixed on
trunk with r274837. Can you Martin please take a look?

[Bug tree-optimization/91909] [10 regression] gcc.dg/vect/vect-cond-4.c fails on armeb after r275898

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
(In reply to Richard Biener from comment #1)
> Maybe Richard is also set up for actual make check on armeb ...

Yeah, I'll take this.  I need to update the arm fp16 tests after
a regression Christophe noticed anyway.

[Bug target/91912] [9/10 Regression] ICE in lra_set_insn_recog_data, at lra.c:1004

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-26
  Known to work||8.3.1
Summary|ICE in  |[9/10 Regression] ICE in
   |lra_set_insn_recog_data, at |lra_set_insn_recog_data, at
   |lra.c:1004  |lra.c:1004
 Ever confirmed|0   |1
  Known to fail||10.0, 9.2.1

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed.

[Bug target/91913] [8/9/10 Regression] ICE in extract_constrain_insn, at recog.c:2211

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-26
  Known to work||7.4.1
Summary|ICE in  |[8/9/10 Regression] ICE in
   |extract_constrain_insn, at  |extract_constrain_insn, at
   |recog.c:2211|recog.c:2211
 Ever confirmed|0   |1
  Known to fail||10.0, 8.3.1, 9.2.1

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed

[Bug libstdc++/91910] Debug mode: there is a racing condition between destructors of iterator and the associated container.

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Leon suggested using the _M_sequence pointer to access the mutex pool directly,
instead of calling _M_sequence->_M_get_mutex() (which is undefined if
_M_sequence is being destroyed).

Combining that with some atomic ops and a double-checked lock might be good
enough:

--- a/libstdc++-v3/src/c++11/debug.cc
+++ b/libstdc++-v3/src/c++11/debug.cc
@@ -381,10 +381,10 @@ namespace __gnu_debug
   _Safe_iterator_base::
   _M_detach()
   {
-if (_M_sequence)
+if (auto seq = __atomic_load_n(&_M_sequence, __ATOMIC_ACQUIRE))
   {
-   _M_sequence->_M_detach(this);
-   _M_reset();
+   __gnu_cxx::__scoped_lock sentry(get_safe_base_mutex(seq));
+   _M_detach_single();
   }
   }

@@ -403,7 +403,7 @@ namespace __gnu_debug
   _Safe_iterator_base::
   _M_reset() throw ()
   {
-_M_sequence = 0;
+__atomic_store_n(&_M_sequence, (_Safe_sequence_base*)0, __ATOMIC_RELEASE);
 _M_version = 0;
 _M_prior = 0;
 _M_next = 0;


This fixes the ThreadSanitizer errors for the provided testcase.

One problem with this approach is that not all targets support pointer-width
atomics without linking to libatomic.

[Bug ipa/91836] [10 Regression] Speed regression of 525.x264_r with -Ofast -march=native since r275982

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
I can confirm it's fixed.

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[marxin at gcc dot gnu.org]

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

Bug 91836 Summary: [10 Regression] Speed regression of 525.x264_r with -Ofast 
-march=native since r275982
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91836

   What|Removed |Added

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

[Bug preprocessor/71102] _Pragma("GCC warning ...") should concatenate string literals

[sbergman at redhat dot com]

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

Stephan Bergmann  changed:

   What|Removed |Added

 CC||sbergman at redhat dot com

--- Comment #1 from Stephan Bergmann  ---
This affects deprecation warnings emitted by GLib, see the discussion in the
commit message of

"Improve GLIB_DEPRECATED_MACRO_FOR output":  "That recent GCC only prints
'Deprecated pre-processor symbol, repace with ' appears to be a bug in GCC that
GLIB_UNAVAILABLE_MACRO already suffers from, too."  (Though it's not a bug but
just unexpected implementation-defined behavior, especially unexpected given
that unlike

  #pragma GCC warning "foo" "bar"

the similar

  #pragma message "foo" "bar"

does print all the given strings and not just the first one.)

[Bug c/91915] New warning for duplicate if condition in if-elseif-elseif chain

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-09-26
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
I can work on that as I'm right now working on a new if to switch conversion
pass.

[Bug c/91915] New: New warning for duplicate if condition in if-elseif-elseif chain

[marxin at gcc dot gnu.org]

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

Bug ID: 91915
   Summary: New warning for duplicate if condition in
if-elseif-elseif chain
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
Blocks: 87403
  Target Milestone: ---

As seen here:

 cat /tmp/warn.c
int global;
void bar();

int foo(int argc)
{
  if (argc == 1)
bar ();
  else if (argc == 2) {
global += 1;
  }
  else if (argc == 1)
  {
bar ();
bar ();
  }
  return 0;
}


int main222(int argc)
{
  switch (argc)
  {
case 1:
  bar ();
  break;
case 2:
  global += 1;
  return 0;
case 1:
  bar ();
  bar ();
  break;
default:
  break;
  }
  return 0;
}

We want about duplicate switch cases:
gcc /tmp/warn.c
/tmp/warn.c: In function ‘main222’:
/tmp/warn.c:30:5: error: duplicate case value
   30 | case 1:
  | ^~~~
/tmp/warn.c:24:5: note: previously used here
   24 | case 1:
  | ^~~~

and I think it can be handy to the same for the if-elseif chains that are
semantically equal to the switch statement.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
[Bug 87403] [Meta-bug] Issues that suggest a new warning

[Bug d/91916] New: Maybe a dead code in socket.d

[marxin at gcc dot gnu.org]

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

Bug ID: 91916
   Summary: Maybe a dead code in socket.d
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: marxin at gcc dot gnu.org
CC: ibuclaw at gcc dot gnu.org
  Target Milestone: ---

Looking at the ./libphobos/src/std/socket.d file, when building:
/dev/shm/mliska/gcc_89622158a277a4f1200d2652d66f8c1b9c1e4012/objdir/./gcc/gdc
-B/dev/shm/mliska/gcc_89622158a277a4f1200d2652d66f8c1b9c1e4012/objdir/./gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/
-isystem /usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys-include -fPIC -O2 -g -nostdinc -I
../../../../libphobos/src -I ../../../../libphobos/libdruntime -I
../libdruntime -I . -c ../../../../libphobos/src/std/socket.d -fversion=Shared
-o std/.libs/socket.o

I see there's a function formatValue which contains if-elseif chain that has a
dead code:

Statement can throw: formatValue (w_9(D), D.19387, f_5(D));
formatValue (struct Appender!(immutable(string)) & w, SocketOption val, const
struct FormatSpec!char & f)
{
...
   :
  if (val_6(D) == 1)
goto ; [INV]
  else
goto ; [INV]

   :
  D.19387.length = 5;
  D.19387.ptr = "DEBUG";
  formatValue (w_9(D), D.19387, f_5(D));
  // predicted unlikely by early return (on trees) predictor.
  goto ; [INV]

   :
  if (val_6(D) == 6)
goto ; [INV]
  else
goto ; [INV]
...
   :
  if (val_6(D) == 1)
goto ; [INV]
  else
goto ; [INV]

   :
  D.19435.length = 11;
  D.19435.ptr = "TCP_NODELAY";
  formatValue (w_9(D), D.19435, f_5(D));
  // predicted unlikely by early return (on trees) predictor.
  goto ; [INV]

So as seen:

/// Specifies a socket option:
enum SocketOption: int
{
DEBUG =SO_DEBUG,/// Record debugging
information
...
TCP_NODELAY =  .TCP_NODELAY,/// Disable the Nagle algorithm
for send coalescing

these two have same integer representation == 1. Maybe it's a bug?

[Bug rtl-optimization/91860] [10 Regression] ICE: in decompose, at rtl.h:2279 with -Og -fipa-cp -g --param=max-combine-insns=3

[zsojka at seznam dot cz]

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

--- Comment #4 from Zdenek Sojka  ---
Created attachment 46947
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46947&action=edit
different testcase

$ riscv64-unknown-linux-gnu-gcc -Og -fexpensive-optimizations -fno-tree-fre -g
--param=max-combine-insns=4 testcase2.c
during RTL pass: combine
testcase2.c: In function 'foo':
testcase2.c:10:1: internal compiler error: in decompose, at rtl.h:2279
   10 | }
  | ^
0xd99782 wi::int_traits >::decompose(long*,
unsigned int, std::pair const&)
/repo/gcc-trunk/gcc/rtl.h:2277
0xd99782 wide_int_ref_storage::wide_int_ref_storage
>(std::pair const&)
/repo/gcc-trunk/gcc/wide-int.h:1022
0xd7c735 generic_wide_int
>::generic_wide_int >(std::pair const&)
/repo/gcc-trunk/gcc/wide-int.h:782
0xd7c735 simplify_const_unary_operation(rtx_code, machine_mode, rtx_def*,
machine_mode)
/repo/gcc-trunk/gcc/simplify-rtx.c:1900
0xd7d0ee simplify_unary_operation(rtx_code, machine_mode, rtx_def*,
machine_mode)
/repo/gcc-trunk/gcc/simplify-rtx.c:868
0xd80220 simplify_gen_unary(rtx_code, machine_mode, rtx_def*, machine_mode)
/repo/gcc-trunk/gcc/simplify-rtx.c:367
0xd916e7 simplify_subreg(machine_mode, rtx_def*, machine_mode, poly_int<1u,
unsigned long>)
/repo/gcc-trunk/gcc/simplify-rtx.c:6845
0xd91ac8 simplify_gen_subreg(machine_mode, rtx_def*, machine_mode, poly_int<1u,
unsigned long>)
/repo/gcc-trunk/gcc/simplify-rtx.c:6873
0xd9327a simplify_replace_fn_rtx(rtx_def*, rtx_def const*, rtx_def*
(*)(rtx_def*, rtx_def const*, void*), void*)
/repo/gcc-trunk/gcc/simplify-rtx.c:479
0x107e690 propagate_for_debug(rtx_insn*, rtx_insn*, rtx_def*, rtx_def*,
basic_block_def*)
/repo/gcc-trunk/gcc/valtrack.c:219
0x13653a8 try_combine
/repo/gcc-trunk/gcc/combine.c:4557
0x136a789 combine_instructions
/repo/gcc-trunk/gcc/combine.c:1461
0x136a789 rest_of_handle_combine
/repo/gcc-trunk/gcc/combine.c:15066
0x136a789 execute
/repo/gcc-trunk/gcc/combine.c:15111
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/91901] unchanged stack array not optimized away in favor off constant pool entry

[trass3r at gmail dot com]

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

--- Comment #2 from Trass3r  ---
(In reply to Richard Biener from comment #1)
> The compiler doesn't know that printf doesn't modify the data you pass it to
> so it cannot elide the automatic variable.

Does it matter in this case? The data comes from constexpr arrays.

constexpr auto names = strings(range_v); // aka const
std::array
return names[i];

And the name_v strings are deduced as const static_string<3>.

[Bug tree-optimization/91909] [10 regression] gcc.dg/vect/vect-cond-4.c fails on armeb after r275898

[rsandifo at gcc dot gnu.org]

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

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Created attachment 46948
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46948&action=edit
Candidate patch

The attached patch seems to fix it.  Will give it a bit more testing.

[Bug c++/69718] [concepts] cc1plus segfault on invalid

[jeff.chapman.bugs at gmail dot com]

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

Jeff Chapman  changed:

   What|Removed |Added

 CC||jeff.chapman.bugs at gmail dot 
com

--- Comment #1 from Jeff Chapman  ---
Created attachment 46949
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46949&action=edit
Patch against concepts-cxx2a to add test (git format-patch format)

This no longer segfaults on concepts-cxx2a. However, it's unclear whether there
was a different issue before being mechanically reduced.

Patch adds a test for the PR. Is there a more direct way to express "source
should successfully fail to compile"?

[Bug c++/70862] [concepts] adding a concept-constrained version of a variable template causes multiple definition assembler error

[jeff.chapman.bugs at gmail dot com]

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

Jeff Chapman  changed:

   What|Removed |Added

 CC||jeff.chapman.bugs at gmail dot 
com

--- Comment #5 from Jeff Chapman  ---
Created attachment 46950
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46950&action=edit
Patch against concepts-cxx2a to add test (git format-patch format)

This appears to be fixed on concepts-cxx2a. Patch adds a test for the PR.

[Bug driver/69471] "-march=native" unintentionally breaks further -march/-mtune flags

[ktkachov at gcc dot gnu.org]

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

--- Comment #13 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Thu Sep 26 10:52:42 2019
New Revision: 276148

URL: https://gcc.gnu.org/viewcvs?rev=276148&root=gcc&view=rev
Log:
driver: Also prune joined switches with negation

When -march=native is passed to host_detect_local_cpu to the backend,
it overrides all command lines after it.  That means

$ gcc -march=native -march=armv8-a

is treated as

$ gcc -march=armv8-a -march=native

Prune joined switches with Negative and RejectNegative to allow
-march=armv8-a to override previous -march=native on command-line.

This is the same fix as was applied for i386 in SVN revision 269164 but for
aarch64 and arm.

2019-09-26  Matt Turner  

PR driver/69471
* config/aarch64/aarch64.opt (march=): Add Negative(march=).
(mtune=): Add Negative(mtune=).
(mcpu=): Add Negative(mcpu=).
* config/arm/arm.opt: Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.opt
trunk/gcc/config/arm/arm.opt

[Bug tree-optimization/91909] [10 regression] gcc.dg/vect/vect-cond-4.c fails on armeb after r275898

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  ---
On Thu, 26 Sep 2019, rsandifo at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91909
> 
> --- Comment #3 from rsandifo at gcc dot gnu.org  
> ---
> Created attachment 46948
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46948&action=edit
> Candidate patch
> 
> The attached patch seems to fix it.  Will give it a bit more testing.

LTGM.

Richard.

[Bug target/91912] [9/10 Regression] ICE in lra_set_insn_recog_data, at lra.c:1004

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.4

[Bug tree-optimization/18374] [meta-bug] Argument and return value marshalling at tree level

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #5 from Nathan Sidwell  ---
yeah, this appears solved.

[Bug target/91913] [8/9/10 Regression] ICE in extract_constrain_insn, at recog.c:2211

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.4

[Bug libstdc++/87858] Building old multilib bootstrap GCC: stage1 32-bit libstdc++ fails to build after building 64-bit libstdc++

[mkrupcale at matthewkrupcale dot com]

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

--- Comment #2 from Matthew Krupcale  ---
I can confirm that I'm still observing this when building multilib bootstrap
GCC 4.8.3 using GCC 9.2.1 on Fedora 30[1,2]. I tried to verify this issue when
building GCC 6.4.1 (GLIBCXX_3.4.22, CXXABI_1.3.10), but it looks like it may
not require ABI from GCC 9.2.1 (i.e. GLIBCXX_3.4.26, CXXABI_1.3.11) and thus
does not fail in this way. So this likely is currently only observable when
building GCC < 5 which does not have CXXABI_1.3.9 with GCC >= 5. However, this
could change in the future if the host executables e.g. cc1{,plus}, lto1 ever
use features which change ABI.

Is it possible to verify that this is an issue on a theoretical level? When I
mentioned the issue on IRC, there was uncertainty as to how this situtation
would arise because it was suspected that the stage1 host programs already used
the build libstdc++. However, I do not believe this is the case because the
current Makefile adds at all stages the target libstdc++ to LD_LIBRARY_PATH and
thus ends up using the target libstdc++ (after it has been built) during stage1
target modules section, despite the fact that the stage1 host programs depend
on the build libstdc++. The above patches try to fix this.

Is there any additional information I can provide to help confirm or refute
this issue?

[1] https://copr.fedorainfracloud.org/coprs/mkrupcale/gcc/build/1040355/
[2] https://copr.fedorainfracloud.org/coprs/mkrupcale/gcc/build/1040368/

[Bug c/91915] New warning for duplicate if condition in if-elseif-elseif chain

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
I already implemented such a warning in r228388:

w.c: In function ‘foo’:
w.c:11:17: warning: duplicated ‘if’ condition [-Wduplicated-cond]
   11 |   else if (argc == 1)
  |~^~~~
w.c:6:12: note: previously used here
6 |   if (argc == 1)
  |   ~^~~~

[Bug c++/91889] [10 Regression] error: call of overloaded ‘to_value_ptr(B*&)’ is ambiguous

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |SUSPENDED

--- Comment #9 from Marek Polacek  ---
I'll raise it with CWG; suspending until then.

[Bug libgomp/91917] New: OpenACC 'acc_set_cuda_stream' return type

[tschwinge at gcc dot gnu.org]

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

Bug ID: 91917
   Summary: OpenACC 'acc_set_cuda_stream' return type
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

OpenACC 2.7, A.2.1. "NVIDIA CUDA Platform" currently specifies:

'acc_set_cuda_stream'
Summary The 'acc_set_cuda_stream' routine sets the NVIDIA CUDA stream
handle [of] the
current device for the specified async value.
Format
C or C++:
int acc_set_cuda_stream ( int async, void* stream );

Note that this is specified to return an 'int' but doesn't specify what these
'int' values would mean.  (And indeed there is no sensible information to be
returned from this function.)

The above matches our declaration in .  The PGI implementation on
the other hand has always provided this function with a 'void' return type
instead of 'int'.

The suggestion is now to adjust the OpenACC specification to match that: 'void'
return type.  (I conceptually agree.)

Jakub, will it be OK to just change GCC's  declaration and
implementation accordingly (given that it hasn't been specified, no user can
have any expectations about the 'int' value returned), or are the ABI concerns
(which can be resolved by introducing a new symbol version?), or even any other
concerns?

[Bug c/91918] New: Const pointer argument to atomic_compare_exchange doesn't cause an error.

[mq at ucw dot cz]

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

Bug ID: 91918
   Summary: Const pointer argument to atomic_compare_exchange
doesn't cause an error.
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mq at ucw dot cz
  Target Milestone: ---

Passing second argument (desired) to atomic_compare_exchange as const pointer
doesn'ŧ cause an error and silently segfaults, as in this code.

#include 
static const int desired = 42;
static _Atomic int data = 0;

int main(void) {
  atomic_compare_exchange_weak(&data, &desired, 64);
}

[Bug c/91918] Const pointer argument to atomic_compare_exchange doesn't cause an error.

[mq at ucw dot cz]

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

--- Comment #2 from Maria Matejka  ---
Created attachment 46952
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46952&action=edit
generated assembler code

[Bug c/91918] Const pointer argument to atomic_compare_exchange doesn't cause an error.

[mq at ucw dot cz]

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

--- Comment #1 from Maria Matejka  ---
Created attachment 46951
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46951&action=edit
preprocessed source file

[Bug c/91918] Const pointer argument to atomic_compare_exchange doesn't cause an error.

[mq at ucw dot cz]

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

--- Comment #3 from Maria Matejka  ---
Created attachment 46953
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46953&action=edit
Compiler output on gcc -v -save-temps

[Bug c/91918] Const pointer argument to atomic_compare_exchange doesn't cause an error.

[mq at ucw dot cz]

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

--- Comment #4 from Maria Matejka  ---
This bug applies also on v9.2.0.

[Bug c++/91889] [10 Regression] error: call of overloaded ‘to_value_ptr(B*&)’ is ambiguous

[sje at gcc dot gnu.org]

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

--- Comment #10 from Steve Ellcey  ---
(In reply to Marek Polacek from comment #9)
> I'll raise it with CWG; suspending until then.

Not sure if it matters but there seem to be 8 instances of this problem in
Boost (get_color, get_left, get_next, get_parent, get_previous, get_right,
to_hook_ptr, and to_value_ptr).  The actual number of errors you get during a
boost build is much higher due to hitting these overload issues numerous times
during the build.

[Bug c++/91369] Implement P0784R7: constexpr new

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
(In reply to Jakub Jelinek from comment #6)
> So, is the [class.dtor]/9 note just incorrect and should be removed, or
> clarified somehow?  I believe it shouldn't affect what actually is a literal
> type or not, because the constructor of a class without virtual bases which
> has a non-static data member that has virtual bases can't be constexpr either.

I think a virtual base just shouldn't make the destructor non-constexpr, which
would make the note correct.  I've emailed CWG to that effect.

[Bug c++/91889] [10 Regression] error: call of overloaded ‘to_value_ptr(B*&)’ is ambiguous

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|SUSPENDED   |NEW

--- Comment #11 from Jason Merrill  ---
(In reply to Marek Polacek from comment #7)
> Maybe the ranking needs additional wording, thus input from CWG.

Indeed, that's what I was thinking about at in my comment on your patch for PR
91877.  I think until we have a way to rank these conversions the DR is broken.
 I also think the obvious fix is to treat the reference binding as having an
implicit qualification conversion for purposes of comparison.

I'd also leave this PR open, not suspended; this is in fact a GCC 10
regression.

[Bug c++/91889] [10 Regression] error: call of overloaded ‘to_value_ptr(B*&)’ is ambiguous

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #12 from Marek Polacek  ---
ACK, will work on that.

[Bug target/91919] New: [10 Regression] arm-linux-eabi ICE with building kernel

[law at redhat dot com]

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

Bug ID: 91919
   Summary: [10 Regression] arm-linux-eabi ICE with building
kernel
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: law at redhat dot com
  Target Milestone: ---

> commit fa761b10d40aaa71e62fbc0c9f2ab8fc07a98b49 (HEAD, refs/bisect/bad)
> Author: wilco 
> Date:   Wed Sep 18 18:33:30 2019 +
>
> [ARM] Cleanup 64-bit multiplies
> 
> Cleanup 64-bit multiplies.  Combine the expanders using iterators.
> Merge the signed/unsigned multiplies as well as the pre-Armv6 and Armv6
> variants.  Split DImode operands early into parallel sets inside the
> MULL/MLAL instructions - this improves register allocation and avoids
> subreg issues due to other DImode operations splitting early.
> 
> gcc/
> * config/arm/arm.md (maddsidi4): Remove expander.
> (mulsidi3adddi): Remove pattern.
> (mulsidi3adddi_v6): Likewise.
> (mulsidi3_nov6): Likewise.
> (mulsidi3_v6): Likewise.
> (umulsidi3): Remove expander.
> (umulsidi3_nov6): Remove pattern.
> (umulsidi3_v6): Likewise.
> (umulsidi3adddi): Likewise.
> (umulsidi3adddi_v6): Likewise.
> (mulsidi3): Add combined expander.
> (maddsidi4): Likewise.
> (mull): Add combined umull and smull pattern.
> (mlal): Likewise.
> * config/arm/iterators.md (Us): Add new iterator.

Is causing the linux kernel to fail to build for arm-linux-gnueabi.

-O2 with this testcase:

__extension__ typedef unsigned long long __u64;
typedef __u64 u64;
static inline unsigned long
__timespec64_to_jiffies (u64 sec, long nsec)
{
  return ((sec *
   ((unsigned
 long) u64) 10L << (32 - 7)) +
 ((10L + 100 / 2) / 100) -
 1) / (u64) ((10L + 100 / 2) / 100 +
  (((u64) nsec *
((unsigned
  long) u64) 1 << ((32 - 7) + 29)) +
  ((10L + 100 / 2) / 100) -
  1) / (u64) ((10L + 100 / 2) / 100 >>
(((32 -

 7) +

29) -

(32 -

7
>> (32 - 7);
}

unsigned long
__timespec_to_jiffies (unsigned long sec, long nsec)
{
  return __timespec64_to_jiffies ((u64) sec, nsec);
}


(insn 14 13 16 2 (parallel [
(set (reg:SI 132)
(plus:SI (mult:SI (zero_extend:DI (reg/v:SI 115 [ sec ]))
(zero_extend:DI (reg:SI 124)))
(reg:SI 130)))
   ...)

Jakub noted the mode of the mult is SImode, while the operands are DImode. 
That's not valid RTL.

[Bug tree-optimization/91914] [9 Regression] Invalid strlen optimization

[msebor at gcc dot gnu.org]

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

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  ---
I was reluctant to backport the fix for pr91490 to GCC 9 because although it
eliminates some false positives it introduces new true ones that didn't exist
before.  Maybe that's okay.  If not, the simple change below appears to both
avoid the false positive and the unintended folding:

Index: gcc/expr.c
===
--- gcc/expr.c  (revision 276151)
+++ gcc/expr.c  (working copy)
@@ -11556,7 +11556,7 @@ string_constant (tree arg, tree *ptr_offset, tree

   base_off = wioff.to_uhwi ();
   unsigned HOST_WIDE_INT fieldoff = 0;
-  init = fold_ctor_reference (NULL_TREE, init, base_off, 0, array,
+  init = fold_ctor_reference (TREE_TYPE (arg), init, base_off, 0, array,
  &fieldoff);
   HOST_WIDE_INT cstoff;
   if (!base_off.is_constant (&cstoff))

[Bug c/91915] New warning for duplicate if condition in if-elseif-elseif chain

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
(In reply to Marek Polacek from comment #2)
> I already implemented such a warning in r228388:
> 
> w.c: In function ‘foo’:
> w.c:11:17: warning: duplicated ‘if’ condition [-Wduplicated-cond]
>11 |   else if (argc == 1)
>   |~^~~~
> w.c:6:12: note: previously used here
> 6 |   if (argc == 1)
>   |   ~^~~~

so in that case this would be bug 87656

[Bug c/91918] Const pointer argument to atomic_compare_exchange doesn't cause an error.

[joseph at codesourcery dot com]

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

--- Comment #5 from joseph at codesourcery dot com  ---
In general this sort of thing is undefined behavior under 7.1.4.  It's 
valid to give an error in this case (as the types are wrong), but it's 
liable to be hard to do so in all cases for generic functions implemented 
using macros.  In this case an error could probably be achieved reliably 
by implementing stricter checks for the arguments to the 
__atomic_compare_exchange built-in function.

[Bug tree-optimization/91914] [9 Regression] Invalid strlen optimization

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Thu Sep 26 16:17:22 2019
New Revision: 276156

URL: https://gcc.gnu.org/viewcvs?rev=276156&root=gcc&view=rev
Log:
PR tree-optimization/91914 - Invalid strlen folding for offset into struct

gcc/testsuite/CHangeLog:
* gcc.dg/strlenopt-79.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/strlenopt-79.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug libgomp/91917] OpenACC 'acc_set_cuda_stream' return type

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-26
 Ever confirmed|0   |1

--- Comment #1 from Thomas Schwinge  ---
Jakub confirmed:

| I'm not aware of any target that supports OpenMP/OpenACC that would
| have different calling conventions between something that returns int and
| void if the return value is ignored.
| So, if OpenACC standard changes it, no concern.

[Bug c/91920] New: ggc 9.2.0 failing openmp compile on ppc64le

[robert at robbieab dot com]

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

Bug ID: 91920
   Summary: ggc 9.2.0 failing openmp compile on ppc64le
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: robert at robbieab dot com
  Target Milestone: ---

Created attachment 46954
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46954&action=edit
The minimal test-case C file i used.

Compiling the attached program with "gcc -fopenmp" failes with the following
error on my ppc64le platform:
---
$ gcc -fopenmp test-openmp.c 
test-openmp.c: In function ‘testfunc’:
test-openmp.c:10:15: error: ‘*.LC0’ not specified in enclosing ‘parallel’
   10 | float k[3] = { 0.1f, 0.1f, 0.1f } ;
  |   ^
test-openmp.c:7:9: error: enclosing ‘parallel’
7 | #pragma omp parallel for default(none) shared(f)
  | ^~~
---

This errors does not appear if the 0.1f values are replaced with 0.0f in the
k[3] array.

gcc details:
---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/powerpc64le-unknown-linux-gnu/9.2.0/lto-wrapper
Target: powerpc64le-unknown-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-9.2.0-r1/work/gcc-9.2.0/configure
--host=powerpc64le-unknown-linux-gnu --build=powerpc64le-unknown-linux-gnu
--prefix=/usr --bindir=/usr/powerpc64le-unknown-linux-gnu/gcc-bin/9.2.0
--includedir=/usr/lib/gcc/powerpc64le-unknown-linux-gnu/9.2.0/include
--datadir=/usr/share/gcc-data/powerpc64le-unknown-linux-gnu/9.2.0
--mandir=/usr/share/gcc-data/powerpc64le-unknown-linux-gnu/9.2.0/man
--infodir=/usr/share/gcc-data/powerpc64le-unknown-linux-gnu/9.2.0/info
--with-gxx-include-dir=/usr/lib/gcc/powerpc64le-unknown-linux-gnu/9.2.0/include/g++-v9
--with-python-dir=/share/gcc-data/powerpc64le-unknown-linux-gnu/9.2.0/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 9.2.0-r1 p2' --disable-esp --enable-libstdcxx-time
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --disable-multilib --enable-altivec --disable-fixed-point
--enable-targets=all --enable-libgomp --disable-libmudflap --disable-libssp
--disable-systemtap --disable-vtable-verify --disable-libvtv --enable-lto
--with-isl --disable-isl-version-check --enable-default-pie
--enable-default-ssp
Thread model: posix
gcc version 9.2.0 (Gentoo 9.2.0-r1 p2) 
---

This problem does not appear to happen on my x86_64 system.

[Bug c/91920] ggc 9.2.0 failing openmp compile on ppc64le

[robert at robbieab dot com]

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

--- Comment #1 from robert at robbieab dot com ---
Created attachment 46955
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46955&action=edit
Preprocessed copy of test-openmp.c

[Bug c/91920] ggc 9.2.0 failing openmp compile on ppc64le

[gcc at octaforge dot org]

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

Daniel Kolesa  changed:

   What|Removed |Added

 CC||gcc at octaforge dot org

--- Comment #2 from Daniel Kolesa  ---
confirmed, same here

[Bug tree-optimization/91896] [10 Regression] ICE in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:1687

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Thu Sep 26 16:54:51 2019
New Revision: 276158

URL: https://gcc.gnu.org/viewcvs?rev=276158&root=gcc&view=rev
Log:
2019-09-25  Richard Biener  

PR tree-optimization/91896
* tree-vect-loop.c (vectorizable_reduction): The single
def-use cycle optimization cannot apply when there's more
than one pattern stmt involved.

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

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

[Bug target/91897] Very poor optimization on large attribute vector_size

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||10.0
 Resolution|--- |FIXED

--- Comment #5 from Richard Biener  ---
Fixed on trunk.

[Bug target/87243] FSF GCC needs to do something special (like using xcrun) on darwin18 to find system headers in SDK

[ken.cunningham.webuse at gmail dot com]

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

Ken Cunningham  changed:

   What|Removed |Added

 CC||ken.cunningham.webuse@gmail
   ||.com

--- Comment #6 from Ken Cunningham  ---
I would suggest that, if not using xcrun (which I understand completely), then
some replication of the logic it uses in darwin's driver would make sense.

An knowledgeable person explained this to me regarding how xcrun finds the SDK:

If -isysroot is on the command line, it is used. Otherwise ...
If system headers are installed, they are used (no sysroot is set). Otherwise
...
If xcrun finds a major-version matching SDK in the selected in
/Library/Developer/SDKs, it will use it. Otherwise ...
If xcrun finds a macosx SDK in the selected Xcode.app or in
/Library/Developer/SDKs, it will use it.
xcrun does not explicitly set the command line arguments. It sets the SDKROOT
envvar, which CFE honors as the default isysroot if set.


This was later updated to change the SDK search path to
/Library/Developer/CommandLineTools/SDKs, which is the one that is working now
on 10.14.

The only thing I would add to that would be that it would probably be quite
desirable to have ${SDKROOT} respected if it has been set by the user, so a
specific SDK can be forced globally.

The way the CFE then uses the ${SDKROOT} internally is here:

https://clang.llvm.org/doxygen/Darwin_8cpp_source.html

[Bug c++/91921] New: Incomplete -Woverloaded-virtual warning when base class is in system header

[andrey.vihrov at gmail dot com]

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

Bug ID: 91921
   Summary: Incomplete -Woverloaded-virtual warning when base
class is in system header
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrey.vihrov at gmail dot com
  Target Milestone: ---

Compiling the following preprocessed source:

  # 1 "foo.h" 3
  struct A
  {
virtual void f();
  };

  # 1 "bar.h"
  struct B : A
  {
void f(int);
  };

with "g++ -c test.ii -Woverloaded-virtual" gives

  bar.h:3:8: warning:   by 'void B::f(int)' [-Woverloaded-virtual]

The first part of the warning is missing.

[Bug c++/91921] Incomplete -Woverloaded-virtual warning when base class is in system header

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-26
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug c++/91921] Incomplete -Woverloaded-virtual warning when base class is in system header

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Looks trivial.

[Bug target/91829] compatibility.cc: syntax error lea (%pc, _GLOBAL_OFFSET_TABLE@GOTPC), a4 ignored

[forkenmasterforce at keemail dot me]

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

Jon Daniel  changed:

   What|Removed |Added

URL||https://cygwin.com/ml/cross
   ||gcc/2001-10/msg00050.html

--- Comment #1 from Jon Daniel  ---
https://cygwin.com/ml/crossgcc/2001-10/msg00050.html

[Bug c++/91369] Implement P0784R7: constexpr new

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #46946|0   |1
is obsolete||

--- Comment #8 from Jakub Jelinek  ---
Created attachment 46956
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46956&action=edit
gcc10-pr91369.patch

Updated patch.
This patch implements the state if C++ drops the note that trivial destructors
are constexpr destructors.  If on the core reflector you agree on something
else, please let me know and I'll change it.
Other than that, I need to finish up the cookie_size support for array new
(trying to represent that heap object as record with two fields, sizetype array
covering cookie and class_type array covering the rest, but seems indirect ref
folding isn't still happy about that, otherwise I'm out of ideas what else to
test.

[Bug target/91829] compatibility.cc: syntax error lea (%pc, _GLOBAL_OFFSET_TABLE@GOTPC), a4 ignored

[forkenmasterforce at keemail dot me]

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

--- Comment #2 from Jon Daniel  ---
Enabling only the COLDFIRE section in load_got seems to fix the compilation
problem even without a coldfire cpu target.
I'll try to figure out which lea move.l combo to use for a specific motorola
target cpu.

[Bug target/91919] [10 Regression] arm-linux-eabi ICE with building kernel

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Created attachment 46957
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46957&action=edit
gcc10-pr91919.patch

I can provide this untested patch that fixes the testcase in a cross-compiler,
but can't easily test it on the trunk.

[Bug target/91919] [10 Regression] arm-linux-eabi ICE with building kernel

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-26
 CC||ktkachov at gcc dot gnu.org,
   ||wilco at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug target/91903] vec_ctf altivec intrinsic can cause ICE on powerpc

[murphyp at linux dot vnet.ibm.com]

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

--- Comment #2 from Paul E. Murphy  ---
I tried this out on IBM's new AT13 compiler (GCC 9.2.1):

/opt/at13.0/bin/powerpc64le-linux-gnu-gcc -c test.c 
during RTL pass: expand
test.c: In function ‘test’:
test.c:5:5: internal compiler error: in copy_to_mode_reg, at explow.c:629
5 | ret = vec_ctf(a,b);
  | ^~
0x735d8b copy_to_mode_reg(machine_mode, rtx_def*)
   
/build/at13.0_RHEL8_x86_64-ppc64le/11/at13.0-0.redhat-8_x86_64_ppc64le/sources/gcc/gcc/explow.c:629
0xca0c21 rs6000_expand_binop_builtin
   
/build/at13.0_RHEL8_x86_64-ppc64le/11/at13.0-0.redhat-8_x86_64_ppc64le/sources/gcc/gcc/config/rs6000/rs6000.c:13787
0xcd0732 rs6000_expand_builtin
   
/build/at13.0_RHEL8_x86_64-ppc64le/11/at13.0-0.redhat-8_x86_64_ppc64le/sources/gcc/gcc/config/rs6000/rs6000.c:16619
0x64158c expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
   
/build/at13.0_RHEL8_x86_64-ppc64le/11/at13.0-0.redhat-8_x86_64_ppc64le/sources/gcc/gcc/builtins.c:7236
0x74c180 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
   
/build/at13.0_RHEL8_x86_64-ppc64le/11/at13.0-0.redhat-8_x86_64_ppc64le/sources/gcc/gcc/expr.c:11030
0x755bca store_expr(tree_node*, rtx_def*, int, bool, bool)
   
/build/at13.0_RHEL8_x86_64-ppc64le/11/at13.0-0.redhat-8_x86_64_ppc64le/sources/gcc/gcc/expr.c:5674
0x756bd0 expand_assignment(tree_node*, tree_node*, bool)
   
/build/at13.0_RHEL8_x86_64-ppc64le/11/at13.0-0.redhat-8_x86_64_ppc64le/sources/gcc/gcc/expr.c:5436
0x660440 expand_call_stmt
   
/build/at13.0_RHEL8_x86_64-ppc64le/11/at13.0-0.redhat-8_x86_64_ppc64le/sources/gcc/gcc/cfgexpand.c:2722
0x660440 expand_gimple_stmt_1
   
/build/at13.0_RHEL8_x86_64-ppc64le/11/at13.0-0.redhat-8_x86_64_ppc64le/sources/gcc/gcc/cfgexpand.c:3691
0x660440 expand_gimple_stmt
   
/build/at13.0_RHEL8_x86_64-ppc64le/11/at13.0-0.redhat-8_x86_64_ppc64le/sources/gcc/gcc/cfgexpand.c:3850
0x6650bf expand_gimple_basic_block
   
/build/at13.0_RHEL8_x86_64-ppc64le/11/at13.0-0.redhat-8_x86_64_ppc64le/sources/gcc/gcc/cfgexpand.c:5890
0x6676d6 execute
   
/build/at13.0_RHEL8_x86_64-ppc64le/11/at13.0-0.redhat-8_x86_64_ppc64le/sources/gcc/gcc/cfgexpand.c:6513
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug preprocessor/49973] Column numbers count multibyte characters as multiple columns

[lhyatt at gmail dot com]

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

--- Comment #18 from Lewis Hyatt  ---
(In reply to jos...@codesourcery.com from comment #17)
> On Tue, 17 Sep 2019, lhyatt at gmail dot com wrote:
> 
> > In any case, the underlying source of wcwidth() could easily be changed as a
> > drop-in replacement so I guess it can also be decided later. The use of
> > mbrtowc() is the bigger problem, since this converts from the user's locale 
> > and
> > it needs to convert from what -finput-charset asked for (or else UTF-8)
> > instead.
> 
> If __STDC_ISO_10646__ is defined, wchar_t is Unicode and so local code 
> converting from UTF-8 to wchar_t can be used (together with wcwidth from 
> libc if available).
> 
> If __STDC_ISO_10646__ is not defined, the encoding of wchar_t is unknown.  
> Maybe in that case it's best to avoid libc's wcwidth (if any) and just use 
> a local implementation of wcwidth on the results of converting UTF-8 to 
> Unicode code points.

It seems to erase a lot of complexity just to always use an internal wcwidth(),
so that's what I ended up doing. Patch was posted to
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01558.html for your
consideration. This one just addresses diagnostics, not the input-charset or
user locale conversion stuff. I will submit those separately after this one is
reviewed. Thanks!

[Bug target/91880] ICE: segfault in hwloop_optimize

[jcmvbkbc at gcc dot gnu.org]

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

--- Comment #4 from jcmvbkbc at gcc dot gnu.org ---
Author: jcmvbkbc
Date: Thu Sep 26 20:51:27 2019
New Revision: 276166

URL: https://gcc.gnu.org/viewcvs?rev=276166&root=gcc&view=rev
Log:
xtensa: fix PR target/91880

Xtensa hwloop_optimize segfaults when zero overhead loop is about to be
inserted as the first instruction of the function.
Insert zero overhead loop instruction into new basic block before the
loop when basic block that precedes the loop is empty.

2019-09-26  Max Filippov  
gcc/
* config/xtensa/xtensa.c (hwloop_optimize): Insert zero overhead
loop instruction into new basic block before the loop when basic
block that precedes the loop is empty.

gcc/testsuite/
* gcc.target/xtensa/pr91880.c: New test case.
* gcc.target/xtensa/xtensa.exp: New test suite.


Added:
trunk/gcc/testsuite/gcc.target/xtensa/
trunk/gcc/testsuite/gcc.target/xtensa/pr91880.c
trunk/gcc/testsuite/gcc.target/xtensa/xtensa.exp
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/xtensa/xtensa.c
trunk/gcc/testsuite/ChangeLog

[Bug c/91922] New: #pragma pack(push,4) does not align element on 32 bit boundary properly

[slightbody at ledroadwaylighting dot com]

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

Bug ID: 91922
   Summary: #pragma pack(push,4) does not align element on 32 bit
boundary properly
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slightbody at ledroadwaylighting dot com
  Target Milestone: ---

Created attachment 46958
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46958&action=edit
c source

The attached small main.c results in a Hard Fault on the line *p=x; when
compiled for the Cortex M0+ processor. The u32thing element of the structure
should be aligned on a 32bit boundary in memory due to the #pragma pack(push,4)
statement, but it is not.

It appears the compiler may be being confused by the pack(1) directive later in
the structure.

Compile line:
"D:\Atmel\Studio\7.0\toolchain\arm\arm-gnu-toolchain\bin\arm-none-eabi-gcc.exe"
 -x c -mthumb -D__SAMD21G18A__ -DNDEBUG 
-I"D:\Atmel\Studio\7.0\Packs\arm\cmsis\5.0.1\CMSIS\Include"
-I"D:\Atmel\Studio\7.0\Packs\atmel\SAMD21_DFP\1.3.304\samd21a\include"  -Os
-ffunction-sections -mlong-calls -Wall -mcpu=cortex-m0plus -c -std=gnu99 -MD
-MP -MF "main.d" -MT"main.d" -MT"main.o"   -o "main.o" ".././main.c" 

Snip of .map file (one_v) should be on a 32 bit aligned address:
 *(COMMON)
 COMMON 0x24500xa main.o
0x2450two
0x2454abc
0x2455one_v

[Bug target/91880] ICE: segfault in hwloop_optimize

[jcmvbkbc at gcc dot gnu.org]

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

jcmvbkbc at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from jcmvbkbc at gcc dot gnu.org ---
This is now fixed and a new regression test is added.

[Bug tree-optimization/91885] [9 Regression] ICE when compiling SPEC 2017 blender benchmark with -O3 -fprofile-generate

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #5 from Christophe Lyon  ---
(In reply to Martin Liška from comment #4)
> Fixed on trunk so far.

So new testcase fails on arm:
FAIL: gcc.dg/pr91885.c (test for excess errors)
Excess errors:
pr91885.c:13:17: warning: right shift count >= width of type
[-Wshift-count-overflow]
pr91885.c:13:34: warning: left shift count >= width of type
[-Wshift-count-overflow]
pr91885.c:18:12: warning: right shift count >= width of type
[-Wshift-count-overflow]
pr91885.c:18:52: warning: left shift count >= width of type
[-Wshift-count-overflow]

because the *int64_t types are not defined correctly for 32 bits targets.

[Bug tree-optimization/91885] [9 Regression] ICE when compiling SPEC 2017 blender benchmark with -O3 -fprofile-generate

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #6 from Rainer Orth  ---
(In reply to Christophe Lyon from comment #5)

> because the *int64_t types are not defined correctly for 32 bits targets.

Indeed:

typedef signed long int __int64_t;
typedef unsigned long int __uint64_t;

They should use long long/unsigned long long or (better yet)
__INT64_TYPE__/__UINT64_TYPE__

[Bug libbacktrace/91908] New libbacktrace tests fail to build

[ian at gcc dot gnu.org]

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

--- Comment #1 from ian at gcc dot gnu.org  ---
Author: ian
Date: Thu Sep 26 22:19:47 2019
New Revision: 276168

URL: https://gcc.gnu.org/viewcvs?rev=276168&root=gcc&view=rev
Log:
PR libbacktrace/91908
* pecoff.c (backtrace_initialize): Explicitly cast unchecked
__sync_bool_compare_and_swap to void.
* xcoff.c (backtrace_initialize): Likewise.

Modified:
trunk/libbacktrace/ChangeLog
trunk/libbacktrace/pecoff.c
trunk/libbacktrace/xcoff.c

[Bug rtl-optimization/91860] [10 Regression] ICE: in decompose, at rtl.h:2279 with -Og -fipa-cp -g --param=max-combine-insns=3

[wilson at gcc dot gnu.org]

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

--- Comment #5 from Jim Wilson  ---
The new testcase is essentially the same problem, but it is i1src this time not
i2src, so just copying i2src earlier doesn't solve the problem, we also need a
fix for i1src, or a fix elsewhere.

[Bug libbacktrace/91908] New libbacktrace tests fail to build

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ian at airs dot com
 Resolution|--- |FIXED

--- Comment #2 from Ian Lance Taylor  ---
Should be fixed on trunk.

[Bug libstdc++/91871] iterator_to_const_iterator() in testsuite_hooks.h causes valid -Wreturn-stack-address warnings with LLVM

[brooks at gcc dot gnu.org]

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

--- Comment #7 from Brooks Moses  ---
Thanks, Jonathan!  I've confirmed that this does indeed fix the warning with
Clang trunk, and the test passes again.

[Bug libbacktrace/91908] New libbacktrace tests fail to build

[dave.anglin at bell dot net]

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

--- Comment #3 from dave.anglin at bell dot net ---
On 2019-09-26 6:26 p.m., ian at airs dot com wrote:
> Should be fixed on trunk.
Thanks Ian.

[Bug ipa/89924] [missed-optimization] Function not de-virtualized within the same TU

[kamleshbhalui at gmail dot com]

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

--- Comment #6 from Kamlesh Kumar  ---
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01527.html

[Bug c++/91923] New: [9/10 Regression] Failure-to-SFINAE with class type NTTP in C++17

[Casey at Carter dot net]

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

Bug ID: 91923
   Summary: [9/10 Regression] Failure-to-SFINAE with class type
NTTP in C++17
   Product: gcc
   Version: 9.2.1
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 well-formed TU (https://godbolt.org/z/8HYWSC):

template
constexpr bool is_integral_(...) {
return false;
}
template
constexpr bool is_integral_(long) {
return true;
}

static_assert(is_integral_(42));
static_assert(!is_integral_(42));

struct S {};
static_assert(!is_integral_(42));

with -std=c++17 diagnoses:

: In substitution of 'template > constexpr
bool is_integral_(long int) [with T = S; T  = ]':
:14:34:   required from here
:5:26: error: non-type template parameters of class type only
available with '-std=c++2a' or '-std=gnu++2a'
5 | template
  |  ^
Compiler returned: 1

whereas earlier compiler versions (at least 6 though 8) accept the TU without
diagnostic.

This seems to simply be a case of adding the helpful new diagnostic but
forgetting to silence it in SFINAE context.

[Bug c++/91923] [9/10 Regression] Failure-to-SFINAE with class type NTTP in C++17

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-27
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Started with r265789.

[Bug c++/91923] [9/10 Regression] Failure-to-SFINAE with class type NTTP in C++17

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
This patch implements that suggestion:

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index e5d64989b32..bd8b2400b86 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -25233,7 +25233,7 @@ invalid_nontype_parm_type_p (tree type, tsubst_flags_t
complain)
 return false;
   else if (CLASS_TYPE_P (type))
 {
-  if (cxx_dialect < cxx2a)
+  if (cxx_dialect < cxx2a && (complain & tf_error))
{
  error ("non-type template parameters of class type only available "
 "with %<-std=c++2a%> or %<-std=gnu++2a%>");

[Bug libquadmath/91924] New: tgammal(- odd.5 ) has wrong sign

[tydeman at tybor dot com]

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

Bug ID: 91924
   Summary: tgammal(- odd.5 ) has wrong sign
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libquadmath
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tydeman at tybor dot com
  Target Milestone: ---

tgammal() of negative odd non-integers, e.g., -33.5, -37.5, -67.5, -69.5, ...
has the wrong sign.  It should be positive.

[Bug tree-optimization/91909] [10 regression] gcc.dg/vect/vect-cond-4.c fails on armeb after r275898

[clyon at gcc dot gnu.org]

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

--- Comment #5 from Christophe Lyon  ---
I confirm that the proposed patch fixed the problem for me.

[Bug c/91918] Const pointer argument to atomic_compare_exchange doesn't cause an error.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-27
 Ever confirmed|0   |1

[Bug target/91919] [10 Regression] arm-linux-eabi ICE with building kernel

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug c/91922] #pragma pack(push,4) does not align element on 32 bit boundary properly

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #1 from Richard Biener  ---
I don't think #pragma pack works on line granularity and we should probably
diagnose that somehow.  You have to resort to __attribute__((aligned))
(or C1x alignas).

[Bug c++/91923] [9/10 Regression] Failure-to-SFINAE with class type NTTP in C++17

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||8.2.0
   Target Milestone|--- |9.3