[Bug c++/110911] New: Confusing diagnostic on misplaced static_assert

[pacoarjonilla at yahoo dot es via Gcc-bugs]

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

Bug ID: 110911
   Summary: Confusing diagnostic on misplaced static_assert
   Product: gcc
   Version: og13 (devel/omp/gcc-13)
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pacoarjonilla at yahoo dot es
  Target Milestone: ---

This code (note static_assert instead of static_cast)


#include 
void f(float m)
{
std::complex c = std::complex(static_assert(m),0);
}


generates the diagnostic

: In function 'void f(float)':
:4:50: error: expected primary-expression before '(' token
4 | std::complex c =
std::complex(static_assert(m),0);
  |  ^
:4:51: error: expected primary-expression before 'static_assert'
4 | std::complex c =
std::complex(static_assert(m),0);
  |  


But the problem is not before the '(' token, nor before static_assert.
A suggestion such as "static_assert not valid here. Did you mean
'static_cast'?" would be nice.

[Bug c/97100] -Wformat checks all arms of _Generic leading to irrelevant type expectation warnings

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Martin Uecker :

https://gcc.gnu.org/g:54be338589ea93ad4ff53d22adde476a0582537b

commit r14-3004-g54be338589ea93ad4ff53d22adde476a0582537b
Author: Martin Uecker 
Date:   Fri Aug 4 07:48:21 2023 +0200

c: _Generic should not warn in non-active branches
[PR68193,PR97100,PR110703]

To avoid false diagnostics, use c_inhibit_evaluation_warnings when
a generic association is known to not match during parsing.  We may
still generate false positives if the default branch comes earler than
a specific association that matches.

PR c/68193
PR c/97100
PR c/110703

gcc/c/:
* c-parser.cc (c_parser_generic_selection): Inhibit evaluation
warnings branches that are known not be taken during parsing.

gcc/testsuite/ChangeLog:
* gcc.dg/pr68193.c: New test.

[Bug c/68193] _Generic -Woverflow false alarm

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Martin Uecker :

https://gcc.gnu.org/g:54be338589ea93ad4ff53d22adde476a0582537b

commit r14-3004-g54be338589ea93ad4ff53d22adde476a0582537b
Author: Martin Uecker 
Date:   Fri Aug 4 07:48:21 2023 +0200

c: _Generic should not warn in non-active branches
[PR68193,PR97100,PR110703]

To avoid false diagnostics, use c_inhibit_evaluation_warnings when
a generic association is known to not match during parsing.  We may
still generate false positives if the default branch comes earler than
a specific association that matches.

PR c/68193
PR c/97100
PR c/110703

gcc/c/:
* c-parser.cc (c_parser_generic_selection): Inhibit evaluation
warnings branches that are known not be taken during parsing.

gcc/testsuite/ChangeLog:
* gcc.dg/pr68193.c: New test.

[Bug c/110703] Incorrect "-Wfloat-conversion" diagnostic with _Generic

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Martin Uecker :

https://gcc.gnu.org/g:54be338589ea93ad4ff53d22adde476a0582537b

commit r14-3004-g54be338589ea93ad4ff53d22adde476a0582537b
Author: Martin Uecker 
Date:   Fri Aug 4 07:48:21 2023 +0200

c: _Generic should not warn in non-active branches
[PR68193,PR97100,PR110703]

To avoid false diagnostics, use c_inhibit_evaluation_warnings when
a generic association is known to not match during parsing.  We may
still generate false positives if the default branch comes earler than
a specific association that matches.

PR c/68193
PR c/97100
PR c/110703

gcc/c/:
* c-parser.cc (c_parser_generic_selection): Inhibit evaluation
warnings branches that are known not be taken during parsing.

gcc/testsuite/ChangeLog:
* gcc.dg/pr68193.c: New test.

[Bug c++/110912] New: False assumption that constructors cannot alias any of their parameters

[janschultke at googlemail dot com via Gcc-bugs]

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

Bug ID: 110912
   Summary: False assumption that constructors cannot alias any of
their parameters
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: janschultke at googlemail dot com
  Target Milestone: ---

It looks like GCC thinks that no aliasing can take place betweeen `this` and
any constructor parameters.
You get the same output if you use `__restrict` for any pointers passed into
constructors, or if you add `noalias` to LLVM IR.

There is no wording in the standard that disallows aliasing in constructors
completely, and this may cause more serious issues in real code See
https://github.com/cplusplus/CWG/issues/206.

This bug stems from an over-interpretation of [class.cdtor] p2
(https://eel.is/c++draft/class.cdtor#2), which states that an unspecified value
is obtained when not accessing subobjects through the `this` pointer. However,
it DOES NOT say that side effects will result in unspecified values, and it
DOES NOT say that any undefined behavior is involved, which is the prerequisite
to treat this as `noalias`.

It seems to have been introduced here, and there is a related LLVM issue:
- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82899
- https://bugs.llvm.org/show_bug.cgi?id=37329

For reference, [class.cdtor] p2:
> During the construction of an object,
> if the value of the object or any of its subobjects is accessed
> through a glvalue that is not obtained,
> directly or indirectly, from the constructor's this pointer,
> the value of the object or subobject thus obtained is unspecified.

THIS WORDING IS NOT STRONG ENOUGH FOR `noalias`! This is an old paragraph which
originally applied to const objects only, and has some problems with breaking
legitimate code for polymorphic classes. I am not entirely sure about the
intention behind it myself, but it would have been very easy for the committee
to make access through such a pointer (not obtained from `this`) undefined
behavior. That would actually allow `noalias`, NOT the current wording.

I have talked to other knowledgeable members of the community, and so far no
one believes that the wording is strong enough, or intended to disallow
aliasing entirely.

Related discussions:
- https://lists.isocpp.org/std-discussion/2023/08/2324.php
- https://lists.isocpp.org/std-discussion/2022/12/1952.php



## Code to Reproduce (https://godbolt.org/z/K4nTPYK3r)

void foo();

struct A {
int i = 0;
[[gnu::used]] A(int &x) {
x = 5;
if (i == 0) {
foo();
}
}
};



## Actual Output (gcc trunk -O3)

A::A(int&) [base object constructor]:
mov DWORD PTR [rdi], 0
mov DWORD PTR [rsi], 5
jmp foo()



## Expected Output (clang trunk -O3)

A::A(int&) [base object constructor]:
mov dword ptr [rdi], 0
mov dword ptr [rsi], 5
cmp dword ptr [rdi], 0
je  foo()@PLT
ret



## Suggested Resolution

Do not assume `noalias` for all parameters in a constructor.

[Bug c++/110913] New: internal compiler error when I pass temporary vector of string to co_await target function

[redboltz at gmail dot com via Gcc-bugs]

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

Bug ID: 110913
   Summary: internal compiler error when I pass temporary vector
of string to co_await target function
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redboltz at gmail dot com
  Target Milestone: ---

# Environment

## gcc --version

gcc (GCC) 13.2.1 20230730
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

## gcc -v

Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=ada,c,c++,d,fortran,go,lto,objc,obj-c++ --enable-bootstrap
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--with-build-config=bootstrap-lto --with-linker-hash-style=gnu
--with-system-zlib --enable-__cxa_atexit --enable-cet=auto
--enable-checking=release --enable-clocale=gnu --enable-default-pie
--enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-libstdcxx-backtrace --enable-link-serialization=1
--enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.1 20230730 (GCC)


## uname -a
Linux archboltz 6.4.7-arch1-2 #1 SMP PREEMPT_DYNAMIC Mon, 31 Jul 2023 11:41:04
+ x86_64 GNU/Linux

compile option
-std=c++20 -O0 -Wall -Wextra -pedantic

# Overview
The following internal compiler error is reported:

```
cpp20coro_error.cpp: In function ‘boost::asio::awaitable
test2(boost::asio::io_context&)’:
cpp20coro_error.cpp:37:1: internal compiler error: in
build_special_member_call, at cp/call.cc:11093
   37 | }
  | ^
0x1ad3438 internal_error(char const*, ...)
???:0
0x6b7b33 fancy_abort(char const*, int, char const*)
???:0
0x10dc453 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x10dc453 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x10dc573 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x10dc453 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x10dc453 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x10dc453 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x10dc573 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x10dc453 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x10dc453 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x74de61 finish_function(bool)
???:0
0x944370 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
```

# Reproduce code

```
#include 
#include 
#include 
#include 

#define REPRODUCE_ISSUE 1

boost::asio::awaitable
test1(boost::asio::io_context& ioc) {
co_await boost::asio::post(
ioc,
boost::asio::append(
boost::asio::use_awaitable,
std::vector {
1, 2, 3
}
)
);
}

boost::asio::awaitable
test2(boost::asio::io_context& ioc) {
std::vector str{ "aaa", "bbb" };
co_await boost::asio::post(

[Bug c++/110911] Confusing diagnostic on misplaced static_assert

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
I think this would need a very specific custom diagnostic just for this case.
But I think I've made the same typo myself and I agree it would be nice, if
it's possible to do.

[Bug c/102558] missing warning comparing T[static N] to null

[muecker at gwdg dot de via Gcc-bugs]

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

Martin Uecker  changed:

   What|Removed |Added

 CC||muecker at gwdg dot de

--- Comment #1 from Martin Uecker  ---
Possibly fix by synthesizing a nonnull attribute:

https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625559.html

[Bug c++/110911] Confusing diagnostic on misplaced static_assert

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Jonathan Wakely  ---
Although Dave Malcolm has recommended that we don't use "did you mean...?"
phrasing, but something like "static_assert not valid here, static_cast would
be valid".

[Bug libstdc++/110909] Missed optimization: Suboptimal codegen in vector copy assignment

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Jonathan Wakely  ---
Right, we don't have a std::copy-but-ranges-do-not-overlap that could be used
instead.

[Bug target/105504] Fails to break dependency for vcvtss2sd xmm, xmm, mem

[egallager at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Eric Gallager  ---
(In reply to CVS Commits from comment #6)
> The master branch has been updated by hongtao Liu :
> 
> https://gcc.gnu.org/g:5e005393d4ff0a428c5f55b9ba7f65d6078a7cf5
> 
> commit r13-1009-g5e005393d4ff0a428c5f55b9ba7f65d6078a7cf5
> Author: liuhongt 
> Date:   Mon May 30 15:30:51 2022 +0800
> 
> Disparages SSE_REGS alternatives sligntly with ?v instead of *v in
> *mov{si,di}_internal.
> 
> So alternative v won't be igored in record_reg_classess.
> 
> Similar for *r alternatives in some vector patterns.
> 
> It helps testcase in the PR, also RA now makes better decisions for
> gcc.target/i386/extract-insert-combining.c
> 
> movd%esi, %xmm0
> movd%edi, %xmm1
> -   movl%esi, -12(%rsp)
> paddd   %xmm0, %xmm1
> pinsrd  $0, %esi, %xmm0
> paddd   %xmm1, %xmm0
> 
> The patch has no big impact on SPEC2017 for both O2 and Ofast
> march=native run.
> 
> And I noticed there's some changes in SPEC2017 from code like
> 
> mov mem, %eax
> vmovd %eax, %xmm0
> ..
> mov %eax, 64(%rsp)
> 
> to
> 
> vmovd mem, %xmm0
> ..
> vmovd %xmm0, 64(%rsp)
> 
> Which should be exactly what we want?
> 
> gcc/ChangeLog:
> 
> PR target/105513
> PR target/105504
> * config/i386/i386.md (*movsi_internal): Change alternative
> from *v to ?v.
> (*movdi_internal): Ditto.
> * config/i386/sse.md (vec_set_0): Change alternative *r
> to ?r.
> (*vec_extractv4sf_mem): Ditto.
> (*vec_extracthf): Ditto.
> 
> gcc/testsuite/ChangeLog:
> 
> * gcc.target/i386/pr105513-1.c: New test.
> * gcc.target/i386/extract-insert-combining.c: Add new
> scan-assembler-not for spill.

Did this fix it?

[Bug c/81233] -Wdiscarded-qualifiers and Wincompatible-pointer-types missing important detail

[egallager at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Eric Gallager  ---
(In reply to Eric Gallager from comment #5)
> (In reply to Marek Polacek from comment #3)
> > Fixed.  Further improvements are possible.
> 
> Uh... reopening for the possible further improvements;
> -Wdiscarded-qualifiers still doesn't say quite enough, IMO

Also I think that a separate flag like clang's
-Wincompatible-pointer-types-discards-qualifiers (mentioned in the OP) would be
useful for additional granularity; often times there are projects where
-Werror=incompatible-pointer-types and -Werror=discarded-qualifiers would make
building them too difficult, but
-Werror=incompatible-pointer-types-discards-qualifier wouldn't

[Bug target/110202] _mm512_ternarylogic_epi64 generates unnecessary operations

[amonakov at gcc dot gnu.org via Gcc-bugs]

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

Alexander Monakov  changed:

   What|Removed |Added

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

--- Comment #12 from Alexander Monakov  ---
We now generate

negate1:
vmovdqa64   zmm0, ZMMWORD PTR [rdi]
vpternlogq  zmm0, zmm0, zmm0, 85
ret
negate2:
vmovdqa32   zmm0, ZMMWORD PTR [rdi]
vpternlogd  zmm0, zmm0, zmm0, 0x55
ret

Fixed for gcc-14.

[Bug c++/110914] New: Optimization eliminating necessary assignment before 0-byte memcpy

[erosenberger at kinetica dot com via Gcc-bugs]

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

Bug ID: 110914
   Summary: Optimization eliminating necessary assignment before
0-byte memcpy
   Product: gcc
   Version: 11.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: erosenberger at kinetica dot com
  Target Milestone: ---

Given the attached source file, when compiled with "g++ -O2 test.cpp", no code
is generated for the line "val_int = 0;" in the Int8_buf constructor. In the
case where the memcpy on the following line is instructed to copy 0 bytes, this
results in val_int remaining uninitialized (and just containing whatever random
value was in memory previously).

In this test program, the result is that the output from main() is "49 49",
when it should be "49 0". (This is because the second 49 is the value remaining
in stack memory from the first call to foo(...) that is never initialized to 0
by the skipped line.)

If the skipped line is changed to initialize to a value other than 0, then
correct code is generated. If compiled with -O1, correct code is also
generated.

Using Compiler Explorer it appears that gcc 9 and earlier produce the correct
code, and gcc 10 is the first version to produce incorrect code.

gcc -v:
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
11.4.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--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
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-11-XeT9lY/gcc-11-11.4.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-XeT9lY/gcc-11-11.4.0/debian/tmp-gcn/usr
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)

[Bug c++/110914] Optimization eliminating necessary assignment before 0-byte memcpy

[erosenberger at kinetica dot com via Gcc-bugs]

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

--- Comment #1 from Eric Rosenberger  ---
Created attachment 55693
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55693&action=edit
Test program

Note: preprocessed .ii is too big to attach

[Bug tree-optimization/110914] [11/12/13/14 Regression] Optimization eliminating necessary assignment before 0-byte memcpy

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Optimization eliminating|[11/12/13/14 Regression]
   |necessary assignment before |Optimization eliminating
   |0-byte memcpy   |necessary assignment before
   ||0-byte memcpy
  Known to work||9.5.0
  Component|c++ |tree-optimization
   Target Milestone|--- |11.5
  Known to fail||10.5.0, 14.0

[Bug c/98536] warning with -Wvla-parameter for unspecified bound getting specified later

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Martin Uecker :

https://gcc.gnu.org/g:39f413fc4b6979d194f2f736bd663eb7f5045168

commit r14-3005-g39f413fc4b6979d194f2f736bd663eb7f5045168
Author: Martin Uecker 
Date:   Thu Apr 13 19:35:15 2023 +0200

c: Less warnings for parameters declared as arrays [PR98536]

To avoid false positivies, tune the warnings for parameters declared
as arrays with size expressions.  Do not warn when more bounds are
specified in the declaration than before.

PR c/98536

gcc/c-family/:
* c-warn.cc (warn_parm_array_mismatch): Do not warn if more
bounds are specified.

gcc/testsuite:
* gcc.dg/Wvla-parameter-4.c: Adapt test.
* gcc.dg/attr-access-2.c: Adapt test.

[Bug tree-optimization/110914] [11/12/13/14 Regression] Optimization eliminating necessary assignment before 0-byte memcpy

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Confirmed, The strlen pass is removing it ...

Self contained testcase:
```

struct Int8_buf
{
Int8_buf(const char* s, __SIZE_TYPE__ l)
{
val_int = 0;
__builtin_memcpy(&val_int, s, l!=0);
}

unsigned char val_int;
};

int __attribute__ ((noinline)) foo(const char* s, __SIZE_TYPE__ l)
{
Int8_buf b(s, l);
return b.val_int;
}

int main()
{
const char *cs="123456";
int a = foo(cs, __builtin_strlen(cs) - 5);
int b = foo(cs, __builtin_strlen(cs) - 6);
if (a != '1')
 __builtin_abort();
if (b != 0)
 __builtin_abort();
}
```

[Bug tree-optimization/96695] Failure to optimize combination of pointer comparison to nullptr and another pointer

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Andrew Pinski  ---
Created attachment 55694
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55694&action=edit
Patch which I am testing

[Bug modula2/110779] SysClock can not read the clock

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Gaius Mulley :

https://gcc.gnu.org/g:0826ebd633e38bd55abd161c15deb431420f82a3

commit r14-3006-g0826ebd633e38bd55abd161c15deb431420f82a3
Author: Gaius Mulley 
Date:   Sat Aug 5 17:35:12 2023 +0100

PR modula2/110779 SysClock can not read the clock

This patch completes the implementation of the ISO module
SysClock.mod.  Three new testcases are provided.  wrapclock.{cc,def}
are new support files providing access to clock_settime, clock_gettime
and glibc timezone variables.

gcc/m2/ChangeLog:

PR modula2/110779
* gm2-libs-iso/SysClock.mod: Re-implement using wrapclock.
* gm2-libs-iso/wrapclock.def: New file.

libgm2/ChangeLog:

PR modula2/110779
* config.h.in: Regenerate.
* configure: Regenerate.
* configure.ac (GM2_CHECK_LIB): Check for clock_gettime
and clock_settime.
* libm2iso/Makefile.am (M2DEFS): Add wrapclock.def.
* libm2iso/Makefile.in: Regenerate.
* libm2iso/wraptime.cc: Replace HAVE_TIMEVAL with
HAVE_STRUCT_TIMEVAL.
* libm2iso/wrapclock.cc: New file.

gcc/testsuite/ChangeLog:

PR modula2/110779
* gm2/iso/run/pass/m2date.mod: New test.
* gm2/iso/run/pass/testclock.mod: New test.
* gm2/iso/run/pass/testclock2.mod: New test.

Signed-off-by: Gaius Mulley 

[Bug c++/110913] internal compiler error when I pass temporary vector of string to co_await target function

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 105574.

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

[Bug c++/105574] coroutines: ICE when co_yield a r-value vector of non-POD type

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||redboltz at gmail dot com

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

[Bug modula2/110779] SysClock can not read the clock

[gaius at gcc dot gnu.org via Gcc-bugs]

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #5 from Gaius Mulley  ---
Closing now that the patch has been applied.

[Bug tree-optimization/110915] vector version of `x == MIN & x > y` is not optimized

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2023-08-05

[Bug tree-optimization/110915] New: vector version of `x == MIN & x > y` is not optimized

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 110915
   Summary: vector version of `x == MIN & x > y` is not optimized
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: pinskia at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Example:
```
#include 

#define vector __attribute__((vector_size(sizeof(unsigned)*2)))

vector signed fs(vector signed x, vector signed y)
{
  vector signed t = x == INT_MIN;
  vector signed t1 = x > y;
  return t & t1;
}
vector signed fu(vector unsigned x, vector unsigned y)
{
  vector signed t = x == 0;
  vector signed t1 = x > y;
  return t & t1;
}

 signed f2_1( signed x,  signed y)
{
   signed t = x == INT_MIN;
   signed t1 = x > y;
  return t & t1;
}
```

I am filing this as I am fixing the pointer version (PR 96695) and don't want
to lose track of this either.

[Bug tree-optimization/110915] vector version of `x == MIN & x > y` is not optimized

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Andrew Pinski  ---
These should work, I think, will try after finishing up the pointer:
(match min_value
 VECTOR_CST
 (with { tree inner = uniform_integer_cst_p (t); }
  (if (inner
   && INTEGRAL_TYPE_P (TREE_TYPE (inner))
   && wi::eq_p (wi::to_wide (inner), wi::min_value (TREE_TYPE (inner
  )
 )
)

(match max_value
 VECTOR_CST
 (with { tree inner = uniform_integer_cst_p (t); }
  (if (inner
   && INTEGRAL_TYPE_P (TREE_TYPE (inner))
   && wi::eq_p (wi::to_wide (inner), wi::max_value (TREE_TYPE (inner
  )
 )
)

[Bug tree-optimization/57650] Suboptimal code after TRUTH_AND_EXPR is changed into BIT_AND_EXPR

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Andrew Pinski  ---
Oh this is basically undoing the AND and then doing jump threading ...

[Bug modula2/108404] M2RTS_Halt fails with a segv (it should emit a diagnostic and exit).

[gaius at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Gaius Mulley  ---
I wonder if this bug has now been fixed via the other PR fixes.  Specifically
the rewrite of RTco.cc, the defensive use of select, bugfixes to HIGH and
FIO.mod (memcpy parameters)?  It might be worth a re-run just to explore the
effect of these fixes.

[Bug tree-optimization/96695] Failure to optimize combination of pointer comparison to nullptr and another pointer

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-August/
   ||626402.html

--- Comment #5 from Andrew Pinski  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626402.html

[Bug rtl-optimization/34072] unoptimal byte extraction.

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #4)
> So we still have an issue for the C++ example with memcpy.

But the code did improve from GCC 6 to GCC 7 though.
From
.cfi_startproc
subl$12, %esp
.cfi_def_cfa_offset 16
movzwl  16(%esp), %eax
addl$12, %esp
.cfi_def_cfa_offset 4
shrw$8, %ax
ret

To:
movl4(%esp), %eax
movzbl  %ah, %eax

So it is definitely already much better from when this was reported.

[Bug middle-end/52802] Equality rewrites pessimizes code

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org
  Component|rtl-optimization|middle-end

--- Comment #5 from Andrew Pinski  ---
I wonder if we could change `a <= 7` back to `a < 8` in isel if we notice we do
another comparison in either branch against `a` and `8`.

[Bug c++/110916] New: [12/13/14 Regression] Architecture-dependent missed optimizations for double swapping

[janschultke at googlemail dot com via Gcc-bugs]

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

Bug ID: 110916
   Summary: [12/13/14 Regression] Architecture-dependent missed
optimizations for double swapping
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: janschultke at googlemail dot com
  Target Milestone: ---

GCC's ability to eliminate redundant stores and loads is oddly dependent on the
architecture. Even on the same overall arch, compiling for Skylake in
particular performs always performs best.

On x86_64 -march=x86-64-v2, GCC 11 provides the optimal output. GCC 12/13/14
provide suboptimal output compared to -march=skylake.

On ARM64, a strange load and store from/to the same register is emitted. This
is the case for all version of GCC available on Compiler Explorer.

## Code to Reproduce (https://godbolt.org/z/d7Kcdn8fo)

static void swap(int* restrict a, int* restrict b) {
const int tmp = *a;
*a = *b;
*b = tmp;
}

void double_swap_alias(int* a, int* b) {
swap(a, b);
swap(a, b);
}

## Expected Output (x86_64 GCC 14 -O3 -march=skylake)

ret


## Actual Output (x86_64 GCC 14 -O3 -march=x86-64-v2)

mov edx, DWORD PTR [rsi]
mov eax, DWORD PTR [rdi]
mov DWORD PTR [rdi], edx
mov DWORD PTR [rsi], eax
mov edx, DWORD PTR [rdi]
mov DWORD PTR [rdi], eax
mov DWORD PTR [rsi], edx
ret


## Actual Output (ARM64 GCC 14 -O3)

ldr w0, [x1]
str w0, [x1]
ret

[Bug tree-optimization/110916] Architecture-dependent missed optimizations for double swapping

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c++ |tree-optimization
Summary|[12/13/14 Regression]   |Architecture-dependent
   |Architecture-dependent  |missed optimizations for
   |missed optimizations for|double swapping
   |double swapping |
 Status|UNCONFIRMED |NEW
  Known to work|11.4.0  |
   Last reconfirmed||2023-08-05
   Keywords||TREE
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Well this is missed optimization at the gimple level fully. It just happens to
be done at the RTL level if SImode is used all the way rather than V1SI mode.

Unless proved otherwise, I highly doubt this comes up in real code.

[Bug tree-optimization/110916] Architecture-dependent missed optimizations for double swapping

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||alias

--- Comment #2 from Andrew Pinski  ---
If the arguments to double_swap_alias are marked as restrict then it is
optimized at the gimple level.

[Bug fortran/103506] [11 Regression] ICE in gfc_free_namespace, at fortran/symbol.c:4039 since r10-2798-ge68a35ae4a65d2b3

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #19 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jerry DeLisle
:

https://gcc.gnu.org/g:238bce471c4391c47ffd4cd3f261f40006993f0e

commit r11-10936-g238bce471c4391c47ffd4cd3f261f40006993f0e
Author: Jerry DeLisle 
Date:   Sat Jan 28 20:00:34 2023 -0800

ICE in gfc_free_namespace. ice-on-invalid.

PR fortran/103506

gcc/fortran/ChangeLog:

* parse.c (parse_module): Remove use of a bool error value
that prevented proper setting of the namespace pointer.

gcc/testsuite/ChangeLog:

* gfortran.dg/pr103506_1.f90: New test.

(cherry picked from commit 8011fbba7baa46947341ca8069b5a327163a68d5)

[Bug fortran/103506] [11 Regression] ICE in gfc_free_namespace, at fortran/symbol.c:4039 since r10-2798-ge68a35ae4a65d2b3

[jvdelisle at gcc dot gnu.org via Gcc-bugs]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #20 from Jerry DeLisle  ---
Backports complete, closing.

[Bug fortran/107397] [11/12 Regression] ICE in gfc_arith_plus, at fortran/arith.cc:654

[jvdelisle at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #15 from Jerry DeLisle  ---
Working this now.

[Bug tree-optimization/106884] ifcombine may move shift so it shifts more than bitwidth

[kristerw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Krister Walfridsson  ---
One more similar case (that may be the same as comment #3):

int g;

void foo(int a, int b, int c, int d, int e)
{
  if ((10 + a) * b)
{
  g = (c || (g >> d)) << 1;
}
}

In this case, reassoc1 optimizes the IR for
  c || (g >> d)
to do 
  (c | (g >> d)) != 0
and we are now always doing the shift, even when c is true.

[Bug fortran/107397] [11/12 Regression] ICE in gfc_arith_plus, at fortran/arith.cc:654

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #16 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Jerry DeLisle
:

https://gcc.gnu.org/g:495332f16df1f73c185a02be428e227e20850752

commit r12-9801-g495332f16df1f73c185a02be428e227e20850752
Author: Steve Kargl 
Date:   Sat Dec 17 19:15:43 2022 -0800

Add a check for invalid use of BOZ with a derived type.

PR fortran/107397

gcc/fortran/ChangeLog:

* decl.cc (add_init_expr_to_sym): Add check with new error message.

gcc/testsuite/ChangeLog:

* gfortran.dg/pr107397.f90: New test.

(cherry picked from commit 09710f9934969dcb07131e1ed78b72e648123a3a)

[Bug fortran/107397] [11/12 Regression] ICE in gfc_arith_plus, at fortran/arith.cc:654

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #17 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Jerry DeLisle
:

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

commit r12-9802-ga3931bf6093dbeda637601da07cdbbd07e57ccbd
Author: Jakub Jelinek 
Date:   Mon Dec 19 11:24:55 2022 +0100

testsuite: Fix up pr107397.f90 test [PR107397]

The pr107397.f90 test FAILs for me, one problem was that the
added diagnostics has an indefinite article before BOZ, but
the test dg-error didn't.  The other problem was that on the
other dg-error there was no space between the string and closing
}, so it was completely ignored and the error was an excess
error.

2022-12-19  Jakub Jelinek  

PR fortran/107397
* gfortran.dg/pr107397.f90: Adjust expected diagnostic wording and
add space between dg-error string and closing }.

(cherry picked from commit 03fb35f8753d87148b29b3f34b6154abe7db4c41)

[Bug fortran/107397] [11/12 Regression] ICE in gfc_arith_plus, at fortran/arith.cc:654

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #19 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jerry DeLisle
:

https://gcc.gnu.org/g:088d907f69901f8d7e40ea099ccb5e42999c472c

commit r11-10939-g088d907f69901f8d7e40ea099ccb5e42999c472c
Author: Jakub Jelinek 
Date:   Mon Dec 19 11:24:55 2022 +0100

testsuite: Fix up pr107397.f90 test [PR107397]

The pr107397.f90 test FAILs for me, one problem was that the
added diagnostics has an indefinite article before BOZ, but
the test dg-error didn't.  The other problem was that on the
other dg-error there was no space between the string and closing
}, so it was completely ignored and the error was an excess
error.

2022-12-19  Jakub Jelinek  

PR fortran/107397
* gfortran.dg/pr107397.f90: Adjust expected diagnostic wording and
add space between dg-error string and closing }.

(cherry picked from commit 03fb35f8753d87148b29b3f34b6154abe7db4c41)

[Bug fortran/107397] [11/12 Regression] ICE in gfc_arith_plus, at fortran/arith.cc:654

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #18 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jerry DeLisle
:

https://gcc.gnu.org/g:276288556d6b4f535466ddbe560ede4c71b7fd2e

commit r11-10938-g276288556d6b4f535466ddbe560ede4c71b7fd2e
Author: Steve Kargl 
Date:   Sat Dec 17 19:15:43 2022 -0800

Add a check for invalid use of BOZ with a derived type.

PR fortran/107397

gcc/fortran/ChangeLog:

* decl.c (add_init_expr_to_sym): Add check with new error message.

gcc/testsuite/ChangeLog:

* gfortran.dg/pr107397.f90: New test.

(cherry picked from commit 09710f9934969dcb07131e1ed78b72e648123a3a)

[Bug tree-optimization/110897] RISC-V: Fail to vectorize shift

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #17 from JuzheZhong  ---
Confirm by this try:
https://godbolt.org/z/q7zx5zG5e

Both ARM SVE trunk GCC and RISC-V GCC failed to vectorize simple
unsigned short shift right, with following failed information:

:14:1: missed: couldn't vectorize loop
:14:1: missed: not vectorized: relevant stmt not supported: patt_47 =
MIN_EXPR <_7, 15>;
Compiler returned: 0

This following code can fix it:

index 2cedf2384..cda27fed9 100644
--- a/riscv-gcc/gcc/tree-vect-patterns.cc
+++ b/riscv-gcc/gcc/tree-vect-patterns.cc
@@ -3133,7 +3133,8 @@ vect_recog_over_widening_pattern (vec_info *vinfo,
return NULL;
}
  else
-   append_pattern_def_seq (vinfo, last_stmt_info, pattern_stmt);
+   append_pattern_def_seq (vinfo, last_stmt_info, pattern_stmt,
+   op_vectype);
  ops[1] = new_var;
}
 }


Bootstrap and Regression in progress, Ok for trunk ?

[Bug fortran/107397] [11/12 Regression] ICE in gfc_arith_plus, at fortran/arith.cc:654

[jvdelisle at gcc dot gnu.org via Gcc-bugs]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #20 from Jerry DeLisle  ---
Backports to 11 and 12 branches complete. Closing.

[Bug c++/102098] ICE when #include with -fmodules-ts -std=c++20 since r11-7530-g1e5cdb9f896fb220

[accelerator0099 at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Devourer Station  ---
Confirmed solved in 13.1.1

[Bug c++/103524] [meta-bug] modules issue

[accelerator0099 at gmail dot com via Gcc-bugs]

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

Bug 102098 Summary: ICE when #include  with -fmodules-ts 
-std=c++20 since r11-7530-g1e5cdb9f896fb220
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102098

   What|Removed |Added

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

[Bug c++/102098] ICE when #include with -fmodules-ts -std=c++20 since r11-7530-g1e5cdb9f896fb220

[accelerator0099 at gmail dot com via Gcc-bugs]

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

Devourer Station  changed:

   What|Removed |Added

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

--- Comment #8 from Devourer Station  ---
Confirmed fixed in 13.1.1

[Bug middle-end/110884] strncmp false positive with -Wstringop-overread on coreutils

[eggert at cs dot ucla.edu via Gcc-bugs]

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

--- Comment #3 from Paul Eggert  ---
(In reply to Richard Biener from comment #2)
> you are basically trying to use strcmp (a, b), so why not do that?

strcmp would not work on Fedora 38, or on most current coreutils platforms.

In the full coreutils code, src/system.h contains this definition[1]:

  /* n==-1 means unbounded */
  #define STREQ_LEN(a, b, n) (strncmp (a, b, n) == 0)

and src/who.c contains this expression[2]:

  STREQ_LEN (ttyname_b, utmp_buf->ut_line, UT_LINE_SIZE)

where UT_LINE_SIZE is an enum that is a small positive number on Fedora and
most platforms (where the arguments are UT_LINE_SIZE-byte character arrays,
possibly not null-terminated), and UT_LINE_SIZE is -1 on rare platforms (where
the arguments are char * pointers to null-terminated strings of unbounded
length).

By the way, we tried to work around the GCC false positive this way:

  #define STREQ_LEN(a, b, n) \
((n) < 0 ? strcmp (a, b) == 0 : strncmp (a, b, n) == 0)

but this didn't pacify GCC. When N is a negative constant expression, GCC emits
a -Wstringop-overread false positive even on the strncmp call that cannot
possibly be executed.

GCC -Wstringop-overread is supposed to (quoting the GCC manual) "Warn for calls
to string manipulation functions such as ‘memchr’, or ‘strcpy’ that are
determined to read past the end of the source sequence." But the abovementioned
calls to strncpy do not read past the end of the source sequence. So this is a
situation where either GCC's code or its documentation is incorrect.

Getting back to the code that prompted this bug report: strncmp is a primitive
designed for an oddball data structure designed back in the 1970s for tiny
machines. This data structure is a fixed-size character array that either
contains a null-terminated string, or contains all non-null bytes. Nobody liked
this data structure back in the day; people put up with it only because the
machines were so small (and hey! I was there! I wrote code for those
machines!). Nowadays the only code that should use strncmp is code like
coreutils/src/who.c that is still stick with ancient data structures designed
for 1970s machines. People who maintain legacy strncmp-using code should know
what they're doing, and if you know what you're doing (as I hope is the case
with the GNU coreutils maintainers :-) it's OK to pass SIZE_MAX to strncmp.

[1]: https://git.savannah.gnu.org/cgit/coreutils.git/tree/src/system.h#n195
[2]: https://git.savannah.gnu.org/cgit/coreutils.git/tree/src/who.c#n612



(In reply to Andrew Pinski from comment #1)
> You could use SSIZE_MAX here ...
> That is what 9223372036854775807 is in this case ...

Although that would work on GNU/Linux, POSIX doesn't guarantee it to be
portable, since ssize_t be 32 bits on platforms with 64-bit size_t (and some
historical implementations did that; on these systems syscalls like 'read'
never returned a value greater than 2**31 - 1).

Using (PTRDIFF_MAX < SIZE_MAX ? PTRDIFF_MAX : SIZE_MAX) would work, but is (as
I wrote) awkward. Among other things, the coreutils code uses an enum to record
the size (or -1), and enums can't portably hold values as large as SIZE_MAX or
PTRDIFF_MAX. So we'd have to use a macro instead, and that would have its own
problems.

[Bug middle-end/110884] strncmp false positive with -Wstringop-overread on coreutils

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Paul Eggert from comment #3)
> 
> Using (PTRDIFF_MAX < SIZE_MAX ? PTRDIFF_MAX : SIZE_MAX) would work, but is
> (as I wrote) awkward. Among other things, the coreutils code uses an enum to
> record the size (or -1), and enums can't portably hold values as large as
> SIZE_MAX or PTRDIFF_MAX. So we'd have to use a macro instead, and that would
> have its own problems.

PTRDIFF_MAX is required to be less than SIZE_MAX and is the max size of an
array because otherwise a-b would be undefined ...

[Bug tree-optimization/110897] RISC-V: Fail to vectorize shift

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #18 from JuzheZhong  ---
(In reply to JuzheZhong from comment #17)
> Confirm by this try:
> https://godbolt.org/z/q7zx5zG5e
> 
> Both ARM SVE trunk GCC and RISC-V GCC failed to vectorize simple
> unsigned short shift right, with following failed information:
> 
> :14:1: missed: couldn't vectorize loop
> :14:1: missed: not vectorized: relevant stmt not supported: patt_47
> = MIN_EXPR <_7, 15>;
> Compiler returned: 0
> 
> This following code can fix it:
> 
> index 2cedf2384..cda27fed9 100644
> --- a/riscv-gcc/gcc/tree-vect-patterns.cc
> +++ b/riscv-gcc/gcc/tree-vect-patterns.cc
> @@ -3133,7 +3133,8 @@ vect_recog_over_widening_pattern (vec_info *vinfo,
> return NULL;
> }
>   else
> -   append_pattern_def_seq (vinfo, last_stmt_info, pattern_stmt);
> +   append_pattern_def_seq (vinfo, last_stmt_info, pattern_stmt,
> +   op_vectype);
>   ops[1] = new_var;
> }
>  }
> 
> 
> Bootstrap and Regression in progress, Ok for trunk ?

Bootstrap and regression on X86 passed.

[Bug libstdc++/110917] New: std::format_to(int*, ...) fails to compile because of _S_make_span

[arthur.j.odwyer at gmail dot com via Gcc-bugs]

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

Bug ID: 110917
   Summary: std::format_to(int*, ...) fails to compile because of
_S_make_span
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arthur.j.odwyer at gmail dot com
  Target Milestone: ---

// https://godbolt.org/z/9onGvqfha
#include 
#include 
#include 

void f(std::list::iterator it) {
std::format_to(it, "");  // OK
}
void g(std::vector::iterator it) {
std::format_to(it, "");  // boom!
}

libc++ and Microsoft are both completely happy with this code. libstdc++ is
happy with `f` but unhappy with `g`. I suspect that someplace is accepting
"contiguous iterators of any old T" when it means to limit itself to
"contiguous iterators of char" specifically.


In file included from :1:
.../include/c++/14.0.0/format:2609:36: error: cannot initialize a parameter of
type 'char *' with an rvalue of type 'int *'
 2609 |   : _Sink<_CharT>(_S_make_span(std::to_address(__out), __n,
_M_buf)),
  |^~
.../include/c++/14.0.0/format:3641:32: note: in instantiation of member
function 'std::__format::_Iter_sink>>::_Iter_sink' requested here
 3641 |   _Iter_sink<_CharT, _Out> __sink(std::move(__out));
  |^
.../include/c++/14.0.0/format:3683:24: note: in instantiation of function
template specialization
'std::__format::__do_vformat_to<__gnu_cxx::__normal_iterator>, char,
std::basic_format_context, char>>' requested
here
 3683 | { return __format::__do_vformat_to(std::move(__out), __fmt,
__args); }
  |^
.../include/c++/14.0.0/format:3778:19: note: in instantiation of function
template specialization 'std::vformat_to<__gnu_cxx::__normal_iterator>>' requested here
 3778 |   return std::vformat_to(std::move(__out), __fmt.get(),
  |   ^
:9:10: note: in instantiation of function template specialization
'std::format_to<__gnu_cxx::__normal_iterator>>'
requested here
9 | std::format_to(it, "");
  |  ^
.../include/c++/14.0.0/format:2574:28: note: passing argument to parameter
'__ptr' here
 2574 |   _S_make_span(_CharT* __ptr, iter_difference_t<_OutIter> __n,
  |^
1 error generated.

[Bug middle-end/110884] strncmp false positive with -Wstringop-overread on coreutils

[eggert at cs dot ucla.edu via Gcc-bugs]

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

--- Comment #5 from Paul Eggert  ---
(In reply to Andrew Pinski from comment #4)
> PTRDIFF_MAX is required to be less than SIZE_MAX and is the max size of an
> array because otherwise a-b would be undefined ...

That is true for glibc, but it's not guaranteed by the C standard or by POSIX,
and coreutils tries to be portable to odd but conforming platforms. In theory
size_t can be 32 bits while ptrdiff_t is 64 bits. It's not much trouble to
write MIN (PTRDIFF_MAX, SIZE_MAX) in the few places where it matters.

C and POSIX also allow arrays with more than PTRDIFF_MAX elements. However,
coreutils takes pains to never create such an array, even on the non-glibc
platforms that allow them; this avoids the undefined behavior you mentioned.