[Bug target/108415] ICE in emit_library_call_value_1 at gcc/calls.cc:4181

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

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

--- Comment #4 from Kewen Lin  ---
(In reply to Peter Bergner from comment #3)
> (In reply to Kewen Lin from comment #2)
> > The contradictory thing is that we can have TARGET_VSX and TARGET_SOFT_FLOAT
> > (!TARGET_HARD_FLOAT) together with the proposed option combination. :)
> 
> I'm not sure what you mean with this comment, but just to be clear, we
> should not allow TARGET_VSX and TARGET_SFT_FLOAT (!TARGET_HARD_FLOAT) at the
> same time.

Sorry for the confusion and thanks for clarifying, I meant the similar meaning
that: the given option combination, like

  -mmodulo -mcpu=401 or -mcpu=401 -mpower9-vector or ...

makes us to have both TARGET_VSX and TARGET_SOFT_FLOAT at the same time, it's
contradictory (shouldn't be allowed as you noted).

[Bug target/108415] ICE in emit_library_call_value_1 at gcc/calls.cc:4181

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

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

--- Comment #3 from Peter Bergner  ---
(In reply to Kewen Lin from comment #2)
> The contradictory thing is that we can have TARGET_VSX and TARGET_SOFT_FLOAT
> (!TARGET_HARD_FLOAT) together with the proposed option combination. :)

I'm not sure what you mean with this comment, but just to be clear, we should
not allow TARGET_VSX and TARGET_SFT_FLOAT (!TARGET_HARD_FLOAT) at the same
time.

[Bug fortran/102595] ICE in var_element, at fortran/decl.c:298 since r10-5607-gde89b5748d68b76b

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

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

Jerry DeLisle  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org

--- Comment #10 from Jerry DeLisle  ---
The following appears to catch it correctly.  The previous spot I removed after
spotting while checking the addition to primary.cc.  I keep the error message
similar so that existing tests in gfortrn.dg pass without changing.

diff --git a/gcc/fortran/data.cc b/gcc/fortran/data.cc
index 443d35da9cf..d29eb12c1b1 100644
--- a/gcc/fortran/data.cc
+++ b/gcc/fortran/data.cc
@@ -244,13 +244,6 @@ gfc_assign_data_value (gfc_expr *lvalue, gfc_expr *rvalue,
mpz_t index,
"array-element nor a scalar-structure-component";

   symbol = lvalue->symtree->n.sym;
-  if (symbol->attr.flavor == FL_PARAMETER)
-{
-  gfc_error ("PARAMETER %qs shall not appear in a DATA statement at %L",
-symbol->name, >where);
-  return false;
-}
-
   init = symbol->value;
   last_ts = >ts;
   last_con = NULL;
diff --git a/gcc/fortran/primary.cc b/gcc/fortran/primary.cc
index 543d9cc0de4..158f039f225 100644
--- a/gcc/fortran/primary.cc
+++ b/gcc/fortran/primary.cc
@@ -4076,6 +4076,11 @@ match_variable (gfc_expr **result, int equiv_flag, int
host_flag)
  gfc_error ("Named constant at %C in an EQUIVALENCE");
  return MATCH_ERROR;
}
+  if (gfc_in_match_data())
+   {
+ gfc_error ("PARAMETER %qs shall not appear in a DATA statement at
%C",
+ sym->name);
+   }
   /* Otherwise this is checked for and an error given in the
 variable definition context checks.  */
   break;

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

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

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

--- Comment #38 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

https://gcc.gnu.org/g:159b0f41adc4c8ead45e12a523470381ce716ff2

commit r13-5235-g159b0f41adc4c8ead45e12a523470381ce716ff2
Author: liuhongt 
Date:   Fri Jan 13 16:19:47 2023 +0800

Don't add crtfastmath.o for -shared.

Patches [1] and [2] fixed PR55522 for x86-linux but left all other x86
targets unfixed (x86-cygwin, x86-darwin and x86-mingw32).
This patch applies a similar change to other specs using crtfastmath.o.

[1] https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608528.html
[2] https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608529.html

gcc/ChangeLog:

PR target/55522
* config/i386/cygwin.h (ENDFILE_SPEC): Link crtfastmath.o
whenever -mdaz-ftz is specified. Don't link crtfastmath.o when
-share or -mno-daz-ftz is specified.
* config/i386/darwin.h (ENDFILE_SPEC): Ditto.
* config/i386/mingw32.h (ENDFILE_SPEC): Ditto.

[Bug target/108415] ICE in emit_library_call_value_1 at gcc/calls.cc:4181

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

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

--- Comment #2 from Kewen Lin  ---
(In reply to Segher Boessenkool from comment #1)
> Soft float does not conflict with anything (anything that does not need
> FP registers that is).  But yes, we really should neuter -mmodulo.

The contradictory thing is that we can have TARGET_VSX and TARGET_SOFT_FLOAT
(!TARGET_HARD_FLOAT) together with the proposed option combination. :)

I agree that we should neuter -mmodulo, but note that this ICE isn't -mmodulo
specific.

With some more testings on those flags which the proposed patch (as field URL)
tries to take care of, the ICE can be reproduced with any one of below:

  -mcpu=401 -m64 -mmodulo
  -mcpu=401 -m64 -mpower9-vector
  -mcpu=401 -m64 -mpower9-misc
  -mcpu=401 -m64 -mpower8-vector
  -mcpu=401 -m64 -mcrypto

For -mcpu=401 -m64 -mpower9-minmax, it has the below error instead of ICE:

  f951: Error: power9 target option is incompatible with ‘-mcpu=’ for
 less than power9

[Bug fortran/102331] ICE in attr_decl1, at fortran/decl.c:8691

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

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

--- Comment #8 from Jerry DeLisle  ---
Fixed ChangeLogs PR number referenced.

commit 04d7cc165387d19e1433a4b2157d2bde7b95305b (HEAD -> master, origin/master,
origin/HEAD)
Author: Jerry DeLisle 
Date:   Tue Jan 17 17:30:49 2023 -0800

Fix bug number reference in Changelogs

For:

gcc/fortran/ChangeLog-2022:

gcc/testsuite/ChangeLog-2022:

[Bug fortran/106731] ICE on automatic array of derived type with DTIO

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

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

--- Comment #13 from Jerry DeLisle  ---
I will backport to 12 as it is an ice on Valid.

[Bug other/108276] libiberty unlink_if_ordinary does not handle Windows nul device correctly

[himalr at proton dot me via Gcc-bugs]

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

--- Comment #7 from Himal  ---
(In reply to niXman from comment #6)
> I think you don't understand me.
> 
> with your patch after preprocessing the `unlink_if_ordinary()` will look
> like:
> ```
> int
> unlink_if_ordinary (const char *name)
> {
>   if (stricmp (name, "nul") == 0)
> return 1;
> 
>   return 1;
> }
> 
> ```
> 
> don't you think it's strange?

Ah, yes. I noticed that after submitting the patch. I have already posted an
updated version
[here](https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609487.html)

[Bug tree-optimization/108440] rotate optimization may introduce new UB

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

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

--- Comment #4 from Krister Walfridsson  ---
I misread the comment -- it describes a possible future improvement (that I
believe is not allowed). But the committed patch seems to be correct.

[Bug tree-optimization/106523] [10/11/12 Regression] forwprop miscompile

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

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

--- Comment #8 from Krister Walfridsson  ---
This fixed most of the rotate issues my translation validation tool found. I
assume the remaining issues are due to a different (but similar) bug, so I
opened Bug 108440 for those. 

But the issue in Bug 108440 seems similar to the "Y equal to B case" discussed
in comment #6, so I believe the comment is slightly wrong (as the rotate
instruction will invoke UB when Y is equal to B).

[Bug tree-optimization/108440] rotate optimization may introduce new UB

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

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

--- Comment #3 from Krister Walfridsson  ---
Hmm. I think this is the "Y equal to B case" from bug 106523. I.e., the bugfix
is not correct...

[Bug tree-optimization/108440] rotate optimization may introduce new UB

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

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

--- Comment #2 from Krister Walfridsson  ---
No, bug 106523 is a different issue (I have tested with a compiler that has
that fixed).

[Bug tree-optimization/108440] rotate optimization may introduce new UB

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Isn't this a dup of bug 106523 which was just fixed on the trunk ?

[Bug tree-optimization/108440] New: rotate optimization may introduce new UB

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

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

Bug ID: 108440
   Summary: rotate optimization may introduce new UB
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kristerw at gcc dot gnu.org
  Target Milestone: ---

GCC optimizes shift instructions to rotate in a way that may make
the optimized IR invoke UB for cases where the original did not.
This can be seen in the IR for f5 from c-c++-common/rotate-1.c:

  unsigned short int
  f5 (unsigned short int x, unsigned int y)
  {
return (x << y) | (x >> (__CHAR_BIT__ * __SIZEOF_SHORT__ - y));
  }

The IR is doing 32-bit shifts, so y = 16 does not invoke UB:

  short unsigned int f5 (short unsigned int x, unsigned int y)
  {
int _1;
int _2;
signed short _3;
int _4;
unsigned int _5;
int _6;
signed short _7;
signed short _8;
short unsigned int _11;

 :
_1 = (int) x_9(D);
_2 = _1 << y_10(D);
_3 = (signed short) _2;
_4 = (int) x_9(D);
_5 = 16 - y_10(D);
_6 = _4 >> _5;
_7 = (signed short) _6;
_8 = _3 | _7;
_11 = (short unsigned int) _8;
return _11;
  }

But forwprop1 changes this to a 16-bit rotate which invokes UB for y=16:

  short unsigned int f5 (short unsigned int x, unsigned int y)
  {
short unsigned int _13;

 :
_13 = x_9(D) r<< y_10(D);
return _13;
  }

[Bug c/108439] incorrect optimization with -O2, -O3, -Os

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

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

--- Comment #6 from Andrew Pinski  ---
Aliasing rules are NOT a local thing and they are not about what the type of
the pointer is, rather than they are about the access after the casting. They
are also global ...

GCC used to have strict aliasing warnings which might warn during optimizations
but it had many false positives so it was tuned down a lot.
The rules are simple in most cases (there are complex parts to it when dealing
with unions and structures but more complex in the implementation of the
compiler).

Some reading on this subject:
https://developers.redhat.com/blog/2020/06/02/the-joys-and-perils-of-c-and-c-aliasing-part-1
https://gist.github.com/shafik/848ae25ee209f698763cffee272a58f8

There are many more papers about C/C++ aliasing rules if you want to go read up
on why GCC is doing the "correct" thing here.

[Bug c/108439] incorrect optimization with -O2, -O3, -Os

[georgmueller at gmx dot net via Gcc-bugs]

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

--- Comment #5 from Georg Müller  ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Georg Müller from comment #1) 
> > Also, this compiler warning and execution error is removed by compiling with
> > -fno-strict-aliasing, but again, this does not look right.
> 
> Why do you think that is not correct? The aliasing violation causing
> undefined behavior is obvious from the stores and loads that happen from the
> source.

main() only works with its own lb_key array. It is only modified before giving
it to crap8() - it does not handle the internals of the hashing function.

crap8() takes the key as a void pointer - no assumptions about what it gets and
only converts void* to  uint32_t*, what should be fine, or?

Why is there a warning of lb_key not being initialized in the second example,
even though its only member gets initialized twice? Via the same reference...

[Bug target/108436] ICE in gen_prefetch, at config/i386/i386.md:24155

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #2 from H.J. Lu  ---
Created attachment 54294
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54294=edit
Issue a warning for the invalid 3rd argument

[Bug c/108439] incorrect optimization with -O2, -O3, -Os

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Georg Müller from comment #1) 
> Also, this compiler warning and execution error is removed by compiling with
> -fno-strict-aliasing, but again, this does not look right.

Why do you think that is not correct? The aliasing violation causing undefined
behavior is obvious from the stores and loads that happen from the source.

[Bug c/108439] incorrect optimization with -O2, -O3, -Os

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Use -fno-strict-aliasing, mayalias attribute, memcpy, etc as you are violating
C/C++ aliasing rules.
You do a store via uint64_t:
lb_key[0] = 0x1234;

And then do loads via uint32_t:
  const uint32_t  m = 0x83d2e73b, n = 0x97e1cc59, *key4 = (const uint32_t
*)key;
...
c8mix(key4[0]) c8mix(key4[1]) key4 += 2;

[Bug c/108439] incorrect optimization with -O2, -O3, -Os

[georgmueller at gmx dot net via Gcc-bugs]

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

--- Comment #2 from Georg Müller  ---
Just a small additional note: The dependency on argc in the loop filling the
array in main() is only there to avoid early optimization.

[Bug libquadmath/94756] strtoflt128 assigns some subnormals incorrectly on MS Windows

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

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

--- Comment #1 from niXman  ---
unfortunately, this bug is still present on the master branch...

trying to deal with it..

[Bug c/108439] incorrect optimization with -O2, -O3, -Os

[georgmueller at gmx dot net via Gcc-bugs]

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

--- Comment #1 from Georg Müller  ---
Created attachment 54293
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54293=edit
reduced test case to give a compile warning, which seems to be incorrect

While trying to reduce the problem and reducing the array size of lb_key to ony
one member (t_crap8-1u64.c), it gives a compile error with -O2, -O3 and -Os
even if the only member gets initialized all the time with the line "lb_key[0]
= 0x1234;".

Also, this compiler warning and execution error is removed by compiling with
-fno-strict-aliasing, but again, this does not look right.

[Bug c/108439] New: incorrect optimization with -O2, -O3, -Os

[georgmueller at gmx dot net via Gcc-bugs]

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

Bug ID: 108439
   Summary: incorrect optimization with -O2, -O3, -Os
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: georgmueller at gmx dot net
  Target Milestone: ---

Created attachment 54292
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54292=edit
test case to trigger bug

When testing the crap8 (or crapwow) hashing funtion, we discovered a gcc
optimization problem with gcc from at least version 9.3.0 up to 12.2.1.

The attached program (t_crap8.c) miscompiles for -O2, -O3, -Os while testing
the crap8 hash function (same behavior with similar hash function crapwow,
which only has different parameters m and n in the hash function).

Implementation is, for example. available in the smhasher project.

The line "lb_key[0] = 0x1234;" gets ignored with -O2, -O3, -Os.

As described in the report, compiling with -fno-strict-aliasing solves the
problem, but the code is compiling correctly with clang at all optimization
levels and does not report an error.

[Bug c++/108437] [13 Regression] ICE in build_min_non_dep_op_overload, at cp/tree.cc:3710

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-01-17
   Target Milestone|--- |13.0
 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Started with r13-4046.

[Bug c++/108438] [10/11/12/13 Regression] ICE in cxx_eval_constant_expression, at cp/constexpr.cc:7611

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

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2023-01-17
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug fortran/106731] ICE on automatic array of derived type with DTIO

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #12 from anlauf at gcc dot gnu.org ---
Fixed on mainline for gcc-13.

Jerry, are you planning to backport?  Otherwise please close the PR.

[Bug fortran/107397] [10/11/12 Regression] ICE in gfc_arith_plus, at fortran/arith.cc:654

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
Summary|[10/11/12/13 Regression]|[10/11/12 Regression] ICE
   |ICE in gfc_arith_plus, at   |in gfc_arith_plus, at
   |fortran/arith.cc:654|fortran/arith.cc:654
   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org

--- Comment #12 from anlauf at gcc dot gnu.org ---
Since mainline is fixed, adjusting summary.

Assigning to you, Jerry, for potential backports...

[Bug fortran/107214] [13 Regression] ICE: base pointer cycle detected since r13-2661-gb57abd072dd319a7

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #3 from anlauf at gcc dot gnu.org ---
Assuming it is fixed, can we close it?

[Bug debug/107965] libstdc++ Python Pretty-Printers: Many Exceptions From Uninitialized Structures

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

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

--- Comment #8 from Jason Merrill  ---
The compiler could represent this with a location list instead of a single
location.  I guess implementing that would involve using NOTE_INSN_VAR_LOCATION
instead of giving the variable DECL_RTL?  This sounds complicated.

[Bug target/108429] [13 Regression] FAIL: gcc.target/i386/pr89618.c scan-tree-dump vect "LOOP VECTORIZED"

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

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #4 from Jan Hubicka  ---
I see this is scatter with generic tuning.  I actually did not intend to
disable it there without more testing, so I will revert that part of change.

In meantime I noticed that aocc sometimes seems to use scatters with some
degree of success even though scatters seems to be loss on all tsvc benchmarks
where GCC generates them. So I think we want to do more work on this (adding
open-coding etc.) next stage1.

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

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #1 from anlauf at gcc dot gnu.org ---
I cannot reproduce the ICE here, but valgrind tells me that something
is fishy here with error recovery that can be solved by the following
obvious patch:

diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index 5ec369c9cd8..9ab6b8eed86 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -4996,14 +4996,14 @@ get_union_initializer (gfc_symbol *union_type,
gfc_component **map_p)
 static bool
 class_allocatable (gfc_component *comp)
 {
-  return comp->ts.type == BT_CLASS && CLASS_DATA (comp)
+  return comp->ts.type == BT_CLASS && comp->attr.class_ok && CLASS_DATA (comp)
 && CLASS_DATA (comp)->attr.allocatable;
 }

 static bool
 class_pointer (gfc_component *comp)
 {
-  return comp->ts.type == BT_CLASS && CLASS_DATA (comp)
+  return comp->ts.type == BT_CLASS && comp->attr.class_ok && CLASS_DATA (comp)
 && CLASS_DATA (comp)->attr.pointer;
 }


However, playing some more, I get an ICE when changing in the bad type
declaration

 class(c), pointer :: a(2)

to

 class(c), allocatable :: a(2)

The traceback tells me that we might want to wait for Paul's finalization
fix...

[Bug modula2/108404] M2RTS_Halt fails with a segv (it should emit a diagnostic and exit).

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

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

--- Comment #6 from Iain Sandoe  ---
(In reply to Gaius Mulley from comment #5)
> I've committed the patch above - since the source tree without it definitely
> has a  mismatched prototype.  The exit issue needs to be resolved before
> this PR can close.

thanks,
of course, it is not clear what the cause of hanging tests is - so it might be
unrelated now (but too early to say).

[Bug fortran/108421] ICE in get_expr_storage_size, at fortran/interface.cc:2862

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
Fixed on mainline for gcc-13.  Closing.

Thanks for the report!

[Bug fortran/108421] ICE in get_expr_storage_size, at fortran/interface.cc:2862

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

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

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

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

commit r13-5232-ga75760374ee54768e5fd6a27080698bfbbd041ab
Author: Harald Anlauf 
Date:   Mon Jan 16 21:30:56 2023 +0100

Fortran: fix ICE in get_expr_storage_size [PR108421]

gcc/fortran/ChangeLog:

PR fortran/108421
* interface.cc (get_expr_storage_size): Check that we actually have
an integer value before trying to extract it with mpz_get_si.

gcc/testsuite/ChangeLog:

PR fortran/108421
* gfortran.dg/pr108421.f90: New test.

[Bug debug/107965] libstdc++ Python Pretty-Printers: Many Exceptions From Uninitialized Structures

[gustaf.waldemarson at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Gustaf Waldemarson  ---
Very interesting to see so many people chime in on this. Since I arguably
agree that this looks like a GDB bug than an error in the printers. To that
end, I went ahead and registered this
[ticket](https://sourceware.org/bugzilla/show_bug.cgi?id=30018) here. Please
feel free to add
some more details if you have time, as some of the details presented here is
admittedly a bit beyond my skills.

All that said, I still think that the pretty printers should be a bit more
defensive to errors and conservative with what it outputs. E.g., presenting an
error message once, due to something like this is fine in my opinion, but
displaying hundreds of lines with the same error just because some function
uses a hash-map is clearly excessive.

To that end, perhaps it would make sense to defend the `to_string` calls (and
possibly others) with something like this:

seen_errors = {}
# ...
try:
to_string(...)
except Exception as ex:
if ex not in seen_errors:
seen_errors.add(ex)
raise ex

Admittedly, I don't know all the details here, so perhaps this isn't feasible?

[Bug libstdc++/107886] Problem witch std::latch, std::binary_semaphores in C++20

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

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

--- Comment #18 from niXman  ---
Created attachment 54291
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54291=edit
confirmation

it works for me. please look at attachment screenshot.

for GCC-master, configured as x86_64-w64-mingw32, threads=win32.

[Bug libstdc++/105730] [12 Regression] Issue with commit - Allow std::condition_variable waits to be cancelled

[glex.spb at gmail dot com via Gcc-bugs]

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

--- Comment #14 from Gleb Mazovetskiy  ---
The patch applies cleanly to the latest gcc-12 release and also fixes the issue
there btw.

[Bug target/90826] Weak symbol does not work reliably on windows

[nightstrike at gmail dot com via Gcc-bugs]

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

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com

--- Comment #3 from nightstrike  ---
See also: https://sourceware.org/bugzilla/show_bug.cgi?id=9687

[Bug target/101823] GCC generates the wrong string in the assembly code.

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

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

--- Comment #4 from niXman  ---

> The gcc I compiled generated wrong assembly code on Windows.
> This gcc is Canadian compiled from Ubuntu.

please provide the step-by-step instruction you used.

[Bug target/101823] GCC generates the wrong string in the assembly code.

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

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

--- Comment #3 from niXman  ---

> The gcc I compiled generated wrong assembly code on Windows.
> This gcc is Canadian compiled from Ubuntu.

what GCC version was used on the host?

[Bug libstdc++/105730] [12 Regression] Issue with commit - Allow std::condition_variable waits to be cancelled

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #13 from Jonathan Wakely  ---
Please don't close it, the patch needs to be backported to the gcc-12 branch.

[Bug c++/106395] [12/13 regression] [mingw] "redeclared without dllimport attribute: previous dllimport ignored" on C++ friend since r12-299-ga0fdff3cf33f72

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

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

niXman  changed:

   What|Removed |Added

 CC||i.nixman at autistici dot org

--- Comment #5 from niXman  ---
(In reply to nightstrike from comment #4)
> This appears to be fixed in GCC 13

yeah, looks like it got fixed for the master/main.

[Bug libstdc++/105730] [12 Regression] Issue with commit - Allow std::condition_variable waits to be cancelled

[lancethepants at gmail dot com via Gcc-bugs]

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

Lance Fredrickson  changed:

   What|Removed |Added

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

--- Comment #12 from Lance Fredrickson  ---
Marking as resolved as others have verified the patch works for uclibc-ng.

[Bug preprocessor/67046] [10/11/12/13 Regression] Segmentation fault when a preprocessor directive follows the argument to _Pragma

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

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

--- Comment #5 from Lewis Hyatt  ---
The patch was submitted for review here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609951.html

[Bug c++/108438] New: [10/11/12/13 Regression] ICE in cxx_eval_constant_expression, at cp/constexpr.cc:7611

[gscfq--- via Gcc-bugs]

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

Bug ID: 108438
   Summary: [10/11/12/13 Regression] ICE in
cxx_eval_constant_expression, at cp/constexpr.cc:7611
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with r6 and -Wall :


$ cat z1.cc
template 
T foo (T arg, T& ref, T* ptr)
{
  int a = 1;
  return static_cast(a);
}


$ g++-13-20230115 -c z1.cc -Wall
z1.cc: In function 'T foo(T, T&, T*)':
z1.cc:5:23: error: expected '>' before '!' token
5 |   return static_cast(a);
  |   ^
z1.cc:5:23: error: expected '(' before '!' token
5 |   return static_cast(a);
  |   ^
  |   (
z1.cc:5:24: error: expected primary-expression before '>' token
5 |   return static_cast(a);
  |^
z1.cc:5:27: internal compiler error: in cxx_eval_constant_expression, at
cp/constexpr.cc:7611
5 |   return static_cast(a);
  |   ^
0x883b61 cxx_eval_constant_expression
../../gcc/cp/constexpr.cc:7611
0x88c97a cxx_eval_outermost_constant_expr
../../gcc/cp/constexpr.cc:8252
0x891e42 maybe_constant_value(tree_node*, tree_node*, bool)
../../gcc/cp/constexpr.cc:8527
0xa11806 cp_parser_binary_expression
../../gcc/cp/parser.cc:10233
0xa11da4 cp_parser_assignment_expression
../../gcc/cp/parser.cc:10444
0xa14362 cp_parser_expression
../../gcc/cp/parser.cc:10614
0xa2b843 cp_parser_postfix_expression
../../gcc/cp/parser.cc:7356
0xa44ddf cp_parser_unary_expression
../../gcc/cp/parser.cc:9095
0xa106ef cp_parser_cast_expression
../../gcc/cp/parser.cc:
0xa1101f cp_parser_binary_expression
../../gcc/cp/parser.cc:10101
0xa11da4 cp_parser_assignment_expression
../../gcc/cp/parser.cc:10444
0xa14362 cp_parser_expression
../../gcc/cp/parser.cc:10614
0xa27806 cp_parser_jump_statement
../../gcc/cp/parser.cc:14359
0xa27806 cp_parser_statement
../../gcc/cp/parser.cc:12335
0xa27de4 cp_parser_statement_seq_opt
../../gcc/cp/parser.cc:12909
0xa27ec7 cp_parser_compound_statement
../../gcc/cp/parser.cc:12861
0xa51d90 cp_parser_function_body
../../gcc/cp/parser.cc:25280
0xa51d90 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.cc:25331
0xa5240a cp_parser_function_definition_after_declarator
../../gcc/cp/parser.cc:31953
0xa5393c cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/cp/parser.cc:31870

[Bug target/108436] ICE in gen_prefetch, at config/i386/i386.md:24155

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[13 Regression] ICE in  |ICE in gen_prefetch, at
   |gen_prefetch, at|config/i386/i386.md:24155
   |config/i386/i386.md:24155   |

--- Comment #1 from Andrew Pinski  ---
Most likely introduced when __builtin_ia32_prefetch was introduced;
r13-3711-gb384d9a05a15d4

[Bug c++/108437] New: [13 Regression] ICE in build_min_non_dep_op_overload, at cp/tree.cc:3710

[gscfq--- via Gcc-bugs]

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

Bug ID: 108437
   Summary: [13 Regression] ICE in build_min_non_dep_op_overload,
at cp/tree.cc:3710
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20221106 and 20221120, with -std=c++23 :


$ cat z1.cc
struct S
{
  static int operator[] (int x) { int a[2]; return a[x]; }
};
template int f ()
{
  S s;
  s[0]++;
  return 0;
}


$ g++-13-20230115 -c z1.cc -std=c++23
z1.cc: In function 'int f()':
z1.cc:8:6: internal compiler error: in build_min_non_dep_op_overload, at
cp/tree.cc:3710
8 |   s[0]++;
  |  ^
0xb397f7 build_min_non_dep_op_overload(tree_code, tree_node*, tree_node*, ...)
../../gcc/cp/tree.cc:3710
0x92b620 grok_array_decl(unsigned int, tree_node*, tree_node*, vec**, int)
../../gcc/cp/decl2.cc:577
0xa17963 cp_parser_postfix_open_square_expression
../../gcc/cp/parser.cc:8177
0xa2b2de cp_parser_postfix_expression
../../gcc/cp/parser.cc:7768
0xa44ddf cp_parser_unary_expression
../../gcc/cp/parser.cc:9095
0xa106ef cp_parser_cast_expression
../../gcc/cp/parser.cc:
0xa1101f cp_parser_binary_expression
../../gcc/cp/parser.cc:10101
0xa11da4 cp_parser_assignment_expression
../../gcc/cp/parser.cc:10444
0xa14362 cp_parser_expression
../../gcc/cp/parser.cc:10614
0xa18577 cp_parser_expression_statement
../../gcc/cp/parser.cc:12758
0xa26ae1 cp_parser_statement
../../gcc/cp/parser.cc:12538
0xa27de4 cp_parser_statement_seq_opt
../../gcc/cp/parser.cc:12909
0xa27ec7 cp_parser_compound_statement
../../gcc/cp/parser.cc:12861
0xa51d90 cp_parser_function_body
../../gcc/cp/parser.cc:25280
0xa51d90 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.cc:25331
0xa5240a cp_parser_function_definition_after_declarator
../../gcc/cp/parser.cc:31953
0xa5393c cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/cp/parser.cc:31870
0xa5393c cp_parser_init_declarator
../../gcc/cp/parser.cc:22734
0xa5713f cp_parser_single_declaration
../../gcc/cp/parser.cc:32470
0xa572a6 cp_parser_template_declaration_after_parameters
../../gcc/cp/parser.cc:32023

[Bug c/108436] New: [13 Regression] ICE in gen_prefetch, at config/i386/i386.md:24155

[gscfq--- via Gcc-bugs]

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

Bug ID: 108436
   Summary: [13 Regression] ICE in gen_prefetch, at
config/i386/i386.md:24155
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20221106 and 20221120 :


$ cat z1.c
#include 
void* p;
void extern
prefetch_test (void)
{
  __builtin_ia32_prefetch (p, 0, 4, 0);
}


$ gcc-13-20230115 -c z1.c
during RTL pass: expand
z1.c: In function 'prefetch_test':
z1.c:6:3: internal compiler error: in gen_prefetch, at
config/i386/i386.md:24155
6 |   __builtin_ia32_prefetch (p, 0, 4, 0);
  |   ^~~~
0x154cfec gen_prefetch(rtx_def*, rtx_def*, rtx_def*)
../../gcc/config/i386/i386.md:24155
0x10edffe ix86_expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode,
int)
../../gcc/config/i386/i386-expand.cc:13200
0x88cc9b expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
../../gcc/builtins.cc:7321
0x9b3ef0 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.cc:11872
0x8af731 expand_expr
../../gcc/expr.h:310
0x8af731 expand_call_stmt
../../gcc/cfgexpand.cc:2831
0x8af731 expand_gimple_stmt_1
../../gcc/cfgexpand.cc:3880
0x8af731 expand_gimple_stmt
../../gcc/cfgexpand.cc:4044
0x8b4307 expand_gimple_basic_block
../../gcc/cfgexpand.cc:6096
0x8b6dce execute
../../gcc/cfgexpand.cc:6831

[Bug fortran/108435] New: [13 Regression] ICE in as_a, at is-a.h:242

[gscfq--- via Gcc-bugs]

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

Bug ID: 108435
   Summary: [13 Regression] ICE in as_a, at is-a.h:242
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20220501 and 20220508 :
(gcc configured with --enable-checking=yes)


$ cat z1.f90
program p
   integer :: j
contains
   subroutine s
  integer :: i
  !$omp do simd collapse(2)
  do i = 1, 16
 do j = 1, i
 end do
  end do
   end
end


$ cat z2.f90
program p
contains
   subroutine s
  integer :: i, j
  !$omp do simd collapse(2)
  do i = 1, 16
 do j = 1, i
 end do
  end do
   end
end


$ gfortran-13-20230115 -c z2.f90 -fopenmp
$
$ gfortran-13-20230115 -c z1.f90 -fopenmp
z1.f90:1:9:

1 | program p
  | ^
internal compiler error: in as_a, at is-a.h:242
0xc3aeba gbind* as_a(gimple*)
../../gcc/is-a.h:242
0xc3aeba declare_vars(tree_node*, gimple*, bool)
../../gcc/gimplify.cc:697
0x1053aa7 convert_nonlocal_omp_clauses
../../gcc/tree-nested.cc:1590
0x10546d2 convert_nonlocal_reference_stmt
../../gcc/tree-nested.cc:1716
0xc34366 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.cc:608
0xc34580 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.cc:51
0xc34421 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.cc:635
0xc34580 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.cc:51
0x104c788 walk_body
../../gcc/tree-nested.cc:811
0x1054616 convert_nonlocal_reference_stmt
../../gcc/tree-nested.cc:1752
0xc34366 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.cc:608
0xc34580 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.cc:51
0xc34421 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.cc:635
0xc34580 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.cc:51
0xc34421 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.cc:635
0xc34580 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.cc:51
0x104c788 walk_body
../../gcc/tree-nested.cc:811
0x104c7d8 walk_function
../../gcc/tree-nested.cc:822
0x104c7d8 walk_all_functions
../../gcc/tree-nested.cc:887
0x10583b4 lower_nested_functions(tree_node*)
../../gcc/tree-nested.cc:3736

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

[gscfq--- via Gcc-bugs]

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

Bug ID: 108434
   Summary: [12/13 Regression] ICE in class_allocatable, at
fortran/expr.cc:5000
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20210905 and 20211121 :
(with -g or a combination of -Wall -g -O2 -fopenmp -fopenacc)


$ cat z1.f90
program p
   type t
  class(c), pointer :: a(2)
   end type
   class(t), allocatable :: x
   class(t), pointer :: y
end


$ cat z2.f90
program p
   type t
  class(c), pointer :: a(2)
   end type
   class(t), pointer :: y
   class(t), allocatable :: x
end


$ gfortran-13-20230115 -c z2.f90 -g
z2.f90:3:31:

3 |   class(c), pointer :: a(2)
  |   1
Error: Pointer array component of structure at (1) must have a deferred shape
f951: internal compiler error: Segmentation fault
0xf8734f crash_signal
../../gcc/toplev.cc:314
0x83e346 class_allocatable
../../gcc/fortran/expr.cc:5000
0x83e346 comp_allocatable
../../gcc/fortran/expr.cc:5013
0x83e346 gfc_generate_initializer(gfc_typespec*, bool)
../../gcc/fortran/expr.cc:5157
0x8139d5 gfc_find_derived_vtab(gfc_symbol*)
../../gcc/fortran/class.cc:2460
0x8bea8d resolve_fl_derived
../../gcc/fortran/resolve.cc:15210
0x8b8057 resolve_symbol
../../gcc/fortran/resolve.cc:15595
0x8d7472 do_traverse_symtree
../../gcc/fortran/symbol.cc:4186
0x8bb624 resolve_types
../../gcc/fortran/resolve.cc:17547
0x8b6a9c gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.cc:17662
0x89e844 resolve_all_program_units
../../gcc/fortran/parse.cc:6656
0x89e844 gfc_parse_file()
../../gcc/fortran/parse.cc:6912
0x8ed3af gfc_be_parse_file
../../gcc/fortran/f95-lang.cc:229

[Bug tree-optimization/104475] [12/13 Regression] Wstringop-overflow + atomics incorrect warning on dynamic object

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

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

--- Comment #25 from Jason Merrill  ---
This was clarified for C++ last year by http://wg21.link/cwg2535

I notice that C warn_for_null_address also warns about >mem; I don't know
where that is justified in the C standard.

[Bug fortran/108431] Loop variable reaching integer `huge` causes infinte loop

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to federico from comment #1)
> I've just found from previous discussions on Fortran forums that this may
> not be a bug in the compiler but rather a gray area in the Fortran standard.
> So I will close the bug as "invalid".

Try adding -Wall to your command line.

% gfcx -fdump-tree-original -c -Wall a.f90
a.f90:4:25:

4 | do i=-huge(i),huge(i)
  | 1
Warning: DO loop at (1) is undefined as it overflows [-Wundefined-do-loop]

[Bug go/108426] [13 regression] SEGV in contains_struct_check

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

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

--- Comment #10 from Andrew Pinski  ---
(In reply to Ian Lance Taylor from comment #9)
> I agree that if the middle-end is going to generate calls to builtin
> functions, it would be nice if the middle-end provided a function to call to
> define those functions.

I was thinking about this too. Maybe we could split up builtins.def some more
and then have the ones which are needed for the middle-end usage done in a
function which can be used by all front-ends. I noticed some backends do
include some of the *.def files to build the functions (e.g. fortran to build
the omp/acc ones) so it would be nice if that is all handled in the middle-end.
NOTE that is also stage 1 change rather than stage 3/4 changes.

[Bug go/108426] [13 regression] SEGV in contains_struct_check

[ian at airs dot com via Gcc-bugs]

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

--- Comment #9 from Ian Lance Taylor  ---
I agree that if the middle-end is going to generate calls to builtin functions,
it would be nice if the middle-end provided a function to call to define those
functions.

[Bug go/108426] [13 regression] SEGV in contains_struct_check

[ian at airs dot com via Gcc-bugs]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #8 from Ian Lance Taylor  ---
I committed the patch.

[Bug go/108426] [13 regression] SEGV in contains_struct_check

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

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

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

https://gcc.gnu.org/g:6d80690132a2f00fae1f619d4ffd950ce8cfdbc7

commit r13-5231-g6d80690132a2f00fae1f619d4ffd950ce8cfdbc7
Author: Ian Lance Taylor 
Date:   Tue Jan 17 09:02:49 2023 -0800

go: define two builtin functions used by middle-end

PR go/108426
* go-gcc.cc (Gcc_backend::Gcc_backend): Define __builtin_ctzl and
__builtin_clzl.  Patch by Andrew Pinski.

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

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

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

Iain Sandoe  changed:

   What|Removed |Added

  Attachment #54261|0   |1
is obsolete||
   Assignee|gaius at gcc dot gnu.org   |iains at gcc dot gnu.org

--- Comment #16 from Iain Sandoe  ---
Created attachment 54290
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54290=edit
Patch to be posted,

This is the patch I intend to post (here in case anyone is testing)

[Bug modula2/102343] gm2/cpp/pass/subaddr.mod FAILs for non-default multilib

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

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

--- Comment #2 from Iain Sandoe  ---
Created attachment 54289
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54289=edit
Patch for discussion

This applies on top of the patch for PR108182 (and will most likely not work
without those changes).

 * -save-temps* should be fixed
 * we no longer try to write those files into the install directories
 * we should now support " gm2 -E  "
 * renamed the pre-processed file extension to ".m2i" we cannot use ".i" or GCC
will try to process it with cc1.
 * We now have default handers for .mod and .m2i (maybe we should add .def is
that something used stand-alone?) So trying to use them with a compiler without
modula-2 should give a more sensible diagnostic.
 * we should handle " gm2 foo.mod.m2i "
 * last, but most important, we now collect the command line options needed to
set the target state into the preprocessor command line.  This then provides
the correct pre-defines and the test case then does the right thing on a 32b
multilib on a 64b host.

If there are no comments in the next week or so I'll post this to the list.

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

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

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

--- Comment #13 from Kito Cheng  ---
Patch posted before, but seems like not everybody agree:
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603049.html

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

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||ktkachov at gcc dot gnu.org
   Last reconfirmed||2023-01-17

--- Comment #12 from ktkachov at gcc dot gnu.org ---
(In reply to Kito Cheng from comment #7)
> We are hitting this issue on RISC-V, and got some complain from linux kernel
> developers, but in different form as the original report, we found cold
> function or any function is marked as cold by `-fguess-branch-probability`
> are all not honor to the -falign-functions=N setting, that become problem on
> some linux kernel feature since they want to control the minimal alignment
> to make sure they can atomically update the instruction which require align
> to 4 byte.
> 
> However current GCC behavior can't guarantee that even -falign-functions=4
> is given, there is 3 option in my mind:
> 
> 1. Fix -falign-functions=N, let it work as expect on -Os and all cold
> functions
> 2. Force align to 4 byte if -fpatchable-function-entry is given, that's
> should be doable by adjust RISC-V's FUNCTION_BOUNDARY
> 3. Adjust RISC-V's FUNCTION_BOUNDARY to let it honor to -falign-functions=N
> 4. Adding a -malign-functions=N...Okay, I know that suck idea, x86 already
> deprecated that.
> 
> But I think ideally this should fixed by 1 option if possible.
> 
> Testcase from RISC-V kernel guy:
> ```
> /* { dg-do compile } */
> /* { dg-options "-march=rv64gc -mabi=lp64d -O1 -falign-functions=128" } */
> /* { dg-final { scan-assembler-times ".align 7" 2 } } */
> 
> // Using 128 byte align rather than 4 byte align since it easier to observe.
> 
> __attribute__((__cold__)) void a() {} // This function isn't align to 128
> byte
> void b() {} // This function align to 128 byte.
> ```
> 
> Proposed fix:
> ```
> diff --git a/gcc/varasm.c b/gcc/varasm.c
> index 49d5cda122f..6f8ed85fea9 100644
> --- a/gcc/varasm.c
> +++ b/gcc/varasm.c
> @@ -1907,8 +1907,7 @@ assemble_start_function (tree decl, const char *fnname)
>   Note that we still need to align to DECL_ALIGN, as above,
>   because ASM_OUTPUT_MAX_SKIP_ALIGN might not do any alignment at all. 
> */
>if (! DECL_USER_ALIGN (decl)
> -  && align_functions.levels[0].log > align
> -  && optimize_function_for_speed_p (cfun))
> +  && align_functions.levels[0].log > align)
>  {
>  #ifdef ASM_OUTPUT_MAX_SKIP_ALIGN
>int align_log = align_functions.levels[0].log;
> 
> ```

I think this patch makes sense given the extra information you and Mark have
provided. Would you mind testing it and posting it to gcc-patches for review
please?

[Bug modula2/108404] M2RTS_Halt fails with a segv (it should emit a diagnostic and exit).

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

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

--- Comment #5 from Gaius Mulley  ---
I've committed the patch above - since the source tree without it definitely
has a  mismatched prototype.  The exit issue needs to be resolved before this
PR can close.

[Bug libgcc/108433] canadian cross aarch64/x86_64/aarch64 fails to build

[schwab--- via Gcc-bugs]

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

--- Comment #2 from Andreas Schwab  ---
The target libraries should not be built in a canadian cross build, they were
already produced while building the cross compiler.

[Bug other/108413] copyrights for gcc 2023

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

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

--- Comment #9 from Gaius Mulley  ---
I've git pushed some fixes for gcc/m2/mc/mcOptions.mod to obfuscate the
copyright text.  The change to mcOptions.mod also includes the removal
of the 'YEAR' constant and it queries the system for the year.  A
summary of the ChangeLog:

gcc/m2/ChangeLog:

* mc-boot/GmcOptions.c: Rebuilt.
* mc/mcOptions.mod (displayVersion):
Split first printf into three components
* mc/mcOptions.mod (YEAR): Remove.
(getYear): New procedure function.
(displayVersion): Use result from getYear instead of YEAR.
Emit boilerplate for GPL v3.
(gplBody): Use result from getYear instead of YEAR.
(glplBody): Use result from getYear instead of YEAR.

taken from gcc r13-5229 and gcc r13-5217

[Bug libgcc/108433] canadian cross aarch64/x86_64/aarch64 fails to build

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

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #1 from Florian Weimer  ---
Sorry, I don't see how this could have ever worked. How can “cc” be the right
compiler in this context?

[Bug libgcc/108433] New: canadian cross aarch64/x86_64/aarch64 fails to build

[arnd at linaro dot org via Gcc-bugs]

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

Bug ID: 108433
   Summary: canadian cross aarch64/x86_64/aarch64 fails to build
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnd at linaro dot org
  Target Milestone: ---

I tried to build a set of cross compilers for all target architectures. Build
architecture is arm64, host architecture is x86_64 or ppc64le, both of them
fail the same way:

cc   -g -O2 -O2  -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include  -fPIC -g
-DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -fPIC -I.
-I. -I../.././gcc -I/home/arnd/git/gcc/libgcc -I/home/arnd/git/gcc/libgcc/.
-I/home/arnd/git/gcc/libgcc/../gcc -I/home/arnd/git/gcc/libgcc/../include 
-DHAVE_CC_TLS   -o unwind-dw2-fde-dip.o -MT unwind-dw2-fde-dip.o -MD -MP -MF
unwind-dw2-fde-dip.dep -fexceptions -c
/home/arnd/git/gcc/libgcc/unwind-dw2-fde-dip.c -fvisibility=hidden
-DHIDE_EXPORTS
libgcc/unwind-dw2.c:967:20: error: ‘__LIBGCC_DWARF_CIE_DATA_ALIGNMENT__’
undeclared (first use in this function); did you mean
‘DWARF_CIE_DATA_ALIGNMENT’?

The problem seems to be caused by configure picking up /usr/bin/cc as the
compiler for building libgcc when in a canadian cross with build==target,
despite another aarch64-linux-gnu-gcc being provided for this purpose:

Configuring in aarch64-linux/libgcc
configure: creating cache ./config.cache
checking build system type... aarch64-unknown-linux-gnu
checking host system type... aarch64-unknown-linux-gnu
checking for --enable-version-specific-runtime-libs... no
checking for a BSD-compatible install... /usr/bin/install -c
checking for gawk... mawk
checking for aarch64-linux-ar...
/home/arnd/cross/arm64/gcc-13.0.1-nolibc/aarch64-linux/lib/gcc/aarch64-linux/13.0.1/../../../../aarch64-linux/bin/ar
checking for aarch64-linux-lipo... lipo
checking for aarch64-linux-nm...
/home/arnd/cross/arm64/gcc-13.0.1-nolibc/aarch64-linux/lib/gcc/aarch64-linux/13.0.1/../../../../aarch64-linux/bin/nm
checking for aarch64-linux-ranlib...
/home/arnd/cross/arm64/gcc-13.0.1-nolibc/aarch64-linux/lib/gcc/aarch64-linux/13.0.1/../../../../aarch64-linux/bin/ranlib
checking for aarch64-linux-strip...
/home/arnd/cross/arm64/gcc-13.0.1-nolibc/aarch64-linux/lib/gcc/aarch64-linux/13.0.1/../../../../aarch64-linux/bin/strip
checking whether ln -s works... yes
checking for aarch64-linux-gcc... cc

I think libgcc should either be built with the other compiler, or it should
avoid dependencies on the having a matching target compiler version in the
definition of __LIBGCC_DWARF_CIE_DATA_ALIGNMENT__.

[Bug target/77882] [Aarch64] Add 'naked' function attribute

[stefan.tauner at gmx dot at via Gcc-bugs]

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

stefan.tauner at gmx dot at changed:

   What|Removed |Added

 CC||stefan.tauner at gmx dot at

--- Comment #13 from stefan.tauner at gmx dot at ---
Please reconsider this. I ran into this when debugging pointer authentication
not working correctly where I have to replace the prologue of a specific
existing non-trivial C function. This would be way easier with this attribute
and some inline assembly than replacing the whole function.

[Bug analyzer/108432] New: Analyzer fails to detect out-of-bounds issues within loops

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

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

Bug ID: 108432
   Summary: Analyzer fails to detect out-of-bounds issues within
loops
   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: ---

Consider:
  https://samate.nist.gov/SARD/test-cases/149169/versions/2.0.0

Without optimization, gcc trunk with -fanalyzer fails to report the
out-of-bounds write:
  https://godbolt.org/z/brx5cT18o

At -O1 and above (https://godbolt.org/z/PdvcE5MhE), we get:

: In function 'main':
:22:25: warning: iteration 9 invokes undefined behavior
[-Waggressive-loop-optimizations]
   22 | bStr[i] = (char)i + 'a';   
/* FLAW */
  | ^~~
:21:23: note: within this loop
   21 | for (i = 1; i <= 10; ++i)
  | ~~^

The analyzer probably ought to try to at least check the final iteration of a
loop (I believe it currently will at least detect issues in the initial
iteration of a loop).

[Bug target/106101] [12 Regression] ICE in reg_bitfield_target_p since r12-4428-g147ed0184f403b

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

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

--- Comment #25 from Richard Biener  ---
Andreas - can you backport this please?

[Bug target/106101] [12 Regression] ICE in reg_bitfield_target_p since r12-4428-g147ed0184f403b

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|[12/13 Regression] ICE in   |[12 Regression] ICE in
   |reg_bitfield_target_p since |reg_bitfield_target_p since
   |r12-4428-g147ed0184f403b|r12-4428-g147ed0184f403b
   Last reconfirmed|2022-06-27 00:00:00 |2023-1-17

--- Comment #24 from Richard Biener  ---
Re-confirmed on the branch (building opie), but that (the build of opie) is
fixed on trunk.

[Bug modula2/107629] runtime libs don't link on macOS

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

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

Iain Sandoe  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
 CC||iains at gcc dot gnu.org

--- Comment #2 from Iain Sandoe  ---
this is fixed in trunk.

[Bug modula2/102343] gm2/cpp/pass/subaddr.mod FAILs for non-default multilib

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

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

Iain Sandoe  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-01-17
 Status|UNCONFIRMED |NEW
   Assignee|unassigned at gcc dot gnu.org  |iains at gcc dot gnu.org
 CC||iains at gcc dot gnu.org

--- Comment #1 from Iain Sandoe  ---
this fail occurs because

 * gm2 builds its own command lines for the preprocessor (the way it works at
present, [preprocssing the main fil and all its dependent .def and .mod] means
that we cannot construct a suitable line from the driver.

 * the command line options needed to enable the correct target state in the
built preprocessor lines are not being captured from the initial command line.

I have a WIP in patch to rework the options capture and handling of stand-alone
preprocessor jobs ( e.g. gm2 -E ... )

[Bug tree-optimization/105769] [11/12/13 Regression] program segmentation fault with -ftree-vectorize and nested lambdas

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #15 from rguenther at suse dot de  ---
On Tue, 17 Jan 2023, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105769
> 
> --- Comment #14 from Jakub Jelinek  ---
> Dunno, bet we really want to introduce CLOBBER(bol) and only consider bol and
> eol clobbers for the stack reuse (or e.g. the tree-ssa-live.cc *live_vars*
> handling).
> Wonder what amount of work it would be to add that, I guess main thing will be
> what to DCE etc., if we have CLOBBER(bol) followed by normal CLOBBER with no
> aliasing stores in between, bet we must keep the former, if we have 
> CLOBBER(bol
> followed by CLOBBER(eol) with no aliasing stores in between, we could perhaps
> remove both as pair, etc.

See the RFC patches I posted last year ([PATCH 1/4][RFC] middle-end/90348 
- add explicit birth), also see how the handling wasn't entirely correct
but I also never got to finish that ...

[Bug tree-optimization/105769] [11/12/13 Regression] program segmentation fault with -ftree-vectorize and nested lambdas

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

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

--- Comment #14 from Jakub Jelinek  ---
Dunno, bet we really want to introduce CLOBBER(bol) and only consider bol and
eol clobbers for the stack reuse (or e.g. the tree-ssa-live.cc *live_vars*
handling).
Wonder what amount of work it would be to add that, I guess main thing will be
what to DCE etc., if we have CLOBBER(bol) followed by normal CLOBBER with no
aliasing stores in between, bet we must keep the former, if we have CLOBBER(bol
followed by CLOBBER(eol) with no aliasing stores in between, we could perhaps
remove both as pair, etc.

[Bug tree-optimization/105769] [11/12/13 Regression] program segmentation fault with -ftree-vectorize and nested lambdas

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #13 from rguenther at suse dot de  ---
On Tue, 17 Jan 2023, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105769
> 
> --- Comment #12 from Jakub Jelinek  ---
> (In reply to Richard Biener from comment #10)
> > I think that's the usual pattern for the two other stack-slot sharing PRs we
> > have.  The liveness analysis makes wrong assumptions about CLOBBER and
> > CLOBBER
> > isn't a barrier for address-takens (and we don't have birth CLOBBERs).
> > 
> > But why does -fstack-reuse=none not help?
> 
> Because -fstack-reuse= controls behavior of the gimplifier/inliner (what kind
> of CLOBBERs are emitted), not whether we reuse stack slots during expansion or
> not.
> And the CLOBBERs that matter here aren't coming from the -fstack-reuse=
> controlled
> ones, but from C++ lifetime DSE.

Ah - we possibly want to gate the stack-sharing code with flag_stack_reuse
then?  (OTOH with inlining across TUs with different -fstack-reuse
setting things are murky - both with testing the flag and without)

[Bug target/108240] [13 Regression] Error message missing since r13-4894-gacc727cf02a144 (then make concealed ICE exposed)

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

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

--- Comment #13 from Kewen Lin  ---
(In reply to Martin Liška from comment #11)
> One more test-case that started to ICE with the same revision:
> 
> ./xgcc -B.
> /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-2.c
> -mcpu=e300c2 -mmodulo -c
> during RTL pass: reload
> /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-2.c:
> In function ‘test_mult’:
> /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-2.c:
> 74:1: internal compiler error: maximum number of generated reload insns per
> insn achieved (90)
>74 | }
>   | ^
> 0x778bb5af __libc_start_call_main
>   ../sysdeps/nptl/libc_start_call_main.h:58
> 0x778bb678 __libc_start_main_impl
>   ../csu/libc-start.c:381
> 0xb648e4 _start
>   ../sysdeps/x86_64/start.S:115
> 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.

I think it has the same root cause as PR108415:

RS6000_CPU ("e300c2", PROCESSOR_PPCE300C2, OPTION_MASK_SOFT_FLOAT)

and also expected this ICE can be reproduced with explicit -m64 at r13-4893
(before the culprit commit r13-4894).

[Bug c/108423] [12/13 Regression] ICE in make_ssa_name_fn with VLA types in arguments and inlining since r12-5338-g4e6bf0b9dd5585df

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|[12/13 Regression] ICE in   |[12/13 Regression] ICE in
   |make_ssa_name_fn with VLA   |make_ssa_name_fn with VLA
   |types in arguments and  |types in arguments and
   |inlining|inlining since
   ||r12-5338-g4e6bf0b9dd5585df
 CC||marxin at gcc dot gnu.org,
   ||muecker at gwdg dot de

--- Comment #2 from Martin Liška  ---
Started with r12-5338-g4e6bf0b9dd5585df.

[Bug c++/108422] [13 Regression] ICE: base pointer cycle detected since r13-2661-gb57abd072dd319a7

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|[13 Regression] ICE: base   |[13 Regression] ICE: base
   |pointer cycle detected  |pointer cycle detected
   ||since
   ||r13-2661-gb57abd072dd319a7
   Last reconfirmed||2023-01-17
 Ever confirmed|0   |1
 CC||julian at codesourcery dot com,
   ||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Liška  ---
Started with r13-2661-gb57abd072dd319a7.

[Bug fortran/108420] [13 Regression] ICE in check_charlen_present, at fortran/iresolve.cc:98 since r13-4394-g3832c6f7e672e76b

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
Summary|[13 Regression] ICE in  |[13 Regression] ICE in
   |check_charlen_present, at   |check_charlen_present, at
   |fortran/iresolve.cc:98  |fortran/iresolve.cc:98
   ||since
   ||r13-4394-g3832c6f7e672e76b

--- Comment #4 from Martin Liška  ---
Started with r13-4394-g3832c6f7e672e76b.

[Bug tree-optimization/108419] [13 Regression] Dead Code Elimination Regression at -O2 since r13-440-g98e475a8f58

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

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug fortran/108431] Loop variable reaching integer `huge` causes infinte loop

[federico.perini at gmail dot com via Gcc-bugs]

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

federico  changed:

   What|Removed |Added

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

--- Comment #1 from federico  ---
I've just found from previous discussions on Fortran forums that this may not
be a bug in the compiler but rather a gray area in the Fortran standard. So I
will close the bug as "invalid".

[Bug c++/108417] [ICE] Crash on aggregate initialization of base class

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

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

--- Comment #7 from m.cencora at gmail dot com ---
Hmm, ok.
So if I wanted to workaround this in generic code, what kind of types should I
exclude from aggregate initialization? Any type that has a base class with a
tail padding? Or just the last direct base cannot have tail padding?

Also ICE-ing is not very user friendly, maybe we could use move/copy-ctor
anyway for such a non-trivial base (similarly to what clang does) or at least
error-out with a nice message.

[Bug target/108240] [13 Regression] Error message missing since r13-4894-gacc727cf02a144 (then make concealed ICE exposed)

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

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

--- Comment #12 from Segher Boessenkool  ---
We really really REALLY should neuter -mmodulo.  It is counter-productive
to have command-line flags for separate instructions at all (as opposed to
facilities), and it is downright destructive to have sneaky ways to enable
most (but not all!) of what -mcpu= does via other options.

[Bug tree-optimization/105769] [11/12/13 Regression] program segmentation fault with -ftree-vectorize and nested lambdas

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

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

--- Comment #12 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #10)
> I think that's the usual pattern for the two other stack-slot sharing PRs we
> have.  The liveness analysis makes wrong assumptions about CLOBBER and
> CLOBBER
> isn't a barrier for address-takens (and we don't have birth CLOBBERs).
> 
> But why does -fstack-reuse=none not help?

Because -fstack-reuse= controls behavior of the gimplifier/inliner (what kind
of CLOBBERs are emitted), not whether we reuse stack slots during expansion or
not.
And the CLOBBERs that matter here aren't coming from the -fstack-reuse=
controlled
ones, but from C++ lifetime DSE.

-flifetime-dse=1 option works as workaround in this case.

[Bug tree-optimization/105769] [11/12/13 Regression] program segmentation fault with -ftree-vectorize and nested lambdas

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

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

--- Comment #11 from Jakub Jelinek  ---
struct S { S *p; S *q; S () {} ~S (); };
void bar (S *);

void
foo ()
{
  S a, b;
  bar (nullptr);
  {
S c;
c.p = 
c.q = 
bar ();
  }
  bar (nullptr);
}

at -O2 gets roughly the same stuff in the IL with taking address of a and b
being done before a and b is clobbered, then c being clobbered, initialized,
eol clobbered and only then a and b destructed and eol clobbered.  But for some
reason no stack sharing happens in that case.

[Bug tree-optimization/105769] [11/12/13 Regression] program segmentation fault with -ftree-vectorize and nested lambdas

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

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

--- Comment #10 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #9)
> And just statements that refer to those 3 variables that (incorrectly) share
> the stack slot + basic block boundaries.
> grep 'bias\|D.5698\|D.5681\|:' /tmp/00
>   struct struct void D.5698;
>   struct map_t D.5681;
>   struct vec bias;
>[local count: 1073741829]:
>   _12 = (long unsigned int) 
>   bias ={v} {CLOBBER};
>   __ct_comp  (__est, );
>[local count: 1073741824]:
>   MEM  [(void *) + 32B] = _21;
>[local count: 1073741824]:
>   __ct_comp  (_14, __est);
>[local count: 1073741824]:
>   vect__16.52_79 = MEM  [(void *) + 32B];
>   __dt_base  ([(struct function *)].D.5235);
>   D.5698 ={v} {CLOBBER};
>   D.5698 ={v} {CLOBBER(eol)};
>   MEM  [(struct _Function_base *)] = {};
>   MEM  [(bool (*) (union _Any_data &
> {ref-all}, const union _Any_data & {ref-all}, _Manager_operation) *)
> + 16B] = _84;
>[count: 0]:
> :
>[count: 0]:
> :
>   __dt_base  ([(struct function *)].D.5235);
>   D.5698 ={v} {CLOBBER};
>[local count: 429496]:
>[local count: 1073312328]:
>   _19 (_M_functor, );
>[local count: 1073312328]:
>   __dt_base  ();
>   D.5681 ={v} {CLOBBER};
>   D.5681 ={v} {CLOBBER(eol)};
>   bias ={v} {CLOBBER(eol)};
>[count: 0]:
> :
>   __dt_base  ();
>   D.5681 ={v} {CLOBBER};
>   D.5681 ={v} {CLOBBER(eol)};
>[count: 0]:
> :
>   D.5698 ={v} {CLOBBER};
> 
> Now, perhaps the sharing of stack slot between D.5681 and D.5698 is fine,
> seems
> D.5698 is destructed before D.5681 is constructed:
>   D.5698 ={v} {CLOBBER};
>   D.5698 ={v} {CLOBBER(eol)};
>   MEM  [(struct _Function_base *)] = {};
> and D.5698 is later used just in EH block reachable only from earlier basic
> blocks
> or just as
>   D.5698 ={v} {CLOBBER};
> in the last EH bb.  But the sharing of the stack slot in between bias and
> D.5698 looks wrong.  What can be seen in the IL is:
>   _12 = (long unsigned int) 
> which has been hoisted before the
>   bias ={v} {CLOBBER};
> statement by the slp1 pass.
> From:
> ;;   basic block 2, loop depth 0
> ;;pred:   ENTRY
>   _3 = operator<< (, "will do (ab)");
>   endl (_3);
>   MEM[(struct vec *)_jn] ={v} {CLOBBER};
>   bias ={v} {CLOBBER};
>   MEM[(struct function *)] ={v} {CLOBBER};
>   MEM  [(struct _Function_base *)] = {};
>   MEM[(struct function *)]._M_invoker = _M_invoke;
>   MEM[(struct function *)].D.5235._M_manager = _M_manager;
>   __ct_comp  (__est, );
> ;;succ:   5
> ;;18
> 
> ;;   basic block 5, loop depth 0
> ;;pred:   2
>   D.5698.__cov = _jn;
>   D.5698.__bias = 
> in dse4 to:
> ;;   basic block 2, loop depth 0
> ;;pred:   ENTRY
>   _12 = VIEW_CONVERT_EXPR();
>   _15 = VIEW_CONVERT_EXPR(_jn);
>   _21 = {_15, _12};
>   _9 = VIEW_CONVERT_EXPR(_M_invoke);
>   _10 = VIEW_CONVERT_EXPR(_M_manager);
>   _8 = {_10, _9};
>   _3 = operator<< (, "will do (ab)");
>   endl (_3);
>   MEM[(struct vec *)_jn] ={v} {CLOBBER};
>   bias ={v} {CLOBBER};
>   MEM[(struct function *)] ={v} {CLOBBER};
>   MEM  [(struct _Function_base *)] = {};
>   MEM  [(bool (*) (union _Any_data &
> {ref-all}, const union _Any_data & {ref-all}, _Manager_operation) *)
> + 16B] = _8;
>   __ct_comp  (__est, );
> ;;succ:   5
> ;;18
>   
> ;;   basic block 5, loop depth 0
> ;;pred:   2
>   MEM  [(void *) + 32B] = _21;
> in slp1.
> 
> Is that what is incorrect? And we should never hoist taking of addresses
> before a clobber on that var?

I think that's the usual pattern for the two other stack-slot sharing PRs we
have.  The liveness analysis makes wrong assumptions about CLOBBER and CLOBBER
isn't a barrier for address-takens (and we don't have birth CLOBBERs).

But why does -fstack-reuse=none not help?

[Bug target/108240] [13 Regression] Error message missing since r13-4894-gacc727cf02a144 (then make concealed ICE exposed)

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

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

--- Comment #11 from Martin Liška  ---
One more test-case that started to ICE with the same revision:

./xgcc -B.
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-2.c
-mcpu=e300c2 -mmodulo -c
during RTL pass: reload
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-2.c:
In function ‘test_mult’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-2.c:74:1:
internal compiler error: maximum number of generated reload insns per insn
achieved (90)
   74 | }
  | ^
0x778bb5af __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x778bb678 __libc_start_main_impl
../csu/libc-start.c:381
0xb648e4 _start
../sysdeps/x86_64/start.S:115
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 tree-optimization/108430] [13 Regression] Wrong code with -msve-vector-bits=512 since r13-707-g68e0063397

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
 CC||rguenth at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
some more analysis from arm folks would be nice

[Bug tree-optimization/105769] [11/12/13 Regression] program segmentation fault with -ftree-vectorize and nested lambdas

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||matz at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
And just statements that refer to those 3 variables that (incorrectly) share
the stack slot + basic block boundaries.
grep 'bias\|D.5698\|D.5681\|:' /tmp/00
  struct struct void D.5698;
  struct map_t D.5681;
  struct vec bias;
   [local count: 1073741829]:
  _12 = (long unsigned int) 
  bias ={v} {CLOBBER};
  __ct_comp  (__est, );
   [local count: 1073741824]:
  MEM  [(void *) + 32B] = _21;
   [local count: 1073741824]:
  __ct_comp  (_14, __est);
   [local count: 1073741824]:
  vect__16.52_79 = MEM  [(void *) + 32B];
  __dt_base  ([(struct function *)].D.5235);
  D.5698 ={v} {CLOBBER};
  D.5698 ={v} {CLOBBER(eol)};
  MEM  [(struct _Function_base *)] = {};
  MEM  [(bool (*) (union _Any_data &
{ref-all}, const union _Any_data & {ref-all}, _Manager_operation) *) +
16B] = _84;
   [count: 0]:
:
   [count: 0]:
:
  __dt_base  ([(struct function *)].D.5235);
  D.5698 ={v} {CLOBBER};
   [local count: 429496]:
   [local count: 1073312328]:
  _19 (_M_functor, );
   [local count: 1073312328]:
  __dt_base  ();
  D.5681 ={v} {CLOBBER};
  D.5681 ={v} {CLOBBER(eol)};
  bias ={v} {CLOBBER(eol)};
   [count: 0]:
:
  __dt_base  ();
  D.5681 ={v} {CLOBBER};
  D.5681 ={v} {CLOBBER(eol)};
   [count: 0]:
:
  D.5698 ={v} {CLOBBER};

Now, perhaps the sharing of stack slot between D.5681 and D.5698 is fine, seems
D.5698 is destructed before D.5681 is constructed:
  D.5698 ={v} {CLOBBER};
  D.5698 ={v} {CLOBBER(eol)};
  MEM  [(struct _Function_base *)] = {};
and D.5698 is later used just in EH block reachable only from earlier basic
blocks
or just as
  D.5698 ={v} {CLOBBER};
in the last EH bb.  But the sharing of the stack slot in between bias and
D.5698 looks wrong.  What can be seen in the IL is:
  _12 = (long unsigned int) 
which has been hoisted before the
  bias ={v} {CLOBBER};
statement by the slp1 pass.
From:
;;   basic block 2, loop depth 0
;;pred:   ENTRY
  _3 = operator<< (, "will do (ab)");
  endl (_3);
  MEM[(struct vec *)_jn] ={v} {CLOBBER};
  bias ={v} {CLOBBER};
  MEM[(struct function *)] ={v} {CLOBBER};
  MEM  [(struct _Function_base *)] = {};
  MEM[(struct function *)]._M_invoker = _M_invoke;
  MEM[(struct function *)].D.5235._M_manager = _M_manager;
  __ct_comp  (__est, );
;;succ:   5
;;18

;;   basic block 5, loop depth 0
;;pred:   2
  D.5698.__cov = _jn;
  D.5698.__bias = 
in dse4 to:
;;   basic block 2, loop depth 0
;;pred:   ENTRY
  _12 = VIEW_CONVERT_EXPR();
  _15 = VIEW_CONVERT_EXPR(_jn);
  _21 = {_15, _12};
  _9 = VIEW_CONVERT_EXPR(_M_invoke);
  _10 = VIEW_CONVERT_EXPR(_M_manager);
  _8 = {_10, _9};
  _3 = operator<< (, "will do (ab)");
  endl (_3);
  MEM[(struct vec *)_jn] ={v} {CLOBBER};
  bias ={v} {CLOBBER};
  MEM[(struct function *)] ={v} {CLOBBER};
  MEM  [(struct _Function_base *)] = {};
  MEM  [(bool (*) (union _Any_data &
{ref-all}, const union _Any_data & {ref-all}, _Manager_operation) *) +
16B] = _8;
  __ct_comp  (__est, );
;;succ:   5
;;18

;;   basic block 5, loop depth 0
;;pred:   2
  MEM  [(void *) + 32B] = _21;
in slp1.

Is that what is incorrect? And we should never hoist taking of addresses before
a clobber on that var?

[Bug target/108396] [12/13 Regression] PPCLE: vec_vsubcuq missing since r12-5752-gd08236359eb229

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

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

--- Comment #5 from Segher Boessenkool  ---
(In reply to Segher Boessenkool from comment #3)
> Is it hard to add one for all (or many) of the legacy builtins?  Do we want
> to test more than just if it compiles?

Btw, "legacy"...  I thought (from the names) this is one of the old VMX
things, but it is the "q" version, ISA 2.07 .  But it still would be nice
if we could at least have trivial compilation tests for this :-)

[Bug tree-optimization/105769] [11/12/13 Regression] program segmentation fault with -ftree-vectorize and nested lambdas

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

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

--- Comment #8 from Jakub Jelinek  ---
Using last night's trunk, it is:
#include 
#include 
#include 

template
struct vec {
  T dat[n];
  vec() {}
  explicit vec(const T& x) { for(size_t i = 0; i < n; i++) dat[i] = x; }
  T& operator [](size_t i) { return dat[i]; }
  const T& operator [](size_t i) const { return dat[i]; }
};

template
using mat = vec>;
template
using sq_mat = mat;
using map_t = std::function;
template
using est_t = std::function; template using est2_t =
std::function;
map_t id_map() { return [](size_t j) -> size_t { return j; }; }

template
est2_t jacknife(const est_t> est, sq_mat& cov, vec&
bias) {
  return [est, , ](map_t map) -> void { bias = est(map); for(size_t i
= 0; i < n; i++) std::cout << bias[i] << std::endl; };
}

template
void print_cov_ratio() {
  sq_mat<2, T> cov_jn;
  vec<2, T> bias;
  jacknife<2, T>([](map_t map) -> vec<2, T> { vec<2, T> retv; retv[0] = 1;
retv[1] = 1; return retv; }, cov_jn, bias)(id_map());
}
struct ab {
  long long unsigned a;
  short unsigned b;
  double operator()() { return a; }
  ab& operator=(double rhs) { a = rhs; return *this; }
  friend std::ostream& operator<<(std::ostream&, const ab&);
};
std::ostream& operator<<(std::ostream& os, const ab& x) { os << x.a; return os;
}

int main() {
  std::cout << "will do (ab)" << std::endl;
  print_cov_ratio();
  return 0;
}

Partition 4: size 64 align 16
cov_jn
Partition 0: size 48 align 16
D.5698  biasD.5681
Partition 1: size 32 align 16
D.5683
Partition 2: size 32 align 16
D.5682
where
  struct struct void D.5698;
  struct est2_t D.5683;
  struct est_t D.5682;
  struct map_t D.5681;
  struct sq_mat cov_jn;
  struct vec bias;
aka D.5682 is the est argument slot - const est_t> est, D.5683 is the
return slot from jacknife est2_t, D.5698 is the lambda object which
contains __est, __cov, __bias and cov_jn and bias the automatic variables in
print_cov_ratio and
D.5681 return value slot of id_map.
main in ltrans optimized dump is mostly serial code with some EH edges, except
for one
_M_manager == nullptr check (if nullptr it throws bad function call, otherwise
continues).
Now, those vars are referenced in:
  _12 = (long unsigned int) 
  _15 = (long unsigned int) _jn;
  _21 = {_15, _12};
...
  MEM[(struct vec *)_jn] ={v} {CLOBBER};
  bias ={v} {CLOBBER};
  MEM[(struct function *)] ={v} {CLOBBER};
  MEM  [(struct _Function_base *)] = {};
  MEM  [(bool (*) (union _Any_data &
{ref-all}, const union _Any_data & {ref-all}, _Manager_operation) *) +
16B] = _8;
  __ct_comp  (__est, );
...
  MEM  [(void *) + 32B] = _21;
  MEM[(struct function *)] ={v} {CLOBBER};
  MEM[(struct function *)].D.5217 = {};
  MEM[(struct function *)]._M_invoker = 0B;
...
  _14 = [(struct struct void *)_13].__est;
  __ct_comp  (_14, __est);
...
  MEM[(struct struct void * &)] = _13;
  MEM  [(bool (*) (union _Any_data &
{ref-all}, const union _Any_data & {ref-all}, _Manager_operation) *) +
16B] = _7;
  __dt_base  ([(struct function *)].D.5235);
  D.5698 ={v} {CLOBBER};
  D.5698 ={v} {CLOBBER(eol)};
  MEM  [(struct _Function_base *)] = {};
  MEM  [(bool (*) (union _Any_data &
{ref-all}, const union _Any_data & {ref-all}, _Manager_operation) *) +
16B] = _84;
  _18 = MEM[(const struct _Function_base *)]._M_manager;
...
  _19 = D.5683._M_invoker;
  _19 (_M_functor, );
...
  __dt_base  ();
  D.5681 ={v} {CLOBBER};
  D.5681 ={v} {CLOBBER(eol)};
  __dt_base  ();
  D.5683 ={v} {CLOBBER};
  __dt_base  ();
  D.5682 ={v} {CLOBBER};
  D.5682 ={v} {CLOBBER(eol)};
  D.5683 ={v} {CLOBBER(eol)};
  cov_jn ={v} {CLOBBER(eol)};
  bias ={v} {CLOBBER(eol)};
  return 0;

and some EH stuff.

[Bug fortran/108431] New: Loop variable reaching integer `huge` causes infinte loop

[federico.perini at gmail dot com via Gcc-bugs]

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

Bug ID: 108431
   Summary: Loop variable reaching integer `huge` causes infinte
loop
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: federico.perini at gmail dot com
  Target Milestone: ---

Consider the following tiny program:

program test_huge
use iso_fortran_env, only: int8
integer(int8) :: i
do i=-huge(i),huge(i)
   print "('i=',i10,' b=',b8.8)", i,i
end do
end

With gfortran 12.2 on Mac, this causes an infinite loop that never ends. I
guess there is a problem with huge(i)=127, because if use the same bounds with
an implicit loop, I get:


3 | integer(int8), parameter :: a(*) = [(i,i=-huge(i),huge(i))]
  |  1
Warning: DO loop at (1) is undefined as it overflows [-Wundefined-do-loop]

I've put this example on godbolt at https://godbolt.org/z/6x7K9a6a3 . 
Apparently, this issue affects all gfortran versions from 7.1 up (6.3 is the
last working version), 

Federico

[Bug tree-optimization/106523] [10/11/12 Regression] forwprop miscompile

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10/11/12/13 Regression]|[10/11/12 Regression]
   |forwprop miscompile |forwprop miscompile

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

[Bug tree-optimization/106523] [10/11/12/13 Regression] forwprop miscompile

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

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

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

https://gcc.gnu.org/g:001121e8921d5d1a439ce0e64ab04c5959b0bfd8

commit r13-5223-g001121e8921d5d1a439ce0e64ab04c5959b0bfd8
Author: Jakub Jelinek 
Date:   Tue Jan 17 12:14:25 2023 +0100

forwprop: Fix up rotate pattern matching [PR106523]

The comment above simplify_rotate roughly describes what patterns
are matched into what:
   We are looking for X with unsigned type T with bitsize B, OP being
   +, | or ^, some type T2 wider than T.  For:
   (X << CNT1) OP (X >> CNT2)   iff CNT1 + CNT2 ==
B
   ((T) ((T2) X << CNT1)) OP ((T) ((T2) X >> CNT2)) iff CNT1 + CNT2 ==
B

   transform these into:
   X r<< CNT1

   Or for:
   (X << Y) OP (X >> (B - Y))
   (X << (int) Y) OP (X >> (int) (B - Y))
   ((T) ((T2) X << Y)) OP ((T) ((T2) X >> (B - Y)))
   ((T) ((T2) X << (int) Y)) OP ((T) ((T2) X >> (int) (B - Y)))
   (X << Y) | (X >> ((-Y) & (B - 1)))
   (X << (int) Y) | (X >> (int) ((-Y) & (B - 1)))
   ((T) ((T2) X << Y)) | ((T) ((T2) X >> ((-Y) & (B - 1
   ((T) ((T2) X << (int) Y)) | ((T) ((T2) X >> (int) ((-Y) & (B - 1

   transform these into (last 2 only if ranger can prove Y < B):
   X r<< Y

   Or for:
   (X << (Y & (B - 1))) | (X >> ((-Y) & (B - 1)))
   (X << (int) (Y & (B - 1))) | (X >> (int) ((-Y) & (B - 1)))
   ((T) ((T2) X << (Y & (B - 1 | ((T) ((T2) X >> ((-Y) & (B - 1
   ((T) ((T2) X << (int) (Y & (B - 1 \
 | ((T) ((T2) X >> (int) ((-Y) & (B - 1

   transform these into:
   X r<< (Y & (B - 1))

The following testcase shows that 2 of these are problematic.
If T2 is wider than T, then the 2 which yse (-Y) & (B - 1) on one
of the shift counts but Y on the can do something different from
rotate.  E.g.:
__attribute__((noipa)) unsigned char
f7 (unsigned char x, unsigned int y)
{
  unsigned int t = x;
  return (t << y) | (t >> ((-y) & 7));
}
if y is [0, 7], then it is a normal rotate, and if y is in [32, ~0U]
then it is UB, but for y in [9, 31] the left shift in this case
will never leave any bits in the result, while in a rotate they are
left there.  Say for y 5 and x 0xaa the expression gives
0x55 which is the same thing as rotate, while for y 19 and x 0xaa
0x5, which is different.
Now, I believe the
   ((T) ((T2) X << Y)) OP ((T) ((T2) X >> (B - Y)))
   ((T) ((T2) X << (int) Y)) OP ((T) ((T2) X >> (int) (B - Y)))
forms are ok, because B - Y still needs to be a valid shift count,
and if Y > B then B - Y should be either negative or very large
positive (for unsigned types).
And similarly the last 2 cases above which use & (B - 1) on both
shift operands are definitely ok.

The following patch disables the
   ((T) ((T2) X << Y)) | ((T) ((T2) X >> ((-Y) & (B - 1
   ((T) ((T2) X << (int) Y)) | ((T) ((T2) X >> (int) ((-Y) & (B - 1
unless ranger says Y is not in [B, B2 - 1] range.

And, looking at it again this morning, actually the Y equal to B
case is still fine, if Y is equal to 0, then it is
(T) (((T2) X << 0) | ((T2) X >> 0))
and so X, for Y == B it is
(T) (((T2) X << B) | ((T2) X >> 0))
which is the same as
(T) (0 | ((T2) X >> 0))
which is also X.  So instead of the [B, B2 - 1] range we could use
[B + 1, B2 - 1].  And, if we wanted to go further, even multiplies
of B are ok if they are smaller than B2, so we could construct a detailed
int_range_max if we wanted.

2023-01-17  Jakub Jelinek  

PR tree-optimization/106523
* tree-ssa-forwprop.cc (simplify_rotate): For the
patterns with (-Y) & (B - 1) in one operand's shift
count and Y in another, if T2 has wider precision than T,
punt if Y could have a value in [B, B2 - 1] range.

* c-c++-common/rotate-2.c (f5, f6, f7, f8, f13, f14, f15, f16,
f37, f38, f39, f40, f45, f46, f47, f48): Add assertions using
__builtin_unreachable about shift count.
* c-c++-common/rotate-2b.c: New test.
* c-c++-common/rotate-4.c (f5, f6, f7, f8, f13, f14, f15, f16,
f37, f38, f39, f40, f45, f46, f47, f48): Add assertions using
__builtin_unreachable about shift count.
* c-c++-common/rotate-4b.c: New test.
* gcc.c-torture/execute/pr106523.c: New test.

[Bug tree-optimization/108430] New: [13 Regression] Wrong code with -msve-vector-bits=512 since r13-707-g68e0063397

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

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

Bug ID: 108430
   Summary: [13 Regression] Wrong code with -msve-vector-bits=512
since r13-707-g68e0063397
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acoplan at gcc dot gnu.org
  Target Milestone: ---

For the following testcase:

static long d;
static int i = 37;
static unsigned long a[22];
static unsigned short c[22];
static unsigned g[80];
static unsigned short *h = c;
static unsigned long *j = a;
int main() {
  for (long m = 0; m < 8; ++m)
d = 1;
  for (unsigned char p = 0; p < 17; p += (d ? i : 0) - 35)
  {
long t = h[p] ? i : j[p];
g[p] = t;
  }
  if (g[0])
__builtin_abort ();
}

we appear to miscompile it with -O3 -march=armv8.2-a+sve -msve-vector-bits=512
since r13-707-g68e0063397ba820e71adc220b2da0581dce29ffa :


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

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

[Bug target/108429] [13 Regression] FAIL: gcc.target/i386/pr89618.c scan-tree-dump vect "LOOP VECTORIZED"

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-01-17
 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Started with r13-5202-g967592488c64a86f37bef3dabebb56364f14acdd

[Bug target/108415] ICE in emit_library_call_value_1 at gcc/calls.cc:4181

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

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

--- Comment #1 from Segher Boessenkool  ---
Soft float does not conflict with anything (anything that does not need
FP registers that is).  But yes, we really should neuter -mmodulo.

[Bug target/108429] [13 Regression] FAIL: gcc.target/i386/pr89618.c scan-tree-dump vect "LOOP VECTORIZED"

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

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

Richard Biener  changed:

   What|Removed |Added

 Blocks||53947

--- Comment #2 from Richard Biener  ---
We now have X86_TUNE_USE_SCATTER_[{2,4}PARTS] but the vectorizer doesn't
have support to open-code 2- or 4- part scatter so the comment that open-coded
variants are consistently faster doesn't help vectorization.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug target/108429] [13 Regression] FAIL: gcc.target/i386/pr89618.c scan-tree-dump vect "LOOP VECTORIZED"

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org
   Target Milestone|--- |13.0
 Target||x86_64-*-*
Summary|FAIL:   |[13 Regression] FAIL:
   |gcc.target/i386/pr89618.c   |gcc.target/i386/pr89618.c
   |scan-tree-dump vect "LOOP   |scan-tree-dump vect "LOOP
   |VECTORIZED" |VECTORIZED"
   Keywords||missed-optimization,
   ||testsuite-fail

--- Comment #1 from Richard Biener  ---
/home/rguenther/src/trunk/gcc/testsuite/gcc.target/i386/pr89618.c:14:7: missed:
  unsupported emulated scatter.
/home/rguenther/src/trunk/gcc/testsuite/gcc.target/i386/pr89618.c:16:14:
missed:   not vectorized: relevant stmt not supported: *_26 = iftmp.0_39;

note the testcase enables -mavx512f but with generic tuning

[Bug target/108429] New: FAIL: gcc.target/i386/pr89618.c scan-tree-dump vect "LOOP VECTORIZED"

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

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

Bug ID: 108429
   Summary: FAIL: gcc.target/i386/pr89618.c scan-tree-dump vect
"LOOP VECTORIZED"
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

The testcase FAILs for me since recently.

[Bug middle-end/106075] Wrong DSE with -fnon-call-exceptions

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Biener  ---
I think the IL is somewhat buggy in the control transfer instruction not being
indicated as reading from global memory.  I think it should act similar to
a GIMPLE_RETURN where we now force a VUSE.  There's a related bug about
GIMPLE_RESX not having virtual operands and the issue DSE has with this.

Now, that would mean that for the original testcase a fix would be simply
to consider all throwing points uses (for global memory).  I have a patch
to do that, leaving the IL issue (the throwing division case and RESX)
unfixed.  Note that RTL DSE happily removes the first store as well, so
I had to fix that as well.