[Bug target/113257] -march=native or -mcpu=native are ineffective, but -march=native -mcpu=native works on arm64 M2 Ultra

2025-01-11 Thread iains at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113257

Iain Sandoe  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org

--- Comment #9 from Iain Sandoe  ---
I suppose we can deduce that 0x38 == efficiency core and 0x39 is the
performance one (since the counts stack up).  We can figure out M1 c.f. M2/3 on
the basis of the feature list - but not sure we can discriminate M2 and M3 from
the feature lists alone (and M4 is currently TBD).

The piece of information that would be most helpful is the "CPU family" that
the Darwin kernel provides - but I have no idea how one might get that during
the Linux bootstrap.

[Bug c++/114630] [14/15 Regression] [modules] building module with submodule causes corrupt gcm

2025-01-11 Thread nshead at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114630

Nathaniel Shead  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |nshead at gcc dot 
gnu.org
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #14 from Nathaniel Shead  ---
Fixed for GCC 14.3.

[Bug c++/116805] -fno-module-lazy breaks thread module when compiled after format module

2025-01-11 Thread nshead at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116805

Nathaniel Shead  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Nathaniel Shead  ---
This is fixed as well with PR116430, so marking as a dup.

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

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

2025-01-11 Thread nshead at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 114630, which changed state.

Bug 114630 Summary: [14/15 Regression] [modules] building module with submodule 
causes corrupt gcm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114630

   What|Removed |Added

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

[Bug c++/114630] [14/15 Regression] [modules] building module with submodule causes corrupt gcm

2025-01-11 Thread nshead at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114630

Nathaniel Shead  changed:

   What|Removed |Added

 CC||gcc at richy dot net

--- Comment #15 from Nathaniel Shead  ---
*** Bug 116805 has been marked as a duplicate of this bug. ***

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

2025-01-11 Thread nshead at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 116805, which changed state.

Bug 116805 Summary: -fno-module-lazy breaks thread module when compiled after 
format module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116805

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug tree-optimization/117997] [15 regression] libgo regressions on aarch64 after g:4d2b9202fe94c54e63fb07d48293a78da3d82532

2025-01-11 Thread jakub at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117997

--- Comment #13 from Jakub Jelinek  ---
Note, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118415#c2
patch fixes this by using section anchors.  Which doesn't mean the linker isn't
buggy.

[Bug other/118417] New: Bootstrap comparison failure! gcc/range-op.o differs

2025-01-11 Thread danglin at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118417

Bug ID: 118417
   Summary: Bootstrap comparison failure! gcc/range-op.o differs
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---

At commit a7ae0c31245a7db7abf2e80d0016510afe9c8ad0, we have a
bootstrap comparison on 32-bit hppa-unknown-linux-gnu.

Comparing stages 2 and 3
Bootstrap comparison failure!
gcc/range-op.o differs
make[2]: *** [Makefile:24463: compare] Error 1

Commit f79f5b87efc690abc3b8d1b0f927f9348157348b was okay.

[Bug middle-end/118411] asm goto in large function miscompiles with "Error: bad immediate value for offset" in ARM mode

2025-01-11 Thread mathieu.desnoyers at efficios dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118411

--- Comment #5 from Mathieu Desnoyers  
---
(In reply to Andrew Pinski from comment #2)
> Created attachment 60101 [details]
> try this patch
> 
> This patch should fix get_attr_length_1 for the inline-asm goto.

I confirm that the proposed fix applied on gcc-14.2.0 fixes the issue when
compiling the the reproducer with "-marm".

Note that this issue is not recent, this fix may need to be backported to older
compiler versions.

Thanks!

[Bug middle-end/118415] [15 Regression] crc optimization uses user accessible symbols

2025-01-11 Thread jakub at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118415

--- Comment #4 from Jakub Jelinek  ---
(In reply to Jeffrey A. Law from comment #3)
> Using output_constant_def didn't even cross my mind.
> 
> I don't recall the TREE_PUBLIC part of the change, though obviously at least
> part of the goal here was to share the table if we have multiple copies
> across TUs.

I think we should try to do such sharing using linker support, e.g. SHF_MERGE
sections.
But it shouldn't be limited to just the crc tables, but anything in the
constant pool that is actually mergeable.

[Bug libstdc++/118413] Move only function makes `std::views::transform` not working correctly

2025-01-11 Thread ppalka at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118413

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #4 from Patrick Palka  ---
I think the definition of __can_transform_view is correct/idiomatic, we must be
passing the wrong types to it.

/opt/compiler-explorer/gcc-trunk-20250111/include/c++/15.0.0/ranges:2247:10:  
required for the satisfaction of '__can_transform_view<_Range, _Fp>' [with
_Range = std::ranges::iota_view; _Fp = const move_only_fn&]
/opt/compiler-explorer/gcc-trunk-20250111/include/c++/15.0.0/ranges:2248:6:  
in requirements  [with _Range = std::ranges::iota_view; _Fp = const
move_only_fn&]
/opt/compiler-explorer/gcc-trunk-20250111/include/c++/15.0.0/ranges:2248:24:
note: the required expression 'transform_view<...auto...>(declval<_Range>(),
declval<_Fp>())' is invalid, because


It's failing because we're incorrectly passing _Fp = const move_only_fn& to
__can_transform_view rather than _Fp = move_only_fn&&.

And seems that's because for adaptors that take a function object, we currently
always enable the _S_has_simple_extra_args optimization (which simplifies the
overload set of partially applied range adaptors and always forwards the saved
arguments by const reference), which was fine when functions were required to
be copyable but after P2494R2 we need to disable this optimization for
non-copyable functions.

[Bug target/112092] RISC-V: Suboptimal RVV code produced for vsetvl-11.c and vsetvlmax-8.c

2025-01-11 Thread macro at orcam dot me.uk via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112092

--- Comment #18 from Maciej W. Rozycki  ---
Any fix will have to be based on valid code though and the lone presence
of inline asm is not supposed to prevent optimisations from being used,
e.g. I may have to insert a memory barrier into my code for some reason:

asm volatile ("" : : : "memory");

and expect vector optimisations to continue being applied to the function
the barrier is in.  So provided that your report is indeed valid, any fix
may not indeed affect the reproducer in any way.

Alternatively you can save the vector CSRs at the beginning of your asm,
set them according to your needs for the operation(s) performed, execute
the operation(s) and restore the original contents of the CSRs before
exiting the asm.

And last but not least: is vector FMA not an operation the compiler can
emit itself from C code, such as by calling a suitable intrinsic on
vector data?

[Bug middle-end/118415] [15 Regression] crc optimization uses user accessible symbols

2025-01-11 Thread jakub at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118415

--- Comment #5 from Jakub Jelinek  ---
Anyway, if we don't go the output_constant_def way, we'd need to change the
name (see above patch), make it public at least if target supports hidden
visibility, set DECL_VISIBILITY{,_SPECIFICIED}, use DECL_RTL of the VAR_DECL
for the address instead of trying to build it by hand (so that it handles
-fsection-anchors properly) and use some hash table to look up already built
tables (because we need the VAR_DECL rather than just IDENTIFIER_NODE to get at
the DECL_RTL).
output_constant_def is earier in that it handles the hashing already.

[Bug tree-optimization/115825] [12/13/14 Regression] Loop unrolling increases code size with -Os

2025-01-11 Thread segher at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115825

--- Comment #16 from Segher Boessenkool  ---
Trivial stuff is no longer unrolled at all after this change.  It does not
matter
*at all* whether an insn has a side effect or not, for whether code with such
an
insn should be unrolled or not.  Any heuristic like that is totally broken,
totally
nonsensical.

In all failing cases I saw none of the code will be eliminated at all ever.

[Bug libstdc++/118413] Move only function makes `std::views::transform` not working correctly

2025-01-11 Thread ppalka at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118413

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |14.3
   Keywords||rejects-valid
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org

--- Comment #5 from Patrick Palka  ---
e.g.

diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index ad69a94b21f..2ca96c52065 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -2260,7 +2260,8 @@ namespace views::__adaptor

   using _RangeAdaptor<_Transform>::operator();
   static constexpr int _S_arity = 2;
-  static constexpr bool _S_has_simple_extra_args = true;
+  template
+   static constexpr bool _S_has_simple_extra_args =
copy_constructible<_Fp>;
 };

 inline constexpr _Transform transform;

[Bug target/118418] [15 Regression][gcn] Compiler selftest ICE in assert_rtx_eq_at, at selftest-rtl.cc:57 / FAIL: ASSERT_RTX_EQ (val, folded) since r15-6777-g06c4cf398947b5

2025-01-11 Thread schwab--- via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118418

Andreas Schwab  changed:

   What|Removed |Added

 Target|gcn |gcn m68k-*-*

--- Comment #1 from Andreas Schwab  ---
Also fails for m68k, probably because both define STORE_FLAG_VALUE to -1.

[Bug fortran/107596] ICE in gfc_match_submodule, at fortran/module.cc:773

2025-01-11 Thread kargls at comcast dot net via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107596

--- Comment #2 from kargls at comcast dot net ---
This appears to be fixed in gcc 14 and trunk.

[Bug rtl-optimization/117868] [avr][lra] Wrong code with -mlra in simd-1.c

2025-01-11 Thread denisc at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117868

--- Comment #4 from Denis Chertykov  ---
In brief:
this is an LRA bug derived from reuse spilling slots after frame pointer
spilling.
The slot was created for QImode (1 byte) and it was reused after spilling of
the
frame pointer for TImode register (16 bytes long) and it overlaps other slots.

Wrong things happened while `lra_spill ()'
 part of lra-spills.cc 
  n = assign_spill_hard_regs (pseudo_regnos, n);
  slots_num = 0;
  assign_stack_slot_num_and_sort_pseudos (pseudo_regnos, n);  <--- first call
--- 
  for (i = 0; i < n; i++)
if (pseudo_slots[pseudo_regnos[i]].mem == NULL_RTX)
  assign_mem_slot (pseudo_regnos[i]);
  if ((n2 = lra_update_fp2sp_elimination (pseudo_regnos)) > 0)
{
  /* Assign stack slots to spilled pseudos assigned to fp.  */
  assign_stack_slot_num_and_sort_pseudos (pseudo_regnos, n2);  <--- second
call --- 
  for (i = 0; i < n2; i++)
if (pseudo_slots[pseudo_regnos[i]].mem == NULL_RTX)
  assign_mem_slot (pseudo_regnos[i]);
}
--

In a first call of `assign_stack_slot_num_and_sort_pseudos(...)' LRA allocates
slot #17
for r93 (QImode - 1 byte).
In a second call of `assign_stack_slot_num_and_sort_pseudos(...)' LRA reuse
slot #17 for
r114 (TImode - 16 bytes).
It's wrong. We can't reuse 1 byte slot #17 for 16 bytes register.


Details:

After IRA pass we have:
-- part of simd-t.c.319r.ira --
(insn 269 268 270 8 (set (subreg:QI (reg:TI 114 [ _116 ]) 6)
(xor:QI (reg:QI 66 [ _36 ])
(reg:QI 67 [ _37 ]))) 631 {xorqi3}
 (expr_list:REG_DEAD (reg:QI 67 [ _37 ])
(expr_list:REG_DEAD (reg:QI 66 [ _36 ])
(nil
(insn 270 269 271 8 (set (subreg:QI (reg:TI 114 [ _116 ]) 7)
(xor:QI (reg:QI 69 [ _39 ])
(reg:QI 70 [ _40 ]))) 631 {xorqi3}
 (expr_list:REG_DEAD (reg:QI 70 [ _40 ])
(expr_list:REG_DEAD (reg:QI 69 [ _39 ])
(nil
---

While LRA spilling:
-- part of simd-t.c.320r.reload ---
  Creating newreg=348 from oldreg=66, assigning class GENERAL_REGS to r348
  269: r348:QI=r348:QI^r67:QI
  REG_DEAD r67:QI
  REG_DEAD r66:QI
Inserting insn reload before:
  543: r348:QI=r66:QI
Inserting insn reload after:
  544: r114:TI#6=r348:QI

[...]

  Choosing alt 0 in insn 270:  (0) =r  (1) %0  (2) r {xorqi3}
  Creating newreg=349 from oldreg=69, assigning class GENERAL_REGS to r349
  Creating newreg=350 from oldreg=70, assigning class GENERAL_REGS to r350
  270: r349:QI=r349:QI^r350:QI
  REG_DEAD r70:QI
  REG_DEAD r69:QI
Inserting insn reload before:
  545: r349:QI=r69:QI
  547: r350:QI=r70:QI
Inserting insn reload after:
  546: r114:TI#7=r349:QI
---


After LRA pass:
-- part of simd-t.c.320r.reload ---
(insn 543 542 269 11 (set (reg:QI 14 r14 [orig:66 _36 ] [66])
(mem/c:QI (plus:HI (reg/f:HI 28 r28)
(const_int 7 [0x7])) [4 %sfp+7 S1 A8])) 113 {movqi_insn_split}
 (nil))
(insn 269 543 544 11 (set (reg:QI 14 r14 [orig:66 _36 ] [66])
(xor:QI (reg:QI 14 r14 [orig:66 _36 ] [66])
(reg:QI 2 r2 [orig:67 _37 ] [67]))) 631 {xorqi3}
 (nil))
(insn 544 269 545 11 (set (mem/c:QI (plus:HI (reg/f:HI 28 r28)
(const_int 24 [0x18])) [4 %sfp+24 S1 A8])
(reg:QI 14 r14 [orig:66 _36 ] [66])) 113 {movqi_insn_split}
 (nil))
(insn 545 544 547 11 (set (reg:QI 14 r14 [orig:69 _39 ] [69])
(mem/c:QI (plus:HI (reg/f:HI 28 r28)
(const_int 24 [0x18])) [4 %sfp+24 S1 A8])) 113
{movqi_insn_split}
 (nil))
(insn 547 545 270 11 (set (reg:QI 13 r13 [orig:70 _40 ] [70])
(mem/c:QI (plus:HI (reg/f:HI 28 r28)
(const_int 8 [0x8])) [4 %sfp+8 S1 A8])) 113 {movqi_insn_split}
 (nil))
(insn 270 547 546 11 (set (reg:QI 14 r14 [orig:69 _39 ] [69])
(xor:QI (reg:QI 14 r14 [orig:69 _39 ] [69])
(reg:QI 13 r13 [orig:70 _40 ] [70]))) 631 {xorqi3}
 (nil))
(insn 546 270 548 11 (set (mem/c:QI (plus:HI (reg/f:HI 28 r28)
(const_int 25 [0x19])) [4 %sfp+25 S1 A8])
(reg:QI 14 r14 [orig:69 _39 ] [69])) 113 {movqi_insn_split}
 (nil))
---

Simplified insns before LRA:
--
insn 269 r114.6  =  r66 ^ r67
insn 270 r114.7  =  r69 ^ r70
--

after LRA:
--
insn 543 r14 {r66} = [sfp+7]# reload insn
insn 269 r14 {r66} ^= r2 {r67}
insn 544 [sfp+24] = r14 {r66}   # reload insn -- bug is here !

insn 545 r14 {r69} = [sfp+24]   # reload insn
insn 547 r13 {r70} = [sfp+8]#

[Bug rtl-optimization/117868] [avr][lra] Wrong code with -mlra in simd-1.c

2025-01-11 Thread denisc at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117868

Denis Chertykov  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2025-01-11
 Status|UNCONFIRMED |NEW

[Bug c/116871] -Wincompatible-pointer-types for function pointers could highlight the mismatch better

2025-01-11 Thread dmalcolm at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116871

--- Comment #6 from David Malcolm  ---
Created attachment 60118
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60118&action=edit
Screenshot of textual output from *after* the patch

[Bug c/116871] -Wincompatible-pointer-types for function pointers could highlight the mismatch better

2025-01-11 Thread dmalcolm at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116871

David Malcolm  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2025-January
   ||/673348.html
   Keywords||patch
 CC||dmalcolm at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org

--- Comment #4 from David Malcolm  ---
Patch posted that helps with part of this:
  https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673348.html

[Bug c/116871] -Wincompatible-pointer-types for function pointers could highlight the mismatch better

2025-01-11 Thread dmalcolm at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116871

--- Comment #5 from David Malcolm  ---
Created attachment 60117
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60117&action=edit
Screenshot of textual output from *before* the patch

[Bug tree-optimization/118409] [15 regression] gas miscompiled by ifcombine ("Unsupported broadcast" assemble failure)

2025-01-11 Thread sjames at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118409

Sam James  changed:

   What|Removed |Added

  Attachment #60106|0   |1
is obsolete||

--- Comment #11 from Sam James  ---
Created attachment 60107
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60107&action=edit
tc-i386.c

[Bug c/87950] GCC warns about reaching end of non-void function when all switch cases are completely handled

2025-01-11 Thread nightstrike at gmail dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87950

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com

--- Comment #17 from nightstrike  ---
(In reply to Arsen Arsenović from comment #16)
> can't we assume that following the aforementioned
> https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1766 ?  at
> least in C++>=17 (and, this bug should either be hijacked or remade for C++,
> probably)

As long as we are hijacking for C++, the following should not warn, given how
enum class works:

$ cat e.cc
enum class E {
A,
B,
};

char get(E e) {
switch (e) {
case E::A: return 'a';
case E::B: return 'b';
}
}

$ g++-14.1 -c e.cc

e.cc: In function 'char get(E)':
e.cc:11:1: warning: control reaches end of non-void function [-Wreturn-type]
   11 | }
  | ^

[Bug fortran/108434] [12/13/14/15 Regression] ICE in class_allocatable, at fortran/expr.cc:5000

2025-01-11 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108434

--- Comment #15 from GCC Commits  ---
The master branch has been updated by Paul Thomas :

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

commit r15-6820-gd64ca15351029164bac30b49fb3c4f9723e755de
Author: Paul Thomas 
Date:   Sat Jan 11 08:23:48 2025 +

Fortran: Fix error recovery for bad component arrayspecs [PR108434]

2025-01-11  Paul Thomas  

gcc/fortran/
PR fortran/108434
* class.cc (generate_finalization_wrapper): To avoid memory
leaks from callocs, return immediately if the derived type
error flag is set.
* decl.cc (build_struct): If the declaration of a derived type
or class component does not have a deferred arrayspec, correct,
set the error flag of the derived type and emit an immediate
error.

gcc/testsuite/
PR fortran/108434
* gfortran.dg/pr108434.f90 : Add tests from comment 1.

[Bug c++/118412] Non-conforming instantiation of definitions of scoped member enum in class template

2025-01-11 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118412

--- Comment #4 from Andrew Pinski  ---
(In reply to André Brand from comment #3)
> That's interesting. 
> This example is copied word for word from the standard section
> [temp.mem.enum](https://eel.is/c++draft/temp.mem.enum):
> https://godbolt.org/z/no6z7WT5s
> ... but all major compilers seem to reject it.

https://eel.is/c++draft/temp.expl.spec#example-4 says it should be rejected.

Looks like this should be fixed up again :).

[Bug tree-optimization/118409] [15 regression] gas miscompiled by ifcombine ("Unsupported broadcast" assemble failure)

2025-01-11 Thread sjames at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118409

Sam James  changed:

   What|Removed |Added

  Attachment #60110|0   |1
is obsolete||

--- Comment #14 from Sam James  ---
Created attachment 60111
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60111&action=edit
tc-i386.c

[Bug tree-optimization/118409] [15 regression] gas miscompiled by ifcombine ("Unsupported broadcast" assemble failure)

2025-01-11 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118409

Andrew Pinski  changed:

   What|Removed |Added

  Attachment #60111|0   |1
is obsolete||

--- Comment #15 from Andrew Pinski  ---
Created attachment 60112
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60112&action=edit
Reduced all the way

[Bug tree-optimization/118409] [15 regression] gas miscompiled by ifcombine ("Unsupported broadcast" assemble failure)

2025-01-11 Thread xry111 at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118409

Xi Ruoyao  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||xry111 at gcc dot gnu.org
   Last reconfirmed||2025-01-11
   Priority|P3  |P1

--- Comment #16 from Xi Ruoyao  ---
(In reply to Andrew Pinski from comment #15)
> Created attachment 60112 [details]
> Reduced all the way

Confirmed then, and I'd say miscompiling gas is a P1.

[Bug tree-optimization/118409] [15 regression] gas miscompiled by ifcombine ("Unsupported broadcast" assemble failure)

2025-01-11 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118409

Andrew Pinski  changed:

   What|Removed |Added

 Target||SLOW_BYTE_ACCESS==0
   ||(x86_64)

--- Comment #17 from Andrew Pinski  ---
Note the miscompile only happens for targets were SLOW_BYTE_ACCESS==0 (x86_64).

[Bug c++/118412] Non-conforming instantiation of definitions of scoped member enum in class template

2025-01-11 Thread andre.brand at mailbox dot org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118412

--- Comment #6 from André Brand  ---
(In reply to Andrew Pinski from comment #5)
> If you want you can submit something to the C++ standards committee because
> it does seems like there is a conflict between the 2 parts at least the
> example (the example might be considered an editorial change):
> https://isocpp.org/std/submit-issue

Sure. I haven't done that so far but there's a first time for everything. :-)

By the way, in case you haven't checked:
https://eel.is/c++draft/temp.expl.spec#example-4
is *not* rejected by GCC even though it should:
https://godbolt.org/z/deocxfvv6

In addition to that, it does not assign the correct value of 0 to the first
enumerator.

[Bug middle-end/118415] [15 Regression] crc optimization uses user accessible symbols

2025-01-11 Thread jakub at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118415

--- Comment #1 from Jakub Jelinek  ---
Minimal patch could be
--- gcc/expr.cc.jj  2025-01-08 10:05:24.498994763 +0100
+++ gcc/expr.cc 2025-01-11 13:31:34.608998939 +0100
@@ -14304,12 +14304,17 @@ generate_crc_table (unsigned HOST_WIDE_I
 {
   gcc_assert (crc_bits <= 64);

-  /* Buf size - 24 letters + 6 '_'
+  /* Buf size - 26 letters + 6 '_'
  + 20 numbers (2 for crc bit size + 2 for 0x + 16 for 64-bit polynomial)
  + 1 for \0.  */
-  char buf[51];
-  sprintf (buf, "crc_table_for_crc_%u_polynomial_" HOST_WIDE_INT_PRINT_HEX,
+  char buf[sizeof ("__crc_table_for_crc__polynomial_") + 20];
+  sprintf (buf, "__crc_table_for_crc_%u_polynomial_" HOST_WIDE_INT_PRINT_HEX,
   crc_bits, polynom);
+#if !defined (NO_DOT_IN_LABEL)
+  buf[sizeof ("__crc_table") - 1] = '.';
+#elif !defined (NO_DOLLAR_IN_LABEL)
+  buf[sizeof ("__crc_table") - 1] = '$';
+#endif

   tree id = maybe_get_identifier (buf);
   if (id)

though that is solely about the name.
I'm really surprised by
  if (TREE_PUBLIC (id))
{
  TREE_PUBLIC (decl) = 1;
  make_decl_one_only (decl, DECL_ASSEMBLER_NAME (decl));
}
since when IDENTIFIER_NODE should have TREE_PUBLIC set on it and what would do
that?

[Bug libstdc++/118416] New: std::experimental::simd code detecting all zero is not optimized to simple ptest on x86-64 avx

2025-01-11 Thread lee.imple at gmail dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118416

Bug ID: 118416
   Summary: std::experimental::simd code detecting all zero is not
optimized to simple ptest on x86-64 avx
   Product: gcc
   Version: 14.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lee.imple at gmail dot com
  Target Milestone: ---

The following code uses experimental c++ standard library simd, and wants to
detect several all-zero patterns that can be easily done with the vptest
instructions. All the code is available at https://godbolt.org/z/Kx68E1T6v .

```c++
#include 
#include 
namespace stdx = std::experimental;

template 
using simd_of = stdx::simd>;

using data_t = simd_of;

bool simple_ptest(data_t x) {
return all_of(x == 0);
}

bool ptest_and(data_t a, data_t b) {
return all_of((a & b) == 0);
}

bool ptest_andn(data_t a, data_t b) {
return all_of((a & ~b) == 0);
}
```

Equivalent assembly (hand-written):

```asm
simple_ptest:
vptest  %xmm0, %xmm0
sete%al
ret
ptest_and:
vptest  %xmm0, %xmm1
sete%al
ret
ptest_andn:
vptest  %xmm0, %xmm1
setc%al
ret
```

But g++ generates the following code at `-O3 -march=x86-64-v3`, and clang++ and
even Intel icpx generates almost the same assembly.

```asm
simple_ptest(std::experimental::parallelism_v2::simd >):
vpxor   %xmm1, %xmm1, %xmm1
vpcmpeqd%xmm1, %xmm0, %xmm0
vpcmpeqd%xmm1, %xmm1, %xmm1
vptest  %xmm1, %xmm0
setc%al
ret
ptest_and(std::experimental::parallelism_v2::simd >,
std::experimental::parallelism_v2::simd >):
vpand   %xmm1, %xmm0, %xmm0
vpxor   %xmm1, %xmm1, %xmm1
vpcmpeqd%xmm1, %xmm0, %xmm0
vpcmpeqd%xmm1, %xmm1, %xmm1
vptest  %xmm1, %xmm0
setc%al
ret
ptest_andn(std::experimental::parallelism_v2::simd >,
std::experimental::parallelism_v2::simd >):
vpandn  %xmm0, %xmm1, %xmm1
vpxor   %xmm0, %xmm0, %xmm0
vpcmpeqd%xmm0, %xmm1, %xmm1
vpcmpeqd%xmm0, %xmm0, %xmm0
vptest  %xmm0, %xmm1
setc%al
ret
```

I don't know whether this should be a missed optimization in g++ or a libstdc++
issue. Since these compilers generate the same output from the same library
code, I guess probably this should be a library issue.

Possibly related: PR58790 ?

[Bug c++/118412] Non-conforming instantiation of definitions of scoped member enum in class template

2025-01-11 Thread andre.brand at mailbox dot org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118412

--- Comment #7 from André Brand  ---
(In reply to Andrew Pinski from comment #5)
> If you want you can submit something to the C++ standards committee because
> it does seems like there is a conflict between the 2 parts at least the
> example (the example might be considered an editorial change):
> https://isocpp.org/std/submit-issue

I proposed an easy solution to the C++ standards committee. You can have a
look, if you're interested: https://github.com/cplusplus/draft/pull/7558

But this doesn't solve the current GCC bug I submitted. This would be more than
just an editorial issue, I guess. ;-)

[Bug libstdc++/118413] Move only function makes `std::views::transform` not working correctly

2025-01-11 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118413

--- Comment #2 from Andrew Pinski  ---
Created attachment 60109
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60109&action=edit
The full error message with `-std=c++23 -fconcepts-diagnostics-depth=100
-fdiagnostics-all-candidates`

[Bug tree-optimization/118409] [15 regression] gas miscompiled by ifcombine ("Unsupported broadcast" assemble failure)

2025-01-11 Thread sjames at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118409

--- Comment #12 from Sam James  ---
Bisect says r15-6774-g740c84975ceb74 or r15-6775-gfd4e979d0c6656 (it ICEs for
some commits so can't be more precise).

[Bug c++/118306] Accepts invalid ctor with * in front

2025-01-11 Thread simartin at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118306

--- Comment #2 from Simon Martin  ---
Patch submitted in
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673196.html

[Bug libstdc++/110352] [C++26] P2630R4 submdspan

2025-01-11 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110352

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2025-01-11

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

[Bug libstdc++/118413] Move only function makes `std::views::transform` not working correctly

2025-01-11 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118413

--- Comment #1 from Andrew Pinski  ---
Created attachment 60108
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60108&action=edit
Full testcase from godbolt

Next time please attach the full testcase either inline or attach it instead of
a code snip it and link to godbolt.

[Bug fortran/106692] [12/13/14 Regression] Cray pointer comparison wrongly optimized away

2025-01-11 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106692

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

https://gcc.gnu.org/g:91706178c3765cb27b05391c86f5c4f421ddd56d

commit r13-9307-g91706178c3765cb27b05391c86f5c4f421ddd56d
Author: Harald Anlauf 
Date:   Thu Jan 2 20:22:23 2025 +0100

Fortran: Cray pointer comparison wrongly optimized away [PR106692]

PR fortran/106692

gcc/fortran/ChangeLog:

* trans-expr.cc (gfc_conv_expr_op): Inhibit excessive optimization
of Cray pointers by treating them as volatile in comparisons.

gcc/testsuite/ChangeLog:

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

(cherry picked from commit c7754a2fb2e60987524947fe189f3ffac035ea1d)

[Bug tree-optimization/118409] [15 regression] gas miscompiled by ifcombine ("Unsupported broadcast" assemble failure)

2025-01-11 Thread law at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118409

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #18 from Jeffrey A. Law  ---
m32r, h8300 and iq2000 are all failing execute/20040709-?.c, bisected down to
same commits and I strongly suspect are ultimately the same problem.

[Bug middle-end/118415] [15 Regression] crc optimization uses user accessible symbols

2025-01-11 Thread law at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118415

--- Comment #3 from Jeffrey A. Law  ---
Using output_constant_def didn't even cross my mind.

I don't recall the TREE_PUBLIC part of the change, though obviously at least
part of the goal here was to share the table if we have multiple copies across
TUs.

[Bug c/87950] GCC warns about reaching end of non-void function when all switch cases are completely handled

2025-01-11 Thread redi at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87950

--- Comment #19 from Jonathan Wakely  ---
(In reply to nightstrike from comment #17)
> As long as we are hijacking for C++, the following should not warn, given
> how enum class works:

Are you sure you know how enum class works?

[Bug tree-optimization/118409] [15 regression] gas miscompiled by ifcombine ("Unsupported broadcast" assemble failure)

2025-01-11 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118409

--- Comment #20 from Andrew Pinski  ---
(In reply to Sergei Trofimovich from comment #19)
> (In reply to Andrew Pinski from comment #15)
> > Created attachment 60112 [details]
> > Reduced all the way
> 
> Nice test Andrew! Bisect says it started from r15-6774-g740c84975ceb74

Most of the credit goes to Sam really. I just took the final step of removing
some minor un-needed things.

[Bug tree-optimization/118409] [15 regression] gas miscompiled by ifcombine ("Unsupported broadcast" assemble failure)

2025-01-11 Thread slyfox at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118409

Sergei Trofimovich  changed:

   What|Removed |Added

 CC||slyfox at gcc dot gnu.org

--- Comment #19 from Sergei Trofimovich  ---
(In reply to Andrew Pinski from comment #15)
> Created attachment 60112 [details]
> Reduced all the way

Nice test Andrew! Bisect says it started from r15-6774-g740c84975ceb74

[Bug objc/118420] New: objc/objc-map.{cc,h} has FSF (physical) mailing address is included in the license header

2025-01-11 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118420

Bug ID: 118420
   Summary: objc/objc-map.{cc,h} has FSF (physical) mailing
address is included in the license header
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: internal-improvement
  Severity: normal
  Priority: P3
 Component: objc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
Blocks: 118419
  Target Milestone: ---

As mentioned in PR 118419, these should be removed as it has changed again. And
the standard practice is not to include them.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118419
[Bug 118419] [meta-bug] FSF (physical) mailing address is included in the
license header

[Bug rtl-optimization/118421] modulo-sched.cc has FSF (physical) mailing address is included in the license header

2025-01-11 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118421

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Sorry my grep was incorrect.
   PACT '96 , pages 80-87, October 1996 (Boston - Massachusetts - USA).

[Bug other/118419] [meta-bug] FSF (physical) mailing address is included in the license header

2025-01-11 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118419
Bug 118419 depends on bug 118421, which changed state.

Bug 118421 Summary: modulo-sched.cc has FSF (physical) mailing address is 
included in the license header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118421

   What|Removed |Added

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

[Bug target/118373] gcc-14.2 kernel panic on alderlake cpus

2025-01-11 Thread sjames at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118373

--- Comment #11 from Sam James  ---
(In reply to Lance Fredrickson from comment #10)
> I have a monitor connected via displayport, but when it crashes it just goes
> blank. 

I wonder if it's actually panicking or if the issue is video output gets broken
when built with GCC 14.2.0.

> Does it need to be a debug build of the kernel?  

No, shouldn't be needed.

> If your able to have access again the following link is a build
> known to have the issue.
> https://tomato64.org/files/x86_64/Releases/2024/2024.5/

We tried
https://tomato64.org/files/x86_64/Releases/2024/2024.5/tomato64-2024.5-uefi-x86_64_v2%2B-livecd.iso.zip
(tomato64-2024.5-uefi-x86_64_v2+-livecd.iso) and that worked OK (video output
and booted into the image fine, ssh, etc).

[Bug c++/118412] Non-conforming instantiation of definitions of scoped member enum in class template

2025-01-11 Thread andre.brand at mailbox dot org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118412

--- Comment #3 from André Brand  ---
That's interesting. 
This example is copied word for word from the standard section
[temp.mem.enum](https://eel.is/c++draft/temp.mem.enum):
https://godbolt.org/z/no6z7WT5s
... but all major compilers seem to reject it.

[Bug tree-optimization/118409] [15 regression] gas miscompiled by ifcombine ("Unsupported broadcast" assemble failure)

2025-01-11 Thread sjames at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118409

Sam James  changed:

   What|Removed |Added

  Attachment #60107|0   |1
is obsolete||

--- Comment #13 from Sam James  ---
Created attachment 60110
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60110&action=edit
tc-i386.c

[Bug middle-end/118411] asm goto in large function miscompiles with "Error: bad immediate value for offset" in ARM mode

2025-01-11 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118411

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2025-January
   ||/673330.html

--- Comment #4 from Andrew Pinski  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673330.html

[Bug modula2/118414] New: cross compiling fails

2025-01-11 Thread gaius at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118414

Bug ID: 118414
   Summary: cross compiling fails
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: gaius at gcc dot gnu.org
  Target Milestone: ---

Forwarded from the gm2 mailing list:

"""
The Modula-2 compiler is not cross-compilable. During configuration, they
simply forgot to add the --host triplet (which fails immediately) and
additionally, the mlink, mc
utilities, which are supposed to run on the build machine, are cross-compiled
for the target. This, of course, results in an error when running mlink on the
build machine (during the GCC build).

There are many such errors, for example, when assembling the gmp library,
improper build, host, target triplets are used and without applying patches to
Makefile.in, it will not be possible to cross-compile with GCC.

People forget that (in the case of GCC):
- build - is the machine where GCC is compiled;
- host - is the machine where the built collection of compilers (GCC) will run;
- target - is the machine for which programs are prepared with GCC on the host
machine.
"""

[Bug analyzer/116060] -fanalyzer -fdiagnostics-text-art-charset=unicode replaces typedef'ed type with "int" in some cases

2025-01-11 Thread azoff at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116060

Torbjorn SVENSSON  changed:

   What|Removed |Added

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

--- Comment #4 from Torbjorn SVENSSON  ---
Thank you Jason for fixing my broken patch!

I've confirmed that your fix also works for the arm-none-eabi target (the
target that I originally found the issue on).

Since this will not be backported to GCC14, I'll mark this as resolved.

[Bug middle-end/118415] New: [15 Regression] crc optimization uses user accessible symbols

2025-01-11 Thread jakub at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118415

Bug ID: 118415
   Summary: [15 Regression] crc optimization uses user accessible
symbols
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

unsigned char crc_table_for_crc_8_polynomial_0x7[2] = { 0xff, 0xff };

static unsigned char
foo (unsigned char byte, unsigned char crc)
{
  unsigned int i;
  crc ^= byte;
  for (i = 0; i < 8; i++)
crc = (crc << 1) ^ ((crc >> 7) ? 0x07 : 0);
  return crc;
}

int
main ()
{
  volatile unsigned char byte = 1;
  volatile unsigned char crc = 0;
  crc = foo (byte, crc);
  if (crc != 7)
__builtin_abort ();
}

is miscompiled starting with the introduction of the CRC optimization.
Using user accessible symbols should be only the last resort, I think in
any case the name should start with double underscore and have at least one of
the underscores replaced with . or $ if the target supports dot
(NO_DOT_IN_LABEL, NO_DOLLAR_IN_LABEL).

I think the symbol should be also hidden whenever target supports that, it is
fine to merge those across TUs within one executable or shared library, but the
optimization shouldn't add to the list of exported symbols.

[Bug middle-end/118415] [15 Regression] crc optimization uses user accessible symbols

2025-01-11 Thread jakub at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118415

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2025-01-11
 Status|UNCONFIRMED |NEW
   Priority|P3  |P1
   Target Milestone|--- |15.0
 Ever confirmed|0   |1

[Bug c++/118412] Non-conforming instantiation of definitions of scoped member enum in class template

2025-01-11 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118412

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=102004
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2025-01-11

--- Comment #2 from Andrew Pinski  ---
DR 1206 changed to allow this:
http://open-std.org/JTC1/SC22/WG21/docs/cwg_defects.html#1206

[Bug c++/102004] The opaque-enum-declaration whose enum-head-name contains a nest-name-specifier should be permitted in an explicit specialization

2025-01-11 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102004

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2025-01-11
 Status|UNCONFIRMED |NEW

--- Comment #2 from Andrew Pinski  ---
Confirmed based on my reading of DR 1206.

[Bug c++/116233] Explicit specialization of an enum member

2025-01-11 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116233

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

[Bug c++/53479] Control flow analysis reports warnings in switch over an enum class even if all possible values have their branches

2025-01-11 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|INVALID |---
   Last reconfirmed||2025-01-11
 Ever confirmed|0   |1
 Status|RESOLVED|NEW

--- Comment #25 from Andrew Pinski  ---
.

[Bug c/87950] GCC warns about reaching end of non-void function when all switch cases are completely handled

2025-01-11 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87950

--- Comment #18 from Andrew Pinski  ---
(In reply to nightstrike from comment #17)
> (In reply to Arsen Arsenović from comment #16)
> > can't we assume that following the aforementioned
> > https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1766 ?  at
> > least in C++>=17 (and, this bug should either be hijacked or remade for C++,
> > probably)
> 
> As long as we are hijacking for C++, the following should not warn, given
> how enum class works:

But that is PR 53479.

[Bug libstdc++/118413] Move only function makes `std::views::transform` not working correctly

2025-01-11 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118413

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2025-01-11
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #3 from Andrew Pinski  ---
I wonder if:
  template
concept __can_transform_view
  = requires { transform_view(std::declval<_Range>(),
std::declval<_Fp>()); };


Should be:
  template
concept __can_transform_view
  = requires (_Fp F) { transform_view(std::declval<_Range>(),
std::move(F)); };

for C++23+ or something similar.

But yes I do think __can_transform_view is wrong for C++23 since C++23 requires
move rather than copy functions.

[Bug modula2/118010] -Wlto-type-mismatch warning/error during m2 bootstrap on arm (gm2-libs-boot/Glibc.h:206:16: warning: type of ‘libc_lseek’ does not match original declaration [-Wlto-type-mismatch]

2025-01-11 Thread gaius at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118010

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #11 from Gaius Mulley  ---
Many thanks for the correction - will update my test.

[Bug target/118373] gcc-14.2 kernel panic on alderlake cpus

2025-01-11 Thread sjames at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118373

--- Comment #9 from Sam James  ---
I used gcc-14.2.0 to build linux-6.12.9 with only a slightly modified config
(to actually be able to boot) on an N100 I had temporary access to and couldn't
reproduce. That pic will really be critical for making any progress here

[Bug target/110901] -march does not override -mcpu in calls to assembler

2025-01-11 Thread tnfchris at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110901

Tamar Christina  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |tnfchris at gcc dot 
gnu.org
 CC||tnfchris at gcc dot gnu.org
   Last reconfirmed|2023-08-07 00:00:00 |2025-1-11
Summary|-march does not override|-march does not override
   |-mcpu (big.little on|-mcpu in calls to assembler
   |aarch64)|

--- Comment #5 from Tamar Christina  ---
This is not unique to big little and is a bug.

There's an inconsistency in how we call cc1 vs as:

 > gcc -O1 -march=armv8.2-a+sve -mcpu=cortex-a72

gives

as -EL "-march=armv8.2-a+sve" "-march=armv8-a+crc" "-mabi=lp64"

to gas but

cc1 .. "-march=armv8.2-a+sve" "-mcpu=cortex-a72"

to cc1.

Mine.

[Bug tree-optimization/117997] [15 regression] libgo regressions on aarch64 after g:4d2b9202fe94c54e63fb07d48293a78da3d82532

2025-01-11 Thread jakub at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117997

Jakub Jelinek  changed:

   What|Removed |Added

 CC||rearnsha at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org

--- Comment #12 from Jakub Jelinek  ---
I admit I know next to nothing about aarch64 relocations/typical PIC code etc.
I think usually aarch64 code uses section anchors, but that is clearly not the
case with these .CRC ifn expansions (why it hasn't been lowered to GIMPLE
earlier if hw doesn't have instructions?).
Anyway, in #c11 testcase (-O2 -fpie), I see in the blah function
adrpx20, _GLOBAL_OFFSET_TABLE_
...
ldr x4, [x20, #:gotpage_lo15:crc_table_for_crc_8_polynomial_0x7]
...
ldr x23, [x20, #:gotpage_lo15:crc_table_for_crc_8_polynomial_0x7]
...
ldr x20, [x20,
#:gotpage_lo15:crc_table_for_crc_16_polynomial_0x8005]
where crc_table_for_crc_16_polynomial_0x8005 is 512 byte .rodata table at
offset 0x20 in .rodata in the object file and
crc_table_for_crc_8_polynomial_0x7 is 256 byte .rodata table at offset 0x220 in
.rodata in the object file.  Only the first ldr is actually encountered at
runtime.
In the objdump -dr crc6.o output that is
  78:   9014adrpx20, 0 <_GLOBAL_OFFSET_TABLE_>
78: R_AARCH64_ADR_PREL_PG_HI21  _GLOBAL_OFFSET_TABLE_
...
  8c:   f9400284ldr x4, [x20]
8c: R_AARCH64_LD64_GOTPAGE_LO15 .rodata+0x220
...
  f4:   f9400297ldr x23, [x20]
f4: R_AARCH64_LD64_GOTPAGE_LO15 .rodata+0x220
...
 148:   f9400294ldr x20, [x20]
148: R_AARCH64_LD64_GOTPAGE_LO15.rodata+0x20
Now in the binary
  [14] .rodata   PROGBITS00400888 000888 000330 00   A 
0   0  8
56: 00400ab8   256 OBJECT  LOCAL  DEFAULT   14
crc_table_for_crc_8_polynomial_0x7
57: 004008b8   512 OBJECT  LOCAL  DEFAULT   14 
crc_table_for_crc_8_polynomial_0x8005

  400738:   f0f4adrpx20, 41f000 <__abi_tag+0x1e274>
...
  40074c:   f947e684ldr x4, [x20, #4040]
...
  4007b4:   f947e697ldr x23, [x20, #4040]
...
  400808:   f947e694ldr x20, [x20, #4040]
As you can see, the actual offset is the same in all 3 cases, and at runtime x4
is loaded from 0x41f000+4040 == 0x41ffc8 and
Contents of section .got:
 41ffc0 f0fd4100  98084000   ..A...@.
 41ffd0      
 41ffe0  
So, it loads the crc_table_for_crc_8_polynomial_0x8005 address in all cases,
even when it should have 2 separate .got entries.
I get this with binutils 2.43.1 and 2.43.50.
When using -fuse-ld={gold,lld,mold} the binary segfaults instead of aborting.
So, is this a binutils bug, or gcc bug (something wrong with what it emits),
both?

[Bug middle-end/118415] [15 Regression] crc optimization uses user accessible symbols

2025-01-11 Thread jakub at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118415

--- Comment #2 from Jakub Jelinek  ---
Created attachment 60113
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60113&action=edit
gcc15-pr118415.patch

Though I wonder why we just don't call output_constant_def, that will simplify
it and will fix PR117997 as well (use section anchors where needed etc.).

It is true we don't merge the tables across TUs that way, but we don't merge
them across TUs right now either (as TREE_PUBLIC isn't set on the symbol).

[Bug c++/114630] [14/15 Regression] [modules] building module with submodule causes corrupt gcm

2025-01-11 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114630

--- Comment #12 from GCC Commits  ---
The master branch has been updated by Nathaniel Shead :

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

commit r15-6822-gd6d7e0261a0ee43c8738b964cbb2572d49d24cad
Author: Nathaniel Shead 
Date:   Fri Jan 10 01:06:37 2025 +1100

c++/modules: Handle chaining already-imported local types [PR114630]

In the linked testcase, an ICE occurs because when reading the
(duplicate) function definition for _M_do_parse from module Y, the local
type definitions have already been streamed from module X and setup as
regular backreferences, rather than being found with find_duplicate,
causing issues with managing DECL_CHAIN.

It is tempting to just skip setting up the DECL_CHAIN for this case.
However, for the future it would be best to ensure that the block vars
for the duplicate definition are accurate, so that we could implement
ODR checking on function definitions at some point.

So to solve this, this patch creates a copy of the streamed-in local
type and chains that; it will be discarded along with the rest of the
duplicate function after we've finished processing.

A couple of suggested implementations from the discussion on the PR that
don't work:

- Replacing the `DECL_CHAIN` assertion with `(*chain && *chain != decl)`
  doesn't handle the case where type definitions are followed by regular
  local variables, since those won't have been imported as separate
  backreferences and so the chains will diverge.

- Correcting the purviewness of GMF template instantiations to force Y
  to emit copies of the local types rather than backreferences into X is
  insufficient, as it's still possible that the local types got streamed
  in a separate cluster to the function definition, and so will be again
  referred to via regular backreferences when importing.

- Likewise, preventing the emission of function definitions where an
  import has already provided that same definition also is insufficient,
  for much the same reason.

PR c++/114630

gcc/cp/ChangeLog:

* module.cc (trees_in::core_vals) : Chain a new node if
DECL_CHAIN already is set.

gcc/testsuite/ChangeLog:

* g++.dg/modules/pr114630.h: New test.
* g++.dg/modules/pr114630_a.C: New test.
* g++.dg/modules/pr114630_b.C: New test.
* g++.dg/modules/pr114630_c.C: New test.

Signed-off-by: Nathaniel Shead 
Reviewed-by: Jason Merrill 
Reviewed-by: Patrick Palka

[Bug c++/114630] [14/15 Regression] [modules] building module with submodule causes corrupt gcm

2025-01-11 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114630

--- Comment #13 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Nathaniel Shead
:

https://gcc.gnu.org/g:7c013a681cc138b8f191b75e408fe322d7fd998c

commit r14-11203-g7c013a681cc138b8f191b75e408fe322d7fd998c
Author: Nathaniel Shead 
Date:   Fri Jan 10 01:06:37 2025 +1100

c++/modules: Handle chaining already-imported local types [PR114630]

In the linked testcase, an ICE occurs because when reading the
(duplicate) function definition for _M_do_parse from module Y, the local
type definitions have already been streamed from module X and setup as
regular backreferences, rather than being found with find_duplicate,
causing issues with managing DECL_CHAIN.

It is tempting to just skip setting up the DECL_CHAIN for this case.
However, for the future it would be best to ensure that the block vars
for the duplicate definition are accurate, so that we could implement
ODR checking on function definitions at some point.

So to solve this, this patch creates a copy of the streamed-in local
type and chains that; it will be discarded along with the rest of the
duplicate function after we've finished processing.

A couple of suggested implementations from the discussion on the PR that
don't work:

- Replacing the `DECL_CHAIN` assertion with `(*chain && *chain != decl)`
  doesn't handle the case where type definitions are followed by regular
  local variables, since those won't have been imported as separate
  backreferences and so the chains will diverge.

- Correcting the purviewness of GMF template instantiations to force Y
  to emit copies of the local types rather than backreferences into X is
  insufficient, as it's still possible that the local types got streamed
  in a separate cluster to the function definition, and so will be again
  referred to via regular backreferences when importing.

- Likewise, preventing the emission of function definitions where an
  import has already provided that same definition also is insufficient,
  for much the same reason.

PR c++/114630

gcc/cp/ChangeLog:

* module.cc (trees_in::core_vals) : Chain a new node if
DECL_CHAIN already is set.

gcc/testsuite/ChangeLog:

* g++.dg/modules/pr114630.h: New test.
* g++.dg/modules/pr114630_a.C: New test.
* g++.dg/modules/pr114630_b.C: New test.
* g++.dg/modules/pr114630_c.C: New test.

Signed-off-by: Nathaniel Shead 
Reviewed-by: Jason Merrill 
Reviewed-by: Patrick Palka

[Bug c++/53479] Control flow analysis reports warnings in switch over an enum class even if all possible values have their branches

2025-01-11 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #26 from Andrew Pinski  ---
Enum class has the full range always (it has an implicit underlying type
specified when one is not specified even). It is an enum without an underlying
type specified that does not.

[Bug middle-end/118419] New: [meta-bug] FSF (physical) mailing address is included in the license header

2025-01-11 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118419

Bug ID: 118419
   Summary: [meta-bug] FSF (physical) mailing address is included
in the license header
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: internal-improvement
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
Depends on: 116558, 116559, 116557
  Target Milestone: ---

When GCC changed from GPLv2 to GPLv3 the FSF (physical) mailing address was
removed from the license header. We should not be reintroducing the mailing
address. This bug tracks cases were the mailing address is still included. Note
the mailing address has changed in 2024 even so it might even be incorrect in
the sources anyways.

https://gcc.gnu.org/pipermail/gcc-patches/2007-July/221394.html


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116557
[Bug 116557] m2: FSF (physical) mailing address is included in the license
header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116558
[Bug 116558] some diagnostic-color* include FSF (physical) mailing address is
included in the license header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116559
[Bug 116559] tree-switch-conversion.cc has FSF (physical) mailing address is
included in the license header

[Bug lto/118424] New: lto/common.cc has FSF (physical) mailing address is included in the license header

2025-01-11 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118424

Bug ID: 118424
   Summary: lto/common.cc has FSF (physical) mailing address is
included in the license header
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: internal-improvement
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
CC: unassigned at gcc dot gnu.org
Blocks: 118419
  Target Milestone: ---
  Host: hppa-netbsd

As mentioned in PR 118419, these should be removed as it has changed again. And
the standard practice is not to include them.

lto/common.cc:Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston, MA


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118419
[Bug 118419] [meta-bug] FSF (physical) mailing address is included in the
license header

[Bug other/118425] New: fixincludes/*.c has FSF (physical) mailing address is included in the license header

2025-01-11 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118425

Bug ID: 118425
   Summary: fixincludes/*.c has FSF (physical) mailing address is
included in the license header
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: internal-improvement
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
CC: unassigned at gcc dot gnu.org
Blocks: 118419
  Target Milestone: ---
  Host: hppa-netbsd

As mentioned in PR 118419, these should be removed as it has changed again. And
the standard practice is not to include them.


fixincludes/procopen.c: * Boston,  MA  02110-1301, USA.
fixincludes/server.c: * Boston,  MA  02110-1301, USA.
fixincludes/server.h: * Boston,  MA  02110-1301, USA.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118419
[Bug 118419] [meta-bug] FSF (physical) mailing address is included in the
license header

[Bug target/118423] New: config/pa/pa32-netbsd.h has FSF (physical) mailing address is included in the license header

2025-01-11 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118423

Bug ID: 118423
   Summary: config/pa/pa32-netbsd.h has FSF (physical) mailing
address is included in the license header
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: internal-improvement
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
Blocks: 118419
  Target Milestone: ---
  Host: hppa-netbsd

As mentioned in PR 118419, these should be removed as it has changed again. And
the standard practice is not to include them.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118419
[Bug 118419] [meta-bug] FSF (physical) mailing address is included in the
license header

[Bug target/118426] New: libgcc/config/avr/lib1funcs-fixed.S has FSF (physical) mailing address is included in the license header

2025-01-11 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118426

Bug ID: 118426
   Summary: libgcc/config/avr/lib1funcs-fixed.S has FSF (physical)
mailing address is included in the license header
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: internal-improvement
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
CC: unassigned at gcc dot gnu.org
Blocks: 118419
  Target Milestone: ---
  Host: avr

As mentioned in PR 118419, these should be removed as it has changed again. And
the standard practice is not to include them.


libgcc/config/avr/lib1funcs-fixed.S:;; Boston, MA 02110-1301, USA.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118419
[Bug 118419] [meta-bug] FSF (physical) mailing address is included in the
license header

[Bug libitm/118427] New: libitm/configure.{ac,tgt} has FSF (physical) mailing address is included in the license header

2025-01-11 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118427

Bug ID: 118427
   Summary: libitm/configure.{ac,tgt} has FSF (physical) mailing
address is included in the license header
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: internal-improvement
  Severity: normal
  Priority: P3
 Component: libitm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
CC: unassigned at gcc dot gnu.org
Blocks: 118419
  Target Milestone: ---
  Host: avr

As mentioned in PR 118419, these should be removed as it has changed again. And
the standard practice is not to include them.


libitm/configure.ac:# Foundation, Inc., 51 Franklin Street, Fifth Floor,
Boston, MA 02110-1301, USA.
libitm/configure.tgt:# Foundation, Inc., 51 Franklin Street, Fifth Floor,
Boston, MA 02110-1301, USA.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118419
[Bug 118419] [meta-bug] FSF (physical) mailing address is included in the
license header

[Bug middle-end/118417] [15 Regression] Bootstrap comparison failure! gcc/range-op.o differs

2025-01-11 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118417

Andrew Pinski  changed:

   What|Removed |Added

 Target||hppa-unknown-linux-gnu
Summary|Bootstrap comparison|[15 Regression] Bootstrap
   |failure! gcc/range-op.o |comparison failure!
   |differs |gcc/range-op.o differs
   Target Milestone|--- |15.0
  Build||hppa-unknown-linux-gnu
   Host||hppa-unknown-linux-gnu
  Component|other   |middle-end
   Keywords||build, wrong-code

[Bug rtl-optimization/118421] New: modulo-sched.cc has FSF (physical) mailing address is included in the license header

2025-01-11 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118421

Bug ID: 118421
   Summary: modulo-sched.cc has FSF (physical) mailing address is
included in the license header
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: internal-improvement
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
CC: unassigned at gcc dot gnu.org
Blocks: 118419
  Target Milestone: ---

As mentioned in PR 118419, these should be removed as it has changed again. And
the standard practice is not to include them.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118419
[Bug 118419] [meta-bug] FSF (physical) mailing address is included in the
license header

[Bug jit/118422] New: jit/jit-dejagnu.h has FSF (physical) mailing address is included in the license header

2025-01-11 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118422

Bug ID: 118422
   Summary: jit/jit-dejagnu.h has FSF (physical) mailing address
is included in the license header
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: internal-improvement
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
CC: antoyo at gcc dot gnu.org, unassigned at gcc dot gnu.org
Blocks: 118419
  Target Milestone: ---

As mentioned in PR 118419, these should be removed as it has changed again. And
the standard practice is not to include them.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118419
[Bug 118419] [meta-bug] FSF (physical) mailing address is included in the
license header

[Bug middle-end/118417] [15 Regression] Bootstrap comparison failure! gcc/range-op.o differs

2025-01-11 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118417

--- Comment #1 from Andrew Pinski  ---
Could you try this patch which disables ifcombine (since there is a known
miscompile in some cases caused by one of the patches in the range you listed,
see PR 118409):
```
[apinski@xeond2 gcc]$ git diff tree-ssa-ifcombine.cc
diff --git a/gcc/tree-ssa-ifcombine.cc b/gcc/tree-ssa-ifcombine.cc
index f791994e3b9..b3812123631 100644
--- a/gcc/tree-ssa-ifcombine.cc
+++ b/gcc/tree-ssa-ifcombine.cc
@@ -1379,6 +1379,7 @@ pass_tree_ifcombine::execute (function *fun)
   basic_block *bbs;
   bool cfg_changed = false;
   int i;
+  return 0;

   bbs = single_pred_before_succ_order ();
   calculate_dominance_info (CDI_DOMINATORS);
```

This is more to see if something is being miscompiled by ifcombine.

[Bug target/118373] gcc-14.2 kernel panic on alderlake cpus

2025-01-11 Thread lancethepants at gmail dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118373

--- Comment #10 from Lance Fredrickson  ---
I have a monitor connected via displayport, but when it crashes it just goes
blank.  There is on the pcb a "jcom1" port for serial access. Should I have
better luck catching it if connect it to another pc and watch the serial
output? I've ordered a cable for it.  Does it need to be a debug build of the
kernel?  If your able to have access again the following link is a build known
to have the issue.
https://tomato64.org/files/x86_64/Releases/2024/2024.5/

[Bug fortran/71884] ICE in gfc_trans_allocate, at fortran/trans-stmt.c:5582 and :5698

2025-01-11 Thread jvdelisle at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71884

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #4 from Jerry DeLisle  ---
(In reply to kargls from comment #3)
> (In reply to Gerhard Steinmetz from comment #1)
--- snip ---
> 
> This now gives
> 
> % gfcx -c pr71884.f90
> pr71884.f90:4:25-31:
> 
> 4 |allocate (character(*) :: z)
>   | 2 1

I am still getting the ICE here. Steve, do you have a patch in there?

[Bug target/118373] gcc-14.2 kernel panic on alderlake cpus

2025-01-11 Thread lancethepants at gmail dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118373

--- Comment #12 from Lance Fredrickson  ---
The screen goes blank and then the device immediately reboots. It's pretty
random, could be within 5-10 minutes or several to numerous hours. My serial
connector should arrive within a day, and then I'll attempt to use something to
log the serial connection.

I'm using musl, and looks like systemd(-pstore) in general is glibc only,
although looks like some semi-successful attempts have been made.
https://catfox.life/2024/01/05/systemd-through-the-eyes-of-a-musl-distribution-maintainer/

[Bug c/118403] uninitialized warning with automatic union

2025-01-11 Thread xry111 at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118403

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #6 from Xi Ruoyao  ---
(In reply to Stephen Hemminger from comment #5)
> (In reply to Andrew Pinski from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > Using `{}` is the correct fix. The referenced part of the C standard here 
> > > is
> > > applying to struct and not unions.
> > 
> > Oh the big reason is GCC switched to defaulting to C23.
> > 
> > Can you attach the preprocessed source with the exact command line used?
> 
> A little difficult with meson build, let me see

Just remove the .o file and run "ninja -v" which will show you the command,
then run the command but replace "-c -o .o" with "-E -o .i"
and you'll get the preprocessed source.

[Bug c++/118428] New: Inherited virtual base class with a private destructor is not rejected during instantiation of the corresponding derived class

2025-01-11 Thread wangbopku15 at gmail dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118428

Bug ID: 118428
   Summary: Inherited virtual base class with a private destructor
is not rejected during instantiation of the
corresponding derived class
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wangbopku15 at gmail dot com
  Target Milestone: ---

Consider the following code:



struct A{
virtual ~A();
};

struct B : private virtual A {};
struct C : private B{};

void foo(){
auto c=C{};
}



Clang rejects it with the following diagnostic: 



:6:8: error: inherited virtual base class 'A' has private destructor
6 | struct C : private B{};
  |^
:9:12: note: in implicit default constructor for 'C' first required
here
9 | auto c=C{};
  |^
:5:12: note: declared private here
5 | struct B : private virtual A {};
  |^
:6:8: error: inherited virtual base class 'A' has private destructor
6 | struct C : private B{};
  |^
:9:12: note: in implicit destructor for 'C' first required here
9 | auto c=C{};
  |^
:5:12: note: declared private here
5 | struct B : private virtual A {};
  |^
2 errors generated.



MSVC with:



(6): warning C4594: class 'C' can never be instantiated - indirect
virtual base class 'A' is inaccessible
(5): note: 'A' is a private base class of 'B'
(6): warning C4624: 'C': destructor was implicitly defined as deleted
(6): error C2282: 'C::~C' cannot override 'B::~B'
(5): note: 'B::~B' is not deleted



It seems that the instantiation of class 'C' should not be allowed as the
destructor of 'A' is private within 'B'.

But GCC accepts this:

https://godbolt.org/z/qdsz1oxq1

[Bug libstdc++/112808] Consider enabling _GLIBCXX_ASSERTIONS checks by default for debug builds

2025-01-11 Thread helge at penne dot no via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112808

--- Comment #5 from helge at penne dot no ---
Thank you for doing this. I think this will have a big impact.

I do hope that when this has been in use for a while and users have fixed most
of the bugs that it will reveal, then perhaps you can enable it for
release/optimised builds as well (perhaps even in gcc 16?). I think that have a
huge impact on security, and it may not affect performance nearly as much as
many think: https://chandlerc.blog/posts/2024/11/story-time-bounds-checking/

[Bug libstdc++/112808] Consider enabling _GLIBCXX_ASSERTIONS checks by default for debug builds

2025-01-11 Thread sjames at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112808

--- Comment #6 from Sam James  ---
My plan was/is to wait for the 15 cycle to be done, see if any reports come in,
and go from there and ask Jonathan what he thinks.

I have been filing some missed-optimisation bugs when _GLIBCXX_ASSERTIONS is
enabled but so far they're not bad.

[Bug c++/118428] Inherited virtual base class with a private destructor is not rejected during instantiation of the corresponding derived class

2025-01-11 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118428

--- Comment #1 from Andrew Pinski  ---
EDG also accepts it.

Note clang 3.3 accepts it while clang 3.4 rejects it. Let see if I can find the
clang change.

[Bug c++/118428] Inherited virtual base class with a private destructor is not rejected during instantiation of the corresponding derived class

2025-01-11 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118428

--- Comment #2 from Andrew Pinski  ---
https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#7

Hmm, it looks like GCC started to accept it after the defect report was filed
and then closed as NAD.

[Bug target/118373] gcc-14.2 kernel panic on alderlake cpus

2025-01-11 Thread andi-gcc at firstfloor dot org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118373

--- Comment #13 from Andi Kleen  ---
If it immediately reboots (and you didn't use panic=XXX to reboot quickly) then
it might be a triple fault. These are unfortunately harder to debug because
they don't produce any console output in a native setup.

[Bug c++/94404] [meta-bug] C++ core issues

2025-01-11 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404
Bug 94404 depends on bug 118428, which changed state.

Bug 118428 Summary: [DR7] Inherited virtual base class with a private 
destructor is not rejected during instantiation of the corresponding derived 
class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118428

   What|Removed |Added

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

[Bug c++/55120] Inaccessible virtual base constructor does not prevent generation of default constructor

2025-01-11 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55120

Andrew Pinski  changed:

   What|Removed |Added

 CC||wangbopku15 at gmail dot com

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

[Bug c++/118428] [DR7] Inherited virtual base class with a private destructor is not rejected during instantiation of the corresponding derived class

2025-01-11 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118428

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Yes this is a dup of bug 55120.
I am still confused at what the overall resolution here is.

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

[Bug target/118429] New: [15 regression] ICE when building poppler-24.11.0 on arm64 (in process_uses_of_deleted_def, at rtl-ssa/changes.cc:276)

2025-01-11 Thread sjames at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118429

Bug ID: 118429
   Summary: [15 regression] ICE when building poppler-24.11.0 on
arm64 (in process_uses_of_deleted_def, at
rtl-ssa/changes.cc:276)
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: acoplan at gcc dot gnu.org, tnfchris at gcc dot gnu.org
  Target Milestone: ---

Created attachment 60119
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60119&action=edit
Annot.cc.ii.xz

```
# gcc -c ./CMakeFiles/poppler.dir/poppler/Annot.cc.ii -O3 -std=gnu++20
during RTL pass: ldp_fusion
/var/tmp/portage/app-text/poppler-24.11.0-r1/work/poppler-24.11.0/poppler/Annot.cc:
In member function ‘bool AnnotAppearanceBuilder::drawFormField(const
FormField*, const Form*, const GfxResources*, const GooString*, const
AnnotBorder*, const AnnotAppearanceCharacs*, const PDFRectangle*, const
GooString*, XRef*, Dict*)’:
/var/tmp/portage/app-text/poppler-24.11.0-r1/work/poppler-24.11.0/poppler/Annot.cc:5144:1:
internal compiler error: in process_uses_of_deleted_def, at
rtl-ssa/changes.cc:276
 5144 | }
  | ^
0xe4394b5f diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, std::__va_list*,
diagnostic_t)
???:0
0xe43230db internal_error(char const*, ...)
???:0
0xe43232af fancy_abort(char const*, int, char const*)
???:0
0xe53ac033
rtl_ssa::function_info::process_uses_of_deleted_def(rtl_ssa::set_info*)
???:0
0xe51893eb
rtl_ssa::function_info::change_insns(array_slice)
???:0
0xe51ef5f7 pair_fusion::process_block(rtl_ssa::bb_info*)
???:0
0xe51edf2b pair_fusion::run()
???: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.
```

---

```
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/aarch64-unknown-linux-gnu/15/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./configure
--host=aarch64-unknown-linux-gnu --build=aarch64-unknown-linux-gnu
--prefix=/usr --bindir=/usr/aarch64-unknown-linux-gnu/gcc-bin/15
--includedir=/usr/lib/gcc/aarch64-unknown-linux-gnu/15/include
--datadir=/usr/share/gcc-data/aarch64-unknown-linux-gnu/15
--mandir=/usr/share/gcc-data/aarch64-unknown-linux-gnu/15/man
--infodir=/usr/share/gcc-data/aarch64-unknown-linux-gnu/15/info
--with-gxx-include-dir=/usr/lib/gcc/aarch64-unknown-linux-gnu/15/include/g++-v15
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/aarch64-unknown-linux-gnu/15/python
--enable-objc-gc --enable-languages=c,c++,d,go,objc,obj-c++,fortran,ada,m2,rust
--enable-obsolete --enable-secureplt --disable-werror --with-system-zlib
--enable-nls --without-included-gettext --disable-libunwind-exceptions
--enable-checking=yes,extra,rtl --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 15.0. p, commit
93975113f3b353a27dea263c60ee62b27894be9b' --with-gcc-major-version-only
--enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--disable-multilib --disable-fixed-point --enable-libgomp --disable-libssp
--enable-libada --disable-standard-branch-protection --disable-systemtap
--disable-valgrind-annotations --disable-vtable-verify --disable-libvtv
--with-zstd --with-isl --disable-isl-version-check --enable-default-pie
--enable-host-pie --enable-host-bind-now --enable-default-ssp
--disable-fixincludes --with-build-config='bootstrap-O3 bootstrap-lto'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20250110 (experimental)
086031c058598512d09bf898e4db3735b3e1f22c (Gentoo 15.0. p, commit
93975113f3b353a27dea263c60ee62b27894be9b)
```

[Bug target/118429] [15 regression] ICE when building poppler-24.11.0 on arm64 (in process_uses_of_deleted_def, at rtl-ssa/changes.cc:276)

2025-01-11 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118429

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
   Keywords||ice-on-valid-code

[Bug target/118429] [15 regression] ICE when building poppler-24.11.0 on arm64 (in process_uses_of_deleted_def, at rtl-ssa/changes.cc:276)

2025-01-11 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118429

--- Comment #1 from Andrew Pinski  ---
  gcc_assert (use->is_live_out_use ());


The full backtrace (pair-fusion.cc is compiled with -O0):
during RTL pass: ldp_fusion
/var/tmp/portage/app-text/poppler-24.11.0-r1/work/poppler-24.11.0/poppler/Annot.cc:
In member function ‘bool AnnotAppearanceBuilder::drawFormField(const
FormField*, const Form*, const GfxResources*, const GooString*, const
AnnotBorder*, const AnnotAppearanceCharacs*, const PDFRectangle*, const
GooString*, XRef*, Dict*)’:
/var/tmp/portage/app-text/poppler-24.11.0-r1/work/poppler-24.11.0/poppler/Annot.cc:5144:1:
internal compiler error: in process_uses_of_deleted_def, at
rtl-ssa/changes.cc:276
0x38f6f8d internal_error(char const*, ...)
../../gcc/diagnostic-global-context.cc:517
0x38c7763 fancy_abort(char const*, int, char const*)
../../gcc/diagnostic.cc:1722
0x3674811
rtl_ssa::function_info::process_uses_of_deleted_def(rtl_ssa::set_info*)
../../gcc/rtl-ssa/changes.cc:276
0x3676aca
rtl_ssa::function_info::change_insns(array_slice)
../../gcc/rtl-ssa/changes.cc:863
0x35ed747 pair_fusion_bb_info::fuse_pair(bool, unsigned int, int,
rtl_ssa::insn_info*, rtl_ssa::insn_info*, base_cand&, rtl_ssa::insn_range_info
const&)
../../gcc/pair-fusion.cc:1992
0x35ef11c pair_fusion_bb_info::try_fuse_pair(bool, unsigned int,
rtl_ssa::insn_info*, rtl_ssa::insn_info*)
../../gcc/pair-fusion.cc:2805
0x35ef3cd
pair_fusion_bb_info::merge_pairs(std::__cxx11::list >&, std::__cxx11::list >&, bool, unsigned int)
../../gcc/pair-fusion.cc:2894
0x35ef5bc pair_fusion_bb_info::transform_for_base(int, access_group&)
../../gcc/pair-fusion.cc:2927
0x35f219c void
pair_fusion_bb_info::traverse_base_map,
int_hash >, access_group,
simple_hashmap_traits,
int_hash > >, access_group> >
>(ordered_hash_map, int_hash >, access_group,
simple_hashmap_traits,
int_hash > >, access_group> >&)
../../gcc/pair-fusion.cc:2975
0x35ef831 pair_fusion_bb_info::transform()
../../gcc/pair-fusion.cc:2983
0x35e9f17 pair_fusion::process_block(rtl_ssa::bb_info*)
../../gcc/pair-fusion.cc:3110
0x35e4f71 pair_fusion::run()
../../gcc/pair-fusion.cc:133
0x23d2716 execute
../../gcc/config/aarch64/aarch64-ldp-fusion.cc:303
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/96570] Warnings desired for time_t to int coversions

2025-01-11 Thread xry111 at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96570

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #11 from Xi Ruoyao  ---
Also note that

srand(time(nullptr));

should be perfectly valid code even after 2038.  Now to suppress the warning we
can write

srand((int)time(nullptr));

So if we start to warn even with an explicitly cast, how would we handle this
case now?

[Bug middle-end/118430] musttail false positive on how locals are used

2025-01-11 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118430

--- Comment #3 from Andrew Pinski  ---
I have to double check but maybe the error message is just wrong.

[Bug libstdc++/118416] std::experimental::simd code detecting all zero is not optimized to simple ptest on x86-64 avx

2025-01-11 Thread lee.imple at gmail dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118416

--- Comment #1 from Imple Lee  ---
Possibly related: PR90483 .

[Bug c/118403] uninitialized warning with automatic union

2025-01-11 Thread sjames at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118403

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #7 from Sam James  ---
Or just `ninja --verbose -C build`, see the relevant command (use
-Werror=uniniitalized to make it easier), then copy/paste it, re-run it with
-save-temps appended.

  1   2   >