[Bug testsuite/93058] FAIL: g++.dg/asan/asan_test.C -O2 (test for excess errors)

[slyfox at inbox dot ru]

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

--- Comment #4 from Sergei Trofimovich  ---
(In reply to Martin Liška from comment #3)
> @Sergei: Can you please send a patch for this?

Sent as https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01642.html

[Bug fortran/93365] ICE in match_data_constant, at fortran/decl.c:426

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl  ---
On Thu, Jan 23, 2020 at 03:37:04PM +, markeggleston at gcc dot gnu.org
wrote:
> 
> If the parameter attribute is removed or a non zero sized array is used, the
> ICE does not occur.
> 
> The ICE occurs in gfc_match_varspec (primary.c) a temporary gfc_ref structure
> has been created and has the type REF_INQUIRY. If the primary expression has
> been passed in is EXPR_CONSTANT the check is done. When the ICE occurs the 
> type
> is EXPR_STRUCTURE, so the value of the REF_INQUIRY taken from u.i is used for
> the inquiry type instead of being 2 (INQUIRY_KIND) it is random e.g.73176720.
> 

Not quite, right.  If you have

   complex, parameter :: a(1) = 0
   integer b
   data b/a%kind%

then at line 2337 in primary.c

   gfc_simplify_expr (primary, 0);

collapses primary to an EXPR_CONSTANT, and then things seem to work.

If you have

   complex, parameter :: a(0) = 0
   integer b
   data b/a%kind%

then "gfc_simplify_expr (primary, 0)" does not collapse primary
to EXPR_CONSTANT as it seems gfc_simplify_expr does not handle
zero size arrays (as there is nothing to simplify!).  gfortran
then enters the switch statement and get to lines 2384-2385

   primary->ts.type = BT_INTEGER;
   primary->ts.kind = gfc_default_integer_kind;

This just resets a part of primary, but it does not fix up
it up correctly.  Likely, need to check for zero size
arrays do extra work.

[Bug target/92767] [m68k]: Random ICE: verify_flow_info failed

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #6 from Jeffrey A. Law  ---
Per c#5.

[Bug c/93410] [9 only] can't use _Decimal64 in C99/C11/C17 mode

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I doubt GCC 9 is going to change.

[Bug c/93410] New: can't use _Decimal64 in C99/C11/C17 mode

[vincent-gcc at vinc17 dot net]

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

Bug ID: 93410
   Summary: can't use _Decimal64 in C99/C11/C17 mode
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincent-gcc at vinc17 dot net
  Target Milestone: ---

With GCC 9.2.1 under Debian/unstable (x86_64):

cventin% cat tst.c
int main (void)
{
  _Decimal64 x = 1;
  return x != 1;
}
cventin% gcc-9 tst.c -o tst 
cventin%

but

cventin% gcc-9 -std=c99 tst.c -o tst
tst.c: In function ‘main’:
tst.c:3:3: error: unknown type name ‘_Decimal64’
3 |   _Decimal64 x = 1;
  |   ^~
cventin% gcc-9 -std=c11 tst.c -o tst
tst.c: In function ‘main’:
tst.c:3:3: error: unknown type name ‘_Decimal64’
3 |   _Decimal64 x = 1;
  |   ^~
cventin% gcc-9 -std=c17 tst.c -o tst
tst.c: In function ‘main’:
tst.c:3:3: error: unknown type name ‘_Decimal64’
3 |   _Decimal64 x = 1;
  |   ^~
cventin%

There is no such issue with the trunk (where one just gets a warning if
-pedantic is used, which is expected).

[Bug analyzer/93368] FAIL: gcc.dg/analyzer/data-model-1.c (test for excess errors)

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from David Malcolm  ---
I'm going to go ahead and mark this as resolved; please reopen if the patch
above didn't fix all the issues.  Thanks.

[Bug analyzer/93316] Several gcc.dg/analyzer tests FAIL

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from David Malcolm  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #6)
[...]
> On Solaris (both sparc and x86), all analyzer testsuite failures are
> gone.

Thanks.

I'll go ahead and mark this as resolved.  Please reopen if there are any other
failures (apart from the pattern-test-2.c issue, which is PR analyzer/93291).

[Bug analyzer/93367] FAIL: gcc.dg/analyzer/abort.c (test for warnings, line 71)

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #5 from David Malcolm  ---
Ought to be fixed by above patch; marking this as resolved.  Please reopen if
there's still an issue.

[Bug analyzer/93367] FAIL: gcc.dg/analyzer/abort.c (test for warnings, line 71)

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-6195-ga0b935ac66bc9804b0864151e5f1bfde5ac1ddeb
Author: David Malcolm 
Date:   Thu Jan 23 17:46:12 2020 -0500

analyzer: avoid relying on system  in testsuite (PR 93367)

PR analyzer/93367 reports a testsuite failure in abort.c on
hppa64-hp-hpux11.11 when detecting if the analyzer "knows" that the
condition holds after the assert.

The root cause is that the assertion failure function in that
configuration's  is not marked with
__attribute__ ((__noreturn__)).

This patch reworks the test to avoid  in favor of a custom
implementation of assert, so that the test demonstrates the idea without
relying on properties of .

gcc/testsuite/ChangeLog:
PR analyzer/93367
* gcc.dg/analyzer/abort.c: Remove include of .
Replace use of assert with a custom assertion implementation.

[Bug target/92767] [m68k]: Random ICE: verify_flow_info failed

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #5 from John Paul Adrian Glaubitz  ---
Recent builds have been fine:

> https://buildd.debian.org/status/fetch.php?pkg=gcc-10=m68k=10-20200117-2=1579373512=0

I guess it's safe to close this issue.

[Bug target/88589] ICE + seemingly wrong codegen with m68k-elf

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2020-01-24
 CC||law at redhat dot com
 Ever confirmed|0   |1

--- Comment #4 from Jeffrey A. Law  ---
I can't reproduce the ICE with the gcc-8 branch or with the trunk.  I have no
idea what (if any) custom patches Debian might be carrying.

Second, I don't see the mov.w issue you raised.  I get a 32bit move.

I note that you're compiling with -mshort.  It's never been thoroughly tested
to the best of my knowledge (and I've been working on gcc for, egad, 30 years
now).  Use it at your own risk.


Finally, if you're looking for good code, -O2 is generally going to be your
best option.

[Bug target/92395] m68k-linux-gnu-gcc generates wrong code when the -mshort option is used

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #9 from Jeffrey A. Law  ---
I think the option should just be removed at this point.

[Bug target/92767] [m68k]: Random ICE: verify_flow_info failed

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2020-01-23
 CC||law at redhat dot com
 Ever confirmed|0   |1

--- Comment #4 from Jeffrey A. Law  ---
Similarly I bootstrap m68k several times per week (qemu)  and haven't stumbled
over this at all.

We're really going to need a .i file to have any hope of moving forward.

[Bug analyzer/93349] ICE: verify_gimple failed (error: location references block not in block tree)

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Within the analyzer exploded_graph::process_node has:
2312  /* Update cfun and input_location in case of an ICE: make it easier
to
2313 track down which source construct we're failing to handle.  */
2314  auto_cfun sentinel (node->get_function ());
2315  const gimple *stmt = point.get_stmt ();
2316  if (stmt)
2317input_location = stmt->location;

It resets cfun, but never resets input_location.

input_location is later used by gimplify_expr, called via gimplify_and_add
within omp-simd-clone.c, which has:
14492 if (!gimple_seq_empty_p (*pre_p))
14493   annotate_all_with_location_after (*pre_p, pre_last_gsi,
input_location);

thus using whatever the value of input_location.

Presumably this code is implicitly assuming that input_location is some
arbitrary value *not* in the block tree, which is violated by the analyzer code
above.

[Bug c++/42129] ICE in pointer difference with sizeof(int)>sizeof(void *)

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #6 from Jeffrey A. Law  ---
It appears this was fixed some time ago.  Given the state of the H8 port, I
don't think it's worth bisecting to find the precise commit.

[Bug translation/90162] exclamation mark in diagnostic!!!!!1111!!!!

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #2 from Jeffrey A. Law  ---
I've fixed this on the trunk.

[Bug target/92269] Profiling (-p) does not work on H8

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #3 from Jeffrey A. Law  ---
I've committed a fix on the trunk.

Note that the H8 is currently scheduled to be deprecated in gcc-10.  Meaning
it'll still be included in gcc-10, but it will be removed in gcc-11.

Deprecation will be cancelled if someone steps forward to do a "cc0 conversion"
on the H8 port.

[Bug tree-optimization/92924] [10 regression] reproducible indirect call profile merging causes 80% slowdown in Firefox pref-reftest-singletons id-getter microbenchmarks

[hubicka at gcc dot gnu.org]

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

--- Comment #10 from Jan Hubicka  ---
-fvpt still has no effect on Firefox
https://treeherder.mozilla.org/perf.html#/compare?originalProject=try=20725e2c319ad69128f075248bc41a0e97029437=try=8a26cb77fed6ccc6752c6ad906a8e20767b454a1=1
while it used to have

[Bug tree-optimization/91882] boolean XOR tautology missed optimisation

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
This is a job for reassociation pass really.
coming into that pass we have:
  _1 = a_3(D) | b_4(D);
  if (_1 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870913]:
  _5 = a_3(D) & b_4(D);
  if (_5 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 805306369]:

   [local count: 1073741824]:
  # iftmp.0_2 = PHI <1(3), 0(4)>

We should be able to transform this into:
  _6 = a_3(D) ^ b_4(D);
  if (_6 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870913]:

  if (0 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 805306369]:

   [local count: 1073741824]:
  # iftmp.0_2 = PHI <1(3), 0(4)>

then cfg cleanup should do:
  _6 = a_3(D) ^ b_4(D);
  if (_6 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 805306369]:

   [local count: 1073741824]:
  # iftmp.0_2 = PHI <1(1), 0(4)>

And then PHI-OPT should transform it into:
_6 = a_3(D) ^ b_4(D);
iftmp.0_2 = _6;

[Bug inline-asm/93027] ICE: in match_reload, at lra-constraints.c:1060

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:3a26c7b3a3569a5e1b6f0342e50aefe76ad0ec4d

commit r10-6190-g3a26c7b3a3569a5e1b6f0342e50aefe76ad0ec4d
Author: Jakub Jelinek 
Date:   Thu Jan 23 22:50:40 2020 +0100

testsuite: Require lp64 target rather x86_64-*-* in pr93027.c. [PR93027]

I've noticed this test failed on x86_64-linux with -m32 or -mx32 testing,
the triplet doesn't really say which actual multilib it is, and the test
really works with lp64.

2020-01-23  Jakub Jelinek  

PR inline-asm/93027
* gcc.target/i386/pr93027.c: Require lp64 target rather x86_64-*-*.

[Bug other/93409] New: [10 Regression] gcn libgomp plugin fails to build for x32

[doko at ubuntu dot com]

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

Bug ID: 93409
   Summary: [10 Regression] gcn libgomp plugin fails to build for
x32
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at ubuntu dot com
  Target Milestone: ---

an x86_64-linux-gnu build configured with
--with-multilib-list=m32,m64,mx32
--enable-offload-targets=nvptx-none,amdgcn-amdhsa,hsa

fails to build the gcn libgomp plugin. This worked in earler snapshots.


../../../../src/libgomp/plugin/plugin-gcn.c: In function
'print_kernel_dispatch':
../../../../src/libgomp/plugin/plugin-gcn.c:1030:5: error: cast to pointer from
integer of different size [-Werror=int-to-pointer-cast]
 1030 | (void*)kernargs->heap_ptr);
  | ^
../../../../src/libgomp/plugin/plugin-gcn.c:1032:5: error: cast to pointer from
integer of different size [-Werror=int-to-pointer-cast]
 1032 | (void*)kernargs->arena_ptr);
  | ^
../../../../src/libgomp/plugin/plugin-gcn.c:1033:34: error: format '%lu'
expects argument of type 'long unsigned int', but argument 5 has type
'uint64_t' {aka 'long long unsigned int'} [-Werror=format=]
 1033 |   fprintf (stderr, "%*sobject: %lu\n", indent, "", dispatch->object);
  |~~^ 
  |  | |
  |  long unsigned int uint64_t
{aka long long unsigned int}
  |%llu
../../../../src/libgomp/plugin/plugin-gcn.c: In function
'create_kernel_dispatch':
../../../../src/libgomp/plugin/plugin-gcn.c:1882:23: error: cast from pointer
to integer of different size [-Werror=pointer-to-int-cast]
 1882 |   kernargs->out_ptr = (int64_t)>output_data;
  |   ^
../../../../src/libgomp/plugin/plugin-gcn.c:1892:24: error: cast from pointer
to integer of different size [-Werror=pointer-to-int-cast]
 1892 |   kernargs->heap_ptr = (int64_t)kernel->module->heap;
  |^
../../../../src/libgomp/plugin/plugin-gcn.c:1896:27: error: cast from pointer
to integer of different size [-Werror=pointer-to-int-cast]
 1896 | kernargs->arena_ptr = (int64_t)get_team_arena (agent, num_teams);
  |   ^
../../../../src/libgomp/plugin/plugin-gcn.c: In function 'console_output':
../../../../src/libgomp/plugin/plugin-gcn.c:1946:27: error: format '%ld'
expects argument of type 'long int', but argument 3 has type 'int64_t' {aka
'long long int'} [-Werror=format=]

[Bug target/93177] PPC: Missing many useful platform intrinsics

[segher at gcc dot gnu.org]

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

--- Comment #13 from Segher Boessenkool  ---
You cannot use that from intrinsics.  But the target code can do similar of
course, whether or not asm syntax for this exists.

[Bug target/93177] PPC: Missing many useful platform intrinsics

[pinskia at gcc dot gnu.org]

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

--- Comment #12 from Andrew Pinski  ---
If PowerPC back-end supported the "Flag Output Operands" part of GCC's
inline-asm, you could use that to do the correct thing.  But sadly PowerPC does
not currently.

https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Flag-Output-Operands

[Bug c/38308] -Wformat does not work for wide strings

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 CC||jerome.hamm@planete-science
   ||s.org

--- Comment #5 from Joseph S. Myers  ---
*** Bug 93406 has been marked as a duplicate of this bug. ***

[Bug c++/93406] No argument checking for wchar_t variants of print-like functions

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #1 from Joseph S. Myers  ---
Duplicate.

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

[Bug analyzer/93316] Several gcc.dg/analyzer tests FAIL

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #5 from David Malcolm  ---
> Sorry about the failing tests.
>
> As noted in comment #4, r10-6152-gda7cf663b75513e4d2baf5a579ffcb4f8a61193b
> hopefully fixes all of these issues (apart from the pattern-test-2.c issue,
> which is PR analyzer/93291).
>
> Are there any other issues being seen on non-Linux targets?  Otherwise, I'd
> like to close this out.  Thanks.

On Solaris (both sparc and x86), all analyzer testsuite failures are
gone.

Thanks.
Rainer

[Bug target/91838] [8/9 Regression] incorrect use of shr and shrx to shift by 64, missed optimization of vector shift

[kretz at kde dot org]

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

--- Comment #6 from Matthias Kretz (Vir)  ---
FWIW, I'd prefer gnu::vector_size(N) to not introduce any additional UB over
the scalar arithmetic types. I.e. behave like if promotion would happen, just
with final assignment back to T (truncation). While I hate integer promotion,
in this case I'd vote for consistency.

[Bug rtl-optimization/93402] [8/9 Regression] Wrong code when returning padded struct

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8/9/10 Regression] Wrong   |[8/9 Regression] Wrong code
   |code when returning padded  |when returning padded
   |struct  |struct

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

[Bug rtl-optimization/93402] [8/9/10 Regression] Wrong code when returning padded struct

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:32667e04c7153d97d09d81c1af073d400f0c719a

commit r10-6186-g32667e04c7153d97d09d81c1af073d400f0c719a
Author: Jakub Jelinek 
Date:   Thu Jan 23 20:08:22 2020 +0100

postreload: Fix up postreload combine [PR93402]

The following testcase is miscompiled, because the postreload pass changes:
-(insn 14 13 23 2 (parallel [
-(set (reg:DI 1 dx [94])
-(plus:DI (reg:DI 1 dx [95])
-(reg:DI 5 di [92])))
-(clobber (reg:CC 17 flags))
-]) "pr93402.c":8:30 186 {*adddi_1}
- (expr_list:REG_EQUAL (plus:DI (reg:DI 5 di [92])
-(const_int  [0x19debd01c7]))
-(nil)))
-(insn 23 14 25 2 (set (reg:SI 0 ax)
+(insn 23 13 25 2 (set (reg:SI 0 ax)
 (const_int 0 [0])) "pr93402.c":10:1 67 {*movsi_internal}
  (nil))
 (insn 25 23 26 2 (use (reg:SI 0 ax)) "pr93402.c":10:1 -1
  (nil))
-(insn 26 25 35 2 (use (reg:DI 1 dx)) "pr93402.c":10:1 -1
+(insn 26 25 35 2 (use (plus:DI (reg:DI 1 dx [95])
+(reg:DI 5 di [92]))) "pr93402.c":10:1 -1
  (nil))
A USE insn is not a normal insn and verify_changes called from
apply_change_group is happy about any changes into it.
The following patch avoids this optimization if we were to change
the USE operand (this routine only changes a reg into (plus reg reg2)).

2020-01-23  Jakub Jelinek  

PR rtl-optimization/93402
* postreload.c (reload_combine_recognize_pattern): Don't try to adjust
USE insns.

* gcc.c-torture/execute/pr93402.c: New test.

[Bug c++/93345] [10 Regression] ICE in nothrow_spec_p, at cp/except.c:1247

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #6 from Jason Merrill  ---
Fixed.

[Bug target/93408] New: PPC: Provide intrinsics for cache prefetch instructions

[memmerto at ca dot ibm.com]

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

Bug ID: 93408
   Summary: PPC: Provide intrinsics for cache prefetch
instructions
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: memmerto at ca dot ibm.com
  Target Milestone: ---

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

> > > > __protected_stream_set()
> > > > __protected_stream_count()
> > > > __protected_stream_count_depth() // currently not implemented in gcc
> > > > __protected_stream_go()
> > > 
> > > Those are pretty specific to CBE I think?
> > 
> > No.  They are implemented on POWER5 and above (ISA 2.02), and are useful in
> > managing cache prefetch behaviour.
> 
> Open a separate feature request for these then, please.

This is that request.

[Bug c++/93345] [10 Regression] ICE in nothrow_spec_p, at cp/except.c:1247

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:20afdcd36982752ba012960b862e9be7154b1274

commit r10-6183-g20afdcd36982752ba012960b862e9be7154b1274
Author: Jason Merrill 
Date:   Thu Jan 23 12:32:02 2020 -0500

c++: Fix ICE with defaulted destructor and template.

In a template we don't instantiate a deferred noexcept-spec, and we don't
need it because we aren't going to do anything with the value of
throwing_cleanup in a template anyway.

PR c++/93345 - ICE with defaulted dtor and template.
PR c++/33799
* decl.c (cxx_maybe_build_cleanup): Don't try to set
throwing_cleanup in a template.

[Bug target/93177] PPC: Missing many useful platform intrinsics

[memmerto at ca dot ibm.com]

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

--- Comment #11 from Matt Emmerton  ---
> > > > The implementation of stwcx() and stdcx() need revision on PPC.
> > > > As I understand it, there is no need the mfocrf instruction nor the
> > > > mask-and-shift on result.
> > > 
> > > How else would you output the CR0.EQ bit?
> > 
> > There is no need to copy CR0 to a GPR - branch instructions such as BNE can
> > operate on CR0 directly.
> 
> You cannot write anything that maps to a CR field directly.

No need to access it directly - just use a BNE instruction (to branch for
retry/success) which operates implicitly on CR0.EQ.

There are plenty of material out there that implements atomic operations on
POWER like this:

loop:
lwarx
// do something
stwcx
bne loop:

gcc does an unnecessary mfocrf + cmp to achieve the same result.

Is there an assumption in gcc that the "result" of any intrinsic is reported in
a GPR, which disallows this implicit use of CR0?

[Bug c++/67491] [meta-bug] concepts issues

[paolo.carlini at oracle dot com]

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

Bug 92804 Summary: [10 Regression] ICE trying to use concept as a 
nested-name-specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92804

   What|Removed |Added

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

[Bug c++/92804] [10 Regression] ICE trying to use concept as a nested-name-specifier

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #5 from Paolo Carlini  ---
Fixed.

[Bug c++/92804] [10 Regression] ICE trying to use concept as a nested-name-specifier

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Paolo Carlini :

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

commit r10-6185-gc91072247eb066ec9c6cd0b0f949c7dae691e46c
Author: Paolo Carlini 
Date:   Thu Jan 23 19:28:23 2020 +0100

Fix "PR c++/92804 ICE trying to use concept as a nested-name-specifier"

A rather simple ICE where we failed to properly check for concept-ids
uses in nested-name-specifiers.

Tested x86_64-linux.

   /cp
   PR c++/92804
   * parser.c (cp_parser_nested_name_specifier_opt): Properly
   diagnose concept-ids.

   /testsuite
   PR c++/92804
   * g++.dg/concepts/pr92804-1.C: New.
   * g++.dg/concepts/pr92804-2.C: New.

[Bug c++/93331] [10 Regression] ICE in build2, at tree.c:4792

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

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

commit r10-6184-g6f346913f2a87e26c6095d9fbf3d20f926c5470a
Author: Jason Merrill 
Date:   Thu Jan 23 12:43:15 2020 -0500

c++: Avoid ICE when constant evaluation of __builtin_strchr fails.

If we can't change the argument to &"...", use the original arg instead of
the partially munged one.

PR c++/93331 - ICE with __builtin_strchr.
* constexpr.c (cxx_eval_builtin_function_call): Use the original
argument if we didn't manage to extract a STRING_CST.

[Bug c++/93331] [10 Regression] ICE in build2, at tree.c:4792

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  ---
Fixed.

[Bug c++/33799] Return value's destructor not executed when a local variable's destructor throws

[cvs-commit at gcc dot gnu.org]

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

--- Comment #13 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:20afdcd36982752ba012960b862e9be7154b1274

commit r10-6183-g20afdcd36982752ba012960b862e9be7154b1274
Author: Jason Merrill 
Date:   Thu Jan 23 12:32:02 2020 -0500

c++: Fix ICE with defaulted destructor and template.

In a template we don't instantiate a deferred noexcept-spec, and we don't
need it because we aren't going to do anything with the value of
throwing_cleanup in a template anyway.

PR c++/93345 - ICE with defaulted dtor and template.
PR c++/33799
* decl.c (cxx_maybe_build_cleanup): Don't try to set
throwing_cleanup in a template.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[elowe at elowe dot com]

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

--- Comment #118 from EML  ---
(In reply to EML from comment #117)
> I do appreciate someone else taking a look at this; I've had a lot of
> changes at work, so this really took a back seat. And I don't have access to
> the HP compiler to try things. I think this is an important step is in
> comment 112:
> 
> ---
> Unfortunately, the above won't work directly because of the function name
> encoding used on pa.  Maybe you can look at aCC to see the assembly output
> it generates to a call to a weak function.
> ---
> 
> 
> If we can figure out how aCC generates such weak and linkonce sections, we
> should be able to make gcc do the same.
> 
> As an aside, I have maxtsiz set to 1073741824 (per kctune)

Going over my notes, we had the same text size problems and we adjusted it to
be the maximum size

[Bug target/93012] PPC: inefficient 64-bit constant generation (upper = lower)

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #2 from Segher Boessenkool  ---
I have a patch.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[elowe at elowe dot com]

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

--- Comment #117 from EML  ---
I do appreciate someone else taking a look at this; I've had a lot of changes
at work, so this really took a back seat. And I don't have access to the HP
compiler to try things. I think this is an important step is in comment 112:

---
Unfortunately, the above won't work directly because of the function name
encoding used on pa.  Maybe you can look at aCC to see the assembly output it
generates to a call to a weak function.
---


If we can figure out how aCC generates such weak and linkonce sections, we
should be able to make gcc do the same.

As an aside, I have maxtsiz set to 1073741824 (per kctune)

[Bug middle-end/90348] [8/9/10 Regression] Partition of char arrays is incorrect in some cases

[rguenther at suse dot de]

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

--- Comment #20 from rguenther at suse dot de  ---
On January 23, 2020 6:00:02 PM GMT+01:00, "amonakov at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90348
>
>--- Comment #19 from Alexander Monakov 
>---
>(In reply to Michael Matz from comment #18)
>> represent all accesses indirectly via pointers
>
>Would that be necessary in presence of a verifier that ensures that all
>references are dominated by births?

No, but it would automatically ensure this via the dependence.

[Bug target/93127] PPC altivec vec_promote creates unnecessary xxpermdi instruction

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Target|powerpc-*-*-*   |powerpc*-*-*

--- Comment #3 from Segher Boessenkool  ---
Hrm, should we expand to vectors and then somehow optimise that in RTL?  Or
should it be expanded to just scalars?

We probably need to improve some gimple (builtin) folding for this.

[Bug target/91838] [8/9 Regression] incorrect use of shr and shrx to shift by 64, missed optimization of vector shift

[amonakov at gcc dot gnu.org]

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

--- Comment #5 from Alexander Monakov  ---
Ah, indeed, it should be explicitly UB, and the documentation should mention
that as well as that implicit integer promotion does not happen for vector
shifts and other operations.

[Bug target/93123] Lacking basic optimization around __int128 bitwise operations against constants

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Target|powerpc-*-*-*   |powerpc*-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-23
 Ever confirmed|0   |1

--- Comment #3 from Segher Boessenkool  ---
Yup, the same problem as always.

[Bug tree-optimization/93407] New: Dead partial memset not optimized away (clang does that)

[hubicka at gcc dot gnu.org]

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

Bug ID: 93407
   Summary: Dead partial memset not optimized away (clang does
that)
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

While analyzing GCC for PR93404 I noticed that gen_rtx_fmt_ee
 34 rtx
 35 gen_rtx_fmt_ee (code, mode, arg0, arg1)
 36  RTX_CODE code;
 37  enum machine_mode mode;
 38  rtx arg0;
 39  rtx arg1;
 40 {
 41   rtx rt;
 42   rt = ggc_alloc_rtx (2);
 43   memset (rt, 0, sizeof (struct rtx_def) - sizeof (rtunion));
 44 
 45   PUT_CODE (rt, code);
 46   PUT_MODE (rt, mode);
 47   XEXP (rt, 0) = arg0;
 48   XEXP (rt, 1) = arg1;
 49 
 50   return rt;
 51 }
gets quite odd codegen which gets inlined many times:

gen_rtx_fmt_ee():
/aux/hubicka/403.gcc/src/genrtl.c:41
  4036ae:   bf 18 00 00 00  mov$0x18,%edi
init_reload():
/aux/hubicka/403.gcc/src/reload1.c:500
  4036b3:   41 0f 95 c6 setne  %r14b
  4036b7:   49 89 c5mov%rax,%r13
gen_rtx_fmt_ee():
/aux/hubicka/403.gcc/src/genrtl.c:41
  4036ba:   e8 d1 64 0d 00  callq  4d9b90 
init_reload():
/aux/hubicka/403.gcc/src/reload1.c:500
  4036bf:   41 83 c6 04 add$0x4,%r14d
plus_constant_wide():
/aux/hubicka/403.gcc/src/genrtl.c:41
  4036c3:   be 04 00 00 00  mov$0x4,%esi
gen_rtx_fmt_ee():
/aux/hubicka/403.gcc/src/genrtl.c:42
  4036c8:   c7 40 03 00 00 00 00movl   $0x0,0x3(%rax)
/aux/hubicka/403.gcc/src/genrtl.c:41
  4036cf:   48 89 c7mov%rax,%rdi
/aux/hubicka/403.gcc/src/genrtl.c:42
  4036d2:   c6 40 07 00 movb   $0x0,0x7(%rax)
/aux/hubicka/403.gcc/src/genrtl.c:44
  4036d6:   b8 4b 00 00 00  mov$0x4b,%eax
  4036db:   66 89 07mov%ax,(%rdi)
/aux/hubicka/403.gcc/src/genrtl.c:45
  4036de:   44 88 77 02 mov%r14b,0x2(%rdi)
/aux/hubicka/403.gcc/src/genrtl.c:46
  4036e2:   4c 89 6f 08 mov%r13,0x8(%rdi)
/aux/hubicka/403.gcc/src/genrtl.c:47
  4036e6:   4c 89 67 10 mov%r12,0x10(%rdi)

For exmaple
  4036c8:   c7 40 03 00 00 00 00movl   $0x0,0x3(%rax)
seems to be leftover of the memset code. Clang does:
gen_rtx_fmt_ee():
/aux/hubicka/403.gcc/src/genrtl.c:43
  67c72f:   bf 18 00 00 00  mov$0x18,%edi
  67c734:   e8 a7 1a eb ff  callq  52e1e0 
  67c739:   49 89 c6mov%rax,%r14
/aux/hubicka/403.gcc/src/genrtl.c:44
  67c73c:   48 c7 00 00 00 00 00movq   $0x0,(%rax)
/aux/hubicka/403.gcc/src/genrtl.c:46
  67c743:   8d 85 4b 00 04 00   lea0x4004b(%rbp),%eax
/aux/hubicka/403.gcc/src/genrtl.c:47
  67c749:   41 89 06mov%eax,(%r14)
/aux/hubicka/403.gcc/src/genrtl.c:48
  67c74c:   49 89 5e 08 mov%rbx,0x8(%r14)
/aux/hubicka/403.gcc/src/genrtl.c:49
  67c750:   4d 89 7e 10 mov%r15,0x10(%r14)

which simply fills in the rtx header and the two XEXP pointers.

[Bug c++/93406] New: No argument checking for wchar_t variants of print-like functions

[jerome.h...@planete-sciences.org]

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

Bug ID: 93406
   Summary: No argument checking for wchar_t variants of
print-like functions
   Product: gcc
   Version: 7.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jerome.h...@planete-sciences.org
  Target Milestone: ---

Hi,

There is no output of -Wformat for functions using wchar_t format specifiers.
Let the following program:

/

#include 
#include 
#include 

int main(void)
{
wchar_t wbuf[128];
charcbuf[128];
time_t now = time(NULL);
swprintf(wbuf, sizeof(wbuf)/sizeof(*wbuf), L"%d", now);
snprintf(cbuf, sizeof(cbuf)/sizeof(*cbuf),  "%d", now);
printf("wbuf:%S\n", wbuf);
printf("cbuf:%s\n", cbuf);
return 0;
}

/

#

c++ -Wall -o rapport.elf rapport.cpp 
rapport.cpp: In function ‘int main()’:
rapport.cpp:11:55: warning: format ‘%d’ expects argument of type ‘int’, but
argument 4 has type ‘time_t {aka long int}’ [-Wformat=]
  snprintf(cbuf, sizeof(cbuf)/sizeof(*cbuf),  "%d", now);
   ^
#

The mismatch between format specifier and argument is only reported for char
functions, not for wchar_t functions.

I have seen this problem on:
c++ (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0
C++ (GCC) 8.2.0

[Bug tree-optimization/93404] [10 regression] -O2 and -O2 -flto SPEC2006 and 2017 code size regression

[hubicka at gcc dot gnu.org]

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

--- Comment #1 from Jan Hubicka  ---
Created attachment 47701
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47701=edit
inliner size stats parser

It took me a while to find some reasonable way to analyze code size regressions
 caused by inliner with -flto. The attached script parses output of objdump -dl
and maps code size back to original functions.

Here is an example of analysis for SPEC2k6 GCC which grows by 16% compared to
GCC 9 and is the main contributor to the SPECint2006 regression (0.42MB out of
1.11MB)

Building binaries with and w/o auto-inlining:

$ /aux/hubicka/trunk-install/bin/gcc -O2 -g -flto=auto *.c -o gcc-inline -I ./
-DSPEC_CPU -DSPEC_CPU_LP64
$ /aux/hubicka/trunk-install/bin/gcc -O2 -g -flto=auto *.c -o gcc-noinline -I
./ -DSPEC_CPU -DSPEC_CPU_LP64 -fno-inline-functions
$ size -A gcc-inline | grep text
.text2459681   4203552
$ size -A gcc-noinline | grep text
.text2126369   4203552

(that is 15% regression, so indeed most of regression to gcc 9 is due to
inlining)

$ objdump -dl gcc-inline | awk -f ~/parseobjdump.awk | sort -n | tail -15
12897   result_ready_cost():
14162   xmalloc():
14517   find_reloads.constprop.0():
14525   gen_rtx_fmt_e0():
14841   insn_extract():
15703   rtx_equal_p():
17105   yyparse_1.isra.0():
18033   recog_26():
22079   expand_expr():
22659   fold():
24046   recog_16():
26606   end_sequence():
31762   gen_rtx_fmt_e():
78479   gen_rtx_fmt_ee():
2511153

$ objdump -dl gcc-noinline | awk -f ~/parseobjdump.awk | sort -n | tail -15
10220   expand_binop():
11667   result_ready_cost():
11782   recog_30.constprop.0():
11939   split_2():
12230   try_combine():
13423   cse_insn():
14740   simplify_comparison():
14829   insn_extract():
14832   find_reloads.constprop.0():
16908   yyparse_1.isra.0():
18101   recog_26():
23255   expand_expr():
23450   fold():
24171   recog_16():
2167901


So the largest difference is inlining of gen_rtx_fmt_ee. It is still the same
as in mainline:

 34 rtx
 35 gen_rtx_fmt_ee (code, mode, arg0, arg1)
 36  RTX_CODE code;
 37  enum machine_mode mode;
 38  rtx arg0;
 39  rtx arg1;
 40 {
 41   rtx rt;
 42   rt = ggc_alloc_rtx (2);
 43   memset (rt, 0, sizeof (struct rtx_def) - sizeof (rtunion));
 44 
 45   PUT_CODE (rt, code);
 46   PUT_MODE (rt, mode);
 47   XEXP (rt, 0) = arg0;
 48   XEXP (rt, 1) = arg1;
 49 
 50   return rt;
 51 }

so pretty basic ctor that makes sense to inline.  Codegen differs on context
but typically is something like (which is bit odd):
gen_rtx_fmt_ee():
/aux/hubicka/403.gcc/src/genrtl.c:41
  4036ae:   bf 18 00 00 00  mov$0x18,%edi
init_reload():
/aux/hubicka/403.gcc/src/reload1.c:500
  4036b3:   41 0f 95 c6 setne  %r14b
  4036b7:   49 89 c5mov%rax,%r13
gen_rtx_fmt_ee():
/aux/hubicka/403.gcc/src/genrtl.c:41
  4036ba:   e8 d1 64 0d 00  callq  4d9b90 
init_reload():
/aux/hubicka/403.gcc/src/reload1.c:500
  4036bf:   41 83 c6 04 add$0x4,%r14d
plus_constant_wide():
/aux/hubicka/403.gcc/src/genrtl.c:41
  4036c3:   be 04 00 00 00  mov$0x4,%esi
gen_rtx_fmt_ee():
/aux/hubicka/403.gcc/src/genrtl.c:42
  4036c8:   c7 40 03 00 00 00 00movl   $0x0,0x3(%rax)
/aux/hubicka/403.gcc/src/genrtl.c:41
  4036cf:   48 89 c7mov%rax,%rdi
/aux/hubicka/403.gcc/src/genrtl.c:42
  4036d2:   c6 40 07 00 movb   $0x0,0x7(%rax)
/aux/hubicka/403.gcc/src/genrtl.c:44
  4036d6:   b8 4b 00 00 00  mov$0x4b,%eax
  4036db:   66 89 07mov%ax,(%rdi)
/aux/hubicka/403.gcc/src/genrtl.c:45
  4036de:   44 88 77 02 mov%r14b,0x2(%rdi)
/aux/hubicka/403.gcc/src/genrtl.c:46
  4036e2:   4c 89 6f 08 mov%r13,0x8(%rdi)
/aux/hubicka/403.gcc/src/genrtl.c:47
  4036e6:   4c 89 67 10 mov%r12,0x10(%rdi)
So about 49 bytes of code which does have a good chance to optimize with
surrounding code.

Adding noinline to gen_rtx_fmt_ee indeed saves 53k of binary which seems
reasonable given that inlined code was reported to be 75k and offlining leads
to a call sequence which is 5 bytes itself + colateral damage on surrounding
code.
This is not the case of our gen_* expanders which just produce a lot of
construction and there is no much to optimize and they do not happen to be
performance cirtical enough for inlining to pay back. Inliner does not
understnad that.

Next two most copied functions:
26606   end_sequence():
31762   gen_rtx_fmt_e():
are clearly the same story.

Adding noinline to all of gen_rtx_fmt* and end_sequence reduces code size to
2340961, so about 5% reduction or 1/3 of the regression. I suppose a lot of
remaining code will go into similar kind of inline decisions.

11808   incdec_operand():
11869   try_combine():
11937   split_2():
12849   cse_insn():
12897  

[Bug middle-end/90348] [8/9/10 Regression] Partition of char arrays is incorrect in some cases

[amonakov at gcc dot gnu.org]

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

--- Comment #19 from Alexander Monakov  ---
(In reply to Michael Matz from comment #18)
> represent all accesses indirectly via pointers

Would that be necessary in presence of a verifier that ensures that all
references are dominated by births?

[Bug c/84919] [8/9 Regression] error: passing argument 1 to restrict-qualified parameter aliases with argument 5 [-Werror=restrict]

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
Summary|[8/9/10 Regression] error:  |[8/9 Regression] error:
   |passing argument 1 to   |passing argument 1 to
   |restrict-qualified  |restrict-qualified
   |parameter aliases with  |parameter aliases with
   |argument 5  |argument 5
   |[-Werror=restrict]  |[-Werror=restrict]

--- Comment #20 from Martin Sebor  ---
Fixed on trunk (GCC 10).  The fix cannot be backported on its own without
introducing false negatives.

[Bug testsuite/93391] [10 regression] new test cases c-c++-common/Wconversion-pr40752.c and pr40752a.c fail

[seurer at gcc dot gnu.org]

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

--- Comment #7 from seurer at gcc dot gnu.org ---
Yup, that fixed all the errors I was seeing on powerpc64.

[Bug middle-end/90348] [8/9/10 Regression] Partition of char arrays is incorrect in some cases

[matz at gcc dot gnu.org]

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

--- Comment #18 from Michael Matz  ---
(In reply to Alexander Monakov from comment #17)
> I think part of the problem is trying to make "deaths" explicit via CLOBBERs
> without making "births" also explicit in the IR.

Yes, that's basically the crux (or rather, that our births (first mention of a
decl name) don't conflict with address-taking or access), and without changing
this we're bound to heap hacks onto hacks to make it all work.  So, ideally
we'd
represent the births of local decls as well (i.e. "allocate" them), represent
all accesses indirectly via pointers, and "free" them at deaths.  Optionally,
very late in the pipeline, we can rewrite alloc/free pairs whose pointers don't
escape into direct accesses to decls again (not sure if that's worthwhile at
all; the 'free/alloc' statements would be virtual anyway, and we would handle
only decls that must lie in memory this way).

With that we'd have to amend some optimizations nevertheless, as those
alloc/free pairs would hinder optimizations (no moving of instructions
accessing 
the locals over them), so they would have to be moved sometimes in order to
allow them (if deemed profitable).

[Bug analyzer/93375] ICE in gimple_call_arg, at gimple.h:3258

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #2 from David Malcolm  ---
Should be fixed by the above commit.

[Bug rtl-optimization/93402] [8/9/10 Regression] Wrong code when returning padded struct

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug analyzer/93375] ICE in gimple_call_arg, at gimple.h:3258

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:648796dab42b6e839f10fee5835f24cd2016a9f4

commit r10-6182-g648796dab42b6e839f10fee5835f24cd2016a9f4
Author: David Malcolm 
Date:   Wed Jan 22 16:26:38 2020 -0500

analyzer: avoid ICE with missing arguments (PR 93375)

PR analyzer/93375 reports an ICE under certain circumstances
involving a call where the number of arguments at the callsite
is less than the parameter count of the callee,

Specifically, the ICE occurs when pruning a checker_path for a
diagnostic, when attempting to maintain which expression is of
interest through such a call.

The root cause is an assumption that there were enough arguments at
the callsite, within callgraph_superedge's methods for mapping
expressions between callee and caller.

This patch adds checks for this to the relevant methods, fixing the ICE.

gcc/analyzer/ChangeLog:
PR analyzer/93375
* supergraph.cc (callgraph_superedge::get_arg_for_parm): Fail
gracefully is the number of parameters at the callee exceeds the
number of arguments at the call stmt.
(callgraph_superedge::get_parm_for_arg): Likewise.

gcc/testsuite/ChangeLog:
PR analyzer/93375
* gcc.dg/analyzer/pr93375.c: New test.

[Bug fortran/93365] ICE in match_data_constant, at fortran/decl.c:426

[markeggleston at gcc dot gnu.org]

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

--- Comment #3 from markeggleston at gcc dot gnu.org ---
(In reply to markeggleston from comment #2)
> f951: internal compiler error: in gfc_match_varspec, at
> fortran/primary.c:2389
> 0x727097 gfc_match_varspec(gfc_expr*, int, bool, bool)
>   ../../gcc/gcc/fortran/primary.c:2389
> 0x728b35 gfc_match_rvalue(gfc_expr**)
>   ../../gcc/gcc/fortran/primary.c:3496
> 0x6ae0f4 match_data_constant
>   ../../gcc/gcc/fortran/decl.c:398
> 0x6ae356 top_val_list
>   ../../gcc/gcc/fortran/decl.c:499
> 0x6ae691 gfc_match_data()
>   ../../gcc/gcc/fortran/decl.c:712
> 0x7177b9 match_word_omp_simd
>   ../../gcc/gcc/fortran/parse.c:93
> 0x71cbc6 match_word
>   ../../gcc/gcc/fortran/parse.c:469
> 0x71cbc6 decode_statement
>   ../../gcc/gcc/fortran/parse.c:469
> 0x71d6d4 next_free
>   ../../gcc/gcc/fortran/parse.c:1279
> 0x71d6d4 next_statement
>   ../../gcc/gcc/fortran/parse.c:1511
> 0x71efcc parse_spec
>   ../../gcc/gcc/fortran/parse.c:3922
> 0x721728 parse_progunit
>   ../../gcc/gcc/fortran/parse.c:5851
> 0x722d54 gfc_parse_file()
>   ../../gcc/gcc/fortran/parse.c:6391
> 0x76e80f gfc_be_parse_file
>   ../../gcc/gcc/fortran/f95-lang.c:210
> 
> on master https://gcc.gnu.org/g:7491c17fe01d8cf116f645532d46120029b26408
> 
> This occurs for:
> 
> program p
>   real, parameter :: a(0) = 0.5
>   write(\*,\*) a%kind
> end
> 
> If the parameter attribute is removed or a non zero sized array is used, the
> ICE does not occur.
> 
> The ICE occurs in gfc_match_varspec (primary.c) a temporary gfc_ref
> structure has been created and has the type REF_INQUIRY. If the primary
> expression has been passed in is EXPR_CONSTANT the check is done. When the
> ICE occurs the type
> is EXPR_STRUCTURE, so the value of the REF_INQUIRY taken from u.i is used

my mistake EXPR_ARRAY not EXPR_STRUCTURE

> for the inquiry type instead of being 2 (INQUIRY_KIND) it is random
> e.g.73176720.

[Bug testsuite/93391] [10 regression] new test cases c-c++-common/Wconversion-pr40752.c and pr40752a.c fail

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Now fixed.

[Bug testsuite/93391] [10 regression] new test cases c-c++-common/Wconversion-pr40752.c and pr40752a.c fail

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

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

commit r10-6181-g6d00f052ef209bacdd93f503b0c5fb428cc6c434
Author: Jason Merrill 
Date:   Thu Jan 23 10:37:18 2020 -0500

c-family: One more 40752 tweak for unsigned char.

My last patch didn't fix all the failures on unsignd char targets.  We were
missing one warning because by suppressing -Wsign-conversion for the second
operand of + we missed an overflow that we want to warn about, and we
properly don't warn about unsigned / or %.

PR testsuite/93391 - PR 40752 test fails with unsigned plain char.
* c-warn.c (conversion_warning): Change -Wsign-conversion handling.
* lib/target-supports.exp (check_effective_target_unsigned_char):
New.

[Bug c++/40752] -Wconversion generates false warnings for operands not larger than target type

[cvs-commit at gcc dot gnu.org]

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

--- Comment #37 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

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

commit r10-6181-g6d00f052ef209bacdd93f503b0c5fb428cc6c434
Author: Jason Merrill 
Date:   Thu Jan 23 10:37:18 2020 -0500

c-family: One more 40752 tweak for unsigned char.

My last patch didn't fix all the failures on unsignd char targets.  We were
missing one warning because by suppressing -Wsign-conversion for the second
operand of + we missed an overflow that we want to warn about, and we
properly don't warn about unsigned / or %.

PR testsuite/93391 - PR 40752 test fails with unsigned plain char.
* c-warn.c (conversion_warning): Change -Wsign-conversion handling.
* lib/target-supports.exp (check_effective_target_unsigned_char):
New.

[Bug analyzer/93405] Passing constant arguments to subroutines in Fortran ... and the analyzer.

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |SUSPENDED
   Last reconfirmed||2020-01-23
   Target Milestone|--- |11.0
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Thanks for filing this.

Note that I don't intend to support non-C frontends in -fanalyzer for GCC 10,
to keep the initial scope of the feature sane; see PR 93392.

I can reproduce; the ICE is in get_lvalue_1 on a CONST_DECL due to hitting:

4614  switch (TREE_CODE (expr))
4615{
4616default:
4617  gcc_unreachable ();

due to the get_rvalue_1 for ADDR_EXPR not having a special-case for CONST_DECL
like it does for FUNCTION_DECL and LABEL_DECL.

[Bug middle-end/90348] [8/9/10 Regression] Partition of char arrays is incorrect in some cases

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #17 from Alexander Monakov  ---
I think part of the problem is trying to make "deaths" explicit via CLOBBERs
without making "births" also explicit in the IR. Doing both would have allowed
a lifetime verifier that checks that births dominate all references to a
variable and likewise deaths/clobbers postdominate all references, which would
presumably catch this early and make the IR more rigorous overall.

[Bug testsuite/93391] [10 regression] new test cases c-c++-common/Wconversion-pr40752.c and pr40752a.c fail

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #4 from Christophe Lyon  ---
(In reply to Richard Biener from comment #3)
> I assume fixed.

Not quite: on arm & aarch64, I'm now seeing:
FAIL: c-c++-common/Wconversion-pr40752.c  -Wc++-compat   (test for warnings,
line 36)

[Bug c++/93279] [9/10 Regression] C++ Template substitution ICE

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
Further reduced:

template  struct B { using f = int; };
template  struct E {
  template ::f = 0>
  void operator*(U l) { [l](T m) { m * l; }; }
};

int
main ()
{
  E, 1> n;
  n * 4.f;
}

[Bug analyzer/93405] New: Passing constant arguments to subroutines in Fortran ... and the analyzer.

[toon at moene dot org]

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

Bug ID: 93405
   Summary: Passing constant arguments to subroutines in Fortran
... and the analyzer.
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: toon at moene dot org
  Target Milestone: ---

I think the analyzer has a problem in the way constant arguments are passed "by
reference" in Fortran:

$ cat main1.f
  real a(10), b(10), c(10)
  a = 0.
  b = 1.
  call sum(a, b, c, 10)
  print *, c(5)
  end
  subroutine sum(a, b, c, n)
  integer i, n
  real a(n), b(n), c(n)
  do i = 1, n
 c(i) = a(i) + b(i)
  enddo
  end
$ ~/compilers/install/bin/gfortran -fanalyzer -S main1.f
during IPA pass: analyzer
main1.f:4:0:

4 |   call sum(a, b, c, 10)
  | 
internal compiler error: in get_lvalue_1, at analyzer/region-model.cc:4617
0x782863 ana::region_model::get_lvalue_1(ana::path_var,
ana::region_model_context*)
/home/toon/compilers/gcc/gcc/analyzer/region-model.cc:4617
0x11bc8c3 ana::region_model::get_lvalue(ana::path_var,
ana::region_model_context*)
/home/toon/compilers/gcc/gcc/analyzer/region-model.cc:4720
0x11bdcdc ana::region_model::get_rvalue_1(ana::path_var,
ana::region_model_context*)
/home/toon/compilers/gcc/gcc/analyzer/region-model.cc:4763
0x11bde53 ana::region_model::get_rvalue(ana::path_var,
ana::region_model_context*)
/home/toon/compilers/gcc/gcc/analyzer/region-model.cc:4800
0x11bf209 ana::region_model::update_for_call_superedge(ana::call_superedge
const&, ana::region_model_context*)
/home/toon/compilers/gcc/gcc/analyzer/region-model.cc:5658
0x11bf2f7 ana::region_model::maybe_update_for_edge(ana::superedge const&,
gimple const*, ana::region_model_context*)
/home/toon/compilers/gcc/gcc/analyzer/region-model.cc:5599
0x11aaba2 ana::program_state::on_edge(ana::exploded_graph&, ana::exploded_node
const&, ana::superedge const*, ana::state_change*)
/home/toon/compilers/gcc/gcc/analyzer/program-state.cc:734
0x1198349 ana::exploded_node::on_edge(ana::exploded_graph&, ana::superedge
const*, ana::program_point*, ana::program_state*, ana::state_change*) const
/home/toon/compilers/gcc/gcc/analyzer/engine.cc:1081
0x119f1ad ana::exploded_graph::process_node(ana::exploded_node*)
/home/toon/compilers/gcc/gcc/analyzer/engine.cc:2506
0x119f7b2 ana::exploded_graph::process_worklist()
/home/toon/compilers/gcc/gcc/analyzer/engine.cc:2259
0x119fe19 ana::impl_run_checkers(ana::logger*)
/home/toon/compilers/gcc/gcc/analyzer/engine.cc:3580
0x11a0883 ana::run_checkers()
/home/toon/compilers/gcc/gcc/analyzer/engine.cc:3634
0x11967d8 execute
/home/toon/compilers/gcc/gcc/analyzer/analyzer-pass.cc:84
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug rtl-optimization/93235] [AArch64] ICE with __fp16 in a struct

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

  Component|target  |rtl-optimization

--- Comment #4 from Richard Earnshaw  ---
Looks to be generic expansion code that is running amok.

#0  fancy_abort (
file=0x232c400 "/home/rearnsha/gnusrc/gcc-cross/master/gcc/emit-rtl.c", 
line=1021, 
function=0x232d608 )::__FUNCTION__> "gen_rtx_SUBREG")
at /home/rearnsha/gnusrc/gcc-cross/master/gcc/diagnostic.c:1768
#1  0x00c7fc9f in gen_rtx_SUBREG (mode=E_SImode, reg=0x7630bcc0, 
offset=...) at /home/rearnsha/gnusrc/gcc-cross/master/gcc/emit-rtl.c:1021
#2  0x00cb3bcb in store_bit_field_using_insv (insv=0x7fffced0, 
op0=0x7630bee8, op0_mode=..., bitsize=16, bitnum=0, 
value=0x7630bed0, value_mode=...)
at /home/rearnsha/gnusrc/gcc-cross/master/gcc/expmed.c:630
#3  0x00cb6031 in store_integral_bit_field (op0=0x7630bee8, 
op0_mode=..., bitsize=16, bitnum=0, bitregion_start=..., 
bitregion_end=..., fieldmode=E_HImode, value=0x7630bed0, 
reverse=false, fallback_p=true)
at /home/rearnsha/gnusrc/gcc-cross/master/gcc/expmed.c:1050
#4  0x00cb5430 in store_bit_field_1 (str_rtx=0x7630bcc0, 
bitsize=..., bitnum=..., bitregion_start=..., bitregion_end=..., 
fieldmode=E_HImode, value=0x7630bed0, reverse=false, fallback_p=true)
at /home/rearnsha/gnusrc/gcc-cross/master/gcc/expmed.c:870
#5  0x00cb6a9a in store_bit_field (str_rtx=0x7630bcc0, 
bitsize=..., bitnum=..., bitregion_start=..., bitregion_end=...,
fieldmode=E_HImode, value=0x7630bed0, reverse=false)
at /home/rearnsha/gnusrc/gcc-cross/master/gcc/expmed.c:1177
#6  0x00cea57a in store_field (target=0x7630bcc0, bitsize=..., 
bitpos=..., bitregion_start=..., bitregion_end=..., mode=E_HImode, 
exp=0x764cab88, alias_set=0, nontemporal=false, reverse=false)
at /home/rearnsha/gnusrc/gcc-cross/master/gcc/expr.c:7192
#7  0x00ce1ba2 in expand_assignment (to=0x763090f0, 
from=0x764cab88, nontemporal=false)
at /home/rearnsha/gnusrc/gcc-cross/master/gcc/expr.c:5369
#8  0x00b552d8 in expand_gimple_stmt_1 (stmt=0x762df960)
at /home/rearnsha/gnusrc/gcc-cross/master/gcc/cfgexpand.c:3749
#9  0x00b556c7 in expand_gimple_stmt (stmt=0x762df960)
at /home/rearnsha/gnusrc/gcc-cross/master/gcc/cfgexpand.c:3847
#10 0x00b5e295 in expand_gimple_basic_block (bb=0x762cf138, 
disable_tail_calls=false)
...

Also fails if __fp16 is changed to _Float16.

[Bug target/91838] [8/9 Regression] incorrect use of shr and shrx to shift by 64, missed optimization of vector shift

[kretz at kde dot org]

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

--- Comment #4 from Matthias Kretz (Vir)  ---
Good point. Since gnu::vector_size(N) types are defined by you, you might be
able to say that for char and short this is also UB. After all the left operand
isn't actually promoted to int. Consequently the the right operand is equal to
the width of the "promoted" left operand in all cases.

[Bug rtl-optimization/93402] [8/9/10 Regression] Wrong code when returning padded struct

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug ipa/93369] [10 regression] g++.dg/lto/pr64076 fails

[segher at gcc dot gnu.org]

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

--- Comment #7 from Segher Boessenkool  ---
Why?  Is there any advantage to that?  The probability of having a collision
anywhere in the repo is nihil with ten digits already, and anywhere in the
world ever with twelve.  Why do we want thirty-two?

[ Maybe I missed some mail thread, sorry if so. ]

[Bug tree-optimization/93404] New: [10 regression] -O2 and -O2 -flto SPEC2006 and 2017 code size regression

[hubicka at gcc dot gnu.org]

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

Bug ID: 93404
   Summary: [10 regression] -O2 and -O2 -flto SPEC2006 and 2017
code size regression
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

I am looking into this for a while, but lets create a tracking bug to record
some info on the problem.

-O2 code size seems to keep getting bigger which is not a good thing. 
From
https://lnt.opensuse.org/db_default/v4/SPEC/spec_report/branch?sorting=_elf_detail_stats=on
We get following comparing text segment sizes to gcc 6

   GCC 7  GCC 8  GCC 9  GCC 10
SPECint2006 -O2:   ~  ~  ~  ~
SPECfp2006 -O2:~  ~  ~  6.94%
SPECint2006 -O2 -flto: ~  ~  ~  11.72%
SPECfp2006  -O2 -flto: ~  ~  ~  8.84%
SPECint2017 -O2:   ~  ~  2.58%  10.33%
SPECfp2018 -O2:~  ~  3.56%  14.47%
SPECint2017 -O2:   ~  ~  ~  9.77%
SPECfp2018 -O2:~  2.42%  ~  18.97%

Of course, -O3 also gets progressively bigger. LNT uses ~ for values which it
considers noise (that is bit funny for sizes that are noise free), but clearly
GCC 10 regressed more than previous releases.

In GCC 10 timeframe a large portion of -flto -O2 growth is enabling
auto-inlining, but it is not the only issue here, because w/o LTO the change
actually improved code size.

In December I compared current -O2 inlining to GCC 9 style inlining and also to
auto inlining with -O3 params:

SPEC text segment effect
Benchmark   -O2 -O2 with -O3 style inlining
SPECint2006 -O2 generic 0.32%   12.08%
SPECfp2006  -O2 generic -0.16%  2.99%
SPECint2006 -O2 generic LTO 11.79%  29.33%
SPECfp2006  -O2 generic LTO 1.72%   6.24%   
SPECint2017 -O2 generic -1.49%  11.17%
SPECfp2017  -O2 generic -0.33%  3.76%   
SPECint2017 -O2 generic LTO 10.99%  20.63%
SPECfp2017  -O2 generic LTO 4.07%   11.09%

First column compares GCC 9 -O2 inliner setting to one after patch and second
to -O3 settings.  Things has improved a bit since December, so i will try to
get fresh numbers.

[Bug fortran/93365] ICE in match_data_constant, at fortran/decl.c:426

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org

--- Comment #2 from markeggleston at gcc dot gnu.org ---
f951: internal compiler error: in gfc_match_varspec, at fortran/primary.c:2389
0x727097 gfc_match_varspec(gfc_expr*, int, bool, bool)
../../gcc/gcc/fortran/primary.c:2389
0x728b35 gfc_match_rvalue(gfc_expr**)
../../gcc/gcc/fortran/primary.c:3496
0x6ae0f4 match_data_constant
../../gcc/gcc/fortran/decl.c:398
0x6ae356 top_val_list
../../gcc/gcc/fortran/decl.c:499
0x6ae691 gfc_match_data()
../../gcc/gcc/fortran/decl.c:712
0x7177b9 match_word_omp_simd
../../gcc/gcc/fortran/parse.c:93
0x71cbc6 match_word
../../gcc/gcc/fortran/parse.c:469
0x71cbc6 decode_statement
../../gcc/gcc/fortran/parse.c:469
0x71d6d4 next_free
../../gcc/gcc/fortran/parse.c:1279
0x71d6d4 next_statement
../../gcc/gcc/fortran/parse.c:1511
0x71efcc parse_spec
../../gcc/gcc/fortran/parse.c:3922
0x721728 parse_progunit
../../gcc/gcc/fortran/parse.c:5851
0x722d54 gfc_parse_file()
../../gcc/gcc/fortran/parse.c:6391
0x76e80f gfc_be_parse_file
../../gcc/gcc/fortran/f95-lang.c:210

on master https://gcc.gnu.org/g:7491c17fe01d8cf116f645532d46120029b26408

This occurs for:

program p
  real, parameter :: a(0) = 0.5
  write(\*,\*) a%kind
end

If the parameter attribute is removed or a non zero sized array is used, the
ICE does not occur.

The ICE occurs in gfc_match_varspec (primary.c) a temporary gfc_ref structure
has been created and has the type REF_INQUIRY. If the primary expression has
been passed in is EXPR_CONSTANT the check is done. When the ICE occurs the type
is EXPR_STRUCTURE, so the value of the REF_INQUIRY taken from u.i is used for
the inquiry type instead of being 2 (INQUIRY_KIND) it is random e.g.73176720.

[Bug rtl-optimization/93402] [8/9/10 Regression] Wrong code when returning padded struct

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
-(insn 14 13 23 2 (parallel [
-(set (reg:DI 1 dx [94])
-(plus:DI (reg:DI 1 dx [95])
-(reg:DI 5 di [92])))
-(clobber (reg:CC 17 flags))
-]) "pr93402.c":8:30 186 {*adddi_1}
- (expr_list:REG_EQUAL (plus:DI (reg:DI 5 di [92])
-(const_int  [0x19debd01c7]))
-(nil)))
-(insn 23 14 25 2 (set (reg:SI 0 ax)
+(insn 23 13 25 2 (set (reg:SI 0 ax)
 (const_int 0 [0])) "pr93402.c":10:1 67 {*movsi_internal}
  (nil))
 (insn 25 23 26 2 (use (reg:SI 0 ax)) "pr93402.c":10:1 -1
  (nil))
-(insn 26 25 35 2 (use (reg:DI 1 dx)) "pr93402.c":10:1 -1
+(insn 26 25 35 2 (use (plus:DI (reg:DI 1 dx [95])
+(reg:DI 5 di [92]))) "pr93402.c":10:1 -1
  (nil))

Ugh, turning a use of a reg into use of addition...

[Bug ipa/93385] [10 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce

[jamborm at gcc dot gnu.org]

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

--- Comment #14 from Martin Jambor  ---
Another option, which does not create an inter-pass dependency and
does not clutter tree-inline any more, but which pessimizes IPA-SRA
(put perhaps just alittle bit?), is making sure that the statements
which might be left behind are harmless:

diff --git a/gcc/ipa-sra.c b/gcc/ipa-sra.c
index 31de527d111..df54b98759c 100644
--- a/gcc/ipa-sra.c
+++ b/gcc/ipa-sra.c
@@ -859,7 +859,8 @@ isra_track_scalar_value_uses (cgraph_node *node, tree name,
int parm_num,
}
  res += all_uses;
}
-  else if ((is_gimple_assign (stmt) && !gimple_has_volatile_ops (stmt))
+  else if ((is_gimple_assign (stmt) && !gimple_has_volatile_ops (stmt)
+   && !gimple_could_trap_p (stmt))
   || gimple_code (stmt) == GIMPLE_PHI)
{
  tree lhs;

I'll see what a tree-inline.c solution would look like and then decide
which of these I'll propose.

[Bug target/93376] [10 Regression] ICE: in immed_wide_int_const_1, at emit-rtl.c:660 with -Og -finline-functions-called-once

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-6178-gc124b345e460780e3c3d4a6e58d0e6e03da982a1
Author: Jakub Jelinek 
Date:   Thu Jan 23 16:17:56 2020 +0100

i386: Fix ICEs on TImode signed overflow add/sub patterns [PR93376]

The following testcase ICEs, because during try_combine of i3:
(insn 18 17 19 2 (parallel [
(set (reg:CCO 17 flags)
(eq:CCO (plus:OI (sign_extend:OI (reg:TI 96))
(const_int 1 [0x1]))
(sign_extend:OI (plus:TI (reg:TI 96)
(const_int 1 [0x1])
(set (reg:TI 98)
(plus:TI (reg:TI 96)
(const_int 1 [0x1])))
]) "pr93376.c":8:10 223 {*addvti4_doubleword_1}
 (expr_list:REG_UNUSED (reg:TI 98)
(expr_list:REG_DEAD (reg:TI 96)
(nil
and i2:
(insn 17 37 18 2 (set (reg:TI 96)
(const_wide_int 0x7fff))
"pr93376.c":8:10 65 {*movti_internal}
 (nil))
the eq in there gets simplified into:
(eq:CCO (const_wide_int 0x08000)
(const_wide_int 0x8000))
and simplify-rtx.c tries to simplify it by simplifying MINUS
of the two operands.
Now, i386 defines MAX_BITSIZE_MODE_ANY_INT to 128, because OImode
and XImode are used mainly as a placeholder for the vector modes;
these new signed overflow patterns are an exception to that,
but what they really need is just TImode precision + 1 (maybe 2 worst case)
bits at any time.

wide-int.h defines WIDE_INT_MAX_ELTS in a way that it contains one more
HWI above number of HWIs to cover WIDE_INT_MAX_ELTS, so on i386 that is
3 HWIs, meaning that TImode precision + 1/2 bits is still representable in
there.  Unfortunately, the way wi::sub_large is implemented, it needs
not just those 3 HWIs, but one HWI above the maximum of the lengths of
both operands, which means it buffer overflows, overwrites the following
precision in wide_int_storage and ICEs later on.  The need for 4 HWIs is
only temporary, because canonize immediately after it canonicalizes it
back to 3 HWIs only.

The patch is something suggested by Richard S., avoid using OImode
for this and instead use a partial int mode that is smaller.

2020-01-23  Jakub Jelinek  

PR target/93376
* config/i386/i386-modes.def (POImode): New mode.
(MAX_BITSIZE_MODE_ANY_INT): Change from 128 to 160.
* config/i386/i386.md (DPWI): New mode attribute.
(addv4, subv4): Use  instead of .
(QWI): Rename to...
(QPWI): ... this.  Use POI instead of OI for TImode.
(*addv4_doubleword, *addv4_doubleword_1,
*subv4_doubleword, *subv4_doubleword_1): Use 
instead of .

* gcc.dg/pr93376.c: New test.

[Bug rtl-optimization/93402] [8/9/10 Regression] Wrong code when returning padded struct

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |8.4

--- Comment #2 from Jakub Jelinek  ---
Seems to have started with r186861 aka
r0-116443-gb5068425b9d7ab59694014bc78d4a29e04e44918.
Slightly adjusted testcase:
struct S { unsigned int a; unsigned long long b; };

__attribute__((noinline)) struct S
foo (unsigned long long x)
{
  struct S ret;
  ret.a = 0;
  ret.b = x * 111ULL + ULL;
  return ret;
}

int
main ()
{
  struct S a = foo (1);
  if (a.b != 1222ULL)
__builtin_abort ();
  return 0;
}
The difference between per-r186861 and r186861 (== trunk) is:
@@ -10,7 +10,6 @@ foo:
movabsq $, %rdx
imulq   %rax, %rdi
xorl%eax, %eax
-   addq%rdi, %rdx
ret
.cfi_endproc
 .LFE0:

[Bug libstdc++/91947] std::filesystem::file_size will return wrong value on 32bit platforms with large files support

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:04681fca936b5bca1dd374dfb0fbca7ccb028994

commit r10-6177-g04681fca936b5bca1dd374dfb0fbca7ccb028994
Author: Jonathan Wakely 
Date:   Thu Jan 23 14:02:32 2020 +

libstdc++: Simplify makefile rule for largefile-config.h (PR91947)

The previous rule could leave an incomplete file if the build was
interrupted, which would then not be remade if make was run again.

This makes the rule more robust by writing to a temporary file and only
moving it into place as the final step. It also simplifies the rule so
that only the essential macro definitions are written to the file, not
the explanatory comments and commented out #undef lines.

Also, the macro for enabling LFS on Mac OS X 10.5 is now set
unconditionally, which is a bug fix from upstream autoconf.

PR libstdc++/91947
* include/Makefile.am (${host_builddir}/largefile-config.h): Simplify
rule.
* include/Makefile.in: Regenerate.

[Bug libstdc++/91947] std::filesystem::file_size will return wrong value on 32bit platforms with large files support

[redi at gcc dot gnu.org]

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

--- Comment #15 from Jonathan Wakely  ---
Fixed on trunk, backport to the branch needed too.

[Bug c++/92778] ICE: Illegal instruction signal terminated program cc1plus

[h2+bugs at fsfe dot org]

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

Hannes Hauswedell  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #5 from Hannes Hauswedell  ---
Any news on this issue?

I have created up to date intermediate files here:

https://hauswedell.net/gcc_ice_20200123/

Compile with -std=c++17 -fconcepts -fopenmp -pthread -lz -lbz2 
On FreeBSD also -lexecinfo
On GCC7/8, also add /path/to/libstdc++fs.a

The code triggers ICEs in GCC8 and GCC9 but not in GCC7, so I am marking this
"ice-on-valid-code" and I would also consider it a regression.

These are the compiler versions tested:

WORKS: g++7 (FreeBSD Ports Collection) 7.5.0
ICEs: g++8 (FreeBSD Ports Collection) 8.3.0
ICEs: g++9 (FreeBSD Ports Collection) 9.2.1 20200118

Do you need anything else from me to confirm this issue?

Thank you very much!

[Bug rtl-optimization/93402] [8/9/10 Regression] Wrong code when returning padded struct

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-23
 CC||amonakov at gcc dot gnu.org
Summary|Wrong code when returning   |[8/9/10 Regression] Wrong
   |padded struct   |code when returning padded
   ||struct
 Ever confirmed|0   |1

--- Comment #1 from Alexander Monakov  ---
Broken by postreload-cse, -fdbg-cnt=postreload_cse:0 gives good code.

[Bug target/93395] AVX2 missed optimization : _mm256_permute_pd() is unfortunately translated into the more expensive VPERMPD instead of the cheap VPERMILPD

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 47699
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47699=edit
gcc10-pr93395.patch

We don't miss any patterns, just have them ordered incorrectly.  RTL-wise,
vpermilp* is a subset of vpermp*, but it was placed after vpermp* and thus
vpermp* matched always when -mavx2 was also enabled, thus vpermilp* got only
emitted with -mavx -mno-avx2.

[Bug gcov-profile/93403] __gcov_indirect_call_profiler_v4 needs atomic version.

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-01-23
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

[Bug target/91824] unnecessary sign-extension after _mm_movemask_epi8 or __builtin_popcount

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #1 from Alexander Monakov  ---
A related problem was previously discussed in PR 29776 but this is not a
duplicate. In that PR part of the problem was with UB of clz/ctz for zero
inputs, none of that poses a problem for popcount and pmovmskb.

[Bug gcov-profile/93403] New: __gcov_indirect_call_profiler_v4 needs atomic version.

[hubicka at gcc dot gnu.org]

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

Bug ID: 93403
   Summary: __gcov_indirect_call_profiler_v4 needs atomic version.
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

We have __gcov_topn_values_profiler and __gcov_topn_values_profiler_atomic
but only no __gcov_indirect_call_profiler_v4_atomic.

Honza

[Bug rtl-optimization/93402] New: Wrong code when returning padded struct

[v at hnn dot net.br]

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

Bug ID: 93402
   Summary: Wrong code when returning padded struct
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: v at hnn dot net.br
  Target Milestone: ---
Target: x86_64-pc-linux-gnu

Created attachment 47698
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47698=edit
Minimal example

Output:
$ gcc example.c -O3 -fno-inline
$ ./a.out 
a.out: example.c:23: main: Assertion `output.b == 1222' failed.
Abortado (imagem do núcleo gravada)

The assembly output:
```
fn:
  movabs rdx, 111
  xor eax, eax
  imul rdi, rdx
  movabs rdx, 
  ret
```
Always returns ret.a = 0 and ret.b = 

This seems to be a GCC 6 regression [1]

Many thanks to everyone on StackOverflow who helped me with this [2]

[1]: "https://gcc.godbolt.org/z/le3EYP;
[2]:
"https://stackoverflow.com/questions/59871171/possible-gcc-bug-when-returning-struct-from-a-function;

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --enable-shared
--enable-threads=posix --with-system-zlib --with-isl --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-lto --enable-plugin --enable-install-libiberty
--with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib
--disable-werror --enable-checking=release --enable-default-pie
--enable-default-ssp --enable-cet=auto gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
gcc version 9.2.0 (GCC)

[Bug target/91838] [8/9 Regression] incorrect use of shr and shrx to shift by 64, missed optimization of vector shift

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #3 from Alexander Monakov  ---
For unsigned int this would be undefined behavior via attempt to shift by 32
(but we fail to emit the corresponding warning).

For narrower types (char, short) this seems well-defined.

[Bug target/93157] gcc should use -mabi=elfv2 on powerpc64-*-linux-*musl* target by default.

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
Someone who can test this should send a patch, and Cc: the Musl OS port
maintainer
(is there one?  There should be!)

[Bug target/93157] gcc should use -mabi=elfv2 on powerpc64-*-linux-*musl* target by default.

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|NEW |WAITING

[Bug bootstrap/93398] PGO bootstrap is not reproducible

[hubicka at ucw dot cz]

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

--- Comment #9 from Jan Hubicka  ---
Also forgot to mention, it is also quite possible that some of the small
divergences propagate themselves into differences in the histogram and
thus differences in hot/cold decisions in completely unrelated code...

[Bug target/93176] PPC: inefficient 64-bit constant consecutive ones

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
When you want the bits from bit MB to ME (inclusive) set, you can just do

  li t,-1
  rldic d,T,MB,63-ME

(bit # 0 is the high bit; can also do wrap-around masks this way).

Confirmed.

[Bug bootstrap/93398] PGO bootstrap is not reproducible

[hubicka at ucw dot cz]

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

--- Comment #8 from Jan Hubicka  ---
The divergence for non-randomization seems under control. But it also
seems that the divergence for randomized build is way too common to be
explained by differences in number of conflicts for hashtables hasing
pointers.  That could probably be worked around by adding no_instrument
attribute to the hashtable and pointer hashers

Honza

[Bug c++/92440] Error output for first error truncated with -fmax-errors=1

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-01-23
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
I've got a patch candidate.

[Bug tree-optimization/93401] [9/10 regression] It is no longer possible to use -fprofile-generate= on setups with different instrumentation and feedback directories

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug tree-optimization/93401] [9/10 regression] It is no longer possible to use -fprofile-generate= on setups with different instrumentation and feedback directories

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-23
 CC||marxin at gcc dot gnu.org
   Assignee|mliska at suse dot cz  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug tree-optimization/93401] [9/10 regression] It is no longer possible to use -fprofile-generate= on setups with different instrumentation and feedback directories

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |mliska at suse dot cz

--- Comment #1 from Jan Hubicka  ---
Martin,
this is your area..

[Bug tree-optimization/93401] New: [9/10 regression] It is no longer possible to use -fprofile-generate= on setups with different instrumentation and feedback directories

[hubicka at gcc dot gnu.org]

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

Bug ID: 93401
   Summary: [9/10 regression] It is no longer possible to use
-fprofile-generate= on setups with different
instrumentation and feedback directories
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=42870a86829f9d6dd326d318a3a028fbceb88d94
updated coverage.c co mangle full rather than relative names into gcov dump
file names.  This solves problem with multiple files conflicting on  single
dump (PR91971) but makes it impossible to read the profile when final build
directory differs from training. This is used i.e. by Firefox and HHVM.

Mark Williams suggested -ffile-prefix-map=old=new to strip away the outer dir
of build.

[Bug target/92469] ICE: output_operand: invalid use of register 'frame' in 7/8/9/10

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Liška  ---
Confirmed, it's very old issue.

[Bug target/93177] PPC: Missing many useful platform intrinsics

[segher at gcc dot gnu.org]

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

--- Comment #10 from Segher Boessenkool  ---
(In reply to Matt Emmerton from comment #9)
> > > __sync()
> > > __isync()
> > > __lwsync()
> > 
> > The sync intrinsics need to be tied to some other code.  A volatile asm with
> > a "memory" clobber is not good enough, in many cases.
> 
> We use these in our internal mutex and atomic implementations, and the
> resulting sequences are carefully scrutinized.

You have to check it after *every build* then, in general :-/

> > > __lwarx()
> > > __ldarx()
> > > __stwcx()
> > > __stdcx()
> > 
> > The compiler can always insert memory accesses in between those two, if you
> > have them as separate intrinsics (and it will, simply stack accesses for
> > temporaries will do, already).  If those accesses hit the same reservation
> > granule as the larx/stcx. uses, you lose.
> > 
> > You need to write the whole sequence in one piece of assembler code.
> 
> I would argue that the compiler should be smart enough to realize that these
> are part of a decomposed atomic operation, and avoid arbitrary instruction
> injection.

But this is impossible, it is contrary to all optimisation goals we have.  Yes,
It could perhaps work with -O0.

> > > __protected_stream_set()
> > > __protected_stream_count()
> > > __protected_stream_count_depth() // currently not implemented in gcc
> > > __protected_stream_go()
> > 
> > Those are pretty specific to CBE I think?
> 
> No.  They are implemented on POWER5 and above (ISA 2.02), and are useful in
> managing cache prefetch behaviour.

Open a separate feature request for these then, please.

> > > The implementation of stwcx() and stdcx() need revision on PPC.
> > > As I understand it, there is no need the mfocrf instruction nor the
> > > mask-and-shift on result.
> > 
> > How else would you output the CR0.EQ bit?
> 
> There is no need to copy CR0 to a GPR - branch instructions such as BNE can
> operate on CR0 directly.

You cannot write anything that maps to a CR field directly.

[Bug debug/92444] gcc generates wrong debug information at -O2 and -O3

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug c/92472] enhancement: 5 * constify some parameters

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug demangler/92453] write buffer overflow in cplus_demangle()

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-01-23
 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |tim.ruehsen at gmx dot 
de
 Ever confirmed|0   |1