[Bug sarif-replay/96032] RFE: add a way to use output from --fdiagnostics-format=json or sarif as input

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #9 from Sam James  ---
(In reply to Kamil Dudka from comment #8)
> Where can one get the sarif-replay tool?  It does not seem to be included in
> gcc-latest.

I just wondered the same: you need to build with --enable-libdiagnostics.

[Bug sarif-replay/96032] RFE: add a way to use output from --fdiagnostics-format=json or sarif as input

[kdudka at redhat dot com via Gcc-bugs]

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

--- Comment #8 from Kamil Dudka  ---
Where can one get the sarif-replay tool?  It does not seem to be included in
gcc-latest.

[Bug analyzer/117667] -flto=auto prevents -fanalyzer from reporting any warnings on a build of systemd

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #5 from Richard Biener  ---
-fanalyzer handling could be added to lto-wrapper.cc:merge_and_complain
which can then arrange for it to be passed to the link phase.  You "only"
need to decide what to do if some TUs had -fanalyzer but others had not ...
-fanalyzer isn't Optimization and thus not recorded on a per-function basis
(not is -fanalyzer likely able to handle some functions analyzed and some not).

A user-friendly way might be to add -fanalyzer when all TUs had it set and
diagnose (and ignore) -fanalyzer if not all had it set and also the
linker command line doesn't have it set.

[Bug ipa/117668] fold_marked_statements in tree-inline.cc does not purge the abnormal edges after folding

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

[Bug ipa/117668] New: fold_marked_statements in tree-inline.cc does not purge the abnormal edges after folding

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

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

Bug ID: 117668
   Summary: fold_marked_statements in tree-inline.cc does not
purge the abnormal edges after folding
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: internal-improvement, missed-optimization
  Severity: enhancement
  Priority: P3
 Component: ipa
  Assignee: pinskia at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

While deciding on how to fix PR 117665, I saw that fold_marked_statements does
not purge the abnormal edges after the folding.

See https://gcc.gnu.org/PR117665#c8 for a patch which I didn't think was the
best though.

I will handle this later on.

[Bug c++/117669] New: RISC-V:The 'VEEWTRUNC4' iterator 'RVVMF2BF' type condition error

[sundongya at nucleisys dot com via Gcc-bugs]

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

Bug ID: 117669
   Summary: RISC-V:The 'VEEWTRUNC4' iterator 'RVVMF2BF' type
condition error
   Product: gcc
   Version: 14.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sundongya at nucleisys dot com
  Target Milestone: ---

Hi,
While studying the bf16 type within the RISC-V related code, I noticed a
potential discrepancy in the vector-iterators.md file, specifically within the
"VEEWTRUNC4" iterator concerning the condition for "RVVMF2BF". The existing
code is as follows:

(RVVM2BF "TARGET_VECTOR_ELEN_BF_16")
(RVVM1BF "TARGET_VECTOR_ELEN_BF_16")
(RVVMF2BF "TARGET_VECTOR_ELEN_FP_16")
(RVVMF4BF "TARGET_VECTOR_ELEN_BF_16 && TARGET_MIN_VLEN > 32 && TARGET_64BIT")

It seems that the constraint for RVVMF2BF should ideally be
"TARGET_VECTOR_ELEN_BF_16". I hope this observation can be of some help in
enhancing the accuracy of our code.

[Bug target/117525] [15 Regression] canvas.cc:1675:1: internal compiler error: in expand_fix, at optabs.cc:5952 since r15-2890

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

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #16 from Eric Botcazou  ---
The SPARC port also uses the double "fix" and that's the correct reading of the
description in rtl.def: "Value is defined only when the operand's value is an
integer." so IMO the regression should be fixed in the middle-end instead.

[Bug ada/117569] predicate involving array indexing rejected in generic package

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

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|Predicate involving array   |predicate involving array
   |indexing won’t compile in   |indexing rejected in
   |generic |generic package
   Last reconfirmed||2024-11-19

--- Comment #1 from Eric Botcazou  ---
Unexpected, bit hopefully easy to fix.

[Bug ada/117569] predicate involving array indexing rejected in generic package

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

[Bug target/117665] [15 regression] ICE when building crypto++ (single_succ_edge, at basic-block.h:332)

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

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

--- Comment #11 from Andrew Pinski  ---
Created attachment 59631
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59631&action=edit
Better testcase just so don't use aarch64 builtins directly

[Bug target/117665] [15 regression] ICE when building crypto++ (single_succ_edge, at basic-block.h:332)

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug target/117657] [15 Regression][gcn] ICE during in-tree newlib build: error: unrecognizable insn

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

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

--- Comment #6 from Andrew Stubbs  ---
The patch changed the wrong operand on the gen_gather_insn_1offset_exec
call. It sets one of the offsets undefined instead of setting the else value
undefined.

I'm testing a fix.

[Bug libstdc++/117630] Useless atexit entry for generic_category_instance and system_category_instance

[rdiez-2006 at rd10 dot de via Gcc-bugs]

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

R. Diez  changed:

   What|Removed |Added

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

--- Comment #15 from R. Diez  ---
I have started using -fno-use-cxa-atexit when building the toolchain (for
libstdc++), which makes this problem go away, as global destructors are no
longer registered with atexit calls.

This is not an ideal solution, because -fno-use-cxa-atexit has its issues, but
it works for my purposes.

I still think there is something iffy with GCC in this area, but I cannot
devote any more time to this issue, so I have decided to close this bug report.

[Bug c++/117672] New: Remove unused virtual methods

[rdiez-2006 at rd10 dot de via Gcc-bugs]

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

Bug ID: 117672
   Summary: Remove unused virtual methods
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rdiez-2006 at rd10 dot de
  Target Milestone: ---

GCC does not remove unused virtual methods, not even with LTO.

This shortcoming is known since a long time, but I could not find any Bugzilla
bug in order to track it easily.

Clang has allegedly options like -fvirtual-function-elimination and
-fwhole-program-vtables to that effect.

GCC 3.1 had option -fvtable-gc for that purpose, but I think it was removed
because it was not reliable.

[Bug c/117059] Enhancement: Make -Wzero-as-null-pointer-constant available in C

[alx at kernel dot org via Gcc-bugs]

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

--- Comment #10 from Alejandro Colomar  ---
Do we warn about enum/_Bool (PR112556) with this?  My computer with which I
work with GCC is having a hardware failure and I can't use it until 3 weeks
from now when a new piece arrives.

[Bug c++/117672] Remove unused virtual methods

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

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

--- Comment #1 from Sam James  ---
Please give a testcase.

[Bug target/117657] [15 Regression][gcn] ICE during in-tree newlib build: error: unrecognizable insn

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

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

--- Comment #7 from Robin Dapp  ---
Thanks, I was just about to write that I managed to build and would start to
look into it.

[Bug ada/117538] Tracebacks don’t include the load address of PIE executables

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

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

Eric Botcazou  changed:

   What|Removed |Added

   Severity|normal  |enhancement
 CC||ebotcazou at gcc dot gnu.org
   Last reconfirmed||2024-11-19
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #4 from Eric Botcazou  ---
Other OSes do support position-independent executables of course and the load
address is already printed for them, so that's specific to Darwin.

[Bug rtl-optimization/117297] [15 Regression] late combine undoes too much

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

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

--- Comment #4 from GCC Commits  ---
The trunk branch has been updated by Richard Sandiford :

https://gcc.gnu.org/g:387dba05e4207fc3f9a2f2bcb09a343a999c76fc

commit r15-5443-g387dba05e4207fc3f9a2f2bcb09a343a999c76fc
Author: Richard Sandiford 
Date:   Tue Nov 19 10:19:24 2024 +

Avoid repeated calls to temporarily_undo_changes [PR117297]

In an attempt to reduce compile time, rtl-ssa computes the cost
of existing instructions lazily rather than eagerly.  However,
this means that it might need to calculate the cost of an existing
instruction while a change group is already in progress for the
instruction.  rtl_ssa::insn_info::calculate_cost therefore temporarily
undoes any in-progress changes in order to get back the original pattern
and insn code.

rtl-ssa's main use of insn costs is in rtl_ssa::changes_are_worthwhile,
which calculates the cost of a change involving an arbitrary number
of instructions.  Summing up the original cost of N instructions
while those N instructions have in-progress changes could lead to
O(N*N) rtl changes, since each lazy calculation might have to
temporarily undo the changes to all N instructions.

We can avoid that by converting the current temporarily_undo_changes/
redo_changes pair into an RAII class and extending it to allow
nested uses.  rtl_ssa::changes_are_worthwhile can then undo the
in-progress changes once, before computing the original cost of all
the instructions.

gcc/
PR rtl-optimization/117297
* recog.h (temporarily_undo_changes, redo_changes): Delete in
favor of...
(undo_recog_changes): ...this new RAII class.
* fwprop.cc (should_replace_address): Update accordingly.
(fwprop_propagation::check_mem): Likewise.
(try_fwprop_subst_note): Likewise.
(try_fwprop_subst_pattern): Likewise.
* rtl-ssa/insns.cc (insn_info::calculate_cost): Likewise.
* rtl-ssa/changes.cc (rtl_ssa::changes_are_worthwhile): Temporarily
undo all in-progress changes while computing the cost of the
original
sequence.
* recog.cc (temporarily_undone_changes): Replace with...
(undo_recog_changes::s_num_changes): ...this static member
variable.
(validate_change_1): Update check accordingly.
(confirm_change_group): Likewise.
(num_validated_changes): Likewise.
(temporarily_undo_changes): Replace with...
(undo_recog_changes::undo_recog_changes): ...this constructor.
(redo_changes): Replace with...
(undo_recog_changes::~undo_recog_changes): ...this destructor.

[Bug rtl-optimization/117297] [15 Regression] late combine undoes too much

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

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

Richard Sandiford  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Sandiford  ---
Fixed.  Thanks for catching this before the release.

[Bug libdiagnostics/117670] New: installation of sarif-replay doesn't honor prefix and suffixes

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

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

Bug ID: 117670
   Summary: installation of sarif-replay doesn't honor prefix and
suffixes
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libdiagnostics
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

the installation of sarif-replay doesn't honor prefix and suffixes, configured
with e.g.

 --program-suffix=-15
 --program-prefix=x86_64-linux-gnu-

[Bug tree-optimization/117671] New: unroll estimate does not take into account later undef stmt removal

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

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

Bug ID: 117671
   Summary: unroll estimate does not take into account later undef
stmt removal
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

c-c++-common/ubsan/unreachable-3.c does

struct snic {
unsigned int wq_count;
struct vnic_wq_ctrl *wq[1];
int wq_lock[1];
};
void snic_log_q_error(struct snic *snic)
{
unsigned int i;
for (i = 0; i < snic->wq_count; i++)
ioread32(&snic->wq[i]->error_status);
}

and cunroll sees

   [local count: 536870912]:
  # i_13 = PHI 
  __builtin___sanitizer_cov_trace_pc ();
  _1 = snic_7(D)->wq[i_13];
  _2 = &_1->error_status;
  ioread32 (_2);
  i_9 = i_13 + 1;
  _3 = snic_7(D)->wq_count;
  if (_3 > i_9)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 268435456]:
  goto ; [100.00%]

when estimating sizes we do not consider that we later mark

  _1 = snic_7(D)->wq[1];

and everything below as unreachable ().  For this reason the above testcase
will be XFAILed with one of my incoming patches to better handle stmts
with side-effects (in the above case the ioread32 call).

[Bug target/107704] [13/14/15 Regression] Testsuite regression after recent DCE changes

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

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

--- Comment #9 from Richard Sandiford  ---
That's because clobbers of hard-coded registers have usually been treated as
kind-of an earlyclobbers:

-
When a @code{clobber} expression for a register appears inside a
@code{parallel} with other side effects, the register allocator
guarantees that the register is unoccupied both before and after that
insn if it is a hard register clobber.
-

This is also modelled by the ira-live.cc code:

/* Mark early clobber hard registers of the current INSN as live (if
   LIVE_P) or dead.  Return true if there are such registers.  */
static bool
mark_hard_reg_early_clobbers (rtx_insn *insn, bool live_p)
{
  df_ref def;
  bool set_p = false;

  FOR_EACH_INSN_DEF (def, insn)
if (DF_REF_FLAGS_IS_SET (def, DF_REF_MUST_CLOBBER))
  {
rtx dreg = DF_REF_REG (def);

if (GET_CODE (dreg) == SUBREG)
  dreg = SUBREG_REG (dreg);
if (! REG_P (dreg) || REGNO (dreg) >= FIRST_PSEUDO_REGISTER)
  continue;

/* Hard register clobbers are believed to be early clobber
   because there is no way to say that non-operand hard
   register clobbers are not early ones.  */
if (live_p)
  mark_ref_live (def);
else
  mark_ref_dead (def);
set_p = true;
  }

  return set_p;
}

I think the .md pattern either has to treat both appearances of the T register
as operands or hard-code both of them.

[Bug target/117562] [15 Regression] 40% slowdown of 482.sphinx3 on Zen4, Zen5 since r15-5120-g9a62c149589103

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2024-11-19
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #3 from Richard Biener  ---
I'll do actual benchmarking and see what happens during stage3.

[Bug middle-end/117571] [15 Regression] ICE: in lower_stmt, at gimple-lower-bitint.cc:5714 at -O1 with _BitInt() shift and divide due to r15-4601

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

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

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

https://gcc.gnu.org/g:758d2b3d3e28c831c79f5c18727d149c81896434

commit r15-5440-g758d2b3d3e28c831c79f5c18727d149c81896434
Author: Jakub Jelinek 
Date:   Tue Nov 19 10:25:04 2024 +0100

bitintlower: Handle EXACT_DIV_EXPR like TRUNC_DIV_EXPR in bitint lowering
[PR117571]

r15-4601 added match.pd simplification of some TRUNC_DIV_EXPR expressions
into EXACT_DIV_EXPR, so bitintlower can now encounter even those.
From bitint lowering POV the fact that the division will be exact
doesn't matter, we still need to call at runtime the __divmodbitint4
API and it wouldn't simplify there anything to know it is exact if
we duplicated that, so the following patch lowers EXACT_DIV_EXPR exactly
as TRUNC_DIV_EXPR.

I think we don't need to backport this unless something introduces
EXACT_DIV_EXPR on BITINT_TYPEd expressions on the 14 branch as well.

2024-11-19  Jakub Jelinek  

PR middle-end/117571
* gimple-lower-bitint.cc (bitint_large_huge::lower_muldiv_stmt,
bitint_large_huge::lower_stmt, stmt_needs_operand_addr,
build_bitint_stmt_ssa_conflicts, gimple_lower_bitint): Handle
EXACT_DIV_EXPR like TRUNC_DIV_EXPR.

* gcc.dg/bitint-114.c: New test.

[Bug middle-end/117571] [15 Regression] ICE: in lower_stmt, at gimple-lower-bitint.cc:5714 at -O1 with _BitInt() shift and divide due to r15-4601

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug middle-end/116997] [13 Regression] Wrong bitfield accesses since r13-3219-g25413fdb2ac249

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

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

--- Comment #11 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Andre Simoes Dias Vieira
:

https://gcc.gnu.org/g:57df36f0365218987fe3565523d4c272935a6561

commit r13-9200-g57df36f0365218987fe3565523d4c272935a6561
Author: Andre Vieira 
Date:   Mon Oct 14 16:24:07 2024 +0100

fold-const: Fix BIT_INSERT_EXPR folding for BYTES_BIG_ENDIAN [PR116997]

Fix constant folding of BIT_INSER_EXPR for BYTES_BIG_ENDIAN targets.

gcc/ChangeLog:

PR middle-end/116997
* fold-const.cc (fold_ternary_loc): Fix BIT_INSERT_EXPR constant
folding
for BYTES_BIG_ENDIAN targets.

gcc/testsuite/ChangeLog:

* gcc.dg/vect/pr116997.c: New test.

Co-authored-by: Andrew Pinski 
(cherry picked from commit 2e30e90a0c2bf8147a6d24854aa653c332c8f84f)

[Bug middle-end/117459] ICE: in lower_stmt, at gimple-lower-bitint.cc:5714 with __builtin_assoc_barrier() on _BitInt(255)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug middle-end/117458] ICE: in gen_lowpart_general, at rtlhooks.cc:63 when reinterpreting _Complex float as _BitInt(33)

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

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

--- Comment #5 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug middle-end/117458] ICE: in gen_lowpart_general, at rtlhooks.cc:63 when reinterpreting _Complex float as _BitInt(33)

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

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

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

https://gcc.gnu.org/g:694613a7f9adfa9c87e733adc63839c8801f2b5c

commit r15-5442-g694613a7f9adfa9c87e733adc63839c8801f2b5c
Author: Jakub Jelinek 
Date:   Tue Nov 19 10:26:44 2024 +0100

expand: Fix up ICE on VCE from _Complex types to _BitInt [PR117458]

extract_bit_field can't handle extraction of non-mode precision
from complex mode operands which don't live in memory, e.g. gen_lowpart
crashes on those.
The following patch in that case defers the extract_bit_field call
until op0 is forced into memory.

2024-11-19  Jakub Jelinek  

PR middle-end/117458
* expr.cc (expand_expr_real_1) : Don't
call extract_bit_field if op0 has complex mode and isn't a MEM,
instead first force op0 into memory and then call
extract_bit_field.

* gcc.dg/bitint-116.c: New test.

[Bug ada/117517] internal error on reduce attribute with swapped arguments

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

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

Eric Botcazou  changed:

   What|Removed |Added

Summary|Reduce attribute creates|internal error on reduce
   |bug |attribute with swapped
   ||arguments
   Last reconfirmed|2024-11-10 00:00:00 |2024-11-19
   Keywords||ice-on-invalid-code
 Ever confirmed|0   |1
 CC||ebotcazou at gcc dot gnu.org
   Severity|normal  |minor
 Status|UNCONFIRMED |NEW

--- Comment #2 from Eric Botcazou  ---
The compiler is as confused as the programmer here, but we should give a proper
error message instead of an ICE.  The proper syntax is:

  B : Positive := A'Reduce (Positive'Max, 1);

[Bug ada/117517] internal error on reduce attribute with swapped arguments

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

[Bug middle-end/117459] ICE: in lower_stmt, at gimple-lower-bitint.cc:5714 with __builtin_assoc_barrier() on _BitInt(255)

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

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

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

https://gcc.gnu.org/g:600cab162c561c3061317c998972b0ed1b681d5b

commit r15-5441-g600cab162c561c3061317c998972b0ed1b681d5b
Author: Jakub Jelinek 
Date:   Tue Nov 19 10:25:57 2024 +0100

bitintlower: Handle PAREN_EXPR [PR117459]

The following patch handles PAREN_EXPR in bitint lowering, and handles it
as an optimization barrier, so that temporary arithmetics from PAREN_EXPR
isn't mixed with temporary arithmetics from outside of the PAREN_EXPR.

2024-11-19  Jakub Jelinek  

PR middle-end/117459
* gimple-lower-bitint.cc (bitint_large_huge::handle_stmt,
bitint_large_huge::lower_stmt): Handle PAREN_EXPR.

* gcc.dg/torture/bitint-74.c: New test.

[Bug target/117562] [15 Regression] 40% slowdown of 482.sphinx3 on Zen4, Zen5 since r15-5120-g9a62c149589103

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

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

--- Comment #2 from Hongtao Liu  ---
My guess there's a lower-tripcount(< 128bit vector) hot loop,
avx512_two_epilogues only takes more cmp/jcc instructions but doesn't execute
any real vector instructions.

[Bug c/112556] Null pointer constants with enumeration type are not accepted

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

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

Sam James  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |sjames at gcc dot 
gnu.org
 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #9 from Sam James  ---
Mine for the backport.

[Bug tree-optimization/87031] [12/13/14/15 Regression] nios2 optimization for size - two cases of regression relatively to 5.3.0 (loop unrolling)

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #9 from Richard Biener  ---
The recent r15-919-gef27b91b62c3aa left the

  /* If the code is going to shrink, we don't need to be extra
 cautious on guessing if the unrolling is going to be
 profitable.
 Move from estimated_unrolled_size to unroll small loops.  */
  if (unr_insns * 2 / 3 
  /* If there is IV variable that will become constant, we
 save one instruction in the loop prologue we do not
 account otherwise.  */
  <= ninsns + (size.constant_iv != false))
;

case alone but applied the 'cunrolli' flag restriction only to the
param_max_completely_peeled_insns limit applied later:

  /* Move 2 / 3 reduction from estimated_unrolled_size, but don't
reduce
 unrolled size for innermost loop.
 1) It could increase register pressure.
 2) Big loop after completely unroll may not be vectorized
 by BB vectorizer.  */
  else if ((cunrolli && !loop->inner
? unr_insns : unr_insns * 2 / 3)
   > (unsigned) param_max_completely_peeled_insns)
{
  if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file, "Not unrolling loop %d: "
 "number of insns in the unrolled sequence reaches "
 "--param max-completely-peeled-insns limit.\n",
 loop->num);
  return false;

One could either re-use that flag also for the loop-gets-smaller check
for consistency or argue that if loop->inner the 2/3 estimate is likely
off anyway.

Note the check above explicitly considers a loop with an inner loop
to shrink optimistically.

I'm testing what happens if guarding the former condition with cunrolli
for half-consistency.

[Bug c/112556] Null pointer constants with enumeration type are not accepted

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

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

Sam James  changed:

   What|Removed |Added

 Status|REOPENED|ASSIGNED

[Bug target/106240] [13/14/15 Regression] missed vectorization opportunity (cond move) on mips since r13-707-g68e0063397ba82

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
 CC||syq at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=114189
   Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot 
gnu.org

--- Comment #9 from Richard Biener  ---
Indeed the suggestion will no longer work and instead mips has to provide
vec_cmp/vcond_mask patterns instead (in principle, for integer vector mode
vec_cmp the middle-end could synthesize the blend which the vcond_mask is
itself as fallback, but usually ISAs have a blend).

I'm leaving this as target specific bug, but it's really PR114189.  I'm
not working on fixing the mips machine description (you might copy from
the loongson solution).

[Bug debug/109161] Bad CTF generated for stub in function scope

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

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

Sam James  changed:

   What|Removed |Added

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

[Bug rtl-optimization/53533] [12/13/14/15 regression] vectorization causes loop unrolling test slowdown as measured by Adobe's C++Benchmark

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Target Milestone|12.5|13.0
 Resolution|--- |FIXED
  Known to work||13.1.0

--- Comment #54 from Richard Biener  ---
Fixed I'd say?

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

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

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

Bug 53533 Summary: [12/13/14/15 regression] vectorization causes loop unrolling 
test slowdown as measured by Adobe's C++Benchmark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533

   What|Removed |Added

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

[Bug target/43908] Unnecessary mov of a constant after unrolling.

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

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

Richard Biener  changed:

   What|Removed |Added

  Component|rtl-optimization|target
Summary|Redundant conditionals [4.5 |Unnecessary mov of a
   |only] - unnecessary mov of  |constant after unrolling.
   |a constant after unrolling. |
   Last reconfirmed|2021-07-26 00:00:00 |2024-11-19

--- Comment #2 from Richard Biener  ---
I can still see the redundant load of #1 with a trunk compiler build in April
2024:

sigh:   
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
mov r3, #1
tst r1, #1
streq   r3, [r0, #4]
strne   r3, [r0]
mov r3, #1
tst r1, #2
streq   r3, [r0, #4]
strne   r3, [r0]
mov r3, #1
tst r1, #4
streq   r3, [r0, #4]
strne   r3, [r0]
mov r3, #1
tst r1, #8
streq   r3, [r0, #4]
strne   r3, [r0]
mov r3, #1
tst r1, #16
streq   r3, [r0, #4]
strne   r3, [r0]
mov r3, #1
tst r1, #32
streq   r3, [r0, #4]
strne   r3, [r0]
mov r3, #1
tst r1, #64
streq   r3, [r0, #4]
strne   r3, [r0]
mov r3, #1
tst r1, #128
strne   r3, [r0]
streq   r3, [r0, #4]
bx  lr

in particular we also fail to apply conditional store-motion (we refuse
because the access can trap).  Enabling that makes somewhat a mess
out of the code though.

I'm quite sure the mov issue is a target issue.

[Bug ipa/117672] Remove unused virtual methods

[rdiez-2006 at rd10 dot de via Gcc-bugs]

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

--- Comment #3 from R. Diez  ---
This is an example:

class test_class
{
public:
  // The mere existence of this empty constructor is enough
  // to make GCC generate an empty _GLOBAL__sub_I_main block
  // and to keep all unused virtual methods.
  test_class ( void )
  {
  }

  virtual int unused1 ( void ) { return 1; }
  virtual int unused2 ( void ) { return 2; }
  virtual int unused3 ( void ) { return 3; }
  virtual int unused4 ( void ) { return 4; }
  virtual int unused5 ( void ) { return 5; }
};

static test_class test_instance;

int main ( void )
{
}


You can play with it here:  https://godbolt.org/z/EPco45T3f

[Bug ipa/117672] Remove unused virtual methods

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org
  Component|c++ |ipa

--- Comment #2 from Richard Biener  ---
I think we internalize vtables but we are not good at pruning initialization to
actual uses (I'm not sure we understand the concept of a vtable enough to do
better than treating it like a C equivalent).

If we cannot internalize the vtable I'm not sure the comdat layout would allow
externalizing unused parts.

[Bug rtl-optimization/15513] loop peeling failed becuase of non-constant start

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

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

Bug 10624 Summary: unroll-loops can't unroll nested constant loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10624

   What|Removed |Added

 Status|SUSPENDED   |RESOLVED
 Resolution|--- |FIXED

[Bug target/117657] [15 Regression][gcn] ICE during in-tree newlib build: error: unrecognizable insn

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

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Andrew Stubbs :

https://gcc.gnu.org/g:234da38a0e68a204a59562fcca2aa6d297bc21ed

commit r15-5459-g234da38a0e68a204a59562fcca2aa6d297bc21ed
Author: Andrew Stubbs 
Date:   Tue Nov 19 12:01:22 2024 +

amdgcn: Fix build failure (PR117657)

The last patch did the right thing to the wrong parameter, which caused a
build
failure in Newlib.  This patch fixes it.

gcc/ChangeLog:

PR target/117657
* config/gcn/gcn-valu.md (mask_gather_load): Fix bug in
maskload else patch.

[Bug c/117490] Invalid TBAA for structures without tag and compatible definition in C.

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

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

--- Comment #10 from GCC Commits  ---
The master branch has been updated by Martin Uecker :

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

commit r15-5470-g8b02cc9a4f2b8db48da2a3460655b062eaa147ba
Author: Martin Uecker 
Date:   Fri Nov 8 18:46:10 2024 +0100

c: fix incorrect TBAA for tagged types across translation units [PR117490]

Two different declarations of tagged types in the same translation unit
are incompatible in C before C23 and without tag also in C23.  Still,
two such types can be compatible to the same tagged type in a different
translation unit, but this means that pointers can alias.

typedef struct { int i; } s1;
typedef struct { int i; } s2;

int f(s1 *p1, s2 *p2)
{
  p1->i = 2;
  p2->i = 3; // p2->i can alias p1->i
  return p1->i;
}

We need to assign the same TYPE_CANONICAL to both types.  This patch fixes
this for C23 and types without tag by also forming equivalence classes for
such types based on their structure as already done for types with tag.
Because this change exposes checking errors related to flexible array
members (cf. PR113688), one test is restricted to C17 for now.

PR c/117490

gcc/c/ChangeLog:
* c-typeck.cc (tagged_types_tu_compatible): Form equivalence
classed for tagless types in C23.

gcc/testsuite/ChangeLog:
* gcc.dg/gnu23-tag-alias-4.c: Adapt test.
* gcc.dg/gnu23-tag-alias-7.c: Adapt test.
* gcc.dg/guality/zero-length-array.c: Restrict to c17.
* gcc.dg/pr117490.c: New test.

[Bug testsuite/52641] Test cases fail for 16-bit int targets

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

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

--- Comment #30 from GCC Commits  ---
The master branch has been updated by Georg-Johann Lay :

https://gcc.gnu.org/g:780720f04b0b83261d6073b92f3b02e8fbef41b9

commit r15-5471-g780720f04b0b83261d6073b92f3b02e8fbef41b9
Author: Georg-Johann Lay 
Date:   Tue Nov 19 19:32:24 2024 +0100

testsuite/52641 - Skip test cases that are not 16-bit clean.

gcc/testsuite/
PR testsuite/52641
PR testsuite/116488
PR testsuite/116915
* gcc.dg/torture/pr116488.c: Require int32plus.
* gcc.dg/torture/pr116915.c: Require int32plus.

[Bug ipa/117668] fold_marked_statements in tree-inline.cc does not purge the abnormal edges after folding

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Richard Biener from comment #1)
> Note this should really be catched by CFG verification.

Yes Though I am worried there are many places where this kind of handling is
missing.

[Bug rtl-optimization/116915] [15 Regression] wrong code at -O{s,2,3} on x86_64-linux-gnu

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Georg-Johann Lay :

https://gcc.gnu.org/g:780720f04b0b83261d6073b92f3b02e8fbef41b9

commit r15-5471-g780720f04b0b83261d6073b92f3b02e8fbef41b9
Author: Georg-Johann Lay 
Date:   Tue Nov 19 19:32:24 2024 +0100

testsuite/52641 - Skip test cases that are not 16-bit clean.

gcc/testsuite/
PR testsuite/52641
PR testsuite/116488
PR testsuite/116915
* gcc.dg/torture/pr116488.c: Require int32plus.
* gcc.dg/torture/pr116915.c: Require int32plus.

[Bug rtl-optimization/116488] [15 Regression] wrong code at -O{s,2,3} with "-fno-forward-propagate" on x86_64-linux-gnu

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

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

--- Comment #14 from GCC Commits  ---
The master branch has been updated by Georg-Johann Lay :

https://gcc.gnu.org/g:780720f04b0b83261d6073b92f3b02e8fbef41b9

commit r15-5471-g780720f04b0b83261d6073b92f3b02e8fbef41b9
Author: Georg-Johann Lay 
Date:   Tue Nov 19 19:32:24 2024 +0100

testsuite/52641 - Skip test cases that are not 16-bit clean.

gcc/testsuite/
PR testsuite/52641
PR testsuite/116488
PR testsuite/116915
* gcc.dg/torture/pr116488.c: Require int32plus.
* gcc.dg/torture/pr116915.c: Require int32plus.

[Bug ipa/117672] Remove unused virtual methods

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
.

[Bug target/116590] unrecognized opcode th.vmv8r.v th.vfrec7.v when compiling for risc-v xtheadvector

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||kito at gcc dot gnu.org

--- Comment #5 from Jeffrey A. Law  ---
So the trick here is to understand where the problematic instruction comes
from.  If you add "-dap" to the command line and look at the assembly you'll
see stuff like this:

th.vmv8r.v  v8,v16  # 90[c=4 l=4]  *pred_maccrvvm8sf_scalar/3
th.vfmacc.vfv8,fa5,v24

That tells you what insn is generating that code - pred_maccrvvm8sf_scalar. 
And if you look at that insn in the riscv backend you'll see that under certain
circumstances it will generate the vmv8r which apparently causes headaches.

As it turns out I was fixing a related problem last week.  Specifically we have
insns that are generating multiple instructions and that's something we should
generally avoid.  I fixed the integer versions of these patterns, but not the
floating point versions.

I'll take care of the problematical tm.vmv8r.v instructions.

I'm not sure how best to handle the recip estimator.  I think the first
question is whether or not that should have been dealt with at the intrinsic
level or not.  ie, should we have a recip estimator intrinsic available for
thead vector or not.  Kito might have some opinions on that.

[Bug c++/117684] New: High compiling time for array initialization

[Sebastien.Lemetter at de dot bosch.com via Gcc-bugs]

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

Bug ID: 117684
   Summary: High compiling time for array initialization
   Product: gcc
   Version: 8.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Sebastien.Lemetter at de dot bosch.com
  Target Milestone: ---

Created attachment 59637
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59637&action=edit
This is the code example which shows the bug. Just copy the file and run the
gcc command

Hi,

We have a complex data structure which should be initialized with non 0
(default) values. If we set the non default value, the compilation time goes
from less than 1s to 5min or more. 
We understand that initializing a large memory segment takes time, but
generating the binary code for doing this task should not last long.
Here is the command that we are using for compiling the code:
/usr/bin/g++-8 '-std=c++17' '-D_FORTIFY_SOURCE=2' -MD -MF main.d -g0 -O2
-DNDEBUG -Werror -c main.cpp -o main.o

Here is the exact version of the compiler we are using:
❯ /usr/bin/g++-8 --version
g++-8 (Ubuntu 8.4.0-3ubuntu2) 8.4.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE

Here is the OS version we are using:
❯ cat /etc/os-release
NAME="Ubuntu"
VERSION="20.04.5 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.5 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/";

[Bug ipa/117668] fold_marked_statements in tree-inline.cc does not purge the abnormal edges after folding

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Attachment #59635|0   |1
is obsolete||

--- Comment #4 from Andrew Pinski  ---
Created attachment 59636
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59636&action=edit
new patch

Whoops some small typos.

[Bug libstdc++/117686] New: [15 Regression] error in unordered_set::emplace

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

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

Bug ID: 117686
   Summary: [15 Regression] error in unordered_set::emplace
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#include 
#include 

struct desc { };
bool operator==(desc, desc) { return true; }

using P = std::pair;

template<> struct std::hash
{ size_t operator()(const P&) const { return 0; } };

int main()
{
  const desc d;
  std::unordered_set s;
  s.emplace(desc{}, desc{});
}



bits/hashtable.h:2282:40: error: cannot convert 'const std::pair*' to 'const std::_Hashtable, std::pair, std::allocator >, std::__detail::_Identity,
std::equal_to >, std::hash >,
std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits >::key_type*' {aka 'const std::pair*'} in assignment

[Bug libstdc++/117686] [15 Regression] error in unordered_set::emplace

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Priority|P3  |P1
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Target Milestone|--- |15.0
   Last reconfirmed||2024-11-19

--- Comment #1 from Jonathan Wakely  ---
https://bugs.gentoo.org/943940

[Bug c++/98992] attribute malloc error associating a member deallocator with an allocator

[rdiez-2006 at rd10 dot de via Gcc-bugs]

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

--- Comment #3 from R. Diez  ---
This is still broken in GCC 14.2.

The test code I am using is:

#include 

struct MyClass
{
  static void FreeMemory ( const void * pMem ) throw();

  __attribute__ (( malloc, malloc( MyClass::FreeMemory, 1 ) ))
  static void * AllocMemory ( size_t Size ) throw();
};

It is available here to play with:

https://godbolt.org/z/EP9x9T1Gv

GCC 11.4 accepts it, and GCC from 12.1 does not anymore. The godbolt.org
sandbox linked above compares GCC 11.4 with GCC 12.4, and version 14.2 still
does not work.

[Bug target/117690] New: RISC-V: Constant is miscompiled by zba extension

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

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

Bug ID: 117690
   Summary: RISC-V: Constant is miscompiled by zba extension
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kristerw at gcc dot gnu.org
  Target Milestone: ---

The following function returns 0x5fff9ffa instead of the expected
0x4fffaffb0fffefff when compiled as
  riscv64-unknown-linux-gnu-gcc -O2 -march=rv64gc_zba bug.c

unsigned long foo()
{
  return 0x4fffaffb0fffefffUL;
}

[Bug c/117687] Wzero-as-nullpointer-constant should warn for zeros of type bool, enum, and _BitInt

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
   Severity|normal  |enhancement
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-11-19

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

[Bug c++/61372] Add warning to detect noexcept functions that might throw [-Wnoexcept-mismatch]

[dcrocker at eschertech dot com via Gcc-bugs]

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

--- Comment #11 from David Crocker  ---
I've been bitten by this several times. In the absence of support for this type
of checking in GCC I added exception checking to our own homebrew static
analysis tool. It's already detected three situations in which invalid user
input would cause termination of our application instead of an error message,
due to a function throwing an exception when it was called from another
function that was declared noexcept.

I think removing more detailed exception specifications from C++ was a big
mistake. I can understand that in many applications they were not needed;
however in mission critical real-time applications that use exceptions in very
limited ways, such as the one we write, it's vital to know that any exception
thrown will be caught and handled, not cause termination.

[Bug c++/78216] Segfault when dealing with a parameter pack of member functions pointers

[gcc.gnu.org at ajryansolutions dot co.uk via Gcc-bugs]

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

Adam Ryan  changed:

   What|Removed |Added

 CC||gcc.gnu.org@ajryansolutions
   ||.co.uk

--- Comment #3 from Adam Ryan  ---
I think I am encountering the same issue. Here is a minimised example from the
code I was working on:


template using MemberFunction = void (T::*)(P);

template class MemberFunctions;
// template F> class
MemberFunctions
template...F> class
MemberFunctions
{
public: void apply( E e, bool value ){ e.write(value); }
};

class Writer{ public: void write( bool ){} };

int main()
{
MemberFunctions().apply( Writer(), true );
}


If the commented out line is put in place of the line below it then it compiles
fine so it is specifically the addition of the parameter packs that cause the
issue.
You can test this in godbolt (https://godbolt.org/) using the x86-64 gcc 14.2
compiler and also that when the compiler is set to x86-64 clang 19.1.0 it
compiles without issue.
If set to the trunk version of gcc it gives a stack trace to where it fails:


:15:1: internal compiler error: Segmentation fault
   15 | }
  | ^
0x28b0815 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x28c7515 internal_error(char const*, ...)
???:0
0xeb2898 symbol_table::decl_assembler_name_hash(tree_node const*)
???:0
0xeb6b14 symtab_node::get_for_asmname(tree_node const*)
???:0
0xeb6c31 symtab_node::verify_base()
???:0
0xec7e2d cgraph_node::verify_node()
???:0
0xeb77c4 symtab_node::verify()
???:0
0xeb89a7 symtab_node::verify_symtab_nodes()
???:0
0xed172b symbol_table::finalize_compilation_unit()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
Compiler returned: 1


I tried debugging it and when reaching here
https://gcc.gnu.org/git?p=gcc.git;a=blob;f=gcc/symtab.cc;h=762a6236ca1e199ab0b5aa78ba51624d72900ecd;hb=refs/heads/master#l1159
 
the MACRO DECL_ASSEMBLER_NAME is returning a null pointer for the assembler
name i.e (NODE)->decl_with_vis.assembler_name is not populated and null. Seems
to be related to set_decl_assembler_name in langhooks which I haven't gone into
so far.

I'd be interested to know if this is a bug or if it's a missing feature as if
it's not too big I'd have a go.

[Bug c++/61372] Add warning to detect noexcept functions that might throw [-Wnoexcept-mismatch]

[rdiez-2006 at rd10 dot de via Gcc-bugs]

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

--- Comment #12 from R. Diez  ---
I do not agree with the detailed exception specifications. Java tried and such
code is hard to maintain. I think all code should generally be able to cope
with any exceptions: either handle them, pass them up the call stack, or
perhaps both depending on the exception type.

But that opinion is not actually relevant in this case: I still agree that, if
a routine states that it will not throw at all, and it could, a warning should
be issued.

[Bug tree-optimization/35341] Early exit loop with short known trip count not unrolled

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||7.5.0
 Resolution|--- |FIXED

--- Comment #3 from Richard Biener  ---
I think this works as expected.  You can always use #pragma GCC unroll N to
override GCCs heuristics here.  As said, with -O3 we now completely peel the
loop.

[Bug analyzer/117677] [15 Regression] Regression in fail, at selftest.cc:47

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

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

--- Comment #1 from Matthias Klose  ---
20241116 succeeded to build

[Bug other/117678] as for RISC-V generates gobbledygook with unusual but valid label formatting

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #1 from Sam James  ---
`as` is from binutils. Please report this on the sourceware bugzilla.

[Bug sarif-replay/96032] RFE: add a way to use output from --fdiagnostics-format=json or sarif as input

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

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

--- Comment #10 from David Malcolm  ---
(In reply to Kamil Dudka from comment #8)
> Where can one get the sarif-replay tool?  It does not seem to be included in
> gcc-latest.

Sorry, I haven't updated the copr build; I'll look at doing that today.

[Bug libdiagnostics/117677] [15 Regression] Regression in fail, at selftest.cc:47

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
Does -Wfloat-equal warn about this? Maybe it'd be worth adding to the warnings
enabled when building GCC?

[Bug other/117678] New: as for RISC-V generates gobbledygook with unusual but valid label formatting

[lightningdzeyenr at gmail dot com via Gcc-bugs]

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

Bug ID: 117678
   Summary: as for RISC-V generates gobbledygook with unusual but
valid label formatting
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lightningdzeyenr at gmail dot com
  Target Milestone: ---

I have a package that generates RISC-V assembly that it then passes to as to
assemble. When as from gcc 14.2.0 processes the following RISC-V assembly

addi t0, zero, 10
addi t1, zero, 10

beq t0, t1, 8
j generated_label1
fadd.s fa0, fa0, fa1
generated_label1:

fsw fa0, 0(a0)

it produces the following result (from objdump -d):

 :
   0:   00a00293li  t0,10
   4:   00a00313li  t1,10
   8:   00629463bne t0,t1,10 
   c:   006fj   c 
  10:   0080006fj   18 
  14:   00b57553fadd.s  fa0,fa0,fa1

0018 :
  18:   00a52027fsw fa0,0(a0)

When running this binary code, it gets stuck on 006f for no good reason,
and the beq is now a bne. This issue does not happen if the labels have
indentation like you usually see in human-written assembly. However,
indentation is not required by the RISC-V standard, so that leaves this
assembled result as a bug. llvm-mc's disassembled output is exactly the same as
the input assembly.

[Bug ada/117538] Tracebacks don’t include the load address of PIE executables

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

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Eric Botcazou :

https://gcc.gnu.org/g:51d12cc4b608960469f6d36b03c45f9a39f7bdaa

commit r15-5469-g51d12cc4b608960469f6d36b03c45f9a39f7bdaa
Author: Eric Botcazou 
Date:   Tue Nov 19 18:45:51 2024 +0100

Enable symbolic backtraces on more Linux and BSD ports

gcc/ada
PR ada/117538
* Makefile.rtl (GNU Hurd): Add $(TRASYM_DWARF_UNIX_OBJS).
(x86-64 kfreebsd): Likewise.
(aarch64 FreeBSD): Likewise.
(x86-64 DragonFly): Likewise.
(S390 Linux): Likewise.
(Mips Linux): Likewise.
(SPARC Linux): Likewise.
(HP/PA Linux): Linux.
(M68K Linux): Likewise.
(SH4 Linux): Likewise.
(Alpha Linux): Likewise.
(RISC-V Linux): Likewise.

[Bug c++/117683] New: provide a way to remove all C++ class names from the binary

[rdiez-2006 at rd10 dot de via Gcc-bugs]

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

Bug ID: 117683
   Summary: provide a way to remove all C++ class names from the
binary
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rdiez-2006 at rd10 dot de
  Target Milestone: ---

I am writing embedded software for very resource-constrained microcontrollers,
and I have noticed that the C++ class names end up in the binary, even if never
used.

These class names have to do with the typeid operator and the std::type_info
class.

Example code:

class very_very_long_class_name_x
{
public:
  virtual void some_method ( void )
  {
  }
};

static const very_very_long_class_name_x
static_instance;

int main ( void )
{
  return 5;
}

Run this command to verify it:

$ g++ typeinfo.cpp  && strip a.out && strings a.out | grep very

55very_very_long_class_name_x

Tool 'objdump' prints this line for a.out:

2020  w  O  .rodata  003a typeinfo name for
very_very_long_class_name_x

This probably has to do with vtables, and is similar to bug 117672 ("Remove
unused virtual methods"). Once that bug is fixed, these class names may be
optimised away if unused.

There is a difference however: I would like to forcibly remove all those class
names from the binaries, in order to save program space (flash memory).

Class names can be rather long if nested classes and templates are involved.
Besides, I don't like having to shorten the names just to save memory.

I have read the following on the Internet:

-8<-8<-8<-
std::type_info::name

const char* name() const;

Returns an implementation defined null-terminated character string containing
the name of the type. No guarantees are given; in particular, the returned
string can be identical for several types and change between invocations of the
same program.
-8<-8<-8<-

Because there are no guarantees (allegedly), I am guessing it should be OK to
always return an empty string.

[Bug fortran/83135] Routines in submodules treat protected variables from other modules as public

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||accepts-invalid
 CC||anlauf at gcc dot gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
In gfc_check_vardef_context we have the following check:

  /* PROTECTED and use-associated.  */
  if (sym->attr.is_protected && sym->attr.use_assoc && check_intentin)
{
...

For the case at hand, the symbol in question has sym->attr.use_assoc = 0
but sym->attr.used_in_submodule=1 .  Replacing the central condition by
(sym->attr.use_assoc || sym->attr.used_in_submodule) however creates false
positives, unless we figure out that the symbol belongs to an ancestor of
the submodule.  I need to figure out how to do that...

[Bug target/54378] code bloat for long << shifts

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Georg-Johann Lay  ---
Fixed in v15

[Bug c++/117683] provide a way to remove all C++ class names from the binary

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||code-size

--- Comment #1 from Andrew Pinski  ---
You know most places which are size constraints ban the use of RTTI.

If you don't need RTTI, you can use the option -fno-rtti and that will not emit
these strings.

[Bug c++/117683] provide a way to remove all C++ class names from the binary

[rdiez-2006 at rd10 dot de via Gcc-bugs]

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

--- Comment #2 from R. Diez  ---

> You know most places which are size constraints ban the use of RTTI.

Popular belief is often wrong. See here for details:

https://github.com/rdiez/DebugDue?tab=readme-ov-file#about-c-exceptions

I am actually using C++ features and C++ exceptions in rather tight
environments. C++ exceptions actually tend to save code space compared with
"if(error)" checks all over the place.

There are other reasons why people may not want the class names in the
binaries:

https://stackoverflow.com/questions/23304820/strip-class-name-from-rtti

[Bug c/114869] [13/14/15 Regression] GCC says nullptr_t is a C built in but it should be in

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Joseph Myers :

https://gcc.gnu.org/g:933b146f0aac96b05cd5a7518929843f72c8b64a

commit r15-5476-g933b146f0aac96b05cd5a7518929843f72c8b64a
Author: Joseph Myers 
Date:   Tue Nov 19 21:31:24 2024 +

c: Do not register nullptr_t built-in type [PR114869]

As reported in bug 114869, the C front end wrongly creates nullptr_t
as a built-in typedef; it should only be defined in .  While
the type node needs a name for debug info generation, it doesn't need
to be a valid identifier; use typeof (nullptr) instead, similar to how
the C++ front end uses decltype(nullptr) for this purpose.

Bootstrapped with no regressions for x86_64-pc-linux-gnu.

PR c/114869

gcc/c/
* c-decl.cc (c_init_decl_processing): Register nullptr_type_node
as typeof (nullptr) not nullptr_t.

gcc/testsuite/
* gcc.dg/c23-nullptr-5.c: Use typeof (nullptr) not nullptr_t.
* gcc.dg/c11-nullptr-2.c, gcc.dg/c11-nullptr-3.c,
gcc.dg/c23-nullptr-7.c: New tests

[Bug c/114869] [13/14 Regression] GCC says nullptr_t is a C built in but it should be in

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

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

Joseph S. Myers  changed:

   What|Removed |Added

  Known to work||15.0
Summary|[13/14/15 Regression] GCC   |[13/14 Regression] GCC says
   |says nullptr_t is a C built |nullptr_t is a C built in
   |in but it should be in  |but it should be in
   |  |

--- Comment #4 from Joseph S. Myers  ---
Fixed so far for GCC 15. Although this could be backported, there would be a
risk of breaking any (incorrect) code that's relying on this built-in typedef
(especially in C23 mode).

[Bug fortran/90608] Inline non-scalar minloc/maxloc calls

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

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

--- Comment #37 from GCC Commits  ---
The master branch has been updated by Mikael Morin :

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

commit r15-5477-gf5a87c8d8c6a8cfcd23595e67d3b86939e01c75c
Author: Mikael Morin 
Date:   Thu Aug 8 12:23:16 2024 +0200

fortran: Inline non-character MINLOC/MAXLOC with DIM [PR90608]

Enable generation of inline MINLOC/MAXLOC code in the cases where DIM is a
constant, and either ARRAY is of REAL type or MASK is an array.  Those
cases
are the remaining bits to fully support inlining of non-CHARACTER
MINLOC/MAXLOC with constant DIM.  They are treated together because they
generate similar code, the NANs for REAL types being handled a bit like a
second level of masking.  These are the cases for which we generate two
loops.

This change affects the code generating the second loop, that was
previously accessible only in cases ARRAY had rank 1.

The main changes are in gfc_conv_intrinsic_minmaxloc the replacement of the
locally initialized scalarization loop with the one provided and previously
initialized by the scalarizer.  Same goes for the locally initialized MASK
scalarizer chain.

As this is enabling the code generating a second loop in a context of
reduction and nested loops, care is taken not to advance the parent
scalarization chain twice.

The scalarization chain element(s) for an array MASK are inserted in the
chain at a different place from that of a scalar MASK.  This is done on
purpose to match the code consuming the chains which are in different
places
for scalar and array MASK.

PR fortran/90608

gcc/fortran/ChangeLog:

* trans-intrinsic.cc (gfc_inline_intrinsic_function_p): Return TRUE
for MINLOC/MAXLOC with constant DIM and either REAL ARRAY or
non-scalar MASK.
(walk_inline_intrinsic_minmaxloc): Walk MASK and if it's an array
add the chain obtained before that of ARRAY.
(gfc_conv_intrinsic_minmaxloc): Use the nested loop if there is
one.
To evaluate MASK (respectively ARRAY in the second loop), inherit
the scalarizer chain if in a nested loop, otherwise keep using the
chain obtained by walking MASK (respectively ARRAY).  If there is a
nested loop, avoid advancing the parent scalarization chain a
second
time in the second loop.

gcc/testsuite/ChangeLog:

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

[Bug c/39438] Can't compile a wrapper around strftime with -Werror=format-nonliteral

[rdiez-2006 at rd10 dot de via Gcc-bugs]

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

R. Diez  changed:

   What|Removed |Added

 CC||rdiez-2006 at rd10 dot de

--- Comment #14 from R. Diez  ---
This is another code example:

-8<-8<-8<-

// Compile with -Wformat -Wformat-nonliteral

#include 

// For strftime formats, the third parameter in "__attribute__ format"
// below is required to be zero.
__attribute__ ((format (strftime, 3, 0)))
size_t strftime_e ( char * const buffer,
const size_t buffermax,
const char * const formatstr,
const tm * const tm )
{
  // This is the work-around to suppress the warning:
  // #pragma GCC diagnostic push
  // #pragma GCC diagnostic ignored "-Wformat-nonliteral"

  return strftime( buffer, buffermax, formatstr, tm );

  // #pragma GCC diagnostic pop
}

-8<-8<-8<-

It shows a work-around to suppress the warning, and is available here to play
with:

https://godbolt.org/z/EYzE3xMYc

[Bug c/115515] constexpr ICE

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

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

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #2 from Joseph S. Myers  ---
Testing a fix.

[Bug c++/117684] High compiling time for array initialization

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

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

--- Comment #3 from Andrew Pinski  ---
By the way the code needs to be updated to add an include for cstdint to
compile with the trunk.

[Bug bootstrap/117677] [15 Regression] Regression in fail, at selftest.cc:47

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

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

--- Comment #5 from Jakub Jelinek  ---
(In reply to Eric Gallager from comment #4)
> Does -Wfloat-equal warn about this? Maybe it'd be worth adding to the
> warnings enabled when building GCC?

I don't think we should use that warning when building GCC.  We shouldn't be
using floating point (almost) at all for the compiler itself, because it
doesn't guarantee reproduceable builds across different hosts.

[Bug modula2/115164] floating-point output generates misleading values with WriteFloat when sigfigs and width are zero

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

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

--- Comment #3 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Gaius Mulley
:

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

commit r14-10944-gaefb47144465c620141daf46e0ce576a5b0a389e
Author: Gaius Mulley 
Date:   Tue Nov 19 19:33:18 2024 +

[PATCH] PR modula2/115164 initial test code highlighting the problem

This patch includes some trivial testcode which highlights
PR 115164.  Expect future test code to perform runtime checks
for a series of trailing zeros.

gcc/testsuite/ChangeLog:

PR modula2/115164
* gm2/isolib/run/pass/testlowread.mod: New test.
* gm2/isolib/run/pass/testwritereal.mod: New test.

(cherry picked from commit d642b66a298ece7394e786a6a2d14a4f0b561d9a)

Signed-off-by: Gaius Mulley 

[Bug c++/117509] False negative on -Wdangling-reference

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
This suppresses the warning for me:

--- 117509.C2024-11-19 15:24:47.447035585 -0500
+++ 117509-2.C  2024-11-19 15:25:05.041046272 -0500
@@ -3,7 +3,7 @@ struct Optional {
 union { T v; };
 bool flag;

-[[nodiscard]] auto value() && -> T&& { return (T&&)v; }
+[[nodiscard, gnu::no_dangling]] auto value() && -> T&& { return (T&&)v; }
 [[nodiscard]] auto operator*() && -> T&& { return (T&&)v; }
 };

[Bug c++/90801] A recurring hang

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug c/115515] constexpr ICE

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

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

Joseph S. Myers  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #3 from Joseph S. Myers  ---
*** Bug 117139 has been marked as a duplicate of this bug. ***

[Bug target/117688] New: RISC-V: Wrong code for .SAT_SUB

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

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

Bug ID: 117688
   Summary: RISC-V: Wrong code for .SAT_SUB
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kristerw at gcc dot gnu.org
  Target Milestone: ---

The following test fails when compiled as
  riscv64-unknown-linux-gnu-gcc -O2 -march=rv64gc bug.c


#include 

int8_t x, y, result;

__attribute__ ((noipa)) void
foo ()
{
  int8_t minus; 
  _Bool overflow = __builtin_sub_overflow (x, y, &minus);
  result = overflow ? (x < 0 ? 0x80 : 0x7f) : minus;
}

int main ()
{
  x = 0x80;
  y = 0x78;
  foo();
  if (result != (int8_t)0x80)
__builtin_abort ();
  return 0;
}

[Bug c/117687] New: Wzero-as-nullpointer-constant should warn for zeros of type bool, enum, and _BitInt

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

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

Bug ID: 117687
   Summary: Wzero-as-nullpointer-constant should warn for zeros of
type bool, enum, and _BitInt
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: uecker at gcc dot gnu.org
  Target Milestone: ---

[Bug c++/61372] Add warning to detect noexcept functions that might throw [-Wnoexcept-mismatch]

[rdiez-2006 at rd10 dot de via Gcc-bugs]

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

--- Comment #10 from R. Diez  ---
I have been bitten by this lack of warning before, but GCC 10.5 should be able
to issue such a warning by default and has the following option in order to
disable the warning:

-Wno-terminate (C++ and Objective-C++ only)
Disable the warning about a throw-expression that will immediately result in a
call to terminate.

However, GCC 10.5 did not issue the warning for me, but GCC 11.4 (and upwards)
did. This is the test case I used:

void test ( void ) throw()
{
  throw 123;
}

The warning is:

warning: 'throw' will always call 'terminate' [-Wterminate]

That test source is available here to play with:

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

Bug 94112 has been marked as a duplicate of this one, but an important piece of
information is missing here: the warning above only works at the point where an
exception is thrown.

Like bug 94112 mentions, if a nothrow routine calls another one which can
throw, no warning is generated.

I believe that such a warning is important and I do not agree that it would
likely be far too noisy to be useful. Such a situation is an accident waiting
to happen. If in doubt, you can always disable the warning by default, but I
would always try to enable it for my software.

I also believe that, when you use extern "C", you are mostly thinking about
interfacing with C code which does not know about exceptions and does not
expect the execution order to suddenly change. The C code may then miss some
clean-up logic before the stack is unwound.

That is why I think that a warning for extern "C" routines is also important.
In the few scenarios where an extern "C" routine should support exceptions, you
could always disable the warning with a #pragma.

[Bug c/117687] Wzero-as-nullpointer-constant should warn for zeros of type bool, enum, and _BitInt

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

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

--- Comment #1 from uecker at gcc dot gnu.org ---
As discussed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117059#c10 the
warning should be enhanced to cover these cases.

[Bug c/117059] Enhancement: Make -Wzero-as-null-pointer-constant available in C

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

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

--- Comment #12 from uecker at gcc dot gnu.org ---
I filed PR117687 for the other cases.

[Bug c/117689] New: enum with underying type "extension" to GNU 17 is not documented

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

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

Bug ID: 117689
   Summary: enum with underying type "extension" to GNU 17 is not
documented
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: documentation
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

In GNU90/99/11/17 modes, GCC allows underlying types for enum to be specified.
This is not documented as an extension to these modes (it is part of C23
though). 

Also in connection to this we could expand "Incomplete enum Types" section to
talk about if you supply an underlying type for the enum tag forward
declaration, you can use it as a normal type too.

[Bug ipa/117668] fold_marked_statements in tree-inline.cc does not purge the abnormal edges after folding

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #4)
> Created attachment 59636 [details]
> new patch
> 
> Whoops some small typos.

Just to confirm this is working, I ran this with the testcase from PR 117665
with and without the Fix for PR 117665 .

With the verification and without the fix for PR 117665 GCC now get:
./cc1plus  t.ii -O2 -quiet
gcm_simd.cpp: In function ‘bool CryptoPP::CPU_ProbePMULL()’:
gcm_simd.cpp:681:1: error: abnormal edge in bb 13 ends in stmt that does not
require an abnormal edge
GIMPLE_NOP
gcm_simd.cpp:681:1: error: abnormal edge in bb 15 ends in stmt that does not
require an abnormal edge
GIMPLE_NOP
gcm_simd.cpp:681:1: error: abnormal edge in bb 17 ends in stmt that does not
require an abnormal edge
GIMPLE_NOP
gcm_simd.cpp:681:1: error: abnormal edge in bb 19 ends in stmt that does not
require an abnormal edge
GIMPLE_NOP
during GIMPLE pass: einline
gcm_simd.cpp:681:1: internal compiler error: verify_flow_info failed
0x358c8ae internal_error(char const*, ...)
../../gcc/diagnostic-global-context.cc:518
0x124caf7 verify_flow_info()
../../gcc/cfghooks.cc:288
0x124340f checking_verify_flow_info()
../../gcc/cfghooks.h:214
0x19d681b cleanup_tree_cfg_noloop
../../gcc/tree-cfgcleanup.cc:1154
0x19d691e cleanup_tree_cfg(unsigned int)
../../gcc/tree-cfgcleanup.cc:1205
0x17fe89f execute_function_todo
../../gcc/passes.cc:2071
0x17fd6a4 do_per_function
../../gcc/passes.cc:1701
0x17fec00 execute_todo
../../gcc/passes.cc:2156
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

With the patch for PR 117665, there is no error.

[Bug libstdc++/117210] [15 regression] error: 'llabs' is not a member of 'std'; did you mean 'labs'

[dimitry at andric dot com via Gcc-bugs]

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

--- Comment #12 from Dimitry Andric  ---
So, something like this?

diff --git a/libstdc++-v3/config/os/bsd/freebsd/os_defines.h
b/libstdc++-v3/config/os/bsd/freebsd/os_defines.h
index 0d63ae6cec4..e414524dcc2 100644
--- a/libstdc++-v3/config/os/bsd/freebsd/os_defines.h
+++ b/libstdc++-v3/config/os/bsd/freebsd/os_defines.h
@@ -26,6 +26,9 @@
 #ifndef _GLIBCXX_OS_DEFINES
 #define _GLIBCXX_OS_DEFINES 1

+// For __ISO_C_VISIBLE and __LONG_LONG_SUPPORTED
+#include 
+
 // System-specific #define, typedefs, corrections, etc, go here.  This
 // file will come before all others.


I think a similar approach might be needed for NetBSD and/or OpenBSD, btw.

[Bug ada/117538] Tracebacks don’t include the load address of PIE executables

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

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

--- Comment #7 from Eric Botcazou  ---
> so I think that all of the "Not used in" targets would benefit from this 
> change - at any rate the linux ones.

All the Linux and *BSD targets can presumably use the DWARF tracebacks.

> It would be interesting to see whether s-trasym__dwarf.adb could be made 
> to work for Darwin. I think Ada.Exceptions.Exception_Information uses its 
> own version of s-trasym, and of course the output from that is what most 
> users are going to see.

Yes, although there is probably a bit of work.

[Bug testsuite/117680] [15 Regression] aarch64 testcases need to be updated for C23

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

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

--- Comment #2 from Andrew Pinski  ---
For these:

+FAIL: gcc.target/aarch64/sme/streaming_mode_1.c (test for excess errors)
+FAIL: gcc.target/aarch64/sme/za_state_1.c (test for excess errors)
+FAIL: gcc.target/aarch64/sme/za_state_2.c  (test for errors, line 33)
+FAIL: gcc.target/aarch64/sme/za_state_2.c (test for excess errors)

I am thinking about creating a new version of these tests for C23+ and use the
ones to support "non-prototypes" declarations (so adding -std=gnu17 for the old
ones).

[Bug target/117357] ICE: in extract_insn, at recog.cc:2882 (unrecognizable insn: UNSPEC_RSQRT) with -mfpmath=387 and __builtin_ia32_rsqrtf()

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

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

--- Comment #5 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Uros Bizjak :

https://gcc.gnu.org/g:724dbdad0d23e2d460ca49aea3be5673e7ad80d1

commit r13-9201-g724dbdad0d23e2d460ca49aea3be5673e7ad80d1
Author: Uros Bizjak 
Date:   Mon Nov 18 22:38:46 2024 +0100

i386: Enable *rsqrtsf2_sse without TARGET_SSE_MATH [PR117357]

__builtin_ia32_rsqrtsf2 expander generates UNSPEC_RSQRT insn pattern
also when TARGET_SSE_MATH is not set.  Enable *rsqrtsf2_sse without
TARGET_SSE_MATH to avoid ICE with unrecognizable insn.

PR target/117357

gcc/ChangeLog:

* config/i386/i386.md (*rsqrtsf2_sse):
Also enable for !TARGET_SSE_MATH.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr117357.c: New test.

(cherry picked from commit 344356f781ddb7bf0abb11edf9bdd13f6802dea8)

[Bug target/117357] ICE: in extract_insn, at recog.cc:2882 (unrecognizable insn: UNSPEC_RSQRT) with -mfpmath=387 and __builtin_ia32_rsqrtf()

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

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

--- Comment #6 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Uros Bizjak :

https://gcc.gnu.org/g:540c0c7c424a43c1d99dd22f6db020cc0cd6eaea

commit r12-10822-g540c0c7c424a43c1d99dd22f6db020cc0cd6eaea
Author: Uros Bizjak 
Date:   Mon Nov 18 22:38:46 2024 +0100

i386: Enable *rsqrtsf2_sse without TARGET_SSE_MATH [PR117357]

__builtin_ia32_rsqrtsf2 expander generates UNSPEC_RSQRT insn pattern
also when TARGET_SSE_MATH is not set.  Enable *rsqrtsf2_sse without
TARGET_SSE_MATH to avoid ICE with unrecognizable insn.

PR target/117357

gcc/ChangeLog:

* config/i386/i386.md (*rsqrtsf2_sse):
Also enable for !TARGET_SSE_MATH.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr117357.c: New test.

(cherry picked from commit 344356f781ddb7bf0abb11edf9bdd13f6802dea8)

[Bug target/117357] ICE: in extract_insn, at recog.cc:2882 (unrecognizable insn: UNSPEC_RSQRT) with -mfpmath=387 and __builtin_ia32_rsqrtf()

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #7 from Uroš Bizjak  ---
Fixed everywhere.

[Bug libstdc++/117210] [15 regression] error: 'llabs' is not a member of 'std'; did you mean 'labs'

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

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

--- Comment #13 from Jakub Jelinek  ---
(In reply to Dimitry Andric from comment #12)
> So, something like this?
> 
> diff --git a/libstdc++-v3/config/os/bsd/freebsd/os_defines.h
> b/libstdc++-v3/config/os/bsd/freebsd/os_defines.h
> index 0d63ae6cec4..e414524dcc2 100644
> --- a/libstdc++-v3/config/os/bsd/freebsd/os_defines.h
> +++ b/libstdc++-v3/config/os/bsd/freebsd/os_defines.h
> @@ -26,6 +26,9 @@
>  #ifndef _GLIBCXX_OS_DEFINES
>  #define _GLIBCXX_OS_DEFINES 1
> 
> +// For __ISO_C_VISIBLE and __LONG_LONG_SUPPORTED
> +#include 
> +
>  // System-specific #define, typedefs, corrections, etc, go here.  This
>  // file will come before all others.
> 
> 
> I think a similar approach might be needed for NetBSD and/or OpenBSD, btw.

Yes.  I think for DragonFly, I don't think NetBSD or OpenBSD had something
similar (macros with defined inside of it, which with -Wsystem-headers are now
warned about).