[Bug ada/100486] Ada build fails for 32bit Windows

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

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

--- Comment #20 from Eric Botcazou  ---
> Adding --enable-frame-pointer makes no difference. No change either adding
> 
> --enable-large-address-aware --with-fpmath=sse --disable-sjlj-exceptions
> --enable-frame-pointer --disable-libada --enable-libstdcxx
> 
> Another data point: for the test mentioned on Comment 16, if I replace
> libstdc++.dll with the same file from gcc 10, the test works.

Weird, I don't have any dependency on the DLL for it:

$ ldd t.exe
ntdll.dll => /Windows/SYSTEM32/ntdll.dll (0x7ffc6556)
ntdll.dll => /Windows/SysWOW64/ntdll.dll (0x770b)
wow64.dll => /Windows/System32/wow64.dll (0x5d1b)
wow64win.dll => /Windows/System32/wow64win.dll (0x5d21)

Can you post the output of 'g++ foo.cpp -v' for your C++ testcase?  Can you
find out what symbol(s) of libstdc++.dll are referenced by your executable?

[Bug middle-end/21111] IA-64 NaT consumption faults due to uninitialized register reads

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

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

--- Comment #17 from Richard Biener  ---
So to sum up, a SSA default def would have to be expanded to an explicit (zero)
initialization.  I suppose memory doesn't have a NaT state so stack allocation
for locals doesn't have to change but decls eventually expanding to pseudos
would have to go through the same exercise.

Since we now have -ftrivial-auto-var-init=zero that might serve as a workaround
for GCC 12.

But I guess trying to fix this in RTL expansion shouldn't be too difficult
(gated with a new target hook), if anyone really cares.  Do any better
maintained archs than ia64 have NaTs?  NVPTX was mentioned, but I guess
that's not really easier to handle since it's also a meta-ISA.

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

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

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

--- Comment #43 from Martin Liška  ---
(In reply to Eric Gallager from comment #42)
> Is this just about parallelism bottlenecks for the main build target (e.g.
> just `make` or `make all`), or does it apply to other Makefile targets, too?
> (e.g. the testsuite via `make check`, or docs via `make pdf` or something)

Well, it was intended to cover only the main build, which pdf can be seen as
part of. On the other hand, `make check` should belong to a different PR if you
have troubles with it.

[Bug tree-optimization/102497] gimple-predicate-analysis.cc:2143:1: warning: function 'add_pred' is not needed and will not be emitted [-Wunneeded-internal-declaration]

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

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

--- Comment #3 from Martin Liška  ---
@Martin: Can you please take a look?

[Bug tree-optimization/102681] AArch64 bootstrap failure

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

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

Tamar Christina  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=102631
   Last reconfirmed||2021-10-11

--- Comment #2 from Tamar Christina  ---
yeah it's been broken for a while now. While it's being sorted out you can
disable werror, which is not ideal but gets things moving again.

[Bug c++/102593] [10/11/12 Regression] ICE in cp_oacc_check_attachments, at cp/semantics.c:6561 since r10-5596-g519d7496beac32c2

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||julian at codesourcery dot com,
   ||marxin at gcc dot gnu.org
   Last reconfirmed||2021-10-11
 Status|UNCONFIRMED |NEW
Summary|[10/11/12 Regression] ICE   |[10/11/12 Regression] ICE
   |in  |in
   |cp_oacc_check_attachments,  |cp_oacc_check_attachments,
   |at cp/semantics.c:6561  |at cp/semantics.c:6561
   ||since
   ||r10-5596-g519d7496beac32c2

--- Comment #1 from Martin Liška  ---
Started with r10-5596-g519d7496beac32c2, it was rejected before the revision.

[Bug c++/102594] ICE in decay_conversion, at cp/typeck.c:2311 since r8-7514-ge278212eeea4f57d

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
Summary|ICE in decay_conversion, at |ICE in decay_conversion, at
   |cp/typeck.c:2311|cp/typeck.c:2311 since
   ||r8-7514-ge278212eeea4f57d
   Last reconfirmed||2021-10-11
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org,
   ||paolo.carlini at oracle dot com

--- Comment #1 from Martin Liška  ---
Confirmed, started with r8-7514-ge278212eeea4f57d.

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

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
Summary|ICE in var_element, at  |ICE in var_element, at
   |fortran/decl.c:298  |fortran/decl.c:298 since
   ||r10-5607-gde89b5748d68b76b

--- Comment #2 from Martin Liška  ---
Started with r10-5607-gde89b5748d68b76b.

[Bug fortran/102596] [11/12 Regression] ICE in gfc_omp_clause_default_ctor, at fortran/trans-openmp.c:713 since r11-4883-ge929ef532ad52cde

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
   Last reconfirmed||2021-10-11
 Ever confirmed|0   |1
Summary|[11/12 Regression] ICE in   |[11/12 Regression] ICE in
   |gfc_omp_clause_default_ctor |gfc_omp_clause_default_ctor
   |, at|, at
   |fortran/trans-openmp.c:713  |fortran/trans-openmp.c:713
   ||since
   ||r11-4883-ge929ef532ad52cde
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Liška  ---
Started with r11-4883-ge929ef532ad52cde.

[Bug fortran/102597] ICE in gfc_get_extern_function_decl, at fortran/trans-decl.c:2243 since r8-3365-gb89a63b916340ef2

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2021-10-11
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
Summary|ICE in  |ICE in
   |gfc_get_extern_function_dec |gfc_get_extern_function_dec
   |l, at   |l, at
   |fortran/trans-decl.c:2243   |fortran/trans-decl.c:2243
   ||since
   ||r8-3365-gb89a63b916340ef2
 CC||marxin at gcc dot gnu.org,
   ||pault at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Started likely with r8-3365-gb89a63b916340ef2.

[Bug fortran/102619] [10/11/12 Regression] ICE in gfc_conv_descriptor_dtype, at fortran/trans-array.c:215 since r9-6493-g0e3088806577e805

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
Summary|[10/11/12 Regression] ICE   |[10/11/12 Regression] ICE
   |in  |in
   |gfc_conv_descriptor_dtype,  |gfc_conv_descriptor_dtype,
   |at  |at
   |fortran/trans-array.c:215   |fortran/trans-array.c:215
   ||since
   ||r9-6493-g0e3088806577e805
   Last reconfirmed||2021-10-11
 CC||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #2 from Martin Liška  ---
Started likely with r9-6493-g0e3088806577e805.

[Bug fortran/102620] [12 Regression] ICE in gfc_get_array_span, at fortran/trans-array.c:865 since r12-1233-gd514626ee2566c68

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|[12 Regression] ICE in  |[12 Regression] ICE in
   |gfc_get_array_span, at  |gfc_get_array_span, at
   |fortran/trans-array.c:865   |fortran/trans-array.c:865
   ||since
   ||r12-1233-gd514626ee2566c68
 CC||jrfsousa at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
Confirmed, started with r12-1233-gd514626ee2566c68.

[Bug fortran/102621] [12 Regression] ICE in convert_nonlocal_reference_op, at tree-nested.c:1166 since r12-1108-g9a5de4d5af1c10a8

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-10-11
Summary|[12 Regression] ICE in  |[12 Regression] ICE in
   |convert_nonlocal_reference_ |convert_nonlocal_reference_
   |op, at tree-nested.c:1166   |op, at tree-nested.c:1166
   ||since
   ||r12-1108-g9a5de4d5af1c10a8
 CC||burnus at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Started with r12-1108-g9a5de4d5af1c10a8.

[Bug tree-optimization/102648] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
Summary|Dead Code Elimination   |[12 Regression] Dead Code
   |Regression at -O3 (trunk vs |Elimination Regression at
   |11.2.0) |-O3 (trunk vs 11.2.0)
   Keywords||missed-optimization

[Bug target/15533] Missed move to partial register

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Uroš Bizjak  ---
(In reply to Cesar Eduardo Barros from comment #0)
> When compiling:
> #include 
> #define regparm __attribute__((regparm(3)))
> uint8_t a;
> uint16_t regparm fn(uint16_t b)
> { return (b & ~0xFF) | a; }

This should probably be optimized in match.pd to BIT_INSERT_EXPR.

[Bug c++/102626] [c++20] compiler crash when invoking constexpr function in the constructor of template class

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Confirmed.

[Bug rtl-optimization/102627] [11 Regression] wrong code with "-O1"

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |vmakarov at gcc dot 
gnu.org
Summary|[11/12 Regression] wrong|[11 Regression] wrong code
   |code with "-O1" |with "-O1"
 Status|NEW |ASSIGNED

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

[Bug tree-optimization/102650] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Target Milestone|--- |12.0
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-10-11
Summary|Dead Code Elimination   |[12 Regression] Dead Code
   |Regression at -O3 (trunk vs |Elimination Regression at
   |11.2.0) |-O3 (trunk vs 11.2.0)

--- Comment #2 from Richard Biener  ---
(In reply to Andrew Macleod from comment #1)
> This is a result of the vagaries of the single subrange value-range.
> 
> VRP is seeing:
> # f_11 = PHI <-1(2), 2(3)>
>   goto ; [100.00%]
> 
>[local count: 955630225]:
>   _3 = (unsigned short) f_11;
>   _6 = _3 + 2;
>   e_19 = (short int) _6;
> 
> It knows f_11 is [-1, 2] and when that is cast to a ushort,  produces ~[3,
> 65534].
> 
> That is all we knew about it in GCC11, so when we calculate_6 = ~[3,65534] +
> 2  it comes up with [1,4] and the e_19 == 0 later on then can be folded away.
> 
> in gcc12, EVRP has figured out that _3 is unsigned short [2, 2][+INF, +INF].
> which if we add 2 to it, would come up with [1,1][4,4] which would be
> perfect.
> 
> We save this to the value_range global table in EVRP, but alas it gets
> transliterated to a single pair value_range : _3  : unsigned short [2, +INF]

That translation could see whether the corresponding anti-rante ~[3,65534] is
smaller (which it is) and use that instead?

[Bug tree-optimization/15533] Missed move to partial register

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|target  |tree-optimization
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org

--- Comment #7 from Andrew Pinski  ---
Mine for gcc 13.

[Bug c++/102654] [11/12 Regression] undefined reference to `std::variant::variant

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug testsuite/102658] [12 regression] Many test case failures after r12-4240

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug c++/102626] [c++20] compiler crash when invoking constexpr function in the constructor of template class

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Slightly reduced:
template  struct P;

template 
struct P {
  static constexpr int size() { return (sizeof(S{}.*ms) + ...); }
  int sz;
  P() : sz(size()) {}
};
struct A { int x, y; };
auto p = P();

[Bug middle-end/21111] IA-64 NaT consumption faults due to uninitialized register reads

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

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

--- Comment #18 from Alexander Monakov  ---
>From my perspective, the main blocker for a nice and clean solution is lack of
"birth" statements on GIMPLE.

Without them, expansion to RTL would either need to insert initialization at
the top of the function (which is silly, extends lifetimes of pseudos that only
live in a small region, complicating RA), or compute something like a lowest
common dominator of all uses and place an initialization there. But perhaps
that's the right way if "birth statements" aren't happening?

Or is there some other approach? Like not trying to insert a single
initialization, but instead substituting a zero in place of each use of the
default def individually?

[Bug tree-optimization/102659] -O2 vectorization if-conversion produces wrong code for gcc.dg/torture/pr69760.c

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2021-10-11
Summary|[false diagnosis] extra |-O2 vectorization
   |warning info after O2   |if-conversion produces
   |vectorization for   |wrong code for
   |gcc.dg/torture/pr69760.c|gcc.dg/torture/pr69760.c
  Component|debug   |tree-optimization
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords|diagnostic  |wrong-code

--- Comment #1 from Richard Biener  ---
With -flto we have range info on the test_func function arguments (w/o -flto as
well if you make the function static).

  # RANGE [1000, 1000] NONZERO 1000
  int L_16(D) = L;
  # RANGE [0, 400] NONZERO 508
  int m_13(D) = m;
  # RANGE [4, 4] NONZERO 4
  int n_15(D) = n;
  # RANGE [400, 400] NONZERO 400
  int N_12(D) = N;

the warning is emitted from the max_loop_iterations call in
vect_truncate_gather_scatter_offset, so it's not because something is
vectorized but because we run the vectorizer.  It's also emitted on
the if-converted code only because only then the address computation
of the a[L * k] = 0.0; store can be used to bound the number of iterations.

And indeed the address calculation overflows 32bit memory so this is a problem
with if-conversion since n == 4 and thus

  if (k >= 0 && k < n)
a[L * k] = 0.0;

will never trigger in iteration 54.

if-conversion doesn't check whether it makes conditional integer overflow
non-conditional.  I think we might have a duplicate report of the problem
somewhere though.

[Bug tree-optimization/102659] -O2 vectorization if-conversion produces wrong code for gcc.dg/torture/pr69760.c

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

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

--- Comment #2 from Richard Biener  ---
If you change the testcase as follows the issue pops up at plain -O2 as well

diff --git a/gcc/testsuite/gcc.dg/torture/pr69760.c
b/gcc/testsuite/gcc.dg/torture/pr69760.c
index 53733c7c6a4..47e01ae59bd 100644
--- a/gcc/testsuite/gcc.dg/torture/pr69760.c
+++ b/gcc/testsuite/gcc.dg/torture/pr69760.c
@@ -1,11 +1,10 @@
 /* PR tree-optimization/69760 */
 /* { dg-do run { target { { *-*-linux* *-*-gnu* *-*-uclinux* } && mmap } } }
*/
-/* { dg-options "-O2" } */

 #include 
 #include 

-__attribute__((noinline, noclone)) void
+__attribute__((noinline, noclone)) static void
 test_func (double *a, int L, int m, int n, int N)
 {
   int i, k;

[Bug tree-optimization/102659] -O2 vectorization if-conversion produces wrong code for gcc.dg/torture/pr69760.c

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
I will have a look.

[Bug libgomp/102668] [12 regression] several libgomp alloc test case failures after r12-3976

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug bootstrap/102675] [12 regression] Bootstrap fails in libsanitizer: 'MD5_DIGEST_STRING_LENGTH' was not declared in this scope

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
Version|unknown |12.0
   Target Milestone|--- |12.0

--- Comment #5 from Richard Biener  ---
or adjust the code to the libiberty provided md5.h which is available
everywhere

[Bug tree-optimization/102676] Failure to optimize out malloc/nothrow allocation that's only used for bool checking

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2021-10-11
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #3 from Richard Biener  ---
We don't eliminate a malloc that's just used in a conditional, I think there's
a related bugreport with

  p = malloc (n)
  if (!p)
abort ();
  free (p);

or sth like that where we fail to elide the allocation.  Note in this case
failing allocation _would_ have a side-effect.

[Bug bootstrap/102681] [12 Regression] AArch64 bootstrap failure

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

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

Richard Biener  changed:

   What|Removed |Added

  Component|tree-optimization   |bootstrap
Summary|AArch64 bootstrap failure   |[12 Regression] AArch64
   ||bootstrap failure
   Priority|P3  |P1
   Target Milestone|--- |12.0
Version|unknown |12.0
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Keywords||build, diagnostic
 Target||aarch64

[Bug rtl-optimization/45223] RTL PRE GCSE pass hoists trapping insn out of loop

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

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

--- Comment #9 from Richard Biener  ---
But this but is about non-MEMs while the fixes were involving only memory ops
IIRC.

[Bug middle-end/21111] IA-64 NaT consumption faults due to uninitialized register reads

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

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

--- Comment #19 from Richard Biener  ---
(In reply to Alexander Monakov from comment #18)
> From my perspective, the main blocker for a nice and clean solution is lack
> of "birth" statements on GIMPLE.

They were not needed until now ;)

> Without them, expansion to RTL would either need to insert initialization at
> the top of the function (which is silly, extends lifetimes of pseudos that
> only live in a small region, complicating RA), or compute something like a
> lowest common dominator of all uses and place an initialization there. But
> perhaps that's the right way if "birth statements" aren't happening?

Yes, note that an explicit birth also affects SSA coalescing so they would
need to be introduced before liveness computation or alternatively
be inserted in possibly multiple places when the reg becomes live.

> Or is there some other approach? Like not trying to insert a single
> initialization, but instead substituting a zero in place of each use of the
> default def individually?

That would of course also work - use replace_uses_by to replace default
defs with zero for modes that have a NaT (I don't think we have an existing
way to check that though).

But maybe one wants to preserve NaT trapping for uninit uses (though that
would require active seeding of default defs with a NaT rather than with
a non-NaT since otherwise the register content is just random and not a NaT).

[Bug tree-optimization/102622] [9/10 Regression] Wrong code with -O1 and above due to phiopt and signed one bit integer types

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

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

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

https://gcc.gnu.org/g:4111b36079fed95b787fafeed1deaab2dedaf3db

commit r10-10177-g4111b36079fed95b787fafeed1deaab2dedaf3db
Author: Andrew Pinski 
Date:   Sun Oct 10 23:12:11 2021 +

[GCC 10 branch] tree-optimization: [PR102622]: wrong code due to signed one
bit integer and "a?-1:0"

So here is the GCC 10 branch version which fixes the wrong code.
The problem is we create a negation of an one bit signed integer type
which is undefined if the value was -1.
This is not needed for GCC 11 branch since the case is handled differently
there and has been fixed there (and the trunk has now been fixed too).
So for one bit types, there is no reason to create the negation so just
setting neg to false for them, just works.

OK? Bootstrapped and tested on x86_64-linux-gnu.

PR tree-optimization/102622

gcc/ChangeLog:

* tree-ssa-phiopt.c (conditional_replacement): Set neg
to false for one bit signed types.

gcc/testsuite/ChangeLog:

* gcc.c-torture/execute/bitfld-10.c: New test.

[Bug tree-optimization/102622] [9 Regression] Wrong code with -O1 and above due to phiopt and signed one bit integer types

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||10.3.1
Summary|[9/10 Regression] Wrong |[9 Regression] Wrong code
   |code with -O1 and above due |with -O1 and above due to
   |to phiopt and signed one|phiopt and signed one bit
   |bit integer types   |integer types

--- Comment #25 from Andrew Pinski  ---
Fixed in GCC 10.4.0 now.  Will backport the GCC 10 patch tomorrow/later today.

[Bug c++/102626] [c++20] compiler crash when invoking constexpr function in the constructor of template class

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

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #3 from Martin Liška  ---
Started with introduction of -std=c++2a (r8-3237-g026a79f70cf33f83).
Btw. clang accepts the code, so like ice-on-valid-code.

[Bug c++/102629] ICE: tree check: expected record_type or union_type or qual_union_type, have decltype_type in lookup_base, at cp/search.c:233 since r10-2194-g10acaf4db9f8b54b

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
Summary|internal compiler error:|ICE: tree check: expected
   |tree check: expected|record_type or union_type
   |record_type or union_type   |or qual_union_type, have
   |or qual_union_type, have|decltype_type in
   |decltype_type in|lookup_base, at
   |lookup_base, at |cp/search.c:233 since
   |cp/search.c:233 |r10-2194-g10acaf4db9f8b54b

--- Comment #1 from Martin Liška  ---
Likely started with r10-2194-g10acaf4db9f8b54b, it was rejected before the
revision.

[Bug c++/102642] [12 Regression] ICE in get, at cgraph.h:2776 since r12-4032-g701075864ac4d1c6

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2021-10-11
Summary|[12 Regression] ICE in get, |[12 Regression] ICE in get,
   |at cgraph.h:2776|at cgraph.h:2776 since
   ||r12-4032-g701075864ac4d1c6
 Status|UNCONFIRMED |NEW
  Known to fail||12.0
  Known to work||11.2.0

--- Comment #1 from Martin Liška  ---
Started with r12-4032-g701075864ac4d1c6.

[Bug c++/102643] Segfault in alias template deduction

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Fixed with r12-1744-g3eecc1db4c691a87, so likely dup of PR86439.

[Bug tree-optimization/102646] large performance changes between 1932e1169a236849f5e7f1cd386da100d9af470f and 9cfb95f9b92326e86e99b50350ebf04fa9cd2477 (probably jump threading)

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
I think most of the regressions are fixed, we get even better numbers now.

[Bug libstdc++/100912] powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++

[qiu.chaofan at outlook dot com via Gcc-bugs]

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

Qiu Chaofan  changed:

   What|Removed |Added

 CC||qiu.chaofan at outlook dot com

--- Comment #5 from Qiu Chaofan  ---
Hi, I encountered the same problem when dynamically linking against libstdcxx,
while static linking works fine. The HEAD of git history is 8f323c712 (early
Sep.) so it shouldn't be old.

The configure option is: --enable-languages=c,c++ --disable-nls
--disable-bootstrap --with-long-double-format=ieee --disable-libgomp
--enable-multilib --with-cpu=power9 --with-advance-toolchain=at15.0

(Disabling multilib still has this issue)

By digging into make log, I found something interesting (some omitted):

libtool: link:  /build/./gcc/xgcc -shared-libgcc ... -fPIC -DPIC
-D_GLIBCXX_SHARED -shared -nostdlib /opt/at15.0/lib/../lib64/crti.o
/build/./gcc/crtbeginS.o  .libs/compatibility.o
.libs/compatibility-debug_list.o .libs/compatibility-debug_list-2.o
.libs/compatibility-ldbl.o .libs/compatibility-c++0x.o
.libs/compatibility-atomic-c++0x.o .libs/compatibility-thread-c++0x.o
.libs/compatibility-chrono.o .libs/compatibility-condvar.o
.libs/compatibility-ldbl-alt128.o .libs/compatibility-ldbl-alt128-cxx11.o 
-Wl,--whole-archive ../libsupc++/.libs/libsupc++convenience.a
../src/c++98/.libs/libc++98convenience.a
../src/c++11/.libs/libc++11convenience.a
../src/c++17/.libs/libc++17convenience.a
../src/c++20/.libs/libc++20convenience.a ... -Wl,-soname -Wl,libstdc++.so.6 -o
.libs/libstdc++.so.6.0.29

Only the 'compatibility' objects joined the link, and they're built using
`-mabi=ibmlongdouble`, not IEEE. Manually adding `c++11/wlocale-inst.o`
produces error complaining about multiple definition.


While libstdc++.a contains all of these definitions, actually seven
(compatibility-ldbl.o compatibility-ldbl-alt128.o
compatibility-ldbl-alt128-cxx11.o cxx11-locale-inst.o cxx11-wlocale-inst.o
locale-inst.o wlocale-inst.o
), so ld can find the correct one properly. (although I'm still not clear how
ld does it)

If I understood correctly, the reason why result is incorrect is that the
`libstdc++.so` only contains symbols built for compatibility. Maybe something
went wrong in the build scripts?

[Bug tree-optimization/102648] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0) since r12-2381-g704e8a825c78b9a8

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
Summary|[12 Regression] Dead Code   |[12 Regression] Dead Code
   |Elimination Regression at   |Elimination Regression at
   |-O3 (trunk vs 11.2.0)   |-O3 (trunk vs 11.2.0) since
   ||r12-2381-g704e8a825c78b9a8
 Ever confirmed|0   |1
   Last reconfirmed||2021-10-11

--- Comment #1 from Martin Liška  ---
Started with r12-2381-g704e8a825c78b9a8.

[Bug c++/102642] [12 Regression] ICE in get, at cgraph.h:2776 since r12-4032-g701075864ac4d1c6

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
   Keywords||error-recovery

[Bug c++/102642] [11/12 Regression] ICE in get, at cgraph.h:2776 since r12-4032-g701075864ac4d1c6

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|12.0|11.3
Summary|[12 Regression] ICE in get, |[11/12 Regression] ICE in
   |at cgraph.h:2776 since  |get, at cgraph.h:2776 since
   |r12-4032-g701075864ac4d1c6  |r12-4032-g701075864ac4d1c6

--- Comment #2 from Jakub Jelinek  ---
Note, the patch has been backported to 11.3 too.

[Bug target/102682] New: [12 Regression] ICE in simplify_gen_subreg_concatn, at lower-subreg.c:717

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 102682
   Summary: [12 Regression] ICE in simplify_gen_subreg_concatn, at
lower-subreg.c:717
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-pc-linux-gnu

Created attachment 51583
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51583&action=edit
Testcase

g++-12.0.0-alpha20211003 snapshot (g:d91056851c5c60f226e3192fb955d018b53eb66f)
ICEs when compiling the attached testcase, partially reduced from
test/std/experimental/simd/simd.mem/store.pass.cpp from the libcxx 12.0.0 test
suite, w/ -mavx2 -O1 -fno-tree-sra --param
sccvn-max-alias-queries-per-access=1:

% x86_64-pc-linux-gnu-g++-12.0.0 -mavx2 -O1 -fno-tree-sra --param
sccvn-max-alias-queries-per-access=1 -c iwely7yr.cpp
during RTL pass: subreg1
iwely7yr.cpp: In function 'void test_converting_store()':
iwely7yr.cpp:99:1: internal compiler error: in simplify_gen_subreg_concatn, at
lower-subreg.c:717
   99 | }
  | ^
0x8ff0de simplify_gen_subreg_concatn
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211003/work/gcc-12-20211003/gcc/lower-subreg.c:717
0x1e92481 resolve_simple_move
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211003/work/gcc-12-20211003/gcc/lower-subreg.c:1091
0x1e93531 decompose_multiword_subregs
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211003/work/gcc-12-20211003/gcc/lower-subreg.c:1657
0x1e93eca execute
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211003/work/gcc-12-20211003/gcc/lower-subreg.c:1773

[Bug tree-optimization/102659] -O2 vectorization if-conversion produces wrong code for gcc.dg/torture/pr69760.c

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

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

--- Comment #4 from Richard Biener  ---
Created attachment 51584
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51584&action=edit
patch I am testing

I'm testing this patch, hopefully without bad side-effects on SCEV/data-ref
analysis ... (but I fear not...)

[Bug target/102682] [12 Regression] ICE in simplify_gen_subreg_concatn, at lower-subreg.c:717

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug c++/102656] [11/12 Regression] ICE on coroutines on -fsanitize=address -O1 since r11-1613-g788b962aa00959e8

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||iains at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-10-11
Summary|ICE on coroutines on|[11/12 Regression] ICE on
   |-fsanitize=address -O1  |coroutines on
   ||-fsanitize=address -O1
   ||since
   ||r11-1613-g788b962aa00959e8

--- Comment #2 from Martin Liška  ---
Confirmed, started with r11-1613-g788b962aa00959e8.

[Bug other/102657] libcody makefile is missing a mostlyclean target

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-10-11

--- Comment #2 from Martin Liška  ---
I can take a look.

[Bug analyzer/102662] [12 Regression] ICE in validate, at analyzer/constraint-manager.cc:581 since r12-3101-g8ca7fa84a3af355c

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org
Summary|[12 Regression] ICE in  |[12 Regression] ICE in
   |validate, at|validate, at
   |analyzer/constraint-manager |analyzer/constraint-manager
   |.cc:581 |.cc:581 since
   ||r12-3101-g8ca7fa84a3af355c
   Last reconfirmed||2021-10-11

--- Comment #1 from Martin Liška  ---
Started with r12-3101-g8ca7fa84a3af355c.

[Bug other/102663] add an install-dvi Makefile target to the toplevel Makefile and all subdirectories

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 CC||marxin at gcc dot gnu.org
   Last reconfirmed||2021-10-11
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
I can theoretically remove all these once we'll start using Sphinx.

[Bug testsuite/102677] Extra testsuite failures with glibc 2.34

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2021-10-11
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Liška  ---
I can confirm that.

[Bug target/102682] [12 Regression] ICE in simplify_gen_subreg_concatn, at lower-subreg.c:717 since r12-3899-gd06dc8a2c73735e9

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|[12 Regression] ICE in  |[12 Regression] ICE in
   |simplify_gen_subreg_concatn |simplify_gen_subreg_concatn
   |, at lower-subreg.c:717 |, at lower-subreg.c:717
   ||since
   ||r12-3899-gd06dc8a2c73735e9
 Status|UNCONFIRMED |NEW
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2021-10-11

--- Comment #1 from Martin Liška  ---
Started with r12-3899-gd06dc8a2c73735e9.

[Bug target/102683] New: [12 Regression] ICE in set_min_and_max_values_for_integral_type, at stor-layout.c:2851

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

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

Bug ID: 102683
   Summary: [12 Regression] ICE in
set_min_and_max_values_for_integral_type, at
stor-layout.c:2851
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: qing.zhao at oracle dot com
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: riscv64-unknown-linux-gnu

The following fails:

$ riscv64-linux-gnu-gcc
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/other/complex1.C -Og
-ftrivial-auto-var-init=pattern
during RTL pass: expand
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/other/complex1.C: In function
‘void foo()’:
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/other/complex1.C:19:5:
internal compiler error: in set_min_and_max_values_for_integral_type, at
stor-layout.c:2851
   19 |   C y = (n==1) ? x : (C){3+3i};
  | ^
0x6185b6 set_min_and_max_values_for_integral_type(tree_node*, int, signop)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/stor-layout.c:2851
0xcb2e2b fixup_unsigned_type(tree_node*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/stor-layout.c:2885
0xf32cd8 build_nonstandard_integer_type(unsigned long, int)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/tree.c:6976
0xa822c9 expand_DEFERRED_INIT
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/internal-fn.c:3058
0x8b6bc7 expand_call_stmt
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/cfgexpand.c:2749
0x8b6bc7 expand_gimple_stmt_1
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/cfgexpand.c:3876
0x8b6bc7 expand_gimple_stmt
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/cfgexpand.c:4040
0x8bb3d2 expand_gimple_basic_block
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/cfgexpand.c:6082
0x8bd216 execute
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/cfgexpand.c:6808
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/102683] [12 Regression] ICE in set_min_and_max_values_for_integral_type, at stor-layout.c:2851

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||rguenth at gcc dot gnu.org
   Target Milestone|--- |12.0
   Last reconfirmed||2021-10-11

[Bug target/102683] [12 Regression] ICE in set_min_and_max_values_for_integral_type, at stor-layout.c:2851

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

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

--- Comment #1 from Richard Biener  ---
That likely means the target lacks an integer mode covering the mode of the
type to be initialized ... :/  I see the target only defines TFmode so
eventually
it has CTFmode but not OImode.  We have

struct C {
  __complex__ long double c;
};

void foo()
{
  C x = {2+2i};

  int n = 1;
  C y = (n==1) ? x : (C){3+3i};
  if (__imag__ y.c != 2)
abort ();
}

(not sure why we get .DEFERRED_INIT here)

[Bug libstdc++/47320] FAIL: 18_support/numeric_limits/lowest.cc execution test

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

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

--- Comment #3 from Jonathan Wakely  ---
N.B. I've just reverted this fix as part of
r12-4268-gfec283b63d7f24f4c37792dd07ab1055186ba88f

The numeric limits specialization is defined unconditionally, so is correct
whether or not _GLIBCXX_USE_WCHAR_T is defined, and so this test should always
pass.

The problem here was that is_integral::value was false, so it used the
do_test(false_type) overload which is intended for floating-point types.

r11-4590-g29e418485848c4a6943d8561cd8fb0b1abf14015 changed that, so that
is_integral is always true (as required by the C++ standard) even if
wchar_t support is not present in libc. Since that change, this test should
always pass for wchar_t.

I'm changing the test to use numeric_limits::is_integer instead of
is_integral anyway, because is_integer<__int128> depends on __STRICT_ANSI__
and so the test fails in a similar way for __int128 as it did for wchar_t.

[Bug c++/102642] [11/12 Regression] ICE in get, at cgraph.h:2776 since r12-4032-g701075864ac4d1c6

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 51585
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51585&action=edit
gcc12-pr102642.patch

Untested fix.

[Bug target/102682] [12 Regression] ICE in simplify_gen_subreg_concatn, at lower-subreg.c:717 since r12-3899-gd06dc8a2c73735e9

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
Breakpoint 1, fancy_abort (
file=0x3973340 "/home/rguenther/src/gcc3/gcc/lower-subreg.c", line=717, 
function=0x39737d0  "simplify_gen_subreg_concatn")
at /home/rguenther/src/gcc3/gcc/diagnostic.c:1982
1982  if (global_dc->printer == NULL)
Missing separate debuginfos, use: zypper install
libgmp10-debuginfo-6.1.2-4.6.1.x86_64 libisl15-debuginfo-0.18-1.443.x86_64
libmpc3-debuginfo-1.1.0-1.47.x86_64 libmpfr6-debuginfo-4.0.2-3.3.1.x86_64
libzstd1-debuginfo-1.4.4-1.6.1.x86_64
(gdb) up
#1  0x02c1c638 in simplify_gen_subreg_concatn (outermode=E_DImode, 
op=0x763490c0, innermode=E_OImode, byte=0)
at /home/rguenther/src/gcc3/gcc/lower-subreg.c:717
717   gcc_assert (!paradoxical_subreg_p (op));
(gdb) p debug_rtx (op)
(subreg:OI (concatn/v:TI [
(reg:DI 92 [ buffer ])
(reg:DI 93 [ buffer+8 ])
]) 0)

and the insn

(insn 6 5 7 2 (set (subreg:OI (concatn/v:TI [
(reg:DI 92 [ buffer ])
(reg:DI 93 [ buffer+8 ])
]) 0)
(subreg:OI (reg/v:V8SI 85 [ __x ]) 0)) "t.ii":76:21 74
{*movoi_internal_avx}
 (nil))

looks more like a latent issue in the subreg lowering pass?  But then the
insn looks dubious in the first place...  it originally is:

;; MEM  [(char * {ref-all})&buffer] = _5;

(insn 6 5 0 (set (subreg:OI (reg/v:TI 84 [ buffer ]) 0)
(subreg:OI (reg/v:V8SI 85 [ __x ]) 0)) "t.ii":76:21 -1
 (nil))

where buffer is too small:

  float buffer[4];

one thing we could do is somehow "fail" when we end up generating the
LHS subreg.  Alternatively see to this situation when expanding the
GIMPLE and mark 'buffer' as not to be expanded to a register via
forced_stack_vars because we have an access that's too big.

[Bug target/102682] [12 Regression] ICE in simplify_gen_subreg_concatn, at lower-subreg.c:717 since r12-3899-gd06dc8a2c73735e9

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
The subreg is generated from store_bit_field_1:

#10 0x01224f12 in store_bit_field (str_rtx=0x76720fc0, 
bitsize=..., bitnum=..., bitregion_start=..., bitregion_end=..., 
fieldmode=E_OImode, value=0x763490a8, reverse=false)
at /home/rguenther/src/gcc3/gcc/expmed.c:1186
...
  /* If the target is a register, overwriting the entire object, or storing
 a full-word or multi-word field can be done with just a SUBREG.  */
  if (!MEM_P (op0)
  && known_eq (bitsize, GET_MODE_BITSIZE (fieldmode)))
{

but note how fieldmode is OImode while op0 is (reg:TI 84 [ buffer ]).

it goes on

  /* Use the subreg machinery either to narrow OP0 to the required
 words or to cope with mode punning between equal-sized modes.
 In the latter case, use subreg on the rhs side, not lhs.  */
  rtx sub;
  HOST_WIDE_INT regnum;
  poly_uint64 regsize = REGMODE_NATURAL_SIZE (GET_MODE (op0));
  if (known_eq (bitnum, 0U)
  && known_eq (bitsize, GET_MODE_BITSIZE (GET_MODE (op0
{
  sub = simplify_gen_subreg (GET_MODE (op0), value, fieldmode, 0);
  if (sub)
{
  if (reverse)
sub = flip_storage_order (GET_MODE (op0), sub);
  emit_move_insn (op0, sub);
  return true;
}
}

it doesn't mention the widening of the LHS, but

  else if (constant_multiple_p (bitnum, regsize * BITS_PER_UNIT, ®num)
   && multiple_p (bitsize, regsize * BITS_PER_UNIT))
{
  sub = simplify_gen_subreg (fieldmode, op0, GET_MODE (op0),
 regnum * regsize);
  if (sub)
{
  if (reverse)
value = flip_storage_order (fieldmode, value);
  emit_move_insn (sub, value);
  return true;
}
}

this does just this.  So eventually the known_eq in the first case can
be changed to known_ge in which case we no longer ICE but prune the RHS.

diff --git a/gcc/expmed.c b/gcc/expmed.c
index 59734d4841c..0e8a60245aa 100644
--- a/gcc/expmed.c
+++ b/gcc/expmed.c
@@ -788,13 +788,14 @@ store_bit_field_1 (rtx str_rtx, poly_uint64 bitsize,
poly_uint64 bitnum,
   && known_eq (bitsize, GET_MODE_BITSIZE (fieldmode)))
 {
   /* Use the subreg machinery either to narrow OP0 to the required
-words or to cope with mode punning between equal-sized modes.
-In the latter case, use subreg on the rhs side, not lhs.  */
+words or to cope with mode punning between equal-sized modes
+or storage of excess bytes.  In the latter case, use subreg on
+the rhs side, not lhs.  */
   rtx sub;
   HOST_WIDE_INT regnum;
   poly_uint64 regsize = REGMODE_NATURAL_SIZE (GET_MODE (op0));
   if (known_eq (bitnum, 0U)
- && known_eq (bitsize, GET_MODE_BITSIZE (GET_MODE (op0
+ && known_ge (bitsize, GET_MODE_BITSIZE (GET_MODE (op0
{
  sub = simplify_gen_subreg (GET_MODE (op0), value, fieldmode, 0);
  if (sub)


another possibility is to fix the condition on the case we run into:

@@ -806,7 +807,7 @@ store_bit_field_1 (rtx str_rtx, poly_uint64 bitsize,
poly_uint64 bitnum,
}
}
   else if (constant_multiple_p (bitnum, regsize * BITS_PER_UNIT, ®num)
-  && multiple_p (bitsize, regsize * BITS_PER_UNIT))
+  && multiple_p (regsize * BITS_PER_UNIT, bitsize))
{
  sub = simplify_gen_subreg (fieldmode, op0, GET_MODE (op0),
 regnum * regsize);

[Bug target/102683] [12 Regression] ICE in set_min_and_max_values_for_integral_type, at stor-layout.c:2851

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

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

--- Comment #2 from Richard Biener  ---
Hmm, a riscv-linux cc1 ICEs with

> ./cc1 -quiet t.i -I include -O
: internal compiler error: Segmentation fault
0x132b5fa crash_signal
/home/rguenther/src/trunk/gcc/toplev.c:326
0x18e4864 riscv_subset_list::begin() const
/home/rguenther/src/trunk/gcc/config/riscv/riscv-subset.h:89
0x18e46e1 riscv_cpu_cpp_builtins(cpp_reader*)
/home/rguenther/src/trunk/gcc/config/riscv/riscv-c.c:114
0xb694bc c_cpp_builtins(cpp_reader*)
/home/rguenther/src/trunk/gcc/c-family/c-cppbuiltin.c:1578
0xb9634d c_finish_options
/home/rguenther/src/trunk/gcc/c-family/c-opts.c:1486
0xb95b7c c_common_parse_file()
/home/rguenther/src/trunk/gcc/c-family/c-opts.c:1231
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Program received signal SIGSEGV, Segmentation fault.
0x018e4864 in riscv_subset_list::begin (this=0x0)
at /home/rguenther/src/trunk/gcc/config/riscv/riscv-subset.h:89
89const riscv_subset_t *begin () const {return m_head;};

[Bug target/102683] [12 Regression] ICE in set_min_and_max_values_for_integral_type, at stor-layout.c:2851

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Otherwise the following would likely fix it:

diff --git a/gcc/internal-fn.c b/gcc/internal-fn.c
index 6bc256832f7..b3638192fb9 100644
--- a/gcc/internal-fn.c
+++ b/gcc/internal-fn.c
@@ -3074,7 +3074,9 @@ expand_DEFERRED_INIT (internal_fn, gcall *stmt)
   tree init;
   if (tree_fits_uhwi_p (var_size)
  && (init_type == AUTO_INIT_PATTERN
- || !is_gimple_reg_type (var_type)))
+ || !is_gimple_reg_type (var_type))
+ && int_mode_for_size (tree_to_uhwi (var_size) * BITS_PER_UNIT,
+   0).exists ())
{
  unsigned HOST_WIDE_INT total_bytes = tree_to_uhwi (var_size);
  unsigned char *buf = (unsigned char *) xmalloc (total_bytes);

[Bug target/102683] [12 Regression] ICE in set_min_and_max_values_for_integral_type, at stor-layout.c:2851

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
Now, for some reason we initialize 'y' which is clearly not necessary:

  y = .DEFERRED_INIT (32, 2, 0);
  if (n == 1) goto ; else goto ;
  :
  y = x;
  goto ;
  :
  y = *.LC1;
  :

and the suggested patch fixes the ICE during expansion.  But we should avoid
the .DEFERRED_INIT here.  The GENERIC is

struct C y;
  < : TARGET_EXPR ) >;

so we have first

stmt 
side-effects arg:0 
t.i:10:5 start: t.i:10:5 finish: t.i:10:5>

and then

stmt 
side-effects
arg:0 
side-effects
arg:0 
side-effects
arg:0 
side-effects arg:0 
arg:1 
...

so this is an INIT_EXPR which never(?) requires .DEFERRED_INIT?  Of course
we're instrumenting the DECL_EXPR, not the INIT_EXPR and at that point
we didn't see the INIT_EXPR.

I wonder if we want a bit on DECL_EXPR denoting whether the decl is
fully initialized?

[Bug ada/100486] Ada build fails for 32bit Windows

[gcc_bugzilla at axeitado dot com via Gcc-bugs]

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

--- Comment #21 from Óscar Fuentes  ---
(In reply to Eric Botcazou from comment #20)
> Weird, I don't have any dependency on the DLL for it:
> 
> $ ldd t.exe
> ntdll.dll => /Windows/SYSTEM32/ntdll.dll (0x7ffc6556)
> ntdll.dll => /Windows/SysWOW64/ntdll.dll (0x770b)
> wow64.dll => /Windows/System32/wow64.dll (0x5d1b)
> wow64win.dll => /Windows/System32/wow64win.dll (0x5d21)
> 
> Can you post the output of 'g++ foo.cpp -v' for your C++ testcase?  Can you
> find out what symbol(s) of libstdc++.dll are referenced by your executable?

ldd does not list libstdc++.dll, but `Dependency Walker` lists both
libstdc++.dll and libgcc_s_dw2-1.dll.

Imports from libstdc++.dll:

_ZTIi
__cxa_allocate_exception
__cxa_begin_catch
__cxa_end_catch
__cxa_throw
__gxx_personality_v0


Imports from libgcc_s_dw2-1.dll:

__deregister_frame_info
__register_frame_info


$ g++ -v excep.cpp
Using built-in specs.
COLLECT_GCC=D:\dev\other\MINGW-packages\mingw-w64-gcc\pkg\mingw-w64-i686-gcc\mingw32\bin\g++.exe
COLLECT_LTO_WRAPPER=D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: ../gcc-11.2.0/configure --prefix=/mingw32
--with-local-prefix=/mingw32/local --build=i686-w64-mingw32
--host=i686-w64-mingw32 --target=i686-w64-mingw32
--with-native-system-header-dir=/mingw32/i686-w64-mingw32/include
--libexecdir=/mingw32/lib --enable-bootstrap --enable-checking=release
--with-arch=i686 --with-tune=generic
--enable-languages=c,lto,c++,fortran,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-libstdcxx-debug
--enable-lto --enable-libgomp --disable-multilib --disable-rpath
--disable-win32-registry --disable-nls --disable-werror --disable-symvers
--with-libiconv --with-system-zlib --with-gmp=/mingw32 --with-mpfr=/mingw32
--with-mpc=/mingw32 --with-isl=/mingw32 --with-pkgversion='Rev1, Built by MSYS2
project' --with-bugurl=https://github.com/msys2/MINGW-packages/issues
--with-gnu-as --with-gnu-ld --with-boot-ldflags='-pipe
-Wl,--dynamicbase,--nxcompat,--no-seh -Wl,--large-address-aware
-Wl,--disable-dynamicbase -static-libstdc++ -static-libgcc'
'LDFLAGS_FOR_TARGET=-pipe -Wl,--dynamicbase,--nxcompat,--no-seh
-Wl,--large-address-aware'
--enable-linker-plugin-flags='LDFLAGS=-static-libstdc++\ -static-libgcc\ -pipe\
-Wl,--dynamicbase,--nxcompat,--no-seh\ -Wl,--large-address-aware\
-Wl,--stack,12582912' --disable-sjlj-exceptions --with-dwarf2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (Rev1, Built by MSYS2 project)
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=i686'
'-dumpdir' 'a-'

D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/cc1plus.exe
-quiet -v -iprefix
D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/
-D_REENTRANT excep.cpp -quiet -dumpdir a- -dumpbase excep.cpp -dumpbase-ext
.cpp -mtune=generic -march=i686 -version -o C:\apps\msys64\tmp\ccit4tWf.s
GNU C++17 (Rev1, Built by MSYS2 project) version 11.2.0 (i686-w64-mingw32)
compiled by GNU C version 11.2.0, GMP version 6.2.1, MPFR version
4.1.0-p13, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/../../../../i686-w64-mingw32/include"
ignoring duplicate directory
"D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/11.2.0/../../../../include/c++/11.2.0"
ignoring duplicate directory
"D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/11.2.0/../../../../include/c++/11.2.0/i686-w64-mingw32"
ignoring duplicate directory
"D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/11.2.0/../../../../include/c++/11.2.0/backward"
ignoring duplicate directory
"D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/11.2.0/include"
ignoring duplicate directory
"D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/11.2.0/include-fixed"
ignoring nonexistent directory
"D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/11.2.0/../../../../i686-w64-mingw32/include"
#include "..." search starts here:
#include <...> search starts here:

D:/dev/other/MINGW-packages/mingw-w64-

[Bug target/62011] False Data Dependency in popcnt instruction

[malincns at 163 dot com via Gcc-bugs]

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

Ma Lin  changed:

   What|Removed |Added

 CC||malincns at 163 dot com

--- Comment #18 from Ma Lin  ---
FYI, in Intel 10th/11th Generation Processor Errata Table, there is no popcnt
problem.

In 9th Generation Errata Table, this problem exists.

[Bug c++/101480] [11/12 Regression] Miscompiled code involving operator new

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com

--- Comment #18 from Richard Biener  ---
(In reply to Martin Sebor from comment #16)
> (In reply to Richard Biener from comment #14)
> ...
> > the testcase does
> > 
> > m = i;
> > p = (int*) new unsigned char [sizeof (int) * m];
> > 
> > for (int i = 0; i < m; i++)
> >   new (p + i) int ();
> > 
> > and we likely have to assume that 'new' changes 'm'.
> 
> Why?  Because of the flow-insensitivity of the alias analysis?
> 
> m is a member of the class whose ctor has the loop above.  Neither the
> enclosing object nor the member actually escapes (the operator new to which
> p is passed in the loop is the nonreplaceable placement new), so there is no
> way it can be changed.

What we see is the global variable construction function which accesses
just 'a', and yes, the call to 'new' is considered clobbering global
variables (including 'a'):

   [local count: 1073741824]:
  MEM[(struct __as_base  &)&a] ={v} {CLOBBER};
  a.m = 0;
  _5 = operator new [] (0);
  a.p = _5;
  goto ; [100.00%]

   [local count: 8687547547]:
  _7 = (long unsigned int) i_6;
  _8 = _7 * 4;
  _9 = _5 + _8;
  MEM[(int *)_9] = 0;
  i_10 = i_6 + 1;

   [local count: 9761289362]:
  # i_6 = PHI <0(2), i_10(3)>
  _11 = a.m;
  if (i_6 < _11)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 1073741824]:
  return;

I suppose implementing the global operator new as accessing a.m would
be valid as IIRC lifetime of a starts when the CTOR is invoked, not
when it finished (otherwise the CTOR could not access the variable itself).

We somehow conclude that

_9: void * [1B, +INF]  EQUIVALENCES: { } (0 elements)

possibly because it cannot be NULL (?):

extract_range_from_stmt visiting:
_5 = operator new [] (0);
Found new range for _5: void * [1B, +INF]
marking stmt to be not simulated again

(huh?)

and then the -Warray-bounds warning concludes the access is always outside
of the allocated area.

I suspect when we'd arrive at VARYING we'd not issue the warning even
when the access would always extend beyond a zero-sized allocation.

I'm going to ignore this diagnostic issue, it concerns the 'offrange'
code I'm not familiar with at all (and maybe the value-range code for
which I now have to say sth similar).

[Bug ada/100486] Ada build fails for 32bit Windows

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

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

--- Comment #22 from Eric Botcazou  ---
> ldd does not list libstdc++.dll, but `Dependency Walker` lists both
> libstdc++.dll and libgcc_s_dw2-1.dll.
> 
> Imports from libstdc++.dll:
> 
> _ZTIi
> __cxa_allocate_exception
> __cxa_begin_catch
> __cxa_end_catch
> __cxa_throw
> __gxx_personality_v0
> 
> 
> Imports from libgcc_s_dw2-1.dll:
> 
> __deregister_frame_info
> __register_frame_info

Yes, I figured out that ldd was not reliable in the meantime.  How nice...

So it looks like exception propagation is broken in your setup and it's hard to
guess why without investigating a little.  Of course it's a bit tricky to do,
especially on Windows.

Can you upload somewhere a package containing the executable,
libgcc_s_dw2-1.dll and libstdc++.dll from GCC 11, as well as libstdc++.dll from
GCC 10 and post the URL here?

[Bug c++/101480] [11/12 Regression] Miscompiled code involving operator new

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

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

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

https://gcc.gnu.org/g:09a0affdb0598a54835ac4bb0dd6b54122c12916

commit r12-4319-g09a0affdb0598a54835ac4bb0dd6b54122c12916
Author: Richard Biener 
Date:   Mon Oct 11 16:06:03 2021 +0200

middle-end/101480 - overloaded global new/delete

The following fixes the issue of ignoring side-effects on memory
from overloaded global new/delete operators by not marking them
as effectively 'const' apart from other explicitely specified
side-effects.

This will cause

FAIL: g++.dg/warn/Warray-bounds-16.C  -std=gnu++1? (test for excess errors)

because we now no longer statically see the initialization loop
never executes because the call to operator new can now clobber 'a.m'.
This seems to be an issue with the warning code and/or ranger so
I'm leaving this FAIL to be addressed as followup.

2021-10-11  Richard Biener  

PR middle-end/101480
* gimple.c (gimple_call_fnspec): Do not mark operator new/delete
as const.

* g++.dg/torture/pr10148.C: New testcase.

[Bug c++/101480] [11 Regression] Miscompiled code involving operator new

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail|12.0|11.2.0
  Known to work||12.0
Summary|[11/12 Regression]  |[11 Regression] Miscompiled
   |Miscompiled code involving  |code involving operator new
   |operator new|

--- Comment #20 from Richard Biener  ---
Fixed on trunk sofar.

[Bug c++/102684] New: [missed optimization] std::min_element / ranges::min_element does not get optimized away with std::gcd

[xkeviota at gmail dot com via Gcc-bugs]

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

Bug ID: 102684
   Summary: [missed optimization] std::min_element /
ranges::min_element does not get optimized away with
std::gcd
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xkeviota at gmail dot com
  Target Milestone: ---

This code which calculates the gcd of the minimum and maximum element of a
range of elements gets optimized away entirely with clang to just a `return`
statement with `-O3` while gcc (trunk) produces up to 232 lines of assembly
depending on the optimization level
(https://compiler-explorer.com/z/TYrx5exP3).

#include 
#include 
#include 
#include 

namespace r = std::ranges;

template 
constexpr auto find_gcd(std::span container) {
return std::gcd(*r::min_element(container),
*r::max_element(container));
}

int main() {
std::vector ints = {2, 4, 6, 10};
return find_gcd(ints);
}

The same happens when `std::min_element` is used for example. I found one other
post regarding `std::min_element` from 2018 about custom predicates but I
wasn't sure if it might have the same underlying problem.

[Bug target/102683] [12 Regression] ICE in set_min_and_max_values_for_integral_type, at stor-layout.c:2851

[qing.zhao at oracle dot com via Gcc-bugs]

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

--- Comment #5 from Qing Zhao  ---
> --- Comment #4 from Richard Biener  ---
> But we should avoid
> the .DEFERRED_INIT here.  The GENERIC is
> 
>struct C y;
>  <  (void) (y = n == 1 ? TARGET_EXPR  : TARGET_EXPR  {.c=__complex__ (3.0e+0, 3.0e+0)}>) >;
> 
> so we have first
> 
>stmt 
>side-effects arg:0 
>t.i:10:5 start: t.i:10:5 finish: t.i:10:5>
> 
> and then
> 
>stmt  void>
>side-effects
>arg:0  void>
>side-effects
>arg:0  0x76558f18 void>
>side-effects
>arg:0  0x76663d20 C>
>side-effects arg:0 
>arg:1  0x76663d20 C>
> ...
> 
> so this is an INIT_EXPR which never(?) requires .DEFERRED_INIT?  Of course
> we're instrumenting the DECL_EXPR, not the INIT_EXPR and at that point
> we didn't see the INIT_EXPR.

Currently, in simplification phase, for each DECL_EXPR, we check:

  if (VAR_P (decl) && !DECL_EXTERNAL (decl))
{
  tree init = DECL_INITIAL (decl);

  If (!init. && is_var_need_auto_init (decl))
gimple_add_init_for_auto_var (decl…)


We assume that FE will put the explicit initializer of a DECL to its
DECL_INITIAL. 
Clearly for this testing case, this is not the case.

I am wondering why FE does not put the initializer of this DECL to its
DECL_INITIAL for this case?

> 
> I wonder if we want a bit on DECL_EXPR denoting whether the decl is
> fully initialized?

Yes, if FE can mark this bit, it will be easier and simpler for the
implementation.

[Bug target/102683] [12 Regression] ICE in set_min_and_max_values_for_integral_type, at stor-layout.c:2851

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

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

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

https://gcc.gnu.org/g:338725652f84793805c55f08a7607c2f45d5512b

commit r12-4320-g338725652f84793805c55f08a7607c2f45d5512b
Author: Richard Biener 
Date:   Mon Oct 11 14:31:59 2021 +0200

middle-end/102683 - fix .DEFERRED_INIT expansion

This avoids using an integer type for which we don't have an
approprate mode when expanding .DEFERRED_INIT to a non-memory
entity.

2021-10-11  Richard Biener  

PR middle-end/102683
* internal-fn.c (expand_DEFERRED_INIT): Check for mode
availability before building an integer type for storage
purposes.

[Bug target/102683] [12 Regression] ICE in set_min_and_max_values_for_integral_type, at stor-layout.c:2851

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Biener  ---
The ICE should be fixed (the unnnecessary .DEFERRED_INIT is not, but that
should eventually get a different bug).

[Bug ada/100486] Ada build fails for 32bit Windows

[gcc_bugzilla at axeitado dot com via Gcc-bugs]

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

--- Comment #23 from Óscar Fuentes  ---
See http://88.17.68.234/clientes/gcc

It contains the gcc binary packages with debug info, plus packages for
dependencies (mpc/gmp/etc.)

It also contains the libstdc++ dll from 10.3 (the "working" one).

The gcc packages are built with the MSYS2 local patches included in the tarfile
patches.tgz.

Note that a build without local patches was already tried with the same failure
while building Ada.

If the local patches are a problem for you, I'll make a build from stock gcc,
but it will take time.

Please let me know if you need something else. Thanks.

[Bug testsuite/102658] [12 regression] Many test case failures after r12-4240

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

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #5 from Martin Sebor  ---
Please don't add xfails for regressions without referencing the bug that tracks
the underlying root cause.

Also, the target-specific conditionals in the xfails are going to be difficult
to maintain.  We need a better solution than that.  That said, it would seem
prudent to discuss such a large number of regressions with the author of the
affected features/warnings (yours truly in this case).

[Bug tree-optimization/102646] large performance changes between 1932e1169a236849f5e7f1cd386da100d9af470f and 9cfb95f9b92326e86e99b50350ebf04fa9cd2477 (probably jump threading)

[hubicka at kam dot mff.cuni.cz via Gcc-bugs]

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

--- Comment #2 from hubicka at kam dot mff.cuni.cz ---
> I think most of the regressions are fixed, we get even better numbers now.
Because we enabled vectorization. I would say they should still
reproduce with -fno-tree-vectorize, right?

Honza

[Bug c++/101480] [11 Regression] Miscompiled code involving operator new

[hubicka at kam dot mff.cuni.cz via Gcc-bugs]

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

--- Comment #21 from hubicka at kam dot mff.cuni.cz ---
Hi,
note that also tree-ssa-structalias has:
/* If the call is to a replaceable operator delete and results
   from a delete expression as opposed to a direct call to
   such operator, then the effects for PTA (in particular 
   the escaping of the pointer) can be ignored.  */   
else if (fndecl   
 && DECL_IS_OPERATOR_DELETE_P (fndecl)
 && gimple_call_from_new_or_delete (t))   
  ;   
I wonder if this is safe...

Honza

[Bug ada/100486] Ada build fails for 32bit Windows

[gcc_bugzilla at axeitado dot com via Gcc-bugs]

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

--- Comment #24 from Óscar Fuentes  ---
Sorry, I misread your message and now realized that you just wanted the
executable and its dependencies. They are now on the same URL. The 11.2
libstdc++ and libgcc dlls are built with debug info.

[Bug tree-optimization/102646] large performance changes between 1932e1169a236849f5e7f1cd386da100d9af470f and 9cfb95f9b92326e86e99b50350ebf04fa9cd2477 (probably jump threading)

[aldyh at redhat dot com via Gcc-bugs]

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

--- Comment #3 from Aldy Hernandez  ---
Most if not all the performance changes I've seen so far have been,
not due to the jump threader changes, but to the restrictions we've
put into place for jump threadable paths.  Before, we used to thread
paths that destroyed loop form.  We are much more cautious now.  In
theory, the vectorizer should be able to do an even better job with
loops preserved longer.

That being said, this has been a bit of a moving target, with the
thread validity model changing a few times in the past month.

A good exercise would be to compare the old and new threaders, with
the vectorizer kept constant (whether -fno-tree-vectorize or
-ftree-vectorize), but without the loop threading restrictions.  That
is, with something like this patch:

diff --git a/gcc/tree-ssa-threadupdate.c b/gcc/tree-ssa-threadupdate.c
index 32ce1e3af40..1a49cb61ca3 100644
--- a/gcc/tree-ssa-threadupdate.c
+++ b/gcc/tree-ssa-threadupdate.c
@@ -2853,9 +2853,6 @@ jt_path_registry::register_jump_thread
(vec *path)
   return false;
 }

-  if (cancel_invalid_paths (*path))
-return false;
-
   if (dump_file && (dump_flags & TDF_DETAILS))
 dump_jump_thread_path (dump_file, *path, true);

On Mon, Oct 11, 2021 at 4:59 PM hubicka at kam dot mff.cuni.cz
 wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102646
>
> --- Comment #2 from hubicka at kam dot mff.cuni.cz ---
> > I think most of the regressions are fixed, we get even better numbers now.
> Because we enabled vectorization. I would say they should still
> reproduce with -fno-tree-vectorize, right?
>
> Honza
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>

[Bug c++/101853] [12 Regression] g++.dg/modules/xtreme-header-5_b.C ICE

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

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

--- Comment #5 from seurer at gcc dot gnu.org ---
I am still seeing these today with g:a40970cf043553f0ca09a3b7be1c5a949623d915,
r12-4318

FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++17 (internal compiler error)
FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++17 (internal compiler error)
FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++2a (internal compiler error)
FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++2a (internal compiler error)
FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++2b (internal compiler error)
FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++2b (internal compiler error)
FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-3_a.H module-cmi 
(gcm.cache/$srcdir/g++.dg/modules/xtreme-header-3_a.H.gcm)
FAIL: g++.dg/modules/xtreme-header-3_a.H module-cmi 
(gcm.cache/$srcdir/g++.dg/modules/xtreme-header-3_a.H.gcm)
FAIL: g++.dg/modules/xtreme-header-3_a.H module-cmi 
(gcm.cache/$srcdir/g++.dg/modules/xtreme-header-3_a.H.gcm)
FAIL: g++.dg/modules/xtreme-header-3_a.H module-cmi 
(gcm.cache/$srcdir/g++.dg/modules/xtreme-header-3_a.H.gcm)
FAIL: g++.dg/modules/xtreme-header-3_a.H module-cmi 
(gcm.cache/$srcdir/g++.dg/modules/xtreme-header-3_a.H.gcm)
FAIL: g++.dg/modules/xtreme-header-3_a.H module-cmi 
(gcm.cache/$srcdir/g++.dg/modules/xtreme-header-3_a.H.gcm)
FAIL: g++.dg/modules/xtreme-header-3_b.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-3_b.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-3_b.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-3_b.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-3_b.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-3_b.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-3_c.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-3_c.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-3_c.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-3_c.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-3_c.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-3_c.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-4_b.C -std=c++2a (internal compiler error)
FAIL: g++.dg/modules/xtreme-header-4_b.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-5_a.H -std=c++2a (internal compiler error)
FAIL: g++.dg/modules/xtreme-header-5_a.H -std=c++2a (internal compiler error)
FAIL: g++.dg/modules/xtreme-header-5_a.H -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-5_a.H -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-5_a.H -std=c++2b (internal compiler error)
FAIL: g++.dg/modules/xtreme-header-5_a.H -std=c++2b (internal compiler error)
FAIL: g++.dg/modules/xtreme-header-5_a.H -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-5_a.H -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-5_a.H module-cmi 
(gcm.cache/$srcdir/g++.dg/modules/xtreme-header-5_a.H.gcm)
FAIL: g++.dg/modules/xtreme-header-5_a.H module-cmi 
(gcm.cache/$srcdir/g++.dg/modules/xtreme-header-5_a.H.gcm)
FAIL: g++.dg/modules/xtreme-header-5_a.H module-cmi 
(gcm.cache/$srcdir/g++.dg/modules/xtreme-header-5_a.H.gcm)
FAIL: g++.dg/modules/xtreme-header-5_a.H module-cmi 
(gcm.cache/$srcdir/g++.dg/modules/xtreme-header-5_a.H.gcm)
FAIL: g++.dg/modules/xtreme-header-5_b.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-5_b.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-5_b.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-5_b.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/xtreme-header_a.H -std=c++17 (internal compiler error)
FAIL: g++.dg/modules/xtreme-header_a.H -std=c++17 (internal compiler error)
FAIL: g++.dg/modules/xtreme-header_a.H -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/xtreme-header_a.H -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/xtreme-header_a.H -std=c++2a (internal compiler error)
FAIL: g++.dg/modules/xtreme-header_a.H -std=c++2a (internal comp

[Bug c++/102643] Segfault in alias template deduction

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

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

Patrick Palka  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-10-11
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org

--- Comment #2 from Patrick Palka  ---
Reduced testcase (needs a checking compiler to reliably crash):

template
struct vector {
  typedef int allocator_type;
  vector(_Tp, allocator_type = allocator_type());
};
template using vector_mm = vector;
vector_mm v(0);

I suppose we should add this testcase to the testsuite before closing the PR.

[Bug c++/102643] Segfault in alias template deduction

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:0de8c2f8104b74f46e63d0d5d7b9e8fd3f04bb98

commit r12-4323-g0de8c2f8104b74f46e63d0d5d7b9e8fd3f04bb98
Author: Patrick Palka 
Date:   Mon Oct 11 12:33:30 2021 -0400

c++: Add testcase for already-fixed PR [PR102643]

Fixed with r12-1744.

PR c++/102643

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/class-deduction-alias11.C: New test.

[Bug bootstrap/102681] [12 Regression] AArch64 bootstrap failure

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

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

--- Comment #3 from Martin Sebor  ---
Simply initializing the variable as in the patch below avoids the warning.  The
control flow in the code is sufficiently opaque to make it worthwhile from a
readability point irrespective of whether or not the variable can, in fact, be
used uninitialized.

index e50d3fc3b62..c7f0a405ff6 100644
--- a/gcc/calls.c
+++ b/gcc/calls.c
@@ -199,7 +199,7 @@ stack_region_maybe_used_p (poly_uint64 lower_bound,
poly_uint64 upper_bound,
 static void
 mark_stack_region_used (poly_uint64 lower_bound, poly_uint64 upper_bound)
 {
-  unsigned HOST_WIDE_INT const_lower, const_upper;
+  unsigned HOST_WIDE_INT const_lower, const_upper = 0;
   const_lower = constant_lower_bound (lower_bound);
   if (upper_bound.is_constant (&const_upper))
 for (unsigned HOST_WIDE_INT i = const_lower; i < const_upper; ++i)

[Bug c++/102643] Segfault in alias template deduction

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=86439
 Resolution|--- |FIXED
   Target Milestone|--- |12.0

--- Comment #4 from Patrick Palka  ---
Fixed

[Bug fortran/102685] New: [12 Regression] ICE in output_constructor_regular_field, at varasm.c:5514

[gscfq--- via Gcc-bugs]

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

Bug ID: 102685
   Summary: [12 Regression] ICE in
output_constructor_regular_field, at varasm.c:5514
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed _recently_ between 20211003 and 20211010 :


$ cat z1.f90
program p
   type t
  integer :: a(1)
   end type
   type(t), parameter :: x(2) = t([1,2])
   print *, x
end


$ gfortran-12-20211003 -c z1.f90
$
$ gfortran-12-20211010 -c z1.f90
z1.f90:7:3:

7 | end
  |   ^
internal compiler error: in output_constructor_regular_field, at varasm.c:5514
0x10131f4 output_constructor_regular_field
../../gcc/varasm.c:5514
0x10131f4 output_constructor
../../gcc/varasm.c:5826
0x101353f output_constant
../../gcc/varasm.c:5172
0x101353f assemble_variable_contents
../../gcc/varasm.c:2235
0x101b31d assemble_variable(tree_node*, int, int, int)
../../gcc/varasm.c:2414
0x101d61a varpool_node::assemble_decl()
../../gcc/varpool.c:595
0x953def output_in_order
../../gcc/cgraphunit.c:2135
0x953def symbol_table::compile()
../../gcc/cgraphunit.c:2353
0x95670f symbol_table::compile()
../../gcc/cgraphunit.c:2540
0x95670f symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2537

[Bug fortran/102685] [12 Regression] ICE in output_constructor_regular_field, at varasm.c:5514

[gscfq--- via Gcc-bugs]

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

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||accepts-invalid,
   ||ice-on-invalid-code

--- Comment #1 from G. Steinmetz  ---

This invalid variant is still accepted :
(also related to pr100970)


$ cat z2.f90
program p
   type t
  integer :: a(1)
   end type
   type(t) :: x(2) = t([1,2])
   print *, x
end

[Bug fortran/102686] New: [PDT] ICE in check_host_association, at fortran/resolve.c:6055

[gscfq--- via Gcc-bugs]

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

Bug ID: 102686
   Summary: [PDT] ICE in check_host_association, at
fortran/resolve.c:6055
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with r8 :


$ cat z1.f90
module m
   implicit none
contains
   integer function n()
  n = 1
   end
   subroutine s
  type t(n)
 integer, len :: n = 2
 character(n) :: c
  end type
   end
end


$ cat z2.f90
module m
   implicit none
contains
   subroutine s
  type t(n)
 integer, len :: n = 2
 character(n) :: c
  end type
   end
   integer function n()
  n = 1
   end
end


$ gfortran-12-20211010 -c z1.f90
f951: internal compiler error: Segmentation fault
0xd43fcf crash_signal
../../gcc/toplev.c:326
0x806716 check_host_association
../../gcc/fortran/resolve.c:6055
0x806716 gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:7114
0x79a244 gfc_reduce_init_expr(gfc_expr*)
../../gcc/fortran/expr.c:3125
0x77b972 char_len_param_value
../../gcc/fortran/decl.c:1126
0x77e690 gfc_match_char_spec(gfc_typespec*)
../../gcc/fortran/decl.c:3553
0x785037 gfc_match_decl_type_spec(gfc_typespec*, int)
../../gcc/fortran/decl.c:4294
0x7865dc gfc_match_data_decl()
../../gcc/fortran/decl.c:6254
0x7f01d3 match_word
../../gcc/fortran/parse.c:65
0x7f01d3 decode_statement
../../gcc/fortran/parse.c:376
0x7f1c1a next_free
../../gcc/fortran/parse.c:1384
0x7f1c1a next_statement
../../gcc/fortran/parse.c:1616
0x7f3774 parse_derived
../../gcc/fortran/parse.c:3571
0x7f3774 parse_spec
../../gcc/fortran/parse.c:4112
0x7f610c parse_progunit
../../gcc/fortran/parse.c:6117
0x7f64f1 parse_contained
../../gcc/fortran/parse.c:6018
0x7f73b7 parse_module
../../gcc/fortran/parse.c:6391
0x7f76e7 gfc_parse_file()
../../gcc/fortran/parse.c:6694
0x84480f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:216

[Bug lto/102649] GCC 9.3.1 LTO bug -- incorrect function call, bad stack arguments pushed

[davidhaufegcc at gmail dot com via Gcc-bugs]

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

--- Comment #2 from David Haufe  ---
I had assumed this would be the response. Unfortunately the source code
involved is both large (1000+ object files in this build) and proprietary. The
behavior we see where if we roll forward GIT and rebuild, and unrelated changes
"fix" the problem, makes it seem futile to develop an isolated test case. 

I can provide the assembly for the functions that highlight the error if that
would be beneficial? Not sure how helpful that would be though. Are there any
other best practices in a case like this one?

[Bug fortran/102685] [12 Regression] ICE in output_constructor_regular_field, at varasm.c:5514

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Priority|P3  |P4
   Last reconfirmed||2021-10-11
 Ever confirmed|0   |1
 CC||anlauf at gcc dot gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
That's arguably a regression.

gcc-11 accepted the invalid testcase in comment#0 but generated wrong code.

The real reason is that the constructor is not dealth with properly,
and there are several related PRs I am too lazy to look up now.

The accepts-invalid for comment#1 is old and not a regression for that reason.
gcc-7 had that already, and maybe much longer.

[Bug middle-end/102687] New: [12 Regression] bootstrap ICE in insert_access, at ipa-modref-tree.h:582

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

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

Bug ID: 102687
   Summary: [12 Regression] bootstrap ICE in insert_access, at
ipa-modref-tree.h:582
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The current GCC 12 trunk fails to bootstrap for me with the ICE below.  Based
on git log I wonder if g:008e7397dad971c03c08fc1b0a4a98fddccaaed8 might be to
blame.

during IPA pass: modref
In file included from /ssd/test/src/gcc/trunk/gcc/cp/module.cc:20075:
./gt-cp-module.h: In member function ‘bool trees_in::core_vals(tree)’:
./gt-cp-module.h:420:1: internal compiler error: in insert_access, at
ipa-modref-tree.h:582
  420 | }
  | ^
0x1452a63 modref_ref_node::insert_access(modref_access_node, unsigned
long, bool)
/ssd/test/src/gcc/trunk/gcc/ipa-modref-tree.h:582
0x1450ef5 modref_tree::insert(int, int, modref_access_node, bool)
/ssd/test/src/gcc/trunk/gcc/ipa-modref-tree.h:853
0x143f5aa record_access
/ssd/test/src/gcc/trunk/gcc/ipa-modref.c:719
0x1441012 analyze_store
/ssd/test/src/gcc/trunk/gcc/ipa-modref.c:1251
0x134baa4 walk_stmt_load_store_addr_ops(gimple*, void*, bool (*)(gimple*,
tree_node*, tree_node*, void*), bool (*)(gimple*, tree_node*, tree_node*,
void*), bool (*)(gimple*, tree_node*, tree_node*, void*))
/ssd/test/src/gcc/trunk/gcc/gimple-walk.c:767
0x134cc0b walk_stmt_load_store_ops(gimple*, void*, bool (*)(gimple*,
tree_node*, tree_node*, void*), bool (*)(gimple*, tree_node*, tree_node*,
void*))
/ssd/test/src/gcc/trunk/gcc/gimple-walk.c:966
0x14410cd analyze_stmt
/ssd/test/src/gcc/trunk/gcc/ipa-modref.c:1274
0x1443b25 analyze_function
/ssd/test/src/gcc/trunk/gcc/ipa-modref.c:2138
0x1443f0e modref_generate
/ssd/test/src/gcc/trunk/gcc/ipa-modref.c:2216
0x1644856 execute_ipa_summary_passes(ipa_opt_pass_d*)
/ssd/test/src/gcc/trunk/gcc/passes.c:2248
0x10d2ccb ipa_passes
/ssd/test/src/gcc/trunk/gcc/cgraphunit.c:2179
0x10d312f symbol_table::compile()
/ssd/test/src/gcc/trunk/gcc/cgraphunit.c:2289
0x10d3730 symbol_table::finalize_compilation_unit()
/ssd/test/src/gcc/trunk/gcc/cgraphunit.c:2537
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.

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

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

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

--- Comment #44 from Eric Gallager  ---
(In reply to Martin Liška from comment #43)
> (In reply to Eric Gallager from comment #42)
> > Is this just about parallelism bottlenecks for the main build target (e.g.
> > just `make` or `make all`), or does it apply to other Makefile targets, too?
> > (e.g. the testsuite via `make check`, or docs via `make pdf` or something)
> 
> Well, it was intended to cover only the main build, which pdf can be seen as
> part of.

I usually have to run `make pdf` as a separate build target, though, as it
doesn't get run as part of the main build for me... and the bottleneck there,
for the pdf target, is in libstdc++ for me...

[Bug libstdc++/102567] Missing noexcept specialization of std::function

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

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

--- Comment #6 from Jonathan Wakely  ---
std::move_only_function is on trunk now.

[Bug testsuite/102688] New: [12 regression] gcc.dg/ipa/iinline-attr.c fails after r12-4288

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

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

Bug ID: 102688
   Summary: [12 regression] gcc.dg/ipa/iinline-attr.c fails after
r12-4288
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:177b800f5fc861af1bf8700f050de28dd47ee1aa, r12-4288

FAIL: gcc.dg/ipa/iinline-attr.c scan-ipa-dump inline "hooray[^\\n]*inline copy
in test"

Executing on host: /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/ipa/iinline-attr.c   
-fdiagnostics-plain-output   -O2 -fdump-ipa-inline -S -o iinline-attr.s   
(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/ipa/iinline-attr.c
-fdiagnostics-plain-output -O2 -fdump-ipa-inline -S -o iinline-attr.s^M
PASS: gcc.dg/ipa/iinline-attr.c (test for excess errors)
FAIL: gcc.dg/ipa/iinline-attr.c scan-ipa-dump inline "hooray[^\\n]*inline copy
in test"

[Bug libstdc++/102667] Inconsistent result of std::regex_match

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

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

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

https://gcc.gnu.org/g:84088dc4bb6a546c896a068dc201463493babf43

commit r12-4325-g84088dc4bb6a546c896a068dc201463493babf43
Author: Jonathan Wakely 
Date:   Mon Oct 11 09:07:15 2021 +0100

libstdc++: Fix std::match_results::end() for failed matches [PR102667]

The end() function needs to consider whether the underlying vector is
empty, not whether the match_results object is empty. That's because the
underlying vector will always contain at least three elements for a
match_results object that is "ready". It contains three extra elements
which are stored in the vector but are not considered part of sequence,
and so should not be part of the [begin(),end()) range.

libstdc++-v3/ChangeLog:

PR libstdc++/102667
* include/bits/regex.h (match_result::empty()): Optimize by
calling the base function directly.
(match_results::end()): Check _Base_type::empty() not empty().
* testsuite/28_regex/match_results/102667.C: New test.

[Bug libstdc++/89927] Inconsistent behavior in std::regex when optimized

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

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

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

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

commit r12-4326-g6b6788f8c2748060d922cc22173ff7f8500917e9
Author: Jonathan Wakely 
Date:   Mon Oct 11 12:08:59 2021 +0100

libstdc++: Add valid range assertions to std::basic_regex [PR89927]

This adds some debug assertions to basic_regex. They don't actually
diagnose the error in the PR yet, but I have another patch to make them
more effective.

Also change the __glibcxx_assert(false) consistency checks to include a
string literal that tells the user a bit more about why the process
aborted. We could consider adding a __glibcxx_bug or
__glibcxx_internal_error macro for this purpose, but ideally we'll never
hit such bugs anyway so it shouldn't be needed.

libstdc++-v3/ChangeLog:

PR libstdc++/89927
* include/bits/regex.h (basic_regex(const _Ch_type*, size_t)):
Add __glibcxx_requires_string_len assertion.
(basic_regex::assign(InputIterator, InputIterator)): Add
__glibcxx_requires_valid_range assertion.
* include/bits/regex_scanner.tcc (_Scanner::_M_advance())
(_Scanner::_M_scan_normal()): Use string literal in assertions.

[Bug middle-end/102687] [12 Regression] bootstrap ICE in insert_access, at ipa-modref-tree.h:582

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

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

--- Comment #1 from Jan Hubicka  ---
Sorry, I accidentally commited an unrelated change I had in my tree.
I am testing
diff --git a/gcc/ipa-modref-tree.h b/gcc/ipa-modref-tree.h
index 52f225b1aae..9795e2b8405 100644
--- a/gcc/ipa-modref-tree.h
+++ b/gcc/ipa-modref-tree.h
@@ -148,8 +148,7 @@ struct GTY(()) modref_access_node
   poly_int64 offset1, poly_int64 size1, poly_int64 max_size1,
   bool record_adjustments)
 {
-  if (known_eq (parm_offset, parm_offset1)
- && known_eq (offset, offset1)
+  if (known_eq (offset, offset1)
  && known_eq (size, size1)
  && known_eq (max_size, max_size1))
return;
@@ -578,10 +577,6 @@ struct GTY((user)) modref_ref_node
  }
(*accesses)[best1].forced_merge (best2 < 0 ? a : (*accesses)[best2],
 record_adjustments);
-   /* CHeck that merging indeed merged ranges.  */
-   gcc_checking_assert ((*accesses)[best1].contains (best2 < 0 ? a :
(*accesses)[best2]));
-   /*if (best2 >= 0)
- accesses->unordered_remove (best2);*/
if (!(*accesses)[best1].useful_p ())
  {
collapse ();

[Bug fortran/102689] New: Segfault with RESHAPE of CLASS as actual argument

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

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

Bug ID: 102689
   Summary: Segfault with RESHAPE of CLASS as actual argument
   Product: gcc
   Version: 12.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: ---

Created attachment 51586
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51586&action=edit
testcase - compile & run (fails with segfault at marked line)

Dummy and actual argument are CLASS, then:

   call class_bar (RESHAPE (B, [100]))

will segfault at runtime.  Besides the actual crash, the question is why there
is a call to the library at all:

  _gfortran_reshape_4 (&atmp.25, D.4357, D.4383, 0B, 0B);

At least for most common cases, it looks as if this should be inlined.

[Bug c++/67898] rejects-valid on overloaded function as non-type template argument of dependent type

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

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug c++/102281] -ftrivial-auto-var-init=zero causes ice

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

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

--- Comment #7 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #2)
> __builtin_clear_padding when folded emits a series of memory stores rather
> than BIT_INSERT_EXPR etc., so that wouldn't work.
> But, IMNSHO, -ftrivial-auto-var-init* shouldn't be adding
> __builtin_clear_padding calls at all for objects of types that can't have
> any padding.
> Currently one can do e.g. what my
> r12-3455-g8122fbff770bcff183a9c3c72e8092c0ca32150b does for OpenMP atomics,
> + bool clear_padding = false;   
> 
> + if (BITS_PER_UNIT == 8 && CHAR_BIT == 8)  
> 
> +   {   
> 
> + HOST_WIDE_INT sz = int_size_in_bytes (cmptype), i;
> 
> + gcc_assert (sz > 0);  
> 
> + unsigned char *buf = XALLOCAVEC (unsigned char, sz);  
> 
> + memset (buf, ~0, sz); 
> 
> + clear_type_padding_in_mask (cmptype, buf);
> 
> + for (i = 0; i < sz; i++)  
> 
> +   if (buf[i] != (unsigned char) ~0)   
> 
> + { 
> 
> +   clear_padding = true;   
> 
> +   break;  
> 
> + } 
> 
> +   }   
> 
> so that when nothing needs to be padded (the usual case for non-struct/union
> types unless they have extended long double), the builtin isn't added at all.
> I doubt we support vectors of long double, so it is mainly whether returning
> of long double or _Complex long double works fine.

I agree that the above additional check  is necessary.

one question here is, can I use the routine "bool
clear_padding_type_may_have_padding_p (tree type)" in gimple-fold.c instead of
the above new function for this purpose?

[Bug objc++/56604] Missing obj-c++.srcman target

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

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

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

https://gcc.gnu.org/g:30cce6f65a77b8eaa22f3efff7f1ba54858106f9

commit r12-4331-g30cce6f65a77b8eaa22f3efff7f1ba54858106f9
Author: Eric Gallager 
Date:   Sat Oct 9 15:10:32 2021 -0400

Add obj-c++.srcman target to gcc/objcp/Makefile.

Closes #56604

Signed-off-by: Eric Gallager 

gcc/objcp/ChangeLog:
PR objc++/56604
* Make-lang.in: Add obj-c++.srcman: line.

[Bug objc++/56604] Missing obj-c++.srcman target

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

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #6 from Eric Gallager  ---
Fixed.