[Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast

[markrubn at yahoo dot com]

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

mark  changed:

   What|Removed |Added

 CC||markrubn at yahoo dot com

--- Comment #18 from mark  ---
I'd also like to request a GCC extension to allow reinterpret_cast in a
constexpr. Following are a question, a comment, and a use-case illustrating why
the extension is needed.

Question: I understand that using reinterpret_cast in a constexpr is disallowed
by the C++ standard. *Why* is it disallowed? The only reason I've seen stated
is that "reinterpret_cast may require runtime (hardware) support". That seems
plausible, but a constexpr static_cast from int to double, which requires a far
deeper understanding of the target architecture, is supported. I understand
that int-to-pointer conversion may involve widening, narrowing, or even more
complex and possibly inexpressible semantics (segmented/non-linear memory
architectures), but reinterpret_cast by definition is non-portable and error
prone. Its "use these bits as they are" semantics, with possible truncation or
zero-padding, seems to allow it to be used unambiguously in most normal cases.

Comment: GCC has never been "shy" about adding extensions. Some of them, like
__attribute__((fallthrough) becoming [[fallthrough]], have even eventually made
it into the standards.

Use-case:
It is common practice in embedded microcontrollers to access hardware resources
via reads and writes to specific, fixed memory addresses. I believe this is
generally understood but can provide much more detail if requested.

In addition, microcontrollers are usually very limited in terms of memory and
CPU speed. By using constexpr constructors, extern/static objects are compiled
pre-initialized in the .data segment, eliminating the memory needed for
pre-main() constructor code and the time to execute it.

In GCC 4.8.3, prior to the changes to make GCC standards-compliant as described
in this bug report, the following code would compile the object into .data
segment:

```
class C {
  public:
constexpr C(
unsigned* const u)
:   _u(u)
{}
void set() const { *_u = 0x87654321; }
  protected:
unsigned* const _u;
};

unsigned* const addr = reinterpret_cast(0x4000);
C   c(addr);

int main()
{
c.set();
}
```

Later versions compile the object into .bss, and also include C::C constructor
code. Attempts to force constexpr construction by changing the above to:

```
constexpr unsigned* const addr = reinterpret_cast(0x4000);
```

causes no change with 4.8.3 but results in a fatal "error: value ‘1073741824’
of type ‘unsigned int*’ is not a constant expression" in later versions.

The only workaround I know is to introduce an extra conversion method, which
will then again compile the object into .data with no runtime construction
required:

```
class Addr {
  public:
constexpr Addr(
unsigned const u_addr)
:   _u_addr(u_addr)
{}
void set() const { *_u() = 0x87654321; }
  protected:
volatile unsigned* _u() const { return
reinterpret_cast(_u_addr);}
unsigned const  _u_addr;
};

Addr addr(0x4000);

int main()
{
addr.set();
}
```

And of course none of this is needed when coding in C instead of C++. The
following struct is placed in .data without any workarounds being required:

```
struct Addr {
unsigned* const u;
};

void set(
struct Addr *a)
{
*(a->u) = 0x87654321;
}

struct Addr addr = { (unsigned*)0x4000 };

int main()
{
set(&addr);
}
```

I firmly believe that C++ offers important improvements over C, with few if any
disadvantages. Many in the embedded programming community feel otherwise ("C++
is obfuscated") and in this example the objection is valid.

Any comments, corrections, or responses -- much less a change so that
-fpermissive allows the reinterpret_cast -- would be welcome. Thank you.

[Bug target/65782] Assembly failure (invalid register for .seh_savexmm) with -O3 -mavx512f on mingw-w64

[ktietz at gcc dot gnu.org]

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

--- Comment #8 from Kai Tietz  ---
Hmm, that behavior of gcc seems to be indeed pretty bad. The SEH commands for
registers above index 15 (0..15) for xmm? are indeed undefined, and even worse,
can't be coded proper into the seh table correctly.
Anything above 16-byte size of ?mm registers, and anything above register index
15 has to be treated as call clobbered. But in anycase, the unwind information
has not to contain that information

[Bug c/93636] New: Incorrect diagnostic of a potential string overflow in strncat

[sebunger44 at gmail dot com]

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

Bug ID: 93636
   Summary: Incorrect diagnostic of a potential string overflow in
strncat
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sebunger44 at gmail dot com
  Target Milestone: ---

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

The following code produces an incorrect warning "specified bound 2 equals
source length". To the best of my understanding, there's nothing wrong with the
bound equalling the size of the source. It certainly has no bearing on whether
this call may or may not overflow the destination.

#include 

void f(char *dst)
{
   strncat(dst, "Hi", 2);
}

My system is an amd64 installation of Ubuntu 19.10. The following is the
command line used to produce the result and its output:

$ gcc -v -save-temps -Wall -Werror -c strncat-bug.c 
Using built-in specs.
COLLECT_GCC=gcc
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 9.2.1-9ubuntu2'
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-9
--program-prefix=x86_64-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-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--with-target-system-zlib=auto --enable-multiarch --disable-werror
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.2.1 20191008 (Ubuntu 9.2.1-9ubuntu2) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Werror' '-c' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/9/cc1 -E -quiet -v -imultiarch x86_64-linux-gnu
strncat-bug.c -mtune=generic -march=x86-64 -Wall -Werror -fpch-preprocess
-fasynchronous-unwind-tables -fstack-protector-strong -Wformat-security
-fstack-clash-protection -fcf-protection -o strncat-bug.i
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/9/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-linux-gnu/9/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/9/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Werror' '-c' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/9/cc1 -fpreprocessed strncat-bug.i -quiet
-dumpbase strncat-bug.c -mtune=generic -march=x86-64 -auxbase strncat-bug -Wall
-Werror -version -fasynchronous-unwind-tables -fstack-protector-strong
-Wformat-security -fstack-clash-protection -fcf-protection -o strncat-bug.s
GNU C17 (Ubuntu 9.2.1-9ubuntu2) version 9.2.1 20191008 (x86_64-linux-gnu)
compiled by GNU C version 9.2.1 20191008, GMP version 6.1.2, MPFR
version 4.0.2, MPC version 1.1.0, isl version isl-0.21-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C17 (Ubuntu 9.2.1-9ubuntu2) version 9.2.1 20191008 (x86_64-linux-gnu)
compiled by GNU C version 9.2.1 20191008, GMP version 6.1.2, MPFR
version 4.0.2, MPC version 1.1.0, isl version isl-0.21-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: dd54e5384b34908287640134d9f8a49c
strncat-bug.c: In function ‘f’:
strncat-bug.c:5:4: error: ‘strncat’ specified bound 2 equals source length
[-Werror=stringop-overflow=]
5 |strncat(dst, "Hi", 2);
  |^
cc1: all warnings being treated as errors

[Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast

[redi at gcc dot gnu.org]

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

--- Comment #19 from Jonathan Wakely  ---
The main reason is that reinterpret_cast subverts the type system. Constant
expressions have to be free of undefined behaviour, which is impossible to do
if arbitrary nonsense^W code that violates the type system is supported.

[Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast

[redi at gcc dot gnu.org]

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

--- Comment #20 from Jonathan Wakely  ---
(In reply to mark from comment #18)
> And of course none of this is needed when coding in C instead of C++. The
> following struct is placed in .data without any workarounds being required:

And doesn't exactly the same thing work fine in C++?

[Bug c++/93633] ICE on consteval virtual

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:81958cd6adf402a85dc7d21b43caac56fba0af21

commit r10-6533-g81958cd6adf402a85dc7d21b43caac56fba0af21
Author: Jakub Jelinek 
Date:   Sun Feb 9 12:32:22 2020 +0100

c++: Fix ICE during constexpr virtual call evaluation [PR93633]

The first (valid) testcase ICEs because for
  A *a = new B ();
  a->foo (); // virtual method call
we actually see &heap  and the "heap " objects don't have the class or
whatever else type was used in new expression, but an array type containing
one (or more of those for array new) and so when using TYPE_BINFO (objtype)
on it we ICE.
This patch handles this special case, and otherwise punts (as shown e.g. in
the second testcase, where because the heap object is already deleted,
we don't really want to allow it to be used.

2020-02-09  Jakub Jelinek  

PR c++/93633
* constexpr.c (cxx_eval_constant_expression): If obj is heap var with
ARRAY_TYPE, use the element type.  Punt if objtype after that is not
a class type.

* g++.dg/cpp2a/constexpr-new11.C: New test.
* g++.dg/cpp2a/constexpr-new12.C: New test.
* g++.dg/cpp2a/constexpr-new13.C: New test.

[Bug c++/93633] ICE on consteval virtual

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Fixed.

[Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast

[markrubn at yahoo dot com]

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

--- Comment #21 from mark  ---
(In reply to Jonathan Wakely from comment #19)
> The main reason is that reinterpret_cast subverts the type system.
> Constant expressions have to be free of undefined behaviour, which is
> impossible to do if arbitrary nonsense^W code that violates the type
> system is supported.
Sorry, I still don't understand. Yes, reinterpret_cast subverts the type
system. In this case that's intentional, as there's no other way (that I know)
to have an arbitrary class pointer to an arbitrary memory address. (I've tried
placement new without success.)

The behavior here is non-portable, but well defined. If it wasn't, the runtime
reinterpret_cast would also be undefined. Why are/should constant expressions
be different?


(In reply to Jonathan Wakely from comment #20)
> And doesn't exactly the same thing work fine in C++?
I don't understand the point. Yes, a C++ compiler will accept the C code. But
it will still be C, without the object-oriented advantages of C++ (the C code
has external functions taking struct pointers instead of instance methods, etc,
etc.) As I illustrated, it's impossible to have a C++ class with an unsigned*
const member pointing to an arbitrary memory address -- and still have the
object constexpr constructed/initialized in .data -- as it is in C.


BTW, I am very committed to strong type-safe system design. See my FOSS
repositories at https://github.com/thanks4opensource/regbits and
https://github.com/thanks4opensource/regbits_stm for examples. It is precisely
the inability to constexpr construct a class containing an Object* const
pointer (or, alternately, a reference) to an instantiation of the class
templates in those systems that led to this request -- the unsigned* examples I
used here were for minimal/clear illustration.

As always, I appreciate the feedback, and would welcome any solution within the
current standard that satisfied all the requirements I've laid out. I have
researched the topic online without finding anything other than the workaround
I described.

[Bug c/85957] i686: Integers appear to be different, but compare as equal

[vincent-gcc at vinc17 dot net]

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

--- Comment #15 from Vincent Lefèvre  ---
(In reply to Rich Felker from comment #14)
> It sounds like you misunderstand the standard's requirements on, and GCC's
> implementation of, FLT_EVAL_METHOD==2/excess-precision. The availability of
> registers does not in any way affect the result, because when expressions
> are evaluated with excess precision, any spills must take place in the
> format of float_t or double_t (long double) and are thereby transparent to
> the application.

The types float_t or double_t correspond to the evaluation format. Thus they
are equivalent to long double if FLT_EVAL_METHOD is 2 (see 7.12p2). And GCC
does not do spills in this format, as see in bug 323.

> With standards-conforming behavior, the rounding of an operation and of
> storage to an object of float/double type are discrete roundings and you can
> observe and handle the intermediate value between them. With -ffloat-store,
> every operation inherently has a double-rounding attached to it. This
> behavior is non-conforming

This is conforming as there is no requirement to keep intermediate results in
excess precision and range.

[Bug target/93637] New: [9/10 Regression] ICE: Segmentation fault (in force_operand)

[asolokha at gmx dot com]

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

Bug ID: 93637
   Summary: [9/10 Regression] ICE: Segmentation fault (in
force_operand)
   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: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-unknown-linux-gnu

gcc-10.0.1-alpha20200202 snapshot (g:b817be038d94c987e02c26ed2d81b6f2ebb5f97a)
and gcc 9.2.0 ICE when compiling the following testcase, reduced from
gcc/testsuite/gcc.dg/vect/pr65947-10.c, w/ -mavx -O3 --param
sccvn-max-alias-queries-per-access=3:

double
zl (void)
{
  int cf;
  double yp;
  double ev[] = {
0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 1.0, 1.0,
  };

  for (cf = 0; cf < sizeof (ev) / sizeof (ev[0]); ++cf)
if (ev[cf] == 0.0)
  yp = ev[cf];

  return yp;
}

% x86_64-unknown-linux-gnu-gcc-10.0.1 -mavx -O3 --param
sccvn-max-alias-queries-per-access=3 -c wyezqdy3.c
during RTL pass: expand
wyezqdy3.c: In function 'zl':
wyezqdy3.c:2:1: internal compiler error: Segmentation fault
2 | zl (void)
  | ^~
0xd88c6f crash_signal
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200202/work/gcc-10-20200202/gcc/toplev.c:328
0xa1d8f2 force_operand(rtx_def*, rtx_def*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200202/work/gcc-10-20200202/gcc/expr.c:7502
0x8f3fde expand_gimple_stmt_1
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200202/work/gcc-10-20200202/gcc/cfgexpand.c:3811
0x8f3fde expand_gimple_stmt
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200202/work/gcc-10-20200202/gcc/cfgexpand.c:3847
0x8f85aa expand_gimple_basic_block
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200202/work/gcc-10-20200202/gcc/cfgexpand.c:5887
0x8fa6de execute
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200202/work/gcc-10-20200202/gcc/cfgexpand.c:6542

[Bug fortran/93599] [9/10 regression] Bug in fortran asynchronous I/O wait function

[tkoenig at gcc dot gnu.org]

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

--- Comment #7 from Thomas Koenig  ---
Hi Jerry,

this is without Janne's patch (which, as far as I see, concerns
handling I/O when the threads have already started).

Regarding testing: I could not get the original test case to fail
on gcc135, a POWER9 machine.

[Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast

[redi at gcc dot gnu.org]

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

--- Comment #22 from Jonathan Wakely  ---
(In reply to mark from comment #21)
> The behavior here is non-portable, but well defined. If it wasn't, the
> runtime reinterpret_cast would also be undefined. Why are/should constant
> expressions be different?

https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion is a better place
to ask that. GCC's bugzilla is not the place for it.

> (In reply to Jonathan Wakely from comment #20)
> > And doesn't exactly the same thing work fine in C++?
> I don't understand the point. Yes, a C++ compiler will accept the C code.
> But it will still be C, without the object-oriented advantages of C++ (the C
> code has external functions taking struct pointers instead of instance
> methods, etc, etc.)

If you want member functions, this works fine:

struct Addr
{
unsigned* const u;

void set() const { *u = 0x87654321; }
};

struct Addr addr = { (unsigned*)0x4000 };

int main()
{
addr.set();
}


> As I illustrated, it's impossible to have a C++ class
> with an unsigned* const member pointing to an arbitrary memory address --
> and still have the object constexpr constructed/initialized in .data -- as
> it is in C.

See above.

[Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast

[redi at gcc dot gnu.org]

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

--- Comment #23 from Jonathan Wakely  ---
What you want (and what everybody I've seen asking for similar things) is to
give a compile-time constant value to a pointer. All that's needed for that is
an extension to provide a compile-time constant value to a pointer, not to
allow arbitrary reinterpret_casts in constexpr.

A more limited extension that solves the problem is a lot more reasonable.

[Bug c/70813] Wrong warning "'0' flag ignored with precision and ‘%d’ gnu_printf format"

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-09
 CC||danglin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from John David Anglin  ---
I observe the same warning.  Whether the '0' flag is ignored or not in this
situation is an issue for mpfr since r13457.

HP-UX treats this situation differently from glibc.  HP-UX ignores the flag and
glibc doesn't.

[Bug c++/93638] New: [concepts] Dependent names in requires clause reported as different types when function definition is not inline

[lyberta at lyberta dot net]

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

Bug ID: 93638
   Summary: [concepts] Dependent names in requires clause reported
as different types when function definition is not
inline
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lyberta at lyberta dot net
  Target Milestone: ---

This happens a lot but I can't pinpoint exact cases. Here's minimal repro for
one case:

#include 

template 
class A
{
using type = int;

template 
requires std::same_as
void Foo();
};

template 
template 
requires std::same_as::type, U>
void A::Foo()
{
}

error: no declaration matches 'void A::Foo()'

[Bug c/85957] i686: Integers appear to be different, but compare as equal

[bugdal at aerifal dot cx]

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

--- Comment #16 from Rich Felker  ---
> And GCC does not do spills in this format, as see in bug 323.

In my experience it seems to (assuming -fexcess-precision=standard), though I
have not done extensive testing. I'll check and follow up.

> This is conforming as there is no requirement to keep intermediate results in 
> excess precision and range.

Such behavior absolutely is non-conforming. The standard reads (5.2.4.2.2 ¶9):

"Except for assignment and cast (which remove all extra range and precision),
the values yielded by operators with floating operands and values subject to
the usual arithmetic conversions and of floating constants are evaluated to a
format whose range and precision may be greater than required by the type"

Note "are evaluated", not "may be evaluated depending on what spills the
compiler chooses to perform".

[Bug c/85957] i686: Integers appear to be different, but compare as equal

[bugdal at aerifal dot cx]

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

--- Comment #17 from Rich Felker  ---
And indeed you're right that GCC does it wrong. This can be seen from a minimal
example:

double g(),h();
double f()
{
return g()+h();
}

where gcc emits fstpl/fldp around the second call rather than fstpt/fldt.

So this is all even more broken that I thought. It looks like the only way to
get deterministic behavior from GCC right now is to get the wrong deterministic
behavior via -ffloat-store.

Note that libfirm/cparser gets the right result, emitting fstpt/fldt.

[Bug c/85957] i686: Integers appear to be different, but compare as equal

[bugdal at aerifal dot cx]

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

--- Comment #18 from Rich Felker  ---
It was just pointed out to me that this might be an invalid test since GCC
assumes (correctly or not) that the return value of a function does not have
excess precision. I'll see if I can make a better test.

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

[lhyatt at gmail dot com]

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

--- Comment #34 from Lewis Hyatt  ---
(In reply to Eric Gallager from comment #33)
> This is a big enough feature that it should probably get an entry in
> gcc-10/changes.html

I emailed a suggested patch to that effect here:
https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01667.html. I can commit if it
looks OK. Thanks!

[Bug c/85957] i686: Integers appear to be different, but compare as equal

[bugdal at aerifal dot cx]

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

--- Comment #19 from Rich Felker  ---
Test case provided by Szabolcs Nagy showing that GCC does seem to spill right
if it can't assume there's no excess precision to begin with:

double h();
double ff(double x, double y)
{
return x+y+h();
}

In theory this doesn't force a spill, but GCC seems to choose to do one, I
guess to avoid having to preserve two incoming values (although they're already
in stack slots that would be naturally preserved).

Here GCC 9.2 with -fexcess-precision=standard -O3 it emits fstpt/fldt.

[Bug c++/93639] New: [c++2a] Segfault on non type template parameter and consteval (master)

[raphael.grimm at kit dot edu]

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

Bug ID: 93639
   Summary: [c++2a] Segfault on non type template parameter and
consteval (master)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: raphael.grimm at kit dot edu
  Target Milestone: ---

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

I played around with some new features and encountered a segfault:

the exact version of GCC: 
commit b780f68e025b2cf5631183e199ebf672ea463af6

the system type:
$ uname -a
Linux i61nb061 4.15.0-76-generic #86-Ubuntu SMP Fri Jan 17 17:24:28 UTC
2020 x86_64 x86_64 x86_64 GNU/Linux

the options given when GCC was configured/built;
./configure"  \
-v  \
--build=x86_64-linux-gnu\
--host=x86_64-linux-gnu \
--target=x86_64-linux-gnu   \
--prefix="$install_dir" \
--enable-checking=release   \
--enable-languages=c,c++,fortran\
--disable-multilib  \
--program-suffix="-b780f68e025b2cf5631183e199ebf672ea463af6"


the complete command line that triggers the bug;
$ gcc-master test.cpp -std=c++2a -save-temps

the compiler output (error messages, warnings, etc.);
test.cpp:25:26: internal compiler error: Segmentation fault
   25 | using type = a;
  |  ^
0xc8980f crash_signal
/home/username/repos/build-gcc/gcc/gcc/toplev.c:328
0x673d73 resolve_args(vec*, int)
/home/username/repos/build-gcc/gcc/gcc/cp/call.c:4431
0x78513c do_class_deduction
/home/username/repos/build-gcc/gcc/gcc/cp/pt.c:28599
0x78513c do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
/home/username/repos/build-gcc/gcc/gcc/cp/pt.c:28732
0x7865cd convert_template_argument
/home/username/repos/build-gcc/gcc/gcc/cp/pt.c:8309
0x798db7 convert_template_argument
/home/username/repos/build-gcc/gcc/gcc/cp/pt.c:8082
0x798db7 coerce_template_parms
/home/username/repos/build-gcc/gcc/gcc/cp/pt.c:8813
0x79cbd9 lookup_template_class_1
/home/username/repos/build-gcc/gcc/gcc/cp/pt.c:9668
0x79dedc lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
/home/username/repos/build-gcc/gcc/gcc/cp/pt.c:10040
0x7b925d finish_template_type(tree_node*, tree_node*, int)
/home/username/repos/build-gcc/gcc/gcc/cp/semantics.c:3407
0x762265 cp_parser_template_id
/home/username/repos/build-gcc/gcc/gcc/cp/parser.c:16681
0x7624b7 cp_parser_class_name
/home/username/repos/build-gcc/gcc/gcc/cp/parser.c:23618
0x75f2e1 cp_parser_qualifying_entity
/home/username/repos/build-gcc/gcc/gcc/cp/parser.c:6738
0x75f2e1 cp_parser_nested_name_specifier_opt
/home/username/repos/build-gcc/gcc/gcc/cp/parser.c:6410
0x71 cp_parser_simple_type_specifier
/home/username/repos/build-gcc/gcc/gcc/cp/parser.c:18076
0x74d46c cp_parser_type_specifier
/home/username/repos/build-gcc/gcc/gcc/cp/parser.c:17734
0x760af2 cp_parser_type_specifier_seq
/home/username/repos/build-gcc/gcc/gcc/cp/parser.c:22307
0x75adb4 cp_parser_type_id_1
/home/username/repos/build-gcc/gcc/gcc/cp/parser.c:22124
0x75bf58 cp_parser_type_id
/home/username/repos/build-gcc/gcc/gcc/cp/parser.c:22203
0x75bf58 cp_parser_alias_declaration
/home/username/repos/build-gcc/gcc/gcc/cp/parser.c:19949
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/93639] [c++2a] Segfault on non type template parameter and consteval (master)

[raphael.grimm at kit dot edu]

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

--- Comment #1 from raphael grimm  ---
Created attachment 47803
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47803&action=edit
ii file

[Bug target/93637] [9/10 Regression] ICE: Segmentation fault (in force_operand)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-09
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |9.3
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r10-1305-gbab9de71b45df56e3ad90aa817d7e23ea79d726d.

[Bug target/93637] [9/10 Regression] ICE: Segmentation fault (in force_operand)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
I'll have a look.

[Bug c/93640] New: The write_only and read_write attributes can be mistyped due to invalid strncmp size argument

[dominik.b.czarnota+bugzilla at gmail dot com]

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

Bug ID: 93640
   Summary: The write_only and read_write attributes can be
mistyped due to invalid strncmp size argument
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominik.b.czarnota+bugzilla at gmail dot com
  Target Milestone: ---

Hey,

There is a small bug in gcc trunk (which I believe will be gcc 10).

The PoC code is below. This compiles while it should not, because there is no
'write_onlX' attribute:

```
 __attribute__ ((access (write_onlX, 1))) int foo (char*);

 __attribute__ ((access (read_writX, 1))) int bar (char*);

int foo(char* x) {
return sizeof(x) * 2;
}

int bar(char* x) {
return sizeof(x) * 2;
}
```

If we mistype it more, it will actually throw a compile error, so e.g. a
`write_onYX` and `read_wriYX` would trigger the following errors:

```
:1:2: error: attribute 'access' invalid mode 'write_onYX'; expected one
of 'read_only', 'read_write', or 'write_only'

1 |  __attribute__ ((access (write_onYX, 1))) int foo (char*);

  |  ^

:3:2: error: attribute 'access' invalid mode 'read_wriYX'; expected one
of 'read_only', 'read_write', or 'write_only'

3 |  __attribute__ ((access (read_wriYX, 1))) int bar (char*);

  |  ^

Compiler returned: 1
```

All this can be observed on https://godbolt.org/z/Pj-5vp


The issue comes from the code below (that can be seen e.g. here:
https://github.com/gcc-mirror/gcc/blob/8d9254fc8aa32619f640efb01cfe87cc6cdc9ce1/gcc/c-family/c-attribs.c#L4061-L4062)
from gcc/c-family/c-attribs.c#L4061-L4062 :

  const bool read_only = strncmp (ps, "read_only", 9) == 0;
  const bool write_only = strncmp (ps, "write_only", 9) == 0;
  if (!read_only && !write_only && strncmp (ps, "read_write", 9))

While the "read_only" string has indeed 9 characters (without the null byte)
both the "write_only" and "read_write" have a length of 10 and so the `strcnmp`
call misses the last byte of them.

This can be easily fixed by changing the size argument from 9 to 10 in those
two cases. I haven't filed a patch as it is more convenient to write this down
here through a web browser (than cloning repo, creating patch, sending e-mails
etc).

There are more, other cases like this which I haven't triaged fully. I will
report them anyway in another bug report.

[Bug c++/93639] [c++2a] Segfault on non type template parameter and consteval (master)

[raphael.grimm at kit dot edu]

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

--- Comment #2 from raphael grimm  ---
Created attachment 47804
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47804&action=edit
more minimal example also causing this error

test.cpp:23:28: internal compiler error: Segmentation fault
   23 | using type = a;
  |^
0xc8980f crash_signal
/home/raphael/repos/build-gcc/gcc/gcc/toplev.c:328
0x673d73 resolve_args(vec*, int)
/home/raphael/repos/build-gcc/gcc/gcc/cp/call.c:4431
0x78513c do_class_deduction
/home/raphael/repos/build-gcc/gcc/gcc/cp/pt.c:28599
0x78513c do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
/home/raphael/repos/build-gcc/gcc/gcc/cp/pt.c:28732
0x7865cd convert_template_argument
/home/raphael/repos/build-gcc/gcc/gcc/cp/pt.c:8309
0x798db7 convert_template_argument
/home/raphael/repos/build-gcc/gcc/gcc/cp/pt.c:8082
0x798db7 coerce_template_parms
/home/raphael/repos/build-gcc/gcc/gcc/cp/pt.c:8813
0x79cbd9 lookup_template_class_1
/home/raphael/repos/build-gcc/gcc/gcc/cp/pt.c:9668
0x79dedc lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
/home/raphael/repos/build-gcc/gcc/gcc/cp/pt.c:10040
0x7b925d finish_template_type(tree_node*, tree_node*, int)
/home/raphael/repos/build-gcc/gcc/gcc/cp/semantics.c:3407
0x762265 cp_parser_template_id
/home/raphael/repos/build-gcc/gcc/gcc/cp/parser.c:16681
0x7624b7 cp_parser_class_name
/home/raphael/repos/build-gcc/gcc/gcc/cp/parser.c:23618
0x75f2e1 cp_parser_qualifying_entity
/home/raphael/repos/build-gcc/gcc/gcc/cp/parser.c:6738
0x75f2e1 cp_parser_nested_name_specifier_opt
/home/raphael/repos/build-gcc/gcc/gcc/cp/parser.c:6410
0x71 cp_parser_simple_type_specifier
/home/raphael/repos/build-gcc/gcc/gcc/cp/parser.c:18076
0x74d46c cp_parser_type_specifier
/home/raphael/repos/build-gcc/gcc/gcc/cp/parser.c:17734
0x760af2 cp_parser_type_specifier_seq
/home/raphael/repos/build-gcc/gcc/gcc/cp/parser.c:22307
0x75adb4 cp_parser_type_id_1
/home/raphael/repos/build-gcc/gcc/gcc/cp/parser.c:22124
0x75bf58 cp_parser_type_id
/home/raphael/repos/build-gcc/gcc/gcc/cp/parser.c:22203
0x75bf58 cp_parser_alias_declaration
/home/raphael/repos/build-gcc/gcc/gcc/cp/parser.c:19949
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug other/93641] New: Wrong strncmp and strncasecmp size arguments

[dominik.b.czarnota+bugzilla at gmail dot com]

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

Bug ID: 93641
   Summary: Wrong strncmp and strncasecmp size arguments
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominik.b.czarnota+bugzilla at gmail dot com
  Target Milestone: ---

Hello,

There are several bugs where `strcnmp` function is used with a string literal
and size that doesn't match the string literal length without a null byte.

All of this was found on the following commit:
* 8e0efc103 - (grafted, HEAD -> master, origin/master, origin/HEAD) i386: Do
GNU2 TLS address computation in ptr_mode (3 weeks ago) 

I haven't triaged all those cases and I also reported two of them separately in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93640.

Below are those cases in the following format:

./gcc/config/i386/i386.c:  || strncmp(name, ".lbss.", 5) == 0
strlen=6, n=5
^-- either one of the strncmp used there is redundant or the 5 should be
changed to 6 here

./gcc/config/i386/i386.c:  || strncmp(name, ".gnu.linkonce.lb.", 16) == 0)
strlen=17, n=16
^-- it is in the same function as previous case: probably the 16 should be
changed to 17

./gcc/config/darwin-c.c:  && !strncmp(identifier_pointer (tn),
"CFStringRef", 8));
strlen=11, n=8
^-- e.g. a CFStringXYZ would be matched here.


./gcc/cp/error.c:  if (!strncmp(str, "_zgr", 3))
strlen=4, n=3
^-- should rather be 4

./gcc/doc/invoke.texi:
strncat(buf, ".txt", 3);strlen=4, n=3
^-- should rather be 4, though its in .texi files which I don't know what are
they for.

./gcc/c-family/c-format.c: && !strncasecmp(format_chars - 3,
"can%'t", 5)
strlen=6, n=5
^-- should rather be 6

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[peter.bisroev at groundlabs dot com]

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

--- Comment #147 from Peter Bisroev  ---
(In reply to The Written Word from comment #145)
> Created attachment 47799 [details]
> gcc-8.3.0 patches v2
> 
> v2 of our patch set.

Thank you The Written Word. However I still get an ICE failure with selftests
as before, although at a different place. I notice you said that you are
bootstrapping with 4.9.4 and I am with 4.7.4. I will try to get 4.9.4
bootstrapped with 4.7.4 and see if that makes any difference.

I will also try troubleshooting suggested by Dave.

Thanks!

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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

--- Comment #148 from The Written Word  
---
(In reply to The Written Word from comment #144)
> We have a build running that seems to be going well. We are using gcc-4.9.4
> to build 8.3.0. I will attach the current patch set we are building against.

We're running into the same issues as encountered in comment#74. I think this
is because of our patch to address PR66319 so I am attempting a build without
it. We will then probably run into the problem in comment#76 but I'll try to
fix that manually and continue the build.

[Bug c++/93642] New: [Coroutines] internal compiler error: in expand_expr_addr_expr_1, at expr.c:8070 using co_return

[wezrule at hotmail dot com]

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

Bug ID: 93642
   Summary: [Coroutines] internal compiler error: in
expand_expr_addr_expr_1, at expr.c:8070 using
co_return
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wezrule at hotmail dot com
  Target Milestone: ---

Created attachment 47805
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47805&action=edit
Preprocessed file

Using the master git branch from a couple days ago, HEAD is
c7c09af8ef0fe6671c7733d4d67bb73ecf10fc1b. gcc version 10.0.1 20200208
(experimental) (GCC).

I tried to make the code as small as possible while still being able to
reproduce the issue:

c.cpp
#include 

struct promise {
  auto initial_suspend() { return std::suspend_always{}; }
  auto final_suspend() noexcept { return std::suspend_always{}; }
  void unhandled_exception();
  auto get_return_object() { return
std::coroutine_handle::from_promise(*this); }
  void return_void();
};

class task {
public:
  using promise_type = promise;
  task(std::coroutine_handle handle);
};

task func ()
{
  co_return;
}

When using the build command:
g++ -fcoroutines -c c.pp

The following error is given:

during RTL pass: expand
c.cpp: In function ‘task func()’:
c.cpp:20:1: internal compiler error: in expand_expr_addr_expr_1, at expr.c:8070
   20 | }
  | ^
0x74435a expand_expr_addr_expr_1
../../gcc/expr.c:8070
0xcc7f24 expand_expr_addr_expr
../../gcc/expr.c:8183
0xcc7f24 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:11358
0xb8d959 expand_normal
../../gcc/expr.h:288
0xb8d959 precompute_register_parameters
../../gcc/calls.c:982
0xb97137 expand_call(tree_node*, rtx_def*, int)
../../gcc/calls.c:4397
0xcc7d5b expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:11130
0xba9509 expand_expr
../../gcc/expr.h:282
0xba9509 expand_call_stmt
../../gcc/cfgexpand.c:2703
0xba9509 expand_gimple_stmt_1
../../gcc/cfgexpand.c:3682
0xba9509 expand_gimple_stmt
../../gcc/cfgexpand.c:3847
0xbad843 expand_gimple_basic_block
../../gcc/cfgexpand.c:5887
0xbaf816 execute
../../gcc/cfgexpand.c:6542

I've attached the preprocessed file too. It is also reproducible on compiler
explorer on the coroutines branch https://godbolt.org/z/3L9bDu

[Bug c++/93642] [Coroutines] internal compiler error: in expand_expr_addr_expr_1, at expr.c:8070 using co_return

[wezrule at hotmail dot com]

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

--- Comment #1 from Wesley Shillingford  ---
Created attachment 47806
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47806&action=edit
Original file showing the issue

[Bug c++/93642] [Coroutines] internal compiler error: in expand_expr_addr_expr_1, at expr.c:8070 using co_return

[wezrule at hotmail dot com]

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

--- Comment #2 from Wesley Shillingford  ---
Not sure if I can edit my comment, but just realised the #include in the
original comment should be #include  not #include . The
attachments are fine though.

[Bug fortran/93635] Get ICE instead of error message if user incorrectly equivalences allocateable variables that are in a NAMELIST group

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-09
 CC||kargl at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
The problem is in symbol.c (gfc_check_conflict).  This check

   if (attr->in_namelist && (attr->allocatable || attr->pointer))
 {
   a1 = in_namelist;
   a2 = attr->allocatable ? allocatable : pointer;
   standard = GFC_STD_F2003;
   goto conflict_std;
 }

jumps to conflict_std, where an error may or may not be issued.
In either case, gfc_check_conflict returns without any futher
checking of other attributes.  There are four cases with the 
conflict_std jump.  This patch removes these jumps.  It causes
a regression with pr87907.f90 where a correct error is emitted,
which is then followed by bunch of run-on errors.  Removing the
of pr87907.f90 that leads to the run-on errors, then results in
a correct error message followed by an ICE.  Likely, the bug 
fix for pr87907.f90 needs to be re-evaluated.  Fortuantely, I 
use neither namelist nor equivalence, so have no skin in the 
game.  Someone else can complete the fix.

Index: gcc/fortran/symbol.c
===
--- gcc/fortran/symbol.c(revision 280157)
+++ gcc/fortran/symbol.c(working copy)
@@ -394,18 +395,35 @@ gfc_check_function_type (gfc_namespace *ns)

 / Symbol attribute stuff */

+/* Older standard produced conflicts for some attributes that are now
+   allowed in newer standards.  Check for the conflict and issue an
+   error depending on the standard in play.  */
+
+static bool
+conflict_std (int standard, const char *a1, const char *a2, const char *name,
+ locus *where)
+{
+  if (name == NULL)
+{
+  return gfc_notify_std (standard, "%s attribute conflicts "
+ "with %s attribute at %L", a1, a2,
+ where);
+}
+  else
+{
+  return gfc_notify_std (standard, "%s attribute conflicts "
+"with %s attribute in %qs at %L",
+ a1, a2, name, where);
+}
+}
+
+
+
 /* This is a generic conflict-checker.  We do this to avoid having a
single conflict in two places.  */

 #define conf(a, b) if (attr->a && attr->b) { a1 = a; a2 = b; goto conflict; }
 #define conf2(a) if (attr->a) { a2 = a; goto conflict; }
-#define conf_std(a, b, std) if (attr->a && attr->b)\
-  {\
-a1 = a;\
-a2 = b;\
-standard = std;\
-goto conflict_std;\
-  }

 bool
 gfc_check_conflict (symbol_attribute *attr, const char *name, locus *where)
@@ -438,7 +456,7 @@ gfc_check_conflict (symbol_attribute *attr, const char
"OACC DECLARE DEVICE_RESIDENT";

   const char *a1, *a2;
-  int standard;
+  bool standard;

   if (attr->artificial)
 return true;
@@ -450,16 +468,18 @@ gfc_check_conflict (symbol_attribute *attr, const char
 {
   a1 = pointer;
   a2 = intent;
-  standard = GFC_STD_F2003;
-  goto conflict_std;
+  standard = conflict_std (GFC_STD_F2003, a1, a2, name, where);
+  if (!standard)
+ return standard;
 }

   if (attr->in_namelist && (attr->allocatable || attr->pointer))
 {
   a1 = in_namelist;
   a2 = attr->allocatable ? allocatable : pointer;
-  standard = GFC_STD_F2003;
-  goto conflict_std;
+  standard = conflict_std (GFC_STD_F2003, a1, a2, name, where);
+  if (!standard)
+ return standard;
 }

   /* Check for attributes not allowed in a BLOCK DATA.  */
@@ -566,9 +586,31 @@ gfc_check_conflict (symbol_attribute *attr, const char
 return false;

   conf (allocatable, pointer);
-  conf_std (allocatable, dummy, GFC_STD_F2003);
-  conf_std (allocatable, function, GFC_STD_F2003);
-  conf_std (allocatable, result, GFC_STD_F2003);
+  if (attr->allocatable && attr->dummy)
+{
+  a1 = allocatable;
+  a2 = dummy;
+  standard = conflict_std (GFC_STD_F2003, a1, a2, name, where);
+  if (!standard)
+ return standard;
+}
+  if (attr->allocatable && attr->function)
+{
+  a1 = allocatable;
+  a2 = function;
+  standard = conflict_std (GFC_STD_F2003, a1, a2, name, where);
+  if (!standard)
+ return standard;
+}
+  if (attr->allocatable && attr->result)
+{
+  a1 = allocatable;
+  a2 = result;
+  standard = conflict_std (GFC_STD_F2003, a1, a2, nam

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[peter.bisroev at groundlabs dot com]

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

--- Comment #149 from Peter Bisroev  ---
(In reply to The Written Word from comment #148)
> (In reply to The Written Word from comment #144)
> > We have a build running that seems to be going well. We are using gcc-4.9.4
> > to build 8.3.0. I will attach the current patch set we are building against.
> 
> We're running into the same issues as encountered in comment#74. I think
> this is because of our patch to address PR66319 so I am attempting a build
> without it. We will then probably run into the problem in comment#76 but
> I'll try to fix that manually and continue the build.

Did you build your 4.9.4 or you are using a pre-built one? I am trying to build
4.9.4 using my 4.7.4 but at the end of stage1 I get
--
conftest.c:15:3: internal compiler error: Illegal instruction
--
This is a similar error as described in comment#21.

Thanks!

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[bugzilla-gcc at thewrittenword dot com]

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

--- Comment #150 from The Written Word  
---
(In reply to Peter Bisroev from comment #149)
> (In reply to The Written Word from comment #148)
> > (In reply to The Written Word from comment #144)
> > > We have a build running that seems to be going well. We are using 
> > > gcc-4.9.4
> > > to build 8.3.0. I will attach the current patch set we are building 
> > > against.
> > 
> > We're running into the same issues as encountered in comment#74. I think
> > this is because of our patch to address PR66319 so I am attempting a build
> > without it. We will then probably run into the problem in comment#76 but
> > I'll try to fix that manually and continue the build.
> 
> Did you build your 4.9.4 or you are using a pre-built one? I am trying to
> build 4.9.4 using my 4.7.4 but at the end of stage1 I get
> --
> conftest.c:15:3: internal compiler error: Illegal instruction
> --
> This is a similar error as described in comment#21.

We built 4.9.4. Try 4.9.3 and you might have more success. On 4.9.4, you need
to look at PR60465. I think comment#63 here also provides a workaround but we
chose to revert the commit that caused the problem.

[Bug c++/93643] New: Static function pointer inside inline function with "C" linkage is not mangled

[iucar at fedoraproject dot org]

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

Bug ID: 93643
   Summary: Static function pointer inside inline function with
"C" linkage is not mangled
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iucar at fedoraproject dot org
  Target Milestone: ---

Created attachment 47807
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47807&action=edit
Assembler

Consider the following example (a simplification of a real case):

$ cat test.cpp 
void* callback(const char* name);

extern "C" {

inline void f1()
{
static void (*f)();
f = (void(*)()) callback("f1");
f();
}

inline void f2()
{
static void (*f)();
f = (void(*)()) callback("f2");
f();
}

} // extern "C"

int main()
{
f1();
f2();
}
$ g++ -save-temps test.cpp
g++ -save-temps test.cpp 
test.s: Assembler messages:
test.s:41: Error: symbol `f' is already defined

As you can see in the attached test.s, symbol "f" for functions f1 and f2 is
not mangled, and thus collides. Previous versions of GCC produce mangled
identifiers _ZZ2f1E1f and _ZZ2f2E1f.

$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --with-isl --enable-offload-targets=nvptx-none
--without-cuda-driver --enable-gnu-indirect-function --enable-cet
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.1 20200130 (Red Hat 10.0.1-0.7) (GCC)

[Bug analyzer/93405] Passing constant arguments to subroutines in Fortran ... and the analyzer.

[toon at moene dot org]

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

--- Comment #5 from Toon Moene  ---
I have no problem with it.

I will ACK it on the fortran mailing list.

[Bug other/93644] New: -Wreturn-local-addr July regression: new false-positive warning

[jim at meyering dot net]

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

Bug ID: 93644
   Summary: -Wreturn-local-addr July regression: new
false-positive warning
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jim at meyering dot net
  Target Milestone: ---

Created attachment 47808
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47808&action=edit
derived from gnulib's lib/careadlinkat.c

Using -Wreturn-local-addr can now evoke this false positive:

$ gcc -c -O2 -Wreturn-local-addr k.c
k.c: In function 'careadlinkat':
cc1: warning: function may return address of local variable
[-Wreturn-local-addr]
k.c:24:8: note: declared here
   24 |   char stack_buf[1024];
  |^

I was able to easily narrow down that this behavior changed on gcc/git master
built from:
2019-07-19 (no warning) to
2019-07-23 (warning emitted).
--

I was surprised not to be able to convince the compiler that the code is ok OR
even to suppress the warning.
Per discussion in the thread at
https://lists.gnu.org/r/coreutils/2020-02/msg6.html, I first tried this:

>> Would an `assure (buf != stack_buf)` before the `return buf`
>> indicate that constraint to gcc with minimal runtime overhead?

I then tried to suppress that warning in the affected file by adding these
lines:

/* Without this pragma, gcc 10.0.1 20200205 reports that
   the "function may return address of local variable".  */
# pragma GCC diagnostic ignored "-Wreturn-local-addr"

But, surprisingly, even with that pragma, the warning was still emitted.
I ended up having to disable this normally-high-signal warning for all of
coreutils/lib.

The attached file is derived from gnulib's lib/careadlinkat.c.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dmalcolm at gcc dot gnu.org]

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

--- Comment #151 from David Malcolm  ---
(In reply to Peter Bisroev from comment #139)

[...]

> I am not sure how these selftests work yet but will take a look into them to
> see if we can reproduce a reliable minimal test case.

FWIW, I added the selftest framework to gcc, in the hopes that failing early in
a minimal reproducer is better than having lots of DejaGnu failures later on.

"make selftest-gdb" is a precanned way to debug things, though I don't know how
well it will work for your configuration.

 However this is what I
> see in GDB for now:
> 
> (gdb) r
> Starting program: /home/pbisroev/src/build/./gcc/cc1 -quiet -nostdinc
> -iprefix /home/pbisroev/src/build/gcc/../lib/gcc/ia64-hp-hpux11.31/8.3.0/
> -isystem /home/pbisroev/src/build/./gcc/include -isystem
> /home/pbisroev/src/build/./gcc/include-fixed /dev/null -quiet -dumpbase null
> -auxbase-strip /dev/null -version
> -fself-test=/home/pbisroev/src/gcc-8.3.0/gcc/testsuite/selftests
> GNU C17 (GCC) version 8.3.0 (ia64-hp-hpux11.31)
> compiled by GNU C version 4.7.4, GMP version 6.1.0, MPFR version
> 3.1.4, MPC version 1.0.3, isl version none
> GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
> GNU C17 (GCC) version 8.3.0 (ia64-hp-hpux11.31)
> compiled by GNU C version 4.7.4, GMP version 6.1.0, MPFR version
> 3.1.4, MPC version 1.0.3, isl version none
> GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
> Compiler executable checksum: 6ad5ed57899a8ef4c993d4479438
> 
> Program received signal SIGSEGV, Segmentation fault
>   si_code: 1 - SEGV_MAPERR - Address not mapped to object.
> 0x79e7a40 in  ()
> (gdb) bt
> #0  0x79e7a40 in  ()
> warning: Attempting to unwind past bad PC 0x79e7a40 
> #1  0x6c81c20 in
> vector_builder::try_npatterns(unsigned
> int)+0x2a0 ()
> #2  0x6c821d0 in vector_builder::finalize()
>+0x390 ()
> #3  0x59e9b70:0 in tree_vector_builder::build()+0x30 ()
> #4  0x5a69240:0 in  ()
> #5  0x5a8b6b0:0 in selftest::tree_c_tests()+0x7b0 ()
> #6  0x642a510:0 in selftest::run_tests()+0x190 ()
> #7  0x52e68e0:0 in toplev::run_self_tests()+0x60 ()
> #8  0x52e8760:0 in toplev::main(int,char**)+0x1be0 ()
> #9  0x64d4eb0:0 in main+0x70 ()
> (gdb)

Probably frame 4 is "test_vector_cst_patterns", judging by frames 1 and 2;
frame 1 is an instantiation of a template.

If a particular selftest is failing, there's always the option of disabling it
with #if 0 (or putting a "return;" at the top of it).  Though obviously that
may be merely postponing dealing with a bug until a later point.

Hope this is helpful

[Bug middle-end/93644] [10 Regression] -Wreturn-local-addr July regression: new false-positive warning

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-09
 CC||msebor at gcc dot gnu.org
  Component|other   |middle-end
Summary|-Wreturn-local-addr July|[10 Regression]
   |regression: new |-Wreturn-local-addr July
   |false-positive warning  |regression: new
   ||false-positive warning
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
The warning is issued because a PHI operand of the the return statement
references another PHI node one of whose operands is yet another PHI node that
includes the local variable stack_buf among its operands:

   [local count: 79230146]:
  # buffer_17 = PHI <&stack_buf(4), buffer_38(D)(5)>
  ...
   [local count: 1073741824]:
  # buf_20 = PHI 
  ...
   [local count: 79230145]:
  # _25 = PHI <0B(10), buf_20(15), 0B(24), 0B(28), b_63(14), b_61(17), 0B(9),
buf_20(16), buf_20(18)>
  stack_buf ={v} {CLOBBER};
  return _25;

A simplified test case is below.  It warns for the same reason (but with fewer
indirections):

  # buffer_2 = PHI <&stack_buf(2), buffer_7(D)(3)>
  ...
  # _4 = PHI <0B(4), _11(7), 0B(5), buffer_2(6)>
  return _4;


There's no way to tell from the IL in either of these test cases that one of
the final PHI operands cannot point to stack_buf so the warning triggers. 
Short of not considering PHI arguments that are themselves PHIs  and trading
off false positives for false negatives I don't see how to avoid the warning in
this case.


$ cat pr93644.c && gcc -O2 -S -Wall -fdump-tree-isolate-paths=/dev/stdout
pr93644.c
typedef __SIZE_TYPE__ size_t;

char *
careadlinkat (char *buffer, size_t buffer_size)
{
  char stack_buf[1024];
  if (!buffer_size)
{
  buffer = stack_buf;
  buffer_size = sizeof stack_buf;
}

  char *buf = buffer;
  size_t buf_size = buffer_size;

  extern int link_length;
  if (link_length < 0)
return 0;

  size_t link_size = link_length;
  if (link_size < buf_size)
{
  if (buf == stack_buf)
return __builtin_malloc (link_size);

  return buf;
}

  return 0;
}

;; Function careadlinkat (careadlinkat, funcdef_no=0, decl_uid=1932,
cgraph_uid=1, symbol_order=0)

pr93644.c: In function ‘careadlinkat’:
cc1: warning: function may return address of local variable
[-Wreturn-local-addr]
pr93644.c:6:8: note: declared here
6 |   char stack_buf[1024];
  |^
careadlinkat (char * buffer, size_t buffer_size)
{
  size_t link_size;
  char stack_buf[1024];
  int link_length.0_1;
  char * _4;
  char * _11;

   [local count: 1073741824]:
  if (buffer_size_6(D) == 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870912]:

   [local count: 1073741824]:
  # buffer_2 = PHI <&stack_buf(2), buffer_7(D)(3)>
  # buffer_size_3 = PHI <1024(2), buffer_size_6(D)(3)>
  link_length.0_1 = link_length;
  if (link_length.0_1 < 0)
goto ; [12.76%]
  else
goto ; [87.24%]

   [local count: 936732369]:
  link_size_9 = (size_t) link_length.0_1;
  if (buffer_size_3 > link_size_9)
goto ; [71.00%]
  else
goto ; [29.00%]

   [local count: 665079983]:
  if (&stack_buf == buffer_2)
goto ; [17.43%]
  else
goto ; [82.57%]

   [local count: 115923441]:
  _11 = __builtin_malloc (link_size_9);

   [local count: 1073741824]:
  # _4 = PHI <0B(4), _11(7), 0B(5), buffer_2(6)>
  stack_buf ={v} {CLOBBER};
  return _4;

}

[Bug other/90556] [meta-bug] bogus/missing -Wreturn-local-addr

[msebor at gcc dot gnu.org]

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

Bug 81811 Summary: missing -Wreturn-local-addr returning strcpy result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81811

   What|Removed |Added

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

[Bug middle-end/81811] missing -Wreturn-local-addr returning strcpy result

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Component|tree-optimization   |middle-end
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
   Target Milestone|--- |10.0

--- Comment #5 from Martin Sebor  ---
Fixed for GCC 10 (most likely by r273261).  Tested in
gcc.dg/Wreturn-local-addr-6.c.

[Bug middle-end/93644] [10 Regression] -Wreturn-local-addr July regression: new false-positive warning

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
  # buffer_2 = PHI <&stack_bufD.1939(3), buffer_7(D)(9)>

  buffer_18 = ASSERT_EXPR ;

Can't we deduce from this

  buffer_18 = buffer_7(D)

? Of course that's not a general solution, but it looks like a sensible
optimization, and in the reduced testcase it should remove &stack_buf from the
possible return values.

[Bug tree-optimization/60669] VRP misses asserts for some already defined statements

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
I ran into this same issue when I am writing a patch for PR55177 (attached
below) but with f8 rather than f7 from vrp65.c.

diff --git a/gcc/match.pd b/gcc/match.pd
index 363006e28fd..a31fe598a25 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -1386,14 +1386,20 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
&& (bitop != BIT_AND_EXPR || GIMPLE)
&& (/* That's a good idea if the conversion widens the operand, thus
  after hoisting the conversion the operation will be narrower.  */
-  TYPE_PRECISION (TREE_TYPE (@0)) < TYPE_PRECISION (type)
+  TYPE_PRECISION (TREE_TYPE (@0)) <= TYPE_PRECISION (type)
   /* It's also a good idea if the conversion is to a non-integer
  mode.  */
   || GET_MODE_CLASS (TYPE_MODE (type)) != MODE_INT
   /* Or if the precision of TO is not the same as the precision
  of its mode.  */
   || !type_has_mode_precision_p (type)))
-   (convert (bitop @0 (convert @1))
+   (convert (bitop @0 (convert @1)
+ (simplify
+  (convert (bitop:c (nop_convert @0) @1))
+  (if (GIMPLE
+   && tree_nop_conversion_p (type, TREE_TYPE (@1))
+   && types_match (type, TREE_TYPE (@0)))
+   (bitop @0 (convert @1)

 (for bitop (bit_and bit_ior)
  rbitop (bit_ior bit_and)

[Bug c/93640] The write_only and read_write attributes can be mistyped due to invalid strncmp size argument

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-09
 CC||msebor at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.

[Bug c/93640] The write_only and read_write attributes can be mistyped due to invalid strncmp size argument

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug c/93636] Incorrect diagnostic of a potential string overflow in strncat

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Martin Sebor  ---
The warning is intentional.  The expected use of the strncat function is to
limit the output to the space in the destination, not to the length source
(using strncat the way the test case in comment #0 does is the same as strcat).
 The latter use is a common source of buffer overflow bugs that the warning is
designed to help avoid.

The articles below provide additional background:
https://developers.redhat.com/blog/2018/05/24/detecting-string-truncation-with-gcc-8/
https://www.us-cert.gov/bsi/articles/knowledge/coding-practices/strncpy-and-strncat.

[Bug middle-end/93644] [10 Regression] -Wreturn-local-addr July regression: new false-positive warning

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
The most likely reason the warning isn't suppressed by #pragma GCC diagnostic
is that the statement it's issued for has no source line number associated with
it.  That's also why the warning doesn't point to such a statement (only the
note does).  The details of this bug are in pr90735.

[Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast

[comexk at gmail dot com]

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

--- Comment #24 from comexk at gmail dot com ---
>  All that's needed for that is an extension to provide a compile-time 
> constant value to a pointer, not to allow arbitrary reinterpret_casts in 
> constexpr.

Well, there aren't that many things that reinterpret_cast can do.  Casting
pointers to different pointer types would be useful, but using such pointers is
normally undefined behavior anyway.  The exception is accessing byte
representations using `char *` pointers.  Supporting that in constexpr context
*would* be a major feature, but it doesn't need to be allowed just because the
cast itself is allowed.

On the other hand, C++20 is adding an alternate way to manipulate byte
representations in constexpr context, std::bit_cast.  (It's non-constexpr when
the types involved contain unions or pointers, so it can't be used directly in
place of reinterpret_cast.)  Most of the work that would be needed to support
access-through-`char *` as an extension needs to be done anyway for
std::bit_cast; on the other hand, its existence reduces the need for an
extension.

Regardless, it would be nice to lift the pointer restriction on std::bit_cast
as an extension.

[Bug middle-end/93644] [10 Regression] -Wreturn-local-addr July regression: new false-positive warning

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
pr90735 suggests using the location of the closing curly brace of the function
instead.  Another alternative might be to use the location associated with the
note.

[Bug c++/93618] [10 Regression] : unknown array size in delete when using C++20 standard

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug tree-optimization/55177] missed optimizations with __builtin_bswap

[pinskia at gcc dot gnu.org]

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

--- Comment #21 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #20)
> diff --git a/gcc/match.pd b/gcc/match.pd

I ran into a testcase regression with my new correct version.  See PR 60669 for
that case.

[Bug driver/93645] New: Support -fuse-ld=/absolute/path/to/ld

[i at maskray dot me]

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

Bug ID: 93645
   Summary: Support -fuse-ld=/absolute/path/to/ld
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: i at maskray dot me
  Target Milestone: ---

This feature request generalizes -fuse-ld=bfd -fuse-ld=gold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55470
and
-fuse-ld=lld

clang -fuse-ld= also supports the following forms:

-fuse-ld=/path/to/binutils-gdb/Debug/ld/ld-new
-fuse-ld=/path/to/ld.lld
-fuse-ld=/usr/bin/ld.lld-9

[Bug driver/93645] Support -fuse-ld=/absolute/path/to/ld

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug middle-end/93646] New: confusing -Wstringop-truncation on strncat where -Wstringop-overflow is expected

[msebor at gcc dot gnu.org]

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

Bug ID: 93646
   Summary: confusing -Wstringop-truncation on strncat where
-Wstringop-overflow is expected
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The -Wstringop-overflow warning in the code below is expected because a call to
strncat with a bound equal to the length of the source might overflow (the
bound should be equal to the size of the space remaining in the destination). 
But -Wstringop-truncation is not expected because strncat a) never copies the
terminating nul from the source and b) always appends a terminating nul to the
destination.

$ cat z.c && gcc -O2 -S -Wall z.c
void f (char *d, const char *s)
{
  __builtin_strncat (d, s, __builtin_strlen (s));
}

char a[4];

void g (void)
{
  f (a, "123");
}
z.c: In function ‘f’:
z.c:3:3: warning: ‘__builtin_strncat’ output truncated before terminating nul
copying as many bytes from a string as its length [-Wstringop-truncation]
3 |   __builtin_strncat (d, s, __builtin_strlen (s));
  |   ^~
In function ‘f’,
inlined from ‘g’ at z.c:10:3:
z.c:3:3: warning: ‘__builtin_strncat’ specified bound 3 equals source length
[-Wstringop-overflow=]
3 |   __builtin_strncat (d, s, __builtin_strlen (s));
  |   ^~

[Bug middle-end/93646] confusing -Wstringop-truncation on strncat where -Wstringop-overflow is expected

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |ASSIGNED
URL||https://bugzilla.redhat.com
   ||/show_bug.cgi?id=1798636
   Last reconfirmed||2020-02-09
 Blocks||88781
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88781
[Bug 88781] [meta-bug] bogus/missing -Wstringop-truncation warnings

[Bug driver/93645] Support -fuse-ld=/absolute/path/to/ld

[i at maskray dot me]

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

--- Comment #1 from Fangrui Song  ---
Posted a patch https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00510.html


I agree with 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59321#c4
we should use a new option, instead of overloading --print-prog-name=ld for a
different meaning

gcc --print-prog-name=ld -fuse-ld=bfd => ld.bfd

[Bug driver/52982] add option to select particular linker

[i at maskray dot me]

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

Fangrui Song  changed:

   What|Removed |Added

 CC||i at maskray dot me

--- Comment #4 from Fangrui Song  ---
I posted a patch https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00510.html to
make -fuse-ld=linker generic (absolute path or ld.linker)

[Bug analyzer/93647] New: ICE in get_lvalue_1, at analyzer/region-model.cc:4613

[asolokha at gmx dot com]

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

Bug ID: 93647
   Summary: ICE in get_lvalue_1, at analyzer/region-model.cc:4613
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-10.0.1-alpha20200202 snapshot (g:b817be038d94c987e02c26ed2d81b6f2ebb5f97a)
ICEs when compiling the following testcase w/ -O1 -fanalyzer:

int *tz;

void
ky (int);

void
wd (void)
{
  tz = 0;
  ky (*tz);
}

% gcc-10.0.1 -O1 -fanalyzer -c boqbjazp.c
during IPA pass: analyzer
boqbjazp.c:9:6: internal compiler error: in get_lvalue_1, at
analyzer/region-model.cc:4613
9 |   tz = 0;
  |   ~~~^~~
0x71dc18 ana::region_model::get_lvalue_1(ana::path_var,
ana::region_model_context*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200202/work/gcc-10-20200202/gcc/analyzer/region-model.cc:4613
0x1104933 ana::region_model::get_lvalue(ana::path_var,
ana::region_model_context*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200202/work/gcc-10-20200202/gcc/analyzer/region-model.cc:4720
0x17afff5 get_any_origin
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200202/work/gcc-10-20200202/gcc/analyzer/diagnostic-manager.cc:539
0x17afff5 get_any_origin
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200202/work/gcc-10-20200202/gcc/analyzer/diagnostic-manager.cc:525
0x17b24f7 ana::diagnostic_manager::prune_for_sm_diagnostic(ana::checker_path*,
ana::state_machine const*, tree_node*, unsigned int) const
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200202/work/gcc-10-20200202/gcc/analyzer/diagnostic-manager.cc:1009
0x17b271e ana::diagnostic_manager::prune_path(ana::checker_path*,
ana::state_machine const*, tree_node*, unsigned int) const
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200202/work/gcc-10-20200202/gcc/analyzer/diagnostic-manager.cc:940
0x17b28ce ana::diagnostic_manager::emit_saved_diagnostic(ana::exploded_graph
const&, ana::saved_diagnostic const&, ana::exploded_path const&, gimple const*,
int)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200202/work/gcc-10-20200202/gcc/analyzer/diagnostic-manager.cc:479
0x17b47dd ana::dedupe_winners::emit_best(ana::diagnostic_manager*,
ana::exploded_graph const&)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200202/work/gcc-10-20200202/gcc/analyzer/diagnostic-manager.cc:410
0x17b2c62 ana::diagnostic_manager::emit_saved_diagnostics(ana::exploded_graph
const&)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200202/work/gcc-10-20200202/gcc/analyzer/diagnostic-manager.cc:453
0x10e6ade ana::impl_run_checkers(ana::logger*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200202/work/gcc-10-20200202/gcc/analyzer/engine.cc:3566
0x10e755c ana::run_checkers()
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200202/work/gcc-10-20200202/gcc/analyzer/engine.cc:3609
0x10dd178 execute
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200202/work/gcc-10-20200202/gcc/analyzer/analyzer-pass.cc:84

[Bug c/93636] Incorrect diagnostic of a potential string overflow in strncat

[sebunger44 at gmail dot com]

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

Sebastian Unger  changed:

   What|Removed |Added

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

--- Comment #2 from Sebastian Unger  ---
The (simplified) test-case I gave may be the same as strcat, but the intention
of strncat is not to limit to the size of destination, but to limit the size
taken from source because it may not be null-terminated. So the real test-case
is more like this:

void f(char* dst)
{
  static const char tt[2] = {'a', 'b'};
  strncat(dst, tt, sizeof(tt));
}

[Bug ipa/93203] [10 Regression] ICE in decide_about_value, at ipa-cp.c:5448 since r278893

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Feng Xue :

https://gcc.gnu.org/g:a0f6a8cb414b687f22c9011a894d5e8e398c4be0

commit r10-6540-ga0f6a8cb414b687f22c9011a894d5e8e398c4be0
Author: Feng Xue 
Date:   Tue Jan 21 20:53:38 2020 +0800

Generalized value pass-through for self-recusive function (PR ipa/93203)

Besides simple pass-through (aggregate) jump function, arithmetic
(aggregate)
jump function could also bring same (aggregate) value as parameter
passed-in
for self-feeding recursive call.  For example,

  f1 (int i)/*  normal jump function */
 {
f1 (i & 1);
 }

Suppose i is 0, recursive propagation via (i & 1) also gets 0, which
can be seen as a simple pass-through of i.

  f2 (int *p)  /* aggregate jump function */
 {
int t = *p & 1;
f2 (&t);
 }
Likewise, if *p is 0, (*p & 1) is also 0, and &t is an aggregate simple
pass-through of p.

2020-02-10  Feng Xue  

PR ipa/93203
* ipa-cp.c (ipcp_lattice::add_value): Add source with same call
edge
but different source value.
(adjust_callers_for_value_intersection): New function.
(gather_edges_for_value): Adjust order of callers to let a
non-self-recursive caller be the first element.
(self_recursive_pass_through_p): Add a new parameter "simple", and
check generalized self-recursive pass-through jump function.
(self_recursive_agg_pass_through_p): Likewise.
(find_more_scalar_values_for_callers_subset): Compute value from
pass-through jump function for self-recursive.
(intersect_with_plats): Cleanup previous implementation code for
value
itersection with self-recursive call edge.
(intersect_with_agg_replacements): Likewise.
(intersect_aggregates_with_edge): Deduce value from pass-through
jump
function for self-recursive call edge.  Cleanup previous
implementation
code for value intersection with self-recursive call edge.
(decide_whether_version_node): Remove dead callers and adjust order
to let a non-self-recursive caller be the first element.

PR ipa/93203
* g++.dg/ipa/pr93203.C: New test.

[Bug ipa/93203] [10 Regression] ICE in decide_about_value, at ipa-cp.c:5448 since r278893

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Feng Xue :

https://gcc.gnu.org/g:a5f79f225e637d59a7b6e26ae62b74b0019d2e85

commit r10-6541-ga5f79f225e637d59a7b6e26ae62b74b0019d2e85
Author: Feng Xue 
Date:   Mon Feb 10 12:46:45 2020 +0800

Update testcase ChangeLog for PR93203

2020-02-10  Feng Xue  

PR ipa/93203
* g++.dg/ipa/pr93203.C: New test.
* gcc.dg/ipa/ipcp-1.c: Change dump string.

[Bug middle-end/93636] Incorrect diagnostic of a potential string overflow in strncat

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |middle-end

--- Comment #3 from Andrew Pinski  ---
I suspect most people don't understand the semantics of strncat enough.  This
is why the warning is there.  Most people don't understand that the length
passed to strncat is the length left (minus 1).

[Bug c++/93643] [10 Regression] Static function pointer inside inline function with "C" linkage is not mangled

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||assemble-failure,
   ||wrong-code
   Target Milestone|--- |10.0
Summary|Static function pointer |[10 Regression] Static
   |inside inline function with |function pointer inside
   |"C" linkage is not mangled  |inline function with "C"
   ||linkage is not mangled
   Severity|normal  |blocker

[Bug middle-end/71509] Bitfield causes load hit store with larger store than load

[luoxhu at gcc dot gnu.org]

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

luoxhu at gcc dot gnu.org changed:

   What|Removed |Added

 CC||luoxhu at gcc dot gnu.org

--- Comment #11 from luoxhu at gcc dot gnu.org ---
(In reply to Anton Blanchard from comment #4)
> Created attachment 39683 [details]
> Another bitop LHS test case
> 
> Here's another issue found in the Linux kernel. Seems like this should be a
> single lwz/stw since the union of counter and the bitops completely overlap.
> 
> The half word store followed by word load is going to prevent it from store
> forwarding.
> 
>  :
>0: 00 00 03 81 lwz r8,0(r3)
>4: 20 00 89 78 clrldi  r9,r4,32
>8: c2 0f 2a 79 rldicl  r10,r9,33,31
>c: 00 f8 48 51 rlwimi  r8,r10,31,0,0
>   10: 5e 00 2a 55 rlwinm  r10,r9,0,1,15
>   14: 00 00 03 91 stw r8,0(r3)
>   18: 00 00 83 b0 sth r4,0(r3)
>   1c: 00 00 42 60 ori r2,r2,0
>   20: 00 00 23 81 lwz r9,0(r3)
>   24: 00 04 29 55 rlwinm  r9,r9,0,16,0
>   28: 78 53 29 7d or  r9,r9,r10
>   2c: 00 00 23 91 stw r9,0(r3)
>   30: 20 00 80 4e blr

This case only is fixed on latest gcc 10 already (issues in case
__skb_decr_checksum_unnecessary from Anton Blanchard and test2 from Nicholas
Piggin  still exist).

gcc version 10.0.1 20200210 

objdump -d set_page_slub_counters.o

set_page_slub_counters.o: file format elf64-powerpcle


Disassembly of section .text:

 :
   0:   22 84 89 78 rldicl  r9,r4,48,48
   4:   00 00 83 b0 sth r4,0(r3)
   8:   02 00 23 b1 sth r9,2(r3)
   c:   20 00 80 4e blr

[Bug lto/92599] [8/9 regression] ICE in speculative_call_info, at cgraph.c:1142

[luoxhu at gcc dot gnu.org]

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

luoxhu at gcc dot gnu.org changed:

   What|Removed |Added

 CC||luoxhu at gcc dot gnu.org

--- Comment #9 from luoxhu at gcc dot gnu.org ---
Fixed on master, could be closed?