[Bug middle-end/113731] [14 regression] ICE when building libbsd since r14-8768-g85094e2aa6dba7

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

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

--- Comment #5 from Sam James  ---
> the libarchive, is that also with -march=znver2? and is
> https://github.com/libarchive/libarchive?

Yeah, filed PR113734 for it.

[Bug middle-end/113731] [14 regression] ICE when building libbsd since r14-8768-g85094e2aa6dba7

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

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

Tamar Christina  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2024-02-03
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |tnfchris at gcc dot 
gnu.org

--- Comment #4 from Tamar Christina  ---
blah,

  gsi_move_before (_gsi, _gsi);

when dest_gsi is empty does not move the pointer.  It's not mentioned in the
description but in the function it eventually calls gsi_insert_before there's a
comment

/* If CUR is NULL, we link at the end of the sequence (this case happens

so it adds it to the end instead of start like you asked.

diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index 30b90d99925..e2587315020 100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -11801,7 +11801,8 @@ move_early_exit_stmts (loop_vec_info loop_vinfo)

   gimple_stmt_iterator stmt_gsi = gsi_for_stmt (stmt);
   gsi_move_before (_gsi, _gsi);
-  gsi_prev (_gsi);
+  if (!gsi_end_p (dest_gsi))
+   gsi_prev (_gsi);
 }

fixes it.

the libarchive, is that also with -march=znver2? and is
https://github.com/libarchive/libarchive?

[Bug tree-optimization/51492] vectorizer does not support saturated arithmetic patterns

[pan2.li at intel dot com via Gcc-bugs]

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

--- Comment #15 from Li Pan  ---
(In reply to Tamar Christina from comment #14)
> Awesome! Feel free to reach out if you need any help.
> 
> It’s likely easier to start with add and sub and get things pipe cleaned and
> expand incrementally than to try and do it all at once.

Cool, thanks in advance.

I will first try to make a SAT_ADD to the direct optab for a POC following your
RFC and suggestion. Looks like at least match.pd and internal-fn.def will be
touched. I am learning how match.pd works right now.

Dedicated Servers Promotions and offers-gcc-b...@gcc.gnu.org

[gowebing via Gcc-bugs]

Mumara Email Template 

 

 

Dedicated Server Hosting 

 

 

 

Dedicated Servers Promotions and Offers

 

 

CPU:i3  RAM:8G Disk:1T United States

 

79 USD/M 
:http://click.return.gowebing.com/campaign/clicked/MjA5ODk3MDQw__MjgwNg%3D%3D__MzIxNjI5NTU%3D__ODkx__2036__3100__129/aHR0cHMlM0ElMkYlMkZ3d3cuZ293ZWJpbmcuY29tJTJGcHJvbW90aW9ucy5waHA=
 

 

  

 

 

gowebing  |  
unsubscribe:http://click.return.gowebing.com/campaign/unsub-email/MjgwNg%3D%3D/MzIxNjI5NTU%3D/MjAzNg%3D%3D__MjA5ODk3MDQw__ODkx

Dedicated Servers Promotions and offers-gcc-b...@gcc.gnu.org

[gowebing via Gcc-bugs]

Mumara Email Template 

 

 

Dedicated Server Hosting 

 

 

 

Dedicated Servers Promotions and Offers

 

 

CPU:i3  RAM:8G Disk:1T United States

 

79 USD/M 
:http://click.return.gowebing.com/campaign/clicked/MjA5ODk3MDQw__MjgwNg%3D%3D__MzIxNjI5NTU%3D__ODkx__2036__3100__129/aHR0cHMlM0ElMkYlMkZ3d3cuZ293ZWJpbmcuY29tJTJGcHJvbW90aW9ucy5waHA=
 

 

  

 

 

gowebing  |  
unsubscribe:http://click.return.gowebing.com/campaign/unsub-email/MjgwNg%3D%3D/MzIxNjI5NTU%3D/MjAzNg%3D%3D__MjA5ODk3MDQw__ODkx

[Bug ipa/97119] Top level option to disable creation of IPA symbols such as .localalias is desired

[ali_gccbugzilla at emvision dot com via Gcc-bugs]

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

--- Comment #10 from Ali Bahrami  ---
> I think the issue described here are all covered by pr 63572

Can you explain how? I might not have followed it, but
pr 63572 seems to revolve around generating correct DWARF
content? Here, we're not reading the DWARF at all, so its
correctness isn't a factor. We're not really making any claims
about gcc correctness.

The problem here is that what these optimizations do
cause us difficulties in our simple mapping of addresses
to names, while the optimizations themselves don't have
enough impact to fight for. Hence, we'd like the option
to opt out.

- Ali

[Bug middle-end/113734] New: [14 regression] libarchive miscompiled (fails libarchive_test_read_format_rar5_extra_field_version test) since r14-8768-g85094e2aa6dba7

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

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

Bug ID: 113734
   Summary: [14 regression] libarchive miscompiled (fails
libarchive_test_read_format_rar5_extra_field_version
test) since r14-8768-g85094e2aa6dba7
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: tnfchris at gcc dot gnu.org
  Target Milestone: ---

This is the miscompilation in libarchive's test suite I mentioned as an aside
in PR113731.

Steps to reproduce:
1. wget
https://github.com/libarchive/libarchive/releases/download/v3.7.2/libarchive-3.7.2.tar.xz
2. tar xvf libarchive-3.7.2.tar.xz && cd libarchive-3.7.2
3. export CFLAGS="-O3 -march=znver2 -ggdb3" CXXFLAGS="-O3 -march=znver2 -ggdb3"
; cmake -B out -S . -G Ninja
4. ninja -C out
5. ninja -C out test

The test failure is pretty suspicious:
```
/home/sam/data/libarchive/libarchive-3.7.2/libarchive/test/test_read_format_rar5.c:106:
bytes_read != fsize
  bytes_read=-30 (0xffe2, 0177742)
  fsize=95 (0x5f, 0137)
/home/sam/data/libarchive/libarchive-3.7.2/libarchive/test/test_read_format_rar5.c:959:
Assertion failed: 0 == extract_one(a, ae, 0xF24181B7)
errno: 22
   detail: Failed to decode the distance slot

Totals:
  Tests run:1
  Tests failed: 1
  Assertions checked: 399
  Assertions failed:4
  Skips reported:   0

Failing tests:
  347: test_read_format_rar5_extra_field_version (4 failures)
```

If I run it under Valgrind, I then get:
```
$ valgrind "/home/sam/data/libarchive/libarchive-3.7.2/out/bin/libarchive_test"
"-vv" "-r" "/home/sam/data/libarchive/libarchive-3.7.2/libarchive/test"
"test_read_fo
rmat_rar5_extra_field_version"
==205571== Memcheck, a memory error detector
==205571== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==205571== Using Valgrind-3.23.0.GIT and LibVEX; rerun with -h for copyright
info
==205571== Command:
/home/sam/data/libarchive/libarchive-3.7.2/out/bin/libarchive_test -vv -r
/home/sam/data/libarchive/libarchive-3.7.2/libarchive/test
test_read_format_rar5_extra_field_version
==205571==

If tests fail or crash, details will be in:
   /tmp/libarchive_test.2024-02-03T00.01.16-000

Reference files will be read from:
/home/sam/data/libarchive/libarchive-3.7.2/libarchive/test
Exercising: libarchive 3.7.2 zlib/1.3.1 liblzma/5.5.1alpha bz2lib/1.0.8
liblz4/1.9.4 libzstd/1.5.5
347: test_read_format_rar5_extra_field_version
==205571== Use of uninitialised value of size 8
==205571==at 0x2752A9: create_decode_tables
(archive_read_support_format_rar5.c:2504)
==205571==by 0x2752A9: parse_tables.constprop.0
(archive_read_support_format_rar5.c:2736)
==205571==by 0x27C942: process_block
(archive_read_support_format_rar5.c:3557)
==205571==by 0x27C942: do_uncompress_file
(archive_read_support_format_rar5.c:3753)
==205571==by 0x27C942: uncompress_file
(archive_read_support_format_rar5.c:3837)
==205571==by 0x27C942: do_unpack (archive_read_support_format_rar5.c:3923)
==205571==by 0x27C942: rar5_read_data
(archive_read_support_format_rar5.c:4087)
==205571==by 0x23D63B: archive_read_data (archive_read.c:841)
==205571==by 0x1AA34C: extract_one (test_read_format_rar5.c:104)
==205571==by 0x1B22CA: test_read_format_rar5_extra_field_version
(test_read_format_rar5.c:955)
==205571==by 0x11E0A4: test_run (test_main.c:3570)
==205571==by 0x11E0A4: main (test_main.c:4182)
[...]
==205571==
==205571== Conditional jump or move depends on uninitialised value(s)
==205571==at 0x275518: create_decode_tables
(archive_read_support_format_rar5.c:2524)
==205571==by 0x275518: parse_tables.constprop.0
(archive_read_support_format_rar5.c:2736)
==205571==by 0x27C942: process_block
(archive_read_support_format_rar5.c:3557)
==205571==by 0x27C942: do_uncompress_file
(archive_read_support_format_rar5.c:3753)
==205571==by 0x27C942: uncompress_file
(archive_read_support_format_rar5.c:3837)
==205571==by 0x27C942: do_unpack (archive_read_support_format_rar5.c:3923)
==205571==by 0x27C942: rar5_read_data
(archive_read_support_format_rar5.c:4087)
==205571==by 0x23D63B: archive_read_data (archive_read.c:841)
==205571==by 0x1AA34C: extract_one (test_read_format_rar5.c:104)
==205571==by 0x1B22CA: test_read_format_rar5_extra_field_version
(test_read_format_rar5.c:955)
==205571==by 0x11E0A4: test_run (test_main.c:3570)
==205571==by 0x11E0A4: main (test_main.c:4182)
==205571==
[...]
```

I will dig a bit more.

[Bug modula2/113730] Unexpected handling of mixed-precision integer arithmetic

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

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

[Bug c++/110006] [11/12/13 Regression] friend function template with constraint doesn't match existing declaration

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

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug c++/112769] [11/12/13 Regression] ICE on valid code related to requires-expression

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

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

Patrick Palka  changed:

   What|Removed |Added

Summary|[11/12/13/14 Regression]|[11/12/13 Regression] ICE
   |ICE on valid code related   |on valid code related to
   |to requires-expression  |requires-expression

--- Comment #5 from Patrick Palka  ---
Fixed for GCC 14 so far.

[Bug c++/110006] [11/12/13 Regression] friend function template with constraint doesn't match existing declaration

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

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

Patrick Palka  changed:

   What|Removed |Added

Summary|[11/12/13/14 Regression]|[11/12/13 Regression]
   |friend function template|friend function template
   |with constraint doesn't |with constraint doesn't
   |match existing declaration  |match existing declaration

--- Comment #5 from Patrick Palka  ---
Fixed for GCC 14 so far.

[Bug c++/112769] [11/12/13/14 Regression] ICE on valid code related to requires-expression

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:686b5eb9c9ee623a604dde5c49fa11c23f384c62

commit r14-8770-g686b5eb9c9ee623a604dde5c49fa11c23f384c62
Author: Patrick Palka 
Date:   Fri Feb 2 19:07:08 2024 -0500

c++: requires-exprs and partial constraint subst [PR110006]

In r11-3261-gb28b621ac67bee we made tsubst_requires_expr never partially
substitute into a requires-expression so as to avoid checking its
requirements out of order during e.g. generic lambda regeneration.

These PRs however illustrate that we still sometimes do need to
partially substitute into a requires-expression, in particular when it
appears in associated constraints that we're directly substituting for
sake of declaration matching or dguide constraint rewriting.  In these
cases we're being called from tsubst_constraint during which
processing_constraint_expression_p is true, so this patch checks this
predicate to control whether we defer substitution or partially
substitute.

In turn, we now need to propagate semantic tsubst flags through
tsubst_requires_expr rather than just using tf_none, notably for sake of
dguide constraint rewriting which sets tf_dguide.

PR c++/110006
PR c++/112769

gcc/cp/ChangeLog:

* constraint.cc (subst_info::quiet): Accomodate non-diagnostic
tsubst flags.
(tsubst_valid_expression_requirement): Likewise.
(tsubst_simple_requirement): Return a substituted _REQ node when
processing_template_decl.
(tsubst_type_requirement_1): Accomodate non-diagnostic tsubst
flags.
(tsubst_type_requirement): Return a substituted _REQ node when
processing_template_decl.
(tsubst_compound_requirement): Likewise.  Accomodate non-diagnostic
tsubst flags.
(tsubst_nested_requirement): Likewise.
(tsubst_requires_expr): Don't defer partial substitution when
processing_constraint_expression_p is true, in which case return
a substituted REQUIRES_EXPR.
* pt.cc (tsubst_expr) : Accomodate
non-diagnostic tsubst flags.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/class-deduction-alias18.C: New test.
* g++.dg/cpp2a/concepts-friend16.C: New test.

Reviewed-by: Jason Merrill 

[Bug c++/110006] [11/12/13/14 Regression] friend function template with constraint doesn't match existing declaration

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:686b5eb9c9ee623a604dde5c49fa11c23f384c62

commit r14-8770-g686b5eb9c9ee623a604dde5c49fa11c23f384c62
Author: Patrick Palka 
Date:   Fri Feb 2 19:07:08 2024 -0500

c++: requires-exprs and partial constraint subst [PR110006]

In r11-3261-gb28b621ac67bee we made tsubst_requires_expr never partially
substitute into a requires-expression so as to avoid checking its
requirements out of order during e.g. generic lambda regeneration.

These PRs however illustrate that we still sometimes do need to
partially substitute into a requires-expression, in particular when it
appears in associated constraints that we're directly substituting for
sake of declaration matching or dguide constraint rewriting.  In these
cases we're being called from tsubst_constraint during which
processing_constraint_expression_p is true, so this patch checks this
predicate to control whether we defer substitution or partially
substitute.

In turn, we now need to propagate semantic tsubst flags through
tsubst_requires_expr rather than just using tf_none, notably for sake of
dguide constraint rewriting which sets tf_dguide.

PR c++/110006
PR c++/112769

gcc/cp/ChangeLog:

* constraint.cc (subst_info::quiet): Accomodate non-diagnostic
tsubst flags.
(tsubst_valid_expression_requirement): Likewise.
(tsubst_simple_requirement): Return a substituted _REQ node when
processing_template_decl.
(tsubst_type_requirement_1): Accomodate non-diagnostic tsubst
flags.
(tsubst_type_requirement): Return a substituted _REQ node when
processing_template_decl.
(tsubst_compound_requirement): Likewise.  Accomodate non-diagnostic
tsubst flags.
(tsubst_nested_requirement): Likewise.
(tsubst_requires_expr): Don't defer partial substitution when
processing_constraint_expression_p is true, in which case return
a substituted REQUIRES_EXPR.
* pt.cc (tsubst_expr) : Accomodate
non-diagnostic tsubst flags.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/class-deduction-alias18.C: New test.
* g++.dg/cpp2a/concepts-friend16.C: New test.

Reviewed-by: Jason Merrill 

[Bug modula2/113730] Unexpected handling of mixed-precision integer arithmetic

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Gaius Mulley :

https://gcc.gnu.org/g:64b0130bb6702c67a13caefaae9facef23d6ac60

commit r14-8769-g64b0130bb6702c67a13caefaae9facef23d6ac60
Author: Gaius Mulley 
Date:   Sat Feb 3 00:03:39 2024 +

PR modula2/113730 Unexpected handling of mixed-precision integer arithmetic

This patch fixes a bug which occurs when an expression is created with
a ZType and an integer or cardinal.  The resulting subexpression is
incorrecly given a ZType which allows compatibility with another
integer/cardinal type.  The solution was to fix the subexpression
type.  In turn this required a minor change to SArgs.mod.

gcc/m2/ChangeLog:

PR modula2/113730
* gm2-compiler/M2Base.mod (IsUserType): New procedure function.
(MixTypes): Use IsUserType instead of IsType before calling
MixTypes.
* gm2-compiler/M2GenGCC.mod (GetTypeMode): Remove and import from
SymbolTable.
(CodeBinaryCheck): Replace call to MixTypes with MixTypesBinary.
(CodeBinary): Replace call to MixTypes with MixTypesBinary.
(CodeIfLess): Replace MixTypes with ComparisonMixTypes.
(CodeIfGre): Replace MixTypes with ComparisonMixTypes.
(CodeIfLessEqu): Replace MixTypes with ComparisonMixTypes.
(CodeIfGreEqu): Replace MixTypes with ComparisonMixTypes.
(CodeIfEqu): Replace MixTypes with ComparisonMixTypes.
(CodeIfNotEqu): Replace MixTypes with ComparisonMixTypes.
(ComparisonMixTypes): New procedure function.
* gm2-compiler/M2Quads.mod (BuildEndFor): Replace GenQuadO
with GenQuadOtok and pass tokenpos for the operands to the AddOp
and XIndrOp.
(CheckRangeIncDec): Check etype against NulSym and dtype for a
pointer and set etype to Address.
(BuildAddAdrFunction): New variable opa.  Convert operand to an
address and save result in opa.  Replace GenQuad with GenQuadOtok.
(BuildSubAdrFunction): New variable opa.  Convert operand to an
address and save result in opa.  Replace GenQuad with GenQuadOtok.
(BuildDiffAdrFunction): New variable opa.  Convert operand to an
address and save result in opa.  Replace GenQuad with GenQuadOtok.
(calculateMultipicand): Replace GenQuadO with GenQuadOtok.
(ConvertToAddress): New procedure function.
(BuildDynamicArray): Convert index to address before adding to
the base.
* gm2-compiler/SymbolTable.def (GetTypeMode): New procedure
function.
* gm2-compiler/SymbolTable.mod (GetTypeMode): New procedure
function implemented (moved from M2GenGCC.mod).
* gm2-libs/SArgs.mod (GetArg): Replace cast to PtrToChar with
ADDRESS.

gcc/testsuite/ChangeLog:

PR modula2/113730
* gm2/extensions/fail/arith1.mod: New test.
* gm2/extensions/fail/arith2.mod: New test.
* gm2/extensions/fail/arith3.mod: New test.
* gm2/extensions/fail/arith4.mod: New test.
* gm2/extensions/fail/arithpromote.mod: New test.
* gm2/extensions/fail/extensions-fail.exp: New test.
* gm2/linking/fail/badimp.def: New test.
* gm2/linking/fail/badimp.mod: New test.
* gm2/linking/fail/linking-fail.exp: New test.
* gm2/linking/fail/testbadimp.mod: New test.

Signed-off-by: Gaius Mulley 

[Bug tree-optimization/113467] [14 regression] libgcrypt-1.10.3 is miscompiled

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

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

--- Comment #30 from GCC Commits  ---
The master branch has been updated by Tamar Christina :

https://gcc.gnu.org/g:85094e2aa6dba7908f053046f02dd443e8f65d72

commit r14-8768-g85094e2aa6dba7908f053046f02dd443e8f65d72
Author: Tamar Christina 
Date:   Fri Feb 2 23:52:27 2024 +

middle-end: check memory accesses in the destination block [PR113588].

When analyzing loads for early break it was always the intention that for
the
exit where things get moved to we only check the loads that can be reached
from
the condition.

However the main loop checks all loads and we skip the destination BB.  As
such
we never actually check the loads reachable from the COND in the last BB
unless
this BB was also the exit chosen by the vectorizer.

This leads us to incorrectly vectorize the loop in the PR and in doing so
access
out of bounds.

gcc/ChangeLog:

PR tree-optimization/113588
PR tree-optimization/113467
* tree-vect-data-refs.cc
(vect_analyze_data_ref_dependence):  Choose correct dest and fix
checks.
(vect_analyze_early_break_dependences): Update comments.

gcc/testsuite/ChangeLog:

PR tree-optimization/113588
PR tree-optimization/113467
* gcc.dg/vect/vect-early-break_108-pr113588.c: New test.
* gcc.dg/vect/vect-early-break_109-pr113588.c: New test.

[Bug tree-optimization/113588] [14 Regression] The vectorizer is introducing out-of-bounds memory access

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

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by Tamar Christina :

https://gcc.gnu.org/g:85094e2aa6dba7908f053046f02dd443e8f65d72

commit r14-8768-g85094e2aa6dba7908f053046f02dd443e8f65d72
Author: Tamar Christina 
Date:   Fri Feb 2 23:52:27 2024 +

middle-end: check memory accesses in the destination block [PR113588].

When analyzing loads for early break it was always the intention that for
the
exit where things get moved to we only check the loads that can be reached
from
the condition.

However the main loop checks all loads and we skip the destination BB.  As
such
we never actually check the loads reachable from the COND in the last BB
unless
this BB was also the exit chosen by the vectorizer.

This leads us to incorrectly vectorize the loop in the PR and in doing so
access
out of bounds.

gcc/ChangeLog:

PR tree-optimization/113588
PR tree-optimization/113467
* tree-vect-data-refs.cc
(vect_analyze_data_ref_dependence):  Choose correct dest and fix
checks.
(vect_analyze_early_break_dependences): Update comments.

gcc/testsuite/ChangeLog:

PR tree-optimization/113588
PR tree-optimization/113467
* gcc.dg/vect/vect-early-break_108-pr113588.c: New test.
* gcc.dg/vect/vect-early-break_109-pr113588.c: New test.

[Bug target/113733] New: Invalid APX TLS code squence

[hjl.tools at gmail dot com via Gcc-bugs]

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

Bug ID: 113733
   Summary: Invalid APX TLS code squence
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com, hongyuw at gcc dot gnu.org
  Target Milestone: ---
Target: x86-64

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

[hjl@gnu-cfl-3 apx-1]$ make
/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/ -mapxf
-O3 -dp -S x.c
/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/ -mapxf
-O3 -dp   -c -o x.o x.c
/tmp/ccbItraT.s: Assembler messages:
/tmp/ccbItraT.s:29: Error: TLS relocation cannot be used with `add'
make: *** [: x.o] Error 1
[hjl@gnu-cfl-3 apx-1]$ 

This NDD
addq%rax, a@gottpoff(%rip), %r15

can't be used in TLS code sequence.

[Bug go/113530] libgo ftbfs on arc-linux-gnu

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Ian Lance Taylor :

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

commit r14-8763-gcfc6d9ae8143cf0e903384bc63e8d659ca1c9fe7
Author: Ian Lance Taylor 
Date:   Mon Jan 22 17:26:23 2024 -0800

libgo: better error messages for unknown GOARCH/GOOS

PR go/113530

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/557655

[Bug middle-end/113731] [14 regression] ICE when building libbsd

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||pinskia at gcc dot gnu.org
   Target Milestone|--- |14.0

[Bug tree-optimization/113725] [14 Regression] ICE during GIMPLE pass: cunroll

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|ICE during GIMPLE pass: |[14 Regression] ICE during
   |cunroll |GIMPLE pass: cunroll
   Target Milestone|--- |14.0
   Keywords||ice-on-valid-code

[Bug middle-end/113731] [14 regression] ICE when building libbsd

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

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

--- Comment #3 from Sam James  ---
I also get a new libarchive test failure with it:
```
test_read_format_rar5_extra_field_version

/var/tmp/portage/app-arch/libarchive-3.7.2/work/libarchive-3.7.2/libarchive/test/test_read_format_rar5.c:106:
bytes_read != fsize
  bytes_read=-30 (0xffe2, 0177742)
  fsize=95 (0x5f, 0137)
/var/tmp/portage/app-arch/libarchive-3.7.2/work/libarchive-3.7.2/libarchive/test/test_read_format_rar5.c:955:
Assertion failed: 0 == extract_one(a, ae, 0xF24181B7)
errno: 22
   detail: Unpacker has written too many bytes
/var/tmp/portage/app-arch/libarchive-3.7.2/work/libarchive-3.7.2/libarchive/test/test_read_format_rar5.c:111:
computed_crc != crc
  computed_crc=1827567249 (0x6cee7691, 015473473221)
  crc=4064379319 (0xf24181b7, 036220300667)
```

[Bug ipa/97119] Top level option to disable creation of IPA symbols such as .localalias is desired

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #9 from Andrew Pinski  ---
I think the issue described here are all covered by pr 63572

[Bug ipa/97119] Top level option to disable creation of IPA symbols such as .localalias is desired

[ali_gccbugzilla at emvision dot com via Gcc-bugs]

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

--- Comment #8 from Ali Bahrami  ---
> I am not quite sure how this confuses stack unwinding on Solaris?

I don't think that most of what you described is a problem
for stack unwinding on Solaris. As discussed in the initial
note, the problem is that we use a table that maps address to
function names ("sort sections") to map virtual addresses to
symbols, and then use those symbol names for the stack
trace. The localalias, and similar, symbols that gcc is
producing make trouble for us, in a couple of ways:

(1) Since these symbols have the same addresses as the
original functions, they might show up in the stack
trace output, rather than the "real" name that the
programmer used.

(2) In the case where gcc replaces multiple identical
function bodies with one instance, the original 1:1
relationship between name and address is lost. Imagine
that my code has functions fooA() and fooB() that get
collapsed into one body, and now, both functions have
the same address. My stack traces may show one when the
programmer actually called the other.

(1) is just an annoyance. (2) is a bit more serious, since
conceptually, fooA() and fooB() really are different, and the
programmer really should see a stack that reflects what their
source code says.

As to why this is done, it's a way to get a useful
stack trace for code that has no debug sections, or
in contexts where running a debugger to get a trace
isn't possible. We put a high priority on observabilty
in contexts where debug sections are not available, or
running a debugger is not possible.

As I hope was clear in my original note, we think these gcc
optimizations are very useful for lots (maybe most) code,
but for our very simple C code base, the win is small, and
the negative aspects are a problem. It would be very useful
for us if this class of optimization could be disabled with
a simple switch.

We filed this request almost 4 years ago, and seeing that it
wasn't getting traction, I've since modified our link-editor
to drop all symbols of the form

XXX.isra.dd
XXX.localalias.dd
XXX.part.dd

from the sort sections. It's an effective hack against
problem (1) above, though not (2). It's also not how
linking ought to work: hardwiring and checking the names
of symbols produced by a specific compiler as a side effect
of optimization settings is ugly and error prone. I'd love
to rip it out if we can get back to gcc producing the 1:1
symbol to code address relationship.

Let me know if more explanation is needed. Thanks.

[Bug middle-end/113731] [14 regression] ICE when building libbsd

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

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

--- Comment #2 from Sam James  ---
```
char* inet_net_pton_ipv4_bits;
char inet_net_pton_ipv4_odst;
void __errno_location();
void inet_net_pton_ipv4();
void inet_net_pton() { inet_net_pton_ipv4(); }
void inet_net_pton_ipv4(char *dst, int size) {
  while ((inet_net_pton_ipv4_bits > dst) & inet_net_pton_ipv4_odst) {
if (size-- <= 0)
  goto emsgsize;
*dst++ = '\0';
  }
emsgsize:
  __errno_location();
}
```

[Bug c++/113710] [14 Regression] g++.dg/modules/hello-1 ICE: canonical types differ for identical types since r14-8710-g65b4cba9d6a9ff

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

[Bug c++/113710] [14 Regression] g++.dg/modules/hello-1 ICE: canonical types differ for identical types since r14-8710-g65b4cba9d6a9ff

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

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

[Bug libstdc++/113732] [14 Regression] FAIL: g++.dg/modules/hello-1_b.C caused by r14-8710

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup.

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

[Bug libstdc++/113732] New: [14 Regression] FAIL: g++.dg/modules/hello-1_b.C caused by r14-8710

[hjl.tools at gmail dot com via Gcc-bugs]

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

Bug ID: 113732
   Summary: [14 Regression] FAIL: g++.dg/modules/hello-1_b.C
caused by r14-8710
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ppalka at gcc dot gnu.org
  Target Milestone: ---

On x86-64, r14-8710 caused:

FAIL: g++.dg/modules/hello-1_b.C -std=c++17 (internal compiler error: canonical 
types differ for identical types 'std::tuple_element<__i, std::tuple<_Elements
.
..> >' and 'std::tuple_element<__i, std::tuple<_Elements ...> >')
FAIL: g++.dg/modules/hello-1_b.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/hello-1_b.C -std=c++2a (internal compiler error: canonical 
types differ for identical types 'std::tuple_element<__i, std::tuple<_Elements
.
..> >' and 'std::tuple_element<__i, std::tuple<_Elements ...> >')
FAIL: g++.dg/modules/hello-1_b.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/hello-1_b.C -std=c++2b (internal compiler error: canonical 
types differ for identical types 'std::tuple_element<__i, std::tuple<_Elements
.
..> >' and 'std::tuple_element<__i, std::tuple<_Elements ...> >')
FAIL: g++.dg/modules/hello-1_b.C -std=c++2b (test for excess errors)

[Bug middle-end/113731] [14 regression] ICE when building libbsd

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

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

--- Comment #1 from Sam James  ---
```
$ gcc -c inet_net_pton.i -O3 -march=znver2 -wrapper valgrind
==3723094== Memcheck, a memory error detector
==3723094== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==3723094== Using Valgrind-3.23.0.GIT and LibVEX; rerun with -h for copyright
info
==3723094== Command: /usr/libexec/gcc/x86_64-pc-linux-gnu/14/cc1 -fpreprocessed
inet_net_pton.i -quiet -dumpbase inet_net_pton.i -dumpbase-ext .i -march=znver2
-O3 -o /tmp/cclQ7eCN.s
==3723094==
==3723094== Invalid read of size 8
==3723094==at 0x21DDFBE: UnknownInlinedFun (gimple-iterator.h:236)
==3723094==by 0x21DDFBE: UnknownInlinedFun (tree-vect-loop.cc:11804)
==3723094==by 0x21DDFBE: vect_transform_loop(_loop_vec_info*, gimple*)
(tree-vect-loop.cc:11969)
==3723094==by 0x24647FD: vect_transform_loops(hash_table*&, loop*, gimple*, function*) [clone .lto_priv.0]
(tree-vectorizer.cc:1006)
==3723094==by 0x23D9AB1: UnknownInlinedFun (tree-vectorizer.cc:1152)
==3723094==by 0x23D9AB1: try_vectorize_loop(hash_table*&, unsigned int*, loop*, function*)
(tree-vectorizer.cc:1182)
==3723094==by 0x2112028: (anonymous
namespace)::pass_vectorize::execute(function*) [clone .lto_priv.0]
(tree-vectorizer.cc:1298)
==3723094==by 0x1B18654: execute_one_pass(opt_pass*) (passes.cc:2646)
==3723094==by 0x1BDC0EB: execute_pass_list_1(opt_pass*) (passes.cc:2755)
==3723094==by 0x1BDC108: execute_pass_list_1(opt_pass*) (passes.cc:2756)
==3723094==by 0x1BDC108: execute_pass_list_1(opt_pass*) (passes.cc:2756)
==3723094==by 0x1BDBE18: execute_pass_list(function*, opt_pass*)
(passes.cc:2766)
==3723094==by 0x2295983: cgraph_node::expand() (cgraphunit.cc:1843)
==3723094==by 0x1B14F13: UnknownInlinedFun (cgraphunit.cc:2026)
==3723094==by 0x1B14F13: symbol_table::compile() (cgraphunit.cc:2400)
==3723094==by 0x22A7598: symbol_table::finalize_compilation_unit()
(cgraphunit.cc:2585)
==3723094==  Address 0x20 is not stack'd, malloc'd or (recently) free'd
==3723094==
during GIMPLE pass: vect
In file included from
/var/tmp/portage/dev-libs/libbsd-0.11.8/work/libbsd-0.11.8/src/inet_net_pton.c:28:
/usr/include/arpa/inet.h: In function ‘inet_net_pton’:
/usr/include/arpa/inet.h:89:12: internal compiler error: Segmentation fault
   89 | extern int inet_net_pton (int __af, const char *__cp,
  |^
0x1262376 crash_signal
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/toplev.cc:317
0x21ddfbe gsi_prev(gimple_stmt_iterator*)
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/gimple-iterator.h:236
0x21ddfbe move_early_exit_stmts
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/tree-vect-loop.cc:11804
0x21ddfbe vect_transform_loop(_loop_vec_info*, gimple*)
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/tree-vect-loop.cc:11969
0x24647fd vect_transform_loops
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/tree-vectorizer.cc:1006
0x23d9ab1 try_vectorize_loop_1
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/tree-vectorizer.cc:1152
0x23d9ab1 try_vectorize_loop
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/tree-vectorizer.cc:1182
0x2112028 execute
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/tree-vectorizer.cc:1298
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.
```

[Bug middle-end/113731] New: [14 regression] ICE when building libbsd

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

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

Bug ID: 113731
   Summary: [14 regression] ICE when building libbsd
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: tnfchris at gcc dot gnu.org
  Target Milestone: ---

Created attachment 57300
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57300=edit
inet_net_pton.i

[This is trunk at r14-8727-gf4998609908e49 with
https://inbox.sourceware.org/gcc-patches/vi1pr08mb5325c266e259acb3b572fad6ff...@vi1pr08mb5325.eurprd08.prod.outlook.com/
applied on top. Just filing as it's easier than giving lots of diff. logs on
IRC.]

I'll try reduce it now.

```
$ gcc -c inet_net_pton.i -O3 -march=znver2
during GIMPLE pass: vect
In file included from
/var/tmp/portage/dev-libs/libbsd-0.11.8/work/libbsd-0.11.8/src/inet_net_pton.c:28:
/usr/include/arpa/inet.h: In function ‘inet_net_pton’:
/usr/include/arpa/inet.h:89:12: internal compiler error: Segmentation fault
   89 | extern int inet_net_pton (int __af, const char *__cp,
  |^
0x562c4cda2376 crash_signal
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/toplev.cc:317
0x562c4dd1dfbe gsi_prev(gimple_stmt_iterator*)
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/gimple-iterator.h:236
0x562c4dd1dfbe move_early_exit_stmts
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/tree-vect-loop.cc:11804
0x562c4dd1dfbe vect_transform_loop(_loop_vec_info*, gimple*)
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/tree-vect-loop.cc:11969
0x562c4dfa47fd vect_transform_loops
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/tree-vectorizer.cc:1006
0x562c4df19ab1 try_vectorize_loop_1
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/tree-vectorizer.cc:1152
0x562c4df19ab1 try_vectorize_loop
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/tree-vectorizer.cc:1182
0x562c4dc52028 execute
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/tree-vectorizer.cc:1298
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.
```

[Bug modula2/113730] Unexpected handling of mixed-precision integer arithmetic

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

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

Gaius Mulley  changed:

   What|Removed |Added

 CC||gaius at gcc dot gnu.org

--- Comment #2 from Gaius Mulley  ---
Created attachment 57299
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57299=edit
Proposed fix

Here is the proposed patch.

[Bug modula2/113730] Unexpected handling of mixed-precision integer arithmetic

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

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

Gaius Mulley  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2024-02-02

--- Comment #1 from Gaius Mulley  ---
Confirmed.

[Bug modula2/113730] New: Unexpected handling of mixed-precision integer arithmetic

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

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

Bug ID: 113730
   Summary: Unexpected handling of mixed-precision integer
arithmetic
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: gaius at gcc dot gnu.org
  Target Milestone: ---

As reported on the gm2 mailing list the compiler incorrectly compiles mixed
precision arithmetic when an expression uses a ZType constant.   It would
appear that the expression is widened to a ZType which is then compatible with
another fixed sized type.

For example:

VAR
   c32: CARDINAL32 ;
   c64: CARDINAL64 ;
BEGIN
   c32 := 1 ;
   c64 := 2 ;
   c64 := c64 + c32 ;   (* Correctly: fails with incompatible expression.  *)
   c64 := c64 * 2 + c32 ;  (* Incorrectly passes!  *)

[Bug c/113727] csmith: differences from nothing to -O1

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

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

--- Comment #7 from Sam James  ---
Can you try produce a testcase without UB please?

[Bug c/113727] csmith: differences from nothing to -O1

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #6 from David Binderman  ---
As expected:

trunk.20210101 $ git bisect good 35b5bb475375dba4
6decda1a35be5764101987c210b5693a0d914e58 is the first bad commit
commit 6decda1a35be5764101987c210b5693a0d914e58
Author: Richard Biener 
Date:   Thu Oct 12 11:34:57 2023 +0200

tree-optimization/111779 - Handle some BIT_FIELD_REFs in SRA

[Bug target/113729] New: Missing APX NDD optimization

[hjl.tools at gmail dot com via Gcc-bugs]

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

Bug ID: 113729
   Summary: Missing APX NDD optimization
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com, hongyuw at gcc dot gnu.org
  Target Milestone: ---
Target: x86-64

APX spec has

---
Unlike the merge-upper behavior at a destination register of a typical x86
integer instruction when OSIZE
is 8b or 16b, the NDD register is always zero-uppered
---

But GCC 14 generates:

[hjl@gnu-tgl-3 pr113711]$ cat b.c
extern unsigned char b;

unsigned int
foo (void)
{
  return 200 + b;
}
[hjl@gnu-tgl-3 pr113711]$ make b.s
/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/ -mapxf
-O3 -S b.c
[hjl@gnu-tgl-3 pr113711]$ cat b.s
.file   "b.c"
.text
.p2align 4
.globl  foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
movzbl  b(%rip), %eax
addl$200, %eax
ret
.cfi_endproc
.LFE0:
.size   foo, .-foo
.ident  "GCC: (GNU) 14.0.1 20240202 (experimental)"
.section.note.G
[hjl@gnu-tgl-3 pr113711]$

addb$200, b(%rip), %al

should be generated.

[Bug libgcc/113604] runtime SIGFPE with _BitInt() division

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #13 from Jakub Jelinek  ---
Should be fixed now, thanks for the report.

[Bug c/113727] csmith: differences from nothing to -O1

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #5 from David Binderman  ---
(In reply to David Binderman from comment #4)
> Current range seems to be g:578aa2f80056175b .. g:328745607c5d403a,
> some 155 commits.

Current range seems to be g:0f40e59f193f96f1 to g:6decda1a35be5764.

Of those 5 commits, 3 are for RISC-V and look unrelated and these two:

g:6decda1a35be5764101987c210b5693a0d914e58
g:35b5bb475375dba4ea9101d6db13a6012c4e84ca

look likely candidates, both by Richard. Adding Richard for their opinion.

My first attempt at a reduction didn't work. 
I will have another go sometime over the weekend.

[Bug sanitizer/113728] libasan uses incorrect prctl prototype

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

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

--- Comment #1 from Andrew Pinski  ---
Can you file this upstream to LLVM too?

[Bug sanitizer/113728] New: libasan uses incorrect prctl prototype

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

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

Bug ID: 113728
   Summary: libasan uses incorrect prctl prototype
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fw at gcc dot gnu.org
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
  Target Milestone: ---
Target: powerpc64le-linux-gnu

The prctl function in glibc is variadic, but the internal prototype used by
libasan has a fixed argument list.

This causes crashes on powerpc64le-linux-gnu with current glibc because the
glibc implementation is variadic as well, it uses . Older glibc uses
an assembler implementation which does not bother with variadic arguments. For
variadic function calls, it's the caller's responsibility to set up the
parameter save area, but that does not happen if function prototype is
incorrect and non-variadic.

I'll try to get this worked around in glibc, but I couldn't get my ABI
regression fix applied the first time I posted it. The libasan library isn't
the first application impacted by the prctl ABI change.

[Bug d/104739] gdc.test/runnable/mangle.d etc. FAIL with Solaris as

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

--- Comment #6 from Iain Buclaw  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #5)
> > --- Comment #4 from Rainer Orth  ---
> > I wonder how to handle this: while DejaGnu has an ucn effective-target 
> > keyword,
> > the gdc.test testsuite doesn't use those at all.
> 
> What I think could be done is
> 
> * Add "//UTF-8 chars" comments to testmodule.d and ufcs.d; mangle.d
>   already has one.
> 
> * Make gdc-utils.exp (gdc-convert-test) check for those annotations,
>   adding
> 
>   // { dg-require-effective-target ucn}
> 
>   if found.
> 
> The new annotations would have to go upstream, I believe.  WDYT?

Can give it a go.

https://github.com/dlang/dmd/pull/16136

[Bug libgcc/113604] runtime SIGFPE with _BitInt() division

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

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

--- Comment #12 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r14-8761-gfbb569315a291d2d5b32ad0fdaf0c42da9f5e93b
Author: Jakub Jelinek 
Date:   Fri Feb 2 22:14:33 2024 +0100

libgcc: Fix up _BitInt division [PR113604]

The following testcase ends up with SIGFPE in __divmodbitint4.
The problem is a thinko in my attempt to implement Knuth's algorithm.

The algorithm does (where b is 65536, i.e. one larger than what
fits in their unsigned short word):
// Compute estimate qhat of q[j].
qhat = (un[j+n]*b + un[j+n-1])/vn[n-1];
rhat = (un[j+n]*b + un[j+n-1]) - qhat*vn[n-1];
  again:
if (qhat >= b || qhat*vn[n-2] > b*rhat + un[j+n-2])
{ qhat = qhat - 1;
  rhat = rhat + vn[n-1];
  if (rhat < b) goto again;
}
The problem is that it uses a double-word / word -> double-word
division (and modulo), while all we have is udiv_qrnnd unless
we'd want to do further library calls, and udiv_qrnnd is a
double-word / word -> word division and modulo.
Now, as the algorithm description says, it can produce at most
word bits + 1 bit quotient.  And I believe that actually the
highest qhat the original algorithm can produce is
(1 << word_bits) + 1.  The algorithm performs earlier canonicalization
where both the divisor and dividend are shifted left such that divisor
has msb set.  If it has msb set already before, no shifting occurs but
we start with added 0 limb, so in the first uv1:uv0 double-word uv1
is 0 and so we can't get too high qhat, if shifting occurs, the first
limb of dividend is shifted right by UWtype bits - shift count into
a new limb, so again in the first iteration in the uv1:uv0 double-word
uv1 doesn't have msb set while vv1 does and qhat has to fit into word.
In the following iterations, previous iteration should guarantee that
the previous quotient digit is correct.  Even if the divisor was the
maximal possible vv1:all_ones_in_all_lower_limbs, if the old
uv0:lower_limbs
would be larger or equal to the divisor, the previous quotient digit
would increase and another divisor would be subtracted, which I think
implies that in the next iteration in uv1:uv0 double-word uv1 <= vv1,
but uv0 could be up to all ones, e.g. in case of all lower limbs
of divisor being all ones and at least one dividend limb below uv0
being not all ones.  So, we can e.g. for 64-bit UWtype see
uv1:uv0 / vv1 0x8000UL:0xUL /
0x8000UL
or 0xUL:0xUL / 0xUL
In all these cases (when uv1 == vv1 && uv0 >= uv1), qhat is
0x10001UL, i.e. 2 more than fits into UWtype result,
if uv1 == vv1 && uv0 < uv1 it would be 0x1UL, i.e.
1 more than fits into UWtype result.
Because we only have udiv_qrnnd which can't deal with those too large
cases (SIGFPEs or otherwise invokes undefined behavior on those), I've
tried to handle the uv1 >= vv1 case separately, but for one thing
I thought it would be at most 1 larger than what fits, and for two
have actually subtracted vv1:vv1 from uv1:uv0 instead of subtracting
0:vv1 from uv1:uv0.
For the uv1 < vv1 case, the implementation already performs roughly
what the algorithm does.
Now, let's see what happens with the two possible extra cases in
the original algorithm.
If uv1 == vv1 && uv0 < uv1, qhat above would be b, so we take
if (qhat >= b, decrement qhat by 1 (it becomes b - 1), add
vn[n-1] aka vv1 to rhat and goto again if rhat < b (but because
qhat already fits we can goto to the again label in the uv1 < vv1
code).  rhat in this case is uv0 and rhat + vv1 can but doesn't
have to overflow, say for uv0 42UL and vv1 0x8000UL
it will not (and so we should goto again), while for uv0
0x8000UL and vv1 0x8001UL it will (and
we shouldn't goto again).
If uv1 == vv1 && uv0 >= uv1, qhat above would be b + 1, so we
take if (qhat >= b, decrement qhat by 1 (it becomes b), add
vn[n-1] aka vv1 to rhat. But because vv1 has msb set and
rhat in this case is uv0 - vv1, the rhat + vv1 addition
certainly doesn't overflow, because (uv0 - vv1) + vv1 is uv0,
so in the algorithm we goto again, again take if (qhat >= b and
decrement qhat so it finally becomes b - 1, and add vn[n-1]
aka vv1 to rhat again.  But this time I believe it must always
overflow, simply because we added (uv0 - vv1) + vv1 + vv1 and
vv1 has msb set, so already vv1 + vv1 must overflow.  And
because it overflowed, it will not goto again.
So, I believe the following patch implements this correctly, by
subtracting vv1 

[Bug c/113727] csmith: differences from nothing to -O1

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #4 from David Binderman  ---
(In reply to David Binderman from comment #3)
> (In reply to David Binderman from comment #2)
> > I have a bisection running too. I am trying out g:0f2e2080685e7509
> 
> That seems bad. Trying g:328745607c5d403a.

Current range seems to be g:578aa2f80056175b .. g:328745607c5d403a,
some 155 commits.

[Bug c/113727] csmith: differences from nothing to -O1

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #3 from David Binderman  ---
(In reply to David Binderman from comment #2)
> I have a bisection running too. I am trying out g:0f2e2080685e7509

That seems bad. Trying g:328745607c5d403a.

[Bug target/113711] APX instruction set and instructions longer than 15 bytes (assembly warning)

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #8 from H.J. Lu  ---
My branch is at

https://gitlab.com/x86-gcc/gcc/-/commits/users/hjl/pr113711/master

We need to add more tests:

1. All NDD instructions are 15 bytes or less.
2. Use "op imm, mem, reg" whenever possible.

[Bug target/113711] APX instruction set and instructions longer than 15 bytes (assembly warning)

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #7 from H.J. Lu  ---
(In reply to Hongyu Wang from comment #6)
> (In reply to H.J. Lu from comment #5)
> > (In reply to Hongyu Wang from comment #4)
> > > Previously I added 
> > > https://gcc.gnu.org/git/?p=gcc.git;a=commit;
> > > h=d564198f960a2f5994dde3f6b83d7a62021e49c3
> > > 
> > > to prohibit several *POFF constant usage in NDD add alternative. If 
> > > checking
> > > ADDR_SPACE_GENERIC can avoid the seg prefix usage, we can drop that 
> > > change?
> > 
> > Are there are any testcases for this change?
> > 
> 
> Cut and edit from gcc.dg\torture\tls\tls-test.c
> 
> #include 
> __thread int a = 255; 
> __thread int *b;
> int *volatile a_in_other_thread = (int *) 12345;
> 
> void *
> thread_func (void *arg)
> {
>   a_in_other_thread =  //Previously it will try to generate addq
> $a@tpoff, %fs:0, %rax 
>   a+=11144; //this was not fixed on trunk as UNSPEC_TPOFF is in mem operand
>   *((int *) arg) = a;
> 
>   return (void *)0;
> }

My patch seems to work.  But we need to add such tests to gcc.target/i386.

[Bug d/112408] [12/13/14 regression] d21 loops in getCpuInfo0B in Solaris/x86 kernel zone

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #11 from Iain Buclaw  ---
Mainline got this in r14-5678.

[Bug c/113727] csmith: differences from nothing to -O1

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from David Binderman  ---
I have a bisection running too. I am trying out g:0f2e2080685e7509

[Bug c/113727] csmith: differences from nothing to -O1

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #1 from Sam James  ---
With UBSAN, I get:
```
$ gcc-13 -ggdb3 -fsanitize=address,undefined /tmp/PR113727.c -o /tmp/PR113727
$ /tmp/PR113727
runData/keep/in.9954.c:416:134: runtime error: store to misaligned address
0x55a497188a23 for type 'uint32_t', which requires 4 byte alignment
0x55a497188a23: note: pointer points here
 00  a5 07 00 83 88 64 91 23  2a 00 28 bc 14 00 50 fe  ff 15 00 00 00 00 00 00 
00 00 00 00 00 00 00
  ^
#0 0x55a49716fda5 in func_46 runData/keep/in.9954.c:416
#1 0x55a49716c2fb in func_19 runData/keep/in.9954.c:352
#2 0x55a49716661e in func_1 runData/keep/in.9954.c:153
#3 0x55a49717dc21 in main runData/keep/in.9954.c:838
#4 0x7f9632452e69  (/usr/lib64/libc.so.6+0x25e69)
#5 0x7f9632452f1c in __libc_start_main (/usr/lib64/libc.so.6+0x25f1c)
#6 0x55a4971632e0 in _start (/tmp/PR113727+0x172e0)
```

[Bug middle-end/111156] [14 Regression] aarch64 aarch64/sve/mask_struct_store_4.c failures

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

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

--- Comment #11 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #10)
> Note I think gcc.target/aarch64/sve/mask_struct_load_3_run.c is the runtime
> failure I mentioned.

And gcc.dg/vect/vect-cond-reduc-in-order-2-signed-zero.c (when tested with
-march=armv9-a which I added to my testing recently).

[Bug middle-end/111156] [14 Regression] aarch64 aarch64/sve/mask_struct_store_4.c failures

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

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

--- Comment #10 from Andrew Pinski  ---
Note I think gcc.target/aarch64/sve/mask_struct_load_3_run.c is the runtime
failure I mentioned.

[Bug target/113711] APX instruction set and instructions longer than 15 bytes (assembly warning)

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

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

--- Comment #6 from Hongyu Wang  ---
(In reply to H.J. Lu from comment #5)
> (In reply to Hongyu Wang from comment #4)
> > Previously I added 
> > https://gcc.gnu.org/git/?p=gcc.git;a=commit;
> > h=d564198f960a2f5994dde3f6b83d7a62021e49c3
> > 
> > to prohibit several *POFF constant usage in NDD add alternative. If checking
> > ADDR_SPACE_GENERIC can avoid the seg prefix usage, we can drop that change?
> 
> Are there are any testcases for this change?
> 

Cut and edit from gcc.dg\torture\tls\tls-test.c

#include 
__thread int a = 255; 
__thread int *b;
int *volatile a_in_other_thread = (int *) 12345;

void *
thread_func (void *arg)
{
  a_in_other_thread =  //Previously it will try to generate addq $a@tpoff,
%fs:0, %rax 
  a+=11144; //this was not fixed on trunk as UNSPEC_TPOFF is in mem operand
  *((int *) arg) = a;

  return (void *)0;
}

[Bug c++/110084] [12/13/14 Regression] defaulted constexpr operator== causes crash

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

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

--- Comment #5 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:28f95c81382243fc4e6f1b22741d258f5fd7541f

commit r12-10129-g28f95c81382243fc4e6f1b22741d258f5fd7541f
Author: Jason Merrill 
Date:   Fri Feb 2 12:04:11 2024 -0500

c++: op== defaulted outside class [PR110084]

defaulted_late_check is for checks that need to happen after the class is
complete; we shouldn't call it sooner.

PR c++/110084

gcc/cp/ChangeLog:

* pt.cc (tsubst_function_decl): Only check a function defaulted
outside the class if the class is complete.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/spaceship-synth-neg3.C: Check error message.
* g++.dg/cpp2a/spaceship-eq16.C: New test.

(cherry picked from commit e17a122d417fc0d606bcb3a3705b93ee81745cab)

[Bug c/113727] New: csmith: differences from nothing to -O1

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 113727
   Summary: csmith: differences from nothing to -O1
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 57298
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57298=edit
C source code

The attached C code seems to produce different answers
between no optimisation flags and -O1:

foundBugs $ ../results/bin/gcc -w bug1002.c
foundBugs $ valgrind -q ./a.out 1 > 0
foundBugs $ ../results/bin/gcc -w -O1 bug1002.c
foundBugs $ valgrind -q ./a.out 1 > 1
foundBugs $ diff 0 1 
469,478c469,478
< ...checksum after hashing g_994.f3 : 5F99C263
< ...checksum after hashing g_994.f4 : 6E61EEE1
< ...checksum after hashing g_994.f5 : 8A4973F3
< ...checksum after hashing g_994.f6 : 1A47F5E1
< ...checksum after hashing g_994.f7 : CD2C240E
< ...checksum after hashing g_994.f8 : 7E61A9F
< ...checksum after hashing g_1368 : 74B15A31
< ...checksum after hashing g_1659 : 322B1FCB
< ...checksum after hashing g_1720 : 65F2763C
< checksum = 65F2763C
---
> ...checksum after hashing g_994.f3 : 3D4A5D24
> ...checksum after hashing g_994.f4 : 23E1696C
> ...checksum after hashing g_994.f5 : B115BFA4
> ...checksum after hashing g_994.f6 : E3A4BBDA
> ...checksum after hashing g_994.f7 : D44B3E01
> ...checksum after hashing g_994.f8 : 656901A2
> ...checksum after hashing g_1368 : 3B45689
> ...checksum after hashing g_1659 : EBA715C1
> ...checksum after hashing g_1720 : BDD5FC31
> checksum = BDD5FC31

I have a reduction running. 

The bug first seems to occur sometime between dates 20231001 and 20231119. 
Git hashes are g:5f3da480e7541a9c and eaeaad3fcac4d7a3.

[Bug target/113711] APX instruction set and instructions longer than 15 bytes (assembly warning)

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #5 from H.J. Lu  ---
(In reply to Hongyu Wang from comment #4)
> Previously I added 
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;
> h=d564198f960a2f5994dde3f6b83d7a62021e49c3
> 
> to prohibit several *POFF constant usage in NDD add alternative. If checking
> ADDR_SPACE_GENERIC can avoid the seg prefix usage, we can drop that change?

Are there are any testcases for this change?

> And I'd suggest to use j prefix for all APX related constraints like jf.

Will do.

[Bug target/113721] [14 Regression][OpenMP][nvptx] cuCtxSynchronize fail when calling 'free' in the target regsion

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

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

Tobias Burnus  changed:

   What|Removed |Added

 Resolution|--- |WORKSFORME
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Tobias Burnus  ---
Hmm, while I did see it on two systems, bisecting failed (always passing) and
now it passes with both the quicker build and full build.

I did not complete the bisecting as I did not see interesting commits in
between, hence, I cannot rule out that there was an in-between issue very
recently. Nor do I rule out some odd build issue.

Oddly, I had the very same issue on two system.

Anyway, close as WORKSFORME.

[Bug c++/110084] [12/13/14 Regression] defaulted constexpr operator== causes crash

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

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

--- Comment #4 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:3b5d906b2de6fd28dd329b70b014ab9784b5

commit r13-8273-g3b5d906b2de6fd28dd329b70b014ab9784b5
Author: Jason Merrill 
Date:   Fri Feb 2 12:04:11 2024 -0500

c++: op== defaulted outside class [PR110084]

defaulted_late_check is for checks that need to happen after the class is
complete; we shouldn't call it sooner.

PR c++/110084

gcc/cp/ChangeLog:

* pt.cc (tsubst_function_decl): Only check a function defaulted
outside the class if the class is complete.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/spaceship-synth-neg3.C: Check error message.
* g++.dg/cpp2a/spaceship-eq16.C: New test.

(cherry picked from commit e17a122d417fc0d606bcb3a3705b93ee81745cab)

[Bug c++/113710] [14 Regression] g++.dg/modules/hello-1 ICE: canonical types differ for identical types since r14-8710-g65b4cba9d6a9ff

[ewlu at rivosinc dot com via Gcc-bugs]

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

Edwin Lu  changed:

   What|Removed |Added

 CC||ewlu at rivosinc dot com,
   ||patrick at rivosinc dot com

--- Comment #2 from Edwin Lu  ---
Also on rv32/64 linux/newlib
https://github.com/patrick-rivos/gcc-postcommit-ci/issues/477

/disk-1/github/patrick-postcommit-1/_work/gcc-postcommit-ci/gcc-postcommit-ci/riscv-gnu-toolchain/gcc/gcc/testsuite/g++.dg/modules/hello-1_b.C:
In function 'int main()':
/disk-1/github/patrick-postcommit-1/_work/gcc-postcommit-ci/gcc-postcommit-ci/riscv-gnu-toolchain/gcc/gcc/testsuite/g++.dg/modules/hello-1_b.C:7:3:
internal compiler error: canonical types differ for identical types
'std::tuple_element<__i, std::tuple<_Elements ...> >' and
'std::tuple_element<__i, std::tuple<_Elements ...> >'
0xd67da3 comptypes(tree_node*, tree_node*, int)
../../../gcc/gcc/cp/typeck.cc:1710
0xd672c7 structural_comptypes
../../../gcc/gcc/cp/typeck.cc:1590
0xbad023 trees_in::is_matching_decl(tree_node*, tree_node*, bool)
../../../gcc/gcc/cp/module.cc:11362
0xbcae0b trees_in::decl_value()
../../../gcc/gcc/cp/module.cc:8341
0xbccbf7 trees_in::tree_node(bool)
../../../gcc/gcc/cp/module.cc:9403
0xbd58d3 module_state::read_cluster(unsigned int)
../../../gcc/gcc/cp/module.cc:15114
0xbd5ea3 module_state::load_section(unsigned int, binding_slot*)
../../../gcc/gcc/cp/module.cc:18491
0xbd5f6f module_state::lazy_load(unsigned int, binding_slot*)
../../../gcc/gcc/cp/module.cc:19166
0xbcd417 trees_in::tree_node(bool)
../../../gcc/gcc/cp/module.cc:9951
0xbd55cb module_state::read_cluster(unsigned int)
../../../gcc/gcc/cp/module.cc:15020
0xbd5ea3 module_state::load_section(unsigned int, binding_slot*)
../../../gcc/gcc/cp/module.cc:18491
0xbd5f6f module_state::lazy_load(unsigned int, binding_slot*)
../../../gcc/gcc/cp/module.cc:19166
0xbcd417 trees_in::tree_node(bool)
../../../gcc/gcc/cp/module.cc:9951
0xbd55cb module_state::read_cluster(unsigned int)
../../../gcc/gcc/cp/module.cc:15020
0xbd5ea3 module_state::load_section(unsigned int, binding_slot*)
../../../gcc/gcc/cp/module.cc:18491
0xbd60d7 lazy_load_binding(unsigned int, tree_node*, tree_node*, binding_slot*)
../../../gcc/gcc/cp/module.cc:19203
0xbed89f name_lookup::search_namespace_only(tree_node*)
../../../gcc/gcc/cp/name-lookup.cc:920
0xbef63f name_lookup::search_unqualified(tree_node*, cp_binding_level*)
../../../gcc/gcc/cp/name-lookup.cc:1143
0xbf81c7 lookup_name(tree_node*, LOOK_where, LOOK_want)
../../../gcc/gcc/cp/name-lookup.cc:7892
0xc0b0cb lookup_name(tree_node*, LOOK_want)
../../../gcc/gcc/cp/name-lookup.h:407
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.
compiler exited with status 1
FAIL: g++.dg/modules/hello-1_b.C -std=c++17 (internal compiler error: canonical
types differ for identical types 'std::tuple_element<__i, std::tuple<_Elements
...> >' and 'std::tuple_element<__i, std::tuple<_Elements ...> >')

[Bug lto/113712] [11/12/13/14 Regression] lto crash: when building 641.leela_s peek with Example-gcc-linux-x86.cfg (SPEC2017 1.1.9)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code,
   ||needs-bisection
  Known to fail||10.1.0, 12.1.0
  Known to work||8.1.0, 9.1.0
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |11.5
 Ever confirmed|0   |1
Summary|lto crash: when building|[11/12/13/14 Regression]
   |641.leela_s peek with   |lto crash: when building
   |Example-gcc-linux-x86.cfg   |641.leela_s peek with
   |(SPEC2017 1.1.9)|Example-gcc-linux-x86.cfg
   ||(SPEC2017 1.1.9)

--- Comment #16 from Andrew Pinski  ---
Confirmed.

[Bug lto/113712] lto crash: when building 641.leela_s peek with Example-gcc-linux-x86.cfg (SPEC2017 1.1.9)

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

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

--- Comment #15 from Andrew Pinski  ---
Created attachment 57297
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57297=edit
testcase

Compile with `-r -fprofile-generate  -O3 -flto -fno-use-linker-plugin 
-flto-partition=max`

[Bug c++/110084] [12/13/14 Regression] defaulted constexpr operator== causes crash

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

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

--- Comment #3 from GCC Commits  ---
The trunk branch has been updated by Jason Merrill :

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

commit r14-8759-ge17a122d417fc0d606bcb3a3705b93ee81745cab
Author: Jason Merrill 
Date:   Fri Feb 2 12:04:11 2024 -0500

c++: op== defaulted outside class [PR110084]

defaulted_late_check is for checks that need to happen after the class is
complete; we shouldn't call it sooner.

PR c++/110084

gcc/cp/ChangeLog:

* pt.cc (tsubst_function_decl): Only check a function defaulted
outside the class if the class is complete.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/spaceship-synth-neg3.C: Check error message.
* g++.dg/cpp2a/spaceship-eq16.C: New test.

[Bug target/113711] APX instruction set and instructions longer than 15 bytes (assembly warning)

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

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

--- Comment #4 from Hongyu Wang  ---
Previously I added 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d564198f960a2f5994dde3f6b83d7a62021e49c3

to prohibit several *POFF constant usage in NDD add alternative. If checking
ADDR_SPACE_GENERIC can avoid the seg prefix usage, we can drop that change?

And I'd suggest to use j prefix for all APX related constraints like jf.

[Bug target/113720] [14 Regression] internal compiler error: in extract_insn, at recog.cc:2812 targeting alpha-linux-gnu

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com

--- Comment #3 from Roger Sayle  ---
Sorry for the inconvenience.  alpha.md's define_expand that creates RTL that
contains a MULT with operands of different modes looks highly suspicious. 
Uros' patch to use the (relatively recently added) UMUL_HIGHPART rtx_code is
certainly a step in the right direction.

[Bug middle-end/113607] [14] RISC-V rv64gcv vector: Runtime mismatch at -O3

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

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

--- Comment #25 from Patrick O'Neill  ---
Confirmed fixed. Thanks!

[Bug target/59778] FAIL: gcc.dg/atomic/c11-atomic-exec-5.c

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by John David Anglin :

https://gcc.gnu.org/g:1c3cfb5a95dcc7f797ec2815690a6291878580c4

commit r14-8758-g1c3cfb5a95dcc7f797ec2815690a6291878580c4
Author: John David Anglin 
Date:   Fri Feb 2 18:05:06 2024 +

hppa: Implement TARGET_ATOMIC_ASSIGN_EXPAND_FENV

This change implements __builtin_get_fpsr() and __builtin_set_fpsr(x)
to get and set the floating-point status register.  They are used to
implement pa_atomic_assign_expand_fenv().

2024-02-02  John David Anglin  

gcc/ChangeLog:

PR target/59778
* config/pa/pa.cc (enum pa_builtins): Add PA_BUILTIN_GET_FPSR
and PA_BUILTIN_SET_FPSR builtins.
* (pa_builtins_icode): Declare.
* (def_builtin, pa_fpu_init_builtins): New.
* (pa_init_builtins): Initialize FPU builtins.
* (pa_builtin_decl, pa_expand_builtin_1): New.
* (pa_expand_builtin): Handle PA_BUILTIN_GET_FPSR and
PA_BUILTIN_SET_FPSR builtins.
* (pa_atomic_assign_expand_fenv): New.
* config/pa/pa.md (UNSPECV_GET_FPSR, UNSPECV_SET_FPSR): New
UNSPECV constants.
(get_fpsr, put_fpsr): New expanders.
(get_fpsr_32, get_fpsr_64, set_fpsr_32, set_fpsr_64): New
insn patterns.

[Bug c++/99599] [11/12/13 Regression] Concepts requirement falsely reporting cyclic dependency, breaks tag_invoke pattern

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

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

Patrick Palka  changed:

   What|Removed |Added

Summary|[11/12/13/14 Regression]|[11/12/13 Regression]
   |Concepts requirement|Concepts requirement
   |falsely reporting cyclic|falsely reporting cyclic
   |dependency, breaks  |dependency, breaks
   |tag_invoke pattern  |tag_invoke pattern

--- Comment #19 from Patrick Palka  ---
The unwanted constraint recursion should be fixed in GCC 14 for the most common
cases.

[Bug c++/112769] [11/12/13/14 Regression] ICE on valid code related to requires-expression

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

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

Patrick Palka  changed:

   What|Removed |Added

   See Also|https://gcc.gnu.org/bugzill |
   |a/show_bug.cgi?id=111222|
 CC||stevenxia990430 at gmail dot 
com

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

[Bug c++/111222] ICE on basic_string_view and alias templates with missing template argument

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

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

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
   See Also|https://gcc.gnu.org/bugzill |
   |a/show_bug.cgi?id=112769|
 Status|ASSIGNED|RESOLVED

--- Comment #4 from Patrick Palka  ---
The underlying bug is the same as PR112769 which is a regression, so let's call
this one a dup.

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

[Bug c++/112769] [11/12/13/14 Regression] ICE on valid code related to requires-expression

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 CC||ppalka at gcc dot gnu.org
Summary|ICE on valid code related   |[11/12/13/14 Regression]
   |to requires-expression  |ICE on valid code related
   ||to requires-expression
 Ever confirmed|0   |1
   Last reconfirmed||2024-02-02
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=101181
   Target Milestone|--- |11.5
  Known to work||11.1.0
  Known to fail||11.4.0, 12.3.0, 13.2.0,
   ||14.0

--- Comment #2 from Patrick Palka  ---
Confirmed, we started ICEing with a non-checking compiler after r12- /
r11-8734.

[Bug target/113697] RISC-V: Redundant vsetvl insn in function

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

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

--- Comment #1 from GCC Commits  ---
The master branch has been updated by Pan Li :

https://gcc.gnu.org/g:922e4599e6261644d336b009b6901cd221ec95fd

commit r14-8757-g922e4599e6261644d336b009b6901cd221ec95fd
Author: Juzhe-Zhong 
Date:   Fri Feb 2 09:56:59 2024 +0800

RISC-V: Expand VLMAX scalar move in reduction

This patch fixes the following:

vsetvli a5,a1,e32,m1,tu,ma
sllia4,a5,2
sub a1,a1,a5
vle32.v v2,0(a0)
add a0,a0,a4
vadd.vv v1,v2,v1
bne a1,zero,.L3
vsetivlizero,1,e32,m1,ta,ma
vmv.s.x v2,zero
vsetvli a5,zero,e32,m1,ta,ma  ---> Redundant vsetvl.
vredsum.vs  v1,v1,v2
vmv.x.s a0,v1
ret

VSETVL PASS is able to fuse avl = 1 of scalar move and VLMAX avl of
reduction.

However, this following RTL blocks the fusion in dependence analysis in
VSETVL PASS:

(insn 49 24 50 5 (set (reg:RVVM1SI 98 v2 [148])
(if_then_else:RVVM1SI (unspec:RVVMF32BI [
(const_vector:RVVMF32BI [
(const_int 1 [0x1])
repeat [
(const_int 0 [0])
]
])
(const_int 1 [0x1])
(const_int 2 [0x2]) repeated x2
(const_int 0 [0])
(reg:SI 66 vl)
(reg:SI 67 vtype)
] UNSPEC_VPREDICATE)
(const_vector:RVVM1SI repeat [
(const_int 0 [0])
])
(unspec:RVVM1SI [
(reg:DI 0 zero)
] UNSPEC_VUNDEF))) 3813 {*pred_broadcastrvvm1si_zero}
 (nil))
(insn 50 49 51 5 (set (reg:DI 15 a5 [151])  > 
It set a5, blocks the following VLMAX into the scalar move above.
(unspec:DI [
(const_int 32 [0x20])
] UNSPEC_VLMAX)) 2566 {vlmax_avldi}
 (expr_list:REG_EQUIV (unspec:DI [
(const_int 32 [0x20])
] UNSPEC_VLMAX)
(nil)))
(insn 51 50 52 5 (set (reg:RVVM1SI 97 v1 [150])
(unspec:RVVM1SI [
(unspec:RVVMF32BI [
(const_vector:RVVMF32BI repeat [
(const_int 1 [0x1])
])
(reg:DI 15 a5 [151])
(const_int 2 [0x2])
(const_int 1 [0x1])
(reg:SI 66 vl)
(reg:SI 67 vtype)
] UNSPEC_VPREDICATE)
(unspec:RVVM1SI [
(reg:RVVM1SI 97 v1 [orig:134 vect_result_14.6 ]
[134])
(reg:RVVM1SI 98 v2 [148])
] UNSPEC_REDUC_SUM)
(unspec:RVVM1SI [
(reg:DI 0 zero)
] UNSPEC_VUNDEF)
] UNSPEC_REDUC)) 17541 {pred_redsumrvvm1si}
 (expr_list:REG_DEAD (reg:RVVM1SI 98 v2 [148])
(expr_list:REG_DEAD (reg:SI 66 vl)
(expr_list:REG_DEAD (reg:DI 15 a5 [151])
(expr_list:REG_DEAD (reg:DI 0 zero)
(nil))

Such situation can only happen on auto-vectorization, never happen on
intrinsic codes.
Since the reduction is passed VLMAX AVL, it should be more natural to pass
VLMAX to the scalar move which initial the value of the reduction.

After this patch:

vsetvli a5,a1,e32,m1,tu,ma
sllia4,a5,2
sub a1,a1,a5
vle32.v v2,0(a0)
add a0,a0,a4
vadd.vv v1,v2,v1
bne a1,zero,.L3
vsetvli a5,zero,e32,m1,ta,ma
vmv.s.x v2,zero
vredsum.vs  v1,v1,v2
vmv.x.s a0,v1
ret

Tested on both RV32/RV64 no regression.

PR target/113697

gcc/ChangeLog:

* config/riscv/riscv-v.cc (expand_reduction): Pass VLMAX avl to
scalar move.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/pr113697.c: New test.

[Bug middle-end/113722] [14 Regression] Constant folding of __builtin_bswap128 is broken since r14-1455

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

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 57296
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57296=edit
gcc14-pr113722.patch

Untested fix.

[Bug middle-end/113726] sanitizer reports signed overflow but not underflow for constant folding case

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|sanitizer   |middle-end
Summary|sanitizer reports signed|sanitizer reports signed
   |overflow but not underflow  |overflow but not underflow
   ||for constant folding case
  Known to fail||14.0, 5.1.0
   Last reconfirmed||2024-02-02
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Confirmed. It is constant folding ...

Reduced testcase:
```

int main() {
long result = (-__LONG_MAX__ - 1);
result -= 1l; // sanitizer reports this 
result = (-__LONG_MAX__ - 1) - 1; // But NOT this
__builtin_printf("%ld\n", result);
}

```

[Bug sanitizer/113726] New: sanitizer reports signed overflow but not underflow

[jetrull at sbcglobal dot net via Gcc-bugs]

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

Bug ID: 113726
   Summary: sanitizer reports signed overflow but not underflow
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jetrull at sbcglobal 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
  Target Milestone: ---

This code produces both a warning and a sanitizer failure:

long result = std::numeric_limits::max() + 1l;

This code produces only a compiler warning:

long result = std::numeric_limits::min() - 1l;

The Clang sanitizer flags both operations.

This seems to be true for several versions, including 11.4 (my laptop) and
trunk.

https://godbolt.org/z/9nf3hhWsM

[Bug lto/113712] lto crash: when building 641.leela_s peek with Example-gcc-linux-x86.cfg (SPEC2017 1.1.9)

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

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

--- Comment #14 from Andrew Pinski  ---
I should have a fully reduced testcase by the end of the day. I have it done to
one file with the added option of `-flto-partition=max` .

[Bug middle-end/113722] [14 Regression] Constant folding of __builtin_bswap128 is broken since r14-1455

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[14 Regression] Constant|[14 Regression] Constant
   |folding of  |folding of
   |__builtin_bswap128 is   |__builtin_bswap128 is
   |broken  |broken since r14-1455
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Priority|P3  |P1

--- Comment #3 from Jakub Jelinek  ---
Anyway, at -O0
int
main ()
{
  unsigned __int128 a = __builtin_bswap128 ((unsigned __int128) 2);
  unsigned __int128 b = 2;
  unsigned __int128 c = __builtin_bswap128 (b);
  if (a != c)
__builtin_abort ();
}
regressed with r14-1455-g0ede6b5ad77c4791a513ab312b9e278dafc2bff9
I'll have a look.

[Bug middle-end/113722] [14 Regression] Constant folding of __builtin_bswap128 is broken

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
The #c0 testcase is broken, res >> 64 has still __uint128_t type, so you
shouldn't pass it to %ld format specifier.

[Bug tree-optimization/113725] New: ICE during GIMPLE pass: cunroll

[shaohua.li at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 113725
   Summary: ICE during GIMPLE pass: cunroll
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shaohua.li at inf dot ethz.ch
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

gcc at -O3 crashed on the test case.

Bisected to r14-8683-gb84f8a5e0a7

Compiler explorer: https://godbolt.org/z/qsPvvPx6q

%cat reduced.c
char a;
int b, c, d, e;
int f() {}
void g() {
  for (;;) {
b = 1;
for (; b >= 0; b--) {
  int *h = 
  for (; d; d++)
a && (*h = 8);
  c = e;
}
for (; f() <= 2;)
  ;
  }
}
int main() {}
%
%gcc -O3 reduced.c
during GIMPLE pass: cunroll
reduced.c: In function ‘g’:
reduced.c:4:6: internal compiler error: Segmentation fault
4 | void g() {
  |  ^
0x7f07fa09208f ???
   
/build/glibc-wuryBv/glibc-2.31/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x7f07fa073082 __libc_start_main
../csu/libc-start.c:308
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.
%

[Bug c++/110084] [12/13/14 Regression] defaulted constexpr operator== causes crash

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug libstdc++/111948] subrange modifies a const size object

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

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

Bug 112439 Summary: [13/14 Regression] Modification of a member overlapping 
with a [[no_unique_address]] member in the constructor is incorrectly rejected 
in constant evaluation since r13-160-g967cdbe6629653
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112439

   What|Removed |Added

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

[Bug c++/113710] [14 Regression] g++.dg/modules/hello-1 ICE: canonical types differ for identical types since r14-8710-g65b4cba9d6a9ff

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

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

--- Comment #1 from seurer at gcc dot gnu.org ---
Also on powerpc64le:

g:65b4cba9d6a9ffe9b4d4bdff90727a7064cc0e3b, r14-8710-g65b4cba9d6a9ff
make  -k check-gcc-c++ RUNTESTFLAGS="modules.exp=hello*"
FAIL: g++.dg/modules/hello-1_b.C -std=c++17 (internal compiler error: canonical
types differ for identical types 'std::tuple_element<__i, std::tuple<_Elements
...> >' and 'std::tuple_element<__i, std::tuple<_Elements ...> >')
FAIL: g++.dg/modules/hello-1_b.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/hello-1_b.C -std=c++2a (internal compiler error: canonical
types differ for identical types 'std::tuple_element<__i, std::tuple<_Elements
...> >' and 'std::tuple_element<__i, std::tuple<_Elements ...> >')
FAIL: g++.dg/modules/hello-1_b.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/hello-1_b.C -std=c++2b (internal compiler error: canonical
types differ for identical types 'std::tuple_element<__i, std::tuple<_Elements
...> >' and 'std::tuple_element<__i, std::tuple<_Elements ...> >')
FAIL: g++.dg/modules/hello-1_b.C -std=c++2b (test for excess errors)
# of expected passes6
# of unexpected failures6
# of unresolved testcases   6

[Bug c++/112439] [13/14 Regression] Modification of a member overlapping with a [[no_unique_address]] member in the constructor is incorrectly rejected in constant evaluation since r13-160-g967cdbe662

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  ---
Fixed for 13.3/14.

[Bug middle-end/113722] [14 Regression] Constant folding of __builtin_bswap128 is broken

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|regression  |middle-end
 Ever confirmed|0   |1
   Last reconfirmed||2024-02-02
Summary|Folding of  |[14 Regression] Constant
   |__builtin_bswap128 doesn't  |folding of
   |work anymore|__builtin_bswap128 is
   ||broken
   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |14.0

--- Comment #1 from Andrew Pinski  ---
Simplified testcase:
```
#define constant 2
int main() {
__uint128_t res = __builtin_bswap128 ((__uint128_t)constant);
__uint128_t t = constant;
__uint128_t res1 = __builtin_bswap128 (t);
if (res != res1)
  __builtin_abort();
}
```

[Bug c++/113638] [13/14 Regression] Array bounds of variable templates are not correctly deduced from initializers since GCC13 inside a decltype/sizeof

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #9 from Jason Merrill  ---
Fixed for 13.3/14.

[Bug c++/112439] [13/14 Regression] Modification of a member overlapping with a [[no_unique_address]] member in the constructor is incorrectly rejected in constant evaluation since r13-160-g967cdbe662

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

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

--- Comment #3 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:8bae2c531d2ea8f7872ed41f273b6fabaa6a9965

commit r13-8271-g8bae2c531d2ea8f7872ed41f273b6fabaa6a9965
Author: Jason Merrill 
Date:   Thu Feb 1 17:23:53 2024 -0500

c++: no_unique_address and constexpr [PR112439]

Here, because we don't build a CONSTRUCTOR for an empty base, we were
wrongly marking the Foo CONSTRUCTOR as complete after initializing the
Empty
member.  Fixed by checking empty_base here as well.

PR c++/112439

gcc/cp/ChangeLog:

* constexpr.cc (cxx_eval_store_expression): Check empty_base
before marking a CONSTRUCTOR readonly.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/no_unique_address15.C: New test.

(cherry picked from commit f4998609908e4926fc095ce97cb84b187294fd1d)

[Bug c++/113638] [13/14 Regression] Array bounds of variable templates are not correctly deduced from initializers since GCC13 inside a decltype/sizeof

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

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

--- Comment #8 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:69f04177fed0de2c5f121b7607b7b59d3ba93451

commit r13-8272-g69f04177fed0de2c5f121b7607b7b59d3ba93451
Author: Jason Merrill 
Date:   Thu Feb 1 16:54:39 2024 -0500

c++: variable template array of unknown bound [PR113638]

When we added variable templates, we didn't extend the
VAR_HAD_UNKNOWN_BOUND
handling for class template static data members to handle them as well.

PR c++/113638

gcc/cp/ChangeLog:

* cp-tree.h: Adjust comment.
* pt.cc (instantiate_template): Set VAR_HAD_UNKNOWN_BOUND for
variable template.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/var-templ-array1.C: New test.

(cherry picked from commit 0b786ff38ab398087820d91241e030a28c451df9)

[Bug libstdc++/107371] __adaptor::_RangeAdaptor rejects the explicit move constructor case

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

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

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
   Target Milestone|--- |14.0

--- Comment #2 from Patrick Palka  ---
This is incidentally fixed by r14-7218-gc48bedd1806722.

[Bug d/104739] gdc.test/runnable/mangle.d etc. FAIL with Solaris as

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #4 from Rainer Orth  ---
> I wonder how to handle this: while DejaGnu has an ucn effective-target 
> keyword,
> the gdc.test testsuite doesn't use those at all.

What I think could be done is

* Add "//UTF-8 chars" comments to testmodule.d and ufcs.d; mangle.d
  already has one.

* Make gdc-utils.exp (gdc-convert-test) check for those annotations,
  adding

  // { dg-require-effective-target ucn}

  if found.

The new annotations would have to go upstream, I believe.  WDYT?

[Bug target/113723] -freorder-blocks-and-partition emits bogus asm directives on aarch64

[redbeard0531 at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Mathias Stearn  ---
As a workaround sticking [[gnu::optimize("no-reorder-blocks-and-partition")]]
 on each function that triggers this seems to work. But that is obviously not a
scalable solution.

[Bug middle-end/113724] New: [14 Regression][OpenMP] ICE (segfault) when mapping a struct in omp_gather_mapping_groups_1

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

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

Bug ID: 113724
   Summary: [14 Regression][OpenMP] ICE (segfault) when mapping a
struct in omp_gather_mapping_groups_1
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, openmp
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

Created attachment 57295
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57295=edit
compile with: gcc -fopenmp target_struct_map.4

The attached testcase from the OpenMP examples document now ICEs in the
new omp_gather_mapping_groups_1 function.

* * *

target_struct_map.4.c: In function ‘main’:
target_struct_map.4.c:46:11: internal compiler error: Segmentation fault
   46 |   #pragma omp target data map(S1.p[:N],S1.p,S1.a,S1.b)
  |   ^~~
0x1045382 crash_signal
/home/tburnus/repos/gcc/gcc/toplev.cc:317
0x7fc380e4251f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0xcf8263 tree_check(tree_node*, char const*, int, char const*, tree_code)
/home/tburnus/repos/gcc/gcc/tree.h:3611
0xcf8263 omp_gather_mapping_groups_1
/home/tburnus/repos/gcc/gcc/gimplify.cc:9583
0xd0bc32 omp_gather_mapping_groups
/home/tburnus/repos/gcc/gcc/gimplify.cc:9610
0xd0bc32 gimplify_adjust_omp_clauses
/home/tburnus/repos/gcc/gcc/gimplify.cc:13733
0xd23d27 gimplify_omp_workshare

[Bug target/113723] New: -freorder-blocks-and-partition emits bogus asm directives on aarch64

[redbeard0531 at gmail dot com via Gcc-bugs]

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

Bug ID: 113723
   Summary: -freorder-blocks-and-partition emits bogus asm
directives on aarch64
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redbeard0531 at gmail dot com
  Target Milestone: ---

It tries to subtract labels across the function split which the assembler
rejects. At the very least it does this when generating a switch jump table,
but there may be other cases.

https://www.godbolt.org/z/Ynh1zzY4a

Repro with -O3 -freorder-blocks-and-partition:


[[gnu::cold]]void cold();

template void f();
#define GENERATE_CASE case __COUNTER__: f<__COUNTER__>(); break 

void test(int i) {
switch(i) {
case 1: cold(); break;
GENERATE_CASE;
GENERATE_CASE;
GENERATE_CASE;
GENERATE_CASE;
GENERATE_CASE;
GENERATE_CASE;
GENERATE_CASE;
GENERATE_CASE;
GENERATE_CASE;
GENERATE_CASE;
}
}

test(int):
cmp w0, 18
bls .L17
.L1:
ret
.L17:
adrpx1, .L4
add x1, x1, :lo12:.L4
ldrbw1, [x1,w0,uxtw]
adr x0, .Lrtx4
add x1, x0, w1, sxtb #2
br  x1
.Lrtx4:
.L4:
.byte   (.L14 - .Lrtx4) / 4
.byte   (.L13 - .Lrtx4) / 4 //  THIS IS THE BAD ONE
.byte   (.L12 - .Lrtx4) / 4

...

test(int) [clone .cold]:
.L13:
b   cold()


/tmp/cck05x4u.s: Assembler messages:
/tmp/cck05x4u.s:48: Error: invalid operands (.text.unlikely and .text sections)
for `-'
Compiler returned: 1

I've repro'd on 11,12, and trunk.

[Bug tree-optimization/113706] c-c++-common/pr103798-2.c FAILs as C++

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

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

Rainer Orth  changed:

   What|Removed |Added

   Last reconfirmed||2024-02-02
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2024-Februar
   ||y/644842.html
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #5 from Rainer Orth  ---
Patch posted.

[Bug regression/113722] New: Folding of __builtin_bswap128 doesn't work anymore

[bouanto at zoho dot com via Gcc-bugs]

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

Bug ID: 113722
   Summary: Folding of __builtin_bswap128 doesn't work anymore
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bouanto at zoho dot com
  Target Milestone: ---

With the following code:

#include 

int main(int argc, char* argv[]) {
__uint128_t res = __builtin_bswap128 (2);
printf("Value: %ld\n", res >> 64);
res = __builtin_bswap128 (argc + 1);
printf("Value: %ld\n", res >> 64);
}

it gives the following output in gcc 13.2.1:

Value: 144115188075855872
Value: 144115188075855872

while it gives the following output in the master branch, commit
2c27aa8d75113f404bf9cd39364611af386d9719:

Value: 0
Value: 144115188075855872

So it seems to be a regression in the folding of wide_int::bswap.

[Bug target/113721] New: [14 Regression][OpenMP][nvptx] cuCtxSynchronize fail when calling 'free' in the target regsion

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

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

Bug ID: 113721
   Summary: [14 Regression][OpenMP][nvptx] cuCtxSynchronize fail
when calling 'free' in the target regsion
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: openmp, wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: tschwinge at gcc dot gnu.org
  Target Milestone: ---
Target: nvptx

Created attachment 57294
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57294=edit
Compile with -fopenmp + run with nvptx offloading

I have not fully debugged this, but OpenMP Example Document example
  devices/sources/target_ptr_map.1.c
fails now.

It works if one comments the 'free(ptr3)' line but with it in, it fails with:

libgomp: cuCtxSynchronize error: unspecified launch failure (perhaps abort was
called)
libgomp: cuMemFree_v2 error: unspecified launch failure

* * *

* Fails with today's GCC where nvptx is configured with --with-arch=sm_80.
* Fails also with -foffload=nvptx-none=-march=sm_30

* Works with AMD GPU offload

* Works using the GCC 13 distro compiler
* Works using the GCC 13 distro compiler and
  LD_LIBRARY_PATH set to the mainline compile.

[Bug c++/113713] constexpr function values (incorrectly?) depend on optimization level

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
Looks like this changed with r11-4230-g46fdced6a9f936

commit 46fdced6a9f936ae4d5b42347d7d87f69875683a
Author: Patrick Palka 
Date:   Thu Oct 22 07:33:58 2020 -0400

c++: constexpr evaluation and bare EMPTY_CLASS_EXPR [PR96575]

but only when A is an empty class.

Using struct A { int i; };, the test has compiled with -O0 since
r7-4458-gf065303fcf9aa2.

[Bug tree-optimization/113716] Missed optimization: (2/a)*b*(!b) => 0

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #4 from Andrew Macleod  ---
(In reply to Jakub Jelinek from comment #3)
> Maybe ranger could figure out that at least one of the multiplication
> operands is zero in this case, because the second one is non-zero only if
> the first one is zero?

  _2 = b_6(D) == 0;
  _3 = (int) _2;
  _4 = _3 * b_6(D);

well, its kind of sort of predicate based.  I mean, the information is
calculable if one thought it was worth it. ie at the multiply, we know _3 is
[0, 1]   and we know b_6 is VARYING
because there are only 2 ranges in _3, you could calculate using GORI "if _3 is
[0,0], what is b_6?" (~[0, 0]) and "if _3 is [1,1], whats b_6?" [0,0]. do the 2
multiplies and union the results.. you'd get [0,0]


We might need a slight API tweak to be able to ask that.   we have fold_stmt
routines for the folding, but I dont think I have added any "what if" hooks to
GORI yet.

[Bug target/113720] [14 Regression] internal compiler error: in extract_insn, at recog.cc:2812 targeting alpha-linux-gnu

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

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

Joseph S. Myers  changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu.org,
   ||sayle at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |14.0
   Last reconfirmed||2024-02-02
 Ever confirmed|0   |1

--- Comment #2 from Joseph S. Myers  ---
Introduced by:

commit 2f14c0dbb789852947cb58fdf7d3162413f053fa
Author: Roger Sayle 
Date:   Thu Feb 1 06:10:42 2024 +

PR target/113560: Enhance is_widening_mult_rhs_p.

[Bug libgomp/113448] libgomp.c/alloc-pinned-1.c etc. XPASS

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

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

--- Comment #3 from seurer at gcc dot gnu.org ---
-1 and -2 fail on powerpc64 LE

make  -k check-target-libgomp RUNTESTFLAGS="c.exp=libgomp.c/alloc-pinned-*"
FAIL: libgomp.c/alloc-pinned-1.c execution test
FAIL: libgomp.c/alloc-pinned-2.c execution test


-3 and -4 fail on powerpc64 BE

make  -k check-target-libgomp RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'
c.exp=libgomp.c/alloc-pinned-*"
FAIL: libgomp.c/alloc-pinned-3.c execution test
FAIL: libgomp.c/alloc-pinned-4.c execution test

[Bug target/113711] APX instruction set and instructions longer than 15 bytes (assembly warning)

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

  Attachment #57288|0   |1
is obsolete||

--- Comment #3 from H.J. Lu  ---
Created attachment 57293
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57293=edit
An updated patch

[Bug libstdc++/113335] [C++23] Implement LWG3617 function/packaged_task deduction guides and deducing this

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

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

--- Comment #1 from GCC Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:6f75149488b74ae696788b8761d6fcfa754a0af7

commit r14-8752-g6f75149488b74ae696788b8761d6fcfa754a0af7
Author: Jonathan Wakely 
Date:   Fri Feb 2 10:03:12 2024 +

libstdc++: Make std::function deduction guide support explicit object
functions [PR113335]

This makes the deduction guides for std::function and std::packaged_task
work for explicit object member functions, i.e. "deducing this", as per
LWG 3617.

libstdc++-v3/ChangeLog:

PR libstdc++/113335
* include/bits/std_function.h (__function_guide_helper): Add
partial specialization for explicit object member functions, as
per LWG 3617.
* testsuite/20_util/function/cons/deduction_c++23.cc: Check
explicit object member functions.
* testsuite/30_threads/packaged_task/cons/deduction_c++23.cc:
Likewise.

[Bug libstdc++/106749] Implement C++23 library features

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

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

Bug 113335 Summary: [C++23] Implement LWG3617 function/packaged_task deduction 
guides and deducing this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113335

   What|Removed |Added

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