[Bug ada/81956] [7/8/9 regression] calling a null procedure is not skipped

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou  ---
Author: ebotcazou
Date: Tue Feb 26 08:12:21 2019
New Revision: 269205

URL: https://gcc.gnu.org/viewcvs?rev=269205&root=gcc&view=rev
Log:
PR ada/81956
Backport from mainline
2017-09-06  Ed Schonberg  

* exp_ch6.adb (Expand_Call_Helper): Do not optimize calls to
null procedures when GNAT coverage is used, so that their (empty)
bodies are properly covered.

2017-09-06  Ed Schonberg  

* exp_ch6.adb (Expand_Call_Helper): Replace call to null
procedure by a single null statement, after evaluating the
actuals that require it.

Modified:
branches/gcc-7-branch/gcc/ada/ChangeLog
branches/gcc-7-branch/gcc/ada/exp_ch6.adb

[Bug ada/81956] [7 regression] call to null procedure not optimized away

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |ebotcazou at gcc dot 
gnu.org
Summary|[7/8/9 regression] calling  |[7 regression] call to null
   |a null procedure is not |procedure not optimized
   |skipped |away

--- Comment #5 from Eric Botcazou  ---
Fixed in 7.5 and later releases.

[Bug fortran/89496] [9 Regression] gcc/fortran/trans-types.c:3015:9: runtime error: member access within null pointer of type 'struct gfc_formal_arglist'

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
(In reply to Thomas Koenig from comment #2)
> This looks pretty obvious to me, at least looking at the
> -fdump-fortran-original dump.  I will try to come up with
> a test case.
> 
> Would it be possible to check that this also fixes the
> nullpointer offset access?
> 
> Index: trans-types.c
> ===
> --- trans-types.c   (Revision 269161)
> +++ trans-types.c   (Arbeitskopie)
> @@ -2988,9 +2988,9 @@
>f = &sym->formal;
>for (a = actual_args; a != NULL; a = a->next)
>  {
> +  (*f) = gfc_get_formal_arglist ();
>if (a->expr)
> {
> - (*f) = gfc_get_formal_arglist ();
>   snprintf (name, GFC_MAX_SYMBOL_LEN, "_formal_%d", var_num ++);
>   gfc_get_symbol (name, NULL, &s);
>   if (a->expr->ts.type == BT_PROCEDURE)
> @@ -3012,6 +3012,9 @@
>   s->attr.intent = INTENT_UNKNOWN;
>   (*f)->sym = s;
> }
> +  else
> +   (*f)->sym = NULL;
> +
>f = &((*f)->next);
>  }
>  }

I can confirm this works fine for the test-case as well as for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89496#c3
Thanks for the fix.

[Bug c/89448] Failure to generate diagnostic for "complex int" (OK for "_Complex int")

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Yes.

[Bug target/89455] [9 Regression] FAIL: g++.target/i386/mv16.C on Westmere

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug c++/89458] adding aligned attribute to struct causes too much to be copied

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-26
 CC||jason at gcc dot gnu.org
  Component|other   |c++
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
The issue is that sizeof(Obj) is 256.  But yes, the padding at the end of the
object need not be copied.  Thus this is a missed optimization (I'm not sure we
actually store the "original" size anywhere though).  Maybe the FE could
use the classtype-as-base type here?

[Bug libquadmath/89459] Incorrect rounding for fma in some cases

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-02-26
 Ever confirmed|0   |1

[Bug lto/89497] [8 Regression] ICE caused by Segmentation Fault when compiling cups 2.2.10 with LTO flags enabled

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-02-26
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
Summary|[8.2 regression] ICE caused |[8 Regression] ICE caused
   |by Segmentation Fault when  |by Segmentation Fault when
   |compiling cups 2.2.10 with  |compiling cups 2.2.10 with
   |LTO flags enabled   |LTO flags enabled
 Ever confirmed|0   |1
  Known to fail||8.3.0

--- Comment #2 from Martin Liška  ---
Confirmed, investigating right now.

[Bug debug/89463] debug information for iteractor of an empty loop is gone (at -O3)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-debug
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-26
Version|unknown |9.0
 Ever confirmed|0   |1
   Severity|enhancement |normal

--- Comment #3 from Richard Biener  ---
stmt removal should generate a # DEBUG i = NULL note but eventually removal
inside a CFG cycle is awkward enough that this doesn't work reliably.  In
fact we seem to get an extra = 0 note, likely from the attempt to generate
a i => i_5 one.

--- t.i.036t.dse1   2019-02-26 09:46:03.325257454 +0100
+++ t.i.037t.cddce1 2019-02-26 09:46:03.329257503 +0100
...
@@ -24,22 +52,10 @@
   if (a.1_3 <= 9)
 goto ; [INV]
   else
-goto ; [INV]
-
-   :
-  # DEBUG BEGIN_STMT
-  i_11 = i_5 + 1;
-  # DEBUG i => i_11
-
-   :
-  # i_5 = PHI 
-  # DEBUG i => i_5
-  if (i_5 != 6)
 goto ; [INV]
-  else
-goto ; [INV]

-   :
+   :
+  # DEBUG i => 0
   # DEBUG BEGIN_STMT
   optimize_me_not ();
   return 0;

[Bug middle-end/89503] New: Checking ICE in 'gcc.dg/warn-strlen-no-nul.c'

[tschwinge at gcc dot gnu.org]

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

Bug ID: 89503
   Summary: Checking ICE in 'gcc.dg/warn-strlen-no-nul.c'
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-checking, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

Comparing a '--enable-checking=yes' build with a
'--enable-checking=yes,extra,df,fold,rtl' build of r269110 (but this started
earlier, but can't tell exactly when), I see:

[-PASS:-]{+FAIL:+} gcc.dg/warn-strlen-no-nul.c  (test for warnings, line
100)
[-PASS:-]{+FAIL:+} gcc.dg/warn-strlen-no-nul.c  (test for warnings, line
101)
[-PASS:-]{+FAIL:+} gcc.dg/warn-strlen-no-nul.c  (test for warnings, line
103)
[...]
[-PASS:-]{+FAIL:+} gcc.dg/warn-strlen-no-nul.c  (test for warnings, line
230)
[-PASS:-]{+FAIL:+} gcc.dg/warn-strlen-no-nul.c  (test for warnings, line
231)
[-PASS:-]{+FAIL:+} gcc.dg/warn-strlen-no-nul.c  (test for warnings, line
232)
PASS: gcc.dg/warn-strlen-no-nul.c  (test for warnings, line 26)
[-PASS:-]{+FAIL:+} gcc.dg/warn-strlen-no-nul.c  (test for warnings, line
27)
[-PASS:-]{+FAIL:+} gcc.dg/warn-strlen-no-nul.c  (test for warnings, line
276)
[-PASS:-]{+FAIL:+} gcc.dg/warn-strlen-no-nul.c  (test for warnings, line
277)
[...]
[-PASS:-]{+FAIL:+} gcc.dg/warn-strlen-no-nul.c  (test for warnings, line
74)
[-PASS:-]{+FAIL:+} gcc.dg/warn-strlen-no-nul.c  (test for warnings, line
75)
[-PASS:-]{+FAIL:+} gcc.dg/warn-strlen-no-nul.c  (test for warnings, line
76)
PASS: gcc.dg/warn-strlen-no-nul.c  (test for warnings, line 8)
[-PASS:-]{+FAIL:+} gcc.dg/warn-strlen-no-nul.c  (test for warnings, line
81)
[-PASS:-]{+FAIL:+} gcc.dg/warn-strlen-no-nul.c  (test for warnings, line
85)
[-PASS:-]{+FAIL:+} gcc.dg/warn-strlen-no-nul.c  (test for warnings, line
92)
[-PASS:-]{+FAIL:+} gcc.dg/warn-strlen-no-nul.c  (test for warnings, line
96)
[-PASS:-]{+FAIL:+} gcc.dg/warn-strlen-no-nul.c  (test for warnings, line
98)
[-PASS:-]{+FAIL:+} gcc.dg/warn-strlen-no-nul.c  (test for warnings, line
99)
[-PASS:-]{+FAIL: gcc.dg/warn-strlen-no-nul.c (internal compiler error)+}
{+FAIL:+} gcc.dg/warn-strlen-no-nul.c (test for excess errors)

[...]/gcc/testsuite/gcc.dg/warn-strlen-no-nul.c: In function 'test_26':
[...]/gcc/testsuite/gcc.dg/warn-strlen-no-nul.c:26:1: warning: 'strlen'
argument missing terminating nul [-Wstringop-overflow=]
[...]/gcc/testsuite/gcc.dg/warn-strlen-no-nul.c:8:12: note: referenced
argument declared here
[...]/gcc/testsuite/gcc.dg/warn-strlen-no-nul.c:26:1: internal compiler
error: fold check: original tree changed by fold
0xc5ce8f fold_check_failed
[...]/gcc/fold-const.c:12106
0xc90d44 fold(tree_node*)
[...]/gcc/fold-const.c:12083
0xa4935e c_fully_fold_internal
[...]/gcc/c/c-fold.c:626
0xa4bb07 c_fully_fold(tree_node*, bool, bool*, bool)
[...]/gcc/c/c-fold.c:125
0xa123c7 convert_arguments
[...]/gcc/c/c-typeck.c:3542
0xa123c7 build_function_call_vec(unsigned int, vec, tree_node*, vec*, vec*)
[...]/gcc/c/c-typeck.c:3084
0xa2ef11 c_parser_postfix_expression_after_primary
[...]/gcc/c/c-parser.c:9591
0xa207a1 c_parser_postfix_expression
[...]/gcc/c/c-parser.c:9270
0xa2a35f c_parser_unary_expression
[...]/gcc/c/c-parser.c:7380
0xa2b9cf c_parser_cast_expression
[...]/gcc/c/c-parser.c:7222
0xa2bc48 c_parser_binary_expression
[...]/gcc/c/c-parser.c:7025
0xa2cc15 c_parser_conditional_expression
[...]/gcc/c/c-parser.c:6759
0xa2d240 c_parser_expr_no_commas
[...]/gcc/c/c-parser.c:6676
0xa2d4a1 c_parser_expression
[...]/gcc/c/c-parser.c:9727
0xa2dbc7 c_parser_expression_conv
[...]/gcc/c/c-parser.c:9760
0xa3d17b c_parser_statement_after_labels
[...]/gcc/c/c-parser.c:5610
0xa3f27a c_parser_compound_statement_nostart
[...]/gcc/c/c-parser.c:5148
0xa3f808 c_parser_compound_statement
[...]/gcc/c/c-parser.c:4982
0xa40f12 c_parser_declaration_or_fndef
[...]/gcc/c/c-parser.c:2354
0xa47f6f c_parser_external_declaration
[...]/gcc/c/c-parser.c:1653

[Bug debug/89472] FAIL: gcc.dg/debug/dwarf2/inline5.c scan-assembler-times DW_TAG_lexical_block\\)[^#/!@;\\|]*[#/!@;\\|]+ +[^#/!@\\|]*\\(DIE \\(0x[0-9a-f]*\\) DW_TAG_variable 1

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Bah, another one.  A patch to XFAIL hppa is pre-approved.

[Bug target/89504] New: Checking ICE in 'gcc.dg/rtl/x86_64/pro_and_epilogue.c'

[tschwinge at gcc dot gnu.org]

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

Bug ID: 89504
   Summary: Checking ICE in 'gcc.dg/rtl/x86_64/pro_and_epilogue.c'
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-checking
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

Comparing a '--enable-checking=yes' build with a
'--enable-checking=yes,extra,df,fold,rtl' build of r269110 (but this started
much, much earlier, but can't tell exactly when), I see:

[-PASS:-]{+FAIL: gcc.dg/rtl/x86_64/pro_and_epilogue.c (internal compiler
error)+}
{+FAIL:+} gcc.dg/rtl/x86_64/pro_and_epilogue.c (test for excess errors)
[-PASS:-]{+FAIL:+} gcc.dg/rtl/x86_64/pro_and_epilogue.c scan-rtl-dump-times
pro_and_epilogue "NOTE_INSN_PROLOGUE_END" 1
[-PASS:-]{+FAIL:+} gcc.dg/rtl/x86_64/pro_and_epilogue.c scan-rtl-dump-times
pro_and_epilogue "simple_return" 2

during RTL pass: pro_and_epilogue
dump file: pro_and_epilogue.c.288r.pro_and_epilogue
[...]/gcc/testsuite/gcc.dg/rtl/x86_64/pro_and_epilogue.c: In function
'test_1':
[...]/gcc/testsuite/gcc.dg/rtl/x86_64/pro_and_epilogue.c:103:1: internal
compiler error: in df_scan_verify, at df-scan.c:4233
0x5ffb7f df_scan_verify()
[...]/gcc/df-scan.c:4233
0xb729f8 df_verify()
[...]/gcc/df-core.c:1817
0xb72a87 df_analyze_1
[...]/gcc/df-core.c:1213
0xca4fb2 thread_prologue_and_epilogue_insns()
[...]/gcc/function.c:5840
0xca5872 rest_of_handle_thread_prologue_and_epilogue
[...]/gcc/function.c:6342
0xca5872 execute
[...]/gcc/function.c:6384

[Bug rtl-optimization/89490] [9 Regression] char array constant put in string merge section

[bernd.edlinger at hotmail dot de]

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

--- Comment #9 from Bernd Edlinger  ---
> And, what do you find wrong on the alignment?

In the case of the artificially zero terminated strings,
the .zero is now wrong, and they can actually screw up the
necessary alignment.


Maybe the easiest way out would be simply not try to put
non-zero terminated strings in merge sections, when the
-fsection-anchors is in effect?

--- varasm.c.orig   2019-01-25 17:57:32.0 +0100
+++ varasm.c2019-02-26 09:48:48.061315685 +0100
@@ -838,7 +838,8 @@
  if (j == unit)
break;
}
- if (i == len - unit || (unit == 1 && i == len))
+ if (i == len - unit || (unit == 1 && i == len &&
+ !flag_section_anchors))
{
  sprintf (name, "%s.str%d.%d", prefix,
   modesize / 8, (int) (align / 8));

[Bug tree-optimization/89479] __restrict

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-26
 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Richard Biener  ---
I believe there's a dup somewhere.  Basically function calls are not
annotated with {base,clique} (our implementation detail exposing __restrict
to the IL).  To elaborate further to successfully mark a function call
with clique == 1 and base == 0 we have to prove the pointer marked restrict
doesn't escape the function through calls since I belive that for

int *p;
void g() { *p = 1; }
void f(int *q) { p = q; }

int foo(const int* x, void g())
  {
  f(x);
  int result = *x;
  g();
  result += *x;
  return result;
  }

the access in g is still based on x since the above is equivalent to

  int foo(const int* x, void g())
  {
  int *p = x;
  int result = *x;
  *p = 1;
  result += *x;
  return result;
  }

letting aside eventual issues with the const qualification of *x.

[Bug c++/89480] internal compiler error: in unify, at cp/pt.c:22160 with the template argument force conversion

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Known to fail||4.8.5, 9.0

--- Comment #1 from Richard Biener  ---
Confirmed.  Not sure if the code is valid.

[Bug c++/89486] GCC fails to compile designated initializer use involving implicit conversion

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
.

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

[Bug c++/71446] Incorrect overload resolution when using designated initializers

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||st at quanttec dot com

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

[Bug rtl-optimization/89487] [8/9 Regression] ICE in expand_expr_addr_expr_1, at expr.c:7993

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Looks like may_be_nonaddressable_p misses a VAR_DECL case checking for hard
registers and the code in loop-distribution should use that helper to fend
off generating invalid addresses.

[Bug rtl-optimization/89487] [8/9 Regression] ICE in expand_expr_addr_expr_1, at expr.c:7993

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P3  |P2

[Bug tree-optimization/89489] [9 Regression] ICE in gimple_duplicate_bb, at tree-cfg.c:6257

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Dup of PR89451 I guess.

[Bug tree-optimization/89489] [9 Regression] ICE in gimple_duplicate_bb, at tree-cfg.c:6257

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Testing patch.

[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||build
 Target||powerpc64-freebsd
   Host||powerpc64-freebsd

--- Comment #5 from Richard Biener  ---
So it looks like stage1 gcc is miscompiled somehow.  I wonder if you can avoid
setting CFLAGS et al?

[Bug lto/89497] [8 Regression] ICE caused by Segmentation Fault when compiling cups 2.2.10 with LTO flags enabled

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.4

--- Comment #3 from Richard Biener  ---
Does trunk work?  Also I wonder whether the graphite flags are necessary to
trigger the issue (and as recommendation, don't use -fgraphite-identity,
it is for debugging, also avoid -floop-nest-optimize and -fipa-pta).

[Bug debug/89498] [8/9 Regression] ICE in AT_loc_list, at dwarf2out.c:4871

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Can't reproduce on trunk.  If #include  is necessary can you attach
preprocessed source please?

[Bug tree-optimization/89499] [7/8/9 Regression] ICE in expand_UNIQUE, at internal-fn.c:2605

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.5

[Bug middle-end/89501] Odd lack of warning about missing initialization

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
(In reply to Jeffrey A. Law from comment #3)
> Yup.  It's the same as 18501.  We meet UNDEFINED and [0,0] resulting in
> [0,0] and nothing ever causes reevaluation of the PHI.  Things are working
> as "expected".

And this meeting helps us avoid bogus warnings for cases where GCC has
difficulties proving dead code paths are actually dead ...  In fact
to preserve uninit warnings we avoid doing the same things for copies,
thus when meeting [i, i] with UNDEFINED which in fact causes some
false positives to appear...  (and with my
GCC-is-an-optimizing-compiler-not-a-static-analysis-tool hat on I'd wanted to
change that more than once,
but testsuite regressions prevented me from doing that)

Uninit warnings are hard ;)

[Bug lto/89497] [8 Regression] ICE caused by Segmentation Fault when compiling cups 2.2.10 with LTO flags enabled

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
(In reply to Richard Biener from comment #3)
> Does trunk work? 

Thunk is fine.

> Also I wonder whether the graphite flags are necessary to
> trigger the issue (and as recommendation, don't use -fgraphite-identity,

No.

> it is for debugging, also avoid -floop-nest-optimize and -fipa-pta).

Give me some time, I'm reducing that right now (both options and source files).

[Bug lto/89497] [8 Regression] ICE caused by Segmentation Fault when compiling cups 2.2.10 with LTO flags enabled

[marxin at gcc dot gnu.org]

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

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

Started to fail with r268745 which is definitely a culprit:

$ gcc 11.i 22.i 33.i 44.i -fPIC -O3 -fno-semantic-interposition -flto=8 -shared
during GIMPLE pass: vrp
ppd-localize.c: In function ‘ppdLocalize’:
ppd-localize.c:51:1: internal compiler error: Segmentation fault
 ppdLocalize(ppd_file_t *ppd)  /* I - PPD file */
 ^
0xdfd704 crash_signal
../../gcc/toplev.c:325
0x779b1e0f ???
   
/usr/src/debug/glibc-2.29-1.3.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0xf2ac71 ptr_derefs_may_alias_p(tree_node*, tree_node*)
../../gcc/tree-ssa-alias.c:284
0xf2d2de indirect_refs_may_alias_p
../../gcc/tree-ssa-alias.c:1303
0xf2dbfa refs_may_alias_p_1(ao_ref*, ao_ref*, bool)
../../gcc/tree-ssa-alias.c:1498
0xaa0876 gimple_fold_builtin_memory_op
../../gcc/gimple-fold.c:918
0xaa79ca gimple_fold_builtin
../../gcc/gimple-fold.c:3657
0xaa95c9 gimple_fold_call
../../gcc/gimple-fold.c:4159
0xaaba38 fold_stmt_1
../../gcc/gimple-fold.c:4834
0xaac069 fold_stmt(gimple_stmt_iterator*)
../../gcc/gimple-fold.c:4981
0xe44b2a replace_uses_by(tree_node*, tree_node*)
../../gcc/tree-cfg.c:2025
0xe44fac gimple_merge_blocks
../../gcc/tree-cfg.c:2111
0x8c1c5a merge_blocks(basic_block_def*, basic_block_def*)
../../gcc/cfghooks.c:793
0xe5 cleanup_tree_cfg_bb
../../gcc/tree-cfgcleanup.c:715
0xe5cfae cleanup_tree_cfg_1
../../gcc/tree-cfgcleanup.c:797
0xe5d2f6 cleanup_tree_cfg_noloop
../../gcc/tree-cfgcleanup.c:911
0xe5d410 cleanup_tree_cfg()
../../gcc/tree-cfgcleanup.c:971
0xcdc9ef execute_function_todo
../../gcc/passes.c:1947
0xcdbb84 do_per_function
../../gcc/passes.c:1659
0xcdcd6d execute_todo
../../gcc/passes.c:2048

[Bug lto/89497] [8 Regression] ICE caused by Segmentation Fault when compiling cups 2.2.10 with LTO flags enabled

[marxin at gcc dot gnu.org]

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

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

However, this reduced test-case fails with GCC-8 branch for all releases.
Started on trunk with r256457 and was fixed on trunk r265421:

$ gcc 1.i 2.i 3.i 4.i -fPIC -O3 -fno-semantic-interposition -flto=8 -shared
3.i:9:4: warning: type of ‘ppdFindNextAttr’ does not match original declaration
[-Wlto-type-mismatch]
 b *ppdFindNextAttr();
^
2.i:1:6: note: ‘ppdFindNextAttr’ was previously declared here
 int *ppdFindNextAttr() { return 0; }
  ^
2.i:1:6: note: code may be misoptimized unless -fno-strict-aliasing is used
during GIMPLE pass: vrp
3.i: In function ‘d’:
3.i:14:6: internal compiler error: Segmentation fault
 void d() {
  ^
0xdfd704 crash_signal
../../gcc/toplev.c:325
0x779b1e0f ???
   
/usr/src/debug/glibc-2.29-1.3.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0xf2a8bc ptr_deref_may_alias_decl_p
../../gcc/tree-ssa-alias.c:169
0xf2cb91 indirect_ref_may_alias_decl_p
../../gcc/tree-ssa-alias.c:1154
0xf2db42 refs_may_alias_p_1(ao_ref*, ao_ref*, bool)
../../gcc/tree-ssa-alias.c:1488
0xaa0876 gimple_fold_builtin_memory_op
../../gcc/gimple-fold.c:918
0xaa79ca gimple_fold_builtin
../../gcc/gimple-fold.c:3657
0xaa95c9 gimple_fold_call
../../gcc/gimple-fold.c:4159
0xaaba38 fold_stmt_1
../../gcc/gimple-fold.c:4834
0xaac069 fold_stmt(gimple_stmt_iterator*)
../../gcc/gimple-fold.c:4981
0xe44b2a replace_uses_by(tree_node*, tree_node*)
../../gcc/tree-cfg.c:2025
0xe44fac gimple_merge_blocks
../../gcc/tree-cfg.c:2111
0x8c1c5a merge_blocks(basic_block_def*, basic_block_def*)
../../gcc/cfghooks.c:793
0xe5 cleanup_tree_cfg_bb
../../gcc/tree-cfgcleanup.c:715
0xe5cfae cleanup_tree_cfg_1
../../gcc/tree-cfgcleanup.c:797
0xe5d2f6 cleanup_tree_cfg_noloop
../../gcc/tree-cfgcleanup.c:911
0xe5d410 cleanup_tree_cfg()
../../gcc/tree-cfgcleanup.c:971
0xcdc9ef execute_function_todo
../../gcc/passes.c:1947
0xcdbb84 do_per_function
../../gcc/passes.c:1659
0xcdcd6d execute_todo
../../gcc/passes.c:2048

[Bug lto/89497] [8 Regression] ICE caused by Segmentation Fault when compiling cups 2.2.10 with LTO flags enabled

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||7.4.0, 9.0
  Known to fail||8.1.0, 8.2.0

--- Comment #7 from Martin Liška  ---
Will it help Richi? Can you please take a look?

[Bug c/89448] Failure to generate diagnostic for "complex int" (OK for "_Complex int")

[mrison at hotmail dot com]

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

--- Comment #4 from Mark RISON  ---
[Aside...

I can't see a way to raise a bug on the GCC Bugzilla itself, so:

The status of this bug is currently NEW.  However the explanatory hyperlink,
https://gcc.gnu.org/bugzilla/page.cgi?id=fields.html#bug_status suggests only
the following are valid statuses: UNCONFIRMED, CONFIRMED, IN_PROGRESS,
RESOLVED, VERIFIED.]

[Bug tree-optimization/89505] New: [9 Regression] LibreOffice miscompilation starting with r260383

[jakub at gcc dot gnu.org]

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

Bug ID: 89505
   Summary: [9 Regression] LibreOffice miscompilation starting
with r260383
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Created attachment 45823
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45823&action=edit
rh1682941.ii.xz

The attached testcase from LibreOffice is miscompiled starting with r260383
with
-O2 -fPIC -std=c++2a, unfortunately don't have a smaller testcase so far and
haven't succeeded in coming up with a reduced one.

In the dumps, look for case 263392: or 263392 and in *.optimized dump it should
look like:
  _59 = rtl_str_toInt32 (_58, 10);
  _148 = MIN_EXPR <_59, 1024>;
  _73 = MAX_EXPR <_148, 1>;
  this_12(D)->nColCount = _73;
but starting with r260383 it is not.

We have before dse1 code like:
  D.857771 = 1;
...
  _129 = rtl_str_toInt32 (_128, 10);
  D.857770 = _129;
  if (_129 <= 0)
goto ; [34.00%]
  else
goto ; [66.00%]

   :

   :
  # _119 = PHI <&D.857770(7), &D.857771(8)>
  _12 = *_119;
  this_29(D)->nColCount = _12;
  D.857770 ={v} {CLOBBER};
  D.857771 ={v} {CLOBBER};
  D.857772 = 1024;
  _13 = &this_29(D)->nColCount;
  if (_12 > 1024)
goto ; [34.00%]
  else
goto ; [66.00%]

   :

   :
  # _116 = PHI <_13(9), &D.857772(10)>
  _15 = *_116;
  this_29(D)->nColCount = _15;

In *.mergephi1 with -alias-vops the difference (trunk vs. trunk with r260383
reverted) is:
   # .MEM_55 = VDEF <.MEM_23>
   D.857771 = 1;
...
   # .MEM_206 = VDEF <.MEM_55>
-  # USE = nonlocal null { D.112965 D.113017 D.857775 D.85 D.857779 }
(nonlocal, escaped, interposable)
-  # CLB = nonlocal null { D.112965 D.113017 D.857775 D.85 D.857779 }
(nonlocal, escaped, interposable)
+  # USE = nonlocal null { D.112965 D.113017 D.857775 D.85 D.857779
D.1010617 } (nonlocal, escaped, restrict, interposable)
+  # CLB = nonlocal null { D.112965 D.113017 D.857775 D.85 D.857779
D.1010617 } (nonlocal, escaped, restrict, interposable)
   _129 = rtl_str_toInt32 (_128, 10);
   # .MEM_57 = VDEF <.MEM_206>
   D.857770 = _129;
   if (_129 <= 0)
 goto ; [34.00%]
   else
 goto ; [66.00%]

:

:
   # PT = { D.857770 D.857771 }
   # ALIGN = 4, MISALIGN = 0
   # _119 = PHI <&D.857770(7), &D.857771(8)>
   # VUSE <.MEM_57>
-  _12 = *_119;
+  _12 = MEM[(const int &)_119 clique 1 base 0];
   # .MEM_59 = VDEF <.MEM_57>
-  this_29(D)->nColCount = _12;
+  MEM[(struct ScXMLTableColContext *)this_29(D) clique 1 base 1].nColCount =
_12;
   # .MEM_60 = VDEF <.MEM_59>
   D.857770 ={v} {CLOBBER};
   # .MEM_61 = VDEF <.MEM_60>
   D.857771 ={v} {CLOBBER};
   # .MEM_62 = VDEF <.MEM_61>
   D.857772 = 1024;
-  # PT = nonlocal 
+  # PT = { D.1010617 } (nonlocal, escaped)
   _13 = &this_29(D)->nColCount;
   if (_12 > 1024)
 goto ; [34.00%]
   else
 goto ; [66.00%]

:

:
-  # PT = nonlocal { D.857772 }
+  # PT = { D.857772 D.1010617 } (nonlocal, escaped)
   # _116 = PHI <_13(9), &D.857772(10)>
   # VUSE <.MEM_62>
-  _15 = *_116;
+  _15 = MEM[(const int &)_116 clique 1 base 0];
   # .MEM_64 = VDEF <.MEM_62>
-  this_29(D)->nColCount = _15;
+  MEM[(struct ScXMLTableColContext *)this_29(D) clique 1 base 1].nColCount =
_15;

and DSE1 removes the nColCount store:
:
   # _119 = PHI <&D.857770(7), &D.857771(8)>
   _12 = *_119;
-  this_29(D)->nColCount = _12;
   D.857770 ={v} {CLOBBER};
   D.857771 ={v} {CLOBBER};
   D.857772 = 1024;
...
:
   # _116 = PHI <_13(9), &D.857772(10)>
   _15 = *_116;
-  this_29(D)->nColCount = _15;
+  *this_29(D).nColCount = _15;
   D.857772 ={v} {CLOBBER};
   goto ; [INV]

I've tried to reduce this to:
template constexpr inline const _Tp&
min (const _Tp& __a, const _Tp& __b) { if (__b < __a) return __b; return __a; }
template constexpr inline const _Tp&
max (const _Tp& __a, const _Tp& __b) { if (__a < __b) return __b; return __a; }
template constexpr inline const _Tp&
min (const _Tp& __a, const _Tp& __b, _Compare __comp) { if (__comp(__b, __a))
return __b; return __a; }
template constexpr inline const _Tp&
max (const _Tp& __a, const _Tp& __b, _Compare __comp) { if (__comp(__a, __b))
return __b; return __a; }
int foo () throw ();
struct S { char pad[80]; int nColCount; S (); };
const signed short m = 1024;
int v;
S::S ()
{
  nColCount = 1;
  if (v)
{
  nColCount = max (foo (), 1);
  nColCount = min (nColCount, m);
}
}
but that doesn't reproduce this.

[Bug tree-optimization/89505] [9 Regression] LibreOffice miscompilation starting with r260383

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||glisse at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Target Milestone|--- |9.0

[Bug lto/89497] [8 Regression] ICE caused by Segmentation Fault when compiling cups 2.2.10 with LTO flags enabled

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
I can also confirm that building the whole project with original flags and
current GCC trunk is fine.

[Bug target/89474] [9 Regression] ice in df_reg_chain_verify_unmarked, at df-scan.c:3995

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Tue Feb 26 10:08:29 2019
New Revision: 269206

URL: https://gcc.gnu.org/viewcvs?rev=269206&root=gcc&view=rev
Log:
PR target/89474
* config/i386/i386.c (remove_partial_avx_dependency): Call
df_analyze etc. before creation of the v4sf_const0 pseudo, rather than
after changing possibly many instructions to use that pseudo.  Fix up
insertion of v4sf_const0 setter at the start of bb.

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

Added:
trunk/gcc/testsuite/gcc.target/i386/pr89474.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/89479] __restrict

[eyalroz at technion dot ac.il]

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

--- Comment #5 from Eyal Rozenberg  ---
(In reply to Richard Biener from comment #4)
> exposing __restrict to the IL). 

Is "IL" an acronym for "Intermediate Language"? Remember many bug
posters/readers are not GCC developers and don't know all the lingo.

> To elaborate further to successfully mark a function call
> with clique == 1 and base == 0 we have to prove the pointer marked restrict
> doesn't escape the function through calls

Certainly, calling g() could be just the same as writing to an alias of the x
pointer. But - __restrict is how we guarantee this doesn't happen (or can be
ignored) even when the compiler can't prove that's the case on its own. So I'm
not sure I understand what you're suggesting with your comment. I suppose you
could try and "disprove the __restrict" to give a warning, but other than that
- why not just respect it?

[Bug target/89502] Inefficient access to stack_guard in TCB

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
(In reply to H.J. Lu from comment #0)
> x.s: Assembler messages:
> x.s:11: Error: can't encode segment `%fs' with 32-bit address
> x.s:18: Error: can't encode segment `%fs' with 32-bit address

Is this some new warning, since

GNU assembler version 2.31.1-17.fc29

happily assembles 

movl%fs:(%edx), %ecx

to:

   8:   64 67 8b 0a mov%fs:(%edx),%ecx

Anyway, the following patch should fix this issue:

--cut here--
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index e77653d66a4..67872e1c15d 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -18542,6 +18542,10 @@ ix86_print_operand_address_as (FILE *file, rtx addr,

   if (!ADDR_SPACE_GENERIC_P (as))
 {
+  /* We can't have 0x67 prefix with segment override.  */
+  if (TARGET_64BIT)
+   code = 'q';
+
   if (ASSEMBLER_DIALECT == ASM_ATT)
putc ('%', file);

--cut here--

[Bug target/89502] Inefficient access to stack_guard in TCB

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak  ---
(In reply to H.J. Lu from comment #1)
> Ever better, we can use UNSPEC_TP to handle it:
> 
>   movl%fs:24, %ecx
> 
> to save a register.

We do, with -O2, but -O1 CSEs the constant into the register for some reason.

[Bug tree-optimization/89505] [9 Regression] LibreOffice miscompilation starting with r260383

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
I think the problem is mainly:
  MEM[(struct ScXMLTableColContext *)this_29(D) clique 1 base 1].nColCount =
_15;
vs.
  _15 = MEM[(const int &)_116 clique 1 base 0];
Both have the same clique, but different base.
std::min(nColCount, MAXCOLCOUNT)
returns a reference, and I bet if this argument was explicitly __restrict, that
would be invalid, referencing *this through some other pointer (reference in
this case).  this argument is not restrict though, and it can alias
references/pointers within the constructor, e.g.
struct S { int s; S (S &, S *); };
S *foo (S *);
S::S (S &x, S *y)
{
  // x.s can't alias this->s
  // y->s can't alias this->s
  S *p = foo (this);
  // p->s can alias this->s
}

[Bug target/89474] [9 Regression] ice in df_reg_chain_verify_unmarked, at df-scan.c:3995

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #11 from Jakub Jelinek  ---
Fixed.

[Bug target/87007] [8 Regression] 10% slowdown with -march=skylake-avx512

[jakub at gcc dot gnu.org]

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

Bug 89474 Summary: [9 Regression] ice in df_reg_chain_verify_unmarked, at 
df-scan.c:3995
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89474

   What|Removed |Added

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

[Bug tree-optimization/89505] [9 Regression] LibreOffice miscompilation starting with r260383

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
ScXMLTableColContext::ScXMLTableColContext (struct ScXMLTableColContext * const
this, struct ScXMLImport & rImport, const struct Reference & rAttrList)
{
  # PT = null { D.1010617 } (nonlocal, escaped, restrict)
  struct ScXMLTableColContext * const this_29(D) = this;

...

   :
  # PT = { D.857772 D.1010617 } (nonlocal, escaped)
  # _116 = PHI <_13(9), &D.857772(10)>
  _15 = MEM[(const int &)_116 clique 1 base 0];

the _116 deref shouldn't have gotten base 0 because of

  vi = get_varinfo (find (vi->id));
  if (bitmap_intersect_p (rvars, vi->solution)
  || (escaped_p && bitmap_bit_p (vi->solution, escaped_id)))
return false;

now I need to debug what goes wrong...

[Bug fortran/43210] Initializer of huge static arrays should be improved

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Tue Feb 26 10:36:05 2019
New Revision: 269207

URL: https://gcc.gnu.org/viewcvs?rev=269207&root=gcc&view=rev
Log:
PR fortran/43210
* trans-array.c (gfc_conv_array_initializer): Use RANGE_EXPR instead
of duplicating the initializer possibly many times.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c

[Bug tree-optimization/89505] [9 Regression] LibreOffice miscompilation starting with r260383

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-02-26
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
So what happens is that this points to an aggregate with a lot of fields and
field-sensitive analysis when gathering what are restrict pointed-to's only
looks at the first field.  Thus if you'd have

struct this { int x; void *p; };

and

  _13 = &this_29(D)->nColCount;
  # _116 = PHI <_13(9), &D.857772(10)>
  _15 = *_116;

here _13 does not point to the _first_ field (note you need meaningful
fields - aka pointers - for points-to to separate fields fod analysis)
then we miss that _116 also points to the same thing as this_29.

Then you need a plain this_29 based access and a indirect ref to _13
to get things wrong.

struct S { int i; void *p; int j; };
int a;
int foo (struct S * __restrict p, int q)
{
  int *x = &p->j;
  if (q)
x = &a;
  p->j = 1;
  *x = 2;
  return p->j;
}

shows wrong alias info:

  # PT = null { D.1921 } (nonlocal, restrict)
  struct S * restrict p_2(D) = p;
...
   :
  # PT = null { D.1909 D.1921 } (nonlocal, interposable)
  # x_1 = PHI 
  MEM[(struct S *)p_2(D) clique 1 base 1].j = 1;
  MEM[(int *)x_1 clique 1 base 0] = 2;
  _9 = MEM[(struct S *)p_2(D) clique 1 base 1].j;

and FRE optimizing the load.


struct S { int i; void *p; int j; };
int a;
int __attribute__((noinline))
foo (struct S * __restrict p, int q)
{
  int *x = &p->j;
  if (q)
x = &a;
  p->j = 1;
  *x = 2;
  return p->j;
}

int main()
{
  struct S s;
  if (foo (&s, 0) != 2)
__builtin_abort ();
  return 0;
}

[Bug tree-optimization/89479] __restrict on a pointer ignored when a function is passed alongside it

[eyalroz at technion dot ac.il]

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

--- Comment #6 from Eyal Rozenberg  ---
Thanks to a friendly StackOverflow user, I should also report that (about) the
same code produces the same compiler behavior disparity for proper C:

https://godbolt.org/z/kVYqp8

with the slight modification being `void g(void)` instead of `void g()` in the
function signatures.

[Bug target/88469] [7/8 regression] AAPCS/AAPCS64 - Struct with 64-bit bitfield (128-bit on AArch64) may be passed in wrong registers

[rearnsha at gcc dot gnu.org]

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

--- Comment #13 from Richard Earnshaw  ---
(In reply to Stefan Ring from comment #12)
> Unfortunately my armv5 device has died in the meantime, so I cannot verify
> my original use case. The behavior is indeed different on armv7. It does not
> trap, even for the original misaligned code. And contrary to x86, where the
> alignment check flag can be changed by user space, this is a privileged
> operation on arm, so I cannot even selectively enable it.

Note that if you have root access on your board you can modify the kernel's
behaviour for various unaligned accesses by changing /proc/cpu/alignment (see
Documentation/arm/mem_alignment in the kernel sources).  You might want to try
setting this to 3 to get the kernel to report (but fix up) any misaligned
accesses).

[Bug tree-optimization/89505] [9 Regression] LibreOffice miscompilation starting with r260383

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Created attachment 45824
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45824&action=edit
patch I am testing

[Bug tree-optimization/89489] [9 Regression] ICE in gimple_duplicate_bb, at tree-cfg.c:6257

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Tue Feb 26 11:03:45 2019
New Revision: 269210

URL: https://gcc.gnu.org/viewcvs?rev=269210&root=gcc&view=rev
Log:
2019-02-26  Richard Biener  

PR tree-optimization/89489
* tree-parloops.c (create_loop_fn): Copy over last_clique.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-parloops.c

[Bug tree-optimization/89489] [9 Regression] ICE in gimple_duplicate_bb, at tree-cfg.c:6257

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
Fixed.

[Bug libstdc++/64132] [7/8/9 Regression] FAIL: 22_locale/numpunct/members/char/3.cc execution test

[redi at gcc dot gnu.org]

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

--- Comment #15 from Jonathan Wakely  ---
Probably r265165 or r265286

[Bug c/89410] [7/8 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1237 after #line

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org

--- Comment #17 from Tamar Christina  ---
Hi, 

I'm getting a test failure on master for these new tests

UNRESOLVED: gcc.dg/pr89410-1.c: bad option "-1": must be -exact, -glob,
-regexp, or -- for " dg-warning 8 "msg" "" { target *-*-* } -1 "

is that `-1` correct there?

[Bug libstdc++/64132] [7/8/9 Regression] FAIL: 22_locale/numpunct/members/char/3.cc execution test

[redi at gcc dot gnu.org]

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

--- Comment #16 from Jonathan Wakely  ---
I suspect Debian had downstream changes to the it_IT.ISO8859-15 locale data, as
was later done in upstream glibc. The original version of the test failed if
it_IT.ISO8859-15 uses thousands separators. The changes in r265165 would have
fixed it, by using a different locale.

The test I put in comment 11 was after that change to use nl_NL, which explains
why it shows no grouping. Mystery solved.

[Bug target/88469] [7/8 regression] AAPCS/AAPCS64 - Struct with 64-bit bitfield (128-bit on AArch64) may be passed in wrong registers

[stefanrin at gmail dot com]

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

--- Comment #14 from Stefan Ring  ---
(In reply to Richard Earnshaw from comment #13)
> Note that if you have root access on your board you can modify the kernel's
> behaviour for various unaligned accesses by changing /proc/cpu/alignment
> (see Documentation/arm/mem_alignment in the kernel sources).  You might want
> to try setting this to 3 to get the kernel to report (but fix up) any
> misaligned accesses).

I know that, but armv7 does not trap at all for misaligned ldrd, at the
hardware level. It does trap if it’s not even 32bit-aligned, but that’s a
different matter.

[Bug debug/89498] [8/9 Regression] ICE in AT_loc_list, at dwarf2out.c:4871

[gs...@t-online.de]

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

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

Hm, on my environment it's not necessary to include ,
can therefore be omitted. But that case was only exemplary.

You can try to catch the other ones, e.g. simply looping over


###

export LANG=C
cd gcc/testsuite

for i in */*.[cC] */*/*.[cC] */*/*/*.[cC]
do
   timeout 2.0 gcc-9-20190224 -c $i -O2 -gdwarf-5 -gsplit-dwarf
done > _list 2>&1

grep -i 'internal compiler' _list
grep -i 'internal compiler' _list | wc -l

###


Or alternatively one combination out of :
   -O2 -gdwarf -gsplit-dwarf
   -O2 -gdwarf-5 -gsplit-dwarf
   -O2 -gdwarf-4 -gsplit-dwarf
   -O2 -g -gdwarf-5 -gsplit-dwarf


It would be very astonishing if nothing comes out there ...
On my plain vanilla test PC above loop finds 19341 cases with ICE :

$ grep -i 'internal compiler' _list | wc -l
19341


Including another ICE group (closely related or not)
with 2327 failing cases, e.g. :

$ gcc-9-20190224 -c gcc.dg/align-2.c -O2 -gdwarf-5 -gsplit-dwarf
gcc.dg/align-2.c:6:1: internal compiler error: Segmentation fault
6 | extern char compile_time_assert[__alignof__(v4) == sizeof(float)*4 ? 1
: -1];
  | ^~
0xa89c1f crash_signal
../../gcc/toplev.c:326
0x797b34 void hash_table::traverse_noresize(unsigned int*)
../../gcc/hash-table.h:965
0x797b34 dwarf2out_finish
../../gcc/dwarf2out.c:31551

[Bug sanitizer/82501] AddressSanitizer does not handle negative offset for first global variable

[marxin at gcc dot gnu.org]

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

--- Comment #20 from Martin Liška  ---
(In reply to Andrey Drobyshev from comment #18)
> (In reply to Martin Liška from comment #16)
> > Created attachment 45797 [details]
> > Patch candidate
> > 
> > Patch candidate where I made some refactoring and come up with tests.
> > Works fine on x86_64, on ppc64le there are some issues with
> > -fsection-anchors, but that would be possible to resolve.
> > 
> > Please let me know if you're fine with that and we can submit that to
> > gcc-patches ML?
> 
> Looks good to me. By not setting TREE_PUBLIC flag we give our dummy globals
> internal linkage (as if they were static), thus allowing linker to mix
> multiple TUs with these dummies.

One can't use TREE_PUBLIC because:

$ cat a.c
int a = 2;

$ cat b.c
int b = 3;

$ gcc a.c b.c -fsanitize=address
/usr/bin/ld: /tmp/ccSj1xmO.o:(.data+0x0): multiple definition of
`__asan_data_dummy_global'; /tmp/ccsHDJug.o:(.data+0x0): first defined here
/usr/bin/ld: /usr/lib/../lib64/crt1.o: in function `_start':
/home/abuild/rpmbuild/BUILD/glibc-2.29/csu/../sysdeps/x86_64/start.S:104:
undefined reference to `main'
collect2: error: ld returned 1 exit status

> 
> However, this way number of dummy globals in the resulting executable is
> proportional to the number of TUs, and each of them occupies additional 64b
> for redzone (due to alignment) + its poisoned metadata (struct
> __asan_global, also 64b on x86_64). I guess that's what was meant by
> "wasting more memory" in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82501#c1. I'm not sure, are we
> ok with such a waste?

Yes, I hope it's a reasonable trade off.

[Bug rtl-optimization/89506] New: [7/8/9 Regression] ICE: in decompose, at rtl.h:2266 with -Og -g

[zsojka at seznam dot cz]

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

Bug ID: 89506
   Summary: [7/8/9 Regression] ICE: in decompose, at rtl.h:2266
with -Og -g
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: armv7a-hardfloat-linux-gnueabi

Created attachment 45825
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45825&action=edit
reduced testcase

Compiler output:
$ armv7a-hardfloat-linux-gnueabi-gcc -Og -g testcase.c
during RTL pass: vartrack
testcase.c: In function 'foo':
testcase.c:10:1: internal compiler error: in decompose, at rtl.h:2266
   10 | }
  | ^
0xa54130 wi::int_traits >::decompose(long*,
unsigned int, std::pair const&)
/repo/gcc-trunk/gcc/rtl.h:2264
0xdbc19c wide_int_ref_storage::wide_int_ref_storage
>(std::pair const&, unsigned int)
/repo/gcc-trunk/gcc/wide-int.h:1013
0xdbc19c generic_wide_int
>::generic_wide_int >(std::pair const&, unsigned int)
/repo/gcc-trunk/gcc/wide-int.h:788
0xdbc19c wi::binary_traits,
std::pair, wi::int_traits >::precision_type, wi::int_traits >::precision_type>::result_type wi::add, std::pair >(std::pair const&, std::pair const&)
/repo/gcc-trunk/gcc/wide-int.h:2403
0xdbc19c simplify_const_binary_operation(rtx_code, machine_mode, rtx_def*,
rtx_def*)
/repo/gcc-trunk/gcc/simplify-rtx.c:4286
0xdbb693 simplify_binary_operation(rtx_code, machine_mode, rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/simplify-rtx.c:2164
0xdcc86e simplify_plus_minus
/repo/gcc-trunk/gcc/simplify-rtx.c:4686
0xdb6277 simplify_binary_operation_1
/repo/gcc-trunk/gcc/simplify-rtx.c:2388
0xdbb6c5 simplify_binary_operation(rtx_code, machine_mode, rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/simplify-rtx.c:2167
0x9b0946 cselib_expand_value_rtx_1
/repo/gcc-trunk/gcc/cselib.c:1856
0x9b1eae cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
/repo/gcc-trunk/gcc/cselib.c:1562
0x10b6ea0 vt_expand_var_loc_chain
/repo/gcc-trunk/gcc/var-tracking.c:8384
0x10b7538 vt_expand_loc_callback
/repo/gcc-trunk/gcc/var-tracking.c:8547
0x9b087a cselib_expand_value_rtx_1
/repo/gcc-trunk/gcc/cselib.c:1716
0x9b0515 cselib_expand_value_rtx_1
/repo/gcc-trunk/gcc/cselib.c:1754
0x9b1eae cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
/repo/gcc-trunk/gcc/cselib.c:1562
0x10b6ea0 vt_expand_var_loc_chain
/repo/gcc-trunk/gcc/var-tracking.c:8384
0x10b7538 vt_expand_loc_callback
/repo/gcc-trunk/gcc/var-tracking.c:8547
0x9b087a cselib_expand_value_rtx_1
/repo/gcc-trunk/gcc/cselib.c:1716
0x9b0515 cselib_expand_value_rtx_1
/repo/gcc-trunk/gcc/cselib.c:1754
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug sanitizer/82501] AddressSanitizer does not handle negative offset for first global variable

[marxin at gcc dot gnu.org]

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

--- Comment #21 from Martin Liška  ---
Thanks for the test-case.

> 
> So I guess we still have to detect relocations. I cannot see limitations
> coming particularly from approach #2 from
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82501#c1. We just need to pass
> the right reloc value to categorize_decl_for_section().

Can you please tweak the patch to emit these?

[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1

[pkubaj at anongoth dot pl]

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

--- Comment #6 from Piotr Kubaj  ---
(In reply to Richard Biener from comment #5)
> So it looks like stage1 gcc is miscompiled somehow.  I wonder if you can
> avoid
> setting CFLAGS et al?

I just added CFLAGS+=-O0 and CXXFLAGS+=-O0. For now, the build is ongoing (I'm
building GCC 7 first, as it had the most verbose errors), but I think it's
already past the stage where it crashed. I will leave it open until all
versions are built (7, 8, 9)

Thanks!

[Bug fortran/67542] ICE in gfc_emit_parameter_debug_info, at fortran/trans-decl.c:4947 and :4945

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
I cannot get any ICE with the options and revisions I have tried.

[Bug fortran/79864] Implicit type conversion on assignment of unallocated array to unallocated array variable segfaults.

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Dominique d'Humieres  ---
> Compiling the test with '-Wall -Wextra -fcheck=all -Ofast -m32 
> -fsanitize=address'
> gives ...

I no longer see the warnings with 8.2.0 and trunk (9.0).

From pr79863 comment 5, the code is invalid.

[Bug c++/70644] Warn about implicit conversion of 'this' to pointer to virtual base class during construction

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
  -Wbase-conversion (C++, Objective-C++ only)
Warn when a pointer/reference to an object is converted to a
pointer/reference to a base class of the object and any intermediate
base classes have not begun construction yet.

I think the [basic.life] reference I gave was incorrect. For an object under
construction the correct reference is [class.cdtor]. I'm no longer sure if the
original testcase is actually undefined, but both f(this) calls in this version
require an undefined conversion to B* before the D base class has begun
construction:

struct B { B(int) { } };
struct D : virtual B { D(int i) : B(i) { } };

int foo(B*) { return 0; }

struct X : D {
  X() : B(foo(this)), D(foo(this)) { }
};

int main() {
  X x;
}


The problem isn't specific to virtual bases either, this is also undefined
because it converts X* to B* before construction of the D base has begun:

struct B { };
struct D : B { D(int i) { } };

int foo(B*) { return 0; }

struct X : D {
  X() : D(foo(this)) { }
};

int main() {
  X x;
}

This testcase is based on the one in [class.cdtor] and doesn't give a warning
or ubsan error for the undefined E* to A* conversion:

struct A { };
struct B : virtual A { };
struct C : B { };
struct D : virtual A { D(A*); };
struct X { X(A*); };

struct E : C, D, X {
  E()
  : D(this), // undefined: upcast from E* to A* might use path E* → D* → A*
 // but D is not constructed
 // “D((C*)this)” would be defined:
 // E* → C* is defined because E() has started,
 // and C* → A* is defined because C is fully constructed

X(this)  // defined: upon construction of X, C/B/D/A sublattice is
 // fully constructed
  { }
};

int main()
{
  E e;
}

D::D(A*) { }
X::X(A*) { }

[Bug c++/89507] New: bogus "size of array exceeds maximum object size"

[sbergman at redhat dot com]

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

Bug ID: 89507
   Summary: bogus "size of array exceeds maximum object size"
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
CC: caolanm at redhat dot com, msebor at gcc dot gnu.org
  Target Milestone: ---

With current trunk (towards GCC 9),

> $ cat test.cc
> unsigned char const n = 128;
> int * p = new int[n];
>
> $ g++ -c test.cc
> test.cc:2:20: error: size ‘128’ of array exceeds maximum object size 
> ‘9223372036854775807’
> 2 | int * p = new int[n];
>   |^

This looks like a regression introduced with
 "PR c++/87996 -
size of array is negative error when SIZE_MAX/2 < sizeof(array) <= SIZE_MAX". 
(This breaks the build of LibreOffice,

> [CXX] i18npool/source/characterclassification/cclass_unicode_parser.cxx
> i18npool/source/characterclassification/cclass_unicode_parser.cxx: In member 
> function ‘void i18npool::cclass_Unicode::initParserTable(const 
> com::sun::star::lang::Locale&, sal_Int32, const rtl::OUString&, sal_Int32, 
> const rtl::OUString&)’:
> i18npool/source/characterclassification/cclass_unicode_parser.cxx:417:45: 
> error: size ‘128’ of array exceeds maximum object size ‘9223372036854775807’
>   417 | pTable.reset(new ParserFlags[nDefCnt]);
>   | ^

.)

[Bug c++/67650] undef reference with -fdevirtualize

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2018-05-03 00:00:00 |2019-2-26

--- Comment #34 from Jonathan Wakely  ---
Honza, could you take another look at this reduced version please?

__attribute__((weak)) void f() { }

template 
struct Base
{
  virtual void virt() = 0;
  void do_virt() { virt(); }
};

template 
struct Derived : Base
{
  void virt() {}
};

template 
struct Wrap
{
  T* p = nullptr;

  virtual void indirect_virt()
  {
#ifdef FIX
p->virt();  // OK
#else
p->do_virt();   // link error
#endif
  }
};

template 
struct Template
{
};

constexpr char str[] = "";

struct I
{
  I() { f(); }
  Wrap>> l;
};

int main(){new I();}


This is valid C++, but when compiled with -O1 -fdevirtualize it fails with:

l.cc:13:8: warning: ‘void Derived::virt() [with T = Template<(& str)>]’ used
but never defined
   void virt() {}
^~~~
/usr/bin/ld: /tmp/ccYAFtTY.o: in function `Wrap >
>::indirect_virt()':
l.cc:(.text+0x57): undefined reference to `Derived >::virt()'
collect2: error: ld returned 1 exit status

If compiled with -DFIX it links OK.

Even though the Template<(&str)> template argument is completely unused, it
compiles fine if Derived is used instead, or
Derived>. It only fails when using a template that has a
pointer for its template parameter.

[Bug target/89508] New: gcc snapshot 9.0.1 20190127 generates invalid assembler options on aarch64-unknown-linux-gnu with -march=native

[andrewm.roberts at sky dot com]

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

Bug ID: 89508
   Summary: gcc snapshot 9.0.1 20190127 generates invalid
assembler options on aarch64-unknown-linux-gnu with
-march=native
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrewm.roberts at sky dot com
  Target Milestone: ---

The latest gcc 9 snapshot (gcc version 9.0.1 20190127 (experimental)) fails
to compile files  (due to assembler option errors) when used with -march=native
on aarch64-unknown-linux-gnu

The gcc-8.3.0 release built with the same options accepts -march=native and
generates options the assembler can accept.

If -march=native is no longer accepted, it should generate a warning or error
as appropriate, or be silently ignored.

/usr/local/gcc/bin/gcc - is the gcc 9 snapshot
/usr/local/gcc-8.3.0/bin/gcc - is the gcc 8.3.0 release

All testing done an a Raspberry Pi 3B (BCM2837), ARM Cortex A53, running 64 bit
ArchLinux ARM:
uname -a
Linux alarm 4.20.11-1-ARCH #1 SMP Wed Feb 20 19:23:26 MST 2019 aarch64
GNU/Linux

The system binutils is used (2.31.1)

as --version
GNU assembler (GNU Binutils) 2.31.1
Copyright (C) 2018 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `aarch64-unknown-linux-gnu'.


Output of gcc-9.0.1 --help=target with -march=native:
(the guessed -march line is not accepted by the assembler)

/usr/local/gcc/bin/gcc -march=native -Q --help=target
The following options are target specific:
  -mabi=lp64
  -march=  
armv8-a+crc+profile+rng+memtag+sb+ssbs+predres
  -mbig-endian  [disabled]
  -mbionic  [disabled]
  -mbranch-protection=
  -mcmodel= small
  -mcpu=generic
  -mfix-cortex-a53-835769   [enabled]
  -mfix-cortex-a53-843419   [enabled]
  -mgeneral-regs-only   [disabled]
  -mglibc   [enabled]
  -mlittle-endian   [enabled]
  -mlow-precision-div   [disabled]
  -mlow-precision-recip-sqrt[disabled]
  -mlow-precision-sqrt  [disabled]
  -mmusl[disabled]
  -momit-leaf-frame-pointer [enabled]
  -moverride=
  -mpc-relative-literal-loads   [enabled]
  -msign-return-address=none
  -mstack-protector-guard-offset=
  -mstack-protector-guard-reg=
  -mstack-protector-guard=  global
  -mstrict-align[disabled]
  -msve-vector-bits=scalable
  -mtls-dialect=desc
  -mtls-size=   24
  -mtrack-speculation   [disabled]
  -mtune=   generic
  -muclibc  [disabled]
  -mverbose-cost-dump   [disabled]

  Known AArch64 ABIs (for use with the -mabi= option):
ilp32 lp64

  Supported AArch64 return address signing scope (for use with
-msign-return-address= option):
all non-leaf none

  The code model option names for -mcmodel:
large small tiny

  Valid arguments to -mstack-protector-guard=:
global sysreg

  The possible SVE vector lengths:
1024 128 2048 256 512 scalable

  The possible TLS dialects:
desc trad

Assembler messages:
Error: unknown architectural extension `rng+memtag+sb+ssbs+predres'
Error: unrecognized option
-march=armv8-a+crc+profile+rng+memtag+sb+ssbs+predres

gcc-9.0.1 build options:

 /usr/local/gcc/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-9.0.0/libexec/gcc/aarch64-unknown-linux-gnu/9.0.1/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: ../gcc-9.0.0/configure --prefix=/usr/local/gcc-9.0.0
--program-suffix= --disable-werror --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin
--enable-gnu-indirect-function --enable-lto --with-isl
--enable-languages=c,c++,fortran,lto --disable-libgcj --enable-clocale=gnu
--disable-libstdcxx-pch --enable-install-libiberty --disable-multilib
--enable-shared --with-arch-directory=aarch64 --enable-multiarch
--disable-libssp --enable-default-pie --enable-default-ssp
--host=aarch64-unknown-linux-gnu --build=aarch64-unknown-linux-gnu
--with-arch=armv8-a --disable-bootstrap
Thread model: posix
gcc version 9.0.1 20190127 (experimental) (GCC)

Output of gcc-

[Bug c++/67650] undef reference with -fdevirtualize

[redi at gcc dot gnu.org]

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

--- Comment #35 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #34)
> __attribute__((weak)) void f() { }

This is here so that I() { f(); } doesn't get inlined (because the compiler
can't know what f() does, since it might get replaced during linking). Without
a call to some non-inlinable function it links OK. For the version in comment
29 the std::string constructor and destructor served that purpose, because
they're defined in libstdc++.so and not inlined.

[Bug go/89171] FAIL: go/build

[sch...@linux-m68k.org]

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

--- Comment #3 from Andreas Schwab  ---
How can I build and run a single libgo test?

[Bug rtl-optimization/89430] A missing ifcvt optimization to generate csel

[jiangning.liu at amperecomputing dot com]

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

--- Comment #8 from Jiangning Liu  ---
It is related to https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02998.html

Bernd's patch is an overkill.

[Bug target/89502] Inefficient access to stack_guard in TCB

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  ---
(In reply to Uroš Bizjak from comment #3)
> (In reply to H.J. Lu from comment #0)
> > x.s: Assembler messages:
> > x.s:11: Error: can't encode segment `%fs' with 32-bit address
> > x.s:18: Error: can't encode segment `%fs' with 32-bit address
> 
> Is this some new warning, since

Yes. it will be in binutils 2.33.

> GNU assembler version 2.31.1-17.fc29
> 
> happily assembles 
> 
>   movl%fs:(%edx), %ecx
> 
> to:
> 
>8:   64 67 8b 0a mov%fs:(%edx),%ecx
> 
> Anyway, the following patch should fix this issue:
> 
> --cut here--
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index e77653d66a4..67872e1c15d 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -18542,6 +18542,10 @@ ix86_print_operand_address_as (FILE *file, rtx addr,
>  
>if (!ADDR_SPACE_GENERIC_P (as))
>  {
> +  /* We can't have 0x67 prefix with segment override.  */
> +  if (TARGET_64BIT)
> +   code = 'q';
> +
>if (ASSEMBLER_DIALECT == ASM_ATT)
> putc ('%', file);
>  
> --cut here--

I think we should avoid %fs:(%edx) address.  Is that possible to generate
%fs:24 even at -O0?  Glibc can do it at -O0:

[hjl@gnu-cfl-1 gcc]$ cat x.i
int
foo (void)
{
  int i;
  asm volatile ("movl %%fs:%P1, %0" : "=r" (i) : "i" (24)); 
  return i;
}
[hjl@gnu-cfl-1 gcc]$ gcc -S -O0 x.i 
[hjl@gnu-cfl-1 gcc]$ cat x.s
.file   "x.i"
.text
.globl  foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
pushq   %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
#APP
# 5 "x.i" 1
movl %fs:24, %eax
# 0 "" 2
#NO_APP
movl%eax, -4(%rbp)
movl-4(%rbp), %eax
popq%rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size   foo, .-foo
.ident  "GCC: (GNU) 8.3.1 20190223 (Red Hat 8.3.1-2)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-1 gcc]$

[Bug target/89506] [7/8/9 Regression] ICE: in decompose, at rtl.h:2266 with -Og -g

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-26
 CC||jakub at gcc dot gnu.org
  Component|rtl-optimization|target
   Target Milestone|--- |7.5
 Ever confirmed|0   |1

[Bug target/89508] gcc snapshot 9.0.1 20190127 generates invalid assembler options on aarch64-unknown-linux-gnu with -march=native

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||tnfchris at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Tamar Christina  ---
Marking as a dupe of PR target/88530.

This will be fixed by https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00381.html
once it's committed.

Thanks!

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

[Bug target/88530] [8/9 Regression] AArch64 Unsupported options passed to assemblers when it doesn't need to.

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

 CC||andrewm.roberts at sky dot com

--- Comment #4 from Tamar Christina  ---
*** Bug 89508 has been marked as a duplicate of this bug. ***

[Bug target/89506] [7/8/9 Regression] ICE: in decompose, at rtl.h:2266 with -Og -g

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug go/89171] FAIL: go/build

[ian at airs dot com]

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

--- Comment #4 from Ian Lance Taylor  ---
To run, say, just the go/build test, cd to the libgo build directory and run
"make go/build/check".  To keep the test binary around, run "make
GOTESTFLAGS=--keep go/build/check".  That will leave the test binary (and other
stuff) in the directory gotestN/test.  In that directory you can run
"LD_LIBRARY_PATH=../../.libs ./a.out -test.short".  That executable also takes
other options, like "-test.run=TestDependencies" to run just the
TestDependencies test.

[Bug target/89502] Inefficient access to stack_guard in TCB

[ubizjak at gmail dot com]

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

--- Comment #6 from Uroš Bizjak  ---
(In reply to H.J. Lu from comment #5)

> I think we should avoid %fs:(%edx) address.  Is that possible to generate

It is what middle-end expands to, so nothing much that we can do here.

[Bug c/89410] [7/8 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1237 after #line

[dmalcolm at gcc dot gnu.org]

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

--- Comment #18 from David Malcolm  ---
(In reply to Tamar Christina from comment #17)
> Hi, 
> 
> I'm getting a test failure on master for these new tests
> 
> UNRESOLVED: gcc.dg/pr89410-1.c: bad option "-1": must be -exact, -glob,
> -regexp, or -- for " dg-warning 8 "msg" "" { target *-*-* } -1 "
> 
> is that `-1` correct there?

Sorry about this.

It's meant to be expressing a line number of "-1", but it looks like on your
system that DejaGnu/Tcl is picking that up as an option to a regexp.

Works for me (on x86_64-pc-linux-gnu) with the following:
  dejagnu-1.5.2-1.fc20.noarch
  expect-5.45-10.fc20.x86_64
  tcl-8.5.14-1.fc20.x86_64
where I get:
  PASS: gcc.dg/pr89410-1.c  (test for warnings, line -1)
  PASS: gcc.dg/pr89410-2.c  (test for warnings, line -1)
for such directives.

[Bug tree-optimization/89479] __restrict on a pointer ignored when a function is passed alongside it

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de  ---
On Tue, 26 Feb 2019, eyalroz at technion dot ac.il wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89479
> 
> --- Comment #5 from Eyal Rozenberg  ---
> (In reply to Richard Biener from comment #4)
> > exposing __restrict to the IL). 
> 
> Is "IL" an acronym for "Intermediate Language"? Remember many bug
> posters/readers are not GCC developers and don't know all the lingo.

Yes.

> > To elaborate further to successfully mark a function call
> > with clique == 1 and base == 0 we have to prove the pointer marked restrict
> > doesn't escape the function through calls
> 
> Certainly, calling g() could be just the same as writing to an alias of the x
> pointer. But - __restrict is how we guarantee this doesn't happen (or can be
> ignored) even when the compiler can't prove that's the case on its own. So I'm
> not sure I understand what you're suggesting with your comment. I suppose you
> could try and "disprove the __restrict" to give a warning, but other than that
> - why not just respect it?

Well, "respecting" it means encoding it in the intermediate language
which we don't at the moment for calls.

[Bug c++/71446] Incorrect overload resolution when using designated initializers

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-26
 Ever confirmed|0   |1

--- Comment #8 from Jonathan Wakely  ---
I'm confirming this as a bug. If we claim to support the extension we should
make it behave sensibly, and we need to fix it for C++2a anyway.

[Bug tree-optimization/89505] [8/7 Regression] LibreOffice miscompilation starting with r260383

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P1  |P2
  Known to work||9.0
   Target Milestone|9.0 |7.5
Summary|[9 Regression] LibreOffice  |[8/7 Regression]
   |miscompilation starting |LibreOffice miscompilation
   |with r260383|starting with r260383

--- Comment #6 from Richard Biener  ---
Fixed on trunk sofar, the reduced testcase also fails on branches.

[Bug tree-optimization/89505] [9 Regression] LibreOffice miscompilation starting with r260383

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Tue Feb 26 14:09:19 2019
New Revision: 269212

URL: https://gcc.gnu.org/viewcvs?rev=269212&root=gcc&view=rev
Log:
2019-02-26  Richard Biener  

PR tree-optimization/89505
* tree-ssa-structalias.c (compute_dependence_clique): Make sure
to handle restrict pointed-to vars with multiple subvars
correctly.

* gcc.dg/torture/pr89505.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr89505.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-structalias.c

[Bug tree-optimization/89509] New: restrict doesnt work with subfield accesses

[rguenth at gcc dot gnu.org]

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

Bug ID: 89509
   Summary: restrict doesnt work with subfield accesses
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

struct S { int i; void *p; int j; };
int
foo (struct S * __restrict p, int *q, int flag)
{
  int *x = &p->j;
  if (flag)
x = &p->i;
  *q = 1;
  *x = 2;
  return *q;
}

Is not optimized to return 1.  This is the missed-optimization part of
PR89505.

[Bug tree-optimization/89509] restrict doesnt work with subfield accesses

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-02-26
 Blocks||49774
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I have a patch (for GCC 10).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49774
[Bug 49774] [meta-bug] restrict qualification aliasing issues

[Bug c++/71446] Incorrect overload resolution when using designated initializers

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
So, shall we never try ck_list conversion for CONSTRUCTORs with any designators
(while for -std=c++2a we'll complain if there is a mix of designated
initializer clauses and non-designated initializ clauses, I think we don't
diagnose that earlier, so maybe we need to cache it in some CONSTRUCTOR flag?),
or never any conversion but ck_aggr?

[Bug c/89410] [7/8 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1237 after #line

[tnfchris at gcc dot gnu.org]

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

--- Comment #19 from Tamar Christina  ---
Hmm we're running it on 

Tcl: 8.5
Expect: 5.45
Dejagnu: 1.5.1

So I think those are about the same..

合e法N经O营u

[jrxo]

办PP 
 
理  $   +Q+V+信#%
  --
&   $  -- I 3 4
髮  $---  2 4 3 4  
&   $  ---6 1 4 8
漂 $  
 -2019/2/26

[Bug c++/89481] constexpr function allows writing one active union member and reading another

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Tue Feb 26 14:37:39 2019
New Revision: 269213

URL: https://gcc.gnu.org/viewcvs?rev=269213&root=gcc&view=rev
Log:
PR c++/89481
* constexpr.c (cxx_eval_store_expression): When changing active union
member, set no_zero_init.

* g++.dg/cpp1y/constexpr-89481.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-89481.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/89481] constexpr function allows writing one active union member and reading another

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Fixed for GCC 9+.

[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails

[ian at gcc dot gnu.org]

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

--- Comment #14 from ian at gcc dot gnu.org  ---
Author: ian
Date: Tue Feb 26 14:46:56 2019
New Revision: 269214

URL: https://gcc.gnu.org/viewcvs?rev=269214&root=gcc&view=rev
Log:
PR go/86535
runtime: always declare nanotime in Go

For libgo it's always defined in C.

Updates https://gcc.gnu.org/PR86535

Reviewed-on: https://go-review.googlesource.com/c/163743

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/libgo/go/runtime/stubs3.go

[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails

[ian at airs dot com]

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

--- Comment #15 from Ian Lance Taylor  ---
I committed a patch that should fix the nanotime problem.

Some of the other issues you describe will most likely require a fix in the
libgo/mkrsysinfo.sh script, which generates the file runtime_sysinfo.go.  For
example, that is likely the problem with _CTL_HW and _HW_PAGESIZE.

For sysctl we'll need a declaration with a //extern comment.

I'm happy to advise but I don't realistically have the time to do the work
myself.

[Bug target/89482] arm aarch32 inline assembly w constraints generate s registers instead of d

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from ktkachov at gcc dot gnu.org ---
Right. So when dealing with double-precision values you should use the %P
output modifier like so:
double my_double = 1.5;
__asm__ (
"vmov.f64 d0, 1.0;"
"vadd.f64 %P[my_double], %P[my_double], d0;"
: [my_double] "+w" (my_double)
:
: "d0"
);

This will print the right D-form of the VFP register allocated.
The documentation for this could, admittedly be improved
(https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html). I believe someone is
working on that currently.

[Bug rtl-optimization/89490] [9 Regression] char array constant put in string merge section

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
I think there is a serious flaw that the section anchor infrastructure is used
at all for the SECTION_MERGE sections, one really must not use any kind of
section anchors for those sections, there is no guarantees that the layout made
by the compiler will match what the linker will do in the end (between
different objects in the section that is, within a single object it has to
stay).

If that isn't done and we for some strange reason must still go through the
block stuff, I think we should do for something like following, where we'll
account for the artificially added trailing zeros.

--- gcc/varasm.c.jj 2019-02-22 09:30:19.133180850 +0100
+++ gcc/varasm.c2019-02-26 16:42:11.699848053 +0100
@@ -7452,7 +7452,7 @@ place_block_symbol (rtx symbol)
   struct constant_descriptor_rtx *desc;
   unsigned int alignment;
   struct object_block *block;
-  tree decl;
+  tree decl = NULL_TREE;

   gcc_assert (SYMBOL_REF_BLOCK (symbol));
   if (SYMBOL_REF_BLOCK_OFFSET (symbol) >= 0)
@@ -7511,6 +7511,20 @@ place_block_symbol (rtx symbol)

   /* Calculate the object's offset from the start of the block.  */
   block = SYMBOL_REF_BLOCK (symbol);
+  if ((block->sect->common.flags & SECTION_MERGE)
+  && (block->sect->common.flags & SECTION_STRINGS)
+  && decl
+  && DECL_INITIAL (decl)
+  && TREE_CODE (DECL_INITIAL (decl)) == STRING_CST)
+{
+  tree str = DECL_INITIAL (decl);
+  unsigned HOST_WIDE_INT thissize = TREE_STRING_LENGTH (str);
+  if ((thissize == 0
+  || TREE_STRING_POINTER (str) [thissize - 1] != '\0')
+ && size == thissize)
+   size++;
+}
+
   mask = alignment / BITS_PER_UNIT - 1;
   offset = (block->size + mask) & ~mask;
   SYMBOL_REF_BLOCK_OFFSET (symbol) = offset;
@@ -7639,6 +7653,8 @@ output_object_block (struct object_block

   /* Output the objects themselves.  */
   offset = 0;
+  bool merge_strings = ((block->sect->common.flags & SECTION_MERGE)
+   && (block->sect->common.flags & SECTION_STRINGS));
   FOR_EACH_VEC_ELT (*block->objects, i, symbol)
 {
   /* Move to the object's offset, padding with zeros if necessary.  */
@@ -7657,9 +7673,18 @@ output_object_block (struct object_block
  HOST_WIDE_INT size;
  decl = SYMBOL_REF_DECL (symbol);
  assemble_constant_contents (DECL_INITIAL (decl), XSTR (symbol, 0),
- DECL_ALIGN (decl), false);
+ DECL_ALIGN (decl), merge_strings);

  size = get_constant_size (DECL_INITIAL (decl));
+ if (merge_strings
+ && TREE_CODE (DECL_INITIAL (decl)) == STRING_CST)
+   {
+ tree str = DECL_INITIAL (decl);
+ HOST_WIDE_INT thissize = TREE_STRING_LENGTH (str);
+ if (thissize == 0
+ || TREE_STRING_POINTER (str) [thissize - 1] != '\0')
+   size = MAX (size, thissize + 1);
+   }
  offset += size;
  if ((flag_sanitize & SANITIZE_ADDRESS)
  && TREE_CODE (DECL_INITIAL (decl)) == STRING_CST
@@ -7674,8 +7699,18 @@ output_object_block (struct object_block
{
  HOST_WIDE_INT size;
  decl = SYMBOL_REF_DECL (symbol);
- assemble_variable_contents (decl, XSTR (symbol, 0), false, false);
+ assemble_variable_contents (decl, XSTR (symbol, 0), false,
+ merge_strings);
  size = tree_to_uhwi (DECL_SIZE_UNIT (decl));
+ if (merge_strings
+ && TREE_CODE (DECL_INITIAL (decl)) == STRING_CST)
+   {
+ tree str = DECL_INITIAL (decl);
+ HOST_WIDE_INT thissize = TREE_STRING_LENGTH (str);
+ if (thissize == 0
+ || TREE_STRING_POINTER (str) [thissize - 1] != '\0')
+   size = MAX (size, thissize + 1);
+   }
  offset += size;
  if ((flag_sanitize & SANITIZE_ADDRESS)
  && asan_protect_global (decl))

[Bug target/89506] [7/8/9 Regression] ICE: in decompose, at rtl.h:2266 with -Og -g

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/89507] [9 Regression] bogus "size of array exceeds maximum object size"

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
   Priority|P3  |P1
 Blocks||87996
   Target Milestone|--- |9.0
Summary|bogus "size of array|[9 Regression] bogus "size
   |exceeds maximum object  |of array exceeds maximum
   |size"   |object size"


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87996
[Bug 87996] [8 Regression] "size of array is negative" error when SIZE_MAX/2 <
sizeof(array) <= SIZE_MAX

[Bug tree-optimization/89509] restrict doesnt work with subfield accesses

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Created attachment 45827
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45827&action=edit
the patch

[Bug rtl-optimization/89490] [9 Regression] char array constant put in string merge section

[bernd.edlinger at hotmail dot de]

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

--- Comment #11 from Bernd Edlinger  ---
I agree, that it would be better to not put any
mergeable things in a block object.  If section anchors
are ever used on a string constant, it is going to fail.

A constant with size = 0 is possible, for instance
in Ada an empty string really empty.  These should not
go into mergeable sections.  output_constant
ignores the merge_strings parameter, therefore
I would not assume there is a zero termination


Instead of:

  if (thissize == 0
  || TREE_STRING_POINTER (str) [thissize - 1] != '\0')
size = MAX (size, thissize + 1);

maybe:

  if (thissize != 0
  && TREE_STRING_POINTER (str) [thissize - 1] != '\0')
size = MAX (size, thissize + 1);

[Bug rtl-optimization/89490] [9 Regression] char array constant put in string merge section

[bernd.edlinger at hotmail dot de]

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

--- Comment #12 from Bernd Edlinger  ---
> These should not go into mergeable sections.

I mean: These do not go into mergeable sections.

[Bug rtl-optimization/89490] [9 Regression] char array constant put in string merge section

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
(In reply to Bernd Edlinger from comment #11)
> Instead of:
> 
> if (thissize == 0
> || TREE_STRING_POINTER (str) [thissize - 1] != '\0')
>   size = MAX (size, thissize + 1);
> 
> maybe:
> 
> if (thissize != 0
> && TREE_STRING_POINTER (str) [thissize - 1] != '\0')
>   size = MAX (size, thissize + 1);

Well, it matches what output_constant does:
case STRING_CST:
  thissize = (unsigned HOST_WIDE_INT)TREE_STRING_LENGTH (exp);
  if (merge_strings
  && (thissize == 0
  || TREE_STRING_POINTER (exp) [thissize - 1] != '\0'))
thissize++;
(using MAX just in case there is already some extra padding in the length or
whatever else).

[Bug middle-end/89501] Odd lack of warning about missing initialization

[torva...@linux-foundation.org]

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

--- Comment #6 from Linus Torvalds  ---
(In reply to Richard Biener from comment #5)
> 
> And this meeting helps us avoid bogus warnings for cases where GCC has
> difficulties proving dead code paths are actually dead ... 

Ack. I do see the difficulty. We already disable some of the
"may-be-uninitialized" warnings in the kernel because they end up being too
noisy for some configurations.

NP. If you guys figure something out, it will be good. If not, we'll survive.

[Bug middle-end/89501] Odd lack of warning about missing initialization

[law at redhat dot com]

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

--- Comment #7 from Jeffrey A. Law  ---
It's reliably the case that a false positive uninit warning also represents a
failure to optimize something.  So we've got significant incentives to deeply
analyze and look for fixes.  So feel free to pass examples of those along.

[Bug libstdc++/89416] [9 regression] std::vector::push_back no longer builds.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #7 from Jonathan Wakely  ---
Sigh, I tested with clang but using std::allocator, which is handled by a
partial specialization. It's still broken with clang.

[Bug c++/89507] [9 Regression] bogus "size of array exceeds maximum object size"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
valid_constant_size_p assumes it is sizetype/ssizetype constant, but in this
case we check it before converting it to sizetype.  Checking now if it is just
one spot or if there aren't others.