[Bug c/91398] Possible missed optimization: Can a pointer be passed as hidden pointer in x86-64 System V ABI

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  ---
On August 10, 2019 4:22:25 AM GMT+02:00, peter at cordes dot ca
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91398
>
>Peter Cordes  changed:
>
>   What|Removed |Added
>
> CC||peter at cordes dot ca
>
>--- Comment #4 from Peter Cordes  ---
>If so, restrict would make this optimization safe if we can prove that
>do_something is "noexcept" and doesn't longjmp.

Yes.

[Bug target/91408] [10 Regression] ICE in extract_insn, at recog.c:2310 since r273981

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Sat Aug 10 10:13:52 2019
New Revision: 274251

URL: https://gcc.gnu.org/viewcvs?rev=274251&root=gcc&view=rev
Log:
PR target/91408
* config/i386/mmx.md (usadv8qi): Use register_operand instead of
vector_operand.

* gcc.target/i386/pr91408.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr91408.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/mmx.md
trunk/gcc/testsuite/ChangeLog

[Bug fortran/91413] New: [F2018]: Procedures are recursive by default; switching from stack to static allocation is not safe

[jb at gcc dot gnu.org]

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

Bug ID: 91413
   Summary: [F2018]: Procedures are recursive by default;
switching from stack to static allocation is not safe
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jb at gcc dot gnu.org
  Target Milestone: ---

As of Fortran 2018, procedures are recursive by default. However, currently
GFortran places automatic arrays larger than the limit specified by
-fmax-stack-var-size= (default 32768 bytes(?)) in static memory, which breaks
reentrancy and thread-safety. Removing this outright, in effect making
-frecursize the default, is probably not OK either as that would cause many
applications to crash due to exhausting stack space. The remaining option then
would be to switch to using heap memory rather than static memory for local
arrays going over the limit.

For a thread on this topic, see
https://gcc.gnu.org/ml/fortran/2017-12/msg00082.html

[Bug fortran/91414] New: Improved PRNG

[jb at gcc dot gnu.org]

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

Bug ID: 91414
   Summary: Improved PRNG
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jb at gcc dot gnu.org
  Target Milestone: ---

Currently GFortran uses the xorshift1024* PRNG. The author of that PRNG has an
improved PRNG "xoshiro" at http://prng.di.unimi.it/ , described in detail at
https://arxiv.org/abs/1805.01407 . GFortran could (should?) switch to this
improved algorithm.

[Bug d/91238] internal compiler error: in add_expr, at tree.c:7794

[ibuclaw at gdcproject dot org]

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

--- Comment #6 from Iain Buclaw  ---
Fixed in trunk in r274253.

[Bug d/91238] internal compiler error: in add_expr, at tree.c:7794

[ibuclaw at gcc dot gnu.org]

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

--- Comment #5 from ibuclaw at gcc dot gnu.org ---
Author: ibuclaw
Date: Sat Aug 10 14:11:49 2019
New Revision: 274253

URL: https://gcc.gnu.org/viewcvs?rev=274253&root=gcc&view=rev
Log:
d: Fix internal compiler error: in add_expr, at tree.c:7794

gcc/d/ChangeLog:

PR d/91238
* d-codegen.cc (build_address): If taking the address of a CALL_EXPR,
wrap it in a TARGET_EXPR.

gcc/testsuite/ChangeLog:

PR d/91238
* gdc.dg/pr91238.d: New test.

Added:
trunk/gcc/testsuite/gdc.dg/pr91238.d
Modified:
trunk/gcc/d/ChangeLog
trunk/gcc/d/d-codegen.cc
trunk/gcc/testsuite/ChangeLog

[Bug c++/91415] New: Invalid warning for C++17 sequencing of shift operator E1<

[maxim.yegorushkin at gmail dot com]

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

Bug ID: 91415
   Summary: Invalid warning for C++17 sequencing of shift operator
E1<

[Bug c++/91415] Invalid warning for C++17 sequencing of shift operator E1<

[maxim.yegorushkin at gmail dot com]

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

--- Comment #1 from Maxim Egorushkin  ---
gcc-9.1 produces the same warning.

[Bug c++/91415] Invalid warning for C++17 sequencing of shift operator E1<

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
So shall we emit no warnings with -std=c++17 -Wsequence-point on:
struct S { int a[10]; };

void
foo (int i, int (&x)[10][10], int y[10], S z[10], S *w[10])
{
  int b = x[i++][i++];
  int c = i++ << i++;
  int d = i++ >> i++;
  int e = i++ && i++;
  int f = i++ ? i++ : i++;
  int g = (i++, i++);
  int h = z[i++].a[i++];
  int j = w[i++]->a[i++];
  y[i++] = y[i++];
}
and warnings on 6 lines for -std=c++14?  Right now we emit warnings on those 6
lines in both standard modes.  clang 7 does the same, clang 9 emits them just
on <<, >> and assignment. + add a testcase for .* and ->* too, what else?

[Bug c++/91415] Invalid warning for C++17 sequencing of shift operator E1<

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
--- gcc/c-family/c-common.c.jj  2019-07-30 08:27:49.987555303 +0200
+++ gcc/c-family/c-common.c 2019-08-10 18:13:20.821949299 +0200
@@ -1889,6 +1889,7 @@ verify_tree (tree x, struct tlist **pbef
 case COMPOUND_EXPR:
 case TRUTH_ANDIF_EXPR:
 case TRUTH_ORIF_EXPR:
+sequenced_binary:
   tmp_before = tmp_nosp = tmp_list2 = tmp_list3 = 0;
   verify_tree (TREE_OPERAND (x, 0), &tmp_before, &tmp_nosp, NULL_TREE);
   warn_for_collisions (tmp_nosp);
@@ -2031,8 +2032,18 @@ verify_tree (tree x, struct tlist **pbef
  x = TREE_OPERAND (x, 0);
  goto restart;
}
-  gcc_fallthrough ();
+  goto do_default;
+
+case LSHIFT_EXPR:
+case RSHIFT_EXPR:
+case COMPONENT_REF:
+case ARRAY_REF:
+  if (cxx_dialect >= cxx17)
+   goto sequenced_binary;
+  goto do_default;
+
 default:
+do_default:
   /* For other expressions, simply recurse on their operands.
 Manual tail recursion for unary expressions.
 Other non-expressions need not be processed.  */
fixes most of this, except for the assignment operator case, plus the .*/->
case isn't addressed either.

[Bug c++/91415] Invalid warning for C++17 sequencing of shift operator E1<

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Testcase also with PMF:
struct S { int a[10]; void bar (); void baz (); };

typedef void (S::*pmf) ();

void
foo (int i, int x[10][10], int y[10], struct S z[10], struct S *w[10], pmf
u[10])
{
  int b = x[i++][i++];
  int c = i++ << i++;
  int d = i++ >> i++;
  int e = i++ && i++;
  int f = i++ ? i++ : i++;
  int g = (i++, i++);
  int h = z[i++].a[i++];
  int j = w[i++]->a[i++];
  (z[i++].*u[i++]) ();
  (w[i++]->*u[i++]) ();
  y[i++] = y[i++];
}

[Bug c++/91415] Invalid warning for C++17 sequencing of shift operator E1<

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-10
 Ever confirmed|0   |1

[Bug c++/91415] Invalid warning for C++17 sequencing of shift operator E1<

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
I think this is
P0145R3 Refining Expression Evaluation Order for Idiomatic C++
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r3.pdf
which says
4. A SOLUTION
In summary, the following expressions are evaluated in the order a, then b,
then c, then d:
1. a.b
2. a->b
3. a->*b
4. a(b1, b2, b3)
5. b @=a
6. a[b]
7. a << b
8. a >> b

[Bug fortran/91414] Improved PRNG

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P5
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-10
 CC||kargl at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from kargl at gcc dot gnu.org ---
I've set this to NEW, P5, enhancement request.  Janne
if you're working on replacing the prng.  Feel free to
ping with a patch.

[Bug fortran/91359] logical function X returns .TRUE. - Warning: spaghetti code

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #15 from kargl at gcc dot gnu.org ---
Take the PR. Waiting or 9-branch to open.

[Bug fortran/91413] [F2018]: Procedures are recursive by default; switching from stack to static allocation is not safe

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-10
 CC||tkoenig at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Thomas Koenig  ---
Confirmed.

[Bug c++/91416] New: ICE in cp_check_const_attributes, at cp/decl2.c:1408

[p.vanhoof at oma dot be]

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

Bug ID: 91416
   Summary: ICE in cp_check_const_attributes, at cp/decl2.c:1408
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: p.vanhoof at oma dot be
  Target Milestone: ---

Created attachment 46698
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46698&action=edit
code that triggers the ICE

The attached code ICEs with the following build of the trunk:

% g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/gcc1000/lib/gcc/x86_64-pc-linux-gnu/10.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-mainline/configure --prefix=/usr/local/gcc1000
--enable-languages=c,c++,fortran
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.0 20190804 (experimental) (GCC) 

This is r274099.

The command to trigger the ICE is:

% g++ -g -c bug.cc

The output is:

bug.cc:11:3: internal compiler error: tree check: expected tree_list, have
ggc_freed in cp_check_const_attributes, at cp/decl2.c:1408
   11 | } ql;
  |   ^~
0x7f5a7b tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc-mainline/gcc/tree.c:9905
0x61da78 tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc-mainline/gcc/tree.h:3257
0x61da78 cp_check_const_attributes(tree_node*)
../../gcc-mainline/gcc/cp/decl2.c:1408
0x959148 cp_check_const_attributes(tree_node*)
../../gcc-mainline/gcc/cp/decl2.c:1401
0x959148 cplus_decl_attributes(tree_node**, tree_node*, int)
../../gcc-mainline/gcc/cp/decl2.c:1565
0x9489f8 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../gcc-mainline/gcc/cp/decl.c:5167
0x9edfbf cp_parser_init_declarator
../../gcc-mainline/gcc/cp/parser.c:20374
0x9d06ce cp_parser_simple_declaration
../../gcc-mainline/gcc/cp/parser.c:13541
0x9f4e01 cp_parser_declaration
../../gcc-mainline/gcc/cp/parser.c:13238
0x9f5580 cp_parser_translation_unit
../../gcc-mainline/gcc/cp/parser.c:4709
0x9f5580 c_parse_file()
../../gcc-mainline/gcc/cp/parser.c:41688
0xaff99b c_common_parse_file()
../../gcc-mainline/gcc/c-family/c-opts.c:1160
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

The attached code compiles correctly with g++ 9.1.0.

Unfortunately this appears to be a heisenbug. I tried generating the
preprocessed file with -save-temps, but the ICE goes away when using that file
(or even when generating the file). So I can only hope you can reproduce it
with the attached file... Let me know if there is anything else I can do.

[Bug c++/91416] ICE in cp_check_const_attributes, at cp/decl2.c:1408

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-10
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug c++/91416] [10 Regression] ICE in cp_check_const_attributes, at cp/decl2.c:1408

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
Summary|ICE in  |[10 Regression] ICE in
   |cp_check_const_attributes,  |cp_check_const_attributes,
   |at cp/decl2.c:1408  |at cp/decl2.c:1408

--- Comment #2 from Marek Polacek  ---
Seems to be a 10 regression.

[Bug c++/91416] [10 Regression] ICE in cp_check_const_attributes, at cp/decl2.c:1408

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
(In reply to p.vanh...@oma.be from comment #0)
> Unfortunately this appears to be a heisenbug. I tried generating the
> preprocessed file with -save-temps, but the ICE goes away when using that
> file (or even when generating the file). So I can only hope you can
> reproduce it with the attached file... Let me know if there is anything else
> I can do.

--param ggc-min-expand=0 --param ggc-min-heapsize=0
can be useful when dealing with bugs like this, BTW.

[Bug c++/91416] [10 Regression] ICE in cp_check_const_attributes, at cp/decl2.c:1408

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
__attribute__ ((unused)) const struct S {
  S() { }
} s;

ICEs with --param ggc-min-expand=0 --param ggc-min-heapsize=0

[Bug c++/91416] [10 Regression] ICE in cp_check_const_attributes, at cp/decl2.c:1408

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug c++/91416] ICE in cp_check_const_attributes, at cp/decl2.c:1408

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|10.0|---
Summary|[10 Regression] ICE in  |ICE in
   |cp_check_const_attributes,  |cp_check_const_attributes,
   |at cp/decl2.c:1408  |at cp/decl2.c:1408

--- Comment #5 from Marek Polacek  ---
I was wrong about the regression, even r110003 crashes.  So the problem is
ancient.

[Bug fortran/91413] [F2018]: Procedures are recursive by default; switching from stack to static allocation is not safe

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2019-08/msg00679.ht
   ||ml
   Assignee|unassigned at gcc dot gnu.org  |jb at gcc dot gnu.org

--- Comment #2 from Janne Blomqvist  ---
Patch at https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00679.html

[Bug fortran/91414] Improved PRNG

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

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

--- Comment #2 from Janne Blomqvist  ---
I have a cunning plan..

[Bug middle-end/90597] [9/10 Regression] FAIL: gcc.dg/attr-vector_size.c (internal compiler error)

[danglin at gcc dot gnu.org]

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

--- Comment #6 from John David Anglin  ---
I suppose an assert could be generated to avoid running the test on hppa64,
but this is a compiler ICE and the error shouldn't occur.

[Bug c++/91416] ICE in cp_check_const_attributes, at cp/decl2.c:1408

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
This is where we free the memory occupied by the parsed attribute:

(gdb) bt
#0  __memset_avx2_unaligned_erms () at
../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:180
#1  0x00c8e052 in poison_pages () at
/home/mpolacek/src/gcc/gcc/ggc-page.c:2112
#2  0x00c8e1d6 in ggc_collect () at
/home/mpolacek/src/gcc/gcc/ggc-page.c:2207
#3  0x00d66a3d in cgraph_node::finalize_function (
decl=, no_collect=false)
at /home/mpolacek/src/gcc/gcc/cgraphunit.c:492
#4  0x00b47b60 in expand_or_defer_fn (fn=)
at /home/mpolacek/src/gcc/gcc/cp/semantics.c:4380
#5  0x00a260d5 in maybe_clone_body (fn=)
at /home/mpolacek/src/gcc/gcc/cp/optimize.c:710
#6  0x00b47a21 in expand_or_defer_fn_1 (fn=)
at /home/mpolacek/src/gcc/gcc/cp/semantics.c:4348
#7  0x00b47b30 in expand_or_defer_fn (fn=)
at /home/mpolacek/src/gcc/gcc/cp/semantics.c:4375
#8  0x00a5e3cd in cp_parser_function_definition_after_declarator
(parser=0x7fffea9527b8, 
inline_p=true) at /home/mpolacek/src/gcc/gcc/cp/parser.c:28080
#9  0x00a60c71 in cp_parser_late_parsing_for_member
(parser=0x7fffea9527b8, 
member_function=) at
/home/mpolacek/src/gcc/gcc/cp/parser.c:28960
#10 0x00a563a2 in cp_parser_class_specifier_1 (parser=0x7fffea9527b8)
at /home/mpolacek/src/gcc/gcc/cp/parser.c:23790
#11 0x00a56473 in cp_parser_class_specifier (parser=0x7fffea9527b8)
at /home/mpolacek/src/gcc/gcc/cp/parser.c:23816
#12 0x00a48f90 in cp_parser_type_specifier (parser=0x7fffea9527b8,
flags=1, 
decl_specs=0x7fffd030, is_declaration=true,
declares_class_or_enum=0x7fffcfa4, 
is_cv_qualifier=0x7fffcfa3) at
/home/mpolacek/src/gcc/gcc/cp/parser.c:17453
#13 0x00a43890 in cp_parser_decl_specifier_seq (parser=0x7fffea9527b8,
flags=1, 
decl_specs=0x7fffd030, declares_class_or_enum=0x7fffd02c)
at /home/mpolacek/src/gcc/gcc/cp/parser.c:14152
#14 0x00a420c0 in cp_parser_simple_declaration (parser=0x7fffea9527b8, 
function_definition_allowed_p=true, maybe_range_for_decl=0x0)
at /home/mpolacek/src/gcc/gcc/cp/parser.c:13447
#15 0x00a42048 in cp_parser_block_declaration (parser=0x7fffea9527b8,
statement_p=false)
at /home/mpolacek/src/gcc/gcc/cp/parser.c:13394
#16 0x00a41d2b in cp_parser_declaration (parser=0x7fffea9527b8)
at /home/mpolacek/src/gcc/gcc/cp/parser.c:13266
#17 0x00a41e26 in cp_parser_toplevel_declaration
(parser=0x7fffea9527b8)
at /home/mpolacek/src/gcc/gcc/cp/parser.c:13295
#18 0x00a2f1d5 in cp_parser_translation_unit (parser=0x7fffea9527b8)
at /home/mpolacek/src/gcc/gcc/cp/parser.c:4711
#19 0x00a8863c in c_parse_file () at
/home/mpolacek/src/gcc/gcc/cp/parser.c:41855
#20 0x00c467fa in c_common_parse_file () at
/home/mpolacek/src/gcc/gcc/c-family/c-opts.c:1164
#21 0x0140b37c in compile_file () at
/home/mpolacek/src/gcc/gcc/toplev.c:456
#22 0x0140e0a5 in do_compile () at
/home/mpolacek/src/gcc/gcc/toplev.c:2190
#23 0x0140e398 in toplev::main (this=0x7fffd3be, argc=7,
argv=0x7fffd4b8)
at /home/mpolacek/src/gcc/gcc/toplev.c:2325
#24 0x0232855a in main (argc=7, argv=0x7fffd4b8) at
/home/mpolacek/src/gcc/gcc/main.c:39

[Bug target/87438] ICE building gfortran for MicroBlaze target

[me at zv dot io]

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

--- Comment #1 from Zach van Rijn  ---
Created attachment 46699
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46699&action=edit
Test case. Triggers bug on 8.x to at least 10-20190721.

[Bug target/87438] ICE building gfortran for MicroBlaze target

[me at zv dot io]

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

--- Comment #2 from Zach van Rijn  ---
Using GCC 8-20180706 snapshot,

gcc -c -O2 -fPIC grapes.c 
during RTL pass: reload
grapes.c: In function 'smaxval_r8':
grapes.c:57:1: internal compiler error: in gen_reg_rtx, at emit-rtl.c:1155
 }
 ^
0x408422 gen_reg_rtx(machine_mode)
../../src_gcc/gcc/emit-rtl.c:1155
0x5e6ba6 force_reg(machine_mode, rtx_def*)
../../src_gcc/gcc/explow.c:665
0xc25604 gen_movdf(rtx_def*, rtx_def*)
../../src_gcc/gcc/config/microblaze/microblaze.md:1224
0x5fe6c5 insn_gen_fn::operator()(rtx_def*, rtx_def*) const
../../src_gcc/gcc/recog.h:301
0x5fe6c5 emit_move_insn_1(rtx_def*, rtx_def*)
../../src_gcc/gcc/expr.c:3666
0x603b45 gen_move_insn(rtx_def*, rtx_def*)
../../src_gcc/gcc/expr.c:3782
0x80e858 gen_reload
../../src_gcc/gcc/reload1.c:8740
0x8171a7 emit_input_reload_insns
../../src_gcc/gcc/reload1.c:7632
0x8171a7 do_input_reload
../../src_gcc/gcc/reload1.c:7919
0x8171a7 emit_reload_insns
../../src_gcc/gcc/reload1.c:8107
0x8171a7 reload_as_needed
../../src_gcc/gcc/reload1.c:4647
0x81ab76 reload(rtx_insn*, int)
../../src_gcc/gcc/reload1.c:1050
0x7044ea do_reload
../../src_gcc/gcc/ira.c:5477
0x7044ea execute
../../src_gcc/gcc/ira.c:5649

[Bug ada/91417] New: [10 regression] acats c761003 fails for powerpc targets

[iains at gcc dot gnu.org]

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

Bug ID: 91417
   Summary: [10 regression] acats c761003 fails for powerpc
targets
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iains at gcc dot gnu.org
  Target Milestone: ---

between r273839 and 273914 c761003 has begun to fail on powerpc (32 and 64b),
at least powerpc-darwin9 and powerpc64-linux-gnu are affected.

on powerpc64-linux-gnu:

splitting /home/iains/gcc-trunk/bld/gcc/testsuite/ada/acats2/tests/c7/c761003.a
into:
   c761003_support.ads
   c761003_support.adb
   c761003_0.ads
   c761003_1.ads
   c761003_2.ads
   c761003_0.adb
   c761003_1.adb
   c761003.adb
BUILD c761003.adb
/home/iains/gcc-trunk/bld/gcc/gnatmake
--GNATBIND=/home/iains/gcc-trunk/bld/gcc/gnatbind
--GNATLINK=/home/iains/gcc-trunk/bld/gcc/gnatlink
--GCC=/home/iains/gcc-trunk/bld/gcc/xgcc -B/home/iains/gcc-trunk/bld/gcc/ -
gnatws -O2 -gnat95
-I/home/iains/gcc-trunk/bld/gcc/testsuite/ada/acats2/../acats/support
c761003.adb -largs --GCC=/home/iains/gcc-trunk/bld/gcc/xgcc
-B/home/iains/gcc-trunk/bld/gcc/
/home/iains/gcc-trunk/bld/gcc/xgcc -c -B/home/iains/gcc-trunk/bld/gcc/ -gnatws
-O2 -gnat95
-I/home/iains/gcc-trunk/bld/gcc/testsuite/ada/acats2/../acats/support
c761003.adb

raised STORAGE_ERROR : stack overflow or erroneous memory access
gnatmake: "c761003.adb" compilation error
FAIL:   c761003

on powerpc-darwin9:

/Volumes/scratch/10-5-leo/powerpc-trunk/gcc/xgcc -c
-B/Volumes/scratch/10-5-leo/powerpc-trunk/gcc/ -gnatws -O2 -gnat95
-I/Volumes/scratch/10-5-leo/powerpc-trunk/gcc/testsuite/ada/acats1/../acats/support
c761003.adb
+===GNAT BUG DETECTED==+
| 10.0.0 20190810 (experimental) [trunk revision 274249]
(powerpc-apple-darwin9) GCC error:|
| in ggc_set_mark, at ggc-page.c:1532  |
| Error detected around c761003.adb:199:5  |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

[Bug c++/91418] New: Nested class of templated class cannot declare parent class friend

[Darrell.Wright at gmail dot com]

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

Bug ID: 91418
   Summary: Nested class of templated class cannot declare parent
class friend
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Darrell.Wright at gmail dot com
  Target Milestone: ---

As seen here https://gcc.godbolt.org/z/FvHncw. One cannot express
friend class Parent;
when parent is templated from a nested class within a member function
As a workaround, it will work with 
friend class Parent;

[Bug ada/91417] [10 regression] acats c761003 fails for powerpc targets

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Target||powerpc*-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-11
 Ever confirmed|0   |1

[Bug c++/91418] Nested class of templated class cannot declare parent class friend

[Darrell.Wright at gmail dot com]

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

--- Comment #1 from Darrell Wright  ---
The template isn't part of it, 
https://gcc.godbolt.org/z/KCok90

[Bug tree-optimization/91419] New: [10 Regression]: gcc.dg/tree-ssa/pr91091-2.c, ssa-fre-61.c, ssa-fre-61.c with r273232

[hp at gcc dot gnu.org]

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

Bug ID: 91419
   Summary: [10 Regression]: gcc.dg/tree-ssa/pr91091-2.c,
ssa-fre-61.c, ssa-fre-61.c with r273232
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hp at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---
Target: cris-elf, pru-elf, m68k-unknown-linux-gnu

Commit r273232 (of 2019-07-08) introduced these regressions for (at least)
cris-elf, pru-elf and m68k-unknown-linux-gnu:

FAIL: gcc.dg/tree-ssa/pr91091-2.c scan-tree-dump-times fre1 "x = " 1
FAIL: gcc.dg/tree-ssa/ssa-fre-61.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/ssa-fre-61.c scan-tree-dump-times fre1 "Replaced \\*p" 3
FAIL: gcc.dg/tree-ssa/ssa-fre-77.c scan-tree-dump fre1 "return 1;"

For cris-elf, the "excess errors" are (from gcc.log):
Excess errors:
ssa-fre-61.c:(.text+0x16): undefined reference to `link_error'
ssa-fre-61.c:(.text+0x30): undefined reference to `link_error'
ssa-fre-61.c:(.text+0x4a): undefined reference to `link_error'

The revision is confirmed for cris-elf by own testing.  For
pru-elf and m68k-unknown-linux-gnu entries before and after
r273232 on gcc-testresults@ were compared, for example:

Before:

(Results for
10.0.020190708(experimental)[trunkrevision273226](GCC) testsuite
on pru-unknown-elf)

(Results for 10.0.0 20190707 (experimental) [trunk revision
273184] (GCC) testsuite on m68k-unknown-linux-gnu)

After:

(Results for
10.0.020190710(experimental)[trunkrevision273328](GCC) testsuite
on pru-unknown-elf)

(Results for 10.0.0 20190708 (experimental) [trunk revision
273247] (GCC) testsuite on m68k-unknown-linux-gnu)

Also, more recent gcc-testresults entries confirms that the regressions
remain.

I'm guessing that some target-ABI-structure-related knob has been overlooked,
common to these targets but different to more mainstream targets.  One that
seems to match that criteria is PCC_BITFIELD_TYPE_MATTERS.

FWIW, the new test ssa-fre-78.c passes.

[Bug c++/91416] ICE in cp_check_const_attributes, at cp/decl2.c:1408

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
This sort of problem, accidentally collecting live data, is typically fixed by
adding
++function_depth;
// whatever
--function_depth;

Here we're in cp_parser_late_parsing_for_member, which calls
start_preparsed_function (++function_depth) and then actually parses the body
using cp_parser_function_definition_after_declarator.

cp_parser_function_definition_after_declarator does

28077   /* Finish the function.  */
28078   fn = finish_function (inline_p);
28079   /* Generate code for it, if necessary.  */
28080   expand_or_defer_fn (fn);

and finish_function does --function_depth.  Then the call to expand_or_defer_fn
triggers calling ggc_collect.

This is similar to PR c++/88180.

[Bug c++/91416] ICE in cp_check_const_attributes, at cp/decl2.c:1408

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek  ---
This patch seems to fix the problem.  It follows cp_parser_lambda_body in its
handling of function_depth.

--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -28934,6 +28934,8 @@ cp_parser_late_parsing_for_member (cp_parser* parser,
tree member_function)
   function_scope = current_function_decl;
   if (function_scope)
push_function_context ();
+  else
+   ++function_depth;

   /* Push the body of the function onto the lexer stack.  */
   cp_parser_push_lexer_for_tokens (parser, tokens);
@@ -28966,6 +28968,9 @@ cp_parser_late_parsing_for_member (cp_parser* parser,
tree member_function)
   /* Leave the scope of the containing function.  */
   if (function_scope)
pop_function_context ();
+  else
+   --function_depth;
+
   cp_parser_pop_lexer (parser);
 }


More tomorrow...

[Bug preprocessor/41492] Please ignore #! on the first line of a file

[felix.von.s at posteo dot de]

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

felix  changed:

   What|Removed |Added

 CC||felix.von.s at posteo dot de

--- Comment #2 from felix  ---
Please reconsider. For one thing, this extension does not in any way interfere
with normal preprocessor syntax. For another, stripping the shebang line in an
external preprocessor introduces overhead and complications: one has to create
a temporary source file, probably insert a #line directive in the shebang
line's place, and arrange for the temporary file to be deleted when compilation
finishes. Being able to have the compiler read the file directly would make
this so much simpler.

Also, I sometimes develop small C programs by alternating between rapid
write-compile-run cycle with Tiny C Compiler and running the program though a
normal compiler to look for warnings and produce an optimised binary. Right
now, if I do this, I have to comment out or remove the shebang line when
compiling, and add it back when I want to invoke the source file directly from
the command line through TCC. This hardly stops me dead in my tracks, but is
sure irritating.

Plus, the compiler can easily keep generating a warning for erroneous shebang
lines (or for all shebang lines when -Wpedantic is in force), so the likelihood
of this feature leading to accepting erroneous code is minimal.

[Bug d/90601] ICE: gimplification failed (gimplify.c at 13436)

[ibuclaw at gcc dot gnu.org]

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

--- Comment #3 from ibuclaw at gcc dot gnu.org ---
Author: ibuclaw
Date: Sun Aug 11 06:53:14 2019
New Revision: 274263

URL: https://gcc.gnu.org/viewcvs?rev=274263&root=gcc&view=rev
Log:
d: Fix ICE: gimplification failed (gimplify.c at 13436)

The expression that caused the ICE

++(a += 1.0);

The D front-end rewrites and applies implicit type conversions so the
expression gets simplified as

(int)((double) a += 1.0) += 1

The codegen pass would subsequently generate the following invalid code

(int)(double) a = (int)((double) a + 1.0) + 1

The LHS expression `(int)(double) a', represented as a FIX_TRUNC_EXPR
being what trips as it is not a valid lvalue for assignment.

While LHS casts are stripped away, convert_expr adds a double cast
because it converts the expression to its original type before
converting it to its target type.  There is no valid reason why this is
done, so it has been removed.

gcc/d/ChangeLog:

PR d/90601
* d-convert.cc (convert_expr): Don't convert an expression to its
original front-end type before converting to its target type.

gcc/testsuite/ChangeLog:

PR d/90601
* gdc.dg/pr90601.d: New test.

Added:
trunk/gcc/testsuite/gdc.dg/pr90601.d
Modified:
trunk/gcc/d/ChangeLog
trunk/gcc/d/d-convert.cc
trunk/gcc/testsuite/ChangeLog

[Bug d/90601] ICE: gimplification failed (gimplify.c at 13436)

[ibuclaw at gdcproject dot org]

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #4 from Iain Buclaw  ---
Fixed in r274263.