[Bug target/108654] Incorrect codegen of RVV GCC

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

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

JuzheZhong  changed:

   What|Removed |Added

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

--- Comment #4 from JuzheZhong  ---
Fixed

[Bug target/108654] Incorrect codegen of RVV GCC

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

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

--- Comment #3 from JuzheZhong  ---
FIXED

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

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

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

--- Comment #8 from Hans-Peter Nilsson  ---
(In reply to David Malcolm from comment #7)
> The invalid UTF-8 in the patch seems to have broken the server-side script:

Maybe the not-really-utf8 files need to be marked in some way in the git repo
to be safely handled for future checkout and updates, including the problematic
scripting?  However, reading gitattributes(5) it's not obvious how.

[Bug target/109279] RISC-V: complex constants synthesized should be improved

[vineet.gupta at linux dot dev via Gcc-bugs]

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

--- Comment #13 from Vineet Gupta  ---
Ok it seems I missed _some_ improvement with prev change, although not ideal
still.

With 2e886eef7f2b

li  a0,0x0101_
addia0,a0,0x0101
sllia0,a0,16
addia0,a0,0x0101
sllia0,a0,16
addia0,a0,0x0101
ret

Allow can_create_pseudo() in splitter

li  a0,0x0101_
addia5,a5,0x0101
mv  a0,a5
sllia5,a5,32
add a0,a5,a0
ret

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

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #7 from David Malcolm  ---
Should be fixed on trunk by r13-6861-gd495ea2b232f3e:

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d495ea2b232f3eb50155d7c7362c09a744766746

https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff_plain;h=d495ea2b232f3eb50155d7c7362c09a744766746

The invalid UTF-8 in the patch seems to have broken the server-side script:

Enumerating objects: 51, done.
Counting objects: 100% (51/51), done.
Delta compression using up to 64 threads
Compressing objects: 100% (29/29), done.
Writing objects: 100% (29/29), 7.74 KiB | 1.29 MiB/s, done.
Total 29 (delta 22), reused 0 (delta 0), pack-reused 0
remote: Traceback (most recent call last):
remote:   File "hooks/post_receive.py", line 118, in 
remote: post_receive(refs_data, args.submitter_email)
remote:   File "hooks/post_receive.py", line 65, in post_receive
remote: submitter_email)
remote:   File "hooks/post_receive.py", line 47, in post_receive_one
remote: update.send_email_notifications()
remote:   File
"/sourceware1/projects/src-home/git-hooks/hooks/updates/__init__.py", line 189,
in send_email_notifications
remote: self.__email_new_commits()
remote:   File
"/sourceware1/projects/src-home/git-hooks/hooks/updates/__init__.py", line
1031, in __email_new_commits
remote: commit, self.get_standard_commit_email(commit))
remote:   File
"/sourceware1/projects/src-home/git-hooks/hooks/updates/__init__.py", line
1011, in __send_commit_email
remote: default_diff=email.diff)
remote:   File
"/sourceware1/projects/src-home/git-hooks/hooks/updates/__init__.py", line 946,
in __maybe_get_email_custom_contents
remote: hook_input=json.dumps(hooks_data),
remote:   File "/usr/lib64/python2.7/json/__init__.py", line 244, in dumps
remote: return _default_encoder.encode(obj)
remote:   File "/usr/lib64/python2.7/json/encoder.py", line 207, in encode
remote: chunks = self.iterencode(o, _one_shot=True)
remote:   File "/usr/lib64/python2.7/json/encoder.py", line 270, in iterencode
remote: return _iterencode(o, 0)
remote: UnicodeDecodeError: 'utf8' codec can't decode byte 0x80 in position
13147: invalid start byte
To git+ssh://gcc.gnu.org/git/gcc.git
   13ec81eb4c3..d495ea2b232  master -> master

[Bug target/109279] RISC-V: complex constants synthesized should be improved

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

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

--- Comment #12 from Andrew Pinski  ---
Here is something to look into:
#define const1 0x0101010101010101ULL 
#define const2 0x0080402010080400ULL 
#define const0 const1
unsigned long long g(unsigned long long occ, const unsigned int sq) {
  return const0 ;
}
unsigned long long f(unsigned long long occ, const unsigned int sq) {
  unsigned long long t= (const0)>>32<<32 ;
  unsigned long long t1= (unsigned int)(const0) ;
  asm("":"+r"(t));
  return t | t1;
}

[Bug target/109279] RISC-V: complex constants synthesized should be improved

[vineet.gupta at linux dot dev via Gcc-bugs]

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

--- Comment #11 from Vineet Gupta  ---
With change suggested by @pinksia, I do see that in split1, 
riscv_move_integer() -> riscv_split_integer() is now called.

[Bug target/109279] RISC-V: complex constants synthesized should be improved

[vineet.gupta at linux dot dev via Gcc-bugs]

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

--- Comment #10 from Vineet Gupta  ---
I tried removing the in_splitter  check (in 2 places), but no change in
results.

@@ -1313,7 +1313,7 @@ riscv_force_temporary (rtx dest, rtx value, bool
in_splitter)

-  if (can_create_pseudo_p () && !in_splitter)
+  if (can_create_pseudo_p ())


@@ -1669,7 +1669,7 @@ riscv_move_integer (rtx temp, rtx dest, HOST_WIDE_INT
value,

-  bool can_create_pseudo = can_create_pseudo_p () && ! in_splitter;
+  bool can_create_pseudo = can_create_pseudo_p ();

[Bug target/109279] RISC-V: complex constants synthesized should be improved

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

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

--- Comment #9 from Andrew Pinski  ---
The comment in riscv.cc:
  /* We can't call gen_reg_rtx from a splitter, because this might realloc
 the regno_reg_rtx array, which would invalidate reg rtx pointers in the
 combine undo buffer.  */
  bool can_create_pseudo = can_create_pseudo_p () && ! in_splitter;

is no longer true after r12-8030-g61bee6aed26eb3

so you should be able to get rid of the `&& ! in_splitter` part.

[Bug c/106465] ICE for VLA in struct in parameter of nested function

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #4 from Martin Uecker  ---
This version works with 4.1.2

https://godbolt.org/z/x4v6aTv87

int h(void)
{
int g(int m, struct { char (*p)[m]; }* b) { return sizeof *b->p; }
return g(5, 0);
}

[Bug c/109280] Very significant increase in code size (gcc-avr)

[dirkx-gcc-2001 at webweaving dot org via Gcc-bugs]

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

Dirk-Willem van Gulik  changed:

   What|Removed |Added

 Target||air
 CC||dirkx-gcc-2001 at webweaving 
dot o
   ||rg

--- Comment #1 from Dirk-Willem van Gulik  ---
Tried and tested code (https://github.com/gnea/grbl) grows from 28k to about
36k (so a 1/3 change) when going gcc version 7.3.0 (GCC) to gcc version 12.2.0
(GCC) for GCC-AVR. 

Size increase is across the board according to avr-nm -l --size-sort ; with
pretty much sensible flags provided:

avr-gcc -Wall -Os -mcall-prologues  -fdata-sections -ffunction-sections
-flto

[Bug c/109280] New: Very significant increase in code size (gcc-avr)

[dirkx-gcc-2001 at webweaving dot org via Gcc-bugs]

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

Bug ID: 109280
   Summary: Very significant increase in code size (gcc-avr)
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dirkx-gcc-2001 at webweaving dot org
  Target Milestone: ---

[Bug target/109279] RISC-V: complex constants synthesized should be improved

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

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

--- Comment #8 from Andrew Pinski  ---
oh right this is because can_create_pseudo is false 

This code is just so broken ...

[Bug target/109279] RISC-V: complex constants synthesized should be improved

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

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

--- Comment #7 from Andrew Pinski  ---
riscv_split_integer does something similarlly to what I was suggesting but for
some reason it is not kicking in for this case ...

[Bug target/109279] RISC-V: complex constants synthesized should be improved

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-03-24
 Status|UNCONFIRMED |NEW
Summary|[13 Regression] RISC-V: |RISC-V: complex constants
   |complex constants   |synthesized should be
   |synthesized vs. fetching|improved
   |from constant pool  |
 Ever confirmed|0   |1

--- Comment #6 from Andrew Pinski  ---
Take:
long long f(void)
{
  return 0x0101010101010101ull;
}

 CUT 
This should be done as:
li  a0,16842752
addia0,a0,257
sllia1,a0,32
or  a0,a0,a1
Which is what this produces:
```
long long f(void)
{
  unsigned t = 16843009;
  long long t1 = t;
  long long t2 = ((unsigned long long )t) << 32;
  asm("":"+r"(t1));
  return t1 | t2;
}
```
I suspect: 0x0080402010080400ULL should be done as two 32bit with a shift/or
added too. Will definitely improve complex constants forming too.

Right now the backend does (const<<16+const)<<16+const... which is just so bad.

[Bug target/109279] [13 Regression] RISC-V: complex constants synthesized vs. fetching from constant pool

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Vineet Gupta from comment #4)
> But this is not so much about code bloat, we see 3.5% additional dynamic
> icount on qemu which will affect perf even if we didn't care about code size
> at all.

Again dynamic icount increase does not always equals worse performance;
especially when it comes to loading from memory. It is a much more complex
equation depending on the cache and such.
Now we should be able to form these constants better in the first place too.

[Bug target/109279] [13 Regression] RISC-V: complex constants synthesized vs. fetching from constant pool

[vineet.gupta at linux dot dev via Gcc-bugs]

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

--- Comment #4 from Vineet Gupta  ---
(In reply to Andrew Pinski from comment #2)
> If this was about -Os, then I would say yes this is a big code bloat but
> this is about -O2.

But this is not so much about code bloat, we see 3.5% additional dynamic icount
on qemu which will affect perf even if we didn't care about code size at all.

[Bug target/109279] [13 Regression] RISC-V: complex constants synthesized vs. fetching from constant pool

[vineet.gupta at linux dot dev via Gcc-bugs]

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

--- Comment #3 from Vineet Gupta  ---
We start off with following:

  (insn 18 17 19 2 (set (reg:DI 154)
 (mem/u/c:DI (reg/f:DI 155) [0  S8 A64])) "...":9:8 179 {*movdi_64bit}
 (expr_list:REG_DEAD (reg/f:DI 155)
(expr_list:REG_EQUAL (const_int [0x101010101010101])

cse1 matches the new pattern and converts mem to const_int.

   (insn 18 17 19 2 (set (reg:DI 154)
(const_int [0x101010101010101])) "...":9:8 177 {*mvconst_internal}
 (expr_list:REG_DEAD (reg/f:DI 155)
(expr_list:REG_EQUAL (const_int [0x101010101010101])

split1 then does its job, again using the introduced define_insn_and_split
"*mvconst_internal"

Splitting with gen_split_15 (riscv.md:1677)
deleting insn with uid = 18.

   (insn 47 15 48 2 (set (reg:DI 154)
(const_int 16842752 [0x101])) "...":9:8 -1

   (insn 48 47 49 2 (set (reg:DI 154)
(plus:DI (reg:DI 154)
(const_int 257 [0x101]))) "...":9:8 -1

   (insn 49 48 50 2 (set (reg:DI 154)
(ashift:DI (reg:DI 154)
(const_int 16 [0x10]))) "...":9:8 -1

   (insn 50 49 51 2 (set (reg:DI 154)
(plus:DI (reg:DI 154)
(const_int 257 [0x101]))) "...":9:8 -1

   (insn 51 50 52 2 (set (reg:DI 154)
(ashift:DI (reg:DI 154)
(const_int 16 [0x10]))) "...":9:8 -1

   (insn 52 51 19 2 (set (reg:DI 154)
(plus:DI (reg:DI 154)
(const_int 257 [0x101]))) "...":9:8 -1
 (expr_list:REG_EQUAL (const_int [0x101010101010101])

[Bug target/109279] [13 Regression] RISC-V: complex constants synthesized vs. fetching from constant pool

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

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

--- Comment #2 from Andrew Pinski  ---
If this was about -Os, then I would say yes this is a big code bloat but this
is about -O2.

[Bug target/109279] [13 Regression] RISC-V: complex constants synthesized vs. fetching from constant pool

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

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

--- Comment #1 from Andrew Pinski  ---
Note I think this really depends on the micro-arch if loading from memory is
faster than doing instructions for constant forming.

[Bug target/109279] New: [13 Regression] RISC-V: complex constants synthesized vs. fetching from constant pool

[vineet.gupta at linux dot dev via Gcc-bugs]

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

Bug ID: 109279
   Summary: [13 Regression] RISC-V: complex constants synthesized
vs. fetching from constant pool
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vineet.gupta at linux dot dev
  Target Milestone: ---

This is code bloat regression since gcc 12.1, seen yet again in SPEC2017
deepsjeng. After 2e886eef7f2b5a ("RISC-V: Produce better code with complex
constants [PR95632] [PR106602]").

unsigned long long FileAttacks(unsigned long long occ, const unsigned int sq) {
unsigned int o;
unsigned int f = sq & 7;

occ   =   0x0101010101010101ULL & (occ   >> f);
o = ( 0x0080402010080400ULL *  occ ) >> 58;
return  ( aFileAttacks[o][sq>>3]) << f;
}

cc1 -O2 -march=rv64gc_zba_zbb_zbc_zbs -mabi=lp64d   # stage1 is enough

Before above commit
---
lui a4,%hi(.LC0)
ld  a4,%lo(.LC0)(a4)
andia3,a1,7
srl a5,a0,a3
and a5,a5,a4
lui a4,%hi(.LC1)
ld  a4,%lo(.LC1)(a4)
srliw   a1,a1,3
mul a5,a5,a4
lui a4,%hi(aFileAttacks)
addia4,a4,%lo(aFileAttacks)
srlia5,a5,58
sh3add  a5,a5,a1
sh3add  a5,a5,a4
ld  a0,0(a5)
sll a0,a0,a3
ret

.section.srodata.cst8,"aM",@progbits,8
.align  3
.LC0:
.dword  0x0101010101010101
.align  3
.LC1:
.dword  0x0080402010080400


With commit
---

   li  a5,16842752
addia5,a5,257
sllia5,a5,16
addia5,a5,257
andia3,a1,7
sllia5,a5,16
srl a4,a0,a3
addia5,a5,257
and a4,a4,a5
sllia5,a4,9
add a5,a5,a4
sllia5,a5,9
add a5,a5,a4
sllia4,a5,27
add a5,a5,a4
srlia5,a5,45
srliw   a1,a1,3
andia5,a5,504
lui a4,%hi(aFileAttacks)
add a5,a5,a1
addia4,a4,%lo(aFileAttacks)
sh3add  a5,a5,a4
ld  a0,0(a5)
sll a0,a0,a3
ret

[Bug middle-end/109258] [13 Regression] go.test/test/fixedbugs/bug207.go ICEs

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

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

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

https://gcc.gnu.org/g:0849a188d539d78101a32deea63db4cb39fb55ac

commit r13-6858-g0849a188d539d78101a32deea63db4cb39fb55ac
Author: Jakub Jelinek 
Date:   Fri Mar 24 23:02:08 2023 +0100

go: Fix up go.test/test/fixedbugs/bug207.go failure [PR109258]

The PR109086 r13-6690 inline_string_cmp change to
  if (diff != result)
emit_move_insn (result, diff);
regressed
FAIL: go.test/test/fixedbugs/bug207.go,  -O2 -g  (internal compiler error:
in emit_move_insn, at expr.cc:4224)
The problem is the Go FE doesn't mark __builtin_memcmp as pure as other
FEs,
so we ended up with
  __builtin_memcmp (whatever, whateverelse, somesize);
in the IL before expansion and the expansion ICEd on it.
As the builtin calls a library function which is pure or is inline expanded
as such, not marking it pure is an unnecessary pessimization from the FE
side, keeping such dead calls in the IL if they aren't needed will not help
anything.

The following patch fixes that.  Initially I've added just DECL_PURE_P to
it, but that unfortunately broke bootstrap, for __builtin_memcmp there is
also __builtin_memcmp_eq registered by the middle-end code if not
registered
earlier and that one is registered with the usual flags (pure, nothrow,
leaf), so if __builtin_memcmp from FE was just pure, it would appear in the
IL as that it can raise exceptions and when folded into __builtin_memcmp_eq
all of sudden it couldn't and we'd ICE in verification.

I think tons of functions should have builtin_nothrow as well, but changing
that wasn't necessary for this fix.

2023-03-24  Jakub Jelinek  

PR middle-end/109258
* go-gcc.cc (Gcc_backend): Add new static data members builtin_pure
and builtin_nothrow.
(Gcc_backend::Gcc_backend): Pass builtin_pure | builtin_nothrow for
BUILT_IN_MEMCMP.
(Gcc_backend::define_builtin): Handle builtin_pure and
builtin_nothrow
in flags.

[Bug c++/109278] a note without a warning

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 54752
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54752=edit
gcc13-pr109278.patch

Untested fix.

[Bug c++/109278] a note without a warning

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Keywords|needs-reduction |

--- Comment #3 from Jakub Jelinek  ---
Reduced testcase:
void foo (long double);

void
bar (_Float128 x)
{
  foo (x);
}

[Bug fortran/107560] ICE in gfc_get_derived_type, at fortran/trans-types.cc:2811

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

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
The BOZ memleak should be fixed with r13-6857-g833233a4aefc99.

There is another FE memleak which is the same for z1.f90 and z2.f90:

==16805== 48 bytes in 1 blocks are definitely lost in loss record 19 of 674
==16805==at 0x4C39571: calloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==16805==by 0x2120D94: xcalloc (xmalloc.c:164)
==16805==by 0x9AB967: gfc_match_actual_arglist(int, gfc_actual_arglist**,
bool) (primary.cc:1870)
==16805==by 0x9AFEA2: gfc_match_rvalue(gfc_expr**) (primary.cc:3695)
==16805==by 0x95F6A6: match_primary(gfc_expr**) (matchexp.cc:157)
==16805==by 0x95F7C3: match_level_1(gfc_expr**) (matchexp.cc:211)
==16805==by 0x95F885: match_mult_operand(gfc_expr**) (matchexp.cc:267)
==16805==by 0x95FA90: match_add_operand(gfc_expr**) (matchexp.cc:356)
==16805==by 0x95FD50: match_level_2(gfc_expr**) (matchexp.cc:480)
==16805==by 0x95FEE2: match_level_3(gfc_expr**) (matchexp.cc:551)
==16805==by 0x95FFE6: match_level_4(gfc_expr**) (matchexp.cc:599)
==16805==by 0x960279: match_and_operand(gfc_expr**) (matchexp.cc:693)

[Bug c++/85775] False positive with -Wparentheses

[markus-t314 at gmx dot de via Gcc-bugs]

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

--- Comment #3 from markus  ---
Worked until 7.5, fails since 8.1 and still fails in 12.2

[Bug c++/109277] [13 Regression] type_traits:1417:30: error: invalid use of incomplete type ‘class v8::internal::WasmArray’

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

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

--- Comment #8 from Jonathan Wakely  ---
Yes, looks undefined at first glance. We don't have to diagnose bad uses of
type traits (but we don't have to ignore them either, which means both gcc 12
and gcc 13 are correct).

The question is whether the trait instantiation is supposed to happen here, or
if it should be ok to name the incomplete type as long as its not used before
it's complete.

[Bug fortran/107560] ICE in gfc_get_derived_type, at fortran/trans-types.cc:2811

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

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #2)
> Yep. It was missed by the guy that did the BOZ rework. ;-)

I think the BOZ rework was a greater step for mankind than the missing fix ...

> If it passed regtesting, it's ok to commit.

It did.  Will commit.

[Bug c++/85775] False positive with -Wparentheses

[markus-t314 at gmx dot de via Gcc-bugs]

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

markus  changed:

   What|Removed |Added

 CC||markus-t314 at gmx dot de

--- Comment #2 from markus  ---
Maybe a simpler example:

struct Foo {
int num;
};

struct S {
static Foo f;
};

// error: 'S' in 'struct Foo' does not name a type
//Foo ::S::f = Foo{23};

// warning: unnecessary parentheses in declaration of 'f' [-Wparentheses]
Foo (::S::f) = Foo{23};


Parantheses are necessary if global scope resolution is wanted/needed,
otherwise they would refer to the class Foo.

https://godbolt.org/z/7d39rbv7o

[Bug c++/109277] [13 Regression] type_traits:1417:30: error: invalid use of incomplete type ‘class v8::internal::WasmArray’

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

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

--- Comment #7 from Andrew Pinski  ---
Note I filed the note without a warning at PR 109278.

[Bug c++/109278] a note without a warning

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

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

--- Comment #2 from Andrew Pinski  ---
Created attachment 54751
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54751=edit
compressed preprocessed source

Semi reduced testcase, just removing what was afterwards rather than anything
else.

[Bug fortran/107560] ICE in gfc_get_derived_type, at fortran/trans-types.cc:2811

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #1)
> This used to fail, but appears to have been fixed in the meantime.
> A possible candidate for variant z2.f90 seems the fix for pr103413.
> 
> While looking at valgrind output with current trunk, I see a memleak
> for the BOZ case that is obviously plugged by:
> 
> diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
> index 4662328bf31..7fb33f81788 100644
> --- a/gcc/fortran/expr.cc
> +++ b/gcc/fortran/expr.cc
> @@ -466,6 +466,10 @@ free_expr0 (gfc_expr *e)
>   mpc_clear (e->value.complex);
>   break;
>  
> +   case BT_BOZ:
> + free (e->boz.str);
> + break;
> +
> default:
>   break;
> }
> 
> This might have been overseen during the BOZ rework.
> Regtesting ...

Yep. It was missed by the guy that did the BOZ rework. ;-)

If it passed regtesting, it's ok to commit.

[Bug c++/109278] a note without a warning

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

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

--- Comment #1 from Andrew Pinski  ---
Sorry the compressed source is still too big.

[Bug c++/109278] New: a note without a warning

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

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

Bug ID: 109278
   Summary: a note without a warning
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: diagnostic, needs-reduction
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

the attached unreduced testcase when compiled with -w -std=c++20, gives:
t.cc: In static member function ‘static int
__iseqsig_type<_Float128>::__call(_Float128, _Float128)’:
t.cc:90092:36: note:   initializing argument 1 of ‘int __iseqsigl(long double,
long double)’
90092 | extern int __iseqsigl (long double __x, long double __y) noexcept
(true);
  |^~~
t.cc:90092:53: note:   initializing argument 2 of ‘int __iseqsigl(long double,
long double)’
90092 | extern int __iseqsigl (long double __x, long double __y) noexcept
(true);
  | ^~~


Which is wrong as the warnings are supressed but still providing the note.

[Bug c++/109277] [13 Regression] type_traits:1417:30: error: invalid use of incomplete type ‘class v8::internal::WasmArray’

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

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

--- Comment #6 from Andrew Pinski  ---
I know cppreference is not the standard but usually it has a good summary.

From: https://en.cppreference.com/w/cpp/types/is_convertible :
```
>From and To shall each be a complete type, (possibly cv-qualified) void, or an
array of unknown bound. Otherwise, the behavior is undefined.
```

So someone who understands the C++ standard better than me should be able to
answer if this is in fact illformed code.

[Bug fortran/107560] ICE in gfc_get_derived_type, at fortran/trans-types.cc:2811

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||11.3.1, 12.2.1, 13.0
 CC||anlauf at gcc dot gnu.org
  Known to fail||11.3.0, 12.2.0

--- Comment #1 from anlauf at gcc dot gnu.org ---
This used to fail, but appears to have been fixed in the meantime.
A possible candidate for variant z2.f90 seems the fix for pr103413.

While looking at valgrind output with current trunk, I see a memleak
for the BOZ case that is obviously plugged by:

diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index 4662328bf31..7fb33f81788 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -466,6 +466,10 @@ free_expr0 (gfc_expr *e)
  mpc_clear (e->value.complex);
  break;

+   case BT_BOZ:
+ free (e->boz.str);
+ break;
+
default:
  break;
}

This might have been overseen during the BOZ rework.
Regtesting ...

[Bug c++/109277] [13 Regression] type_traits:1417:30: error: invalid use of incomplete type ‘class v8::internal::WasmArray’

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

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

--- Comment #5 from Andrew Pinski  ---
Reduced testcase that shows the compiling difference between GCC 12 and 13:
```
#include 
struct a;
struct b{};
bool c = std::is_convertible::value;
```

[Bug c++/109277] [13 Regression] type_traits:1417:30: error: invalid use of incomplete type ‘class v8::internal::WasmArray’

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> The difference is is_convertible definition.
> 12:
>   template
> struct is_convertible
> : public __is_convertible_helper<_From, _To>::type
> { };
> 
> 
> 13:
>   template
> struct is_convertible
> : public __bool_constant<__is_convertible(_From, _To)>
> { };
> 
> So it might be a front-end issue after all.

and yes that is definitely the difference here. If I add back the
__is_convertible_helper and use that for is_convertible to the GCC 13
preprocessed source, the code then compiles.

[Bug c++/109277] [13 Regression] type_traits:1417:30: error: invalid use of incomplete type ‘class v8::internal::WasmArray’

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

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

--- Comment #3 from Andrew Pinski  ---
Though the code might be undefined ...

20.15.6/5 says:
```
The predicate condition for a template specialization is_convertible
shall be satisfied if and
only if the return expression in the following code would be well-formed,
including any implicit conversions
to the return type of the function:
To test() {
return declval();
}
[Note: This requirement gives well-defined results for reference types, void
types, array types, and function
types. — end note] Access checking is performed in a context unrelated to To
and From. Only the validity
of the immediate context of the expression of the return statement (8.7.3)
(including initialization of the
returned object or reference) is considered. [Note: The initialization can
result in side effects such as
the instantiation of class template specializations and function template
specializations, the generation of
implicitly-defined functions, and so on. Such side effects are not in the
“immediate context” and can result in
the program being ill-formed. — end note]

```
I am not 100% sure but I suspect this is just ill-formed code which was not
rejected before but is now using the builtin rather than the template form ...

[Bug c++/109277] [13 Regression] type_traits:1417:30: error: invalid use of incomplete type ‘class v8::internal::WasmArray’

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also|https://gcc.gnu.org/bugzill |https://gcc.gnu.org/bugzill
   |a/show_bug.cgi?id=96592 |a/show_bug.cgi?id=107049
  Component|libstdc++   |c++

--- Comment #2 from Andrew Pinski  ---
The difference is is_convertible definition.
12:
  template
struct is_convertible
: public __is_convertible_helper<_From, _To>::type
{ };


13:
  template
struct is_convertible
: public __bool_constant<__is_convertible(_From, _To)>
{ };

So it might be a front-end issue after all.

[Bug libstdc++/109277] [13 Regression] type_traits:1417:30: error: invalid use of incomplete type ‘class v8::internal::WasmArray’

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c++ |libstdc++

--- Comment #1 from Andrew Pinski  ---
The GCC 12 preprocessed source works (with a minor change of
s/__remove_cv/__remove_cv1/ ) so this is definitely due to a libstdc++ change.

[Bug c++/109277] [13 Regression] type_traits:1417:30: error: invalid use of incomplete type ‘class v8::internal::WasmArray’

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |UNCONFIRMED
   Target Milestone|--- |13.0
 Ever confirmed|1   |0

[Bug tree-optimization/109175] error: 'void* __builtin_memset(void*, int, long unsigned int)' writing 4 or more bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]

[jan.wassenberg at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Jan Wassenberg  ---
Thanks, I will be changing the code to add a nullptr check.

[Bug fortran/109275] Bad error messages for interfaces describing surrounding program unit

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2023-03-24
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords||diagnostic

[Bug c++/109277] [13 Regression] type_traits:1417:30: error: invalid use of incomplete type ‘class v8::internal::WasmArray’

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

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug c++/109277] New: [13 Regression] type_traits:1417:30: error: invalid use of incomplete type ‘class v8::internal::WasmArray’

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

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

Bug ID: 109277
   Summary: [13 Regression] type_traits:1417:30: error: invalid
use of incomplete type ‘class v8::internal::WasmArray’
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: redi at gcc dot gnu.org
  Target Milestone: ---

Reduced from chromium, gcc-12 accepts the code:

GCC 13 pre-processed source code:
https://gist.githubusercontent.com/marxin/377cbc8221f7c36e87aebe48a55b52ba/raw/b80443940faf20f6f5db124fb6a56d9bee994fee/promise13.ii

$ g++ -std=gnu++20 promise13.ii -c -w
In file included from /usr/include/math.h:398,
 from /usr/include/c++/13/cmath:47,
 from ../v8/src/utils/utils.h:12,
 from ../v8/src/zone/zone.h:15,
 from ../v8/src/handles/handles.h:14,
 from ../v8/src/ast/ast-value-factory.h:36,
 from ../v8/src/ast/ast.h:10,
 from
gen/v8/torque-generated/src/builtins/promise-all-element-closure-tq-csa.cc:1:
/usr/include/bits/mathcalls-helper-functions.h: In static member function
‘static int __iseqsig_type<_Float128>::__call(_Float128, _Float128)’:
/usr/include/bits/mathcalls-helper-functions.h:41:36: note:   initializing
argument 1 of ‘int __iseqsigl(long double, long double)’
   41 | __MATHDECL_ALIAS (int, __iseqsig,, (_Mdouble_ __x, _Mdouble_ __y),
iseqsig);
  |^~~
/usr/include/bits/mathcalls-helper-functions.h:41:53: note:   initializing
argument 2 of ‘int __iseqsigl(long double, long double)’
   41 | __MATHDECL_ALIAS (int, __iseqsig,, (_Mdouble_ __x, _Mdouble_ __y),
iseqsig);
  | ^~~
In file included from /usr/include/c++/13/bits/move.h:57,
 from /usr/include/c++/13/bits/new_allocator.h:36,
 from
/usr/include/c++/13/aarch64-suse-linux/bits/c++allocator.h:33,
 from /usr/include/c++/13/bits/allocator.h:46,
 from /usr/include/c++/13/memory:65,
 from ../v8/src/ast/ast.h:8:
/usr/include/c++/13/type_traits: In instantiation of ‘struct
std::is_convertible’:
../v8/src/codegen/tnode.h:273:72:   required from ‘const bool
v8::internal::is_subtype::value’
../v8/src/codegen/tnode.h:361:75:   required by substitution of ‘template::value, int>::type  >
v8::internal::TNode::TNode(const
v8::internal::TNode&) [with U = v8::internal::WasmArray; typename
std::enable_if::value,
int>::type  = ]’
/usr/include/c++/13/tuple:188:12:   required from ‘struct std::_Head_base<0,
v8::internal::TNode, false>’
/usr/include/c++/13/tuple:259:12:   required from ‘struct std::_Tuple_impl<0,
v8::internal::TNode,
v8::internal::TNode,
v8::internal::TNode >’
/usr/include/c++/13/tuple:746:11:   required from ‘class
std::tuple,
v8::internal::TNode,
v8::internal::TNode >’
gen/v8/torque-generated/csa-types.h:487:80:   required from here
/usr/include/c++/13/type_traits:1417:30: error: invalid use of incomplete type
‘class v8::internal::WasmArray’
 1417 | : public __bool_constant<__is_convertible(_From, _To)>
  |  ^~~~
In file included from ../v8/src/heap/factory-base.h:15,
 from ../v8/src/heap/factory.h:18,
 from ../v8/src/ast/ast.h:18:
gen/v8/torque-generated/class-forward-declarations.h:291:7: note: forward
declaration of ‘class v8::internal::WasmArray’
In file included from ../v8/src/codegen/interface-descriptors.h:13,
 from ../v8/src/codegen/callable.h:8,
 from ../v8/src/codegen/code-factory.h:8,
 from ../v8/src/codegen/code-stub-assembler.h:12,
 from ../v8/src/builtins/builtins-array-gen.h:8,
 from
gen/v8/torque-generated/src/builtins/promise-all-element-closure-tq-csa.cc:2:
../v8/src/codegen/tnode.h: In instantiation of ‘const bool
v8::internal::is_subtype::value’:
../v8/src/codegen/tnode.h:361:75:   required by substitution of ‘template::value, int>::type  >
v8::internal::TNode::TNode(const
v8::internal::TNode&) [with U = v8::internal::WasmArray; typename
std::enable_if::value,
int>::type  = ]’
/usr/include/c++/13/tuple:188:12:   required from ‘struct std::_Head_base<0,
v8::internal::TNode, false>’
/usr/include/c++/13/tuple:259:12:   required from ‘struct std::_Tuple_impl<0,
v8::internal::TNode,
v8::internal::TNode,
v8::internal::TNode >’
/usr/include/c++/13/tuple:746:11:   required from ‘class
std::tuple,
v8::internal::TNode,
v8::internal::TNode >’
gen/v8/torque-generated/csa-types.h:487:80:   required from here
../v8/src/codegen/tnode.h:273:72: error: ‘value’ is not a member of
‘std::is_convertible’

GCC 12 pre-processed source 

[Bug c++/106969] [12 Regression] member function constness incorrectly propagates to local class member function return type deduction

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

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

Patrick Palka  changed:

   What|Removed |Added

Summary|[12/13 Regression] member   |[12 Regression] member
   |function constness  |function constness
   |incorrectly propagates to   |incorrectly propagates to
   |local class member function |local class member function
   |return type deduction   |return type deduction

--- Comment #4 from Patrick Palka  ---
Fixed for GCC 13 so far

[Bug c++/106969] [12/13 Regression] member function constness incorrectly propagates to local class member function return type deduction

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

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

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

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

commit r13-6856-gbbf2424c57c2e13d1a972c4ef4e871c3119b9cb4
Author: Patrick Palka 
Date:   Fri Mar 24 14:51:24 2023 -0400

c++: outer 'this' leaking into local class [PR106969]

Here when resolving the implicit object for '' within the
local class Foo, we expect to obtain a dummy object of type Foo& since
there's no 'this' available in this context.  And yet at this point
current_class_ref still corresponds to the outer class Context (and is
const), which confuses maybe_dummy_object into propagating the cv-quals
of current_class_ref and returning an object of type const Foo&.  Thus
decltype() wrongly yields const int* instead of int*.

The problem ultimately seems to be that the 'this' from the enclosing
class appears available for use when parsing the local class, but 'this'
shouldn't persist across classes like that.  This patch fixes this by
clearing current_class_ptr/ref before parsing a class definition.

After this change, for the test name-clash11.C in C++98 mode we would
now complain about an invalid use of 'this' in e.g.

  ASSERT (sizeof (this->A) == 16);

due to the way the test defines the ASSERT macro via a local class.
This patch redefines the macro using a local typedef instead.

PR c++/106969

gcc/cp/ChangeLog:

* parser.cc (cp_parser_class_specifier): Clear current_class_ptr
and current_class_ref sooner, before parsing a class definition.

gcc/testsuite/ChangeLog:

* g++.dg/lookup/name-clash11.C: Fix ASSERT macro definition in
C++98 mode.
* g++.dg/lookup/this2.C: New test.

[Bug tree-optimization/109175] error: 'void* __builtin_memset(void*, int, long unsigned int)' writing 4 or more bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]

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

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

--- Comment #6 from Andrew Pinski  ---
Reduced all the way removing all of the classes showing exactly what I thought
it was:
```
void *ao();
float *aq(long t) {
  if (t)
return nullptr;
  return static_cast(ao());
}
float v;
void at(long t) {
  long a = sizeof(0), i = 0;
  auto b = aq(t);
  for (; i < a; ++i)
b[i] = v;
  for (; i < t; ++i)
b[i] = 0.0f;
}
```

Notice how there is no check for null on aq.

[Bug fortran/109186] nearest(huge(x),-1.0_kind(x)) half of correct value

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #10 from anlauf at gcc dot gnu.org ---
Fixed on all open branches.  Closing.

Thanks for the report!

[Bug fortran/85877] [10/11/12/13 Regression] ICE in fold_convert_loc, at fold-const.c:2449

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #16 from anlauf at gcc dot gnu.org ---
Fixed on all affected branches.  Closing.

Thanks for the report!

[Bug fortran/32630] [meta-bug] ISO C binding

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

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

Bug 85877 Summary: [10/11/12/13 Regression] ICE in fold_convert_loc, at 
fold-const.c:2449
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85877

   What|Removed |Added

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

[Bug fortran/109186] nearest(huge(x),-1.0_kind(x)) half of correct value

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

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

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

commit r10-11265-gb9f6e7e234bab6ef8b5425c3e8b88bf8dfbc5089
Author: Harald Anlauf 
Date:   Sun Mar 19 21:29:46 2023 +0100

Fortran: simplification of NEAREST for large argument [PR109186]

gcc/fortran/ChangeLog:

PR fortran/109186
* simplify.c (gfc_simplify_nearest): Fix off-by-one error in
setting
up real kind-specific maximum exponent for mpfr.

gcc/testsuite/ChangeLog:

PR fortran/109186
* gfortran.dg/nearest_6.f90: New test.

(cherry picked from commit 4410a08b80cc40342eeaa5b6af824cd4352b218c)

[Bug fortran/85877] [10/11/12/13 Regression] ICE in fold_convert_loc, at fold-const.c:2449

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

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

--- Comment #15 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

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

commit r10-11264-gdca8e28c990547648543175de9b6e05356f77e8a
Author: Harald Anlauf 
Date:   Fri Mar 17 22:24:49 2023 +0100

Fortran: procedures with BIND(C) attribute require explicit interface
[PR85877]

gcc/fortran/ChangeLog:

PR fortran/85877
* resolve.c (resolve_fl_procedure): Check for an explicit interface
of procedures with the BIND(C) attribute (F2018:15.4.2.2).

gcc/testsuite/ChangeLog:

PR fortran/85877
* gfortran.dg/pr85877.f90: New test.

(cherry picked from commit 5426ab34643d9e6502f3ee572891a03471fa33ed)

[Bug fortran/99036] [11/12/13 Regression] ICE in gfc_current_interface_head, at fortran/interface.c:4699

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #14 from anlauf at gcc dot gnu.org ---
Fixed on all affected branches.  Closing.

Thanks for the report!

[Bug fortran/99036] [11/12/13 Regression] ICE in gfc_current_interface_head, at fortran/interface.c:4699

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

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

--- Comment #13 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:2055702e8d492be6e978fa93a7bfefd358d5d9e3

commit r11-10596-g2055702e8d492be6e978fa93a7bfefd358d5d9e3
Author: Harald Anlauf 
Date:   Tue Mar 21 19:58:31 2023 +0100

Fortran: reject MODULE PROCEDURE outside generic module interface [PR99036]

gcc/fortran/ChangeLog:

PR fortran/99036
* decl.c (gfc_match_modproc): Reject MODULE PROCEDURE if not in a
generic module interface.

gcc/testsuite/ChangeLog:

PR fortran/99036
* gfortran.dg/pr99036.f90: New test.

(cherry picked from commit dd282b16bfd3c6e218dffb7798a375365b10ae22)

[Bug fortran/109186] nearest(huge(x),-1.0_kind(x)) half of correct value

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:

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

commit r11-10595-g4b722050fe8e7f06a3e653f290a39ccdc4d03174
Author: Harald Anlauf 
Date:   Sun Mar 19 21:29:46 2023 +0100

Fortran: simplification of NEAREST for large argument [PR109186]

gcc/fortran/ChangeLog:

PR fortran/109186
* simplify.c (gfc_simplify_nearest): Fix off-by-one error in
setting
up real kind-specific maximum exponent for mpfr.

gcc/testsuite/ChangeLog:

PR fortran/109186
* gfortran.dg/nearest_6.f90: New test.

(cherry picked from commit 4410a08b80cc40342eeaa5b6af824cd4352b218c)

[Bug fortran/85877] [10/11/12/13 Regression] ICE in fold_convert_loc, at fold-const.c:2449

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

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

--- Comment #14 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:0257ba766443f11cf61c52db9b480337e44b48c8

commit r11-10594-g0257ba766443f11cf61c52db9b480337e44b48c8
Author: Harald Anlauf 
Date:   Fri Mar 17 22:24:49 2023 +0100

Fortran: procedures with BIND(C) attribute require explicit interface
[PR85877]

gcc/fortran/ChangeLog:

PR fortran/85877
* resolve.c (resolve_fl_procedure): Check for an explicit interface
of procedures with the BIND(C) attribute (F2018:15.4.2.2).

gcc/testsuite/ChangeLog:

PR fortran/85877
* gfortran.dg/pr85877.f90: New test.

(cherry picked from commit 5426ab34643d9e6502f3ee572891a03471fa33ed)

[Bug target/109276] [11/12/13 Regression] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

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

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

--- Comment #10 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #7)
> This started to ICE with r11-508-gdfa4fcdba374ed44 in the newly added pass
> there,
> and since r11-2259-g0a9d711df36b42b6494b73 it ICEs similarly like on the
> trunk.

The new pass should just stack alignment requirements when alignment of
stack variable is increased.

[Bug tree-optimization/109175] error: 'void* __builtin_memset(void*, int, long unsigned int)' writing 4 or more bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]

[malat at debian dot org via Gcc-bugs]

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

--- Comment #5 from Mathieu Malaterre  ---
c-reduce(d) ugly version:

% cat demo3.cc
struct d {
  using b = float &;
};
template  using c = d::b;
struct e {
  using b = c;
};
template  struct j;
template  using h = typename j::b;
template  struct p;
template  struct p<0, k, l...> { using b = k; };
template  class m;
template  struct aa {
  aa(n t) : o(t) {}
  static n ab(aa t) { return t.o; }
  n o;
};
template  struct q;
template 
struct q : q<1, s...>, aa {
  q(n t, s... ac) : q<1, s...>(ac...), aa(t) {}
};
template  struct q : aa {
  q(n t) : aa(t) {}
};
template  class m : public q<0, ad, ae> {
public:
  m(ad t, ae ac) : q<0, ad, ae>(t, ac) {}
};
template  struct j> {
  using b = typename p::b;
};
template  n ag(q t) {
  return q::ab(t);
}
template  h> ai(m t) { return ag(t);
}
class u {
  struct aj {
using b = float *;
  };

public:
  using ak = aj::b;
  u(ak t, int) : al(t, long()) {}
  ak w() { return ai<0>(al); }
  m al;
};
struct x : u {
  using u::u;
};
class y {
  x al;

public:
  using ak = u::ak;
  using am = int;
  template  y(an t, am ac) : al(t, ac) {}
  e::b operator[](long t) { return z()[t]; }
  ak z() { return al.w(); }
};
void *ao();
template  ap *aq(long t) {
  if (t)
return nullptr;
  return static_cast(ao());
}
template  using ar = y;
template  ar as(long t, void *) {
  return ar(aq(t), int());
}
template  ar as(long t) { return as(t, nullptr); }
float v;
void at(long t) {
  long a = sizeof(0), i = 0;
  auto b = as(t);
  for (; i < a; ++i)
b[i] = v;
  for (; i < t; ++i)
b[i] = 0.0f;
}

 % /usr/lib/gcc-snapshot/bin/g++ -Wall -O2 -o t.o -c demo3.cc
demo3.cc: In function 'void at(long int)':
demo3.cc:79:10: warning: 'void* __builtin_memset(void*, int, long unsigned
int)' writing 4 or more bytes into a region of size 0 overflows the destination
[-Wstringop-overflow=]
   79 | b[i] = 0.0f;
cc1plus: note: destination object is likely at address zero

[Bug target/109276] [11/12/13 Regression] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug target/109276] [11/12/13 Regression] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

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

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

--- Comment #8 from Andrew Pinski  ---
A workaround is to do:
long long int digit __attribute__((aligned(8)));

Note manually setting the digit alignment to 4 does not cause an ICE for GCC
10.4 either.

[Bug target/109276] [11/12/13 Regression] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com,
   ||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
This started to ICE with r11-508-gdfa4fcdba374ed44 in the newly added pass
there,
and since r11-2259-g0a9d711df36b42b6494b73 it ICEs similarly like on the trunk.

[Bug target/109276] [11/12/13 Regression] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||11.1.0, 13.0
Summary|ICE: in |[11/12/13 Regression] ICE:
   |assign_stack_local_1, at|in assign_stack_local_1, at
   |function.cc:429 with|function.cc:429 with
   |-mpreferred-stack-boundary= |-mpreferred-stack-boundary=
   |2   |2
   Target Milestone|--- |11.4
   Keywords||ice-on-valid-code
  Known to work||10.1.0, 10.4.0, 9.5.0

[Bug rtl-optimization/109276] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[max.aehle at scicomp dot uni-kl.de via Gcc-bugs]

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

Max Aehle  changed:

   What|Removed |Added

  Attachment #54745|0   |1
is obsolete||

--- Comment #6 from Max Aehle  ---
Comment on attachment 54745
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54745
verbose output, preprocessed source, .i and .s file

I submitted the zip archive because I though that only a single file could be
attached. Afterwards, I attached all files in the archive to this bug report
individually.

[Bug rtl-optimization/109276] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[max.aehle at scicomp dot uni-kl.de via Gcc-bugs]

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

--- Comment #5 from Max Aehle  ---
Created attachment 54750
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54750=edit
produced with -save-temps

[Bug rtl-optimization/109276] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[max.aehle at scicomp dot uni-kl.de via Gcc-bugs]

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

--- Comment #4 from Max Aehle  ---
Created attachment 54749
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54749=edit
produces with -save-temps

[Bug rtl-optimization/109276] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[max.aehle at scicomp dot uni-kl.de via Gcc-bugs]

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

--- Comment #3 from Max Aehle  ---
Created attachment 54748
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54748=edit
preprocessed source produced with -freport-bug

[Bug rtl-optimization/109276] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[max.aehle at scicomp dot uni-kl.de via Gcc-bugs]

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

--- Comment #2 from Max Aehle  ---
Created attachment 54747
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54747=edit
output with additional flag -v

[Bug rtl-optimization/109276] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[max.aehle at scicomp dot uni-kl.de via Gcc-bugs]

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

--- Comment #1 from Max Aehle  ---
Created attachment 54746
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54746=edit
source code of minimal example

[Bug rtl-optimization/109276] New: ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2

[max.aehle at scicomp dot uni-kl.de via Gcc-bugs]

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

Bug ID: 109276
   Summary: ICE: in assign_stack_local_1, at function.cc:429 with
-mpreferred-stack-boundary=2
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: max.aehle at scicomp dot uni-kl.de
  Target Milestone: ---

Created attachment 54745
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54745=edit
verbose output, preprocessed source, .i and .s file

Compiling the attached bug.c with GCC 12.2.0 via

gcc -m32 -O0 -c bug.c -mpreferred-stack-boundary=2

prints

during RTL pass: split1
bug.c: In function 'fun':
bug.c:23:1: internal compiler error: in assign_stack_local_1, at
function.cc:429
   23 | }
  | ^
0x6d3b9b assign_stack_local_1(machine_mode, poly_int<1u, long>, int, int)
/ramdisk/aehle/gcc/gcc-obj/../gcc-12.2.0/gcc/function.cc:429
0xf81d50 assign_386_stack_local(machine_mode, ix86_stack_slot)
/ramdisk/aehle/gcc/gcc-obj/../gcc-12.2.0/gcc/config/i386/i386.cc:16558
0x13bdd87 gen_split_65(rtx_insn*, rtx_def**)
/ramdisk/aehle/gcc/gcc-obj/../gcc-12.2.0/gcc/config/i386/i386.md:5471
0x17d3e0a split_insns(rtx_def*, rtx_insn*)
/ramdisk/aehle/gcc/gcc-obj/../gcc-12.2.0/gcc/config/i386/i386.md:15646
0x9295fe try_split(rtx_def*, rtx_insn*, int)
/ramdisk/aehle/gcc/gcc-obj/../gcc-12.2.0/gcc/emit-rtl.cc:3795
0xc01fb1 split_insn
/ramdisk/aehle/gcc/gcc-obj/../gcc-12.2.0/gcc/recog.cc:3384
0xc072f2 split_all_insns()
/ramdisk/aehle/gcc/gcc-obj/../gcc-12.2.0/gcc/recog.cc:3488
0xc073e8 execute
/ramdisk/aehle/gcc/gcc-obj/../gcc-12.2.0/gcc/recog.cc:4406
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.

We have attached:
- the stdout/stderr output with the additional flag -v,
- the preprocessed source produced with -freport-bug, 
- the files bug.i and bug.s produced with -save-temps.

The GCC 12.2.0 build was configured only with a --prefix option. gcc -v shows

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/ramdisk/aehle/gcc/gcc-install/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /ramdisk/aehle/gcc/gcc-obj/../gcc-12.2.0/configure
--prefix=/ramdisk/aehle/gcc/gcc-obj/../gcc-install
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.2.0 (GCC) 

uname -a says "Linux  5.4.0-122-generic #138-Ubuntu SMP Wed Jun 22
15:00:31 UTC 2022 x86_64 GNU/Linux". /proc/cpuinfo shows a list of 96 cores
with the model name "AMD EPYC 7F72 24-Core Processor". All of the above
commands were executed in a Singularity container based on Debian 11.3.

The source file is a minimal example condensed from Valgrind's m_libcbase.c.

[Bug target/106069] [12/13 Regression] wrong code with -O -fno-tree-forwprop -maltivec on ppc64le

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

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

--- Comment #36 from Peter Bergner  ---
(In reply to Jakub Jelinek from comment #34)
> What is the state of this PR?  I see patches posted in August, but don't see
> anything committed...

I've seen some patch submissions and pings in February and it looks like it
just needs a review.  I'll work with the team to get this reviewed.

[Bug libgcc/108891] libatomic: AArch64 SEQ_CST 16-byte load missing barrier

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

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

Wilco  changed:

   What|Removed |Added

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

--- Comment #2 from Wilco  ---
Fixed

[Bug libgcc/108891] libatomic: AArch64 SEQ_CST 16-byte load missing barrier

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Wilco Dijkstra :

https://gcc.gnu.org/g:1f641d6aba284e0c277e6684cd6b2c73591cd14d

commit r13-6855-g1f641d6aba284e0c277e6684cd6b2c73591cd14d
Author: Wilco Dijkstra 
Date:   Fri Feb 10 17:41:05 2023 +

libatomic: Fix SEQ_CST 128-bit atomic load [PR108891]

The LSE2 ifunc for 16-byte atomic load requires a barrier before the LDP -
without it, it effectively has Load-AcquirePC semantics similar to LDAPR,
which is less restrictive than what __ATOMIC_SEQ_CST requires.  This patch
fixes this and adds comments to make it easier to see which sequence is
used for each case.  Use a load/store exclusive loop for store to simplify
testing memory ordering is correct (it is slightly faster too).

libatomic/
PR libgcc/108891
* config/linux/aarch64/atomic_16.S: Fix libat_load_16_i1.
Add comments describing the memory order.

[Bug c++/105481] [10/11/12/13 Regression] ICE: unexpected expression of kind template_parm_index

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

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

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

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

commit r13-6853-g4e2cdb1ddb5f6ace909358775e94bfe23046ad5a
Author: Jason Merrill 
Date:   Thu Mar 23 18:20:52 2023 -0400

c++: default template arg, partial ordering [PR105481]

The default argument code in type_unification_real was assuming that all
targs we've deduced by that point are non-dependent, but that's not the
case
for partial ordering.

PR c++/105481

gcc/cp/ChangeLog:

* pt.cc (type_unification_real): Adjust for partial ordering.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/fntmpdefarg-partial1.C: New test.

[Bug target/106069] [12/13 Regression] wrong code with -O -fno-tree-forwprop -maltivec on ppc64le

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

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

--- Comment #35 from Jakub Jelinek  ---
Ping again.

[Bug fortran/104949] [OpenMP] omp target: firstprivate of allocatable array – only descriptor firstprivatized

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

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

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

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

commit r13-6852-ge8fec6998b656dac02d4bc6c69b35a0fb5611e87
Author: Thomas Schwinge 
Date:   Thu Mar 23 12:32:35 2023 +0100

Add caveat/safeguard to OpenMP: Handle descriptors in target's firstprivate
[PR104949]

Follow-up to commit 49d1a2f91325fa8cc011149e27e5093a988b3a49
"OpenMP: Handle descriptors in target's firstprivate [PR104949]".

PR fortran/104949
libgomp/
* target.c (gomp_map_vars_internal) : Add
caveat/safeguard.

[Bug target/105980] [11/12 Regression] ICE in final_scan_insn_1, at final.cc:2811

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[11/12/13 Regression] ICE   |[11/12 Regression] ICE in
   |in final_scan_insn_1, at|final_scan_insn_1, at
   |final.cc:2811   |final.cc:2811

--- Comment #10 from Jakub Jelinek  ---
Fixed on the trunk.

[Bug c++/97740] [10/11/12/13 Regression] Weird error message about accessing a private member of my own class inside of std::string_view inside of constexpr

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

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

--- Comment #4 from Patrick Palka  ---
A C++14 version that's more similar to the original testcase using a generic
lambda and dependent initializer:

struct A {
  constexpr const int* get() const { return  }
private:
  int m = 42;
} a;

struct B { const int* p; };

template
void f() {
  [] (auto) {
constexpr B b = {arg->get()};
  }(0);
}

template void f<>();

[Bug ipa/105685] [10/11/12/13 Regression] Bogus `-Wsuggest-attribute=cold` on function already marked as `__attribute__((cold))`

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 54744
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54744=edit
gcc13-pr105865.patch

Untested fix.

[Bug c++/97740] [10/11/12/13 Regression] Weird error message about accessing a private member of my own class inside of std::string_view inside of constexpr

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

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |10.5
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=96716
Summary|Weird error message about   |[10/11/12/13 Regression]
   |accessing a private member  |Weird error message about
   |of my own class inside of   |accessing a private member
   |std::string_view inside of  |of my own class inside of
   |constexpr   |std::string_view inside of
   ||constexpr
 CC||jason at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org

--- Comment #3 from Patrick Palka  ---
Here's a reduced C++11 testcase that became rejects-valid after
r10-6416-g8fda2c274ac66d:

struct A {
  constexpr const int* get() const { return  }
private:
  int m = 42;
} a;

struct B { const int* p; };

template
void f() {
  constexpr B b = {a.get()};
}

template void f();

: In function ‘void f()’:
:11:25: error: ‘int A::m’ is private within this context
:4:7: note: declared private here
: In instantiation of ‘void f() [with  = int]’:
:14:22:   required from here
:11:25: error: ‘int A::m’ is private within this context
:4:7: note: declared private here

[Bug other/109163] SARIF (and other JSON) output files are non-deterministic

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

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

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

https://gcc.gnu.org/g:7f1e15f743357e037d7c4f6f6000863c26f3dfc3

commit r13-6851-g7f1e15f743357e037d7c4f6f6000863c26f3dfc3
Author: David Malcolm 
Date:   Fri Mar 24 11:38:14 2023 -0400

json: preserve key-insertion order [PR109163]

PR other/109163 notes that when we write out JSON files, we traverse
the keys within each object via hash_map iteration, and thus the
ordering is non-deterministic - it can arbitrarily vary from run to
run and from different machines, making it harder for users to compare
results and determine if anything has "really" changed.

I'm running into this issue with SARIF output, but there are several
places where we're currently emitting JSON:

  * -fsave-optimization-record emits SRCFILE.opt-record.json.gz
"This option is experimental and the format of the data within
the compressed JSON file is subject to change."; see
optinfo-emit-json.{h,cc}, dumpfile.cc, etc
  * -fdiagnostics-format= with the various "sarif" and "json" options
  * -fdump-analyzer-json is a developer option in the analyzer
  * gcov has:
 "-j, --json-format: Output JSON intermediate format into
 .gcov.json.gz file"

This patch adds an auto_vec to class json::object to preserve
key-insertion order, and use it when writing out objects.  Potentially
this slightly slows down JSON output, but I believe that this isn't
normally a bottleneck, and that the benefits to the user of
deterministic output are worth it.

I had first attempted to use ordered_hash_map.h for this, but ran into
impenetrable template errors, so this patch uses a simpler approach of
just adding an auto_vec to json::object.

Testing showed a failure of diagnostic-format-json-5.c, which was using
a convoluted set of regexps to consume the output; I believe that this
was brittle, and was intermittently failing for some of the random
orderings of output.  I rewrote these regexps to work with the expected
output order.  The other such tests seem to pass with the
now-deterministic orderings.

gcc/ChangeLog:
PR other/109163
* json.cc: Update comments to indicate that we now preserve
insertion order of keys within objects.
(object::print): Traverse keys in insertion order.
(object::set): Preserve insertion order of keys.
(selftest::test_writing_objects): Add an additional key to verify
that we preserve insertion order.
* json.h (object::m_keys): New field.

gcc/testsuite/ChangeLog:
PR other/109163
* c-c++-common/diagnostic-format-json-1.c: Update comment.
* c-c++-common/diagnostic-format-json-2.c: Likewise.
* c-c++-common/diagnostic-format-json-3.c: Likewise.
* c-c++-common/diagnostic-format-json-4.c: Likewise.
* c-c++-common/diagnostic-format-json-5.c: Rewrite regexps.
* c-c++-common/diagnostic-format-json-stderr-1.c: Update comment.

Signed-off-by: David Malcolm 

[Bug tree-optimization/109274] [13 Regression] ice in in_chain_p, at gimple-range-gori.cc:119 starting with r13-6787-g0963cb5fde158cce986

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Agree your patch is better, but can you please also include the Fortran
testcase from my patch?  Or I could commit it incrementally of course.

[Bug tree-optimization/109274] [13 Regression] ice in in_chain_p, at gimple-range-gori.cc:119 starting with r13-6787-g0963cb5fde158cce986

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

  Attachment #54742|0   |1
is obsolete||

--- Comment #6 from Andrew Macleod  ---
Created attachment 54743
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54743=edit
new patch

Before floating point relations were added, we tried to sanitize 
value-relation records to not include non-sensensical records... ie 
x != x or x < x.   Instead, we made a VREL_VARYING record with no 
operands. 

When floating point relations were supported, some of these were no 
longer non-sensical, AND we expanded the use of value_relation records 
into GORI. 

As a result, this sanitization is no longer needed.  The Oracle 
does not create records with op1 == op2, so its only within GORI 
that these records can exist, and we shouldn't try to interpret them. 

The bug occurs because the "sanitized" records doesn't set op1 and op2, and
changes the relation to VARYING..  and we have a record so expected the
operands it to be set the way they were just set.

We should not be setting a VREL_VARYING record if asked to set something else.

[Bug target/103628] ICE: Segmentation fault (in gfc_conv_tree_to_mpfr)

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

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

--- Comment #7 from Segher Boessenkool  ---
(In reply to HaoChen Gui from comment #5)
> The memory representation of IBM long double is not unique. It's actually
> the sum of two 64-bit doubles. 

Yes, and the first of those two DP numbers is required to be the full
number rounded to double precision (with round-to-nearest).

What happened here?  I cannot make much sense of those numbers, but it
seems to contain something with uppercase ASCII overwritten?

[Bug tree-optimization/109265] [13 Regression] ICE for 527.cam4_r after r13-6787-g0963cb5fde158c

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #10 from Jakub Jelinek  ---
Dup.

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

[Bug tree-optimization/109274] [13 Regression] ice in in_chain_p, at gimple-range-gori.cc:119 starting with r13-6787-g0963cb5fde158cce986

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||stefansf at linux dot ibm.com

--- Comment #5 from Jakub Jelinek  ---
*** Bug 109265 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/109274] [13 Regression] ice in in_chain_p, at gimple-range-gori.cc:119 starting with r13-6787-g0963cb5fde158cce986

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 54742
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54742=edit
gcc13-pr109274.patch

Full untested patch.

[Bug fortran/109275] Bad error messages for interfaces describing surrounding program unit

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Raoul Hidalgo Charman from comment #0)
> The following example, where an interface is defined for the surrounding
> program unit fails to compile:
> 
>   function foo(arg1) result(res)
> 
>   interface foo
> function foo(arg1)
>   integer*2 foo(3)
>   integer*8 arg1
> end function foo
>   end interface
> 
>   integer*2 res(3)
>   integer*8 arg1
>   res = (/1,2,int(arg1,4)/)
>   end function
> 
> Giving the error:
> 
> recursive-interface.f:4:8:
> 
> 4 | function foo(arg1)
>   |1
> Error: Procedure pointer result ‘foo’ at (1) is missing the pointer attribute
> 
> Given you can use this function with that interface, this appears to be an
> incorrect warning.

It's not a warning.  It is an error.  And, yes it seems wrong.

> 
> While I don't see any reason why a correctly defined interface would not be
> allowed, especially if it's not even used and result is used to disambiguate
> the symbol, other compilers do fail to compile and complain about using an
> interface with the same name as the surrounding program unit. XLF complained
> for normal interfaces, while Sun Studio just complains for generic interface.
> 
> GFortrans error message should at least be more informative, explicitly
> saying it's not allowed if this is the case.
> 
> I came across this issue because a library had an include with many
> interfaces, and was then trying to use some of those interfaces in the
> definitions of those program units.

It seems to be invalid Fortran.  From Fortran 2018

 C1501 (R1501) An interface-block in a subprogram shall not contain
 an interface-body for a procedure defined by that subprogram.

It seems gfortran is missing a check for C1501.

[Bug tree-optimization/109265] [13 Regression] ICE for 527.cam4_r after r13-6787-g0963cb5fde158c

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

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

--- Comment #9 from Jakub Jelinek  ---
Adjusted testcase:
module pr109265
  integer, parameter :: r8 = selected_real_kind (12)
contains
  subroutine foo (b, c, d, e, f)
implicit none
logical :: b
real (kind = r8) :: c, d, e, f, i
if (b) then
  c = bar (c * d, e)
  i = bar (f, c)
  call baz (i)
  call baz (-i)
end if
  end subroutine foo
  function bar (a, b)
implicit none
real (kind = r8) :: bar
real (kind = r8) :: a, b
bar = a + b
  end function bar
  subroutine baz (b)
implicit none
real (kind = r8) :: b, d, e, f, g, h, i
d = b
i = 0
e = d
f = d
g = d
  10 continue
if ((e.eq.d) .and. (f.eq.d) .and. (g.eq.d) .and. (h.eq.d)) then
  h = i
  go to 10
end if
  end subroutine baz
end module pr109265

It uses one uninitialized variable (h, D2 in the above one; but we shouldn't
ICE on it).

[Bug ipa/107769] [12/13 Regression] -flto with -Os/-O2/-O3 emitted code with gcc 12.x segfaults via mutated global in .rodata since r12-2887-ga6da2cddcf0e959d

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

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

Martin Jambor  changed:

   What|Removed |Added

   Assignee|hubicka at gcc dot gnu.org |jamborm at gcc dot 
gnu.org

--- Comment #4 from Martin Jambor  ---
Indeed, I hope I know what is going on.

[Bug tree-optimization/109265] [13 Regression] ICE for 527.cam4_r after r13-6787-g0963cb5fde158c

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

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

--- Comment #8 from Jakub Jelinek  ---
My PR109274 patch fixes this too.

[Bug tree-optimization/109238] [13 Regression] tst-realloc.i:42:19: error: pointer ‘p’ may be used after ‘realloc’ [-Werror=use-after-free] in glibc tests

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

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

--- Comment #9 from Andrew Macleod  ---
fixed.

[Bug libgcc/109270] ssp/ssp.h should be adapted to use __builtin_dynamic_object_size()

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

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

Siddhesh Poyarekar  changed:

   What|Removed |Added

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

[Bug driver/108865] gcc on Windows fails with Unicode path to source file

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||jdx at o2 dot pl

--- Comment #30 from Richard Biener  ---
*** Bug 109188 has been marked as a duplicate of this bug. ***

[Bug bootstrap/109188] Building genmodes under MinGW-W64/MSYS2 fails due to undefined HOST_EXTRA_OBJS_SYMBOL

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #16 from Richard Biener  ---
duplicate

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

[Bug tree-optimization/109274] [13 Regression] ice in in_chain_p, at gimple-range-gori.cc:119 starting with r13-6787-g0963cb5fde158cce986

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

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

--- Comment #3 from Jakub Jelinek  ---
I think:
--- gcc/gimple-range-gori.cc.jj 2023-03-23 15:25:47.060741116 +0100
+++ gcc/gimple-range-gori.cc2023-03-24 14:30:38.272043631 +0100
@@ -632,10 +632,11 @@ gori_compute::compute_operand_range (vra
   if (!vrel_ptr && k == VREL_VARYING && op1 == op2)
k = VREL_EQ;
   if (k != VREL_VARYING)
-   {
-vrel.set_relation (k, op1, op2);
-vrel_ptr = 
-   }
+   {
+ vrel.set_relation (k, op1, op2);
+ if (vrel.kind () != VREL_VARYING)
+   vrel_ptr = 
+   }
 }

   // Handle end of lookup first.
should fix this.

[Bug tree-optimization/109238] [13 Regression] tst-realloc.i:42:19: error: pointer ‘p’ may be used after ‘realloc’ [-Werror=use-after-free] in glibc tests

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Andrew Macleod :

https://gcc.gnu.org/g:0409aa5a2de9ce3164933814a4a7adc91f6acb96

commit r13-6850-g0409aa5a2de9ce3164933814a4a7adc91f6acb96
Author: Andrew MacLeod 
Date:   Thu Mar 23 10:28:34 2023 -0400

Ranger cache dominator queries should ignore backedges.

When querying dominators for cache values, ignore back edges in
read-only mode.

PR tree-optimization/109238
gcc/
* gimple-range-cache.cc (ranger_cache::resolve_dom): Ignore
predecessors which this block dominates.

gcc/testsuite/
* gcc.dg/pr109238.c: New.

[Bug target/109137] [12 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75

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

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

--- Comment #20 from Vladimir Makarov  ---
(In reply to CVS Commits from comment #19)
> The master branch has been updated by Jakub Jelinek :
> 
> https://gcc.gnu.org/g:0d9e52675c009139a14182d92ddb446ba2feabce
> 
> commit r13-6846-g0d9e52675c009139a14182d92ddb446ba2feabce
> Author: Jakub Jelinek 
> Date:   Fri Mar 24 09:42:18 2023 +0100
> 
> testsuite: Fix up gcc.target/i386/pr109137.c testcase [PR109137]
> 
> The testcase has a couple of small problems:
> 1) had -m32 in dg-options, that should never be done, instead the test
>should be guarded on ia32
> 2) adds -fPIC unconditionally (that should be guarded on fpic effective
>target)
> 3) using #include  for a RA test seems unnecessary,
> __builtin_memset
>handles it without the header

Thank you for the test correction, Jakub.

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #21 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #20 from Jakub Jelinek  ---
> Tried valgrind on the cross d21 on x86_64 and didn't see anything.
> Perhaps modify the makefiles such that it uses -fdump-tree-all -da already 
> when
> compiling typeinfo.lo?

I'll give that a whirl.  However, my SPARC box is pretty busy right now
with the weekly bootstraps, so this will be later this weekend only.

In the meantime, I try to reproduce the issue on gcc211.