[Bug c/69960] "initializer element is not constant"

[daniel.lundin.mail at gmail dot com via Gcc-bugs]

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

--- Comment #23 from Daniel Lundin  ---
(In reply to jos...@codesourcery.com from comment #21)
> On Wed, 22 Feb 2023, daniel.lundin.mail at gmail dot com via Gcc-bugs wrote:
> 
> > First of all, it is questionable if gcc is still conforming after the change
> > discussed here and implemented as per gcc 8.0. Yes "an implementation may
> > accept other forms of constant expressions" but that doesn't mean that a
> > compiler is allowed to ignore the constraints in C17 6.7.9/4 nor the 
> > definition
> > of an integer constant expression. So this ought to explicitly be a compiler
> > extension and we ought to have a way to reliably compile strictly conforming
> > programs with gcc without constraint violations silently getting ignored. 
> 
> "integer constant expression" does not mean the same thing as "constant 
> expression of integer type".  

Yes, who said otherwise? Rather, this is the problem. Please check out the link
I gave for the full reasoning including quotes.
https://stackoverflow.com/questions/68252570/why-are-const-qualified-variables-accepted-as-initializers-on-gcc

Specifically (C17 6.6):

"An integer constant expression shall have integer type and shall only have
operands that are integer constants, enumeration constants, character
constants, sizeof expressions whose results are integer constants, _Alignof
expressions, and floating constants that are the immediate operands of casts."

In this code 

static const int y = 1;
static int x = y;

y is not an integer constant expression, nor is it an integer constant in the
meaning that ISO 9899 defines it. Therefore an initializer was given which is
not a constant expression. Therefore this is a constraint violation of C17
6.7.9/4 and a diagnostic must be issued. Therefore gcc is not conforming
because of the "bug fix" carried out above.

"an implementation may accept other forms of constant expressions" does not
mean that an implementation can throw out any constraints it pleases out the
window. Also the text "however, they are not an integer constant expression"
added in C23 must have been added for a reason, such as misbehaving compilers.

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

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

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

--- Comment #7 from Iain Sandoe  ---
(In reply to ibuclaw from comment #6)
> There's r13-1113 with introduced the use of visible().
> 
> Can't see anything odd about the virtual function declaration that would
> suggest there's a mismatch between C++/D.
> 
> It does return a struct though.  Is there maybe something special done in
> the way structs are returned on 32-bit OSX that doesn't occur on 32-bit
> Linux?

Well, I can re-check (there _are_ some differences between x86 Darwin / Linux,
where x86_64 is supposed to be the same).

 - but is that not the province of the middle & back-ends?
   why would it make any difference what the FE language does?

> I could also just revert to accessing the underlying `->visibility` field
> directly, if it really is just that function call that's problematic.

We cannot really tell, since the build does not get beyond stage1 - so that
we're nowhere near running the testsuite.

This was on Darwin17, for reference - so the most modern supported 32b case.

[Bug testsuite/108899] New: [13 Regression] ERROR: can't rename to "saved-unsupported": command already exists on i386

[haochen.jiang at intel dot com via Gcc-bugs]

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

Bug ID: 108899
   Summary: [13 Regression] ERROR: can't rename to
"saved-unsupported": command already exists on i386
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haochen.jiang at intel dot com
  Target Milestone: ---

We currently got these errors on i386 when running tests.

ERROR: can't rename to "saved-unsupported": command already exists
ERROR: in testcase
/export/gnu/import/git/gcc-test-master-intel64-native/src-master/gcc/testsuite/g++.dg/modules/modules.exp

I checked the trunk and I suppose it is probably caused by
r13-6288-g5344482c4d3ae0618fa8f5ed38f8309db43fdb82.

This commit changed modules.exp and rename unsupported to saved-unsupported.

Feel free to correct me if I am wrong.

[Bug rtl-optimization/108273] Inconsistent dfa state between debug and non-debug

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

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

--- Comment #3 from Kewen Lin  ---
The attached patch can be bootstrapped and regress-tested and solve the
reported issue right after r13-5107-g6224db0e4d6d3b, but I can not reproduce
the failure with the latest trunk, interesting... I suspected that something
changed the insn sequence and made the issue concealed, bisecting ...

[Bug rtl-optimization/108273] Inconsistent dfa state between debug and non-debug

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

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

--- Comment #2 from Kewen Lin  ---
Created attachment 54512
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54512=edit
Consider debug insn in no_real_insns_p

[Bug rtl-optimization/108273] Inconsistent dfa state between debug and non-debug

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

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

Kewen Lin  changed:

   What|Removed |Added

   Last reconfirmed||2023-02-23
   Assignee|unassigned at gcc dot gnu.org  |linkw at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

[Bug testsuite/108898] New: [13 Regression] Test introduced by r13-6278-g3da77f217c8b2089ecba3eb201e727c3fcdcd19d failed on i386

[haochen.jiang at intel dot com via Gcc-bugs]

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

Bug ID: 108898
   Summary: [13 Regression] Test introduced by
r13-6278-g3da77f217c8b2089ecba3eb201e727c3fcdcd19d
failed on i386
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haochen.jiang at intel dot com
  Target Milestone: ---

r13-6278-g3da77f217c8b2089ecba3eb201e727c3fcdcd19d introduced
gcc.dg/vect/vect-simd-clone-1{6,7,8}{,b,c,d,e,f}.c.

My bisect script showed it caused these FAIL:

FAIL: gcc.dg/vect/vect-simd-clone-18e.c scan-tree-dump-times vect "[\\n\\r]
[^\\n]* = foo\\.simdclone" 3
FAIL: gcc.dg/vect/vect-simd-clone-18e.c scan-tree-dump-times vect "[\\n\\r]
[^\\n]* = foo\\.simdclone" 3
FAIL: gcc.dg/vect/vect-simd-clone-18f.c scan-tree-dump-times vect "[\\n\\r]
[^\\n]* = foo\\.simdclone" 2
FAIL: gcc.dg/vect/vect-simd-clone-18f.c scan-tree-dump-times vect "[\\n\\r]
[^\\n]* = foo\\.simdclone" 2
FAIL: gcc.dg/vect/vect-simd-clone-18f.c scan-tree-dump-times vect "[\\n\\r]
[^\\n]* = foo\\.simdclone" 2

And I suppose other FAIL are also related to this commit:

FAIL: gcc.dg/vect/vect-simd-clone-16.c scan-tree-dump-times vect "[\\n\\r]
[^\\n]* = foo\\.simdclone" 2
FAIL: gcc.dg/vect/vect-simd-clone-16.c scan-tree-dump-times vect "[\\n\\r]
[^\\n]* = foo\\.simdclone" 2
FAIL: gcc.dg/vect/vect-simd-clone-16.c scan-tree-dump-times vect "[\\n\\r]
[^\\n]* = foo\\.simdclone" 2
FAIL: gcc.dg/vect/vect-simd-clone-16e.c scan-tree-dump-times vect "[\\n\\r]
[^\\n]* = foo\\.simdclone" 3
FAIL: gcc.dg/vect/vect-simd-clone-16e.c scan-tree-dump-times vect "[\\n\\r]
[^\\n]* = foo\\.simdclone" 3
FAIL: gcc.dg/vect/vect-simd-clone-16f.c scan-tree-dump-times vect "[\\n\\r]
[^\\n]* = foo\\.simdclone" 2
FAIL: gcc.dg/vect/vect-simd-clone-16f.c scan-tree-dump-times vect "[\\n\\r]
[^\\n]* = foo\\.simdclone" 2
FAIL: gcc.dg/vect/vect-simd-clone-16f.c scan-tree-dump-times vect "[\\n\\r]
[^\\n]* = foo\\.simdclone" 2
FAIL: gcc.dg/vect/vect-simd-clone-17.c scan-tree-dump-times vect "[\\n\\r]
[^\\n]* = foo\\.simdclone" 2
FAIL: gcc.dg/vect/vect-simd-clone-17.c scan-tree-dump-times vect "[\\n\\r]
[^\\n]* = foo\\.simdclone" 2
FAIL: gcc.dg/vect/vect-simd-clone-17.c scan-tree-dump-times vect "[\\n\\r]
[^\\n]* = foo\\.simdclone" 2
FAIL: gcc.dg/vect/vect-simd-clone-17e.c scan-tree-dump-times vect "[\\n\\r]
[^\\n]* = foo\\.simdclone" 3
FAIL: gcc.dg/vect/vect-simd-clone-17e.c scan-tree-dump-times vect "[\\n\\r]
[^\\n]* = foo\\.simdclone" 3
FAIL: gcc.dg/vect/vect-simd-clone-17f.c scan-tree-dump-times vect "[\\n\\r]
[^\\n]* = foo\\.simdclone" 2
FAIL: gcc.dg/vect/vect-simd-clone-17f.c scan-tree-dump-times vect "[\\n\\r]
[^\\n]* = foo\\.simdclone" 2
FAIL: gcc.dg/vect/vect-simd-clone-17f.c scan-tree-dump-times vect "[\\n\\r]
[^\\n]* = foo\\.simdclone" 2
FAIL: gcc.dg/vect/vect-simd-clone-18.c scan-tree-dump-times vect "[\\n\\r]
[^\\n]* = foo\\.simdclone" 2
FAIL: gcc.dg/vect/vect-simd-clone-18.c scan-tree-dump-times vect "[\\n\\r]
[^\\n]* = foo\\.simdclone" 2
FAIL: gcc.dg/vect/vect-simd-clone-18.c scan-tree-dump-times vect "[\\n\\r]
[^\\n]* = foo\\.simdclone" 2

[Bug c++/108897] Comparing pointer to field in rvalue class is not considered constant expression

[danakj at orodu dot net via Gcc-bugs]

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

--- Comment #2 from danakj at orodu dot net ---
Thank you for the workaround!

[Bug c++/85944] Address of temporary bound to a function parameter at global scope not considered constexpr

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||danakj at orodu dot net

--- Comment #8 from Patrick Palka  ---
*** Bug 108897 has been marked as a duplicate of this bug. ***

[Bug c++/108897] Comparing pointer to field in rvalue class is not considered constant expression

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #1 from Patrick Palka  ---
dup of PR85944

One workaround is to place the static_assert in function scope instead of
namespace scope, e.g.

void my_static_asserts() {
  static_assert(S{2}.ptr() != nullptr);
  static_assert(S{2}.p != nullptr);
}

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

[Bug c++/108897] New: Comparing pointer to field in rvalue class is not considered constant expression

[danakj at orodu dot net via Gcc-bugs]

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

Bug ID: 108897
   Summary: Comparing pointer to field in rvalue class is not
considered constant expression
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danakj at orodu dot net
  Target Milestone: ---

This reproduces on godbolt in GCC 10, 11, 12, and trunk.

A pointer to a field of a structure that is constructed as an rvalue temporary
object can not be compared in a constant expression.

```
struct S {
int i;
int *p = 
constexpr const int* ptr() const { return  }
};

// Not constant expression in GCC.
static_assert(S{2}.ptr() != nullptr);
static_assert(S{2}.p != nullptr);

// Is a constant expression.
static_assert(*S{2}.ptr() == 2);
static_assert(*S{2}.p == 2);

static_assert([]() constexpr {
S r(2);

// Is a constant expression.
return r.ptr() != nullptr && r.p != nullptr;
}());
```

Errors:
:8:26: error: non-constant condition for static assertion
8 | static_assert(S{2}.ptr() != nullptr);
  |   ~~~^~
:8:26: error: '((&.S::i) != 0)' is not a constant expression
:9:22: error: non-constant condition for static assertion
9 | static_assert(S{2}.p != nullptr);
  |   ~~~^~
:9:22: error: '((&.S::i) != 0)' is not a constant expression


- Generates errors for comparing `ptr()` or `p` to nullptr.
- Dereferencing the pointer does not generate an error.
- If the object S is stored as an lvalue, then the pointer comparison is a
constant expression.

Godbolt: https://godbolt.org/z/P9GGKeb3Y

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

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

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

ibuclaw at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ibuclaw at gcc dot gnu.org

--- Comment #6 from ibuclaw at gcc dot gnu.org ---
There's r13-1113 with introduced the use of visible().

Can't see anything odd about the virtual function declaration that would
suggest there's a mismatch between C++/D.

It does return a struct though.  Is there maybe something special done in the
way structs are returned on 32-bit OSX that doesn't occur on 32-bit Linux?

I could also just revert to accessing the underlying `->visibility` field
directly, if it really is just that function call that's problematic.

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

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

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||ice-on-valid-code
 Ever confirmed|0   |1
 Target|i386-apple-darwin11.4.2 |i?86-apple-darwin*
   Last reconfirmed||2023-02-22

--- Comment #5 from Iain Sandoe  ---
with the latest D updates (as of 2023-02-22) this seems to be still present:

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x43)
frame #0: 0x00054e38 d21`Declaration::visible(this=0x0007) at
declaration.d:562
   559  
   560  override final Visibility visible() pure nothrow @nogc @safe
   561  {
-> 562  return visibility;
   563  }
   564  
   565  override final inout(Declaration) isDeclaration() inout pure
nothrow @nogc @safe
Target 0: (d21) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x43)
  * frame #0: 0x00054e38 d21`Declaration::visible(this=0x0007) at
declaration.d:562
frame #1: 0x00200841 d21`get_symbol_decl(Declaration*) (.part.0) + 849
frame #2: 0x00203b27 d21`DeclVisitor::visit(FuncDeclaration*) + 775
frame #3: 0x001fdf0c d21`DeclVisitor::visit(AttribDeclaration*) + 92
frame #4: 0x001fed8c d21`build_decl_tree(Dsymbol*) + 92
frame #5: 0x00212a39 d21`build_module_tree(Module*) + 137
frame #6: 0x001fcaa7 d21`DeclVisitor::visit(Module*) + 23
frame #7: 0x001fed8c d21`build_decl_tree(Dsymbol*) + 92
frame #8: 0x001f9469 d21`d_parse_file() + 3897
frame #9: 0x01420234 d21`compile_file() + 36
frame #10: 0x01c5f870 d21`toplev::main(int, char**) + 5696
frame #11: 0x01c60cc4 d21`main + 36
frame #12: 0xa7273611 libdyld.dylib`start + 1

[Bug c/108880] [11/12 Regression] slow compilation with "-fsanitize=undefined"

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

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[11/12/13 Regression] slow  |[11/12 Regression] slow
   |compilation with|compilation with
   |"-fsanitize=undefined"  |"-fsanitize=undefined"

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

[Bug c/108880] [11/12/13 Regression] slow compilation with "-fsanitize=undefined"

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

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

--- Comment #15 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:1370014f2ea02ec185cf1199027575916f79fe63

commit r13-6290-g1370014f2ea02ec185cf1199027575916f79fe63
Author: Marek Polacek 
Date:   Wed Feb 22 15:17:03 2023 -0500

c-family: avoid compile-time-hog in c_genericize [PR108880]

This fixes a compile-time hog with UBSan.  This only happened in cc1 but
not cc1plus.  The problem is ultimately that c_genericize_control_stmt/
STATEMENT_LIST -> walk_tree_1 doesn't use a hash_set to remember visited
nodes, so it kept on recursing for a long time.  We should be able to
use the pset that c_genericize created.  We just need to use walk_tree
instead of walk_tree_w_d so that the pset is explicit.

PR c/108880

gcc/c-family/ChangeLog:

* c-gimplify.cc (c_genericize_control_stmt) :
Pass
pset to walk_tree_1.
(c_genericize): Call walk_tree with an explicit pset.

gcc/testsuite/ChangeLog:

* c-c++-common/ubsan/pr108880.c: New test.

[Bug target/83670] [10/11/12/13 Regression] m32c ICE in leaf_function_p, at final.c:4368

[mike at mnmoran dot org via Gcc-bugs]

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

Michael N. Moran  changed:

   What|Removed |Added

 CC||mike at mnmoran dot org

--- Comment #10 from Michael N. Moran  ---
Created attachment 54511
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54511=edit
ICE report

This is the -freport-bug output for an m32c build on GCC 12.1.0

[Bug sanitizer/108894] -fsanitize=bounds missing bounds provided by __builtin_dynamic_object_size()

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

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

--- Comment #3 from Jakub Jelinek  ---
-fstrict-flex-array= option doesn't affect the sanitization, if you want strict
sanitization of bounds, you should use -fsanitize=bounds-strict rather than
-fsanitize=bounds.
Furthermore, it is misunderstanding on what either of those sanitizers does,
they check the array index against the array domain.  In the case of flexible
array member, that size is unlimited, not some constant or variable (that would
be just in case of a VLA).
If you want sanitization against object size, there is -fsanitize=object-size
for it.

[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds

[kees at outflux dot net via Gcc-bugs]

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

--- Comment #1 from Kees Cook  ---
The corresponding Clang feature request is here:
https://github.com/llvm/llvm-project/issues/60928

[Bug c/108896] New: provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds

[kees at outflux dot net via Gcc-bugs]

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

Bug ID: 108896
   Summary: provide "element_count" attribute to give more context
to __builtin_dynamic_object_size() and
-fsanitize=bounds
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kees at outflux dot net
  Target Milestone: ---

Frequently a structure containing a flexible array member will also contain a
member where the count of array elements is stored. For example:

struct foo {
...
unsigned int count;
...
int data[];
};

struct foo *allocate_foo(unsigned int how_many)
{
struct foo *p;

p = malloc(sizeof(*p) + how_many * sizeof(*byte_array));
p->count = how_many;

return p;
}

While __builtin_dynamic_object_size(p->data, 1) will know the size within
"allocate_foo" due to malloc's __alloc_size hinting, this information is
immediately lost on return. However, the information _is_ still available in
p->count, but the compiler has no way to know about it.

Please provide a struct member attribute "element_count" that can be used to
associate the size of a flexible array to another struct member. For example:

struct foo {
...
unsigned int count;
...
int data[] __attribute__((__element_count__(count)));
};

Now any later examination of the size of "data" can be calculated. For example,
this equality will hold true:

__builtin_dynamic_object_size(p->data) == p->count * sizeof(*p->data)

and -fsanitize-bounds can examine this as well, to trap:

p->data[index] = ...; /* traps when index < 0, or index >= p->count */

[Bug libgomp/108895] New: [13.0.1 (exp)] Fortran + gfx90a !$acc update device produces a segfault.

[hberre3 at gatech dot edu via Gcc-bugs]

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

Bug ID: 108895
   Summary: [13.0.1 (exp)] Fortran + gfx90a !$acc update device
produces a segfault.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hberre3 at gatech dot edu
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Created attachment 54510
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54510=edit
The minimal reproducible sample (fortran + openacc).

gfortran configuration:

> [hberre3@96:instinct]:gcc-acc-test $ gfortran -v
> Using built-in specs.
> COLLECT_GCC=gfortran
> COLLECT_LTO_WRAPPER=/nethome/hberre3/gcc-acc/libexec/gcc/x86_64-pc-linux-gnu/13.0.1/lto-wrapper
> OFFLOAD_TARGET_NAMES=amdgcn-amdhsa
> Target: x86_64-pc-linux-gnu
> Configured with: 
> /nethome/hberre3/temp-gcc-acc-work/build-gcc-amdgpu//gcc/configure 
> --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu 
> --target=x86_64-pc-linux-gnu 
> --enable-offload-targets=amdgcn-amdhsa=/nethome/hberre3/gcc-acc//amdgcn-amdhsa
>  --enable-languages=c,c++,fortran,lto --disable-multilib 
> --prefix=/nethome/hberre3/gcc-acc/
> Thread model: posix
> Supported LTO compression algorithms: zlib zstd
> gcc version 13.0.1 20230219 (experimental) (GCC)

Compiled on:

> GNU:  0263e9d5d84b4abbb53e73fbc8d72fd233764fc8 (master)
> LLVM: llvmorg-13.0.1 (GitHub release)

Minimal reproducible (also found attached):

> ! Henry Le Berre  
> 
> program p_main
> 
> real(kind(0d0)), allocatable, dimension(:) :: arrs
> !$acc declare create(arrs)
> 
> allocate(arrs(1000))
> !$acc enter data create(arrs(1000))
> !$acc update device(arrs(1:1000))
> 
> end program

Compiled with:

> gfortran -g -fopenacc -foffload-options=-march=gfx90a sample.f90 -o sample

Produces:

> [hberre3@102:instinct]:gcc-acc-test $ ./sample
> 
> Program received signal SIGSEGV: Segmentation fault - invalid memory 
> reference.
>
> Backtrace for this error:
> #0  0x7fd01c643b1f in ???
> #1  0x7fd01c6c4ee9 in ???
> #2  0x7fd01bdf6007 in ???
> #3  0x7fd01bdd921f in ???
> #4  0x7fd01c1e5088 in hsa_memory_copy_wrapper
>   at 
> /nethome/hberre3/temp-gcc-acc-work/build-gcc-amdgpu//gcc/libgomp/plugin/plugin-gcn.c:2958
> #5  0x7fd01c1eb1eb in GOMP_OFFLOAD_host2dev
>   at 
> /nethome/hberre3/temp-gcc-acc-work/build-gcc-amdgpu//gcc/libgomp/plugin/plugin-gcn.c:3796
> #6  0x7fd01ce25cba in gomp_device_copy
>   at 
> /nethome/hberre3/temp-gcc-acc-work/build-gcc-amdgpu//gcc/libgomp/target.c:234
> #7  0x7fd01ce25cba in gomp_copy_host2dev
>   at 
> /nethome/hberre3/temp-gcc-acc-work/build-gcc-amdgpu//gcc/libgomp/target.c:433
> #8  0x7fd01ce35596 in update_dev_host
>   at 
> /nethome/hberre3/temp-gcc-acc-work/build-gcc-amdgpu//gcc/libgomp/oacc-mem.c:877
> #9  0x7fd01ce33142 in GOACC_update
>   at 
> /nethome/hberre3/temp-gcc-acc-work/build-gcc-amdgpu//gcc/libgomp/oacc-parallel.c:678
> #10  0x400cad in p_main
>   at /nethome/hberre3/gcc-acc-test/sample.f90:10
> #11  0x400ced in main
>   at /nethome/hberre3/gcc-acc-test/sample.f90:3
> Segmentation fault (core dumped)

Observations:

1) If the length/size of the array were smaller (say 10 or 100) no segmentation
fault is observed, possibly indicating silent R/W operations to memory we don't
own.

2) On ORNL Summit's GCC 8.3.1 (nvptx), this sample does not produce a segfault.
It was configured with:

> [henrylb@login4.summit ~]$ gcc -v
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/ppc64le-redhat-linux/8/lto-wrapper
> OFFLOAD_TARGET_NAMES=nvptx-none
> OFFLOAD_TARGET_DEFAULT=1
> Target: ppc64le-redhat-linux
> Configured with: ../configure --enable-bootstrap 
> --enable-languages=c,c++,fortran,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-targets=powerpcle-linux --disable-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 --disable-libmpx 
> --enable-offload-targets=nvptx-none --without-cuda-driver 
> --enable-gnu-indirect-function --enable-secureplt --with-long-double-128 
> --with-cpu-32=power8 --with-tune-32=power8 --with-cpu-64=power8 
> --with-tune-64=power8 --build=ppc64le-redhat-linux
> Thread model: posix
> gcc version 8.3.1 20191121 (Red Hat 8.3.1-5) (GCC)

3) If I translate this sample to C, no matter how large the array is, a
segfault is not produced. Please excuse me if this C/OpenACC sample is invalid
as I only use hip/Cuda when writing offloaded code in C/C++. This might
indicate it is not an issue with libomp 

[Bug sanitizer/108894] -fsanitize=bounds missing bounds provided by __builtin_dynamic_object_size()

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2023-02-22
 Status|UNCONFIRMED |NEW

[Bug sanitizer/108894] -fsanitize=bounds missing bounds provided by __builtin_dynamic_object_size()

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug sanitizer/108894] -fsanitize=bounds missing bounds provided by __builtin_dynamic_object_size()

[kees at outflux dot net via Gcc-bugs]

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

Kees Cook  changed:

   What|Removed |Added

  Attachment #54508|0   |1
is obsolete||

--- Comment #2 from Kees Cook  ---
Created attachment 54509
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54509=edit
PoC showing lack of __bdos support in -fsanitize=bounds

(Updated PoC so the "unknown" case correctly said "ignored" instead of
"ok"/"failure" -- the unknown size case must continue to be ignored.)

[Bug sanitizer/108894] -fsanitize=bounds missing bounds provided by __builtin_dynamic_object_size()

[kees at outflux dot net via Gcc-bugs]

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

--- Comment #1 from Kees Cook  ---
The matching Clang bug is: https://github.com/llvm/llvm-project/issues/60926

[Bug sanitizer/108894] New: -fsanitize=bounds missing bounds provided by __builtin_dynamic_object_size()

[kees at outflux dot net via Gcc-bugs]

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

Bug ID: 108894
   Summary: -fsanitize=bounds missing bounds provided by
__builtin_dynamic_object_size()
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kees at outflux dot net
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

Created attachment 54508
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54508=edit
PoC showing lack of __bdos support in -fsanitize=bounds

While -fsanitize-bounds is able to perform run-time bounds checking on
fixed-size arrays (i.e. when __builtin_object_size(x, 1) does not return
SIZE_MAX), it does not perform bounds checking when
__builtin_dynamic_object_size(x, 1) is available.

For example, the attached program produces _no_ bounds-checker warnings:

$ gcc -Wall -O2 -fstrict-flex-arrays=3 -fsanitize=bounds -fstrict-flex-arrays=3
-o bounds bounds.c
$ ./bounds

p->array has a fixed size: 64 (16 elements of size 4)
p->array[0] assignment: 255 (should be ok)
p->array[16] assignment: 255 (should be failure)

p->array has a dynamic size: 64 (16 elements of size 4)
p->array[0] assignment: 255 (should be ok)
p->array[16] assignment: 255 (should be failure)

p->array has unknowable size
p->array[0] assignment: 255 (should be ok)
p->array[16] assignment: 255 (should be failure)


Note that the first failure for a fixed size array implies that
-fsanitize=bounds has also not been wired up to -fstrict-flex-arrays=3, so it
is ignoring all trailing arrays.

[Bug c++/108893] attribute access read_only

[jg at jguk dot org via Gcc-bugs]

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

--- Comment #4 from Jonny Grant  ---
My apologies, I had understood attribute access read_only was different from
the attribute nonnull. So I filed a different report for this.

I didn't want to use __attribute__((nonnull)) because the optimizer may use
that knowledge to remove nullptr checks. access read_only I hoped would just
warn about the dereference.

Unfortunately I pasted the wrong example link in the report.

[Bug c/108880] [11/12/13 Regression] slow compilation with "-fsanitize=undefined"

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

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

--- Comment #14 from Marek Polacek  ---
(In reply to Jakub Jelinek from comment #13)
> (In reply to Marek Polacek from comment #12)
> > Sure, it worked for the testcase because the STATEMENT_LIST only had two
> > stmts.  I'm testing:
> > 
> > --- a/gcc/c-family/c-gimplify.cc
> > +++ b/gcc/c-family/c-gimplify.cc
> > @@ -516,7 +516,8 @@ c_genericize_control_stmt (tree *stmt_p, int
> > *walk_subtrees, void *data,
> >   tree t = tsi_stmt (i);
> >   if (TREE_CODE (t) != DEBUG_BEGIN_STMT && nondebug_stmts < 2)
> > nondebug_stmts++;
> > - walk_tree_1 (tsi_stmt_ptr (i), func, data, NULL, lh);
> > + walk_tree_1 (tsi_stmt_ptr (i), func, data,
> > +  static_cast *>(data), lh);
> 
> I'd limit this change to !c_dialect_cxx () only, I'm afraid if it is done
> for C++ too, then cp_genericize_r won't then walk into those trees later on
> and could avoid replacing there something important.  While for C, there is
> walk_tree solely for the purposes of c_genericize_control* and nothing else.
> To avoid testing it in every iteration you could have a hash_set *pset
> temporary initialized based on c_dialect_cxx () to NULL or data and then
> just use it in the loop.

Yeah, in C++ I get a crash in check_complete_insertion anyway.  I don't really
see why but best to limit it to C.

[Bug c/108880] [11/12/13 Regression] slow compilation with "-fsanitize=undefined"

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

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

--- Comment #13 from Jakub Jelinek  ---
(In reply to Marek Polacek from comment #12)
> Sure, it worked for the testcase because the STATEMENT_LIST only had two
> stmts.  I'm testing:
> 
> --- a/gcc/c-family/c-gimplify.cc
> +++ b/gcc/c-family/c-gimplify.cc
> @@ -516,7 +516,8 @@ c_genericize_control_stmt (tree *stmt_p, int
> *walk_subtrees, void *data,
>   tree t = tsi_stmt (i);
>   if (TREE_CODE (t) != DEBUG_BEGIN_STMT && nondebug_stmts < 2)
> nondebug_stmts++;
> - walk_tree_1 (tsi_stmt_ptr (i), func, data, NULL, lh);
> + walk_tree_1 (tsi_stmt_ptr (i), func, data,
> +  static_cast *>(data), lh);

I'd limit this change to !c_dialect_cxx () only, I'm afraid if it is done
for C++ too, then cp_genericize_r won't then walk into those trees later on and
could avoid replacing there something important.  While for C, there is
walk_tree solely for the purposes of c_genericize_control* and nothing else.
To avoid testing it in every iteration you could have a hash_set *pset
temporary initialized based on c_dialect_cxx () to NULL or data and then just
use it in the loop.

>   if (TREE_CODE (t) != DEBUG_BEGIN_STMT
>   && (nondebug_stmts > 1 || TREE_SIDE_EFFECTS (tsi_stmt (i
> clear_side_effects = false;

[Bug c++/108893] attribute access read_only

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Jonny Grant from comment #0) 
> 
> void f(const char * const str) __attribute__((access(read_only, 1)));
> void f(const char * const str)
> {
> __builtin_puts(str);
> }
> 
> int main()
> {
> const char * a = nullptr;
> f(a);
> }
> 
> Tested on trunk in C++
> https://godbolt.org/z/rc8G6bePq

The goldbolt testcase does not match the above testcase. In fact using the
above testcase works and gives us the warning for both -fanalyzer and
-Wnonnull:
```
In function 'void f(const char*)',
inlined from 'int main()' at :10:6:
:4:19: warning: use of NULL where non-null expected [CWE-476]
[-Wanalyzer-null-argument]
4 | __builtin_puts(str);
  | ~~^
  'int main()': event 1
|
|   10 | f(a);
|  |  ^
|  |  |
|  |  (1) inlined call to 'f' from 'main'
|
+--> 'void f(const char*)': event 2
   |
   |4 | __builtin_puts(str);
   |  | ~~^
   |  |   |
   |  |   (2) argument 1 NULL where non-null
expected
   |
: In function 'int main()':
: note: argument 1 of 'int __builtin_puts(const char*)' must be
non-null
In function 'void f(const char*)',
inlined from 'int main()' at :10:6:
:4:19: warning: argument 1 null where non-null expected [-Wnonnull]
:4:19: note: in a call to built-in function 'int __builtin_puts(const
char*)'
```

[Bug c++/108893] attribute access read_only

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Yes this is a dup of bug 108871 which was specifically about that gcc-help
thread too.

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

[Bug ipa/108871] attribute nonnull does not spot nullptr O2 and above when function inlined

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

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

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

[Bug c++/108893] attribute access read_only

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

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

--- Comment #1 from Andrew Pinski  ---
Isn't this the same as PR 108871 ?


Also, the access attribute does not imply the attribute nonnull; it may be
appropriate to add both attributes at the declaration of a function that
unconditionally manipulates a buffer via a pointer argument. See the nonnull
attribute for more information and caveats.

[Bug c++/108893] New: attribute access read_only

[jg at jguk dot org via Gcc-bugs]

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

Bug ID: 108893
   Summary: attribute access read_only
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jg at jguk dot org
  Target Milestone: ---

could attribute access read_only give a build warning about this nullptr
dereference? This example compiles, and then gives SEGV when run.

Following on from gcc-help mailing list discussion I tried this out
https://gcc.gnu.org/pipermail/gcc-help/2023-February/142280.html


void f(const char * const str) __attribute__((access(read_only, 1)));
void f(const char * const str)
{
__builtin_puts(str);
}

int main()
{
const char * a = nullptr;
f(a);
}


https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html

Tested on trunk in C++
https://godbolt.org/z/rc8G6bePq

[Bug c/108880] [11/12/13 Regression] slow compilation with "-fsanitize=undefined"

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

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

--- Comment #12 from Marek Polacek  ---
Sure, it worked for the testcase because the STATEMENT_LIST only had two stmts.
 I'm testing:

--- a/gcc/c-family/c-gimplify.cc
+++ b/gcc/c-family/c-gimplify.cc
@@ -516,7 +516,8 @@ c_genericize_control_stmt (tree *stmt_p, int
*walk_subtrees, void *data,
  tree t = tsi_stmt (i);
  if (TREE_CODE (t) != DEBUG_BEGIN_STMT && nondebug_stmts < 2)
nondebug_stmts++;
- walk_tree_1 (tsi_stmt_ptr (i), func, data, NULL, lh);
+ walk_tree_1 (tsi_stmt_ptr (i), func, data,
+  static_cast *>(data), lh);
  if (TREE_CODE (t) != DEBUG_BEGIN_STMT
  && (nondebug_stmts > 1 || TREE_SIDE_EFFECTS (tsi_stmt (i
clear_side_effects = false;
@@ -572,8 +573,9 @@ c_genericize (tree fndecl)
   bc_state_t save_state;
   push_cfun (DECL_STRUCT_FUNCTION (fndecl));
   save_bc_state (_state);
-  walk_tree_without_duplicates (_SAVED_TREE (fndecl),
-   c_genericize_control_r, NULL);
+  hash_set pset;
+  walk_tree (_SAVED_TREE (fndecl), c_genericize_control_r, ,
+);
   restore_bc_state (_state);
   pop_cfun ();
 }

[Bug c/108880] [11/12/13 Regression] slow compilation with "-fsanitize=undefined"

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

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

--- Comment #11 from Jakub Jelinek  ---
(In reply to Marek Polacek from comment #10)
> Another simple patch is
> 
> --- a/gcc/c-family/c-gimplify.cc
> +++ b/gcc/c-family/c-gimplify.cc
> @@ -516,7 +516,7 @@ c_genericize_control_stmt (tree *stmt_p, int
> *walk_subtrees, void *data,
>   tree t = tsi_stmt (i);
>   if (TREE_CODE (t) != DEBUG_BEGIN_STMT && nondebug_stmts < 2)
> nondebug_stmts++;
> - walk_tree_1 (tsi_stmt_ptr (i), func, data, NULL, lh);
> + walk_tree_without_duplicates_1 (tsi_stmt_ptr (i), func, data, lh);
>   if (TREE_CODE (t) != DEBUG_BEGIN_STMT
>   && (nondebug_stmts > 1 || TREE_SIDE_EFFECTS (tsi_stmt (i
> clear_side_effects = false;

But that creates another pset, this time another one for each statement in each
STATEMENT_LIST seen.  That would be terribly expensive.
While the cp_genericize_r pset is just one for the whole function, the one used
by
walk_tree_without_duplicates for C is also one for the whole function.

[Bug rtl-optimization/108892] New: [13 Regression] ICE: in curr_insn_transform, at lra-constraints.cc:4168 (unable to generate reloads for: {*mvconst_internal}) at -Og on riscv64

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 108892
   Summary: [13 Regression] ICE: in curr_insn_transform, at
lra-constraints.cc:4168 (unable to generate reloads
for: {*mvconst_internal}) at -Og on riscv64
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: riscv64-unknown-linux-gnu

Created attachment 54507
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54507=edit
reduced testcase

Compiler output:
$ riscv64-unknown-linux-gnu-gcc -Og testcase.c
testcase.c: In function 'foo':
testcase.c:23:1: error: unable to generate reloads for:
   23 | }
  | ^
(insn 122 117 127 2 (set (reg:DI 157 [ _46 ])
(ior:DI (reg:DI 200)
(reg:DI 251))) "testcase.c":14:5 177 {*mvconst_internal}
 (expr_list:REG_EQUIV (const_int 25769803782 [0x60006])
(nil)))
during RTL pass: reload
testcase.c:23:1: internal compiler error: in curr_insn_transform, at
lra-constraints.cc:4168
0x79094f _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.cc:108
0x75103a curr_insn_transform
/repo/gcc-trunk/gcc/lra-constraints.cc:4168
0xeca15b lra_constraints(bool)
/repo/gcc-trunk/gcc/lra-constraints.cc:5215
0xeb18e4 lra(_IO_FILE*)
/repo/gcc-trunk/gcc/lra.cc:2375
0xe62d09 do_reload
/repo/gcc-trunk/gcc/ira.cc:5963
0xe62d09 execute
/repo/gcc-trunk/gcc/ira.cc:6149
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ riscv64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-riscv64/bin/riscv64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-6278-20230222135711-g3da77f217c8-checking-yes-rtl-df-extra-riscv64/bin/../libexec/gcc/riscv64-unknown-linux-gnu/13.0.1/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --with-isa-spec=2.2
--with-sysroot=/usr/riscv64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=riscv64-unknown-linux-gnu
--with-ld=/usr/bin/riscv64-unknown-linux-gnu-ld
--with-as=/usr/bin/riscv64-unknown-linux-gnu-as --disable-multilib
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-6278-20230222135711-g3da77f217c8-checking-yes-rtl-df-extra-riscv64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.1 20230222 (experimental) (GCC)

[Bug c/108880] [11/12/13 Regression] slow compilation with "-fsanitize=undefined"

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

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

--- Comment #10 from Marek Polacek  ---
Another simple patch is

--- a/gcc/c-family/c-gimplify.cc
+++ b/gcc/c-family/c-gimplify.cc
@@ -516,7 +516,7 @@ c_genericize_control_stmt (tree *stmt_p, int
*walk_subtrees, void *data,
  tree t = tsi_stmt (i);
  if (TREE_CODE (t) != DEBUG_BEGIN_STMT && nondebug_stmts < 2)
nondebug_stmts++;
- walk_tree_1 (tsi_stmt_ptr (i), func, data, NULL, lh);
+ walk_tree_without_duplicates_1 (tsi_stmt_ptr (i), func, data, lh);
  if (TREE_CODE (t) != DEBUG_BEGIN_STMT
  && (nondebug_stmts > 1 || TREE_SIDE_EFFECTS (tsi_stmt (i
clear_side_effects = false;

[Bug c/108880] [11/12/13 Regression] slow compilation with "-fsanitize=undefined"

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

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

--- Comment #9 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #4)
> It's not only "slow", it also produces a gigantic executable, the .original
> dump was 7.1GB when I stopped the compilation ...

Well, original dump for deeply nested SAVE_EXPRs is pretty unusable, even when
the actual trees are fairly small, because it prints each SAVE_EXPR in full.
If we wanted to avoid that, we'd need to use during the printing some hash
table on which SAVE_EXPRs we have printed already and print some id for them
and print just that id rather than full content next time we see it.  Or
perhaps trigger that behavior when we see deeper SAVE_EXPR nesting.

> The culprit is c_genericize calling c_genericize_control_r which must
> somehow do the ubsan instrumentation as well.

As Marek said, on the C++ FE side this is handled by cp-gimplify.cc using a
pset on its own and not trying to genericize a control stmt which has been
handled already (e.g. when seeing it again in another SAVE_EXPR), or even
SAVE_EXPRs that have been handled already.
So, adding another pset that would be used also for C++ would be a waste.
Now, the C FE in c-gimplify.cc has:
  walk_tree_without_duplicates (_SAVED_TREE (fndecl),
c_genericize_control_r, NULL);
so it effectively already creates a pset.
Thus, I think we should replace this walk_tree_without_duplicates with a new
pset + walk_tree, pass  twice - as pset and data and in
c_genericize_control_r don't walk again what we've already walked.
which

[Bug c/108880] [11/12/13 Regression] slow compilation with "-fsanitize=undefined"

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug fortran/108889] [12/13 Regression] (Re)Allocate in assignment shows used uninitialized memory warning with -Wall if LHS is unallocated

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Depends on||106089
   Keywords|diagnostic  |

--- Comment #2 from kargl at gcc dot gnu.org ---
Remove diagnostic keyword.  This has nothing to do with diagnostics.  It flat
out a bug.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106089
[Bug 106089] false positives with -Wuninitialized for allocation on assignment

[Bug fortran/108889] [12/13 Regression] (Re)Allocate in assignment shows used uninitialized memory warning with -Wall if LHS is unallocated

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
This is likely a duplicate of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106089

[Bug libgcc/108891] New: libatomic: AArch64 SEQ_CST 16-byte load missing barrier

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

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

Bug ID: 108891
   Summary: libatomic: AArch64 SEQ_CST 16-byte load missing
barrier
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wilco at gcc dot gnu.org
  Target Milestone: ---

LSE2 uses the following sequence for a 16-byte atomic load:

ldp res0, res1, [x0]
dmb ish

The AArch64 memory model allows the LDP to be reordered with an earlier STLXP
(eg. a SEQ_CST exchange), thus breaking SEQ_CST ordering.

To avoid this, atomic loads need a barrier before the LDP - either DBM ISHLD or
LDAR works.

[Bug analyzer/108830] Excess warnings from -Wanalyzer-null-dereference

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

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

--- Comment #3 from David Malcolm  ---
(In reply to David Malcolm from comment #0)

> There are also a huge number of spammy "'new_vals' is NULL" messages.

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105958#c1

[Bug analyzer/105958] Stray events emitted by state machine tests (e.g. "'VAR' is NULL")

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

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

--- Comment #1 from David Malcolm  ---
A particularly bad example seems to be gcc.dg/analyzer/null-deref-pr108830.c:
  https://godbolt.org/z/rabfxeaxz
which currently emits:
: In function 'apr_hash_merge':
:82:24: warning: dereference of NULL 'new_vals' [CWE-476]
[-Wanalyzer-null-dereference]
   82 |   new_vals[j].klen = iter->klen;   /* { dg-warning "dereference of
NULL 'new_vals'" } */
  |   ~^~~~
  'apr_hash_merge': event 1
|
|   57 |   apr_hash_entry_t* new_vals = NULL;
|  | ^~~~
|  | |
|  | (1) 'new_vals' is NULL
|
  'apr_hash_merge': event 2
|
|   62 |   res->free = NULL;
|  | ^
|  | |
|  | (2) 'new_vals' is NULL
|
  'apr_hash_merge': event 3
|
|   62 |   res->free = NULL;
|  | ^
|  | |
|  | (3) 'new_vals' is NULL
|
  'apr_hash_merge': events 4-17
|
|   62 |   res->free = NULL;
|  | ^
|  | |
|  | (4) 'new_vals' is NULL
|..
|   71 |   if (base->count + overlay->count) {
|  |  ~   
|  |  |
|  |  (5) following 'false' branch...
|..
|   75 |   j = 0;
|  |   ~  
|  | |
|  | (6) ...to here
|   76 |   for (k = 0; k <= base->max; k++) {
|  |   ~~
|  | |
|  | (7) following 'true' branch...
|   77 | for (iter = base->array[k]; iter; iter = iter->next) {
|  | ~~~ 
|  | |   |
|  | |   (9) following 'true' branch (when
'iter' is non-NULL)...
|  | (8) ...to here
|   78 |   i = iter->hash & res->max;
|  |   ~~
|  |   |
|  |   (10) ...to here
|..
|   82 |   new_vals[j].klen = iter->klen;   /* { dg-warning
"dereference of NULL 'new_vals'" } */
|  |   ~
|  |   ||
|  |   |(17) dereference of NULL 'new_vals + (long
unsigned int)j * 40'
|  |   (11) 'new_vals' is NULL
|   83 |   /* ...but not for subsequent ones: */
|   84 |   new_vals[j].key = iter->key;  /* { dg-bogus "dereference
of NULL 'new_vals'" "PR analyzer/108830" } */
|  |   ~
|  |   |
|  |   (12) 'new_vals' is NULL
|   85 |   new_vals[j].val = iter->val;  /* { dg-bogus "dereference
of NULL 'new_vals'" "PR analyzer/108830" } */
|  |   ~
|  |   |
|  |   (13) 'new_vals' is NULL
|   86 |   new_vals[j].hash = iter->hash;/* { dg-bogus "dereference
of NULL 'new_vals'" "PR analyzer/108830" } */
|  |   ~
|  |   |
|  |   (14) 'new_vals' is NULL
|   87 |   new_vals[j].next = res->array[i]; /* { dg-bogus "dereference
of NULL 'new_vals'" "PR analyzer/108830" } */
|  |   ~
|  |   |
|  |   (15) 'new_vals' is NULL
|   88 |   res->array[i] = _vals[j]; /* { dg-bogus "dereference
of NULL 'new_vals'" "PR analyzer/108830" } */
|  |   
|  |   |
|  |   (16) 'new_vals' is NULL
|

...where events 2-4 and 12-16 seem to be noise.

[Bug c/108880] [11/12/13 Regression] slow compilation with "-fsanitize=undefined"

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

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

--- Comment #8 from Marek Polacek  ---
We generate HUGE trees for the div sanitization, but I notice that
c_genericize_control_r doesn't use pset, like cp_genericize_r does.  So I think
the fix would be to add a hash_set to c_genericize_control_r.

Indeed, if I remove p_set->add (*stmt_p); in cp_genericize_r, the compilation
with cc1plus also takes around 10s.

[Bug middle-end/108878] Mis-optimization with splitting floating point into a significand and exponent.

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #8 from Steve Kargl  ---
On Wed, Feb 22, 2023 at 08:48:07AM +, rguenth at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108878
> 
> --- Comment #6 from Richard Biener  ---
> For the specific testcase I also wonder if the Fortran frontend optimization
> pass can somehow unify these?

This might be possible.  Thomas knows the frontend pass better
than I.  Thomas, do you think it would be possible to replace

m = exponent(x)
f = fraction(x)

with a single function/subroutine call?

[Bug analyzer/108879] -Wanalyzer-malloc-leak false positive stl string in try catch block

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

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

David Malcolm  changed:

   What|Removed |Added

 Blocks||97110

--- Comment #1 from David Malcolm  ---
Yeah, I haven't implemented exceptions yet, so even the simplest cases are
likely to fail :-/

I plan to spent a chunk of my GCC *14* cycles working on C++ support (in the
hope of "eating my own dogfood" for GCC 14), but in the meantime, I'm afraid
it's not going to be helpful to file any more bugs about -fanalyzer on C++.

I've added a caveat about that to the GCC 13 release notes:
https://gcc.gnu.org/git/?p=gcc-wwwdocs.git;a=commitdiff;h=98c77c7cd4fc3f1bb1e77e260640cbbe5fd45b46

and to the manpage/docs:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=a90316c6ceddfbb47b3c2161baf446ccb87df5ff


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97110
[Bug 97110] [meta-bug] tracker bug for supporting C++ in -fanalyzer

[Bug translation/108890] New: Translation mistakes 2023

[roland.illig at gmx dot de via Gcc-bugs]

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

Bug ID: 108890
   Summary: Translation mistakes 2023
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

> %qs is loaded but symbol %qs is not found: %s

That string is marked as 'format-c' but should be 'format-gcc-internal'.

> to generate dependencies you must specify '-fcpp'

Trailing whitespace, wrong quotes.

> -frust-crate= Set the crate name for the compilation
> -frust-dump-\tDump Rust frontend internal information.

The upper is indented using spaces, the lower using a single tab.
That's inconsistent.

> -frust-max-recursion-depth=integer

Placeholders should be enclosed in <>.

> -frust-mangling=[legacy|v0] Choose which version to use for name mangling

The word 'Choose' is redundant and should be removed.
This word occurs in other messages as well.

> Flag to enable embeding metadata directly into object files

The word 'Flag' is redundant.
Typo in 'embeding'.

> -frust-compile-until=[ast|attributecheck|expansion|nameresolution|lowering|typecheck|privacy|unsafety|const|copimlation|end]
>  When to stop in the pipeline when compiling Rust code

The word 'until' sounds inclusive, the phrase 'When to stop' sounds exclusive.
Typo in 'copimlation'.

> inproper usages

Typo in 'inproper'.

> Enable certain features present drafts of C++ Contracts.

Grammar?

[Bug fortran/108889] New: [12/13 Regression] (Re)Allocate in assignment shows used uninitialized memory warning with -Wall if LHS is unallocated

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

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

Bug ID: 108889
   Summary: [12/13 Regression] (Re)Allocate in assignment shows
used uninitialized memory warning with -Wall if LHS is
unallocated
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: diagnostic, wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

The following testcase shows the following -Wall warnings:

Warning: ‘reference.offset’ is used uninitialized [-Wuninitialized]
Warning: ‘reference.dim[0].lbound’ is used uninitialized [-Wuninitialized]
Warning: ‘reference.dim[0].ubound’ may be used uninitialized
[-Wmaybe-uninitialized]

The warning (but not the issue) is new since GCC 12. The dump shows:

D.4310 = reference.offset;
D.4311 = reference.dim[0].lbound;
D.4312 = reference.dim[0].ubound;

D.4313 = D.4311 - D.4307;  // D.4307 = single.var.dim[0].lbound

But all expressions are actually re-evaluated later:
D.4317 = (real(kind=4)[0:] * restrict) reference.data == 0B;
if (D.4317) goto L.4;
...
L.4:;
...
reference.dim[0].lbound = single.var.dim...
reference.offset = -NON_LVALUE_EXPR ;
D.4310 = reference.offset;
D.4313 = reference.dim[0].lbound - D.4307;
...
L.5:;  /// If the shape was correct, there is a jump to here / L.5
  while (1)
{
  if (S.2 > D.4308) goto L.6;
  (*D.4309)[(S.2 + D.4313) + D.4310] = (*D.4305)[S.2 + D.4306];

Thus, D.4313 + D.4310 needs to be evaluated in the no-(re)alloc case and in the
needs-to-be allocated case.


Thus, the produced code is fine at the end – even though there was
uninitialized memory in between. — But this should be fixed, also to silence
the warning.

* * * 

! Testcase: Compile with -Wall

program main
  implicit none

  type :: struct
real, allocatable :: var(:)
  end type struct

  type(struct) :: single
  real, allocatable :: reference(:)

  single%var = [1,2,3,4,5]
  reference = single%var

  if (size(reference) /= size(single%var)) stop 1
  if (lbound(reference, 1) /= 1) stop 3
  if (any (reference /= single%var)) stop 3
end

[Bug fortran/96024] [10/11/12/13 Regression] ICE in mio_name_expr_t, at fortran/module.c:2159

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

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

--- Comment #12 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:31303c9b5bab200754cdb7ef8cd91ae4918f3018

commit r13-6289-g31303c9b5bab200754cdb7ef8cd91ae4918f3018
Author: Harald Anlauf 
Date:   Tue Feb 21 22:06:33 2023 +0100

Fortran: reject invalid CHARACTER length of derived type components
[PR96024]

gcc/fortran/ChangeLog:

PR fortran/96024
* resolve.cc (resolve_component): The type of a CHARACTER length
expression must be INTEGER.

gcc/testsuite/ChangeLog:

PR fortran/96024
* gfortran.dg/pr96024.f90: New test.

[Bug tree-optimization/105329] [12/13 Regression] Bogus restrict warning when assigning 1-char string literal to std::string since r12-3347-g8af8abfbbace49e6

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

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

--- Comment #29 from Jonathan Wakely  ---
It adds a new symbol to the library, which is not usually considered an ABI
change, because it's backwards compatible. Compiling with a new GCC and linking
to an old libstdc++ is never supported anyway.

[Bug tree-optimization/105329] [12/13 Regression] Bogus restrict warning when assigning 1-char string literal to std::string since r12-3347-g8af8abfbbace49e6

[49tbwddbqeazdawz at chyen dot cc via Gcc-bugs]

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

--- Comment #28 from yan12125 <49tbwddbqeazdawz at chyen dot cc> ---
Thanks, so that commit changes ABI - objects built by patched GCC will not link
to unpatched libstdc++. I will stick to -Wno-restrict for now.

[Bug c++/108219] [12/13 Regression] requirement fails on a valid expression since r12-5253-g4df7f8c79835d569

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

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug c/69960] "initializer element is not constant"

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #22 from joseph at codesourcery dot com  ---
I do however expect there may be cases in GCC 13 where constexpr 
initializers of floating type are accepted that do not meet the definition 
of arithmetic constant expressions, since GCC is generally a lot more 
careful about ensuring things are integer constant expressions when 
required than it is about doing the same for arithmetic constant 
expressions (before C2x there weren't any cases that allowed arithmetic 
constant expressions without also allowing other kinds of constant 
expressions permitted in initializers).

[Bug c/69960] "initializer element is not constant"

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #21 from joseph at codesourcery dot com  ---
On Wed, 22 Feb 2023, daniel.lundin.mail at gmail dot com via Gcc-bugs wrote:

> First of all, it is questionable if gcc is still conforming after the change
> discussed here and implemented as per gcc 8.0. Yes "an implementation may
> accept other forms of constant expressions" but that doesn't mean that a
> compiler is allowed to ignore the constraints in C17 6.7.9/4 nor the 
> definition
> of an integer constant expression. So this ought to explicitly be a compiler
> extension and we ought to have a way to reliably compile strictly conforming
> programs with gcc without constraint violations silently getting ignored. 

"integer constant expression" does not mean the same thing as "constant 
expression of integer type".  If you use this expression in a context 
requiring an integer constant expression (case label, bit-field width, 
array designator in initializer, enum value, array size at file scope, 
constexpr initializer for object of integer type, etc.), it's properly 
rejected as required; in contexts where both integer constant expressions 
and other expressions are valid but with different semantics (e.g. 
determining whether something is a null pointer constant, determining 
whether an array is a VLA in a context where both VLA and non-VLA arrays 
are valid), again it's treated as non-constant.

[Bug tree-optimization/108888] [13 Regression] error: definition in block 26 follows the use

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-02-22
 Ever confirmed|0   |1

[Bug c++/108888] [13 Regression] error: definition in block 26 follows the use

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

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
Summary|error: definition in block  |[13 Regression] error:
   |26 follows the use  |definition in block 26
   ||follows the use
   Target Milestone|--- |13.0
 CC||ams at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
   Priority|P3  |P1

--- Comment #1 from Marek Polacek  ---
Started with r13-6278-g3da77f217c8b20.

[Bug c++/108888] New: error: definition in block 26 follows the use

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 10
   Summary: error: definition in block 26 follows the use
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this C++ code:

int scaleValueSaturate_scalefactor, scaleValueSaturate___trans_tmp_2,
scaleValuesSaturate_i;
int scaleValueSaturate(int value) {
  int result = __builtin_clz(value);
  if (value)
if (-result <= scaleValueSaturate_scalefactor)
  return 0;
  return scaleValueSaturate___trans_tmp_2;
}
short scaleValuesSaturate_dst;
short *scaleValuesSaturate_src;
void scaleValuesSaturate() {
  for (; scaleValuesSaturate_i; scaleValuesSaturate_i++)
scaleValuesSaturate_dst =
scaleValueSaturate(scaleValuesSaturate_src[scaleValuesSaturate_i]);
}

compiled with recent gcc trunk, does this:

[dcb36@fedora36 cvise]$ ~/gcc/results/bin/g++ -c -O1 bug887B.cc
[dcb36@fedora36 cvise]$ ~/gcc/results/bin/g++ -c -O2 bug887B.cc
bug887B.cc: In function ‘void scaleValuesSaturate()’:
bug887B.cc:12:6: error: definition in block 4 follows the use
   12 | void scaleValuesSaturate() {
  |  ^~~
for SSA_NAME: _25 in statement:
result_14 = .MASK_CALL (__builtin_clz, value.0_11, _25);
during GIMPLE pass: ifcvt
bug887B.cc:12:6: internal compiler error: verify_ssa failed
0x1316f05 verify_ssa(bool, bool)
../../trunk.d1/gcc/tree-ssa.cc:1211

The bug first seems to appear sometime between git hash g:a804419c89db9e1c
from yesterday and g:aee5ee35602e0098, from today.

[Bug c/108880] [11/12/13 Regression] slow compilation with "-fsanitize=undefined"

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

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

--- Comment #7 from Marek Polacek  ---
The C90/C99 difference is due to ubsan_instrument_shift:

193   /* For signed x << y, in C99 and later, the following:
194  (unsigned) x >> (uprecm1 - y)
195  if non-zero, is undefined.  */
196   else if (code == LSHIFT_EXPR && flag_isoc99 && cxx_dialect < cxx11)
197 {
198   tree x = fold_build2 (MINUS_EXPR, op1_utype, uprecm1,
199 fold_convert (op1_utype, unshare_expr (op1)));

[Bug ada/108858] Assert_Failure at exp_ch6.adb:6499

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

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-02-22

--- Comment #1 from Eric Botcazou  ---
I can reproduce.

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

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

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

Bug 102633 Summary: [11 Regression] warning for self-initialization despite 
-Wno-init-self
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102633

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

[Bug middle-end/102633] [11 Regression] warning for self-initialization despite -Wno-init-self

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #13 from Marek Polacek  ---
.

[Bug libstdc++/108886] Add basic_string throw logic_error when assigned a nullptr

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

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

--- Comment #1 from Jonathan Wakely  ---
Why are you suggesting adding a check in two places when the first one just
calls the second one?

What would be the point of _GLIBCXX_DEBUG_PEDASSERT when there's already a
debug assertion there? Compiling with _GLIBCXX_DEBUG will already abort.

I don't see the point of adding anything to char_traits at all. It's a very
low-level interface and you probably shouldn't be (and aren't) using it
directly anyway.

[Bug c/108880] [11/12/13 Regression] slow compilation with "-fsanitize=undefined"

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

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

--- Comment #6 from Marek Polacek  ---
FWIW, -fsanitize=signed-integer-overflow,shift seems to be enough to trigger
the runaway compilation.

[Bug c/108880] [11/12/13 Regression] slow compilation with "-fsanitize=undefined"

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #5 from Marek Polacek  ---
Started with r11-3299:

commit cba079f354a55363916759f6f186f92c5616b98a
Author: Sandra Loosemore 
Date:   Sat Sep 19 07:32:35 2020 -0700

Move loop and switch tree data structures from cp/ to c-family/.

This patch moves the definitions for DO_STMT, FOR_STMT, WHILE_STMT,
SWITCH_STMT, BREAK_STMT, and CONTINUE_STMT from the C++ front end to
c-family.  This includes the genericizers, pretty-printers, and dump
support as well as the tree definitions and accessors.  Some related
code for OMP_FOR and similar OMP constructs is also moved.

[Bug middle-end/108854] [10/11/12/13 Regression] tbb-2021.8.0 fails on i686-linux (32-bit), internal compiler error: in expand_expr_real_1, at expr.c:10281

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords|needs-reduction |
   Priority|P3  |P2
   Target Milestone|--- |10.5
 CC||hubicka at gcc dot gnu.org,
   ||jamborm at gcc dot gnu.org
Summary|tbb-2021.8.0 fails on   |[10/11/12/13 Regression]
   |i686-linux (32-bit),|tbb-2021.8.0 fails on
   |internal compiler error: in |i686-linux (32-bit),
   |expand_expr_real_1, at  |internal compiler error: in
   |expr.c:10281|expand_expr_real_1, at
   ||expr.c:10281

--- Comment #10 from Jakub Jelinek  ---
Reduced testcase for -m32 -O3 -std=c++11 -fPIC:

struct unique_scoped_lock {
  unique_scoped_lock(int);
  ~unique_scoped_lock();
};
struct rw_scoped_lock {
  rw_scoped_lock(int, bool);
  ~rw_scoped_lock();
};
template  struct Trans_NS___cxx11_list {
  typedef _Tp value_type;
  void push_front(value_type);
  void push_back(value_type &&);
};
class receiver typedef node_priority_t;
struct graph_node {
  virtual void reset_node();
};
template  struct sender {
  typedef receiver successor_type;
  virtual bool register_successor(successor_type &);
};
struct receiver {
  virtual node_priority_t priority() { return receiver(); }
};
void fgt_make_edge(void *, void *);
struct successor_cache {
  int my_mutex;
  Trans_NS___cxx11_list my_successors;
  void register_successor(receiver ) {
rw_scoped_lock l(my_mutex, true);
r.priority();
my_successors.push_front();
my_successors.push_back();
  }
};
struct input_node : graph_node, sender {
  template  input_node(int, Body);
  bool register_successor(successor_type ) {
unique_scoped_lock lock(my_mutex);
my_successors.register_successor(r);
if (my_active)
  return true;
  }
  int my_mutex;
  bool my_active;
  successor_cache my_successors;
};
inline void make_edge(sender ) {
  receiver s, __trans_tmp_2;
  p.register_successor(__trans_tmp_2);
  fgt_make_edge(, );
}
enum TestNodeTypeEnum { nonThrowing, isThrowing };
template  struct absorber_body;
template 
void run_one_priority_queue_node_test() {
  int g, input_count;
  InputNodeType input(g, input_count);
  make_edge(input);
}
template 
void run_priority_queue_node_test() {
  run_one_priority_queue_node_test>();
}
void test_priority_queue_node() {
  run_priority_queue_node_test();
  run_priority_queue_node_test();
}

This started to ICE (segfault in same_node_or_its_all_contexts_clone_p) with
r10-4511-g6cf67b62c8cda035dccac and starting with
r10-5061-g68188fff88d0c302e6002 it gets the
ICE that shows up to latest trunk.

[Bug c++/108887] [13 Regression] ICE in process_function_and_variable_attributes since r13-3601

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

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

--- Comment #1 from Jakub Jelinek  ---
The ICE is actually in cgraph code, so it might as well be just some latent
cgraph bug triggered by the C++ changes.
What I see is that first_analyzed is set to a cgraph node for
_ZZN27LinkPaginationTimelineModel12fillTimelineEvENKUlP15AbstractAccountE0_clES1_
But that node is then removed in:
#0  0x77a4ec8f in __memset_evex_unaligned_erms () from /lib64/libc.so.6
#1  0x0094ec0b in ggc_free (p=0x7fffe9e93bb0) at
../../gcc/ggc-page.cc:1630
#2  0x00a24fb6 in symbol_table::release_symbol (this=0x7fffea13,
node=)
at ../../gcc/cgraph.h:2853
#3  0x00a1d498 in cgraph_node::remove (this=) at
../../gcc/cgraph.cc:1974
#4  0x00a08369 in symtab_node::remove (this=) at ../../gcc/symtab.cc:481
#5  0x005866e4 in record_mangling (decl=, need_warning=true) at ../../gcc/cp/decl2.cc:4751
#6  0x005f5d5d in mangle_decl (decl=) at ../../gcc/cp/mangle.cc:4196
#7  0x01456c70 in decl_assembler_name (decl=) at ../../gcc/tree.cc:743
#8  0x01457234 in assign_assembler_name_if_needed (t=) at ../../gcc/tree.cc:858
#9  0x00a2cf4d in cgraph_node::analyze (this=) at ../../gcc/cgraphunit.cc:669
#10 0x00a2effe in analyze_functions (first_time=true) at
../../gcc/cgraphunit.cc:1238
but nothing updates first_analyzed.

record_mangling has:
  /* If this is already an alias, remove the alias, because the real
 decl takes precedence.  */
  if (*slot && DECL_ARTIFICIAL (*slot) && DECL_IGNORED_P (*slot))
if (symtab_node *n = symtab_node::get (*slot))
  if (n->cpp_implicit_alias)
{
  n->remove ();
  *slot = NULL_TREE;
}

So, to some extent this is related to PR107897.
The ICE is obviously gone with -fabi-compat-version=0 and so if we wouldn't
emit compatibility aliases for lambdas based on PR107897, this issue would be
latent again.

[Bug c++/108887] [13 Regression] ICE in process_function_and_variable_attributes since r13-3601

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

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2023-02-22
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Target Milestone|--- |13.0
   Priority|P3  |P1
   Keywords||ice-on-valid-code
 CC||mpolacek at gcc dot gnu.org

[Bug c++/108887] New: [13 Regression] ICE in process_function_and_variable_attributes since r13-3601

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

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

Bug ID: 108887
   Summary: [13 Regression] ICE in
process_function_and_variable_attributes since
r13-3601
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Since r13-3601-g2b0e81d5cc2f7e1d773f6c502bd65b097f392675 we ICE:
./cc1plus -quiet -O2 rh2171964.ii
cc1plus: internal compiler error: Segmentation fault
0x10bf746 crash_signal
../../gcc/toplev.cc:314
0xa2d845 process_function_and_variable_attributes
../../gcc/cgraphunit.cc:861
0xa2ed43 analyze_functions
../../gcc/cgraphunit.cc:1181
0xa32419 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.cc:2545
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.

Testcase:
template  struct integral_constant {
  static constexpr int value = __v;
};
using false_type = integral_constant;
template  struct __result_of_impl;
template 
struct __result_of_impl {
  typedef decltype(0) type;
};
template 
struct __invoke_result
: __result_of_impl {};
template 
void __invoke_impl(_Fn __f, _Args... __args) {
  __f(__args...);
}
template 
void __invoke_r(_Callable __fn, _Args... __args) {
  using __result = __invoke_result<_Args...>;
  using __type = typename __result::type;
  __invoke_impl<__type>(__fn, __args...);
}
struct QString {
  QString(const char *);
};
template  class function;
template  struct _Base_manager {
  static _Functor _M_get_pointer(int) { __builtin_abort (); }
};
template  class _Function_handler;
template 
struct _Function_handler<_Res(_ArgTypes...), _Functor> {
  using _Base = _Base_manager<_Functor>;
  static _Res _M_invoke(const int &__functor, _ArgTypes &&...__args) {
auto __trans_tmp_1 = _Base::_M_get_pointer(__functor);
__invoke_r<_Res>(__trans_tmp_1, __args...);
  }
};
template 
struct function<_Res(_ArgTypes...)> {
  template 
  using _Handler = _Function_handler<_Res(_ArgTypes...), _Functor>;
  template  function(_Functor) {
using _My_handler = _Handler<_Functor>;
_M_invoker = _My_handler::_M_invoke;
  }
  using _Invoker_type = _Res (*)(const int &, _ArgTypes &&...);
  _Invoker_type _M_invoker;
};
struct QRegularExpression {
  QRegularExpression(QString);
};
struct AbstractAccount {
  void get(function,
   function);
};
struct AbstractTimelineModel {
  AbstractAccount m_account;
};
struct LinkPaginationTimelineModel : AbstractTimelineModel {
  void fillTimeline();
};
void LinkPaginationTimelineModel::fillTimeline() {
  [] {};
  m_account.get([](AbstractAccount *) { static QRegularExpression re(""); },
[](AbstractAccount *) {});
}

[Bug c++/108884] [temp.friends]/9: Should constraint friends declared in class scope differ with definition out of scope?

[zyn7109 at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Younan Zhang  ---
Sorry for duplicate comments. Network issue :(
And thanks Patrik's explaination.

[Bug c++/108884] [temp.friends]/9: Should constraint friends declared in class scope differ with definition out of scope?

[zyn7109 at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Younan Zhang  ---
(In reply to Patrick Palka from comment #4)
> (In reply to Younan Zhang from comment #2)
> > (In reply to Patrick Palka from comment #1)
> > > #1 is neither a non-template friend declaration with a requires-clause 
> > > nor a
> > > friend function template with a constraint that depends on a template
> > > parameter from an enclosing template, so it seems to me [temp.friend]/9
> > > doesn't apply here?
> > 
> > I'm a bit confused. Doesn't `friend auto factory(const C auto&...)` equal to
> > template where `Us` depends on parameter from outter C?
> > ```cpp
> > template 
> > friend auto factory(const C Us&...);`
> > ```
> 
> And IIUC if we desugar the type-constraint C... we get
> 
> ```cpp
> template  requires (C && ...)
> friend auto factory(const Us&...);
> ```
> 
> so the friend doesn't have a constraint that depends on an outer template
> parameter (Ts)

Oh I see. I thought C was the template parameter, which should be a concept.

[Bug c++/108884] [temp.friends]/9: Should constraint friends declared in class scope differ with definition out of scope?

[zyn7109 at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Younan Zhang  ---
(In reply to Patrick Palka from comment #4)
> (In reply to Younan Zhang from comment #2)
> > (In reply to Patrick Palka from comment #1)
> > > #1 is neither a non-template friend declaration with a requires-clause 
> > > nor a
> > > friend function template with a constraint that depends on a template
> > > parameter from an enclosing template, so it seems to me [temp.friend]/9
> > > doesn't apply here?
> > 
> > I'm a bit confused. Doesn't `friend auto factory(const C auto&...)` equal to
> > template where `Us` depends on parameter from outter C?
> > ```cpp
> > template 
> > friend auto factory(const C Us&...);`
> > ```
> 
> And IIUC if we desugar the type-constraint C... we get
> 
> ```cpp
> template  requires (C && ...)
> friend auto factory(const Us&...);
> ```
> 
> so the friend doesn't have a constraint that depends on an outer template
> parameter (Ts)

Oh I see. I thought C was the template parameter, which should be a concept.

[Bug c++/108884] [temp.friends]/9: Should constraint friends declared in class scope differ with definition out of scope?

[zyn7109 at gmail dot com via Gcc-bugs]

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

Younan Zhang  changed:

   What|Removed |Added

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

--- Comment #5 from Younan Zhang  ---
(In reply to Patrick Palka from comment #4)
> (In reply to Younan Zhang from comment #2)
> > (In reply to Patrick Palka from comment #1)
> > > #1 is neither a non-template friend declaration with a requires-clause 
> > > nor a
> > > friend function template with a constraint that depends on a template
> > > parameter from an enclosing template, so it seems to me [temp.friend]/9
> > > doesn't apply here?
> > 
> > I'm a bit confused. Doesn't `friend auto factory(const C auto&...)` equal to
> > template where `Us` depends on parameter from outter C?
> > ```cpp
> > template 
> > friend auto factory(const C Us&...);`
> > ```
> 
> And IIUC if we desugar the type-constraint C... we get
> 
> ```cpp
> template  requires (C && ...)
> friend auto factory(const Us&...);
> ```
> 
> so the friend doesn't have a constraint that depends on an outer template
> parameter (Ts)

Oh I see. I thought C was the template parameter, which should be a concept.

[Bug libstdc++/108886] New: Add basic_string throw logic_error when assigned a nullptr

[jg at jguk dot org via Gcc-bugs]

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

Bug ID: 108886
   Summary: Add basic_string throw logic_error when assigned a
nullptr
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jg at jguk dot org
  Target Milestone: ---

Checked this on godbolt trunk today.
https://godbolt.org/z/6xxEc85c9

basic_string.h will throw a logic_error at runtime if a nullptr gets through to
the basic_string() constructor. But assignment doesn't throw a logic_error, it
gives SEGV.

Could I suggest two improvements please:

1) Add throw logic_error to basic_string.h:815 if pointer is nullptr.
  _GLIBCXX20_CONSTEXPR
  basic_string&
  operator=(const _CharT* __s)
  { return this->assign(__s); }

2) Add throw logic_error to basic_string:1647

_GLIBCXX20_CONSTEXPR
  basic_string&
  assign(const _CharT* __s)
  {
__glibcxx_requires_string(__s);
return _M_replace(size_type(0), this->size(), __s,
  traits_type::length(__s));
  }


This is what basic_string.h has for normal construction
std::__throw_logic_error(__N("basic_string: "
   "construction from null is not valid"));



The basic_string assignment = uses char_traits to check the length using
__builtin_strlen and then SEGV.

I believe it is the actual __builtin_strlen that does the nullptr dereference.

GDB output
Core was generated by `./str2'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  __strlen_sse2 () at ../sysdeps/x86_64/multiarch/strlen-sse2.S:142
142 ../sysdeps/x86_64/multiarch/strlen-sse2.S: No such file or directory.
(gdb) bt
#0  __strlen_sse2 () at ../sysdeps/x86_64/multiarch/strlen-sse2.S:142
#1  0x55ca94a8327e in std::char_traits::length (__s=0x0) at
/usr/include/c++/12/bits/char_traits.h:395
#2  std::__cxx11::basic_string,
std::allocator >::assign (__s=0x0, this=0x7fff26f1e370) at
/usr/include/c++/12/bits/basic_string.h:1647
#3  std::__cxx11::basic_string,
std::allocator >::operator= (__s=0x0, this=0x7fff26f1e370) at
/usr/include/c++/12/bits/basic_string.h:815
#4  make_string (str=str@entry=0x0, out_string="") at str2.cpp:8
#5  0x55ca94a832d9 in main () at str2.cpp:15






Therefore I propose

1) Add throw logic_error to basic_string.h:815 if pointer is nullptr.
  _GLIBCXX20_CONSTEXPR
  basic_string&
  operator=(const _CharT* __s)
  { return this->assign(__s); }

2) Add throw logic_error to basic_string:1647

_GLIBCXX20_CONSTEXPR
  basic_string&
  assign(const _CharT* __s)
  {
__glibcxx_requires_string(__s);
return _M_replace(size_type(0), this->size(), __s,
  traits_type::length(__s));
  }

3) I don't think char_traits allows exceptions, so I can't suggest a
logic_error
Is there anything else that could be added here? Maybe just a
_GLIBCXX_DEBUG_PEDASSERT ? strlen() doesn't have a way to even set errno and
return -1


This is what char_traits.h has


/usr/include/c++/12/bits/char_traits.h:395:25: runtime error: null pointer
passed as argument 1, which is declared to never be null
AddressSanitizer:DEADLYSIGNAL

/usr/include/c++/12/bits/char_traits.h

  static _GLIBCXX17_CONSTEXPR size_t
  length(const char_type* __s)
  {
#if __cplusplus >= 201703L
if (std::__is_constant_evaluated())
  return __gnu_cxx::char_traits::length(__s);
#endif
return __builtin_strlen(__s);
  }






Example:

#include 
#include 

void make_string(const char * const str, std::string & out_string)
{
out_string = str;
}

int main()
{
const char * a = NULL;
std::string str;
make_string(a, str);
printf("%s\n", str.c_str());
}

[Bug c++/108884] [temp.friends]/9: Should constraint friends declared in class scope differ with definition out of scope?

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

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

--- Comment #4 from Patrick Palka  ---
(In reply to Younan Zhang from comment #2)
> (In reply to Patrick Palka from comment #1)
> > #1 is neither a non-template friend declaration with a requires-clause nor a
> > friend function template with a constraint that depends on a template
> > parameter from an enclosing template, so it seems to me [temp.friend]/9
> > doesn't apply here?
> 
> I'm a bit confused. Doesn't `friend auto factory(const C auto&...)` equal to
> template where `Us` depends on parameter from outter C?
> ```cpp
> template 
> friend auto factory(const C Us&...);`
> ```

And IIUC if we desugar the type-constraint C... we get

```cpp
template  requires (C && ...)
friend auto factory(const Us&...);
```

so the friend doesn't have a constraint that depends on an outer template
parameter (Ts)

[Bug c++/108884] [temp.friends]/9: Should constraint friends declared in class scope differ with definition out of scope?

[zyn7109 at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Younan Zhang  ---
(In reply to Younan Zhang from comment #2)
> (In reply to Patrick Palka from comment #1)
> > #1 is neither a non-template friend declaration with a requires-clause nor a
> > friend function template with a constraint that depends on a template
> > parameter from an enclosing template, so it seems to me [temp.friend]/9
> > doesn't apply here?
> 
> I'm a bit confused. Doesn't `friend auto factory(const C auto&...)` equal to
> template where `Us` depends on parameter from outter C?
> ```cpp
> template 
> friend auto factory(const C Us&...);`
> ```

typo: friend auto factory(const Us&...);

[Bug c++/108884] [temp.friends]/9: Should constraint friends declared in class scope differ with definition out of scope?

[zyn7109 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Younan Zhang  ---
(In reply to Patrick Palka from comment #1)
> #1 is neither a non-template friend declaration with a requires-clause nor a
> friend function template with a constraint that depends on a template
> parameter from an enclosing template, so it seems to me [temp.friend]/9
> doesn't apply here?

I'm a bit confused. Doesn't `friend auto factory(const C auto&...)` equal to
template where `Us` depends on parameter from outter C?
```cpp
template 
friend auto factory(const C Us&...);`
```

[Bug c++/108884] [temp.friends]/9: Should constraint friends declared in class scope differ with definition out of scope?

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #1 from Patrick Palka  ---
#1 is neither a non-template friend declaration with a requires-clause nor a
friend function template with a constraint that depends on a template parameter
from an enclosing template, so it seems to me [temp.friend]/9 doesn't apply
here?

[Bug sanitizer/108885] Missing sanitization checks for optimized integer

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
The signed integer overflow is in dead code and so is dead code eliminated.
It would be reported with -O0 -fsanitize=undefined

[Bug sanitizer/108885] New: Missing sanitization checks for optimized integer

[cbossut21 at gatech dot edu via Gcc-bugs]

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

Bug ID: 108885
   Summary: Missing sanitization checks for optimized integer
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cbossut21 at gatech dot edu
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

I noticed the following behavior for the following code in test.c:

=
#include "stdio.h"
int a = 6;
int main() { 
  int c = a * 936722028; 
  printf("%d\n", a);
}
=

$ gcc-trunk -fsanitize=signed-integer-overflow -O3 -msse4.2  test.c -o test

$ ./test
6

$ gcc-trunk -v
gcc version 13.0.1 20230218 (experimental) [master r13-6132-g32b5875c911] (GCC) 

There are no sanitization checks inserted in this case, despite overflow
occurring on the first line of main. It seems like the check is optimized out.
However, the same code produces a signed integer overflow error at runtime when
compiled with clang using the same flags. 

Is this expected behavior for GCC? Thanks!

[Bug middle-end/108854] tbb-2021.8.0 fails on i686-linux (32-bit), internal compiler error: in expand_expr_real_1, at expr.c:10281

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #9 from Jakub Jelinek  ---
Reproduced with 11/12, reducing now.

[Bug rust/108631] gcc/rust/backend/rust-constexpr.cc:2099:33: error: too few arguments to function ‘tree_node* Rust::Compile::unshare_constructor(tree, const char*, int, const char*)’ with --enable-ga

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

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

Arthur Cohen  changed:

   What|Removed |Added

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

[Bug libstdc++/108883] [13 Regression] ABI problems with _Float16/std::bfloat16_t rtti symbols on i?86

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

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 54506
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54506=edit
gcc13-pr108883.patch

Untested fix on the compiler side of emit_support_tinfos.

That said, these fundamental types whose presence/absence depends on ISA flags
are quite problematic IMHO, as they are incompatible with the target
attribute/pragmas.  Whether they are available or not available depends on
whether in this case SSE2 is enabled during compiler initialization (aka after
parsing command line options) and then they are available or unavailable to
everything else based on that.

[Bug c++/108884] New: [temp.friends]/9: Should constraint friends declared in class scope differ with definition out of scope?

[zyn7109 at gmail dot com via Gcc-bugs]

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

Bug ID: 108884
   Summary: [temp.friends]/9: Should constraint friends declared
in class scope differ with definition out of scope?
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zyn7109 at gmail dot com
  Target Milestone: ---

Clang implements deferred concept instantiation in
[D126907](https://reviews.llvm.org/D126907). As that patch suggests, according
to [temp.friend]/9, 

> A friend function template with a constraint that depends on a
> template parameter from an enclosing template shall be a definition.
> Such a constrained friend function or function template declaration
> does not declare the same function or function template as a
> declaration in any other scope.

That being said, such code should not compile as constrained friend declaration
(#1) doesn't declare the function defined out of class scope (#2).

(Example comes from https://github.com/clangd/clangd/issues/1511)

```cpp
// https://gcc.godbolt.org/z/sP9xdTqhe
template 
concept C = true;

template 
class Foo
{
private:
  Foo(const Ts&...) {};

public:
  friend auto factory(const C auto&...);  // #1
};

auto factory(const C auto&... ts)  // #2
{
  return Foo{ts...};
}

int main()
{
  factory(5);
}
```

Such code is rejected in Clang 16 onwards, showing that function defined at #2
is trying to access private constructor of `Foo`, but GCC still accepts this,
which implies GCC considers #1 and #2 are the same function. Is this a GCC
regression or I have missed something from the wording?

Note that if we swap #1 and #2, i.e.,
```cpp
// https://gcc.godbolt.org/z/WfG7vnxx8

template 
concept C = true;

template 
class Foo
{
private:
  Foo(const Ts&...) {}

public:
  friend auto factory(const C auto&... ts)
  {
return Foo{ts...};
  }
};

template 
auto factory(const C auto&... ts) -> Foo;

int main()
{
  factory(5);
}
```

then both GCC and Clang would accept it.

[Bug c/69960] "initializer element is not constant"

[daniel.lundin.mail at gmail dot com via Gcc-bugs]

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

--- Comment #20 from Daniel Lundin  ---
Further info about the "ARM32 port bug". 

In case you write code like `(uint32_t)_pointer` and the port happens
to use 32 bit pointers, the non-conforming cast is let through. 

In case you cast to an integer type of different size in relation to the
pointer size (non-portable cast), you first get a warning about that: "warning:
cast from pointer to integer of different size [-Wpointer-to-int-cast]",
followed by the diagnostic "error: initializer element is not computable at
load time".

https://godbolt.org/z/xjYvd41qe

Correct compiler behavior here is to always give a diagnostic for
(uint32_t)_handler not being an acceptable arithmetic constant
expression. 

If that's the same "implementation may accept other forms of constant
expressions"  bug as originally discussed here or a different bug, I don't
know.

[Bug libstdc++/108882] [13 Regression] Wrong symver on 4 new libstdc++ symbols on ppc64le

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-02-22
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

[Bug testsuite/108835] gm2 tests at large -jNN numbers do not return

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

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

Iain Sandoe  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org
 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED
 Target||*-*-darwin*

--- Comment #6 from Iain Sandoe  ---
still fails on several Darwin versions (depending on hardware).

[Bug target/108874] [10/11/12/13 Regression] Missing bswap detection

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

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

--- Comment #4 from Richard Biener  ---
(In reply to ktkachov from comment #3)
> (In reply to Richard Biener from comment #2)
> > The regression is probably rtl-optimization/target specific since we never
> > had this kind of pattern detected on the tree/GIMPLE level and there's no
> > builtin or IFN for this shuffling on u32.
> 
> FWIW a colleague reported that he bisected the failure to
> g:98e30e515f184bd63196d4d500a682fbfeb9635e though I haven't tried it myself.

There's a slight difference in before/after since GENERIC folding only
applied the (X & C2) << C1 into (X << C1) & (C2 << C1) transform
when the new BIT_AND "simplified":

- tem = fold_binary_loc (loc, BIT_AND_EXPR, type, shift, mask);
- if (tem)
-   return tem;

The transform was added in r0-84712-g22164c3db76535 for some rotate
patterns, tested by gcc.dg/fold-rotate-1.c, the pattern was meanwhile
extended to cover other bit operations as well.

> We do have patterns for these in aarch64 and arm, but combine would need to
> match about 5 insns to get there and that's beyond its current limit of 4

maybe some helper patterns no longer catch the differently canonicalized forms?

[Bug target/108874] [10/11/12/13 Regression] Missing bswap detection

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

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
(In reply to Richard Biener from comment #2)
> The regression is probably rtl-optimization/target specific since we never
> had this kind of pattern detected on the tree/GIMPLE level and there's no
> builtin or IFN for this shuffling on u32.

FWIW a colleague reported that he bisected the failure to
g:98e30e515f184bd63196d4d500a682fbfeb9635e though I haven't tried it myself.
We do have patterns for these in aarch64 and arm, but combine would need to
match about 5 insns to get there and that's beyond its current limit of 4

[Bug libstdc++/108883] [13 Regression] ABI problems with _Float16/std::bfloat16_t rtti symbols on i?86

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

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

--- Comment #2 from Richard Biener  ---
(In reply to Richard Biener from comment #1)
> Can we split them out to a separate CU that we can build with -msse2?
> 
> That is, does it work to simply add tinfo-x86-sse2.o by compiling
> fundamental_type_info.cc with -msse2 and the linker will sort out duplicates
> via comdats appropriately?

Hmm, but we have no way to tell it to prefer the -mno-sse2 variant if that
exists ...(?)

[Bug libstdc++/108883] [13 Regression] ABI problems with _Float16/std::bfloat16_t rtti symbols on i?86

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

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

Richard Biener  changed:

   What|Removed |Added

 Target||i?86-*-*

--- Comment #1 from Richard Biener  ---
Can we split them out to a separate CU that we can build with -msse2?

That is, does it work to simply add tinfo-x86-sse2.o by compiling
fundamental_type_info.cc with -msse2 and the linker will sort out duplicates
via comdats appropriately?

[Bug c/108880] [11/12/13 Regression] slow compilation with "-fsanitize=undefined"

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c/108880] [11/12/13 Regression] slow compilation with "-fsanitize=undefined"

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-02-22
Version|unknown |13.0
  Component|sanitizer   |c

--- Comment #4 from Richard Biener  ---
It's not only "slow", it also produces a gigantic executable, the .original
dump was 7.1GB when I stopped the compilation ...

The culprit is c_genericize calling c_genericize_control_r which must somehow
do the ubsan instrumentation as well.

[Bug middle-end/106258] [13 Regression] ICE in ipa_verify_edge_has_no_modifications, at ipa-param-manipulation.cc:139 since r13-1204-gd68d366425369649

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

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

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

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

commit r13-6273-gfb5365907317551cf9e4661aa78dd4f773e7a18a
Author: Jakub Jelinek 
Date:   Wed Feb 22 11:22:03 2023 +0100

cgraph: Handle BUILT_IN_UNREACHABLE_TRAP like BUILT_IN_UNREACHABLE in more
spots [PR106258]

The following testcase ICEs because we still have some spots that
treat BUILT_IN_UNREACHABLE specially but not BUILT_IN_UNREACHABLE_TRAP
the same.

2023-02-22  Jakub Jelinek  

PR middle-end/106258
* cgraph.cc (cgraph_edge::redirect_call_stmt_to_callee,
cgraph_update_edges_for_call_stmt_node, cgraph_node::verify_node):
Handle BUILT_IN_UNREACHABLE_TRAP like BUILT_IN_UNREACHABLE.
* cgraphclones.cc (cgraph_node::create_clone): Likewise.

* g++.dg/ipa/pr106258.C: New test.

[Bug c/69960] "initializer element is not constant"

[daniel.lundin.mail at gmail dot com via Gcc-bugs]

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

Daniel Lundin  changed:

   What|Removed |Added

 CC||daniel.lundin.mail at gmail 
dot co
   ||m

--- Comment #19 from Daniel Lundin  ---
This ought to be discussed again. "clang allows it" is not an argument. 

First of all, it is questionable if gcc is still conforming after the change
discussed here and implemented as per gcc 8.0. Yes "an implementation may
accept other forms of constant expressions" but that doesn't mean that a
compiler is allowed to ignore the constraints in C17 6.7.9/4 nor the definition
of an integer constant expression. So this ought to explicitly be a compiler
extension and we ought to have a way to reliably compile strictly conforming
programs with gcc without constraint violations silently getting ignored. 

So if this feature is desired as an extension (I'm sure it is), then the old
diagnostic message should still be there when compiling as -std=c17 -pedantic.
See detailed discussion and relevant ISO 9899 quotes here:
https://stackoverflow.com/questions/68252570/why-are-const-qualified-variables-accepted-as-initializers-on-gcc

On top of that mess, I just found out that gcc behaves inconsistently in
regards of constant expressions between compiler ports. All gcc ports reject an
initializer such as (uint32_t)_pointer as they ought, except gcc for
ARM32 which silently allows this even under strict mode. This as per
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108875 which I think is NOT a bug,
since the definition of an arithmetic constant expression (6.6) always had
"Cast operators in an arithmetic constant expression shall only convert
arithmetic types to arithmetic types". A function/object pointer is not an
arithmetic type. A normative "shall" was violated. A conforming compiler must
issue a diagnostic. 

If the C standard by design blocks meaningful use of some constant expressions
inside initializer lists (I would agree that it does, the linked bug report
above is a very valid use-case in embedded systems), then gcc has the option to
make an extension and only warn in -pedantic mode. Bug again, this route was
not taken there either. Standard compliance was just silently abandoned in the
ARM32 port.

Therefore the current state of affairs is: gcc <8.0 (IMO compliant) behaves
differently from gcc >=8.0 which in turn behaves differently from gcc ARM32 any
version. Three different gcc behaviors for a language feature which has NOT
changed at all between C90 to C17.

All of this has to be revisited for the C23 constexpr/"named constants" 
implementation, so it would be great if we at the same time can separate
non-standard extensions from -pedantic mode. Notably C23 does not allow casts
from non-arithemtic types inside arithmetic constant expressions either.

Also note that C23 changed the wording slightly from C17: "An implementation
may accept other forms of constant expressions; however, they are not an
integer constant expression." I don't know why but likely because of some
implemented DR.

[Bug ipa/107925] ICE in update_specialized_profile at gcc/ipa-cp.cc:5082 for 531.deepsjeng_r benchmark

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

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

--- Comment #7 from Martin Jambor  ---
I have proposed the patch on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612506.html

[Bug libstdc++/108883] New: [13 Regression] ABI problems with _Float16/std::bfloat16_t rtti symbols on i?86

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

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

Bug ID: 108883
   Summary: [13 Regression] ABI problems with
_Float16/std::bfloat16_t rtti symbols on i?86
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

My https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612342.html patch
works fine on i?86 in Fedora 38/39, but when I try it in my local
bootstrap/regtest,
_ZTIDF16b
_ZTIDF16_
_ZTIPKDF16_
_ZTIPDF16b
_ZTIPDF16_
_ZTIPKDF16b
symbols are missing.  This is because _Float16 and decltype(0.0bf16) on
i?86/x86_64
are only supported with -msse2 (because psABI passes those in SSE registers). 
While x86_64 has -msse2 on by default, ia32 doesn't and it would be problematic
if these 6 exports depend on whether libstdc++.{so,a} or libsupc++.a has been
built with -msse2 or not; programs could be compiled with -msse2 and use those
types and if libstdc++ doesn't
have the rtti for it, it wouldn't link.

Not sure what we can do, either detect that and compile
libstdc++-v3/libsupc++/fundamental_type_info.cc in that case forcefully with
-msse2 and
arrange in that case for [[gnu::target ("no-sse")]] to be on the destructor
definition
so that SSE/SSE2 instructions don't leak by accident into the dtor code, or
supply the RTTI symbols by hand say in assembly (we are doing this sort of
things in
RHEL GTS), or arrange somehow for the backend(s) to pretend support for the
extra types even if they are just supported conditionally, say by adding a new
target hook which would be called when emitting the fundamental type info.

[Bug libstdc++/108883] [13 Regression] ABI problems with _Float16/std::bfloat16_t rtti symbols on i?86

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-02-22
 CC||jason at gcc dot gnu.org,
   ||redi at gcc dot gnu.org
   Target Milestone|--- |13.0

[Bug middle-end/108854] tbb-2021.8.0 fails on i686-linux (32-bit), internal compiler error: in expand_expr_real_1, at expr.c:10281

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

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

Sergei Trofimovich  changed:

   What|Removed |Added

 CC||slyfox at gcc dot gnu.org

--- Comment #8 from Sergei Trofimovich  ---
Created attachment 54505
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54505=edit
bug.cpp.xz

I reproduced it locally as well. Extracted preprocessed file as bug.cpp.xz (not
yet reduced).

To crash:

g++ -O3 -Wall -Wextra -Werror -Wfatal-errors -Wno-error=stringop-overflow
-Wshadow -Wcast-qual -Woverloaded-virtual -Wnon-virtual-dtor -mrtm -mwaitpkg
-std=c++11 -c bug.cpp -fPIC -fstack-protector-strong --param ssp-buffer-size=4
-fno-strict-overflow
during RTL pass: expand
In file included from
/nix/store/c4xm3qfkw2npn4vyiyx2pkp95rb27ig8-gcc-12.2.0/include/c++/12.2.0/atomic:41,
 from
/home/slyfox/nsn/source/src/tbb/../../include/tbb/../oneapi/tbb/flow_graph.h:20,
 from
/home/slyfox/nsn/source/src/tbb/../../include/tbb/flow_graph.h:17,
 from
/home/slyfox/nsn/source/test/tbb/test_eh_flow_graph.cpp:25:
/nix/store/c4xm3qfkw2npn4vyiyx2pkp95rb27ig8-gcc-12.2.0/include/c++/12.2.0/bits/atomic_base.h:
In member function 'bool tbb::detail::d1::input_node
>::_ZThn16_N3tbb6detail2d110input_nodeISt5tupleIJiiEEE18register_successorERNS1_8receiverIS4_EE.artificial_thunk.0(successor_type&)':
/nix/store/c4xm3qfkw2npn4vyiyx2pkp95rb27ig8-gcc-12.2.0/include/c++/12.2.0/bits/atomic_base.h:506:36:
internal compiler error: in expand_expr_real_1, at expr.cc:10586
  506 | return __atomic_exchange_n(&_M_i, __i, int(__m));
  |^
0x9764c81 diagnostic_impl(rich_location*, diagnostic_metadata const*, int, char
const*, char**, diagnostic_t)
???:0
0x976527c internal_error(char const*, ...)
???:0
0x832b252 fancy_abort(char const*, int, char const*)
???:0
0x82f641b expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool) [clone .cold]
???:0
0x86d5b33 expand_operands(tree_node*, tree_node*, rtx_def*, rtx_def**,
rtx_def**, expand_modifier)
???:0
0x86e4307 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
???:0
0x86d1ec1 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
???:0
0x86dbda2 expand_expr_addr_expr_1(tree_node*, rtx_def*, scalar_int_mode,
expand_modifier, unsigned char)
???:0
0x86d16d4 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
???:0
0x86dec8e store_expr(tree_node*, rtx_def*, int, bool, bool)
???:0
0x86e07ba expand_assignment(tree_node*, tree_node*, bool) [clone .part.0]
???:0
0x85cb005 expand_gimple_stmt(gimple*)
???:0
0x85cff76 expand_gimple_basic_block(basic_block_def*, bool)
???:0
0x85d1e56 (anonymous namespace)::pass_expand::execute(function*)
???: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.

$ g++ -v |& unnix
Using built-in specs.
COLLECT_GCC=/<>/gcc-12.2.0/bin/g++
COLLECT_LTO_WRAPPER=/<>/gcc-12.2.0/libexec/gcc/i686-unknown-linux-gnu/12.2.0/lto-wrapper
Target: i686-unknown-linux-gnu
Configured with:
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.2.0 (GCC)