[Bug target/112801] [14] RISC-V vector: failure to mask top bits during type conversion

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code

--- Comment #2 from Richard Biener  ---
I think wrong-code should be high-priority ;)

[Bug tree-optimization/112793] [14 regression] ICE when building stellarium (internal compiler error: in vect_schedule_slp_node, at tree-vect-slp.cc:9062)

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |14.0

--- Comment #12 from Richard Biener  ---
Confirmed, mine.  We're scheduling the same SLP node twice from different SLP
instances.  We're supposed to merge SLP instances which share nodes though,
but we're only doing that for internal defs.  We need to either duplicate
the constant/external nodes in different subgraphs or merge subgraphs
with common constants/externals as well.

I'll think about it.

This isn't new in GCC 14, it should be a problem since GCC 11.

[Bug tree-optimization/112793] [14 regression] ICE when building stellarium (internal compiler error: in vect_schedule_slp_node, at tree-vect-slp.cc:9062)

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

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

--- Comment #11 from Sam James  ---
Created attachment 56747
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56747=edit
another cvised testcase

[Bug tree-optimization/112788] [14 regression] ICEs in fold_range, at range-op.cc:206 after r14-5972-gea19de921b01a6

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||amacleod at redhat dot com
   Keywords||ice-checking

[Bug target/112787] Codegen regression of large GCC vector extensions when enabling SVE

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

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

--- Comment #2 from Richard Biener  ---
I think you should make sure to not use VLA vectors in lowering since lowering
doesn't really support using those (much similar to BB SLP).

[Bug testsuite/112786] [14 Regression] gcc.dg/tree-ssa/scev-3.c scev-4.c and scev-5.c XPASSing on most ilp32 targets

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

--- Comment #2 from Richard Biener  ---
Note they XPASS on the 13 branch as well IIRC.

[Bug target/112753] [14 Regression] unrecognizable insn building glibc for s390x

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Andreas Krebbel :

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

commit r14-6040-g8a2e428591dc97d573cf5c1789c84c8a3884b364
Author: Juergen Christ 
Date:   Fri Dec 1 08:01:36 2023 +0100

s390x: Fix s390_md_asm_adjust handling of long doubles [PR112753]

Commit 466b100e5fee808d77598e0f294654deec281150 introduced a bug in
s390_md_asm_adjust if vector extensions are not available.  Fix the
control flow of this function to not adjust long double values.

gcc/ChangeLog:

PR target/112753
* config/s390/s390.cc (s390_md_asm_adjust): Return after dealing
with the outputs, if no further processing of long doubles is
required.

gcc/testsuite/ChangeLog:

* gcc.target/s390/pr112753.c: New test.

[Bug c/108476] Please turn -Wreturn-type on by default for C

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

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #4 from Florian Weimer  ---
For GCC 14, we have -Wreturn-mismatch turned on by default, as an error. This
diagnoses cases of extra or missing expressions in return statements. Together
with the other warnings-as-errors changes, this seems to cover the request in
the description.

[Bug target/112725] [14 Regression] powerpc64le-linux-gnu: 'c-c++-common/builtin-classify-type-1.c:113:3: error: AltiVec argument passed to unprototyped function'

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Fixed on both powerpc and s390.

[Bug target/112725] [14 Regression] powerpc64le-linux-gnu: 'c-c++-common/builtin-classify-type-1.c:113:3: error: AltiVec argument passed to unprototyped function'

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

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

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

https://gcc.gnu.org/g:28944a016bb5eef9a99691b3c55b124882375180

commit r14-6039-g28944a016bb5eef9a99691b3c55b124882375180
Author: Jakub Jelinek 
Date:   Fri Dec 1 08:11:34 2023 +0100

s390: Fix builtin-classify-type-1.c on s390 too [PR112725]

s390 suffers from the same issue with __builtin_classify_type vector
arguments, the target hook diagnoses those because it thinks a vector
is passed to an unprototyped function, but in this case it is a
type-generic
builtin which can support vector types just fine, by folding into the
appropriate constant.

This fixes
-FAIL: c-c++-common/builtin-classify-type-1.c  -Wc++-compat  (test for
excess errors)
-UNRESOLVED: c-c++-common/builtin-classify-type-1.c  -Wc++-compat 
compilation failed to produce executable
on s390x-linux.

2023-12-01  Jakub Jelinek  

PR target/112725
* config/s390/s390.cc (s390_invalid_arg_for_unprototyped_fn):
Return
NULL for __builtin_classify_type calls with vector arguments.

[Bug c/96284] Outdated C features should be made errors with newer standards

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

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

Bug 91093 Summary: Error on implicit int by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91093

   What|Removed |Added

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

[Bug c/91093] Error on implicit int by default

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

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

Florian Weimer  changed:

   What|Removed |Added

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

--- Comment #5 from Florian Weimer  ---
Fixed for GCC 14.

[Bug c/91092] Error on implicit function declarations by default

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

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

Florian Weimer  changed:

   What|Removed |Added

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

--- Comment #23 from Florian Weimer  ---
Fixed for GCC 14.

[Bug c/96284] Outdated C features should be made errors with newer standards

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

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

Bug 106416 Summary: -Wint-conversion should be an error, not a pedwarn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106416

   What|Removed |Added

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

[Bug c/106416] -Wint-conversion should be an error, not a pedwarn

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

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

Florian Weimer  changed:

   What|Removed |Added

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

--- Comment #7 from Florian Weimer  ---
Fixed for GCC 14.

[Bug c/96284] Outdated C features should be made errors with newer standards

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

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

--- Comment #12 from GCC Commits  ---
The master branch has been updated by Florian Weimer :

https://gcc.gnu.org/g:4ecfa6c4a9df19b364cbdf6d9de5f0b98c22bd8f

commit r14-6036-g4ecfa6c4a9df19b364cbdf6d9de5f0b98c22bd8f
Author: Florian Weimer 
Date:   Fri Dec 1 08:10:13 2023 +0100

c: Turn -Wreturn-mismatch into a permerror

gcc/

* doc/invoke.texi (Warning Options): Document that
-Wreturn-mismatch is a permerror in C99 and later.

gcc/c/

PR c/96284
* c-typeck.cc (c_finish_return): Use permerrors
for OPT_Wreturn_mismatch diagnostics.

gcc/testsuite/

* gcc.dg/permerror-default.c (return_mismatch_1)
(return_mismatch_2): Expect new permerror.
* gcc.dg/permerror-gnu89-nopermissive.c (return_mismatch_1):
Likewise.
* gcc.dg/permerror-system.c: Likewise.
* gcc.dg/20030906-1.c: Compile with -fpermissive due to
expected -Wreturn-mismatch error.
* gcc.dg/20030906-1a.c: New test.  Copied from
gcc.dg/20030906-1.c.  Expect the error.
* gcc.dg/20030906-2.c: Compile with -fpermissive due to
expected -Wreturn-mismatch error.
* gcc.dg/20030906-2a.c: New test.  Copied from
gcc.dg/20030906-2.c.  Expect the error.
* gcc.dg/Wreturn-mismatch-1.c: Compile with -fpermissive due to
expected -Wreturn-mismatch error.
* gcc.dg/Wreturn-mismatch-1a.c: New test.  Copied from
gcc.dg/Wreturn-mismatch-1.c.  Expect the error.
* gcc.dg/Wreturn-mismatch-2.c: Compile with -fpermissive due to
expected -Wreturn-mismatch error.
* gcc.dg/Wreturn-mismatch-2a.c: New test.  Copied from
gcc.dg/Wreturn-mismatch-2.c.  Expect the error.
* gcc.dg/diagnostic-range-bad-return.c: Compile with
-fpermissive due to expected -Wreturn-mismatch error.
* gcc.dg/diagnostic-range-bad-return-2.c: New test.
Copied from gcc.dg/diagnostic-range-bad-return.c.  Expect the
error.
* gcc.dg/pr105635-2.c: Expect -Wreturn-mismatch error.
* gcc.dg/pr23075.c: Build with -fpermissive due to
expected -Wreturn-mismatch error.
* gcc.dg/pr23075-2.c: New test.  Copied from gcc.dg/pr23075.c.
Expect the error.
* gcc.dg/pr29521.c: Compile with -fpermissive due to expected
-Wreturn-mismatch error.
* gcc.dg/pr29521-a.c: New test. Copied from gcc.dg/pr29521.c.
Expect error.
* gcc.dg/pr67730.c: Compile with -fpermissive due to expected
-Wreturn-mismatch error.
* gcc.dg/pr67730-a.c: New test.  Copied from
gcc.dg/pr67730-a.c.  Expect error.
* gcc.target/powerpc/conditional-return.c: Compile with
-fpermissive due to expected -Wreturn-mismatch error.

[Bug other/44209] [meta-bug] Some warnings are not linked to diagnostics options

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

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

--- Comment #12 from GCC Commits  ---
The master branch has been updated by Florian Weimer :

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

commit r14-6038-gff9efa3fc48baa1dee7ed376c25ecfcfbc28d35c
Author: Florian Weimer 
Date:   Fri Dec 1 08:10:13 2023 +0100

c: Add new -Wdeclaration-missing-parameter-type permerror

This used to be a warning, enabled by default, without its own option.

A subsequent change could improve diagnostics and provide spelling
hints for declarations like âvoid function (int32t);â.

gcc/c-family/

* c.opt (Wdeclaration-missing-parameter-type): New.

gcc/c/ChangeLog:

PR other/44209
* c-decl.cc (grokparms): Issue permerror for
OPT_Wdeclaration_missing_parameter_type instead of a pedwarn.

gcc/ChangeLog:

* doc/invoke.texi (Warning Options): Document
-Wdeclaration-missing-parameter-type.

gcc/testsuite/ChangeLog:

* gcc.dg/permerror-default.c (missing_parameter_type):
Expect error.
* gcc.dg/permerror-fpermissive.c (missing_parameter_type):
Expect -Wdeclaration-missing-parameter-type warning.
* gcc.dg/permerror-gnu89-nopermissive.c (missing_parameter_type):
Expect -Wdeclaration-missing-parameter-type error.
* gcc.dg/permerror-gnu89-pedantic.c (missing_parameter_type):
Likewise.
* gcc.dg/permerror-gnu89.c (missing_parameter_type):
Expect -Wdeclaration-missing-parameter-type warning.
* gcc.dg/permerror-noerror.c: Add
-Wno-error=declaration-missing-parameter-type to build flags.
(missing_parameter_type): Expect
-Wdeclaration-missing-parameter-type warning.
* gcc.dg/permerror-nowarning.c: Build with
-Wno-declaration-missing-parameter-type.  Remove previously
expected warning.
* gcc.dg/permerror-fpermissive-nowarning.c: Likewise.
* gcc.dg/permerror-pedantic.c (missing_parameter_type):
Expect -Wdeclaration-missing-parameter-type error.
* gcc.dg/permerror-system.c (missing_parameter_type):
Likewise.

[Bug c/96284] Outdated C features should be made errors with newer standards

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

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

--- Comment #13 from GCC Commits  ---
The master branch has been updated by Florian Weimer :

https://gcc.gnu.org/g:9715c545d33b3a32ddc1ae817ba9356ade1fb9df

commit r14-6037-g9715c545d33b3a32ddc1ae817ba9356ade1fb9df
Author: Florian Weimer 
Date:   Fri Dec 1 08:10:13 2023 +0100

c: Turn -Wincompatible-pointer-types into a permerror

The change to build_conditional_expr drops the downgrade
from a pedwarn to warning for builtins for C99 and later
language dialects.  It remains a warning in C89 mode (not
a permerror), as the -std=gnu89 -fno-permissive test shows.

gcc/

* doc/invoke.texi (Warning Options): Document changes.

gcc/c/

PR c/96284
* c-typeck.cc (build_conditional_expr): Upgrade most pointer
type mismatches to a permerror.
(convert_for_assignment): Use permerror_opt and
permerror_init for OPT_Wincompatible_pointer_types warnings.

gcc/testsuite/

* gcc.dg/permerror-default.c (incompatible_pointer_types):
Expect new permerror.
* gcc.dg/permerror-gnu89-nopermissive.c
(incompatible_pointer_types): Likewise.
* gcc.dg/permerror-pedantic.c (incompatible_pointer_types):
Likewise.
* gcc.dg/permerror-system.c: Likewise.
* gcc.dg/Wincompatible-pointer-types-2.c: Compile with
-fpermissive due to expected errors.
* gcc.dg/Wincompatible-pointer-types-5.c: New test.  Copied
from gcc.dg/Wincompatible-pointer-types-2.c.  Expect errors.
* gcc.dg/anon-struct-11.c: Compile with -fpermissive
due to expected errors.
* gcc.dg/anon-struct-11a.c: New test.  Copied from
gcc.dg/anon-struct-11.c.  Expect errors.
* gcc.dg/anon-struct-13.c: Compile with -fpermissive
due to expected errors.
* gcc.dg/anon-struct-13a.c: New test.  Copied from
gcc.dg/anon-struct-13.c.  Expect errors.
* gcc.dg/builtin-arith-overflow-4.c: Compile with -fpermissive
due to expected errors.
* gcc.dg/builtin-arith-overflow-4a.c: New test.  Copied from
gcc.dg/builtin-arith-overflow-4.c.  Expect errors.
* gcc.dg/c23-qual-4.c: Expect -Wincompatible-pointer-types errors.
* gcc.dg/dfp/composite-type.c: Compile with -fpermissive
due to expected errors.
* gcc.dg/dfp/composite-type-2.c: New test.  Copied from
gcc.dg/dfp/composite-type.c.  Expect errors.
* gcc.dg/diag-aka-1.c: Compile with -fpermissive
due to expected errors.
* gcc.dg/diag-aka-1a.c: New test.  Copied from
gcc.dg/diag-aka-1a.c.  Expect errors.
* gcc.dg/enum-compat-1.c: Compile with -fpermissive
due to expected errors.
* gcc.dg/enum-compat-2.c: New test.  Copied from
gcc.dg/enum-compat-1.c.  Expect errors.
* gcc.dg/func-ptr-conv-1.c: Compile with -fpermissive
due to expected errors.
* gcc.dg/func-ptr-conv-2.c: New test.  Copied from
gcc.dg/func-ptr-conv-1.c.  Expect errors.
* gcc.dg/init-bad-7.c: Compile with -fpermissive
due to expected errors.
* gcc.dg/init-bad-7a.c: New test.  Copied from gcc.dg/init-bad-7.c.
Expect errors.
* gcc.dg/noncompile/incomplete-3.c (foo): Expect
-Wincompatible-pointer-types error.
* gcc.dg/param-type-mismatch-2.c (test8): Likewise.
* gcc.dg/pointer-array-atomic.c: Compile with -fpermissive
due to expected errors.
* gcc.dg/pointer-array-atomic-2.c: New test.  Copied from
gcc.dg/pointer-array-atomic.c.  Expect errors.
* gcc.dg/pointer-array-quals-1.c (test): Expect
-Wincompatible-pointer-types errors.
* gcc.dg/transparent-union-1.c: Compile with -fpermissive
due to expected errors.
* gcc.dg/transparent-union-1a.c: New test.  Copied from
gcc.dg/transparent-union-1.c.  Expect errors.
* gcc.target/aarch64/acle/memtag_2a.c
(test_memtag_warning_return_qualifier): Expect additional
errors.
* gcc.target/aarch64/sve/acle/general-c/load_2.c (f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_1.c
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_2.c
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_3.c
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_4.c
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_5.c
(f1): Likewise.
*

[Bug c/91093] Error on implicit int by default

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Florian Weimer :

https://gcc.gnu.org/g:4ee2aca7ca098cc6e622a9a41e63224af37e6532

commit r14-6034-g4ee2aca7ca098cc6e622a9a41e63224af37e6532
Author: Florian Weimer 
Date:   Fri Dec 1 08:10:13 2023 +0100

c: Turn -Wimplicit-int into a permerror

Most of these new permerrors are currently not diagnosed in system
headers.

gcc/

PR c/91093
PR c/96284
* doc/invoke.texi (Warning Options): Document changes.

gcc/c/

* c-decl.cc (warn_defaults_to): Remove.
(grok_declarator, start_function): Call permerror_opt
instead of warn_defaults_to.
(store_parm_decls_oldstyle): Call permerror_opt for
OPT_Wimplicit_int.

gcc/testsuite/

* gcc.dg/permerror-default.c (implicit_int_1, implicit_int_2)
(implicit_int_3, implicit_int_4): Expect new permerror.
* gcc.dg/permerror-system.c: Expect a single new permerror.
* gcc.dg/Wimplicit-int-1.c: Compile with -fpermissive due to
expected warning.
* gcc.dg/Wimplicit-int-4.c: Likewise.
* gcc.dg/Wimplicit-int-1a.c: New test.  Copied from
gcc.dg/Wimplicit-int-1.c, but expect errors.
* gcc.dg/Wimplicit-int-4a.c: New test.  Copied from
gcc.dg/Wimplicit-int-4.c, but expect errors.
* gcc.dg/gnu23-attr-syntax-2.c: Compile with -fpermissive
due to expected implicit-int error.
* gcc.dg/gnu23-attr-syntax-3.c: New test.  Copied from
gcc.dg/gnu23-attr-syntax-2.c, but expect an error.
* gcc.dg/pr105635.c: Build with -fpermissive due to implicit
int.
* gcc.dg/pr105635-2.c: New test.  Copied from
gcc.dg/pr105635.c.  Expect implicit int error.
* gcc.dg/noncompile/pr79758.c: Build with -fpermissive due to
implicit int.
* gcc.dg/noncompile/pr79758-2.c: New test.  Copied from
gcc.dg/noncompile/pr79758.c.  Expect implicit int error.

[Bug c/96284] Outdated C features should be made errors with newer standards

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

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

--- Comment #10 from GCC Commits  ---
The master branch has been updated by Florian Weimer :

https://gcc.gnu.org/g:55e94561e97ed0bce4774aa1c6b5d5d82209a379

commit r14-6033-g55e94561e97ed0bce4774aa1c6b5d5d82209a379
Author: Florian Weimer 
Date:   Fri Dec 1 08:10:13 2023 +0100

c: Turn -Wimplicit-function-declaration into a permerror

In the future, it may make sense to avoid cascading errors from
the implicit declaration, especially its assumed int return type.
This change here only changes the kind of the diagnostic, not
its wording or consequences.

gcc/

* doc/invoke.texi (Warning Options): Document changes.

gcc/c/

PR c/91092
PR c/96284
* c-decl.cc (implicit_decl_permerror): Rename from
implicit_decl_warning.  Call permerror_opt instead of
pedwarn and warning_at.
(implicitly_declare): Adjust callers.

gcc/testsuite/

* gcc.dg/permerror-default.c (implicit_function_declaration):
Expect the new permerror.
* gcc.dg/permerror-system.c: Likewise.
* c-c++-common/spellcheck-reserved.c (test, test_2): Expect
error instead of warning.
(f): Expect error instead of warning.
* gcc.dg/Wimplicit-function-declaration-c99.c: Compile with
-fpermissive due to expected warning.
* gcc.dg/Wimplicit-function-declaration-c99-2.c: New test.
Copied from gcc.dg/Wimplicit-function-declaration-c99.c.
Expect error.
* gcc.dg/missing-header-fixit-1.c: Compile with -fpermissive
due to expect error.
* gcc.dg/missing-header-fixit-1a.c: New test.  Copied from
gcc.dg/missing-header-fixit-1.c, but expect error.
* gcc.dg/missing-header-fixit-2.c: Compile with -fpermissive
due to expect error.
* gcc.dg/missing-header-fixit-2a.c: New test.  Copied from
gcc.dg/missing-header-fixit-2.c, but expect error.
* gcc.dg/missing-header-fixit-4.c: Compile with -fpermissive
due to expect error.
* gcc.dg/missing-header-fixit-4a.c: New test.  Copied from
gcc.dg/missing-header-fixit-4.c, but expect error.
* gcc.dg/missing-header-fixit-5.c: Compile with -fpermissive
due to expect error.
* gcc.dg/missing-header-fixit-5a.c: New test.  Copied from
gcc.dg/missing-header-fixit-5.c, but expect error.
* gcc.dg/pr61852.c: Expect implicit-function-declaration
error instead of warning.
* gcc.dg/spellcheck-identifiers-2.c: Compile with
-fpermissive due to expected warnings.
* gcc.dg/spellcheck-identifiers-2a.c: New test.  Copied
from gcc.dg/spellcheck-identifiers-2a.c.  Expect errors.
* gcc.dg/spellcheck-identifiers-3.c: Compile with
-fpermissive due to expected warnings.
* gcc.dg/spellcheck-identifiers-3a.c: New test.  Copied
from gcc.dg/spellcheck-identifiers-2a.c.  Expect errors.
* gcc.dg/spellcheck-identifiers-4.c: Compile with
-fpermissive due to expected warnings.
* gcc.dg/spellcheck-identifiers-4a.c: New test.  Copied
from gcc.dg/spellcheck-identifiers-2a.c.  Expect error.
* gcc.dg/spellcheck-identifiers.c: Compile with
-fpermissive due to expected warnings.
* gcc.dg/spellcheck-identifiers-1a.c: New test.  Copied
from gcc.dg/spellcheck-identifiers.c.  Expect errors.
* gcc.target/aarch64/sve/acle/general-c/ld1sh_gather_1.c (f1):
Expect error.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_index_1.c:
(f1): Likewise.
*
gcc.target/aarch64/sve/acle/general-c/load_ext_gather_index_restricted_1.c:
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_1.c:
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_2.c:
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_3.c:
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_4.c:
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_5.c:
(f1): Likewise.
*
gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_restricted_1.c:
(f1): Likewise.
*
gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_restricted_2.c:
(f1): Likewise.
*
gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_restricted_3.c:
(f1): Likewise.
*
gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_restricted_4.c:
  

[Bug c/96284] Outdated C features should be made errors with newer standards

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

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

--- Comment #11 from GCC Commits  ---
The master branch has been updated by Florian Weimer :

https://gcc.gnu.org/g:4ee2aca7ca098cc6e622a9a41e63224af37e6532

commit r14-6034-g4ee2aca7ca098cc6e622a9a41e63224af37e6532
Author: Florian Weimer 
Date:   Fri Dec 1 08:10:13 2023 +0100

c: Turn -Wimplicit-int into a permerror

Most of these new permerrors are currently not diagnosed in system
headers.

gcc/

PR c/91093
PR c/96284
* doc/invoke.texi (Warning Options): Document changes.

gcc/c/

* c-decl.cc (warn_defaults_to): Remove.
(grok_declarator, start_function): Call permerror_opt
instead of warn_defaults_to.
(store_parm_decls_oldstyle): Call permerror_opt for
OPT_Wimplicit_int.

gcc/testsuite/

* gcc.dg/permerror-default.c (implicit_int_1, implicit_int_2)
(implicit_int_3, implicit_int_4): Expect new permerror.
* gcc.dg/permerror-system.c: Expect a single new permerror.
* gcc.dg/Wimplicit-int-1.c: Compile with -fpermissive due to
expected warning.
* gcc.dg/Wimplicit-int-4.c: Likewise.
* gcc.dg/Wimplicit-int-1a.c: New test.  Copied from
gcc.dg/Wimplicit-int-1.c, but expect errors.
* gcc.dg/Wimplicit-int-4a.c: New test.  Copied from
gcc.dg/Wimplicit-int-4.c, but expect errors.
* gcc.dg/gnu23-attr-syntax-2.c: Compile with -fpermissive
due to expected implicit-int error.
* gcc.dg/gnu23-attr-syntax-3.c: New test.  Copied from
gcc.dg/gnu23-attr-syntax-2.c, but expect an error.
* gcc.dg/pr105635.c: Build with -fpermissive due to implicit
int.
* gcc.dg/pr105635-2.c: New test.  Copied from
gcc.dg/pr105635.c.  Expect implicit int error.
* gcc.dg/noncompile/pr79758.c: Build with -fpermissive due to
implicit int.
* gcc.dg/noncompile/pr79758-2.c: New test.  Copied from
gcc.dg/noncompile/pr79758.c.  Expect implicit int error.

[Bug c/91092] Error on implicit function declarations by default

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

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

--- Comment #22 from GCC Commits  ---
The master branch has been updated by Florian Weimer :

https://gcc.gnu.org/g:55e94561e97ed0bce4774aa1c6b5d5d82209a379

commit r14-6033-g55e94561e97ed0bce4774aa1c6b5d5d82209a379
Author: Florian Weimer 
Date:   Fri Dec 1 08:10:13 2023 +0100

c: Turn -Wimplicit-function-declaration into a permerror

In the future, it may make sense to avoid cascading errors from
the implicit declaration, especially its assumed int return type.
This change here only changes the kind of the diagnostic, not
its wording or consequences.

gcc/

* doc/invoke.texi (Warning Options): Document changes.

gcc/c/

PR c/91092
PR c/96284
* c-decl.cc (implicit_decl_permerror): Rename from
implicit_decl_warning.  Call permerror_opt instead of
pedwarn and warning_at.
(implicitly_declare): Adjust callers.

gcc/testsuite/

* gcc.dg/permerror-default.c (implicit_function_declaration):
Expect the new permerror.
* gcc.dg/permerror-system.c: Likewise.
* c-c++-common/spellcheck-reserved.c (test, test_2): Expect
error instead of warning.
(f): Expect error instead of warning.
* gcc.dg/Wimplicit-function-declaration-c99.c: Compile with
-fpermissive due to expected warning.
* gcc.dg/Wimplicit-function-declaration-c99-2.c: New test.
Copied from gcc.dg/Wimplicit-function-declaration-c99.c.
Expect error.
* gcc.dg/missing-header-fixit-1.c: Compile with -fpermissive
due to expect error.
* gcc.dg/missing-header-fixit-1a.c: New test.  Copied from
gcc.dg/missing-header-fixit-1.c, but expect error.
* gcc.dg/missing-header-fixit-2.c: Compile with -fpermissive
due to expect error.
* gcc.dg/missing-header-fixit-2a.c: New test.  Copied from
gcc.dg/missing-header-fixit-2.c, but expect error.
* gcc.dg/missing-header-fixit-4.c: Compile with -fpermissive
due to expect error.
* gcc.dg/missing-header-fixit-4a.c: New test.  Copied from
gcc.dg/missing-header-fixit-4.c, but expect error.
* gcc.dg/missing-header-fixit-5.c: Compile with -fpermissive
due to expect error.
* gcc.dg/missing-header-fixit-5a.c: New test.  Copied from
gcc.dg/missing-header-fixit-5.c, but expect error.
* gcc.dg/pr61852.c: Expect implicit-function-declaration
error instead of warning.
* gcc.dg/spellcheck-identifiers-2.c: Compile with
-fpermissive due to expected warnings.
* gcc.dg/spellcheck-identifiers-2a.c: New test.  Copied
from gcc.dg/spellcheck-identifiers-2a.c.  Expect errors.
* gcc.dg/spellcheck-identifiers-3.c: Compile with
-fpermissive due to expected warnings.
* gcc.dg/spellcheck-identifiers-3a.c: New test.  Copied
from gcc.dg/spellcheck-identifiers-2a.c.  Expect errors.
* gcc.dg/spellcheck-identifiers-4.c: Compile with
-fpermissive due to expected warnings.
* gcc.dg/spellcheck-identifiers-4a.c: New test.  Copied
from gcc.dg/spellcheck-identifiers-2a.c.  Expect error.
* gcc.dg/spellcheck-identifiers.c: Compile with
-fpermissive due to expected warnings.
* gcc.dg/spellcheck-identifiers-1a.c: New test.  Copied
from gcc.dg/spellcheck-identifiers.c.  Expect errors.
* gcc.target/aarch64/sve/acle/general-c/ld1sh_gather_1.c (f1):
Expect error.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_index_1.c:
(f1): Likewise.
*
gcc.target/aarch64/sve/acle/general-c/load_ext_gather_index_restricted_1.c:
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_1.c:
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_2.c:
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_3.c:
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_4.c:
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_5.c:
(f1): Likewise.
*
gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_restricted_1.c:
(f1): Likewise.
*
gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_restricted_2.c:
(f1): Likewise.
*
gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_restricted_3.c:
(f1): Likewise.
*
gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_restricted_4.c:
  

[Bug c/96284] Outdated C features should be made errors with newer standards

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

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

--- Comment #9 from GCC Commits  ---
The master branch has been updated by Florian Weimer :

https://gcc.gnu.org/g:2c3db94d9fd07681f8806dae93d555779ff4dfb1

commit r14-6032-g2c3db94d9fd07681f8806dae93d555779ff4dfb1
Author: Florian Weimer 
Date:   Fri Dec 1 08:10:12 2023 +0100

c: Turn int-conversion warnings into permerrors

gcc/

* doc/invoke.texi (Warning Options): Document changes.

gcc/c/

PR c/96284
PR c/106416
* c-typeck.cc (build_conditional_expr): Use permerror_opt for
pointer/integer type mismatches, based on -Wint-conversion.
(pedwarn_permerror_init, permerror_init): New function.
(pedwarn_init): Call pedwarn_permerror_init.
(convert_for_assignment): Use permerror_opt and
permerror_init for -Wint-conversion warnings.

gcc/testsuite/

* gcc.dg/permerror-default.c (int_conversion_1)
(int_conversion_2): Expect the new permerrors.
* gcc.dg/permerror-gnu89-nopermissive.c (int_conversion_1)
(int_conversion_2): Likewise.
* gcc.dg/permerror-system.c: Likewise.
* c-c++-common/pr77624-1.c (foo, bar): Expect
error instead of warning.
* gcc.dg/Wint-conversion-2.c: Compile with -fpermissive due
to expected int-conversion warning.
* gcc.dg/Wint-conversion-3.c: Likewise.
* gcc.dg/Wint-conversion-4.c: New test.  Based on
gcc.dg/Wint-conversion-3.c.  Expect int-conversion errors.
* gcc.dg/assign-warn-1.c: Compile with -fpermissive.
* gcc.dg/assign-warn-4.c: New file.  Extracted from
assign-warn1.c.  Expect int-conversion errors.
* gcc.dg/diagnostic-types-1.c: Compile with -fpermissive.
* gcc.dg/diagnostic-types-2.c: New file.  Extracted from
gcc.dg/diagnostic-types-1.c.  Expect some errors instead of
warnings.
* gcc.dg/gomp/pr35738.c: Compile with -fpermissive due to
expected int-conversion error.
* gcc.dg/gomp/pr35738-2.c: New test.  Based on
gcc.dg/gomp/pr35738.c.  Expect int-converison errors.
* gcc.dg/init-excess-3.c: Expect int-converison errors.
* gcc.dg/overflow-warn-1.c: Likewise.
* gcc.dg/overflow-warn-3.c: Likewise.
* gcc.dg/param-type-mismatch.c: Compile with -fpermissive.
* gcc.dg/param-type-mismatch-2.c: New test.  Copied from
gcc.dg/param-type-mismatch.c.  Expect errors.
* gcc.dg/pr61162-2.c: Compile with -fpermissive.
* gcc.dg/pr61162-3.c: New test. Extracted from
gcc.dg/pr61162-2.c.  Expect int-conversion errors.
* gcc.dg/spec-barrier-3.c: Use -fpermissive due to expected
int-conversion error.
* gcc.dg/spec-barrier-3a.c: New test.  Based on
gcc.dg/spec-barrier-3.c.  Expect int-conversion errors.
* gcc.target/aarch64/acle/memtag_2.c: Use -fpermissive due to
expected
int-conversion error.
* gcc.target/aarch64/acle/memtag_2a.c: New test.  Copied from
gcc.target/aarch64/acle/memtag_2.c.  Expect error.
* gcc.target/aarch64/sve/acle/general-c/load_3.c (f1): Expect
error.
* gcc.target/aarch64/sve/acle/general-c/store_2.c (f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/store_scatter_index_1.c
(f1): Likewise.
*
gcc.target/aarch64/sve/acle/general-c/store_scatter_index_restricted_1.c
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/store_scatter_offset_2.c
(f1): Likewise.
*
gcc.target/aarch64/sve/acle/general-c/store_scatter_offset_restricted_1.c
(f1): Likewise.

[Bug c/106416] -Wint-conversion should be an error, not a pedwarn

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

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by Florian Weimer :

https://gcc.gnu.org/g:2c3db94d9fd07681f8806dae93d555779ff4dfb1

commit r14-6032-g2c3db94d9fd07681f8806dae93d555779ff4dfb1
Author: Florian Weimer 
Date:   Fri Dec 1 08:10:12 2023 +0100

c: Turn int-conversion warnings into permerrors

gcc/

* doc/invoke.texi (Warning Options): Document changes.

gcc/c/

PR c/96284
PR c/106416
* c-typeck.cc (build_conditional_expr): Use permerror_opt for
pointer/integer type mismatches, based on -Wint-conversion.
(pedwarn_permerror_init, permerror_init): New function.
(pedwarn_init): Call pedwarn_permerror_init.
(convert_for_assignment): Use permerror_opt and
permerror_init for -Wint-conversion warnings.

gcc/testsuite/

* gcc.dg/permerror-default.c (int_conversion_1)
(int_conversion_2): Expect the new permerrors.
* gcc.dg/permerror-gnu89-nopermissive.c (int_conversion_1)
(int_conversion_2): Likewise.
* gcc.dg/permerror-system.c: Likewise.
* c-c++-common/pr77624-1.c (foo, bar): Expect
error instead of warning.
* gcc.dg/Wint-conversion-2.c: Compile with -fpermissive due
to expected int-conversion warning.
* gcc.dg/Wint-conversion-3.c: Likewise.
* gcc.dg/Wint-conversion-4.c: New test.  Based on
gcc.dg/Wint-conversion-3.c.  Expect int-conversion errors.
* gcc.dg/assign-warn-1.c: Compile with -fpermissive.
* gcc.dg/assign-warn-4.c: New file.  Extracted from
assign-warn1.c.  Expect int-conversion errors.
* gcc.dg/diagnostic-types-1.c: Compile with -fpermissive.
* gcc.dg/diagnostic-types-2.c: New file.  Extracted from
gcc.dg/diagnostic-types-1.c.  Expect some errors instead of
warnings.
* gcc.dg/gomp/pr35738.c: Compile with -fpermissive due to
expected int-conversion error.
* gcc.dg/gomp/pr35738-2.c: New test.  Based on
gcc.dg/gomp/pr35738.c.  Expect int-converison errors.
* gcc.dg/init-excess-3.c: Expect int-converison errors.
* gcc.dg/overflow-warn-1.c: Likewise.
* gcc.dg/overflow-warn-3.c: Likewise.
* gcc.dg/param-type-mismatch.c: Compile with -fpermissive.
* gcc.dg/param-type-mismatch-2.c: New test.  Copied from
gcc.dg/param-type-mismatch.c.  Expect errors.
* gcc.dg/pr61162-2.c: Compile with -fpermissive.
* gcc.dg/pr61162-3.c: New test. Extracted from
gcc.dg/pr61162-2.c.  Expect int-conversion errors.
* gcc.dg/spec-barrier-3.c: Use -fpermissive due to expected
int-conversion error.
* gcc.dg/spec-barrier-3a.c: New test.  Based on
gcc.dg/spec-barrier-3.c.  Expect int-conversion errors.
* gcc.target/aarch64/acle/memtag_2.c: Use -fpermissive due to
expected
int-conversion error.
* gcc.target/aarch64/acle/memtag_2a.c: New test.  Copied from
gcc.target/aarch64/acle/memtag_2.c.  Expect error.
* gcc.target/aarch64/sve/acle/general-c/load_3.c (f1): Expect
error.
* gcc.target/aarch64/sve/acle/general-c/store_2.c (f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/store_scatter_index_1.c
(f1): Likewise.
*
gcc.target/aarch64/sve/acle/general-c/store_scatter_index_restricted_1.c
(f1): Likewise.
* gcc.target/aarch64/sve/acle/general-c/store_scatter_offset_2.c
(f1): Likewise.
*
gcc.target/aarch64/sve/acle/general-c/store_scatter_offset_restricted_1.c
(f1): Likewise.

[Bug c++/112789] Missing clang __builtin_ctzs for short

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
(In reply to Andrew Pinski from comment #4)
> So just for future reference __builtin_c[lt]zs is for short.
> 
> But with GCC 14 (trunk) added __builtin_ct[lt]g, there is no need to add
> __builtin_c[lt]zs to GCC.
> 
> You could just do:
> 
> #if __has_builtin(__builtin_ctzg) && !__has_builtin(__builtin_ctzs)
> #define ctzs(a) __builtin_ctzg((short)a)
> #elif __has_builtin(__builtin_ctzs)
> #define ctzs(a) __builtin_ctzs((short)a)
> #else
> #error implement fall back for not both cases
> #endif

s/short/unsigned short/ above (and not really needed for the clang
__builtin_ctzs).
So
#if __has_builtin(__builtin_ctzs)
#define ctzs(a) __builtin_ctzs(a)
#elif __has_builtin(__builtin_ctzg)
#define ctzs(a) __builtin_ctzg((unsigned short)(a))
#else
...
#endif

[Bug c++/110734] Attributes cannot be applied to asm declaration

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #19 from Jakub Jelinek  ---
Attributes have been allowed on asm in C++ only since 2017's
https://cplusplus.github.io/CWG/issues/2262.html
which we apparently don't implement.  See
https://gcc.gnu.org/projects/cxx-dr-status.html
It is not clear whether that change has been effectively applied as a DR and
thus whether it should apply to earlier standards as well (guess starting with
C++11) or not.

[Bug target/112776] RISC-V Regression: Missed optimization of VSETVL PASS

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

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

JuzheZhong  changed:

   What|Removed |Added

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

--- Comment #2 from JuzheZhong  ---
Fixed.

[Bug target/112776] RISC-V Regression: Missed optimization of VSETVL PASS

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

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

--- Comment #1 from GCC Commits  ---
The trunk branch has been updated by Lehua Ding :

https://gcc.gnu.org/g:923a67f17badcbe6e2b2e5d3570a265443258c8e

commit r14-6027-g923a67f17badcbe6e2b2e5d3570a265443258c8e
Author: Juzhe-Zhong 
Date:   Fri Dec 1 08:39:57 2023 +0800

RISC-V: Fix VSETVL PASS regression

This patch fix 2 regression (one is bug regression, the other is
performance regression).
Those 2 regressions are both we are comparing ratio for same AVL in wrong
place.

1. BUG regression:
avl_single-84.c:

f0:
li  a5,999424
add a1,a1,a5
li  a4,299008
add a5,a0,a5
addia3,a4,992
addia5,a5,576
addia1,a1,576
vsetvli a4,zero,e8,m2,ta,ma
add a0,a0,a3
vlm.v   v1,0(a5)
vsm.v   v1,0(a1)
vl1re64.v   v1,0(a0)
beq a2,zero,.L10
li  a5,0
vsetvli zero,zero,e64,m1,tu,ma   --->  This is totally incorrect
since the ratio above is 4, wheras it is demanding ratio = 64 here.
.L3:
fcvt.d.lu   fa5,a5
addia5,a5,1
fadd.d  fa5,fa5,fa0
vfmv.s.fv1,fa5
bne a5,a2,.L3
vfmv.f.sfa0,v1
ret
.L10:
vsetvli zero,zero,e64,m1,ta,ma
vfmv.f.sfa0,v1
ret

2. Performance regression:

before this patch:

vsetvli a5,a4,e8,m1,ta,ma
vsetvli zero,a5,e32,m1,tu,ma
vmv.s.x v2,zero
vmv.s.x v1,zero
vsetvli zero,a5,e32,m4,tu,ma
vle32.v v4,0(a1)
vfmul.vvv4,v4,v4
vfredosum.vsv1,v4,v2
vfmv.f.sfa5,v1
fsw fa5,0(a0)
sub a4,a4,a5
bne a4,zero,.L2
ret

After this patch:

vsetvli a5,a4,e32,m4,tu,ma
vle32.v v4,0(a1)
vmv.s.x v2,zero
vmv.s.x v1,zero
vfmul.vvv4,v4,v4
vfredosum.vsv1,v4,v2
vfmv.f.sfa5,v1
fsw fa5,0(a0)
sub a4,a4,a5
bne a4,zero,.L2
ret

Tested rv64gcv_zvfh_zfh passed no regression.

zvl256b/zvl512b/zvl1024b/zve64d is runing.

PR target/112776

gcc/ChangeLog:

* config/riscv/riscv-vsetvl.cc
(pre_vsetvl::pre_global_vsetvl_info): Fix ratio.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/vsetvl/avl_single-84.c: Adapt test.
* gcc.target/riscv/rvv/vsetvl/pr111037-3.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/pr112776.c: New test.

[Bug target/112778] ICE in ppc64-linux-gnu crosscompiler in store_by_pieces since r14-5946-g1ff6d9f7428b06

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

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

Kewen Lin  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org,
   ||bergner at gcc dot gnu.org,
   ||linkw at gcc dot gnu.org,
   ||segher at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
Summary|ICE in ppc64-linux-gnu  |ICE in ppc64-linux-gnu
   |crosscompiler in|crosscompiler in
   |store_by_pieces, at |store_by_pieces since
   |expr.cc:1820|r14-5946-g1ff6d9f7428b06
   Keywords|needs-bisection |
   Last reconfirmed||2023-12-01

--- Comment #1 from Kewen Lin  ---
Confirmed, thanks for reporting, it starts from r14-5946-g1ff6d9f7428b06.

It looks function try_store_by_multiple_pieces has the wrong assumption. For
the code "memset (buf, 'v', 3)", it checks 

+  if (max_bits < orig_max_bits
+  && xlenest + blksize >= xlenest
+  && can_store_by_pieces (xlenest + blksize,
+  builtin_memset_read_str,
+  , align, true))

, succeeds and breaks. later it goes with blksize:

  to = store_by_pieces (to, blksize,
constfun, constfundata,
align, true,
max_len != 0 ? RETURN_END : RETURN_BEGIN);

and fails at targetm.use_by_pieces_infrastructure_p assertion.

It's concluded that can_store_by_pieces (xlenest + blksize, ...) doesn't
necessarily means can_store_by_pieces (blksize, ...).

[Bug tree-optimization/112793] [14 regression] ICE when building stellarium (internal compiler error: in vect_schedule_slp_node, at tree-vect-slp.cc:9062)

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

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

--- Comment #10 from Andrew Pinski  ---
Created attachment 56746
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56746=edit
Delta reduced testcase

This one is slightly less reduced than the other one but this is a delta based
reduced testcase rather than a cvise based one. I didn't manually reduce it
further though.

[Bug c++/110734] Attributes cannot be applied to asm declaration

[tanksherman27 at gmail dot com via Gcc-bugs]

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

--- Comment #18 from Julian Waters  ---
Oops, I meant warning: 'no_reorder' attribute ignored [-Wattributes] in my
above comment

[Bug c++/110734] Attributes cannot be applied to asm declaration

[tanksherman27 at gmail dot com via Gcc-bugs]

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

--- Comment #17 from Julian Waters  ---
Looking at the source of the C++ parser it doesn't seem like asm (""); is
considered a statement but rather is correctly parsed as a declaration, see
cp_parser_block_declaration and cp_parser_declaration_statement. The no_reorder
attribute is just a demonstration, I am aware it is not meant for asm
declarations, rather the error is in how the error message is formed, eg error:
expected primary-expression before 'asm' instead of error: expected
primary-expression before 'asm'

[Bug c++/110734] Attributes cannot be applied to asm declaration

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

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

--- Comment #16 from Xi Ruoyao  ---
(In reply to Xi Ruoyao from comment #15)
> Alright, this is a C++ issue and I mistakenly assumed it was C.

Note that in C++ we have some inconsistency with the standard.  In the standard
asm(...) are "declarations" but in GNU C++ asm(...) are always "statements".

[Bug c++/110734] Attributes cannot be applied to asm declaration

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

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

Xi Ruoyao  changed:

   What|Removed |Added

Summary|Attributes cannot be|Attributes cannot be
   |applied to asm statements   |applied to asm declaration
 Status|WAITING |NEW

--- Comment #15 from Xi Ruoyao  ---
Alright, this is a C++ issue and I mistakenly assumed it was C.

[Bug c++/110734] Attributes cannot be applied to asm statements

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #14 from Xi Ruoyao  ---
Wait a minute.  [[gnu::no_reorder]] is a function or variable attribute, so
it's just not intended to be used for an asm statement.  Actually it won't work
for any statement:

int x;
int main()
{
[[gnu::no_reorder]]
x += 1;
}

gives:

t.c: In function 'main':
t.c:5:9: warning: 'no_reorder' attribute ignored [-Wattributes]
5 | x += 1;
  | ^

We have "statement attributes" (fallthrough and assume) but the doc is clear
that they can only be set on null statements, while asm statements are not null
statements.

Now to me this is just an invalid PR.  Or am I missing something?

[Bug c++/110734] Attributes cannot be applied to asm statements

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

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

Xi Ruoyao  changed:

   What|Removed |Added

Summary|Attributes cannot be|Attributes cannot be
   |applied to asm declarations |applied to asm statements

--- Comment #13 from Xi Ruoyao  ---
Re-titling as there is no such a concept "asm declarations".

[Bug fortran/112764] Associating entity does not have target attribute if selector has pointer attribute in associate block

[mscfd at gmx dot net via Gcc-bugs]

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

--- Comment #10 from martin  ---
Thanks for the speedy fix! I just thought about a variation, which should now
with the fix work as well (was not yet able to compile current dev branch, so
cannot check myself):


program assoc_ptr_in

implicit none

integer, dimension(:,:), pointer :: x
integer, pointer :: j

allocate(x(1:100,1:2), source=123)
associate(i1 => x(:,1))
   call sub(i1)
end associate
deallocate(x)

contains

subroutine sub(j)
   integer, dimension(:), pointer, intent(in) :: j
   print *,j(1)
end subroutine sub

end program assoc_ptr_in

[Bug libstdc++/105118] Why is unexpected::value() named error() in libstdc++?

[hewillk at gmail dot com via Gcc-bugs]

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

康桓瑋  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|SUSPENDED   |RESOLVED

--- Comment #3 from 康桓瑋  ---
Closed as P2549 was approved in C++23.

[Bug ipa/112783] core dump on libxo when function is inlined

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

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

Sam James  changed:

   What|Removed |Added

   See Also||https://github.com/Juniper/
   ||libxo/issues/90
 CC||sjames at gcc dot gnu.org

--- Comment #1 from Sam James  ---
Please see the instructions at https://gcc.gnu.org/bugs/#report, in particular
with regard to checking code with certain options, and also wrt test cases.

[Bug libstdc++/112803] New: : to(Args&&... args) is missing Mandates

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 112803
   Summary: : to(Args&&... args) is missing Mandates
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

[range.utility.conv.adaptors]: Mandates: For the first overload, C is a
cv-unqualified class type.

https://godbolt.org/z/zxjhGx4re

#include 
auto r = std::ranges::to();

[Bug c++/110734] Attributes cannot be applied to asm declarations

[tanksherman27 at gmail dot com via Gcc-bugs]

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

--- Comment #12 from Julian Waters  ---
Will do, will save the new attribute for gcc 15 and just fix the attribute
specifier sequence here

[Bug target/59874] Missing builtin (__builtin_clzs) when compiling with g++

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=112789

--- Comment #18 from Sam James  ---
(In reply to Allan Jensen from comment #8)
> Thanks that looks good. I will test it when I have a chance. I am changing
> the Qt sources to not assume the presence of __builtin_clzs when __BMI__ is
> defined. It can use __builtin_clz() and __builtin_ctz()-16U instead, but for
> general compatibility it is nice that GCC also keeps it around. 
> 
> Note, it would be even better though if GCC could support the short forms as
> generic builtins. That changes the semantics slightly, but they are named so
> similarly to the clz, clzl and clzll it would be easy to assume they also
> are generics, with similar semantics, and can work across all targets.
> 

GCC 14 will have __builtin_clzg, if you want to start using that:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112789#c4.

[Bug tree-optimization/112793] [14 regression] ICE when building stellarium (internal compiler error: in vect_schedule_slp_node, at tree-vect-slp.cc:9062)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-12-01
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #9 from Andrew Pinski  ---
.

[Bug tree-optimization/112793] [14 regression] ICE when building stellarium (internal compiler error: in vect_schedule_slp_node, at tree-vect-slp.cc:9062)

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Attachment #56744|0   |1
is obsolete||

--- Comment #8 from Andrew Pinski  ---
Created attachment 56745
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56745=edit
testcase without any undefinedness to it

Further reduced and without any undefined/uninitialized variables in it (as far
as I can tell):

Note I added a `#if 0` section which produces almost the same IR (except ssa
names are different) from the other but does not produce an ICE. I don't
understand why though.

[Bug testsuite/112786] [14 Regression] gcc.dg/tree-ssa/scev-3.c scev-4.c and scev-5.c XPASSing on most ilp32 targets

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

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #1 from Hans-Peter Nilsson  ---
See URL field for patch alternative 1.
Alternative 2:
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/638863.html

[Bug libstdc++/112802] New: : _ToClosure::operator() has no constraints

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 112802
   Summary: : _ToClosure::operator() has no constraints
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

which means this is not SFINAE-friendly. That's not standard compliance, right?

  #include 
  #include 

  template
  concept test = requires { std::ranges::to>()(T{}); };

  static_assert(!test); // hard error in libstdc++

https://godbolt.org/z/Tasba18Kv

[Bug tree-optimization/112793] [14 regression] ICE when building stellarium (internal compiler error: in vect_schedule_slp_node, at tree-vect-slp.cc:9062)

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

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

--- Comment #7 from Andrew Pinski  ---
e.g. r[8 * 2] is r[16] and 16 >= 16 :).

[Bug tree-optimization/112793] [14 regression] ICE when building stellarium (internal compiler error: in vect_schedule_slp_node, at tree-vect-slp.cc:9062)

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Sam James from comment #5)
> Created attachment 56744 [details]
> reduced.ii

Note this reduced testcase has undefined code in it ...

[Bug tree-optimization/112793] [14 regression] ICE when building stellarium (internal compiler error: in vect_schedule_slp_node, at tree-vect-slp.cc:9062)

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

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

--- Comment #5 from Sam James  ---
Created attachment 56744
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56744=edit
reduced.ii

[Bug target/112801] [14] RISC-V vector: failure to mask top bits during type conversion

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

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

--- Comment #1 from JuzheZhong  ---
Known issue for a long time.

I realized that 2 years ago:

https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1075

when I developed the first version of RVV GCC (rvv-next).

I don't think it is serious issue since I chose to ignore this issue and
correctly work fine in all my downstream application.

This issue is also exposed in our regression:

FAIL: gcc.dg/signbit-5.c execution test

I ignore this FAIL for a long time.

Low priority for me and I won't work on fixing it.

[Bug target/112801] New: [14] RISC-V vector: failure to mask top bits during type conversion

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 112801
   Summary: [14] RISC-V vector: failure to mask top bits during
type conversion
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

This testcase is correctly handled on rv64gc but fails on rv64gcv -O2

> ./bin/riscv64-unknown-linux-gnu-gcc -march=rv64gcv -mabi=lp64d -O2 red.c -o 
> rv64gcv.out

Creduced testcase:
int printf(char *, ...);
int a;
void c(int b) { a = b; }
char d;
char *const e = 
long f = 66483309998;
unsigned long g[2];
short h;
int k;
void l() {
  int i = 0;
  for (; i < 2; i++) {
{
  unsigned long *m = [0];
  *m &= 2;
  if (f && *e)
for (;;)
  ;
}
k = f;
g[1] = k;
for (; h;)
  ;
  }
}
int main() {
  l();
  c(g[1] >> 32);
  printf("%X\n", a);
}

Here's my analysis:
Focusing on the stack of operations that lead to a:
long f = 66483309998; // hex: F7AB6CDAE
int k = f; // Should mask off the top bits: 7AB6CDAE
unsigned long g[1] = k; // 7AB6CDAE
int arg to c() = g[1]; >> 32 // 0
int a = arg; // 0
print(a); // 0

0 is expected but rv64gcv fails to mask the top bits and ends up printing F

Tested using qemu with these commands:
> ./bin/riscv64-unknown-linux-gnu-gcc -march=rv64gcv -mabi=lp64d -O2 red.c -o 
> rv64gcv.out

> ./bin/riscv64-unknown-linux-gnu-gcc -march=rv64gc -mabi=lp64d -O2 red.c -o 
> rv64gc.out

> QEMU_CPU="rv64,vlen=128,v=true,vext_spec=v1.0,Zve32f=true,Zve64f=true" 
> ./bin/qemu-riscv64 rv64gc.out
0

> QEMU_CPU="rv64,vlen=128,v=true,vext_spec=v1.0,Zve32f=true,Zve64f=true" 
> ./bin/qemu-riscv64 rv64gcv.out
F

[Bug target/112773] [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b

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

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

--- Comment #7 from JuzheZhong  ---
Here is the compiler explorer for reference and easily see the issue:

https://godbolt.org/z/8v1dsKG3f

[Bug target/112773] [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #6 from Patrick O'Neill  ---
(In reply to JuzheZhong from comment #3)
> I see. I didn't reproduce the ICE since I didn't enable gcc_assert_checking.
> 
> Could you tell me how to enable it ?

I didn't explicitly enable checking. The full configure command I ran with
(from -freport-bug output) is:
/scratch/tc-testing/tc-nov-30-trunk/build-rv64gcv/../gcc/configure
--target=riscv64-unknown-linux-gnu
--prefix=/scratch/tc-testing/tc-nov-30-trunk/build-rv64gcv
--with-sysroot=/scratch/tc-testing/tc-nov-30-trunk/build-rv64gcv/sysroot
--with-pkgversion=g18d8a50a042 --with-system-zlib --enable-shared --enable-tls
--enable-languages=c,c++,fortran --disable-libmudflap --disable-libssp
--disable-libquadmath --disable-libsanitizer --disable-nls --disable-bootstrap
--src=../../gcc --enable-multilib --with-abi=lp64d --with-arch=rv64imafdc
--with-tune=rocket --with-isa-spec=20191213 'CFLAGS_FOR_TARGET=-O2   
-mcmodel=medlow' 'CXXFLAGS_FOR_TARGET=-O2-mcmodel=medlow'

I built the toolchain using riscv-gnu-toolchain `make linux`.

[Bug target/112773] [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b

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

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

--- Comment #5 from JuzheZhong  ---
Besides, the mask type is:

vector([4,4]) 

[Bug target/112773] [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b

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

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

--- Comment #4 from JuzheZhong  ---
After reproducing the ICE.

I confirm the root cause is because we enable vec_extract for mask:

;; -
;; This extracts a bit (via QImode) from a bitmask vector.
;; -
(define_expand "vec_extractqi"
  [(set (match_operand:QI 0 "register_operand")
 (vec_select:QI
   (match_operand:VB  1 "register_operand")
   (parallel
 [(match_operand  2 "nonmemory_operand")])))]


The ICE happens optimized IR is as follows:

_68 = BIT_FIELD_REF ;

can_align_p return false for POLY_INT_CST [3, 4] since the alignment require
multipe of 8:

force_align_down_and_div (X, BITS_PER_UNIT) -> BITS_PER_UNIT = 8.


It's ovbious POLY_INT_CST [3, 4] is definitely not aligned with 8.


I have no idea how to fix it.

CCing Robin who enable mask bit extraction should know much better than me.

And CCing Richard B and Richard S may give us some useful suggestions.

Thanks.

[Bug target/112773] [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b

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

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

--- Comment #3 from JuzheZhong  ---
I see. I didn't reproduce the ICE since I didn't enable gcc_assert_checking.

Could you tell me how to enable it ?


I hack the codes as follows:

diff --git a/gcc/poly-int.h b/gcc/poly-int.h
index 828714ee910..24cce294414 100644
--- a/gcc/poly-int.h
+++ b/gcc/poly-int.h
@@ -1825,7 +1825,7 @@ template
 inline poly_int
 force_align_down_and_div (const poly_int , Cb align)
 {
-  gcc_checking_assert (can_align_p (value, align));
+  gcc_assert (can_align_p (value, align));

   poly_int r;
   POLY_SET_COEFF (Ca, r, 0, ((value.coeffs[0]


Then I can see the assertion FAIL.

[Bug target/112640] [14 regression] Failed profiledbootstrap on arm64 (libgcc/config/libbid/bid128_fma.c:3569:1: internal compiler error: in extract_base_offset_in_addr, at config/aarch64/aarch64.cc:2

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

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

Sam James  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2023-12-01
 Ever confirmed|0   |1

--- Comment #11 from Sam James  ---
Still happens but bisecting it has proven unreliable. I'm going to call this
WAITING until I get a chance to at least give some standalone build command
which fails.

[Bug target/112798] RISC-V regression testsuite errors with rv64gcv_zve32f

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #1 from Patrick O'Neill  ---
See also:
rv64gcv_zve64d: pr112797
rv64gcv_zve32f: pr112798
rv32gcv_zve64d: pr112799
rv32gcv_zve32f: pr112800

[Bug testsuite/112799] RISC-V regression testsuite errors with rv32gcv_zve64d

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #1 from Patrick O'Neill  ---
See also:
rv64gcv_zve64d: pr112797
rv64gcv_zve32f: pr112798
rv32gcv_zve64d: pr112799
rv32gcv_zve32f: pr112800

[Bug testsuite/112800] RISC-V regression testsuite errors with rv32gcv_zve32f

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #1 from Patrick O'Neill  ---
See also:
rv64gcv_zve64d: pr112797
rv64gcv_zve32f: pr112798
rv32gcv_zve64d: pr112799
rv32gcv_zve32f: pr112800

[Bug target/112797] RISC-V regression testsuite errors with rv64gcv_zve64d

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #1 from Patrick O'Neill  ---
See also:
rv64gcv_zve64d: pr112797
rv64gcv_zve32f: pr112798
rv32gcv_zve64d: pr112799
rv32gcv_zve32f: pr112800

[Bug testsuite/112800] New: RISC-V regression testsuite errors with rv32gcv_zve32f

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 112800
   Summary: RISC-V regression testsuite errors with rv32gcv_zve32f
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Created attachment 56743
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56743=edit
rv32gcv_zve32f testsuite failures 2023-11-30

Current testsuite status of rv32gcv_zve32f on GCC
18d8a50a042a7faa78626373fdcfe3468c7ae864

I've started running rv32/64 zve variants weekly on the postcommit CI. This is
my first time running these so if any of the failures look odd poke me here or
via email and I can dig into/share the logs.

Artifacts for this run can be downloaded here:
https://github.com/patrick-rivos/gcc-postcommit-ci/actions/runs/7049117326

This is just a tracking issue, similar to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311

I'll open separate tracking issues for rv{32|64}gcv_zve{32f|64d} and link them
here when I do.

I've attached the current results for rv32gcv_zvl128b with glibc v2.37 on QEMU
v8.1.2

[Bug testsuite/112799] New: RISC-V regression testsuite errors with rv32gcv_zve64d

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 112799
   Summary: RISC-V regression testsuite errors with rv32gcv_zve64d
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Created attachment 56742
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56742=edit
rv32gcv_zve64d testsuite failures 2023-11-30

Current testsuite status of rv32gcv_zve64d on GCC
18d8a50a042a7faa78626373fdcfe3468c7ae864

I've started running rv32/64 zve variants weekly on the postcommit CI. This is
my first time running these so if any of the failures look odd poke me here or
via email and I can dig into/share the logs.

Artifacts for this run can be downloaded here:
https://github.com/patrick-rivos/gcc-postcommit-ci/actions/runs/7049117326

This is just a tracking issue, similar to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311

I'll open separate tracking issues for rv{32|64}gcv_zve{32f|64d} and link them
here when I do.

I've attached the current results for rv32gcv_zvl128b with glibc v2.37 on QEMU
v8.1.2

[Bug target/112798] New: RISC-V regression testsuite errors with rv64gcv_zve32f

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 112798
   Summary: RISC-V regression testsuite errors with rv64gcv_zve32f
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Created attachment 56741
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56741=edit
rv64gcv_zve32f testsuite failures 2023-11-30

Current testsuite status of rv64gcv_zve32f on GCC
18d8a50a042a7faa78626373fdcfe3468c7ae864

I've started running rv32/64 zve variants weekly on the postcommit CI. This is
my first time running these so if any of the failures look odd poke me here or
via email and I can dig into/share the logs.

Artifacts for this run can be downloaded here:
https://github.com/patrick-rivos/gcc-postcommit-ci/actions/runs/7049117326

This is just a tracking issue, similar to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311

I'll open separate tracking issues for rv{32|64}gcv_zve{32f|64d} and link them
here when I do.

I've attached the current results for rv32gcv_zvl128b with glibc v2.37 on QEMU
v8.1.2

[Bug target/112797] New: RISC-V regression testsuite errors with rv64gcv_zve64d

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 112797
   Summary: RISC-V regression testsuite errors with rv64gcv_zve64d
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Created attachment 56740
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56740=edit
rv64gcv_zve64d testsuite failures 2023-11-30

Current testsuite status of rv64gcv_zve64d on GCC
18d8a50a042a7faa78626373fdcfe3468c7ae864

I've started running rv32/64 zve variants weekly on the postcommit CI. This is
my first time running these so if any of the failures look odd poke me here or
via email and I can dig into/share the logs.

Artifacts for this run can be downloaded here:
https://github.com/patrick-rivos/gcc-postcommit-ci/actions/runs/7049117326

This is just a tracking issue, similar to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311

I'll open separate tracking issues for rv{32|64}gcv_zve{32f|64d} and link them
here when I do.

I've attached the current results for rv32gcv_zvl128b with glibc v2.37 on QEMU
v8.1.2

[Bug c++/112795] [C++>=14] ICE pragma GCC unroll (n) cxx_eval_constant_expression

[magnus.hegdahl at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Magnus Hokland Hegdahl  ---
Full output:
// Target: x86_64-pc-linux-gnu
// Configured with: /build/gcc/src/gcc/configure
--enable-languages=ada,c,c++,d,fortran,go,lto,objc,obj-c++ --enable-bootstrap
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--with-build-config=bootstrap-lto --with-linker-hash-style=gnu
--with-system-zlib --enable-__cxa_atexit --enable-cet=auto
--enable-checking=release --enable-clocale=gnu --enable-default-pie
--enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-libstdcxx-backtrace --enable-link-serialization=1
--enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-werror
// Thread model: posix
// Supported LTO compression algorithms: zlib zstd
// gcc version 13.2.1 20230801 (GCC) 
// 
// mwe.cpp: In function ‘void f()’:
// mwe.cpp:5:21: internal compiler error: in cxx_eval_constant_expression, at
cp/constexpr.cc:7619
// 5 | #pragma GCC unroll(n)
//   | ^
// 0x1ad33c8 internal_error(char const*, ...)
//  ???:0
// 0x6b7b63 fancy_abort(char const*, int, char const*)
//  ???:0
// 0x711364 maybe_constant_value(tree_node*, tree_node*, mce_value)
//  ???:0
// 0x9443d0 c_common_parse_file()
//  ???:0
// Please submit a full bug report, with preprocessed source.
// Please include the complete backtrace with any bug report.
// See  for instructions.

// /usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/cc1plus -quiet -D_GNU_SOURCE mwe.cpp
-quiet -dumpbase mwe.cpp -dumpbase-ext .cpp -mtune=generic -march=x86-64 -Wall
-Wextra -Wpedantic -freport-bug -o - -frandom-seed=0 -fdump-noaddr

# 0 "mwe.cpp"
# 0 ""
# 0 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 0 "" 2
# 1 "mwe.cpp"
constexpr int n = 1;

template 
void f() {
#pragma GCC unroll(n)
for (int i = 0; i != n; ++i) {
}
}

[Bug libstdc++/112796] New: header implicitly includes

[bill.trost at harmonicinc dot com via Gcc-bugs]

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

Bug ID: 112796
   Summary:  header implicitly includes 
   Product: gcc
   Version: 12.2.0
   URL: https://godbolt.org/z/Pra17xczj
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bill.trost at harmonicinc dot com
  Target Milestone: ---
Target: x86-64

Created attachment 56739
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56739=edit
Sample code that incorrectly compiles.

The attached code should not compile (and does not compile if you don't include
). It should have to #include .

[Bug c++/112795] New: [C++>=14] ICE pragma GCC unroll (n) cxx_eval_constant_expression

[magnus.hegdahl at gmail dot com via Gcc-bugs]

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

Bug ID: 112795
   Summary: [C++>=14] ICE pragma GCC unroll (n)
cxx_eval_constant_expression
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: magnus.hegdahl at gmail dot com
  Target Milestone: ---

Compiling the following code with GCC >= 8.1 (when #pragma GCC unroll was
added), and -std=c++14 or higher results in an internal compiler error:
```
constexpr int n = 1;
template 
void f() {
#pragma GCC unroll(n)
for (int i = 0; i != n; ++i) {
}
}
```

It does not fail if f is not a template, if n is not parenthesized, or if using
-std=c++11.

[Bug c++/112794] New: [contracts] modifying return value fails

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

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

Bug ID: 112794
   Summary: [contracts] modifying return value fails
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jason at gcc dot gnu.org
  Target Milestone: ---

Both asserts should pass.  f1 seems to fail because we pass a copy of r to
mutate instead of r itself; the .gimple dump for f2 looks fine but the
optimizers get confused for some reason.

#include 

bool mutate(const int ) {
  const_cast(i) = 42;
  return true;
}

int f1()
  [[ post r: mutate(r) ]]
{
  return 0;
}

struct S {
  S(int i) : i(i) {}
  S(S&&) = delete; // non-moveable  
  int i;
};

bool mutate(const S& s) {
  const_cast(s).i = 42;
  return true;
}

S f2()
  [[ post r: mutate(r) ]]
{
  return S{0};
}

int main() {
  assert(f1() == 42);   // Fails.   
  assert(f2().i == 42); // Passes at -O0, ICEs at -O1, fails at -O2.
}

[Bug tree-optimization/112793] [14 regression] ICE when building stellarium (internal compiler error: in vect_schedule_slp_node, at tree-vect-slp.cc:9062)

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

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

--- Comment #4 from Andrew Pinski  ---
With s/__builtin_ctzs/__builtin_ctzg/ and `-O3 -march=skylake-avx512`, I can
reproduce it with an unmodified trunk GCC.

[Bug tree-optimization/112793] [14 regression] ICE when building stellarium (internal compiler error: in vect_schedule_slp_node, at tree-vect-slp.cc:9062)

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

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

--- Comment #3 from Sam James  ---
(In reply to Andrew Pinski from comment #2)
> Does gentoo has a patch which adds __builtin_ctzs ?

No, nothing like that. Here's what this one was built with:
https://gitweb.gentoo.org/proj/gcc-patches.git/tree/14.0.0/gentoo

[Bug tree-optimization/112793] [14 regression] ICE when building stellarium (internal compiler error: in vect_schedule_slp_node, at tree-vect-slp.cc:9062)

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

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

--- Comment #2 from Andrew Pinski  ---
Does gentoo has a patch which adds __builtin_ctzs ?

[Bug tree-optimization/112793] [14 regression] ICE when building stellarium (internal compiler error: in vect_schedule_slp_node, at tree-vect-slp.cc:9062)

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

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

--- Comment #1 from Andrew Pinski  ---
Hmm __builtin_ctzs 

[Bug c++/112793] New: [14 regression] ICE when building stellarium (internal compiler error: in vect_schedule_slp_node, at tree-vect-slp.cc:9062)

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

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

Bug ID: 112793
   Summary: [14 regression] ICE when building stellarium (internal
compiler error: in vect_schedule_slp_node, at
tree-vect-slp.cc:9062)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Created attachment 56738
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56738=edit
StelObserver.cpp.ii.xz

Originally reported downstream in Gentoo by Toralf Förster at
https://bugs.gentoo.org/918911.

```
FAILED: src/CMakeFiles/stelMain.dir/core/StelObserver.cpp.o
/usr/lib/ccache/bin/x86_64-pc-linux-gnu-g++ -DCOPYRIGHT_YEARS=\"2000-2023\"
-DENABLE_NLS -DENABLE_SCRIPTING -DENABLE_SCRIPT_CONSOLE -DENABLE_SHOWMYSKY
-DENABLE_XLSX -DINSTALL_DATADIR=\"/usr/share/stellarium\"
 -DNDEBUG -DPACKAGE_VERSION=\"23.3.0\" -DQT_CHARTS_LIB -DQT_CONCURRENT_LIB
-DQT_CORE_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_OPENGL_LIB
-DQT_SCRIPT_LIB -DQT_WIDGETS_LIB -DQXlsx_SHAREDLIB -DSTELLA
RIUM_COPYRIGHT="\"Copyright (C) 2000-2023 Stellarium Developers\""
-DSTELLARIUM_DEV_URL=\"https://github.com/Stellarium/stellarium\;
-DSTELLARIUM_MAJOR=23 -DSTELLARIUM_MINOR=3 -DSTELLARIUM_PATCH=0 -DSTELLARIU
M_PUBLIC_VERSION=\"23.3\" -DSTELLARIUM_RELEASE_BUILD
-DSTELLARIUM_SERIES=\"23.0\"
-DSTELLARIUM_SOURCE_DIR=\"/var/tmp/portage/sci-astronomy/stellarium-23.3/work/stellarium-23.3\"
-DSTELLARIUM_URL=\"https://ste
llarium.org/\" -DUSE_STATIC_PLUGIN_ANGLEMEASURE
-DUSE_STATIC_PLUGIN_ARCHAEOLINES -DUSE_STATIC_PLUGIN_CALENDARS
-DUSE_STATIC_PLUGIN_EQUATIONOFTIME -DUSE_STATIC_PLUGIN_EXOPLANETS
-DUSE_STATIC_PLUGIN_METEORSHOWE
RS -DUSE_STATIC_PLUGIN_MISSINGSTARS -DUSE_STATIC_PLUGIN_NAVSTARS
-DUSE_STATIC_PLUGIN_NOVAE -DUSE_STATIC_PLUGIN_OBSERVABILITY
-DUSE_STATIC_PLUGIN_OCULARS -DUSE_STATIC_PLUGIN_ONLINEQUERIES
-DUSE_STATIC_PLUGIN_P
OINTERCOORDINATES -DUSE_STATIC_PLUGIN_PULSARS -DUSE_STATIC_PLUGIN_QUASARS
-DUSE_STATIC_PLUGIN_REMOTECONTROL -DUSE_STATIC_PLUGIN_REMOTESYNC
-DUSE_STATIC_PLUGIN_SATELLITES -DUSE_STATIC_PLUGIN_SCENERY3D -DUSE_ST
ATIC_PLUGIN_SOLARSYSTEMEDITOR -DUSE_STATIC_PLUGIN_SUPERNOVAE
-D_USE_MATH_DEFINES
-I/var/tmp/portage/sci-astronomy/stellarium-23.3/work/stellarium-23.3_build/src
-I/var/tmp/portage/sci-astronomy/stellarium-23.
3/work/stellarium-23.3/src
-I/var/tmp/portage/sci-astronomy/stellarium-23.3/work/stellarium-23.3_build/src/stelMain_autogen/include
-I/var/tmp/portage/sci-astronomy/stellarium-23.3/work/stellarium-23.3_build
-I/var/tmp/portage/sci-astronomy/stellarium-23.3/work/stellarium-23.3/src/core
-I/var/tmp/portage/sci-astronomy/stellarium-23.3/work/stellarium-23.3/src/core/modules
-I/var/tmp/portage/sci-astronomy/stellariu
m-23.3/work/stellarium-23.3/src/core/planetsephems
-I/var/tmp/portage/sci-astronomy/stellarium-23.3/work/stellarium-23.3/src/gui
-I/var/tmp/portage/sci-astronomy/stellarium-23.3/work/stellarium-23.3/src/scrip
ting
-I/var/tmp/portage/sci-astronomy/stellarium-23.3/work/stellarium-23.3/src/external/glues_stel/source
-I/var/tmp/portage/sci-astronomy/stellarium-23.3/work/stellarium-23.3/plugins/RemoteControl/src/../inc
lude -isystem /usr/include/qt5 -isystem /usr/include/qt5/QtGui -isystem
/usr/include/qt5/QtCore -isystem /usr/lib64/qt5/mkspecs/linux-g++ -isystem
/usr/include/qt5/QtWidgets -isystem /usr/include/qt5/QtNetwor
k -isystem /usr/include/qt5/QtCharts -isystem /usr/include/qt5/QtGui/5.15.11
-isystem /usr/include/qt5/QtGui/5.15.11/QtGui -isystem
/usr/include/qt5/QtCore/5.15.11 -isystem /usr/include/qt5/QtCore/5.15.11/QtC
ore -isystem /usr/include/qt5/QtConcurrent -isystem /usr/include/qt5/QtOpenGL
-isystem /usr/include/qt5/QtScript -isystem /usr/include/QXlsxQt5 -DQT_NO_DEBUG
-O3 -march=native -fno-semantic-interposition -pip
e -Wa,-O2 -Wa,-mtune=znver2 -fcf-protection=none -fdiagnostics-color=always
-fdiagnostics-urls=never -frecord-gcc-switches -ggdb3 -Werror=format-security
-Wformat -Wall -Wextra -Wno-unused-parameter -Wno-unkn
own-pragmas -Wno-unused-result -std=c++17 -fdiagnostics-color=always -fPIC
-Winvalid-pch -include
/var/tmp/portage/sci-astronomy/stellarium-23.3/work/stellarium-23.3_build/src/CMakeFiles/stelMain.dir/cmake_pc
h.hxx -MD -MT src/CMakeFiles/stelMain.dir/core/StelObserver.cpp.o -MF
src/CMakeFiles/stelMain.dir/core/StelObserver.cpp.o.d -o
src/CMakeFiles/stelMain.dir/core/StelObserver.cpp.o -c
/var/tmp/portage/sci-astro
nomy/stellarium-23.3/work/stellarium-23.3/src/core/StelObserver.cpp
during GIMPLE pass: slp
/var/tmp/portage/sci-astronomy/stellarium-23.3/work/stellarium-23.3/src/core/StelObserver.cpp:
In member function ‘Mat4d StelObserver::getRotAltAzToEquatorial(double, double)
const’:
/var/tmp/portage/sci-astronomy/stellarium-23.3/work/stellarium-23.3/src/core/StelObserver.cpp:222:7:
internal compiler error: in 

[Bug middle-end/112740] [14 Regression] wrong code with vector compare on riscv64 at -O0

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||ams at gcc dot gnu.org

--- Comment #10 from Andrew Pinski  ---
Actually it looks like r14-5319-ga5922427c29fad broke this.

This expand patch seems broken for the case in general. I am suspecting
something else is broken for GCN here ...

[Bug middle-end/112572] [14 regression] LLVM miscompiled since r14-5355-g3cd3a09b3f91a1

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

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

--- Comment #30 from Sam James  ---
afaik the best we have so far is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112613#c0

[Bug middle-end/112740] [14 Regression] wrong code with vector compare on riscv64 at -O0

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

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

--- Comment #9 from Andrew Pinski  ---
Note this was exposed by r14-3350-g47b833a9abe19d which changed the original IR
From:
  _4 = VEC_COND_EXPR <_3, { -1 }, { 0 }>;
  _5 = VIEW_CONVERT_EXPR(_4);
  _6 = _5 == { 0 };
  _7 = VEC_COND_EXPR <_6, { -1 }, { 0 }>;
  _8 = VIEW_CONVERT_EXPR(_7);

To:
  _4 = ~_3;
  _5 = VEC_COND_EXPR <_4, { 0x }, { 0 }>;

Which is 100% correct and nothing wrong with that change there either.

[Bug middle-end/112740] [14 Regression] wrong code with vector compare on riscv64 at -O0

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #8 from Andrew Pinski  ---
I am not going to able to figure out how to fix expand for a while so
unassigning. But at least there is some analysis on what is going on.

[Bug middle-end/112740] [14 Regression] wrong code with vector compare on riscv64 at -O0

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|target  |middle-end

--- Comment #7 from Andrew Pinski  ---
Oh it is not the ~ but rather `_3 = {_16};` which produces the wrong code:
//   _16;
//   vector(1)  _3;

;; _3 = {_16};

(insn 36 35 37 (set (reg:TI 114)
(reg:TI 102 [ _16 ])) "/app/example.cpp":15:6 -1
 (nil))

(insn 37 36 38 (set (subreg:DI (reg:TI 113) 0)
(and:DI (subreg:DI (reg:TI 114) 0)
(const_int 1 [0x1]))) "/app/example.cpp":15:6 -1
 (nil))

(insn 38 37 39 (set (reg:DI 115)
(const_int 0 [0])) "/app/example.cpp":15:6 -1
 (nil))

(insn 39 38 40 (set (subreg:DI (reg:TI 113) 8)
(and:DI (subreg:DI (reg:TI 114) 8)
(reg:DI 115))) "/app/example.cpp":15:6 -1
 (nil))

(insn 40 39 0 (set (reg:TI 94 [ _3 ])
(reg:TI 113)) "/app/example.cpp":15:6 -1
 (nil))


That is wrong. that is producing 1 in _3 when it should have been -1 .
That is it is doing `r94 = r102 & 0x1` which is totally wrong/broken ...

[Bug target/112740] [14 Regression] wrong code with vector compare on riscv64 at -O0

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

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

--- Comment #6 from Andrew Pinski  ---
Veclower -O0 produces
  c.0_6 = c_5(D);
  _2 = (__int128 unsigned) c.0_6;
  _1 = {_2};
  _10 = VIEW_CONVERT_EXPR<__int128 unsigned>(v_7(D));
  _11 = _10 >= _2; // 1 true
  _12 = (int128_t) _11; // 1
  _13 = -_12; // -1
  _14 = () _13; // -1 aka true
  _3 = {_14}; // {-1} aka true
  _4 = ~_3; // 0 aka false
  _15 = VIEW_CONVERT_EXPR<>(_4); // 0 aka false
  _16 = _15 != 0; // 0 != 0, 0 false
  _17 = (__int128 unsigned) _16; // 0
  _18 = -_17; // 0
  _8 = {_18};

Which looks correct.
NOTE the ~ there, I am suspecting it is producing the wrong result ...

[Bug c++/112744] Nested name specifier wrongly produces ambiguity in accessing static field

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Fixed for GCC 14.

[Bug c++/112744] Nested name specifier wrongly produces ambiguity in accessing static field

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

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

--- Comment #2 from GCC Commits  ---
The trunk branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:725c68c54c265fe7f6fc7babff7139f3161bdfa6

commit r14-6024-g725c68c54c265fe7f6fc7babff7139f3161bdfa6
Author: Marek Polacek 
Date:   Tue Nov 28 14:44:24 2023 -0500

c++: wrong ambiguity in accessing static field [PR112744]

Given

  struct A { constexpr static int a = 0; };
  struct B : A {};
  struct C : A {};
  struct D : B, C {};

we give the "'A' is an ambiguous base of 'D'" error for

  D{}.A::a;

which seems wrong: 'a' is a static data member so there is only one copy
so it can be unambiguously referred to even if there are multiple A
objects.  clang++/MSVC/icx agree.

This patch uses ba_any: [class.access.base] requires conversion to a unique
base subobject for non-static data members, but it does not require that
the
base be unique or accessible for static data members.

PR c++/112744

gcc/cp/ChangeLog:

* typeck.cc (finish_class_member_access_expr): When accessing
a static data member, use ba_any for lookup_base.

gcc/testsuite/ChangeLog:

* g++.dg/lookup/scoped11.C: New test.
* g++.dg/lookup/scoped12.C: New test.
* g++.dg/lookup/scoped13.C: New test.
* g++.dg/lookup/scoped14.C: New test.
* g++.dg/lookup/scoped15.C: New test.

[Bug analyzer/112792] New: -Wanalyzer-out-of-bounds seen on Linux kernel with certain unions

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

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

Bug ID: 112792
   Summary: -Wanalyzer-out-of-bounds seen on Linux kernel with
certain unions
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
Blocks: 106358
  Target Milestone: ---


typedef unsigned int u32;

union msix_perm {
  struct {
u32 rsvd2 : 8;
u32 pasid : 20;
  };
  u32 bits;
} __attribute__((__packed__));

union msix_perm mperm;

void idxd_device_set_perm_entry(u32 pasid) {
  mperm.pasid = pasid;
}


False positive with -fanalyzer:
t.c: In function ‘idxd_device_set_perm_entry’:
t.c:14:15: warning: buffer overflow [CWE-787] [-Wanalyzer-out-of-bounds]
   14 |   mperm.pasid = pasid;
  |   ^~~
  event 1
|
|   11 | union msix_perm mperm;
|  | ^
|  | |
|  | (1) capacity: 4 bytes
|
+--> ‘idxd_device_set_perm_entry’: event 2
   |
   |   14 |   mperm.pasid = pasid;
   |  |   ^~~
   |  |   |
   |  |   (2) out-of-bounds write at byte 4 but ‘mperm’
ends at byte 4
   |
t.c:14:15: note: write of 1 byte to beyond the end of ‘mperm’

 ┌─┐
 │write from ‘pasid’ (type: ‘u32’) │
 └─┘
  │
  │
  v
  ┌──┐
  │  ‘mperm’ (type: ‘union msix_perm’)   │
  └──┘
  ├──┬───┤
 │
╭┴╮
│capacity: 4 bytes│
╰─╯




Affects trunk: https://godbolt.org/z/oWoY7j6eY
Affects 13.2:  https://godbolt.org/z/vzdEbq6E1

(reduced from drivers/dma/idxd/device.c)


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106358
[Bug 106358] [meta-bug] tracker bug for building the Linux kernel with
-fanalyzer

[Bug target/97323] [11/12/13/14 Regression] ICE 'verify_type' failed on arm-linux-gnueabihf

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

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

[Bug c/112791] error: 'TYPE_CANONICAL' is not compatible

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug c/112791] error: 'TYPE_CANONICAL' is not compatible

[muecker at gwdg dot de via Gcc-bugs]

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

Martin Uecker  changed:

   What|Removed |Added

 CC||muecker at gwdg dot de

--- Comment #1 from Martin Uecker  ---
Also on RISC V (64 bit9 https://godbolt.org/z/3bEc5j34E

[Bug target/112698] gcc r14-5617-gb8592186611 introduces regressions in bfloat16_vector_typecheck_1.c for cortex-m0 and cortex-m3

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

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

--- Comment #5 from Matthias Kretz (Vir)  ---
OK, I can follow that reasoning. It's still a breaking change for everyone that
was using int up to this point. I guess the argument is that using int was
wrong in the first place and it just happened to work by chance. The right type
to use would have been int32_t instead of int. However, if I use int32_t for
interacting with NEON intrinsics, will this work everywhere (older GCC, Clang,
etc.)? Or is the only portable solution decltype(int32x2t()[0])?

[Bug fortran/112764] Associating entity does not have target attribute if selector has pointer attribute in associate block

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #9 from anlauf at gcc dot gnu.org ---
Fixed on mainline for gcc-14, and backported to 13-branch.  Closing.

Thanks for the report!

[Bug c/112791] New: error: 'TYPE_CANONICAL' is not compatible

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 112791
   Summary: error: 'TYPE_CANONICAL' is not compatible
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

This C source code:

typedef abi_ulong __attribute__((aligned(2)));
abi_ulong extramask[];

when compiled by recent gcc trunk, does this:

$ ../gcc/results.20231126/bin/gcc -c -g -w bug986.c
bug986.c:2:1: error: 'TYPE_CANONICAL' is not compatible
2 | abi_ulong extramask[];
  | ^
 
unit-size 
align:32 warn_if_not_align:0 symtab:1990149344 alias-set -1
canonical-ty
pe 0x76f853c0 precision:32 min  max


This is on a Raspberry PI 3.

dcb@raspberrypi:~ $ ~/gcc/results.20231126/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/dcb/gcc/results.20231126/bin/gcc
COLLECT_LTO_WRAPPER=/home/dcb/gcc/results.20231126/libexec/gcc/arm-linux-gnueabihf/14.0.0/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../trunk/configure --prefix=/home/dcb/gcc/results.20231126
--disable-bootstrap --disable-multilib --disable-werror
--with-pkgversion=e40a13eaca4d87ec --enable-checking=yes
--enable-languages=c,c++ --with-cpu=cortex-a72 --with-fpu=neon-fp-armv8
--with-float=hard --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf
--target=arm-linux-gnueabihf
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20231126 (experimental) (e40a13eaca4d87ec) 
dcb@raspberrypi:~ $

[Bug fortran/111880] [11/12/13/14] False positive warning of obsolescent COMMON block with Fortran submodule

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

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

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

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

commit r13-8111-gff96ddf43bcfe5c37a85118a68dcac87ce33c8d9
Author: Harald Anlauf 
Date:   Thu Nov 23 22:48:38 2023 +0100

Fortran: avoid obsolescence warning for COMMON with submodule [PR111880]

gcc/fortran/ChangeLog:

PR fortran/111880
* resolve.cc (resolve_common_vars): Do not call gfc_add_in_common
for symbols that are USE associated or used in a submodule.

gcc/testsuite/ChangeLog:

PR fortran/111880
* gfortran.dg/pr111880.f90: New test.

(cherry picked from commit c9d029ba2ceb435e31492c1f3f0fd3edf0e386be)

[Bug fortran/112764] Associating entity does not have target attribute if selector has pointer attribute in associate block

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

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

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

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

commit r13-8110-gdd5d399fc16ebe7a1a2b13ae8cb888d619af695c
Author: Harald Anlauf 
Date:   Wed Nov 29 21:47:24 2023 +0100

Fortran: fix TARGET attribute of associating entity in ASSOCIATE [PR112764]

The associating entity in an ASSOCIATE construct has the TARGET attribute
if and only if the selector is a variable and has either the TARGET or
POINTER attribute (e.g. F2018:11.1.3.3).

gcc/fortran/ChangeLog:

PR fortran/112764
* primary.cc (gfc_variable_attr): Set TARGET attribute of
associating
entity dependent on TARGET or POINTER attribute of selector.

gcc/testsuite/ChangeLog:

PR fortran/112764
* gfortran.dg/associate_62.f90: New test.

(cherry picked from commit 951a3e3749a9bf15cea3940ad4bd76d696e1b0b6)

[Bug c++/112789] Missing clang __builtin_ctzs for short

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

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

--- Comment #4 from Andrew Pinski  ---
So just for future reference __builtin_c[lt]zs is for short.

But with GCC 14 (trunk) added __builtin_ct[lt]g, there is no need to add
__builtin_c[lt]zs to GCC.

You could just do:

#if __has_builtin(__builtin_ctzg) && !__has_builtin(__builtin_ctzs)
#define ctzs(a) __builtin_ctzg((short)a)
#elif __has_builtin(__builtin_ctzs)
#define ctzs(a) __builtin_ctzs((short)a)
#else
#error implement fall back for not both cases
#endif

[Bug analyzer/112790] -Wanalyzer-deref-before-check false positives seen in Linux kernel due to inlining

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

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

David Malcolm  changed:

   What|Removed |Added

   Last reconfirmed||2023-11-30
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from David Malcolm  ---
Also affects gcc 13.2: https://godbolt.org/z/3WTrzGTTc

[Bug analyzer/112790] New: -Wanalyzer-deref-before-check false positives seen in Linux kernel due to inlining

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

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

Bug ID: 112790
   Summary: -Wanalyzer-deref-before-check false positives seen in
Linux kernel due to inlining
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

https://godbolt.org/z/4fjjcfbPb

False positive on:

typedef unsigned char u8;
struct inode {
  void *i_mapping;
  u8 i_blkbits;
};
struct block_device {
  struct inode *bd_inode;
};
int sync_blockdev(struct block_device *bdev);
int set_blocksize(struct block_device *bdev, u8 size) {
  if (bdev->bd_inode->i_blkbits != size) {
sync_blockdev(bdev);
  }
  return 0;
}
extern int filemap_write_and_wait(void *);
int sync_blockdev(struct block_device *bdev) {
  if (!bdev)
return 0;
  return filemap_write_and_wait(bdev->bd_inode->i_mapping);
}

$ xgcc B. -Wall -fno-delete-null-pointer-checks -O2 -fanalyzer -g -S 

False positive:

In function ‘sync_blockdev’,
inlined from ‘set_blocksize’ at t.c:12:5:
t.c:18:6: warning: check of ‘bdev’ for NULL after already dereferencing it
[-Wanalyzer-deref-before-check]
   18 |   if (!bdev)
  |  ^
  ‘set_blocksize’: events 1-4
|
|   11 |   if (bdev->bd_inode->i_blkbits != size) {
|  |  ~^~
|  |  ||
|  |  |(1) pointer ‘bdev’ is dereferenced here
|  |  (2) following ‘true’ branch...
|   12 | sync_blockdev(bdev);
|  | ~
|  | |
|  | (3) ...to here
|  | (4) inlined call to ‘sync_blockdev’ from ‘set_blocksize’
|
+--> ‘sync_blockdev’: event 5
   |
   |   18 |   if (!bdev)
   |  |  ^
   |  |  |
   |  |  (5) pointer ‘bdev’ is checked for NULL here but it was
already dereferenced at (1)
   |

The check from the inlined function shouldn't lead to this warning.

All of "-fno-delete-null-pointer-checks -O2 -fanalyzer -g" seem to be
necessary.

(reduced from block/bdev.c)

[Bug middle-end/112572] [14 regression] LLVM miscompiled since r14-5355-g3cd3a09b3f91a1

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

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

--- Comment #29 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #28)
> So, what is the state here?  Andrew, are you going to post the #c18 patch?
> Do we have a reduced testcase?

I was hoping someone else would take over since there seems to be a
disagreement of if the bug is in compare-elim or in postreload pass.

As far as a reduced testcase, I don't think we have one.

[Bug middle-end/112572] [14 regression] LLVM miscompiled since r14-5355-g3cd3a09b3f91a1

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

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

--- Comment #28 from Jakub Jelinek  ---
So, what is the state here?  Andrew, are you going to post the #c18 patch?
Do we have a reduced testcase?

[Bug c++/112789] Missing clang __builtin_ctzs for short

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

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

--- Comment #3 from Andrew Pinski  ---
Also clang does not even document __builtin_ctzs anywhere ...

[Bug fortran/112772] Some issues with OPTIONAL, ALLOCATABLE dummy arguments

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
Fix for first testcase submitted:

https://gcc.gnu.org/pipermail/fortran/2023-November/059976.html

[Bug c++/112789] Missing clang __builtin_ctzs for short

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #2 from Andrew Pinski  ---
Anyways GCC 14 adds __builtin_ctzg, __builtin_stdc_first_trailing_one, and
__builtin_stdc_trailing_zeros :
https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index-_005f_005fbuiltin_005fctzg

[Bug target/112753] [14 Regression] unrecognizable insn building glibc for s390x

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Last reconfirmed||2023-11-30
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

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

Full patch I'm going to bootstrap/regtest now.