[Bug c++/91369] Implement P0784R7: constexpr new

[lutztonineubert at gmail dot com]

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

--- Comment #24 from Toni Neubert  ---
Great thank you.

[Bug tree-optimization/92772] wrong code vectorizing masked max

[rsandifo at gcc dot gnu.org]

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

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
(In reply to Richard Biener from comment #1)
> Looks like cond-reduction cannot handle fully masked loops unless we'd
> somehow mask the condition operation itself?

Yeah, looks like it.  We'd never noticed this for SVE because
we always use EXTRACT_LAST reductions instead.

[Bug fortran/92754] ICE in gfc_finish_var_decl, at fortran/trans-decl.c:693

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00153.html

[Bug fortran/92756] [9/10 Regression] ICE in lower_omp, at omp-low.c:12988

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Wed Dec  4 08:47:13 2019
New Revision: 278956

URL: https://gcc.gnu.org/viewcvs?rev=278956&root=gcc&view=rev
Log:
PR fortran/92756
* trans-openmp.c (gfc_trans_omp_teams): Wrap OMP_TEAMS body into a
BIND_EXPR with a forced BLOCK.

* gfortran.dg/gomp/teams1.f90: New test.

* testsuite/libgomp.fortran/teams1.f90: New test.
* testsuite/libgomp.fortran/teams2.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/gomp/teams1.f90
trunk/libgomp/testsuite/libgomp.fortran/teams1.f90
trunk/libgomp/testsuite/libgomp.fortran/teams2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-openmp.c
trunk/gcc/testsuite/ChangeLog
trunk/libgomp/ChangeLog

[Bug testsuite/92398] [10 regression] error in update of gcc.target/powerpc/pr72804.c in r277872

[luoxhu at gcc dot gnu.org]

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

--- Comment #10 from luoxhu at gcc dot gnu.org ---
Author: luoxhu
Revision: 278890
Modified property: svn:log

Modified: svn:log at Wed Dec  4 08:50:33 2019
--
--- svn:log (original)
+++ svn:log Wed Dec  4 08:50:33 2019
@@ -10,7 +10,7 @@

2019-12-02  Luo Xiong Hu  

-   testsuite/pr92398
+   PR testsuite/92398
* gcc.target/powerpc/pr72804.c: Split the store function to...
* gcc.target/powerpc/pr92398.h: ... this one.  New.
* gcc.target/powerpc/pr92398.p9+.c: New.

[Bug fortran/92756] [9 Regression] ICE in lower_omp, at omp-low.c:12988

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[9/10 Regression] ICE in|[9 Regression] ICE in
   |lower_omp, at   |lower_omp, at
   |omp-low.c:12988 |omp-low.c:12988

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

[Bug tree-optimization/92788] [10 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2313

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug tree-optimization/92788] [10 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2313

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Started with r272922, guess latent before.  I'll have a look.

[Bug other/92784] [10 regression] ICE when compiling g++.dg/torture/pr59226.C after r278944

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Yeah, on i686-linux too.  Maybe everywhere.

[Bug c++/92789] New: Non-obvious ?: behaviour with structurally equivalent types

[rsandifo at gcc dot gnu.org]

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

Bug ID: 92789
   Summary: Non-obvious ?: behaviour with structurally equivalent
types
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rsandifo at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64*-*-*

As noted in https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00128.html
build_conditional_expr_1 uses same_type_p to check whether the "then"
and "else" types are the same.  If they are, it uses the "then"
type for the result.

However, same_type_p uses structural equality when
TYPE_STRUCTURAL_EQUALITY_P is true.  This means that we can treat
two distinct but equivalent types as "the same" and use the "then"
type for the result.  For example:

  #include 
  typedef uint8_t gnu_uint8_t __attribute__ ((vector_size (16)));
  void f(gnu_uint8_t x) {}
  void g(uint8x16_t y) {}

correctly mangles f as _Z1fDv16_h and g as _Z1g12__Uint8x16_t.  But:

  void h1(decltype(*(int *)nullptr ? *(gnu_uint8_t *)nullptr : *(uint8x16_t
*)nullptr)) {}
  void h2(decltype(*(int *)nullptr ? *(uint8x16_t *)nullptr : *(gnu_uint8_t
*)nullptr)) {}

mangles h1 as _Z2h1RDv16_h and h2 as _Z2h2R12__Uint8x16_t.

See https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00173.html for
Jason's comments on how this should work.

[Bug fortran/92790] New: [OpenACC] declare device_resident - Fortran common blocks not handled / libgomp.oacc-fortran/declare-5.f90 fails

[burnus at gcc dot gnu.org]

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

Bug ID: 92790
   Summary: [OpenACC] declare device_resident - Fortran common
blocks not handled /
libgomp.oacc-fortran/declare-5.f90 fails
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: tschwinge at gcc dot gnu.org
Depends on: 63859, 90921, 92728
  Target Milestone: ---

Related:
PR 90921 - this introduced the questionable module code, mentioned below;
   it looks like a work-around for the issue of the main point in
   this PR.
PR 63859 (a bit unclear what this PR is about)
(PR 92728 – ordering of common-block decl and using it in a decl+blank commons)


It turned out that for Fortran's common blocks, OpenACC's 'declare
device_resident' is not handled – causing libgomp.oacc-fortran/declare-5.f90 to
fail.

There is a RFC patch for this at the end of 
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00149.html


However, the patch causes that the same(-)named common block is marked as
'declare target' in multiple procedures. That seems to be very sensible from
the FE side. However, the ME code generates multiple times the same mapping
code. Result:

libgomp: Trying to map into device [0x407218..0x40721c) object when
[0x407210..0x40721c) is already mapped

Ideally, the ME part would consolidate all of them into a single item (at least
per translation unit). And to support multiple translation units, the libgomp
part should be handles as 'pcreate' not as with 'create'.
[In terms of common blocks, those are static variables with the same name,
pointing to the same memory block.]


Additional issues (cf. email):

* Code for handling modules variables looks fragile (seems to assume that the
module symbol ends up in the main program) - that code looks like a work-around
for the issue above. 

* Unclear what exactly get's mapped for
integer :: a,b,c
common /name/ a, b, c
declare device_resident(a)
  will this map the whole /name/?  (Current patch does so, cf. email;
  other variants will also ICE)

  I think it only makes sense if OpenACC requires that all is mapped, e.g.
  by requiring the explicit /name/ instead of permitting single common-block
  variables. Otherwise, it could also be handled by the FE as currently done,
  i.e. if one of them is device-resident, all are.

* General question what's meant by device resident, i.e., whether the
  same-named common block also exists on the host, i.e.
copy(/name/)
  will map all of the host's common block to the device and back.
  Of whether they only exist on the device, such that one passes individual
  variables, which happen to have the same name, i.e.
copy(/name/)
  passes a, b, c and one has to take care of them as single variables in the
  parallel/kernels block.

* Question whether OpenACC permits:
  block data
...
common /name/
  end block data

* Blank commons spec issue, PR 92728

* Data mapping question - i.e. if /name/ is device resident; will automatic
mapping imply copy() and firstprivate for common-block variables accessed in
the parallels/kernels block?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63859
[Bug 63859] Fortran OpenACC declare directive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90921
[Bug 90921] Fortran OpenACC 'declare' directive's module handling causes
duplicate data clauses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92728
[Bug 92728] [OpenMP][OpenACC] Common-block name clause matching issues: common
block needs to be defined before + blank common not supported

[Bug tree-optimization/92734] Missing match.pd simplification done by fold_binary_loc on generic

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Wed Dec  4 09:38:48 2019
New Revision: 278958

URL: https://gcc.gnu.org/viewcvs?rev=278958&root=gcc&view=rev
Log:
PR tree-optimization/92734
* match.pd ((A +- B) - A -> +- B, (A +- B) -+ B -> A,
A - (A +- B) -> -+ B, A +- (B -+ A) -> +- B): Handle nop_convert.

* gcc.dg/tree-ssa/pr92734-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr92734-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/92788] [10 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2313

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-04
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug target/92791] New: [10 Regression] ICE in extract_insn, at recog.c:2311 since r278645

[marxin at gcc dot gnu.org]

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

Bug ID: 92791
   Summary: [10 Regression] ICE in extract_insn, at recog.c:2311
since r278645
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: i586-linux-gnu
Target: i586-linux-gnu

Created attachment 47414
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47414&action=edit
Source files

It's an ugly bug for which I spent 2 days with a reduction. Still I ended up
with ~7MB of source files. It's reduced from boost package:

$ g++ -fPIC -O2 -flto=auto -march=i686 -fno-strict-aliasing -c *.ii
...
$ g++ -flto=16 -shared 1.o 2.o 3.o 4.o 5.o 6.o 7.o 8.o 9.o 10.o 11.o 12.o 13.o
...
(insn 63 62 64 4 (set (strict_low_part (subreg:QI (reg/v:DI 128 [ sbuf_it ])
4))
(reg:QI 145)) "6.ii":2362:116 -1
 (nil))
during RTL pass: vregs
6.ii:7056:1562: internal compiler error: in extract_insn, at recog.c:2311
0x827c17f _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/rtl-error.c:108
0x827c1aa _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/rtl-error.c:116
0x827a264 extract_insn(rtx_insn*)
../../gcc/recog.c:2311
0x85c3a91 instantiate_virtual_regs_in_insn
../../gcc/function.c:1607
0x85c3a91 instantiate_virtual_regs
../../gcc/function.c:1977
0x85c3a91 execute
../../gcc/function.c:2026

[Bug target/92791] [10 Regression] ICE in extract_insn, at recog.c:2311 since r278645

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-04
 CC||hubicka at gcc dot gnu.org
  Known to work||9.2.0
   Target Milestone|--- |10.0
 Ever confirmed|0   |1
  Known to fail||10.0

[Bug tree-optimization/92768] [8/9/10 Regression] Maybe a wrong code for vector constants

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Biener  ---
So I think it's unfortunate that we break testcases like this using _mm_xor_ps
with -ffast-math since users expect the mask to not be treated as signed
zero/zero.  The error here obviously lies in the use of FP vectors for
arguments
to _mm_xor_ps but I have no idea how we can rectify users (correct) expectation
here.  As Jakub says fixing the regression doesn't really solve the issue in
general.

Still I'd not expect middle-end core-infrastructure like the vector builder
to strip off signs from zeros.

[Bug tree-optimization/92768] [8/9/10 Regression] Maybe a wrong code for vector constants

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
For SSE2+, the code can of course use _mm_xor_si128 instead and
_mm_castsi128_ps/_mm_castps_si128, but for SSE that is not an option.
And not really sure what can be done there, the _mm_xor_ps arguments are given,
and even if we e.g. change the xorps builtin to take integral vectors, there
still would be casts to the floating point vectors and still risk of the
optimizers with -fno-signed-zeros to optimize that away.

[Bug tree-optimization/92772] wrong code vectorizing masked max

[ams at gcc dot gnu.org]

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

--- Comment #3 from Andrew Stubbs  ---
The GCN architecture can handle the masking, but I don't know how we'd
represent or apply that in the middle end?

I can probably implement extract_last, and that might be more efficient, but I
don't see how that will help the logic? The convoluted extraction is working
fine; it's the vector comparison that is misleading.

[Bug tree-optimization/92772] wrong code vectorizing masked max

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
IIRC AVX512 also implements fully masked loops so the testcase should fail
there, too, if we adjust N accordingly (to 15 or 31).  Hmm, can't seem to
trigger
the fully masked support here, maybe I misremember.

Btw, isn't the issue that the reduction looks at all lanes?  That is,
I think the code simply assumes that for fully masked loops at least
one iteration is performed with all lanes active.  So if you bump
N to 64 + 32 the test passes on amdgcn?

[Bug tree-optimization/92788] [10 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2313

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
So, what happens is that we have a bb like:
 [local count: 7102878]:
# __result_2 = PHI <_10(3)>
*this_4(D).D.3185._M_impl.D.3135._M_finish = __result_2;
with EH and normal successor edges.
dom_opt_dom_walker::optimize_stmt decides to remove the stmt (the only one in
the bb):
2160  if (cached_lhs && operand_equal_p (rhs, cached_lhs, 0))
2161{
2162  basic_block bb = gimple_bb (stmt);
2163  unlink_stmt_vdef (stmt);
2164  if (gsi_remove (si, true))
2165{
2166  bitmap_set_bit (need_eh_cleanup, bb->index);
2167  if (dump_file && (dump_flags & TDF_DETAILS))
2168fprintf (dump_file, "  Flagged to clear EH
edges.\n");
2169}
2170  release_defs (stmt);
2171  *removed_p = true;
2172  return retval;
2173}
but before we perform
780   /* Removal of statements may make some EH edges dead.  Purge
781  such edges from the CFG as needed.  */
782   if (!bitmap_empty_p (need_eh_cleanup))
...
to clean up those EH edges,
774   /* Thread jumps, creating duplicate blocks as needed.  */
775   cfg_altered |= thread_through_all_blocks (may_peel_loop_headers_p);
is called, calls thread_block_1 on the bb 13 and ICE trying to redirect EH edge
on a copy of that BB, because for EH edges we obviously assume there is some
statement that can throw but there are no statements in the bb at all.
Not really sure what can be done here.

[Bug tree-optimization/92772] wrong code vectorizing masked max

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
And the issue is to be fixed in vect_create_epilog_for_reduction where
we create the index IV:

  /* For cond reductions we want to create a new vector (INDEX_COND_EXPR)
 which is updated with the current index of the loop for every match of
 the original loop's cond_expr (VEC_STMT).  This results in a vector
 containing the last time the condition passed for that vector lane.
 The first match will be a 1 to allow 0 to be used for non-matching
 indexes.  If there are no matches at all then the vector will be all
 zeroes.  */
  if (STMT_VINFO_REDUC_TYPE (reduc_info) == COND_REDUCTION)
{

and the masking support needs to be added similarly to how
vectorizable_condition
handles it.

[Bug fortran/92782] ICE in fold_convert_loc, at fold-const.c:2431

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-04
 CC||jakub at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r242037, before that the code was rejected.

[Bug fortran/92780] [10 Regression] ICE in gfc_get_class_from_expr, at fortran/trans-expr.c:484

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-04
 CC||marxin at gcc dot gnu.org,
   ||pault at gcc dot gnu.org
  Known to work||9.2.0
   Target Milestone|--- |10.0
 Ever confirmed|0   |1
  Known to fail||10.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r276269.

[Bug fortran/92779] [8/9/10 Regression] ICE in gfc_conv_intrinsic_funcall, at fortran/trans-intrinsic.c:4225

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-04
 CC||marxin at gcc dot gnu.org,
   ||pault at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Started to ICE with r257827, before that it was rejected.

[Bug gcov-profile/91971] Profile directory concatenated with object file path

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|REOPENED|ASSIGNED
   Assignee|qinzhao at gcc dot gnu.org |marxin at gcc dot 
gnu.org

[Bug driver/92757] Documentation ambiguous/misleading about interplay of optimization and warning flags

[ricardolafabreu at gmail dot com]

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

--- Comment #10 from Ricardo Abreu  ---
> Usually CLI applications don't have as many switches as GCC with as many 
> non-trivial interactions between them.

True, but I am not sure I understand your point. To me that sounds like all the
more reason to avoid coupling between them and document it prominently
otherwise.

My outsider impression is that, ideally, turning on -W... flags should turn on
whatever analysis was needed, independently of optimization. It would make for
smoother UI because it would be more in line with the natural affordance of a
switch. I suppose the increase in compilation cost would be justified by the
request for more checking. I am sure there are reasons why this is unfeasible,
undesirable, too risky... Better highlighting in documentation would alleviate
the surprise.

[Bug d/92792] New: [10 Regression] symbols dropped from libphobos

[doko at debian dot org]

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

Bug ID: 92792
   Summary: [10 Regression] symbols dropped from libphobos
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: doko at debian dot org
  Target Milestone: ---

Created attachment 47415
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47415&action=edit
symbols diff

the current trunk 20191204 dropped two symbols from the shared phobos library. 
Is this expected, should the soversion be bumped?

[Bug fortran/92793] New: Fortran Location Data for Diagnostic lacks the column number – when passing on to ME

[burnus at gcc dot gnu.org]

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

Bug ID: 92793
   Summary: Fortran Location Data for Diagnostic lacks the column
number – when passing on to ME
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

Currently, all location_t locations (such as gfc_current_locus->lb->location)
always point to the beginning of the line, i.e. LOCATION_COLUMN(...) == 0.

For front-end diagnostic, this is corrected in gcc/fortran/error.c's
gfc_format_decoder using:

unsigned int offset = loc->nextc - loc->lb->line;

int loc_num = text->get_location (0) == UNKNOWN_LOCATION ? 0 : 1;
location_t src_loc
  = linemap_position_for_loc_and_offset (line_table,
 loc->lb->location,
 offset);

But this correction does not happen when setting the location for 'tree', e.g.:
   build_decl (ns->proc_name->declared_at.lb->location
or 
   tmp = fold_build1_loc (code->expr1->where.lb->location, LOOP_EXPR
or
  …

The question is how to fix this best. My feeling is that it should already be
fixed in the scanner such that   loc->lb->location  is always correct and we
can get rid off the offset calculation in error.c

[Bug fortran/92781] ICE in convert_nonlocal_reference_op, at tree-nested.c:1065

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 47416
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47416&action=edit
gcc10-pr92781.patch

Untested fix.

[Bug c++/92786] [c++11] static constexpr member link error

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Yes, this is
https://gcc.gnu.org/wiki/VerboseDiagnostics#missing_static_const_definition

In C++17 the static member is implicitly 'inline' which means the declaration
with an initializer is also a definition.

[Bug tree-optimization/92772] wrong code vectorizing masked max

[ams at gcc dot gnu.org]

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

--- Comment #6 from Andrew Stubbs  ---
(In reply to Richard Biener from comment #4)
> Btw, isn't the issue that the reduction looks at all lanes?  That is,
> I think the code simply assumes that for fully masked loops at least
> one iteration is performed with all lanes active.  So if you bump
> N to 64 + 32 the test passes on amdgcn?

Yes, only the loads are masked. For most things this works fine, but not for
reductions or permutations, etc.

If I set N=64, and double the input array, then the test passes indeed.

Masking the load of the {1, 2, 3 .. 63} vector would solve the issue, as would
masking the comparison or the reduction (not that there's an optab for that).

[Bug ipa/92794] New: [10 Regression] ICE in decide_about_value, at ipa-cp.c:5186

[asolokha at gmx dot com]

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

Bug ID: 92794
   Summary: [10 Regression] ICE in decide_about_value, at
ipa-cp.c:5186
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc-*-linux-gnu

gfortran-10.0.0-alpha20191201 snapshot (r278886) ICEs when compiling the
following testcase, extracted from
gcc/testsuite/gfortran.dg/unlimited_polymorphic_17.f90, for 32-bit BE powerpc
w/ -O3 --param ipa-cp-eval-threshold=2:

module m
  implicit none
contains
  recursive subroutine show_generic1(a)
class(*), intent(in) :: a(:)
call show_generic1 (a(2:))
return
  end subroutine show_generic1
end module m
program test
  use :: m
  implicit none
  real :: array(1:6) = (/ 0, 1, 2, 3, 4, 5 /)
  call show_generic1 (array)
end program test

% powerpc-e300c3-linux-gnu-gfortran-10.0.0-alpha20191201 -O3 --param
ipa-cp-eval-threshold=2 -c u0qbclbb.f90
during IPA pass: cp
u0qbclbb.f90:11:0:

   11 |   use :: m
  | 
internal compiler error: in decide_about_value, at ipa-cp.c:5186
0x7babc9 decide_about_value
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191201/work/gcc-10-20191201/gcc/ipa-cp.c:5186
0x1665c65 decide_whether_version_node
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191201/work/gcc-10-20191201/gcc/ipa-cp.c:5245
0x1665c65 ipcp_decision_stage
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191201/work/gcc-10-20191201/gcc/ipa-cp.c:5391
0x1665c65 ipcp_driver
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191201/work/gcc-10-20191201/gcc/ipa-cp.c:5574
0x1665c65 execute
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191201/work/gcc-10-20191201/gcc/ipa-cp.c:5665

[Bug fortran/92754] ICE in gfc_finish_var_decl, at fortran/trans-decl.c:693

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  ---
Author: burnus
Date: Wed Dec  4 12:19:55 2019
New Revision: 278961

URL: https://gcc.gnu.org/viewcvs?rev=278961&root=gcc&view=rev
Log:
Fortran] PR92754 - fix an issue with resolving intrinsic functions

gcc/fortran/
PR fortran/92754
* intrinsic.c (gfc_intrinsic_func_interface): Set
sym's flavor, intrinsic and function attribute if
unset.

gcc/testsuite/
PR fortran/92754
gfortran.dg/intrinsic_9.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/intrinsic_9.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/intrinsic.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/92754] ICE in gfc_finish_var_decl, at fortran/trans-decl.c:693

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #5 from Tobias Burnus  ---
FIXED on the GCC 10 trunk – not a (real) regression and potentially fragile
(cf. email); hence, no backporting.

Thanks for the bug report!

[Bug ipa/92794] [10 Regression] ICE in decide_about_value, at ipa-cp.c:5186

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||needs-bisection
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-04
  Known to work||9.2.0
   Host||x86_64-linux-gnu
 Ever confirmed|0   |1
  Known to fail||10.0

--- Comment #1 from Martin Liška  ---
Confirmed, let me bisect that, one can see it with a cross-compiler as well.

[Bug ipa/92794] [10 Regression] ICE in decide_about_value, at ipa-cp.c:5186

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |fxue at gcc dot gnu.org
   Target Milestone|--- |10.0

--- Comment #2 from Martin Liška  ---
Started with r278193.

[Bug target/92791] [10 Regression] ICE in extract_insn, at recog.c:2311 since r278645

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Reproduced, looking at it now.

[Bug demangler/92795] New: Another slowness issue in the demangler (on trunk)

[tim.ruehsen at gmx dot de]

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

Bug ID: 92795
   Summary: Another slowness issue in the demangler (on trunk)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: demangler
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tim.ruehsen at gmx dot de
  Target Milestone: ---

c++filt
'_ZZ1_DO1z1psp1VEz1VE2On'

takes ~1200s to finish.

Relevant part of the callback
#6 0x514263 in d_find_pack
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11
#7 0x514263 in d_find_pack
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11
#8 0x514263 in d_find_pack
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11
#9 0x514263 in d_find_pack
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11
#10 0x514263 in d_find_pack
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11
#11 0x514263 in d_find_pack
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11
#12 0x514263 in d_find_pack
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11
#13 0x514263 in d_find_pack
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11
#14 0x514263 in d_find_pack
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11
#15 0x514263 in d_find_pack
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11
#16 0x514263 in d_find_pack
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11
#17 0x514263 in d_find_pack
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11
#18 0x514263 in d_find_pack
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11
#19 0x514263 in d_find_pack
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11
#20 0x514263 in d_find_pack
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11
#21 0x514263 in d_find_pack
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11
#22 0x514263 in d_find_pack
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11
#23 0x50d514 in d_print_comp_inner
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:5685:33
#24 0x503a44 in d_print_comp
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:5781:3
#25 0x514138 in d_print_subexpr
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4540:3
#26 0x51150c in d_print_comp_inner
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:5514:4
#27 0x503a44 in d_print_comp
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:5781:3
#28 0x512ce5 in d_print_mod
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c
#29 0x50f6d4 in d_print_comp_inner
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:5155:4
#30 0x503a44 in d_print_comp
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:5781:3
#31 0x50edc2 in d_print_comp_inner
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:5331:2
#32 0x503a44 in d_print_comp
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:5781:3
#33 0x51384c in d_print_function_type
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:6084:5
#34 0x510d8d in d_print_comp_inner
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:5216:4
#35 0x503a44 in d_print_comp
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:5781:3
#36 0x510628 in d_print_comp_inner
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4813:2
#37 0x503a44 in d_print_comp
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:5781:3
#38 0x50dda3 in d_print_comp_inner
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4708:7
#39 0x503a44 in d_print_comp
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:5781:3
#40 0x50335e in cplus_demangle_print_callback
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4352:5
#41 0x504a5e in d_demangle_callback
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:6345:16
#42 0x504325 in d_demangle
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:6367:12
#43 0x504209 in cplus_demangle_v3
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:6524:10
#44 0x4fbc44 in cplus_demangle
/home/tim/src/binutils-gdb/libiberty/./cplus-dem.c:166:13

[Bug c++/92743] doc: -Wattribute-alias improperly indexed

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Fixed with r272672.

[Bug rtl-optimization/92796] New: [10 Regression] ICE in lra_assign, at lra-assigns.c:1646 on powerpc64le-linux-gnu

[doko at debian dot org]

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

Bug ID: 92796
   Summary: [10 Regression] ICE in lra_assign, at
lra-assigns.c:1646 on powerpc64le-linux-gnu
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at debian dot org
  Target Milestone: ---

Created attachment 47417
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47417&action=edit
preprocessed source

seen with r278959 on powerpc64le-linux-gnu, trunk:

// during RTL pass: reload
// ../../../src/libquadmath/math/acosq.c: In function 'acosq':
// ../../../src/libquadmath/math/acosq.c:317:1: internal compiler error: in
lra_assign, at lra-assigns.c:1646
//   317 | }
//   | ^
// 0x106652fb lra_assign(bool&)
//  ../../src/gcc/lra-assigns.c:1646
// 0x1065e353 lra(_IO_FILE*)
//  ../../src/gcc/lra.c:2487
// 0x1060345b do_reload
//  ../../src/gcc/ira.c:5518
// 0x1060345b execute
//  ../../src/gcc/ira.c:5704
// Please submit a full bug report,
// with preprocessed source if appropriate.

[Bug demangler/92797] New: cplus_demangle() produces huge amount of output (on trunk)

[tim.ruehsen at gmx dot de]

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

Bug ID: 92797
   Summary: cplus_demangle() produces huge amount of output (on
trunk)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: demangler
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tim.ruehsen at gmx dot de
  Target Milestone: ---

Created attachment 47418
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47418&action=edit
700mb output reproducer

c++file `cat slow-unit-150de9e10e6b2b6e62a6bac5b4c1fc87602ef3c6` (the attached
reproducer file) creates output of >700Mb.

[Bug c/92773] GCC compilation with big array / header is infinite

[renault at fedoraproject dot org]

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

Charles-Antoine Couret  changed:

   What|Removed |Added

  Attachment #47408|0   |1
is obsolete||
  Attachment #47409|0   |1
is obsolete||
  Attachment #47410|0   |1
is obsolete||

--- Comment #4 from Charles-Antoine Couret  
---
Created attachment 47419
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47419&action=edit
module driver after preprocessor

[Bug demangler/92797] cplus_demangle() produces huge amount of output (on trunk)

[tim.ruehsen at gmx dot de]

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

--- Comment #1 from Tim Ruehsen  ---
BTW, llvm-cxxfilt does not show this behavior.

[Bug c/92773] GCC compilation with big array / header is infinite

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Hmm, compilation finishes instantly for me.  I tried, -O2, -Os and -O3.

[Bug fortran/92775] Incorrect expression in DW_AT_byte_stride on an array

[andrew.burgess at embecosm dot com]

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

--- Comment #1 from Andrew Burgess  ---
I ran a bisect and this is the commit where GCC stops producing the DWARF I
would expect to see:

In GIT:
 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=47e6a59aedf4b114c2b4865c97a91a7b700cd991

In SVN:
  https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=251949

[Bug fortran/92775] Incorrect expression in DW_AT_byte_stride on an array

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
That means the get_array_descr_info langhook wasn't updated I guess.

[Bug fortran/92775] [8/9/10 Regression] Incorrect expression in DW_AT_byte_stride on an array

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||7.5.0
   Target Milestone|--- |8.4
Summary|Incorrect expression in |[8/9/10 Regression]
   |DW_AT_byte_stride on an |Incorrect expression in
   |array   |DW_AT_byte_stride on an
   ||array

[Bug libstdc++/92798] New: -fshort-enums can break iterators of std::map

[fc9vqetne38 at temp dot mailbox.org]

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

Bug ID: 92798
   Summary: -fshort-enums can break iterators of std::map
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fc9vqetne38 at temp dot mailbox.org
  Target Milestone: ---

Hi,

I'm having problems with iterators of std::map when -fshort-enums is enabled.
It somehow depends on the combination of compiler, stdlib and optimizations
(tested g++ and clang++, libstdc++ and libc++). The size of key (int vs. long)
and map also seem to matter. My layman guess is, that it's somehow related to
operator--.

Short example that shows the (to me unexpected) behavior, used versions of g++
and clang++ at the end:

#include 
#include 
int main() {
  auto m = std::map{{0,0}, {1,1}, {2,2}};
  std::cout << std::boolalpha;
  std::cout << (&(*m.begin()) == &(*m.rbegin())) << ' ';
  std::cout << (m.begin() == --m.end()) << ' ';
  std::cout << (++m.rbegin() == m.rend()) << ' ';
  std::cout << (++m.begin() == m.end()) << ' ';
  std::cout << (++(--m.end()) == m.end()) << '\n';
}

Compiling with g++ -fshort-enums main.cpp gives

true true true false false

while g++ main.cpp gives

false false false false true

I also tried compiling with clang++, libc++ and optimizations enabled in
various combinations.

1) g++ -nostdinc++ -I/usr/include/c++/v1 main.cpp -nodefaultlibs -lc++ -lc++abi
-lm -lc -lgcc_s -lgcc -fshort-enums

2) g++ -nostdinc++ -I/usr/include/c++/v1 main.cpp -nodefaultlibs -lc++ -lc++abi
-lm -lc -lgcc_s -lgcc -fshort-enums -O

3) clang++ -stdlib=libstdc++ -fshort-enums main.cpp

4) clang++ -O -stdlib=libstdc++ -fshort-enums main.cpp

5) clang++ -stdlib=libc++ -fshort-enums main.cpp

6) clang++ -O -stdlib=libc++ -fshort-enums main.cpp

All 1)-6) give

false false false false true

though 4) sometimes produces

true true true false false

e.g. when doing a range-based loop over the map before the comparisons.

Hope the report is legit and not too messy.

Cheers,
Christian

PS:

opensuse tumbleweed
g++ (SUSE Linux) 9.2.1 20190903 [gcc-9-branch revision 275330]
clang version 9.0.0 (tags/RELEASE_900/final 372316)

[Bug rtl-optimization/92591] ICE in optimize_sc, at modulo-sched.c:1063

[zhroma at gcc dot gnu.org]

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

--- Comment #6 from Roman Zhuykov  ---
Patches are still testing.  Arm (both 32 and 64 bit) cross compilers are OK,
and I want to test some additional scenarios for powerpc.  Probably I'll post
patches next week.

[Bug c/92799] New: ICE: in get, at cgraph.h:1339

[anbu1024.me at gmail dot com]

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

Bug ID: 92799
   Summary: ICE: in get, at cgraph.h:1339
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anbu1024.me at gmail dot com
  Target Milestone: ---

$ cat test.c 

static void __attribute__ ( ( weakref ( "bar" ) ) ) foo ( void ) { } 

extern void foo ( void ) ;



$ gcc-snapshot10 --version
gcc (GCC) 10.0.0 20191201 (experimental)
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.



$ gcc-snapshot10 test.c 
test.c:2:53: internal compiler error: in get, at cgraph.h:1339
2 | static void __attribute__ ( ( weakref ( "bar" ) ) ) foo ( void ) { }
  | ^~~
0x618bad cgraph_node::get(tree_node const*)
../../gcc-10-20191201/gcc/cgraph.h:1339
0x619c7a cgraph_node::get(tree_node const*)
../../gcc-10-20191201/gcc/tree.h:3387
0x619c7a cgraph_node::analyze()
../../gcc-10-20191201/gcc/cgraphunit.c:622
0x9268ef analyze_functions
../../gcc-10-20191201/gcc/cgraphunit.c:1212
0x9274a2 symbol_table::finalize_compilation_unit()
../../gcc-10-20191201/gcc/cgraphunit.c:2925
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.



$ gcc-snapshot9 --version
gcc (GCC) 9.2.1 20191123
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.



$ gcc-snapshot9 test.c 
test.c:2:53: internal compiler error: Segmentation fault
2 | static void __attribute__ ( ( weakref ( "bar" ) ) ) foo ( void ) { }
  | ^~~
0xa8c89f crash_signal
../../gcc-9-20191123/gcc/toplev.c:326
0x71f7c2 cgraph_node* dyn_cast(symtab_node*)
../../gcc-9-20191123/gcc/is-a.h:227
0x71f7c2 cgraph_node::get(tree_node const*)
../../gcc-9-20191123/gcc/cgraph.h:1339
0x71f7c2 cgraph_node::analyze()
../../gcc-9-20191123/gcc/cgraphunit.c:640
0x721e77 analyze_functions
../../gcc-9-20191123/gcc/cgraphunit.c:1126
0x722a62 symbol_table::finalize_compilation_unit()
../../gcc-9-20191123/gcc/cgraphunit.c:2837
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/92791] [10 Regression] ICE in extract_insn, at recog.c:2311 since r278645

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
So:
struct S { S (void *a, bool b) : x (a), y (b) {} void *x; bool y; };
void bar (S);

void
foo (void *x)
{
  S sbuf_it (x, x == nullptr);
  bar (sbuf_it);
}
with -O2 -m32 -march=i686 -mtune=i586
gives the same insn, but is actually recognized.
>From what I can see, the problem is that this_fn_optabs points to something
that has been initialized in a function that has been optimized for size, but
this function is not.  So, the question is, is it invalid to use
optimize_function_for_size_p (cfun) in optab conditions?

[Bug ipa/92800] New: IPA escape analysis for structs

[christoph.muell...@theobroma-systems.com]

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

Bug ID: 92800
   Summary: IPA escape analysis for structs
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christoph.muell...@theobroma-systems.com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Having GCC infrastructure code to detect non-escaping
structs during whole-program analysis opens the door
for the field of struct reorganisation optimisations.

We are currently working on such infrastructure
and want to use this ticket to further publish
details and patches, and to collect feedback from
the community.

First implementation details:

* escape analysis for RECORD_TYPE types
* supporting code for IPA passes
* running after IPA visibility
* checking all externally visible symbols/signatures
* checking all type casts

[Bug ipa/92801] New: Drop unused struct fields

[christoph.muell...@theobroma-systems.com]

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

Bug ID: 92801
   Summary: Drop unused struct fields
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christoph.muell...@theobroma-systems.com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Non-escaping structs [1] can have their unused fields removed such that
they have a smaller memory footprint and thus allow
a more efficient cache utilisation.

We are currently working on such a pass and want to use this
ticket to further publish details and patches, and to collect
feedback from the community.

First implementation details:

* Iterate with gsi over function bodies to find field accesses
  (e.g. in assignment, call, cond or switch statements).
* Allowed for removal if never accessed
* Allowed for removal if write-only (incl. removal of write statements)
* Removal based on modification of DECL_CHAIN() of TYPE_FIELDS(t)

Early tests showed, that this has the potential to eliminate
struct fields nextout and nextin from struct arc of CPU2017's mcf benchmark.
As elements of an struct arc array are accessed for the main calculation in
the hot loop, this benchmark is a good example, where this pass will help.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92800

[Bug ipa/92538] Proposal for IPA init() constant propagation

[christoph.muell...@theobroma-systems.com]

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

--- Comment #4 from Christoph Müllner 
 ---
Early tests with this pass showed that a bunch of SPEC CPU2017 benchmarks
benefit from this. For example, the written-once global variable TTSize of
sjeng
is eliminated by this pass.

[Bug ipa/92802] New: Struct field reordering

[christoph.muell...@theobroma-systems.com]

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

Bug ID: 92802
   Summary: Struct field reordering
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christoph.muell...@theobroma-systems.com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Non-escaping structs [1] can be rearranged such that
they have a smaller memory footprint and thus allow
a more efficient cache utilisation.

We are currently working on such a pass and want to use this
ticket to further publish details and patches, and to collect
feedback from the community.

First implementation details:

* Reordering is based on modification of DECL_CHAIN()s of TYPE_FIELDS(t)
* Reordering based on size (biggest to smallest)

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92800

[Bug tree-optimization/92803] New: [10 Regression] error: type mismatch in 'vec_perm_expr' since r278764

[marxin at gcc dot gnu.org]

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

Bug ID: 92803
   Summary: [10 Regression] error: type mismatch in
'vec_perm_expr' since r278764
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu

I see the following ICE reduced from 465.tonto:

$ gcc -O3 -flto=16 -march=haswell realmat.fppized.f90 realmat3.fppized.f90
-shared
realmat3.fppized.f90:7:15:

7 |   do n = 1,order
  |   1
Warning: Deleted feature: End expression in DO loop at (1) must be integer
realmat3.fppized.f90: In function 'gaussian_f_xyz_matrices':
realmat3.fppized.f90:4: error: type mismatch in 'vec_perm_expr'
4 |function gaussian_f_xyz_matrices(self) result(ftr)
  | 
vector(4) double
vector(4) double
vector(2) double
vector(4) unsigned long
_433 = VEC_PERM_EXPR ;
during GIMPLE pass: forwprop
realmat3.fppized.f90:4: internal compiler error: verify_gimple failed
0xd16001 verify_gimple_in_cfg(function*, bool)
/home/marxin/Programming/gcc/gcc/tree-cfg.c:5445
0xbf458f execute_function_todo
/home/marxin/Programming/gcc/gcc/passes.c:1983
0xbf533e execute_todo
/home/marxin/Programming/gcc/gcc/passes.c:2037
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make: *** [/tmp/ccEdrkBy.mk:2: /tmp/ccDaF6lu.ltrans0.ltrans.o] Error 1
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

[Bug tree-optimization/92803] [10 Regression] error: type mismatch in 'vec_perm_expr' since r278764

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Created attachment 47421
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47421&action=edit
test-case

[Bug tree-optimization/92803] [10 Regression] error: type mismatch in 'vec_perm_expr' since r278764

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Created attachment 47420
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47420&action=edit
test-case

[Bug tree-optimization/92803] [10 Regression] error: type mismatch in 'vec_perm_expr' since r278764

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-04
 CC||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
  Known to work||9.2.0
   Target Milestone|--- |10.0
 Ever confirmed|0   |1
  Known to fail||10.0

[Bug libgomp/85463] [nvptx] "exit" in offloaded region doesn't terminate process

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #3 from Tobias Burnus  ---
(In reply to Martin Liška from comment #2)
> Tom: Can the bug be marked as resolved?

One has
! { dg-output "libgomp: cuStreamSynchronize error.*" { target
openacc_nvidia_accel_selected } }

That's for the output:

  ERROR STOP (possibly followed by a number or message string)

  libgomp: cuStreamSynchronize error: an illegal instruction was encountered

Which is not that nice. Also the error code is not propagated. (It is the value
of the integer used with 'error stop' or one when using nothing or a string.)

I assume the illegal instruction was a way to cause terminations with non-zero
exit code …

In my opinion: I think that's the only issue with the current implementation;
if one regards this part as WONTFIX – then the commit in comment 1 has FIXED
it. Otherwise, one can leave this bug OPEN until a better solution is found.

[Bug c/92773] GCC compilation with big array / header is infinite

[renault at fedoraproject dot org]

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

--- Comment #6 from Charles-Antoine Couret  
---
Ok with a friend we identified a bit more what is the issue.

So in fact I built (manually):

$ gcc -Wall sound/soc/codecs/tas5756m.i -o sound/soc/codecs/tas5756m.o

In that case, no output and it does not stop.

But with:

$ gcc sound/soc/codecs/tas5756m.i

It finished very quickly with some linker errors.

And with:

$ gcc -Wall sound/soc/codecs/tas5756m.i

There are a lot of outputs (warning for each line of my big arrays). And the
process is really slow, some minutes to display the first 1000 lines. It seems
slower over the time (the beginning seems really faster than the end).

I assume that's the issue that I got with Linux build system.

>From my point of view there is a performance regression somewhere. I don't
think this behaviour is normal.

[Bug libstdc++/92798] -fshort-enums can break iterators of std::map

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
-fshort-enums is an ABI-changing option, which means you should recompile the
entire toolchain including the standard libraries.

Why are you using it anyway? In C++ you can specify a fixed underlying type, so
you can control the exact size of each enumeration type.

[Bug target/92791] [10 Regression] ICE in extract_insn, at recog.c:2311 since r278645

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
We have in the documentation:
 For a named pattern, the condition may not depend on the data in
 the insn being matched, but only the target-machine-type flags.
 The compiler needs to test these conditions during initialization
 in order to learn exactly which named instructions are available in
 a particular run.
and while optimize_function_for_size_p (cfun) doesn't depend on data in the
insn being matched, it can't be said to be target-machine-type flags either.
As -m32 -O2 -march=i686 testcase below shows, while I can't reproduce the ICE
on a short testcase yet (i.e. the case when init_all_optabs is called while
optimize_function_for_size_p (cfun) is true, but this_fn_optabs is later used
in a function where it is full, this testcase shows the other case, where the
optab is initialized while it is false, but is used when it is true, so this
testcase doesn't use movstrictqi even when it should.
struct S { S (void *a, bool b) : x (a), y (b) {} void *x; bool y; };
void bar (S);

__attribute__((noipa, cold, optimize ("Os"))) void
foo (void *x)
{
  S sbuf_it (x, x == nullptr);
  bar (sbuf_it);
}

__attribute__((noipa, hot)) void
bar (S x)
{
  asm volatile ("" : : "r" (x.x), "q" (x.y) : "memory");
}

__attribute__((noipa, hot)) void
baz (void *x)
{
  S sbuf_it (x, x == nullptr);
  bar (sbuf_it);
}

__attribute__((noipa, cold, optimize ("Os"))) void
qux (void *x)
{
  S sbuf_it (x, x == nullptr);
  bar (sbuf_it);
}

int
main ()
{
  foo (nullptr);
  for (int i = 0; i < 10; i++)
baz (nullptr);
  qux (nullptr);
  return 0;
}

Seems movstrict{qi,hi} are the only i386 patterns that in init_all_optabs (as
verified by preprocessing insn-opinit.c) where something depends on size or
speed optimization of current function.

Thus, I think we should go with a patch like:
2019-12-04  Jakub Jelinek  

PR target/92791
* config/i386/i386.md (movstrict): Move test for
TARGET_PARTIAL_REG_STALL and not optimizing for size from
expander's condition to the body - FAIL; in that case.

--- gcc/config/i386/i386.md.jj  2019-12-03 09:22:17.421777187 +0100
+++ gcc/config/i386/i386.md 2019-12-04 16:35:34.193669660 +0100
@@ -2801,10 +2801,11 @@ (define_peephole2
 (define_expand "movstrict"
   [(set (strict_low_part (match_operand:SWI12 0 "register_operand"))
(match_operand:SWI12 1 "general_operand"))]
-  "!TARGET_PARTIAL_REG_STALL || optimize_function_for_size_p (cfun)"
+  ""
 {
   gcc_assert (SUBREG_P (operands[0]));
-  if (GET_MODE_CLASS (GET_MODE (SUBREG_REG (operands[0]))) != MODE_INT)
+  if ((TARGET_PARTIAL_REG_STALL && optimize_function_for_speed_p (cfun))
+  || GET_MODE_CLASS (GET_MODE (SUBREG_REG (operands[0]))) != MODE_INT)
 FAIL;
 })


which fixes the #c0 ICE and improves the above testcase (makes the Os optimized
functions shorter).

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

[redi at gcc dot gnu.org]

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

Bug ID: 92804
   Summary: [10 Regression] ICE trying to use concept as a
nested-name-specifier
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
Blocks: 67491
  Target Milestone: ---

template
concept foo = true;

template
void bar(T t)
{
  if constexpr (foo::value)
  {
  }
}

int main()
{
  bar(1);
}


Compiled with -std=gnu++2a on trunk:

iced.cc: In function 'void bar(T)':
iced.cc:7:22: internal compiler error: in cp_parser_nested_name_specifier_opt,
at cp/parser.c:6467
7 |   if constexpr (foo::value)
  |  ^
0x9edca7 cp_parser_nested_name_specifier_opt
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:6467
0x9ea58b cp_parser_simple_type_specifier
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:17994
0x9d8ee0 cp_parser_type_specifier
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:17652
0x9d9ea6 cp_parser_decl_specifier_seq
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:14249
0x9f6e6f cp_parser_condition
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:12128
0x9dce0e cp_parser_selection_statement
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:11883
0x9dce0e cp_parser_statement
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:11258
0x9de1f2 cp_parser_statement_seq_opt
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:11742
0x9de2c8 cp_parser_compound_statement
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:11696
0x9f6755 cp_parser_function_body
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:22867
0x9f6755 cp_parser_ctor_initializer_opt_and_function_body
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:22918
0x9f9a91 cp_parser_function_definition_after_declarator
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:28675
0x9fa831 cp_parser_function_definition_from_specifiers_and_declarator
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:28591
0x9fa831 cp_parser_init_declarator
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:20496
0x9ff004 cp_parser_single_declaration
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:29166
0x9ff171 cp_parser_template_declaration_after_parameters
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:28738
0x9ffc89 cp_parser_explicit_template_declaration
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:29004
0x9ffc89 cp_parser_template_declaration_after_export
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:29023
0xa02999 cp_parser_declaration
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:13271
0xa02fe7 cp_parser_translation_unit
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:4721
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


With -std=gnu++17 -fconcepts on gcc-9-branch we get an inaccurate error (it's
not a variable template) but no ICE:

iced.cc: In function 'void bar(T)':
iced.cc:7:17: error: variable template-id 'foo' in nested-name-specifier
7 |   if constexpr (foo::value)
  | ^~
iced.cc:2:9: note: 'template concept const bool foo' declared here
2 | concept foo = true;
  | ^~~
iced.cc:7:30: error: expected initializer before ')' token
7 |   if constexpr (foo::value)
  |  ^
iced.cc:7:30: error: the value of 'value' is not usable in a constant
expression
iced.cc: In instantiation of 'void bar(T) [with T = int]':
iced.cc:14:8:   required from here
iced.cc:7:3: error: the value of 'value' is not usable in a constant expression
7 |   if constexpr (foo::value)
  |   ^~
iced.cc:5:12: warning: unused parameter 't' [-Wunused-parameter]
5 | void bar(T t)
  |  ~~^


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||9.2.1
  Known to fail||10.0

--- Comment #1 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #0)
> With -std=gnu++17 -fconcepts on gcc-9-branch we get an inaccurate error
> (it's not a variable template) but no ICE:

Oh, and the same on trunk. It only ICEs with -std=gnu++2a


So arguably, not a regression, because GCC 9 doesn't support C++2a concepts.

[Bug tree-optimization/92738] [10 regression] Large code size growth for -O2 binaries between 2019-05-19...2019-05-29

[tkoenig at gcc dot gnu.org]

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

--- Comment #12 from Thomas Koenig  ---
(In reply to Wilco from comment #11)

> Would using -frepack-arrays solve this issue? I proposed making that the
> default a while back. It would do any repacking that is necessary at call
> sites rather than creating multiple copies of all loops in every function.

I'm not convinced that that is the answer - this would penalize (at runtime)
programs which use non-contiguous memory when _not_ passing them to
an explicit size or assumed size paramter. For example, all the optimizations
for passing a transposed argument would then no longer work.

What we could do instead is to introduce another option, -frepack-inline
(or whatever we want to call it) and enable this by default at all -O
except at -Os. People who have problems can then enable that option for
the specific files they have the problems with.

[Bug fortran/92805] New: gfortran: blanks within literal constants should not be allowed

[ripero84 at gmail dot com]

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

Bug ID: 92805
   Summary: gfortran: blanks within literal constants should not
be allowed
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ripero84 at gmail dot com
  Target Milestone: ---

I belive that when writing free source form and using kind parameters as part
of integer, real, logical or character literal constants, there cannot be any
blanks between the underscore and the kind-param, or between the underscore and
the rest of characters that are part of the same literal constant.  This means
that, e.g.,

3.1415_4

is a valid real literal constant (if 4 is a valid real kind), but

3.1415 _4
3.1415_ 4

are not - and these don't have an possible interpretations as valid Fortran.

My interpretation is based on the following sections and rules of the Fortran
2018 standard:
* 6.2.1: "A lexical token is a keyword, name, literal constant other than a
complex literal constant [...]"
* 6.3.2.2: "In free source form blank characters shall not appear within
lexical tokens other than in a character context or in a format specification."
* R708, R714, and R725 establish that a trailing _kind-param is an optional
part of int-literal-constants, real-literal-constants, and
logical-literal-constants, respectively.
* R724 establishes that a leading kind-param_ is an optional part of a
char-literal-constant.

As far as I can see, these requirements go back all the way to the first
version of the standard that supported free source form, Fortran 90.

Unfortunately, all the versions of gfortran I've tried so far (9.2.1 20191109,
8.3.0, 7.5.0, 6.4.0 20181019), irrespective of the use of one of the -std=
flags or none, fail to detect the presence of blanks at one or both of the
sides of the underscore, and happily compile the source code.  This happens
also irrespective of whether the kind-param is numeric (3.1415_4) or an integer
variable with the parameter attribute

INTEGER, PARAMETER :: k = KIND(1.0)
WRITE(*,*) 3.1415_k ! valid Fortran
WRITE(*,*) 3.1415 _k ! invalid Fortran not detected by gfortran

with the only exception of character literal constants, where gfortran actually
produces an error if one attempts to compile code where spaces are present and
the kind-param is given by a variable:

WRITE(*,*) 4_ 'b' ! invalid Fortran not detected by gfortran
INTEGER, PARAMETER :: k = KIND('a')
WRITE(*,*) k_ 'b' ! invalid Fortran detected by gfortran

[Bug tree-optimization/92803] [10 Regression] error: type mismatch in 'vec_perm_expr' since r278764

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Reduced testcase with -O2 -mavx:
typedef double v4df __attribute__((vector_size (32)));
typedef double v2df __attribute__((vector_size (16)));

v2df
foo (v4df x, double *p, v2df y)
{
  return (v2df) { x[3], *p };
}

[Bug tree-optimization/92738] [10 regression] Large code size growth for -O2 binaries between 2019-05-19...2019-05-29

[tkoenig at gcc dot gnu.org]

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

--- Comment #13 from Thomas Koenig  ---
(In reply to Thomas Koenig from comment #12)
> People who have problems can then enable

I meant disable, of course.

> that option for
> the specific files they have the problems with.

[Bug c++/81178] [concepts] poor (partial?) diagnostic for alias substitution failure in a concept body

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Huh, trunk now accepts the program.

[Bug c++/92806] New: Suboptimal diagnostic for concept that depends on non-bool value

[redi at gcc dot gnu.org]

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

Bug ID: 92806
   Summary: Suboptimal diagnostic for concept that depends on
non-bool value
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
Blocks: 67491
  Target Milestone: ---

template
struct trait
{
  enum { value = 1 };
};

template
concept foo = trait::value;

static_assert(foo);


Compiled with -std=gnu++2a:

nonbool.cc:8:9:   required by the constraints of 'template concept
foo'
nonbool.cc:10:24: error: constraint does not have type 'bool'
   10 | static_assert(foo);
  |^
nonbool.cc:10:15: error: non-constant condition for static assertion
   10 | static_assert(foo);
  |   ^~~~
nonbool.cc:8:9:   required by the constraints of 'template concept
foo'
nonbool.cc:10:15: error: constraint does not have type 'bool'


It's not clear from the diagnostic that the problem is trait::value on line
8, so the user is left thinking "how can a concept not have type 'bool'?!"

The fix is something like:

template
concept foo = (bool)trait::value;
  ^~

so it would be helpful to diagnose the non-bool type at the location of the
concept definition, not its use.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues

[Bug rtl-optimization/92007] [9/10 Regression] ICE: verify_flow_info failed (error: EH edge crosses section boundary in bb 7)

[asolokha at gmx dot com]

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

--- Comment #19 from Arseny Solokha  ---
I believe this is fixed on both affected branches for over a month, thus the PR
can be closed.

[Bug fortran/92805] gfortran: blanks within literal constants should not be allowed

[ripero84 at gmail dot com]

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

ripero84 at gmail dot com changed:

   What|Removed |Added

 CC||ripero84 at gmail dot com

--- Comment #1 from ripero84 at gmail dot com ---
Created attachment 47422
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47422&action=edit
Test source files

I believe all attached tests should fail to compile, but currently only
char_*_var.f90 tests do so.

[Bug rtl-optimization/92176] LRA problem with reloads for subreg operands

[vmakarov at gcc dot gnu.org]

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

--- Comment #6 from Vladimir Makarov  ---
(In reply to Vladimir Makarov from comment #5)
> 
> I'll investigate this problem more.

Hi, Andreas.  The rtlanal code (!lra_in_progress) was added to GCC since the
first patch introducing LRA.  As I wrote it was for x86/x86-64 insn
descriptions which match operands of different modes one of which is XFmode. 
After that I introduced LRA_SUBREG_P for solving this problem.  So I believe we
can remove the code in rtlanal.  Here is the patch I'd like to commit.  I
checked it on variety of targets.  Is the patch ok for you?  I am specially
interesting in your opinion about the test.  It is hard for me get z13 machine,
so I decided to use scan-assembler-not instead of running you test.

Index: ../../gcc/gcc/ChangeLog
===
--- ../../gcc/gcc/ChangeLog (revision 278865)
+++ ../../gcc/gcc/ChangeLog (working copy)
@@ -1,3 +1,10 @@
+2019-12-04  Andreas Krebbel  
+   Vladimir Makarov  
+
+   PR rtl-optimization/92176
+   * lra.c (simplify_subreg_regno): Don't permit unconditional
+   changing mode for LRA too.
+
 2019-11-29  Vladimir Makarov  

PR rtl-optimization/92283
Index: ../../gcc/gcc/rtlanal.c
===
--- ../../gcc/gcc/rtlanal.c (revision 278413)
+++ ../../gcc/gcc/rtlanal.c (working copy)
@@ -4009,9 +4009,7 @@ simplify_subreg_regno (unsigned int xreg
   /* Give the backend a chance to disallow the mode change.  */
   if (GET_MODE_CLASS (xmode) != MODE_COMPLEX_INT
   && GET_MODE_CLASS (xmode) != MODE_COMPLEX_FLOAT
-  && !REG_CAN_CHANGE_MODE_P (xregno, xmode, ymode)
-  /* We can use mode change in LRA for some transformations.  */
-  && ! lra_in_progress)
+  && !REG_CAN_CHANGE_MODE_P (xregno, xmode, ymode))
 return -1;

   /* We shouldn't simplify stack-related registers.  */
Index: ../../gcc/gcc/testsuite/ChangeLog
===
--- ../../gcc/gcc/testsuite/ChangeLog   (revision 278770)
+++ ../../gcc/gcc/testsuite/ChangeLog   (working copy)
@@ -1,3 +1,9 @@
+2019-12-04  Andreas Krebbel  
+   Vladimir Makarov  
+
+   PR rtl-optimization/92176
+   * gcc.target/s390/pr92176.c: New test.
+
 2019-11-27  Vladimir Makarov  

PR rtl-optimization/90007
Index: ../../gcc/gcc/testsuite/gcc.target/s390/pr92176.c
===
--- ../../gcc/gcc/testsuite/gcc.target/s390/pr92176.c   (nonexistent)
+++ ../../gcc/gcc/testsuite/gcc.target/s390/pr92176.c   (working copy)
@@ -0,0 +1,33 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -march=z13" } */
+
+int a = 5, b, c, d, g, h, k, l, m, o;
+static int e[7];
+int *volatile i = &d;
+long j;
+
+short p(int f, int dummy) {
+  k = 0 != (*e = m);
+  j = 0;
+  for (; j < 59; j = j + 1)
+*i |= b;
+  g = 1;
+  for (; g <= 4; g++) {
+o = 0;
+for (; o <= 4; o++)
+  i = (int * volatile)(long)l;
+  }
+  return 42;
+}
+
+void
+q() {
+  char *n = (char*)&b;
+
+  (*n = a) == p(e[6], c);
+  for (; h;)
+for (;;)
+  ;
+}
+
+/* { dg-final { scan-assembler-not "\tvsteb" } } */

[Bug rtl-optimization/92007] [9/10 Regression] ICE: verify_flow_info failed (error: EH edge crosses section boundary in bb 7)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #20 from Jakub Jelinek  ---
.

[Bug target/92807] New: gcc generate extra move for the snippet code

[skpgkp2 at gmail dot com]

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

Bug ID: 92807
   Summary: gcc generate extra move for the snippet code
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: skpgkp2 at gmail dot com
  Target Milestone: ---

[Bug libstdc++/92798] -fshort-enums can break iterators of std::map

[fc9vqetne38 at temp dot mailbox.org]

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

--- Comment #2 from Christian N  ---
To be honest, I'm not sure when and why it came to be. The build instructions
are partially from an old project and weren't cleaned properly. The immediate
code base actually only uses scoped enums. The problem just came up and upon
investigating, removing the flag fixed it.

It didn't occur to me that basically everything needs recompilation with
-fshort-enums, but it makes perfect sense.

I suppose this report can be closed as invalid then!?

Thanks!

[Bug tree-optimization/92803] [10 Regression] error: type mismatch in 'vec_perm_expr' since r278764

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Untested fix:
--- gcc/tree-ssa-forwprop.c.jj  2019-12-03 20:21:30.554464396 +0100
+++ gcc/tree-ssa-forwprop.c 2019-12-04 17:48:36.351450274 +0100
@@ -2283,11 +2283,11 @@ simplify_vector_constructor (gimple_stmt
   gimple_seq stmts = NULL;
   if (!orig[1])
orig[1] = orig[0];
-  else if (orig[1] == error_mark_node
-  && one_nonconstant)
+  else if (orig[1] == error_mark_node && one_nonconstant)
{
  orig[1] = gimple_build_vector_from_val (&stmts, UNKNOWN_LOCATION,
- type, one_nonconstant);
+ TREE_TYPE (orig[0]),
+ one_nonconstant);
  /* ???  We can see if we can safely convert to the original
 element type.  */
  converted_orig1 = conv_code != ERROR_MARK;
Though, there is another issue, for the nelts 2 vectors
simplify_vector_constructor created code is actually larger than old code.
And, it might be beneficial if we one day implement clang-like
__builtin_shufflevector or at least add to VEC_PERM_EXPR or something similar
the possibility to say certain element is a don't care (for
__builtin_shufflevector I think that is -1 or negative?), as e.g. on AVX/AVX2
when extracting 128-bit vector out of 256-bit permutation all the upper
elements are don't care and we might get better code if the backend picks the
best element indexes for those to get smallest/fastest permutation.

[Bug target/92807] gcc generate extra move for the snippet code along with lea instruction.

[skpgkp2 at gmail dot com]

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

Sunil Pandey  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com,
   ||skpgkp2 at gmail dot com
Summary|gcc generate extra move for |gcc generate extra move for
   |the snippet code|the snippet code along with
   ||lea instruction.

--- Comment #1 from Sunil Pandey  ---
$ cat t1.c
#include
uint32_t abs2( uint32_t a )
{
uint32_t s = ((a>>15)&0x10001)*0x;
return (a+s)^s;
}

$ gcc --version
gcc (GCC) 9.2.1 20190827 (Red Hat 9.2.1-1)
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


$ gcc -Ofast -S t1.c -o t1.s.gcc.9
$ cat t1.s.gcc.9
.file   "t1.c"
.text
.p2align 4
.globl  abs2
.type   abs2, @function
abs2:
.LFB0:
.cfi_startproc
movl%edi, %edx
shrl$15, %edx
andl$65537, %edx
movl%edx, %eax
sall$16, %eax
subl%edx, %eax
movl%eax, %edx
leal(%rdi,%rax), %eax
xorl%edx, %eax
ret
.cfi_endproc
.LFE0:
.size   abs2, .-abs2
.ident  "GCC: (GNU) 9.2.1 20190827 (Red Hat 9.2.1-1)"
.section.note.GNU-stack,"",@progbits


Intel compiler generate add instead of lea as well as 1 less mov instruction
for same code.

$ icc -Ofast -S t1.c -o t1.s.icc

$ cat t1.s.icc

.L_2__routine_start_abs2_0:
# -- Begin  abs2
.text
# mark_begin;
   .align16,0x90
.globl abs2
# --- abs2(uint32_t)
abs2:
# parameter 1: %edi
..B1.1: # Preds ..B1.0
# Execution count [1.00e+00]
.cfi_startproc
..___tag_value_abs2.1:
..L2:
  #3.1
movl  %edi, %edx#4.23
shrl  $15, %edx #4.23
andl  $65537, %edx  #4.27
movl  %edx, %eax#4.36
shll  $16, %eax #4.36
subl  %edx, %eax#4.36
addl  %eax, %edi#5.19
xorl  %edi, %eax#5.22
ret #5.22
.align16,0x90
# LOE
.cfi_endproc
# mark_end;
.type   abs2,@function
.size   abs2,.-abs2
..LNabs2.0:
.data
# -- End  abs2
.data
.section .note.GNU-stack, ""
# End

[Bug target/92807] gcc generate extra move for the snippet code along with lea instruction.

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #2 from H.J. Lu  ---
Shouldn't

leal(%rdi,%rax), %eax

be changed to

addl %edi, %eax

unconditionally?

[Bug tree-optimization/92803] [10 Regression] error: type mismatch in 'vec_perm_expr' since r278764

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 47423
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47423&action=edit
gcc10-pr92803.patch

Full untested patch for the ICE.

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

[mikpelinux at gmail dot com]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #3 from Mikael Pettersson  ---
I've been doing many gcc-10 native bootstraps on m68k (Aranym) (roughly one per
week), and haven't hit any m68k-specific bootstrap failures.  In particular,
r278681 (post-CC0 conversion) bootstrapped fine with c,ada,c++.  My builds use
pristine sources, save for a local patch to disable a few test cases known to
time out on m68k.

[Bug libstdc++/92798] -fshort-enums can break iterators of std::map

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Christian N from comment #2)
> It didn't occur to me that basically everything needs recompilation with
> -fshort-enums, but it makes perfect sense.

Read the fabulous manual:

  Warning: the -fshort-enums switch causes GCC to generate code that is not
  binary compatible with code generated without that switch.  Use it to conform
  to a non-default application binary interface.

> I suppose this report can be closed as invalid then!?

OK, done.

[Bug target/92808] New: GCC sets BTI flag in .note.gnu.property section even though not all functions are compiled with BTI

[momchil.velikov at gmail dot com]

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

Bug ID: 92808
   Summary: GCC sets BTI flag in .note.gnu.property section even
though not all functions are compiled with BTI
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: momchil.velikov at gmail dot com
  Target Milestone: ---

When GCC compiles the following source
```
__attribute__((target("branch-protection=pac-ret"))) int f() { return 0; }
__attribute__((target("branch-protection=bti"))) int g() { return 0; }
```

with

  aarch64-none-linux-gnu-gcc -c x7.c

the `.note.gnu.property` section has the BTI flag set:

```
$ llvm-readelf --notes x7.o
Displaying notes found at file offset 0x0090 with length 0x0020:
  OwnerData size Description
  GNU  0x0010NT_GNU_PROPERTY_TYPE_0 (property note)
Properties:aarch64 feature: BTI

```

IMHO, the flag should be clear, since not all of the functions are compiled
with BTI.

[Bug target/92807] gcc generate extra move for the snippet code along with lea instruction.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Well, lea has to be used in case the flags are live across it.  Not the case of
this PR though of course.

[Bug ipa/92801] Drop unused struct fields

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Removal based on modification of DECL_CHAIN() of TYPE_FIELDS(t)

would mean you have to convert either all uses of such types or none.  Wouldn't
it be better to rather do it just on particular uses of the types and replace
the types with a new shorter or reordered type instead?  I mean, if you in a
couple of functions never access some fields or just write only access them,
but in another spot those fields are used, there is no reason to punt.

[Bug target/92807] gcc generate extra move for the snippet code along with lea instruction.

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
Created attachment 47424
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47424&action=edit
A patch

[Bug ipa/92809] New: [10 regression] error: calls_comdat_local is set outside of a comdat group

[dimhen at gmail dot com]

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

Bug ID: 92809
   Summary: [10 regression] error: calls_comdat_local is set
outside of a comdat group
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimhen at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

r278936 PASS
r278958 FAIL

Maybe dup PR86905?

$ $ cat x.ii
struct a {
  int operator!=(a);
};
template  struct c : a {
  b operator*();
  void operator++();
};
template  struct e {
  using f = c;
  f begin();
  f end();
};
struct g {
  virtual void anchor();
};
struct h {
  e i;
  virtual void j(int &);
  void k();
};
struct l : g, h {
  void j(int &) {}
};
void h::k() {
  for (auto m : i)
j(*m);
}

$ g++ -fpreprocessed -O2 -std=c++11 -fchecking=1 -c x.ii
x.ii:27:1: error: calls_comdat_local is set outside of a comdat group
   27 | }
  | ^
_ZThn8_N1l1jERi/2 (virtual void l::_ZThn8_N1l1jERi(int&)) @0x7f578fca12d0
  Type: function
  Body removed by symtab_remove_unreachable_nodes
  Visibility: externally_visible public weak comdat comdat_group:_ZN1l1jERi
one_only section:.text._ZN1l1jERi (implicit_section) virtual artificial
  References: 
  Referring: 
  Availability: not_available
  Function flags: calls_comdat_local indirect_call_target
  Former thunk fixed offset -8 virtual value 0 indirect_offset 0 has virtual
offset 0
  Called by: 
  Calls: 
during IPA pass: inline
x.ii:27:1: internal compiler error: verify_cgraph_node failed
0xd7a956 cgraph_node::verify_node()
/home/dimhen/src/gcc_current/gcc/cgraph.c:3444
0xd6ea94 symtab_node::verify()
/home/dimhen/src/gcc_current/gcc/symtab.c:1279
0xd6fbbe symtab_node::verify_symtab_nodes()
/home/dimhen/src/gcc_current/gcc/symtab.c:1299
0xff0290 symtab_node::checking_verify_symtab_nodes()
/home/dimhen/src/gcc_current/gcc/cgraph.h:650
0xff0290 symbol_table::remove_unreachable_nodes(_IO_FILE*)
/home/dimhen/src/gcc_current/gcc/ipa.c:672
0x1b893f6 ipa_inline
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:2695
0x1b893f6 execute
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:3088
Please submit a full bug report,

g++ -v
Using built-in specs.
COLLECT_GCC=/home/dimhen/arch-gcc/gcc_current/bin/g++
COLLECT_LTO_WRAPPER=/home/dimhen/arch-gcc/gcc_current/libexec/gcc/x86_64-pc-linux-gnu/10.0.0/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
Target: x86_64-pc-linux-gnu
Configured with: /home/dimhen/src/gcc_current/configure
--prefix=/home/dimhen/arch-gcc/gcc_current
--enable-checking=yes,df,fold,rtl,extra --enable-languages=c,c++,lto
--disable-multilib --enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --enable-cet --with-tune=native
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.0 20191204 (experimental) [trunk revision 278958] (GCC)

[Bug fortran/92775] [8/9/10 Regression] Incorrect expression in DW_AT_byte_stride on an array

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-04
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Jakub Jelinek  ---
It has been updated.  I'll have a look.

[Bug fortran/92775] [8/9/10 Regression] Incorrect expression in DW_AT_byte_stride on an array

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug ipa/92801] Drop unused struct fields

[christoph.muell...@theobroma-systems.com]

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

--- Comment #2 from Christoph Müllner 
 ---
Yes, our current approach is all or nothing (i.e. all uses of a struct are
changed or none).

Optimizing individual uses of a type would allow a more tailored optimization.
We decided to defer such an approach in our first shot because it would
make the analysis more complex as we would make individual struct uses
incompatible and we would have to track these uses of the structs
(across compilation units).

[Bug bootstrap/92661] [10 Regression] Bootstrap failure with builtin-types.def change

[bergner at gcc dot gnu.org]

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

--- Comment #12 from Peter Bergner  ---
Author: bergner
Date: Wed Dec  4 19:53:26 2019
New Revision: 278973

URL: https://gcc.gnu.org/viewcvs?rev=278973&root=gcc&view=rev
Log:
Do not define builtins that overload disabled builtins.

PR bootstrap/92661
* config/rs6000/rs6000-c.c (struct altivec_builtin_types): Move to
rs6000.h.
(altivec_overloaded_builtins): Move to rs6000-call.c.
* config/rs6000/rs6000.h (struct altivec_builtin_types): Moved from
rs6000-c.c.
* config/rs6000/rs6000-call.c (rs6000_builtin_info): Make static.
(altivec_overloaded_builtins): Moved from rs6000-c.c.
(rs6000_common_init_builtins): Do no define builtins that overload
builtins that have been disabled.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000-c.c
trunk/gcc/config/rs6000/rs6000-call.c
trunk/gcc/config/rs6000/rs6000.h

[Bug bootstrap/92661] [10 Regression] Bootstrap failure with builtin-types.def change

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #13 from Peter Bergner  ---
Ok, second patch to fix the overloaded builtin issue has been committed to
trunk, so I'm marking this as resolved.

We are discussing about disabling the running of the powerpc/dfp/ tests when
DFP is disabled, but that isn't required for this bugzilla.

[Bug go/92810] New: Compiling GCC go for aarch64_be-marvell-linux-gnu fails

[pinskia at gcc dot gnu.org]

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

Bug ID: 92810
   Summary: Compiling GCC go for aarch64_be-marvell-linux-gnu
fails
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: pinskia at gcc dot gnu.org
CC: cmang at google dot com
  Target Milestone: ---
Target: aarch64_be-marvell-linux-gnu

cpugen.go:3:1: error: expected operand
3 | const FunctionDescriptors = false
  | ^
cpugen.go:3:1: error: expected ‘;’ or newline after top level declaration
version.go:67:13: error: expected ‘;’ or ‘)’ or newline
   67 |   BigEndian =
  | ^
version.go:67:3: error: reference to undefined name ‘BigEndian’
   67 |   BigEndian =
  |   ^
libtool: compile: 
/home/apinski/src/toolchain-10/build-aarch64_be-marvell-linux-gnu/./gcc/gccgo
-B/home/apinski/src/toolchain-10/build-aarch64_be-marvell-linux-gnu/./gcc/
-B/bajas/pinskia/src/toolchain-10/scripts/../marvell-tools-be/aarch64_be-marvell-linux-gnu/bin/
-B/bajas/pinskia/src/toolchain-10/scripts/../marvell-tools-be/aarch64_be-marvell-linux-gnu/lib/
-isystem
/bajas/pinskia/src/toolchain-10/scripts/../marvell-tools-be/aarch64_be-marvell-linux-gnu/include
-isystem
/bajas/pinskia/src/toolchain-10/scripts/../marvell-tools-be/aarch64_be-marvell-linux-gnu/sys-include
-L/home/apinski/src/toolchain-10/build-aarch64_be-marvell-linux-gnu/./ld -O2 -g
-I . -c -fgo-pkgpath=crypto/subtle
/bajas/pinskia/src/toolchain-10/scripts/../src/libgo/go/crypto/subtle/constant_time.go
 -fPIC -o crypto/.libs/subtle.o
Makefile:2826: recipe for target 'runtime/internal/sys.lo' failed
make[5]: *** [runtime/internal/sys.lo] Error 1
make[5]: *** Waiting for unfinished jobs


 CUT ---
This is because aarch64_be is not detected at all in libgo/configure .
Currently only aarch64-*-* is detected:
  aarch64-*-*)
GOARCH=arm64
;;

Even though arm64be is listed in ALLGOARCH.

[Bug demangler/92797] cplus_demangle() produces huge amount of output (on trunk)

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Tim Ruehsen from comment #1)
> BTW, llvm-cxxfilt does not show this behavior.

Could it because it does not implement the D demangler?

[Bug c++/92811] New: Odd optimisation differences with lambdas

[david at westcontrol dot com]

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

Bug ID: 92811
   Summary: Odd optimisation differences with lambdas
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david at westcontrol dot com
  Target Milestone: ---

While playing with lambdas for higher order functions (in particular, functions
that manipulate functions and return new ones), I saw some differences in the
optimisations depending on seemingly minor changes to how functions are
defined.  This is my sample code:

template 
auto twice(F f)
{
return [f](int v) { return f(f(v)); };
};

int g1(int i)
{
return i + 3;
};

auto g2 = [](int i) { return i + 3; };

int test(int i) {
auto tw = twice(g1);
return tw(i);
}

int test2(int i) {
auto tw = twice(g1);
auto tw2 = twice(tw);
return tw2(i);
}

int test3(int i) {
auto tw = twice(g2);
return tw(i);
}

int test4(int i) {
auto tw = twice(g2);
auto tw2 = twice(tw);
return tw2(i);
}


The generated assembly (x86-64) with -O2 or -O3 is:

g1(int):
leal3(%rdi), %eax
ret
test(int):
leal6(%rdi), %eax
ret
test2(int):
addl$6, %edi
callg1(int)
movl%eax, %edi
jmp g1(int)
test3(int):
leal6(%rdi), %eax
ret
test4(int):
leal12(%rdi), %eax
ret

With -O1, test3 and test4 (where the original function is a lambda) were still
fully optimised, while test1 and test2 had 2 and 4 calls to g1.

(For comparison, clang requires -O2 to get good code, but fully optimises all 4
test functions.)

[Bug c/84919] [8/9/10 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

--- Comment #17 from Martin Sebor  ---
The patch below avoids the warning.  Unfortunately, as a result of bug 92666,
it triggers another bogus warning during bootstrap.

Index: gcc/c-family/c-common.c
===
--- gcc/c-family/c-common.c (revision 278975)
+++ gcc/c-family/c-common.c (working copy)
@@ -5763,8 +5763,26 @@ check_function_arguments (location_t loc, const_tr
   if (warn_format)
 check_function_sentinel (fntype, nargs, argarray);

-  if (warn_restrict)
-warned_p |= check_function_restrict (fndecl, fntype, nargs, argarray);
+  if (fndecl && fndecl_built_in_p (fndecl, BUILT_IN_NORMAL))
+{
+  switch (DECL_FUNCTION_CODE (fndecl))
+   {
+   case BUILT_IN_SPRINTF:
+   case BUILT_IN_SPRINTF_CHK:
+   case BUILT_IN_SNPRINTF:
+   case BUILT_IN_SNPRINTF_CHK:
+ /* Let the sprintf pass handle these.  */
+ return warned_p;
+
+   default:
+ break;
+   }
+}
+
+  /* check_function_restrict sets the DECL_READ_P for arguments
+ so it must be called unconiditionally.  */
+  warned_p |= check_function_restrict (fndecl, fntype, nargs, argarray);
+
   return warned_p;
 }

[Bug fortran/91661] ICE in gfc_conv_intrinsic_dot_product, at fortran/trans-intrinsic.c:4804

[anlauf at gcc dot gnu.org]

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
The following variant of the patch in comment#3 regtests cleanly and handles
more complex cases, like

  integer, parameter :: b(a(1)+a(2)) = 3

Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c  (Revision 278972)
+++ gcc/fortran/decl.c  (Arbeitskopie)
@@ -29,6 +29,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "parse.h"
 #include "constructor.h"
 #include "target.h"
+#include "arith.h"

 /* Macros to access allocate memory for gfc_data_variable,
gfc_data_value and gfc_data.  */
@@ -2587,8 +2588,20 @@ variable_decl (int elem)
  if (e->expr_type != EXPR_CONSTANT)
{
  n = gfc_copy_expr (e);
+ switch (n->expr_type)
+   {
+   case EXPR_VARIABLE:
+   case EXPR_FUNCTION:
+   case EXPR_OP:
+ gfc_resolve_expr (n);
+ break;
+
+   default:
+ break;
+   }
  gfc_simplify_expr (n, 1);
- if (n->expr_type == EXPR_CONSTANT)
+ if (n->expr_type == EXPR_CONSTANT
+ && gfc_range_check (n) == ARITH_OK)
gfc_replace_expr (e, n);
  else
gfc_free_expr (n);
@@ -2597,8 +2610,20 @@ variable_decl (int elem)
  if (e->expr_type != EXPR_CONSTANT)
{
  n = gfc_copy_expr (e);
+ switch (n->expr_type)
+   {
+   case EXPR_VARIABLE:
+   case EXPR_FUNCTION:
+   case EXPR_OP:
+ gfc_resolve_expr (n);
+ break;
+
+   default:
+ break;
+   }
  gfc_simplify_expr (n, 1);
- if (n->expr_type == EXPR_CONSTANT)
+ if (n->expr_type == EXPR_CONSTANT
+ && gfc_range_check (n) == ARITH_OK)
gfc_replace_expr (e, n);
  else
gfc_free_expr (n);

Given the clumsiness to circumvent the issue with type-bound procedures,
I feel that the simplifications involved should be done at an earlier stage.
Anybody knows where that might be?

[Bug demangler/70517] c++filt crashes when demangling a symbol

[cbiesinger at google dot com]

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

Christian Biesinger  changed:

   What|Removed |Added

 CC||cbiesinger at google dot com

--- Comment #5 from Christian Biesinger  ---
Using binutils from a month ago or so, this does not crash but also does not
demangle...

[Bug demangler/81682] Timeout in demangler

[cbiesinger at google dot com]

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

Christian Biesinger  changed:

   What|Removed |Added

 CC||cbiesinger at google dot com

--- Comment #3 from Christian Biesinger  ---
In today's binutils, both those testcases run really quick in c++filt
(cxxfilt).