[Bug tree-optimization/107409] Perf loss ~5% on 519.lbm_r SPEC cpu2017 benchmark with r10-5090-ga9a4edf0e71bba

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

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

--- Comment #16 from Martin Liška  ---
@Honza: ???

[Bug lto/108330] [13 Regression] ICE in add, at hash-set.h:64

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Last reconfirmed||2023-01-09

--- Comment #1 from Martin Liška  ---
I've got a patch candidate.

[Bug tree-optimization/105294] restrict pointer - disagreement with specification

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

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

Richard Biener  changed:

   What|Removed |Added

  Component|c   |tree-optimization
   Last reconfirmed||2023-01-09
 Status|UNCONFIRMED |NEW
   Keywords||wrong-code
 Ever confirmed|0   |1
 Blocks||49774

--- Comment #3 from Richard Biener  ---
(In reply to Matthew House from comment #2)
> Isn't this example invalid per the spec? At `*r = 42;`, `&*r` is based on
> `s`. However, `*p = 13;` modifies the same object that `*r` refers to, and
> `&*p` is not based on `s`, so the behavior is undefined.
> 
> I've recently found another example which is valid under the current spec as
> well as the two new proposed definitions in N3025 and N3058. 
> 
> https://godbolt.org/z/ezvMfPd78
> 
> static int x;
> 
> __attribute__ ((noinline))
> int f(int * restrict p) {
>   *p = 1;
>   if (p == &x) {
> *p = 2;
>   }
>   return *p;
> }
> 
> int main(void) {
>   return f(&x);
> }
> 
> At `*p = 2;`, `&*p` is based on `p` under every definition. However, both
> GCC and Clang incorrectly assume that the write to `*p` inside the `if`
> block cannot affect the return value.

While the early alias (restrict) pass figures correct base/cliques the
early VRP pass propagates the conditional equivalence and turns the IL
into

__attribute__((noinline))
int f (int * restrict p)
{
  int _6;

   :
  *p_3(D) = 1;
  if (p_3(D) == &x)
goto ; [INV]
  else
goto ; [INV]

   :
  x = 2;

   :
  _6 = *p_3(D);
  return _6;
}

which in turn is "invalid" as to the restrict rules.  So the core issue is
that we apply (a supposedly stricter set of) restrict rules to our internal
IL rather than the language definition to the language specific AST.  But
the propagation of conditional equivalences makes that "stricter" set of
rules not strict enough.

(Propagating) conditional equivalences is bad.

We _might_ get away with disallowing propagation to restrict qualified
uses, but that might in the end also pessimize things.  We could also
refrain from re-computing restrict info after inlining.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49774
[Bug 49774] [meta-bug] restrict qualification aliasing issues

[Bug target/108339] New: riscv64-linux-gnu: fails to link libgcc_s.so on the GCC 10 branch

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

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

Bug ID: 108339
   Summary: riscv64-linux-gnu: fails to link libgcc_s.so on the
GCC 10 branch
   Product: gcc
   Version: 10.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

the gcc-10 branch fails to build on riscv64-linux-gnu with the binutils-2.40
branch, trying to build a cross compiler, building libgcc_s.so:

/usr/riscv64-linux-gnu/bin/ld: relocation R_RISCV_JAL against `__udivdi3' which
may bind externally
 can not be used when making a shared object; recompile with -fPIC
collect2: error: ld returned 1 exit status
make[5]: *** [Makefile:994: libgcc_s.so] Error 1
make[5]: Leaving directory
'/<>/gcc/build/riscv64-linux-gnu/libgcc'

all newer branches and the trunk successfully build with this binutils
versions, so assuming that some backport is needed for the gcc-10 branch to
work with recent binutils?

[Bug libstdc++/108332] dynamic link libstdc++ with win32 thread model's gcc for windows native toolchain would cause .rdata_r: section below image base

[nightstrike at gmail dot com via Gcc-bugs]

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

nightstrike  changed:

   What|Removed |Added

 CC||10walls at gmail dot com,
   ||nightstrike at gmail dot com

--- Comment #5 from nightstrike  ---
(In reply to cqwrteur from comment #4)
> (In reply to Andrew Pinski from comment #3)
> > cygwin was improved here:
> > https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;
> > h=801120c1f402f9b0f72b5a231bf9e1cf82614cac
> > 
> > It might be the case mingw linker script is broken 
> 
> This is mingw-w64, not newlib-cygwin

I think he's suggesting that we have to apply the same solution to mingw that
Corinna applied to Cygwin.

[Bug libstdc++/108326] Question about definitions in c++config.h for gcc13 20221229

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

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Jamaika from comment #4)
> I tried adding c++config definitions to gcc 11.3.1 with
> _GLIBCXX_HAS_GTHREADS.

What do you mean? The c++config.h file is created by GCC during installation,
you can't edit it, and you can't define (or redefine) those macros.

[Bug middle-end/108300] `abort()` macro cause bootstrap failure on *-w64-mingw32

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

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

--- Comment #14 from Jonathan Wakely  ---
Yes. Your mingw headers have changed, adding  which is incompatible
with the 'abort' macro in the GCC sources.

[Bug tree-optimization/101912] -Wmaybe-uninitialized false alarm in tzdb localtime.c

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #9 from Richard Biener  ---
We simply optimize this better now.  I'll add the testcase.

[Bug tree-optimization/107767] [13 Regression] switch to table conversion happening even though using btq is better

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #18 from Richard Biener  ---
Mine then.

[Bug c++/108321] [13 regression] g++.dg/contracts/contracts-tmpl-spec2.C fails after r13-4160-g2efb237ffc68ec

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
> FAIL: compiler driver --help=c++ option(s): "^ +-.*[^:.]$" absent from
> output: "  -fcontract-build-level=[off|default|audit] Specify max contract
> level to generate runtime checks for"

This is fixed after r13-4290-g138ee8f7453ffd.

[Bug tree-optimization/91470] [10/11/12 Regression] bogus uninitialized warning in trans-intrinsic.c

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

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

--- Comment #12 from Richard Biener  ---
OK, so better optimization.

[Bug target/108004] x-form logical operations with dot instructions are not emitted.

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

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

Segher Boessenkool  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Resolution|INVALID |---
 Status|RESOLVED|SUSPENDED
   Last reconfirmed||2023-01-09

--- Comment #7 from Segher Boessenkool  ---
It's not really invalid, but it won't happen any time soon.

The upper bits *are* defined for argument passing, in all our 64-bit ABIs:
for signed type (like here the value is passed sign-extended.  But the code
has "(a & b) > 0" which does the comparison as an int.  In combine we get

Trying 11 -> 14:
   11: r124:SI=r129:DI#4&r130:DI#4
  REG_DEAD r130:DI
  REG_DEAD r129:DI
   14: r125:CC=cmp(r124:SI,0)
  REG_DEAD r124:SI
Failed to match this instruction:
(set (reg:CC 125)
(compare:CC (and:SI (subreg:SI (reg:DI 129) 4)
(subreg:SI (reg:DI 130) 4))
(const_int 0 [0])))

If we upgraded some stuff to DImode instead of SImode, sometimes we can
make better code, like we could here.  But in other cases the opposite is
true.  I think it is likely it helps more often than it would hurt, and we
can upgrade the mode only sometimes as well of course.

In any case, this is just a special case of a much more generic problem
(in all ports, not just rs6000!), that has been known for a very long time,
and no real progress has been made yet.  But it definitely should be doable.
To simplify the problem a lot it probably is okay to only consider upgrading
the mode of a pseudo everywhere (so not do it in some insns but not others),
and then assign a score to it.  Probably a higher score inside loops, that
is the case where we see this most / where we see it as a shortcoming most.

Where rs6000 is special here is that we have "w" and "d" (32-bit and 64-bit)
variants of many insns (but no smaller versions most of the time fwiw).

[Bug tree-optimization/86318] const local aggregates can be assumed not to be modified even when escaped

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

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

--- Comment #5 from Richard Biener  ---
(In reply to Josh Haberman from comment #4)
> Is there any plan or timeline for fixing this bug?

No.  There's no agreed upon way on how to design such a fix.

[Bug target/108339] riscv64-linux-gnu: fails to link libgcc_s.so on the GCC 10 branch

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-01-09
 CC||kito at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

[Bug middle-end/108237] [13 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 at -O since r13-1085-g90467f0ad649d081

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

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

--- Comment #8 from Richard Biener  ---
Btw, I've also backported the offending rev. to the GCC 12 branch, so
presumably we want this fix also there even if just out of caution.

[Bug middle-end/35560] Missing CSE/PRE for memory operations involved in virtual call.

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

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

--- Comment #16 from Richard Biener  ---
(In reply to Witold Baryluk from comment #15)
> I know this is a pretty old bug, but I was exploring some assembly of gcc
> and clang on godbolt, and also stumbled into same issue.
> 
> https://godbolt.org/z/qPzMhWse1
> 
> class A {
> public:
> virtual int f7(int x) const;
> };
> 
> int g(const A * const a, int x) {
> int r = 0;
> for (int i = 0; i < 1; i++)
> r += a->f7(x);
> return r;
> }
> 
> (same happens without loop, when just calling a->f7 multiple times)
> 
> 
> 
> g(A const*, int):
> pushr13
> mov r13d, esi
> pushr12
> xor r12d, r12d
> pushrbp
> mov rbp, rdi
> pushrbx
> mov ebx, 1
> sub rsp, 8
> .L2:
> mov rax, QWORD PTR [rbp+0]   # a vtable deref
> mov esi, r13d
> mov rdi, rbp
> call[QWORD PTR [rax]]# f7 indirect call
> add r12d, eax
> dec ebx
> jne .L2
> 
> add rsp, 8
> pop rbx
> pop rbp
> mov eax, r12d
> pop r12
> pop r13
> ret
> 
> 
> I was expecting  mov rax, QWORD PTR [rbp+0] and call[QWORD PTR
> [rax]], to be hoisted out of the loop (call converted to lea, and call
> register).
> 
> 
> A bit sad.
> 
> Is there some recent work done on this optimization?
> 
> Are there at least some cases where it is valid to do CSE, or change code so
> it is moved out of the loop?

GCC sees a->f() as possibly altering the virtual table [pointer] since
the function gets passed 'a' and thus a pointer to it (and *a is global
memory anyway, so GCC has to assume f() has access to it).

In C++ probably there's probably no virtual function that could do this.
A virtual DTOR would leave an uninitialized object.  Not sure if

class A
{
  virtual void f() { }
}
class B : A
{
  virtual void f() { new A (this); }
}

would be valid (maybe with first calling the DTOR on the existing object).

[Bug c/107993] ICE: tree check: expected string_cst, have integer_cst in get_target_clone_attr_len, at tree.cc:14872

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Martin Liska :

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

commit r13-5063-gbefd29d5fe15c09638f73eeeb1f8a9e62ce569ee
Author: Martin Liska 
Date:   Tue Dec 27 16:31:57 2022 +0100

c: check if target_clone attrs are all string

PR c/107993

gcc/c-family/ChangeLog:

* c-attribs.cc (handle_target_clones_attribute): Check for
string constant for all target_clone attribute values.

gcc/testsuite/ChangeLog:

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

[Bug c/107993] ICE: tree check: expected string_cst, have integer_cst in get_target_clone_attr_len, at tree.cc:14872

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Liška  ---
Fixed for master, not planning to do a backport.

[Bug c/108296] __builtin_memcpy generating wrong code in some cases

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|DUPLICATE   |INVALID

--- Comment #5 from Richard Biener  ---
Not a duplicate but indeed invalid.  For the aggregate asignment
you cannot have an object of type data live at &x and &x + 1 at the same time.

[Bug tree-optimization/101912] -Wmaybe-uninitialized false alarm in tzdb localtime.c

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

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Richard Biener :

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

commit r13-5064-g7afecddf1ecbb93ee44517ad6d3e9c1c0d68e722
Author: Richard Biener 
Date:   Mon Jan 9 11:00:43 2023 +0100

tree-optimization/101912 - testcase for fixed uninit case

We now properly optimize this testcase and no longer diagnose
a bogus uninit use.

PR tree-optimization/101912
* gcc.dg/uninit-pr101912.c: New testcase.

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

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

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

Bug 101912 Summary: -Wmaybe-uninitialized false alarm in tzdb localtime.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101912

   What|Removed |Added

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

[Bug tree-optimization/101912] -Wmaybe-uninitialized false alarm in tzdb localtime.c

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
  Known to work||13.0
   Target Milestone|--- |13.0

--- Comment #11 from Richard Biener  ---
Fixed for GCC 13.

[Bug tree-optimization/97108] [10/11/12/13 Regression] -Wmaybe-uninitialized false positive

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

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

Bug 101912 Summary: -Wmaybe-uninitialized false alarm in tzdb localtime.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101912

   What|Removed |Added

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

[Bug libstdc++/77691] [10/11/12/13 regression] experimental/memory_resource/resource_adaptor.cc FAILs

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

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

--- Comment #55 from Jonathan Wakely  ---
Created attachment 54215
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54215&action=edit
Generalise special case for malloc not afreeing with max_align_t

I think we also want to fix the actual code to meet the guarantee, not just
relax the test.

Maybe like this.

[Bug tree-optimization/108306] false-positive -Warray-bounds warning emitted with -fsanitize=shift

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
I fail to get any diagnostic with the better PoC:

> gcc-12 -S t.c -Warray-bounds -fsanitize=shift -O2 -fno-strict-aliasing
>

what options are required?

[Bug libstdc++/108331] [13 Regression] ABI break of std::__c_file and std::fstream for win32 thread model of GCC for windows

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

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

--- Comment #4 from Jonathan Wakely  ---
That would be more flexible, but I'm not sure this is a problem that will
happen again. This is a particular case where we have a completely unused
member variable that just needs a specific layout.

It occurs to me libstdc++ could just check the GCC_GTHR_WIN32_H include guard,
although an explicitly-defined macro with a documented purpose (even if just
via a comment) would be less fragile.

How's this?

diff --git a/libgcc/config/i386/gthr-win32.h b/libgcc/config/i386/gthr-win32.h
index 146357fa436..050c7a21fcc 100644
--- a/libgcc/config/i386/gthr-win32.h
+++ b/libgcc/config/i386/gthr-win32.h
@@ -381,6 +381,14 @@ typedef struct timespec __gthread_time_t;
 #define __GTHREAD_COND_INIT_FUNCTION __gthread_cond_init_function
 #define __GTHREAD_TIME_INIT {0, 0}

+// Libstdc++ std::basic_filebuf needs the old definition of __gthread_mutex_t
+// for layout purposes, but doesn't actually use it.
+typedef struct {
+  long __unused1;
+  void *__unused2;
+} __gthr_win32_legacy_mutex_t;
+#define __GTHREAD_LEGACY_MUTEX_T __gthr_win32_legacy_mutex_t
+
 #if defined (_WIN32) && !defined(__CYGWIN__)
 #define MINGW32_SUPPORTS_MT_EH 1
 /* Mingw runtime >= v0.3 provides a magic variable that is set to nonzero
diff --git a/libstdc++-v3/config/io/c_io_stdio.h
b/libstdc++-v3/config/io/c_io_stdio.h
index 1a5e05a844a..e9e6e3ef4d8 100644
--- a/libstdc++-v3/config/io/c_io_stdio.h
+++ b/libstdc++-v3/config/io/c_io_stdio.h
@@ -39,7 +39,14 @@ namespace std _GLIBCXX_VISIBILITY(default)
 {
 _GLIBCXX_BEGIN_NAMESPACE_VERSION

+#ifdef __GTHREAD_LEGACY_MUTEX_T
+  // The layout of __gthread_mutex_t changed in GCC 13, but libstdc++ doesn't
+  // actually use the basic_filebuf::_M_lock member, so define it consistently
+  // with the old __gthread_mutex_t to avoid an unnecessary layout change:
+  typedef __GTHREAD_LEGACY_MUTEX_T __c_lock;
+#else
   typedef __gthread_mutex_t __c_lock;
+#endif

   // for basic_file.h
   typedef FILE __c_file;

[Bug libstdc++/108331] [13 Regression] ABI break of std::__c_file and std::fstream for win32 thread model of GCC for windows

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

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

--- Comment #5 from Eric Botcazou  ---
> How's this?

This looks good to me, thanks!

[Bug middle-end/69482] Writing through pointers to volatile not always preserved

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #8 from Richard Biener  ---
Note we do expand volatile qualified variables to memory but this case is about
non-volatile qualified variables stored to through volatile qualified pointers.
So it's

int foo (int i)
{
  volatile int j = i;
  return j;
}

vs.

int bar (int i)
{
  int j;
  *(volatile int *)&j = i;
  return j;
}

I have a patch.

[Bug middle-end/69482] Writing through pointers to volatile not always preserved

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #9 from Richard Biener  ---
*** Bug 108298 has been marked as a duplicate of this bug. ***

[Bug middle-end/108298] Wrong optimization of volatile access from gcc 11 and beyond

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #8 from Richard Biener  ---
Yes, and I think it's a duplicate in the end.

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

[Bug c/108340] New: compiler segfault

[julien.staub at se dot com via Gcc-bugs]

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

Bug ID: 108340
   Summary: compiler segfault
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: julien.staub at se dot com
  Target Milestone: ---

Created attachment 54216
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54216&action=edit
minimal file to reproduce

To reproduce :
1. Downloaded arm-gnu-toolchain-12.2.rel1-mingw-w64-i686-arm-none-eabi.zip from
https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads
2. In attached zip, modify and run compilerBug.bat (will just compile 1 faulty
file known to work)
3. observe segmentation fault in compiler

Actual Results: What happened after performing the above steps.

```
C:\FW>"C:\GIT\FW_Toolchain\GNU Tools ARM
Embedded\12.2.rel1\bin\arm-none-eabi-gcc.exe" -DSTM32U575xx=1
-IC:/FW/minimalInc -O3 -DNDEBUG -freport-bug -mcpu=cortex-m33 -mthumb
-mfpu=fpv5-sp-d16 -mfloat-abi=hard --specs=nano.specs -ffunction-sections
-fdata-sections -fno-builtin -Wall -Wfatal-errors -O3 -std=gnu17 -o
stm32u5xx_hal_dma_ex.c.obj -c C:/FW/minimalInc/stm32u5xx_hal_dma_ex.c
during GIMPLE pass: evrp
C:/FW/minimalInc/stm32u5xx_hal_dma_ex.c: In function
'HAL_DMAEx_List_ReplaceNode_Head':
C:/FW/minimalInc/stm32u5xx_hal_dma_ex.c:4689:1: internal compiler error:
Segmentation fault
 4689 | }
  | ^
Please submit a full bug report, with preprocessed source.
See  for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.
```

It's possible to reproduce issue with only godbolt :
https://godbolt.org/z/oG8rGfG4E
and GCC 11.x to 12.2 seem affected. -O0 will not show the bug.

I also opened the bug on Linaro for arm-none-aebi-gcc build but it seems this
is a GCC issue and I did not find it bug list.
https://bugs.linaro.org/show_bug.cgi?id=5924

[Bug tree-optimization/108341] New: argument to `__builtin_ctz` should be assumed non-zero

[lh_mouse at 126 dot com via Gcc-bugs]

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

Bug ID: 108341
   Summary: argument to `__builtin_ctz` should be assumed non-zero
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lh_mouse at 126 dot com
  Target Milestone: ---

Godbolt: https://gcc.godbolt.org/z/PrPP4v9z1


```
extern int r;

int
bz(int value)
  {
r = __builtin_ctz(value);
return value != 0;  // always true
  }
```


According to GCC manual, if the argument to `__builtin_ctz()` is zero then the
behavior is undefined, but GCC fails to assume that this function always
returns `1`. 

But I have read https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94801, not sure
whether it's related.

[Bug c/108340] compiler segfault

[julien.staub at se dot com via Gcc-bugs]

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

--- Comment #1 from Julien  ---
striped even more : https://godbolt.org/z/YqoPKqoKK

[Bug lto/108330] [13 Regression] ICE in add, at hash-set.h:64

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Martin Liska :

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

commit r13-5065-gfb082e3293d45d928ae107d8f351b04be89d1bc2
Author: Martin Liska 
Date:   Mon Jan 9 09:51:01 2023 +0100

hash: do not insert deleted value to a hash_set

PR lto/108330

gcc/ChangeLog:

* lto-cgraph.cc (compute_ltrans_boundary): Do not insert
NULL (deleleted value) to a hash_set.

gcc/testsuite/ChangeLog:

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

[Bug c/108340] compiler segfault

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Working on that, it's fixed on master, so bisecting now.

Reduced test-case:

int DMA_List_CheckNodesBaseAddresses_pNode1,
DMA_List_CheckNodesBaseAddresses_pNode2;
int DMA_List_CheckNodesBaseAddresses() {
  unsigned temp = ((int)&DMA_List_CheckNodesBaseAddresses_pNode1 |
   (int)&DMA_List_CheckNodesBaseAddresses_pNode2) &
  65535 << 16;
  int ref = (int)&DMA_List_CheckNodesBaseAddresses_pNode1;
  if (temp != (ref & 65535 << 16))
return 1;
}

$ arm-suse-linux-gnueabi-gcc-11 pr108340.i -c -O2
during GIMPLE pass: evrp
pr108340.i: In function 'DMA_List_CheckNodesBaseAddresses':
pr108340.i:10:1: internal compiler error: Segmentation fault
   10 | }
  | ^
0x778b78df ???
   
/usr/src/debug/glibc-2.36/signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x778a15af __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x778a1678 __libc_start_main_impl
../csu/libc-start.c:381
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug lto/108330] [13 Regression] ICE in add, at hash-set.h:64

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Fixed.

[Bug tree-optimization/108341] argument to `__builtin_ctz` should be assumed non-zero

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org,
   ||amacleod at redhat dot com,
   ||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
May be an opportunity for Ranger?

[Bug middle-end/69482] Writing through pointers to volatile not always preserved

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

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Richard Biener :

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

commit r13-5066-ga5a8242153d078f1ebe60f00409415da260a29ee
Author: Richard Biener 
Date:   Mon Jan 9 12:46:28 2023 +0100

middle-end/69482 - not preserving volatile accesses

The following addresses a long standing issue with not preserving
accesses to non-volatile objects through volatile qualified
pointers in the case that object gets expanded to a register.  The
fix is to treat accesses to an object with a volatile qualified
access as forcing that object to memory.  This issue got more
exposed recently so it regressed more since GCC 11.

PR middle-end/69482
* cfgexpand.cc (discover_nonconstant_array_refs_r): Volatile
qualified accesses also force objects to memory.

* gcc.target/i386/pr69482-1.c: New testcase.
* gcc.target/i386/pr69482-2.c: Likewise.

[Bug middle-end/69482] Writing through pointers to volatile not always preserved

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||13.0

--- Comment #11 from Richard Biener  ---
fixed on trunk, queued for eventual backporting.

[Bug c/108340] compiler segfault

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Dup.

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

[Bug tree-optimization/106878] [11/12 Regression] ICE: verify_gimple failed at -O2 with pointers and bitwise calculation

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||julien.staub at se dot com

--- Comment #12 from Martin Liška  ---
*** Bug 108340 has been marked as a duplicate of this bug. ***

[Bug target/107453] [13 Regression] New stdarg tests in r13-3549-g4fe34cdcc80ac2 fail

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

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

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

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

commit r13-5067-gb1879fb84e78fa2c530e66de43f3dc125820864a
Author: Jakub Jelinek 
Date:   Mon Jan 9 13:36:22 2023 +0100

calls: Fix up TYPE_NO_NAMED_ARGS_STDARG_P handling [PR107453]

On powerpc64le-linux, the following patch fixes
-FAIL: gcc.dg/c2x-stdarg-4.c execution test
-FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c   -O0  execution test
-FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c   -O1  execution test
-FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c   -O2  execution test
-FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  execution test
-FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
-FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c   -O3 -g  execution test
-FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c   -Os  execution test
The problem is mismatch between the caller and callee side.
On the callee side, we do:
  /* NAMED_ARG is a misnomer.  We really mean 'non-variadic'. */
  if (!cfun->stdarg)
data->arg.named = 1;  /* No variadic parms.  */
  else if (DECL_CHAIN (parm))
data->arg.named = 1;  /* Not the last non-variadic parm. */
  else if (targetm.calls.strict_argument_naming (all->args_so_far))
data->arg.named = 1;  /* Only variadic ones are unnamed.  */
  else
data->arg.named = 0;  /* Treat as variadic.  */
which is later passed to the target hooks to determine if a particular
argument is named or not.  Now, cfun->stdarg is determined from the
stdarg_p
call, which for the new C2X TYPE_NO_NAMED_ARGS_STDARG_P function types
(rettype fn (...)) returns true.  Such functions have no named arguments,
so data->arg.named will be 0 in function.cc.  But on the caller side,
as TYPE_NO_NAMED_ARGS_STDARG_P function types have TYPE_ARG_TYPES NULL,
we instead treat those calls as unprototyped even when they are prototyped
- /* If we know nothing, treat all args as named.  */ n_named_args =
num_actuals;
in 2 spots.  We need to treat the TYPE_NO_NAMED_ARGS_STDARG_P cases as
prototyped with no named arguments.

2023-01-09  Jakub Jelinek  

PR target/107453
* calls.cc (expand_call): For calls with
TYPE_NO_NAMED_ARGS_STDARG_P (funtype) use zero for n_named_args.
Formatting fix.

[Bug target/107453] [13 Regression] New stdarg tests in r13-3549-g4fe34cdcc80ac2 fail

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Fixed on powerpc64le-linux.  I've also on a cross to sparc64-linux tested that
without the patch both c2x-stdarg-4.c and c2x-stdarg-split-1{a,b}.c at -O0
abort and with the patch succeed.
No testing on nvptx nor loongarch, so if it is still broken there, please
reopen.

[Bug tree-optimization/108008] [12 Regression] wrong code with -O3 and posix_memalign since r12-4526-gd8edfadfc7a9795b

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||rguenth at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=107323
  Known to work||13.0
   Keywords||needs-bisection

--- Comment #13 from Richard Biener  ---
(In reply to Alexander Monakov from comment #9)
> I think this is tree-ldist placing memset(sameZ, 0, zPlaneCount) after the
> loop, overwriting conditional 'sameZ[i] = true' assignments that happen in
> the loop.
> 
> For the smaller testcase from comment #6, -O2 -ftree-loop-distribution is
> enough, namely:
> 
> works:
> 
> gcc-12 -O2 -ftree-loop-distribution -fno-tree-vectorize
> -fno-tree-loop-distribute-patterns
> 
> breaks:
> 
> gcc-12 -O2 -ftree-loop-distribution -fno-tree-vectorize

Note I can not reproduce on the branch after r12-8855-g19a9b5e587e87f52,
so maybe that's truly the duplicate.

Bisecting on the branch might reveal that.

[Bug c++/108342] New: std::complex: ignoring packed attribute because of unpacked non-POD field

[ruilvo at ua dot pt via Gcc-bugs]

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

Bug ID: 108342
   Summary: std::complex: ignoring packed attribute because of
unpacked non-POD field
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ruilvo at ua dot pt
  Target Milestone: ---

Created attachment 54217
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54217&action=edit
Code to reproduce the bug report

Summary:

With the annexed code, reproduced on the following CE link:
https://godbolt.org/z/1q9a5Mq7r

I get the following warning:

```
:29:16: warning: ignoring packed attribute because of unpacked non-POD
field 'fcomplex_t ::bb_iq_samples [512]'
   29 | fcomplex_t bb_iq_samples[BB_FRAME_IQ_SAMPLES_COUNT];
  |^
```

Clang doesn't complain facing the same code.


Details:

I was trying to write a C++ library, which is going to target an ARM Linux
system, but leaving C-compatible "bindings" and structs for using with CFFI on
other languages.

The library deals with a serial stream that I don't control, and that I wanted
to de-serialize, thus the weird structure. 

I discovered the problem (warning) when I changed from a C source file and
`_Complex float` to C++ and `std::complex`. 

The compiler I first discovered the problem on was arm-linux-gnueabihf-g++
(GCC) 12.2.1 20221203 [releases/gcc-12 revision
c03cb4b762aceeba95da918b042583af0d9f6030] from Linaro. 

The bug is reproducible on x86 and mainline GCC (see Compiler Explorer URL)


Expected behaviour:

For this code to compile without warnings and producing the desired effect
(packing). The C++ standard even carves out a guarantee than `_Complex
[float|double]` is memory-layout-compatible with
`std::complex<[float|double]>`.

[Bug libstdc++/108221] Building cross compiler for H8 family fails at libstdc++-v3/src/c++20/tzdb.cc

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

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

--- Comment #14 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #3)
> /tmp/ccC7KXoL.s: Assembler messages:
> /tmp/ccC7KXoL.s:82719: Error: value of 0001254e too large for field of 2
> bytes at 0002

I still see these errors with binutils HEAD. I get it nearly 16000 times for
tzdb.o

[Bug tree-optimization/108199] Bitfields, unions and SRA and storage_order_attribute

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #8 from Richard Biener  ---
Eric fixed multiple storage-order issues in SRA so probably can comment here.

[Bug testsuite/108204] pr84973-2.C fails with wrong error on mingw

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

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

Richard Biener  changed:

   What|Removed |Added

  Component|c++ |testsuite

--- Comment #3 from Richard Biener  ---
I'd suggest to add a dg-additional-options -fno-ms-extensions to the test then.

[Bug c++/108206] [12 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in merge_default_template_args, at cp/decl.cc:1563 since r12-7562-gfe548eb8436

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||13.0
   Priority|P3  |P4

[Bug testsuite/108204] pr84973-2.C fails with wrong error on mingw

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #4 from nightstrike  ---
(In reply to Richard Biener from comment #3)
> I'd suggest to add a dg-additional-options -fno-ms-extensions to the test
> then.

We certainly can (well, Jon can :P), but shouldn't the ms extensions ultimately
be fixed to work right?

[Bug middle-end/108209] goof in genmatch.cc:commutative_op

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-01-09
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #2 from Richard Biener  ---
Mine.

[Bug tree-optimization/108215] Does not optimize trivial case with bit operations

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

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

--- Comment #2 from Richard Biener  ---
It's something for if-conversion / if-combine.  We have

   [local count: 1073741824]:
  src_6 = MEM[(const uint32_t *)data_5(D)];
  _1 = src_6 & 4294967040;
  if (_1 == 287453952)
goto ; [20.97%]
  else
goto ; [79.03%]

   [local count: 848578161]:
  _2 = src_6 & 4294901760;
  if (_2 == 287440896)
goto ; [20.97%]
  else
goto ; [79.03%]

   [local count: 177946843]:

   [local count: 1073741824]:
  # _3 = PHI <1(4), 0(3), 1(2)>

so an effective if-or-if where we fail to handle combining the conditions
(we're going the if-and-if way to the zero return).

[Bug c++/108218] [12/13 Regression] Constant arguments in the new expression is not checked in unevaluated operand since r12-5253-g4df7f8c79835d569

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

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

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c/108340] compiler segfault

[julien.staub at se dot com via Gcc-bugs]

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

--- Comment #4 from Julien  ---
Thank you. 
Can you please confirm if this will be fixed in 12.2.x or only in 13.0 ?

Are fixes ported to 12.x along the way or are patches chosen just before
release ?

[Bug middle-end/108298] Wrong optimization of volatile access from gcc 11 and beyond

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

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

--- Comment #9 from Segher Boessenkool  ---
It cannot be a duplicate: this bug was introduced much later than when
PR69482 was filed!

But glad the same patch seems to have fixed both, sure :-)

[Bug ipa/108226] __restrict on inlined function parameters does not function as expected

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
  Component|tree-optimization   |ipa
   Last reconfirmed||2023-01-09

--- Comment #1 from Richard Biener  ---
For the first case it's the order of inlining - we first inline Func2 into
Func3 early and only then inline Func1 at IPA time which fails to put the Func1
accesses under __restrict.

For the second case it's with __restrict:

> ./cc1 -quiet t.c -O2 -fopt-info -fdump-tree-all
t.c:27:3: optimized:  Inlining Func2/2 into Func3/3.
t.c:22:3: optimized:  Inlined Func1.isra/5 into Func3/3 which now has time
12.50 and size 21, net change of -7.

vs without

> ./cc1 -quiet t.c -O2 -fopt-info -fdump-tree-all
t.c:27:3: optimized:  Inlining Func2/2 into Func3/3.
t.c:22:3: optimized:  Inlined Func1.constprop.isra/6 into Func3/3 which now has
time 4.375000 and size 7, net change of -21.

so somehow the restrict qualification pessimizes IPA-CP?!  Martin?

Note with restrict it's again the first issue.  -fno-early-inlining helps
there.

[Bug middle-end/108298] Wrong optimization of volatile access from gcc 11 and beyond

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #10 from rguenther at suse dot de  ---
On Mon, 9 Jan 2023, segher at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108298
> 
> --- Comment #9 from Segher Boessenkool  ---
> It cannot be a duplicate: this bug was introduced much later than when
> PR69482 was filed!

It wasn't introduced - the present issue was exposed for this case ;-)

[Bug sanitizer/108343] New: ASAN at -O3 misses a heap-use-after-free

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

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

Bug ID: 108343
   Summary: ASAN at -O3 misses a heap-use-after-free
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shaohua.li at inf dot ethz.ch
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

For the following code, ASAN at -O3 misses the heap-use-after-free, while other
opt levels catch it.

% cat a.c
#include 
int a, c;
char b;
int main() {
  char **d = malloc(sizeof(char*));
  for(int i=0; i<1; i++)
*d = malloc(sizeof(char));
  d[0][0] = 0;
  int e, f = -1;
  free(d[0]);
  free(d);
  for (; a <= 1; a++) {
long g[1];
g;
c = f;
e = 0;
for (; e <= 1; e++) {
  c |= d[a][0];
  if (b)
c = a;
}
  }
  return c;
}
%
% gcc-tk -fsanitize=address -g -O2 a.c && ./a.out
=
==2253130==ERROR: AddressSanitizer: heap-use-after-free on address
0x60200010 at pc 0x00401210 bp 0x7ffdd10f9a90 sp 0x7ffdd10f9a88
READ of size 8 at 0x60200010 thread T0
#0 0x40120f in main /zdata/shaoli/sanitizertesting/mutate/bugs/gcc/a.c:18
#1 0x7f15496b0082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
...
%
% gcc-tk -fsanitize=address -g -O3 a.c && ./a.out
%

[Bug tree-optimization/108227] Unnecessary division when looping over array with size of elements not a power of two

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

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

--- Comment #3 from Richard Biener  ---
it boils down to IVOPTs

[Bug target/108240] [13 Regression] ICE in emit_library_call_value_1 at gcc/calls.cc:4181 since r13-4894-gacc727cf02a144

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|ICE in  |[13 Regression] ICE in
   |emit_library_call_value_1   |emit_library_call_value_1
   |at gcc/calls.cc:4181 since  |at gcc/calls.cc:4181 since
   |r13-4894-gacc727cf02a144|r13-4894-gacc727cf02a144
   Priority|P3  |P1

[Bug rtl-optimization/108241] [12/13 Regression] ICE in lra_eliminate_regs_1, at lra-eliminations.cc:658

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.3
   Priority|P3  |P2

[Bug c++/108242] [10/11/12/13 Regression] '__FUNCTION__' was not declared when used inside a generic (templated) lambda declared inside a template function

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/108243] [10/11/12/13 Regression] Missed optimization for static const std::string_view(const char*)

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.5

[Bug preprocessor/108244] [13 Regression] `pragma GCC diagnostic` and -E -fdirectives-only causes the preprocessor to become confused since r13-1544-ge46f4d7430c52104

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug middle-end/108209] goof in genmatch.cc:commutative_op

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:46034c46f82dec169fe7fc7c2d82d8321d9a9512

commit r13-5068-g46034c46f82dec169fe7fc7c2d82d8321d9a9512
Author: Richard Biener 
Date:   Mon Jan 9 14:28:03 2023 +0100

middle-end/108209 - typo in genmatch.cc:commutative_op

The early out for user-id handling indicated commutative
rather than not commutative.

PR middle-end/108209
* genmatch.cc (commutative_op): Fix return value for
user-id with non-commutative first replacement.

[Bug middle-end/108209] goof in genmatch.cc:commutative_op

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Fixed.

[Bug ipa/108250] [12/13 regression] llvm-tblgen miscompiled on powerpc-unknown-linux-gnu since r12-5383-g22c242342e38eb

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.3

[Bug target/108240] [13 Regression] ICE in emit_library_call_value_1 at gcc/calls.cc:4181 since r13-4894-gacc727cf02a144

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

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

--- Comment #4 from Segher Boessenkool  ---
(In reply to Kewen Lin from comment #3)
> With the culprit commit r13-4894, we always implicitly enable powerpc64 for
> both explicit and implicit 64 bit, it's the same as before for the explicit
> 64 bit case, but for the implicit 64 bit case, there is no chance for the
> used cpu to unset powerpc64 (like this case). To keep it consistent with the
> previous, the fix can be to only enable powerpc64 implicitly for explicit 64
> bit, while let it be for implicit 64 bit.

No?  If the user says to use a CPU without 64-bit instructions, while the
user also says we require 64-bit insns (via -m64), we should just error.
Not hide the problem (and cause many more problems!)

We used to do that:

f951: Error: ‘-m64’ requires a PowerPC64 cpu

We can do such a check again, just in a bit different spot probably.

[Bug target/108274] [13 Regression] ICE in df_refs_verify during arm_reorg pass with -fipa-icf

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug middle-end/35560] Missing CSE/PRE for memory operations involved in virtual call.

[m.cencora at gmail dot com via Gcc-bugs]

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

m.cencora at gmail dot com changed:

   What|Removed |Added

 CC||m.cencora at gmail dot com

--- Comment #17 from m.cencora at gmail dot com ---
It is (In reply to Richard Biener from comment #16)
> (In reply to Witold Baryluk from comment #15)
> > I know this is a pretty old bug, but I was exploring some assembly of gcc
> > and clang on godbolt, and also stumbled into same issue.
> > 
> > https://godbolt.org/z/qPzMhWse1
> > 
> > class A {
> > public:
> > virtual int f7(int x) const;
> > };
> > 
> > int g(const A * const a, int x) {
> > int r = 0;
> > for (int i = 0; i < 1; i++)
> > r += a->f7(x);
> > return r;
> > }
> > 
> > (same happens without loop, when just calling a->f7 multiple times)
> > 
> > 
> > 
> > g(A const*, int):
> > pushr13
> > mov r13d, esi
> > pushr12
> > xor r12d, r12d
> > pushrbp
> > mov rbp, rdi
> > pushrbx
> > mov ebx, 1
> > sub rsp, 8
> > .L2:
> > mov rax, QWORD PTR [rbp+0]   # a vtable deref
> > mov esi, r13d
> > mov rdi, rbp
> > call[QWORD PTR [rax]]# f7 indirect call
> > add r12d, eax
> > dec ebx
> > jne .L2
> > 
> > add rsp, 8
> > pop rbx
> > pop rbp
> > mov eax, r12d
> > pop r12
> > pop r13
> > ret
> > 
> > 
> > I was expecting  mov rax, QWORD PTR [rbp+0] and call[QWORD PTR
> > [rax]], to be hoisted out of the loop (call converted to lea, and call
> > register).
> > 
> > 
> > A bit sad.
> > 
> > Is there some recent work done on this optimization?
> > 
> > Are there at least some cases where it is valid to do CSE, or change code so
> > it is moved out of the loop?
> 
> GCC sees a->f() as possibly altering the virtual table [pointer] since
> the function gets passed 'a' and thus a pointer to it (and *a is global
> memory anyway, so GCC has to assume f() has access to it).
> 
> In C++ probably there's probably no virtual function that could do this.
> A virtual DTOR would leave an uninitialized object.  Not sure if
> 
> class A
> {
>   virtual void f() { }
> }
> class B : A
> {
>   virtual void f() { new A (this); }
> }
> 
> would be valid (maybe with first calling the DTOR on the existing object).

It is valid, but to be able to use B object after B::f was invoked (and a new
object is placed there instead), a user need to launder the pointer.
https://en.cppreference.com/w/cpp/utility/launder

[Bug c/108340] compiler segfault

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

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

--- Comment #5 from Jakub Jelinek  ---
The trunk change caused various regressions and needed multiple follow-ups, I'm
afraid it is not a good idea to backport that.
r13-2658, r13-2709, r13-2891 at least.
Perhaps backporting the 2 match.pd hunks from r13-2658 and nothing else could
work for 12.3, provided it fixes the testcases.

[Bug sanitizer/108343] ASAN at -O3 misses a heap-use-after-free

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
It has similar symptoms like PR108085.

[Bug tree-optimization/108008] [12 Regression] wrong code with -O3 and posix_memalign since r12-4526-gd8edfadfc7a9795b

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

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

Martin Liška  changed:

   What|Removed |Added

   Keywords|needs-bisection |

--- Comment #14 from Martin Liška  ---
> Note I can not reproduce on the branch after r12-8855-g19a9b5e587e87f52,
> so maybe that's truly the duplicate.

gcc-12 branch is fixed since the mentioned revision.

[Bug modula2/108182] gm2 driver mishandles target and multilib options

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

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

--- Comment #10 from Gaius Mulley  ---
here is version 4 of the bugfix which enables the driver to link against shared
libraries.

[Bug modula2/108261] modula-2 module registration process seems to fail with shared libraries.

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

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

--- Comment #7 from Gaius Mulley  ---
Created attachment 54218
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54218&action=edit
Potential fix for target multilib_dir handling (version 4) shared lib fix

[Bug modula2/108344] New: Many tests time out: isatty called in a tight loop

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

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

Bug ID: 108344
   Summary: Many tests time out: isatty called in a tight loop
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
  Host: i386-pc-solaris2.11
Target: i386-pc-solaris2.11
 Build: i386-pc-solaris2.11

I'm seeing a very weird error running the m2 testsuite on Solaris/x86: quite
a number of tests time out in compilation.  However, this only happens when
gcc is configured to use /bin/as, not with gas.  Besides, the timeouts affect
only 64-bit compiltions.  I'm seeing this with both flex 2.5.35 and 2.6.4.

Here's what I observe: for the affected tests, is in a tight loop like this:

12901:  /var/gcc/regression/master/11.4-gcc/build/gcc/cc1gm2 -fcpp-begin -E -l
 fabbd4c7 ioctl(0x6, 0x0, 0x1032, 0x8c15c33) + 7
 08c15c87 yy_init_buffer(yy_buffer_state*, __FILE*) (0xadce188, 0xadce189,
0xfeff9778, 0xadce188, 0x0, 0xadce189) + 67
 08c15d17 yyrestart(__FILE*) (0xad29110, 0x1, 0x2000, 0xad29110, 0x14,
0xadcbb60) + 27
 08c18918 yylex() (0xad6c320, 0xfeff97f0, 0xfeff97f8, 0x8c4e16f, 0x2a, 0x1) +
2668
 08c18b9c m2flex_GetToken (0x2a, 0x1, 0xfeff9808, 0x8c4e16f, 0xadd4d58, 0x2a) +
3c
 08c4e16f M2LexBuf_GetToken (0x1, 0xfeff983c, 0xfeff9858, 0x8c347cd, 0xadd3750,
0x2a) + 3f
 08c4ebe5 M2LexBuf_OpenSource (0xadd3750, 0x2a, 0xfeff9858, 0x8c344d8) + 65
 08c347cd M2Comp_compile (0xfeffa662, 0x43, 0x36, 0xad33290) + 3fd
 08bea500 gm2_langhook_parse_file() (0x3, 0xf9e09000, 0xfeff9948, 0x92a78d7,
0x43, 0x0) + 60
 092a442d compile_file() (0x2, 0x8b3c3de, 0xfeff9948, 0x92a7e34) + 1d
 092a78dc toplev::main(int, char**) (0x1000, 0x84ee24f, 0xfae8e310, 0xa4411e1)
+ 136c
 0a4411e1 main (0xfeff9c6c, 0xfeff99b4, 0x8be8add) + 31
 08be8a46 _start   (0x4f, 0xfeff9cee, 0xfeff9d23, 0xfeff9d2f, 0xfeff9d32,
0xfeff9d3c) + 46

That ioctl is

ioctl(6, TCGETA, 0xFEFF96E0)Err#25 ENOTTY

no doubt resulting from calls to isatty in the generated gm2-compiler/m2flex.c.

What's even weirder, if I run such a compilation manually, it completes in
about
half a second, and I've not yet managed to reproduce the issue with anything
but
a full make -jN -k check-m2 run.  This is pretty tedious because those 600
second
timeouts massively add up, slowing the whole test time tremendously.

I've already tried using flex -B to generate the lexer, but that didn't make
a difference, which judging from the skeleton file is no wonder.  However, when
using --never-interactive, things gets way worse: I've already several
instances of cc1gm2 running for 12+ minutes (way beyond the 600 second timeout
of runtest),
making not syscall whatsoever.  All this suggests that something is very weird
in the m2 lexer somewhere.

Here's the list of affected tests (all in gm2/iso/pass, doesn't change between
runs):

addadr1.mod
bits32c.mod
callwraptime.mod
caseiso.mod
caseiso2.mod
cast.mod
cast3.mod
castiso.mod
ChanConsts.mod
const1.mod
constreal.mod
constructor1.mod
constructor2.mod
constructor3.mod
constructor4.mod
constructor5.mod
constructor6.mod
constsize4.mod
ConvTypes.mod
delim.mod
delim2.mod
enummodule.mod
except1.mod
expproc.mod
expproc2.mod
isob.mod
isobitset.mod
isobitset2.mod
longm.mod
m.mod
proccast.mod
realbitscast.mod
set12.mod
stringchar.mod
subassign.mod
testaddindr.mod
testconv.mod
testconv2.mod
testconv3.mod
testconv4.mod
testconv5.mod
testconv6.mod
testconv7.mod
testconv8.mod
testconv9.mod
testiso.mod
testiso2.mod
testisosize.mod
testlength.mod
testlength2.mod
testlength3.mod
testlength4.mod
testlength5.mod
unbounded.mod
unbounded2.mod

[Bug modula2/108344] Many tests time out: isatty called in a tight loop

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

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug web/88860] Clarify gcc online manual 6.38 Attribute Syntax

[jg at jguk dot org via Gcc-bugs]

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

--- Comment #7 from Jonny Grant  ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to Jonny Grant from comment #5)
> > Re the patches, I recall I did email them, but pasted here too as another
> > developer was doing that. I'll have a good read of that contribution guide.
> 
> If you've emailed them to the list then it's better to link to the mails in
> the list archive, not duplicate them here.
>  
> > What did you think of the "infelicities" patch?
> 
> It loses a little of the nuance, i.e. that the limitations are unfortunate.
> But I think it's an improvement.

Ok thank you. May I ask if you could commit the patch please?

[Bug web/88860] Clarify gcc online manual 6.38 Attribute Syntax

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

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

--- Comment #8 from Jonathan Wakely  ---
Has it been reviewed and approved? I can't do that for patches outside the
libstdc++-v3 dir.

[Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c

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

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

--- Comment #12 from Aldy Hernandez  ---
(In reply to Richard Biener from comment #6)
> (In reply to Jakub Jelinek from comment #0)
> > ... but then
> > comes dom2 and happily replaces
> >   _1 = 3.4028234663852885981170418348451692544e+38 * 2.0e+0;
> >   return _1;
> > with
> >   _1 = 3.4028234663852885981170418348451692544e+38 * 2.0e+0;
> >   return  Inf;
> > (I think this is still correct)
> 
> Note this is also a pessimization code-generation wise since if we
> preserve the multiplication the result is readily available in a
> register but as optimized we have another constant pool entry and load.
> 
> So we might want to consider not propagating constants generated by
> operations
> we cannot eliminate.  If the only consumer is a compare-and-branch we
> can of course still end up with a seemingly dead stmt, so this would be only
> for the missed optimization.

[Sorry for the delayed response.  I've been on PTO.]

For the original testcase, the propagation happens in DOM:

   [local count: 1073741824]:
  _1 = 3.4028234663852885981170418348451692544e+38 * 2.0e+0;
  return _1;

range_of_expr gets called on the return's _1 and correctly returns Inf, which
allows cprop_operand to do the replacement.

If I understand correctly you're suggesting not propagating constants that were
generated by an operation we can't eliminate.  In this case, it'd be easy to
chase the DEF back to the offending _1 definition (from cprop_operand and every
other places where we do propagations based on range_of_expr's result), but
ranger doesn't keep track of how it got to an answer, so we'd have to chase all
operands used to generate _1??  That'd get hairy pretty fast, unless I'm
misunderstanding something.

It really looks like the problem here is DCE (and the gimplifier as you point
out in comment #2), which is removing a needed statement.  Can't this be fixed
there?

[Bug fortran/108329] IEEE_SET_ROUNDING_MODE ineffective with common subexpression elimination

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

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #3 from Thomas Koenig  ---
Seems to be much more complicated than I thought, see the thrad starting at
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609532.html

[Bug web/88860] Clarify gcc online manual 6.38 Attribute Syntax

[jg at jguk dot org via Gcc-bugs]

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

--- Comment #9 from Jonny Grant  ---
(In reply to Jonathan Wakely from comment #8)
> Has it been reviewed and approved? I can't do that for patches outside the
> libstdc++-v3 dir.

I've not yet received a reply to it on gcc-patches list.

https://gcc.gnu.org/pipermail/gcc-patches/2022-December/609132.html

[Bug c++/107616] c++tools: select not found breaks build

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

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

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

https://gcc.gnu.org/g:0925a9772960c946440833033423bff41c330154

commit r13-5072-g0925a9772960c946440833033423bff41c330154
Author: John David Anglin 
Date:   Mon Jan 9 15:41:51 2023 +

Fix compilation of server.cc on hpux.

Select and FD_ISSET are declared in sys/time.h on most versions
of hpux.  As a result, HAVE_PSELECT and HAVE_SELECT can be 0.

2023-01-08  John David Anglin  

c++tools/ChangeLog:

PR other/107616
* server.cc (server): Don't call FD_ISSET when HAVE_PSELECT
and HAVE_SELECT are zero.

[Bug tree-optimization/108341] argument to `__builtin_ctz` should be assumed non-zero

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

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

--- Comment #2 from Aldy Hernandez  ---
(In reply to Martin Liška from comment #1)
> May be an opportunity for Ranger?

Hmmm... I don't think so:

 :
value.0_1 = (unsigned int) value_4(D);
_2 = __builtin_ctz (value.0_1);
r = _2;
_3 = value_4(D) != 0;
_7 = (int) _3;
return _7;

We could add an op1_range operator to class cfn_clz to return nonzero for op1,
but that would only work if we knew _2 to be anything...and have no info on _2.

[Bug c++/108342] std::complex: ignoring packed attribute because of unpacked non-POD field

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

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

--- Comment #1 from Andrew Pinski  ---
>The C++ standard even carves out a guarantee than `_Complex [float|double]` is 
>memory-layout-compatible with `std::complex<[float|double]>`.

I know about _Atomic and std::atomic but not std::complex and _Complex. Because
std::complex was part of C++98 which was done before C99's _Complex ...

[Bug libstdc++/108342] std::complex: ignoring packed attribute because of unpacked non-POD field

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

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

--- Comment #2 from Andrew Pinski  ---
Hmm: diff.cpp03.numerics

[Bug libstdc++/108342] std::complex: ignoring packed attribute because of unpacked non-POD field

[ruilvo at ua dot pt via Gcc-bugs]

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

--- Comment #3 from Rui Oliveira  ---
(In reply to Andrew Pinski from comment #1)
> 
> I know about _Atomic and std::atomic but not std::complex and _Complex.
> Because std::complex was part of C++98 which was done before C99's _Complex
> ...

[complex.numbers.general] mentions:

If z is an lvalue of type cv complex then: 
the expression reinterpret_­cast(z) is well-formed,

https://eel.is/c++draft/complex.numbers.general

Basically stating that std::complex is layouted exactly the same as T[2]. 

C standard says something similar iirc.

[Bug libstdc++/108342] std::complex: ignoring packed attribute because of unpacked non-POD field

[ruilvo at ua dot pt via Gcc-bugs]

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

--- Comment #4 from Rui Oliveira  ---
(In reply to Andrew Pinski from comment #2)
> Hmm: diff.cpp03.numerics

I saw you moved the bug to libstdc++ but is the problem libstdc++, or should
g++ just accept packing when it encounters it?

[Bug libstdc++/108342] std::complex: ignoring packed attribute because of unpacked non-POD field

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

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

--- Comment #5 from Jonathan Wakely  ---
I don't think there's anything the library can do here. The layout of
std::complex is fixed, as stated above. And the fact it's a non-POD is also
fixed.

If the front-end warns about trying to pack a non-POD, then the library can't
stop it warning about std::complex.

I don't know whether clang allows packing non-PODs, or just doesn't ever warn
for them, or has a special case for std::complex, or does something smarter
like not warn for types that have no padding bytes anyway (so that packing them
would be a no-op).

[Bug c++/107616] c++tools: select not found breaks build

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

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #4 from John David Anglin  ---
Fixed on trunk.

[Bug tree-optimization/108341] argument to `__builtin_ctz` should be assumed non-zero

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

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

--- Comment #3 from Andrew Pinski  ---
Not always.
It depends on the definition of CTZ_DEFINED_VALUE_AT_ZERO.

/* The value at zero is only defined for the BMI instructions
   LZCNT and TZCNT, not the BSR/BSF insns in the original isa.  */
#define CTZ_DEFINED_VALUE_AT_ZERO(MODE, VALUE) \
((VALUE) = GET_MODE_BITSIZE (MODE), TARGET_BMI ? 2 : 0)
#define CLZ_DEFINED_VALUE_AT_ZERO(MODE, VALUE) \
((VALUE) = GET_MODE_BITSIZE (MODE), TARGET_LZCNT ? 2 : 0)



So assuming !=0 with -mbmi would be an invalid assumitation.

[Bug c++/108342] std::complex: ignoring packed attribute because of unpacked non-POD field

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|libstdc++   |c++

--- Comment #6 from Andrew Pinski  ---
clang:
typedef struct __attribute__((__packed__))
{
/** Every frame starts with BB_FRAME_MAGIC. */
uint32_t magic;
unsigned char t;

fcomplex_t bb_iq_samples[BB_FRAME_IQ_SAMPLES_COUNT];

} bb_frame_t;
int t = sizeof(bb_frame_t);

t:
.long   4101# 0x1005
.size   t, 4


it might be the case clang does not implement the ABI 

[Bug c++/108342] std::complex: ignoring packed attribute because of unpacked non-POD field

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Jonathan Wakely from comment #5)
> I don't know whether clang allows packing non-PODs, or just doesn't ever
> warn for them, or has a special case for std::complex, or does something
> smarter like not warn for types that have no padding bytes anyway (so that
> packing them would be a no-op).

clang allows packing of non-PODs:
```
class f
{
public:
  f();
private:
  int t[2];
};

typedef struct __attribute__((__packed__))
{
/** Every frame starts with BB_FRAME_MAGIC. */
unsigned magic;
unsigned char t;

f bb_iq_samples[100];

} bb_frame_t;
```

[Bug modula2/108261] modula-2 module registration process seems to fail with shared libraries.

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

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

--- Comment #8 from Iain Sandoe  ---
This is good in that it removes the extra -Ls, but ...

1. This will not work in general for targets with spec substitution for library
names - the library names *do* need to be on the driver line,

2. It will probably not work for -static-libgm2 on Bstatic/dynamic targets
either because those options need to be inserted in the lang-specific driver.

I think it would be quite hard to implement the target-specific changes in the
specs .. 

* The include spec are nicely handled by this change and now they do not appear
in parts of the driver output that does not need them.

* The library driving I *think* still needs to live in the language-specific
driver.

.. I'll add an updated patch later, if that's OK

Unfortunately, I do not think that the library ordering is enough to fix this
PR ..

[Bug c++/108342] std::complex: ignoring packed attribute because of unpacked non-POD field

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #8 from Andrew Pinski  ---
r0-51814-ge0d1297c4320ae added the warning and started to ignore the packed
(back in 2003).

[Bug tree-optimization/108341] argument to `__builtin_ctz` should be assumed non-zero when CTZ_DEFINED_VALUE_AT_ZERO says it is undefined

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
I think 0 argument for __builtin_c[lt]z{,l,ll,imax} is always undefined, 0
argument
to .C[LT]Z (internal calls) is undefined if C[LT]Z_DEFINED_VALUE_AT_ZERO is not
2 and
0 argument to C[LT]Z RTL is undefined if C[LT]Z_DEFINED_VALUE_AT_ZERO is not
non-zero.

[Bug c++/108342] std::complex: ignoring packed attribute because of unpacked non-POD field

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #9 from Andrew Pinski  ---
https://gcc.gnu.org/pipermail/gcc-patches/2003-July/110087.html

This was done on purpose. GCC also rejects References too while clang accepts
that (but I am not sure it gives the correct code for references of packed
either which is why GCC started to reject it).

[Bug middle-end/107991] [10/11/12/13 Regression] Extra mov instructions with ternary on x86

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com

--- Comment #6 from Roger Sayle  ---
An x86 peephole2 to workaround the problem was proposed here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609578.html
but improved register allocation (if possible) would be a better solution:
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609588.html

[Bug target/108339] [10 only] riscv64-linux-gnu: fails to link libgcc_s.so on the GCC 10 branch

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |10.5