[Bug c++/105593] avx512 math function raises uninitialized variable warning

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

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

--- Comment #8 from Richard Biener  ---
(In reply to Jason Merrill from comment #5)
> (In reply to Richard Biener from comment #4)
> > fails to hide the -Wuninitialized with the C++ frontend, works correct with
> > the C frontend and on the GCC 11 branch.
> 
> I also get the warning on the 11 branch.  And all the way back to the 4.1
> branch, which is the oldest I have handy; this doesn't seem like a
> regression.

I can confirm that even

void bar (int);

void baz()
{
  int u = u;
  bar (u);
}

warns with the C++ frontend, so the self-init "trick" to suppress uninit
diagnostics was never implemented in the new parser (it diagnoses with
GCC 3.4 but not with 3.3).  So it's kind-of a regression, but ...

[Bug tree-optimization/99412] s352 benchmark of TSVC is vectorized by clang and not by gcc

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

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

--- Comment #3 from Richard Biener  ---
(In reply to Jan Hubicka from comment #2)
> This is also seen with zen4 comparing gcc and aocc. (about 2.3 times
> differnece)

Disabling

@@ -6877,7 +6887,7 @@ reassociate_bb (basic_block bb)
  binary op are chosen wisely.  */
   int len = ops.length ();
   if (len >= 3)
 swap_ops_for_binary_stmt (ops, len - 3, stmt);

will naturally create the reduction chain (or leave it in place) given the
current rank computation.  We do have (somewhat) robust fallback from
reduction chain to reduction (via reduction path support), so I think this
change would be OK.

[Bug tree-optimization/99412] s352 benchmark of TSVC is vectorized by clang and not by gcc

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

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

--- Comment #4 from Richard Biener  ---
(In reply to Richard Biener from comment #3)
> (In reply to Jan Hubicka from comment #2)
> > This is also seen with zen4 comparing gcc and aocc. (about 2.3 times
> > differnece)
> 
> Disabling
> 
> @@ -6877,7 +6887,7 @@ reassociate_bb (basic_block bb)
>   binary op are chosen wisely.  */
>int len = ops.length ();
>if (len >= 3)
>  swap_ops_for_binary_stmt (ops, len - 3, stmt);
> 
> will naturally create the reduction chain (or leave it in place) given the
> current rank computation.  We do have (somewhat) robust fallback from
> reduction chain to reduction (via reduction path support), so I think this
> change would be OK.

The code originated from r0-111616-gdf7b0cc4aae062, the reassoc rewrite by
Jeff back in 2005 for GCC 4.3 (or 4.2, don't have that tree around anymore).

[Bug tree-optimization/108374] [12/13 Regression] unexpected -Wstringop-overflow when using std::atomic and std::shared_ptr

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Priority|P3  |P2
   Target Milestone|--- |12.3
   Last reconfirmed||2023-01-12
 Ever confirmed|0   |1
Version|unknown |12.2.0

--- Comment #2 from Richard Biener  ---
We now say

cc1plus: note: destination object is likely at address zero

 [local count: 1073741824]:
_9 = MEM[(const struct __shared_ptr &)pointer_2(D)]._M_ptr;
_10 = MEM[(const struct __shared_count &)pointer_2(D) + 8]._M_pi;
if (_10 != 0B)
  goto ; [53.47%]
else
  goto ; [46.53%]

 [local count: 499612072]:
__atomic_load_8 (16B, 5); [tail call]
D.37576 ={v} {CLOBBER};
D.37576 ={v} {CLOBBER(eol)};
goto ; [100.00%] (leads straight to return)

so we have __shared_count of pointer _M_pi == 0 here, whatever that means
and not sure why we atomically load here.

Confirmed.

[Bug tree-optimization/108374] [12/13 Regression] unexpected -Wstringop-overflow when using std::atomic and std::shared_ptr

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Romain Geissler from comment #0)
> std::weak_ptr weakPointer(pointer);
> 
> [[maybe_unused]] const unsigned int aAttr = weakPointer.lock()->_attr;

If pointer == nullptr then weakPointer.lock() is also null, and so
dereferencing it to access the attr member is undefined, and does indeed
perform an atomic load at address 0.

Instead of complaining about it, I would expect GCC to treat that undefined
condition as unreachable and optimize it away.

[Bug tree-optimization/108374] [12/13 Regression] unexpected -Wstringop-overflow when using std::atomic and std::shared_ptr

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

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

--- Comment #4 from Richard Biener  ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to Romain Geissler from comment #0)
> > std::weak_ptr weakPointer(pointer);
> > 
> > [[maybe_unused]] const unsigned int aAttr = weakPointer.lock()->_attr;
> 
> If pointer == nullptr then weakPointer.lock() is also null, and so
> dereferencing it to access the attr member is undefined, and does indeed
> perform an atomic load at address 0.
> 
> Instead of complaining about it, I would expect GCC to treat that undefined
> condition as unreachable and optimize it away.

Hmm, but then the program is bogus, no?  And a diagnostic warranted.

At least if it is well-defined to have a nullptr == pointer.

So I'd be inclined to close as INVALID?

[Bug tree-optimization/108374] [12/13 Regression] unexpected -Wstringop-overflow when using std::atomic and std::shared_ptr

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

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Richard Biener from comment #4)
> Hmm, but then the program is bogus, no?  And a diagnostic warranted.

No.

> At least if it is well-defined to have a nullptr == pointer.

It's well defined, but that doesn't mean the program is bogus. It just means
you can't call that function with such a value.

> So I'd be inclined to close as INVALID?

No, I don't think so. It would only be invalid if you called f(nullptr) or
similar.

The code is basically doing something like:

int f(const A* p, bool is_valid)
{
  const A* q = is_valid ? p : nullptr;
  return *q;
}

Instead of complaining that q might be null, we can optimize that to return *p.

It might be nicer to optimize it to:

  if (!p)
__builtin_trap();
  return *p;

but either way, we can't just declare the whole program to be invalid because
it's possible to call the function incorrectly.

[Bug middle-end/108376] TSVC s1279 runs 40% faster with aocc than gcc at zen4

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
As far as I can see a[] is all zeros.  AOCC basically preserves the
loop control flow when if (a[i] < 0.) for all elements processed in the
iteration, likewise for if (b[i] > a[i]) but GCC if-converts this all
down to combined masking of the guarded code.

I think the testcase as-is is too artificial to be relevant.  GCC
has code to do such thing to convert masked stores, but in this case
we are not using masked stores or masked loads:

.L3:
vmovaps a(%rax), %ymm3
vmovaps b(%rax), %ymm4
vmovaps c(%rax), %ymm7
addq$32, %rax
vmovaps c-32(%rax), %ymm0
vmovaps e-32(%rax), %ymm5
vcmpps  $1, %ymm1, %ymm3, %k1
vcmpps  $14, %ymm3, %ymm4, %k1{%k1}
vfmadd231ps d-32(%rax), %ymm5, %ymm0{%k1}
vfmadd231ps d-32(%rax), %ymm5, %ymm0
vblendmps   %ymm0, %ymm7, %ymm0{%k1}
vmovaps %ymm0, c-32(%rax)
cmpq$128000, %rax
jne .L3

I suspect if you do a less optimal initialization of a/b then the AOCC
code will be slower.

Note GCC applies unroll-and-jam to the loop (the outer iteration is
visibly redundant, so we are eventually doing half of the work as AOCC ;))

Confirmed for us not vectorizing control flow but if-converting.

[Bug fortran/107706] [13 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.cc:7572 since r13-3136-g50c35c691517291d

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Tobias Burnus :

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

commit r13-5118-g2ce55247a8bf32985a96ed63a7a92d36746723dc
Author: Tobias Burnus 
Date:   Thu Jan 12 11:43:37 2023 +0100

Fortran/OpenMP: Reject non-scalar 'holds' expr in 'omp assume(s)'
[PR107706]

gcc/fortran/ChangeLog:

PR fortran/107706
* openmp.cc (gfc_resolve_omp_assumptions): Reject nonscalars.

gcc/testsuite/ChangeLog:

PR fortran/107706
* gfortran.dg/gomp/assume-2.f90: Update dg-error.
* gfortran.dg/gomp/assumes-2.f90: Likewise.
* gfortran.dg/gomp/assume-5.f90: New test.

[Bug c++/108380] New: function execution order

[sameer.varyani at gmail dot com via Gcc-bugs]

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

Bug ID: 108380
   Summary: function execution order
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sameer.varyani at gmail dot com
  Target Milestone: ---

#include 
#include 
#include 
#include 

int values(){
std::cout << "calling values" << std::endl;
static int idx;
return idx++;
}
std::string keys(){
std::cout << "calling keys" << std::endl;
static std::vector str = {"A", "B", "C", "D", "E"};
static int a;
return str[(a++)%str.size()];
}
int main(int argc, char **argv){
std::map mm;
mm[keys()] = values();
}

g++ -std=c++17 test.cpp ; ./a.out
calling values
calling keys

g++ -std=c++14 test.cpp ; ./a.out
calling keys
calling values

clang is consistent across standards.
clang++ -std=c++17 test.cpp ; ./a.out
calling values
calling keys

Also not that the if the values return type is changes to std::string the order
in c++17 and c++14 stay consistent.

[Bug tree-optimization/108374] [12/13 Regression] unexpected -Wstringop-overflow when using std::atomic and std::shared_ptr

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
The warning is simply badly designed like most of the middle-end warnings.

As has been discussed, we should have some switch to decide what to do when we
have such provable UB, and the possibilities should be turn it into
__builtin_unreachable (), turn it into __builtin_trap () or for users who don't
mind seeing lots of false positives keep the warning.  Though perhaps now that
we have -funreachable-traps the option could be just 2 possibilities,
unreachable vs. (useless) warnings, with the default of the former.

[Bug middle-end/88345] -Os overrides -falign-functions=N on the command line

[mark at kernel dot org via Gcc-bugs]

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

Branko Drevensek  changed:

   What|Removed |Added

 CC||branko.drevensek at gmail dot 
com

Mark Rutland  changed:

   What|Removed |Added

 CC||mark at kernel dot org

--- Comment #8 from Branko Drevensek  ---
Size optimization turning function alignment off assumes function alignment is
an optimization only, while for some architectures it might be requirement for
certain functions, such as interrupt handlers on risc-v.
This makes it impossible to have those functions aligned using this
switch/attribute regardless of optimization level selected as -Os will cause
alignment setting to be ignored.

--- Comment #9 from Mark Rutland  ---
This appears to be one case of several where GCC drops the alignment specified
by `-falign-functions=N`. I'm commenting with the other cases here rather than
creating new tickets on the assumption that's preferable.

Dropping the alignment specified by `-falign-functions=N` is a functional issue
for the arm64 Linux kernel port affecting our 'ftrace' tracing mechanism. I see
this with GCC 12.1.0 (and have no tested other versions), and LLVM seems to
always respect the alignment specified by `-falign-functions=N`

The arm64 Linux kernel port needs to use `-falign-functions=8` along with
`-fpatchable-function-entry=N,2` to place a naturally-aligned 8-byte literal at
the start of functions. There's some detail of that at:

  https://lore.kernel.org/lkml/20230109135828.879136-1-mark.rutl...@arm.com/

As noted earlier in this ticket, GCC does not seem to respect
`-falign-functions=N` when using `-Os`. For my use-case we cvan work around the
issue by not passing `-Os`, and I have one patch to do so, but this is not
ideal:

  https://lore.kernel.org/lkml/20230109135828.879136-3-mark.rutl...@arm.com/


In addition, GCC seems to drop alignment for cold functions, whether those are
marked as cold explicitly or when determined by some interprocedural analysis.
I've noted this on LKML at:

  https://lore.kernel.org/lkml/Y77%2FqVgvaJidFpYt@FVFF77S0Q05N/

... the below summary is a copy-paste of that:

For example:

| [mark@lakrids:/mnt/data/tests/gcc-alignment]% cat test-cold.c 
| #define __cold \
| __attribute__((cold))
| 
| #define EXPORT_FUNC_PTR(func) \
| typeof((func)) *__ptr_##func = (func)
| 
| __cold
| void cold_func_a(void) { }
| 
| __cold
| void cold_func_b(void) { }
| 
| __cold
| void cold_func_c(void) { }
| 
| static __cold
| void static_cold_func_a(void) { }
| EXPORT_FUNC_PTR(static_cold_func_a);
| 
| static __cold
| void static_cold_func_b(void) { }
| EXPORT_FUNC_PTR(static_cold_func_b);
| 
| static __cold
| void static_cold_func_c(void) { }
| EXPORT_FUNC_PTR(static_cold_func_c);
| [mark@lakrids:/mnt/data/tests/gcc-alignment]% usekorg 12.1.0
aarch64-linux-gcc -falign-functions=16 -c test-cold.c -O1
| [mark@lakrids:/mnt/data/tests/gcc-alignment]% usekorg 12.1.0
aarch64-linux-objdump -d test-cold.o 
| 
| test-cold.o: file format elf64-littleaarch64
| 
| 
| Disassembly of section .text:
| 
|  :
|0:   d65f03c0ret
| 
| 0004 :
|4:   d65f03c0ret
| 
| 0008 :
|8:   d65f03c0ret
| 
| 000c :
|c:   d65f03c0ret
| 
| 0010 :
|   10:   d65f03c0ret
| 
| 0014 :
|   14:   d65f03c0ret
| [mark@lakrids:/mnt/data/tests/gcc-alignment]% usekorg 12.1.0
aarch64-linux-objdump -h test-cold.o
| 
| test-cold.o: file format elf64-littleaarch64
| 
| Sections:
| Idx Name  Size  VMA   LMA   File off 
Algn
|   0 .text 0018      0040 
2**2
|   CONTENTS, ALLOC, LOAD, READONLY, CODE
|   1 .data 0018      0058 
2**3
|   CONTENTS, ALLOC, LOAD, RELOC, DATA
|   2 .bss        0070 
2**0
|   ALLOC
|   3 .comment  0013      0070 
2**0
|   CONTENTS, READONLY
|   4 .note.GNU-stack       0083 
2**0
|   CONTENTS, READONLY
|   5 .eh_frame 0090      0088 
2**3
|   CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA

In simple cases, alignment *can* be restored if an explicit function attribute
is used. For example:

| [mark@lakrids:/mnt/data/tests/gcc-alignment]% cat test-aligned-cold.c 
| #define __aligned(n) \
| __attribute__((aligned(n)))
| 
| #define __cold \
|

[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

Aldy Hernandez  changed:

   What|Removed |Added

  Attachment #54224|0   |1
is obsolete||

--- Comment #26 from Aldy Hernandez  ---
Created attachment 54253
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54253&action=edit
proposed patch

So where are we on this?  Do we want to do something like this for this
release, or something else entirely?

This is a variation of the previous patch that instead of setting varying,
avoids the singleton by returning:

[INF, INF]   => [+MAX, +INF]
[-INF, -INF] => [-INF, -MIN]

[Bug c++/105593] avx512 math function raises uninitialized variable warning

[jay+ggcc--- via Gcc-bugs]

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

James Addison  changed:

   What|Removed |Added

 CC||jay+g...@jp-hosting.net

--- Comment #9 from James Addison  ---
A similar warning is raised when compiling avx512erintrin.h with optimization
and -Wuninitialized enabled:

/usr/lib/gcc/x86_64-linux-gnu/12/include/avx512erintrin.h:55:20: warning:
‘__W’ is used uninitialized [-Wuninitialized]

The relevant GCC code can be found at
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/avx512erintrin.h;h=6b3b679a17675612f45a1090f227012b80b871a6#l54

The compilation command-line used was: gcc -O -Wuninitialized -mavx512er
-mavx512pf

The code-under-compilation can be found at
https://github.com/numpy/numpy/blob/bb2769e12a8646f3d63097e9464592aa6e20058d/numpy/distutils/checks/cpu_avx512_knl.c

[Bug c++/108380] function execution order

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
N.B. GCC 9 is no longer maintained or supported.

Not a bug. In C++14 the order is unspecified, so GCC can choose the order. For
C++17 the order is specified by the standard, so GCC follows the standard.

Clang happens to choose a different order for C++14, but that's fine. Either
order is allowed for C++14.

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

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

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

--- Comment #27 from Jakub Jelinek  ---
"elide an overflow" should be probably "elide an overflow or division by zero"
I think,
because finite / 0.0 returns infinity and raises FE_DIVBYZERO rather than
FE_OVERFLOW,
even when it returns infinity from finite operands.
Seems for infinity / 0.0 no exception is raised, so the finite operands
infinite result condition seems to be sufficient.

For GCC 13, I think it is important that we e.g. don't miscompile glibc libm,
so
the libm testsuite should be clean.  PR107967 fixed some of the failures, and
some were claimed to be dups of this PR.  So, would be nice to test GCC with
your patch on glibc + libm testsuite.
Just
CC=/path/to/patched-gcc-trunk/gcc CXX=/path/to/patched-gcc-trunk/g++
../configure --prefix=/usr
CC=/path/to/patched-gcc-trunk/gcc CXX=/path/to/patched-gcc-trunk/g++ make -jN
CC=/path/to/patched-gcc-trunk/gcc CXX=/path/to/patched-gcc-trunk/g++ make -jN
check
should be enough in latest glibc (and perhaps compare that to GCC 12).

[Bug analyzer/108381] New: GCC Static Analyzer evaluates ( ((c)<=(b)) && ((c)!=(b)) ) == false to be FALSE with the fact c >= b

[geoffreydgr at icloud dot com via Gcc-bugs]

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

Bug ID: 108381
   Summary: GCC Static Analyzer evaluates ( ((c)<=(b)) &&
((c)!=(b)) ) == false to be FALSE with the fact c >= b
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: geoffreydgr at icloud dot com
  Target Milestone: ---

Hi, i found a problem that GCC Static Analyzer evaluates `( ((c)<=(b)) &&
((c)!=(b)) ) == false ` to be FALSE with the fact `c >= b`. However, CSA does
not have this problem.
GSA: https://godbolt.org/z/qjEvndsxT
CSA: https://godbolt.org/z/zMYheK7Pf

Compiler options: -O0 -fanalyzer

Input:
```c
#include "stdint.h"
#include 


int a(int* b, int *c) {

d:
  if (c >= b) {

__analyzer_eval((!(c >= b))==false);
__analyzer_evalc)<=(b))&&((c)!=(b)))==false);
__analyzer_eval(true);
goto d;
  }
}
```


Output:
```bash
: In function 'a':
:10:5: warning: implicit declaration of function '__analyzer_eval'
[-Wimplicit-function-declaration]
   10 | __analyzer_eval((!(c >= b))==false);
  | ^~~
:10:5: warning: TRUE
   10 | __analyzer_eval((!(c >= b))==false);
  | ^~~
:11:5: warning: FALSE
   11 | __analyzer_evalc)<=(b))&&((c)!=(b)))==false);
  | ^~~~
:12:5: warning: TRUE
   12 | __analyzer_eval(true);
  | ^
:11:5: warning: UNKNOWN
   11 | __analyzer_evalc)<=(b))&&((c)!=(b)))==false);
  | ^~~~
:12:5: warning: TRUE
   12 | __analyzer_eval(true);
  | ^
Compiler returned: 0

```

[Bug fortran/107706] [13 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.cc:7572 since r13-3136-g50c35c691517291d

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

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #3 from Tobias Burnus  ---
FIXED.  Thanks for the report!

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

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

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

--- Comment #28 from Xi Ruoyao  ---
(In reply to Jakub Jelinek from comment #27)

> For GCC 13, I think it is important that we e.g. don't miscompile glibc
> libm, so
> the libm testsuite should be clean.  PR107967 fixed some of the failures,
> and some were claimed to be dups of this PR.  So, would be nice to test GCC
> with your patch on glibc + libm testsuite.

Some bugs are hidden on x86/x86_64 because glibc uses more assembly for FP than
oother ports.  It's better to try on RISC-V etc.

> Just
> CC=/path/to/patched-gcc-trunk/gcc CXX=/path/to/patched-gcc-trunk/g++
> ../configure --prefix=/usr
> CC=/path/to/patched-gcc-trunk/gcc CXX=/path/to/patched-gcc-trunk/g++ make -jN
> CC=/path/to/patched-gcc-trunk/gcc CXX=/path/to/patched-gcc-trunk/g++ make
> -jN check
> should be enough in latest glibc (and perhaps compare that to GCC 12).

[Bug fortran/108382] New: Incorrect parsing when acc and omp coexist and -fopenmp -fopenacc is used.

[zbigniew.piotrowski at ecmwf dot int via Gcc-bugs]

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

Bug ID: 108382
   Summary: Incorrect parsing when acc and omp coexist and
-fopenmp -fopenacc is used.
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zbigniew.piotrowski at ecmwf dot int
  Target Milestone: ---

Created attachment 54254
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54254&action=edit
Source file with a minimal example raising an error.

Problem: parsing acc and omp directives seems to incorrectly interfere, when
line continuation is used. As a result, frontend is trying to interpret omp
directives as belonging to acc. 

1) GCC versions affected: 12.1.0 (also: Mac 12.2.0) (11.3.0 unaffected)
2) System type: both: x86_64-linux-gnu (also: aarch64-apple-darwin)
3) configure options: see below, official Ubuntu 22.04 package 
4) command line: gfortran-12  -c -fopenmp -fopenacc  yoethf.F90 (same with
gfortran-11 works fine)
5) compiler output:

yoethf.F90:76:7:

   76 | !$ompr5alvcp, r5alscp, ralvdcp, ralsdcp, ralfdcp,
rtwat, rtice, rticecu , &
  |   1
Error: Wrong OpenACC continuation at (1): expected !$ACC, got !$OMP
yoethf.F90:75:21:

   75 | !$omp declare target(r2es, r3les, r3ies, r4les, r4ies, r5les, r5ies , &
  | 1
Error: Syntax error in !$OMP DECLARE TARGET list at (1)
yoethf.F90:76:22:

   76 | !$ompr5alvcp, r5alscp, ralvdcp, ralsdcp, ralfdcp,
rtwat, rtice, rticecu , &
  |  1
Error: Unclassifiable OpenMP directive at (1)
yoethf.F90:77:7:

   77 | !$omprtwat_rtice_r, rtwat_rticecu_r, rkoop1, rkoop2)
  |   1
Error: Wrong OpenACC continuation at (1): expected !$ACC, got !$OMP
yoethf.F90:77:22:

   77 | !$omprtwat_rtice_r, rtwat_rticecu_r, rkoop1, rkoop2)
  |  1
Error: Unclassifiable OpenMP directive at (1)

6) Workaround: replace lines:

!$acc declare copyin(r2es, r3les, r3ies, r4les, r4ies, r5les, r5ies, &
!$acc   r5alvcp, r5alscp, ralvdcp, ralsdcp, ralfdcp, rtwat, rtice, rticecu, &
!$acc   rtwat_rtice_r, rtwat_rticecu_r, rkoop1, rkoop2)

!$omp declare target(r2es, r3les, r3ies, r4les, r4ies, r5les, r5ies , &
!$ompr5alvcp, r5alscp, ralvdcp, ralsdcp, ralfdcp, rtwat, rtice,
rticecu , &
!$omprtwat_rtice_r, rtwat_rticecu_r, rkoop1, rkoop2)

with:

!$acc declare copyin(r2es, r3les, r3ies, r4les, r4ies, r5les, r5ies, &
!$acc   r5alvcp, r5alscp, ralvdcp, ralsdcp, ralfdcp, rtwat, rtice, rticecu, &
!$acc   rtwat_rtice_r, rtwat_rticecu_r, rkoop1, rkoop2)

!$omp declare target(r2es, r3les, r3ies, r4les, r4ies, r5les, r5ies)
!$omp declare target(r5alvcp, r5alscp, ralvdcp, ralsdcp, ralfdcp, rtwat, rtice,
rticecu)
!$omp declare target(rtwat_rtice_r, rtwat_rticecu_r, rkoop1, rkoop2)




gfortran-12 -v
Using built-in specs.
COLLECT_GCC=gfortran-12
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
12.1.0-2ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-12
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-12-sZcx2y/gcc-12-12.1.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-sZcx2y/gcc-12-12.1.0/debian/tmp-gcn/usr
--enable-offload-defaulted --without-cuda-driver --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.1.0 (Ubuntu 12.1.0-2ubuntu1~22.04)

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|REOPENED|ASSIGNED
   Target Milestone|--- |13.0
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

--- Comment #27 from Jonathan Wakely  ---
Gah, this doesn't work (and not only because it should be  not
).

We include os_defines.h before the line create by configure:
#include 
...
#define _GLIBCXX_HAS_GTHREADS 1

I have a fix, but it will have to wait for higher priority things to be done
first.

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

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

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

--- Comment #28 from Jonathan Wakely  ---
(In reply to cqwrteur from comment #2)
> Please stop! Windows 95 support is extremely important

Looks like you can't even include  if you set _WIN32_WINNT < 0x0600 so
this has NEVER worked, and I don't see why we should waste our time supporting
it.

[Bug tree-optimization/99412] s352 benchmark of TSVC is vectorized by clang and not by gcc

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

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

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

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

commit r13-5122-gb073f2b098ba7819450d6c14a0fb96cb1c09f242
Author: Richard Biener 
Date:   Thu Jan 12 11:18:22 2023 +0100

tree-optimization/99412 - reassoc and reduction chains

With -ffast-math we end up associating reduction chains and break
them - this is because of old code that tries to rectify reductions
into a shape likened by the vectorizer.  Nowadays the rank compute
produces correct association for reduction chains and the vectorizer
has robust support to fall back to a regular reductions (via
reduction path) when it turns out to be not a proper reduction chain.

So this patch removes the special code in reassoc which makes
the TSVC s352 vectorized with -Ofast (it is already without
-ffast-math).

PR tree-optimization/99412
* tree-ssa-reassoc.cc (is_phi_for_stmt): Remove.
(swap_ops_for_binary_stmt): Remove reduction handling.
(rewrite_expr_tree_parallel): Adjust.
(reassociate_bb): Likewise.
* tree-parloops.cc (build_new_reduction): Handle MINUS_EXPR.

* gcc.dg/vect/pr99412.c: New testcase.
* gcc.dg/tree-ssa/reassoc-47.c: Adjust comment.
* gcc.dg/tree-ssa/reassoc-48.c: Remove.

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

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

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

Bug 99412 Summary: s352 benchmark of TSVC is vectorized by clang and not by gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99412

   What|Removed |Added

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

[Bug tree-optimization/99412] s352 benchmark of TSVC is vectorized by clang and not by gcc

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
GCC now does

.L2:
vmovaps b(%rax), %xmm6
vmulps  a(%rax), %xmm6, %xmm0
addq$80, %rax
vmovaps b-64(%rax), %xmm7
vmovaps b-48(%rax), %xmm6
vaddps  %xmm0, %xmm5, %xmm5
vmulps  a-64(%rax), %xmm7, %xmm0
vmovaps b-32(%rax), %xmm7
vaddps  %xmm0, %xmm1, %xmm1
vmulps  a-48(%rax), %xmm6, %xmm0
vmovaps b-16(%rax), %xmm6
vaddps  %xmm0, %xmm4, %xmm4
vmulps  a-32(%rax), %xmm7, %xmm0
vaddps  %xmm0, %xmm2, %xmm2
vmulps  a-16(%rax), %xmm6, %xmm0
vaddps  %xmm0, %xmm3, %xmm3
cmpq$128000, %rax
jne .L2

thus uses a VF of 4 with -Ofast.  Your LLVM snippet uses 5 lanes
instead of our 20 with four lanes in a V4SF and one lane in a scalar.
That's interesting but not something we support.

Re-rolling would mean using a single v4sf 4 lane vector here.  For
a pure SLP loop something like this should be possible without too
much hassle I think.  We'd just need to try ... (and think of if it's
worth in real life)

For the purpose of the Summary this is fixed now.

[Bug tree-optimization/99412] s352 benchmark of TSVC is vectorized by clang and not by gcc

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug target/105549] aarch64: Wrong va_arg alignment handling with packed bitfields and alignment

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Christophe Lyon :

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

commit r13-5123-g3df1a115be22caeab3ffe7afb12e71adb54ff132
Author: Christophe Lyon 
Date:   Tue Jun 14 21:08:33 2022 +

aarch64: fix warning emission for ABI break since GCC 9.1

While looking at PR 105549, which is about fixing the ABI break
introduced in GCC 9.1 in parameter alignment with bit-fields, we
noticed that the GCC 9.1 warning is not emitted in all the cases where
it should be.  This patch fixes that and the next patch in the series
fixes the GCC 9.1 break.

We split this into two patches since patch #2 introduces a new ABI
break starting with GCC 13.1.  This way, patch #1 can be back-ported
to release branches if needed to fix the GCC 9.1 warning issue.

The main idea is to add a new global boolean that indicates whether
we're expanding the start of a function, so that aarch64_layout_arg
can emit warnings for callees as well as callers.  This removes the
need for aarch64_function_arg_boundary to warn (with its incomplete
information).  However, in the first patch there are still cases where
we emit warnings were we should not; this is fixed in patch #2 where
we can distinguish between GCC 9.1 and GCC.13.1 ABI breaks properly.

The fix in aarch64_function_arg_boundary (replacing & with &&) looks
like an oversight of a previous commit in this area which changed
'abi_break' from a boolean to an integer.

We also take the opportunity to fix the comment above
aarch64_function_arg_alignment since the value of the abi_break
parameter was changed in a previous commit, no longer matching the
description.

2022-11-28  Christophe Lyon  
Richard Sandiford  

gcc/ChangeLog:

* config/aarch64/aarch64.cc (aarch64_function_arg_alignment): Fix
comment.
(aarch64_layout_arg): Factorize warning conditions.
(aarch64_function_arg_boundary): Fix typo.
* function.cc (currently_expanding_function_start): New variable.
(expand_function_start): Handle
currently_expanding_function_start.
* function.h (currently_expanding_function_start): Declare.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/bitfield-abi-warning-align16-O2.c: New test.
* gcc.target/aarch64/bitfield-abi-warning-align16-O2-extra.c: New
test.
* gcc.target/aarch64/bitfield-abi-warning-align32-O2.c: New test.
* gcc.target/aarch64/bitfield-abi-warning-align32-O2-extra.c: New
test.
* gcc.target/aarch64/bitfield-abi-warning-align8-O2.c: New test.
* gcc.target/aarch64/bitfield-abi-warning.h: New test.
* g++.target/aarch64/bitfield-abi-warning-align16-O2.C: New test.
* g++.target/aarch64/bitfield-abi-warning-align16-O2-extra.C: New
test.
* g++.target/aarch64/bitfield-abi-warning-align32-O2.C: New test.
* g++.target/aarch64/bitfield-abi-warning-align32-O2-extra.C: New
test.
* g++.target/aarch64/bitfield-abi-warning-align8-O2.C: New test.
* g++.target/aarch64/bitfield-abi-warning.h: New test.

[Bug target/105549] aarch64: Wrong va_arg alignment handling with packed bitfields and alignment

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Christophe Lyon :

https://gcc.gnu.org/g:6610daa1cfb75b72500c22ae97988ec2a48b85c6

commit r13-5124-g6610daa1cfb75b72500c22ae97988ec2a48b85c6
Author: Christophe Lyon 
Date:   Fri Nov 25 13:35:11 2022 +

aarch64: Fix bit-field alignment in param passing [PR105549]

While working on enabling DFP for AArch64, I noticed new failures in
gcc.dg/compat/struct-layout-1.exp (t028) which were not actually
caused by DFP types handling. These tests are generated during 'make
check' and enabling DFP made generation different (not sure if new
non-DFP tests are generated, or if existing ones are generated
differently, the tests in question are huge and difficult to compare).

Anyway, I reduced the problem to what I attach at the end of the new
gcc.target/aarch64/aapcs64/va_arg-17.c test and rewrote it in the same
scheme as other va_arg* AArch64 tests.  Richard Sandiford further
reduced this to a non-vararg function, added as a second testcase.

This is a tough case mixing bit-fields and alignment, where
aarch64_function_arg_alignment did not follow what its descriptive
comment says: we want to use the natural alignment of the bit-field
type only if the user didn't reduce the alignment for the bit-field
itself.

The patch also adds a comment and assert that would help someone who
has to look at this area again.

The fix would be very small, except that this introduces a new ABI
break, and we have to warn about that.  Since this actually fixes a
problem introduced in GCC 9.1, we keep the old computation to detect
when we now behave differently.

This patch adds two new tests (va_arg-17.c and
pr105549.c). va_arg-17.c contains the reduced offending testcase from
struct-layout-1.exp for reference.  We update some tests introduced by
the previous patch, where parameters with bit-fields and packed
attribute now emit a different warning.

2022-11-28  Christophe Lyon  
Richard Sandiford  

gcc/
PR target/105549
* config/aarch64/aarch64.cc (aarch64_function_arg_alignment):
Check DECL_PACKED for bitfield.
(aarch64_layout_arg): Warn when parameter passing ABI changes.
(aarch64_function_arg_boundary): Do not warn here.
(aarch64_gimplify_va_arg_expr): Warn when parameter passing ABI
changes.

gcc/testsuite/
PR target/105549
* gcc.target/aarch64/bitfield-abi-warning-align16-O2.c: Update.
* gcc.target/aarch64/bitfield-abi-warning-align16-O2-extra.c:
Update.
* gcc.target/aarch64/bitfield-abi-warning-align32-O2.c: Update.
* gcc.target/aarch64/bitfield-abi-warning-align32-O2-extra.c:
Update.
* gcc.target/aarch64/aapcs64/va_arg-17.c: New test.
* gcc.target/aarch64/pr105549.c: New test.
* g++.target/aarch64/bitfield-abi-warning-align16-O2.C: Update.
* g++.target/aarch64/bitfield-abi-warning-align16-O2-extra.C:
Update.
* g++.target/aarch64/bitfield-abi-warning-align32-O2.C: Update.
* g++.target/aarch64/bitfield-abi-warning-align32-O2-extra.C:
Update.

[Bug target/55522] -funsafe-math-optimizations is unexpectedly harmful, especially w/ -shared

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

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

Richard Biener  changed:

   What|Removed |Added

 Target|x86_64-*-*, i?86-*-*,   |x86_64-*-*, i?86-*-*,
   |aarch64, alpha, arm, ia64,  |aarch64, alpha, arm, ia64,
   |loongarch, mips, sparc  |loongarch, mips, sparc,
   ||*-solaris2*

--- Comment #32 from Richard Biener  ---
Do other targets want to follow suite for GCC 13 here?

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |WONTFIX

--- Comment #29 from Jonathan Wakely  ---
I think if you want to build for ancient versions < 0x0600 then you should
build a custom toolchain for that. Build the whole compiler with
--enable-cxx-flags="-O2 -g -D_WIN32_WINNT=0x0500" and that way libstdc++'s
configure will correctly detect at build time that you are from prehistoric
times. It will correctly disable uses of C99 stdlib.h and C++11 mutexes and
threads etc.

Building a compiler for modern Windows versions and expecting it to also
compile for ancient versions is not going to work. Treat the ancient versions
as a cross-compilation target and use a custom toolchain instead.

So I'm closing this again.

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

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

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

--- Comment #30 from Jonathan Wakely  ---
Created attachment 54255
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54255&action=edit
Disable C++11 mutex etc. when not supported by win32 threads

This patch would solve the problem for  and , but would not do
anything about the fact that this would still fail:

#define _WIN32_WINNT 0x0502
#include 

If you can't even include  then the library is unusable, so we're not
going to attempt to support that.

As I said in the last comment, it will work if libstdc++ is configured with the
ancient value of _WIN32_WINNT, but selecting those ancient versions after
installation by defining it in your own code won't work. I'll document this in
the manual.

[Bug target/105549] aarch64: Wrong va_arg alignment handling with packed bitfields and alignment

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

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

--- Comment #5 from Christophe Lyon  ---
Fixed on trunk

[Bug c++/108383] New: g++ ICE with -O3 and -flto on simple function

[eebssk1 at godaftwithebk dot pub via Gcc-bugs]

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

Bug ID: 108383
   Summary: g++ ICE with -O3 and -flto on simple function
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eebssk1 at godaftwithebk dot pub
  Target Milestone: ---

Getting ICE with O3&flto when compiling a project.
Using mingw32 cross compiler on linux.
project url: https://github.com/doitsujin/dxvk

x86_64-w64-mingw32-g++  -o src/dxgi/dxgi.dll src/dxgi/dxgi.dll.p/version.o
src/dxgi/dxgi.dll.p/dxgi_adapter.cpp.obj src/dxgi/dxgi.dll.p/dxgi_enums.cpp.obj
src/dxgi/dxgi.dll.p/dxgi_factory.cpp.obj
src/dxgi/dxgi.dll.p/dxgi_format.cpp.obj src/dxgi/dxgi.dll.p/dxgi_main.cpp.obj
src/dxgi/dxgi.dll.p/dxgi_monitor.cpp.obj
src/dxgi/dxgi.dll.p/dxgi_options.cpp.obj
src/dxgi/dxgi.dll.p/dxgi_output.cpp.obj
src/dxgi/dxgi.dll.p/dxgi_surface.cpp.obj
src/dxgi/dxgi.dll.p/dxgi_swapchain.cpp.obj -Wl,--allow-shlib-undefined -Wl,-O1
-shared ../src/dxgi/dxgi.def -Wl,--start-group
-Wl,--out-implib=src/dxgi/dxgi.dll.a -static -static-libgcc -static-libstdc++
-Wl,--file-alignment=4096 src/dxvk/libdxvk.a src/util/libutil.a
src/spirv/libspirv.a src/wsi/libwsi.a
subprojects/libdisplay-info/libdisplay-info.a src/vulkan/libvkcommon.a -pthread
-lm -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid
-lcomdlg32 -ladvapi32 -Wl,--end-group
lto-wrapper: warning: using serial compilation of 21 LTRANS jobs
lto-wrapper: note: see the ‘-flto’ option documentation for more information
during GIMPLE pass: alias
../src/dxgi/dxgi_adapter.cpp: In member function
‘RegisterVideoMemoryBudgetChangeNotificationEvent’:
../src/dxgi/dxgi_adapter.cpp:402:61: internal compiler error: in
binds_to_current_def_p, at symtab.cc:2494
  402 |   HRESULT STDMETHODCALLTYPE 
DxgiAdapter::RegisterVideoMemoryBudgetChangeNotificationEvent(
  | ^
0x62d5fd symtab_node::binds_to_current_def_p(symtab_node*)
../../gcc/symtab.cc:2494
0x84ddd7 gimple_call_arg_flags(gcall const*, unsigned int)
../../gcc/gimple.cc:1583
0xce9a84 handle_rhs_call
../../gcc/tree-ssa-structalias.cc:4335
0xcebe1a find_func_aliases_for_call
../../gcc/tree-ssa-structalias.cc:5010
0xcebe1a find_func_aliases
../../gcc/tree-ssa-structalias.cc:5113
0xcee3c6 compute_points_to_sets
../../gcc/tree-ssa-structalias.cc:7536
0xcee3c6 compute_may_aliases()
../../gcc/tree-ssa-structalias.cc:8044
0xa4ff5c execute_function_todo
../../gcc/passes.cc:2057
0xa50c9c do_per_function
../../gcc/passes.cc:1688
0xa50c9c execute_todo
../../gcc/passes.cc:2139
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.
lto-wrapper: fatal error: x86_64-w64-mingw32-g++ returned 1 exit status
compilation terminated.

and then

../src/dxgi/dxgi_adapter.cpp: In member function
‘RegisterVideoMemoryBudgetChangeNotificationEvent’:
../src/dxgi/dxgi_adapter.cpp:402:71: internal compiler error: in
binds_to_current_def_p, at symtab.cc:2494
  402 |   HRESULT STDMETHODCALLTYPE __attribute__((optimize("no-tree-pta"))) 
DxgiAdapter::RegisterVideoMemoryBudgetChangeNotificationEvent(
  |   ^
0x62d5fd symtab_node::binds_to_current_def_p(symtab_node*)
../../gcc/symtab.cc:2494
0x912baf merge_call_side_effects
../../gcc/ipa-modref.cc:1310
0x913671 analyze_call
../../gcc/ipa-modref.cc:1678
0x913671 analyze_stmt
../../gcc/ipa-modref.cc:1811
0x91a19a analyze
../../gcc/ipa-modref.cc:1900
0x91a19a analyze_function
../../gcc/ipa-modref.cc:3219
0x91c5da execute
../../gcc/ipa-modref.cc:4186

and then

with __attribute__((optimize("no-tree-pta","no-ipa-modref")))
the code unit compiled without ICE.

The optimizations are in O1, however if i simply use
__attribute__((optimize(2))),then the code unit does compile too, which is
really weired.

There's similar(may be same?) issues in here:
https://github.com/msys2/MINGW-packages/issues/11726 , ICE in same gcc code
location (symtab.cc:2494), with different flags though.

[Bug c++/105593] avx512 math function raises uninitialized variable warning

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

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

--- Comment #10 from Jakub Jelinek  ---
Seems the difference between C and C++ is documented:
'-Winit-self (C, C++, Objective-C and Objective-C++ only)'
 Warn about uninitialized variables that are initialized with
 themselves.  Note this option can only be used with the
 '-Wuninitialized' option.

 For example, GCC warns about 'i' being uninitialized in the
 following snippet only when '-Winit-self' has been specified:
  int f()
  {
int i = i;
return i;
  }

 This warning is enabled by '-Wall' in C++.

We do emit the warning even in C with -W -Wall -Winit-self, and don't emit
it with -W -Wall -Wno-init-self in C++.

[Bug c++/105593] avx512 math function raises uninitialized variable warning

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #11 from Jakub Jelinek  ---
This changed with PR53210.  See e.g.
https://gcc.gnu.org/legacy-ml/gcc-patches/2012-09/msg00898.html
Though, not sure how else we could avoid the warning.
void bar (int);

static inline int
baz (void)
{
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wuninitialized"
#pragma GCC diagnostic ignored "-Winit-self"
  int u = u;
  return u;
#pragma GCC diagnostic pop
}

void
foo (void)
{
  int u = baz ();
  bar (u);
}

certainly doesn't work, what works is to make the -Wuninitialized diagnostic
ignored at the use side, but that is incompatible with how _mm*_undefined*
intrinsics are meant to be used.
Note, the above (in particular the first diagnostic ignored alone) pragma helps
to shut the warning up in clang.  Though, for the intrinsic headers we care
just about gcc.

[Bug c/108384] New: error: conversion of register to a different size in ‘view_convert_expr’

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 108384
   Summary: error: conversion of register to a different size in
‘view_convert_expr’
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

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

The attached C code does this:

$ ~/gcc/results/bin/gcc -c -w -O3 -ftrivial-auto-var-init=zero bug873.c
testFile.4557.c: In function ‘func_1.isra’:
testFile.4557.c:130:16: error: conversion of register to a different size in
‘view_convert_expr’
VIEW_CONVERT_EXPR(removed_ipa_cp.834_390);

_393 = VIEW_CONVERT_EXPR(removed_ipa_cp.834_390);
during GIMPLE pass: fixup_cfg
testFile.4557.c:130:16: internal compiler error: verify_gimple failed
0xeaab49 verify_gimple_in_cfg(function*, bool, bool)
../../trunk.d1/gcc/tree-cfg.cc:5647
0xd46c5b execute_function_todo(function*, void*)
../../trunk.d1/gcc/passes.cc:2091

The bug first seems to occur sometime between git hash g:d901bf8a44a85e12
and g:b399afd22c6ea507.

A reduction is running now.

[Bug c/108384] error: conversion of register to a different size in ‘view_convert_expr’

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
Reduced C code seems to be:

struct S0 {
  int f0;
  short f1;
  unsigned f2 : 7;
  short f3
};
g_389;
static *func_23();
func_2() {
  struct S0 l_26[] = {4, 5, 4, 6, 4, 5, 4, 6};
  func_23(l_26[1]);
}
*func_23(struct S0 p_24, struct S0 p_25) {
  int *l_1051 = g_389;
  if (safe_sub_func_int16_t_s_s())
safe_lshift_func_uint8_t_u_s(p_24.f1);
  *l_1051 = p_25.f0;
}

[Bug analyzer/108252] false positive: leak detection

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

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

--- Comment #6 from David Malcolm  ---
(In reply to Илья Шипицин from comment #5)
> thank you, David!
> 
> I'll rerun haproxy check soon

Note that I haven't yet fixed bug 108251, so I don't know how useful the
results will be to you :/

FWIW I've added a build of haproxy-2.7.1 with -fanalyzer to my integration
tests of -fanalyzer:
  https://github.com/davidmalcolm/gcc-analyzer-integration-tests
to try to track the output.

Prior to the above patch I got this from gcc trunk with haproxy-2.7.1:

warning: 185
 - -Wanalyzer-null-dereference dereference of NULL ‘0’: 17
 - -Wanalyzer-null-dereference dereference of NULL ‘conn’: 14
 - -Wanalyzer-malloc-leak leak of ‘b’: 11
 - -Wanalyzer-malloc-leak leak of ‘’: 10
 - -Wanalyzer-malloc-leak leak of ‘strdup(args[1])’: 8
 - -Wanalyzer-use-of-uninitialized-value use of uninitialized value
‘sl.rq.m.ptr’: 7
 - -Wanalyzer-use-of-uninitialized-value use of uninitialized value
‘sl.rq.u.ptr’: 7
 - -Wanalyzer-malloc-leak leak of ‘strdup(tmp)’: 5
 - -Wanalyzer-fd-leak leak of file descriptor ‘*rx.fd’: 4
 - -Wanalyzer-null-dereference dereference of NULL ‘fstrm’: 4
 - -Wanalyzer-use-of-uninitialized-value use of uninitialized value
‘sl.rq.v.ptr’: 4
 - -Wanalyzer-out-of-bounds heap-based buffer under-read: 3
 - -Wanalyzer-malloc-leak leak of ‘u’: 3
 - -Wanalyzer-use-of-uninitialized-value use of uninitialized value
‘sl.rq.u.len’: 3
 - -Wanalyzer-null-dereference dereference of NULL ‘s’: 3
 - -Wanalyzer-malloc-leak leak of ‘strdup(&buf)’: 2
 - -Wanalyzer-null-dereference dereference of NULL ‘ret’: 2
 - -Wanalyzer-malloc-leak leak of ‘chk.area’: 2
 - -Wanalyzer-fd-leak leak of file descriptor ‘socket(1, 1, 0)’: 2
 - -Wanalyzer-use-of-uninitialized-value use of uninitialized value
‘ring.buf.data’: 2
 - -Wanalyzer-deref-before-check check of ‘meth’ for NULL after already
dereferencing it: 2
 - -Wanalyzer-deref-before-check check of ‘uri’ for NULL after already
dereferencing it: 2
 - -Wanalyzer-deref-before-check check of ‘vsn’ for NULL after already
dereferencing it: 2
 - -Wanalyzer-allocation-size allocated buffer size is not a multiple of the
pointee's size: 2
 - -Wanalyzer-deref-before-check check of ‘etag_buffer’ for NULL after already
dereferencing it: 2
 - -Wanalyzer-use-of-uninitialized-value use of uninitialized value ‘*(unsigned
int *)memPtr’: 2
 - -Wanalyzer-deref-before-check check of ‘result’ for NULL after already
dereferencing it: 2
 - -Wanalyzer-possible-null-dereference dereference of possibly-NULL ‘p’: 2
 - -Wanalyzer-null-argument use of NULL ‘params’ where non-null expected: 2
 - -Wanalyzer-null-dereference dereference of NULL ‘uri’: 2
 - -Wanalyzer-deref-before-check check of ‘dash’ for NULL after already
dereferencing it: 2
 - -Wanalyzer-fd-leak leak of file descriptor: 1
 - -Wanalyzer-malloc-leak leak of ‘calloc((long unsigned int)(hdr_num + 1),
32)’: 1
 - -Wanalyzer-malloc-leak leak of ‘node’: 1
 - -Wanalyzer-malloc-leak leak of ‘malloc((long unsigned int)(len + 1))’: 1
 - -Wanalyzer-use-of-uninitialized-value use of uninitialized value ‘data’: 1
 - -Wanalyzer-malloc-leak leak of ‘newkey’: 1
 - -Wanalyzer-possible-null-dereference dereference of possibly-NULL ‘p1’: 1
 - -Wanalyzer-malloc-leak leak of ‘conf_err’: 1
 - -Wanalyzer-malloc-leak leak of ‘new_conf_err’: 1
 - -Wanalyzer-malloc-leak leak of ‘strdup(*args_21(D) + _3)’: 1
 - -Wanalyzer-use-of-uninitialized-value use of uninitialized value ‘*(struct
lru64 *)_117 = PHI <_8(16), troot_4(13), ret_106(24)>.revision’: 1
 - -Wanalyzer-use-of-uninitialized-value use of uninitialized value ‘*(struct
lru64 *)_117 = PHI <_8(16), troot_4(13), ret_106(24)>.lru.n’: 1
 - -Wanalyzer-use-of-uninitialized-value use of uninitialized value ‘*(struct
lru64 *)_117 = PHI <_8(16), troot_4(13), ret_106(24)>.lru.p’: 1
 - -Wanalyzer-malloc-leak leak of ‘*lru.spare’: 1
 - -Wanalyzer-malloc-leak leak of ‘strdup(*args_18(D) + _4)’: 1
 - -Wanalyzer-possible-null-dereference dereference of possibly-NULL ‘dst’: 1
 - -Wanalyzer-use-after-free use after ‘free’ of ‘link’: 1
 - -Wanalyzer-malloc-leak leak of ‘strdup(backing)’: 1
 - -Wanalyzer-possible-null-dereference dereference of possibly-NULL ‘comp’: 1
 - -Wanalyzer-malloc-leak leak of ‘fconf’: 1
 - -Wanalyzer-malloc-leak leak of ‘strdup("/haproxy?stats")’: 1
 - -Wanalyzer-malloc-leak leak of ‘strdup(".internal-stats-userlist")’: 1
 - -Wanalyzer-malloc-leak leak of ‘calloc(1, 72)’: 1
 - -Wanalyzer-malloc-leak leak of ‘strdup(*args_153(D) + _49)’: 1
 - -Wanalyzer-deref-before-check check of ‘ext_child’ for NULL after already
dereferencing it: 1
 - -Wanalyzer-use-of-uninitialized-value use of uninitialized value
‘sl.rq.m.len’: 1
 - -Wanalyzer-use-of-uninitialized-value use of uninitialized value
‘sl.rq.v.len’: 1
 - -Wanalyzer-malloc-leak leak of ‘vph’: 1
 - -Wanalyzer-null-argument use of NULL where non-null expected: 1
 - -Wanalyzer-null-dereference dereference of NULL ‘value’: 1
 - -Wanalyzer-malloc-leak leak of ‘wl’: 1
 - -Wanalyze

[Bug c/108310] Some warnings that -Wtraditional-conversion causes to be emitted aren't actually controlled by it

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

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

--- Comment #3 from Eric Gallager  ---
(In reply to Eric Gallager from comment #0)
> So, I'm having trouble crafting a testcase that properly reproduces this
> issue, but...

...for reference, this is what I've got so far:

$ cat Wtraditional_conversion_darwin.c
#include 
#include 
#include 

uint32_t foo(float x)
{
return OSSwapHostToLittleInt32(x);
}

int32_t bar(double x)
{
return OSSwapHostToBigInt32(x);
}
$

Unfortunately, the only warning that it produces so far *is* actually
controlled by -Wtraditional-conversion properly, so it's not an example of this
bug (yet):

$ /usr/local/bin/gcc -c -Wall -Wextra -pedantic -Wtraditional-conversion
Wtraditional_conversion_darwin.c
In file included from
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/libkern/OSByteOrder.h:33,
 from
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/architecture/byte_order.h:38,
 from Wtraditional_conversion_darwin.c:1:
Wtraditional_conversion_darwin.c: In function 'bar':
Wtraditional_conversion_darwin.c:12:37: warning: passing argument 1 of
'_OSSwapInt32' as integer rather than floating due to prototype
[-Wtraditional-conversion]
   12 | return OSSwapHostToBigInt32(x);
  | ^
$

ref:
https://github.com/cooljeanius/gcc_bugs/blob/master/Wtraditional_conversion_darwin.c

[Bug c++/108383] g++ ICE with -O3 and -flto on simple function

[eebssk1 at godaftwithebk dot pub via Gcc-bugs]

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

--- Comment #1 from eebssk1 at godaftwithebk dot pub ---
It looks like my issue is caused by a extra inconspicuous flag
"-fdeclone-ctor-dtor". The program compiled succefully without it.

I do use this flag on other projects,never have such problem before.

[Bug c++/105593] avx512 math function raises uninitialized variable warning

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #12 from Jakub Jelinek  ---
Created attachment 54257
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54257&action=edit
gcc13-pr105593.patch

What we could do is test if -Winit-self is enabled at the point we decide if
we should suppress it.

[Bug c/108310] Some warnings that -Wtraditional-conversion causes to be emitted aren't actually controlled by it

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

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

--- Comment #4 from Jonathan Wakely  ---
void f(float);

void g()
{
  f(1.0);
}

conv.c: In function ‘g’:
conv.c:5:5: warning: passing argument 1 of ‘f’ as ‘float’ rather than ‘double’
due to prototype
5 |   f(1.0);
  | ^~~

[Bug c++/108385] New: false positive -Wfree-nonheap-object

[steveire at gmail dot com via Gcc-bugs]

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

Bug ID: 108385
   Summary: false positive -Wfree-nonheap-object
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: steveire at gmail dot com
  Target Milestone: ---

Sorry I was not able to reduce this further. Changing almost anything makes the
bug no-longer reproduce:


```

#include 
#include 
#include 

class DataType {
 public:
  DataType() {
   }

  DataType get() const;

 private:
  double v = 0.0;
  char values[41];
};

class ptrType {
 public:
  DataType someMethod() const {
DataType t;
t = t.get();
return t;
  }
};

class AnotherDataType {
 public:
  typedef uint32_t size_type;

  AnotherDataType() : _size(0), _data(new double[0]) {}

  explicit AnotherDataType(size_type size) : _size(size), _data(new
double[size]) {}

  virtual ~AnotherDataType() { delete[] _data; }

  uint32_t size() const { return _size; }

  double& operator()(size_type i) { return _data[i]; }

  AnotherDataType get(const AnotherDataType& b) const
  {
AnotherDataType c(size());

auto aItr = _data;
auto cItr = c.begin();
auto endp = _data + _size;

for (; aItr != endp; ++aItr, ++cItr) {
  (*cItr) = (*aItr);
}
return c;
  }

  double sum() const {
double sum = *_data;
auto aItr = _data;
for (; aItr != _data + _size; ++aItr) {
  sum = (*aItr);
}
return sum;
  }

  double* begin() { return _data; }

 private:
  size_type _size;
  double* _data;
};

AnotherDataType anotherMethod(const ptrType* ptrType1) {
  ptrType1->someMethod();
  return {};
}

struct otherStruct {
  const ptrType* ptrType1;
  std::vector q1;
};

static double minF(otherStruct* params) {
  auto err = anotherMethod(params->ptrType1);

  return (err.get(err)).sum();
}

struct someStruct {
  double (*f)(otherStruct* params);
  otherStruct* params;
};

void foo(someStruct function) {
  std::vector v;

  minF(function.params);
}

void why() {
  someStruct func;
  func.f = &minF;
  foo(func);
}
```

Godbolt link: https://godbolt.org/z/nqvsezj49

[Bug analyzer/108252] false positive: leak detection

[chipitsine at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Илья Шипицин  ---
(In reply to David Malcolm from comment #6)
> (In reply to Илья Шипицин from comment #5)
> > thank you, David!
> > 
> > I'll rerun haproxy check soon
> 
> Note that I haven't yet fixed bug 108251, so I don't know how useful the
> results will be to you :/
> 
> FWIW I've added a build of haproxy-2.7.1 with -fanalyzer to my integration
> tests of -fanalyzer:
>   https://github.com/davidmalcolm/gcc-analyzer-integration-tests
> to try to track the output.
> 
> Prior to the above patch I got this from gcc trunk with haproxy-2.7.1:
> 
> warning: 185
>  - -Wanalyzer-null-dereference dereference of NULL ‘0’: 17
>  - -Wanalyzer-null-dereference dereference of NULL ‘conn’: 14
>  - -Wanalyzer-malloc-leak leak of ‘b’: 11
>  - -Wanalyzer-malloc-leak leak of ‘’: 10
>  - -Wanalyzer-malloc-leak leak of ‘strdup(args[1])’: 8
>  - -Wanalyzer-use-of-uninitialized-value use of uninitialized value
> ‘sl.rq.m.ptr’: 7
>  - -Wanalyzer-use-of-uninitialized-value use of uninitialized value
> ‘sl.rq.u.ptr’: 7
>  - -Wanalyzer-malloc-leak leak of ‘strdup(tmp)’: 5
>  - -Wanalyzer-fd-leak leak of file descriptor ‘*rx.fd’: 4
>  - -Wanalyzer-null-dereference dereference of NULL ‘fstrm’: 4
>  - -Wanalyzer-use-of-uninitialized-value use of uninitialized value
> ‘sl.rq.v.ptr’: 4
>  - -Wanalyzer-out-of-bounds heap-based buffer under-read: 3
>  - -Wanalyzer-malloc-leak leak of ‘u’: 3
>  - -Wanalyzer-use-of-uninitialized-value use of uninitialized value
> ‘sl.rq.u.len’: 3
>  - -Wanalyzer-null-dereference dereference of NULL ‘s’: 3
>  - -Wanalyzer-malloc-leak leak of ‘strdup(&buf)’: 2
>  - -Wanalyzer-null-dereference dereference of NULL ‘ret’: 2
>  - -Wanalyzer-malloc-leak leak of ‘chk.area’: 2
>  - -Wanalyzer-fd-leak leak of file descriptor ‘socket(1, 1, 0)’: 2
>  - -Wanalyzer-use-of-uninitialized-value use of uninitialized value
> ‘ring.buf.data’: 2
>  - -Wanalyzer-deref-before-check check of ‘meth’ for NULL after already
> dereferencing it: 2
>  - -Wanalyzer-deref-before-check check of ‘uri’ for NULL after already
> dereferencing it: 2
>  - -Wanalyzer-deref-before-check check of ‘vsn’ for NULL after already
> dereferencing it: 2
>  - -Wanalyzer-allocation-size allocated buffer size is not a multiple of the
> pointee's size: 2
>  - -Wanalyzer-deref-before-check check of ‘etag_buffer’ for NULL after
> already dereferencing it: 2
>  - -Wanalyzer-use-of-uninitialized-value use of uninitialized value
> ‘*(unsigned int *)memPtr’: 2
>  - -Wanalyzer-deref-before-check check of ‘result’ for NULL after already
> dereferencing it: 2
>  - -Wanalyzer-possible-null-dereference dereference of possibly-NULL ‘p’: 2
>  - -Wanalyzer-null-argument use of NULL ‘params’ where non-null expected: 2
>  - -Wanalyzer-null-dereference dereference of NULL ‘uri’: 2
>  - -Wanalyzer-deref-before-check check of ‘dash’ for NULL after already
> dereferencing it: 2
>  - -Wanalyzer-fd-leak leak of file descriptor: 1
>  - -Wanalyzer-malloc-leak leak of ‘calloc((long unsigned int)(hdr_num + 1),
> 32)’: 1
>  - -Wanalyzer-malloc-leak leak of ‘node’: 1
>  - -Wanalyzer-malloc-leak leak of ‘malloc((long unsigned int)(len + 1))’: 1
>  - -Wanalyzer-use-of-uninitialized-value use of uninitialized value ‘data’: 1
>  - -Wanalyzer-malloc-leak leak of ‘newkey’: 1
>  - -Wanalyzer-possible-null-dereference dereference of possibly-NULL ‘p1’: 1
>  - -Wanalyzer-malloc-leak leak of ‘conf_err’: 1
>  - -Wanalyzer-malloc-leak leak of ‘new_conf_err’: 1
>  - -Wanalyzer-malloc-leak leak of ‘strdup(*args_21(D) + _3)’: 1
>  - -Wanalyzer-use-of-uninitialized-value use of uninitialized value
> ‘*(struct lru64 *)_117 = PHI <_8(16), troot_4(13), ret_106(24)>.revision’: 1
>  - -Wanalyzer-use-of-uninitialized-value use of uninitialized value
> ‘*(struct lru64 *)_117 = PHI <_8(16), troot_4(13), ret_106(24)>.lru.n’: 1
>  - -Wanalyzer-use-of-uninitialized-value use of uninitialized value
> ‘*(struct lru64 *)_117 = PHI <_8(16), troot_4(13), ret_106(24)>.lru.p’: 1
>  - -Wanalyzer-malloc-leak leak of ‘*lru.spare’: 1
>  - -Wanalyzer-malloc-leak leak of ‘strdup(*args_18(D) + _4)’: 1
>  - -Wanalyzer-possible-null-dereference dereference of possibly-NULL ‘dst’: 1
>  - -Wanalyzer-use-after-free use after ‘free’ of ‘link’: 1
>  - -Wanalyzer-malloc-leak leak of ‘strdup(backing)’: 1
>  - -Wanalyzer-possible-null-dereference dereference of possibly-NULL ‘comp’:
> 1
>  - -Wanalyzer-malloc-leak leak of ‘fconf’: 1
>  - -Wanalyzer-malloc-leak leak of ‘strdup("/haproxy?stats")’: 1
>  - -Wanalyzer-malloc-leak leak of ‘strdup(".internal-stats-userlist")’: 1
>  - -Wanalyzer-malloc-leak leak of ‘calloc(1, 72)’: 1
>  - -Wanalyzer-malloc-leak leak of ‘strdup(*args_153(D) + _49)’: 1
>  - -Wanalyzer-deref-before-check check of ‘ext_child’ for NULL after already
> dereferencing it: 1
>  - -Wanalyzer-use-of-uninitialized-value use of uninitialized value
> ‘sl.rq.m.len’: 1
>  - -Wanalyzer-use-of-uninitialized-value use of uninitialized value
> ‘sl.rq.v.l

[Bug middle-end/88345] -Os overrides -falign-functions=N on the command line

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #10 from Eric Gallager  ---
(In reply to Jakub Jelinek from comment #2)
> I disagree, with -Os you want smallest size.

There is -Oz now, so now *that's* the one for the smallest size

[Bug ipa/108384] error: conversion of register to a different size in ‘view_convert_expr’

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |ipa
 CC||marxin at gcc dot gnu.org

--- Comment #2 from Andrew Pinski  ---
The code is undefined ...

  func_23(l_26[1]);

func_23(struct S0 p_24, struct S0 p_25)

[Bug ipa/108384] error: conversion of register to a different size in ‘view_convert_expr’

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #3 from David Binderman  ---
(In reply to Andrew Pinski from comment #2)
> The code is undefined ...
> 
>   func_23(l_26[1]);
> 
> func_23(struct S0 p_24, struct S0 p_25)

Interesting. It looks like the reduction has not preserved the two
parameters required of func_23.

>From the original csmith produced code:

$ fgrep func_23 bug873.c
static union U2 * func_23(struct S0 p_24, const struct S1 p_25);
if *l_9) &= 0x3631L) ,
(safe_div_func_int32_t_s_s((safe_sub_func_int8_t_s_ssafe_mod_func_uint32_t_u_u(((func_17(func_23(l_26[1],
l_27), l_9, ((*l_1367) = l_1366),
(safe_add_func_uint32_t_u_u(((safe_div_func_uint8_t_u_u(((safe_rshift_func_uint8_t_u_s((l_27.f0
> p_3), 1)) || (((safe_div_func_int64_t_s_s(p_3, p_3)) != 0x47247D4EED584808LL)
|| g_1119)), 0x21L)) > g_1165[0]), 0xB3A4A36DL)), l_27.f4.f0) <=
0x334C102EE31FC4EFLL) & p_3), g_7.f0)) & g_1165[0]) || l_1397), 0L)),
0x55B9621EL
static union U2 * func_23(struct S0 p_24, const struct S1 p_25)

Two parameters in the first declaration, two in the call and two in the
definition.

[Bug tree-optimization/108385] false positive -Wfree-nonheap-object

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

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

--- Comment #1 from Andrew Pinski  ---
-std=c++20 -O2

[Bug tree-optimization/108385] false positive -Wfree-nonheap-object

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

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

--- Comment #2 from Andrew Pinski  ---
The warning is gone on the trunk.

[Bug ipa/108384] error: conversion of register to a different size in ‘view_convert_expr’

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #4 from David Binderman  ---
(In reply to David Binderman from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > The code is undefined ...
> > 
> >   func_23(l_26[1]);
> > 
> > func_23(struct S0 p_24, struct S0 p_25)
> 
> Interesting. It looks like the reduction has not preserved the two
> parameters required of func_23.

I suspect a grep pattern could help guide the reduction.
I tried a few patterns, but didn't make any real progress.

Meanwhile, I try a bisection. Trying git hash g:0333892db367b2b9

[Bug ipa/108384] error: conversion of register to a different size in ‘view_convert_expr’

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #5 from David Binderman  ---
(In reply to David Binderman from comment #4)
> Meanwhile, I try a bisection. Trying git hash g:0333892db367b2b9

Seems good. Trying g:d3328df5f5c9908c

[Bug c++/83652] template substitution fails on operator

[sameer.varyani at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Sameer Varyani  ---
Is there an update on this bug?

[Bug ipa/108384] error: conversion of register to a different size in ‘view_convert_expr’

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #6 from David Binderman  ---
(In reply to David Binderman from comment #5)
> (In reply to David Binderman from comment #4)
> > Meanwhile, I try a bisection. Trying git hash g:0333892db367b2b9
> 
> Seems good. Trying g:d3328df5f5c9908c

Seems good. Trying g:5b918b20d18b9cce

[Bug target/108386] New: Missed optimization with -fno-omit-frame-pointer on x86

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

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

Bug ID: 108386
   Summary: Missed optimization with -fno-omit-frame-pointer on
x86
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

void bar (char *);

void
foo (void)
{
  char buf[384];
  bar (&buf[0]);
  bar (&buf[16]);
  bar (&buf[127]);
  bar (&buf[128]);
  bar (&buf[256]);
  bar (&buf[380]);
  bar (&buf[384]);
}

compiles with -O2 -fno-omit-frame-pointer to:
pushq   %rbp
movq%rsp, %rbp
subq$384, %rsp
leaq-384(%rbp), %rdi
callbar
leaq-368(%rbp), %rdi
callbar
leaq-257(%rbp), %rdi
callbar
leaq-256(%rbp), %rdi
callbar
leaq-128(%rbp), %rdi
callbar
leaq-4(%rbp), %rdi
callbar
movq%rbp, %rdi
callbar
leave
ret
but this is unnecessarily large.  As frame pointer is here only because user
asked for it, the compiler knows there is always constant difference between
the stack pointer and frame pointer and perhaps in machine reorg could
interchange those cases which would be smaller and not slower.
For these particular leaq/movq instructions, movq %r{sp,bp}, %rdi is 3 bytes,
leaq SIMM8(%rbp), %rdi 4 bytes, leaq SIMM8(%rsp), %rdi 5 bytes, leaq
SIMM32(%rbp), %rdi 7 bytes and leaq SIMM32(%rsp), %rdi 8 bytes.
So at least from code size POV, movq %rsp, %rdi is smaller than any %rbp based
leaq,
and similarly leaq SIMM8(%rbp), %rdi 2 bytes smaller than leaq SIMM32(%rbp),
%rdi.
So, the mov would be a win always, and for frame sizes of more than 128 bytes
%rsp up to 127 offset too.
Though, I think the aliasing code hardcodes frame pointer knowledge and ditto I
think
the unwinder would be quite upset if we did such changes early.

[Bug d/99794] libphobos: Support building on *-*mingw*

[nightstrike at gmail dot com via Gcc-bugs]

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

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com

--- Comment #2 from nightstrike  ---
Hoping this can be backported to 11 so that we can easily bootstrap later
versions.  Meanwhile, will this also fix the build errors on cygwin, or if is
specific to mingw?

[Bug ipa/108384] error: conversion of register to a different size in ‘view_convert_expr’

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||mjambor at suse dot cz

--- Comment #7 from David Binderman  ---
(In reply to David Binderman from comment #6)
> (In reply to David Binderman from comment #5)
> > (In reply to David Binderman from comment #4)
> > > Meanwhile, I try a bisection. Trying git hash g:0333892db367b2b9
> > 
> > Seems good. Trying g:d3328df5f5c9908c
> 
> Seems good. Trying g:5b918b20d18b9cce

It appears to me that Martin Jambor's revision g:c389991432da2bcc
is the one at fault.

Adding Martin for their best opinion.

[Bug tree-optimization/108387] New: [13 Regression] ICE: tree check: expected ssa_name, have integer_cst in VN_INFO, at tree-ssa-sccvn.cc:450 at -Os

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 108387
   Summary: [13 Regression] ICE: tree check: expected ssa_name,
have integer_cst in VN_INFO, at tree-ssa-sccvn.cc:450
at -Os
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 54258
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54258&action=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -Os testcase.c 
during GIMPLE pass: fre
testcase.c: In function 'foo':
testcase.c:6:1: internal compiler error: tree check: expected ssa_name, have
integer_cst in VN_INFO, at tree-ssa-sccvn.cc:450
6 | foo (char c)
  | ^~~
0x8144d0 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/repo/gcc-trunk/gcc/tree.cc:8854
0x7f8e10 tree_check(tree_node*, char const*, int, char const*, tree_code)
/repo/gcc-trunk/gcc/tree.h:3530
0x7f8e10 VN_INFO(tree_node*)
/repo/gcc-trunk/gcc/tree-ssa-sccvn.cc:450
0x15c7e55 vn_nary_op_insert_stmt
/repo/gcc-trunk/gcc/tree-ssa-sccvn.cc:4610
0x15d3330 visit_nary_op
/repo/gcc-trunk/gcc/tree-ssa-sccvn.cc:5408
0x15d4870 process_bb
/repo/gcc-trunk/gcc/tree-ssa-sccvn.cc:7870
0x15d60c2 do_rpo_vn_1
/repo/gcc-trunk/gcc/tree-ssa-sccvn.cc:8469
0x15d7a96 execute
/repo/gcc-trunk/gcc/tree-ssa-sccvn.cc:8627
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-5122-20230112143021-gb073f2b098b-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-5122-20230112143021-gb073f2b098b-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20230112 (experimental) (GCC)

[Bug fortran/108369] FM509 Fails to compile with error

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #4 from Steve Kargl  ---
On Wed, Jan 11, 2023 at 09:50:37PM +, kargl at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369
> 
> --- Comment #3 from kargl at gcc dot gnu.org ---
> (In reply to anlauf from comment #1)
> > (In reply to Ben Brewer from comment #0)
> > Workaround: either use -std=legacy or fix the above argument declaration to:
> > 
> >   CHARACTER C1D001(*)*8,CVD001*8
> 
> While the workaround will work, it does so because it disables
> -fallow-argument-mismatch.  But, that feature emitting a bogus
> error/warning.
> 
> Note the following all compile and execute.  TKR is satisfied
> as I discussion in comment #2.
> 

After looking into this a bit closer, Harald is indeed correct
with the need for -std=legacy (or -fallow-argument-mismatch).
In the line

  CALL SN512(C1N001(5)(2:9),CVCOMP)

'C1N001(5)(2:9)' is a substring of the array element 'C1N001(5)',
which is a scalar (ie., rank = 0).  The interface for SN512 is

  SUBROUTINE SN512(C1D001,CVD001)
  CHARACTER C1D001(6)*8,CVD001*8

The first dummy argument is a rank 1 array.  

Now, if the test is changed to pass an array section such as

  CALL SN512(C1N001(4:5)(2:9),CVCOMP)

then gfortran gives

%  gfcx -w -c fm509.f
fm509.f:378:17:

  378 |   CALL SN512(C1N001(4:5)(2:9),CVCOMP)  
  03770509
  | 1
Error: Actual argument contains too few elements for dummy
argument 'c1d001' (16/48) at (1)

which I believe may be wrong.

[Bug debug/49312] Make DW_AT_name contain only simple name, no template-id

[dblaikie at gmail dot com via Gcc-bugs]

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

David Blaikie  changed:

   What|Removed |Added

 CC||dblaikie at gmail dot com

--- Comment #4 from David Blaikie  ---
FWIW I've (partially) implemented this in Clang under the flag
`-gsimple-template-names` due to some really large debug info issues with
(especially eigen and tensorflow) expression templates (I saw template names as
long as 50k characters leading to exceeding the 32 bit limit in .debug_str.dwo
sections in dwp files (and gold dwp didn't check for overflow, so this caused
silent corruption)).

There certainly are some issues with it - my approach didn't simplify all names
- certain names aren't easy to roundtrip from the DIE descriptions of the
template parameters (lambdas are a great/difficult example, for instance - the
lambda type DIEs don't have anything about the lambda mangling number, etc, and
maybe should - so even in non-template cases the lambdas could be matched up
between two TUs (lambdas in inline functions are the same type even in
different translation units & should be treated as such))

So there's a bunch of work that'd probably need to be done on template DIE
accuracy/completeness before this feature could be adopted wholesale without
any exemptions, but for the size benefits (especially in expression template
heavy code) I've found it to be worthwhile & we've done some work to flesh out
support for this in lldb as well as identify maybe a couple of gdb bugs related
to this.

I've tried to poke dwarf-discuss about the lambda issue in particular (
http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/2022-August/007117.html
) but no one seems interested in discussing it. So maybe it's something
GCC/Clang/GDB/LLDB folks should discuss more directly together.

Also some recent discussion with Simon Marchi on the gdb list:
https://sourceware.org/pipermail/gdb/2023-January/050496.html

[Bug ipa/108384] error: conversion of register to a different size in ‘view_convert_expr’

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #8 from David Binderman  ---
(In reply to David Binderman from comment #4)
> I suspect a grep pattern could help guide the reduction.
> I tried a few patterns, but didn't make any real progress.

Using this pattern:

$ grep "func_23[^,]*,[^)]*)" bug873.c

I got the following reduced code:

struct S0 {
  int f0;
  short f1;
  unsigned f2 : 7;
  short f3
} func_2_l_27;
g_389;
func_23(struct S0 p_24, struct S0 p_25) {
  int *l_1051 = g_389;
  if (safe_sub_func_int16_t_s_s())
for (;;)
  safe_lshift_func_uint8_t_u_s(p_24.f1);
  *l_1051 = p_25.f0;
}
func_2() {
  struct S0 l_26[] = {4, 5, 4, 6, 4, 5, 4, 6};
  func_23(l_26[1], func_2_l_27);
}

$ fgrep func_23 bug873.c
func_23(struct S0 p_24, struct S0 p_25) {
  func_23(l_26[1], func_2_l_27);
$

[Bug libstdc++/107189] Inconsistent range insertion implementations in std::_Rb_tree in

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Francois Dumont :

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

commit r13-5125-gb3c9148cad2f6f05ef9bc0be34b65a62a7e236dd
Author: François Dumont 
Date:   Wed Oct 12 19:34:01 2022 +0200

libstdc++: Remove _Alloc_node instance in _Rb_tree [PR107189]

libstdc++-v3/ChangeLog:

PR libstdc++/107189
* include/bits/stl_tree.h (_Rb_tree<>::_M_insert_range_equal):
Remove
unused _Alloc_node instance.

[Bug rtl-optimization/108388] New: LRA generates RTL that violates constraints

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

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

Bug ID: 108388
   Summary: LRA generates RTL that violates constraints
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pkoning at gcc dot gnu.org
  Target Milestone: ---

Created attachment 54259
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54259&action=edit
Reproducer for this issue

In gcc for pdp11-aout, compiling with LRA enabled (-mlra) and optimization (-Os
or -O2) I get an ICE when building libgcc2.  The issue appears to be that LRA
first assigns a hard register for the destination of an addhi3 RTL,
specifically R5.  R5 is the frame register, but it can be eliminated.  The
source is an address computed from the frame pointer, i.e., a (plus (r5) (const
int something)).  The machine is a two-operand machine, so in patterns like
addhi3 the operand descriptor for operand 1 (first source) requires it to be
the same as operand 0 (destination).

So far so good.  The assigned register indeed satisfies that constraint.

But apparently after that point LRA decides to eliminate the frame register, so
it simply replaces that frame-related reference in the source by a stack
pointer based reference, of the form (plus (sp) (const int something-else)). 
At this point we have a constraint violation because operands 0 and 1 are now
different (r5 and sp respectively).  Correct code would require copying sp into
some other register then doing the addhi3 with that register.

The code compiles correctly with old reload (the default, in the currently
committed pdp11 target).

[Bug debug/49130] discrepancies between DW_AT_name and demangler

[dblaikie at gmail dot com via Gcc-bugs]

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

David Blaikie  changed:

   What|Removed |Added

 CC||dblaikie at gmail dot com

--- Comment #12 from David Blaikie  ---
> Note that both DW_AT_name and DW_TAG_template_value_param are
> incorrect.  The demangler gets it right:
> 
>void f(S2)

Yeah, the problem here is that the /type/ is correctly `S2` -
that's the same type no matter how it's written. But the mangling of `f` is
distinct depending on how the expression is written...

I'm not really sure how we should encode that in DWARF - it'd be problematic to
encode a different `S2` instantiation for this context compared to some other
place that names the type differently - in terms of the debugger being able to
treat them as the same type, match declarations and definitions, etc. I guess
S2 could be emitted as an alias/typedef of the
underlying S2?

Or some other way to carry the mangle-equivalent details on the
DW_TAG_template_*_parameter directly?

Though these expression template issues only apply to functions, yeah? Is there
a need to deduplicate function definitions - generally the linker has already
done this & the DWARF describes the function definition - I guess the issue
here is that two different functions will have the same DW_AT_name & confuse
the debugger/user if they're trying to call the functions in an expression
evaluator, etc.

[Bug lto/108389] New: LTO(plugin) can not find lto-ed symbols

[eebssk1 at godaftwithebk dot pub via Gcc-bugs]

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

Bug ID: 108389
   Summary: LTO(plugin) can not find lto-ed symbols
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eebssk1 at godaftwithebk dot pub
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

I had compiled mingw32 crt with LTO on (fat objects enabled to maintain
compability).
However when I trying to compile a dll(also with lto),I got undefined reference
at final linking.

like:
/home/eebssk1/mingw32/x86_64-w64-mingw32/bin/../lib/gcc/x86_64-w64-mingw32/12.2.1/../../../../x86_64-w64-mingw32/bin/ld:
/tmp/ccImpF6y.ltrans0.ltrans.o: in function `pthread_once':
/home/eebssk1/g/mingw-crt-build/mingw-w64-mingw-w64/build/../mingw-w64-libraries/winpthreads/src/thread.c:762:
undefined reference to `fprintf'
/home/eebssk1/mingw32/x86_64-w64-mingw32/bin/../lib/gcc/x86_64-w64-mingw32/12.2.1/../../../../x86_64-w64-mingw32/bin/ld:
/tmp/ccImpF6y.ltrans0.ltrans.o: in function `_amsg_exit':
/home/eebssk1/g/mingw-crt-build/mingw-w64-mingw-w64/build/mingw-w64-crt/../../mingw-w64-crt/crt/ucrtbase_compat.c:106:
undefined reference to `fprintf'
/home/eebssk1/mingw32/x86_64-w64-mingw32/bin/../lib/gcc/x86_64-w64-mingw32/12.2.1/../../../../x86_64-w64-mingw32/bin/ld:
/tmp/ccImpF6y.ltrans0.ltrans.o: in function `rwl_print':
/home/eebssk1/g/mingw-crt-build/mingw-w64-mingw-w64/build/../mingw-w64-libraries/winpthreads/src/rwlock.c:139:
undefined reference to `printf'

from verbose ld:
(/home/eebssk1/g/mingw-crt-build/mingw-w64-mingw-w64/build/../out/lib/libmsvcrt.a)libapi-ms-win-crt-heap-l1-1-0s00025.o
(/home/eebssk1/g/mingw-crt-build/mingw-w64-mingw-w64/build/../out/lib/libmsvcrt.a)libapi-ms-win-crt-heap-l1-1-0s00026.o
(/home/eebssk1/g/mingw-crt-build/mingw-w64-mingw-w64/build/../out/lib/libmsvcrt.a)lib64_libucrt_extra_a-ucrt_vfprintf.o:
no new IR symbols to claim
(/home/eebssk1/g/mingw-crt-build/mingw-w64-mingw-w64/build/../out/lib/libmsvcrt.a)lib64_libucrt_extra_a-ucrt_vfprintf.o:
no new IR symbols to claim
(/home/eebssk1/g/mingw-crt-build/mingw-w64-mingw-w64/build/../out/lib/libmsvcrt.a)lib64_libucrt_extra_a-ucrt_printf.o:
no new IR symbols to claim
(/home/eebssk1/g/mingw-crt-build/mingw-w64-mingw-w64/build/../out/lib/libmsvcrt.a)lib64_libucrt_extra_a-ucrt_printf.o:
no new IR symbols to claim
(/home/eebssk1/g/mingw-crt-build/mingw-w64-mingw-w64/build/../out/lib/libmsvcrt.a)lib64_libucrt_extra_a-ucrt_fprintf.o:
no new IR symbols to claim

These objects really have lto-ed reference indeed.
lib64_libucrt_extra_a-ucrt_printf.o:
 U __acrt_iob_func
 b .bss
 d .data
 d .data$__imp_printf
 N .debug_abbrev
 N .debug_aranges
 N .debug_frame
 N .debug_info
 N .debug_line
 N .debug_line_str
 r .gnu.lto_.decls.c11a8587d357cea5
 r .gnu.lto_.ext_symtab.c11a8587d357cea5
 r .gnu.lto_.icf.c11a8587d357cea5
 r .gnu.lto___imp_printf.120.c11a8587d357cea5
 r .gnu.lto_.inline.c11a8587d357cea5
 r .gnu.lto_.ipa_modref.c11a8587d357cea5
 r .gnu.lto_.ipa_sra.c11a8587d357cea5
 r .gnu.lto_.jmpfuncs.c11a8587d357cea5
 r .gnu.lto_.lto.c11a8587d357cea5
 r .gnu.lto_.opts
 r .gnu.lto_printf.119.c11a8587d357cea5
 r .gnu.lto_.profile.c11a8587d357cea5
 r .gnu.lto_.pureconst.c11a8587d357cea5
 r .gnu.lto_.refs.c11a8587d357cea5
 r .gnu.lto_.symbol_nodes.c11a8587d357cea5
 r .gnu.lto_.symtab.c11a8587d357cea5
 D __imp_printf
 p .pdata
 T printf
 r .rdata$zzz
 U __stdio_common_vfprintf
 t .text
 r .xdata

If I manually extract these objects and append them at compiler commandline,
then the final linking successed.
It looks like the gcc lto plugin does not want to handle them.

The problem is persist both on linux cross compiling environment and windows
msys2 environemnt.

[Bug lto/108389] LTO(plugin) can not find lto-ed symbols

[eebssk1 at godaftwithebk dot pub via Gcc-bugs]

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

--- Comment #1 from eebssk1 at godaftwithebk dot pub ---
binutils version 2.39

[Bug driver/108350] Windows: invoking gcc via symlink does not work

[i.nixman at autistici dot org via Gcc-bugs]

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

--- Comment #13 from niXman  ---
I figured out the building problem.

it seems to work as it should for symlink, but it doesn't work for hardlink.

will dive into docs...

[Bug ipa/108384] [13 Regression] error: conversion of register to a different size in ‘view_convert_expr’

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|error: conversion of|[13 Regression] error:
   |register to a different |conversion of register to a
   |size in ‘view_convert_expr’ |different size in
   ||‘view_convert_expr’
   Last reconfirmed||2023-01-12
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Target Milestone|--- |13.0

--- Comment #9 from Andrew Pinski  ---
Confirmed.
Here is a cleaned up testcase where you don't need the
-ftrivial-auto-var-init=zero option either; just -O3

```
struct S0 {
  int f0;
  short f1;
  unsigned f2 : 7;
  short f3;
} func_2_l_27;
int *g_389;
int safe_sub_func_int16_t_s_s(void);
void safe_lshift_func_uint8_t_u_s(int);
void func_23(struct S0 p_24, struct S0 p_25) {
  int *l_1051 = g_389;
  if (safe_sub_func_int16_t_s_s())
for (;;)
  safe_lshift_func_uint8_t_u_s(p_24.f1);
  *l_1051 = p_25.f0;
}
void func_2(void) {
  struct S0 l_26[] = {4, 5, 4, 6, 4, 5, 4, 6};
  __builtin_clear_padding (&l_26);
  func_23(l_26[1], func_2_l_27);
}
```

[Bug ipa/108384] [13 Regression] error: conversion of register to a different size in ‘view_convert_expr’

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek  ---
If it is __builtin_clear_padding only, I'll have a look...

[Bug d/99794] libphobos: Support building on *-*mingw*

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #3 from nightstrike  ---
Hm, looks like it *IS* in 11.  I was confused by the PR being open and the
version stating 11, thinking that it still wasn't applied.  So the remaining
issues then are building on cygwin.  But at least on a linux to mingw cross,
the testsuite passes with only 33 fails.

[Bug modula2/108136] Modula2 meets cppcheck

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #1 from Gaius Mulley  ---
Many thanks for the bug report!  I've generated a patch to fix the two cases of
*RTco*.c in the tree.

[Bug ipa/108384] [13 Regression] error: conversion of register to a different size in ‘view_convert_expr’

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

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

--- Comment #11 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #10)
> If it is __builtin_clear_padding only, I'll have a look...

After the __builtin_clear_padding is exposed and before the IPA passes, the IR
looks like:

  l_26[1].f0 = 4;
  MEM  [(struct S0[2] *)&l_26 + 16B] = 25770065925;
  func_23 (l_26[1], func_2_l_27);

So here is another testcase which you can reproduce it with -O3
-fno-strict-aliasing (because I voilate aliasing rules to get a similar enough
IR):
```
struct S0 {
  int f0;
  short f1;
  unsigned f2 : 7;
  short f3;
} func_2_l_27;
int *g_389;
int safe_sub_func_int16_t_s_s(void);
void safe_lshift_func_uint8_t_u_s(int);
void func_23(struct S0 p_24, struct S0 p_25) {
  int *l_1051 = g_389;
  if (safe_sub_func_int16_t_s_s())
for (;;)
  safe_lshift_func_uint8_t_u_s(p_24.f1);
  *l_1051 = p_25.f0;
}
void func_2(void) {
  struct S0 l_26[2];
  l_26[1].f0 = 4;
  ((long long*)&l_26)[2] = 25770065925;
  func_23(l_26[1], func_2_l_27);
}
```

[Bug modula2/108136] Modula2 meets cppcheck

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

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

--- Comment #2 from Gaius Mulley  ---
Created attachment 54260
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54260&action=edit
Add missing return statement to RTco_select

[Bug analyzer/105273] -Wanalyzer-use-of-uninitialized-value warns on "missing" default for switch when callers can be statically determined

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

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

--- Comment #5 from David Malcolm  ---
Similar thing seen in linuxdoom-1.10:

p_floor.c: In function ‘EV_BuildStairs’:
p_floor.c:503:22: warning: use of uninitialized value ‘speed’ [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
  503 | floor->speed = speed;
  | ~^~~
  ‘EV_BuildStairs’: events 1-9
|
|  472 | fixed_t speed;
|  | ^
|  | |
|  | (1) region created on stack here
|  | (2) capacity: 4 bytes
|..
|  476 | while ((secnum = P_FindSectorFromLineTag(line,secnum)) >= 0)
|  |
|  ||
|  |(3)
following ‘true’ branch (when ‘secnum >= 0’)...
|  477 | {
|  478 | sec = §ors[secnum];
|  |   
|  |   |
|  |   (4) ...to here
|..
|  481 | if (sec->specialdata)
|  |~ 
|  ||
|  |(5) following ‘false’ branch...
|..
|  485 | rtn = 1;
|  | ~~~  
|  | |
|  | (6) ...to here
|..
|  492 | switch(type)
|  | ~~   
|  | |
|  | (7) following ‘default:’ branch...
|..
|  503 | floor->speed = speed;
|  | 
|  |  |
|  |  (8) ...to here
|  |  (9) use of uninitialized value ‘speed’ here
|


and also with "stairsize".

In both cases the analyzer considers the case of taking the "default" branch
at:

|  492 | switch(type)
|  | ~~   
|  | |
|  | (7) following ‘default:’ branch...


which would leave this uninitialized, where:

int
EV_BuildStairs
( line_t*   line,
  stair_e   type )

and p_spec.h has:

typedef enum
{
build8, // slowly build by 8
turbo16 // quickly build by 16

} stair_e;

and the only calls to EV_BuildStairs are in other TUs:

p_spec.c: 576:  EV_BuildStairs(line,build8);
p_spec.c: 739:  EV_BuildStairs(line,turbo16);
p_switch.c: 350:if (EV_BuildStairs(line,build8))
p_switch.c: 488:if (EV_BuildStairs(line,turbo16))

Probably should assume that a switch on an enum takes one of the enum's values.

[Bug tree-optimization/108387] [13 Regression] ICE: tree check: expected ssa_name, have integer_cst in VN_INFO, at tree-ssa-sccvn.cc:450 at -Os

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug tree-optimization/108387] [13 Regression] ICE: tree check: expected ssa_name, have integer_cst in VN_INFO, at tree-ssa-sccvn.cc:450 at -Os

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

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

--- Comment #1 from Andrew Pinski  ---
Obvious caused by r13-5111-g98837d6e79dd27 .

[Bug tree-optimization/108387] [13 Regression] ICE in VN_INFO with multiple and shifts producing 0 at -O2/s/3

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-01-12
Summary|[13 Regression] ICE: tree   |[13 Regression] ICE in
   |check: expected ssa_name,   |VN_INFO with multiple and
   |have integer_cst in |shifts producing 0 at
   |VN_INFO, at |-O2/s/3
   |tree-ssa-sccvn.cc:450 at|
   |-O2/s/3 |

--- Comment #2 from Andrew Pinski  ---
Confirmed. Here is a testcase without vectors Compile at -O2 -fno-tree-ccp to
produce the same issue:
```
void bar2 (unsigned char, unsigned char);

void
foo1 (char c)
{
  unsigned char t = c;
  t *= 2;
  unsigned char t1 = t << 7;
  bar2 (t, t1);
}
```

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

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

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

--- Comment #57 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r13-5127-gf629f63d2d9d7ad2c43f8e451f0f6e32b5f4d06a
Author: Jonathan Wakely 
Date:   Thu Jan 12 10:58:13 2023 +

libstdc++: Extend max_align_t special case to 64-bit HP-UX [PR77691]

GCC's std::max_align_t doesn't agree with the system malloc on HP-UX, so
generalize the current hack for Solaris to apply to that target too.

libstdc++-v3/ChangeLog:

PR libstdc++/77691
* include/experimental/memory_resource
(_GLIBCXX_MAX_ALIGN_MATCHES_MALLOC): Define.
(do_allocate, do_deallocate): Check it.
* testsuite/experimental/memory_resource/new_delete_resource.cc:
Relax expected behaviour for 64-bit hppa-hp-hpux11.11.

[Bug analyzer/105273] -Wanalyzer-use-of-uninitialized-value warns on "missing" default for switch when callers can be statically determined

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

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

--- Comment #6 from David Malcolm  ---
Another instance from Doom, this time where the enum is in a field lookup,
rather than an input parameter:

p_maputl.c: In function ‘P_BoxOnLineSide’:
p_maputl.c:151:8: warning: use of uninitialized value ‘p1’ [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
  151 | if (p1 == p2)
  |^
  ‘P_BoxOnLineSide’: events 1-5
|
|  115 | int p1;
|  | ^~
|  | |
|  | (1) region created on stack here
|  | (2) capacity: 4 bytes
|..
|  118 | switch (ld->slopetype)
|  | ~~   
|  | |
|  | (3) following ‘default:’ branch...
|..
|  151 | if (p1 == p2)
|  |~ 
|  ||
|  |(4) ...to here
|  |(5) use of uninitialized value ‘p1’ here
|

where r_defs.h has:

//
// Move clipping aid for LineDefs.
//
typedef enum
{
ST_HORIZONTAL,
ST_VERTICAL,
ST_POSITIVE,
ST_NEGATIVE

} slopetype_t;

typedef struct line_s
{
[...snip...]

// To aid move clipping.
slopetype_t slopetype;

[...snip...]
} line_t;

and all four enum values are covered by the switch statement.

[Bug ipa/108384] [13 Regression] error: conversion of register to a different size in ‘view_convert_expr’

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

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #12 from Martin Jambor  ---
Looks like V_C_E insertion by ipa_param_body_adjustments needs to be more
careful.  Let me have a look.

[Bug fortran/107508] Invalid bounds due to bogus reallocation on assignment with KIND=4 characters

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
So fixed for gcc-13?

[Bug tree-optimization/92342] [10/11/12/13 Regression] a small missed transformation into x?b:0

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

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

--- Comment #28 from CVS Commits  ---
The master branch has been updated by Roger Sayle :

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

commit r13-5128-gfd1f5373b8647a5da2f7f4b42282e676a4b04d98
Author: Roger Sayle 
Date:   Thu Jan 12 21:47:40 2023 +

PR tree-optimization/92342: Optimize b & -(a==c) in match.pd

This patch is an update/tweak of Andrew Pinski's two patches for
PR tree-optimization/92342, that were originally posted by in November:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585111.html
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585112.html

Technically, the first of those was approved by Richard Biener, though
never committed, and my first thought was to simply push it for Andrew,
but the review of the second piece expressed concerns over comparisons
in non-integral modes, where the result may not be zero-one valued.
Indeed both transformations misbehave in the presence of vector mode
comparisons (these transformations are already implemented for
vec_cond elsewhere in match.pd), so my minor contribution is to limit
these new transformations to scalars, by testing that both the operands
and results are INTEGRAL_TYPE_P.

2023-01-12  Andrew Pinski  
Roger Sayle  

gcc/ChangeLog:
PR tree-optimization/92342
* match.pd ((m1 CMP m2) * d -> (m1 CMP m2) ? d : 0):
Use tcc_comparison and :c for the multiply.
(b & -(a CMP c) -> (a CMP c)?b:0): New pattern.

gcc/testsuite/ChangeLog:
PR tree-optimization/92342
* gcc.dg/tree-ssa/andnegcmp-1.c: New test.
* gcc.dg/tree-ssa/andnegcmp-2.c: New test.
* gcc.dg/tree-ssa/multcmp-1.c: New test.
* gcc.dg/tree-ssa/multcmp-2.c: New test.

[Bug libgcc/108279] Improved speed for float128 routines

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

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

--- Comment #6 from Thomas Koenig  ---
(In reply to Michael_S from comment #5)
> Hi Thomas
> Are you in or out?

Depends a bit on what exactly you want to do, and if there is
a chance that what you want to do will be incorporated into gcc.

If you want to replace the soft-float routines, you will have to
replace them with the full functionality.

And there will have to be a decision about 32-bit targets.

> If you are still in, I can use your help on several issues.
> 
> 1. Torture. 
> See if Invalid Operand exception raised properly now. Also if there are
> still remaining problems with NaN.

I've putyour addition/subtraction routines in as a replacement
an am running a regression test.  We'll see when that finishes.

> 2. Run my correction tests on as many non-AMD64 targets as you can.
> Preferably, with 100,000,000 iterations, but on weaker HW 10,000,000 will do.

This will take some time.

> 3. Run my speed tests (tests/matmulq/mm_speed_ma) on more diverse set of
> AMD64 computers than I did.
> Of special interest are
> - AMD Zen3 on Linux running on bare metal
> - Intel Skylake, SkylakeX, Tiger/Rocket Lake and Alder Lake on Linux running
> on bare metal
> I realize that doing speed tests is not nearly as simple as correctness
> tests.
> We need non-busy (preferably almost idle) machines that have stable CPU
> clock rate. It's not easy to find machines like that nowadays. But, may be,
> you can find at least some from the list.

I currenty have no access to that sort of hardware (I'm just a volunteer,
and my home box is Zen-1).

> 4. Run my speed tests on as many non-obsolete ARM64 computers as you can
> find.
> Well, probably a wishful thinking on my part.
> 
> 
> Also off topic but of interest: postprocessed source of matmul_r16.c

Where should I send that to?

[Bug target/99531] [10/11 Regression] Performance regression since gcc 9 (argument passing / register allocation)

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

Summary|[10/11/12/13 Regression]|[10/11 Regression]
   |Performance regression  |Performance regression
   |since gcc 9 (argument   |since gcc 9 (argument
   |passing / register  |passing / register
   |allocation) |allocation)
 CC||roger at nextmovesoftware dot 
com

--- Comment #9 from Roger Sayle  ---
This has been fixed for GCC 12 and GCC 13.  Thanks to Vladimir.

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

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

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

Iain Sandoe  changed:

   What|Removed |Added

  Attachment #54220|0   |1
is obsolete||
  Attachment #54248|0   |1
is obsolete||

--- Comment #14 from Iain Sandoe  ---
Created attachment 54261
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54261&action=edit
Updated patch that honours the order of include use.

This is V5 ...

... so here we collect the incoming search paths and then apply (most of) the
rules in 
https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html#Directory-Options

... TODO:
 - eliminate duplicate -I entries that have a system one
 - figure out the right way to implement -nostdinc 
 - handle -idirafter

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

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

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

--- Comment #15 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #14)
> Created attachment 54261 [details]
> Updated patch that honours the order of include use.
> 
> This is V5 ...
> 
> ... so here we collect the incoming search paths and then apply (most of)
> the rules in 
> https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html#Directory-Options
> 
> ... TODO:
>  - eliminate duplicate -I entries that have a system one
>  - figure out the right way to implement -nostdinc 
>  - handle -idirafter

add this missed hunk.

diff --git a/gcc/m2/gm2-lang.cc b/gcc/m2/gm2-lang.cc
index 073d1dd55db..cd59784d7b2 100644
--- a/gcc/m2/gm2-lang.cc
+++ b/gcc/m2/gm2-lang.cc
@@ -513,6 +513,7 @@ add_m2_import_paths (const char *liblist)
 {
   char *libname = (char *) alloca (6);
   strncpy (libname, liblist, 5);
+  libname[5] = 0;
   add_one_import_path (libname);
   liblist += 5;
   if (*liblist == ',')

[Bug libstdc++/108327] [13 Regression] Lots of libstdc++ FAILs on powerpc64le-linux

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r13-5132-gceae3a66d3d9eb7c468f0a36f203c9e6b2b8a3e7
Author: Jonathan Wakely 
Date:   Thu Jan 12 22:35:30 2023 +

libstdc++: Fix exports for IEEE128 versions of __try_use_facet [PR108327]

The new symbols need to be exported, as well as some of the
std::locale::facet::id globals, which are not new but were presumably
not needed by any inline functions before now.

libstdc++-v3/ChangeLog:

PR libstdc++/108327
* config/os/gnu-linux/ldbl-extra.ver (GLIBCXX_LDBL_3.4.31):
Export __try_use_facet specializations for facets in namespace
__gnu_cxx_ldbl128.
* config/os/gnu-linux/ldbl-ieee128-extra.ver
(GLIBCXX_IEEE128_3.4.31): Likewise for facets in namespace
__gnu_cxx_ieee128.
* testsuite/util/testsuite_abi.cc: Add to lists of known and
latest versions.

[Bug libstdc++/108327] [13 Regression] Lots of libstdc++ FAILs on powerpc64le-linux

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
Fixed

[Bug fortran/108369] FM509 Fails to compile with error

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

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #5 from Jerry DeLisle  ---
I use to run the NIST tests regularly many years ago. Even then, we would hita
bug once in a while.  FM509 has failed before in those times and I would not be
surprised something got broke.  I do remember you have to use -std=legacy no
matter what.

Steve you may have discovered something new.  I the meantime I hope I can find
the old script I used to run the tests.  Its about three disk drive ago
connected to three different computers, however, I never delete things. (on the
hunt tonight)

[Bug libstdc++/108362] views::istream is SFINAE-unfriendly

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug libgcc/108279] Improved speed for float128 routines

[already5chosen at yahoo dot com via Gcc-bugs]

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

--- Comment #7 from Michael_S  ---
Either here or my yahoo e-mail

[Bug c++/108390] New: ICE in fold_convert_loc, at fold-const.cc:2504 partial ordering between array types

[ed at catmur dot uk via Gcc-bugs]

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

Bug ID: 108390
   Summary: ICE in fold_convert_loc, at fold-const.cc:2504 partial
ordering between array types
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ed at catmur dot uk
  Target Milestone: ---

template long f(int(*)[t], T(*)[t]);
template int f(int(*)[i], T(*)[i]);
int n = f(0, 0);

:4:18: internal compiler error: in fold_convert_loc, at
fold-const.cc:2504
4 | int n = f(0, 0);
  | ~^~
0x23975be internal_error(char const*, ...)
???:0
0xa693ae fancy_abort(char const*, int, char const*)
???:0
0xc99848 more_specialized_fn(tree_node*, tree_node*, int)
???:0
0xa97529 build_new_function_call(tree_node*, vec**, int)
???:0
0xcb6fd4 finish_call_expr(tree_node*, vec**, bool,
bool, int)
???:0
0xc43be7 c_parse_file()
???:0
0xd7fd79 c_common_parse_file()
???:0

Godbolt says this is bad back to 8.1; before that it was ambiguous.

[Bug c++/108390] ICE in fold_convert_loc, at fold-const.cc:2504 partial ordering between array types

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

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

--- Comment #1 from Andrew Pinski  ---
MSVC considers this ambigous just like older versions of GCC:

(3): error C2668: 'f': ambiguous call to overloaded function
(2): note: could be 'int f(int (*)[2],T (*)[2])'
with
[
T=int
]
(1): note: or   'long f(int (*)[2],T (*)[2])'
with
[
T=int
]
(3): note: while trying to match the argument list '(int, int)'

[Bug fortran/108369] FM509 Fails to compile with error

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

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

--- Comment #6 from Jerry DeLisle  ---
Unbelievable! I found the folder in my test directory. The NIST test suite
passes as before with my test script using the latest gfortran trunk rev 13.

I do some comparisons way back with some example outputs in some of these
cases.  I will zip this up and send it to Ben and Steve.

I was actually surprised things still passed.

[Bug c++/108390] ICE in fold_convert_loc, at fold-const.cc:2504 partial ordering between array types

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-01-13
 Ever confirmed|0   |1
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=79092

--- Comment #2 from Andrew Pinski  ---
I suspect the patch for PR79092 cahnged the behavior in GCC 8.

I don't see how this can't be ambiguous. It is odd that clang accepts it.

This C++20 testcase also causes the ICE and clang rejects it as ambiguous:

```
template long f(int(*)[t], int(*)[t]);
template int f(int(*)[i], int(*)[i]);
int n = f<2>(0, 0);
```

So at least ICE on invalid.

[Bug fortran/108369] FM509 Fails to compile with error

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

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

--- Comment #7 from Jerry DeLisle  ---
Created attachment 54262
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54262&action=edit
Script used. may need to be adjusted for ones envoronment

[Bug fortran/108369] FM509 Fails to compile with error

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

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

--- Comment #8 from Jerry DeLisle  ---
Created attachment 54263
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54263&action=edit
Reference files used by script

[Bug fortran/108369] FM509 Fails to compile with error

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

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

--- Comment #9 from Jerry DeLisle  ---
The NIST files themselves are too large to attach here.

[Bug libgcc/108279] Improved speed for float128 routines

[already5chosen at yahoo dot com via Gcc-bugs]

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

--- Comment #8 from Michael_S  ---
(In reply to Thomas Koenig from comment #6)
> (In reply to Michael_S from comment #5)
> > Hi Thomas
> > Are you in or out?
> 
> Depends a bit on what exactly you want to do, and if there is
> a chance that what you want to do will be incorporated into gcc.
> 

What about incorporation in Fortran?
What about incorporation in C under fast-math ?

> If you want to replace the soft-float routines, you will have to
> replace them with the full functionality.
> 

Full functionality including Inexact Exception that practically nobody uses?
Sounds wasteful of perfectly good CPU cycles.
Also, I am not so sure that Inexact Exception is fully supported in  existing
soft-float library.

Almost-full functionality with support for non-default rounding modes, but
without Inexact Exception?
I actually implemented it and did few measurements. You can find the results in
the directory /reports in my repo.
Summary: architecture-neutral method cause very serious slowdown. Less so on
slower machines, massive 2.5x on the fastest machine (Zen3 under Linux under
WSL).
AMD64-specific method causes smaller slowdown, esp. on relatively old Intel
cores on Windows (I have no modern Intel cores available for testing). But
Zen3/Linux still suffer 1.45x slowdown. Again, a big wastage of perfectly good
CPU cycles.
Also, what about other architectures? Should they suffer an
"architecture-neutral" slowdown? Even if there are faster methods on other
architecture, these methods should be found by somebody and tested by somebody.
This sort of work is time-consuming. And for what?

Also I measured an impact of implementing non-default rounding through
additional function parameter. An impact is very small, 0  to 5%.
You said on comp.arch that at least for Fortran it could work.

What else is missing for "full functionality"? 
Surely there are other things that I forgot. May be, additional exceptions
apart from Invalid Operand (that hopefully already works) and apart from
Inexact that I find stupid? I don't think that they are hard to implement or
expensive in terms of speed. Just a bit of work and more than a bit of testing.

> And there will have to be a decision about 32-bit targets.
>

IMHO, 32-bit targets should be left in their current state.
People that use them probably do not care deeply about performance.
Technically, I can implement 32-bit targets in the same sources, by means of
few ifdefs and macros, but resulting source code will look much uglier than how
it looks today. Still, not to the same level of horror that you have in
matmul_r16.c, but certainly uglier than how I like it to look.
And I am not sure at all that my implementation of 32-bit targets would be
significantly faster than current soft float. 
In short, it does not sound as a good ROI.
BTW, do you know why current soft float supports so few 32-bit targets?
Most likely somebody felt just like me about it - it's not too hard to support
more 32-bit targets, but it's not a good ROI.

[Bug fortran/108369] FM509 Fails to compile with error

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #10 from Steve Kargl  ---
On Fri, Jan 13, 2023 at 01:09:22AM +, jvdelisle at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369
> 
> --- Comment #6 from Jerry DeLisle  ---
> Unbelievable! I found the folder in my test directory. The NIST test suite
> passes as before with my test script using the latest gfortran trunk rev 13.
> 
> I do some comparisons way back with some example outputs in some of these
> cases.  I will zip this up and send it to Ben and Steve.
> 
> I was actually surprised things still passed.
> 

Thanks Jerry.  I have NIST, but have only ever done compile
tests.  I've not tried to actually run all of the tests.

[Bug target/55522] -funsafe-math-optimizations is unexpectedly harmful, especially w/ -shared

[sam at gentoo dot org via Gcc-bugs]

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

--- Comment #33 from Sam James  ---
(In reply to Richard Biener from comment #32)
> Do other targets want to follow suite for GCC 13 here?

I think the deviation for x86 and !x86 as-is will lead to further confusion.