[Bug analyzer/105765] New: [13 Regression] ICE: Segmentation fault (in ana::region_model::deref_rvalue)

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 105765
   Summary: [13 Regression] ICE: Segmentation fault (in
ana::region_model::deref_rvalue)
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc 13.0.0 20220522 snapshot (g:a60228404f2ac11b5eb66270037ff3fa6bf948e5) ICEs
when compiling the following testcase, reduced from
clang/testsuite/CodeGen/ms_abi_aarch64.c from the clang 14.0.3 test suite, w/
-fanalyzer:

void
f4 (int a, ...)
{
  __builtin_ms_va_list ap, ap2;

  __builtin_ms_va_start (ap, a);
  __builtin_ms_va_copy (ap2, ap);
  __builtin_ms_va_end (ap);
}

% gcc-13.0.0 -fanalyzer -c jhszfd06.c
during IPA pass: analyzer
jhszfd06.c: In function 'f4':
jhszfd06.c:7:3: internal compiler error: Segmentation fault
7 |   __builtin_ms_va_copy (ap2, ap);
  |   ^~
0xedc30f crash_signal
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220522/work/gcc-13-20220522/gcc/toplev.cc:322
0x12af921 ana::region_model::deref_rvalue(ana::svalue const*, tree_node*,
ana::region_model_context*) const
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220522/work/gcc-13-20220522/gcc/analyzer/region-model.cc:2472
0x130 get_BT_VALIST_ARG
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220522/work/gcc-13-20220522/gcc/analyzer/varargs.cc:183
0x1311449 ana::region_model::impl_call_va_copy(ana::call_details const&)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220522/work/gcc-13-20220522/gcc/analyzer/varargs.cc:670
0x12b2268 ana::region_model::on_call_pre(gcall const*,
ana::region_model_context*, bool*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220522/work/gcc-13-20220522/gcc/analyzer/region-model.cc:1439
0x12c0bc2 ana::region_model::on_stmt_pre(gimple const*, bool*, bool*,
ana::region_model_context*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220522/work/gcc-13-20220522/gcc/analyzer/region-model.cc:1213
0x128bff9 ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode
const*, gimple const*, ana::program_state*, ana::uncertainty_t*,
ana::path_context*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220522/work/gcc-13-20220522/gcc/analyzer/engine.cc:1383
0x128f3cc ana::exploded_graph::process_node(ana::exploded_node*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220522/work/gcc-13-20220522/gcc/analyzer/engine.cc:3776
0x12903da ana::exploded_graph::process_worklist()
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220522/work/gcc-13-20220522/gcc/analyzer/engine.cc:3219
0x1292ac5 ana::impl_run_checkers(ana::logger*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220522/work/gcc-13-20220522/gcc/analyzer/engine.cc:5811
0x12939ce ana::run_checkers()
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220522/work/gcc-13-20220522/gcc/analyzer/engine.cc:5885
0x1282358 execute
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220522/work/gcc-13-20220522/gcc/analyzer/analyzer-pass.cc:87

[Bug testsuite/104423] [libgomp, testsuite] Add means to do accelerator-only testing in libgomp

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=103324

--- Comment #6 from Eric Gallager  ---
Seems kinda like the same idea as bug 103324, albeit a more-specific variant of
it just for libgomp.

[Bug other/82383] Some new toplevel directories are not documented

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

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #8 from Eric Gallager  ---
Fixed for GCC 13; I'm not planning on backporting. If someone else would like
to backport, feel free to reopen.

[Bug libgomp/66005] libgomp make check time is excessive

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
*** Bug 90084 has been marked as a duplicate of this bug. ***

[Bug libgomp/90084] Parallelize libgomp testing

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Eric Gallager  ---
(In reply to Sam James from comment #2)
> Duplicate of bug 66005?

Sure I guess so.

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

Re: [PATCH] sourcebuild.texi: Document new toplevel directories [PR82383]

[Eric Gallager via Gcc-patches]

On Sat, May 28, 2022 at 2:30 PM Jeff Law via Gcc-patches
 wrote:
> On 5/24/2022 11:32 AM, Eric Gallager via Gcc-patches wrote:
> > This patch adds entries for the c++tools, gotools, libbacktrace,
> > libcc1, libcody, liboffloadmic, and libsanitizer directories into the
> > list of toplevel source directories in sourcebuild.texi. I also
> > removed the entry for boehm-gc (which is no longer in-tree), and fixed
> > the alphabetization for libquadmath while I was at it. Any style nits
> > I need to fix before committing (with a proper ChangeLog entry)?
> I think this is fine.  If you're looking for a good cleanup, removing
> liboffloadmic  would be useful IMHO.  MIC is dead.
>

OK thanks, committed as r13-817. I'll leave removing the liboffloadmic
directory for someone else to do, as it still has stuff in it.

[Bug other/82383] Some new toplevel directories are not documented

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Eric Gallager :

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

commit r13-817-gda5f0cc2f51a791a397fd1b3cef662763897a826
Author: Eric Gallager 
Date:   Sun May 29 00:57:05 2022 -0400

sourcebuild.texi: Document toplevel directories

Fixes PR82383

gcc/ChangeLog:

PR other/82383
* doc/sourcebuild.texi: Add entries for the c++tools,
gotools, libbacktrace, libcc1, libcody, liboffloadmic,
and libsanitizer directories. Remove entry for boehm-gc.
Fix alphabetization for libquadmath.

[Bug libgomp/90084] Parallelize libgomp testing

[sam at gentoo dot org via Gcc-bugs]

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

Sam James  changed:

   What|Removed |Added

 CC||sam at gentoo dot org

--- Comment #2 from Sam James  ---
Duplicate of bug 66005?

[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck

[sam at gentoo dot org via Gcc-bugs]

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

Sam James  changed:

   What|Removed |Added

 CC||sam at gentoo dot org

--- Comment #46 from Sam James  ---
Even partially making the build less recursive would likely help a fair bit. 

The classic text on this is
https://accu.org/journals/overload/14/71/miller_2004/. This doesn't mean that
splitting up files is futile, but when watching a build, much of the time, make
doesn't even get to traverse into each of the directories, because it doesn't
know if it's able to. It can safely be done in stages.

Using includes would let you get a lot of the current state wrt split
directories. Could even just have a certain number of toplevel directories but
non-recursive within them.

[Bug libfortran/105764] New: libgfortran fails to build with a custom thread model

[lh_mouse at 126 dot com via Gcc-bugs]

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

Bug ID: 105764
   Summary: libgfortran fails to build with a custom thread model
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lh_mouse at 126 dot com
  Target Milestone: ---

Created attachment 53049
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53049=edit
proposed patch

Bootstrapping GCC with fortran enabled and a custom thread model can fail:

```
In file included from ../../../gcc/libgfortran/runtime/error.c:28:
../../../gcc/libgfortran/io/async.h:354:3: error: unknown type name 'pthread_t'
  354 |   pthread_t thread;
  |   ^
```


In commit a79878585a1c5e32bafbc6d1e73f91fd6e4293bf, `pthread_mutex_t` was
replaced with `__gthread_mutex_t`, but `pthread_t` was left over. Not sure
whether this was by design, or was an oversight.

Patch also sent to gcc-patches:
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595754.html

[Bug tree-optimization/105763] [13 Regression] ice in outgoing_edge_range_p, at gimple-ra nge-gori.cc:1253

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

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

Andrew Pinski  changed:

   What|Removed |Added

Version|12.0|13.0
   Target Milestone|--- |13.0
Summary|ice in  |[13 Regression] ice in
   |outgoing_edge_range_p, at   |outgoing_edge_range_p, at
   |gimple-ra nge-gori.cc:1253  |gimple-ra nge-gori.cc:1253

[Bug c/105763] ice in outgoing_edge_range_p, at gimple-ra nge-gori.cc:1253

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
Reduced C code is

int rl2_decode_png_bit_depth;
int *rl2_decode_png_p_data;
void rl2_decode_png_row_pointers() {
  unsigned sample_type = 0;
  _setjmp();
  switch (rl2_decode_png_bit_depth)
  case 6:
sample_type = 7;
  png_destroy_read_struct();
  for (;;)
switch (sample_type)
case 3:
case 5:
  *rl2_decode_png_p_data;
}

[Bug c/105763] New: ice in outgoing_edge_range_p, at gimple-ra nge-gori.cc:1253

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 105763
   Summary: ice in outgoing_edge_range_p, at gimple-ra
nge-gori.cc:1253
   Product: gcc
   Version: 12.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 53048
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53048=edit
C source code

For the attached code, with compiler flag -O3, does this:

during GIMPLE pass: unswitch
rl2png.c: In function ‘rl2_decode_png’:
rl2png.c:1292:1: internal compiler error: in outgoing_edge_range_p, at
gimple-ra
nge-gori.cc:1253
0xa17888 gori_compute::outgoing_edge_range_p(irange&, edge_def*, tree_node*,
ran
ge_query&)
../../trunk.git/gcc/gimple-range-gori.cc:1253
0x2da292b evaluate_control_stmt_using_entry_checks
../../trunk.git/gcc/tree-ssa-loop-unswitch.cc:686
0x2da4e43 evaluate_bbs >
../../trunk.git/gcc/tree-ssa-loop-unswitch.cc:830
0x2da97b6 evaluate_loop_insns_for_predicate
../../trunk.git/gcc/tree-ssa-loop-unswitch.cc:876

The problem first seems to occur sometime between git hash 442cf0977a299394
and 850a9ce8bcca59c7, a distance of some 32 commits.

A reduction is running now and will be finishing in the next ten minutes.

gcc-12-20220528 is now available

[GCC Administrator via Gcc]

Snapshot gcc-12-20220528 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/12-20220528/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 12 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-12 revision c2476f7b22ea74ca8ebbec1c6a00ac5173d26599

You'll find:

 gcc-12-20220528.tar.xz   Complete GCC

  SHA256=aaca18bcfe0847aeae34c02c0e63ffa6a1304bb535fe3f3a2a283a39cb00599c
  SHA1=326f1e601c671fdc4d4a663f1ce18960f5fc775d

Diffs from 12-20220521 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-12
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[no subject]

[Randi Amon via Gcc]

randiam...@gmail.com

OMP_PLACES

[Mohamed Atef via Gcc]

Hello,
  if I want to dump elements of gomp_places_list
in a string

gomp_affinity_print_place (gomp_places_list[i]);
what does this function do ?
I read its body, it has only one line
(void) p;
should I call it before sprintf (temp_buffer, );

[Bug fortran/91300] Wrong runtime error message with allocate and errmsg=

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from anlauf at gcc dot gnu.org ---
Patch submitted: https://gcc.gnu.org/pipermail/fortran/2022-May/057887.html

[PATCH] PR fortran/91300 - runtime error message with allocate and errmsg=

[Harald Anlauf via Gcc-patches]

Dear Fortranners,

the PR rightfully complained that we did not differentiate errors on
ALLOCATE(...,stat=,errmsg=) for failures from allocation of already
allocated objects or insufficient virtual memory.

The attached patch introduces a new STAT value LIBERROR_NO_MEMORY
that is returned for insufficient virtual memory, and a corresponding
(simple and invariant) ERRMSG: "Insufficient virtual memory".

(In the PR Janne mentions checking for errno, but since the standard
malloc(3) only mentions ENOMEM as possible error value, and the user
may replace malloc by a special library, I believe that won't be easy
to handle in a general way.)

Most compilers I tried (Intel/NAG/Crayftn) behave similarly, except
for Nvidia/Flang, which try to return the size of the allocation in
the error message.

I am not sure that this is worth the effort.  First, ERRMSG is very
compiler-dependent anyway and thus not really portable.  If a user
wants to know what the size of the failed allocation is and really
wants to recover, he/she should find that out himself.  Second, I
think that the more important change is the introduction of a STAT
value that allows the distinction between the different causes of
failure.

The testcase should be able to handle 32 and 64 bit systems.
At least that's what I think.

Regtested on x86_64-pc-linux-gnu.  OK for mainline?  Suggestions?

Thanks,
Harald

From 19ccd22ee9359bd14b32a95bd9efcaead3593b2f Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Sat, 28 May 2022 22:02:20 +0200
Subject: [PATCH] Fortran: improve runtime error message with ALLOCATE and
 ERRMSG=

ALLOCATE: generate different STAT,ERRMSG results for failures from
allocation of already allocated objects or insufficient virtual memory.

gcc/fortran/ChangeLog:

	PR fortran/91300
	* libgfortran.h: Define new error code LIBERROR_NO_MEMORY.
	* trans-stmt.cc (gfc_trans_allocate): Generate code for setting
	ERRMSG depending on result of STAT result of ALLOCATE.
	* trans.cc (gfc_allocate_using_malloc): Use STAT value of
	LIBERROR_NO_MEMORY in case of failed malloc.

gcc/testsuite/ChangeLog:

	PR fortran/91300
	* gfortran.dg/allocate_alloc_opt_15.f90: New test.
---
 gcc/fortran/libgfortran.h |  1 +
 gcc/fortran/trans-stmt.cc | 33 +--
 gcc/fortran/trans.cc  |  4 +-
 .../gfortran.dg/allocate_alloc_opt_15.f90 | 40 +++
 4 files changed, 73 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/allocate_alloc_opt_15.f90

diff --git a/gcc/fortran/libgfortran.h b/gcc/fortran/libgfortran.h
index 064795eb469..4328447be04 100644
--- a/gcc/fortran/libgfortran.h
+++ b/gcc/fortran/libgfortran.h
@@ -133,6 +133,7 @@ typedef enum
   LIBERROR_CORRUPT_FILE,
   LIBERROR_INQUIRE_INTERNAL_UNIT, /* Must be different from STAT_STOPPED_IMAGE.  */
   LIBERROR_BAD_WAIT_ID,
+  LIBERROR_NO_MEMORY,
   LIBERROR_LAST			/* Not a real error, the last error # + 1.  */
 }
 libgfortran_error_codes;
diff --git a/gcc/fortran/trans-stmt.cc b/gcc/fortran/trans-stmt.cc
index 79096816c6e..fd6d294147e 100644
--- a/gcc/fortran/trans-stmt.cc
+++ b/gcc/fortran/trans-stmt.cc
@@ -7130,7 +7130,8 @@ gfc_trans_allocate (gfc_code * code)
   if (code->expr1 && code->expr2)
 {
   const char *msg = "Attempt to allocate an allocated object";
-  tree slen, dlen, errmsg_str;
+  const char *oommsg = "Insufficient virtual memory";
+  tree slen, dlen, errmsg_str, oom_str, oom_loc;
   stmtblock_t errmsg_block;

   gfc_init_block (_block);
@@ -7151,8 +7152,34 @@ gfc_trans_allocate (gfc_code * code)
 			 gfc_default_character_kind);
   dlen = gfc_finish_block (_block);

-  tmp = fold_build2_loc (input_location, NE_EXPR, logical_type_node,
-			 stat, build_int_cst (TREE_TYPE (stat), 0));
+  tmp = fold_build2_loc (input_location, EQ_EXPR, logical_type_node,
+			 stat, build_int_cst (TREE_TYPE (stat),
+		  LIBERROR_ALLOCATION));
+
+  tmp = build3_v (COND_EXPR, tmp,
+		  dlen, build_empty_stmt (input_location));
+
+  gfc_add_expr_to_block (, tmp);
+
+  oom_str = gfc_create_var (pchar_type_node, "OOMMSG");
+  oom_loc = gfc_build_localized_cstring_const (oommsg);
+  gfc_add_modify (_block, oom_str,
+		  gfc_build_addr_expr (pchar_type_node, oom_loc));
+
+  slen = build_int_cst (gfc_charlen_type_node, strlen (oommsg));
+  dlen = gfc_get_expr_charlen (code->expr2);
+  slen = fold_build2_loc (input_location, MIN_EXPR,
+			  TREE_TYPE (slen), dlen, slen);
+
+  gfc_trans_string_copy (_block, dlen, errmsg,
+			 code->expr2->ts.kind,
+			 slen, oom_str,
+			 gfc_default_character_kind);
+  dlen = gfc_finish_block (_block);
+
+  tmp = fold_build2_loc (input_location, EQ_EXPR, logical_type_node,
+			 stat, build_int_cst (TREE_TYPE (stat),
+		  LIBERROR_NO_MEMORY));

   tmp = build3_v (COND_EXPR, tmp,
 		  dlen, build_empty_stmt (input_location));
diff --git 

[Bug middle-end/105762] New: [12 Regression] -Warray-bounds false positives for integer-to-pointer casts

[roland at gnu dot org via Gcc-bugs]

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

Bug ID: 105762
   Summary: [12 Regression] -Warray-bounds false positives for
integer-to-pointer casts
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland at gnu dot org
  Target Milestone: ---

This code:

```
void crash(void) {  
  volatile int* ptr = (volatile int*)1ul;   
 *ptr = 1;  
}
```

now gets:

```
warning: array subscript 0 is outside array bounds of 'volatile int[0]'
[-Warray-bounds]
```

This is a regression since GCC 11.

Reproduced on aarch64-elf and x86_64-elf targets as of 12 branch commit
2c11a9a380e7af333e19d6e576a889646d699b2a

Re: [PATCH 1/2] avr: Added AVR-DA and DB MCU series

[Jeff Law via Gcc-patches]

On 4/1/2022 9:20 AM, Joel Holdsworth via Gcc-patches wrote:

gcc/
 * config/avr/avr-mcus.def: Add device definitions.
 * doc/avr-mmcu.texi: Corresponding changes.
 * gcc/config/avr/gen-avr-mmcu-texi.c: Added support for avr
   device prefix.
 * gcc/config/avr/gen-avr-mmcu-specs.c: Prevent -mmcu=avr* flags
   from leaking into cc1.
I fixed a few trivial issues with the ChangeLog and pushed this patch to 
the trunk.

jeff

Re: [PATCH] avr: add support for tinyAVR 2 family

[Jeff Law via Gcc-patches]

On 4/26/2022 8:59 AM, Torsten Duwe via Gcc-patches wrote:

Signed-off-by: Torsten Duwe 

---
gcc/ChangeLog:

2022-04-26  Torsten Duwe  

* config/avr/avr-mcus.def (AVR_MCU): add definitions for
attiny{4,8,16,32}2{4,6,7}; 4k and 8k flash types use RCALL.
Are these independent of patch from Joel Holdworth?  I think so, but I'm 
not at all familiar with the avr family of chips, so it'd be good if 
someone with more familiarity would chime in.


I think you need to update avr-mmcu.texi for the new chips as well.

jeff

Re: [PATCH 2/2] avr: Removed errant control characters

[Jeff Law via Gcc-patches]

On 4/1/2022 9:20 AM, Joel Holdsworth via Gcc-patches wrote:

Signed-off-by: Joel Holdsworth 
---
  gcc/config/avr/avr-devices.cc | 2 --
  1 file changed, 2 deletions(-)
These aren't really errant.  There was a time when these form feeds were 
actually encouraged and you'll find them all over the place in GCC.


I'd just assume remove them all at this point, but I think that would 
need broader consensus.


jeff

Re: [PATCH v3] DSE: Use the constant store source if possible

[Jeff Law via Gcc-patches]

On 5/26/2022 2:43 PM, H.J. Lu via Gcc-patches wrote:

On Thu, May 26, 2022 at 04:14:17PM +0100, Richard Sandiford wrote:

"H.J. Lu"  writes:

On Wed, May 25, 2022 at 12:30 AM Richard Sandiford
 wrote:

"H.J. Lu via Gcc-patches"  writes:

On Mon, May 23, 2022 at 12:38:06PM +0200, Richard Biener wrote:

On Sat, May 21, 2022 at 5:02 AM H.J. Lu via Gcc-patches
 wrote:

When recording store for RTL dead store elimination, check if the source
register is set only once to a constant.  If yes, record the constant
as the store source.  It eliminates unrolled zero stores after memset 0
in a loop where a vector register is used as the zero store source.

gcc/

 PR rtl-optimization/105638
 * dse.cc (record_store): Use the constant source if the source
 register is set only once.

gcc/testsuite/

 PR rtl-optimization/105638
 * g++.target/i386/pr105638.C: New test.
---
  gcc/dse.cc   | 19 ++
  gcc/testsuite/g++.target/i386/pr105638.C | 44 
  2 files changed, 63 insertions(+)
  create mode 100644 gcc/testsuite/g++.target/i386/pr105638.C

diff --git a/gcc/dse.cc b/gcc/dse.cc
index 30c11cee034..0433dd3d846 100644
--- a/gcc/dse.cc
+++ b/gcc/dse.cc
@@ -1508,6 +1508,25 @@ record_store (rtx body, bb_info_t bb_info)

   if (tem && CONSTANT_P (tem))
 const_rhs = tem;
+ else
+   {
+ /* If RHS is set only once to a constant, set CONST_RHS
+to the constant.  */
+ df_ref def = DF_REG_DEF_CHAIN (REGNO (rhs));
+ if (def != nullptr
+ && !DF_REF_IS_ARTIFICIAL (def)
+ && !DF_REF_NEXT_REG (def))
+   {
+ rtx_insn *def_insn = DF_REF_INSN (def);
+ rtx def_body = PATTERN (def_insn);
+ if (GET_CODE (def_body) == SET)
+   {
+ rtx def_src = SET_SRC (def_body);
+ if (CONSTANT_P (def_src))
+   const_rhs = def_src;

doesn't DSE have its own tracking of stored values?  Shouldn't we

It tracks stored values only within the basic block.  When RTL loop
invariant motion hoists a constant initialization out of the loop into
a separate basic block, the constant store value becomes unknown
within the original basic block.


improve _that_ if it is not enough?  I also wonder if you need to

My patch extends DSE stored value tracking to include the constant which
is set only once in another basic block.


verify the SET isn't partial?


Here is the v2 patch to check that the constant is set by a non-partial
unconditional load.

OK for master?

Thanks.

H.J.
---
RTL DSE tracks redundant constant stores within a basic block.  When RTL
loop invariant motion hoists a constant initialization out of the loop
into a separate basic block, the constant store value becomes unknown
within the original basic block.  When recording store for RTL DSE, check
if the source register is set only once to a constant by a non-partial
unconditional load.  If yes, record the constant as the constant store
source.  It eliminates unrolled zero stores after memset 0 in a loop
where a vector register is used as the zero store source.

gcc/

   PR rtl-optimization/105638
   * dse.cc (record_store): Use the constant source if the source
   register is set only once.

gcc/testsuite/

   PR rtl-optimization/105638
   * g++.target/i386/pr105638.C: New test.
---
  gcc/dse.cc   | 22 
  gcc/testsuite/g++.target/i386/pr105638.C | 44 
  2 files changed, 66 insertions(+)
  create mode 100644 gcc/testsuite/g++.target/i386/pr105638.C

diff --git a/gcc/dse.cc b/gcc/dse.cc
index 30c11cee034..af8e88dac32 100644
--- a/gcc/dse.cc
+++ b/gcc/dse.cc
@@ -1508,6 +1508,28 @@ record_store (rtx body, bb_info_t bb_info)

 if (tem && CONSTANT_P (tem))
   const_rhs = tem;
+   else
+ {
+   /* If RHS is set only once to a constant, set CONST_RHS
+  to the constant.  */
+   df_ref def = DF_REG_DEF_CHAIN (REGNO (rhs));
+   if (def != nullptr
+   && !DF_REF_IS_ARTIFICIAL (def)
+   && !(DF_REF_FLAGS (def)
+& (DF_REF_PARTIAL | DF_REF_CONDITIONAL))
+   && !DF_REF_NEXT_REG (def))

Can we introduce a helper for this?  There are already similar tests
in ira and loop-iv, and it seems a bit too complex to have to open-code
each time.

I can use find_single_def_src in loop-iv.cc:

/* If REGNO has a single definition, return its known value, otherwise return
null.  */

rtx
find_single_def_src (unsigned int regno)

Yeah, reusing that sounds good.  Perhaps we should move it into df-core.cc,
alongside the df_reg_used group of functions.

I think the mode check in your original patch should be kept though,
so how about we change the parameter to an rtx reg and use rtx_equal 

Re: [PATCH] sourcebuild.texi: Document new toplevel directories [PR82383]

[Jeff Law via Gcc-patches]

On 5/24/2022 11:32 AM, Eric Gallager via Gcc-patches wrote:

This patch adds entries for the c++tools, gotools, libbacktrace,
libcc1, libcody, liboffloadmic, and libsanitizer directories into the
list of toplevel source directories in sourcebuild.texi. I also
removed the entry for boehm-gc (which is no longer in-tree), and fixed
the alphabetization for libquadmath while I was at it. Any style nits
I need to fix before committing (with a proper ChangeLog entry)?
I think this is fine.  If you're looking for a good cleanup, removing 
liboffloadmic  would be useful IMHO.  MIC is dead.


jeff

Re: libatomic: drop redundant all-multi command

[Jeff Law via Gcc-patches]

On 5/27/2022 2:01 AM, Jan Beulich via Gcc-patches wrote:

./multilib.am already specifies this same command, and make warns about
the earlier one being ignored when seeing the later one. All that needs
retaining to still satisfy the preceding comment is the extra
dependency.

libatomic/
2022-05-XX  Jan Beulich  

* Makefile.am (all-multi): Drop commands.
* Makefile.in: Update accordingly.

OK for the trunk.
jeff

[Bug target/103722] [12/13 Regression] ICE in extract_constrain_insn building glibc for SH4

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

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

--- Comment #6 from Jeffrey A. Law  ---
Fixed on the trunk.  Backporting to the gcc-12 release branch should be safe if
someone wanted to do that.

[Bug c++/105761] ICE on hidden friend definition defined in base type

[johelegp at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Johel Ernesto Guerrero Peña  ---
Simplified: https://godbolt.org/z/66Gd84dos.

```C++
template 
class X {
  friend auto f(X);
};

struct Y : X {
  friend auto f(X) { return 0L; }
};
```

[Bug target/103722] [12/13 Regression] ICE in extract_constrain_insn building glibc for SH4

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jeff Law :

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

commit r13-813-gce1580252ea57de23a595e9804ea87ed4353aa6a
Author: Vladimir Makarov 
Date:   Sat May 28 12:08:38 2022 -0600

Fix ICE on sh

gcc/
PR target/103722
* config/sh/sh.cc (sh_register_move_cost): Avoid cost "2" (which
is special) for various scenarios.

[committed] [PR target/103722] Fix register_move_cost for the sh

[Jeff Law via Gcc-patches]

As outlined in the BZ the sh is returning cost 2 for various reg->reg 
moves.  Cost 2 has special meaning to reload and prevents the insns from 
being re-recognized.  Vlad's patch bumps the cost to 7.  Other values 
might be better, but given this has been languishing for ~6 months and 
there are no signs of an SH expert stepping in to provide a better 
value, I'm going with Vlad's patch from the PR as-is.


Committed to the trunk,
Jeffcommit 42d8fb2d4569e9930e277b01170bfd3586bf94d3
Author: Vladimir Makarov 
Date:   Sat May 28 12:08:38 2022 -0600

Fix ICE on sh

gcc/
PR target/103722
* config/sh/sh.c (sh_register_move_cost): Avoid cost "2" (which
is special) for various scenarios.

diff --git a/gcc/config/sh/sh.cc b/gcc/config/sh/sh.cc
index 8d4056338a5..03e1c04ec7e 100644
--- a/gcc/config/sh/sh.cc
+++ b/gcc/config/sh/sh.cc
@@ -10762,6 +10762,12 @@ sh_register_move_cost (machine_mode mode,
   && ! REGCLASS_HAS_GENERAL_REG (dstclass))
 return 2 * ((GET_MODE_SIZE (mode) + 7) / 8U);
 
+  if (((dstclass == FP_REGS || dstclass == DF_REGS)
+   && (srcclass == PR_REGS))
+  || ((srcclass == FP_REGS || srcclass == DF_REGS)
+ && (dstclass == PR_REGS)))
+return 7;
+
   return 2 * ((GET_MODE_SIZE (mode) + 3) / 4U);
 }
 

[Bug fortran/105759] is_contiguous(zero_size_array(2:0)) wrongly returns .true.

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #0)
> GCC and ifort both return T for the following code:
> 
> integer :: a(2)
> print *, is_contiguous(a(2:1))
> end
> 
> 
> However, I think that should be F / .false. as F2018 has:
> 
> 8.5.7 CONTIGUOUS attribute
> ...
> An object is contiguous if it is
> ...
> (7) a nonzero-sized array section (9.5.3) provided that
> ...
> 
> 
> Disclaimer: I might have missed something.
> 
> 
> If it is a bug, then we probably need to fix both the simplify.cc
> compile-time and libgfortran run-time check.

I think that you may be wrongly interpreting what the standard says.  (7)
clearly does not apply to your code because a(2:1) is a zero-sized array
section.

What I think you're missing from 22-007.pdf, page 104,

   It is processor dependent whether any other object is contiguous.

and a zero-sized entity falls under this statement.  Then on page 94, we have

   An empty sequence forms a zero-sized array.

As the sequence is empty, it can be neither contiguous nor discontiguous.

[Bug c++/105761] New: ICE on hidden friend definition defined in base type

[johelegp at gmail dot com via Gcc-bugs]

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

Bug ID: 105761
   Summary: ICE on hidden friend definition defined in base type
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johelegp at gmail dot com
CC: johelegp at gmail dot com
  Target Milestone: ---

See https://godbolt.org/z/v8arThEs1.

```C++
#include 

template class X {
  friend auto f(X);
};

template> struct downcast_t { using type = void;
};
template struct downcast_t{}))>> {
using type = decltype(f(X{})); };

template using downcast = typename downcast_t::type;

static_assert(std::is_same_v>);

struct Y : X {
  friend auto f(X) { return 0L; }
};

static_assert(std::is_same_v>);
```

```
:4:18: warning: friend declaration 'auto f(X)' declares a
non-template function [-Wnon-template-friend]
4 |   friend auto f(X);
  |  ^
:4:18: note: (if this is not what you intended, make sure the function
template has already been declared and add '<>' after the function name here)
:15:20: internal compiler error: in push_template_decl, at
cp/pt.cc:6125
   15 |   friend auto f(X) { return 0L; }
  |^
0x21ffa39 internal_error(char const*, ...)
  ???:0
0x7452f3 fancy_abort(char const*, int, char const*)
  ???:0
0x82a0cd start_preparsed_function(tree_node*, tree_node*, int)
  ???:0
0x98cb8d c_parse_file()
  ???:0
0xb21d91 c_common_parse_file()
  ???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
```

[Bug c++/105760] New: ICE: in build_function_type, at tree.cc:7365

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 105760
   Summary: ICE: in build_function_type, at tree.cc:7365
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

13 Regression

template
struct A { A(Ts...); };
A a;

https://godbolt.org/z/qeYGz1Yov

[Bug fortran/105759] New: is_contiguous(zero_size_array(2:0)) wrongly returns .true.

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

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

Bug ID: 105759
   Summary: is_contiguous(zero_size_array(2:0)) wrongly returns
.true.
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

GCC and ifort both return T for the following code:

integer :: a(2)
print *, is_contiguous(a(2:1))
end


However, I think that should be F / .false. as F2018 has:

8.5.7 CONTIGUOUS attribute
...
An object is contiguous if it is
...
(7) a nonzero-sized array section (9.5.3) provided that
...


Disclaimer: I might have missed something.


If it is a bug, then we probably need to fix both the simplify.cc compile-time
and libgfortran run-time check.

Re: Vim swap files not ignored

[Jeff Law via Gcc-patches]

On 5/25/2022 11:02 AM, Bruce Korb via Gcc-patches wrote:

Subject:
Vim swap files not ignored
From:
Bruce Korb via Gcc-patches 
Date:
5/25/2022, 11:02 AM

To:
gcc-patches@gcc.gnu.org


Hi,
I don't have the keys for write access anymore. This ought to be 
applied. Odd that it never has been. :)

Applied.  We can certainly get you fresh keys if you want them Bruce!

jeff

Re: [PATCH] Modula-2: merge proposal/review: 1/9 01.patch-set-01

[Gaius Mulley via Gcc-patches]

Richard Biener  writes:

> On Wed, May 25, 2022 at 9:50 PM Gaius Mulley  wrote:
>>
>> Richard Biener  writes:
>>
>> > So is there a reason to have the 'scaffold' separate from the object
>> > of hello.mod?
>>
>> Perhaps the major advantage is flexibility?  But no we can by default
>> produce the scaffold within the object of hello.mod (and give users the
>> ability to disable scaffold generation should they wish to implement
>> their own).
>>
>> > Is there more than a 1:1 relation between a .mod and the 'scaffold'?
>>
>> yes there is a 1:1 relation between a .mod and the scaffold.  Although
>> the caveat is that the compiler would need to parse every .def and .mod
>> imports from the application universe.  Not a major change as gm2 has
>> the ability to do whole program (application) compiling, so a minor set
>> of changes to ensure that upon compiling the program module that it also
>> parses every .def/.mod.
>>
>> > Why are multiple tools involved here - can the m2 frontend not parse
>> > imports, reorder runtime modules and generate the 'scaffold' as
>> > GENERIC IL as part of the translation unit of the .mod file?
>> > Indirection through emitting C++ source code makes the process a bit
>> > awkward IMHO.
>>
>> indeed the m2 front end can parse imports, reorder and generate the
>> scaffold.
>>
>> > Unfortunately I have no m2 installation around to look at how complex
>> > the 'scaffold' is.
>>
>> the scaffold is really simple for example here it is for hello.mod:
>>
>>   $ gm2 -c -g -fmakelist hello.mod
>>   $ cat hello.lst
>> Storage
>> SYSTEM
>> M2RTS
>> RTExceptions
>> # libc   11 
>> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/libc.def FOR 'C'
>> # SYSTEM   11 
>> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/SYSTEM.mod
>> # StrIO   11 
>> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/StrIO.mod
>> # StrLib   10 
>> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/StrLib.mod
>> # ASCII   10 
>> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/ASCII.mod
>> # NumberIO   10 
>> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/NumberIO.mod
>> # Indexing   10 
>> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/Indexing.mod
>> # errno9 
>> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/errno.def
>> # termios9 
>> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/termios.def
>> # FIO9 
>> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/FIO.mod
>> # IO8 /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/IO.mod
>> # StdIO7 
>> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/StdIO.mod
>> # Debug6 
>> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/Debug.mod
>> # SysStorage5 
>> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/SysStorage.mod
>> # SysExceptions4 
>> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/SysExceptions.def
>> # M2EXCEPTION4 
>> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/M2EXCEPTION.mod
>> # Storage4 
>> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/Storage.mod
>> # RTExceptions3 
>> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/RTExceptions.mod
>> # M2RTS2 
>> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/M2RTS.mod
>> # hello1 hello.mod
>> #
>> # Initialization order
>> #
>> StrIO
>> StrLib
>> ASCII
>> NumberIO
>> Indexing
>> errno
>> termios
>> FIO
>> IO
>> StdIO
>> Debug
>> SysStorage
>> SysExceptions
>> M2EXCEPTION
>> hello
>>
>>and now to generate the scaffold for a static application:
>>
>>$ ~/opt/bin/gm2 -fmakeinit -c -g hello.mod
>>$ cat hello_m2.cpp
>> extern "C" void exit(int);
>>
>> extern "C" void RTExceptions_DefaultErrorCatch(void);
>> extern "C" void _M2_Storage_init (int argc, char *argv[]);
>> extern "C" void _M2_Storage_finish (void);
>> extern "C" void _M2_SYSTEM_init (int argc, char *argv[]);
>> extern "C" void _M2_SYSTEM_finish (void);
>> extern "C" void _M2_M2RTS_init (int argc, char *argv[]);
>> extern "C" void _M2_M2RTS_finish (void);
>> extern "C" void _M2_RTExceptions_init (int argc, char *argv[]);
>> extern "C" void _M2_RTExceptions_finish (void);
>> extern "C" void _M2_StrIO_init (int argc, char *argv[]);
>> extern "C" void _M2_StrIO_finish (void);
>> extern "C" void _M2_StrLib_init (int argc, char *argv[]);
>> extern "C" void _M2_StrLib_finish (void);
>> extern "C" void _M2_ASCII_init (int argc, char *argv[]);
>> extern "C" void _M2_ASCII_finish (void);
>> extern "C" void _M2_NumberIO_init (int argc, char *argv[]);
>> extern "C" void _M2_NumberIO_finish (void);
>> extern "C" void _M2_Indexing_init (int argc, char *argv[]);
>> extern "C" void _M2_Indexing_finish (void);
>> extern "C" void _M2_errno_init (int argc, char *argv[]);
>> extern "C" void _M2_errno_finish (void);
>> extern "C" void _M2_termios_init (int argc, char *argv[]);
>> extern "C" void 

[Bug target/77311] bfin: error: unable to find a register to spill in class 'CCREGS'

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2022-05-28
 CC||law at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #1 from Jeffrey A. Law  ---
So my tester tripped over a similar, likely the same, problem starting about a
week ago.

After reviewing the bfin port I think it is fundamentally broken WRT its
handling of condition codes.

Let's say we have these two insns in the stream:

(insn 1711 1710 1717 139 (set (reg:BI 1203)
(ne:BI (reg:SI 977)
(const_int 0 [0]))) "k.c":18:12 130 {movsibi}
 (expr_list:REG_DEAD (reg:SI 977)
(nil)))

(insn 1717 1711 1726 139 (set (reg:BI 1204)
(reg:BI 34 CC)) "k.c":19:13 13 {movbi}
 (expr_list:REG_DEAD (reg:BI 34 CC)
(nil)))

r1203 is going to need to be allocated to the CC register.  But we can
trivially see that the CC register already has a live value in it by way of the
use at insn 1717.

So r1203 is going to have to be assigned to a GPR and LRA/reload will have to
fix things up.   Any sequence I can think of to do that will ultimately result
in clobbering CC.  But that's not valid because bfin has exposed CC prior to
allocation/reload.

This change from Richi is trigger for the fault I've seen, but I think the real
issue is the bfin port is just plain broken.

commit 68e0063397ba820e71adc220b2da0581dce29ffa (HEAD, refs/bisect/bad)
Author: Richard Biener 
Date:   Mon Apr 11 13:36:53 2022 +0200

Force the selection operand of a GIMPLE COND_EXPR to be a register

This goes away with the selection operand allowed to be a GENERIC
tcc_comparison tree.  It keeps those for vectorizer pattern recog,
those are short lived and removing this instance is a bigger task.

The patch doesn't yet remove dead code and functionality, that's
left for a followup.  Instead the patch makes sure to produce
valid GIMPLE IL and continue to optimize COND_EXPRs where the
previous IL allowed and the new IL showed regressions in the testsuite.

Here's the new failures just for reference.  But I suspect this will likely go
latent as some point given its sensitivity to instruction orderings and
register allocation.

bfin-sim: c-c++-common/torture/pr101636.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess
errors)
bfin-sim: c-c++-common/torture/pr101636.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess
errors)
bfin-sim: c-c++-common/torture/pr101636.c   -O3 -g  (test for excess errors)
bfin-sim: c-c++-common/torture/pr101636.c   -O3 -g  (test for excess errors)

[Bug libbacktrace/105721] libbacktrace: update README

[ian at airs dot com via Gcc-bugs]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
 CC||ian at airs dot com

--- Comment #2 from Ian Lance Taylor  ---
Thanks, fixed.

libbacktrace patch committed: Update README

[Ian Lance Taylor via Gcc-patches]

This patch updates the libbacktrace README to a near copy of the one
from github.com/ianlancetaylor/libbacktrace.  Committed to mainline.
This fixes GCC PR 105721.

Ian

* README: Update.
6cf19361732bd7f8b41716ef9f4b5c205a3193b8
diff --git a/libbacktrace/README b/libbacktrace/README
index e8b225745c9..6225f92b855 100644
--- a/libbacktrace/README
+++ b/libbacktrace/README
@@ -1,23 +1,31 @@
 The libbacktrace library
-Initially written by Ian Lance Taylor 
+Initially written by Ian Lance Taylor 
 
 The libbacktrace library may be linked into a program or library and
-used to produce symbolic backtraces.  Sample uses would be to print a
-detailed backtrace when an error occurs or to gather detailed
-profiling information.
+used to produce symbolic backtraces.
+Sample uses would be to print a detailed backtrace when an error
+occurs or to gather detailed profiling information.
+In general the functions provided by this library are async-signal-safe,
+meaning that they may be safely called from a signal handler.
 
-The libbacktrace library is provided under a BSD license.  See the
-source files for the exact license text.
+The libbacktrace library is provided under a BSD license.
+See the source files for the exact license text.
 
 The public functions are declared and documented in the header file
 backtrace.h, which should be #include'd by a user of the library.
 
 Building libbacktrace will generate a file backtrace-supported.h,
 which a user of the library may use to determine whether backtraces
-will work.  See the source file backtrace-supported.h.in for the
-macros that it defines.
+will work.
+See the source file backtrace-supported.h.in for the macros that it
+defines.
 
-As of September 2012, libbacktrace only supports ELF executables with
-DWARF debugging information.  The library is written to make it
-straightforward to add support for other object file and debugging
-formats.
+As of October 2020, libbacktrace supports ELF, PE/COFF, Mach-O, and
+XCOFF executables with DWARF debugging information.
+In other words, it supports GNU/Linux, *BSD, macOS, Windows, and AIX.
+The library is written to make it straightforward to add support for
+other object file and debugging formats.
+
+The library relies on the C++ unwind API defined at
+https://itanium-cxx-abi.github.io/cxx-abi/abi-eh.html
+This API is provided by GCC and clang.

[Bug libbacktrace/105721] libbacktrace: update README

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Ian Lance Taylor :

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

commit r13-811-gf535f9d7b05db6fa02e90c90173c597d1972faa1
Author: Ian Lance Taylor 
Date:   Sat May 28 07:57:32 2022 -0700

libbacktrace: update README

PR libbacktrace/105721
* README: Update.

Re: [PATCH] Add divide by zero side effect.

[Eric Gallager via Gcc-patches]

On Fri, May 27, 2022 at 3:57 PM Andrew MacLeod via Gcc-patches
 wrote:
>
> On 5/27/22 15:33, Andi Kleen wrote:
> > Andrew MacLeod via Gcc-patches  writes:
> >> diff --git a/gcc/gimple-range-side-effect.cc 
> >> b/gcc/gimple-range-side-effect.cc
> >> index 2c8c77dc569..548e4bea313 100644
> >> --- a/gcc/gimple-range-side-effect.cc
> >> +++ b/gcc/gimple-range-side-effect.cc
> >> @@ -116,6 +116,23 @@ stmt_side_effects::stmt_side_effects (gimple *s)
> >>   walk_stmt_load_store_ops (s, (void *)this, non_null_loadstore,
> >>non_null_loadstore);
> >>
> >> +  if (is_a (s))
> >> +{
> >> +  switch (gimple_assign_rhs_code (s))
> >> +{
> >> +case TRUNC_DIV_EXPR:
> >> +case CEIL_DIV_EXPR:
> >> +case FLOOR_DIV_EXPR:
> >> +case ROUND_DIV_EXPR:
> >> +case EXACT_DIV_EXPR:
> >> +  // Divide means operand 2 is not zero after this stmt.
> >> +  if (gimple_range_ssa_p (gimple_assign_rhs2 (s)))
> >> +add_nonzero (gimple_assign_rhs2 (s));
> > Sorry I'm late, but how does this ensure the value is a integer?
> > I believe for floating point the assumption is not correct because
> > division by zero doesn't necessarily fault.
> >
> > -Andi
> >
> gimple_range_ssa_p() only returns non-zero when the value is an ssa_name
> whose type is supported by the range calculators... currently only
> integrals values.  When we support floating points we will have to add
> additional logic.
>

Maybe add a comment to that effect, then? As a reminder...

> Andrew
>

[Bug c++/105758] [12/13 Regression] ICE in build_baselink since r12-6897

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |12.2
 CC||ppalka at gcc dot gnu.org
   Priority|P3  |P2

[Bug c++/105758] New: [12/13 Regression] ICE in build_baselink since r12-6897

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

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

Bug ID: 105758
   Summary: [12/13 Regression] ICE in build_baselink since
r12-6897
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Starting with r12-6897-gdec8d0e5fa00ceb2ded78b8a3eba8976d860a90e we ICE with
-std=c++11 on the following testcase:
struct A {
  template  void foo(D, T, int);
};
template 
struct Z : A {
  static Z *z;
  void bar();
};
template 
Z *Z::z;
template 
void Z::bar() {
  int a = 0, b = 1, c = 2;
  z->foo(a, b, c);
}

[Bug c++/105757] New: default argument of incomplete type with C++20

[fsb4000 at yandex dot ru via Gcc-bugs]

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

Bug ID: 105757
   Summary: default argument of incomplete type with C++20
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fsb4000 at yandex dot ru
  Target Milestone: ---

Hi!

One user reported that some code doesn't work with current MSVC but worked
before and works with gcc.

Reduced code:

template 
struct A {
constexpr A() {}
constexpr ~A() { T t; }
};

struct B;
void f(const A& = {});

$ g++ -std=c++20 -c main.cpp

https://gcc.godbolt.org/z/jWdd3Gc5h

MSVC devs think that the code is not valid and I decided to inform you:

Cameron DaCamara: "I'm pretty convinced this is a source bug and that GCC
hasn't quite implemented
P0859R0(https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0859r0.html)
fully yet. The reason this is now observable with newer MSVC versions is
because the compiler is required to instantiate special member functions if
they could be potentially used for constant evaluation. Since the default
argument here is going to end up being assigned to a variable the ctor and dtor
are actually odr-used in the default argument."


Also if we reformat the code slightly(A{} instead of {}) then it is rejected
by gcc:

template 
struct A {
constexpr A() {}
constexpr ~A() { T t; }
};

struct B;
void f(const A& = A{});

$ g++ -std=c++20 -c main.cpp
main.cpp: In instantiation of 'constexpr A::~A() [with T = B]':
main.cpp:9:27:   required from here
main.cpp:5:24: error: 'B t' has incomplete type
5 | constexpr ~A() { T t; }
  |


My GCC version:

$ g++ -v
Using built-in specs.
COLLECT_GCC=C:\tools\msys64\mingw64\bin\g++.exe
COLLECT_LTO_WRAPPER=C:/tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.1.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-12.1.0/configure --prefix=/mingw64
--with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
--with-native-system-header-dir=/mingw64/include --libexecdir=/mingw64/lib
--enable-bootstrap --enable-checking=release --with-arch=x86-64
--with-tune=generic --enable-languages=c,lto,c++,fortran,ada,objc,obj-c++,jit
--enable-shared --enable-static --enable-libatomic --enable-threads=posix
--enable-graphite --enable-fully-dynamic-string
--enable-libstdcxx-filesystem-ts --enable-libstdcxx-time
--disable-libstdcxx-pch --enable-lto --enable-libgomp --disable-multilib
--disable-rpath --disable-win32-registry --disable-nls --disable-werror
--disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64
--with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64
--with-pkgversion='Rev2, Built by MSYS2 project'
--with-bugurl=https://github.com/msys2/MINGW-packages/issues --with-gnu-as
--with-gnu-ld --disable-libstdcxx-debug --with-boot-ldflags=-static-libstdc++
--with-stage1-ldflags=-static-libstdc++
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.1.0 (Rev2, Built by MSYS2 project)

[pushed] Darwin: Amend REAL_LIBGCC_SPEC comment [NFC].

[Iain Sandoe via Gcc-patches]

This comment had got out of sync with reality, partly due to merging
of patches.  Updated to reflect the current implementation.

Signed-off-by: Iain Sandoe 

gcc/ChangeLog:

* config/darwin.h (REAL_LIBGCC_SPEC): Update the comment block
describing this macro.
---
 gcc/config/darwin.h | 38 +-
 1 file changed, 13 insertions(+), 25 deletions(-)

diff --git a/gcc/config/darwin.h b/gcc/config/darwin.h
index 3682bd2b2c5..b73e12372d8 100644
--- a/gcc/config/darwin.h
+++ b/gcc/config/darwin.h
@@ -465,48 +465,36 @@ extern GTY(()) int darwin_ms_struct;
 
 #define LIB_SPEC "%{!static:-lSystem}"
 
-/*
-   Note that by default, -lgcc_eh is not linked against.
-   This is because,in general, we need to unwind through system libraries that
-   are linked with the shared unwinder in libunwind (or libgcc_s for 10.4/5).
+/* Note that by default, -lgcc_eh (which provides a statically-linked unwinder)
+   is not used. This is because, in general, we need to unwind through system
+   libraries that are linked with the shared unwinder in libunwind (or libgcc_s
+   for OSX 10.4/5 [darwin8/9]).
 
-   For -static-libgcc: < 10.6, use the unwinder in libgcc_eh (and find
-   the emultls impl. there too).
+   When -static-libgcc is forced: < 10.6, use the unwinder in libgcc_eh (and
+   find the emultls impl. there too).
 
For -static-libgcc: >= 10.6, the unwinder *still* comes from libSystem and
we find the emutls impl from lemutls_w. In either case, the builtins etc.
-   are linked from -lgcc.
+   are linked from -lgcc.  The eh library is still available so that it could
+   be specified explicitly if there is some reason to do so.
 
When we have specified shared-libgcc or any case that might require
exceptions, we pull the libgcc content (including emulated tls) from
-   -lgcc_s.1 in GCC and the unwinder from /usr/lib/libgcc_s.1 for < 10.6 and
+   -lgcc_s.1.1 in GCC and the unwinder from /usr/lib/libgcc_s.1 for < 10.6 and
libSystem for >= 10.6 respectively.
Otherwise, we just link the emutls/builtins from convenience libs.
 
-   If we need exceptions, prior to 10.3.9, then we have to link the static
-   eh lib, since there's no shared version on the system.
-
-   In all cases, libgcc_s.1 will be installed with the compiler, or any app
-   built using it, so we can link the builtins and emutls shared on all.
-
We have to work around that DYLD_ are disabled in macOS 10.11+ which
means that any bootstrap trying to use a shared libgcc with a bumped SO-
name will fail.  This means that we do not accept shared libgcc for these
-   versions.
+   versions (the primary reason for forcing a shared libgcc was that it
+   contained the unwinder on Darwin8 and 9).
 
-   For -static-libgcc: >= 10.6, the unwinder *still* comes from libSystem and
-   we find the emutls impl from lemutls_w. In either case, the builtins etc.
-   are linked from -lgcc.
->
-   Otherwise, we just link the shared version of gcc_s.1.1 and pick up
-   exceptions:
+   When using the shared version of gcc_s.1.1 the unwinder is provided by:
  * Prior to 10.3.9, then we have to link the static eh lib, since there
-   is no shared version on the system.
+   is no shared unwinder version on the system.
  * from 10.3.9 to 10.5, from /usr/lib/libgcc_s.1.dylib
  * from 10.6 onwards, from libSystem.dylib
-
-   In all cases, libgcc_s.1.1 will be installed with the compiler, or any app
-   built using it, so we can link the builtins and emutls shared on all.
 */
 #undef REAL_LIBGCC_SPEC
 #define REAL_LIBGCC_SPEC \
-- 
2.24.3 (Apple Git-128)

[Bug middle-end/98865] Missed transform of (a >> 63) * b

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com
 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |13.0

--- Comment #9 from Roger Sayle  ---
This is now fixed/implemented on mainline for GCC 13.

[Bug c++/105756] [12/13 Regression] ICE in cxx_eval_constant_expression at cp/constexpr.cc:7586: unexpected expression ‘ElemSize’ of kind template_parm_index

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||jakub at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org
   Priority|P3  |P2
 Ever confirmed|0   |1
   Target Milestone|--- |12.2
   Last reconfirmed||2022-05-28

--- Comment #2 from Jakub Jelinek  ---
Started with r12-7564-gec0f53a3a542e762f8fc8 aka PR104823 fix.

Re: libiberty: Would it be reasonable to add support for GnuCOBOL function name demangling?

[Simon Sobisch via Gcc-patches]

Am 27.05.22 um 20:31 schrieb Eric Gallager:

On Fri, May 27, 2022 at 3:17 AM Simon Sobisch via Gcc-patches
 wrote:

[...] the first question is: is it reasonable to add support for
GnuCOBOL?

* How would the demangler know it is to be called? Just "best match"
(GnuCOBOL modules always have some symbols in it which should be
available if there is any debugging information in, if that helps)?
* Giving the work of gcc-cobol which was discussed on this mailing list
some months ago (not sure about its current state) there possibly will
be a COBOL support be "integrated" - with possibly different name
mangling. But still - GnuCOBOL is used "in the wild" (for production
environments) since years (and will be for many years to come, both
based on GCC and with other compilers) and the name mangling rules did
not change.

If the plan is to integrate GnuCOBOL into trunk, then I'd say adding
demangling support for it to libiberty would not only be reasonable,
but also a necessary prerequisite for merging the rest of it.


Just to ensure that there aren't confusions:

Nobody intends to integrate GnuCOBOL [0] into gcc; but it would be 
important for gcobol for being integrated into gcc to succeed.


GnuCOBOL (formerly OpenCOBOL) is a project which translates COBOL to 
intermediate C (mostly consisting of calls to functions in the GnuCOBOL 
runtime library libcob), then executes the "native" / system C compiler.
It is very mature and used a lot; we _suggest_ to use GCC but also work 
with other free and nonfree compilers on free and nonfree systems.


gcobol [1][2] (I've also seen it referenced as gcc-cobol) is an actual 
gcc frontend, so translates into gcc intermediate format. As far as I 
know, the plans are to both provide a usable working COBOL compiler and 
reach a state for integration until 2023. It possibly will use a very 
small but important part of libcob (at least if available) to provide 
support of a COBOL-native way to read/write data.
When it comes up to the integration phase it _could_ be considered to 
integrate only those parts as-is (so effectively forking libcob to 
glibcob), as both GCC and GnuCOBOL are FSF-Copyrighted - or add it as an 
optional dependency (a lot of COBOL users don't use that 'old' way of 
accessing data and moved to EXEC SQL preprocessors instead).


But as GnuCOBOL maintainer my question here was about the GnuCOBOL name 
mangling.
I've now learned that as there isn't an explicit prefix like Z_ the 
de-mangling will be an "upon request", and as far as current responses 
were it seems like an reasonable approach and "patches to add that are 
likely to be accepted" (otherwise I won't start, because obviously there 
is always something to do on the GnuCOBOL side, too).


Simon

[0]: http://www.gnu.org/software/gnucobol

[1]: https://gcc.gnu.org/pipermail/gcc/2022-March/238408.html
[2]: https://git.symas.net/cobolworx/gcc-cobol/-/tree/master+cobol/gcc/cobol

Re: Passing c blocks to pre processor

[Jonathan Wakely via Gcc]

On Sat, 28 May 2022, 06:49 Yair Lenga via Gcc,  wrote:

> Hi,
>
> I am trying to define macros that will accept code blocks. This will be
> used to create high level structures (like iterations, etc.). Ideally, I
> would like to do something like (this is simplified example, actual code
> much more application specific):
>
> Foreach(var, low, high, block)
>
> While should translate to:
> For (int var=low ; var < high ; var ++) block
>
> The challnge is the gcc pre processor does not accept blocks. It assume a
> comma terminate a block. For example:
> Foreach(foo, 1, 30, { int z=5, y=3, …}) will invoke the macro with 5
> arguments: (1) foo (2) 1, (3) 30, (4) { int z=5}, (5) y=3,
>
> Is there a way to tell CPP that an argument that start with ‘{‘ should
> extend until the matching ‘}’ ? Similar to the way ‘(‘ in macro arguments
> will extend till matching ‘)’.
>


This question seems off-topic on this mailing list, as it's not about GCC
development. It would be more suited to the gcc-help list.

I don't think you can do that. You need to use __VA_ARGS__ to accept
arbitrary code containing commas. You could look at how the
Boost.Preprocessor library works.

Re: [PATCH] Support multilib-aware target lib flags self-specs overriding

[Alexandre Oliva via Gcc-patches]

On May 20, 2022, Alexandre Oliva  wrote:

> Regstrapped on x86_64-linux-gnu.  Ok to install?

Ping?  https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595356.html

> for  gcc/ChangeLog

>   * common.opt (multiflags): New.
>   * doc/invoke.texi: Document it.
>   * gcc.cc (driver_self_specs): Discard it.
>   * opts.cc (common_handle_option): Ignore it in the driver.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [MRISC32] Not getting scaled index addressing in loops

[m]

I'm sorry about the messed up code formatting (I blame the WYSIWYG). I 
hope the message gets through anyway (have a look at the Compiler 
Explorer link - https://godbolt.org/z/drzfjsxf7 - it has all the code).


/Marcus

[Bug c++/105756] [12/13 Regression] ICE in cxx_eval_constant_expression at cp/constexpr.cc:7586: unexpected expression ‘ElemSize’ of kind template_parm_index

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

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

Sergei Trofimovich  changed:

   What|Removed |Added

Summary|ICE in  |[12/13 Regression] ICE in
   |cxx_eval_constant_expressio |cxx_eval_constant_expressio
   |n at cp/constexpr.cc:7586:  |n at cp/constexpr.cc:7586:
   |unexpected expression   |unexpected expression
   |‘ElemSize’ of kind  |‘ElemSize’ of kind
   |template_parm_index |template_parm_index

--- Comment #1 from Sergei Trofimovich  ---
g++-11.3.0 builds the example file. Let's declare it a possible gcc-12
regression.

[MRISC32] Not getting scaled index addressing in loops

[m]

Hello!

I maintain a fork of GCC which adds support for my custom CPU ISA, 
MRISC32 (the machine description can be found here: 
https://github.com/mrisc32/gcc-mrisc32/tree/mbitsnbites/mrisc32/gcc/config/mrisc32 
).


I recently discovered that scaled index addressing (i.e. MEM[base + 
index * scale]) does not work inside loops, but I have not been able to 
figure out why.


I believe that I have all the plumbing in the MD that's required 
(MAX_REGS_PER_ADDRESS, REGNO_OK_FOR_BASE_P, REGNO_OK_FOR_INDEX_P, etc), 
and I have verified that scaled index addressing is used in trivial 
cases like this:


charcarray[100];
shortsarray[100];
intiarray[100];
voidsingle_element(intidx, intvalue) {
carray[idx] = value; // OK
sarray[idx] = value; // OK
iarray[idx] = value; // OK
}

...which produces the expected machine code similar to this:

stbr2, [r3, r1] // OK
sthr2, [r3, r1*2] // OK
stwr2, [r3, r1*4] // OK

However, when the array assignment happens inside a loop, only the char 
version uses index addressing. The other sizes (short and int) will be 
transformed into code where the addresses are stored in registers that 
are incremented by +2 and +4 respectively.


voidloop(void) {
for(intidx = 0; idx < 100; ++idx) {
carray[idx] = idx; // OK
sarray[idx] = idx; // BAD
iarray[idx] = idx; // BAD
}
} ...which produces:
.L4:
sthr1, [r3] // BAD
stwr1, [r2] // BAD
stbr1, [r5, r1] // OK
addr1, r1, #1
sner4, r1, #100
addr3, r3, #2 // (BAD)
addr2, r2, #4 // (BAD)
bsr4, .L4

I would expect scaled index addressing to be used in loops too, just as 
is done for AArch64 for instance. I have dug around in the machine 
description, but I can't really figure out what's wrong.


For reference, here is the same code in Compiler Explorer, including the 
code generated for AArch64 for comparison: https://godbolt.org/z/drzfjsxf7


Passing -da (dump RTL all) to gcc, I can see that the decision to not 
use index addressing has been made already in *.253r.expand.


Does anyone have any hints about what could be wrong and where I should 
start looking?


Regards,

  Marcus

[Bug c++/105756] New: ICE in cxx_eval_constant_expression at cp/constexpr.cc:7586: unexpected expression ‘ElemSize’ of kind template_parm_index

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

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

Bug ID: 105756
   Summary: ICE in cxx_eval_constant_expression at
cp/constexpr.cc:7586: unexpected expression ‘ElemSize’
of kind template_parm_index
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

Originally reported by tt_1 at https://bugs.gentoo.org/847601 on 0ad-0.0.25b
project.

I see two similar ICEs in bugzilla but not sure they are the happening in same
area. Here is the minimized example that seems to be buildable by clang:

  // $ cat RegExp.cpp.cpp
  template  decltype(0 % ElemSize == 0) a;


$ g++ -o RegExp.o -c  -O2  RegExp.cpp.cpp
RegExp.cpp.cpp:1:47: internal compiler error: unexpected expression ‘ElemSize’
of kind template_parm_index
1 | template  decltype(0 % ElemSize == 0) a;
  |  ~^~~~
0xa39bb3 cxx_eval_constant_expression
../../gcc-13-20220522/gcc/cp/constexpr.cc:7586
0xa39eab cxx_eval_outermost_constant_expr
../../gcc-13-20220522/gcc/cp/constexpr.cc:7823
0xa3cc89 potential_constant_expression_1
../../gcc-13-20220522/gcc/cp/constexpr.cc:9272
0xa3d8a9 potential_constant_expression_1(tree_node*, bool, bool, bool, int)
../../gcc-13-20220522/gcc/cp/constexpr.cc:9548
0xa3d8a9 is_constant_expression(tree_node*)
../../gcc-13-20220522/gcc/cp/constexpr.cc:9605
0xa3d8a9 is_nondependent_constant_expression(tree_node*)
../../gcc-13-20220522/gcc/cp/constexpr.cc:9642
0xa3e83f maybe_constant_value(tree_node*, tree_node*, bool)
../../gcc-13-20220522/gcc/cp/constexpr.cc:8069
0xa6dea4 cp_fully_fold(tree_node*)
../../gcc-13-20220522/gcc/cp/cp-gimplify.cc:2353
0xa6dea4 cp_fully_fold(tree_node*)
../../gcc-13-20220522/gcc/cp/cp-gimplify.cc:2345
0xc6a059 cp_build_binary_op(op_location_t const&, tree_code, tree_node*,
tree_node*, int)
../../gcc-13-20220522/gcc/cp/typeck.cc:6260
0xa09a50 build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node**, int)
../../gcc-13-20220522/gcc/cp/call.cc:6930
0xc5d87e build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node*, tree_node**, int)
../../gcc-13-20220522/gcc/cp/typeck.cc:4563
0xbcfba1 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-13-20220522/gcc/cp/pt.cc:20347
0xbd4c27 instantiate_non_dependent_expr_internal(tree_node*, int)
../../gcc-13-20220522/gcc/cp/pt.cc:6366
0xbd4c27 instantiate_non_dependent_expr_sfinae(tree_node*, int)
../../gcc-13-20220522/gcc/cp/pt.cc:6387
0xc2d789 finish_decltype_type(tree_node*, bool, int)
../../gcc-13-20220522/gcc/cp/semantics.cc:11297
0xb837d1 cp_parser_decltype
../../gcc-13-20220522/gcc/cp/parser.cc:16578
0xb9cd49 cp_parser_simple_type_specifier
../../gcc-13-20220522/gcc/cp/parser.cc:19693
0xb78a07 cp_parser_type_specifier
../../gcc-13-20220522/gcc/cp/parser.cc:19470
0xb79a21 cp_parser_decl_specifier_seq
../../gcc-13-20220522/gcc/cp/parser.cc:15940
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.

$ g++ -v
Using built-in specs.
COLLECT_GCC=/<>/gcc-debug-13.0.0/bin/g++
COLLECT_LTO_WRAPPER=/<>/gcc-debug-13.0.0/libexec/gcc/x86_64-unknown-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with:
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220522 (experimental) (GCC)

[committed] libgomp: Don't define GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC for _aligned_malloc [PR105745]

[Jakub Jelinek via Gcc-patches]

since apparently _aligned_malloc requires freeing with _aligned_free and:
 /* Defined if gomp_aligned_alloc doesn't use fallback version
and free can be used instead of gomp_aligned_free.  */
 #define GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC 1
so the second condition isn't satisfied.  For uses inside of the OpenMP
allocators we can still use _aligned_malloc but we need to call _aligned_free
in gomp_aligned_free.

Bootstrapped/regtested on x86_64-linux and i686-linux (no way to test on
mingw), committed to trunk.

2022-05-28  Jakub Jelinek  

PR libgomp/105745
* libgomp.h (GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC): Don't define for
defined(HAVE__ALIGNED_MALLOC) case.
* alloc.c (gomp_aligned_alloc): Move defined(HAVE__ALIGNED_MALLOC)
handling as last option before fallback instead of first.
(gomp_aligned_free): For defined(HAVE__ALIGNED_MALLOC) call
_aligned_free.

--- libgomp/libgomp.h.jj2022-05-23 21:44:48.941848475 +0200
+++ libgomp/libgomp.h   2022-05-27 13:11:55.576057315 +0200
@@ -87,7 +87,6 @@ enum memmodel
 /* alloc.c */
 
 #if defined(HAVE_ALIGNED_ALLOC) \
-|| defined(HAVE__ALIGNED_MALLOC) \
 || defined(HAVE_POSIX_MEMALIGN) \
 || defined(HAVE_MEMALIGN)
 /* Defined if gomp_aligned_alloc doesn't use fallback version
--- libgomp/alloc.c.jj  2022-01-11 22:31:41.361758955 +0100
+++ libgomp/alloc.c 2022-05-27 13:15:32.151816509 +0200
@@ -65,9 +65,7 @@ gomp_aligned_alloc (size_t al, size_t si
   void *ret;
   if (al < sizeof (void *))
 al = sizeof (void *);
-#ifdef HAVE__ALIGNED_MALLOC
-  ret = _aligned_malloc (size, al);
-#elif defined(HAVE_MEMALIGN)
+#ifdef HAVE_MEMALIGN
   {
 extern void *memalign (size_t, size_t);
 ret = memalign (al, size);
@@ -83,6 +81,8 @@ gomp_aligned_alloc (size_t al, size_t si
 else
   ret = NULL;
   }
+#elif defined(HAVE__ALIGNED_MALLOC)
+  ret = _aligned_malloc (size, al);
 #else
   ret = NULL;
   if ((al & (al - 1)) == 0 && size)
@@ -106,6 +106,8 @@ gomp_aligned_free (void *ptr)
 {
 #ifdef GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC
   free (ptr);
+#elif defined(HAVE__ALIGNED_MALLOC)
+  _aligned_free (ptr);
 #else
   if (ptr)
 free (((void **) ptr)[-1]);

Jakub

[Bug preprocessor/105732] [10/11/12/13 Regression] internal compiler error: unspellable token PADDING

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

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

--- Comment #13 from Jakub Jelinek  ---
Not entirely. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732#c8 will work
there, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732#c9 does not.

[Bug libgomp/105745] [12/13 Regression] Conditional OpenMP directive fails with GCC 12

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

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

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

https://gcc.gnu.org/g:42fd2cd932384288914174f4af7974a060972bff

commit r13-808-g42fd2cd932384288914174f4af7974a060972bff
Author: Jakub Jelinek 
Date:   Sat May 28 08:30:47 2022 +0200

libgomp: Don't define GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC for _aligned_malloc
[PR105745]

since apparently _aligned_malloc requires freeing with _aligned_free and:
 /* Defined if gomp_aligned_alloc doesn't use fallback version
and free can be used instead of gomp_aligned_free.  */
 #define GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC 1
so the second condition isn't satisfied.  For uses inside of the OpenMP
allocators we can still use _aligned_malloc but we need to call
_aligned_free
in gomp_aligned_free.

2022-05-28  Jakub Jelinek  

PR libgomp/105745
* libgomp.h (GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC): Don't define for
defined(HAVE__ALIGNED_MALLOC) case.
* alloc.c (gomp_aligned_alloc): Move defined(HAVE__ALIGNED_MALLOC)
handling as last option before fallback instead of first.
(gomp_aligned_free): For defined(HAVE__ALIGNED_MALLOC) call
_aligned_free.

[COMMITTED] [Ada, build] Rename OSCONS_CC to GCC_FOR_ADA_RTS

[Alexandre Oliva via Gcc-patches]

Several gnatlib* targets perform, with a subshell and sed, the same
GCC_FOR_TARGET pathname transformation that OSCONS_CC performs with
make subst macros.  Rename OSCONS_CC to a more general name, and use
it for gnatlib as well.

Tested on x86_64-linux-gnu, checking in.


for  gcc/ada/ChangeLog

* gcc-interface/Makefile (OSCONS_CC): Rename to...
(GCC_FOR_ADA_RTS): ... this.  Adjust users.
(gnatlib): Pass it down as CC.
(gnatlib-shared-default): Likewise.
(gnatlib-shared-win32, gnatlib-shared-darwin): Likewise.
---
 gcc/ada/gcc-interface/Makefile.in |   32 
 1 file changed, 12 insertions(+), 20 deletions(-)

diff --git a/gcc/ada/gcc-interface/Makefile.in 
b/gcc/ada/gcc-interface/Makefile.in
index 1e9801a8b961d..8c34f421adfc7 100644
--- a/gcc/ada/gcc-interface/Makefile.in
+++ b/gcc/ada/gcc-interface/Makefile.in
@@ -588,9 +588,9 @@ install-gnatlib: ../stamp-gnatlib-$(RTSDIR) 
install-gcc-specs
touch ../stamp-gnatlib1-$(RTSDIR)
 
 # GCC_FOR_TARGET has paths relative to the gcc directory, so we need to adjust
-# for running it from ada/rts
+# for running it from ada/rts.
 
-OSCONS_CC=$(subst ./xgcc,../../xgcc,$(subst -B./, -B../../,$(GCC_FOR_TARGET)))
+GCC_FOR_ADA_RTS=$(subst ./xgcc,../../xgcc,$(subst -B./, 
-B../../,$(GCC_FOR_TARGET)))
 
 # The main ada source directory must be on the include path for #include "..."
 # because s-oscons-tmplt.c requires adaint.h, gsocket.h, and any file included
@@ -598,9 +598,9 @@ OSCONS_CC=$(subst ./xgcc,../../xgcc,$(subst -B./, 
-B../../,$(GCC_FOR_TARGET)))
 # ada/types.h does not conflict with a same-named system header (VxWorks
 # has a  header).
 
-OSCONS_CPP=$(OSCONS_CC) $(GNATLIBCFLAGS_FOR_C) -E -C \
+OSCONS_CPP=$(GCC_FOR_ADA_RTS) $(GNATLIBCFLAGS_FOR_C) -E -C \
   -DTARGET=\"$(target_noncanonical)\" -iquote $(fsrcpfx)ada 
$(fsrcpfx)ada/s-oscons-tmplt.c > s-oscons-tmplt.i
-OSCONS_EXTRACT=$(OSCONS_CC) $(GNATLIBCFLAGS_FOR_C) -S s-oscons-tmplt.i
+OSCONS_EXTRACT=$(GCC_FOR_ADA_RTS) $(GNATLIBCFLAGS_FOR_C) -S s-oscons-tmplt.i
 
 # Note: if you need to build with a non-GNU compiler, you could adapt the
 # following definitions (written for VMS DEC-C)
@@ -629,8 +629,7 @@ gnatlib: ../stamp-gnatlib1-$(RTSDIR) 
../stamp-gnatlib2-$(RTSDIR) $(RTSDIR)/s-osc
test -f $(RTSDIR)/s-oscons.ads || exit 1
 # C files
$(MAKE) -C $(RTSDIR) \
-   CC="`echo \"$(GCC_FOR_TARGET)\" \
-   | sed -e 's,\./xgcc,../../xgcc,' -e 's,-B\./,-B../../,'`" \
+   CC="$(GCC_FOR_ADA_RTS)" \
INCLUDES="$(INCLUDES_FOR_SUBDIR) -I./../.." \
 CFLAGS="$(GNATLIBCFLAGS_FOR_C)" \
FORCE_DEBUG_ADAFLAGS="$(FORCE_DEBUG_ADAFLAGS)" \
@@ -638,8 +637,7 @@ gnatlib: ../stamp-gnatlib1-$(RTSDIR) 
../stamp-gnatlib2-$(RTSDIR) $(RTSDIR)/s-osc
-f ../Makefile $(LIBGNAT_OBJS) $(EXTRA_ADALIB_OBJS)
 # Ada files
$(MAKE) -C $(RTSDIR) \
-   CC="`echo \"$(GCC_FOR_TARGET)\" \
-   | sed -e 's,\./xgcc,../../xgcc,' -e 's,-B\./,-B../../,'`" \
+   CC="$(GCC_FOR_ADA_RTS)" \
ADA_INCLUDES="" \
 CFLAGS="$(GNATLIBCFLAGS)" \
ADAFLAGS="$(GNATLIBFLAGS)" \
@@ -672,15 +670,13 @@ gnatlib-shared-default:
 LN_S="$(LN_S)" \
  gnatlib
$(RM) $(RTSDIR)/libgna*$(soext)
-   cd $(RTSDIR); `echo "$(GCC_FOR_TARGET)" \
-| sed -e 's,\./xgcc,../../xgcc,' -e 's,-B\./,-B../../,'` 
-shared $(GNATLIBCFLAGS) \
+   cd $(RTSDIR); $(GCC_FOR_ADA_RTS) -shared $(GNATLIBCFLAGS) \
$(PICFLAG_FOR_TARGET) \
-o libgnat$(hyphen)$(LIBRARY_VERSION)$(soext) \
$(GNATRTL_NONTASKING_OBJS) $(LIBGNAT_OBJS) \
$(SO_OPTS)libgnat$(hyphen)$(LIBRARY_VERSION)$(soext) \
$(MISCLIB) -lm
-   cd $(RTSDIR); `echo "$(GCC_FOR_TARGET)" \
-| sed -e 's,\./xgcc,../../xgcc,' -e 's,-B\./,-B../../,'` 
-shared $(GNATLIBCFLAGS) \
+   cd $(RTSDIR); $(GCC_FOR_ADA_RTS) -shared $(GNATLIBCFLAGS) \
$(PICFLAG_FOR_TARGET) \
-o libgnarl$(hyphen)$(LIBRARY_VERSION)$(soext) \
$(GNATRTL_TASKING_OBJS) \
@@ -764,14 +760,12 @@ gnatlib-shared-win32:
$(RM) $(RTSDIR)/libgna*$(soext)
$(CP) $(RTSDIR)/libgnat$(arext) $(RTSDIR)/libgnat_pic$(arext)
$(CP) $(RTSDIR)/libgnarl$(arext) $(RTSDIR)/libgnarl_pic$(arext)
-   cd $(RTSDIR); `echo "$(GCC_FOR_TARGET)" \
-| sed -e 's,\./xgcc,../../xgcc,' -e 's,-B\./,-B../../,'` 
-shared -shared-libgcc \
+   cd $(RTSDIR); $(GCC_FOR_ADA_RTS) -shared -shared-libgcc \
$(PICFLAG_FOR_TARGET) \
-o libgnat$(hyphen)$(LIBRARY_VERSION)$(soext) \
$(GNATRTL_NONTASKING_OBJS) $(LIBGNAT_OBJS) \
$(SO_OPTS)libgnat$(hyphen)$(LIBRARY_VERSION)$(soext) $(MISCLIB)
-   cd $(RTSDIR); `echo "$(GCC_FOR_TARGET)" \
-| sed -e 

[Bug preprocessor/105732] [10/11/12/13 Regression] internal compiler error: unspellable token PADDING

[herrtimson at yahoo dot de via Gcc-bugs]

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

--- Comment #12 from tt_1  ---
With the revert included in the release tarball, it seems that gcc-9.5.0 is
'known to work' then?