[Bug target/87928] [7/8/9 Regression] ICE in ix86_compute_frame_layout, at config/i386/i386.c:11161 since r228607

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
One more similar back-trace:

$ gcc
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/x86_64/abi/callabi/func-1.c
-Ofast -mcall-ms2sysv-xlogues -mandroid -mavx512vpopcntdq
during RTL pass: reload
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/x86_64/abi/callabi/func-1.c:
In function ‘func_cross’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/x86_64/abi/callabi/func-1.c:20:1:
internal compiler error: in ix86_compute_frame_layout, at
config/i386/i386.c:11169
   20 | }
  | ^
0x73bae0 ix86_compute_frame_layout
/home/marxin/Programming/gcc/gcc/config/i386/i386.c:11169
0xc268af update_reg_eliminate
/home/marxin/Programming/gcc/gcc/lra-eliminations.c:1207
0xc28f97 lra_eliminate(bool, bool)
/home/marxin/Programming/gcc/gcc/lra-eliminations.c:1460
0xc2058a lra_constraints(bool)
/home/marxin/Programming/gcc/gcc/lra-constraints.c:4716
0xc0d2a0 lra(_IO_FILE*)
/home/marxin/Programming/gcc/gcc/lra.c:2446
0xbbe87c do_reload
/home/marxin/Programming/gcc/gcc/ira.c:5469
0xbbe87c execute
/home/marxin/Programming/gcc/gcc/ira.c:5653

[Bug target/87928] New: ICE in ix86_compute_frame_layout, at config/i386/i386.c:11161 since r228607

[marxin at gcc dot gnu.org]

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

Bug ID: 87928
   Summary: ICE in ix86_compute_frame_layout, at
config/i386/i386.c:11161 since r228607
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Following causes ICE:

$ gcc
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/aggregate-ret4.c
-mabi=ms -O1 -mstackrealign
during RTL pass: pro_and_epilogue
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/aggregate-ret4.c: In
function ‘bar’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/aggregate-ret4.c:24:1:
internal compiler error: in ix86_compute_frame_layout, at
config/i386/i386.c:11161
   24 | }
  | ^
0x73ba80 ix86_compute_frame_layout
/home/marxin/Programming/gcc/gcc/config/i386/i386.c:11161
0x111ef6f ix86_finalize_stack_frame_flags
/home/marxin/Programming/gcc/gcc/config/i386/i386.c:12925
0x11255e4 ix86_expand_prologue()
/home/marxin/Programming/gcc/gcc/config/i386/i386.c:13035
0x145df8a gen_prologue()
/home/marxin/Programming/gcc/gcc/config/i386/i386.md:12984
0x1107728 target_gen_prologue
/home/marxin/Programming/gcc/gcc/config/i386/i386.md:18928
0xab61c1 make_prologue_seq
/home/marxin/Programming/gcc/gcc/function.c:5713
0xab6367 thread_prologue_and_epilogue_insns()
/home/marxin/Programming/gcc/gcc/function.c:5830
0xab6a96 rest_of_handle_thread_prologue_and_epilogue
/home/marxin/Programming/gcc/gcc/function.c:6321
0xab6a96 execute
/home/marxin/Programming/gcc/gcc/function.c:6363

[Bug rtl-optimization/86438] [8/9 Regression] wrong code at -Os

[aoliva at gcc dot gnu.org]

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

--- Comment #5 from Alexandre Oliva  ---
The candidate patch regresses the regression test added along with the fix for
bug 49095.  At first I thought it should, but there seems to be logic in place
to adjust the compare for the flags-clobbering insn.

[Bug sanitizer/81902] new -fsanitize=pointer-overflow option undocumented

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||sandra at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from sandra at gcc dot gnu.org ---
Closing this issue as it has been fixed.

[Bug sanitizer/80998] Implement -fsanitize=pointer-overflow

[sandra at gcc dot gnu.org]

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

Bug 81902 Summary: new -fsanitize=pointer-overflow option undocumented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81902

   What|Removed |Added

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

[Bug middle-end/42726] -fno-common documentation inaccuracy

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||sandra at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #2 from sandra at gcc dot gnu.org ---
This has (finally) been fixed on trunk.

[Bug rtl-optimization/86438] [8/9 Regression] wrong code at -Os

[aoliva at gcc dot gnu.org]

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

--- Comment #4 from Alexandre Oliva  ---
Created attachment 44970
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44970=edit
candidate patch

[Bug middle-end/42726] -fno-common documentation inaccuracy

[sandra at gcc dot gnu.org]

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

--- Comment #1 from sandra at gcc dot gnu.org ---
Author: sandra
Date: Thu Nov  8 03:37:32 2018
New Revision: 265906

URL: https://gcc.gnu.org/viewcvs?rev=265906=gcc=rev
Log:
2018-11-07  Sandra Loosemore  

PR middle-end/42726

gcc/
* doc/invoke.texi (Code Gen Options): Clarify -fno-common behavior.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/invoke.texi

[Bug rtl-optimization/86438] [8/9 Regression] wrong code at -Os

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #3 from Alexandre Oliva  ---
Mine

[Bug driver/80828] Command line option -e not documented

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||sandra at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from sandra at gcc dot gnu.org ---
Documentation for this option has been added on trunk.

There are several driver options, including this one, that don't include any
documentation for the --help output.  I'm not sure if that was deliberate or
not, but if it's a problem, it would be worth doing a review to see what else
is missing.

[Bug target/87927] ICE: segmentation fault with patchable_function_entry attribute for msp430-elf -mlarge

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
Patches should be sent to gcc-patches@ after reading
https://gcc.gnu.org/contribute.html .

[Bug driver/80828] Command line option -e not documented

[sandra at gcc dot gnu.org]

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

--- Comment #2 from sandra at gcc dot gnu.org ---
Author: sandra
Date: Thu Nov  8 01:26:28 2018
New Revision: 265903

URL: https://gcc.gnu.org/viewcvs?rev=265903=gcc=rev
Log:
2018-11-07  Sandra Loosemore  

PR driver/80828

gcc/
* doc/invoke.texi (Option Summary): Add -e and --entry.
(Link Options): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/invoke.texi

[Bug c/87927] ICE: segmentation fault with patchable_function_entry attribute for msp430-elf -mlarge

[jozef.l at mittosystems dot com]

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

Jozef Lawrynowicz  changed:

   What|Removed |Added

  Attachment #44968|0   |1
is obsolete||

--- Comment #2 from Jozef Lawrynowicz  ---
Created attachment 44969
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44969=edit
proposed patch (fixed)

Fixed wrong ordering of new elements in "struct asm_int_op"

[Bug target/87690] [RISCV][ABI] GCC fails to sign-extend floats passed in the lp64 ABI

[wilson at gcc dot gnu.org]

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

Jim Wilson  changed:

   What|Removed |Added

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

--- Comment #7 from Jim Wilson  ---
The proposed psABI change was accepted, so no gcc change is necessary.

[Bug c/87927] ICE: segmentation fault with patchable_function_entry attribute for msp430-elf -mlarge

[jozef.l at mittosystems dot com]

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

--- Comment #1 from Jozef Lawrynowicz  ---
Created attachment 44968
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44968=edit
proposed patch

In default_print_patchable_function_entry, integer_asm_op is passed
POINTER_SIZE_UNITS. For msp430-elf -mlarge, this is 3, which is not handled in
integer_asm_op, so it returns NULL.
fputs is directly writing out the return value of integer_asm_op, so when this
is NULL we are segfaulting.

Attached is a proposed patch which implements
TARGET_ASM_{,UN}ALIGNED_P{S,D,T}I_OP, so integer_asm_op will not return NULL
for values < 16.

This fixes the c-c++-common/patchable_function_entry* tests but is otherwise
untested.

[Bug c/87927] New: ICE: segmentation fault with patchable_function_entry attribute for msp430-elf -mlarge

[jozef.l at mittosystems dot com]

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

Bug ID: 87927
   Summary: ICE: segmentation fault with patchable_function_entry
attribute for msp430-elf -mlarge
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jozef.l at mittosystems dot com
  Target Milestone: ---

Use of the patchable_function_entry attribute with msp430-elf in the large
memory model causes a segfault on trunk.

For example in c-c++-common/patchable_function_entry-decl.c:

> extern int a;
> 
> int f3 (void) __attribute__((patchable_function_entry(2)));
> 
> int
> __attribute__((noinline))
> f3 (void)
> {
>   return 5*a;
> }

> gcc -mlarge -fpatchable-function-entry=3,1 -S 
> gcc/testsuite/c-c++-common/patchable_function_entry-decl.c

> gcc/testsuite/c-c++-common/patchable_function_entry-decl.c: In function 'f3':
> gcc/testsuite/c-c++-common/patchable_function_entry-decl.c:18:1: internal 
> compiler error: Segmentation fault
> 0xb5e4af crash_signal
>   ../../gcc/toplev.c:325
> 0xb59d41 default_print_patchable_function_entry(_IO_FILE*, unsigned long, 
> bool)
>   ../../gcc/targhooks.c:1816
> 0xe94d2c assemble_start_function(tree_node*, char const*)
>   ../../gcc/varasm.c:1903
> 0x84188f rest_of_handle_final
>   ../../gcc/final.c:4645
> 0x84188f execute
>   ../../gcc/final.c:4723

[Bug c++/79393] [7/8/9 Regression] cc1plus rejects valid code with noexcept

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|SUSPENDED   |ASSIGNED

--- Comment #11 from Nathan Sidwell  ---
Is 2336 now has a proposed solution.

[Bug tree-optimization/87926] bad array-index warning breaks --disable-checking bootstrap

[nathan at gcc dot gnu.org]

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

--- Comment #1 from Nathan Sidwell  ---
Author: nathan
Date: Wed Nov  7 22:50:20 2018
New Revision: 265899

URL: https://gcc.gnu.org/viewcvs?rev=265899=gcc=rev
Log:
[PR/87936] --disable-checking bootstrap break

https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00502.html
PR 87926
* Makefile.in (bitmap.o-warn): Add -Wno-error to unbreak
--disable-checking bootstrap.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in

[Bug tree-optimization/87926] New: bad array-index warning breaks --disable-checking bootstrap

[nathan at gcc dot gnu.org]

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

Bug ID: 87926
   Summary: bad array-index warning breaks --disable-checking
bootstrap
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nathan at gcc dot gnu.org
  Target Milestone: ---

Created attachment 44967
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44967=edit
cc1plus bug.ii -O2 -W -Wall -quiet

x86_64-linux --disable-checking bootstrap fails with:
../../../src/gcc/bitmap.c: In function ‘unsigned int
bitmap_last_set_bit(const_bitmap)’:
../../../src/gcc/bitmap.c:1191:26: error: array subscript -1 is below array
bounds of ‘const BITMAP_WORD [2]’ {aka ‘const long unsigned int [2]’}
[-Werror=array-bounds]
  1191 |   word = elt->bits[ix];
   |  ^

Attached is a reduced testcase

Adding:
bitmap.o-warn = -Wno-error
to gcc/Makefile.in works around the problem.

[Bug rtl-optimization/87925] Missed optimization: Distinct-value if-then-else chains treated differently than switch statements

[eyalroz at technion dot ac.il]

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

Eyal Rozenberg  changed:

   What|Removed |Added

Version|unknown |9.0

--- Comment #1 from Eyal Rozenberg  ---
See also: 
https://stackoverflow.com/questions/53198276/do-compilers-optimize-switches-differently-than-long-if-then-else-chains

[Bug rtl-optimization/87925] New: Missed optimization: Single-value if-then-else chains treated differently than switch'es

[eyalroz at technion dot ac.il]

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

Bug ID: 87925
   Summary: Missed optimization: Single-value if-then-else chains
treated differently than switch'es
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eyalroz at technion dot ac.il
  Target Milestone: ---

Have a look at this GodBolt example: https://gcc.godbolt.org/z/zR03rA

On one hand, we have:

void foo(int i) {
switch (i) {
case 1: boo<1>(); break;
case 2: boo<2>(); break;
case 3: boo<3>(); break;
case 4: boo<4>(); break;
// etc. etc.
}
}

on the other hand we have the same, but using an if-then-else chain:

void bar(int i) {
if  (i == 1) boo<1>();
else if (i == 2) boo<2>();
else if (i == 3) boo<3>();
else if (i == 4) boo<4>();
// etc. etc.
}

The switch statement gets a jump table; the if-then-else chain - does not. At
the link, there are 20 cases; g++ starts using a jump table with 4 switch
values.

This is not just a matter of programmers needing to remember to prefer switch
statements (which it's better not to require of them), but rather that
if-then-else chains are sometimes generated by expansion of templated code,
e.g. this example for checking for membership in a set of values (= all values
of an enum):

https://stackoverflow.com/a/53191264/1593077

while switch() statements of variable do not get generated AFAICT. It would
thus be quite useful if such generated code would not result in
highly-inefficient long chains of comparisons.

[Bug c/87691] transparent_union attribute does not work with MODE_PARTIAL_INT

[jozefl at gcc dot gnu.org]

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

--- Comment #10 from jozefl at gcc dot gnu.org ---
Author: jozefl
Date: Wed Nov  7 22:06:26 2018
New Revision: 265894

URL: https://gcc.gnu.org/viewcvs?rev=265894=gcc=rev
Log:
2018-11-07  Jozef Lawrynowicz  

PR c/87691

gcc/ChangeLog:
* stor-layout.c (compute_record_mode): Set TYPE_MODE of UNION_TYPE
to the mode of the widest field iff the widest field has mode class
MODE_INT, or MODE_PARTIAL_INT and the union would be passed by
reference.

gcc/testsuite/ChangeLog:
* gcc.target/msp430/pr87691.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/msp430/pr87691.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/stor-layout.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/87919] Incorrect fortran handling of -fno-* options

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
The -fdec-structure part has been posted in
https://gcc.gnu.org/ml/fortran/2018-11/msg00029.html

[Bug fortran/85982] ICE in resolve_component, at fortran/resolve.c:13696

[foreese at gcc dot gnu.org]

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

Fritz Reese  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Last reconfirmed|2018-05-31 00:00:00 |2018-11-7
   Assignee|unassigned at gcc dot gnu.org  |foreese at gcc dot 
gnu.org
  Known to fail||6.4.0, 9.0

[Bug fortran/87919] Incorrect fortran handling of -fno-* options

[foreese at gcc dot gnu.org]

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

Fritz Reese  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-07
 CC||foreese at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |foreese at gcc dot 
gnu.org
   Target Milestone|--- |7.4
 Ever confirmed|0   |1

[Bug middle-end/87854] [9 Regression] gcc.c-torture/compile/pr46534.c ICE for 16-bit size_t

[gjl at gcc dot gnu.org]

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

--- Comment #1 from Georg-Johann Lay  ---
(In reply to Jozef Lawrynowicz from comment #0)
> Rather than ICE'ing should there be some error message about object size
> being too large?

Yes.  In any case, there should be no ICE whatever code you provide.

[Bug middle-end/78707] [6 Regression] internal compiler error: in push_reload, at reload.c:1349

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|6.5 |7.0

--- Comment #4 from Jakub Jelinek  ---
Thus fixed in 7.x.

[Bug other/56183] [meta-bug][avr] Problems with register allocation

[jakub at gcc dot gnu.org]

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

Bug 78707 Summary: [6 Regression] internal compiler error: in push_reload, at 
reload.c:1349
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78707

   What|Removed |Added

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

[Bug middle-end/78707] [6 Regression] internal compiler error: in push_reload, at reload.c:1349

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

  Known to work||7.1.1, 8.0.1

--- Comment #3 from Georg-Johann Lay  ---
(In reply to Jakub Jelinek from comment #2)
> Does this fail also with 7.x and later?

The test case passes fine for me with 7.1.1 and 8.0.1.

[Bug fortran/87922] ICE in gfc_wide_strlen, at fortran/scanner.c:142

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-07
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
Index: gcc/fortran/io.c
===
--- gcc/fortran/io.c(revision 265885)
+++ gcc/fortran/io.c(working copy)
@@ -2232,6 +2232,21 @@ gfc_match_open (void)
   if (!is_char_type ("ASYNCHRONOUS", open->asynchronous))
goto cleanup;

+  if (open->asynchronous->ts.kind != 1)
+   {
+ gfc_error ("ASYNCHRONOUS= specifier at %L must have be of default "
+"CHARACTER kind", >asynchronous->where);
+ return MATCH_ERROR;
+   }
+
+  if (open->asynchronous->expr_type == EXPR_ARRAY
+ || open->asynchronous->expr_type == EXPR_STRUCTURE)
+   {
+ gfc_error ("ASYNCHRONOUS= specifier at %L must have be scalar",
+>asynchronous->where);
+ return MATCH_ERROR;
+   }
+
   if (open->asynchronous->expr_type == EXPR_CONSTANT)
{
  static const char * asynchronous[] = { "YES", "NO", NULL };
@@ -3792,6 +3807,21 @@ if (condition) \

   if (!is_char_type ("ASYNCHRONOUS", dt->asynchronous))
return MATCH_ERROR;
+
+  if (dt->asynchronous->ts.kind != 1)
+   {
+ gfc_error ("ASYNCHRONOUS= specifier at %L must have be of default "
+"CHARACTER kind", >asynchronous->where);
+ return MATCH_ERROR;
+   }
+
+  if (dt->asynchronous->expr_type == EXPR_ARRAY
+ || dt->asynchronous->expr_type == EXPR_STRUCTURE)
+   {
+ gfc_error ("ASYNCHRONOUS= specifier at %L must have be scalar",
+>asynchronous->where);
+ return MATCH_ERROR;
+   }

   if (!compare_to_allowed_values
("ASYNCHRONOUS", asynchronous, NULL, NULL,

[Bug c++/69348] alias declarations can not be used inside qualifiers of declarators

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-07
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug c/87924] New: OpenACC wait clauses without async-arguments

[tschwinge at gcc dot gnu.org]

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

Bug ID: 87924
   Summary: OpenACC wait clauses without async-arguments
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: openacc, patch
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

As reported in ,
we're currently not taking any action for OpenACC wait clauses without
async-arguments.

[Bug c++/87921] [7/8/9 Regression] Incorrect error "storage size of [array] isn't known (when it is)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Target Milestone|--- |7.4
Summary|Incorrect error "storage|[7/8/9 Regression]
   |size of [array] isn't known |Incorrect error "storage
   |(when it is)|size of [array] isn't known
   ||(when it is)

[Bug c++/87921] Incorrect error "storage size of [array] isn't known (when it is)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-07
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Probably started with r241143.

[Bug gcov-profile/87442] Add options to filter files we want to instrument for code coverage

[cdenizet at mozilla dot com]

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

--- Comment #9 from calixte  ---
(In reply to Martin Liška from comment #8)
> Ok, I've got a patch prototype and I hope I'll be able to sent it before
> the end of this stage1.
> 
> > The idea is to add two options to easily include/exclude some files from
> > being instrumented.
> > Here are two use cases:
> >  1) -coverage-exclude=/usr/include/*: typically we remove the data for such
> > files when post-processing the gcno/gcda so we don't need to instrument them
> > and so we could reduce the overhead due to instrumentation.
> >  2) -coverage-filter=.*/foo.cpp:.*/bar.cpp: here we want to only instrument
> > these two files (for example, to display code coverage data for files
> > appearing in a patch at review phase)
> 
> However, calixte can you please explain me difference in between those two
> options.
> More precisely, one is a white list and the second one is a black list. Will
> you
> mix these together or they will be used exclusively?

Few things:
 i) I use ';' as regex separator (to avoid issues under windows with C:\...)
 ii) if exclude is empty and filename is matching any of the regexes in filter
then instrument it.
 iii) if filter is empty and filename is not matching any of the regexes in
exclude then instrument it.
 iv) if both are not empty and filename is matching any of the regexes in
filter AND is not matching any of the regexes in exclude then instrument it. 

Few examples:
 i) exclude="^/usr/include/;^/usr/local/include/" => a file is instrumented if
and only if it isn't in /usr/include/ nor in /usr/local/include/
 ii) filter="^/home/foo/dev/.*\.cpp;^/home/foo/ved/.*\.cpp" => a file is
instrumented if and only if it's a cpp file somewhere under /home/foo/dev/ or
/home/foo/ved/
 iii) exclude="^/usr/include/.*$" and filter="^/usr/.*$" => a file is
instrumented if and only if it's somewhere under /usr/ but not under
/usr/include

My patch for llvm is here:
https://reviews.llvm.org/D52033

If you see something wrong or have idea to improve, please ping me.

[Bug fortran/87923] New: ICE in gfc_widechar_to_char, at fortran/scanner.c:198

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

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

Bug ID: 87923
   Summary: ICE in gfc_widechar_to_char, at fortran/scanner.c:198
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With option -fdec and versions 7 to 9 :


$ cat z1.f90
program p
   open (1, carriagecontrol=char(1000,4))
   open (2, share=char(1000,4))
end


$ gfortran-9-20181104 -c z1.f90 -fdec
f951: internal compiler error: in gfc_widechar_to_char, at
fortran/scanner.c:198
0x694556 gfc_widechar_to_char(unsigned int const*, int)
../../gcc/fortran/scanner.c:198
0x638784 compare_to_allowed_values
../../gcc/fortran/io.c:2091
0x63dcd0 gfc_match_open()
../../gcc/fortran/io.c:2276
0x66a3c1 match_word
../../gcc/fortran/parse.c:65
0x66e335 decode_statement
../../gcc/fortran/parse.c:531
0x66e72a next_free
../../gcc/fortran/parse.c:1234
0x66e72a next_statement
../../gcc/fortran/parse.c:1466
0x670a94 parse_spec
../../gcc/fortran/parse.c:3674
0x672807 parse_progunit
../../gcc/fortran/parse.c:5671
0x673e89 gfc_parse_file()
../../gcc/fortran/parse.c:6211
0x6bc03f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/87922] New: ICE in gfc_wide_strlen, at fortran/scanner.c:142

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

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

Bug ID: 87922
   Summary: ICE in gfc_wide_strlen, at fortran/scanner.c:142
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With a non-scalar-default-char-constant-expr since at least gfortran-5 :


$ cat z1.f90
program p
   read (1, asynchronous=['no'])
   read (1, asynchronous=[character::])
end

$ cat z2.f90
program p
   write (1, asynchronous=['no'])
   write (1, asynchronous=[character::])
end


$ gfortran-9-20181104 -c z1.f90
f951: internal compiler error: Segmentation fault
0xb205df crash_signal
../../gcc/toplev.c:325
0x694450 gfc_wide_strlen(unsigned int const*)
../../gcc/fortran/scanner.c:142
0x638587 compare_to_allowed_values
../../gcc/fortran/io.c:2008
0x63b7ca check_io_constraints
../../gcc/fortran/io.c:3797
0x63b7ca match_io
../../gcc/fortran/io.c:4301
0x66a3c1 match_word
../../gcc/fortran/parse.c:65
0x66e1a0 decode_statement
../../gcc/fortran/parse.c:549
0x66e72a next_free
../../gcc/fortran/parse.c:1234
0x66e72a next_statement
../../gcc/fortran/parse.c:1466
0x670a94 parse_spec
../../gcc/fortran/parse.c:3674
0x672807 parse_progunit
../../gcc/fortran/parse.c:5671
0x673e89 gfc_parse_file()
../../gcc/fortran/parse.c:6211
0x6bc03f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/69654] ICE in gfc_trans_structure_assign

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

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

G. Steinmetz  changed:

   What|Removed |Added

 CC||gs...@t-online.de

--- Comment #6 from G. Steinmetz  ---

Update, reduced a bit :


$ cat z1.f90
module m
   type t
  class(*), pointer :: z => null()
   end type
end
program p
contains
   subroutine s1
  use m
  type(t) :: x
  call s2(x)
   end
   subroutine s2(x)
  use m
  type(t) :: x
   end
end


$ gfortran-9-20181104 -c z1.f90
z1.f90:12:0:

   12 |end
  |
internal compiler error: Segmentation fault
0xb205df crash_signal
../../gcc/toplev.c:325
0x6f3735 gfc_trans_structure_assign(tree_node*, gfc_expr*, bool, bool)
../../gcc/fortran/trans-expr.c:7814
0x6f3282 gfc_trans_subcomponent_assign
../../gcc/fortran/trans-expr.c:7659
0x6f375a gfc_trans_structure_assign(tree_node*, gfc_expr*, bool, bool)
../../gcc/fortran/trans-expr.c:7824
0x6edf0f gfc_conv_structure(gfc_se*, gfc_expr*, int)
../../gcc/fortran/trans-expr.c:7891
0x6ee14c gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:8059
0x6fc779 gfc_trans_assignment_1
../../gcc/fortran/trans-expr.c:10248
0x6dd90d gfc_init_default_dt(gfc_symbol*, stmtblock_t*, bool)
../../gcc/fortran/trans-decl.c:4067
0x6e4f30 gfc_trans_deferred_vars(gfc_symbol*, gfc_wrapped_block*)
../../gcc/fortran/trans-decl.c:4792
0x6e6ef8 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6614
0x6e6c14 gfc_generate_contained_functions
../../gcc/fortran/trans-decl.c:5524
0x6e6c14 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6441
0x6740a6 translate_all_program_units
../../gcc/fortran/parse.c:6125
0x6740a6 gfc_parse_file()
../../gcc/fortran/parse.c:6328
0x6bc03f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204


---

The ICE also goes away when all "use m" are moved to top level :

$ cat z7.f90
module m
   type t
  class(*), pointer :: z => null()
   end type
end
program p
   use m
   call s1
contains
   subroutine s1
  type(t) :: x
  call s2(x)
   end
   subroutine s2(x)
  type(t) :: x
   end
end

[Bug c++/87921] New: Incorrect error "storage size of [array] isn't known (when it is)

[cuzdav at gmail dot com]

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

Bug ID: 87921
   Summary: Incorrect error "storage size of [array] isn't known
(when it is)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cuzdav at gmail dot com
  Target Milestone: ---

I'm getting an error for what I believe to be valid code.  Here's a complete,
minimal example to reproduce it:

// 
template
struct X {
static constexpr long Ary[] = { 1L };
long foo() { return Ary[0]; }
};

void f() {
class L{};
X foo{};
}
// 
https://godbolt.org/z/2tGwxo

#1 with x86-64 gcc (trunk)
:3:27: error: storage size of 'X::Ary' isn't known
3  static constexpr long Ary[] = { 1L };
 ^~~
Clearly the size of the array should be known.

- locally, on both mac and linux I see same results
- in g++6.3, C++17 mode it compiles
- in 7.3 and all versions up through 8.2 and the trunk, in C++ 17 mode it does
not compile.
- in clang++, it compiles.
- moving the function-local class L to file-scope fixes it.
- moving the array outside of the template class fixes it.
- explicitly providing a size to the array declaration fixes it.

[Bug c++/87904] [9 Regression] ICE in lookup_mark, at cp/tree.c:2322 since r265679

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #2 from Nathan Sidwell  ---
Fixed r265879.

[Bug c++/87904] [9 Regression] ICE in lookup_mark, at cp/tree.c:2322 since r265679

[nathan at gcc dot gnu.org]

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

--- Comment #1 from Nathan Sidwell  ---
Author: nathan
Date: Wed Nov  7 16:28:46 2018
New Revision: 265879

URL: https://gcc.gnu.org/viewcvs?rev=265879=gcc=rev
Log:
[PR C++/87904] lookup ICE

https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00468.html
PR c++/87904
* cp-tree.h (struct tree_overload): Fix comment.
* tree.c (ovl_iterator::reveal_node): Propagate OVL_DEDUP_P.

PR c++/87904
* g++.dg/lookup/pr87904.C: New.

Added:
trunk/gcc/testsuite/g++.dg/lookup/pr87904.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog

[Bug ipa/86395] add support of -fopt-info-inline in inliner

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2018-11/msg00463.ht
   ||ml

--- Comment #4 from David Malcolm  ---
Candidate patches: https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00463.html

[Bug c/66298] -Wmisleading-indentation should also detect missing indentation

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
I believe there is no general consistency in the indentation of pragmas, some
projects never indent them, others put them at the same level as the previous
stmt, others at the same level as the next stmt.
To catch the
if (1)
  #pragma GCC diagnostics ...
  something;
we just should have a separate warning that warns if the body of an
if/else/while/for is a pragma handled as a statement.
Note, for OpenMP, this is covered by the standard and GCC already errors on
OpenMP standalone directives in such contexts, so you get an error for
if (1)
  #pragma omp flush
  something;
where flush is standalone directive, but not for
if (1)
  #pragma omp single
  something;
where single is not standalone directive and has associated non-pragma code.

[Bug c/39438] Can't compile a wrapper around strftime with -Werror=format-nonliteral

[groungccg at amelkin dot msk.ru]

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

--- Comment #12 from Alexander Amelkin  ---
Also happens with `gcc (Ubuntu 8.1.0-5ubuntu1~16.04) 8.1.0`

[Bug target/87913] max(n, 1) code generation

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
A fix for the MIN/MAX recognition generates

f:
.LFB0:
.cfi_startproc
testl   %edi, %edi
movl$1, %eax
cmovne  %edi, %eax
ret

it doesn't change g().

[Bug gcov-profile/87442] Add options to filter files we want to instrument for code coverage

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|10.0|9.0

--- Comment #8 from Martin Liška  ---
Ok, I've got a patch prototype and I hope I'll be able to sent it before
the end of this stage1.

> The idea is to add two options to easily include/exclude some files from
> being instrumented.
> Here are two use cases:
>  1) -coverage-exclude=/usr/include/*: typically we remove the data for such
> files when post-processing the gcno/gcda so we don't need to instrument them
> and so we could reduce the overhead due to instrumentation.
>  2) -coverage-filter=.*/foo.cpp:.*/bar.cpp: here we want to only instrument
> these two files (for example, to display code coverage data for files
> appearing in a patch at review phase)

However, calixte can you please explain me difference in between those two
options.
More precisely, one is a white list and the second one is a black list. Will
you
mix these together or they will be used exclusively?

[Bug tree-optimization/87914] gcc fails to vectorize bitreverse code

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Wed Nov  7 15:01:09 2018
New Revision: 265876

URL: https://gcc.gnu.org/viewcvs?rev=265876=gcc=rev
Log:
2018-11-07  Richard Biener  

PR tree-optimization/87914
* tree-vect-loop.c (vect_is_simple_reduction): Improve detection
of nested cycles.
(vectorizable_reduction): Handle shifts and rotates by dispatching
to vectorizable_shift.
* tree-vect-stmts.c (vect_get_vec_def_for_operand_1): Handle
in-loop uses of vect_nested_cycle defs.  Merge cycle and internal
def cases.
(vectorizable_shift): Export and handle being called as
vect_nested_cycle.
(vect_analyze_stmt): Call vectorizable_shift after
vectorizable_reduction.
* tree-vectorizer.h (vectorizable_shift): Declare.

* lib/target-supports.exp (check_effective_target_vect_var_shift): New.
(check_avx2_available): Likewise.
* g++.dg/vect/pr87914.cc: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/vect/pr87914.cc
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/lib/target-supports.exp
trunk/gcc/tree-vect-loop.c
trunk/gcc/tree-vect-stmts.c
trunk/gcc/tree-vectorizer.h

[Bug tree-optimization/87914] gcc fails to vectorize bitreverse code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Fixed on trunk.

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

[rguenth at gcc dot gnu.org]

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

Bug 87914 Summary: gcc fails to vectorize bitreverse code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87914

   What|Removed |Added

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

[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware

[gary_mills at fastmail dot fm]

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

--- Comment #6 from Gary Mills  ---
I'm still waiting for information on how to use gdb to check the alignment of
the structures involved in this ICE.

[Bug middle-end/87916] [9 Regression] ICE in dwarf2out_abstract_function, at dwarf2out.c:22479 since r264943

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

  Component|debug   |middle-end

--- Comment #3 from Eric Botcazou  ---
Recategorizing.

[Bug debug/87916] [9 Regression] ICE in dwarf2out_abstract_function, at dwarf2out.c:22479 since r264943

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Botcazou  ---
Fixing.

[Bug debug/87916] [9 Regression] ICE in dwarf2out_abstract_function, at dwarf2out.c:22479 since r264943

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
I can reproduce.

[Bug target/87920] Lots of regression tests fail with bootstrap build of arm-linux-gnueabihf

[prathamesh3492 at gcc dot gnu.org]

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

prathamesh3492 at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from prathamesh3492 at gcc dot gnu.org ---
Likely yes, thanks for the pointer! I will mark this as dup.

Thanks,
Prathamesh

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

[Bug middle-end/87899] [9 regression]r264897 cause mis-compiled native arm-linux-gnueabihf toolchain

[prathamesh3492 at gcc dot gnu.org]

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

prathamesh3492 at gcc dot gnu.org changed:

   What|Removed |Added

 CC||prathamesh3492 at gcc dot 
gnu.org

--- Comment #4 from prathamesh3492 at gcc dot gnu.org ---
*** Bug 87920 has been marked as a duplicate of this bug. ***

[Bug target/87920] Lots of regression tests fail with bootstrap build of arm-linux-gnueabihf

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #1 from Christophe Lyon  ---
Is this a duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87899 ?

[Bug target/87920] New: Lots of regression tests fail with bootstrap build of arm-linux-gnueabihf

[prathamesh3492 at gcc dot gnu.org]

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

Bug ID: 87920
   Summary: Lots of regression tests fail with bootstrap build of
arm-linux-gnueabihf
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: prathamesh3492 at gcc dot gnu.org
  Target Milestone: ---

Hi,
It seems lots of tests are failing with bootstrap build of arm-linux-gnueabihf
with following ICE:

during GIMPLE pass: ldist
/home/prathamesh.kulkarni/gnu-toolchain/gcc/tcwg-319-4/gcc/gcc/testsuite/c-c++-common/torture/pr53505.c:
In function 'main':
/home/prathamesh.kulkarni/gnu-toolchain/gcc/tcwg-319-4/gcc/gcc/testsuite/c-c++-common/torture/pr53505.c:29:1:
internal compiler error: Segmentation fault
0x5e83cb crash_signal
../../gcc/gcc/toplev.c:325
0x660e57 inchash::hash::add(void const*, unsigned int)
../../gcc/gcc/inchash.h:100
0x660e57 inchash::hash::add_ptr(void const*)
../../gcc/gcc/inchash.h:94
0x660e57 ddr_hasher::hash(data_dependence_relation const*)
../../gcc/gcc/tree-loop-distribution.c:143
0x660e57 hash_table::find_slot(data_dependence_relation* const&, insert_option)
../../gcc/gcc/hash-table.h:414
0x660e57 get_data_dependence
../../gcc/gcc/tree-loop-distribution.c:1184
0x66157b pg_add_dependence_edges
../../gcc/gcc/tree-loop-distribution.c:1890
0x66157b build_partition_graph
../../gcc/gcc/tree-loop-distribution.c:2107
0x66180f merge_dep_scc_partitions
../../gcc/gcc/tree-loop-distribution.c:2171
0x662e69 distribute_loop
../../gcc/gcc/tree-loop-distribution.c:2892
0x66416d execute
../../gcc/gcc/tree-loop-distribution.c:3133

Several tests fail with above ICE, like pr53505.c,
20131115-1.c, 20181024-1.c etc.

Thanks,
Prathamesh

[Bug c/79775] Confusing fix-it diagnostics with double pointers to structs

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

   Last reconfirmed|2017-03-01 00:00:00 |2018-11-7
 CC||dmalcolm at gcc dot gnu.org,
   ||tschwinge at gcc dot gnu.org

--- Comment #2 from Thomas Schwinge  ---
I ran into such a thing, too (with today's GCC trunk r265867):

struct s
{
  int m;
};

void f(struct s **s)
{
  *s->m = 5;
  // (*s)->m = 5;
}

C:

../f.c: In function 'f':
../f.c:8:5: error: '*s' is a pointer; did you mean to use '->'?
8 |   *s->m = 5;
  | ^~
  | ->

C++:

../f.c: In function 'void f(s**)':
../f.c:8:7: error: request for member 'm' in '* s', which is of pointer
type 's*' (maybe you meant to use '->' ?)
8 |   *s->m = 5;
  |   ^

[Bug driver/83243] -fuse-ld=lld

[juri.valdmann at gmail dot com]

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

Jüri Valdmann  changed:

   What|Removed |Added

 CC||juri.valdmann at gmail dot com

--- Comment #4 from Jüri Valdmann  ---
(In reply to Markus Trippelsdorf from comment #3)
> So, I see no reason at all to support -fuse-ld=lld.

I can think of one reason: users want to use it.

[Bug tree-optimization/87914] gcc fails to vectorize bitreverse code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Note that if that is fixed we still fail vectorization with

t.C:8:21: missed:   not vectorized: relevant stmt not supported: _16 = mask_26
<< s_7;
t.C:18:27: missed:  bad operation or unsupported loop bound.

I have a fix for that.  But in the end the issue is weak handling of vectorized
nested cycles in general.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug target/87913] max(n, 1) code generation

[hoganmeier at gmail dot com]

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

--- Comment #2 from krux  ---
The case of function g is quite interesting because of the data dependencies
and adc's latency:
https://godbolt.org/z/0V8Dlx

[Bug c/66298] -Wmisleading-indentation should also detect missing indentation

[fw at gcc dot gnu.org]

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

--- Comment #3 from Florian Weimer  ---
This would also help to detect the incorrect pragma placement in bug 63326:

int main()
{
  int result = 1;
  if (result < 0)
#pragma GCC diagnostic ignored "-Wunused-result"
return result;
  return 0;
}

[Bug sanitizer/87454] Maybe implement -fsanitize=implicit-integer-truncation

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-07
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Note that truncation is only part of recently added Implicit Conversion
Sanitizer:
http://releases.llvm.org/7.0.0/tools/clang/docs/ReleaseNotes.html#undefined-behavior-sanitizer-ubsan

One can find a blog post about it here (mentioned in LLVM weekly):
John Regehr has a short blog post on [recently added implicit integer cast 
sanitizers](https://blog.regehr.org/archives/1633).

[Bug fortran/87919] New: Incorrect fortran handling of -fno-* options

[jakub at gcc dot gnu.org]

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

Bug ID: 87919
   Summary: Incorrect fortran handling of -fno-* options
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Seems gfc_handle_options doesn't handle properly some -fno-* options.
Mark Eggleston has a fix for -fno-dec-structure (that acts the same as
-fdec-structure), but -fno-check-array-temporaries, -fno-init-local-zero and
-fno-dec behave similarly, they ignore the no- part completely.
In
case OPT_fcheck_array_temporaries:
  gfc_option.rtcheck |= GFC_RTCHECK_ARRAY_TEMPS;
  break;
I guess it should be:
  if (value)
gfc_option.rtcheck |= GFC_RTCHECK_ARRAY_TEMPS;
  else
gfc_option.rtcheck &= ~GFC_RTCHECK_ARRAY_TEMPS;
for -fno-initi-local-zero for !value I'd say it should set all the knobs to
*_OFF, and -fno-dec, the question is if set_dec_flags (0) actually shouldn't
also undo what set_dec_flags (1) does; then it should do the &= ~ for !value
rather than the useless |= value; which does nothing if value is 0.

[Bug rtl-optimization/87868] testsuite/c-c++-common/pr60101.c with -O3 and ubsan

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Liška  ---
Fixed on trunk.

[Bug rtl-optimization/87868] testsuite/c-c++-common/pr60101.c with -O3 and ubsan

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Author: marxin
Date: Wed Nov  7 09:33:22 2018
New Revision: 265869

URL: https://gcc.gnu.org/viewcvs?rev=265869=gcc=rev
Log:
Fix UBSAN in postreload-gcse.c (PR rtl-optimization/87868).

2018-11-07  Martin Liska  

PR rtl-optimization/87868
* postreload-gcse.c (eliminate_partially_redundant_load): Set
threshold to max_count if we would overflow.
* profile-count.h: Make max_count a public constant.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/postreload-gcse.c
trunk/gcc/profile-count.h

[Bug tree-optimization/87915] emit warning if (explicit) vectorization failed

[hoganmeier at gmail dot com]

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

--- Comment #2 from krux  ---
Yeah I'm using -fopt-info for manual performance analysis but that can't be
enabled in the normal build as it's too noisy.
Furthermore a proper warning can be turned into an error to ensure that
developer expectations are met by the compiler.

[Bug rtl-optimization/87918] [9 Regression] ICE in simplify_binary_operation, at simplify-rtx.c:2153 since r264688

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2018-11-7
 CC||ams at gcc dot gnu.org,
   ||hubicka at gcc dot gnu.org,
   ||jamborm at gcc dot gnu.org
  Known to work||8.2.0
   Target Milestone|--- |9.0
  Known to fail||9.0

[Bug rtl-optimization/87918] New: [9 Regression] ICE in simplify_binary_operation, at simplify-rtx.c:2153 since r264688

[marxin at gcc dot gnu.org]

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

Bug ID: 87918
   Summary: [9 Regression] ICE in simplify_binary_operation, at
simplify-rtx.c:2153 since r264688
   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: marxin at gcc dot gnu.org
  Target Milestone: ---

Following is causing an ICE:

$ cat loops.i
typedef float a __attribute__((__vector_size__(16)));
a b, c, d;

void e() {
  float f;
  c = (__attribute__((__vector_size__(4 * sizeof(float float){f};
  d = __builtin_ia32_cmpless(c, b);
}

$ gcc loops.i -c -O2
during RTL pass: fwprop1
loops.i: In function ‘e’:
loops.i:8:1: internal compiler error: in simplify_binary_operation, at
simplify-rtx.c:2153
8 | }
  | ^
0x772e68 simplify_binary_operation(rtx_code, machine_mode, rtx_def*, rtx_def*)
/home/marxin/Programming/gcc/gcc/simplify-rtx.c:2153
0x26502d1 simplify_gen_binary(rtx_code, machine_mode, rtx_def*, rtx_def*)
/home/marxin/Programming/gcc/gcc/simplify-rtx.c:194
0x26828f2 simplify_merge_mask(rtx_def*, rtx_def*, int)
/home/marxin/Programming/gcc/gcc/simplify-rtx.c:5650
0x26571c1 simplify_ternary_operation(rtx_code, machine_mode, machine_mode,
rtx_def*, rtx_def*, rtx_def*)
/home/marxin/Programming/gcc/gcc/simplify-rtx.c:6066
0x265b68e simplify_gen_ternary(rtx_code, machine_mode, machine_mode, rtx_def*,
rtx_def*, rtx_def*)
/home/marxin/Programming/gcc/gcc/simplify-rtx.c:387
0x2657211 simplify_ternary_operation(rtx_code, machine_mode, machine_mode,
rtx_def*, rtx_def*, rtx_def*)
/home/marxin/Programming/gcc/gcc/simplify-rtx.c:5928
0x265b68e simplify_gen_ternary(rtx_code, machine_mode, machine_mode, rtx_def*,
rtx_def*, rtx_def*)
/home/marxin/Programming/gcc/gcc/simplify-rtx.c:387
0x4c73d30 propagate_rtx_1
/home/marxin/Programming/gcc/gcc/fwprop.c:536
0x4c767d6 propagate_rtx
/home/marxin/Programming/gcc/gcc/fwprop.c:692
0x4c781a2 forward_propagate_and_simplify
/home/marxin/Programming/gcc/gcc/fwprop.c:1361
0x4c781a2 forward_propagate_into
/home/marxin/Programming/gcc/gcc/fwprop.c:1420
0x4c7bff7 fwprop
/home/marxin/Programming/gcc/gcc/fwprop.c:1509
0x4c7bff7 execute
/home/marxin/Programming/gcc/gcc/fwprop.c:1540

[Bug tree-optimization/87914] gcc fails to vectorize bitreverse code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-07
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  You are expecting the outer loop to be vectorized but outer loop
vectorization fails due to

t.C:18:27: note:   Analyze phi: x_24 = PHI <_4(3), x_23(8)>
t.C:18:27: missed:   reduction value used in loop.
t.C:18:27: missed:   Unknown def-use cycle pattern.
t.C:18:27: note:   Analyze phi: mask_26 = PHI <4294967295(3), mask_17(8)>
t.C:18:27: missed:   reduction value used in loop.
t.C:18:27: missed:   Unknown def-use cycle pattern.
t.C:18:27: note:   Analyze phi: s_7 = PHI <16(3), s_14(8)>
t.C:18:27: missed:   reduction value used in loop.
t.C:18:27: missed:   Unknown def-use cycle pattern.

but for the inner loop those are just internal defs so I'm not sure why
the vectorizer backs off here... (at least mask and s should be simple
vect_nested_cycle, IMHO x as well)

[Bug tree-optimization/87915] emit warning if (explicit) vectorization failed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic, openmp
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-07
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
You could use -fopt-info-vec-missed but that warns about more cases than just
#pragma omp simd ones.

Thus confirmed.

I don't think we want to add -Wpass-failed but -Wopenmp might warn about
"unhandled" (unoptimized) OMP constructs?

[Bug target/87913] max(n, 1) code generation

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||x86_64-*-*, i?86-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-07
  Component|tree-optimization   |target
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  For f we fail to detect the max() operation at the tree level
because the test is using != 0 instead of < 1.

f (unsigned int num)
{
  unsigned int iftmp.0_1;

   [local count: 1073741825]:
  if (num_2(D) != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870913]:

   [local count: 1073741825]:
  # iftmp.0_1 = PHI 
  return iftmp.0_1;


g is represented as

g (unsigned int num)
{
  _Bool _1;
  unsigned int _2;
  unsigned int _4;

   [local count: 1073741825]:
  _1 = num_3(D) == 0;
  _2 = (unsigned int) _1;
  _4 = _2 + num_3(D);
  return _4;

expanded to (after combine)

(insn 6 3 7 2 (set (reg:CCZ 17 flags)
(compare:CCZ (reg/v:SI 85 [ num ])
(const_int 0 [0]))) "/tmp/t.c":13:16 7 {*cmpsi_ccno_1}
 (nil))
(insn 8 7 9 2 (set (reg:SI 87)
(eq:SI (reg:CCZ 17 flags)
(const_int 0 [0]))) "/tmp/t.c":13:16 652 {*setcc_si_1_movzbl}
(insn 9 8 14 2 (parallel [
(set (reg:SI 86)
(plus:SI (reg:SI 87)
(reg/v:SI 85 [ num ])))
(clobber (reg:CC 17 flags))
]) "/tmp/t.c":13:14 190 {*addsi_1}

that's a target missed optimization.  I'll fix the MIN/MAX detection
and thus make this issue a target one.

[Bug lto/87906] [9 Regression] ICE in tree check: expected block, have function_decl in block_ultimate_origin, at tree.c:12326 since r264734

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug middle-end/87869] Unrolled loop leads to excessive code bloat with -Os on ARC EM.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||amylaar at gcc dot gnu.org,
   ||andrew.burgess at embecosm dot 
com
   ||, claziss at gcc dot gnu.org

--- Comment #6 from Richard Biener  ---
CCing (former) ARC port maintainers.

[Bug tree-optimization/36602] memset should be optimized into an empty CONSTRUCTOR

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
(In reply to Richard Biener from comment #11)
> Created attachment 44963 [details]
> updated patch
> 
> Updated patch.  There are the expected missing warnings plus the two missed
> optimizations noted by the bugs this now depends on.

Current fallout is

FAIL: g++.dg/pr79095-2.C  -std=gnu++14  (test for warnings, line )
FAIL: g++.dg/pr79095-2.C  -std=gnu++17  (test for warnings, line )
FAIL: g++.dg/pr79095-2.C  -std=gnu++98  (test for warnings, line )

FAIL: gcc.dg/builtin-object-size-4.c execution test
FAIL: gcc.dg/builtin-stringop-chk-5.c  (test for warnings, line 72)
FAIL: gcc.dg/builtin-stringop-chk-5.c  (test for warnings, line 75)
FAIL: gcc.dg/builtin-stringop-chk-5.c  (test for warnings, line 78)
FAIL: gcc.dg/builtin-stringop-chk-5.c  (test for warnings, line 81)
FAIL: gcc.dg/builtin-stringop-chk-5.c  (test for warnings, line 84)
FAIL: gcc.dg/builtin-stringop-chk-5.c  (test for warnings, line 87)
FAIL: gcc.dg/builtin-stringop-chk-5.c  (test for warnings, line 92)
FAIL: gcc.dg/builtin-stringop-chk-5.c  (test for warnings, line 95)
FAIL: gcc.dg/builtin-stringop-chk-5.c  (test for warnings, line 98)

FAIL: gcc.dg/tm/memset.c scan-assembler _ITM_memsetW

FAIL: gcc.dg/tree-ssa/calloc-3.c scan-tree-dump-not optimized "malloc"
FAIL: gcc.dg/tree-ssa/calloc-3.c scan-tree-dump-times optimized "calloc" 1
 -> PR87900

FAIL: gcc.dg/tree-ssa/ssa-dse-25.c scan-tree-dump dse1 "memset ., 0, 8."
 -> PR87901

and additionally with -m32

FAIL: gcc.dg/warn-strlen-no-nul.c  (test for warnings, line 101)
FAIL: gcc.dg/warn-strlen-no-nul.c  (test for warnings, line 110)
FAIL: gcc.dg/warn-strlen-no-nul.c  (test for warnings, line 111)
FAIL: gcc.dg/warn-strlen-no-nul.c  (test for warnings, line 117)
FAIL: gcc.dg/warn-strlen-no-nul.c  (test for warnings, line 118)
FAIL: gcc.dg/warn-strlen-no-nul.c  (test for warnings, line 119)
FAIL: gcc.dg/warn-strlen-no-nul.c  (test for warnings, line 153)
FAIL: gcc.dg/warn-strlen-no-nul.c  (test for warnings, line 154)
FAIL: gcc.dg/warn-strlen-no-nul.c  (test for warnings, line 155)
FAIL: gcc.dg/warn-strlen-no-nul.c  (test for warnings, line 156)
FAIL: gcc.dg/warn-strlen-no-nul.c  (test for warnings, line 157)
FAIL: gcc.dg/warn-strlen-no-nul.c  (test for warnings, line 158)
FAIL: gcc.dg/warn-strlen-no-nul.c  (test for warnings, line 46)
FAIL: gcc.dg/warn-strlen-no-nul.c  (test for warnings, line 71)
FAIL: gcc.dg/warn-strlen-no-nul.c  (test for warnings, line 72)
FAIL: gcc.dg/warn-strlen-no-nul.c  (test for warnings, line 73)
FAIL: gcc.dg/warn-strlen-no-nul.c  (test for warnings, line 74)
FAIL: gcc.dg/warn-strlen-no-nul.c  (test for warnings, line 75)
FAIL: gcc.dg/warn-strlen-no-nul.c  (test for warnings, line 76)
FAIL: gcc.dg/warn-strlen-no-nul.c  (test for warnings, line 92)
FAIL: gcc.dg/warn-strlen-no-nul.c  (test for warnings, line 96)
FAIL: gcc.dg/warn-strlen-no-nul.c  (test for warnings, line 99)
FAIL: gcc.dg/warn-strlen-no-nul.c (internal compiler error)
FAIL: gcc.dg/warn-strlen-no-nul.c (test for excess errors)

(the ICE looks latent, and thus may be the reason for the missed warnings)

FAIL: gcc.dg/tree-ssa/builtin-sprintf-10.c (test for excess errors)


Some of the missed warnings might be cured with careful placement of
check_bounds_or_overlap calls in memset folding like we do for
memcpy folding.  But that's not exactly my area of expertise/interest.

I will test a slightly less aggresive patch now.

[Bug sanitizer/87840] LSAN not always printing the leaks when -fsanitize=address is absent

[chefmax at gcc dot gnu.org]

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

chefmax at gcc dot gnu.org changed:

   What|Removed |Added

 CC||chefmax at gcc dot gnu.org

--- Comment #10 from chefmax at gcc dot gnu.org ---
(In reply to Jan Engelhardt from comment #0)
> $ cat x.cpp
> #include 
> struct S {
> std::shared_ptr other;
> };
> int main()
> {
> auto e = std::make_shared();
> e->other = e;
> }
> 
> $ g++-9 x.cpp -ggdb3 -llsan -fsanitize=leak
> $ ./a.out
> $
> 
> LSAN fails to report the cycle while valgrind does.
> 
> Using built-in specs.
> COLLECT_GCC=g++-9
> COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/9/lto-wrapper
> OFFLOAD_TARGET_NAMES=hsa:nvptx-none
> Target: x86_64-suse-linux
> Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
> --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
> --enable-languages=c,c++,objc,fortran,obj-c++,ada,go
> --enable-offload-targets=hsa,nvptx-none=/usr/nvptx-none,
> --without-cuda-driver --enable-checking=release --disable-werror
> --with-gxx-include-dir=/usr/include/c++/9 --enable-ssp --disable-libssp
> --disable-libvtv --disable-cet --disable-libcc1 --enable-plugin
> --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
> --with-slibdir=/lib64 --with-system-zlib --enable-libstdcxx-allocator=new
> --disable-libstdcxx-pch --enable-version-specific-runtime-libs
> --with-gcc-major-version-only --enable-linker-build-id --enable-linux-futex
> --enable-gnu-indirect-function --program-suffix=-9
> --without-system-libunwind --enable-multilib --with-arch-32=x86-64
> --with-tune=generic --build=x86_64-suse-linux --host=x86_64-suse-linux
> Thread model: posix
> gcc version 9.0.0 20181026 (experimental) [trunk revision 265522] (SUSE
> Linux) 
> Applies to 
> gcc version 8.2.1 20180831 [gcc-8-branch revision 264010] (SUSE Linux) 
> gcc version 7.3.1 20180817 [gcc-7-branch revision 263612] (SUSE Linux) 
> as well.

I can confirm this with master GCC:

$  ~/install/master/bin/g++ x.cpp -ggdb3  -fsanitize=leak -static-liblsan ;
LSAN_OPTIONS=log_pointers=1:log_threads=1 ./a.out
==9273==Scanning GLOBAL range 0x00651000-0x00654fe0.
==9273==Scanning GLOBAL range 0x006552a8-0x00ee86e8.
==9273==Scanning GLOBAL range 0x7fa92c405308-0x7fa92c4140a0.
==9273==0x7fa92c410ca8: found 0x6310 pointing into chunk
0x6310-0x63111c00 of size 72704.
==9273==Scanning GLOBAL range 0x7fa92c090d70-0x7fa92c0910f8.
==9273==Scanning GLOBAL range 0x7fa92bd87d60-0x7fa92bd880f0.
==9273==Scanning GLOBAL range 0x7fa92bb83d58-0x7fa92bb84bc0.
==9273==Scanning GLOBAL range 0x7fa92b977b78-0x7fa92b97c428.
==9273==Scanning GLOBAL range 0x7fa92b75edc8-0x7fa92b75f450.
==9273==Scanning GLOBAL range 0x7fa92b53f7c0-0x7fa92b5489a0.
==9273==Scanning GLOBAL range 0x7fa92c63abc0-0x7fa92c63c168.
==9273==Processing thread 9272.
==9273==Scanning REGISTERS range 0x7fa92c5ff000-0x7fa92c5ff0d8.
==9273==Stack at 0x7ffe51e77000-0x7ffe52677000 (SP = 0x7ffe52674a28).
==9273==Scanning STACK range 0x7ffe52674a28-0x7ffe52677000.
==9273==0x7ffe52674bf8: found 0x6028 pointing into chunk
0x6020-0x60200020 of size 32.
==9273==TLS at 0x7fa92c5e2000-0x7fa92c5f0c00.
==9273==Scanning TLS range 0x7fa92c5e2000-0x7fa92c5e2758.
==9273==Scanning TLS range 0x7fa92c5f02d8-0x7fa92c5f0c00.
==9273==Scanning HEAP range 0x6020-0x60200020.
==9273==Scanning HEAP range 0x6310-0x63111c00.
==9273==Processing platform-specific allocations.
==9273==Scanning leaked chunks

>From the log I can see that pointer to allocated chunk still reachable from
main thread stack.
I'm not sure why this doesn't happen with ASan enabled, perhaps it performs
some stack cleanup before exit and rewrites this pointer.
Anyways, I don't see any opportunity to fix this in LSan in its current usage
model.
FWIW upstream has several similar reports, see e.g.
https://github.com/google/sanitizers/issues/937

[Bug lto/87906] [9 Regression] ICE in tree check: expected block, have function_decl in block_ultimate_origin, at tree.c:12326 since r264734

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Wed Nov  7 08:06:57 2018
New Revision: 265861

URL: https://gcc.gnu.org/viewcvs?rev=265861=gcc=rev
Log:
2018-11-07  Richard Biener  

PR lto/87906
* tree-streamer-in.c (lto_input_ts_block_tree_pointers): Fixup
BLOCK_ABSTRACT_ORIGIN to be the ultimate origin.

* g++.dg/lto/pr87906_0.C: New testcase.
* g++.dg/lto/pr87906_1.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/lto/pr87906_0.C
trunk/gcc/testsuite/g++.dg/lto/pr87906_1.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-streamer-in.c

[Bug tree-optimization/87917] New: ICE in initialize_matrix_A at gcc/tree-data-ref.c:3150

[marxin at gcc dot gnu.org]

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

Bug ID: 87917
   Summary: ICE in initialize_matrix_A at gcc/tree-data-ref.c:3150
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Following causes ICE:

$ arm-linux-gnueabi-gcc 
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr34635.c
-ftree-loop-distribute-patterns -ftrapv -fno-tree-fre -O2
during GIMPLE pass: ldist
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr34635.c: In
function ‘foo’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr34635.c:4:6:
internal compiler error: in int_cst_value, at tree.c:11385
4 | void foo(int x[])
  |  ^~~
0x59cad1 int_cst_value(tree_node const*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/tree.c:11385
0x112cddc initialize_matrix_A
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/tree-data-ref.c:3150
0x112fcd2 initialize_matrix_A
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/tree-data-ref.c:3143
0x112fcd2 analyze_subscript_affine_affine
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/tree-data-ref.c:3568
0x113632b analyze_miv_subscript
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/tree-data-ref.c:4014
0x113632b analyze_overlapping_iterations
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/tree-data-ref.c:4120
0x113632b subscript_dependence_tester_1
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/tree-data-ref.c:4656
0x1136ac7 subscript_dependence_tester_1
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/tree-data-ref.c:4652
0x1136ac7 subscript_dependence_tester
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/tree-data-ref.c:4706
0x1136ac7 compute_affine_dependence(data_dependence_relation*, loop*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/tree-data-ref.c:4765
0xab3f61 get_data_dependence
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/tree-loop-distribution.c:1188
0xab4195 data_dep_in_cycle_p
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/tree-loop-distribution.c:1210
0xab4195 update_type_for_merge
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/tree-loop-distribution.c:1255
0xab5b97 build_rdg_partition_for_vertex
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/tree-loop-distribution.c:1302
0xab5b97 rdg_build_partitions
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/tree-loop-distribution.c:1754
0xab5b97 distribute_loop
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/tree-loop-distribution.c:2795
0xab88a0 execute
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/tree-loop-distribution.c:3133

[Bug tree-optimization/87901] partial DSE of memset doesn't work for other kind of stores

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
(In reply to Martin Sebor from comment #1)
> The example is undefined -- it forms a past the-end pointer -- and
> -Warray-bounds detects it:
> 
> warning: array subscript 2 is outside array bounds of ‘int[1]’
> [-Warray-bounds]
> 6 |   *((short *) + sizeof (int) - sizeof (short)) = 1;
> 
> I don't suppose you meant to do that, but presumably meant to access a part
> of the object.  But even then the code is undefined.
> 
> Can you explain/clarify what you have in mind and why it's important?

Whoops - should be + 2 - 1 (was char * before I made it to shorts).

int i;
void foo ()
{
  i = 0;
  *((short *) + 1) = 1;
}

the original motivation is from 36602 patch regressions.  When transforming

char z[32];

int
foo(void)
{
  memset (z, 0, 16);
  memset (z+8, 0, 24);
}

to

int
foo(void)
{
  MEM[] = 0;
  MEM[+8] = {};
}

DSE doesn't know to adjust the = 0 store (and likely not a = {} store if it
were first).

I first wanted to construct an example with unions...