[Bug middle-end/102519] [12 Regression] VRP Jump threader memory explosion

[aldyh at redhat dot com via Gcc-bugs]

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

--- Comment #21 from Aldy Hernandez  ---
However, if you care to test a patch, I'd be happy to review it.

On Thu, Sep 30, 2021 at 7:49 AM aldot at gcc dot gnu.org
 wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
>
> Bernhard Reutner-Fischer  changed:
>
>What|Removed |Added
> 
>  CC||aldot at gcc dot gnu.org
>
> --- Comment #19 from Bernhard Reutner-Fischer  ---
> so as asked in
> https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580485.html what 
> about
> dominance_info?
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>

[Bug middle-end/102519] [12 Regression] VRP Jump threader memory explosion

[aldyh at redhat dot com via Gcc-bugs]

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

--- Comment #20 from Aldy Hernandez  ---
Doesn't make a difference.  If the blocks are stale, they need to be
reconstructed anyhow.  It's preexisting behavior in VRP anyhow.

I heard you the first time ;-).

On Thu, Sep 30, 2021 at 7:49 AM aldot at gcc dot gnu.org
 wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
>
> Bernhard Reutner-Fischer  changed:
>
>What|Removed |Added
> 
>  CC||aldot at gcc dot gnu.org
>
> --- Comment #19 from Bernhard Reutner-Fischer  ---
> so as asked in
> https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580485.html what 
> about
> dominance_info?
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>

[Bug middle-end/102519] [12 Regression] VRP Jump threader memory explosion

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

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

Bernhard Reutner-Fischer  changed:

   What|Removed |Added

 CC||aldot at gcc dot gnu.org

--- Comment #19 from Bernhard Reutner-Fischer  ---
so as asked in
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580485.html what about
dominance_info?

[Bug objc/102537] New: Objective-C: can't use >= USE_FIXUP_BEFORE paths for non-Darwin

[mhjacobson at me dot com via Gcc-bugs]

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

Bug ID: 102537
   Summary: Objective-C: can't use >= USE_FIXUP_BEFORE paths for
non-Darwin
   Product: gcc
   Version: 10.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: objc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mhjacobson at me dot com
  Target Milestone: ---

I am working on a NeXTv2-ABI-compatible Objective-C runtime for a non-Darwin
platform (AVR micros).  I'd like my Objective-C code to make use of the most
modern ABI features, namely those guarded in the code by `flag_next_runtime >=
USE_FIXUP_BEFORE`.

However, there appears to be no way to control `flag_next_runtime` (short of
modifying the compiler source).  I can set it to zero with `-fgnu-runtime` or
one with `-fnext-runtime`, but `USE_FIXUP_BEFORE` is an encoded Mac OS X
version (namely 100600, referring to Snow Leopard).

There is Darwin-specific option parsing code (`darwin_override_options()`) that
appears to set `flag_next_runtime` based on `-mmacosx-version-min`, but
obviously that doesn't run for non-Darwin targets.

I could imagine a few approaches to fixing this:

1. Parse `-mmacosx-version-min` even when the target is not Darwin, whenever
we're compiling Objective-C.  On non-Darwin, this would be interpreted as
requesting Objective-C codegen compatible with the Objective-C ABI of the
specified release of Mac OS X.

2. Allow an argument to `-fnext-runtime`, with the meaning approximately the
same as in #1.

3. Instead of using `flag_next_runtime` as a version number, switch it back to
being zero or one, and use a separate flag (perhaps the existing
`-fobjc-abi-version`?) to differentiate ABIs.

[Bug c++/102536] New: [modules] ICE Error reporting routines re-entered

[johelegp at gmail dot com via Gcc-bugs]

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

Bug ID: 102536
   Summary: [modules] ICE Error reporting routines re-entered
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johelegp at gmail dot com
CC: johelegp at gmail dot com
  Target Milestone: ---

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

mod.cpp:
```C++
export module mod;

namespace mod {

export struct X {
  X() { }

  constexpr void f() {
[](auto) { }(0);
  }
};

}
```

test.cpp:
```C++
import mod;

int main() {
  mod::X{}.f();
}
```

```
Internal compiler error: Error reporting routines re-entered.
0x1fe6b9d error_at(unsigned int, char const*, ...)
???:0
0x989719 lazy_load_pendings(tree_node*)
???:0
0x994388 get_class_binding(tree_node*, tree_node*, bool)
???:0
0xa953ce dfs_walk_all(tree_node*, tree_node* (*)(tree_node*, void*), tree_node*
(*)(tree_node*, void*), void*)
???:0
0xa9558c lookup_member(tree_node*, tree_node*, int, bool, int,
access_failure_info*)
???:0
0x91b9aa lambda_function(tree_node*)
???:0
0x2003411 pp_format(pretty_printer*, text_info*)
???:0
0x2003a90 pp_format_verbatim(pretty_printer*, text_info*)
???:0
0x2003b71 pp_verbatim(pretty_printer*, char const*, ...)
???:0
0x1fe5b51 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
???:0
0x1fe6b9d error_at(unsigned int, char const*, ...)
???:0
0x989719 lazy_load_pendings(tree_node*)
???:0
0x994388 get_class_binding(tree_node*, tree_node*, bool)
???:0
0xa953ce dfs_walk_all(tree_node*, tree_node* (*)(tree_node*, void*), tree_node*
(*)(tree_node*, void*), void*)
???:0
0xa9558c lookup_member(tree_node*, tree_node*, int, bool, int,
access_failure_info*)
???:0
0x91b9aa lambda_function(tree_node*)
???:0
0x93419b mangle_decl(tree_node*)
???:0
0x14c5f02 decl_assembler_name(tree_node*)
???:0
0xc70f8a cgraph_node::finalize_function(tree_node*, bool)
???:0
0x9873f8 module_state::read_cluster(unsigned int)
???:0
```

[Bug c++/102535] New: __is_trivially_constructible rejects some trivial cases in aggregate initializations

[de34 at live dot cn via Gcc-bugs]

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

Bug ID: 102535
   Summary: __is_trivially_constructible rejects some trivial
cases in aggregate initializations
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: de34 at live dot cn
  Target Milestone: ---

It seems that gcc's __is_trivially_constructible (the underlying mechanism of
std::is_trivially_constructible in libstdc++) gives inconsistent answers to
whether aggregate initializations performed by direct-non-list-initializations
(available since C++20) affect triviality of operations.

#include 
#include 

struct A { int x; };
struct B { float y; };
struct C { A a; B b; };

int main()
{
#if __cpp_aggregate_paren_init >= 201902L 
std::cout
<< std::is_constructible_v << '\n'   // 1
<< std::is_constructible_v << '\n'// 1
<< !std::is_constructible_v << '\n'  // 1
<< std::is_trivially_constructible_v << '\n' // 1
<< std::is_trivially_constructible_v << '\n'; // 0, seems
buggy
#endif
}

According to the definitions, initialization of a C variable from A or A and B
(both treated as xvalues according to [meta.unary.prop]/8) only calls trivial
move constructors. It seems unreasonable that
std::is_trivially_constructible_v is true but
std::is_trivially_constructible_v is false, they should be both true
in C++20.

This bug has been existing since gcc 10.1.0, and is not fixed in 12.0.0
20210721:
https://wandbox.org/permlink/L0ZLipQZLsCOqYcT
https://wandbox.org/permlink/lBwowJpeFshRC03z

[Bug target/102169] powerpc64 int memory operations using FP instructions

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

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

HaoChen Gui  changed:

   What|Removed |Added

 CC||guihaoc at gcc dot gnu.org

--- Comment #4 from HaoChen Gui  ---
In this case, it picks up "GEN_OR_VSX_REGS" as FLOAT_REGS costs zero in ira
pass. There is a "d,Z" alternative pair in "*movsi_internal1" expand. When the
second operand is not a "indexed_or_indirect_operand", the reload is need. In
this case, the reload is needed when it's a d-form address and doesn't match
the 'Z'. So we should punish the reload of 'Z'. Change the alternative to '^Z'.

[Bug c/80454] -Wmissing-braces wrongly warns about universal zero initializer {0}

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed|2017-08-01 00:00:00 |2021-9-29
   Severity|normal  |enhancement

--- Comment #5 from Andrew Pinski  ---
clang no longer warns with their C front-end.

[Bug c/68725] suboptimal handling of constant compound literals

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

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

--- Comment #4 from Andrew Pinski  ---
The copy on the stack is correct as the variable is considered a local variable
and has its address taken 

[Bug c/71188] missing warning converting constant integer expression zero to pointer

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed|2017-07-29 00:00:00 |2021-9-29
   Severity|normal  |enhancement

[Bug target/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails

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

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

--- Comment #9 from Peter Bergner  ---
(In reply to Patrick McGehearty from comment #8)
> Thanks again for helping this fix move forward.

If you have another patch you want me to test, just send it to me and I'll kick
it off.

[Bug middle-end/102519] [12 Regression] VRP Jump threader memory explosion

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

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

--- Comment #18 from David Edelsohn  ---
Yea!  That fixes the *worst* of the memory growth problem for me.

It still is growing, but much more slowly.  RSS now grows from 569788 to 642076
for the final function, instead of 783896 before it died on an intermediate
function.

Definitely an improvement and good catch.

[Bug middle-end/102519] [12 Regression] VRP Jump threader memory explosion

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

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

--- Comment #17 from Jeffrey A. Law  ---
Consider that pre-approved.

[Bug bootstrap/102527] [12 regression] out of memory compiling insn-emit.c

[aldyh at redhat dot com via Gcc-bugs]

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

--- Comment #11 from Aldy Hernandez  ---
This looks mighty suspicious ;-)

diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index 69a3ab0ea9d..c24c67f8874 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -4408,6 +4408,7 @@ hybrid_threader::~hybrid_threader ()
   delete m_threader;
   delete m_state;
   delete m_ranger;
+  delete m_query;

   scev_finalize ();
   loop_optimizer_finalize ();

[Bug middle-end/102519] [12 Regression] VRP Jump threader memory explosion

[aldyh at redhat dot com via Gcc-bugs]

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

--- Comment #16 from Aldy Hernandez  ---
On Wed, Sep 29, 2021 at 10:46 PM dje at gcc dot gnu.org
 wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
>
> --- Comment #15 from David Edelsohn  ---
> I annotated execute_vrp_threader() to call getrusage() and print the size of
> RSS around each call to threader.thread_jumps().  It consistently is growing,
> but not in the threader itself.  Was the former VPR Threader intentionally or
> implicitly freeing some other data allocated by the compiler that the new
> threader is not cleaning up?

Huh.  Very good insight.

:-)

diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index 69a3ab0ea9d..c24c67f8874 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -4408,6 +4408,7 @@ hybrid_threader::~hybrid_threader ()
   delete m_threader;
   delete m_state;
   delete m_ranger;
+  delete m_query;

   scev_finalize ();
   loop_optimizer_finalize ();

[Bug target/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails

[patrick.mcgehearty at oracle dot com via Gcc-bugs]

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

--- Comment #8 from Patrick McGehearty  
---
Thanks for the run.

On the plus side, I would expect FAIL or PASS to be consistent
for all optimization levels, so that's actually good that
they all match now.

I'm either I'm mistaken about the root cause of the failure
or I've made some goof in my fix.

... break to reexamine the tests I did...

got back on gcc135.fsffrance.org and looked carefully at the
tests I ran.  I see where I went wrong. In my manual testing,
I set RBIG, RMIN, RMIN2, RMINSCAL and RMAX2 all to double
precision values instead of long double precision values.
When I modified the libgcc2.c file, I only changed the
RMINSCAL and RMAX2 (which depended DBL_EPSILON).
I just created and ran a new manual test which only changes
RMINSCAL and RMAX2. It fails. Oops...
I'm pretty sure of the fix, but I will take the time to be
careful and submit a revised patch (V6) soon.

My challenge is that the very old glibc on gcc135.fsffrance.org
does not know about _TF_ vs _KF_ and _IF_. It refused to
build the new libgcc/config/rs6000/_divkc3.c file.
That's why I did not test the result in place.

It just occurred to me that if I remove _KF_ references in that
file and build a test compiler, that will give me a way to
test the ibm doubledouble code generated by libgcc/libgcc2.c

Thanks again for helping this fix move forward.

- patrick




On 9/29/2021 4:46 PM, bergner at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104
>
> --- Comment #7 from Peter Bergner  ---
> (In reply to Peter Bergner from comment #6)
>> Ah, the v5 patch.  I'll bootstrap and regtest the patch and report back.
> Building with and without the patch, I'm seeing:
>
> +FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O0
>   FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O1
>   FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O2
>   FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O2 -flto
> -fno-use-linker-plugin -flto-partition=none
>   FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O2 -flto
> -fuse-linker-plugin -fno-fat-lto-objects
>   FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O3
> -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-fu
> nctions
>   FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O3 -g
> +FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -Og -g
>   FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -Os
>
> So 2 new FAILs and no new PASSes with the patch. :-(
> Is there anything you want me to check?
>

[Bug debug/102534] RFE epilog is not reliably a statement with inlining

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

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

--- Comment #3 from Andrew Pinski  ---
With -O1 or -O2 (and -g2), there are no .loc for line 6 at all.


There might not be anything that can be done for that case as inlining removes
it 

[Bug debug/102534] RFE epilog is not reliably a statement with inlining

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|RFE epilog is not reliably  |RFE epilog is not reliably
   |a statement with|a statement with inlining
   |optimization|

--- Comment #2 from Andrew Pinski  ---
-Og -g2 GCC produces:

.loc 1 5 4 is_stmt 0 view .LVU3
movl$0, %eax
callprintf
.LVL2:
.loc 1 6 1 view .LVU4
addq$8, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc

Which looks good too.

So this must be an issue with inlining.

[Bug debug/102534] RFE epilog is not reliably a statement with optimization

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|RFE epilog is not reliably  |RFE epilog is not reliably
   |a statement |a statement with
   ||optimization

--- Comment #1 from Andrew Pinski  ---
For -O0 -g we get:

callprintf
.loc 1 6 1
nop
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc


Oh you are doing this at -O2.

[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c

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

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

--- Comment #8 from qinzhao at gcc dot gnu.org ---
the ICE is triggered by the following IR:

MEM[(int[0:D.1993] *)] = .DEFERRED_INIT (16, 2, 1);

which is transformed from the original IR:

(*fb.1_9) = .DEFERRED_INIT (16, 2, 1);

[Bug debug/102534] New: RFE epilog is not reliably a statement

[woodard at redhat dot com via Gcc-bugs]

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

Bug ID: 102534
   Summary: RFE epilog is not reliably a statement
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: woodard at redhat dot com
  Target Milestone: ---

Created attachment 51523
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51523=edit
demonstration program

Given a program like this:

 1  #include 
 2   
 3  static void do_print(char *s)
 4  {
 5 printf("%s", s);
 6  }
 7   
 8  int main(int argc, char *argv[])
 9  {
10 int i = 0;
11 for (;;) {
12do_print(argv[i]);
13i++;
14if (argv[i] == NULL) {
15   do_print("\n");
16   return 0;
17}
18do_print(", ");
19 }
20 #ifdef BAD_MATT_CODE
21 //no longer used
22 return -1;
23 }
24 #endif
25  }
26   
27  /**
28  * Just a comment taking a few lines of code
29  * What do you call cheese that isn't yours?
30  * Nacho cheese.
31  **/
32  int unused_variable;
33   
34  void unused_function()
35  {
36 printf("I'm not called anywhere\n");
37  }

When you try to set a breakpoint on the closing brace of a function, it skips
to the beginning of the next function in the file:

$ gdb a.out 
GNU gdb (GDB) Fedora 10.2-3.fc34
Reading symbols from a.out...
(gdb) break 6
Breakpoint 1 at 0x401060: file line-range.c, line 9.

That is the start of main() which is not what was intended which I would assert
means “break before you leave the context of do_print()” in other words the
epilog of the function. 

On the other hand “b 5” works as expected

(gdb) break 5
Breakpoint 2 at 0x401070: /home/ben/Shared/test/line-ranges/line-range.c:5. (3
locations)
(gdb) info break
Num Type   Disp Enb AddressWhat
1   breakpoint keep y   0x00401060 in main at line-range.c:9
2   breakpoint keep y
2.1 y   0x00401070 in do_print at
line-range.c:5
2.2 y   0x00401081 in do_print at
line-range.c:5
2.3 y   0x0040109a in do_print at
line-range.c:5

In that particular case the function ends up being inlined and the "ret"
instruction where the epilog is_stmt would be has been eliminated. We believe
it should still mark the first instruction after the code from the function.
Where their would have been a ret.

It isn't just inline functions are affected.

(gdb) break 25
Breakpoint 1 at 0x4011a0: file line-range.c, line 35.

Once again this the first instruction of the function defined after the one
where the epilog for main should be. There is even a ret instruction there:

(gdb) disassemble main
Dump of assembler code for function main:
   0x00401060 <+0>: push   %rbx
   0x00401061 <+1>: mov%rsi,%rbx
   0x00401064 <+4>: jmp0x401081 
   0x00401066 <+6>: nopw   %cs:0x0(%rax,%rax,1)
   0x00401070 <+16>:mov$0x402013,%esi
   0x00401075 <+21>:mov$0x402010,%edi
   0x0040107a <+26>:xor%eax,%eax
   0x0040107c <+28>:call   0x401050 
   0x00401081 <+33>:mov(%rbx),%rsi
   0x00401084 <+36>:xor%eax,%eax
   0x00401086 <+38>:mov$0x402010,%edi
   0x0040108b <+43>:add$0x8,%rbx
   0x0040108f <+47>:call   0x401050 
   0x00401094 <+52>:cmpq   $0x0,(%rbx)
   0x00401098 <+56>:jne0x401070 
   0x0040109a <+58>:mov$0xa,%edi
   0x0040109f <+63>:call   0x401030 
   0x004010a4 <+68>:xor%eax,%eax
   0x004010a6 <+70>:pop%rbx
   0x004010a7 <+71>:ret
End of assembler dump.

it even has linemap entries

$ readelf --debug-dump=decodedline a.out | egrep ^File\|25
File nameLine numberStarting addressView   
Stmt
line-range.c  250x4010a4   2
line-range.c  250x4010a8

But the problem seems to be that none of the linemap entries is adorned with
is_stmt. We believe that that should point at 4010a7.

Putting the is-stmt for the closing brace of a functopm on the ret instruction
of normal extern function is easy but we would like all the other complicating
situations to be handled as well some of which include: 

- inline functions
- void functions
- multiple returns from a function
- functions which optimize into being empty.
- external functions that are not used but could be called from another
function in a different CU. However that means that they could be dropped 

[Bug bootstrap/102527] [12 regression] out of memory compiling insn-emit.c

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

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

--- Comment #10 from Rainer Orth  ---
(In reply to Aldy Hernandez from comment #6)
> The attached patch adds a separate TV_* timer to see the actual break down
> for VRP and the VRP threader.
> 
> Could you incorporate this patch and run the problematic file with ./cc1
> -ftime-report -O2?  I'd like to see the table at the end.  If you're so
> inclined, could you also email me the entire -ftime-report so I can see the
> GC output as it compiles?

Sure: I've attached the output of

cc1plus -fpreprocessed insn-emit.ii -quiet -mtune=generic -march=pentium4 -g
-O2 -o insn-emit.s -ftime-report

[Bug bootstrap/102527] [12 regression] out of memory compiling insn-emit.c

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

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

--- Comment #9 from Rainer Orth  ---
Created attachment 51522
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51522=edit
insn-emit.ii -ftime-report output

[Bug target/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails

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

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

--- Comment #7 from Peter Bergner  ---
(In reply to Peter Bergner from comment #6)
> Ah, the v5 patch.  I'll bootstrap and regtest the patch and report back. 

Building with and without the patch, I'm seeing:

+FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O0 
 FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O1 
 FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O2 
 FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O2 -flto
-fno-use-linker-plugin -flto-partition=none 
 FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects 
 FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-fu
nctions 
 FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O3 -g 
+FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -Og -g 
 FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -Os 

So 2 new FAILs and no new PASSes with the patch. :-(
Is there anything you want me to check?

[Bug fortran/102521] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:6240

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

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

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 ---
Possibly related:

program p
  type t
 integer :: n
  end type
  type(t), parameter :: a(4)   = t(1)
  type(t), parameter :: c(*)   = a
end

This gives an ICE already in add_init_expr_to_sym.
So we likely screw up long before trans*.

[Bug bootstrap/102527] [12 regression] out of memory compiling insn-emit.c

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

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

--- Comment #8 from Rainer Orth  ---
Created attachment 51521
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51521=edit
i386-pc-solaris2.11 insn-emit.ii

[Bug bootstrap/102527] [12 regression] out of memory compiling insn-emit.c

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

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

--- Comment #7 from Rainer Orth  ---
(In reply to Aldy Hernandez from comment #4)

> Can it be reproduced on a cross?  If so, could you post the .ii file with
> your include file peculiarities?

I haven't tried, but expect it should work, provided you run on a 32-bit host
and perhaps limit VM consumption.  I expect that depending on the host OSes
VM layout cc1plus may be able to use more of the 4 GB address space on one OS
than the other.

That said, there's a weird problem:

If I run a regular build, I get the `out of memory' error reported.  Just
adding
-save-temps to the command line produces a couple of weird warnings/errors:

/var/gcc/reghunt/master/gcc/config/i386/i386.md: In function ‘rtx_insn*
gen_split_495(rtx_insn*, rtx_def**)’:
/var/gcc/reghunt/master/gcc/config/i386/i386.md:20130:29: error: this statement
may fall through [-Werror=implicit-fallthrough=]
20130 |   code = swap_condition (code);
  |  ~~~^~
/var/gcc/reghunt/master/gcc/config/i386/i386.md:20133:5: note: here
20133 | case GE: case GEU:
  | ^~~~
/var/gcc/reghunt/master/gcc/config/i386/i386.md: In function ‘rtx_insn*
gen_split_496(rtx_insn*, rtx_def**)’:
/var/gcc/reghunt/master/gcc/config/i386/i386.md:20130:29: error: this statement
may fall through [-Werror=implicit-fallthrough=]
20130 |   code = swap_condition (code);
  |  ~~~^~
/var/gcc/reghunt/master/gcc/config/i386/i386.md:20133:5: note: here
20133 | case GE: case GEU:
  | ^~~~
/var/gcc/reghunt/master/gcc/config/i386/i386.md: In function ‘rtx_insn*
gen_split_497(rtx_insn*, rtx_def**)’:
/var/gcc/reghunt/master/gcc/config/i386/i386.md:20130:29: error: this statement
may fall through [-Werror=implicit-fallthrough=]
20130 |   code = swap_condition (code);
  |  ~~~^~
/var/gcc/reghunt/master/gcc/config/i386/i386.md:20133:5: note: here
20133 | case GE: case GEU:
  | ^~~~
/var/gcc/reghunt/master/gcc/config/i386/i386.md: In function ‘rtx_insn*
gen_split_498(rtx_insn*, rtx_def**)’:
/var/gcc/reghunt/master/gcc/config/i386/i386.md:20130:29: error: this statement
may fall through [-Werror=implicit-fallthrough=]
20130 |   code = swap_condition (code);
  |  ~~~^~
/var/gcc/reghunt/master/gcc/config/i386/i386.md:20133:5: note: here
20133 | case GE: case GEU:
  | ^~~~
/var/gcc/reghunt/master/gcc/config/i386/i386.md: In function ‘rtx_insn*
gen_split_499(rtx_insn*, rtx_def**)’:
/var/gcc/reghunt/master/gcc/config/i386/i386.md:20130:29: error: this statement
may fall through [-Werror=implicit-fallthrough=]
20130 |   code = swap_condition (code);
  |  ~~~^~
/var/gcc/reghunt/master/gcc/config/i386/i386.md:20133:5: note: here
20133 | case GE: case GEU:
  | ^~~~
/var/gcc/reghunt/master/gcc/config/i386/i386.md: In function ‘rtx_insn*
gen_split_500(rtx_insn*, rtx_def**)’:
/var/gcc/reghunt/master/gcc/config/i386/i386.md:20130:29: error: this statement
may fall through [-Werror=implicit-fallthrough=]
20130 |   code = swap_condition (code);
  |  ~~~^~
/var/gcc/reghunt/master/gcc/config/i386/i386.md:20133:5: note: here
20133 | case GE: case GEU:
  | ^~~~
/var/gcc/reghunt/master/gcc/config/i386/i386.md: In function ‘rtx_insn*
gen_split_501(rtx_insn*, rtx_def**)’:
/var/gcc/reghunt/master/gcc/config/i386/i386.md:20130:29: error: this statement
may fall through [-Werror=implicit-fallthrough=]
20130 |   code = swap_condition (code);
  |  ~~~^~
/var/gcc/reghunt/master/gcc/config/i386/i386.md:20133:5: note: here
20133 | case GE: case GEU:
  | ^~~~
/var/gcc/reghunt/master/gcc/config/i386/i386.md: In function ‘rtx_insn*
gen_split_502(rtx_insn*, rtx_def**)’:
/var/gcc/reghunt/master/gcc/config/i386/i386.md:20130:29: error: this statement
may fall through [-Werror=implicit-fallthrough=]
20130 |   code = swap_condition (code);
  |  ~~~^~
/var/gcc/reghunt/master/gcc/config/i386/i386.md:20133:5: note: here
20133 | case GE: case GEU:
  | ^~~~
/var/gcc/reghunt/master/gcc/config/i386/sse.md: In function ‘rtx_insn*
gen_split_2186(rtx_insn*, rtx_def**)’:
/var/gcc/reghunt/master/gcc/config/i386/sse.md:18256:19: error: this statement
may fall through [-Werror=implicit-fallthrough=]
18256 |   operands[1] = tmp;
  |   ^
/var/gcc/reghunt/master/gcc/config/i386/sse.md:18258:5: note: here
18258 | case 32:
  | ^~~~
/var/gcc/reghunt/master/gcc/config/i386/sse.md: In function ‘rtx_insn*
gen_split_2187(rtx_insn*, rtx_def**)’:
/var/gcc/reghunt/master/gcc/config/i386/sse.md:18256:19: error: this statement
may fall through [-Werror=implicit-fallthrough=]
18256 |   operands[1] = tmp;
  |   ^
/var/gcc/reghunt/master/gcc/config/i386/sse.md:18258:5: 

[Bug fortran/102510] Function call has unnecessary stride check

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #5 from anlauf at gcc dot gnu.org ---
If you collect your procedures in a separate file, there is the possible
question of what happens when you "use" these in another module.

A possible expectation is that this situation should be handled with LTO.
I have not checked whether this works (at the time of writing), though.

I'ld like to close this issue for now.  Please reopen or open a new one
if you think there is room for improvement.

[Bug middle-end/102519] [12 Regression] VRP Jump threader memory explosion

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

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

--- Comment #15 from David Edelsohn  ---
I annotated execute_vrp_threader() to call getrusage() and print the size of
RSS around each call to threader.thread_jumps().  It consistently is growing,
but not in the threader itself.  Was the former VPR Threader intentionally or
implicitly freeing some other data allocated by the compiler that the new
threader is not cleaning up?

Assembling  functions:
 f_0_0_0
RSS = 569788
RSS = 569788
RSS = 569792
RSS = 569792
 g_0_0_0
RSS = 569876
RSS = 569876
RSS = 569880
RSS = 569880
 f_0_0_1
RSS = 569880
RSS = 569880
RSS = 569884
RSS = 569884
...
g_17_15_17
RSS = 783824
RSS = 783824
RSS = 783836
RSS = 783836
 f_17_15_23
RSS = 783892
RSS = 783892
RSS = 783896
RSS = 783896

cc1: out of memory allocating 65536 bytes after a total of 1071909664 bytes

[Bug debug/102507] ICE in btf_finalize when compiling with -gbtf

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Indu Bhagat :

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

commit r12-3972-gd6a87d96d7473cbd2404d5dcc7eef36a7f53b2b2
Author: Indu Bhagat 
Date:   Wed Sep 29 13:25:39 2021 -0700

debug/102507: ICE in btf_finalize when compiling with -gbtf

Fix the free up of btf_var_ids hash_map in btf_finalize ().

gcc/ChangeLog:

PR debug/102507
* btfout.c (GTY): Add GTY (()) albeit for cosmetic only purpose.
(btf_finalize): Empty the hash_map btf_var_ids.

[Bug target/101985] vec_cpsgn parameter order

[simb611alt at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Kunwar Maheep Singh  ---
(In reply to Bill Schmidt from comment #3)
> Kunwar, can you please tell us (if you don't mind) where the problem was
> detected?  Since we're changing behavior of the intrinsic, we'll need to
> document this, and knowing whether we have problematic code in the wild that
> relies on present behavior would be helpful.

I detected it in SIMDe (https://github.com/simd-everywhere/simde).
Relevant commit -
https://github.com/simd-everywhere/simde/commit/1ba15969fdc1b302c0e50084420412368a14cd96

[Bug fortran/102458] ICE tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136

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

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

--- Comment #13 from anlauf at gcc dot gnu.org ---
Corrected patch that addresses the remaining issue (for valid code):

https://gcc.gnu.org/pipermail/fortran/2021-September/056599.html

[Bug target/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails

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

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

--- Comment #6 from Peter Bergner  ---
(In reply to Patrick McGehearty from comment #5)
> I submitted a patch that I believe resolves the issue on Aug 27, 2021
> and pinged the gcc-patches list on Sept 8, 2021. Allowing for the
> 'distraction' of Linux Plumbers conference last week, I'm hoping
> someone will try out my patch on a modern rs6000 environment to
> confirm it works as expected.

Ah, the v5 patch.  I'll bootstrap and regtest the patch and report back. 
Thanks!

[Bug fortran/102533] ICE in gfc_set_backend_locus, at fortran/trans.c:1861

[gscfq--- via Gcc-bugs]

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

G. Steinmetz  changed:

   What|Removed |Added

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

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

$ cat z2.f90   # invalid, this is file za000.f90
end;&



$ cat generator_backend_locus.f90
program generate_backend_locus
   implicit none
   character(16) :: file
   integer :: k
   do k = 0, 255
  write (file, '(a,i3.3,a)')   'za', k, '.f90'
  open (1, file=file)
  write (1, '(a)')   'end;' // char(k) // '&'
  write (1, '(a)')   ' '
  close (1)
   end do
   do k = 0, 255
  write (file, '(a,i3.3,a)')   'zb', k, '.f90'
  open (1, file=file)
  write (1, '(a)')   'end;&'
  write (1, '(a)')   char(k)
  close (1)
   end do
end

[Bug fortran/102533] New: ICE in gfc_set_backend_locus, at fortran/trans.c:1861

[gscfq--- via Gcc-bugs]

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

Bug ID: 102533
   Summary: ICE in gfc_set_backend_locus, at fortran/trans.c:1861
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Running the generator from comment 1 will produce a number of files,
some of them are valid, some are invalid (see F2018 6.1.6).
An ICE occurs with char(k), k=0,9,10,12,13,32,33,59.
Affects versions down to at least r5.


$ cat z1.f90   # valid, this is file zb033.f90
end;&
!


$ gfortran-12-20210926 -c z1.f90
f951: Warning: Inconsistent internal state: No location in statement
f951: internal compiler error: Segmentation fault
0xd400cf crash_signal
../../gcc/toplev.c:328
0x849958 gfc_set_backend_locus(locus*)
../../gcc/fortran/trans.c:1861
0x864e70 build_function_decl
../../gcc/fortran/trans-decl.c:2398
0x86ab16 gfc_create_function_decl(gfc_namespace*, bool)
../../gcc/fortran/trans-decl.c:3105
0x871176 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6813
0x7f6646 translate_all_program_units
../../gcc/fortran/parse.c:6572
0x7f6646 gfc_parse_file()
../../gcc/fortran/parse.c:6841
0x842daf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:216

[Bug fortran/102456] ICE in gfc_check_rank, at fortran/check.c:4594

[gscfq--- via Gcc-bugs]

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

--- Comment #2 from G. Steinmetz  ---

It compiles when using "size(shape(x))" as a synonym for "rank(x)".
And indeed, that scalar x (from image 1) has rank 0.

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

$ gfortran-12 -c z2.f90 -fcoarray=lib
$

---

Simplified a bit with "integer" instead of "type(t)".
All of the following variants work i.e. with -fcoarray=single :


$ cat z4.f90
program p
   integer :: a
   integer :: b(2)
   integer :: c(2,3)
   integer :: d(2,3,5)
   print *, rank(a), size(shape(a))
   print *, rank(b), size(shape(b))
   print *, rank(c), size(shape(c))
   print *, rank(d), size(shape(d))
end


$ cat z5.f90
program p
   integer :: a[*]
   integer :: b(2)[*]
   integer :: c(2,3)[*]
   integer :: d(2,3,5)[*]
   print *, rank(a), size(shape(a))
   print *, rank(b), size(shape(b))
   print *, rank(c), size(shape(c))
   print *, rank(d), size(shape(d))
end


$ cat z6.f90
program p
   integer :: a[*]
   integer :: b(2)[*]
   integer :: c(2,3)[*]
   integer :: d(2,3,5)[*]
   print *, rank(a[1]), size(shape(a[1]))
   print *, rank(b(:)[1]), size(shape(b(:)[1]))
   print *, rank(c(:,:)[1]), size(shape(c(:,:)[1]))
   print *, rank(d(:,:,:)[1]), size(shape(d(:,:,:)[1]))
end


$ gfortran-12 z4.f90 && ./a.out
   0   0
   1   1
   2   2
   3   3

$ gfortran-12 z5.f90 -fcoarray=single && ./a.out
   0   0
   1   1
   2   2
   3   3

$ gfortran-12 z6.f90 -fcoarray=single && ./a.out
   0   0
   1   1
   2   2
   3   3

[Bug fortran/102532] [10/11/12 Regression] ICE in gfc_get_corank, at fortran/expr.c:5769

[gscfq--- via Gcc-bugs]

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

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

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

With an assignment :


$ cat z3.f90
program p
   character(:), allocatable :: x[:]
   character(:), allocatable :: y[:]
   y = x(:)(2:)
end


$ gfortran-12-20210926 -c z3.f90 -fcoarray=lib 
z3.f90:4:8:

4 |y = x(:)(2:)
  |1
Error: Rank mismatch in array reference at (1) (1/0)

[Bug fortran/102532] New: [10/11/12 Regression] ICE in gfc_get_corank, at fortran/expr.c:5769

[gscfq--- via Gcc-bugs]

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

Bug ID: 102532
   Summary: [10/11/12 Regression] ICE in gfc_get_corank, at
fortran/expr.c:5769
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with r6 (and detected somehow with r5) :


$ cat z1.f90
program p
   character(:), allocatable :: x[:]
   associate (y => x(:)(2:))
   end associate
end


$ cat z2.f90
program p
   character(:), allocatable :: x[:]
   associate (y => x(:)(:))
   end associate
end


$ gfortran-5 -c z1.f90 -fcoarray=lib 
z1.f90:3:20:

associate (y => x(:)(2:))
1
Error: Rank mismatch in array reference at (1) (1/0)
z1.f90:3:27:

associate (y => x(:)(2:))
   1
Error: Entity 'y' at (1) has a deferred type parameter and requires either the
POINTER or ALLOCATABLE attribute


$ gfortran-12-20210926 -c z1.f90 -fcoarray=lib
f951: internal compiler error: in gfc_get_corank, at fortran/expr.c:5769
0x79c591 gfc_get_corank(gfc_expr*)
../../gcc/fortran/expr.c:5769
0x7f38fb parse_associate
../../gcc/fortran/parse.c:4981
0x7f38fb parse_executable
../../gcc/fortran/parse.c:5728
0x7f47ef parse_progunit
../../gcc/fortran/parse.c:6143
0x7f5ed1 gfc_parse_file()
../../gcc/fortran/parse.c:6658
0x842daf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:216

[Bug fortran/92586] ICE in gimplify_expr, at gimplify.c:13479 with nested allocatable derived types

[epagone at email dot it via Gcc-bugs]

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

--- Comment #10 from epagone  ---
Bug persists in version 11.1.

[Bug testsuite/102501] [12 regression] several test case failures after r12-3876

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

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #4 from Aldy Hernandez  ---
fixed

[Bug testsuite/102501] [12 regression] several test case failures after r12-3876

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Aldy Hernandez :

https://gcc.gnu.org/g:24e30f485bc80c823393d8fc62b65f860230e04b

commit r12-3970-g24e30f485bc80c823393d8fc62b65f860230e04b
Author: Aldy Hernandez 
Date:   Tue Sep 28 17:53:57 2021 +0200

[PR102501] Adjust jump threading testcases for ppc64* and others.

I really don't know what to do here.  This is a bit of whack-o-mole.
The IL is sufficiently different for various architectures that any
tweak can cause the number of jump threads to vary.

For the pr7745-2.c testcase, we have less threading candidates because 2
of them now cross loop boundaries.  Interestingly, this test matches
"Jumps threaded", not threads registered, so the block copier can
drop threads at copying time adding further confusion.

For example, we can register N threads, but the old copier can cancel
N-M threads while updating the CFG for a variety of different reasons
(removed edges, threading through loop exits, etc).  This makes the
"Registering jump threads" not to match the total number of threads this
test checks for with "Jumps threaded".

The pr66752-3.c test OTOH, is just a matter of thread4 eliminating the
"if".  I had erroneously thought it would always be eliminated by
thread3, but we really don't care where it gets cleaned up.  All we know
is that DCE can't depend on the early threaders doing this work, because
it may cross loop boundaries.  I've chosen thread4 arbitrarily, but we
could just as easily pick the ".optimized" dump.

Sorry, I'm really at my wits end here.  I don't see any clean path
forward, except rewrite these tests as gimple IL.  They're close to useless
as they sit.

gcc/testsuite/ChangeLog:

PR testsuite/102501
* gcc.dg/tree-ssa/pr66752-3.c: Adjust.
* gcc.dg/tree-ssa/pr77445-2.c: Adjust.

[Bug libstdc++/98731] s390x: Large classes of std::bitset and std::vector hash the same

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||miladfarca at gmail dot com

--- Comment #5 from Jonathan Wakely  ---
*** Bug 102531 has been marked as a duplicate of this bug. ***

[Bug libstdc++/102531] std::hash does not work correctly on Big Endian platforms

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
dup

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

[Bug target/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails

[patrick.mcgehearty at oracle dot com via Gcc-bugs]

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

--- Comment #5 from Patrick McGehearty  
---
(In reply to Peter Bergner from comment #4)
> So what is the status here?  Are we just waiting for another patch to be
> submitted or it has been submitted and we're waiting on a review?

I submitted a patch that I believe resolves the issue on Aug 27, 2021
and pinged the gcc-patches list on Sept 8, 2021. Allowing for the
'distraction' of Linux Plumbers conference last week, I'm hoping
someone will try out my patch on a modern rs6000 environment to
confirm it works as expected.

[Bug c++/102104] parameter packs not expanded with '...' for operator conversions

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2021-09-29
 Status|UNCONFIRMED |NEW

--- Comment #1 from Patrick Palka  ---
We also reject the following, with a different error message:

template
struct variadic: private Bases... {
// error: expansion pattern ‘T’ contains no parameter packs
using T::operator typename Bases::target_type...;
};

[Bug fortran/102520] [10/11/12 Regression] ICE in expand_constructor, at fortran/array.c:1802

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

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

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

https://gcc.gnu.org/g:5e2adfeed21ee584a82cdcdfa7eed41202eb67cd

commit r12-3967-g5e2adfeed21ee584a82cdcdfa7eed41202eb67cd
Author: Harald Anlauf 
Date:   Wed Sep 29 20:11:53 2021 +0200

Fortran: fix error recovery for invalid constructor

gcc/fortran/ChangeLog:

PR fortran/102520
* array.c (expand_constructor): Do not dereference NULL pointer.

gcc/testsuite/ChangeLog:

PR fortran/102520
* gfortran.dg/pr102520.f90: New test.

[Bug debug/101283] Several tests fail on Darwin with -gctf/gbtf

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

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

Indu Bhagat  changed:

   What|Removed |Added

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

--- Comment #22 from Indu Bhagat  ---
Failing tests have been fixed and target now have an option to opt out of
CTF/BTF. Closing the bug.

[Bug c++/79094] Pack expansion in using-declaration rejects an attempt to inherit a pack of constructors

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |11.0

--- Comment #5 from Patrick Palka  ---
(In reply to Andrew Pinski from comment #4)
> Seems fixed in GCC 11+.

Fixed by r11-6942

[Bug middle-end/102519] [12 Regression] VRP Jump threader memory explosion

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

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

--- Comment #14 from David Edelsohn  ---
I tried the patch, but, unfortunately, it exceeds the memory limit in the same
manner.

[Bug c++/102528] Unused out-of-line functions emitted for trivial coroutines

[redbeard0531 at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Mathias Stearn  ---
Sorry, there was a typo in the initial code. I forgot the trivial
implementation of await_resume(). (D'oh!)

Now I can see that test() is just a ret instruction, but there is still a lot
of dead code emitted for the coroutine functions. While it isn't too much for
the trivial functions, for a real use case it would be. And it seems like a bug
anyway  that unused code makes it to the obj file in -O3:
https://godbolt.org/z/bTncofrzd

#include 

struct simple {
struct promise_type {
void return_void() {}
std::suspend_never initial_suspend() { return {}; }
std::suspend_never final_suspend() noexcept { return {}; }
void unhandled_exception() { throw; }
simple get_return_object() { return {}; }
};

std::true_type await_ready() {return {}; }
void await_suspend(std::coroutine_handle<>) {}
void await_resume() {}
};

inline simple test1() {
co_return;
}

inline simple test2() {
co_await test1();
co_return;
}

void test() {
test2();
}

test1(test1()::_Z5test1v.frame*) [clone .actor]:
movzx   eax, WORD PTR [rdi+18]
testal, 1
je  .L2
cmp ax, 5
ja  .L3
mov edx, 42
bt  rdx, rax
jnc .L3
.L4:
cmp BYTE PTR [rdi+17], 0
jne .L14
.L1:
ret
.L2:
cmp ax, 2
je  .L5
cmp ax, 4
je  .L4
testax, ax
jne .L3
mov QWORD PTR [rdi+24], rdi
.L5:
cmp BYTE PTR [rdi+17], 0
mov BYTE PTR [rdi+32], 1
mov QWORD PTR [rdi], 0
je  .L1
.L14:
jmp operator delete(void*)
test1(test1()::_Z5test1v.frame*) [clone .actor] [clone .cold]:
.L3:
ud2
test2(test2()::_Z5test2v.frame*) [clone .actor]:
movzx   eax, WORD PTR [rdi+18]
testal, 1
je  .L16
cmp ax, 7
ja  .L17
mov edx, 170
bt  rdx, rax
jnc .L17
.L18:
cmp BYTE PTR [rdi+17], 0
jne .L33
.L15:
ret
.L16:
cmp ax, 4
je  .L19
ja  .L20
testax, ax
jne .L34
mov QWORD PTR [rdi+24], rdi
.L22:
mov BYTE PTR [rdi+32], 1
.L19:
cmp BYTE PTR [rdi+17], 0
mov QWORD PTR [rdi], 0
je  .L15
.L33:
jmp operator delete(void*)
.L34:
cmp ax, 2
je  .L22
jmp .L17
.L20:
cmp ax, 6
je  .L18
jmp .L17
test2(test2()::_Z5test2v.frame*) [clone .actor] [clone .cold]:
.L17:
ud2
test1(test1()::_Z5test1v.frame*) [clone .destroy]:
movzx   eax, WORD PTR [rdi+18]
or  eax, 1
mov WORD PTR [rdi+18], ax
cmp ax, 5
ja  .L36
mov edx, 42
bt  rdx, rax
jnc .L36
cmp BYTE PTR [rdi+17], 0
jne .L39
ret
.L39:
jmp operator delete(void*)
test1(test1()::_Z5test1v.frame*) [clone .destroy] [clone .cold]:
.L36:
ud2
test2(test2()::_Z5test2v.frame*) [clone .destroy]:
movzx   eax, WORD PTR [rdi+18]
or  eax, 1
mov WORD PTR [rdi+18], ax
cmp ax, 7
ja  .L41
mov edx, 170
bt  rdx, rax
jnc .L41
cmp BYTE PTR [rdi+17], 0
jne .L44
ret
.L44:
jmp operator delete(void*)
test2(test2()::_Z5test2v.frame*) [clone .destroy] [clone .cold]:
.L41:
ud2
test():
ret

[Bug libstdc++/102531] New: std::hash does not work correctly on Big Endian platforms

[miladfarca at gmail dot com via Gcc-bugs]

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

Bug ID: 102531
   Summary: std::hash does not work correctly on Big Endian
platforms
   Product: gcc
   Version: 8.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: miladfarca at gmail dot com
  Target Milestone: ---

std::hash does not work correctly on BE machines using the following key types:
- std::hash
- std::hash>

They both break the 5th rule, a large number of inputs will end up having the
same hash:
https://en.cppreference.com/w/cpp/utility/hash

### std::bitset
```
#include 
#include 
#include 

int main(){
  std::bitset<2> a(0b01);
  std::bitset<2> b(0b10);

  std::size_t h1 = std::hash>{}(a);
  std::size_t h2 = std::hash>{}(b);

  std::cout << h1 << std::endl;
  std::cout << h2 << std::endl;
  return 0;

```
Output will be the same on BE machines.
The input length calculation is done incorrectly here:
https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/std/bitset#L1575
`bitset` writes 0 extended size_t sized values into memory. Reading smaller
lengths might return 0 as bytes are not reversed on BE.

### std::vector
```
#include 
#include 
#include 

int main(){

  std::vector a= {static_cast(1), static_cast(2)};
  std::vector b= {static_cast(1), static_cast(2),
static_cast(3)};

  std::size_t h1 = std::hash>{}(a);
  std::size_t h2 = std::hash>{}(b);

  std::cout << h1 << std::endl;
  std::cout << h2 << std::endl;

   return 0;
}
```
Similar issue as bitset. vector writes size_t sized values into memory.
https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/vector.tcc#L987
The calculated length in the above link might be smaller than the input and
only 0s will get returned as bytes are not reversed on BE.

[Bug middle-end/102519] [12 Regression] VRP Jump threader memory explosion

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

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

--- Comment #13 from Aldy Hernandez  ---
Created attachment 51520
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51520=edit
avoid CFG  and SSA updates when possible

The VRP threader is updating SSAs and CFG even if nothing changes.  This could
have an effect outside the time/memory budget for the threader, but it's just a
guess.

I am testing this patch and will commit it shortly.  Sorry to keep shooting in
the dark here, but could you see if this helps?

[Bug tree-optimization/102359] ICE gimplification failed since r12-3433-ga25e0b5e6ac8a77a

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

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

--- Comment #2 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
> Confirmed.  So we end with '&__closure->__this' which indeed isn't an lvalue.
> 
> The issue here is that we are initializing the VAR_DECL 'this' but that
> has a DECL_VALUE_EXPR expanding to &__closure->__this:
> 
> const struct A * const this [value-expr: &__closure->__this];
> 
> note the variable is const as well, so emitting a runtime initializer might
> have other issues (like trapping ...), or in this case, not being an lvalue.
> 
> But note the FE fails to mark the decl as TREE_READONLY - that would be an
> easy thing to check (and something we fail to check in
> is_var_need_auto_init).

Indeed, VAR_DECL "this" is:

(gdb) call debug_tree(t)
 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffe9461930 fields  context

full-name "const struct A"
needs-constructor X() X(constX&) this=(X&) n_parents=0
use_template=0 interface-unknown
pointer_to_this  reference_to_this
>
readonly sizes-gimplified unsigned DI size  unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffe947a000>
used unsigned read DI t.cpp:4:18 size 
unit-size 
align:64 warn_if_not_align:0 context 
value-expr 
readonly
arg:0 
readonly
arg:0 
arg:0 > arg:1 
t.cpp:4:18 start: t.cpp:4:18 finish: t.cpp:4:18>>>

It's not marked as "READONLY" by FE. 
this looks like a FE bug to me. 
I just feel strange why not marking "this" as "READONLY" hasn't caused any
other issue yet?


> Thus sth like
> 
> diff --git a/gcc/gimplify.c b/gcc/gimplify.c
> index f680292fd91..b2bfab47a2f 100644
> --- a/gcc/gimplify.c
> +++ b/gcc/gimplify.c
> @@ -1824,7 +1824,9 @@ gimple_add_padding_init_for_auto_var (tree decl, bool
> is_vla,
>  static bool
>  is_var_need_auto_init (tree decl)
>  {
> -  if (auto_var_p (decl)
> +  if (VAR_P (decl)
> +  && !TREE_READONLY (decl)
> +  && auto_var_p (decl)
>&& (flag_auto_var_init > AUTO_INIT_UNINITIALIZED)
>&& (!lookup_attribute ("uninitialized", DECL_ATTRIBUTES (decl)))
>&& !is_empty_type (TREE_TYPE (decl)))
> 
> should be needed.

If the FE can mark "this" as READONLY, the above will be the reasonable fix in
middle end. 
should we put this middle end fix in first and then transfer this bug to FE to
fix?
> 
> Jason, any idea?

[Bug c++/102530] Warn about non-extended temporary passed to a function returning a reference in temp-extending context

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

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

--- Comment #3 from Jason Merrill  ---
A simpler alternative would be to warn about any non-extended temporaries in an
initializer.  This would have both more false positives and fewer false
negatives.

If the temporary is passed by value or rvalue reference to another function,
it's probably OK.  If it's passed by lvalue reference, including as 'this',
it's dangerous.

The reference-like class issue also affects what we are initializing;
initializing an iterator from container().begin() has the same problem.  As can
a pointer:

const char *p = string().c_str();

Getting something more complex than the "simpler alternative" to a low enough
level of false negatives would probably require analysis of types and functions
to recognize reference-like classes and functions that return internal
references/pointers.

[Bug c++/102530] Warn about non-extended temporary passed to a function returning a reference in temp-extending context

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-09-29
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Confirmed, I thought I had saw a similar bug to this before.

[Bug c++/102530] Warn about non-extended temporary passed to a function returning a reference in temp-extending context

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

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

--- Comment #1 from Jason Merrill  ---
https://wg21.link/cwg900 and https://wg21.link/ewg120 deal with temporary
lifetime issues with range-for.  But they involve reference-like classes rather
than C++ reference types; I suppose the warning also needs to consider
reference/pointer-like classes.

[Bug middle-end/102519] [12 Regression] VRP Jump threader memory explosion

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

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

--- Comment #12 from David Edelsohn  ---
GCC non-quiet mode shows:

...
g_31_31_16 f_31_31_17 g_31_31_17 f_31_31_23 g_31_31_23 f_31_31_24 g_31_31_24
f_31_31_25 g_31_31_25 f_31_31_29 g_31_31_29 f_31_31_30 g_31_31_30 f_31_31_31
g_31_31_31
Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data> {heap 4160k}  {heap 4288k} 
{heap 4288k}  {heap 4416k}  {heap 9985k}
 {heap 9985k}  {heap 9985k}Streaming LTO
  {heap 12M}  {heap 12M}  {heap 15M}
 {heap 15M}  {heap 15M}  {heap 15M}  {heap 15M}
 {heap 15M}  {heap 15M}  {heap 16M} 
{heap 16M}  {heap 16M}  {heap 16M} 
{heap 16M}
Assembling functions:
 f_0_0_0 g_0_0_0 f_0_0_1 g_0_0_1 f_0_0_2 g_0_0_2 f_0_0_7 g_0_0_7 f_0_0_8
g_0_0_8 f_0_0_9 g_0_0_9 f_0_0_15 g_0_0_15 f_0_0_16 g_0_0_16 f_0_0_17 g_0_0_17
f_0_0_23 
...
f_17_15_9 g_17_15_9 f_17_15_15 g_17_15_15 f_17_15_16 g_17_15_16 f_17_15_17
g_17_15_17 f_17_15_23
cc1: out of memory allocating 65536 bytes after a total of 1071778432 bytes

Somehow the VRP threader change provoked this change in memory usage and
failure mode.

[Bug c++/102530] New: Warn about non-extended temporary passed to a function returning a reference in temp-extending context

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

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

Bug ID: 102530
   Summary: Warn about non-extended temporary passed to a function
returning a reference in temp-extending context
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jason at gcc dot gnu.org
  Target Milestone: ---

struct A {
  ~A();
};
struct B
{
  A a;
  A& get_a() { return a; }
};

int main()
{
  A& ar = B().get_a();
  // ar now refers to a destroyed object
}

We can recognize this situation based on

1) We're initializing a reference (a temporary-extending context) from a
function returning a reference.
2) The arguments to this reference-returning function include a temporary with
non-trivial destruction (or, recursively, another ref-returning function with
such an argument).

[Bug libstdc++/102445] [meta-bug] std::regex issues

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

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

Bug 84110 Summary: Null character in regex throws std::regex_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84110

   What|Removed |Added

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

[Bug libstdc++/84110] Null character in regex throws std::regex_error

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
Fixed for GCC 12. I might backport this after some soak time on trunk.

[Bug libstdc++/102445] [meta-bug] std::regex issues

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

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

Bug 102480 Summary: std::regex fails to match ^ when match_prev_avail is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102480

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |INVALID

[Bug libstdc++/102480] std::regex fails to match ^ when match_prev_avail is used

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|ASSIGNED|RESOLVED

--- Comment #3 from Jonathan Wakely  ---
The original report was invalid, but I've now implemented the multiline option
which does support the behaviour in the original testcase.

[Bug middle-end/102519] [12 Regression] VRP Jump threader memory explosion

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

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

--- Comment #11 from David Edelsohn  ---
tree VRP threader  :   0.25 (  2%)   0.03 (  1%)   0.76 (  1%) 
7804k (  2%)

Despite that report output, prior to the two patches ending with
ef1e524fd87a679f5da06116029c66a84daac80 "Remove old VRP jump threader code" and
"Replace VRP threader with a hybrid forward threader.", I was able to compile
the testcase with an AIX limit of 1.25GB data size and now I need 2.25GB.

In other words, I don't need the entire patch series or even the cleanup patch,
just the replace VRP and remove old VRP patches.

[Bug c++/102529] ctad for aliases fails in the presence of constraints

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

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug bootstrap/102527] [12 regression] out of memory compiling insn-emit.c

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

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

--- Comment #6 from Aldy Hernandez  ---
The attached patch adds a separate TV_* timer to see the actual break down for
VRP and the VRP threader.

Could you incorporate this patch and run the problematic file with ./cc1
-ftime-report -O2?  I'd like to see the table at the end.  If you're so
inclined, could you also email me the entire -ftime-report so I can see the GC
output as it compiles?

[Bug middle-end/102519] [12 Regression] VRP Jump threader memory explosion

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

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

--- Comment #10 from Aldy Hernandez  ---
The attached patch adds a separate TV_* timer to see the actual break down for
VRP and the VRP threader.

Could you incorporate this patch and run the problematic file with ./cc1
-ftime-report -O2?  I'd like to see the table at the end.  If you're so
inclined, could you also email me the entire -ftime-report so I can see the GC
output as it compiles?

[Bug middle-end/102519] [12 Regression] VRP Jump threader memory explosion

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

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

--- Comment #9 from Aldy Hernandez  ---
Created attachment 51519
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51519=edit
patch to help diagnose issue with -ftime-report

[Bug bootstrap/102527] [12 regression] out of memory compiling insn-emit.c

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

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

--- Comment #5 from Aldy Hernandez  ---
Created attachment 51518
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51518=edit
patch to help diagnose issue with -ftime-report

[Bug target/102477] ICE: in emit_move_insn, at expr.c:4026 at -Og with __builtin_shufflevector()

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #3 from Zdenek Sojka  ---
Created attachment 51517
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51517=edit
different testcase failing at -O without __builtin_shufflevector()

$ x86_64-pc-linux-gnu-gcc -O testcase.c 
during RTL pass: expand
testcase.c: In function 'foo':
testcase.c:7:9: internal compiler error: in emit_move_insn, at expr.c:4026
7 |   V v = -(g >> sizeof (g) - 1);
  | ^~
0x6b8206 emit_move_insn(rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/expr.c:4026
0xe36893 expand_gimple_stmt_1
/repo/gcc-trunk/gcc/cfgexpand.c:4006
0xe36893 expand_gimple_stmt
/repo/gcc-trunk/gcc/cfgexpand.c:4040
0xe3c98f expand_gimple_basic_block
/repo/gcc-trunk/gcc/cfgexpand.c:6082
0xe3e55e execute
/repo/gcc-trunk/gcc/cfgexpand.c:6808
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/102529] New: ctad for aliases fails in the presence of constraints

[barry.revzin at gmail dot com via Gcc-bugs]

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

Bug ID: 102529
   Summary: ctad for aliases fails in the presence of constraints
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Here's an example:

template 
struct C {
template 
C(U);
};

template 
C(U) -> C;

template 
requires true
using A = C;

C ok(1);   // ok, a is a C
A bad(2);  // fails

The provided error on gcc 11.2 (and trunk as of this writing) is:

:15:8: error: class template argument deduction failed:
   15 | A bad(2);  // fails
  |^
:15:8: error: no matching function for call to 'C(int)'
:2:8: note: candidate: 'template C(C)-> C requires 
__is_same(A, C)'
2 | struct C {
  |^
:2:8: note:   template argument deduction/substitution failed:
:15:8: note:   mismatched types 'C' and 'int'
   15 | A bad(2);  // fails
  |^
:4:5: note: candidate: 'template C(U)-> C requires
 __is_same(A, C)'
4 | C(U);
  | ^
:4:5: note:   template argument deduction/substitution failed:
:15:8: note:   couldn't deduce template parameter 'T'
   15 | A bad(2);  // fails
  |^

If you drop the "requires true" part of the alias template A, then this works.
As far as I understand the rules, this should work. MSVC accepts the example.
clang does not yet implement class template argument deduction for alias
templates.

[Bug bootstrap/102527] [12 regression] out of memory compiling insn-emit.c

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

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

--- Comment #4 from Aldy Hernandez  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #3)
> > --- Comment #2 from Aldy Hernandez  ---
> > (In reply to David Edelsohn from comment #1)
> >> Confirmed.
> >
> > I don't have access to an i386-solaris box.
> 
> ... and there's none in the cfarm unfortunately, and sparc-solaris is
> unaffected.

Ughh..

Can it be reproduced on a cross?  If so, could you post the .ii file with your
include file peculiarities?

[Bug middle-end/102519] [12 Regression] VRP Jump threader memory explosion

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

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

--- Comment #8 from Aldy Hernandez  ---
(In reply to David Edelsohn from comment #7)
> Have you tried a native PPC64LE Linux build?
> 
> AIX defaults to 32 bit, and it's big endian. I wouldn't expect that to
> affect the memory usage, but I'm mentioning it.
> 
> Did you try to compiler gcc/testsuite/gcc.target/powerpc/rlwimi-1.c ?

Yes.  That was the first thing I did.

I've also tried ppc32 with setarch ppc32 on gcc135.

ppc64le:
 TOTAL  :  34.50 11.83 46.33   
  540M (OLD)
 TOTAL  :  31.62 11.72 43.34   
  555M (NEW)

-ftime-report -O2 -m32 -mlittle-endian
 TOTAL  :  32.17 11.35 43.53   
  518M (OLD)
 TOTAL  :  31.89 11.89 43.79   
  533M (NEW)

-ftime-report -O2 -m32 -mbig-endian
 TOTAL  :  29.07 11.24 40.31   
  518M (OLD)
 TOTAL  :  33.68 12.66 46.34   
  533M (NEW)

These are all on a stage1 compiler

[Bug c++/102528] New: Unable to inline even trivial coroutines

[redbeard0531 at gmail dot com via Gcc-bugs]

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

Bug ID: 102528
   Summary: Unable to inline even trivial coroutines
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redbeard0531 at gmail dot com
  Target Milestone: ---

https://godbolt.org/z/aoab9W4xG

This should all compile away, and test() should just be a single ret
instruction. That is not what happens now, even with -O3.

#include 

struct simple {
struct promise_type {
void return_void() {}
std::suspend_never initial_suspend() { return {}; }
std::suspend_never final_suspend() noexcept { return {}; }
void unhandled_exception() { throw; }
simple get_return_object() { return {}; }
};

std::true_type await_ready() { return {}; }
void await_suspend(std::coroutine_handle<>) {}
void await_resume();
};

inline simple test1() {
co_return;
}

inline simple test2() {
co_await test1();
co_return;
}

void test() {
test2();
}

[Bug bootstrap/102527] [12 regression] out of memory compiling insn-emit.c

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

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

--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #2 from Aldy Hernandez  ---
> (In reply to David Edelsohn from comment #1)
>> Confirmed.
>
> I don't have access to an i386-solaris box.

... and there's none in the cfarm unfortunately, and sparc-solaris is
unaffected.

[Bug c++/95567] Defaulted virtual <=> has the wrong behavior, vtable is checked when it should not be

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

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug bootstrap/102527] [12 regression] out of memory compiling insn-emit.c

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

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

--- Comment #2 from Aldy Hernandez  ---
(In reply to David Edelsohn from comment #1)
> Confirmed.

I don't have access to an i386-solaris box.

David, how were you able to reproduce?

[Bug bootstrap/102527] [12 regression] out of memory compiling insn-emit.c

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

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

David Edelsohn  changed:

   What|Removed |Added

 CC||dje at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2021-09-29
 Status|UNCONFIRMED |NEW

--- Comment #1 from David Edelsohn  ---
Confirmed.

[Bug middle-end/102519] [12 Regression] VRP Jump threader memory explosion

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

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

--- Comment #7 from David Edelsohn  ---
Have you tried a native PPC64LE Linux build?

AIX defaults to 32 bit, and it's big endian. I wouldn't expect that to affect
the memory usage, but I'm mentioning it.

Did you try to compiler gcc/testsuite/gcc.target/powerpc/rlwimi-1.c ?

[Bug bootstrap/102527] [12 regression] out of memory compiling insn-emit.c

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

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug bootstrap/102527] New: [12 regression] out of memory compiling insn-emit.c

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

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

Bug ID: 102527
   Summary: [12 regression] out of memory compiling insn-emit.c
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: aldyh at gcc dot gnu.org
  Target Milestone: ---
  Host: i386-pc-solaris2.11
Target: i386-pc-solaris2.11
 Build: i386-pc-solaris2.11

Between 20210927 (rev dd11aab6463880c35d942c4a4fd346fdaeeb8e72) and
20210928 (rev a11052d98db2f2a61841f0c5ee84de4ca1b3e296), 32-bit Solaris/x86
bootstrap broke compiling insn-emit.c in stage 2:

cc1plus: out of memory allocating 65536 bytes after a total of 2747670528 bytes
make[3]: *** [Makefile:1136: insn-emit.o] Error 1

Comparing to the cc1plus memory consumption in the working configuration,
memory usage has almost quadrupled from ca. 750 MB to ca. 2.6 GB.

A reghunt identified this patch as the culprit:

commit 0288527f47cec6698b31ccb3210816415506009e
Author: Aldy Hernandez 
Date:   Tue Sep 21 10:27:53 2021 +0200

Replace VRP threader with a hybrid forward threader.

sparc-sun-solaris2.11 isn't affected, neither is i686-pc-linux-gnu.

Compiling with -fmem-report doesn't produce anything in the failing case.

[Bug tree-optimization/102516] [12 regression] pr65947-13.c and vect-alias-check-18.c fail on armeb since r12-3893

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

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

--- Comment #3 from Christophe Lyon  ---
The target name is armeb-linux-gnueabi or armeb-linux-gnueabihf

[Bug libstdc++/102480] std::regex fails to match ^ when match_prev_avail is used

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

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

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

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

commit r12-3963-gf38cd3bdb4cd429a5f7082ea91793a59b37d47b9
Author: Jonathan Wakely 
Date:   Wed Sep 29 13:48:19 2021 +0100

libstdc++: Implement std::regex_constants::multiline (LWG 2503)

This implements LWG 2503, which allows ^ and $ to match line terminator
characters, rather than only matching the beginning and end of the
entire input. The multiline option is only valid for ECMAScript, but
for other grammars we ignore it rather than throwing an exception.

This is related to PR libstdc++/102480, which incorrectly said that
ECMAscript should match the beginning of a line when match_prev_avail
is used. I think that's only supposed to happen when multiline is used.

The new regex_constants::multiline and basic_regex::multiline constants
are not defined for strict -std=c++11 and -std=c++14 modes, but
regex_constants::__multiline is always defined, so that the
implementation can use it internally.

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

* include/bits/regex.h (basic_regex::multiline): Define constant
for C++17.
* include/bits/regex_constants.h (regex_constants::multiline):
Define constant for C++17.
(regex_constants::__multiline): Define duplicate constant for
internal use in C++11 and C++14.
* include/bits/regex_executor.h (_Executor::_M_match_multiline()):
New member function.
(_Executor::_M_is_line_terminator(_CharT)): New member function.
(_Executor::_M_at_begin(), _Executor::_M_at_end()): Use new
member functions to support multiline matches.
* testsuite/28_regex/algorithms/regex_match/multiline.cc: New test.

[Bug libstdc++/84110] Null character in regex throws std::regex_error

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

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

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

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

commit r12-3961-gb701e1f8f6870c0f8cb4050674da489101dd05a5
Author: Jonathan Wakely 
Date:   Wed Sep 29 13:48:11 2021 +0100

libstdc++: std::basic_regex should treat '\0' as an ordinary char [PR84110]

When the input sequence contains a _CharT(0) character, the strchr call
in _Scanner<_CharT>::_M_scan_normal() will search for '\0' and so return
a pointer to the terminating null at the end of the string. This makes
the scanner think it's found a special character. Because it doesn't
match any of the actual special characters, we fall off the end of the
function (or assert in debug mode).

We should check for a null character explicitly and either treat it as
an ordinary character (for the ECMAScript grammar) or an error (for all
others). I'm not 100% sure that's right, but it seems consistent with
the POSIX RE rules where a '\0' means the end of the regex pattern or
the end of the sequence being matched.

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

PR libstdc++/84110
* include/bits/regex_error.h (regex_constants::_S_null): New
error code for internal use.
* include/bits/regex_scanner.tcc (_Scanner::_M_scan_normal()):
Check for null character.
* testsuite/28_regex/basic_regex/84110.cc: New test.

[Bug tree-optimization/102516] [12 regression] pr65947-13.c and vect-alias-check-18.c fail on armeb since r12-3893

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #2 from Richard Biener  ---
How do I need to configure GCC?  --target=armeb-linux-gnu isn't supported.

Note this looks like peeling related, maybe it's also fixed after
g:4c7731081647c22cbd249dc0faa20c3df9ed6411

[Bug middle-end/102517] [12 regression] regressions on aarch64 since r12-3899

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

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|rguenth at gcc dot gnu.org |rearnsha at gcc dot 
gnu.org
 CC||rguenth at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
So gcc.target/aarch64/cpymem-q-reg_1.c remains - since it all started with your
patch Richard, can you please see how to adjust the testcase?  For me it now
produces

foo:
.LFB0:
.cfi_startproc
adrpx1, src
add x1, x1, :lo12:src
adrpx0, dst
add x0, x0, :lo12:dst
ld1 {v0.16b - v1.16b}, [x1]
st1 {v0.16b - v1.16b}, [x0]
ret

using OImode moves with "uint256_t" type.

  _2 = MEM  [(char * {ref-all})];
  MEM  [(char * {ref-all})] = _2;

previously the C frontend didn't have such type and thus
langhooks.type_for_size returned NULL.  But now we do have the OImode integer
mode and support for moving it [but the actual move ends up using vector
registers].

[Bug middle-end/102517] [12 regression] regressions on aarch64 since r12-3899

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

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

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

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

commit r12-3959-gb34fa88becb6367229074f25ef9e2de6f4594b58
Author: Richard Biener 
Date:   Wed Sep 29 14:32:32 2021 +0200

testsuite/102517 - fix FAIL of gcc.dg/pr78408-1.c with OImode availability

This fixes the testcase which looks for variants of memcpy after
memset folding which is disturbed when we expand the memcpy inline
earlier which in fact performs the desired optimization but makes
the dump file not match.  For the ease of testing the following
adjusts the smaller structure size to be no longer power-of-two
which avoids the inline expansion.

2021-09-29  Richard Biener  

PR testsuite/102517
* gcc.dg/pr78408-1.c: Make S not power-of-two size.

[Bug middle-end/102517] [12 regression] regressions on aarch64 since r12-3899

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

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

--- Comment #2 from Richard Biener  ---
FAIL: gcc:gcc.dg/dg.exp=gcc.dg/pr78408-1.c scan-tree-dump-times fab1 "after
previous" 17

here we perform the desired optimization earlier in FRE.  I'll adjust the
testcase to make 'S' size not power of two.

[Bug c++/102482] Winit-list-lifetime false positive for temporaries with std::initializer_list

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

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #6)
> The warning should not trigger if the constructor takes the initializer_list
> by non-const lvalue reference.

I think this change to cp/init.c:maybe_warn_list_ctor will check if the
initializer_list parameter is a non-const lvalue reference:

--- a/gcc/cp/init.c
+++ b/gcc/cp/init.c
@@ -750,7 +750,8 @@ maybe_warn_list_ctor (tree member, tree init)
 return;

   tree parms = FUNCTION_FIRST_USER_PARMTYPE (current_function_decl);
-  tree initlist = non_reference (TREE_VALUE (parms));
+  tree parm1 = TREE_VALUE (parms);
+  tree initlist = non_reference (parm1);
   tree targs = CLASSTYPE_TI_ARGS (initlist);
   tree elttype = TREE_VEC_ELT (targs, 0);

@@ -758,6 +759,10 @@ maybe_warn_list_ctor (tree member, tree init)
   (TREE_TYPE (memtype), elttype))
 return;

+  if (TYPE_REF_P (parm1) && !TYPE_REF_IS_RVALUE (parm1)
+  && !(cp_type_quals (initlist) & TYPE_QUAL_CONST))
+return;
+
   tree begin = find_list_begin (init);
   if (!begin)
 return;

[Bug c++/102482] Winit-list-lifetime false positive for temporaries with std::initializer_list

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

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #5)
> True, but approximately nobody writes constructors taking a non-const lvalue
> reference to std::initializer_list, so this corner case doesn't seem very
> important. This does seem like a concrete enhancement that could be made
> easily though, even if low value in practice.

Just to make this bit easier to find in my wall of text above:

The warning should not trigger if the constructor takes the initializer_list by
non-const lvalue reference.

[Bug c++/102482] Winit-list-lifetime false positive for temporaries with std::initializer_list

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-09-29
 Ever confirmed|0   |1

--- Comment #5 from Jonathan Wakely  ---
(In reply to Federico Kircheis from comment #4)
> Note that following equivalent snippet
> 
> 
> #include 
> 
> struct span {
> span(std::initializer_list il) noexcept : begin(nullptr),
> size(il.size()) { begin = il.begin();}
> const int* begin;
> std::size_t size;
> };
> 
> 
> does not trigger the warning.

Ideally it would warn, but I hope the reason it doesn't its fairly obvious. The
C++ front end doesn't perform arbitrarily complex data flow analysis for the
constructor body, it just looks for the most common pattern of storing a
pointer to the temporary array in a mem-initializer. Using the array in the
constructor body /without storing it/ is less problematic, because only the
non-static data members persist beyond the end of the constructor e.g. this is
fine:

span(std::initializer_list il)
{ for (auto i : il) std::cout << i << ' '; }


As a simple heuristic to warn about the majority of cases, GCC checks for
storing the pointer in the mem-initializer-list only.

Maybe you're misunderstanding what the warning is telling you. It's not saying
that the statement `return foo(span(std::initializer_list{}));` has a bug,
because that's not the location of the warning. It's telling you that your
constructor definition is potentially dangerous. Which is totally true. How is
the compiler supposed to know that you never plan to use that constructor for
lvalues? (C++ doesn't allow a && ref-qualifier on a constructor, which would
enforce that at the language level). Should it re-compile the constructor every
time it's called, passing in whether it's constructing an rvalue or lvalue, so
that only some uses of it warn? That would slow down compilation for every
class with an initializer-list constructor. What if the constructor is not
defined inline, so is compiled completely separate from its callers?

If **you** know that nobody will never use that constructor for lvalues, then
just disable the warning around the constructor:

struct span {
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Winit-list-lifetime"
span(std::initializer_list il) noexcept : begin(il.begin()),
size(il.size()) {}
#pragma GCC diagnostic pop
const int* begin;
std::size_t size;
};

Or if you don't think the warning is useful, just disable it on the command
line via -Wno-init-list-lifetime. But the compiler can't know how you plan to
use that constructor, so it tells you it's got a potential bug.

> > And the fabulous manual [...]
> 
> Mhm, I should have done a little more research before opening this ticket.

Reading the documentation for the warning you're reporting a bug for is
probably a good start :-)

> > *   When a list constructor stores the "begin" pointer from the
> > "initializer_list" argument, this doesn't extend the lifetime of
> > the array, so if a class variable is constructed from a temporary
> > "initializer_list", the pointer is left dangling by the end of the
> > variable declaration statement.
> 
> The first statement is correct (does not extend lifetime), but the second is
> not always (the pointer is not always left dangling).

If the pointer's lifetime has not ended, it dangles. The manual seems correct
as written (it could be made more verbose to talk about special cases, but
approximately nobody reads the manual now, adding more words isn't going to
help).


> Also following snippet generates the warning:
> 
> 
> #include 
> 
> struct span {
> span(std::initializer_list& il) noexcept : begin(il.begin()),
> size(il.size()) {}
> const int* begin;
> std::size_t size;
> };
> 
> 
> but I currently cannot imagine a scenario where this would dangle, as one
> cannot write "span({1,2,3})"

True, but approximately nobody writes constructors taking a non-const lvalue
reference to std::initializer_list, so this corner case doesn't seem very
important. This does seem like a concrete enhancement that could be made easily
though, even if low value in practice.

The point is, this is a warning that warns about **potentially** problematic
code in the constructor. All warnings like this have false positives (otherwise
they would be errors not warnings).

If you have concrete suggestions for improving the heuristics then it might be
possible to reduce the false positive rate, but otherwise this amounts to "this
warning has false positives" and the response is "yes".

The current -Winit-list-lifetime is a simple, heuristic-based warning done in
the front end, so is 

[Bug c/81402] unhelpful -Wparentheses suggestion for assignment from non-zero constant

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-09-29
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #5 from Andrew Pinski  ---
Confirmed, we should mention both cases just like clang does:
:4:9: warning: using the result of an assignment as a condition without
parentheses [-Wparentheses]
  if (i = j) { }  // assignment could be intended
  ~~^~~
:4:9: note: place parentheses around the assignment to silence this
warning
  if (i = j) { }  // assignment could be intended
^
  ()
:4:9: note: use '==' to turn this assignment into an equality
comparison
  if (i = j) { }  // assignment could be intended
^
==

:9:9: warning: using the result of an assignment as a condition without
parentheses [-Wparentheses]
  if (i = 1) { }   // assignment almost certainly not intended
  ~~^~~
:9:9: note: place parentheses around the assignment to silence this
warning
  if (i = 1) { }   // assignment almost certainly not intended
^
  ()
:9:9: note: use '==' to turn this assignment into an equality
comparison
  if (i = 1) { }   // assignment almost certainly not intended
^
==

[Bug c/80756] missing diagnostic on non-constant expression with function call such as fabs or fma in initializer

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #7 from Andrew Pinski  ---
As mentioned -std=c99 -pedantic-errors errors out like expected.

[Bug target/100005] undefined reference to `_rdrand64_step'

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||yzhang1985 at gmail dot com

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

[Bug target/61417] can't use intrinsic function as argument to function template

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
You intrinsic cannot use normal functions.


See PR 15.

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

[Bug target/100005] undefined reference to `_rdrand64_step'

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||cyb70289 at gmail dot com

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

[Bug target/102526] Failed to link simd code if -O0

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
You intrinsic cannot use normal functions.


See PR 15.

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

[Bug c++/102526] New: Failed to link simd code if -O0

[cyb70289 at gmail dot com via Gcc-bugs]

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

Bug ID: 102526
   Summary: Failed to link simd code if -O0
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cyb70289 at gmail dot com
  Target Milestone: ---

Below test code assigns an simd intrinsic to another variable, and call
intrinic through that variable. GCC failed to link if build with -O0.


Test code
=
#include 
int main()
{
auto func = _mm_add_epi8;
auto v = func(_mm_set1_epi8(0), _mm_set1_epi8(1));
return 0;
}


Build error
===
$ g++ -O0 test.cc -msse2
/usr/bin/ld: /tmp/cc6pJnIg.o: in function `main':
test.cc:(.text+0x18): undefined reference to `_mm_add_epi8(long long
__vector(2), long long __vector(2))'
collect2: error: ld returned 1 exit status

$ g++ -O1 test.cc -msse2

[Bug middle-end/102504] [12 Regression] ICE in build_outer_var_ref, at omp-low.c:746

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

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

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

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

commit r12-3955-gd3e7bb15e28c554bf4484a912f3b9c18c60ec68f
Author: Jakub Jelinek 
Date:   Wed Sep 29 10:17:52 2021 +0200

openmp: Disallow reduction with var private in containing parallel even on
scope [PR102504]

The standard has a restriction:
"A list item that appears in a reduction clause of a scope construct must
be
shared in the parallel region to which a corresponding scope region binds."
similar to the restriction for worksharing constructs, but we were checking
it only on worksharing constructs and not for scope and ICEd later on
during
omp expansion.

2021-09-29  Jakub Jelinek  

PR middle-end/102504
* gimplify.c (gimplify_scan_omp_clauses): Use omp_check_private
even
in OMP_SCOPE clauses, not just on worksharing construct clauses.

* c-c++-common/gomp/scope-4.c: New test.

[Bug middle-end/102519] [12 Regression] VRP Jump threader memory explosion

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

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

--- Comment #6 from Aldy Hernandez  ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Aldy Hernandez from comment #4)
> > Is there any way of reproducing this on a cross?  I've been waiting 15
> > minutes for a "git fetch" on gcc111.fsffrance.org or gcc119.fsffrance.org. 
> > I'll continue trying in the background just in case.
> > 
> > FWIW, on a cross to --target=powerpc-ibm-aix7.1.2.0 --enable-languages=c I
> > don't see much of a difference on cc1 with -ftime-report:
> > 
> >  TOTAL  :  67.25  5.84 73.41
> > 518M
> > 
> >  TOTAL  :  70.15  6.23 76.74
> > 533M
> > 
> > That looks like a 2.9% increase.
> 
> Memory usage increased rather than compile time :).

But isn't that what was reported?  A 2X increase in memory usage?  Or is the
518M / 533M displayed here not an accurate measure of memory usage?

[Bug middle-end/102519] [12 Regression] VRP Jump threader memory explosion

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Aldy Hernandez from comment #4)
> Is there any way of reproducing this on a cross?  I've been waiting 15
> minutes for a "git fetch" on gcc111.fsffrance.org or gcc119.fsffrance.org. 
> I'll continue trying in the background just in case.
> 
> FWIW, on a cross to --target=powerpc-ibm-aix7.1.2.0 --enable-languages=c I
> don't see much of a difference on cc1 with -ftime-report:
> 
>  TOTAL  :  67.25  5.84 73.41
> 518M
> 
>  TOTAL  :  70.15  6.23 76.74
> 533M
> 
> That looks like a 2.9% increase.

Memory usage increased rather than compile time :).