[Bug middle-end/112830] internal compiler error: in convert_memory_address_addr_space_1, at explow.cc:302

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

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

--- Comment #3 from Richard Biener  ---
I think the assert can be relaxed to make truncation OK.

[Bug web/108473] bugzilla see also should support gitlab.com URLs

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #9 from Eric Gallager  ---
(In reply to Mark Wielaard from comment #7)
> OK, applied all 12 above commits to both both gcc and sourceware bugzilla.
> There were some small whitespace issues, but most applied cleanly.
> 
> Could you check that everything looks fine and the new trackers can be added
> through See Also now?

GitLab links added to See Also without issue in bug 112380

[Bug tree-optimization/112827] [14 Regression] ICE on valid code at -O1 on x86_64-linux-gnu: Segmentation fault

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
Version|unknown |14.0
   Priority|P3  |P1
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Target||x86_64-*-*

--- Comment #3 from Richard Biener  ---
Sounds like mine.

[Bug tree-optimization/112818] [14 regression] ICE when building accel-ppp (error: conversion of register to a different size in ‘view_convert_expr’, verify_gimple failed)

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

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

--- Comment #5 from Sam James  ---
that's in my bisect range, yeah, got a few steps to go..

[Bug middle-end/112822] [14 regression] ICE: invalid RHS for gimple memory store after r14-5831-gaae723d360ca26

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug c++/112820] vtable not emitted correctly from module when compiling with -g

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||documentation,
   ||internal-improvement

--- Comment #2 from Richard Biener  ---
The flags are documented to not apply to the same entities (TYPE_DECL vs. other
_DECL nodes).  If that no longer applies then I think we should pick different
flags here (or not use DECL_EXTERNAL on TYPE_DECL in the C++ frontend?).

We might want to strengthen the tree checking on DECL_EXTERNAL as it currently
allows all decl nodes.

[Bug tree-optimization/112819] rearrange branches to improve code generation

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||fkastl at suse dot cz,
   ||hubicka at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Last reconfirmed||2023-12-04
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
We don't "re-associate" branches.  But we might want to turn if-to-switch
into sth that does (relaxing the restriction on the ifs testing the same var).

We should have a PHI node with incoming vals predicated by the ifs, free to
re-order otherwise.

The *a deref might impose some limitations for re-ordering, but we can always
handle it last in this case.

Might be also interesting to order branches which are predictable earlier.

Related to switch-conversion/if-to-switch IMHO.

[Bug tree-optimization/112818] [14 regression] ICE when building accel-ppp (error: conversion of register to a different size in ‘view_convert_expr’, verify_gimple failed)

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
I'll have a look, likely caused by r14-5068-g88aca917eb705b.

[Bug other/112836] gcc fails when job control is used

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

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

--- Comment #2 from Sam James  ---
Thanks for chasing this down. This has been driving me nuts for a while but I
hadn't dug into it yet.

[Bug c/112841] typeof_unqual is not removing qualifiers from the element type of array types

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

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

--- Comment #2 from Andrew Pinski  ---
Note clang also gets this "wrong".

You can see that from:
```
const char* const animals[] = {
"aardvark",
"bluejay",
 "catte",
};
int main (int argc, char* argv[]) {
 const char* animals2_array1[3];
 typeof_unqual(animals) animals2_array;
 animals2_array1[0] = 0;
 animals2_array[0] = 0;
 return 0;
}
```

[Bug tree-optimization/112814] `Plus , PHI>` is not optimized to just PLUS

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Interesting one - this isn't catched by PRE code hoisting because that only
hoists sth if it's available in one of the successors (but it's only antic
there).

[Bug target/112813] [14 Regression] RISCV ICE: vsetvl pass: in merge at config/riscv/riscv-vsetvl.cc:1968 on rv32gcv_zvl256b

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug c/112841] typeof_unqual is not removing qualifiers from the element type of array types

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
Summary|typeof_unqual is not|typeof_unqual is not
   |removing qualifiers from|removing qualifiers from
   |array types |the element type of array
   ||types
   Last reconfirmed||2023-12-04

--- Comment #1 from Andrew Pinski  ---
Hmm, 6.7.3/10
"If the specification of an array type includes any type qualifiers, both the
array and the element type are so-qualified." and the note 166 notes that this
can happen with typedefs ...

But then typeof_unqual only mentions the about the type qualifer of the array
and not the element type but the example is showing it means the element type
of the array should be unqualified too ...

I am suspecting if we are pedantic about the language used, this would be a
defect in the standard where the typeof_unqual does not mention the `element
type` when it should as the example intends it as such.


Note GCC does not try to remove qualifiers from the element type because of
this quirk in the language of the standard dealing with array types ...

Confirmed at least GCC is not following the example in the standard ...

[Bug c/112841] New: typeof_unqual is not removing qualifiers from array types

[luigighiron at gmail dot com via Gcc-bugs]

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

Bug ID: 112841
   Summary: typeof_unqual is not removing qualifiers from array
types
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: luigighiron at gmail dot com
  Target Milestone: ---

GCC does not remove qualifiers from array types when used with typeof_unqual:

puts(_Generic(
(typeof_unqual(const int[])*)0,
int(*)[]:"non-const",
const int(*)[]:"const"
));

This should print non-const, but GCC prints const.

The latest working draft of the standard includes an example of typeof_unqual
with an array of const:

> EXAMPLE 2 The following program:
> const _Atomic int purr = 0;
> const int meow = 1;
> const char* const animals[] = {
> "aardvark",
> "bluejay",
> "catte",
> };
> typeof_unqual(meow) main (int argc, char* argv[]) {
> typeof_unqual(purr) plain_purr;
> typeof(_Atomic typeof(meow)) atomic_meow;
> typeof(animals) animals_array;
> typeof_unqual(animals) animals2_array;
> return 0;
> }
> is equivalent to this program:
> const _Atomic int purr = 0;
> const int meow = 1;
> const char* const animals[] = {
> "aardvark",
> "bluejay",
> "catte",
> };
> int main (int argc, char* argv[]) {
> int plain_purr;
> const _Atomic int atomic_meow;
> const char* const animals_array[3];
> const char* animals2_array[3];
> return 0;
> }
Section 6.7.2.5 "Typeof specifiers" Paragraph 7, from N3096

Here, GCC does not not remove the const on the array type for animals2_array in
the first part of the example.

[Bug target/112816] [11/12/13/14 Regression] ICE unrecognizable_insn with __builtin_signbit and returning struct with int[4]

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

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

liuhongt at gcc dot gnu.org changed:

   What|Removed |Added

 CC||liuhongt at gcc dot gnu.org

--- Comment #6 from liuhongt at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #3)
> Created attachment 56767 [details]
> gcc14-pr112816.patch
> 
> Untested fix.
> 
> Another issue is that the emitted code is terrible:
> pxor%xmm1, %xmm1
> psrld   $31, %xmm0
> pcmpeqd %xmm1, %xmm0
> pcmpeqd %xmm1, %xmm0
> Why not just
> psrad   $31, %xmm0
> instead of all this?

We have optimization in ix86_expand_int_vcond.
 5090  /* Try to optimize x < 0 ? -1 : 0 into (signed) x >> 31
 5091 and x < 0 ? 1 : 0 into (unsigned) x >> 31.  */

But for signbit case, it's 

  vect__1.10_4 = MEM  [(float *)&x];
  vect__2.11_3 = .SIGNBIT (vect__1.10_4);
  mask__11.12_22 = vect__2.11_3 != { 0, 0, 0, 0 };
  vect__13.14_26 = VIEW_CONVERT_EXPR(mask__11.12_22);

I'm curious, can we move all of those to the middle-end, like match.pd?

[Bug target/101017] ICE: Segmentation fault, convert_memory_address_addr_space_1 with vector_size(32) and target_clone arch=core-avx2/default

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

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

liuhongt at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||liuhongt at gcc dot gnu.org

--- Comment #5 from liuhongt at gcc dot gnu.org ---
Let me take a look.

[Bug target/112583] RISC-V regression testsuite errors with rv64gcv_zvl128b

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #9 from JuzheZhong  ---
=== gfortran: Unexpected fails for rv64gcv lp64d medany  ===
FAIL: gfortran.dg/dollar_edit_descriptor_3.f   -O0  output pattern test
FAIL: gfortran.dg/dollar_edit_descriptor_3.f   -O1  output pattern test
FAIL: gfortran.dg/dollar_edit_descriptor_3.f   -O2  output pattern test
FAIL: gfortran.dg/dollar_edit_descriptor_3.f   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  output pattern test
FAIL: gfortran.dg/dollar_edit_descriptor_3.f   -O3 -g  output pattern test
FAIL: gfortran.dg/dollar_edit_descriptor_3.f   -Os  output pattern test
FAIL: gfortran.dg/namelist_print_1.f   -O0  output pattern test
FAIL: gfortran.dg/namelist_print_1.f   -O1  output pattern test
FAIL: gfortran.dg/namelist_print_1.f   -O2  output pattern test
FAIL: gfortran.dg/namelist_print_1.f   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  output pattern test
FAIL: gfortran.dg/namelist_print_1.f   -O3 -g  output pattern test
FAIL: gfortran.dg/namelist_print_1.f   -Os  output pattern test
FAIL: gfortran.dg/read_x_eor.f90   -O0  output pattern test
FAIL: gfortran.dg/read_x_eor.f90   -O1  output pattern test
FAIL: gfortran.dg/read_x_eor.f90   -O2  output pattern test
FAIL: gfortran.dg/read_x_eor.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  output pattern test
FAIL: gfortran.dg/read_x_eor.f90   -O3 -g  output pattern test
FAIL: gfortran.dg/read_x_eor.f90   -Os  output pattern test
FAIL: gfortran.dg/g77/f77-edit-apostrophe-out.f   -O0  output pattern test
FAIL: gfortran.dg/g77/f77-edit-apostrophe-out.f   -O1  output pattern test
FAIL: gfortran.dg/g77/f77-edit-apostrophe-out.f   -O2  output pattern test
FAIL: gfortran.dg/g77/f77-edit-apostrophe-out.f   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  output pattern test
FAIL: gfortran.dg/g77/f77-edit-apostrophe-out.f   -O3 -g  output pattern test
FAIL: gfortran.dg/g77/f77-edit-apostrophe-out.f   -Os  output pattern test
FAIL: gfortran.dg/g77/f77-edit-colon-out.f   -O0  output pattern test
FAIL: gfortran.dg/g77/f77-edit-colon-out.f   -O1  output pattern test
FAIL: gfortran.dg/g77/f77-edit-colon-out.f   -O2  output pattern test
FAIL: gfortran.dg/g77/f77-edit-colon-out.f   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  output pattern test
FAIL: gfortran.dg/g77/f77-edit-colon-out.f   -O3 -g  output pattern test
FAIL: gfortran.dg/g77/f77-edit-colon-out.f   -Os  output pattern test
FAIL: gfortran.dg/g77/f77-edit-h-out.f   -O0  output pattern test
FAIL: gfortran.dg/g77/f77-edit-h-out.f   -O1  output pattern test
FAIL: gfortran.dg/g77/f77-edit-h-out.f   -O2  output pattern test
FAIL: gfortran.dg/g77/f77-edit-h-out.f   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  output pattern test
FAIL: gfortran.dg/g77/f77-edit-h-out.f   -O3 -g  output pattern test
FAIL: gfortran.dg/g77/f77-edit-h-out.f   -Os  output pattern test
FAIL: gfortran.dg/g77/f77-edit-i-out.f   -O0  output pattern test
FAIL: gfortran.dg/g77/f77-edit-i-out.f   -O1  output pattern test
FAIL: gfortran.dg/g77/f77-edit-i-out.f   -O2  output pattern test
FAIL: gfortran.dg/g77/f77-edit-i-out.f   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  output pattern test
FAIL: gfortran.dg/g77/f77-edit-i-out.f   -O3 -g  output pattern test
FAIL: gfortran.dg/g77/f77-edit-i-out.f   -Os  output pattern test
FAIL: gfortran.dg/g77/f77-edit-s-out.f   -O0  output pattern test
FAIL: gfortran.dg/g77/f77-edit-s-out.f   -O1  output pattern test
FAIL: gfortran.dg/g77/f77-edit-s-out.f   -O2  output pattern test
FAIL: gfortran.dg/g77/f77-edit-s-out.f   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  output pattern test
FAIL: gfortran.dg/g77/f77-edit-s-out.f   -O3 -g  output pattern test
FAIL: gfortran.dg/g77/f77-edit-s-out.f   -Os  output pattern test
FAIL: gfortran.dg/g77/f77-edit-slash-out.f   -O0  output pattern test
FAIL: gfortran.dg/g77/f77-edit-slash-out.f   -O1  output pattern test
FAIL: gfortran.dg/g77/f77-edit-slash-out.f   -O2  output pattern test
FAIL: gfortran.dg/g77/f77-edit-slash-out.f   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  output pattern test
FAIL: gfortran.dg/g77/f77-edit-slash-out.f   -O3 -g  output pattern test
FAIL: gfortran.dg/g77/f77-edit-slash-out.f   -Os  output pattern test
FAIL: gfortran.dg/g77/f77-edit-t-out.f   -O0  output pattern test
FAIL: gfortran.dg/g77/f77-edit-t-out.f   -O1  output pattern test
FAIL: gfortran.dg/g77/f77-edit-t-out.f   -O2  output pattern test
FAIL: gfortran.dg/g77/f77-edit-t-out.f   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  output pattern test
FAIL: gfortran.dg/g77/f77-edit-t-out.f   -O3 -g  output pattern test
FAIL: gfortran.dg/g77/f77-edit-t-out.f   -Os  out

[Bug middle-end/112824] Stack spills and vector splitting with vector builtins

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

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

liuhongt at gcc dot gnu.org changed:

   What|Removed |Added

 CC||liuhongt at gcc dot gnu.org

--- Comment #4 from liuhongt at gcc dot gnu.org ---
there're 2 reasons.
1. X86_TUNE_AVX512_MOVE_BY_PIECES is used for move struct but it's independent
of -mprefer-vector-width=512, manully add
-mtune-ctrl=-mtune-ctrl=avx512_move_by_pieces can solve most cases.
2. There's still spills for (subreg:DF (reg: V8DF) since ix86_modes_tieable_p
return false for DF and V8DF.

For 1, I guess when there's explicit -mprefer-vector-width=512, it should
rewrite tune X86_TUNE_AVX512_MOVE_BY_PIECES and unset
X86_TUNE_AVX256_OPTIMAL/X86_TUNE_AVX128_OPTIMAL

For 2, according to doc, it should return false since DF can be allocated to
X87 reg, but V8DF only SSE_REGS, so the fix should be using vec_select instead
of subreg for that case?

[Bug middle-end/112822] [14 regression] ICE: invalid RHS for gimple memory store after r14-5831-gaae723d360ca26

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

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

--- Comment #3 from Peter Bergner  ---
Created attachment 56784
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56784&action=edit
creduce minimized test case

Attached creduce minimized test case.  Use -O3 -mcpu=power10 to recreate.

[Bug target/59390] presence of __attribute__((target("fma"))) declaration breaks __builtin_fma

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||d.g.gorbachev at gmail dot com

--- Comment #7 from Andrew Pinski  ---
*** Bug 56536 has been marked as a duplicate of this bug. ***

[Bug target/56536] GCC with LTO and `-march=pentium3' tries to generate SSE2 code

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|FIXED   |DUPLICATE

--- Comment #3 from Andrew Pinski  ---
Actually it was a dup of bug 59390.

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

[Bug target/56536] GCC with LTO and `-march=pentium3' tries to generate SSE2 code

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Fixed for GCC 4.9.0 by r0-127160-g26084432876599 .

[Bug target/112813] [14 Regression] RISCV ICE: vsetvl pass: in merge at config/riscv/riscv-vsetvl.cc:1968 on rv32gcv_zvl256b

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #2 from JuzheZhong  ---
https://godbolt.org/z/8bovzxYox

Confirm it has been fixed now.

Could you send a patch with test pr112813.c ? To avoid future regression.

Thanks.

[Bug middle-end/112572] [14 regression] LLVM miscompiled since r14-5355-g3cd3a09b3f91a1

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #31 from Andrew Pinski  ---
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40209#c5 (and other comments
there about single_use). This definitely has been a latent issue with
single_use for a long time now too ...

[Bug gcov-profile/112829] Dump PGO profiles to a memory buffer

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #3 from Andrew Pinski  ---
GCC does not currently have a way. Though I suspect one of the reasons is that
for embedded, folks don't use -fprofile-generate/-fprofile-use that much or
they use a simulator which then has direct access to the host machine to
generate the files.

I Know for Octeon SE (MIPS baremetal interface on the Cavium Octeon) that they
had a way to do this using memory dump but it was hooked up outside of gcov and
in newlib instead.

I do think this is a good idea for embedded env but I am not sure if anyone who
is interested in doing it. for Linux env, using nfs mount and
-fprofile-dir=/-fprofile-prefix-map=/-fprofile-prefix-path= is one way of doing
it.

Also if you are using Zephyr, it does handle the writes and does the store to
memory and such too.  See
https://docs.zephyrproject.org/latest/develop/test/coverage.html .

[Bug tree-optimization/112788] [14 regression] ICEs in fold_range, at range-op.cc:206 after r14-5972-gea19de921b01a6

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

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

Kewen Lin  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |linkw at gcc dot gnu.org
 Status|NEW |ASSIGNED
   Last reconfirmed|2023-12-03 00:00:00 |2023-12-01 0:00

--- Comment #4 from Kewen Lin  ---
(In reply to Andrew Macleod from comment #2)
> (In reply to Kewen Lin from comment #1)
> 
> > 
> > ranger makes use of type precision directly instead of something like
> > types_compatible_p. I wonder if we can introduce a target hook (or hookpod)
> > to make ranger unrestrict this check a bit, the justification is that for
> > float type its precision information is encoded in its underlying
> > real_format, if two float types underlying modes are the same, the precision
> > are actually the same. 
> > 
> > btw, the operand_check_ps seems able to call range_compatible_p?
> 
> It could, but just a precision check seemed enough at the time.
> The patch also went thru many iterations and it was only the final version
> that operand_check_p() ended up with types as the parameter rather than
> ranges.
> 
> You bring up a good point tho. I just switched those routines to call
> range_compatible_p() and checked it in.  Now it is all centralized in the
> one routine going forward. 

Nice! Thanks a lot for your prompt enhancement!

>  
> It does seem wrong that the float precision don't match, and weird that its
> hard to fix :-)   

Yes, I dislike it and thought it's not sensible and tried to fix, but as the
discussion in the thread mentioned above showed there were some historical
reasons and practical issues to fix it. At the time, Segher mentioned he had
some patches to avoid different modes having the same format but encountered
some issues before and would have a re-try, but now stage 1 passed again, I
guessed we have to stay with it in this release.

> It should now be possible to have range_compatible_p check
> the underlying mode for floats rather than the precision...  If there's a
> good argument for it, and you want to give that a shot...

I have to admit this idea is just a workaround, even the actual float precision
is encoded in the format associated to the underlying mode, but it's still
unexpected to have two types with the same underlying mode but different type
precision. I'm going to make and test a workaround patch since it affected the
build again as reported. :(

[Bug modula2/112825] Modula 2 builds target objects as part of all-gcc

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #6 from Gaius Mulley  ---
Bootstrapped on x86_64.

Many thanks for the patch review - now git committed and pushed.
I'm optimistically closing this PR (feel free to re-open).

[Bug modula2/112825] Modula 2 builds target objects as part of all-gcc

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Gaius Mulley :

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

commit r14-6100-g4e5f5a8ae82c5f4f714102d2437175ec366f644c
Author: Gaius Mulley 
Date:   Mon Dec 4 01:35:46 2023 +

PR modula2/112825: modula2 builds target objects as part of all-gcc

This patch fixes the PR modula2/112825 which fails if the target
assembler is not present on the host.  This can be seen if the
build invokes make all-gcc.  m2 should not attempt to generate
target libraries when performing make all-gcc.

Prior to this patch it generated build/gcc/m2/gm2-libs/SYSTSEM.def
using the script gcc/m2/tools-src/makeSystem (and gm2 -c).
makeSystem should exec gm2 -S instead (and other flags)
to generate the list of target data types without requiring any
target tools.  The target types emitted are textually converted
into SYSTEM.def.

gcc/m2/ChangeLog:

PR modula2/112825
* tools-src/makeSystem: Change all occurrences of -c to -S.

Signed-off-by: Gaius Mulley 

[Bug gcov-profile/112829] Dump PGO profiles to a memory buffer

[zamazan4ik at tut dot by via Gcc-bugs]

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

--- Comment #2 from Alexander Zaitsev  ---
Am I right that right now in GCC there are no ready-to-use alternatives to "int
__llvm_profile_write_buffer(char *Buffer)" from LLVM and it should be
implemented somehow manually (as you described)?

[Bug gcov-profile/112829] Dump PGO profiles to a memory buffer

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

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

--- Comment #1 from Andrew Pinski  ---
One way is to simple replace all of the functions in gcov-io.c and implement
them, gcov_open, etc.

[Bug web/108473] bugzilla see also should support gitlab.com URLs

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

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

--- Comment #8 from Andrew Pinski  ---
gitlab works but savannah URLs still do not. (the URL I tested is in bug 107333
).

[Bug web/108473] bugzilla see also should support gitlab.com URLs

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

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

Mark Wielaard  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #7 from Mark Wielaard  ---
OK, applied all 12 above commits to both both gcc and sourceware bugzilla.
There were some small whitespace issues, but most applied cleanly.

Could you check that everything looks fine and the new trackers can be added
through See Also now?

[Bug web/108473] bugzilla see also should support gitlab.com URLs

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

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

--- Comment #6 from Mark Wielaard  ---
Also looking at f944c5b2a894f866fc50e06ba90fb5dbd902ba36 "Bug 1167919: See
Also: support debbugs.gnu.org tracker"

[Bug modula2/112825] Modula 2 builds target objects as part of all-gcc

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org

--- Comment #4 from Thomas Schwinge  ---
I too, months ago, had run into this problem -- via the nvptx 'as' failing on
'-o /dev/null'... (which I'll fix anyway).  After a quick look at
'gcc/m2/tools-src/makeSystem' I did presume that the compiler is invoked there
only for some side effects (remember, '-o /dev/null'), and thus fixing this
might be...

(In reply to Gaius Mulley from comment #3)
> Created attachment 56782 [details]
> Proposed fix
> 
> This patch changes all invocations of gm2 -c to gm2 -S to avoid invoking the
> target assembler (which might not be present if make all-gcc is run).

... as simple as this.  (Then, of course, interrupted by higher-priority
things, and I never got back to this.)

Therefore, for what it's worth, conceptual ACK to this proposed change (which
I've not yet tested, but will, eventually).

[Bug target/112837] [12/13/14 Regression] ICE: RTL check: expected elt 1 type 'i' or 'n', have 'e' (rtx plus) in ix86_elim_entry_set_got, at config/i386/i386.cc:8612 with -fcompare-elim -fpie -fprofil

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-12-03
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Created attachment 56783
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56783&action=edit
gcc14-pr112837.patch

Untested fix.

[Bug modula2/112825] Modula 2 builds target objects as part of all-gcc

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

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

Gaius Mulley  changed:

   What|Removed |Added

 CC||gaius at gcc dot gnu.org

--- Comment #3 from Gaius Mulley  ---
Created attachment 56782
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56782&action=edit
Proposed fix

This patch changes all invocations of gm2 -c to gm2 -S to avoid invoking the
target assembler (which might not be present if make all-gcc is run).

Tested using:

cd gcc-src
mkdir build
cd build
../configure --target=aarch64-linux-gnu --enable-languages=m2
make all-gcc -j 30

on an x86_64 based gnu/linux box

[Bug modula2/112825] Modula 2 builds target objects as part of all-gcc

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

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

--- Comment #2 from Gaius Mulley  ---
Following up on commit: 301dec8533460152c4dd61f46c8e9276e169c49a.

Indeed m2 shouldn't attempt to generate target libraries when performing make
all-gcc.  Currently it generates build/gcc/m2/gm2-libs/SYSTSEM.def using the
script gcc/m2/tools-src/makeSystem.  makeSystem should exec gm2 with -S rather
than -c (and other flags) to generate the list of target data types which are
textually converted into SYSTEM.def.

[Bug middle-end/112830] internal compiler error: in convert_memory_address_addr_space_1, at explow.cc:302

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
The middle-end of GCC definitely does not support the case where size_type for
address spaces is different from the original type. At this point as shown by
the other bug reports too. I had ideas of how to change/fix that but have not
implemented it since the targets recently I work on don't have that issue (well
don't have address spaces either).

This work does require modifying almost all of the middle-end to support this.

Did it get this support worse with the addition of pointer plus, yes but at the
same time it did get easier to implement.

[Bug target/112837] [12/13/14 Regression] ICE: RTL check: expected elt 1 type 'i' or 'n', have 'e' (rtx plus) in ix86_elim_entry_set_got, at config/i386/i386.cc:8612 with -fcompare-elim -fpie -fprofil

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
The bug is there since r5-4566 I think, perhaps latent.

[Bug target/101017] ICE: Segmentation fault, convert_memory_address_addr_space_1 with vector_size(32) and target_clone arch=core-avx2/default

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed|2021-12-19 00:00:00 |2023-12-3

--- Comment #4 from Andrew Pinski  ---
Note the testcase which ICEs is now:
```
typedef int v32qi __attribute__((vector_size(32)));
__attribute__((target_clones("arch=core-avx2", "default"))) v32qi
foo_ashift_256() {}
```

Note the `int` there. Otherwise you get an error.

[Bug fortran/100988] Missed optimization: RESTRICT missing for optional arguments

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
Created attachment 56781
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56781&action=edit
Improved patch

When looking at testcases, it appeared that POINTER attributes of CLASS dummy
arguments were not properly handled.  This is fixed by the attached patch.

@Tobias: may I proceed with this PR, or is there something else I am missing?

[Bug middle-end/91354] verify_gimple triggers ICE after reporting 'invalid types in nop conversion' error for avr target

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

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

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

[Bug middle-end/89270] [11/12/13/14 regression] AVR ICE: verify_gimple failed

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||saaadhu at gcc dot gnu.org

--- Comment #11 from Andrew Pinski  ---
*** Bug 91354 has been marked as a duplicate of this bug. ***

[Bug c/112840] feature request: warn on incorrect tagged union value access

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

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

--- Comment #1 from Andrew Pinski  ---
This seems more like something for analyzier rather than a generic warning due
to it requires keeping track of the path where the access is located.

[Bug c/112840] feature request: warn on incorrect tagged union value access

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
   Severity|normal  |enhancement
   See Also||https://github.com/llvm/llv
   ||m-project/issues/74205

[Bug c/112840] New: feature request: warn on incorrect tagged union value access

[matheus.a.m.moreira at gmail dot com via Gcc-bugs]

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

Bug ID: 112840
   Summary: feature request: warn on incorrect tagged union value
access
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matheus.a.m.moreira at gmail dot com
  Target Milestone: ---

It would be useful if GCC could warn the programmer if the value of a tagged
union that doesn't correspond to its type tag is accessed.

Here's an example that illustrates the kind of mistake such a warning would
prevent:

#include 

enum T { I, F };
union U { int i; float f; };
struct S { enum T t; union U u; };

int main(void) {
struct S s = { .t = F, .u.f = 12345.67890f };
switch (s.t) {

case I:
printf("%d\n", s.u.i);
break;

case F:

// copied the above case
// but neglected to update the code

printf("%d\n", s.u.i);
break;
}
}

I understand that unions are typically used for type punning and that such
accesses are often intended by the programmer but compiler checks would still
be beneficial when that's not the case.

A compiler mechanism to establish a relationship between the union values and
their corresponding enum tags would be extremely useful. Something like this,
perhaps:

struct S {
enum T t;
union U {
int i   __attribute__((tag(t, I)));
float f __attribute__((tag(t, F)));
} u;
};

Then gcc would be able to warn when union values are accessed in a context
where their specified tags are not known to be the correct value:

switch (s.t) {

case I:

// i is accessed
// the tag of i is t
// t is supposed to equal I
// compiler knows t equals I because of switch case
// correct, no warning is emitted

printf("%d\n", s.u.i);
break;

case F:

// i is accessed
// the tag of i is t
// t is supposed to equal I
// compiler knows t equals F because of switch case
// incorrect, a warning is emitted

printf("%d\n", s.u.i);
break;
}

Such a feature would make C less error prone. I've also seen support for safe
tagged unions in newer languages like Zig. People have created C preprocessor
solutions to use tagged unions safely in C due to the lack of this safety:

https://github.com/Hirrolot/datatype99

Relevant clang issue:

https://github.com/llvm/llvm-project/issues/74205

[Bug tree-optimization/112831] [14 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in type_has_mode_precision_p, at tree.h:6767

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Confirmed, reduced slightly more:
```
int a, b;
char c;
void e() {
  for (; c; c++) {
int t;
b = 0;
for (; b <= 7; b++)
  ;
for (; (short)(t + b) + a; a++)
  ;
  }
}
```


0x1ace576 generic_simplify_CONVERT_EXPR(unsigned int, tree_code, tree_node*,
tree_node*)
???:0
0x1042d3f fold_unary_loc(unsigned int, tree_code, tree_node*, tree_node*)
???:0
0x10443cc fold_build1_loc(unsigned int, tree_code, tree_node*, tree_node*)
???:0
0x1529c9d analyze_scalar_evolution(loop*, tree_node*)
???:0
0x15e5575 estimate_numbers_of_iterations(loop*)
???:0
0x15e83b9 scev_probably_wraps_p(tree_node*, tree_node*, tree_node*, gimple*,
loop*, bool)
???:0

[Bug tree-optimization/112831] [14 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in type_has_mode_precision_p, at tree.h:6767

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Target||x86_64-linux-gnu
Summary|ICE: tree check: expected   |[14 Regression] ICE: tree
   |class 'type', have  |check: expected class
   |'exceptional' (error_mark)  |'type', have 'exceptional'
   |in  |(error_mark) in
   |type_has_mode_precision_p,  |type_has_mode_precision_p,
   |at tree.h:6767  |at tree.h:6767
   Target Milestone|--- |14.0

[Bug c++/102199] is_default_constructible incorrect for an inner type with NSDMI

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||luigighiron at gmail dot com

--- Comment #9 from Andrew Pinski  ---
*** Bug 112839 has been marked as a duplicate of this bug. ***

[Bug c++/112839] Unable to default initialize member variable in specific circumstances

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
This code is not valid C++ really due to the nested classes are not complete
until after the `}` of the outer class 

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

[Bug c++/112839] New: Unable to default initialize member variable in specific circumstances

[luigighiron at gmail dot com via Gcc-bugs]

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

Bug ID: 112839
   Summary: Unable to default initialize member variable in
specific circumstances
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: luigighiron at gmail dot com
  Target Milestone: ---

The following code is not accepted by GCC:

struct A {
struct B {
int C = 0;
};
A() = default;
A(int) {}
std::pair p;
};

The error message generated indicates that it was unable to find a constructor
to call in the constructor A(int).

Doing any of the following seems to remove the error:
1. Removing the constructor A()
2. Explicitly define the constructor A()
3. Defining a default constructor for B (that isn't defaulted)
4. Removing the default value from C
5. Initializing p when it is being declared, i.e. std::pair p{};
6. Defining B outside of the class
7. Using a non-default constructor in the member initializer list

Clang, MSVC, and old versions of GCC (version 8, version 5, and version 4)
accept this code.

[Bug c++/112838] Compiler is unable to show the exact error location when calling copy ctor for a non-copyable object

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Ahmad Nour from comment #2)
> 
> Thanks for confirmation.
> I tried with clang-12 -Wall -Wextra main.cpp, but I didn't get that
> hint/note. Am I missing something?

Oh I tried with -std=c++20 which provided that note.  Sorry about that. But it
might be the case that adding this for -std=c++17 might be hard ...

[Bug fortran/112828] Abort with malloc(): corrupted top size

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-12-03
 Status|UNCONFIRMED |NEW
   Keywords||wrong-code
 CC||anlauf at gcc dot gnu.org

--- Comment #6 from anlauf at gcc dot gnu.org ---
I get this crash with all gfortran versions (>= 7) on x86_64-pc-linux-gnu.
Sometimes optimization needs to be enabled to see this.

Replacing in reallocate the line

character(LEN(array)), allocatable :: array_new(:)

with the actual (constant) length fixes the issue, e.g.

character(LEN=64), allocatable :: array_new(:)

This may be a hint.

In my tests the stat variable only needs to be accessed by the line

if (PRESENT(stat))

it needs not be set explicitly.

Compiling with -fsanitize=address gives at runtime:

- when compiled with -O0:

==30489==ERROR: AddressSanitizer: requested allocation size 0x515f988
(0x515f9881000 after adjustments for alignment, red zones etc.) exceeds maximum
supported size of 0x100 (thread T0)
#0 0x1457e8eb4527 in malloc
../../../../gcc-trunk/libsanitizer/asan/asan_malloc_linux.cpp:69
...

- with -Og and higher:

==30533==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x50200071 at pc 0x152c5cbc8a79 bp 0x7fff0a124100 sp 0x7fff0a1238c0
WRITE of size 64 at 0x50200071 thread T0
...

(details depend on optimization level).

[Bug c++/112838] Compiler is unable to show the exact error location when calling copy ctor for a non-copyable object

[eng.ahmad.nour at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Ahmad Nour  ---
(In reply to Andrew Pinski from comment #1)
> Confirmed, I thought I had saw an issue filed that is very smilar to this.
> 
> 
> Note clang provides the context:
> 
> :5:7: note: in instantiation of member function
> 'std::vector>::vector' requested here
> 5 | class NonCopyable
>   |   ^
> :14:18: note: in implicit copy constructor for 'NonCopyable' first
> required here
>14 | NonCopyable b(a);
>   | ^

Thanks for confirmation.
I tried with clang-12 -Wall -Wextra main.cpp, but I didn't get that hint/note.
Am I missing something?

[Bug middle-end/112835] inverting the result of memcmp() produces inefficient code

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-12-03
 Target||x86_64-linux-gnu
   ||aarch64-linux-gnu
  Component|target  |middle-end
   Keywords||missed-optimization
 Ever confirmed|0   |1

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

aarch64 code generation is slightly better:
...
.L2:
mov w0, 1
eor w0, w0, 1
ret
...
mov w0, 0
eor w0, w0, 1
ret

But there is no reason for the mov followed by eor there, it should just be a
mov.

Note the gimple level is fine:
  _1 = __builtin_memcmp_eq (a_3(D), b_4(D), 12);
  _5 = _1 == 0;


Expansion does:
```
(jump_insn 14 13 33 4 (set (pc)
(if_then_else (ne (reg:CC 66 cc)
(const_int 0 [0]))
(label_ref 19)
(pc))) "/app/example.cpp":5:24 -1
 (int_list:REG_BR_PROB 708669604 (nil))
 -> 19)
(note 33 14 15 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
(insn 15 33 16 5 (set (reg:SI 92 [ _1 ])
(const_int 0 [0])) "/app/example.cpp":5:24 -1
 (nil))
(jump_insn 16 15 17 5 (set (pc)
(label_ref 21)) "/app/example.cpp":5:24 -1
 (nil)
 -> 21)
(barrier 17 16 18)
(barrier 18 17 19)
(code_label 19 18 34 6 2 (nil) [2 uses])
(note 34 19 20 6 [bb 6] NOTE_INSN_BASIC_BLOCK)
(insn 20 34 21 6 (set (reg:SI 92 [ _1 ])
(const_int 1 [0x1])) "/app/example.cpp":5:24 -1
 (nil))
(code_label 21 20 35 7 3 (nil) [1 uses])
(note 35 21 22 7 [bb 7] NOTE_INSN_BASIC_BLOCK)
(insn 22 35 23 7 (set (reg:CC 66 cc)
(compare:CC (reg:SI 92 [ _1 ])
(const_int 0 [0]))) "/app/example.cpp":5:33 discrim 1 -1
 (nil))
(insn 23 22 24 7 (set (reg:SI 102)
(eq:SI (reg:CC 66 cc)
(const_int 0 [0]))) "/app/example.cpp":5:33 discrim 1 -1
 (nil))

```

Seems like we could do a better job at expansion here ...

[Bug c++/112838] Compiler is unable to show the exact error location when calling copy ctor for a non-copyable object

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Confirmed, I thought I had saw an issue filed that is very smilar to this.


Note clang provides the context:

:5:7: note: in instantiation of member function
'std::vector>::vector' requested here
5 | class NonCopyable
  |   ^
:14:18: note: in implicit copy constructor for 'NonCopyable' first
required here
   14 | NonCopyable b(a);
  | ^

[Bug c++/112838] New: Compiler is unable to show the exact error location when calling copy ctor for a non-copyable object

[eng.ahmad.nour at gmail dot com via Gcc-bugs]

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

Bug ID: 112838
   Summary: Compiler is unable to show the exact error location
when calling copy ctor for a non-copyable object
   Product: gcc
   Version: 10.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eng.ahmad.nour at gmail dot com
  Target Milestone: ---

For this minimal example, the compiler never shows that the "real" cause of the
error is line #13 where the copy ctor is being called.

01#include 
02#include 
03
04class NonCopyable
05{
06private:
07std::vector> mElements;
08};
09
10int main()
11{
12  NonCopyable a;
13  NonCopyable b(a);
14  
15  return 0;
16}


I'm compiling using: 
g++-10 -Wall -Wextra main.cpp

And getting this:
In file included from /usr/include/c++/10/vector:66,
 from main.cpp:1:
/usr/include/c++/10/bits/stl_uninitialized.h: In instantiation of
‘_ForwardIterator std::uninitialized_copy(_InputIterator, _InputIterator,
_ForwardIterator) [with _InputIterator = __gnu_cxx::__normal_iterator*, std::vector > >; _ForwardIterator =
std::unique_ptr*]’:
/usr/include/c++/10/bits/stl_uninitialized.h:325:37:   required from
‘_ForwardIterator std::__uninitialized_copy_a(_InputIterator, _InputIterator,
_ForwardIterator, std::allocator<_Tp>&) [with _InputIterator =
__gnu_cxx::__normal_iterator*,
std::vector > >; _ForwardIterator = std::unique_ptr*;
_Tp = std::unique_ptr]’
/usr/include/c++/10/bits/stl_vector.h:558:31:   required from ‘std::vector<_Tp,
_Alloc>::vector(const std::vector<_Tp, _Alloc>&) [with _Tp =
std::unique_ptr; _Alloc = std::allocator >]’
main.cpp:4:7:   required from here
/usr/include/c++/10/bits/stl_uninitialized.h:137:72: error: static assertion
failed: result type must be constructible from value type of input range
  137 |   static_assert(is_constructible<_ValueType2,
decltype(*__first)>::value,
  |   
^

Compiler only shows that error is related to the class NonCopyable. But it was
a nightmare for me to try and find the exact line where copying was made in the
whole project.

[Bug target/112837] New: [12/13/14 Regression] ICE: RTL check: expected elt 1 type 'i' or 'n', have 'e' (rtx plus) in ix86_elim_entry_set_got, at config/i386/i386.cc:8612 with -fcompare-elim -fpie -fp

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 112837
   Summary: [12/13/14 Regression] ICE: RTL check: expected elt 1
type 'i' or 'n', have 'e' (rtx plus) in
ix86_elim_entry_set_got, at config/i386/i386.cc:8612
with -fcompare-elim -fpie -fprofile
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: i686-pc-linux-gnu

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

RTL checking might be needed.

Compiler output:
$ x86_64-pc-linux-gnu-gcc -m32 -fcompare-elim -fpie -fprofile testcase.c
during RTL pass: pro_and_epilogue
testcase.c: In function 'foo':
testcase.c:5:1: internal compiler error: RTL check: expected elt 1 type 'i' or
'n', have 'e' (rtx plus) in ix86_elim_entry_set_got, at
config/i386/i386.cc:8612
5 | }
  | ^
0x7fc743 rtl_check_failed_type2(rtx_def const*, int, int, int, char const*,
int, char const*)
/repo/gcc-trunk/gcc/rtl.cc:761
0x8b147a ix86_elim_entry_set_got
/repo/gcc-trunk/gcc/config/i386/i386.cc:8612
0x8b147a ix86_expand_prologue()
/repo/gcc-trunk/gcc/config/i386/i386.cc:9248
0x1dd305a gen_prologue()
/repo/gcc-trunk/gcc/config/i386/i386.md:18316
0x189bb85 target_gen_prologue
/repo/gcc-trunk/gcc/config/i386/i386.md:26218
0x111da87 make_prologue_seq
/repo/gcc-trunk/gcc/function.cc:5815
0x111dc23 thread_prologue_and_epilogue_insns()
/repo/gcc-trunk/gcc/function.cc:6050
0x111e592 rest_of_handle_thread_prologue_and_epilogue
/repo/gcc-trunk/gcc/function.cc:6553
0x111e592 execute
/repo/gcc-trunk/gcc/function.cc:6634
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

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

[Bug driver/112836] gcc fails when job control is used

[bruno at clisp dot org via Gcc-bugs]

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

--- Comment #1 from Bruno Haible  ---
Created attachment 56779
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56779&action=edit
proposed fix

Although the error is not easily reproducible, it is easy to analyze
and fix:

The piece of error message string "failed to get exit status" occurs
only in one place: in gcc/gcc.cc line 3462.

The only possible cause for the error message
"failed to get exit status: Interrupted system call" is therefore
that pex_get_status returned 0, with error code EINTR.

pex_get_status is defined in libiberty/pex-common.c, line 547.
It returns 0 only in line 555. We can infer that the function
pex_get_status_and_time had returned 0, with error code EINTR.

pex_get_status_and_time is defined in libiberty/pex-common.c, line 518.
It returns 0 only when ret gets to 0 in line 537. We can infer
that the obj->funcs->wait function must have returned non-zero,
with error code EINTR.

obj->funcs->wait is the method declared in libiberty/pex-common.h
line 128. On this platform, the relevant implementation is in
libiberty/pex-unix.c. The initialization happens in
libiberty/pex-unix.c line 338:
  return pex_init_common (flags, pname, tempbase, &funcs);
The obj->funcs->wait function function is thus pex_unix_wait.
It must have returned non-zero, with error code EINTR.

pex_unix_wait is defined in libiberty/pex-unix.c line 938.
Looking at its code, the function pex_wait must have returned a
negative value, with errno being set to EINTR.

pex_wait has 4 possible implementations, in
  libiberty/pex-unix.c line 128
  libiberty/pex-unix.c line 159
  libiberty/pex-unix.c line 170
  libiberty/pex-unix.c line 219
Since glibc has the 'wait4' function, the implementation that
matters is the one from libiberty/pex-unix.c line 128. But the
other implementations have the same problem: they don't handle
EINTR so far.

Find attached a proposed patch.

[Bug driver/112836] New: gcc fails when job control is used

[bruno at clisp dot org via Gcc-bugs]

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

Bug ID: 112836
   Summary: gcc fails when job control is used
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bruno at clisp dot org
  Target Milestone: ---

A compilation command with gcc failed, when I used bash's job control:


$ ~/build-32 -C
...
gcc -m32 -DHAVE_CONFIG_H -DEXEEXT=\"\" -DEXEEXT=\"\" -DNO_XMALLOC -DEXEEXT=\"\"
-I. -I../../gllib -I..  -DGNULIB_STRICT_CHECKING=1
-I/home/bruno/prefix32/include -Wall -fvisibility=hidden -g -O2 -MT
git-merge-changelog.o -MD -MP -MF $depbase.Tpo -c -o git-merge-changelog.o
../../gllib/git-merge-changelog.c &&\
mv -f $depbase.Tpo $depbase.Po
^Z
[1]+  Stopped ~/build-32 -C
bruno@localhost:~/testdir-all$ free
   totalusedfree  shared  buff/cache  
available
Mem: 2056072  119664 1773880 632  224808
1936408
Swap: 514072   0  514072
bruno@localhost:~/testdir-all$ fg 1
~/build-32 -C
gcc: fatal error: failed to get exit status: Interrupted system call
compilation terminated.
make[4]: *** [Makefile:11320: git-merge-changelog.o] Error 1
make[4]: Leaving directory '/home/bruno/testdir-all/build-32/gllib'
make[3]: *** [Makefile:11366: all-recursive] Error 1
make[3]: Leaving directory '/home/bruno/testdir-all/build-32/gllib'
make[2]: *** [Makefile:8407: all] Error 2
make[2]: Leaving directory '/home/bruno/testdir-all/build-32/gllib'
make[1]: *** [Makefile:3220: all-recursive] Error 1
make[1]: Leaving directory '/home/bruno/testdir-all/build-32'
make: *** [Makefile:3151: all] Error 2


The expected behaviour that after 'fg 1', stopped jobs continue to run
without failing.

This is on Linux/sparc64. Versions:
  - gcc (T2SDE) 13.2.1 20231124
  - Linux 6.6.3
  - glibc 2.38

[Bug middle-end/112406] [14 Regression] Several SPECCPU 2017 benchmarks fail with on internal compiler error: in expand_insn, at optabs.cc:8305 after g:01c18f58d37865d5f3bbe93e666183b54ec608c7

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

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

--- Comment #25 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r14-6096-g4c0dc30099d39ef6d1b6c8c81418c726aa660768
Author: Jakub Jelinek 
Date:   Sun Dec 3 20:03:27 2023 +0100

testsuite: Fix up gcc.target/aarch64/pr112406.c for modern C [PR112406]

On Fri, Nov 17, 2023 at 02:04:01PM +0100, Robin Dapp wrote:
> > Yes, your version is also OK.
>
> The attached was bootstrapped and regtested on aarch64, x86 and
> regtested on riscv.  Going to commit it later unless somebody objects.

Unfortunately the aarch64/pr112406.c was reduced too much and is rejected
since the switch to modern C patchset.

The following patch fixes that, I've verified the testcase
before/after the changes still ICEs in r14-5563 and doesn't with
r14-5564 and after the changes compiles fine with even latest trunk.
Everything admittedly with a cross-compiler, but that shouldn't change
anything.

Note, one of the modern C changes is that at least when people use
cvise/creduce/delta scripts which ensure no further errors are introduced
during the reduction then expected originally such reductions will not
appear anymore.

2023-12-03  Jakub Jelinek  

PR middle-end/112406
* gcc.target/aarch64/pr112406.c (MagickPixelPacket): Add missing
semicolon.
(GetImageChannelMoments_image): Avoid using implicit int.
(SetMagickPixelPacket): Use void return type instead of implicit
int.
(GetImageChannelMoments): Likewise.  Use __builtin_atan instead of
atan.

[Bug fortran/112828] Abort with malloc(): corrupted top size

[townsend at astro dot wisc.edu via Gcc-bugs]

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

--- Comment #5 from Rich Townsend  ---
One more data point: I tried with gfortran 13.2.0 on Linux/Intel and get the
same result as for 13.1.0.

[Bug target/96127] ICE in extract_insn, at recog.c:2294

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

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

[Bug tree-optimization/112835] New: inverting the result of memcmp() produces inefficient code

[gnu at kosak dot com via Gcc-bugs]

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

Bug ID: 112835
   Summary: inverting the result of memcmp() produces inefficient
code
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gnu at kosak dot com
  Target Milestone: ---

Created attachment 56778
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56778&action=edit
the .ii file from --save-temps

Hello,

The assembly output of this program does a suboptimal thing in two different
places. It moves a constant (0 or 1) into %eax and then does a `testl` and
`sete` to invert that constant. This would be reasonable code for `!x` when x
is a runtime `int` value. However, when x is a constant, it would be simpler to
emit a single load instruction.

```
#include 

bool calc(const void *a, const void *b) {
return !std::memcmp(a, b, 12);
}
```

Relevant assembly on x86_64, invoked with g++ -S -O3 test.cc

```
_Z4calcPKvS0_:
.LFB31:
.cfi_startproc
endbr64
movq(%rsi), %rax
cmpq%rax, (%rdi)
je  .L5
.L2:
movl$1, %eax
testl   %eax, %eax
sete%al
ret
.p2align 4,,10
.p2align 3
.L5:
movl8(%rsi), %eax
cmpl%eax, 8(%rdi)
jne .L2
xorl%eax, %eax
testl   %eax, %eax
sete%al
ret
.cfi_endproc

```

In the above, the code at label .L2 (movl/testl/sete) would be better off as
the single instruction "xorl %eax,%eax" and likewise the code at the latter
part of .L5 (xorl/testl/sete) would be better off as the single instruction
"movl $1, %eax". You can see the compiler doing this, though with inverted
logic, if you simply delete the ! in the source code.

Apologies if I've posted this to the wrong component.

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

[Bug fortran/112834] New: Class array function selector causes chain of syntax and other spurious errors

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

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

Bug ID: 112834
   Summary: Class array function selector causes chain of syntax
and other spurious errors
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pault at gcc dot gnu.org
  Target Milestone: ---

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

The attached produces:

[pault@pc30 pr87477]$ rm ./a.out;~/grun/bin/gfortran test.f90
-fdump-tree-original -g;./a.out
test.f90:24:15:

   24 |   if (var1(2)%i .ne. test_array(2)%i) stop 9
  |   1
Error: Syntax error in IF-expression at (1)
test.f90:31:16:

   31 |   if (x(1)%i .ne. test_array(1)%i) stop 11
  |1
Error: Syntax error in IF-expression at (1)
test.f90:39:52:

   39 | print *, "yes, size of 'y' is ", size(y), y(1)
  |1
Error: Syntax error in PRINT statement at (1)
test.f90:44:26:

   44 | end module class_selectors
  |  1
Error: Pointer assignment target in initialization expression does not have the
TARGET attribute at (1)
test.f90:46:7:

   46 |   use class_selectors
  |   1
Fatal Error: Cannot open module file ‘class_selectors.mod’ for reading at (1):
No such file or directory
compilation terminated

Paul

[Bug tree-optimization/112831] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in type_has_mode_precision_p, at tree.h:6767

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

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

--- Comment #2 from Florian Weimer  ---
Created attachment 56776
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56776&action=edit
valgrind output

[Bug tree-optimization/112831] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in type_has_mode_precision_p, at tree.h:6767

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

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

Florian Weimer  changed:

   What|Removed |Added

 CC|fweimer at redhat dot com  |fw at gcc dot gnu.org

--- Comment #1 from Florian Weimer  ---
For me, it ICEs on the previous commit as well.

Could it be a latent bug? I'm going to attach some valgrind output.

[Bug c/112833] Missing warnings on restrict misuse

[alx at kernel dot org via Gcc-bugs]

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

--- Comment #1 from Alejandro Colomar  ---
Oops, in the reproducer from above, I should only expect a warning at call
site.  The definition is correct, since all parameters are restrict, so it's
free to copy one to the other.

Here's a reproducer where the call is fine, but the definition is wrong, and
the compiler doesn't realize:


$ cat restrict.c 
#include 

long bogus2_strtol(const char *s, char **restrict ep, int base);

int
main(void)
{
char buf[3] = "foo";
char *p = buf;

bogus2_strtol(p, &p, -42);
}

long
bogus2_strtol(const char *s, char **restrict ep, int base)
{
memcpy(*ep, s, 1);
return base;
}
$ gcc -Wall -Wextra restrict.c -fanalyzer
$ gcc -Wall -Wextra restrict.c -fanalyzer -O3

[Bug tree-optimization/112807] ICE: SIGSEGV in contains_struct_check (tree.h:3747) with _BitInt() at -O1 and above

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/112807] ICE: SIGSEGV in contains_struct_check (tree.h:3747) with _BitInt() at -O1 and above

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

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

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

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

commit r14-6095-geef6aea3052b4b8a60df211015dafcb4573d19fb
Author: Jakub Jelinek 
Date:   Sun Dec 3 17:54:03 2023 +0100

lower-bitint: Fix up lower_addsub_overflow [PR112807]

lower_addsub_overflow uses handle_cast or handle_operand to extract current
limb from the operands.  Both of those functions heavily assume that they
return a large or huge BITINT_TYPE.  The problem in the testcase is that
this is violated.  Normally, lower_addsub_overflow isn't even called if
neither the return's type element type nor any of the operand is large/huge
BITINT_TYPE (on x86_64 129+ bits), for middle BITINT_TYPE (on x86_64 65-128
bits) some other code casts such operands to {,unsigned }__int128.
In the testcase the result is complex unsigned, so small, but one of the
arguments is _BitInt(256), so lower_addsub_overflow is called.  But
range_for_prec asks the ranger for ranges of the operands and in this
case the first argument has [0, 0x] range and second [-2, 1], so
unsigned 32-bit and signed 2-bit, and in such case the code for
handle_operand/handle_cast purposes would use the _BitInt(256) type for the
first operand (ok), but because prec3 aka maximum of result precision and
the VRP computes ranges of the arguments is 32, use cast to 32-bit
BITINT_TYPE, which is why it didn't work correctly.
The following patch ensures that in such cases we use handle_cast to the
type of the other argument.

Perhaps incrementally, we could try to optimize this in an earlier phase,
see that while the .{ADD,SUB}_OVERFLOW has large/huge _BitInt argument, as
ranger says it fits into a smaller type, add a cast of the larger argument
to the smaller precision type in which it fits.  Either in
gimple_lower_bitint, or match.pd.  An argument for the latter is that e.g.
complex unsigned .ADD_OVERFLOW (unsigned_long_long_arg, unsigned_arg)
where ranger says unsigned_long_long_arg fits into unsigned 32-bit could
be also more efficient as
.ADD_OVERFLOW ((unsigned) unsigned_long_long_arg, unsigned_arg)

2023-12-03  Jakub Jelinek  

PR middle-end/112807
* gimple-lower-bitint.cc
(bitint_large_huge::lower_addsub_overflow):
When choosing type0 and type1 types, if prec3 has small/middle
bitint
kind, use maximum of type0 and type1's precision instead of prec3.

* gcc.dg/bitint-46.c: New test.

[Bug fortran/112828] Abort with malloc(): corrupted top size

[townsend at astro dot wisc.edu via Gcc-bugs]

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

--- Comment #4 from Rich Townsend  ---
Another data point for MacOS/Intel (10.13.6, High Sierra) -- with the character
vars set to length 64, the crash is as follows:

test(3287,0x7fff8fc11380) malloc: *** error for object 0x7fe44cc03b58:
incorrect checksum for freed object - object was probably modified after being
freed.
*** set a breakpoint in malloc_error_break to debug

Program received signal SIGABRT: Process abort signal.

Backtrace for this error:
#0  0x105c19a5e
#1  0x105c18c1d
#2  0x7fff57818f59
Abort trap: 6

Again, commenting out the allocate(..., STAT=stat) line makes the problem go
away. Reducing the length to <=24 also resolves the problem.

[Bug c/112833] New: Missing warnings on restrict misuse

[alx at kernel dot org via Gcc-bugs]

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

Bug ID: 112833
   Summary: Missing warnings on restrict misuse
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alx at kernel dot org
  Target Milestone: ---

Reproducer:


$ cat restrict.c 
long bogus_strtol(const char *restrict s, char **restrict ep, int base);

int
main(void)
{
char buf[3] = "foo";
char *p = buf;

bogus_strtol(p, &p, -42);
}

long
bogus_strtol(const char *restrict s, char **restrict ep, int base)
{
**ep = *s;
return base;
}
$ gcc -Wall -Wextra restrict.c -fanalyzer
$ gcc -Wall -Wextra restrict.c -fanalyzer -O3


I'd expect two -Wrestrict warnings, one at call site, and another at `**ep =
*s;`.

BTW, of course, I'd also expect a warning at calls to strtol(3), which I
consider has a wrong use of restrict in the prototype.

Original report at gcc-help@:

[Bug libstdc++/112832] New: [std::format] Broken non-SFINAE-friendly `set_debug_format()` for `const char *` formatter

[iamsupermouse at mail dot ru via Gcc-bugs]

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

Bug ID: 112832
   Summary: [std::format] Broken non-SFINAE-friendly
`set_debug_format()` for `const char *` formatter
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iamsupermouse at mail dot ru
  Target Milestone: ---

GCC doesn't seem to implement `{:?}` debug format for strings yet.

Yet for some reason `std::formatter` has a `set_debug_format()`
function, which causes a hard error when used (isn't SFINAE-friendly).

`set_debug_format()` should be SFINAE-friendly, to allow the user to call it
conditionally when available.

Here's a code sample that fails to compile because of it:
https://gcc.godbolt.org/z/PbfnsxE9n (still fails in GCC 14 trunk)

#include 
#include 
#include 
#include 
#include 

template 
struct PreferDebugFormat
{
T ⌖
constexpr PreferDebugFormat(T &target) : target(target) {}
};
template 
PreferDebugFormat(T &&) -> PreferDebugFormat &>;

template 
struct std::formatter, CharT> :
std::formatter, CharT>
{
using base = std::formatter, CharT>;

constexpr decltype(auto) parse(std::basic_format_parse_context
&parse_ctx)
{
if constexpr (requires{this->set_debug_format();})
this->set_debug_format();
return base::parse(parse_ctx);
}

template 
constexpr decltype(auto) format(const PreferDebugFormat &arg,
std::basic_format_context &format_ctx) const
{
return base::format(arg.target, format_ctx);
}
};

template 
std::string ToDebugString(const T &value)
{
return std::format("{}", PreferDebugFormat(value));
}

int main()
{
std::cout << ToDebugString("foo\nbar") << '\n'; // hard error == BUG
std::cout << ToDebugString(std::string_view("foo\nbar")) << '\n'; //
ok, no debug format yet
std::cout << ToDebugString(42) << '\n'; // ok, no debug format
}

[Bug fortran/112828] Abort with malloc(): corrupted top size

[townsend at astro dot wisc.edu via Gcc-bugs]

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

--- Comment #3 from Rich Townsend  ---
I can get the MWE to barf on MacOS/Arm (Sonoma 14.1.1), gfortran 13.1.0, by
changing the length of the character vars in the main program from 64 to 16.
The error is now:

In file 'test.f90', around line 49: Error allocating 211106259502048 bytes:
Cannot allocate memory

Error termination. Backtrace:
#0  0x102d77617
#1  0x102d781b7
#2  0x102d78457
#3  0x10275f5bb
#4  0x10275fc37
#5  0x10275f84f
#6  0x10275fc87

Once again, commenting out the allocate w/ STAT line makes the problem go away.
It seems as though having two allocate invocations (one with stat, one without)
is causing some kind of memory corruption.

[Bug fortran/112828] Abort with malloc(): corrupted top size

[townsend at astro dot wisc.edu via Gcc-bugs]

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

--- Comment #2 from Rich Townsend  ---
The problem manifests with gfortran 13.1.0 on Linux/x86_64. I've run into
similar looking problems on MacOS/Arm, but the MWE I provided seems to work OK
on Arm.

[Bug tree-optimization/112831] New: ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in type_has_mode_precision_p, at tree.h:6767

[shaohua.li at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 112831
   Summary: ICE: tree check: expected class 'type', have
'exceptional' (error_mark) in
type_has_mode_precision_p, at tree.h:6767
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shaohua.li at inf dot ethz.ch
CC: fweimer at redhat dot com
  Target Milestone: ---

gcc at -Os crashes on the test case.

Bisected to r14-6034-g4ee2aca7ca0

Compiler explorer: https://godbolt.org/z/6We5qxMbr

% cat a.c
int a, b;
char c;
int d() {}
void e() {
  for (; c; c++) {
b = 0;
for (; b <= 7; b++)
  ;
for (; (short)(d() + b) + a; a++)
  ;
  }
}
int main() {}
%
% gcc -Os a.c
during GIMPLE pass: sccp
a.c: In function ‘e’:
a.c:4:6: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in type_has_mode_precision_p, at tree.h:6767
4 | void e() {
  |  ^
0x7f47566c3082 __libc_start_main
../csu/libc-start.c:308
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
%

[Bug middle-end/112824] Stack spills and vector splitting with vector builtins

[elrodc at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Chris Elrod  ---
> I thought I hit the important cases, but my non-minimal example still gets 
> unnecessary register splits and stack spills, so maybe I missed places, or 
> perhaps there's another issue.

Adding the unroll pragma to the `Vector`'s operator + and *:

template
[[gnu::always_inline]] constexpr auto operator+(Vector x, Vector y)
-> Vector {
Vector z;
#pragma GCC unroll 16
for (ptrdiff_t n = 0; n < Vector::L; ++n) z.data[n] = x.data[n] +
y.data[n];
return z;
}
template
[[gnu::always_inline]] constexpr auto operator*(Vector x, Vector y)
-> Vector {
Vector z;
#pragma GCC unroll 16
for (ptrdiff_t n = 0; n < Vector::L; ++n) z.data[n] = x.data[n] *
y.data[n];
return z;
}
template
[[gnu::always_inline]] constexpr auto operator+(T x, Vector y) ->
Vector {
Vector z;
#pragma GCC unroll 16
for (ptrdiff_t n = 0; n < Vector::L; ++n) z.data[n] = x + y.data[n];
return z;
}
template
[[gnu::always_inline]] constexpr auto operator*(T x, Vector y) ->
Vector {
Vector z;
#pragma GCC unroll 16
for (ptrdiff_t n = 0; n < Vector::L; ++n) z.data[n] = x * y.data[n];
return z;
}


does not improve code generation (still get the same problem), so that's a
reproducer for such an issue.

[Bug fortran/112828] Abort with malloc(): corrupted top size

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

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu.org

--- Comment #1 from Francois-Xavier Coudert  ---
I cannot reproduce this on macOS with gfortran 13.2.0
Could you give more details on what compiler version, what target, etc?

[Bug middle-end/112824] Stack spills and vector splitting with vector builtins

[elrodc at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Chris Elrod  ---
https://godbolt.org/z/3648aMTz8

Perhaps a simpler diff is that you can reproduce by uncommenting the pragma,
but codegen becomes good with it.

template
constexpr auto operator*(OuterDualUA2 a, OuterDualUA2
b)->OuterDualUA2{  
  //return
{a.value*b.value,a.value*b.p[0]+b.value*a.p[0],a.value*b.p[1]+b.value*a.p[1]}; 
  OuterDualUA2 c;
  c.value = a.value*b.value;
#pragma GCC unroll 16
  for (ptrdiff_t i = 0; i < 2; ++i)
c.p[i] = a.value*b.p[i] + b.value*a.p[i];
  //c.p[0] = a.value*b.p[0] + b.value*a.p[0];
  //c.p[1] = a.value*b.p[1] + b.value*a.p[1];
  return c;
}


It's not great to have to add pragmas everywhere to my actual codebase. I
thought I hit the important cases, but my non-minimal example still gets
unnecessary register splits and stack spills, so maybe I missed places, or
perhaps there's another issue.

Given that GCC unrolls the above code even without the pragma, it seems like a
definite bug that the pragma is needed for the resulting code generation to
actually be good.
Not knowing the compiler pipeline, my naive guess is that the pragma causes
earlier unrolling than whatever optimization pass does it sans pragma, and that
some important analysis/optimization gets run between those two times.

[Bug tree-optimization/112788] [14 regression] ICEs in fold_range, at range-op.cc:206 after r14-5972-gea19de921b01a6

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

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

Thomas Schwinge  changed:

   What|Removed |Added

   Last reconfirmed|2023-12-01 00:00:00 |2023-12-3
 CC||tschwinge at gcc dot gnu.org
   Keywords||build

--- Comment #3 from Thomas Schwinge  ---
I'm actually running into this ICE already during powerpc64le-linux-gnu build:

libtool: compile:  [...]/build-gcc/./gcc/xgcc [...] -fchecking=1 [...]
-mabi=ibmlongdouble -mno-gnu-attribute -fcx-fortran-rules -ffunction-sections
-fdata-sections -mabi=ieeelongdouble -g -O2 -MT norm2_r17.lo -MD -MP -MF
.deps/norm2_r17.Tpo -c [...]/source-gcc/libgfortran/generated/norm2_r17.c 
-fPIC -DPIC -o .libs/norm2_r17.o
cc1: warning: Using IEEE extended precision ‘long double’ [-Wpsabi]
during GIMPLE pass: evrp
[...]/source-gcc/libgfortran/generated/norm2_r17.c: In function
‘norm2_r17’:
[...]/source-gcc/libgfortran/generated/norm2_r17.c:214:1: internal compiler
error: in fold_range, at range-op.cc:206
  214 | }
  | ^
0x10bf213b range_op_handler::fold_range(vrange&, tree_node*, vrange const&,
vrange const&, relation_trio) const
[...]/source-gcc/gcc/range-op.cc:206
0x11d8790b fold_using_range::range_of_range_op(vrange&,
gimple_range_op_handler&, fur_source&)
[...]/source-gcc/gcc/gimple-range-fold.cc:702
0x11d89873 fold_using_range::fold_stmt(vrange&, gimple*, fur_source&,
tree_node*)
[...]/source-gcc/gcc/gimple-range-fold.cc:602
0x11d89eaf fold_range(vrange&, gimple*, range_query*)
[...]/source-gcc/gcc/gimple-range-fold.cc:322
0x11d7c6e3 ranger_cache::get_global_range(vrange&, tree_node*, bool&)
[...]/source-gcc/gcc/gimple-range-cache.cc:1052
0x11d69577 gimple_ranger::range_of_stmt(vrange&, gimple*, tree_node*)
[...]/source-gcc/gcc/gimple-range.cc:311
0x11221b93 range_query::value_of_stmt(gimple*, tree_node*)
[...]/source-gcc/gcc/value-query.cc:113
0x111c6ae7 rvrp_folder::value_of_stmt(gimple*, tree_node*)
[...]/source-gcc/gcc/tree-vrp.cc:999
0x11044fbb
substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
[...]/source-gcc/gcc/tree-ssa-propagate.cc:820
0x11ce966b dom_walker::walk(basic_block_def*)
[...]/source-gcc/gcc/domwalk.cc:311
0x110436f3
substitute_and_fold_engine::substitute_and_fold(basic_block_def*)
[...]/source-gcc/gcc/tree-ssa-propagate.cc:999
0x111c1877 execute_ranger_vrp(function*, bool, bool)
[...]/source-gcc/gcc/tree-vrp.cc:1064
0x111c6a6b execute
[...]/source-gcc/gcc/tree-vrp.cc:1307
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
make[3]: *** [norm2_r17.lo] Error 1

[Bug middle-end/112830] internal compiler error: in convert_memory_address_addr_space_1, at explow.cc:302

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Target||avr
   Keywords||addr-space,
   ||ice-on-valid-code

--- Comment #1 from Georg-Johann Lay  ---
In explow.cc, we have:

rtx convert_memory_address_addr_space_1 (...)
{
#ifndef POINTERS_EXTEND_UNSIGNED
  gcc_assert (GET_MODE (x) == to_mode || GET_MODE (x) == VOIDmode); // line 302
  return x;
#else /* defined(POINTERS_EXTEND_UNSIGNED) */

so it seems the backend has to define POINTERS_EXTEND_UNSIGNED, which it
currently doesn't.  However, the documentation of PEU reads:

> Macro: POINTERS_EXTEND_UNSIGNED
>   A C expression that determines how pointers should be extended from
>   ptr_mode to either Pmode or word_mode. It is greater than zero if
>   pointers should be zero-extended, zero if they should be sign-extended,
>   and negative if some other sort of conversion is needed. In the last case,
>   the extension is done by the target’s ptr_extend instruction.
>   You need not define this macro if the ptr_mode, Pmode and word_mode are
>   all the same width. 

The avr backend has:

Pmode = word_mode = HImode (16 bits), mode for ADDR_SPACE_GENERIC

PSImode = 24 bits, mode for ADDR_SPACE_MEMX, aka. __memx

So it appear the middle-end wants to "extend" a pointer from 24-bit PSImode to
16-bit Pmode, which makes no sense.  Apart from that, the code does not require
any pointer adjustments.

One guess is that the middle-end tries to expand the memcpy, because insn
cpymemhi only support CONST_INT lengths, and gets somethig wrong about address
spaces.

The backend defines TARGET_ADDR_SPACE_CONVERT, and
TARGET_ADDR_SPACE_ADDRESS_MODE is the same like TARGET_ADDR_SPACE_POINTER_MODE
for all address spaces.

[Bug middle-end/112830] New: internal compiler error: in convert_memory_address_addr_space_1, at explow.cc:302

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

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

Bug ID: 112830
   Summary: internal compiler error: in
convert_memory_address_addr_space_1, at explow.cc:302
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

Compile the following C test case with avr-gcc -S:

typedef __SIZE_TYPE__ size_t;

void copy_n (void *vdst, const __memx void *vsrc, size_t n)
{
typedef struct { char a[n]; } T;
T *dst = (T*) vdst;
const __memx T *src = (const __memx T*) vsrc;
*dst = *src;
}

during RTL pass: expand
ice.c: In function 'copy_n':
ce.c:20:10: internal compiler error: in convert_memory_address_addr_space_1, at
explow.cc:302
   20 | *dst = *src;
  | ~^~

It occurs with at least v5.4 to current master (future v14).

Configured with: ../../source/gcc-master/configure --target=avr --disable-nls
--with-dwarf2 --with-gnu-as --with-gnu-ld --disable-shared
--enable-checking=release --enable-languages=c,c++

[Bug c++/112789] Missing clang __builtin_ctzs for short

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

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

--- Comment #14 from Jakub Jelinek  ---
One thing against adding these builtins (especially when we have a type-generic
builtin which can handle all types, not just some of them) is that clang has
added them completely unorthogonally.
GCC has __builtin_{ctz,clz,clrsb,ffs,popcount,parity}{,l,ll,imax,g} (the last
one in GCC 14 only), while clang has
__builtin_{ctz,clz,clrsb,ffs,popcount,parity}{,l,ll} and then just
__builtin_c{l,t}zs for unsigned short extra, but none of the other 4 similar
builtins, nor any builtin for unsigned char, etc.  Why is unsigned short that
much more important than unsigned char or unsigned __int128 or all the unsigned
_BitInt types?

[Bug fortran/89645] No IMPLICIT type error with: ASSOCIATE( X => function() )

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

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #4 from Paul Thomas  ---
Created attachment 56775
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56775&action=edit
Deadend fix for this PR

I got as far as I could with this fix up method. The testcase below fails and
so I am going to set aside this approach and tackle what I should have done in
the first place: two step parsing of contained procedures.

The patch contains a fix for class array function selectors that do not work,
even if the selector function is parsed first. I will make a new PR for this
and will break out the patch for it and post it to the list.

Paul

module m
  implicit none
  type t
integer :: i = 0
  end type t
  integer :: i = 0
  type(t), parameter :: test_array (2) = [t(42),t(84)], &
test_scalar = t(99)
end module m
module class_selectors
  use m
  implicit none
  private
  public foo2
contains

  subroutine foo2()
associate (var1 => bar3())
  if (any (var1%i .ne. test_array%i)) stop 8
  if (var1(2)%i .ne. test_array(2)%i) stop 9
!  associate (var3 => var1%i)  ! This still fails
! print *, "yipee"
!  end associate
  select type (x => var1)
type is (t)
  if (any (x%i .ne. test_array%i)) stop 10
  if (x(1)%i .ne. test_array(1)%i) stop 11
class default
  stop 12
  end select
end associate

select type (y => bar3 ())
  type is (t)
print *, "yes, size of 'y' is ", size(y), y(1)
  class default
print *, "no"
end select
  end subroutine foo2

! Since these functions are parsed after 'foo', the symbols were not available
! for the selectors and the fixup, tested here, was necessary.

  function bar3() result(res)
class(t), allocatable :: res(:)
allocate (res, source = test_array)
  end
end module class_selectors

  use class_selectors
  call foo2
end

[Bug tree-optimization/112827] [14 Regression] ICE on valid code at -O1 on x86_64-linux-gnu: Segmentation fault

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

--- Comment #2 from Zhendong Su  ---
Another test that reproduces at -O1 and above.

[520] % gcctk -O3 small.c
during GIMPLE pass: sccp
small.c: In function ‘main’:
small.c:4:5: internal compiler error: Segmentation fault
4 | int main() {
  | ^~~~
0x105e613 crash_signal
../../gcc-trunk/gcc/toplev.cc:316
0x1149882 gimple_bb(gimple const*)
../../gcc-trunk/gcc/gimple.h:1908
0x1149882 instantiate_scev_name
../../gcc-trunk/gcc/tree-scalar-evolution.cc:2263
0x1149882 instantiate_scev_r
../../gcc-trunk/gcc/tree-scalar-evolution.cc:2637
0x114977d instantiate_scev_poly
../../gcc-trunk/gcc/tree-scalar-evolution.cc:2410
0x114977d instantiate_scev_r
../../gcc-trunk/gcc/tree-scalar-evolution.cc:2642
0x114a1de instantiate_scev(edge_def*, loop*, tree_node*)
../../gcc-trunk/gcc/tree-scalar-evolution.cc:2719
0x12027c5 instantiate_parameters(loop*, tree_node*)
../../gcc-trunk/gcc/tree-scalar-evolution.h:64
0x12027c5 idx_infer_loop_bounds
../../gcc-trunk/gcc/tree-ssa-loop-niter.cc:4154
0x1217343 for_each_index(tree_node**, bool (*)(tree_node*, tree_node**, void*),
void*)
../../gcc-trunk/gcc/tree-ssa-loop.cc:571
0x11ffa7d infer_loop_bounds_from_ref
../../gcc-trunk/gcc/tree-ssa-loop-niter.cc:4230
0x11ffa7d infer_loop_bounds_from_array
../../gcc-trunk/gcc/tree-ssa-loop-niter.cc:4251
0x11ffa7d infer_loop_bounds_from_undefined
../../gcc-trunk/gcc/tree-ssa-loop-niter.cc:4408
0x11ffa7d estimate_numbers_of_iterations(loop*)
../../gcc-trunk/gcc/tree-ssa-loop-niter.cc:4866
0x1201caf loop_exits_before_overflow
../../gcc-trunk/gcc/tree-ssa-loop-niter.cc:5253
0x1201caf scev_probably_wraps_p(tree_node*, tree_node*, tree_node*, gimple*,
loop*, bool)
../../gcc-trunk/gcc/tree-ssa-loop-niter.cc:5505
0x1201caf scev_probably_wraps_p(tree_node*, tree_node*, tree_node*, gimple*,
loop*, bool)
../../gcc-trunk/gcc/tree-ssa-loop-niter.cc:5463
0x2033067 convert_affine_scev(loop*, tree_node*, tree_node**, tree_node**,
gimple*, bool, tree_node*)
../../gcc-trunk/gcc/tree-chrec.cc:1425
0x2032abe chrec_convert_1
../../gcc-trunk/gcc/tree-chrec.cc:1483
0x114a923 scev_dfs::follow_ssa_edge_expr(gimple*, tree_node*, tree_node**, int)
../../gcc-trunk/gcc/tree-scalar-evolution.cc:1238
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
[521] % 
[521] % cat small.c
short a, b[1], f;
char c, g;
int d, e;
int main() {
  for (; f; f++) {
for (d = 0; d < 2; d++)
  ;
if (a)
  for (g = 0; g < 2; g++)
for (c = 0; c < 2; c += b[d+g])
  ;
for (; e; e++)
  ;
  }
  return 0;
}

[Bug fortran/85836] [meta-bug] Fortran 2018 support

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

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

--- Comment #7 from Paul Thomas  ---
Created attachment 56774
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56774&action=edit
Features 6.x

[Bug fortran/85836] [meta-bug] Fortran 2018 support

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

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

--- Comment #6 from Paul Thomas  ---
Created attachment 56773
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56773&action=edit
Feature 5.12

[Bug fortran/85836] [meta-bug] Fortran 2018 support

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

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

--- Comment #5 from Paul Thomas  ---
Created attachment 56772
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56772&action=edit
Features 4.x

[Bug fortran/85836] [meta-bug] Fortran 2018 support

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

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

--- Comment #4 from Paul Thomas  ---
Created attachment 56771
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56771&action=edit
Features 2.x

[Bug fortran/85836] [meta-bug] Fortran 2018 support

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

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

--- Comment #3 from Paul Thomas  ---
Created attachment 56770
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56770&action=edit
Features 1.x

[Bug fortran/85836] [meta-bug] Fortran 2018 support

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

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #2 from Paul Thomas  ---
Created attachment 56769
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56769&action=edit
Chivers and Sleightholme compliance table mostly completed

The as yet incomplete entries concern coarray features of which I have no
expertise at all. Likewise, other coarray feature have been filled out by
inspection of the gfortran source code.

"Testcases" for sections 1.x to 6.x follow.

Paul

[Bug c/112826] gcc rejects the valid code and reports undefined reference

[jwzeng at nuaa dot edu.cn via Gcc-bugs]

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

--- Comment #4 from Junwei Zeng  ---
Thank you for your explanation.