[Bug c++/82226] New: previously instantiation of template type breaks future use

[john at mcfarlane dot name]

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

Bug ID: 82226
   Summary: previously instantiation of template type breaks
future use
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john at mcfarlane dot name
  Target Milestone: ---

The following fragment fails to compile because the second `static_assert`
fires incorrectly. Removing the first `static_assert` causes the code to
compile successfully.

#include 

template
struct constant {
static constexpr decltype(Value) value{};
};

// if this line is commented out, the last line compiles OK
static_assert(!constant<0>::value);

static_assert(std::is_same_v::value)>);

Setup: CompilerExplorer with x86-64 GCC 7.1.0 and 7.2.0
(https://godbolt.org/g/KE9uXB) and on Intel(R) Xeon(R) CPU E5-2676 v3 with GCC
7.2.0 compiled from source.

Flags: -std=c++17

Result: second static_assert fails because the `decltype` expression resolves
to `int`.

Expected: `decltype` result should be `long`. The first `static_assert`
statement should not influence the second.

Notes:
1. The type of the literal used in the first `static_assert` seems to determine
the type to which the second `decltype` resolves. For instance, replacing `0`
with `0LL` and `long` with `long long` prevents the compiler error.
2. Observer the operators used in both `static_assert` statements: `!` and `+`.
These are necessary. Other operators will cause the error but without
operators, there is no error.

[Bug inline-asm/82225] New: Unexpected nondeterministic "internal compiler error: Segmentation fault" when gcc is expected to save either rsp or rbp to allow its use in inline asm

[jasongross9+bugzilla at gmail dot com]

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

Bug ID: 82225
   Summary: Unexpected nondeterministic "internal compiler error:
Segmentation fault" when gcc is expected to save
either rsp or rbp to allow its use in inline asm
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jasongross9+bugzilla at gmail dot com
  Target Milestone: ---

Created attachment 42185
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42185=edit
.tgz containing the c code

This bug only shows up on some runs of gcc (maybe 70% of them).  It does not
show up when I compile the .i files emitted by -save-temps, so far as I can
tell.

gcc is installed from the ubuntu package gcc-7

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
7.2.0-1ubuntu1~16.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.2.0 (Ubuntu 7.2.0-1ubuntu1~16.04) 

$ uname -a
Linux jgross-Leopard-WS 4.4.0-66-generic #87-Ubuntu SMP Fri Mar 3 15:29:05 UTC
2017 x86_64 x86_64 x86_64 GNU/Linux

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 16.04.2 LTS
Release:16.04
Codename:   xenial

$ gcc -o measure -I liblow measure.c scalarmult_noladderstep.c
femul_scheduled.c -D UUT=crypto_scalarmult_bench
scalarmult_noladderstep.c:97:1: warning: always_inline function might not be
inlinable [-Wattributes]
 fmul(felem output, const felem in2, const felem in) {
 ^~~~
In file included from scalarmult_noladderstep.c:32:0:
femul.h:6:19: warning: always_inline function might not be inlinable
[-Wattributes]
 void force_inline femul(uint64_t* out, uint64_t x10, uint64_t x11, uint64_t
x9, uint64_t x7, uint64_t x5, uint64_t x18, uint64_t x19, uint64_t x17,
uint64_t x15, uint64_t x13);
   ^
scalarmult_noladderstep.c: In function ‘fmul’:
femul.h:6:19: error: inlining failed in call to always_inline ‘femul’: function
body not available
scalarmult_noladderstep.c:99:3: note: called from here
   femul(out,
   ^~
   in2[4], in2[3], in2[2], in2[1], in2[0],
   ~~~
   in[4], in[3], in[2], in[1], in[0]);
   ~~
femul_scheduled.c:19:19: warning: always_inline function might not be inlinable
[-Wattributes]
 void force_inline femul(uint64_t* out, uint64_t x10, uint64_t x11, uint64_t
x9, uint64_t x7, uint64_t x5, uint64_t x18, uint64_t x19, uint64_t x17,
uint64_t x15, uint64_t x13) {
   ^
femul_scheduled.c: In function ‘femul’:
femul_scheduled.c:221:1: internal compiler error: Segmentation fault
 }
 ^
0x9e0c5f crash_signal
../../src/gcc/toplev.c:337
0x8b6cd0 lra_eliminate_reg_if_possible(rtx_def**)
../../src/gcc/lra-eliminations.c:1385
0x8a66c6 address_eliminator
../../src/gcc/lra-constraints.c:362
0x8a67d5 satisfies_address_constraint_p
../../src/gcc/lra-constraints.c:411
0x8ae3c9 satisfies_address_constraint_p
../../src/gcc/lra-constraints.c:423
0x8ae3c9 process_alt_operands
../../src/gcc/lra-constraints.c:2274
0x8ae3c9 curr_insn_transform
../../src/gcc/lra-constraints.c:3848
0x8b098e lra_constraints(bool)
../../src/gcc/lra-constraints.c:4847
0x89fe84 lra(_IO_FILE*)
../../src/gcc/lra.c:2392
0x85e0e1 do_reload
../../src/gcc/ira.c:5472
0x85e0e1 execute
../../src/gcc/ira.c:5656
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

With -v -save-temps:

$ gcc -v -save-temps -o measure -I liblow measure.c scalarmult_noladderstep.c
femul_scheduled.c -D UUT=crypto_scalarmult_bench
Using 

[Bug target/79868] aarch64: diagnostic "malformed target %s value" not translateable

[sje at gcc dot gnu.org]

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

Steve Ellcey  changed:

   What|Removed |Added

 CC||sje at gcc dot gnu.org

--- Comment #6 from Steve Ellcey  ---
Created attachment 42184
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42184=edit
Proposed patch

Roland, does this patch look like it will fix your translation problems?  If so
I can submit it to gcc-patches.

[Bug target/82221] internal compiler error: in print_reg, at config/i386/i386.c:17656

[jpoimboe at redhat dot com]

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

--- Comment #16 from Josh Poimboeuf  ---
Ok.  I thought you were saying that, with your new patch, putting "sp" in
clobbers would *always* force DRAP, even in cases where the function doesn't
need realignment.

If you're *not* saying that, then it sounds good :-)

Either way I'll try the patch out next week and see what it does.

[Bug target/82221] internal compiler error: in print_reg, at config/i386/i386.c:17656

[hjl.tools at gmail dot com]

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

--- Comment #15 from H.J. Lu  ---
(In reply to Josh Poimboeuf from comment #14)
> (In reply to H.J. Lu from comment #13)
> > (In reply to Josh Poimboeuf from comment #12)
> > > I would like to clarify that most of the time, when we use "sp" in the
> > > clobbers list, the stack does *not* need to be realigned.  And in those
> > 
> > Yes, stack alignment may be needed due to:
> > 
> > typedef struct {
> >  u64 __attribute__((aligned(8))) counter;
> > } atomic64_t;
> > 
> > with -mpreferred-stack-boundary=2.
> 
> Yes, in the above example that is true.  However there are many more cases
> in the kernel where we want to use the "sp" clobbers, where stack alignment
> is not needed.

DRAP is used only when stack realignment may be needed.  If the code doesn't
need more 4 byte alignment on stack, you won't run into this issue at all.

[Bug target/82221] internal compiler error: in print_reg, at config/i386/i386.c:17656

[jpoimboe at redhat dot com]

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

--- Comment #14 from Josh Poimboeuf  ---
(In reply to H.J. Lu from comment #13)
> (In reply to Josh Poimboeuf from comment #12)
> > I would like to clarify that most of the time, when we use "sp" in the
> > clobbers list, the stack does *not* need to be realigned.  And in those
> 
> Yes, stack alignment may be needed due to:
> 
> typedef struct {
>  u64 __attribute__((aligned(8))) counter;
> } atomic64_t;
> 
> with -mpreferred-stack-boundary=2.

Yes, in the above example that is true.  However there are many more cases in
the kernel where we want to use the "sp" clobbers, where stack alignment is not
needed.

[Bug target/82221] internal compiler error: in print_reg, at config/i386/i386.c:17656

[hjl.tools at gmail dot com]

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

--- Comment #13 from H.J. Lu  ---
(In reply to Josh Poimboeuf from comment #12)
> I would like to clarify that most of the time, when we use "sp" in the
> clobbers list, the stack does *not* need to be realigned.  And in those

Yes, stack alignment may be needed due to:

typedef struct {
 u64 __attribute__((aligned(8))) counter;
} atomic64_t;

with -mpreferred-stack-boundary=2.

[Bug target/82221] internal compiler error: in print_reg, at config/i386/i386.c:17656

[jpoimboe at redhat dot com]

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

--- Comment #12 from Josh Poimboeuf  ---
While I know about DRAP, I'm otherwise not very familiar with GCC internals, so
I don't quite understand your points.

I would like to clarify that most of the time, when we use "sp" in the clobbers
list, the stack does *not* need to be realigned.  And in those cases, we would
*not* want DRAP, because it's not needed.  We would instead just want the
normal frame pointer setup.

For cases where the stack pointer *does* need to be realigned, DRAP is fine.

I can try out your patch next week to see what changes it makes to the
generated code.  Thanks!

[Bug rtl-optimization/63281] powerpc64le creates 64 bit constants from scratch instead of loading them

[kelvin at gcc dot gnu.org]

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

kelvin at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kelvin at gcc dot gnu.org

--- Comment #6 from kelvin at gcc dot gnu.org ---
It appears that Alan's proposed patches will "improve" the generated code, but
those patches were never proposed for incoporation into the trunk.  Can Alan
clarify his thoughts on this?

I can incorporate those patches and do the regression testing if we think
that's desirable.  But it seems that we might not have consensus on what should
be done here.

[Bug c/82224] Strict-aliasing not noticing valid aliasing of two unions with active members

[myriachan at gmail dot com]

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

--- Comment #3 from Melissa  ---
(In reply to Andrew Pinski from comment #1)
> See PR 14319 which I think this is a dup of.

PR 14319 refers to a case in which you are allowed to read the common prefix of
a structure when the structure is not the active member of the union.

In this report, however, it is never the case that an inactive member is
accessed.  Instead, it appears that GCC isn't aware of aliasing of two pointers
when it comes to tracking which is the active member.

Melissa

[Bug fortran/82205] parametrized derived types, problems with initialization

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-15
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed.

[Bug middle-end/82223] Incorrect optimization for lossy round trips of arithmetic types

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
invalid as explained.

[Bug c++/81314] [6/7/8 Regression] Undefined reference to a function with -fopenmp

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 15 21:42:20 2017
New Revision: 252864

URL: https://gcc.gnu.org/viewcvs?rev=252864=gcc=rev
Log:
Backported from mainline
2017-09-14  Jakub Jelinek  

PR c++/81314
* cp-gimplify.c (omp_var_to_track): Look through references.
(omp_cxx_notice_variable): Likewise.

* testsuite/libgomp.c++/pr81314.C: New test.

Added:
branches/gcc-6-branch/libgomp/testsuite/libgomp.c++/pr81314.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/cp-gimplify.c
branches/gcc-6-branch/libgomp/ChangeLog

[Bug target/82112] internal compiler error: in fold_convert_loc, at fold-const.c:2262

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 15 21:41:29 2017
New Revision: 252863

URL: https://gcc.gnu.org/viewcvs?rev=252863=gcc=rev
Log:
Backported from mainline
2017-09-12  Jakub Jelinek  

PR target/82112
* gcc.target/powerpc/pr82112.c: New test.
* g++.dg/ext/altivec-18.C: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/ext/altivec-18.C
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr82112.c
Modified:
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug target/82112] internal compiler error: in fold_convert_loc, at fold-const.c:2262

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 15 21:40:51 2017
New Revision: 252862

URL: https://gcc.gnu.org/viewcvs?rev=252862=gcc=rev
Log:
Backported from mainline
2017-09-12  Jakub Jelinek  

PR target/82112
* c-common.c (sync_resolve_size): Instead of c_dialect_cxx ()
assertion check that in the condition.
(get_atomic_generic_size): Likewise.  Before testing if parameter
has pointer type, if it has array type, call for C++
default_conversion to perform array-to-pointer conversion.

* c-c++-common/pr82112.c: New test.
* gcc.dg/pr82112.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/c-c++-common/pr82112.c
branches/gcc-6-branch/gcc/testsuite/gcc.dg/pr82112.c
Modified:
branches/gcc-6-branch/gcc/c-family/ChangeLog
branches/gcc-6-branch/gcc/c-family/c-common.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug middle-end/81768] [8 Regression] error: control flow in the middle of basic block

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 15 21:39:36 2017
New Revision: 252861

URL: https://gcc.gnu.org/viewcvs?rev=252861=gcc=rev
Log:
Backported from mainline
2017-09-05  Jakub Jelinek  

PR middle-end/81768
* omp-low.c (lower_omp_for): Recompute tree invariant if
gimple_omp_for_initial/final is ADDR_EXPR.

* gcc.dg/gomp/pr81768-2.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/gomp/pr81768-2.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/omp-low.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug middle-end/81768] [8 Regression] error: control flow in the middle of basic block

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 15 21:38:43 2017
New Revision: 252860

URL: https://gcc.gnu.org/viewcvs?rev=252860=gcc=rev
Log:
Backported from mainline
2017-09-05  Jakub Jelinek  

PR middle-end/81768
* omp-low.c (expand_omp_simd): Force second operands of COND_EXPR
into gimple val before gimplification fo the COND_EXPR.

* gcc.dg/gomp/pr81768-1.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/gomp/pr81768-1.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/omp-low.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug c/81687] Compiler drops label in OpenMP region

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 15 21:37:16 2017
New Revision: 252858

URL: https://gcc.gnu.org/viewcvs?rev=252858=gcc=rev
Log:
Backported from mainline
2017-08-09  Jakub Jelinek  

PR c/81687
* omp-low.c (omp_copy_decl): Don't remap FORCED_LABEL or DECL_NONLOCAL
LABEL_DECLs.
* tree-cfg.c (move_stmt_op): Don't adjust DECL_CONTEXT of FORCED_LABEL
or DECL_NONLOCAL labels.
(move_stmt_r) : Adjust DECL_CONTEXT of FORCED_LABEL
or DECL_NONLOCAL labels here.

* testsuite/libgomp.c/pr81687-1.c: New test.
* testsuite/libgomp.c/pr81687-2.c: New test.

Added:
branches/gcc-6-branch/libgomp/testsuite/libgomp.c/pr81687-1.c
branches/gcc-6-branch/libgomp/testsuite/libgomp.c/pr81687-2.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/omp-low.c
branches/gcc-6-branch/gcc/tree-cfg.c
branches/gcc-6-branch/libgomp/ChangeLog

[Bug target/81621] ICE in delete_insn, at cfgrtl.c:167 with s390x cross compiler

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 15 21:35:48 2017
New Revision: 252857

URL: https://gcc.gnu.org/viewcvs?rev=252857=gcc=rev
Log:
Backported from mainline
2017-08-03  Jakub Jelinek  

PR target/81621
* bb-reorder.c (pass_partition_blocks::execute): Return TODO_df_finish
after setting changeable df flags.

* gcc.dg/pr81621.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/pr81621.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/bb-reorder.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug middle-end/81052] ICE in verify_dominators, at dominance.c:1184

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 15 21:34:10 2017
New Revision: 252856

URL: https://gcc.gnu.org/viewcvs?rev=252856=gcc=rev
Log:
Backported from mainline
2017-08-03  Jakub Jelinek  

PR middle-end/81052
* omp-low.c (diagnose_sb_0): Handle flag_openmp_simd like flag_openmp.
(pass_diagnose_omp_blocks::gate): Enable also for flag_openmp_simd.

* c-c++-common/pr81052.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/c-c++-common/pr81052.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/omp-low.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug c/45784] gcc OpenMP - error: invalid controlling predicate

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 15 21:33:08 2017
New Revision: 252855

URL: https://gcc.gnu.org/viewcvs?rev=252855=gcc=rev
Log:
Backported from mainline
2017-07-27  Jakub Jelinek  

PR c/45784
* c-omp.c (c_finish_omp_for): If the condition is wrapped in
rhs of COMPOUND_EXPR(s), skip them and readd their lhs into
new COMPOUND_EXPRs around the rhs of the comparison.

* testsuite/libgomp.c/pr45784.c: New test.
* testsuite/libgomp.c++/pr45784.C: New test.

Added:
branches/gcc-6-branch/libgomp/testsuite/libgomp.c++/pr45784.C
branches/gcc-6-branch/libgomp/testsuite/libgomp.c/pr45784.c
Modified:
branches/gcc-6-branch/gcc/c-family/ChangeLog
branches/gcc-6-branch/gcc/c-family/c-omp.c
branches/gcc-6-branch/libgomp/ChangeLog

[Bug target/81766] [8 Regression] ICE in maybe_add_or_update_dep_1, at sched-deps.c:924 caused by r250815

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 15 21:32:05 2017
New Revision: 252854

URL: https://gcc.gnu.org/viewcvs?rev=252854=gcc=rev
Log:
Backported from mainline
2017-08-08  Richard Biener  

PR middle-end/81766
* function.c (thread_prologue_and_epilogue_insns): Restore
behavior of always calling find_many_sub_basic_blocks on
the inserted prologue.

* gcc.target/i386/pr81766.c: New testcase.

2017-08-02  Jakub Jelinek  

PR middle-end/79499
* function.c (thread_prologue_and_epilogue_insns): Determine blocks
for find_many_sub_basic_blocks bitmap by looking up BLOCK_FOR_INSN
of first NONDEBUG_INSN_P in each of the split_prologue_seq and
prologue_seq sequences - if any.

* gcc.dg/pr79499.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/pr79499.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/pr81766.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/function.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug middle-end/79499] ICE in rtl_verify_bb_insns, at cfgrtl.c:2661

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 15 21:32:05 2017
New Revision: 252854

URL: https://gcc.gnu.org/viewcvs?rev=252854=gcc=rev
Log:
Backported from mainline
2017-08-08  Richard Biener  

PR middle-end/81766
* function.c (thread_prologue_and_epilogue_insns): Restore
behavior of always calling find_many_sub_basic_blocks on
the inserted prologue.

* gcc.target/i386/pr81766.c: New testcase.

2017-08-02  Jakub Jelinek  

PR middle-end/79499
* function.c (thread_prologue_and_epilogue_insns): Determine blocks
for find_many_sub_basic_blocks bitmap by looking up BLOCK_FOR_INSN
of first NONDEBUG_INSN_P in each of the split_prologue_seq and
prologue_seq sequences - if any.

* gcc.dg/pr79499.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/pr79499.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/pr81766.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/function.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug libquadmath/65757] gfortran gives incorrect result for anint with real*16 argument

[jakub at gcc dot gnu.org]

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

--- Comment #22 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 15 21:30:40 2017
New Revision: 252853

URL: https://gcc.gnu.org/viewcvs?rev=252853=gcc=rev
Log:
PR libquadmath/65757
* math/roundq.c: Cherry-pick upstream glibc 2015-04-28 change.

Modified:
branches/gcc-6-branch/libquadmath/ChangeLog
branches/gcc-6-branch/libquadmath/math/roundq.c

[Bug target/81225] [6 Regression] ICE with -mavx512ifma -O3 -ffloat-store

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 15 21:30:04 2017
New Revision: 252852

URL: https://gcc.gnu.org/viewcvs?rev=252852=gcc=rev
Log:
Backported from mainline
2017-06-30  Jakub Jelinek  

PR target/81225
* config/i386/sse.md (vec_extract_lo_): For
V8FI, V16FI and VI8F_256 iterators, use  instead
of nonimmediate_operand and  instead of m for
the input operand.  For V8FI iterator, always split if input is a MEM.
For V16FI and V8SF_256 iterators, don't test if both operands are MEM
if .  For VI4F_256 iterator, use 
instead of register_operand and  instead of v
for
the input operand.  Make sure both operands aren't MEMs for if not
.

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

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/pr81225.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/i386/sse.md
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug sanitizer/81224] ICE in -fsanitize=address w/ a register variable of a vector type

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Are you sure?
At least on gcc-6-branch I'm seeing:
spawn -ignore SIGHUP /usr/src/gcc-6/obj28/gcc/xgcc -B/usr/src/gcc-6/obj28/gcc/
/usr/src/gcc-6/gcc/testsuite/gcc.dg/asan/pr81224.c
-B/usr/src/gcc-6/obj28/x86_64-pc-linux-gnu/./libsanitizer/
-B/usr/src/gcc-6/obj28/x86_64-pc-linux-gnu/./libsanitizer/asan/
-L/usr/src/gcc-6/obj28/x86_64-pc-linux-gnu/./libsanitizer/asan/.libs
-fsanitize=address -g -I/usr/src/gcc-6/gcc/testsuite/../../libsanitizer/include
-fno-diagnostics-show-caret -fdiagnostics-color=never -O0 -msse2 -S -o
pr81224.s
/usr/src/gcc-6/gcc/testsuite/gcc.dg/asan/pr81224.c: In function 'b':
/usr/src/gcc-6/gcc/testsuite/gcc.dg/asan/pr81224.c:10:11: internal compiler
error: in expand_expr_addr_expr_1, at expr.c:7672
0x868fe1 expand_expr_addr_expr_1
../../gcc/expr.c:7672
0x84ca06 expand_expr_addr_expr
../../gcc/expr.c:7785
0x84ca06 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:10869
0x85b820 expand_expr
../../gcc/expr.h:260
0x85b820 expand_operands(tree_node*, tree_node*, rtx_def*, rtx_def**,
rtx_def**, expand_modifier)
../../gcc/expr.c:7554
0x863113 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc/expr.c:8395
0x73251d expand_gimple_stmt_1
../../gcc/cfgexpand.c:3653
0x73251d expand_gimple_stmt
../../gcc/cfgexpand.c:3714
0x733f8e expand_gimple_basic_block
../../gcc/cfgexpand.c:5720
0x739896 execute
../../gcc/cfgexpand.c:6335
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
compiler exited with status 1
FAIL: gcc.dg/asan/pr81224.c   -O0  (internal compiler error)
FAIL: gcc.dg/asan/pr81224.c   -O0  (test for excess errors)
and similarly for other -O levels.

[Bug c/82224] Strict-aliasing not noticing valid aliasing of two unions with active members

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
And PR 65892.

[Bug c/82224] Strict-aliasing not noticing valid aliasing of two unions with active members

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
See PR 14319 which I think this is a dup of.

[Bug target/80101] ICE in store_data_bypass_p, at recog.c:3737

[kelvin at gcc dot gnu.org]

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

kelvin at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from kelvin at gcc dot gnu.org ---
Patch was commited 2017-05-09.  Was backported to GCC 6 2017-07-14.

[Bug middle-end/79794] unnecessary copy from target to target results in poor code for aarch64

[sje at gcc dot gnu.org]

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

Steve Ellcey  changed:

   What|Removed |Added

 CC||sje at gcc dot gnu.org

--- Comment #5 from Steve Ellcey  ---
It looks like a patch for this has been checked in.  Should it be closed as
fixed?

[Bug ada/81361] [8 regression] broken exception handling at -O2

[ebotcazou at gcc dot gnu.org]

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

--- Comment #22 from Eric Botcazou  ---
> Actually, the build still fails in the same place - here is the assembler
> for the reduced test-case from pr81241.  I'll look at the c++ test case in
> due course.
> 
> any thoughts?

Take a look at the output of dwarfdump --eh?

[Bug target/82066] #pragma GCC target documentation does not say it is implemented for aarch64

[sje at gcc dot gnu.org]

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

--- Comment #2 from Steve Ellcey  ---
Author: sje
Date: Fri Sep 15 20:55:52 2017
New Revision: 252848

URL: https://gcc.gnu.org/viewcvs?rev=252848=gcc=rev
Log:
2017-09-15  Steve Ellcey  

PR target/82066
* doc/extend.texi (Common Function Attributes): Add 
references to ARM, AArch64, and S/390 specific attributes.
(Function Specific Option Pragmas): Add AArch64 and S/390
to list of back ends that support the target pragma.

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

[Bug c/82071] Error in assign-ops in combination with FLT_EVAL_METHOD

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #5 from Joseph S. Myers  ---
Fixed for GCC 8.

[Bug c/82071] Error in assign-ops in combination with FLT_EVAL_METHOD

[jsm28 at gcc dot gnu.org]

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

--- Comment #4 from Joseph S. Myers  ---
Author: jsm28
Date: Fri Sep 15 20:49:02 2017
New Revision: 252847

URL: https://gcc.gnu.org/viewcvs?rev=252847=gcc=rev
Log:
Implement C11 excess precision semantics for conversions (PR c/82071).

C11 semantics for excess precision (from N1531) are that an implicit
conversion (from the usual arithmetic conversions, not by assignment)
from integer to floating point has a result in the corresponding
evaluation format of that floating-point type, so possibly with excess
precision (whereas a cast or conversion by assignment from integer to
floating point must produce a value without excess range or precision,
as always).  This patch makes GCC support those semantics if
flag_isoc11 (which in turn means that conditional expressions need to
support generating a result with excess precision even if neither
operand had excess precision).

C99 is less than entirely clear in this regard, but my reading as
outlined at 
is that the results of conversions from integer to floating-point
types are always expected to be representable in the target type
without excess precision, and this patch conservatively keeps these
semantics for pre-C11 (i.e. if an older standard is explicitly
selected).

Bootstrapped with no regressions on x86_64-pc-linux-gnu.

PR c/82071

gcc/c:
* c-typeck.c (ep_convert_and_check): Just call convert_and_check
for C11.
(build_conditional_expr): For C11, generate result with excess
precision when one argument is an integer and the other is of a
type using excess precision.

gcc/testsuite:
* gcc.target/i386/excess-precision-8.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/excess-precision-8.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/81033] [8 Regression] Revision r249019 breaks bootstrap on darwin

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|REOPENED|ASSIGNED
 CC||egallager at gcc dot gnu.org

--- Comment #26 from Eric Gallager  ---
Changing status to ASSIGNED since Iain made himself the assignee.

[Bug c/82224] New: Strict-aliasing not noticing valid aliasing of two unions with active members

[myriachan at gmail dot com]

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

Bug ID: 82224
   Summary: Strict-aliasing not noticing valid aliasing of two
unions with active members
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: myriachan at gmail dot com
  Target Milestone: ---

Consider the following C/C++ code with -O3 -fstrict-aliasing:

struct s1 {unsigned short x;};
struct s2 {unsigned short x;};
union s1s2 { struct s1 v1; struct s2 v2; };

static int read_s1x(struct s1 *p) { return p->x; }
static void write_s2x(struct s2 *p, int v) { p->x=v;}

int test(union s1s2 *p1, union s1s2 *p2, union s1s2 *p3)
{
  if (read_s1x(>v1))
  {
unsigned short temp;
temp = p3->v1.x;
p3->v2.x = temp;
write_s2x(>v2,1234);
temp = p3->v2.x;
p3->v1.x = temp;
  }
  return read_s1x(>v1);
}
int test2(int x)
{
  union s1s2 q[2];
  q->v1.x = 4321;
  return test(q,q+x,q+x);
}
#include 
int main(void)
{
  printf("%d\n",test2(0));
}

GCC (and Clang) generate code that outputs 4321 instead of the expected 1234.

I don't really understand things in terms of the C standard, but in terms of
the C++ standard, it seems as if GCC and Clang are incorrect, and this code is
well-defined.  (The output is 4321 in both C and C++ mode.)

According to [class.union]/5 in the C++17 draft N4659, the assignment
expression "p3->v2.x = temp;" changes the active member of the union.  It's
done through a union member access expression.  Thus the pointer >v2 is
valid here.

Even if I switch this to "p3->v2 = { x };", avoiding the nested case, the
problem still happens.

Even if I explicitly change the active member of the union with placement new
as "new() s2;", the problem still happens.

Is it possible that Clang doesn't see the possibility that p2 and p3 point to
the same object?

Clang cross-reference: https://bugs.llvm.org/show_bug.cgi?id=34632

[Bug middle-end/82223] Incorrect optimization for lossy round trips of arithmetic types

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
(float)INT_MAX gets rounded to 2^31. When you try to convert it to int, it
doesn't fit, so the compiler is at liberty to return INT_MAX if it likes.
clang's -fsanitize=undefined does complain on your code (not gcc's though).

[Bug target/82221] internal compiler error: in print_reg, at config/i386/i386.c:17656

[hjl.tools at gmail dot com]

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

--- Comment #11 from H.J. Lu  ---
(In reply to Josh Poimboeuf from comment #9)
> I might be misunderstanding, but I don't think we need DRAP for our use
> case.  We just need assurance that the frame pointer (RBP) has been set up
> before the inline asm is inserted.
> 

The problem is

#define stack_realign_fp (crtl->stack_realign_needed && !crtl->need_drap)

Since function returns 64-bit integer and incoming stack is aligned to
32 bits, initially GCC assume stack realignment is needed.  If need_drap
is false, stack_realign_fp is true.  In this case, we won't eliminate
frame pointer with stack pointer

static bool
ix86_can_eliminate (const int from, const int to)
{
  if (stack_realign_fp)
return ((from == ARG_POINTER_REGNUM
 && to == HARD_FRAME_POINTER_REGNUM)
|| (from == FRAME_POINTER_REGNUM
&& to == STACK_POINTER_REGNUM));
  else  
return to == STACK_POINTER_REGNUM ? !frame_pointer_needed : true; 
}

when sp_is_unchanging is false.  Setting need_drap when sp_is_unchanging is
false allows it to work.  BTW, drap is really used since stack_realign_needed
is changed to false by ix86_finalize_stack_frame_flags.

[Bug middle-end/82223] Incorrect optimization for lossy round trips of arithmetic types

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
What target is this for?

[Bug middle-end/82223] New: Incorrect optimization for lossy round trips of arithmetic types

[02c9a08a70164b24b9f762d53a64ab at gmail dot com]

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

Bug ID: 82223
   Summary: Incorrect optimization for lossy round trips of
arithmetic types
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 02c9a08a70164b24b9f762d53a64ab at gmail dot com
  Target Milestone: ---

When the value of x in known to the compiler, GCC always returns true for x ==
static_cast(static_cast(x)).

I believe this behaviour is incorrect. If the round trip is lossy, these two
values should not be equal. Clang 5.0 and vc141 both return false if x is
MAX_INT.

https://godbolt.org/g/74e5ok

==
Test code:
==

#include 

bool foo()
{
  // This function should return FALSE. You cannot
  // round trip MAX_INT to a float and back without
  // losing precision.
  constexpr auto x = std::numeric_limits::max();
  return x == static_cast(static_cast(x));
}

==
Compiler options:
==
-O3 -std=c++14

==
Generated assembly (x86):
==
foo():
  mov eax, 1
  ret

[Bug ada/81361] [8 regression] broken exception handling at -O2

[iains at gcc dot gnu.org]

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

--- Comment #21 from Iain Sandoe  ---
Created attachment 42183
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42183=edit
assembler for C++ testcase with .cfi_xxx

this gives, when linked to the GCC8 static libstdc++ (I have a patch that
actually makes -static-libstdc++ DTRT).

$ ./tt
terminate called after throwing an instance of 'int'
terminate called recursively
Abort trap: 6

With the system (GCC2.4) libstdc++.6.dylib we get:
$ ./tt
libc++abi.dylib: terminating with uncaught exception of type int
Abort trap: 6

If built using the libc++ headers and library:

CPLUS_INCLUDE_PATH=/path/to/usr/include/c++/v1 ./gcc/xg++ -Bgcc -O2 -save-temps
-v /src-local/test-eh/pr81361.C -lc++ -o tt

we get 
$ ./tt
libc++abi.dylib: terminating with uncaught exception of type int
Abort trap: 6

[Bug c++/64644] "warning: anonymous union with no members" should be an error with -pedantic-errors

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org
   Target Milestone|--- |8.0

--- Comment #6 from Paolo Carlini  ---
Fixed.

[Bug c++/64644] "warning: anonymous union with no members" should be an error with -pedantic-errors

[paolo at gcc dot gnu.org]

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

--- Comment #5 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Fri Sep 15 19:22:35 2017
New Revision: 252835

URL: https://gcc.gnu.org/viewcvs?rev=252835=gcc=rev
Log:
/cp
2017-09-15  Manuel Lopez-Ibanez  
Paolo Carlini  

PR c++/64644
* decl2.c (finish_anon_union): Complain about "anonymous union with
no members" with a pedwarn.

/testsuite
2017-09-15  Manuel Lopez-Ibanez  
Paolo Carlini  

PR c++/64644
* g++.dg/other/anon-union4.C: New.
* g++.old-deja/g++.law/union4.C: Adjust.
* g++.old-deja/g++.other/anon1.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/other/anon-union4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl2.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.old-deja/g++.law/union4.C
trunk/gcc/testsuite/g++.old-deja/g++.other/anon1.C

[Bug c++/68177] Lambda capture doesn't work correctly when lambda is used in a pack expansion

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||benni.buch at gmail dot com

--- Comment #4 from Paolo Carlini  ---
*** Bug 8 has been marked as a duplicate of this bug. ***

[Bug c++/82222] wrong uninitialized reference in lambda capture in fold expression

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||paolo.carlini at oracle dot com
 Resolution|--- |DUPLICATE

--- Comment #1 from Paolo Carlini  ---
Dup.

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

[Bug ada/81361] [8 regression] broken exception handling at -O2

[iains at gcc dot gnu.org]

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

--- Comment #20 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #19)
> Created attachment 42182 [details]
> assembler for pr81241 Ada testcase with .cfi_xxx
> 
> I rebased my patches to enable .cfi_xxx for Darwin (no claim that they are
> perfect, but good enough to get to stage #3, apparently).
> 
> Actually, the build still fails in the same place - here is the assembler
> for the reduced test-case from pr81241.  I'll look at the c++ test case in
> due course.
> 
> any thoughts?

I suspect that

   .cfi_startproc
.cfi_personality 0x9b,___gnat_personality_v0
.cfi_lsda 0x10,LLSDAC5
___cold_sect_of__p__raise_it.4258.constprop.0:
_p__raise_it.4258.constprop.0.cold.1:

is associating the startproc with the previous symbol and not the one for the
cold section... this seems reminiscent of the kind of issue I had with
partitioning.

[Bug ada/81361] [8 regression] broken exception handling at -O2

[iains at gcc dot gnu.org]

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

--- Comment #19 from Iain Sandoe  ---
Created attachment 42182
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42182=edit
assembler for pr81241 Ada testcase with .cfi_xxx

I rebased my patches to enable .cfi_xxx for Darwin (no claim that they are
perfect, but good enough to get to stage #3, apparently).

Actually, the build still fails in the same place - here is the assembler for
the reduced test-case from pr81241.  I'll look at the c++ test case in due
course.

any thoughts?

[Bug c++/82222] New: wrong uninitialized reference in lambda capture in fold expression

[benni.buch at gmail dot com]

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

Bug ID: 8
   Summary: wrong uninitialized reference in lambda capture in
fold expression
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: benni.buch at gmail dot com
  Target Milestone: ---

int main(){
int dummy = 0;
[](auto& d, auto ... args){
([](auto ...){}(([](){}, args)), ...);
}(dummy, 0, 0);
}

is a valid program, but:

$ g++ -std=c++17 -o main gcc-test.cpp 
gcc-test.cpp: In instantiation of 'main():: [with
auto:1 = int; auto:2 = {int, int}]':
gcc-test.cpp:5:15:   required from here
gcc-test.cpp:4:20: error: member 'main():: [with
auto:1 = int; auto:2 = {int, int}]::::' is uninitialized
reference
   ([](auto ...){}(([](){}, args)), ...);
^

I found this while implementing an output function:

#include 
#include 

template < typename Arg, typename ... Args >
void comma_separated_output(
std::ostream& os,
Arg const& arg,
Args const& ... args
){
std::apply([](auto const& ... args)mutable{
(os << ... << args);
}, arg);
(std::apply([](auto const& ... args)mutable{
((os << ", ") << ... << args);
}, args), ...);
}

int main(){
comma_separated_output(std::cout,
std::make_tuple(), std::make_tuple(), std::make_tuple());
}

$ g++ -std=c++17 -o main gcc-test.cpp 
gcc-test.cpp: In instantiation of 'void comma_separated_output(std::ostream&,
const Arg&, const Args& ...) [with Arg = std::tuple<>; Args = {std::tuple<>,
std::tuple<>}; std::ostream = std::basic_ostream]':
gcc-test.cpp:20:64:   required from here
gcc-test.cpp:13:17: error: member 'comma_separated_output(std::ostream&, const
Arg&, const Args& ...) [with Arg = std::tuple<>; Args = {std::tuple<>,
std::tuple<>}; std::ostream = std::basic_ostream]::::' is uninitialized reference
 (std::apply([](auto const& ... args)mutable{
 ^

Tested with:
$ g++ --version
g++ (GCC) 7.2.1 20170911

[Bug target/82221] internal compiler error: in print_reg, at config/i386/i386.c:17656

[hjl.tools at gmail dot com]

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

--- Comment #10 from H.J. Lu  ---
Try this one:

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 4f0414ffa9d..ee27273c80d 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -13801,6 +13801,7 @@ ix86_get_drap_rtx (void)
   /* We must use DRAP if there are outgoing arguments on stack and
  ACCUMULATE_OUTGOING_ARGS is false.  */
   if (ix86_force_drap
+  || !crtl->sp_is_unchanging
   || (cfun->machine->outgoing_args_on_stack
 && !ACCUMULATE_OUTGOING_ARGS))
 crtl->need_drap = true;

to see what the generated code looks like.

[Bug target/82221] internal compiler error: in print_reg, at config/i386/i386.c:17656

[jpoimboe at redhat dot com]

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

--- Comment #9 from Josh Poimboeuf  ---
I might be misunderstanding, but I don't think we need DRAP for our use case. 
We just need assurance that the frame pointer (RBP) has been set up before the
inline asm is inserted.

If clobbering "sp" isn't the right approach, maybe a new syntax, hopefully a
documented one, would be better.  Like a special "frame" clobber, for example.

[Bug target/82221] internal compiler error: in print_reg, at config/i386/i386.c:17656

[hjl.tools at gmail dot com]

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

--- Comment #8 from H.J. Lu  ---
(In reply to Josh Poimboeuf from comment #7)
> Putting "sp" in the clobbers list is something that was suggested to me on
> the GCC mailing list a while back.  And, other than this rare bug, it seems
> to do exactly what we want, which is, force GCC to save the frame pointer
> before inserting the inline asm.  We need that to happen when we put a
> "call" instruction inside the inline asm, so that we can get a reliable
> stack trace from the called function.
> 
> I know that putting "sp" in the clobbers list is an undocumented "feature",
> so maybe it is user error.  However it would be nice to have something like
> this as a real feature.  Either with "sp", or maybe a new clobbers keyword
> like "frame". 
> 
> Would that be feasible?

Yes, if we can somehow update

static rtx
ix86_get_drap_rtx (void)
{
  /* We must use DRAP if there are outgoing arguments on stack and
 ACCUMULATE_OUTGOING_ARGS is false.  */
  if (ix86_force_drap
  || (cfun->machine->outgoing_args_on_stack
  && !ACCUMULATE_OUTGOING_ARGS))
crtl->need_drap = true; 

to set need_drap when stack register is clobbered by asm statement.

[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV

[rguenther at suse dot de]

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

--- Comment #17 from rguenther at suse dot de  ---
On September 15, 2017 5:02:36 PM GMT+02:00, "ro at CeBiTec dot
Uni-Bielefeld.DE"  wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968
>
>--- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE dot Uni-Bielefeld.DE> ---
>> --- Comment #14 from Richard Biener  ---
>> Thanks for the detailed analysis.  Indeed
>>
>>   /* Mark sections as preserved that are required by to be preserved
>>  sections.  */
>>   for (i = 1; i < shnum; ++i)
>> {
>> ...
>>   if (sh_type == SHT_SYMTAB)
>> {
>>   /* Mark strings sections of copied symtabs.  */
>>   if (pfnret[i - 1] == 0)
>> pfnret[sh_link - 1] = 0;
>> }
>> }
>>
>> so it conditionally preserves sh_link of SHT_SYMTAB.
>>
>> I think we need to iterate this loop.  And maybe always preserve the
>symtab
>> since we keep exported symbols of preserved sections, we're currently
>lucky
>> here because .debug_info always contains a relocation to
>.debug_abbrev.
>> Probably good enough...
>
>That worked just fine, thanks.
>
>While there are still ld warnings
>
>ld: warning: file /var/tmp//ccmgPmhadebugobjtem: section [2] has
>invalid type [
>SHT_NULL ]
>
>ro@lucy 87 > elfdump -c -I 2 cc2qd7lbdebugobjtem 
>cc2qd7lbdebugobjtem: : invalid sh_type: 0
>
>Section Header[2]:  sh_name: 
>sh_addr:  0   sh_flags:   [ SHF_EXCLUDE ]
>sh_size:  0   sh_type:[ SHT_NULL ]
>sh_offset:0x4980  sh_entsize: 0
>sh_link:  0   sh_info:0
>sh_addralign: 0x10  
>
>and there's no way to silence them from the ld command line, I should
>be
>able to prune them for the testsuite at least.

Can you report this issue to the Solaris folks? 

  However, the final link
>fails:
>
>Undefined   first referenced
> symbol in file
>__gnu_lto_v1/var/tmp//ccQylLjddebugobj
>
>It turns out that __gnu_lto_v1 in the original object
>
>[336] 0x10x1  OBJT GLOB  D0 COMMON 
>__gnu_lto_v1
>
>remains in the one produced by lto-wrapper:
>
>  [339]  00  NOTY GLOB  D0 UNDEF   __gnu_lto_v1
>
>Need to check what's going on here...

How does it fail? The symbol should be unused...

Richard. 

>Rainer

[Bug tree-optimization/71026] Missing division optimizations

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #6 from Wilco  ---
(In reply to Jeffrey A. Law from comment #5)
> Author: law
> Date: Fri Sep 15 16:17:55 2017
> New Revision: 252827
> 
> URL: https://gcc.gnu.org/viewcvs?rev=252827=gcc=rev
> Log:
> 2017-09-15  Jackson Woodruff  
> 
>   PR tree-optimization/71026
>   * match.pd: Move RDIV patterns from fold-const.c
>   * fold-const.c (distribute_real_division): Removed.
>   (fold_binary_loc): Remove calls to distribute_real_divison.
> 
>   PR tree-optimization/71026
>   * gcc/testsuire/gcc.dg/fold-div-1.c: Use -O1.
> 
> Modified:
> trunk/gcc/ChangeLog
> trunk/gcc/match.pd
> trunk/gcc/testsuite/ChangeLog
> trunk/gcc/testsuite/gcc.dg/fold-div-1.c

This seems to leave out the fold-const.c changes...

[Bug ada/81361] [8 regression] broken exception handling at -O2

[dominiq at lps dot ens.fr]

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

--- Comment #18 from Dominique d'Humieres  ---
With the patch in comment 7 applied on top of r252799, I have bootstrapped
x86_64-apple-darwin16.7.0, configured with: 

../work/configure --prefix=/opt/gcc/gcc8w
--enable-languages=c,c++,fortran,objc,obj-c++,ada,lto --with-gmp=/opt/mp-new
--with-system-zlib --with-isl=/opt/mp-new --enable-lto --enable-plugin
--with-arch=corei7 --with-cpu=corei7

and check-ada gives

=== acats Summary ===
# of expected passes2320
# of unexpected failures0

=== gnat Summary ===

# of expected passes2600
# of expected failures  24
# of unsupported tests  7

Thanks for working on the issue.

For the record

% as --version
Apple LLVM version 8.1.0 (clang-802.0.42)
Target: x86_64-apple-darwin16.7.0
Thread model: posix
InstalledDir:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

[Bug target/82221] internal compiler error: in print_reg, at config/i386/i386.c:17656

[jpoimboe at redhat dot com]

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

--- Comment #7 from Josh Poimboeuf  ---
Putting "sp" in the clobbers list is something that was suggested to me on the
GCC mailing list a while back.  And, other than this rare bug, it seems to do
exactly what we want, which is, force GCC to save the frame pointer before
inserting the inline asm.  We need that to happen when we put a "call"
instruction inside the inline asm, so that we can get a reliable stack trace
from the called function.

I know that putting "sp" in the clobbers list is an undocumented "feature", so
maybe it is user error.  However it would be nice to have something like this
as a real feature.  Either with "sp", or maybe a new clobbers keyword like
"frame". 

Would that be feasible?

[Bug target/82221] internal compiler error: in print_reg, at config/i386/i386.c:17656

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
paravirt_read_pmc should be fixed not to clobber SP when stack realignment
is needed.

[Bug target/82221] internal compiler error: in print_reg, at config/i386/i386.c:17656

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com,
   ||ubizjak at gmail dot com

--- Comment #5 from H.J. Lu  ---
The problem is

static inline
__attribute__((always_inline))
unsigned long long paravirt_read_pmc(int counter)
{
  return ({ u64 __ret; unsigned long __eax = __eax, __edx = __edx;
  { asm volatile("# foo" : "=a" (__eax), "=d" (__edx)
 : "a" ((unsigned long)(counter))
 : "memory", "cc", "sp" );
   ^^^ with
-mpreferred-stack-boundary=2
  __ret = (u64)u64)__edx) << 32) | __eax);
  }
  __ret;
  });
}

On one hand, GCC needs BP register to align the stack for

static inline
__attribute__((always_inline,unused))
__attribute__((no_instrument_function))
long long bar(atomic64_t *v, long long o, long long n)
{
 return ((__typeof__(*(>counter)))__bar((>counter), (unsigned long
long)(o
), (unsigned long long)(n)));
}

On the other hand, GCC needs BP register to preserve SP since asm statement
in paravirt_read_pmc clobbers SP.  I think it is a user error.  But GCC should
provide a better error message.

[Bug ada/81361] [8 regression] broken exception handling at -O2

[ebotcazou at gcc dot gnu.org]

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

--- Comment #17 from Eric Botcazou  ---
> So, FAOD, the fix is a work-around for a bug in either the assembler or
> unwinder? (the original DWARF output is expected to be well-formed?)

Yes, that's my understanding.

> Given that the GCC unwinder segvs in the same place, perhaps it's more
> likely an assembler issue.  Are you using LLVM-backend-based assembler (i.e.
> via clang) and, if so, what version?  Like GCC the DWARF code is mostly
> common in LLVM, so we should raise an upstream bug report + a radar.

(botcazou@goole) ~ $ as --version
Apple LLVM version 7.0.0 (clang-700.1.76)
Target: x86_64-apple-darwin14.5.0
Thread model: posix

[Bug target/82221] internal compiler error: in print_reg, at config/i386/i386.c:17656

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-15
 Ever confirmed|0   |1

--- Comment #4 from H.J. Lu  ---
[hjl@gnu-6 gcc]$ cat x.c
typedef unsigned long long u64;
typedef struct {
 u64 __attribute__((aligned(8))) counter;
} atomic64_t;
typedef unsigned int u32;
static inline
__attribute__((always_inline,unused))
__attribute__((no_instrument_function))
unsigned long long paravirt_read_pmc(int counter)
{
  return ({ u64 __ret; unsigned long __eax = __eax, __edx = __edx, __ecx =
__ecx;
  { asm volatile("# foo" : "=a" (__eax), "=d" (__edx), "=c" (__ecx)
 : "a" ((unsigned long)(counter))
 : "memory", "cc" , "sp");
  __ret = (u64)u64)__edx) << 32) | __eax);
  }
  __ret;
  });
}
typedef struct {
 atomic64_t a;
} local64_t;

struct hw_perf_event {

 union {
  struct {
   int event_base_rdpmc;
   int idx;
  };
 };
 local64_t prev_count;
};

static inline
__attribute__((always_inline,unused))
__attribute__((no_instrument_function))
u64 __bar(volatile u64 *ptr, u64 old, u64 new)
{
 u64 prev;
 asm volatile(".pushsection .smp_locks,\"a\"\n" ".balign 4\n" ".long 671f -
.\n" ".popsection\n" "671:" "\n\tlock; " "cmpxchg8b %1"
   : "=A" (prev),
 "+m" (*ptr)
   : "b" ((u32)new),
 "c" ((u32)(new >> 32)),
 "0" (old)
   : "memory");
 return prev;
}

static inline
__attribute__((always_inline,unused))
__attribute__((no_instrument_function))
long long bar(atomic64_t *v, long long o, long long n)
{
 return ((__typeof__(*(>counter)))__bar((>counter), (unsigned long
long)(o), (unsigned long long)(n)));
}

u64
foo (struct hw_perf_event *hwc, int shift)
{
 u64 prev_raw_count, new_raw_count;
 int idx = hwc->idx;
 u64 delta;

again:
 ((new_raw_count) = paravirt_read_pmc(hwc->event_base_rdpmc));

 if (bar((&(>prev_count)->a), (prev_raw_count), (new_raw_count))
!= prev_raw_count)
  goto again;

 return new_raw_count;
}
[hjl@gnu-6 gcc]$ ./xgcc -B./ -m32 -march=i686 x.c -O2  -S
-mpreferred-stack-boundary=2
during RTL pass: final
x.c: In function ‘foo’:
x.c:74:1: internal compiler error: output_operand: invalid use of register
'frame'
 }
 ^
0xadb606 output_operand_lossage(char const*, ...)
/export/gnu/import/git/sources/gcc/gcc/final.c:3453
0x1350cff print_reg(rtx_def*, int, _IO_FILE*)
/export/gnu/import/git/sources/gcc/gcc/config/i386/i386.c:18798
0x13531ad ix86_print_operand_address_as
/export/gnu/import/git/sources/gcc/gcc/config/i386/i386.c:19809
0x13524c2 ix86_print_operand(_IO_FILE*, rtx_def*, int)
/export/gnu/import/git/sources/gcc/gcc/config/i386/i386.c:19552
0xadc636 output_operand(rtx_def*, int)
/export/gnu/import/git/sources/gcc/gcc/final.c:3887
0xadc285 output_asm_insn(char const*, rtx_def**)
/export/gnu/import/git/sources/gcc/gcc/final.c:3803
0xadacf8 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/export/gnu/import/git/sources/gcc/gcc/final.c:3055
0xad8fc1 final(rtx_insn*, _IO_FILE*, int)
/export/gnu/import/git/sources/gcc/gcc/final.c:2048
0xadd9db rest_of_handle_final
/export/gnu/import/git/sources/gcc/gcc/final.c:4488
0xaddcf2 execute
/export/gnu/import/git/sources/gcc/gcc/final.c:4562
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
[hjl@gnu-6 gcc]$

[Bug ada/81361] [8 regression] broken exception handling at -O2

[ebotcazou at gcc dot gnu.org]

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

--- Comment #16 from Eric Botcazou  ---
> I did this and there's nothing interesting revealed - everything
> consistently gives the same output (and dwarfdump --verify claims it's
> valid).

Not for me though.  Here's the output on the C++ testcase:

(botcazou@goole) ~ $ dwarfdump t.o --eh --verify
--
 File: t.o (x86_64)
--
Verifying EH Frame... error: FDE row for address 0xffe2 is not in
the FDE address range.

0x0050: FDE
length: 0x002c
   CIE_pointer: 0x
start_addr: 0x0054 ___cold_sect_of__main + 0x0008
range_size: 0x0022 (end_addr = 0x0076)
  LSDA address: 0x00a0
  Instructions: 0x0054: CFA=rsp+8 rip=[rsp]
DW_CFA_set_loc (0xff8e)
DW_CFA_def_cfa_offset (16)
DW_CFA_offset (rbx, -16)
DW_CFA_nop
DW_CFA_nop
0xffe2: CFA=rsp+16rbx=[rsp]  rip=[rsp+8]


error: FDE row for address 0xff82 is not in the FDE address range.
error: FDE row for address 0xffb2 is not in the FDE address range.

0x00a8: FDE
length: 0x0034
   CIE_pointer: 0x
start_addr: 0x004c ___cold_sect_of__main
range_size: 0x0031 (end_addr = 0x007d)
  LSDA address: 0x00f0
  Instructions: 0x004c: CFA=rsp+8 rip=[rsp]
DW_CFA_set_loc (0xff36)
DW_CFA_def_cfa_offset (16)
0xff82: CFA=rsp+16rip=[rsp+8]
DW_CFA_advance_loc4 (48)
DW_CFA_def_cfa_offset (8)
DW_CFA_nop
DW_CFA_nop
DW_CFA_nop
DW_CFA_nop
DW_CFA_nop
0xffb2: CFA=rsp+8 rip=[rsp]



3 errors found in EH frame for t.o (x86_64).


But I have an error with the fixed compiler too:

(botcazou@goole) ~ $ dwarfdump t.o --eh --verify
--
 File: t.o (x86_64)
--
Verifying EH Frame... 
error: 0x0050: FDE - address range overlaps with previous FDE:

0x00a8: FDE
length: 0x002c
   CIE_pointer: 0x
start_addr: 0x004c ___cold_sect_of__main
range_size: 0x0031 (end_addr = 0x007d)
  LSDA address: 0x00f0

0x0050: FDE
length: 0x002c
   CIE_pointer: 0x
start_addr: 0x0054 ___cold_sect_of__main + 0x0008
range_size: 0x0022 (end_addr = 0x0076)
  LSDA address: 0x00a0

1 errors found in EH frame for t.o (x86_64).

although this yields a working executable.

> There's one point that I'm pursuing, which is that some relocations are
> elided from mach-o objects, where the linker can figure out the right result
> without needing one.  So it could be an oversight, or a ld64 bug too.  Since
> Darwin is now using .cfi_ there's probably not much testing of the DWARF
> stuff outside GCC use.

Switching to the CFI asm directives is indeed a workaround.

> I also have some patches to enable .cfi_ in Darwin GCC, but need to
> rebase them to current trunk.  I guess the hard thing at the moment is to
> know what the true intention  was and therefore which component is buggy.

Not clear at this point, but the assembler seems to be a good candidate.

[Bug ada/81361] [8 regression] broken exception handling at -O2

[ebotcazou at gcc dot gnu.org]

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

--- Comment #15 from Eric Botcazou  ---
Created attachment 42181
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42181=edit
C++ testcase

To be compiled at -O2 and run:

(botcazou@goole) ~ $ g++ -o t t.C -O2
(botcazou@goole) ~ $ ./t 
terminate called after throwing an instance of 'int'
Abort trap: 6

[Bug fortran/82215] Feature request to better support two pass compiling with gfortran

[busby1 at llnl dot gov]

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

--- Comment #5 from Lee Busby  ---
Thank you very much for reading my report, Mr. Koenig.  I probably should have
pulled out footnote #6 as an explicit comment here, as it comes closest to my
own first guess at a "feature request".

As you have seen, the "feature request", such as it is, is pretty simple. 
Gfortran already has all the capabilities needed -- indeed, my report
demonstrates a working production scale system, so why is anything needed at
all?

The only irreplaceable component of the two pass system is the -fsyntax-only
flag.  That allows us to build all the dependencies quickly, then do the heavy
work (code generation) in parallel.  So at a bare minimum, my "feature request"
would be to add a note to the documentation that -fsyntax-only also, as a side
effect, generates the .mod files.  There is no need to say anything about two
pass compiling.

Going on to add -fmodule-files=no would be a nice step that makes the user's
intention more obvious, and it might avoid the temporary subdirectory that I
resort to in the current pass2.  If you did add that option, then also adding
-fobject-files=no as, basically, a synonym for -fsyntax-only might be an
orthogonal addition to the command line interface.

On the third point, putting the source file path into the module file, I agree
that it could well be problematic, and perhaps best left alone.  There are
several ways for practical build systems to match an object file with its
proper source file.

Basically, that's it.  I'm not trying to promote two pass compiling as an
alternative to any other uses of the language or compiler.  My technical report
surprised me, to tell the truth.  It was very easy to set up the two pass
system  for Miranda, and it is extraordinarily effective.  The key mental shift
for me was to see that a fortran compiler is a tool for making module files and
object files: Usually that happens both at once, but in some situations, it can
be much better to do them one at a time.

I would therefore like to see (all) fortran compilers gain the flexibility to
generate modules and objects one at a time.  I consider the gfortran team to be
something of a thought leader in showing how the tool can be used, so I am
grateful for your ideas and insights about which, if any, new features might be
best.

Thank you.

[Bug c++/78648] [5/6/7/8 Regression] ICE on invalid C++ code on x86_64-linux-gnu (Segmentation fault, contains_struct_check)

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Fri Sep 15 16:31:15 2017
New Revision: 252829

URL: https://gcc.gnu.org/viewcvs?rev=252829=gcc=rev
Log:
2017-09-13  Paolo Carlini  

PR c++/78648
* g++.dg/cpp0x/lambda/lambda-ice21.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice21.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/71026] Missing division optimizations

[law at gcc dot gnu.org]

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

--- Comment #5 from Jeffrey A. Law  ---
Author: law
Date: Fri Sep 15 16:17:55 2017
New Revision: 252827

URL: https://gcc.gnu.org/viewcvs?rev=252827=gcc=rev
Log:
2017-09-15  Jackson Woodruff  

PR tree-optimization/71026
* match.pd: Move RDIV patterns from fold-const.c
* fold-const.c (distribute_real_division): Removed.
(fold_binary_loc): Remove calls to distribute_real_divison.

PR tree-optimization/71026
* gcc/testsuire/gcc.dg/fold-div-1.c: Use -O1.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/fold-div-1.c

[Bug sanitizer/81715] asan-stack=1 redzone allocation is too inflexible

[arnd at linaro dot org]

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

--- Comment #3 from Arnd Bergmann  ---
(In reply to Arnd Bergmann from comment #2)
> Created attachment 42178 [details]
> preprocessed linux/drivers/media/dvb-frontends/stv090x.c, compressed
> 
> This is one of the typical files showing the behavior, with stack sizes up
> to 8 KB using gcc, but only a few hundred bytes using clang:
> 

Looking at it again, it was probably not the best example, in this case the
difference between clang and gcc is that clang happens to inline 
stv090x_write_regs while gcc doesn't inline it. If I mark that function as
__always_inline, gcc produces good code as well, but that is a little besides
the point. In a lot of other examples the function that gets called is from
another file, so we can't inline it. I can attach a few other examples if that
helps, or you could just replace the function with an extern declaration for
testing.

[Bug rtl-optimization/82192] [5/6/7/8 Regression] gcc produces incorrect code with -O2 and bit-field

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep 15 15:54:04 2017
New Revision: 252824

URL: https://gcc.gnu.org/viewcvs?rev=252824=gcc=rev
Log:
PR rtl-optimization/82192
* combine.c (make_extraction): Don't look through non-paradoxical
SUBREGs or TRUNCATE if pos + len is or might be bigger than
inner's mode.

* gcc.c-torture/execute/pr82192.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr82192.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/testsuite/ChangeLog

[Bug c/82221] internal compiler error: in print_reg, at config/i386/i386.c:17656

[jpoimboe at redhat dot com]

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

--- Comment #3 from Josh Poimboeuf  ---
This has been seen on Fedora GCC 7.1.1 and Debian GCC 6.2.0-3.

This bug can be recreated with the above kernel git branch and the attached
.config by typing "make ARCH=i386 arch/x86/events/core.o".

I've also attached the preprocessed source which GCC produced when it reported
the error.

[Bug c/82221] internal compiler error: in print_reg, at config/i386/i386.c:17656

[jpoimboe at redhat dot com]

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

--- Comment #2 from Josh Poimboeuf  ---
Created attachment 42180
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42180=edit
kernel config file

[Bug c/82221] internal compiler error: in print_reg, at config/i386/i386.c:17656

[jpoimboe at redhat dot com]

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

--- Comment #1 from Josh Poimboeuf  ---
Created attachment 42179
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42179=edit
preprocessed source

[Bug c/82221] New: internal compiler error: in print_reg, at config/i386/i386.c:17656

[jpoimboe at redhat dot com]

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

Bug ID: 82221
   Summary: internal compiler error: in print_reg, at
config/i386/i386.c:17656
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jpoimboe at redhat dot com
  Target Milestone: ---

When compiling a patch for the Linux kernel, GCC crashes with the following
error:

gcc -Wp,-MD,arch/x86/events/.core.o.d  -nostdinc -isystem
/usr/lib/gcc/x86_64-redhat-linux/7/include -I./arch/x86/include
-I./arch/x86/include/generated  -I./include -I./arch/x86/include/uapi
-I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi
-include ./include/linux/kconfig.h -D__KERNEL__ -Wall -Wundef
-Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common
-fshort-wchar -Werror-implicit-function-declaration -Wno-format-security
-std=gnu89 -fno-PIE -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -m32
-msoft-float -mregparm=3 -freg-struct-return -fno-pic
-mpreferred-stack-boundary=2 -march=i686 -Wa,-mtune=generic32 -ffreestanding
-DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1
-DCONFIG_AS_SSSE3=1 -DCONFIG_AS_CRC32=1 -DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1
-DCONFIG_AS_AVX512=1 -DCONFIG_AS_SHA1_NI=1 -DCONFIG_AS_SHA256_NI=1 -pipe
-Wno-sign-compare -fno-asynchronous-unwind-tables
-fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation
-Wno-format-overflow -Wno-int-in-bool-context -O2
--param=allow-store-data-races=0 -DCC_HAVE_ASM_GOTO -fno-reorder-blocks
-fno-ipa-cp-clone -fno-partial-inlining -Wframe-larger-than=1024
-fno-stack-protector -Wno-unused-but-set-variable -Wno-unused-const-variable
-fno-omit-frame-pointer -fno-optimize-sibling-calls
-fno-var-tracking-assignments -pg -mfentry -DCC_USING_FENTRY
-fno-inline-functions-called-once -Wdeclaration-after-statement
-Wno-pointer-sign -fno-strict-overflow -fconserve-stack -Werror=implicit-int
-Werror=strict-prototypes -Werror=date-time -Werror=incompatible-pointer-types
-Werror=designated-init-DKBUILD_BASENAME='"core"' 
-DKBUILD_MODNAME='"core"' -c -o arch/x86/events/core.o arch/x86/events/core.c
arch/x86/events/core.c: In function ‘x86_perf_event_update’:
arch/x86/events/core.c:108:1: internal compiler error: in print_reg, at
config/i386/i386.c:17656
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
{standard input}: Assembler messages:
{standard input}: Warning: end of file not at end of a line; newline inserted
{standard input}:1573: Error: unbalanced parenthesis in operand 2.
Preprocessed source stored into /tmp/ccydezQe.out file, please attach this to
your bugreport.

The code being compiled is at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux.git
clang-sp-clobber

I will also attach the kernel .config file which triggers this bug.

[Bug target/82158] _Noreturn functions that do return clobber caller's registers on ARM32 (but not other arches)

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org

--- Comment #4 from Ramana Radhakrishnan  ---

(In reply to Peter Cordes from comment #3)
> (In reply to jos...@codesourcery.com from comment #2)
> > Falling off a noreturn function sounds like it could be another case to 
> > insert __builtin_trap (), as we do in various cases of undefined behavior.
> 
> gcc has had a `-mabort-on-noreturn` option for ARM32 for a long time, but
> it's not enabled by default.
> 
> I'm still not sure if clobbering r5 when the function really doesn't return
> is a feature (which gcc should be doing for other targets) or a bug.

It's a "feature" - if the function really doesn't return, then there is no real
requirement to save and restore all callee-saved registers. 

A deliberate choice when computing the save register mask - all that we are
providing is an ability to backtrace out of such cases - anything more is just
broken and sort of defeats the purpose of noreturn functions in the first
place.

I can see that other backends have similar techniques - x86_64 appears to trash
%esi in the experiments I did and it does look like %esi is a callee saved
register.

> 
> It clearly breaks stack unwinding of call-preserved register values with
> x86-64 style .eh_frame metadata; does this matter for exceptions from
> callees of the noreturn function, or only for debugging?

Arm doesn't turn on exception tables by default very unlike x86_64 - if you
want eh information from C then use -fexceptions on the command line and I see
that it all works just fine. 

> 
> Anyway, gcc should either produce a compile-time error, call
> __builtin_trap() or abort(), or properly restore all call-preserved
> registers when it returns.  There should be no set of options that lets it
> make bad code like this, even with a warning.


It does produce a warning , you could use -Werror :) ? We could look to put out
a __builtin_trap instead of a call to abort in the backend - As you say
-mabort-on-noreturn has existed since time immemorial , maybe we have to
replace that with a trap instruction and discuss whether to turn it on by
default.

[Bug ada/81361] [8 regression] broken exception handling at -O2

[iains at gcc dot gnu.org]

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

--- Comment #14 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #13)
> (In reply to Eric Botcazou from comment #12)
> > Bootstrap completed on Darwin with the tentative fix (and the workaround for
> > PR target/80556) and the ACATS testsuite is clean.
> 
> Also, doing a bootstrap on D15.6 with the patch and the
> --with--ldflags=-static-libstdc++.

works for me too.

> So, FAOD, the fix is a work-around for a bug in either the assembler or
> unwinder? (the original DWARF output is expected to be well-formed?)
> 
> Given that the GCC unwinder segvs in the same place, perhaps it's more
> likely an assembler issue.  Are you using LLVM-backend-based assembler (i.e.
> via clang) and, if so, what version?  Like GCC the DWARF code is mostly
> common in LLVM, so we should raise an upstream bug report + a radar.
> 
> it could be interesting to compare as -q ... with as -Q to see if the bug is
> also present in the GAS-based assembler .. dwarfdump --verify and --eh-frame
> could be interesting too.

I did this and there's nothing interesting revealed - everything consistently
gives the same output (and dwarfdump --verify claims it's valid).

There's one point that I'm pursuing, which is that some relocations are elided
from mach-o objects, where the linker can figure out the right result without
needing one.  So it could be an oversight, or a ld64 bug too.  Since Darwin is
now using .cfi_ there's probably not much testing of the DWARF stuff
outside GCC use.

I also have some patches to enable .cfi_ in Darwin GCC, but need to rebase
them to current trunk.  I guess the hard thing at the moment is to know what
the true intention  was and therefore which component is buggy.

[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #14 from Richard Biener  ---
> Thanks for the detailed analysis.  Indeed
>
>   /* Mark sections as preserved that are required by to be preserved
>  sections.  */
>   for (i = 1; i < shnum; ++i)
> {
> ...
>   if (sh_type == SHT_SYMTAB)
> {
>   /* Mark strings sections of copied symtabs.  */
>   if (pfnret[i - 1] == 0)
> pfnret[sh_link - 1] = 0;
> }
> }
>
> so it conditionally preserves sh_link of SHT_SYMTAB.
>
> I think we need to iterate this loop.  And maybe always preserve the symtab
> since we keep exported symbols of preserved sections, we're currently lucky
> here because .debug_info always contains a relocation to .debug_abbrev.
> Probably good enough...

That worked just fine, thanks.

While there are still ld warnings

ld: warning: file /var/tmp//ccmgPmhadebugobjtem: section [2] has invalid type [
SHT_NULL ]

ro@lucy 87 > elfdump -c -I 2 cc2qd7lbdebugobjtem 
cc2qd7lbdebugobjtem: : invalid sh_type: 0

Section Header[2]:  sh_name: 
sh_addr:  0   sh_flags:   [ SHF_EXCLUDE ]
sh_size:  0   sh_type:[ SHT_NULL ]
sh_offset:0x4980  sh_entsize: 0
sh_link:  0   sh_info:0
sh_addralign: 0x10  

and there's no way to silence them from the ld command line, I should be
able to prune them for the testsuite at least.  However, the final link
fails:

Undefined   first referenced
 symbol in file
__gnu_lto_v1/var/tmp//ccQylLjddebugobj

It turns out that __gnu_lto_v1 in the original object

  [336] 0x10x1  OBJT GLOB  D0 COMMON  __gnu_lto_v1

remains in the one produced by lto-wrapper:

  [339]  00  NOTY GLOB  D0 UNDEF   __gnu_lto_v1

Need to check what's going on here...

Rainer

[Bug tree-optimization/82220] [8 Regression] SPEC CPU2006 482.sphinx3 ~10% performance regression with trunk@250416

[alexander.nesterovskiy at intel dot com]

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

--- Comment #2 from Alexander Nesterovskiy  ---
Yes, I've applied a patch and looks like it helped:
---
Overhead   SamplesSymbol
trunk@252796 + patch
  31.57%412037mgau_eval
  30.54%--> 397608vector_gautbl_eval_logs3
   9.78%127468subvq_mgau_shortlist
---
And I see in perf that actual execution goes exactly the same way as it goes
for r250415 (corresponding parts of function bodies are actually being
executed).

[Bug middle-end/21850] [4.0 Regression] misscompiling comparision from vector to integer

[palves at gcc dot gnu.org]

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

--- Comment #6 from palves at gcc dot gnu.org ---
Author: palves
Date: Fri Sep 15 14:53:48 2017
New Revision: 252822

URL: https://gcc.gnu.org/viewcvs?rev=252822=gcc=rev
Log:
Fix compile time error when using ansidecl.h with an old version of GCC.

include/
2017-07-31  Nick Clifton  

Binutils PR 21850
* ansidecl.h (OVERRIDE): Protect check of __cplusplus value with
#idef __cplusplus.

Modified:
trunk/include/ChangeLog
trunk/include/ansidecl.h

[Bug rtl-optimization/82192] [5/6/7/8 Regression] gcc produces incorrect code with -O2 and bit-field

[segher at gcc dot gnu.org]

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

--- Comment #16 from Segher Boessenkool  ---
(In reply to Jakub Jelinek from comment #15)
> Also, stripped gcc/*.o files from the latest stage between non-patched and
> patched differ just in the expected combine.o and cc1*checksum.o.

I see no code changes at at all in my usual "build compiler + Linux for 31
architectures" either, so no unexpected changes either :-)  The patch is
preapproved.

[Bug c++/82069] [8 Regression] ICE: Segmentation fault

[trippels at gcc dot gnu.org]

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

--- Comment #7 from Markus Trippelsdorf  ---
Another testcase:

struct A {
  void foo(int *);
};
struct B : A {
  template  void bar(int *p1) {
[&] { foo(p1); };
  };
};

[Bug other/65530] [meta-bug] -mmpx -fcheck-pointer-bounds failures

[marxin at gcc dot gnu.org]

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

Bug 79987 Summary: [CHKP] ICE in gimplify_expr, at gimplify.c:12151
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79987

   What|Removed |Added

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

[Bug tree-optimization/79987] [CHKP] ICE in gimplify_expr, at gimplify.c:12151

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Liška  ---
Fixed on all active branches.

[Bug tree-optimization/79987] [CHKP] ICE in gimplify_expr, at gimplify.c:12151

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Author: marxin
Date: Fri Sep 15 14:11:57 2017
New Revision: 252820

URL: https://gcc.gnu.org/viewcvs?rev=252820=gcc=rev
Log:
Backport r251049

2017-09-15  Martin Liska  

Backport from mainline
2017-08-11  Martin Liska  

PR tree-opt/79987
* tree-chkp.c (chkp_get_bounds_for_decl_addr): Do not instrument
variables of void type.
2017-09-15  Martin Liska  

Backport from mainline
2017-08-11  Martin Liska  

PR tree-opt/79987
* gcc.target/i386/mpx/pr79987.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/mpx/pr79987.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/tree-chkp.c

[Bug tree-optimization/79987] [CHKP] ICE in gimplify_expr, at gimplify.c:12151

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Author: marxin
Date: Fri Sep 15 14:11:27 2017
New Revision: 252819

URL: https://gcc.gnu.org/viewcvs?rev=252819=gcc=rev
Log:
Backport r251049

2017-09-15  Martin Liska  

Backport from mainline
2017-08-11  Martin Liska  

PR tree-opt/79987
* tree-chkp.c (chkp_get_bounds_for_decl_addr): Do not instrument
variables of void type.
2017-09-15  Martin Liska  

Backport from mainline
2017-08-11  Martin Liska  

PR tree-opt/79987
* gcc.target/i386/mpx/pr79987.c: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/mpx/pr79987.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/tree-chkp.c

[Bug fortran/82184] [8 Regression] 187.facerec in SPEC CPU 2000 miscompares

[andrey.y.guskov at intel dot com]

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

--- Comment #9 from Andrey Guskov  ---
Yep, 187 seems to be working now.
Not sure about performance, will check this next week when the automatic perf
build arrives.

[Bug sanitizer/81715] asan-stack=1 redzone allocation is too inflexible

[arnd at linaro dot org]

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

--- Comment #2 from Arnd Bergmann  ---
Created attachment 42178
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42178=edit
preprocessed linux/drivers/media/dvb-frontends/stv090x.c, compressed

This is one of the typical files showing the behavior, with stack sizes up to 8
KB using gcc, but only a few hundred bytes using clang:

$ /home/arnd/cross-gcc/bin/x86_64-linux-gcc-8.0.0 -c /tmp/stv090x.i 
-Werror=frame-larger-than=256 -O2 -fsanitize=kernel-address  --param
asan-stack=0 # no warnings

$ /home/arnd/cross-gcc/bin/x86_64-linux-gcc-8.0.0 -c stv090x.i 
-Werror=frame-larger-than=128 -O2 -fsanitize=kernel-address  --param
asan-stack=1
/git/arm-soc/drivers/media/dvb-frontends/stv090x.c: In function
'stv090x_i2c_gate_ctrl':
/git/arm-soc/drivers/media/dvb-frontends/stv090x.c:810:1: error: the frame size
of 288 bytes is larger than 256 bytes [-Werror=frame-larger-than=]

/git/arm-soc/drivers/media/dvb-frontends/stv090x.c: In function
'stv090x_blind_search':
/git/arm-soc/drivers/media/dvb-frontends/stv090x.c:2067:1: error: the frame
size of 8688 bytes is larger than 256 bytes [-Werror=frame-larger-than=]
 }
 ^
/git/arm-soc/drivers/media/dvb-frontends/stv090x.c: In function
'stv090x_optimize_track':
/git/arm-soc/drivers/media/dvb-frontends/stv090x.c:3089:1: error: the frame
size of 5872 bytes is larger than 256 bytes [-Werror=frame-larger-than=]
 }
 ^
/git/arm-soc/drivers/media/dvb-frontends/stv090x.c: In function
'stv090x_search':
/git/arm-soc/drivers/media/dvb-frontends/stv090x.c:3505:1: error: the frame
size of 8016 bytes is larger than 256 bytes [-Werror=frame-larger-than=]
 }
 ^
/git/arm-soc/drivers/media/dvb-frontends/stv090x.c: In function
'stv090x_attach':
/git/arm-soc/drivers/media/dvb-frontends/stv090x.c:4998:1: error: the frame
size of 1152 bytes is larger than 256 bytes [-Werror=frame-larger-than=]

$ /home/arnd/cross-gcc/bin/clang  -Wframe-larger-than=256 /tmp/stv090x.i -c
-Wall -Wno-constant-logical-operand  -O2 -Wno-unused-value -Wno-pointer-sign
-fsanitize=kernel-address  -mllvm -asan-stack=0
/git/arm-soc/drivers/media/dvb-frontends/stv090x.c:3173:34: warning: stack
frame size of 264 bytes in function
  'stv090x_algo' [-Wframe-larger-than=]
static enum stv090x_signal_state stv090x_algo(struct stv090x_state *state)

$ /home/arnd/cross-gcc/bin/clang  -Wframe-larger-than=256 /tmp/stv090x.i -c
-Wall -Wno-constant-logical-operand  -O2 -Wno-unused-value -Wno-pointer-sign
-fsanitize=kernel-address  -mllvm -asan-stack=1
/git/arm-soc/drivers/media/dvb-frontends/stv090x.c:756:12: warning: stack frame
size of 280 bytes in function
  'stv090x_write_reg' [-Wframe-larger-than=]
static int stv090x_write_reg(struct stv090x_state *state, unsigned int reg, u8
data)
   ^
/git/arm-soc/drivers/media/dvb-frontends/stv090x.c:3173:34: warning: stack
frame size of 376 bytes in function
  'stv090x_algo' [-Wframe-larger-than=]
static enum stv090x_signal_state stv090x_algo(struct stv090x_state *state)
 ^

[Bug c++/78648] [5/6/7/8 Regression] ICE on invalid C++ code on x86_64-linux-gnu (Segmentation fault, contains_struct_check)

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot com

--- Comment #2 from Paolo Carlini  ---
Seems fixed in trunk. I'm probably adding the testcase while keeping the bug
open.

[Bug target/67591] ARM v8 Thumb IT blocks deprecated

[clyon at gcc dot gnu.org]

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

--- Comment #4 from Christophe Lyon  ---
Author: clyon
Date: Fri Sep 15 13:12:33 2017
New Revision: 252817

URL: https://gcc.gnu.org/viewcvs?rev=252817=gcc=rev
Log:
[PR target/67591] ARM v8 Thumb IT blocks are deprecated

2017-09-15  Christophe Lyon  

PR target/67591
* config/arm/arm.md (*cmp_and): Add enabled_for_depr_it attribute.
(*cmp_ior): Likewise.
(*ior_scc_scc): Add alternative for enabled_for_depr_it attribute.
(*ior_scc_scc_cmp): Likewise.
(*and_scc_scc): Likewise.
(*and_scc_scc_cmp): Likewise.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.md

[Bug c++/82219] [8 Regression] Not wanted warning: "type qualifiers ignored on cast result type" on template instantiation

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-15
 Ever confirmed|0   |1

--- Comment #3 from Jonathan Wakely  ---
(I added this warning in r248432)

(In reply to Markus Trippelsdorf from comment #2)
> I don't think this warning makes much sense for templates.

It does in general, e.g. we should still warn for static_cast(0),
but I agree it might be too noisy for static_cast(0) where is_const is
true.

[Bug c++/80947] [6/7/8 Regression] Different visibility for the lambda and its capture list members with -fvisibility=hidden

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
(In reply to Vlad Zolotarov from comment #10)
> (In reply to Jonathan Wakely from comment #9)
> > It says not to attach an archive containing the things we don't want (e.g.
> > sources without includes). And a .gz file is not an archive.
> 
> 
> "Please avoid posting an archive (.tar, .shar or .zip); we generally need

And those are all archive formats, not just compression formats like gzip.

> just a single file to reproduce the bug (the .i/.ii/.f preprocessed file),

A gzipped single file is a single file.

> and, by storing it in an archive, you're just making our volunteers' jobs
> harder."

A gzipped file is not an archive.

An attachment that is a URL that must be copied and pasted to get a Google Docs
page with data that must be copied and pasted or downloaded is also making it
harder!

> But if you insist I can gzip and post it. Whatever makes it easier to fix
> the issue. Please, let me know if that's what you want.

There's no need now because comment 4 shows the issue, but next time yes,
please attach the preprocessed source directly. If it's too big compress it, or
better still reduce it: https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction

That way the reproducer is in our bugzilla permanently. Files hosted externally
might go away or change, so we want the file *here*.

[Bug sanitizer/81715] asan-stack=1 redzone allocation is too inflexible

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-09-15
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
May I please ask you for pre-processed source file. Note that with GCC 7 the
situation can be even worse as we added -fsanitize-address-use-after-scope.

Having the example I can do some measurements and we'll think about
improvements.

[Bug c++/54367] [meta-bug] lambda expressions

[nathan at gcc dot gnu.org]

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

Bug 82195 Summary: Undemangleable lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82195

   What|Removed |Added

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

[Bug demangler/82195] Undemangleable lambda

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #5 from Nathan Sidwell  ---
Fixed r252815.

[Bug demangler/82195] Undemangleable lambda

[nathan at gcc dot gnu.org]

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

--- Comment #4 from Nathan Sidwell  ---
Author: nathan
Date: Fri Sep 15 12:23:57 2017
New Revision: 252815

URL: https://gcc.gnu.org/viewcvs?rev=252815=gcc=rev
Log:
[demangler] Fix nested generic lambda

https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00994.html
PR demangler/82195
* cp-demangle.c (d_name): Add 'toplevel' parm.  Pass to ...
(d_local_name): ... here.  Parse trailing function args on nested
local_name.
(d_encoding, d_special_name, d_class_enum_type): Adjust d_name calls.
* testsuite/demangle-expected: Add tests.

Modified:
trunk/libiberty/ChangeLog
trunk/libiberty/cp-demangle.c
trunk/libiberty/testsuite/demangle-expected

[Bug c++/81355] SegFault when using attribute target dispatch with empty parameter

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Liška  ---
Fixed on all active branches.

[Bug sanitizer/81224] ICE in -fsanitize=address w/ a register variable of a vector type

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Liška  ---
Fixed on all active branches.

[Bug tree-optimization/81696] [5/6/7 Regression] ICF ICE on non-local goto

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Liška  ---
Fixed on all active branches.

[Bug inline-asm/82001] [5/6/7 regression] wrong code when two functions differ only in inline asm register constraints

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Liška  ---
Fixed on all active branches.

[Bug sanitizer/63361] Test case c-c++-common/ubsan/float-cast-overflow-1.c fails on Pentium2

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #20 from Martin Liška  ---
Fixed on all active branches.

[Bug sanitizer/81224] ICE in -fsanitize=address w/ a register variable of a vector type

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
Author: marxin
Date: Fri Sep 15 12:15:52 2017
New Revision: 252814

URL: https://gcc.gnu.org/viewcvs?rev=252814=gcc=rev
Log:
Backport r249728

2017-09-15  Martin Liska  

Backport from mainline
2017-06-28  Martin Liska  

PR sanitizer/81224
* asan.c (instrument_derefs): Bail out inner references
that are hard register variables.
2017-09-15  Martin Liska  

Backport from mainline
2017-06-28  Martin Liska  

PR sanitizer/81224
* gcc.dg/asan/pr81224.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/asan/pr81224.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/asan.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug sanitizer/81224] ICE in -fsanitize=address w/ a register variable of a vector type

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Author: marxin
Date: Fri Sep 15 12:14:40 2017
New Revision: 252813

URL: https://gcc.gnu.org/viewcvs?rev=252813=gcc=rev
Log:
Backport r249728

2017-09-15  Martin Liska  

Backport from mainline
2017-06-28  Martin Liska  

PR sanitizer/81224
* asan.c (instrument_derefs): Bail out inner references
that are hard register variables.
2017-09-15  Martin Liska  

Backport from mainline
2017-06-28  Martin Liska  

PR sanitizer/81224
* gcc.dg/asan/pr81224.c: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.dg/asan/pr81224.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/asan.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug inline-asm/82001] [5/6/7 regression] wrong code when two functions differ only in inline asm register constraints

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
Author: marxin
Date: Fri Sep 15 12:14:19 2017
New Revision: 252812

URL: https://gcc.gnu.org/viewcvs?rev=252812=gcc=rev
Log:
Backport r251530

2017-09-15  Martin Liska  

Backport from mainline
2017-08-30  Martin Liska  

PR inline-asm/82001
* ipa-icf-gimple.c (func_checker::compare_tree_list_operand):
Rename to ...
(func_checker::compare_asm_inputs_outputs): ... this function.
(func_checker::compare_gimple_asm): Use the function to compare
also ASM constrains.
* ipa-icf-gimple.h: Rename the function.
2017-09-15  Martin Liska  

Backport from mainline
2017-08-30  Martin Liska  

PR inline-asm/82001
* gcc.dg/ipa/pr82001.c: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.dg/ipa/pr82001.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/ipa-icf-gimple.c
branches/gcc-5-branch/gcc/ipa-icf-gimple.h
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug c++/81355] SegFault when using attribute target dispatch with empty parameter

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
Author: marxin
Date: Fri Sep 15 12:14:01 2017
New Revision: 252811

URL: https://gcc.gnu.org/viewcvs?rev=252811=gcc=rev
Log:
Backport r251020

2017-09-15  Martin Liska  

Backport from mainline
2017-08-10  Martin Liska  

PR c++/81355
* c-attribs.c (handle_target_attribute):
Report warning for an empty string argument of target attribute.
2017-09-15  Martin Liska  

Backport from mainline
2017-08-10  Martin Liska  

PR c++/81355
* g++.dg/other/pr81355.C: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/other/pr81355.C
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/c-family/c-common.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog