[Bug rtl-optimization/109035] meaningless memory store on RISC-V and LoongArch

[chenglulu at loongson dot cn via Gcc-bugs]

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

--- Comment #6 from chenglulu  ---
I tried changing the code,
diff --git a/gcc/lra-eliminations.cc b/gcc/lra-eliminations.cc
index 4220639..efaea6922b5 100644
--- a/gcc/lra-eliminations.cc
+++ b/gcc/lra-eliminations.cc
@@ -914,6 +914,11 @@ eliminate_regs_in_insn (rtx_insn *insn, bool replace_p,
bool first_p,
   /* First see if the source is of the form (plus (...) CST).  */
   if (plus_src && poly_int_rtx_p (XEXP (plus_src, 1), &offset))
plus_cst_src = plus_src;
+  else if (plus_src && ira_reg_equiv[REGNO (XEXP (plus_src, 1))].constant)
+   {
+ poly_int_rtx_p (ira_reg_equiv[REGNO (XEXP (plus_src, 1))].constant,
&offset);
+ plus_cst_src = gen_rtx_PLUS (GET_MODE (XEXP (plus_src, 0)),XEXP
(plus_src, 0), ira_reg_equiv[REGNO (XEXP (plus_src, 1))].constant);
+   }
   /* Check that the first operand of the PLUS is a hard reg or
 the lowpart subreg of one.  */
   if (plus_cst_src)

Redundant instructions can be eliminated, but I don't know if it can be
modified like this.

[Bug rtl-optimization/109035] meaningless memory store on RISC-V and LoongArch

[chenglulu at loongson dot cn via Gcc-bugs]

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

--- Comment #5 from chenglulu  ---
On AARCH64:
$cat t.c
int test(int x)
{
char buf[128 << 10];
return buf[x];
}
$cat t-1.c
int test(int x)
{
char buf[0xfff];
return buf[x];
}

The generated assemblies are as follows:

  t.s  | t-1.s
test:  |test:
.LFB0: |.LFB0:
.cfi_startproc |.cfi_startproc
sub sp, sp, #131072|mov x12, 16
.cfi_def_cfa_offset 131072 |mov x2, 16
ldrbw0, [sp, w0, sxtw] |movkx12, 0x1000, lsl 16
add sp, sp, 131072 |sub sp, sp, x12
.cfi_def_cfa_offset 0  |.cfi_def_cfa_offset 268435472
ret|movkx2, 0x1000, lsl 16
.cfi_endproc   |mov x1, -268435456
.LFE0: |add x1, x2, x1
.size   test, .-test   |add x1, sp, x1
   |str x1, [sp, 8]
   |ldrbw0, [x1, w0, sxtw]
   |add sp, sp, x12
   |.cfi_def_cfa_offset 0
   |ret

In my opinion, not only the instruction "str x1, [sp, 8]" is redundant in
t-1.s.
The following instructions are redundant:
"movk   x2, 0x1000, lsl 16
 movx1, -268435456
 addx1, x2, x1
 addx1, sp, x1
 strx1, [sp, 8]"

Comparing the intermediate results of the two test cases t.c t-1.c reload pass
optimization, I found the reason for these redundant instructions.
In t.c,
(insn 7 15 12 2 (set (reg/f:DI 96)
(plus:DI (reg/f:DI 64 sfp)
(const_int -131072 [0xfffe]))) "t-1.c":4:12 153
{*adddi3_aarch64}
 (expr_list:REG_EQUIV (plus:DI (reg/f:DI 64 sfp)
(const_int -131072 [0xfffe]))
(nil)))
It will be deleted after reload.

In t-1.c, the behavior of insn 7 in t.c is realized by two instructions
(insn 7 16 8 2 (set (reg:DI 97)
(const_int -268435456 [0xf000])) "t.c":4:12 65
{*movdi_aarch64}
 (expr_list:REG_EQUIV (const_int -268435456 [0xf000])
(nil)))
(insn 8 7 13 2 (set (reg:DI 96)
(plus:DI (reg/f:DI 64 sfp)
(reg:DI 97))) "t.c":4:12 153 {*adddi3_aarch64}
 (expr_list:REG_DEAD (reg:DI 97)
(expr_list:REG_EQUIV (plus:DI (reg/f:DI 64 sfp)
(const_int -268435456 [0xf000]))
(nil
Due to the problem of reload pass optimization, these two instructions are not
deleted, thus generating redundant instructions.

[Bug other/109103] New: Missing function internal_error_at

[roland.illig at gmx dot de via Gcc-bugs]

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

Bug ID: 109103
   Summary: Missing function internal_error_at
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

m2expr.c says:
> error_at (
> location,
> "internal error: not expecting operand1 to be a constant set");

This should rather be a call to internal_error_at, but that function does not
exist yet. For symmetry with the other error reporting functions, it should be
added.

[Bug modula2/109102] New: Wrong quotes in diagnostic

[roland.illig at gmx dot de via Gcc-bugs]

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

Bug ID: 109102
   Summary: Wrong quotes in diagnostic
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

m2builtins.cc says:
> %s:%d:assertion of condition `%s' failed

The backtick and single quote should be replaced with %< and %>, see
.

[Bug fortran/109101] New: Wrong quotes in OpenMP diagnostic

[roland.illig at gmx dot de via Gcc-bugs]

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

Bug ID: 109101
   Summary: Wrong quotes in OpenMP diagnostic
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

scanner.cc says:
> Ignoring '!$omx' vendor-extension sentinel at %C

The single quotes should be replaced with %< and %>,
see
.

[Bug target/109100] Possible typo CRS

[roland.illig at gmx dot de via Gcc-bugs]

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

--- Comment #1 from Roland Illig  ---
While here: In that same message, there is a single space between sentences 1
and 2, but 2 spaces between sentences 2 and 3.

While here: can not is usually spelled cannot.

[Bug target/109100] New: Possible typo CRS

[roland.illig at gmx dot de via Gcc-bugs]

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

Bug ID: 109100
   Summary: Possible typo CRS
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---
Target: riscv

riscv.opt says:
> Enable the CSR checking for the ISA-dependent CRS and the read-only CSR.

Is the CRS a typo and should be CSR?
As the German translator, I'm not familiar with either of these abbreviations,
that's why I'm asking.

[Bug tree-optimization/105135] [11/12/13 Regression] Optimization regression for handrolled branchless assignment since r11-4717-g3e190757fa332d32

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|target  |tree-optimization

--- Comment #7 from Andrew Pinski  ---
For aarch64 to_lower_1/to_lower_2 is better:

and w0, w0, 255
sub w1, w0, #65
and w1, w1, 255
cmp w1, 25
csetw1, ls
add w0, w0, w1, lsl 5
ret

vs
and w0, w0, 255
sub w2, w0, #65
add w1, w0, 32
and w2, w2, 255
and w1, w1, 255
cmp w2, 25
cselw0, w0, w1, hi
ret

[Bug target/105135] [11/12/13 Regression] Optimization regression for handrolled branchless assignment since r11-4717-g3e190757fa332d32

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

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

--- Comment #6 from Andrew Pinski  ---
If we change all char to "unsigned char", it is still different and for
to_lower_3 we get on the tree level:

  if (_1 <= 25)
goto ; [34.00%]
  else
goto ; [66.00%]

   [local count: 365072224]:
  _4 = c_3(D) + 32;

   [local count: 1073741824]:
  # _2 = PHI <_4(3), c_3(D)(2)>

There is another bug for the above which asks to transform this to:
  if (_1 <= 25)
goto ; [34.00%]
  else
goto ; [66.00%]

   [local count: 365072224]:
  _4 = 32;

   [local count: 1073741824]:
  # _t = PHI <_4(3), 0>
_2 = c_3(D) + _t;

Which then would get it similar to the other two ...

[Bug fortran/109099] New: Assignment in NAMELIST input does not fill in row-column order

[urbanjost at comcast dot net via Gcc-bugs]

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

Bug ID: 109099
   Summary: Assignment in NAMELIST input does not fill in
row-column order
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: urbanjost at comcast dot net
  Target Milestone: ---

program testit
integer, allocatable :: x(:,:); namelist / group / x
character(len=80) :: input(3)
   allocate( x(3,4),source=999)
   input=[&
   "&group  ",&
   " x(2,3)=1,2,3,4,",&
   "/   "]
   read( input, nml=group)
   write(*,group)
end program testit


gfortran 12.2 generating
 &GROUP X= 7*999 ,1 ,2 ,999 ,3 , 4 , /
should be
 &GROUP X = 7*999, 1, 2, 3, 4, 999 /

The values on the RHS are not stored in row-column order starting at the
specified address, instead they are stored in row-column order till the end of
the column and then continued at the same row as the address instead of the top
row. So if the row of the starting address is one it looks OK. They way I read
the description of NAMELIST group input it should just fill in a contigious
section of values (?)

[Bug tree-optimization/105532] [11 Regression] UBSAN: gcc/hwint.h:293:61: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int'

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||10.1.0, 12.1.0, 12.2.0
Summary|[11/12 Regression] UBSAN:   |[11 Regression] UBSAN:
   |gcc/hwint.h:293:61: runtime |gcc/hwint.h:293:61: runtime
   |error: shift exponent 64 is |error: shift exponent 64 is
   |too large for 64-bit type   |too large for 64-bit type
   |'long unsigned int' |'long unsigned int'
  Known to work||12.2.1

--- Comment #11 from Andrew Pinski  ---
Fixed for GCC 12.3.0 also.

[Bug tree-optimization/105532] [11/12 Regression] UBSAN: gcc/hwint.h:293:61: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int'

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

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

--- Comment #10 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Andrew Pinski
:

https://gcc.gnu.org/g:67608f7a2cf3eff99654ab3f44d5183049e3b36c

commit r12-9241-g67608f7a2cf3eff99654ab3f44d5183049e3b36c
Author: Andrew Pinski 
Date:   Wed Nov 2 15:56:31 2022 +

Fix PR 105532: match.pd patterns calling tree_nonzero_bits with vector
types

Even though this PR was reported with an ubsan issue, the problem is
tree_nonzero_bits is being called with an expression which is a vector
type.
This fixes three patterns I noticed which does that.
And adds a testcase for one of the patterns.

Committed after a bootstrapped and tested on x86_64-linux-gnu with no
regressions

gcc/ChangeLog:

PR tree-optimization/105532
* match.pd (~(X >> Y) -> ~X >> Y): Check if it is an integral
type before calling tree_nonzero_bits.
(popcount(X) + popcount(Y)): Likewise.
(popcount(X&C1)): Likewise.

gcc/testsuite/ChangeLog:

* gcc.c-torture/compile/vector-shift-1.c: New test.

(cherry picked from commit 193fccaa5c3525e979a989835c47c76d2c49d10c)

[Bug analyzer/109098] Encoding errors on SARIF output for non-UTF-8 source files

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

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||hp at gcc dot gnu.org

--- Comment #5 from Hans-Peter Nilsson  ---
While considering UTF-8 in SARIF files, please also have a look at PR105959.

[Bug analyzer/109098] Encoding errors on SARIF output for non-UTF-8 source files

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

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

--- Comment #4 from David Malcolm  ---
(In reply to Andrew Pinski from comment #2)
> So I think there is a bug in that code ...

The issue is in sarif_builder::maybe_make_artifact_content_object, which uses;

 char *text_utf8 = maybe_read_file (filename);

where there's no guarantee that "text_utf8" is (ahem) actually utf-8.  Sorry
about that.

Working on a fix to make it use the input.cc source-quoting machinery, which
should handle encoding.

[Bug analyzer/109098] Encoding errors on SARIF output for non-UTF-8 source files

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

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

--- Comment #3 from David Malcolm  ---
(In reply to Andrew Pinski from comment #1)
> I would have assumed you need -finput-charset= for the non-utf8 ones really
> if your LANG/LANGUAGE is not set to C/UTF8 really.

Yeah, but when complaining about encoding issues, the error message we emit
should at least be properly encoded :/

It's a major pain for my integration testing where two(?) bad bytes in one
source file lead to an unparseable .sarif file (out of thousands).

When quoting source in the .sarif output, we should ensure that the final JSON
output is all valid UTF-8, perhaps falling back to not quoting source for cases
where e.g.
- the source file isn't validly encoded, or
- the -finput-charset= is wrong, or   
- the -finput-charset= is missing or
- where the source file (erroneously) uses a mixture of different encodings in
different 
parts of itself

Probably should also check we do something sane for trojan source attacks

[Bug analyzer/109098] Encoding errors on SARIF output for non-UTF-8 source files

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

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

--- Comment #2 from Andrew Pinski  ---
https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Preprocessor-Options.html#index-finput-charset

Even has the following:

-finput-charset=charset
Set the input character set, used for translation from the character set of the
input file to the source character set used by GCC. If the locale does not
specify, or GCC cannot get this information from the locale, the default is
UTF-8. This can be overridden by either the locale or this command-line option.
Currently the command-line option takes precedence if there’s a conflict.
charset can be any encoding supported by the system’s iconv library routine.

So I think there is a bug in that code ...

[Bug analyzer/109098] Encoding errors on SARIF output for non-UTF-8 source files

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

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

--- Comment #1 from Andrew Pinski  ---
I would have assumed you need -finput-charset= for the non-utf8 ones really if
your LANG/LANGUAGE is not set to C/UTF8 really.

[Bug analyzer/109098] Encoding errors on SARIF output for non-UTF-8 source files

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

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

David Malcolm  changed:

   What|Removed |Added

   Last reconfirmed||2023-03-11
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

[Bug analyzer/109098] New: Encoding errors on SARIF output for non-UTF-8 source files

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

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

Bug ID: 109098
   Summary: Encoding errors on SARIF output for non-UTF-8 source
files
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

I've run into issues with -fanalyzer integration testing when a diagnostic
occurs in a source file with non-UTF-8 bytes in it.

Specifically, haproxy-2.7.1's include/import/ist.h has a comment within
function "istalloc" that isn't quite UTF-8.

When a diagnostic occurs on this, with  -fdiagnostics-format=sarif-file, the
file is quoted in the SARIF output, but the individual bytes are copied
directly into the JSON, leading to e.g.:

$ sarif ls integration-tests/haproxy-2.7.1/haproxy-2.7.1/http_client.c.sarif
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/sarif/loader.py", line 57, in
load_sarif_file
data = json.load(file_in)
  File "/usr/lib64/python3.8/json/__init__.py", line 293, in load
return loads(fp.read(),
  File "/usr/lib64/python3.8/codecs.py", line 322, in decode
(result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x80 in position 96006:
invalid start byte

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/local/bin/sarif", line 8, in 
sys.exit(main())
  File "/usr/local/lib/python3.8/site-packages/sarif/cmdline/main.py", line 40,
in main
exitcode = args.func(args)
  File "/usr/local/lib/python3.8/site-packages/sarif/cmdline/main.py", line
384, in _ls
ls_op.print_ls(args.files_or_dirs, args.output)
  File "/usr/local/lib/python3.8/site-packages/sarif/operations/ls_op.py", line
17, in print_ls
sarif_files = loader.load_sarif_files(path)
  File "/usr/local/lib/python3.8/site-packages/sarif/loader.py", line 30, in
load_sarif_files
path_exists = _add_path_to_sarif_file_set(path, ret)
  File "/usr/local/lib/python3.8/site-packages/sarif/loader.py", line 17, in
_add_path_to_sarif_file_set
sarif_file_set.add_file(load_sarif_file(path))
  File "/usr/local/lib/python3.8/site-packages/sarif/loader.py", line 60, in
load_sarif_file
raise IOError(f"Cannot load {file_path}") from exception
OSError: integration-tests/haproxy-2.7.1/haproxy-2.7.1/http_client.c.sarif

I'm working on a fix.

[Bug analyzer/109097] New: No SARIF output happens on an ICE

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

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

Bug ID: 109097
   Summary: No SARIF output happens on an ICE
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

If an ICE occurs inside cc1 with -fdiagnostics-format=sarif-file, then no
.sarif file is written out.

This is a nuisance e.g. for my integration testing of -fanalyzer, which I'm
gathering the results via the .sarif output; if it crashes on a particular
source file, then no output is generated, and it's effectively silent about the
crash.

I've been experimenting with adding SARIF output to the crash-handling code
(which I used to detect PR analyzer/109094); filing this bug to track this
work.

It's not clear how such crashes should be encoded in SARIF form; my prototype
emits them within the results array with with:
  ruleId": "internal compiler error"
but arguably as it's a failure of the analyzer rather than the
software-under-test such crashses should be captured as a SARIF 3.58
"notification" object.

Note to self: in one version of my prototypes there was an infinite loop where
a crash could happen in the crash-handling code, so need to be careful about
this.

[Bug libstdc++/109074] SIGABRT signal without using -lpthread at Linux RHEL 7.3

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

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

--- Comment #11 from Andrew Pinski  ---
(In reply to Murugesan Nagarajan from comment #10)
> (In reply to Murugesan Nagarajan from comment #9)
> > Thank you again. Reason for Porting this comment:
> > Libc Library having core dump issue.hence thought of sharing this bug at
> > Libc Library.
> 
> Hence sigabrt signal needs to be handler at libc.so.6 Library
> or this could have been fixed at other library. If so (like libc.so:))I need
> to know which version of that library fixed this issue.
> I'm not changing the status.

Again there is no fix to libc needed. The problem is you need to enable
threading and you are not doing that and you don't want to admit that is the
issue.

[Bug libstdc++/109074] SIGABRT signal without using -lpthread at Linux RHEL 7.3

[murugesandins at gmail dot com via Gcc-bugs]

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

--- Comment #10 from Murugesan Nagarajan  ---
(In reply to Murugesan Nagarajan from comment #9)
> Thank you again. Reason for Porting this comment:
> Libc Library having core dump issue.hence thought of sharing this bug at
> Libc Library.

Hence sigabrt signal needs to be handler at libc.so.6 Library
or this could have been fixed at other library. If so (like libc.so:))I need to
know which version of that library fixed this issue.
I'm not changing the status.

[Bug c++/109096] __has_unique_object_representations does not account for unnamed bitfield

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug c++/109096] __has_unique_object_representations does not account for unnamed bitfield

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-03-10
 Ever confirmed|0   |1
   Keywords||wrong-code
 Status|UNCONFIRMED |NEW

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

[Bug c++/109095] ICE when specializing a template with an auto nontype template template parameter

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-03-10
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

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

[Bug c++/109096] __has_unique_object_representations does not account for unnamed bitfield

[gcc at jonathanmueller dot dev via Gcc-bugs]

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

--- Comment #1 from Jonathan Müller  ---
Sorry, wrong godbolt link: https://godbolt.org/z/f1fGExsr7

[Bug tree-optimization/108684] [12 Regression] ICE: verify_ssa failed

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #16 from Andrew Pinski  ---
Fixed.

[Bug tree-optimization/108684] [12 Regression] ICE: verify_ssa failed

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

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

--- Comment #15 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Andrew Pinski
:

https://gcc.gnu.org/g:657e1e89d34b114ca47fe1f2c5366927c5850af7

commit r12-9239-g657e1e89d34b114ca47fe1f2c5366927c5850af7
Author: Andrew Pinski 
Date:   Tue Feb 7 23:09:40 2023 +

tree-optimization: [PR108684] ICE in verify_ssa due to
simple_dce_from_worklist

In simple_dce_from_worklist, we were removing an inline-asm which had a
vdef.
We should not be removing inline-asm which have a vdef as this code
does not check to the store.
This fixes that oversight. This was a latent bug exposed recently
by both VRP and removal of stores to static starting to use
simple_dce_from_worklist.

Backported after bootstrapped and tested on x86_64-linux-gnu with no
regressions.

PR tree-optimization/108684

gcc/ChangeLog:

* tree-ssa-dce.cc (simple_dce_from_worklist):
Check all ssa names and not just non-vdef ones
before accepting the inline-asm.
Call unlink_stmt_vdef on the statement before
removing it.

gcc/testsuite/ChangeLog:

* gcc.c-torture/compile/dce-inline-asm-1.c: New test.
* gcc.c-torture/compile/dce-inline-asm-2.c: New test.
* gcc.dg/tree-ssa/pr108684-1.c: New test.

co-authored-by: Andrew Macleod  
(cherry picked from commit 6a5cb782d1486b378d70857c8efae558da0eb2cc)

[Bug c++/109096] New: __has_unique_object_representations does not account for unnamed bitfield

[gcc at jonathanmueller dot dev via Gcc-bugs]

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

Bug ID: 109096
   Summary: __has_unique_object_representations does not account
for unnamed bitfield
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at jonathanmueller dot dev
  Target Milestone: ---

__has_unique_object_representations should return false for types that contain
an unnamed bit field of non-zero bit-width, since that introduces padding bits;
yet it doesn't:

```
#include 
#include 

struct foo
{
int member : 8;
// We explitly introduce 24 padding bits here.
int : 24;

bool operator==(const foo&) const = default;
};

// Yet this assertion passes?!
static_assert(__has_unique_object_representations(foo));

// But we clearly don't have unique object representations:
int main()
{
// Create two objects with different object representations.
foo a, b;
std::memset(&a, 0xFF, sizeof(foo));
std::memset(&b, 0x99, sizeof(foo));

// Make all members identical to give them the same value representation.
a.member = 0;
b.member = 0;
// This passes; they have the same value representation.
assert(a == b);

// But this fails; they don't have unique object representations!
assert(std::memcmp(&a, &b, sizeof(foo)) == 0);
}
```

https://godbolt.org/z/Y4GzqYE8s

[Bug libstdc++/109074] SIGABRT signal without using -lpthread at Linux RHEL 7.3

[murugesandins at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Murugesan Nagarajan  ---
Thank you again. Reason for Porting this comment:
Libc Library having core dump issue.hence thought of sharing this bug at Libc
Library.

[Bug fortran/106945] [10/11/12/13 Regression] ICE: 'verify_gimple' failed

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #4 from anlauf at gcc dot gnu.org ---
As there is no ICE with -fcheck=bounds -fwrapv but with -fcheck=bounds -ftrapv,
there might be a wrapping issue with the bounds checking code.

Difference of the dump-trees:

--- pr106945-z1.f90.005t.original.wrapv 2023-03-10 22:15:44.992525716 +0100
+++ pr106945-z1.f90.005t.original.trapv 2023-03-10 22:15:24.892582362 +0100
@@ -268,7 +268,7 @@
 D.4395 = (unsigned long) src->a._vptr->_size;
 D.4396 = (unsigned long) src->a._len;
 D.4397 = D.4396 != 0 ? D.4395 * D.4396 : D.4395;
-if (src->a._data.dim[0].ubound != src->a._data.dim[0].lbound)
+if ((src->a._data.dim[0].ubound - src->a._data.dim[0].lbound) + 1
!= 1)
   {
 _gfortran_runtime_error_at (&"At line 9 of file
pr106945-z1.f90"[1]{lb: 1 sz: 1}, &"Array bound mismatch for dimension 1 of
array \'<>\' (%ld/%ld)"[1]{lb: 1 sz: 1}, 1, MAX_EXPR
<(src->a._data.dim[0].ubound - src->a._data.dim[0].lbound) + 1, 0>);
   }


I am having difficulties to understand the code generated for -ftrapv.

[Bug c++/109095] New: ICE when specializing a template with an auto nontype template template parameter

[n.morales.0 at proton dot me via Gcc-bugs]

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

Bug ID: 109095
   Summary: ICE when specializing a template with an auto nontype
template template parameter
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: n.morales.0 at proton dot me
  Target Milestone: ---

This ICE is present in gcc 12.1/2 and in trunk:

template< typename T >
struct bar
{};

template< int X >
struct baz
{};

template< auto N, template< auto N2 > typename TT >
struct foo;

template< typename T, bar< T > B, template< T N2 > typename TT >
struct foo< B, TT >
{};

foo< bar< int >{}, baz > x;


This code ICE's with the following message when compiled with
-std=c++20 -Werror -Wall -Wextra

:13:19: internal compiler error: in tsubst, at cp/pt.cc:15867
   13 | struct foo< B, TT >
  |   ^
0x1bb069e internal_error(char const*, ...)
???:0
0x6ff396 fancy_abort(char const*, int, char const*)
???:0
0x884007 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
???:0
0x8aa461 finish_template_type(tree_node*, tree_node*, int)
???:0
0x861eaa c_parse_file()
???:0
0x93e4e5 c_common_parse_file()
???:0

I found a workaround to the ICE by making N2 "auto" instead of "T". Also, this
code compiles fine on clang 15.

Here is a godbolt link: https://godbolt.org/z/vxxeG36Gz

[Bug target/104039] [10/11 Regression] AArch64 Redundant instruction moving general to vector register

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[10/11/12/13 Regression]|[10/11 Regression] AArch64
   |AArch64 Redundant   |Redundant instruction
   |instruction moving general  |moving general to vector
   |to vector register  |register
 Status|NEW |RESOLVED
  Known to work||12.1.0, 13.0
   Target Milestone|10.5|12.0
 Resolution|--- |FIXED

--- Comment #6 from Andrew Pinski  ---
Fixed for GCC 12.

[Bug target/109093] [13 regression] csmith: a February runtime bug ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #4 from David Binderman  ---
Created attachment 54639
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54639&action=edit
C source code

A third example that fails at the same git hash.

[Bug target/109093] [13 regression] csmith: a February runtime bug ?

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
Summary|csmith: a February runtime  |[13 regression] csmith: a
   |bug ?   |February runtime bug ?
   Keywords||needs-reduction

[Bug target/109093] csmith: a February runtime bug ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #3 from David Binderman  ---
Created attachment 54638
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54638&action=edit
C source code

This C code seems to fail in the same way. Possible duplicate.

[Bug c/16186] gcc should have an option to warn about enumerations with duplicate values

[trashyankes at wp dot pl via Gcc-bugs]

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

trashyankes at wp dot pl changed:

   What|Removed |Added

 CC||trashyankes at wp dot pl

--- Comment #7 from trashyankes at wp dot pl ---
Should be way to disable/enable this warning per `enum`?
Like:

```
enum [[gnu::enum_unique]] X
{
  I = 1,
  J = 2,
};

enum [[gnu::enum_not_unique]] Y
{
  K = 1,
  L = 1,
};

```

[Bug analyzer/109094] [13 Regression] ICE in -fanalyzer seen in qemu's target/i386/tcg/translate.c

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

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

--- Comment #1 from David Malcolm  ---
Created attachment 54637
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54637&action=edit
Unreduced reproducer

[Bug target/109093] csmith: a February runtime bug ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||jakub at redhat dot com

--- Comment #2 from David Binderman  ---
As expected:

$ git bisect bad 866555b170016c49
866555b170016c49beb869a78cbecdeb07c63135 is the first bad commit
commit 866555b170016c49beb869a78cbecdeb07c63135
Author: Jakub Jelinek 
Date:   Thu Feb 16 15:35:05 2023 +0100

tree-ssa-dse: Fix up handling of lhs of internal calls [PR108657]

[Bug analyzer/109094] New: [13 Regression] ICE in -fanalyzer seen in qemu's target/i386/tcg/translate.c

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

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

Bug ID: 109094
   Summary: [13 Regression] ICE in -fanalyzer seen in qemu's
target/i386/tcg/translate.c
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Trunk ICEs on the attached:

$ ./xgcc -B. -fanalyzer  -S ../../src/target_i386_tcg_translate.c \
  -Wall -Wno-array-parameter -Wno-unused-function -Wno-unused-variable

/home/david/more-coding/gcc-newgit-analyzer-dsl/src/target_i386_tcg_translate.c:48985:29:
internal compiler error: in get_region_for_local, at analyzer/region.cc:920
48985 |   if (s->base.num_insns > 1 && !is_same_page(&s->base, s->pc +
num_bytes - 1)) {
  |  
~~^
0x1af2cb3 ana::frame_region::get_region_for_local(ana::region_model_manager*,
tree_node*, ana::region_model_context const*) const
../../src/gcc/analyzer/region.cc:920
0x1afc3f8 ana::region_model::get_lvalue_1(ana::path_var,
ana::region_model_context*) const
../../src/gcc/analyzer/region-model.cc:2101
0x1afc5c7 ana::region_model::get_lvalue(ana::path_var,
ana::region_model_context*) const
../../src/gcc/analyzer/region-model.cc:2153
0x1afcac1 ana::region_model::get_rvalue_1(ana::path_var,
ana::region_model_context*) const
../../src/gcc/analyzer/region-model.cc:2219
0x1afcf08 ana::region_model::get_rvalue(ana::path_var,
ana::region_model_context*) const
../../src/gcc/analyzer/region-model.cc:2297
0x1afcfc7 ana::region_model::get_rvalue(tree_node*, ana::region_model_context*)
const
../../src/gcc/analyzer/region-model.cc:2312
0x1b172ac
ana::poisoned_value_diagnostic::check_valid_fpath_p(ana::feasible_node const&,
gimple const*) const
../../src/gcc/analyzer/region-model.cc:596
0x2f1f2d7 ana::epath_finder::process_worklist_item(ana::feasible_worklist*,
ana::trimmed_graph const&, ana::feasible_graph*, ana::exploded_node const*,
gimple const*, ana::pending_diagnostic const&, unsigned int,
std::unique_ptr >*)
const
../../src/gcc/analyzer/diagnostic-manager.cc:538
0x2f1ee71 ana::epath_finder::explore_feasible_paths(ana::exploded_node const*,
gimple const*, ana::pending_diagnostic const&, char const*, unsigned int)
../../src/gcc/analyzer/diagnostic-manager.cc:434
0x2f1e9d8 ana::epath_finder::get_best_epath(ana::exploded_node const*, gimple
const*, ana::pending_diagnostic const&, char const*, unsigned int,
std::unique_ptr >*)
../../src/gcc/analyzer/diagnostic-manager.cc:175
0x2f201fa ana::saved_diagnostic::calc_best_epath(ana::epath_finder*)
../../src/gcc/analyzer/diagnostic-manager.cc:839
0x2f2541d ana::dedupe_winners::add(ana::logger*, ana::epath_finder*,
ana::saved_diagnostic*)
../../src/gcc/analyzer/diagnostic-manager.cc:1207
0x2f20d21 ana::diagnostic_manager::emit_saved_diagnostics(ana::exploded_graph
const&)
../../src/gcc/analyzer/diagnostic-manager.cc:1357
0x1aa1816 ana::impl_run_checkers(ana::logger*)
../../src/gcc/analyzer/engine.cc:6139
0x1aa1b70 ana::run_checkers()
../../src/gcc/analyzer/engine.cc:6213
0x1a9404a execute
../../src/gcc/analyzer/analyzer-pass.cc:87
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.

Unfortunately it takes about 12 minutes to ICE.

Haven't yet tested with earlier versions.

[Bug tree-optimization/103725] [10/11/12/13 Regression] warning: assuming signed overflow does not occur when simplifying conditional to constant

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #6 from Andrew Pinski  ---
Seems to be fixed on the trunk 

[Bug target/107703] TImode to __bf16 conversions and __bf16 to TImode conversions aren't implemented in libgcc

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Resolution|--- |FIXED

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

[Bug c++/107558] [10/11/12 Regression] ICE in fld_incomplete_type_of with -fmerge-all-constants and openmp and LTO since r11-16-ga2f32550a085984f

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Status|NEW |ASSIGNED
Summary|[10/11/12/13 Regression]|[10/11/12 Regression] ICE
   |ICE in  |in fld_incomplete_type_of
   |fld_incomplete_type_of with |with -fmerge-all-constants
   |-fmerge-all-constants and   |and openmp and LTO since
   |openmp and LTO since|r11-16-ga2f32550a085984f
   |r11-16-ga2f32550a085984f|

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

[Bug c++/109039] [12 Regression] Miscompilation with no_unique_address and bitfields

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[12/13 Regression]  |[12 Regression]
   |Miscompilation with |Miscompilation with
   |no_unique_address and   |no_unique_address and
   |bitfields   |bitfields

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

[Bug target/107703] TImode to __bf16 conversions and __bf16 to TImode conversions aren't implemented in libgcc

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

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

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

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

commit r13-6599-gc227508d06a63f9b8fede3fd88813accb447060e
Author: Jakub Jelinek 
Date:   Fri Mar 10 20:43:58 2023 +0100

c++ testsuite: Add test for PR107703

This is on top of the
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606398.html
and
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613724.html
patches (to be precise, the latter isn't essential for it), I've
realized that for the PR107703 bugfix in the first patch I haven't
added some test coverage that the extended floating vs. integral
or vice versa conversions work correctly.

This new testcase adds such checks.  And when writing it I've
found that in ext-floating.h header in the testsuite I forgot back
in November to remove #undef __STDCPP_BFLOAT16_T__ which was left
there because the bfloat16 support wasn't in yet.

The new testcase (and all older ext-floating*.C tests too) passes
on vanilla trunk without the ext-floating.h change (x86_64-linux
-m32/-m64) and with the PR107703 fix also with the ext-floating.h
change.

2023-03-10  Jakub Jelinek  

PR target/107703
* g++.dg/cpp23/ext-floating.h (__STDCPP_BFLOAT16_T__): Don't
undefine
it.
(std::bfloat16_t): Use decltype (0.0bf16) like libstdc++, rather
than
__bf16.
* g++.dg/cpp23/ext-floating14.C: New test.

[Bug target/107703] TImode to __bf16 conversions and __bf16 to TImode conversions aren't implemented in libgcc

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

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

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

https://gcc.gnu.org/g:246127ab238bac6aa71a9b4ee1f6fabf776b5ccb

commit r13-6598-g246127ab238bac6aa71a9b4ee1f6fabf776b5ccb
Author: Jakub Jelinek 
Date:   Fri Mar 10 20:39:54 2023 +0100

libgcc, i386: Add __fix{,uns}bfti and __float{,un}tibf [PR107703]

While DI <-> BF conversions can be handled (and are) through
DI <-> XF <-> BF and for narrower integral modes even sometimes
through DF or SF, because XFmode has 64-bit mantissa and so all
the DImode values are exactly representable in XFmode.
That is not the case for TImode, and while e.g. the HF -> TI
conversions are IMHO useless in libgcc, because HFmode has
-65504.0f16, 65504.0f16 range, all the integers will be already
representable in SImode (or even HImode for unsigned) and so
I think HF -> DI -> TI conversions are faster and valid,
BFmode has roughly the same range as SFmode and so we absolutely need
the TI -> BF conversions to avoid double rounding.

As for BF -> TI conversions, they can be either also implemented
in libgcc, or they can be implemented (as done in this commit)
as BF -> SF -> TI conversions with the same code generation used
elsewhere, just doing the 16-bit left shift of the bits - I think
we don't need to handle sNaNs during the BF -> SF part because
SF -> TI (which is already a libcall too) will handle that too.

The BF -> SF -> TI path avoids wasting
32: 00015e10   321 FUNCGLOBAL DEFAULT   13
__fixbfti@@GCC_13.0.0
89: 00015f60   299 FUNCGLOBAL DEFAULT   13
__fixunsbfti@@GCC_13.0.0

2023-03-10  Jakub Jelinek  

PR target/107703
* optabs.cc (expand_fix): For conversions from BFmode to integral,
use shifts to convert it to SFmode first and then convert SFmode
to integral.

* soft-fp/floattibf.c: New file.
* soft-fp/floatuntibf.c: New file.
* config/i386/libgcc-glibc.ver: Export __float{,un}tibf @
GCC_13.0.0.
* config/i386/64/t-softfp (softfp_extras): Add floattibf and
floatuntibf.
(CFLAGS-floattibf.c, CFLAGS-floatunstibf.c): Add -msse2.

[Bug c++/107558] [10/11/12/13 Regression] ICE in fld_incomplete_type_of with -fmerge-all-constants and openmp and LTO since r11-16-ga2f32550a085984f

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

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

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

https://gcc.gnu.org/g:60b6f5c0a334db3f8f6dffaf0b9aab42fd5c54a2

commit r13-6597-g60b6f5c0a334db3f8f6dffaf0b9aab42fd5c54a2
Author: Jakub Jelinek 
Date:   Fri Mar 10 20:38:13 2023 +0100

c++: Don't clear TREE_READONLY for -fmerge-all-constants for non-aggregates
[PR107558]

The following testcase ICEs, because OpenMP lowering for shared clause
on l variable with REFERENCE_TYPE creates POINTER_TYPE to REFERENCE_TYPE.
The reason is that the automatic variable has non-trivial construction
(reference to a lambda) and -fmerge-all-constants is on and so
TREE_READONLY
isn't set - omp-low will handle automatic TREE_READONLY vars in shared
specially and only copy to the construct and not back, while !TREE_READONLY
are assumed to be changeable.
The PR91529 change rationale was that the gimplification can change
some non-addressable automatic variables to TREE_STATIC with
-fmerge-all-constants and therefore TREE_READONLY on them is undesirable.
But, the gimplifier does that only for aggregate variables:
  switch (TREE_CODE (type))
{
case RECORD_TYPE:
case UNION_TYPE:
case QUAL_UNION_TYPE:
case ARRAY_TYPE:
and not for anything else.  So, I think clearing TREE_READONLY for
automatic integral or reference or pointer etc. vars for
-fmerge-all-constants only is unnecessary.

2023-03-10  Jakub Jelinek  

PR c++/107558
* decl.cc (cp_finish_decl): Don't clear TREE_READONLY on
automatic non-aggregate variables just because of
-fmerge-all-constants.

* g++.dg/gomp/pr107558.C: New test.

[Bug c++/109039] [12/13 Regression] Miscompilation with no_unique_address and bitfields

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

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

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

https://gcc.gnu.org/g:991f9eb2da3a268b7b08346761fa0078ab55f506

commit r13-6596-g991f9eb2da3a268b7b08346761fa0078ab55f506
Author: Jakub Jelinek 
Date:   Fri Mar 10 20:36:33 2023 +0100

c++, abi: Fix up class layout with bitfields [PR109039]

The following testcase FAILs, because starting with r12-6028
the S class has only 2 bytes, not enough to hold one 7-bit bitfield, one
8-bit
bitfield and one 8-bit char field.

The reason is that when end_of_class attempts to compute dsize, it simply
adds byte_position of the field and DECL_SIZE_UNIT (and uses maximum from
those offsets).
The problematic bit-field in question has bit_position 7, byte_position 0,
DECL_SIZE 8 and DECL_SIZE_UNIT 1.  So, byte_position + DECL_SIZE_UNIT is
1, even when the bitfield only has a single bit in the first byte and 7
further bits in the second byte, so per the Itanium ABI it should be 2:
"In either case, update dsize(C) to include the last byte
containing (part of) the bit-field, and update sizeof(C) to
max(sizeof(C),dsize(C))."

The following patch fixes it by computing bitsize of the end and using
CEIL_DIV_EXPR division to round it to next byte boundary and convert
from bits to bytes.

While this is an ABI change, classes with such incorrect layout couldn't
have worked properly, so I doubt anybody is actually running it often
in the wild.  Thus I think adding some ABI warning for it is unnecessary.

2023-03-10  Jakub Jelinek  

PR c++/109039
* class.cc (end_of_class): For bit-fields, instead of computing
offset as sum of byte_position (field) and DECL_SIZE_UNIT (field),
compute it as sum of bit_position (field) and DECL_SIZE (field)
divided by BITS_PER_UNIT rounded up.

* g++.dg/abi/no_unique_address7.C: New test.

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

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   Target Milestone|10.5|13.0
 Resolution|--- |FIXED

--- Comment #31 from Andrew Pinski  ---
Fixed in GCC 13. I don't mind this not being fixed on other branches.

[Bug c++/108179] [11/12/13 regression] ICE related to template template parameters in tsubst, at cp/pt.cc:15782

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/109093] csmith: a February runtime bug ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
Current git range is g:7478278f88ba1753 .. g:fea34ee491104f32

This is 7 commits. 6 of them seem to be libstdc++ and then there is
this one:

commit 866555b170016c49beb869a78cbecdeb07c63135
Author: Jakub Jelinek 
Date:   Thu Feb 16 15:35:05 2023 +0100

tree-ssa-dse: Fix up handling of lhs of internal calls [PR108657]

This is the current hot candidate.

[Bug c++/108972] [13 Regression] ICE: tree check: expected tree that contains 'decl common' structure, have 'error_mark' in compare_lambda_template_head, at cp/lambda.cc:1551 since r13-3601-g2b0e81d5c

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  ---
Fixed.

[Bug c++/108972] [13 Regression] ICE: tree check: expected tree that contains 'decl common' structure, have 'error_mark' in compare_lambda_template_head, at cp/lambda.cc:1551 since r13-3601-g2b0e81d5c

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

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

--- Comment #3 from CVS Commits  ---
The trunk branch has been updated by Jason Merrill :

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

commit r13-6594-ga915c29a7d63ccb88cfded75ba1c8c4919845e98
Author: Jason Merrill 
Date:   Thu Mar 9 17:01:48 2023 -0500

c++: constrained lambda error-recovery [PR108972]

Better not to ICE after various valid errors.

PR c++/108972

gcc/cp/ChangeLog:

* lambda.cc (compare_lambda_template_head): Check more
for error_mark_node.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-lambda3.C: Run at lower std levels,
but expect errors.

[Bug sanitizer/108060] [10/11/12 Regression] UBsan missed an out-of-bound bug at -O0 since r7-1900-g8a1b7b7fd75a3847

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

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[10/11/12/13 Regression]|[10/11/12 Regression] UBsan
   |UBsan missed an |missed an out-of-bound bug
   |out-of-bound bug at -O0 |at -O0 since
   |since   |r7-1900-g8a1b7b7fd75a3847
   |r7-1900-g8a1b7b7fd75a3847   |

--- Comment #9 from Marek Polacek  ---
Fixed on trunk so far.

[Bug sanitizer/109050] UBsan failed to detect out-of-bound at -O0/1/2/s

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

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

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

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

commit r13-6593-g4d0baeae315ebe7d0ec7682ea3e7c0516027c2b8
Author: Marek Polacek 
Date:   Wed Mar 8 09:15:07 2023 -0500

ubsan: missed -fsanitize=bounds for compound ops [PR108060]

In this PR we are dealing with a missing .UBSAN_BOUNDS, so the
out-of-bounds access in the test makes the program crash before
a UBSan diagnostic was emitted.  In C and C++, c_genericize gets

  a[b] = a[b] | c;

but in C, both a[b] are one identical shared tree (not in C++ because
cp_fold/ARRAY_REF created two same but not identical trees).  Since
ubsan_walk_array_refs_r keeps a pset, in C we produce

  a[.UBSAN_BOUNDS (0B, SAVE_EXPR , 8);, SAVE_EXPR ;] = a[b] | c;

because the LHS is walked before the RHS.

Since r7-1900, we gimplify the RHS before the LHS.  So the statement above
gets gimplified into

_1 = a[b];
c.0_2 = c;
b.1 = b;
.UBSAN_BOUNDS (0B, b.1, 8);

With this patch we produce:

  a[b] = a[.UBSAN_BOUNDS (0B, SAVE_EXPR , 8);, SAVE_EXPR ;] | c;

which gets gimplified into:

b.0 = b;
.UBSAN_BOUNDS (0B, b.0, 8);
_1 = a[b.0];

therefore we emit a runtime error before making the bad array access.

I think it's OK that only the RHS gets a .UBSAN_BOUNDS, as in few lines
above: the instrumented array access dominates the array access on the
LHS, and I've verified that

  b = 0;
  a[b] = (a[b], b = -32768, a[0] | c);

works as expected: the inner a[b] is OK but we do emit an error for the
a[b] on the LHS.

For GCC 14, we could apply

since the copy_node doesn't seem to be needed.

PR sanitizer/108060
PR sanitizer/109050

gcc/c-family/ChangeLog:

* c-gimplify.cc (ubsan_walk_array_refs_r): For a MODIFY_EXPR,
instrument
the RHS before the LHS.

gcc/testsuite/ChangeLog:

* c-c++-common/ubsan/bounds-17.c: New test.
* c-c++-common/ubsan/bounds-18.c: New test.
* c-c++-common/ubsan/bounds-19.c: New test.
* c-c++-common/ubsan/bounds-20.c: New test.
* c-c++-common/ubsan/bounds-21.c: New test.

[Bug sanitizer/108060] [10/11/12/13 Regression] UBsan missed an out-of-bound bug at -O0 since r7-1900-g8a1b7b7fd75a3847

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

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

--- Comment #8 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

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

commit r13-6593-g4d0baeae315ebe7d0ec7682ea3e7c0516027c2b8
Author: Marek Polacek 
Date:   Wed Mar 8 09:15:07 2023 -0500

ubsan: missed -fsanitize=bounds for compound ops [PR108060]

In this PR we are dealing with a missing .UBSAN_BOUNDS, so the
out-of-bounds access in the test makes the program crash before
a UBSan diagnostic was emitted.  In C and C++, c_genericize gets

  a[b] = a[b] | c;

but in C, both a[b] are one identical shared tree (not in C++ because
cp_fold/ARRAY_REF created two same but not identical trees).  Since
ubsan_walk_array_refs_r keeps a pset, in C we produce

  a[.UBSAN_BOUNDS (0B, SAVE_EXPR , 8);, SAVE_EXPR ;] = a[b] | c;

because the LHS is walked before the RHS.

Since r7-1900, we gimplify the RHS before the LHS.  So the statement above
gets gimplified into

_1 = a[b];
c.0_2 = c;
b.1 = b;
.UBSAN_BOUNDS (0B, b.1, 8);

With this patch we produce:

  a[b] = a[.UBSAN_BOUNDS (0B, SAVE_EXPR , 8);, SAVE_EXPR ;] | c;

which gets gimplified into:

b.0 = b;
.UBSAN_BOUNDS (0B, b.0, 8);
_1 = a[b.0];

therefore we emit a runtime error before making the bad array access.

I think it's OK that only the RHS gets a .UBSAN_BOUNDS, as in few lines
above: the instrumented array access dominates the array access on the
LHS, and I've verified that

  b = 0;
  a[b] = (a[b], b = -32768, a[0] | c);

works as expected: the inner a[b] is OK but we do emit an error for the
a[b] on the LHS.

For GCC 14, we could apply

since the copy_node doesn't seem to be needed.

PR sanitizer/108060
PR sanitizer/109050

gcc/c-family/ChangeLog:

* c-gimplify.cc (ubsan_walk_array_refs_r): For a MODIFY_EXPR,
instrument
the RHS before the LHS.

gcc/testsuite/ChangeLog:

* c-c++-common/ubsan/bounds-17.c: New test.
* c-c++-common/ubsan/bounds-18.c: New test.
* c-c++-common/ubsan/bounds-19.c: New test.
* c-c++-common/ubsan/bounds-20.c: New test.
* c-c++-common/ubsan/bounds-21.c: New test.

[Bug libstdc++/108882] [13 Regression] Wrong symver on 4 new libstdc++ symbols on ppc64le

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

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

[Bug fortran/104332] [10/11/12/13 Regression] ICE in resolve_symbol, at fortran/resolve.cc:15815

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

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

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

commit r13-6592-ge20e5d9dc11b64e8eabce6803c91cb5768207083
Author: Harald Anlauf 
Date:   Thu Mar 9 18:59:08 2023 +0100

Fortran: fix ICE with bind(c) in block data [PR104332]

gcc/fortran/ChangeLog:

PR fortran/104332
* resolve.cc (resolve_symbol): Avoid NULL pointer dereference while
checking a symbol with the BIND(C) attribute.

gcc/testsuite/ChangeLog:

PR fortran/104332
* gfortran.dg/bind_c_usage_34.f90: New test.

[Bug target/108938] Missing bswap detection

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

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

Bug 108874 Summary: [10/11/12/13 Regression] Missing bswap detection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108874

   What|Removed |Added

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

[Bug target/108933] [10/11/12/13 Regression] Missing bswap detection

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

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

Bug 108874 Summary: [10/11/12/13 Regression] Missing bswap detection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108874

   What|Removed |Added

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

[Bug target/108874] [10/11/12/13 Regression] Missing bswap detection

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #14 from Andrew Pinski  ---
Fixed on the trunk, this can be backported if anyone wants to do that testing
but since it took over 5 years to notice it because there was no testcase for
it, I am not going to do the backporting.

[Bug tree-optimization/94094] [meta-bug] store-merging and/or bswap load/store-merging missed optimizations

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

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

Bug 108874 Summary: [10/11/12/13 Regression] Missing bswap detection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108874

   What|Removed |Added

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

[Bug target/108874] [10/11/12/13 Regression] Missing bswap detection

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

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

--- Comment #13 from CVS Commits  ---
The trunk branch has been updated by Andrew Pinski :

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

commit r13-6591-gfcbc5c190c40b51c82f827830ce403c07d628960
Author: Andrew Pinski 
Date:   Fri Mar 10 00:53:39 2023 +

Fix PR 108874: aarch64 code regression with shift and ands

After r6-2044-g98e30e515f184b, code like "((x & 0xff00ff00U) >> 8)"
would be optimized like (x >> 8) & 0xff00ffU which is normally better
except on aarch64, the shift right could be combined with another
operation in some cases. So we need to add a few define_splits
to the aarch64 backends that match "((x >> shift) & CST0) OP Y"
and splits it to:
TMP = X & CST1
(TMP >> shift) OP Y

Note this also gets us to matching rev16 back too so I added a
testcase to make sure we don't lose that matching any more.
Note when the generic patch to recognize those as bswap ROT 16,
we might regress again and need to add a few more patterns to
the aarch64 backend but will deal with that once that happens.

Committed as approved after a bootstrapp/test on aarch64-linux-gnu with no
regressions.

gcc/ChangeLog:

* config/aarch64/aarch64.md: Add a new define_split
to help combine.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/rev16_2.c: New test.
* gcc.target/aarch64/shift_and_operator-1.c: New test.

[Bug target/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1 since r13-2706-g6e80a1d164d1f9

[tstellar at redhat dot com via Gcc-bugs]

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

--- Comment #16 from Tom Stellard  ---
I looked into this a little more, and I think the s390x failures may be an LLVM
bug.  It's trying to JIT an X86 ELF file on s390x, and I think maybe the layout
of the frames is different due to endianness.

I'm still not sure what's going on with the aarch64 failure, though.

[Bug target/109092] [13 Regression] ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1932 when building libgcc on riscv64

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-03-10
   Target Milestone|--- |13.0
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
(define_insn "*movsi_internal"
  [(set (match_operand:SI 0 "nonimmediate_operand" "=r,r,r, m,  *f,*f,*r,*m,r")
(match_operand:SI 1 "move_operand" "
r,T,m,rJ,*r*J,*m,*f,*f,vp"))]
  "(register_operand (operands[0], SImode)
|| reg_or_0_operand (operands[1], SImode))
&& !(register_operand (operands[1], SImode)
 && REGNO (operands[1]) == VL_REGNUM)"
  { return riscv_output_move (operands[0], operands[1]); }
  [(set_attr "move_type"
"move,const,load,store,mtc,fpload,mfc,fpstore,rdvlenb")
   (set_attr "mode" "SI")
   (set_attr "ext" "base,base,base,base,f,f,f,f,vector")])


The issue is register_operand accepts subreg but then REGNO is checked on it.
That is obviously wrong. It should be "REG_P (operands[1]) && REGNO
(operands[1]) == VL_REGNUM" instead ...

[Bug c/109093] New: csmith: a February runtime bug ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 109093
   Summary: csmith: a February runtime bug ?
   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 54636
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54636&action=edit
C source code

For the attached C code, compiled by recent gcc and flags -O3 -march=znver1 
-fno-strict-aliasing -ftrivial-auto-var-init=zero, does this:

/home/dcb36/gcc/results.20230215.asan.ubsan/bin/gcc
checksum = 95F158F5
/home/dcb36/gcc/results.20230216/bin/gcc
checksum = 95F158F5
/home/dcb36/gcc/results.20230217.asan.ubsan/bin/gcc
Segmentation fault (core dumped)
/home/dcb36/gcc/results.20230218.asan.ubsan/bin/gcc
Segmentation fault (core dumped)

20230216 has git hash g:7478278f88ba1753 and 20230217 has g:f978585c29396911.
This is a range of 30 commits.

I will have a go at a git bisect. This is bug #895 for me.

[Bug rtl-optimization/109092] New: [13 Regression] ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1932 when building libgcc on riscv64

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 109092
   Summary: [13 Regression] ICE: RTL check: expected code 'reg',
have 'subreg' in rhs_regno, at rtl.h:1932 when
building libgcc on riscv64
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: build, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: riscv64-unknown-linux-gnu

$ cat testcase.c 
void foo(int i) {}

$ /repo/build-gcc-trunk-riscv64/./gcc/cc1 -mabi=lp64d -march=rv64imafdc
testcase.c -quiet
during RTL pass: vregs
testcase.c: In function 'foo':
testcase.c:1:18: internal compiler error: RTL check: expected code 'reg', have
'subreg' in rhs_regno, at rtl.h:1932
1 | void foo(int i) {}
  |  ^
0x7a0e7d rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int,
char const*)
/repo/gcc-trunk/gcc/rtl.cc:916
0x93b82e rhs_regno(rtx_def const*)
/repo/gcc-trunk/gcc/rtl.h:1932
0x958236 rhs_regno(rtx_def const*)
/repo/gcc-trunk/gcc/config/riscv/pic.md:87
0x958236 recog_17
/repo/gcc-trunk/gcc/config/riscv/riscv.md:1750
0x1ac76aa recog_174
/repo/gcc-trunk/gcc/config/riscv/vector-iterators.md:326
0xb527dc recog_memoized(rtx_insn*)
/repo/gcc-trunk/gcc/recog.h:273
0xfdff84 extract_insn(rtx_insn*)
/repo/gcc-trunk/gcc/recog.cc:2789
0xd111ff instantiate_virtual_regs_in_insn
/repo/gcc-trunk/gcc/function.cc:1611
0xd111ff instantiate_virtual_regs
/repo/gcc-trunk/gcc/function.cc:1985
0xd111ff execute
/repo/gcc-trunk/gcc/function.cc:2034
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.


Currently build with RTL checking enabled for the riscv64-unknown-linux-gnu
target fails.

[Bug target/109087] [13 Regression] csmith: end of year runtime bug since r13-4839-geef81eefcdc2a581

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

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

--- Comment #10 from Andrew Pinski  ---
(In reply to David Binderman from comment #9)
> (In reply to Richard Biener from comment #6)
> > Try -fno-tree-vectorize?
> 
> I tried that, and it made no difference at all.
> 
> I also tried dropping the -march= setting back to znver1 and
> that also made no difference.

The change added znver1/2/3 to X86_TUNE_AVX256_MOVE_BY_PIECES,
X86_TUNE_AVX256_STORE_BY_PIECES also so must be related to that ...

Most likely a latent bug too ...

you might get a similar failure on alderlake or core_avx2 too.

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

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

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

--- Comment #19 from Marek Polacek  ---
(In reply to Barnabás Pőcze from comment #17)
> The simple test case with std::span still triggers the warning:
> https://gcc.godbolt.org/z/43cKxdqr3. I feel that without deeper code
> analysis such a warning will generate too many false positives and people
> will simply turn it off.

...but I could at least add a std::span check to fix this test...

[Bug target/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1 since r13-2706-g6e80a1d164d1f9

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

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

--- Comment #15 from Jakub Jelinek  ---
So I guess the primary question would be, are threads involved in the
reproducer or not?
All the backtraces don't include start_thread, so the crashes are from the
initial thread, but that doesn't mean other threads weren't registering or
deregistering unwind info frames concurrently.
unwind-dw2-fde.c:719 is fairly simple:
  for (; ! last_fde (ob, this_fde); this_fde = next_fde (this_fde))
where last_fde is:
static inline int
last_fde (const struct object *obj __attribute__ ((__unused__)), const fde *f)
{
#ifdef DWARF2_OBJECT_END_PTR_EXTENSION
  return f == (const fde *) obj->fde_end || f->length == 0;
#else
  return f->length == 0;
#endif
}
and next_fde is:
static inline const fde *
next_fde (const fde *f)
{
  return (const fde *) ((const char *) f + f->length + sizeof (f->length));
}
So, I guess the primary question is what the LLVM JIT is calling the function
with,
if begin is a proper chain of valid .eh_frame CIEs and FDEs and if it is
properly 0 terminated.  DWARF2_OBJECT_END_PTR_EXTENSION is Darwin only.
Also, __register_frame_info_bases requires the controlling struct object to be
preserved by the caller until it is deregistered, is that the case?  Also, does
something change
the FDEs or CIEs which have been registered before they are deregistered again?

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

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

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

--- Comment #18 from Marek Polacek  ---
(In reply to Jonathan Wakely from comment #16)
> Span is a view, so it is like reference-wrapper. The lifetime of the
> underlying data is not tied to the lifetime of the Span.

Aha, I could add a check for std::span but that wouldn't help, because here
it's a custom-made Span.  And I don't think there's a pattern I could look for
that would tell us "this is a std::span-like class".  :/

(In reply to Barnabás Pőcze from comment #17)
> The simple test case with std::span still triggers the warning:
> https://gcc.godbolt.org/z/43cKxdqr3. I feel that without deeper code
> analysis such a warning will generate too many false positives and people
> will simply turn it off.

There really haven't been that many, except this and one with range-based for
loops.

[Bug target/109087] [13 Regression] csmith: end of year runtime bug since r13-4839-geef81eefcdc2a581

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #9 from David Binderman  ---
(In reply to Richard Biener from comment #6)
> Try -fno-tree-vectorize?

I tried that, and it made no difference at all.

I also tried dropping the -march= setting back to znver1 and
that also made no difference.

[Bug libgomp/90596] 'GOACC_parallel_keyed' should use 'GOMP_MAP_VARS_TARGET'

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Thomas Schwinge :

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

commit r13-6590-gf8332e52a498df480f72303de32ad0751ad899fe
Author: Thomas Schwinge 
Date:   Mon Feb 27 15:56:18 2023 +0100

Use 'GOMP_MAP_VARS_TARGET' for OpenACC compute constructs [PR90596]

Thereby considerably simplify the device plugins'
'GOMP_OFFLOAD_openacc_exec',
'GOMP_OFFLOAD_openacc_async_exec' functions: in terms of lines of code, but
in
particular conceptually: no more device memory allocation, host to device
data
copying, device memory deallocation -- 'GOMP_MAP_VARS_TARGET' does all that
for
us.

This depends on commit 2b2340e236c0bba8aaca358ea25a5accd8249fbd
"Allow libgomp 'cbuf' buffering with OpenACC 'async' for 'ephemeral' data",
where I said that "a use will emerge later", which is this one here.

PR libgomp/90596
libgomp/
* target.c (gomp_map_vars_internal): Allow for
'param_kind == GOMP_MAP_VARS_OPENACC | GOMP_MAP_VARS_TARGET'.
* oacc-parallel.c (GOACC_parallel_keyed): Pass
'GOMP_MAP_VARS_TARGET' to 'goacc_map_vars'.
* plugin/plugin-gcn.c (alloc_by_agent, gcn_exec)
(GOMP_OFFLOAD_openacc_exec, GOMP_OFFLOAD_openacc_async_exec):
Adjust, simplify.
(gomp_offload_free): Remove.
* plugin/plugin-nvptx.c (nvptx_exec, GOMP_OFFLOAD_openacc_exec)
(GOMP_OFFLOAD_openacc_async_exec): Adjust, simplify.
(cuda_free_argmem): Remove.
* testsuite/libgomp.oacc-c-c++-common/acc_prof-parallel-1.c:
Adjust.

[Bug analyzer/109059] -Wanalyzer-malloc-leak false +ve seen on haproxy's cfgparse.c: cfg_register_postparser

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

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

David Malcolm  changed:

   What|Removed |Added

   Last reconfirmed||2023-03-10
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #2 from David Malcolm  ---
Fixed on trunk by the above patch.

Keeping open to track backporting this.

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[pobrn at protonmail dot com via Gcc-bugs]

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

--- Comment #17 from Barnabás Pőcze  ---
The simple test case with std::span still triggers the warning:
https://gcc.godbolt.org/z/43cKxdqr3. I feel that without deeper code analysis
such a warning will generate too many false positives and people will simply
turn it off.

[Bug target/109087] [13 Regression] csmith: end of year runtime bug since r13-4839-geef81eefcdc2a581

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

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Martin Liška from comment #7)
> With gcc pr109087.c -w -ftrivial-auto-var-init=zero -g -O3 -march=znver3
> -fno-strict-aliasing -fno-tree-vectorize -fno-tree-slp-vectorize
> it started with r13-4839-geef81eefcdc2a581. That's strange, because I
> intentionally disable the vectorizer.

Could be exposed by the change to ix86_expand_set_or_cpymem or
ix86_reassociation_width then.

Or the change to X86_TUNE_AVX256_MOVE_BY_PIECES,
X86_TUNE_AVX256_STORE_BY_PIECES which adds znver3 to them ...

[Bug analyzer/109059] -Wanalyzer-malloc-leak false +ve seen on haproxy's cfgparse.c: cfg_register_postparser

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:14f5e56a8a766c6f48c2a07b301fce2db1a19a3c

commit r13-6589-g14f5e56a8a766c6f48c2a07b301fce2db1a19a3c
Author: David Malcolm 
Date:   Fri Mar 10 11:55:44 2023 -0500

analyzer: fix leak false +ve seen in haproxy's cfgparse.c [PR109059]

If a bound region gets overwritten with UNKNOWN due to being
possibly-aliased during a write, that could have been the only
region keeping its value live, in which case we could falsely report
a leak.  This is hidden somewhat by the "uncertainty" mechanism for
cases where the write happens in the same stmt as the last reference
to the value goes away, but not in the general case, which occurs
in PR analyzer/109059, which falsely complains about a leak whilst
haproxy updates a doubly-linked list.

The whole "uncertainty_t" class seems broken to me now; I think we need
to track (in the store) what values could have escaped to the external
part of the program.  We do this to some extent for pointers by tracking
the region as escaped, though we're failing to do this for this case:
even though there could still be other pointers to the region,
eventually they go away; we want to capture the fact that the external
part of the state is still keeping it live.  Also, this doesn't work for
non-pointer svalues, such as for detecting file-descriptor leaks.

As both a workaround and a step towards eventually removing
"class uncertainty_t" this patch updates the "mark_region_as_unknown"
code called by possibly-aliased set_value so that when old values are
removed, any base region pointed to them is marked as escaped, fixing
the leak false positive.

The patch has this effect on my integration tests of -fanalyzer:

  Comparison:
GOOD: 129(19.20% -> 20.22%)
 BAD: 543 -> 509 (-34)

where there's a big improvement in -Wanalyzer-malloc-leak:

  -Wanalyzer-malloc-leak:
GOOD: 61   (45.19% -> 54.95%)
 BAD: 74 -> 50 (-24)
 Known false positives: 25 -> 2 (-23)
   haproxy-2.7.1: 24 ->  1 (-23)
 Suspected false positives: 49 -> 48 (-1)
   coreutils-9.1: 32 -> 31 (-1)

and some churn in the other warnings:

  -Wanalyzer-use-of-uninitialized-value:
 GOOD: 0
  BAD: 81 -> 80 (-1)
  -Wanalyzer-file-leak:
 GOOD: 0
  BAD: 10 -> 11 (+1)
  -Wanalyzer-out-of-bounds:
 GOOD: 0
  BAD: 24 -> 22 (-2)

gcc/analyzer/ChangeLog:
PR analyzer/109059
* region-model.cc (region_model::mark_region_as_unknown): Gather a
set of maybe-live svalues and call on_maybe_live_values with it.
* store.cc (binding_map::remove_overlapping_bindings): Add new
"maybe_live_values" param; add any removed svalues to it.
(binding_cluster::clobber_region): Add NULL as new param of
remove_overlapping_bindings.
(binding_cluster::mark_region_as_unknown): Add "maybe_live_values"
param and pass it to remove_overlapping_bindings.
(binding_cluster::maybe_get_compound_binding): Add NULL for new
param of binding_map::remove_overlapping_bindings.
(binding_cluster::remove_overlapping_bindings): Add
"maybe_live_values" param and pass to
binding_map::remove_overlapping_bindings.
(store::set_value): Capture a set of maybe-live svalues, and call
on_maybe_live_values with it.
(store::on_maybe_live_values): New.
(store::mark_region_as_unknown): Add "maybe_live_values" param
and pass it to binding_cluster::mark_region_as_unknown.
(store::remove_overlapping_bindings): Pass NULL for new param of
binding_cluster::remove_overlapping_bindings.
* store.h (binding_map::remove_overlapping_bindings): Add
"maybe_live_values" param.
(binding_cluster::mark_region_as_unknown): Likewise.
(binding_cluster::remove_overlapping_bindings): Likewise.
(store::mark_region_as_unknown): Likewise.
(store::on_maybe_live_values): New decl.

gcc/testsuite/ChangeLog:
PR analyzer/109059
* gcc.dg/analyzer/flex-with-call-summaries.c: Remove xfail.
* gcc.dg/analyzer/leak-pr109059-1.c: New test.
* gcc.dg/analyzer/leak-pr109059-2.c: New test.

Signed-off-by: David Malcolm 

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

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

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

--- Comment #16 from Jonathan Wakely  ---
Span is a view, so it is like reference-wrapper. The lifetime of the underlying
data is not tied to the lifetime of the Span.

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

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

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

--- Comment #15 from Marek Polacek  ---
Hmm, so it's this line

const FrameMetadata::Plane &meta = buffer->metadata().planes()[i];

and we complain because we have

libcamera::Span::operator[]
(&TARGET_EXPR (buffer)>))>, (size_type)
VIEW_CONVERT_EXPR(i))

and the argument to operator[] is a temporary of type Span.  Span is not a
reference wrapper class so I *think* this is a valid warning.

[Bug c++/92851] Lambda capture of *this with mutable is not mutable

[flast at flast dot jp via Gcc-bugs]

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

--- Comment #3 from Kohei Takahashi  ---
It's still rejected in GCC 13.0. https://wandbox.org/permlink/jKItc5W8KnYR7JN1

[Bug target/108910] [12/13 Regression] Further ICE in aarch64_layout_arg

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

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

--- Comment #11 from Jakub Jelinek  ---
To be exact, it is more complicated than that.
Some types with extra types are created using build_variant_type_copy and so
their TYPE_MAIN_VARIANT is without the attributes.
Example is handle_aligned_attribute -> common_handle_aligned_attribute ->
build_variant_type_copy.
Others are created as build_distinct_type_copy and don't have TYPE_MAIN_VARIANT
without it, e.g. build_type_attribute_variant ->
build_type_attribute_qual_variant -> build_distinct_type_copy.

Compare e.g. the #c0 testcase vs.
extern void foo (float, float *, float *);

void
bar (void *p)
{
  typedef float *FP;
  typedef FP FP2 __attribute__((aligned (64)));
  FP2 q = __builtin_assume_aligned (p, 64);
  foo (0.0f, q, q);
}
which doesn't ICE.
#0  build_distinct_type_copy (type=) at
../../gcc/tree.cc:5693
#1  0x00c143bb in build_type_attribute_qual_variant
(otype=, attribute=,
quals=0) at ../../gcc/attribs.cc:1298
#2  0x00c156f0 in build_type_attribute_variant (ttype=, attribute=) at
../../gcc/attribs.cc:1591
#3  0x00c13465 in decl_attributes (node=0x7fffd1f8,
attributes=, flags=1, last_decl=) at
../../gcc/attribs.cc:964
#4  0x00c32a69 in grokdeclarator (declarator=0x3716e40,
declspecs=0x3716cc0, decl_context=NORMAL, initialized=true, width=0x0,
decl_attrs=0x7fffd3d0, 
expr=0x7fffd3f0, expr_const_operands=0x7fffd1ef,
deprecated_state=DEPRECATED_NORMAL) at ../../gcc/c/c-decl.cc:6967
#5  0x00c2d270 in start_decl (declarator=0x3716e70,
declspecs=0x3716cc0, initialized=true, attributes=, do_push=true,
lastloc=0x0) at ../../gcc/c/c-decl.cc:5364
on #c0 while this one:
#1  0x0191494b in build_variant_type_copy (type=) at ../../gcc/tree.cc:5727
#2  0x00dbaeba in common_handle_aligned_attribute (node=0x7fffd270,
name=, args=,
flags=0, 
no_add_attrs=0x7fffd28f, warn_if_not_aligned_p=false) at
../../gcc/c-family/c-attribs.cc:2386
#3  0x00dbb633 in handle_aligned_attribute (node=0x7fffd270,
name=, args=,
flags=0, 
no_add_attrs=0x7fffd28f) at ../../gcc/c-family/c-attribs.cc:2499
#4  0x00c12dcd in decl_attributes (node=0x7fffd3f8,
attributes=, flags=0, last_decl=) at
../../gcc/attribs.cc:878
#5  0x00c2d1bc in c_decl_attributes (node=0x7fffd3f8,
attributes=, flags=0) at ../../gcc/c/c-decl.cc:5323
#6  0x00c2d699 in start_decl (declarator=0x3716f60,
declspecs=0x3716ea0, initialized=false, attributes=,
do_push=true, lastloc=0x7fffd584)
at ../../gcc/c/c-decl.cc:5460

[Bug c++/109091] New: AIX: thread_local is not being internally linked

[miladfarca at gmail dot com via Gcc-bugs]

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

Bug ID: 109091
   Summary: AIX: thread_local is not being internally linked
   Product: gcc
   Version: 10.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: miladfarca at gmail dot com
  Target Milestone: ---

Sample:

0.cc
```
void check();
namespace {
 thread_local int num = 0;
}

int main(){
  num = 5;
  check(); 
  return 0;
}

```

1.cc
```
#include 
namespace {
 thread_local int num = 0;
}
void check(){
  std::cout << num << std::endl;  
}

```
Compile with g++ -lpthread 0.cc 1.cc and run.

Expected output: 0
Output on AIX: 5

[Bug tree-optimization/109071] -Warray-bounds warning when array index checked via inline

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

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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

 CC||qinzhao at gcc dot gnu.org

--- Comment #4 from qinzhao at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #1)
> Jump threading is happening which is causing some code to be duplicated. I
> am 100% sure there is a dup of this bug already filed too.

Yes, the false positive warning is due to the code duplication by jump
threading. 

***without jump threading (adding fno-thread-jumps), the IR in vrp1 is:

   [local count: 1073741824]:
  if (index_3(D) > 3)
goto ; [33.00%]
  else
goto ; [67.00%]

   [local count: 354334800]:
  warn ();

   [local count: 1073741824]:
  *ptr_5(D) = 0;
  _1 = MEM  [(int *)sg_2(D)].vals[index_3(D)];
  if (index_3(D) > 3)
goto ; [33.00%]
  else
goto ; [67.00%]

   [local count: 354334800]:
  warn ();

***with jump threading, the "Bad" IR in vrp1 is:

   [local count: 1073741824]:
  if (index_3(D) > 3)
goto ; [33.00%]
  else
goto ; [67.00%]

   [local count: 719407024]:
  *ptr_5(D) = 0;
  _14 = MEM  [(int *)sg_2(D)].vals[index_3(D)];
  goto ; [100.00%]

   [local count: 354334800]:
  warn ();
  *ptr_5(D) = 0;
  _17 = MEM  [(int *)sg_2(D)].vals[index_3(D)];
  warn ();

in the above "Bad" IR with jump threading, we can see the problematic part is:

   [local count: 354334800]:
  warn ();
  *ptr_5(D) = 0;
  _17 = MEM  [(int *)sg_2(D)].vals[index_3(D)];
  warn ();

in which the "_17 = MEM  [(int *)sg_2(D)].vals[index_3(D)];" is
the one that was duplicated by jump threading and also is the one that caused
array bound checker to report the false positive warning based on the value
range propagation result in block 4: the value range for "index_3" is > 3,
which is out-of-range of the array "Vals", therefore the warning. 

my though is:

1. the jump threading and code duplication are all correct optimization;
2. but the duplication of the array reference caused the false positive
warning;

So, the following is my proposed solution to this problem:

1. when jump threading applies the code duplication, mark those array
references that are duplicated as ARTIFICIAL (or something else..);
2. during array bound checker, check whether the array references are
ARTIFICIAL, if it's true, do not emit the warning.

is the proposed solution feasible?

[Bug sanitizer/109090] [10/11/12/13 Regression] UBSan signed integer overflow check missing.

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

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

--- Comment #4 from Marek Polacek  ---
Dunno, this doesn't seem to be fixed by the patch in PR108995.

[Bug sanitizer/109090] [10/11/12/13 Regression] UBSan signed integer overflow check missing.

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

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

--- Comment #3 from Martin Liška  ---
A dup of PR108995?

[Bug sanitizer/109090] [10/11/12/13 Regression] UBSan signed integer overflow check missing.

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

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

--- Comment #2 from Marek Polacek  ---
Started with r8-343-g2bf54d93f15921 it seems:

commit 2bf54d93f159210d0c05a07c655eb847c069365c
Author: Richard Biener 
Date:   Tue May 2 12:43:47 2017 +

common.opt (fstrict-overflow): Alias negative to fwrapv.

[Bug c/109090] [10/11/12/13 Regression] UBSan signed integer overflow check missing.

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |10.5
 Ever confirmed|0   |1
Summary|UBSan signed integer|[10/11/12/13 Regression]
   |overflow check missing. |UBSan signed integer
   ||overflow check missing.
   Last reconfirmed||2023-03-10
   Priority|P3  |P2

--- Comment #1 from Marek Polacek  ---
Confirmed.

int a = -1113063836;
int *b, *c = &a;
int **d = &b;
int main(void) {
  *d = c;
  *b = 0 > *c + *c;
  __builtin_printf("checksum = %X\n", a);
}

[Bug target/109087] [13 Regression] csmith: end of year runtime bug ?

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-03-10
 CC||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #7 from Martin Liška  ---
With gcc pr109087.c -w -ftrivial-auto-var-init=zero -g -O3 -march=znver3
-fno-strict-aliasing -fno-tree-vectorize -fno-tree-slp-vectorize
it started with r13-4839-geef81eefcdc2a581. That's strange, because I
intentionally disable the vectorizer.

[Bug c/109090] New: UBSan signed integer overflow check missing.

[cbossut21 at gatech dot edu via Gcc-bugs]

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

Bug ID: 109090
   Summary: UBSan signed integer overflow check missing.
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cbossut21 at gatech dot edu
  Target Milestone: ---

$ cat test.c
int printf(const char *, ...);
int a = 3181903460;
int *b, *c = &a;
int **d = &b;
void main(void) {
  *d = c;
  *b = 0 > *c + *c;
  printf("checksum = %X\n", a);
}


UBSan doesn't emit any runtime error messages reporting overflow for the most
recent version of gcc. However in gcc-7 UBSan reports overflow, and the using
the -fwrapv flag produces different output.


$ gcc-7 -O3 -fsanitize=undefined test.c ; ./a.out
test.c:7:15: runtime error: signed integer overflow: -1113063836 * 2 cannot be
represented in type 'int'
checksum = 0

$ gcc-trunk -fwrapv -O3 -fsanitize=undefined test.c ; ./a.out
checksum = 0

$ gcc-trunk -O3 -fsanitize=undefined test.c ; ./a.out
checksum = 1

$ gcc-trunk -fsanitize=undefined test.c ; ./a.out
checksum = 1

[Bug target/108910] [12/13 Regression] Further ICE in aarch64_layout_arg

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

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

--- Comment #10 from Jakub Jelinek  ---
(In reply to Christophe Lyon from comment #9)
> So is it expected that the alignment of TYPE_MAIN_VARIANT(type) is 512?

Yes, it is.  aligned attribute on non-aggregate types create a distinct type,
and TYPE_MAIN_VARIANT of a distinct type is the non-qualified variant of such a
distinct type.  For structures/unions, I believe we disallow creation of
less/more aligned variants of the original types, one needs to supply the
alignment when defining the structure/union type.

[Bug target/108910] [12/13 Regression] Further ICE in aarch64_layout_arg

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

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||rearnsha at gcc dot gnu.org

--- Comment #9 from Christophe Lyon  ---
Looking at #c6 again, the behavior of aarch64_function_arg_alignment does not
seem to match the comment preceding it. IIUC, it should ignore user alignment.

So is it expected that the alignment of TYPE_MAIN_VARIANT(type) is 512? (ie. is
the bug in aarch64_function_arg_alignment or earlier, when we build "type"?)

[Bug tree-optimization/109041] Bogus compile time check by __builtin_memset? error: ‘__builtin_memset’ writing 4 bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]

[ishikawa at yk dot rim.or.jp via Gcc-bugs]

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

--- Comment #9 from ishikawa,chiaki  ---
Thank you for the confirmation for the fix in GCC-12.

Now I have to figure out how GCC-12 seems to miscompile something in
Thunderbird mail client to report a run-time assertion error.
(Compiling Thunderbird mail client with earlier version did not show the
runtime assertion error. So I wanted to weed out possible source problem from
mozilla source code and thunderbird mail client code by using -Werror with due
caution.)

Thank you again for the confirmation of the fix in GCC-12.

[Bug tree-optimization/109088] GCC does not always vectorize conditional reduction

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-03-10
   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
Summary|GCC fail auto-vectorization |GCC does not always
   ||vectorize conditional
   ||reduction

--- Comment #5 from Andrew Pinski  ---
GCC does vectorize:
if (a[i] > b[i]) {
  result += a[i];
}

Even for variable-length vectors.
Just we don't vectorize when there is an extra conditional operation.

GCC will even vectorize with variable-length vectors:
#include 

uint64_t single_loop_with_if_condition(
uint64_t * restrict a,
uint64_t * restrict b,
uint64_t * restrict c,
int loop_size) {
  uint64_t result = 0;

  for (int i = 0; i < loop_size; i++) {
c[i] = a[i] + 1;
if (a[i] > b[i]) {
  result += c[i];
}
  }
  return result;
}

[Bug tree-optimization/109088] GCC fail auto-vectorization

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

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

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

[Bug c++/108542] [13 Regression] ICE in instantiate_type, at cp/class.cc:8833

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  ---
Fixed.

[Bug analyzer/109060] -Wanalyzer-deref-before-check false positives seen in haproxy's cfgparse.c: parse_process_number

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #2 from David Malcolm  ---
Should be fixed by the above patch.

[Bug analyzer/108475] -Wanalyzer-deref-before-check false positives seen in haproxy's tcpcheck.c

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #2 from David Malcolm  ---
Should be fixed by the above patch.

[Bug c++/108566] [11/12 Regression] ICE: tree check: expected tree that contains 'decl with visibility' structure, have 'field_decl' in write_unqualified_name with anonymous struct inside an anonymous

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

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[11/12/13 Regression] ICE:  |[11/12 Regression] ICE:
   |tree check: expected tree   |tree check: expected tree
   |that contains 'decl with|that contains 'decl with
   |visibility' structure, have |visibility' structure, have
   |'field_decl' in |'field_decl' in
   |write_unqualified_name with |write_unqualified_name with
   |anonymous struct inside an  |anonymous struct inside an
   |anonymous union since   |anonymous union since
   |r11-2016-g6324c52bba490baa  |r11-2016-g6324c52bba490baa

--- Comment #7 from Jason Merrill  ---
Fixed for GCC 13 so far.

[Bug c++/108566] [11/12/13 Regression] ICE: tree check: expected tree that contains 'decl with visibility' structure, have 'field_decl' in write_unqualified_name with anonymous struct inside an anonym

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

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

--- Comment #6 from CVS Commits  ---
The trunk branch has been updated by Jason Merrill :

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

commit r13-6582-ge1c8cf9006bd278e969ab7ed35178067ce128f32
Author: Jason Merrill 
Date:   Thu Mar 9 23:33:43 2023 -0500

c++: class NTTP and nested anon union [PR108566]

We were failing to come up with the name for the anonymous union.  It seems
like unfortunate redundancy, but the ABI does say that the name of an
anonymous union is its first named member.

PR c++/108566

gcc/cp/ChangeLog:

* mangle.cc (anon_aggr_naming_decl): New.
(write_unqualified_name): Use it.

gcc/testsuite/ChangeLog:

* g++.dg/abi/anon6.C: New test.

[Bug analyzer/108475] -Wanalyzer-deref-before-check false positives seen in haproxy's tcpcheck.c

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by David Malcolm :

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

commit r13-6581-gc4fd232f9843bb800548a906653aeb0723cdb411
Author: David Malcolm 
Date:   Fri Mar 10 08:20:10 2023 -0500

analyzer: fix deref-before-check false +ves seen in haproxy
[PR108475,PR109060]

Integration testing showed various false positives from
-Wanalyzer-deref-before-check where the expression that's dereferenced
is different from the one that's checked, but the diagnostic is emitted
because they both evaluate to the same symbolic value.

This patch rejects such warnings, unless we have tree expressions for
both and that both tree expressions are "spelled the same way" i.e.
would be printed to the same user-facing string.

gcc/analyzer/ChangeLog:
PR analyzer/108475
PR analyzer/109060
* sm-malloc.cc (deref_before_check::deref_before_check):
Initialize new field m_deref_expr.  Assert that arg is non-NULL.
(deref_before_check::emit): Reject cases where the spelling of the
thing that was dereferenced differs from that of what is checked,
or if the dereference expression was not found.  Remove code to
handle NULL m_arg.
(deref_before_check::describe_state_change): Remove code to handle
NULL m_arg.
(deref_before_check::describe_final_event): Likewise.
(deref_before_check::sufficiently_similar_p): New.
(deref_before_check::m_deref_expr): New field.
(malloc_state_machine::maybe_complain_about_deref_before_check):
Don't warn if the diag_ptr is NULL.

gcc/testsuite/ChangeLog:
PR analyzer/108475
PR analyzer/109060
* gcc.dg/analyzer/deref-before-check-pr108475-1.c: New test.
* gcc.dg/analyzer/deref-before-check-pr108475-haproxy-tcpcheck.c:
New test.
* gcc.dg/analyzer/deref-before-check-pr109060-haproxy-cfgparse.c:
New test.

Signed-off-by: David Malcolm