[Bug tree-optimization/87952] New: Missed optimization for std::get_if on std::variant

[narut.se at gmail dot com]

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

Bug ID: 87952
   Summary: Missed optimization for std::get_if on std::variant
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: narut.se at gmail dot com
  Target Milestone: ---

Here is the sample code:

#include 

int test(std::variant )
{
return *std::get_if();
}


gcc generates (on x86-64):

test(std::variant&):
cmp BYTE PTR [rdi+4], 0
jne .L2
mov eax, DWORD PTR [rdi]
ret
test(std::variant&) [clone .cold]:
.L2:
mov eax, DWORD PTR ds:0
ud2

It seems like the undefined behavior branch can be optimized away leaving (as
clang does):

test(std::variant&):   # @test(std::variant&)
mov eax, dword ptr [rdi]
ret


The reason this is useful is that if I know ahead of time (but the compiler
can't prove) that the variant holds a certain alternative, calling get_if this
way will provide no overhead access to the alternative. (The standard doesn't
allow this kind of access for std::get.) Since dereferencing the null pointer
(as would happen if the variant didn't hold the alternative) is undefined
behavior anyway, we could optimize it away and assume that the alternative is
valid.

[Bug c++/87951] New: GCC warns about reaching end of non-void function when all switch is completely handled

[vlovich at gmail dot com]

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

Bug ID: 87951
   Summary: GCC warns about reaching end of non-void function when
all switch is completely handled
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vlovich at gmail dot com
  Target Milestone: ---

If a function has a single switch statement that handles all enum values &
returns a value GCC will warn about the function not returning a value whereas
clang does not.  GCC requires an explicit __builtin_unreachable() annotation
after the switch. As of C++17 it seems to now be undefined behaviour rather
than unspecified behaviour for an enum to have a value that's not enumerated.

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1766

> cat test.c

enum Enum {
  A,
  B,
};

int CoverMyBases(enum Enum x) {
switch (x) {
case A:
return 1;
case B:
return 0;
}
}

int main(int argc, const char **argv) {
CoverMyBases(A);
CoverMyBases(B);
return 0;
}

> g++-8 -Wall --std=c++17 test.c

test.c: In function 'CoverMyBases':
test.c:16:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^

> clang++ -std=c++17 -Wall test.c

NOTE: Clang never warns about this even prior to C++17 or in C either.

[Bug c/87950] GCC warns about reaching end of non-void function when all switch cases are completely handled

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Vitali from comment #6)
> Actually as of C++17 it's undefined behaviour.
> 
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1766
> 
> so at the very least when compiled with C++17 the compiler should be smart
> enough to strengthen the control flow analysis.

Open a C++ bug then rather than reusing a C bug report ...

[Bug c/87950] GCC warns about reaching end of non-void function when all switch cases are completely handled

[vlovich at gmail dot com]

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

Vitali  changed:

   What|Removed |Added

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

--- Comment #6 from Vitali  ---
Actually as of C++17 it's undefined behaviour.

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1766

so at the very least when compiled with C++17 the compiler should be smart
enough to strengthen the control flow analysis.

[Bug c/87950] GCC warns about reaching end of non-void function when all switch cases are completely handled

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Vitali from comment #2)
> Why has clang made a different decision? Also, this warning is present in
> C++ code too.

You need to ask clang why they made that decision.  C rules are clear about
value ranges of enums and all.

In C++, (unlike C), out of ranges are just unspecified rather than undefined.
This means the warning is correct too.  NOTE there is a big difference between
the three: implmenentation defined, undefined and unspecified behaviors.
implmenentation defined is behavior that needs to be documented.  Undefined
behavior means the behavior can be different at different runs.  unspecified
behaviors means the behavior does not need to be documented but it has to be
constitiant between runs.

So there is no bug here again.

See PR12242 also about a warning for the unspecified behavior when doing the
conversion;  NOTE it is not undefined which is different.

See also https://gcc.gnu.org/ml/gcc-patches/2010-04/msg01694.html .

Also see PR 53479 for the C++ side of the warning too (for enum classes).

--- Comment #5 from Andrew Pinski  ---
(In reply to Vitali from comment #2)
> Why has clang made a different decision? Also, this warning is present in
> C++ code too.

You need to ask clang why they made that decision.  C rules are clear about
value ranges of enums and all.

In C++, (unlike C), out of ranges are just unspecified rather than undefined.
This means the warning is correct too.  NOTE there is a big difference between
the three: implmenentation defined, undefined and unspecified behaviors.
implmenentation defined is behavior that needs to be documented.  Undefined
behavior means the behavior can be different at different runs.  unspecified
behaviors means the behavior does not need to be documented but it has to be
constitiant between runs.

So there is no bug here again.

See PR12242 also about a warning for the unspecified behavior when doing the
conversion;  NOTE it is not undefined which is different.

See also https://gcc.gnu.org/ml/gcc-patches/2010-04/msg01694.html .

Also see PR 53479 for the C++ side of the warning too (for enum classes).

[Bug c/87950] GCC warns about reaching end of non-void function when all switch cases are completely handled

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Vitali from comment #2)
> Why has clang made a different decision? Also, this warning is present in
> C++ code too.

You need to ask clang why they made that decision.  C rules are clear about
value ranges of enums and all.

In C++, (unlike C), out of ranges are just unspecified rather than undefined.
This means the warning is correct too.  NOTE there is a big difference between
the three: implmenentation defined, undefined and unspecified behaviors.
implmenentation defined is behavior that needs to be documented.  Undefined
behavior means the behavior can be different at different runs.  unspecified
behaviors means the behavior does not need to be documented but it has to be
constitiant between runs.

So there is no bug here again.

See PR12242 also about a warning for the unspecified behavior when doing the
conversion;  NOTE it is not undefined which is different.

See also https://gcc.gnu.org/ml/gcc-patches/2010-04/msg01694.html .

Also see PR 53479 for the C++ side of the warning too (for enum classes).

--- Comment #5 from Andrew Pinski  ---
(In reply to Vitali from comment #2)
> Why has clang made a different decision? Also, this warning is present in
> C++ code too.

You need to ask clang why they made that decision.  C rules are clear about
value ranges of enums and all.

In C++, (unlike C), out of ranges are just unspecified rather than undefined.
This means the warning is correct too.  NOTE there is a big difference between
the three: implmenentation defined, undefined and unspecified behaviors.
implmenentation defined is behavior that needs to be documented.  Undefined
behavior means the behavior can be different at different runs.  unspecified
behaviors means the behavior does not need to be documented but it has to be
constitiant between runs.

So there is no bug here again.

See PR12242 also about a warning for the unspecified behavior when doing the
conversion;  NOTE it is not undefined which is different.

See also https://gcc.gnu.org/ml/gcc-patches/2010-04/msg01694.html .

Also see PR 53479 for the C++ side of the warning too (for enum classes).

[Bug middle-end/12849] testing divisibility by constant

[hoganmeier at gmail dot com]

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

krux  changed:

   What|Removed |Added

 CC||hoganmeier at gmail dot com

--- Comment #5 from krux  ---
Should be fixed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82853

[Bug c/87950] GCC warns about reaching end of non-void function when all switch cases are completely handled

[vlovich at gmail dot com]

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

Vitali  changed:

   What|Removed |Added

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

--- Comment #3 from Vitali  ---
Follow-up comment.

[Bug c/87950] GCC warns about reaching end of non-void function when all switch cases are completely handled

[vlovich at gmail dot com]

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

--- Comment #2 from Vitali  ---
Why has clang made a different decision? Also, this warning is present in C++
code too.

[Bug c/87950] GCC warns about reaching end of non-void function when all switch cases are completely handled

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
In C, enum valid value range is the full int range.
So all switch cases are not being handled even for valid C code.

[Bug c/87950] New: GCC warns about reaching end of non-void function when all switch is completely handled

[vlovich at gmail dot com]

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

Bug ID: 87950
   Summary: GCC warns about reaching end of non-void function when
all switch is completely handled
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vlovich at gmail dot com
  Target Milestone: ---

Noticed this for a while. If a function has a single switch statement that
handles all enum values & returns a value GCC will warn about the function not
returning a value whereas clang does not.  GCC requires an explicit
__builtin_unreachable() annotation after the switch. Maybe it's an intentional
disagreement over how to interpret the spec? AFAICT via objdump the generated
assembly is identical between clang & GCC even when compiled with
optimizations.

> cat test.c
enum Enum {
  A,
  B,
};

int CoverMyBases(enum Enum x) {
switch (x) {
case A:
return 1;
case B:
return 0;
}
}

int main(int argc, const char **argv) {
CoverMyBases(A);
CoverMyBases(B);
return 0;
}

> gcc-8 -Wall test.c
test.c: In function 'CoverMyBases':
test.c:16:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^

> clang -Wall test.c
> gcc-8 --version
gcc-8 (Homebrew GCC 8.2.0) 8.2.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> clang --version
Apple LLVM version 10.0.0 (clang-1000.11.45.2)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

This applies to both C & C++.

[Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?

[jvdelisle at gcc dot gnu.org]

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

--- Comment #24 from Jerry DeLisle  ---
Author: jvdelisle
Date: Fri Nov  9 02:46:03 2018
New Revision: 265946

URL: https://gcc.gnu.org/viewcvs?rev=265946=gcc=rev
Log:
2018-11-08  Jerry DeLisle  

PR libfortran/78351
* io/transfer.c (read_sf_internal): Add support for early
comma termination of internal unit formatted reads.

* gfortran.dg/read_legacy_comma.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/read_legacy_comma.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/transfer.c

[Bug target/87949] PowerPC saves CR registers across calls

[bergner at gcc dot gnu.org]

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

--- Comment #3 from Peter Bergner  ---
What do you think we can do about that?  The call clobbers the ABI defined
non-volatile CR regs, so we have to save/restore them.  I don't think we have
any other option, other than telling GCC to never use the non-volatile CR regs
so they never have to be saved/restored.  Does using -ffixed-cr2 -ffixed-cr3
-ffixed-cr4 help?

[Bug rtl-optimization/87948] LRA register allocator does not support HARD_REGNO_CALLER_SAVE_MODE returning VOIDmode

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  ---
I entered bug 87949 as the bug I was trying to fix when I encountered the
HARD_REGNO_CALLER_SAVE issue.

[Bug target/87949] PowerPC saves CR registers across calls

[meissner at gcc dot gnu.org]

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

--- Comment #2 from Michael Meissner  ---
Created attachment 44981
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44981=edit
Bzip2 assembly file from the fortran source

In the assembly file, at line 1262, there is a store from a MFCR instruction to
save a CR register, and on line 1381 there is a load and a MTCRF instruction to
restore it.

[Bug target/87949] PowerPC saves CR registers across calls

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  ---
Created attachment 44980
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44980=edit
Fortran file showing problem from gamess

Compile this file with the '-Ofast -g -S -std=legacy -mcpu=power9' options.

In the assembly file, at line 1262, there is a store from a MFCR instruction to
save a CR register, and on line 1381 there is a load and a MTCRF instruction to
restore it.

[Bug c++/43105] Document restrictions on mixing -fno-rtti and -frtti

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Works for me.

[Bug c++/87947] Symbol Does Not Appear in Object File

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to comm+gnu from comment #0)
> The expected behavior is that A::foobar is exposed as a symbol. Note that
> -std=c++17 is required to duplicate this.

Your expectation is wrong. In C++17 the static data member is implicitly
"inline" which means a definition is only emitted when it's odr-used (and the
namespace scope definition is redundant, and deprecated).

GCC 6.x does not implement the C++17 rule, so still emits the symbol.

If you need to ensure a definition is emitted in a given object file either
compile it as C++14, or mark it as used:

[[gnu::used]] constexpr int A::foobar;

[Bug target/87949] New: PowerPC saves CR registers across calls

[meissner at gcc dot gnu.org]

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

Bug ID: 87949
   Summary: PowerPC saves CR registers across calls
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

While there are 3 saved CR registers (CR2, CR3, CR4) in the PowerPC, we really,
really, really should not be saving CR values across calls due to the amount of
time it takes to save and restore these registers.

This shows up in the Spec 2006 perlbench benchmark where the hot function
(S_regmatch in regexep.c) saves all 3 CRs at the function prologue, and has to
restore these registers at the epilog.

It also shows up in the gamess benchmark (which is where I found it in doing
some future code).  Note only do functions in gamess save all 3 CR registers,
at least one function decides to use caller saves to save a 4th CR register
across a call.

I'm not sure whether this is a target feature or a machine independent feature
at this point.  My first attempt at fixing it via HARD_REGNO_CALLER_SAVE_MODE
fails due to LRA not supporting it returning VOIDmode (PR 87948).

[Bug rtl-optimization/87948] New: LRA register allocator does not support HARD_REGNO_CALLER_SAVE_MODE returning VOIDmode

[meissner at gcc dot gnu.org]

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

Bug ID: 87948
   Summary: LRA register allocator does not support
HARD_REGNO_CALLER_SAVE_MODE returning VOIDmode
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

The documentation for HARD_REGNO_CALLER_SAVE_MODE states:

@defmac HARD_REGNO_CALLER_SAVE_MODE (@var{regno}, @var{nregs})
A C expression specifying which mode is required for saving @var{nregs}
of a pseudo-register in call-clobbered hard register @var{regno}.  If
@var{regno} is unsuitable for caller save, @code{VOIDmode} should be
returned.  For most machines this macro need not be defined since GCC
will select the smallest suitable mode.
@end defmac

I was trying to prevent the GCC compiler from saving and restoring CR registers
across calls, so I defined HARD_REGNO_CALLER_SAVE_MODE as:

/* When setting up caller-save slots (MODE == VOIDmode) ensure we allocate  
   enough space to account for vectors in FP regs.  However, TFmode/TDmode  
   should not use VSX instructions to do a caller save.  Return VOIDmode
   for the CR registers so that we don't try to save them across calls.  */
#define HARD_REGNO_CALLER_SAVE_MODE(REGNO, NREGS, MODE) \
  (CR_REGNO_P (REGNO)   \
   ? VOIDmode   \
   : (NREGS) <= rs6000_hard_regno_nregs[MODE][REGNO]\
   ? (MODE) \
   : TARGET_VSX \
 && ((MODE) == VOIDmode || ALTIVEC_OR_VSX_VECTOR_MODE (MODE))   \
 && FP_REGNO_P (REGNO)  \
   ? V2DFmode   \
   : FLOAT128_IBM_P (MODE) && FP_REGNO_P (REGNO)\
   ? DFmode \
   : (MODE) == TDmode && FP_REGNO_P (REGNO) \
   ? DImode \
   : choose_hard_reg_mode ((REGNO), (NREGS), false))

However, when I try to build the compiler (without bootstrap initially), I get
the following error:

during RTL pass: reload
/home/meissner/fsf-src/test/libbacktrace/elf.c: In function 'elf_add':
/home/meissner/fsf-src/test/libbacktrace/elf.c:3211:1: internal compiler error:
in lra_create_new_reg_with_unique_value, at lra.c:189
 3211 | }
  | ^
0x107bba3f lra_create_new_reg_with_unique_value(machine_mode, rtx_def*,
reg_class, char const*)
/home/meissner/fsf-src/test/gcc/lra.c:189
0x107bbabf lra_create_new_reg(machine_mode, rtx_def*, reg_class, char const*)
/home/meissner/fsf-src/test/gcc/lra.c:229
0x107ce00b split_reg
/home/meissner/fsf-src/test/gcc/lra-constraints.c:5566
0x107d5aa3 inherit_in_ebb
/home/meissner/fsf-src/test/gcc/lra-constraints.c:6568
0x107d5aa3 lra_inheritance()
/home/meissner/fsf-src/test/gcc/lra-constraints.c:6639
0x107c0f37 lra(_IO_FILE*)
/home/meissner/fsf-src/test/gcc/lra.c:2486
0x1075abeb do_reload
/home/meissner/fsf-src/test/gcc/ira.c:5469
0x1075abeb execute
/home/meissner/fsf-src/test/gcc/ira.c:5653
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
Makefile:820: recipe for target 'elf.lo' failed
make[3]: *** [elf.lo] Error 1
make[3]: Leaving directory
'/home/meissner/fsf-build-ppc64le/test/powerpc64le-unknown-linux-gnu/libbacktrace'
Makefile:700: recipe for target 'all' failed
make[2]: *** [all] Error 2
make[2]: Leaving directory
'/home/meissner/fsf-build-ppc64le/test/powerpc64le-unknown-linux-gnu/libbacktrace'
Makefile:13084: recipe for target 'all-target-libbacktrace' failed
make[1]: *** [all-target-libbacktrace] Error 2
make[1]: Leaving directory '/home/meissner/fsf-build-ppc64le/test'
Makefile:939: recipe for target 'all' failed
make: *** [all] Error 2

[Bug rtl-optimization/87600] Fix for PRs 86939 and 87479 causes build issues for several targets

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #7 from Peter Bergner  ---
Ok, I think this resolves all but one ARM issue which is being tracked in
PR87899, so I'm going to mark this bugzilla as fixed.

[Bug rtl-optimization/87600] Fix for PRs 86939 and 87479 causes build issues for several targets

[bergner at gcc dot gnu.org]

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

--- Comment #6 from Peter Bergner  ---
Author: bergner
Date: Thu Nov  8 22:39:45 2018
New Revision: 265942

URL: https://gcc.gnu.org/viewcvs?rev=265942=gcc=rev
Log:
gcc/
PR rtl-optimization/87600
* cfgexpand.c (expand_asm_stmt): Catch illegal asm constraint usage.
* lra-constraints.c (process_alt_operands): Skip illegal hard
register usage.  Prefer reloading non hard register operands.

gcc/testsuite/
PR rtl-optimization/87600
* gcc.dg/pr87600.h: New file.
* gcc.dg/pr87600-1.c: New test.
* gcc.dg/pr87600-2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/pr87600-1.c
trunk/gcc/testsuite/gcc.dg/pr87600-2.c
trunk/gcc/testsuite/gcc.dg/pr87600.h
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c
trunk/gcc/lra-constraints.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/87931] [9 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:6193 since r265876

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #2 from David Binderman  ---
Might be related to this:

==6494==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7ffcf43dbd58 at pc 0x02cfffdd bp 0x7ffcf43da650 sp 0x7ffcf43da648
READ of size 8 at 0x7ffcf43dbd58 thread T0
#0 0x2cfffdc in vectorizable_reduction(_stmt_vec_info*,
gimple_stmt_iterator*, _stmt_vec_info**, _slp_tree*, _slp_instance*,
vec*)
../../trunk/gcc/tree-vect-loop.c:6485

[Bug c++/87947] New: Symbol Does Not Appear in Object File

[comm+gnu at squotd dot net]

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

Bug ID: 87947
   Summary: Symbol Does Not Appear in Object File
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: comm+gnu at squotd dot net
  Target Milestone: ---

A symbol is not exposed in cirucumstances where it seems it should be, and is
exposed in version 6.3.0 (and clang 7.0.0, fwiw).

$ gcc --save-temps -std=c++17 -c symbol.cpp 
$ cat symbol.ii 
# 1 "symbol.cpp"
# 1 ""
# 1 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "" 2
# 1 "symbol.cpp"
struct A {
static constexpr auto foobar = 0;
};

constexpr int A::foobar;

$ nm symbol.o 
$ 

The expected behavior is that A::foobar is exposed as a symbol. Note that
-std=c++17 is required to duplicate this.

The same thing done with 6.3.0 results in this.

$ nm symbol.o 
 R _ZN1A6foobarE

Version information is as follows.

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

[Bug other/36572] Documentation for some options starting with “no-” not clear

[sandra at gcc dot gnu.org]

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

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 ---
Fixed (finally) on trunk.

[Bug other/36572] Documentation for some options starting with “no-” not clear

[sandra at gcc dot gnu.org]

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

--- Comment #1 from sandra at gcc dot gnu.org ---
Author: sandra
Date: Thu Nov  8 22:02:38 2018
New Revision: 265939

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

PR other/36572

gcc/
* doc/invoke.texi (Optimize Options): Clarify default behavior
for -fno-sched-interblock and -fno-sched-spec.

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

[Bug c++/87814] [9 Regression] ICE in in tsubst_copy, at cp/pt.c:15962 with range-v3

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
I actually still see an ICE in tsubst_copy:

h.C: In instantiation of ‘constexpr adaptor_cursor::adaptor_cursor(Args&& ...)
[with Args = {int*}][inherited from compressed_tuple_]’:
h.C:24:43:   required from here
h.C:20:30: internal compiler error: in tsubst_copy, at cp/pt.c:16090
   20 | using compressed_tuple_::compressed_tuple_;
  |  ^
0x80b870 tsubst_copy
/home/mpolacek/src/gcc/gcc/cp/pt.c:16090
0xa3cbc2 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mpolacek/src/gcc/gcc/cp/pt.c:19160
0xa4286b tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mpolacek/src/gcc/gcc/cp/pt.c:17862
0xa4286b tsubst_exception_specification
/home/mpolacek/src/gcc/gcc/cp/pt.c:14231
0xa509b4 regenerate_decl_from_template
/home/mpolacek/src/gcc/gcc/cp/pt.c:23584
0xa509b4 instantiate_decl(tree_node*, bool, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.c:24154
0x8e74c9 instantiate_cx_fn_r
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:4944

[Bug c++/87137] [8/9 Regression] Non-virtual member function increases struct size

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #15 from Nathan Sidwell  ---
I forgot to mark this fixed.

[Bug c++/87814] [9 Regression] ICE in in tsubst_copy, at cp/pt.c:15962 with range-v3

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org

--- Comment #3 from Nathan Sidwell  ---
This is ICEing, but not in tsubst_copy:
87814.ii:19:8: internal compiler error: Segmentation fault
   19 | struct adaptor_cursor : compressed_tuple_ {
  |^~
0xb08b4f crash_signal
../../../src/gcc/toplev.c:325
0x5ac177 standard_conversion
../../../src/gcc/cp/call.c:1122
0x5b226b implicit_conversion
../../../src/gcc/cp/call.c:1860
0x5af991 perform_implicit_conversion_flags(tree_node*, tree_node*, int, int)
../../../src/gcc/cp/call.c:10909
0x61d8be build_noexcept_spec(tree_node*, int)
../../../src/gcc/cp/except.c:1198
0x6a65d2 maybe_instantiate_noexcept(tree_node*, int)
../../../src/gcc/cp/pt.c:23802
0x5f5a2c start_preparsed_function(tree_node*, tree_node*, int)
../../../src/gcc/cp/decl.c:15430
0x63a6c1 synthesize_method(tree_node*)
../../../src/gcc/cp/method.c:913
0x6adaed instantiate_decl(tree_node*, bool, bool)
../../../src/gcc/cp/pt.c:24198
0x5ce05b instantiate_cx_fn_r

[Bug c++/87269] [9 Regression] ICE in tsubst_copy, at cp/pt.c:15475 starting from r261802

[nathan at gcc dot gnu.org]

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

--- Comment #5 from Nathan Sidwell  ---
Martin, this isn't icing now.

[Bug rtl-optimization/87902] [9 Regression] Shrink-wrapping multiple conditions

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
All instructions that depend on the new registers can start later, too, if
you move all new registers down.  If you move copies from hard registers
down it is much worse: you are extending the lifetime of those hard regs
so that nothing else can live there, but more likely, it will have to be
spilled even.

[Bug c++/43105] Document restrictions on mixing -fno-rtti and -frtti

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #4 from sandra at gcc dot gnu.org ---
It sounds to me like the right solution here is just to add a vague warning
that mixing -frtti and -fno-rtti code may not always work, citing the base
class example in the issue problem statement.  WDYT?

[Bug sanitizer/87837] [8/9 Regression] -O2 -fsanitize=signed-integer-overflow misses overflows on x86-64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

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

[spop at gcc dot gnu.org]

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

Sebastian Pop  changed:

   What|Removed |Added

 CC||spop at gcc dot gnu.org

--- Comment #3 from Sebastian Pop  ---
> Sebastian - can you say if
> evolution_function_is_affine_multivariate_p ({0, +, {0, +, 4}_1}_2, 1)
> should really return true?

You are right, {0, +, {0, +, 4}_1}_2 is not a valid affine multivariate
function: only the base (not the step) should vary in an outer loop.

For example, this would be an affine multivariate: {{0, +, 4}_1, +, 42}_2.

[Bug fortran/87946] New: [7/8/9 Regression] ICE in gfc_walk_array_ref, at fortran/trans-array.c:10506

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

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

Bug ID: 87946
   Summary: [7/8/9 Regression] ICE in gfc_walk_array_ref, at
fortran/trans-array.c:10506
   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: ---

Affects versions 7 to 9.
Compiles with "type(t), allocatable :: u(:)" instead of class...


$ cat z1.f90
module m
   type t
   contains
  generic :: h => g
  procedure, private :: g
   end type
contains
   function g(x, y) result(z)
  class(t), intent(in) :: x
  real, intent(in) :: y(:, :)
  real :: z(size(y, 2))
   end
end
module m2
   use m
   type t2
  class(t), allocatable :: u(:)
   end type
end
function f(x, y) result(z)
   use m2
   type(t2) :: x
   real :: y(:, :)
   real :: z(size(y, 2))
   z = x%u(1)%h(y)
end


$ gfortran-6 -c z1.f90
$
$ gfortran-9-20181104 -c z1.f90
z1.f90:25:0:

   25 |z = x%u(1)%h(y)
  |
internal compiler error: Segmentation fault
0xb205df crash_signal
../../gcc/toplev.c:325
0x6ce11f gfc_walk_array_ref(gfc_ss*, gfc_expr*, gfc_ref*)
../../gcc/fortran/trans-array.c:10506
0x6cfda9 gfc_walk_expr(gfc_expr*)
../../gcc/fortran/trans-array.c:10886
0x6cfda9 gfc_conv_expr_descriptor(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-array.c:7087
0x6ffb41 gfc_conv_intrinsic_size
../../gcc/fortran/trans-intrinsic.c:7144
0x71549b gfc_conv_intrinsic_function(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-intrinsic.c:9754
0x6f9a54 gfc_conv_function_expr
../../gcc/fortran/trans-expr.c:6905
0x6ee0aa gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:8039
0x6f010a gfc_apply_interface_mapping(gfc_interface_mapping*, gfc_se*,
gfc_expr*)
../../gcc/fortran/trans-expr.c:4451
0x6c5d07 gfc_set_loop_bounds_from_array_spec(gfc_interface_mapping*, gfc_se*,
gfc_array_spec*)
../../gcc/fortran/trans-array.c:932
0x6f84a5 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec*)
../../gcc/fortran/trans-expr.c:6147
0x6f9a3c gfc_conv_function_expr
../../gcc/fortran/trans-expr.c:6928
0x6ee0aa gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:8039
0x6cf080 gfc_add_loop_ss_code
../../gcc/fortran/trans-array.c:2815
0x6cfc25 gfc_conv_loop_setup(gfc_loopinfo*, locus*)
../../gcc/fortran/trans-array.c:5129
0x6fc69b gfc_trans_assignment_1
../../gcc/fortran/trans-expr.c:10208
0x6bf54f trans_code
../../gcc/fortran/trans.c:1822
0x6e6e14 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6509
0x6740a6 translate_all_program_units
../../gcc/fortran/parse.c:6125
0x6740a6 gfc_parse_file()
../../gcc/fortran/parse.c:6328

[Bug fortran/87945] New: [9 Regression] ICE in var_element, at fortran/decl.c:281

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

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

Bug ID: 87945
   Summary: [9 Regression] ICE in var_element, at
fortran/decl.c:281
   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: ---

Changed recently :


$ cat z1.f90
program p
   character :: a, b
   data a%len /1/
   data b%kind /'b'/
end


$ gfortran-9-20181104 -c z1.f90
f951: internal compiler error: Segmentation fault
0xb205df crash_signal
../../gcc/toplev.c:325
0x60299e var_element
../../gcc/fortran/decl.c:281
0x604ce4 top_var_list
../../gcc/fortran/decl.c:321
0x604ce4 gfc_match_data()
../../gcc/fortran/decl.c:598
0x66a3c1 match_word
../../gcc/fortran/parse.c:65
0x66db06 decode_statement
../../gcc/fortran/parse.c:468
0x66e72a next_free
../../gcc/fortran/parse.c:1234
0x66e72a next_statement
../../gcc/fortran/parse.c:1466
0x66fd3b parse_spec
../../gcc/fortran/parse.c:3858
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/56423] F08/0071: Shall reject invalid Vector subscript target with Pointer assignment

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

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

G. Steinmetz  changed:

   What|Removed |Added

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

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

Update, slightly simplified :


$ cat z1.f90
program p
   integer, target :: x(3) = [7, 8, 9]
   type t
  integer, pointer :: a(:)
   end type
   type(t) :: z
   z = t(x([2]))
   print *, z%a
end


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

7 |z = t(x([2]))
  |
internal compiler error: in gfc_conv_expr_descriptor, at
fortran/trans-array.c:7285
0x6d14c3 gfc_conv_expr_descriptor(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-array.c:7285
0x6f2a9b gfc_trans_subcomponent_assign
../../gcc/fortran/trans-expr.c:7485
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
0x6bf54f trans_code
../../gcc/fortran/trans.c:1822
0x6e6e14 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6509
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


---

And nearby :


$ cat z2.f90
program p
   integer, target :: x(3) = [7, 8, 9]
   type t
  integer, pointer :: a(:)
   end type
   type(t) :: z
   z = t(x(2))
   print *, z%a
end


$ gfortran-9-20181104 -c z2.f90
z2.f90:7:0:

7 |z = t(x(2))
  |
internal compiler error: in gfc_conv_expr_descriptor, at
fortran/trans-array.c:7090
0x6d14eb gfc_conv_expr_descriptor(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-array.c:7090
0x6f2a9b gfc_trans_subcomponent_assign
../../gcc/fortran/trans-expr.c:7485
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
0x6bf54f trans_code
../../gcc/fortran/trans.c:1822
0x6e6e14 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6509
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

[Bug middle-end/51019] unclear documentation on -fomit-frame-pointer default for -Os and different platforms

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||sandra at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #2 from sandra at gcc dot gnu.org ---
Since this issue was filed, the discussion about -fomit-frame-pointer has been
rewritten so that it no longer mentions specific releases or targets.  It now
says "Enabled by default at @option{-O} and higher.", which matches what the
code in  opts.c does with it.

[Bug middle-end/54615] unclear documentation on -fomit-frame-pointer for -O

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from sandra at gcc dot gnu.org ---
The text about the interaction between -O and -fomit-frame-pointer in the
discussion of both options has been rewritten since this issue was filed.  It
looks like it agrees with the code:  "Enabled by default at @option{-O} and
higher."

[Bug c/87944] Wrong code with LRA pushing stack local variable

[pkoning at gcc dot gnu.org]

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

--- Comment #2 from pkoning at gcc dot gnu.org ---
Created attachment 44979
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44979=edit
Test program source

[Bug c/87944] Wrong code with LRA pushing stack local variable

[pkoning at gcc dot gnu.org]

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

--- Comment #1 from pkoning at gcc dot gnu.org ---
Created attachment 44978
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44978=edit
Reload dump

[Bug c/87944] New: Wrong code with LRA pushing stack local variable

[pkoning at gcc dot gnu.org]

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

Bug ID: 87944
   Summary: Wrong code with LRA pushing stack local variable
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pkoning at gcc dot gnu.org
  Target Milestone: ---

Created attachment 44977
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44977=edit
Dump file before reload

I see this on pdp11, I haven't found a mainline target yet that reproduces it.

The issue is on a call that passes the address of a local variable, with
arguments pushed on the stack so effectively we get a push(frame_pointer). 
With frame pointer elimination, that becomes push(stack_pointer).

But that's not a legal instruction on this machine, and I created constraints
that say so.  With the old reload, I see the intended result: copy SP to
another register, then push that register.

LRA instead adjusts the stack pointer by a word to make room for the argument,
then copies the stack pointer to that spot.  The result is that the argument is
off by one word because it copied the SP after adjustment rather than
generating the value before.  The offending pdp11 code looks like this:

add $-02,sp
mov sp,(sp)
jsr pc,_strlen

what's wanted is something like this:

mov sp,r0
mov r0,-(sp)

I've seen variations of this issue in LRA; the common thread is that it doesn't
aways account for changes in SP when calculating the SP offset for a local
variable.

I'll attach dump files that show the issue.  The issue is with insn 12.

[Bug rtl-optimization/87902] [9 Regression] Shrink-wrapping multiple conditions

[iii at linux dot ibm.com]

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

--- Comment #3 from Ilya Leoshkevich  ---
Judging by the following comment in lra-coalesce.c, RA doesn't do this
intentionally:

   Here we coalesce only spilled pseudos.  Coalescing non-spilled
   pseudos (with different hard regs) might result in spilling
   additional pseudos because of possible conflicts with other
   non-spilled pseudos and, as a consequence, in more constraint
   passes and even LRA infinite cycling.  Trivial the same hard
   register moves will be removed by subsequent compiler passes.

In which cases would moving copies down in prepare_shrink_wrap () make
the code worse?

[Bug tree-optimization/78969] bogus snprintf truncation warning due to missing range info

[gcc at sheaffer dot ws]

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

Jeremy Sheaffer  changed:

   What|Removed |Added

 CC||gcc at sheaffer dot ws

--- Comment #13 from Jeremy Sheaffer  ---
Bug is still present in 8.2.0:

snprintf(s[i], 60, "%40s%2d %s by %2d %s", tmp,
 abs(character_get_y(c[i]) - character_get_y(d->PC)),
 ((character_get_y(c[i]) - character_get_y(d->PC)) <= 0 ?
  "North" : "South"),
 abs(character_get_x(c[i]) - character_get_x(d->PC)),
 ((character_get_x(c[i]) - character_get_x(d->PC)) <= 0 ?
  "West" : "East"));

The two integer conversion are always <= 2 digits.

[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

--- Comment #5 from David Malcolm  ---
Author: dmalcolm
Date: Thu Nov  8 15:38:30 2018
New Revision: 265920

URL: https://gcc.gnu.org/viewcvs?rev=265920=gcc=rev
Log:
ipa-inline.c/tree-inline.c: port from fprintf to dump API (PR ipa/86395)

This patch ports various fprintf calls in the inlining code to using
the dump API, using the %C format code for printing cgraph_node *.
I focussed on the dump messages that seemed most significant to
end-users; I didn't port all of the calls.

Doing so makes this information appear in -fopt-info and in
optimization records, rather than just in the dump_file.

It also changes the affected dumpfile-dumps from being unconditional
(assuming the dump_file is enabled) to being guarded by the MSG_*
status.  Hence various tests with dg-final scan-*-dump directives
need to gain "-all" or "-optimized" suffixes to -fdump-ipa-inline.

The use of %C throughout also slightly changes the dump format for
several messages, e.g. changing:

 Inlining void inline_me(char*) into int main(int, char**).

to:

../../src/gcc/testsuite/g++.dg/tree-ssa/inline-1.C:13:8: optimized:  Inlining
void inline_me(char*)/0 into int main(int, char**)/2.

amongst other things adding "/order" suffixes to the cgraph node
names.

gcc/ChangeLog:
PR ipa/86395
* doc/invoke.texi (-fdump-ipa-): Document the "-optimized",
"-missed", "-note", and "-all" sub-options.
* ipa-inline.c (caller_growth_limits): Port from fprintf to dump
API.
(can_early_inline_edge_p): Likewise.
(want_early_inline_function_p): Likewise.
(want_inline_self_recursive_call_p): Likewise.
(recursive_inlining): Likewise.
(inline_small_functions): Likewise.
(flatten_function): Likewise.
(ipa_inline): Likewise.
(inline_always_inline_functions): Likewise.
(early_inline_small_functions): Likewise.
(early_inliner): Likewise.
* tree-inline.c (expand_call_inline): Likewise.

gcc/testsuite/ChangeLog:
PR ipa/86395
* g++.dg/ipa/devirt-12.C: Add "-all" suffix to
"-fdump-ipa-inline".
* g++.dg/ipa/imm-devirt-1.C: Add "-optimized" suffix to
"-fdump-tree-einline".
* g++.dg/tree-prof/inline_mismatch_args.C: Add "-all" suffix to
"-fdump-tree-einline".
* g++.dg/tree-ssa/inline-1.C: Add "-optimized" suffix to
"-fdump-tree-einline".
* g++.dg/tree-ssa/inline-2.C: Likewise.
* g++.dg/tree-ssa/inline-3.C: Likewise.
* g++.dg/tree-ssa/inline-4.C: New test, based on inline-1.C, but
using "-fopt-info-inline".
* gcc.dg/ipa/fopt-info-inline-1.c: New test.
* gcc.dg/ipa/inline-4.c:  Add "-all" suffix to
"-fdump-ipa-inline".  Add "-fopt-info-inline" and dg-optimized
directive.
* gcc.dg/ipa/inline-7.c: Add "-optimized" suffix to
"-fdump-tree-einline".  Add "-fopt-info-inline" and dg-optimized
directive.  Update scan-tree-dump-times to reflect /order
suffixes.
* gcc.dg/ipa/inlinehint-4.c: Update scan-tree-dump-times to
reflect /order suffixes.
* gcc.dg/plugin/dump-1.c: Add "-loop" to "-fopt-info-note" to
avoid getting extra messages from inliner.
* gcc.dg/plugin/dump-2.c: Likewise.
* gcc.dg/pr26570.c: Add dg-prune-output to ignore new
"function body not available" missed optimization messages.
* gcc.dg/pr71969-2.c: Update scan-tree-dump-times to reflect
/order suffixes.
* gcc.dg/pr71969-3.c: Likewise.
* gcc.dg/tree-ssa/inline-11.c: Add "-all" suffix to
"-fdump-tree-einline".
* gcc.dg/tree-ssa/inline-3.c: Add "-optimized" suffix to
"-fdump-tree-einline".  Update scan-tree-dump-times to reflect
/order suffixes.
* gcc.dg/tree-ssa/inline-4.c: Add "-optimized" suffix to
"-fdump-tree-einline".  Add "-fopt-info-inline" and dg-optimized
directive.
* gcc.dg/tree-ssa/inline-8.c: Add "-optimized" suffix to
"-fdump-tree-einline".
* gfortran.dg/pr79966.f90: Update scan-ipa-dump to reflect /order
suffixes.


Added:
trunk/gcc/testsuite/g++.dg/tree-ssa/inline-4.C
trunk/gcc/testsuite/gcc.dg/ipa/fopt-info-inline-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/invoke.texi
trunk/gcc/ipa-inline.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/ipa/devirt-12.C
trunk/gcc/testsuite/g++.dg/ipa/imm-devirt-1.C
trunk/gcc/testsuite/g++.dg/tree-prof/inline_mismatch_args.C
trunk/gcc/testsuite/g++.dg/tree-ssa/inline-1.C
trunk/gcc/testsuite/g++.dg/tree-ssa/inline-2.C
trunk/gcc/testsuite/g++.dg/tree-ssa/inline-3.C
trunk/gcc/testsuite/gcc.dg/ipa/inline-4.c
trunk/gcc/testsuite/gcc.dg/ipa/inline-7.c
trunk/gcc/testsuite/gcc.dg/ipa/inlinehint-4.c
trunk/gcc/testsuite/gcc.dg/plugin/dump-1.c
trunk/gcc/testsuite/gcc.dg/plugin/dump-2.c
  

[Bug c++/87934] [8/9 regression] struct with NSDMI of enum makes initialization a non-constant expression

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
commit d93ee6f87d421c95c873fe09445fc77cd8624a25
Author: jason 
Date:   Fri Jun 9 22:46:51 2017 +

Don't fold conversion from a constant variable.

* call.c (convert_like_real): Remove "inner" parameter.
Don't replace a constant with its value.
* cp-gimplify.c (cp_fully_fold): Use cp_fold_rvalue.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@249083
138bc75d-0d04-0410-961f-82ee72b054a4

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

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
(In reply to Eric Botcazou from comment #5)
> Thanks for the reduced testcase.

I thank you for the quick fix.

[Bug fortran/87943] New: [6.5 regression] severe regression on iso_varying_string (?)

[juergen.reuter at desy dot de]

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

Bug ID: 87943
   Summary: [6.5 regression] severe regression on
iso_varying_string (?)
   Product: gcc
   Version: 6.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

Created attachment 44976
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44976=edit
Reproducer

I put 6.4.1 as there is no option to choose 6.5.0.

This is a report on a severe regression (from our point of view) for the 6.5
(final?) version of the gfortran 6 series, so not sure whether it makes to
report. But you might close it as 'won't fix'. The attached reproducer is not
yet completely reduced, if you unpack and do 'make' it generates a dynamic
library external.Test.so (which is not really necessary) and an executable
whizard_test. Then execute this with 
$./whizard_test --check models 
This runs one of our unit tests, the tests models_3 and models_4 fail as the
strings for several objects have not been correctly read from file. In total, 
with gfortran 6.5, 19 of 128 unit tests fail and all non-skipped functional
tests fail with segmentation faults (236 of 278). The full code is here:
http://whizard.hepforge.org/whizard-2.6.4.tar.gz
You need OCaml to run all/most tests, just to ./configure; make; make check.
I wait for feedback before I attempt to possibly reduce the reproducer.

[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

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

--- Comment #5 from Eric Botcazou  ---
Thanks for the reduced testcase.

[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

--- Comment #4 from Eric Botcazou  ---
Author: ebotcazou
Date: Thu Nov  8 14:57:47 2018
New Revision: 265916

URL: https://gcc.gnu.org/viewcvs?rev=265916=gcc=rev
Log:
PR middle-end/87916
* cgraphclones.c (duplicate_thunk_for_node): Also set DECL_IGNORED_P.

Added:
trunk/gcc/testsuite/g++.dg/other/pr87916.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraphclones.c
trunk/gcc/testsuite/ChangeLog

[Bug c/87942] every int seems to be unaligned in packed structure

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #1 from Alexander Monakov  ---
(In reply to Johannes Vetter from comment #0)
> since version gcc version>=5 there seems to be a bug if pragma pack(1) is
> used. gcc thinks test.cmd is missaligned, but it isn't.
> 
> The code is ok in gcc version 4. The code with AND without pack(1) should be
> identical in this example.

No, it was a bug in version 4: since 'test' does not have an initializer, it
ends up as a common definition, which could be preempted at link time with a
normal definition with less-than-int alignment. Compiling with -fno-common
leads to desired code generation, as does providing an initializer:

test_t test = { 0 };

You can also add __attribute__((aligned(4))) on the struct type to make it
aligned (while still packed).

> It would be nice, if there is a compiler switch, which leeds into an error,
> if a volatile variable can't be read/write in one single access.

I think this makes sense.

[Bug c/87942] New: every int seems to be unaligned in packed structure

[johannes.vet...@dom-sicherheitstechnik.de]

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

Bug ID: 87942
   Summary: every int seems to be unaligned in packed structure
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johannes.vet...@dom-sicherheitstechnik.de
  Target Milestone: ---

testcode:

#pragma pack(1)
typedef struct
{
volatile int cmd;
} test_t;
#pragma pack(0)

test_t test;

int read32() 
{ 
test.cmd = 11;
return 0; 
}

host: win/linux x86_64
target: arm, STM32L471
gcc versions: 4.8.3 (ok), bugs in: 5.4.1, 6.3.0, 7.2.1, 8.2.0

---
since version gcc version>=5 there seems to be a bug if pragma pack(1) is used.
gcc thinks test.cmd is missaligned, but it isn't.

The code is ok in gcc version 4. The code with AND without pack(1) should be
identical in this example.

The inner code should be something like this:
mov r2, #11
str r2, [r3, #0]

but with pack(1):
mov r1, #11
mov r2, #0
ldr r3, .L3
ldrbr0, [r3]@ zero_extendqisi2
strbr1, [r3]
ldrbr1, [r3, #1]@ zero_extendqisi2
strbr2, [r3, #1]
ldrbr1, [r3, #2]@ zero_extendqisi2
strbr2, [r3, #2]
mov r0, r2
ldrbr1, [r3, #3]@ zero_extendqisi2
strbr2, [r3, #3]

The problem is that the variable in this case is a special function register of
the chip and have to be accessed in 32bit only. Every 8bit access to this
register crashes the system.

It would be nice, if there is a compiler switch, which leeds into an error, if
a volatile variable can't be read/write in one single access.

[Bug rtl-optimization/87941] New: by_pieces infra does not use movmisalign optab

[amonakov at gcc dot gnu.org]

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

Bug ID: 87941
   Summary: by_pieces infra does not use movmisalign optab
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
  Target Milestone: ---

by_pieces code uses only mov_optab, never checking movmisalign_optab, so on
STRICT_ALIGNMENT targets such as arm it does not use available misaligned
load/store patterns. It results in suboptimal code for e.g.

void f(char *c)
{
  __builtin_memcpy(c, "foo", 4);
}

where with -O2 -march=armv6t2 gcc emits

f:
movwr3, #:lower16:.LANCHOR0
mov r2, r0
movtr3, #:upper16:.LANCHOR0
ldr r0, [r3]
str r0, [r2]@ unaligned
bx  lr
.size   f, .-f
.section.rodata
.align  2
.set.LANCHOR0,. + 0
.LC0:
.ascii  "foo\000"

while optimal code is emitted for the equivalent

void f(char *c)
{
  int t;
  __builtin_memcpy(, "foo", 4);
  __builtin_memcpy(c, , 4);
}

f:
movwr3, #28518
movtr3, 111
str r3, [r0]@ unaligned
bx  lr
.size   f, .-f

[Bug tree-optimization/87940] [9 Regression] FAIL: gcc.dg/warn-strlen-no-nul.c

[edlinger at gcc dot gnu.org]

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

Bernd Edlinger  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-08
   Assignee|unassigned at gcc dot gnu.org  |edlinger at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Bernd Edlinger  ---
proposed patch: https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00325.html

[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

--- Comment #10 from Martin Liška  ---
> 
> 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.

Looks good to me, I've just sent patch candidate:
https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00568.html

[Bug tree-optimization/87940] New: [9 Regression] FAIL: gcc.dg/warn-strlen-no-nul.c

[hjl.tools at gmail dot com]

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

Bug ID: 87940
   Summary: [9 Regression] FAIL: gcc.dg/warn-strlen-no-nul.c
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: edlinger at gcc dot gnu.org
  Target Milestone: ---

On i686, r265778 caused:

/export/gnu/import/git/gcc-test-ia32/src-trunk/gcc/testsuite/gcc.dg/warn-strlen-no-nul.c:56:1:
internal compiler error: verify_gimple failed^M
0x8922dc4 verify_gimple_in_seq(gimple*)^M
../../src-trunk/gcc/tree-cfg.c:5082^M
0x86899d7 gimplify_body(tree_node*, bool)^M
../../src-trunk/gcc/gimplify.c:12859^M
0x8689b8b gimplify_function_tree(tree_node*)^M
../../src-trunk/gcc/gimplify.c:12949^M
0x84f7690 cgraph_node::analyze()^M
../../src-trunk/gcc/cgraphunit.c:667^M
0x84fa1d8 analyze_functions^M
../../src-trunk/gcc/cgraphunit.c:1126^M
0x84fadd3 symbol_table::finalize_compilation_unit()^M
../../src-trunk/gcc/cgraphunit.c:2833^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
Please include the complete backtrace with any bug report.^M
See  for instructions.^M
compiler exited with status 1
FAIL: gcc.dg/warn-strlen-no-nul.c (internal compiler error)

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

[renlin at gcc dot gnu.org]

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

--- Comment #6 from Renlin Li  ---
Created attachment 44975
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44975=edit
IRA dump

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

[renlin at gcc dot gnu.org]

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

--- Comment #5 from Renlin Li  ---
Created attachment 44974
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44974=edit
IRA dump

The code you want to check is the following in ira pass:
insn 10905: r1 = r2040
insn 208: use and update r1 with pre_modify
insn 191: use pseudo r2040

[Bug ada/87936] gnatlink fails with -pie

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries  ---
(In reply to Richard Biener from comment #1)
> I suppose it works when using -fPIC/-pic?

Using -fPIC:
...
$ rm -f hello.ali hello.o hello ; gnatmake -fPIC hello.adb 
gcc -c -fPIC hello.adb
gnatbind -x hello.ali
gnatlink hello.ali -fPIC
$ ./hello 
Hello, world!
...

using -fpic:
...
$ rm -f hello.ali hello.o hello ; gnatmake -fpic hello.adb 
gcc -c -fpic hello.adb
gnatbind -x hello.ali
gnatlink hello.ali -fpic
$ ./hello 
Hello, world!
...

[Bug ada/87936] gnatlink fails with -pie

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
I suppose it works when using -fPIC/-pic?

[Bug fortran/87937] [8/9 Regression] LHS reallocation broken inside "select type"

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |8.3

[Bug fortran/87939] New: Support STAT= and ERRMSG= specifiers to CRITICAL and TEAM statements

[weeks at iastate dot edu]

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

Bug ID: 87939
   Summary: Support STAT= and ERRMSG= specifiers to CRITICAL and
TEAM statements
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: weeks at iastate dot edu
  Target Milestone: ---

gcc/fortran/match.c appears to implement support for that STAT= and ERRMSG=
specifiers in LOCK, UNLOCK, SYNC ALL, SYNC IMAGES, and SYNC MEMORY statements
(as standardized by Fortran 2008), in addition to EVENT POST and EVENT WAIT
from the forthcoming Fortran 2018 standard.

gfortran currently lacks support for STAT= and ERRMSG= specifiers in several
statements where they will be allowed in Fortran 2018: FORM TEAM, CHANGE TEAM,
SYNC TEAM, END TEAM, CRITICAL, and END CRITICAL. It would be beneficial to add
these to gfortran to allow more comprehensive support for failed images in
OpenCoarrays.

[Bug fortran/87937] [8/9 Regression] LHS reallocation broken inside "select type"

[tomastrnka at gmx dot com]

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

--- Comment #4 from Tomáš Trnka  ---
Created attachment 44973
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44973=edit
Original tree dump after removing the offending check

[Bug fortran/87937] [8/9 Regression] LHS reallocation broken inside "select type"

[tomastrnka at gmx dot com]

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

--- Comment #3 from Tomáš Trnka  ---
Created attachment 44972
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44972=edit
Original tree dump from 8.2.1 20181011

[Bug fortran/87937] [8/9 Regression] LHS reallocation broken inside "select type"

[tomastrnka at gmx dot com]

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

--- Comment #2 from Tomáš Trnka  ---
(In reply to Dominique d'Humieres from comment #1)
> > The code to allocate t%x is simply never generated.
> 
> How do you see that?
> 
> WORKSFORME on darwin.

Weird, I wouldn't expect the frontend to behave in a platform-specific way.
What version are you using to test? (8.2.0 is not affected. I haven't actually
tried it with 9, but AFAICS the code is the same.)

Running "gfortran -fdump-tree-original lhsalloc.f90" with and without the
associate_var check produces the two attached files, with the allocation
obviously missing from the bad one.

[Bug fortran/87625] [OOP] (re)allocate on assignment fails for polymorphic array

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #5 from Dominique d'Humieres  ---
This seems fixed on trunk (9.0). Will r265283 be back ported?

[Bug fortran/87937] [8/9 Regression] LHS reallocation broken inside "select type"

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-11-08
 Ever confirmed|0   |1

[Bug fortran/87937] [8/9 Regression] LHS reallocation broken inside "select type"

[dominiq at lps dot ens.fr]

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

--- Comment #1 from Dominique d'Humieres  ---
> The code to allocate t%x is simply never generated.

How do you see that?

WORKSFORME on darwin.

[Bug ada/87938] New: libgnat.a not compiled with -fno-PIC

[vries at gcc dot gnu.org]

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

Bug ID: 87938
   Summary: libgnat.a not compiled with -fno-PIC
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

We build two versions of libgnat.a: libgnat.a and libgnat_pic.a.

The libgnat_pic.a is compiled with -fpic (more precisely, with
PICFLAG_FOR_TARGET).

But libgnat.a is compiled with whatever the default is, so if gcc defaults to
-pie -fPIE, then libgnat.a is compiled with -fPIE.  My guess is that we want to
build libgnat.a with -fno-PIE/-fno-pie.

[Bug c++/87935] [9 regression] new failures on arm since r265788

[clyon at gcc dot gnu.org]

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

--- Comment #1 from Christophe Lyon  ---
It also causes:
FAIL: g++.dg/cpp0x/pr83734.C  -std=gnu++14 (internal compiler error)
FAIL: g++.dg/cpp0x/pr83734.C  -std=gnu++17 (internal compiler error)

[Bug fortran/87937] New: [8/9 Regression] LHS reallocation broken inside "select type"

[tomastrnka at gmx dot com]

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

Bug ID: 87937
   Summary: [8/9 Regression] LHS reallocation broken inside
"select type"
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tomastrnka at gmx dot com
  Target Milestone: ---

The fix for pr85954 broke LHS reallocation inside "select type" blocks. The
following program segfaults with current 8.2 branch (including the system
compiler 8.2.1 20181011 on my Fedora 29):

program lhsalloc
   type, abstract :: A
  real, allocatable :: x(:)
   end type

   type, extends(A) :: B
   end type

   class(A), allocatable :: t
   real :: y(4)

   y = 1

   allocate(B::t)

   select type (t)
   type is (B)
  t%x = y
   end select

   write(*,*) allocated(t%x)
end program

The code to allocate t%x is simply never generated.

Partially reverting the offending change by removing these two lines from
gfc_is_reallocatable_lhs fixes the issue:

if (sym->attr.associate_var)
  return false;

Although pr87625 sounds related, its fix doesn't help here because the
associate_var check comes earlier.

[Bug ada/87936] New: gnatlink fails with -pie

[vries at gcc dot gnu.org]

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

Bug ID: 87936
   Summary: gnatlink fails with -pie
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Consider the following testcase:
...
$ cat hello.adb 
with Ada.Text_IO;

procedure Hello is
begin
   Ada.Text_IO.Put_Line("Hello, world!");
end Hello;
...

It compiles without problems:
...
$ rm -f hello.ali hello.o hello ; gnatmake hello.adb
gcc -c hello.adb
gnatbind -x hello.ali
gnatlink hello.ali
...

and works fine:
...
delia:~ # ./hello 
Hello, world!
...

However, when we try to compile with -fPIE -pie, we get:
...
$ rm -f hello.ali hello.o hello ; gnatmake -fPIE hello.adb -largs -pie 
gcc -c -fPIE hello.adb
gnatbind -x hello.ali
gnatlink hello.ali -fPIE -pie
/usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/bin/ld:
/usr/lib64/gcc/x86_64-suse-linux/8/adalib/libgnat.a(a-contai.o): relocation
R_X86_64_32 against symbol `ada__containers__capacity_error' can not be used
when making a PIE object; recompile with -fPIC
   ...
/usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/bin/ld: final
link failed: nonrepresentable section on output
collect2: error: ld returned 1 exit status
gnatlink: error when calling /usr/bin/gcc
gnatmake: *** link failed.
...

The problem is that libgnat.a is picked up instead of libgnat_pic.a, so a
workaround is to add -lgnat_pic:
...
$ rm -f hello.ali hello.o hello ; gnatmake -fPIE hello.adb -largs -pie
-lgnat_pic
$ ./hello 
Hello, world!
...

AFAIU, gnatlink should include libgnat_pic.a instead of libgnat.a when passed
the -pie option.

[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 #7 from Alexandre Oliva  ---
https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00533.html

[Bug tree-optimization/87929] ICE in verify_gimple failed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||9.0
 Resolution|--- |FIXED

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Thu Nov  8 10:47:59 2018
New Revision: 265912

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

PR tree-optimization/87929
* tree-complex.c (expand_complex_comparison): Clean EH.

* gcc.dg/pr87929.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/pr87929.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-complex.c

[Bug tree-optimization/87929] ICE in verify_gimple failed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||9.0
 Resolution|--- |FIXED

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

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

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||ktietz at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Uroš Bizjak  ---
(In reply to Martin Liška from comment #0)
> 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

This happens in i386.c:

--cut here--
  /* 64-bit MS ABI seem to require stack alignment to be always 16,
 except for function prologues, leaf functions and when the defult
 incoming stack boundary is overriden at command line or via
 force_align_arg_pointer attribute.  */
  if ((TARGET_64BIT_MS_ABI && crtl->preferred_stack_boundary < 128)
  && (!crtl->is_leaf || cfun->calls_alloca != 0
  || ix86_current_function_calls_tls_descriptor
  || ix86_incoming_stack_boundary < 128))
{
  crtl->preferred_stack_boundary = 128;
  crtl->stack_alignment_needed = 128;
}

  stack_alignment_needed = crtl->stack_alignment_needed / BITS_PER_UNIT;
  preferred_alignment = crtl->preferred_stack_boundary / BITS_PER_UNIT;

  gcc_assert (!size || stack_alignment_needed);
  gcc_assert (preferred_alignment >= STACK_BOUNDARY / BITS_PER_UNIT);
  gcc_assert (preferred_alignment <= stack_alignment_needed);
--cut here--

Where TARGET_64BIT_MS_ABI gets defined as:

#define TARGET_64BIT_MS_ABI (TARGET_64BIT && ix86_cfun_abi () == MS_ABI)

and STACK_BOUNDARY:

#define STACK_BOUNDARY \
  (TARGET_64BIT && ix86_abi == MS_ABI ? 128 : BITS_PER_WORD)

Please note that the former definition depends on ix86_cfun_abi, which depends
on __attribute__(([sysv_abi|ms_abi])), while the later depends on ix86_abi
global variable. In the testcase, ix86_cfun_abi () returns SYSV_ABI due to
function __attribute__ override, while ix86_abi returns MS_ABI.

The following patch redefines STACK_BOUNDARY to:

 #define STACK_BOUNDARY \
- (TARGET_64BIT && ix86_abi == MS_ABI ? 128 : BITS_PER_WORD)
+  (TARGET_64BIT && ix86_cfun_abi () == MS_ABI ? 128 : BITS_PER_WORD)

so, STACK_BOUNDARY now also depends on function __attribute__.

The patch also removes unneeded redefinition of STACK_BOUNDARY from cygming.h.

--cut here--
diff --git a/gcc/config/i386/cygming.h b/gcc/config/i386/cygming.h
index d7c7dd7057bf..0a3c9a0dd401 100644
--- a/gcc/config/i386/cygming.h
+++ b/gcc/config/i386/cygming.h
@@ -268,9 +268,6 @@ do {\
bytes in one go.  */
 #define CHECK_STACK_LIMIT 4000

-#undef STACK_BOUNDARY
-#define STACK_BOUNDARY (TARGET_64BIT && ix86_abi == MS_ABI ? 128 :
BITS_PER_WORD)
-
 /* By default, target has a 80387, uses IEEE compatible arithmetic,
returns float values in the 387 and needs stack probes.
We also align doubles to 64-bits for MSVC default compatibility.  */
diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
index 58caab2bb55b..a85b43134092 100644
--- a/gcc/config/i386/i386.h
+++ b/gcc/config/i386/i386.h
@@ -808,7 +808,7 @@ extern const char *host_detect_local_cpu (int argc, const
char **argv);

 /* Boundary (in *bits*) on which stack pointer should be aligned.  */
 #define STACK_BOUNDARY \
- (TARGET_64BIT && ix86_abi == MS_ABI ? 128 : BITS_PER_WORD)
+  (TARGET_64BIT && ix86_cfun_abi () == MS_ABI ? 128 : BITS_PER_WORD)

 /* Stack boundary of the main function guaranteed by OS.  */
 #define MAIN_STACK_BOUNDARY (TARGET_64BIT ? 128 : 32)
--cut here--

Adding Kai to CC. The patch also needs to be tested on Windows targets.

[Bug c++/87935] [9 regression] new failures on arm since r265788

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
Version|6.4.1   |9.0
   Target Milestone|--- |9.0

[Bug c++/87935] New: [9 regression] new failures on arm since r265788

[clyon at gcc dot gnu.org]

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

Bug ID: 87935
   Summary: [9 regression] new failures on arm since r265788
   Product: gcc
   Version: 6.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

Hi Jason,

Since r265788, I've noticed regressions on arm targets:
FAIL: g++.dg/cpp0x/constexpr-static.C  -std=gnu++14  scan-assembler-not
static_initialization
FAIL: g++.dg/cpp0x/constexpr-static.C  -std=gnu++17  scan-assembler-not
static_initialization
FAIL: g++.dg/cpp0x/constexpr-static12.C  -std=c++14  scan-assembler-not
_ZNSt10unique_ptrC1Ei
FAIL: g++.dg/cpp0x/constexpr-static12.C  -std=c++17  scan-assembler-not
_ZNSt10unique_ptrC1Ei
FAIL: g++.dg/cpp0x/constexpr-static3.C  -std=gnu++14  scan-assembler-not
static_initialization
FAIL: g++.dg/cpp0x/constexpr-static3.C  -std=gnu++17  scan-assembler-not
static_initialization
FAIL: g++.dg/cpp0x/implicit13.C  -std=c++14  scan-assembler-not _ZN1BC1Ev
FAIL: g++.dg/cpp0x/implicit13.C  -std=c++17  scan-assembler-not _ZN1BC1Ev
FAIL: g++.dg/cpp0x/pr83734.C  -std=gnu++14 (test for excess errors)
FAIL: g++.dg/cpp0x/pr83734.C  -std=gnu++17 (test for excess errors)
FAIL: g++.dg/cpp1y/constexpr-empty3.C  -std=c++14  scan-assembler-not
static_init
FAIL: g++.dg/cpp1y/constexpr-empty3.C  -std=c++17  scan-assembler-not
static_init

[Bug web/87933] Bad headers and titles for:

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
Using:

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index be9b07b5d23..b82594bd28e 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -2,7 +2,6 @@
 @c @ifnothtml
 @c %**start of header
 @setfilename gccinstall.info
-@settitle Installing GCC
 @setchapternewpage odd
 @c %**end of header
 @c @end ifnothtml

fixes the problem with HTML pages.

Btw. what does it mean:

\input texinfo.tex@c -*-texinfo-*-
@c @ifnothtml <- this
@c %**start of header
@setfilename gccinstall.info
@settitle Installing GCC
@setchapternewpage odd
@c %**end of header
@c @end ifnothtml

?

[Bug web/87933] Bad headers and titles for:

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
(In reply to Andreas Schwab from comment #5)
> Nope, the first one is unconditional.

You're right:
...
define = indexhtml
/home/marxin/Programming/gcc/gcc/doc/install.texi:14: warning: multiple
@settitle
define = specifichtml
/home/marxin/Programming/gcc/gcc/doc/install.texi:17: warning: multiple
@settitle
...

[Bug middle-end/50481] builtin to reverse the bit order

[hoganmeier at gmail dot com]

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

--- Comment #4 from krux  ---
+1
The builtins already produce better code than a generic bitreverse
implementation:
https://godbolt.org/z/Um2Tit

But using special hardware instructions automatically is even more important
imho.

[Bug web/87933] Bad headers and titles for:

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

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

--- Comment #6 from Andreas Schwab  ---
Most like this is a texinfo 4 vs 5+ difference.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||sebpop at gmail dot com

--- Comment #2 from Richard Biener  ---
I get:

during GIMPLE pass: ldist
pr34635.c: In function ‘foo’:
pr34635.c:4:6: internal compiler error: tree check: expected integer_cst, have
polynomial_chrec in int_cst_value, at tree.c:11188
4 | void foo(int x[])
  |  ^~~
0x1397ffc tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/tmp/trunk/gcc/tree.c:9371
0x83e3a7 tree_int_cst_elt_check(tree_node const*, int, char const*, int, char
const*)
/tmp/trunk/gcc/tree.h:3307
0x13a0e5b int_cst_value(tree_node const*)
/tmp/trunk/gcc/tree.c:11188

#11 0x010cf399 in get_data_dependence (rdg=0x2816ba0, a=0x2817830, 
b=0x28170c0) at /tmp/trunk/gcc/tree-loop-distribution.c:1188
1188  compute_affine_dependence (ddr, loop_nest[0]);
(gdb) l
1183  ent.b = b;
1184  slot = ddrs_table->find_slot (, INSERT);
1185  if (*slot == NULL)
1186{
1187  ddr = initialize_data_dependence_relation (a, b, loop_nest);
1188  compute_affine_dependence (ddr, loop_nest[0]);
1189  *slot = ddr;
1190}
(gdb) p debug_data_reference (a)
#(Data Ref: 
#  bb: 3 
#  stmt: _8 = *_4;
#  ref: *_4;
#  base_object: *x_22(D);
#  Access function 0: {0B, +, {0, +, 4}_1}_2
#)
$6 = void
(gdb) p debug_data_reference (b)
#(Data Ref: 
#  bb: 3 
#  stmt: *_7 = _8;
#  ref: *_7;
#  base_object: *x_22(D);
#  Access function 0: {0B, +, 4}_1
#)

so we have an "invariant" access and a variant one.

I think

  else if (evolution_function_is_affine_multivariate_p (chrec_a,
loop_nest->num)
   && !chrec_contains_symbols (chrec_a)
   && evolution_function_is_affine_multivariate_p (chrec_b,
loop_nest->num)
   && !chrec_contains_symbols (chrec_b))
{
  /* testsuite/.../ssa-chrec-35.c
 {0, +, 1}_2  vs.  {0, +, 1}_3
 the overlapping elements are respectively located at iterations:
 {0, +, 1}_x and {0, +, 1}_x,
 in other words, we have the equality:
 {0, +, 1}_2 ({0, +, 1}_x) = {0, +, 1}_3 ({0, +, 1}_x)

 Other examples:
 {{0, +, 1}_1, +, 2}_2 ({0, +, 1}_x, {0, +, 1}_y) =
 {0, +, 1}_1 ({{0, +, 1}_x, +, 2}_y)

 {{0, +, 2}_1, +, 3}_2 ({0, +, 1}_y, {0, +, 1}_x) =
 {{0, +, 3}_1, +, 2}_2 ({0, +, 1}_x, {0, +, 1}_y)
  */
  analyze_subscript_affine_affine (chrec_a, chrec_b,
   overlaps_a, overlaps_b, last_conflicts);


is not properly guarded.  evolution_function_is_affine_multivariate_p
lets this through via

bool
evolution_function_is_affine_multivariate_p (const_tree chrec, int loopnum)
{
  if (chrec == NULL_TREE)
return false;

  switch (TREE_CODE (chrec))
{
case POLYNOMIAL_CHREC:
  if (evolution_function_is_invariant_rec_p (CHREC_LEFT (chrec), loopnum))
{
  if (evolution_function_is_invariant_rec_p (CHREC_RIGHT (chrec),
loopnum))
return true;
  else
{
  if (TREE_CODE (CHREC_RIGHT (chrec)) == POLYNOMIAL_CHREC
  && CHREC_VARIABLE (CHREC_RIGHT (chrec))
 != CHREC_VARIABLE (chrec)
  && evolution_function_is_affine_multivariate_p
  (CHREC_RIGHT (chrec), loopnum))

but as we are interested in loopnum == 1 for {0, +, {0, +, 4}_1}_2
we have to exclude the case where CHREC_RIGHT variates in it.

Whatever exactly a affine multivariate is...

Sebastian - can you say if

 evolution_function_is_affine_multivariate_p ({0, +, {0, +, 4}_1}_2, 1)

should really return true?

[Bug web/87933] Bad headers and titles for:

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

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

--- Comment #5 from Andreas Schwab  ---
Nope, the first one is unconditional.

[Bug web/87933] Bad headers and titles for:

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
Sure, but it looks conditional:

@c Specify title for specific html page
@ifset indexhtml
@settitle Installing GCC
@end ifset
@ifset specifichtml
@settitle Host/Target specific installation notes for GCC
@end ifset
@ifset prerequisiteshtml
@settitle Prerequisites for GCC
@end ifset
@ifset downloadhtml
@settitle Downloading GCC
@end ifset
@ifset configurehtml
@settitle Installing GCC: Configuration
@end ifset
@ifset buildhtml
@settitle Installing GCC: Building
@end ifset
@ifset testhtml
@settitle Installing GCC: Testing
@end ifset
@ifset finalinstallhtml
@settitle Installing GCC: Final installation
@end ifset
@ifset binarieshtml
@settitle Installing GCC: Binaries
@end ifset
@ifset oldhtml
@settitle Installing GCC: Old documentation
@end ifset
@ifset gfdlhtml
@settitle Installing GCC: GNU Free Documentation License
@end ifset

Issue is that I don't see any recent change in git log -p and I know it used to
be right.

[Bug web/87933] Bad headers and titles for:

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

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

--- Comment #3 from Andreas Schwab  ---
The first @settitle wins.

$ grep @settitle gcc/doc/install.texi
@settitle Installing GCC
@settitle Installing GCC
@settitle Host/Target specific installation notes for GCC
@settitle Prerequisites for GCC
@settitle Downloading GCC
@settitle Installing GCC: Configuration
@settitle Installing GCC: Building
@settitle Installing GCC: Testing
@settitle Installing GCC: Final installation
@settitle Installing GCC: Binaries
@settitle Installing GCC: Old documentation
@settitle Installing GCC: GNU Free Documentation License

[Bug tree-optimization/87925] [missed-optimization] Distinct-value if-then-else chains treated differently than switch statements

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
(In reply to Eyal Rozenberg from comment #5)
> (In reply to Martin Liška from comment #3)
> > Currently we only do switch -> balanced decision tree (read series of
> > if-then-else statements). Well definitely a potentially enhancement,
> > question is whether it worth doing that..
> 
> That is a question for another bug. I'm just saying that these two cases (or
> some expansion thereof, e.g. with some fallthrough on the case side, or with
> several distinct values in each if statement) should be treated the same.
> i.e. whatever optimizations are considered for one of them should be
> considered for the other.

Sure, agree with that.

> 
> (In reply to Martin Liška from comment #4)
> > This is not problem because it's a const expression that is evaluate in C++
> > front-end. Thus you don't get any penalty.
> 
> The specific use example at the link is a static_assert, but the in()
> function there works with runtime values as well. So - not just compile-time
> computation. Another example - un-type-erasure dispatches, which may go into
> tight loops: https://stackoverflow.com/a/38924396/1593077

Indeed.

[Bug tree-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

--- Comment #5 from Eyal Rozenberg  ---
(In reply to Martin Liška from comment #3)
> Currently we only do switch -> balanced decision tree (read series of
> if-then-else statements). Well definitely a potentially enhancement,
> question is whether it worth doing that..

That is a question for another bug. I'm just saying that these two cases (or
some expansion thereof, e.g. with some fallthrough on the case side, or with
several distinct values in each if statement) should be treated the same. i.e.
whatever optimizations are considered for one of them should be considered for
the other.

(In reply to Martin Liška from comment #4)
> This is not problem because it's a const expression that is evaluate in C++
> front-end. Thus you don't get any penalty.

The specific use example at the link is a static_assert, but the in() function
there works with runtime values as well. So - not just compile-time
computation. Another example - un-type-erasure dispatches, which may go into
tight loops: https://stackoverflow.com/a/38924396/1593077

[Bug web/87933] Bad headers and titles for:

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Hm, then it looks title after ':' is stripped:

$ grep 'Installing GCC: ' gcc/doc/install.texi
@settitle Installing GCC: Configuration
@settitle Installing GCC: Building
@settitle Installing GCC: Testing
@settitle Installing GCC: Final installation
@settitle Installing GCC: Binaries
@settitle Installing GCC: Old documentation
@settitle Installing GCC: GNU Free Documentation License
@chapter Installing GCC: Configuration
@cindex Installing GCC: Configuration
@cindex Installing GCC: Building
@chapter Installing GCC: Testing
@cindex Installing GCC: Testing
@chapter Installing GCC: Final installation
@chapter Installing GCC: Binaries
@cindex Installing GCC: Binaries

[Bug web/87933] Bad headers and titles for:

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||documentation

--- Comment #1 from Richard Biener  ---
They are generated from texinfo install.texi sources so that's probably
"intended" or a texinfo bug?

[Bug c++/87934] [8/9 regression] struct with NSDMI of enum makes initialization a non-constant expression

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-08
  Known to work||7.3.1
   Target Milestone|--- |8.3
Summary|[8 regression] struct with  |[8/9 regression] struct
   |NSDMI of enum makes |with NSDMI of enum makes
   |initialization a|initialization a
   |non-constant expression |non-constant expression
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  It passes with -std=c++11.

[Bug tree-optimization/87931] [9 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:6193 since r265876

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Mine.

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

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
(In reply to Eyal Rozenberg from comment #0)
> 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.

Agree with that, but I would say that when having a lot of cases, switch is
more
natural constructor. The code looks nicer ;)

> 
> 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

This is not problem because it's a const expression that is evaluate in C++
front-end.
Thus you don't get any penalty.

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

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #3 from Martin Liška  ---
(In reply to Richard Biener from comment #2)
> IIRC there was some work turning if-then-else chains into switches (and
> possibly back to a tree)

Currently we only do switch -> balanced decision tree (read series of
if-then-else statements). Well definitely a potentially enhancement, question
is whether it worth doing that..

[Bug tree-optimization/87929] ICE in verify_gimple failed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-08
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Looks like some folding happens but we forget to cleanup stmts.  Mine.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.4

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Blocks||56456

--- Comment #2 from Richard Biener  ---
Please use -Wno-error=array-bounds instead of disabling _all_ errors.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-08
 CC||marxin at gcc dot gnu.org
  Component|rtl-optimization|tree-optimization
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
IIRC there was some work turning if-then-else chains into switches (and
possibly back to a tree)

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
I think we have some duplicates here.  dependence analysis use of int_cst_value
is fishy and it doesn't properly guard any of its inputs for its internal use
of 'int' as the underlying type for dependence distances... (think of
overflows,
etc.):

static tree
initialize_matrix_A (lambda_matrix A, tree chrec, unsigned index, int mult)
{
  gcc_assert (chrec);

  switch (TREE_CODE (chrec))
{
case POLYNOMIAL_CHREC:
  A[index][0] = mult * int_cst_value (CHREC_RIGHT (chrec));
  return initialize_matrix_A (A, CHREC_LEFT (chrec), index + 1, mult);

If CHREC_RIGHT doesn't fit in an 'int' or if multiplying by mult overflows
we're doomed (wrong-code, etc.).  Making the lambda matrix entries
gmp values or widest_ints might be the (expensive) solution here.

int_cst_value needs a better name btw...

As said, there are dups.

[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

  Attachment #44970|0   |1
is obsolete||

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

This one does not regress pr49095 with -m32, but -m64 scan-assembler-times
fails before and after.