[Bug bootstrap/82037] powerpc64-unknown-linux-gnu bootstrap breaks in stage2 with gcc/liblto_plugin.so: wrong ELF class: ELFCLASS64

[dclarke at blastwave dot org]

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

--- Comment #6 from Dennis Clarke  ---
Well that change fails in stage 1 : 

/usr/local/build/gcc-7.2.0_linux_3.16.0-4-powerpc64.003/./gcc/xgcc
-B/usr/local/build/gcc-7.2.0_linux_3.16.0-4-powerpc64.003/./gcc/
-B/usr/local/gcc7/powerpc64-unknown-linux-gnu/bin/
-B/usr/local/gcc7/powerpc64-unknown-linux-gnu/lib/ -isystem
/usr/local/gcc7/powerpc64-unknown-linux-gnu/include -isystem
/usr/local/gcc7/powerpc64-unknown-linux-gnu/sys-include-O2  -g -O2 -DIN_GCC
   -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include   -fPIC -mlong-double-128 -mno-minimal-toc -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector  -shared -nodefaultlibs
-Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc.map -o
64/libgcc_s.so.1.tmp -g -O2 -m64 -B./ _muldi3_s.o _negdi2_s.o _lshrdi3_s.o
_ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o
_trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o
_subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o
_ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o
_ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o
_paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulhc3_s.o
_mulsc3_s.o _muldc3_s.o _mulxc3_s.o _multc3_s.o _divhc3_s.o _divsc3_s.o
_divdc3_s.o _divxc3_s.o _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o
_clrsbdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o
_fixdfdi_s.o _fixxfdi_s.o _fixtfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o
_fixunsxfdi_s.o _fixunstfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o
_floatditf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o
_floatunditf_s.o _divdi3_s.o _moddi3_s.o _divmoddi4_s.o _udivdi3_s.o
_umoddi3_s.o _udivmoddi4_s.o _udiv_w_sdiv_s.o ibm-ldouble_s.o tramp_s.o
ppc64-fp_s.o enable-execute-stack_s.o unwind-dw2_s.o unwind-dw2-fde-dip_s.o
unwind-sjlj_s.o unwind-c_s.o emutls_s.o libgcc.a -lc && rm -f 64/libgcc_s.so &&
if [ -f 64/libgcc_s.so.1 ]; then mv -f 64/libgcc_s.so.1
64/libgcc_s.so.1.backup; else true; fi && mv 64/libgcc_s.so.1.tmp
64/libgcc_s.so.1 && (echo "/* GNU ld script"; echo "   Use the shared library,
but some functions are only in"; echo "   the static library.  */"; echo "GROUP
( libgcc_s.so.1 -lgcc )" ) > 64/libgcc_s.so
/usr/bin/ld:
/usr/local/build/gcc-7.2.0_linux_3.16.0-4-powerpc64.003/./gcc/liblto_plugin.so:
error loading plugin:
/usr/local/build/gcc-7.2.0_linux_3.16.0-4-powerpc64.003/./gcc/liblto_plugin.so:
wrong ELF class: ELFCLASS64
collect2: error: ld returned 1 exit status
gmake[5]: *** [libgcc_s.so] Error 1
gmake[5]: Leaving directory
`/usr/local/build/gcc-7.2.0_linux_3.16.0-4-powerpc64.003/powerpc64-unknown-linux-gnu/64/libgcc'
gmake[4]: *** [multi-do] Error 1
gmake[4]: Leaving directory
`/usr/local/build/gcc-7.2.0_linux_3.16.0-4-powerpc64.003/powerpc64-unknown-linux-gnu/libgcc'
gmake[3]: *** [all-multi] Error 2
gmake[3]: Leaving directory
`/usr/local/build/gcc-7.2.0_linux_3.16.0-4-powerpc64.003/powerpc64-unknown-linux-gnu/libgcc'
gmake[2]: *** [all-stage1-target-libgcc] Error 2
gmake[2]: Leaving directory
`/usr/local/build/gcc-7.2.0_linux_3.16.0-4-powerpc64.003'
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory
`/usr/local/build/gcc-7.2.0_linux_3.16.0-4-powerpc64.003'
gmake: *** [bootstrap] Error 2
Command exited with non-zero status 2

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

[psmith at gnu dot org]

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

--- Comment #25 from Paul Smith  ---
> (1) Find the mangled name of the vtable of tv.
> (2) Demangle the name, to be 'vtable for TreeVector::Tree'.
> (3) Skip 'vtable for ' and get 'TreeVector::Tree'.
> (4) Lookup this symbol.

Right, and this is my concern: how many different types of symbol modifications
are we going to expect GDB to attempt?  Massaging this type to all its
different equivalent types and then attempting to look them up seems pretty
inefficient.  I'm not familiar at all with the implementation but I'm not sure
I see why we can't just ensure that the symbol values provided match
identically to the de-mangled names, so we always know that we can demangle the
name then look up the symbol.

I also filed a bug against GDB (mentioned above) which is similar: in that case
the demangled name contained the default value for a defaulted template
argument, but the actual symbol provided didn't contain that default: again the
lookup didn't match.  How can GDB know that this argument is the default and it
should try removing that argument and looking up the symbol without it?

[Bug c/82068] New: wrong double to uint64_t conversion with -mieee

[coypu at sdf dot org]

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

Bug ID: 82068
   Summary: wrong double to uint64_t conversion with -mieee
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: coypu at sdf dot org
  Target Milestone: ---

background:
gcc 8.0.0 20170827
netbsd-8.99.2/alpha, 21264

the following test case asserts if built with -mieee, but not without:

#include 
#include 
#include 

int
main (void)
{
long double even = 9223372036854775808.00; /* 2^63 */
uint64_t unsigned_even = even;

assert(unsigned_even % 2 == 0);

return 0;
}

[Bug target/81874] internal compiler error: in do_SUBST, at combine.c:725

[paul.hua.gm at gmail dot com]

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

Paul Hua  changed:

   What|Removed |Added

 CC||paul.hua.gm at gmail dot com

--- Comment #3 from Paul Hua  ---
It hides or fixed whit r251397 on trunk.

[Bug bootstrap/82037] powerpc64-unknown-linux-gnu bootstrap breaks in stage2 with gcc/liblto_plugin.so: wrong ELF class: ELFCLASS64

[dclarke at blastwave dot org]

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

--- Comment #5 from Dennis Clarke  ---
ppc64$ pwd
/usr/local/build/gcc-7.2.0_linux_3.16.0-4-powerpc64.003

ppc64$ date 
Fri Sep  1 03:01:16 GMT 2017

ppc64$ ../gcc-7.2.0/configure --build=powerpc64-unknown-linux-gnu \
> --target=powerpc64-unknown-linux-gnu --host=powerpc64-unknown-linux-gnu \
> --enable-targets=powerpc-linux,powerpc64-linux --prefix=/usr/local/gcc7 \
> --disable-nls --enable-threads=posix --enable-shared \
> --with-cpu=default32 --enable-bootstrap \
> --enable-libstdcxx-debug --enable-libstdcxx-time=yes \
> --enable-__cxa_atexit --with-system-zlib --enable-objc-gc \
> --enable-multiarch --with-long-double-128 --enable-multilib \
> --enable-stage1-languages=c,c++ --enable-stage1-checking=misc \
> --enable-languages=ada,c,c++,fortran,go,lto,objc,obj-c++ \
> --with-pkgversion='genunix Fri Sep  1 03:01:16 GMT 2017' 
checking build system type... powerpc64-unknown-linux-gnu
checking host system type... powerpc64-unknown-linux-gnu
checking target system type... powerpc64-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for a sed that does not truncate output... /bin/sed
checking for gawk... no
checking for mawk... mawk
checking for libatomic support... yes
checking for libcilkrts support... no
checking for libitm support... yes
checking for libsanitizer support... yes
checking for libvtv support... no
checking for libmpx support... no
checking for libhsail-rt support... no
checking for powerpc64-unknown-linux-gnu-gcc... gcc -m64
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc -m64 accepts -g... yes
checking for gcc -m64 option to accept ISO C89... none needed
checking whether we are using the GNU C++ compiler... yes
checking whether g++ -m64 accepts -g... yes
checking whether g++ accepts -static-libstdc++ -static-libgcc... yes
checking for powerpc64-unknown-linux-gnu-gnatbind... no
checking for gnatbind... gnatbind
checking for powerpc64-unknown-linux-gnu-gnatmake... no
checking for gnatmake... gnatmake
checking whether compiler driver understands Ada... yes
checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1
$$f2
checking for objdir... .libs
configure: WARNING: using in-tree isl, disabling version check
The following languages will be built: c,ada,c++,fortran,go,lto,objc,obj-c++
checking for bdw garbage collector... using bdw-gc in default locations
*** This configuration is not supported in the following subdirectories:
 zlib target-libcilkrts target-libvtv target-libmpx target-libhsail-rt
target-liboffloadmic
(Any other directories should still work fine.)
checking for default BUILD_CONFIG... bootstrap-debug
checking for --enable-vtable-verify... no
checking for bison... bison -y
checking for bison... bison
checking for gm4... no
checking for gnum4... no
checking for m4... m4
checking for flex... flex
checking for flex... flex
checking for makeinfo... makeinfo
checking for expect... expect
checking for runtest... runtest
checking for powerpc64-unknown-linux-gnu-ar... no
checking for ar... ar
checking for powerpc64-unknown-linux-gnu-as... no
checking for as... as
checking for powerpc64-unknown-linux-gnu-dlltool... no
checking for dlltool... no
checking for powerpc64-unknown-linux-gnu-ld... no
checking for ld... ld
checking for powerpc64-unknown-linux-gnu-lipo... no
checking for lipo... no
checking for powerpc64-unknown-linux-gnu-nm... no
checking for nm... nm
checking for powerpc64-unknown-linux-gnu-ranlib... no
checking for ranlib... ranlib
checking for powerpc64-unknown-linux-gnu-strip... no
checking for strip... strip
checking for powerpc64-unknown-linux-gnu-windres... no
checking for windres... no
checking for powerpc64-unknown-linux-gnu-windmc... no
checking for windmc... no
checking for powerpc64-unknown-linux-gnu-objcopy... no
checking for objcopy... objcopy
checking for powerpc64-unknown-linux-gnu-objdump... no
checking for objdump... objdump
checking for powerpc64-unknown-linux-gnu-readelf... no
checking for readelf... readelf
checking for powerpc64-unknown-linux-gnu-cc... no
checking for cc... cc
checking for powerpc64-unknown-linux-gnu-c++... no
checking for c++... c++
checking for powerpc64-unknown-linux-gnu-gcc... no
checking for gcc... gcc
checking for powerpc64-unknown-linux-gnu-gfortran... no
checking for gfortran... gfortran
checking for powerpc64-unknown-linux-gnu-gccgo... no
checking for gccgo... no
checking for ar... no
checking for powerpc64-unknown-linux-gnu-ar... no
checking for ar... ar
checking for as... no
checking for powerpc64-unknown-linux-gnu-as... no
checking for as... as
checking for dlltool... no
checking for 

[Bug c++/82067] New: G++ has an internal compiler error in possible_polymorphic_call_targets, at ipa-devirt.c:1557

[jupitercuso4 at gmail dot com]

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

Bug ID: 82067
   Summary: G++ has an internal compiler error in
possible_polymorphic_call_targets, at
ipa-devirt.c:1557
   Product: gcc
   Version: 4.9.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jupitercuso4 at gmail dot com
  Target Milestone: ---

Applied patch from PR60871 but it still fails:

$ gcc -v
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/project/usr-tensilica-RHEL5/stools-8.0-2017-06-05/bin/../libexec/gcc/x86_64-pc-linux-gnu/4.9.4/lto-wrapper
Target: x86_64-pc-linux-gnu
../gcc-4.9.4/configure --with-checking=release --build=x86_64-pc-linux-gnu
-enable-languages=c,c++ --disable-libgcj --prefix=/usr/bin

$  g++ -c -O2 -g -MD -Werror -Wno-unused-value -fPIC  -Wall -Werror -O3
-fomit-frame-pointer -std=gnu++0x -Wno-non-virtual-dtor -Wno-write-strings
-Wno-deprecated -Wno-parentheses -Wno-delete-non-virtual-dtor -Wno-parentheses
-Wno-unused-variable test.cpp

test.cpp:32:1: internal compiler error: in possible_polymorphic_call_targets,
at ipa-devirt.c:1557

0x6828cb possible_polymorphic_call_targets(tree_node*, long,
ipa_polymorphic_call_context, bool*, void**, int*)
../../gcc-4.9.4/gcc/ipa-devirt.c:1557
0x665cea possible_polymorphic_call_targets(tree_node*, bool*, void**)
../../gcc-4.9.4/gcc/ipa-utils.h:142
0xc87198 gimple_fold_call
../../gcc-4.9.4/gcc/gimple-fold.c:1127
0xc87198 fold_stmt_1
../../gcc-4.9.4/gcc/gimple-fold.c:1302
0xd909b8 fold_marked_statements
../../gcc-4.9.4/gcc/tree-inline.c:4549
0xd8c2e0 optimize_inline_calls(tree_node*)
../../gcc-4.9.4/gcc/tree-inline.c:4630
0xf48b89 inline_transform(cgraph_node*)
../../gcc-4.9.4/gcc/ipa-inline-transform.c:457
0xd1b58a execute_one_ipa_transform_pass
../../gcc-4.9.4/gcc/passes.c:2066
0xd1b58a execute_all_ipa_transforms()
../../gcc-4.9.4/gcc/passes.c:2107
0xbd8abd expand_function
../../gcc-4.9.4/gcc/cgraphunit.c:1775
0xf99653 expand_all_functions
../../gcc-4.9.4/gcc/cgraphunit.c:1916
0xf99653 compile()
../../gcc-4.9.4/gcc/cgraphunit.c:2260
0xf98f17 finalize_compilation_unit()
../../gcc-4.9.4/gcc/cgraphunit.c:2337
0xb149dd cp_write_global_declarations()
../../gcc-4.9.4/gcc/cp/decl2.c:4647
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

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

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Also the documentation for the target attribute does not point to the aarch64
documentation (it does point to the arm one though):
The options supported are specific to each target; refer to x86 Function
Attributes, PowerPC Function Attributes, ARM Function Attributes,and Nios II
Function Attributes, for details.

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

[pinskia at gcc dot gnu.org]

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

Bug ID: 82066
   Summary: #pragma GCC target documentation does not say it is
implemented for aarch64
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: documentation
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

Currently the documentation stays:
The #pragma GCC target pragma is presently implemented for x86, PowerPC, and
Nios II targets only.


https://gcc.gnu.org/onlinedocs/gcc/Function-Specific-Option-Pragmas.html#Function-Specific-Option-Pragmas

But this is wrong as it is implemented for AARCH64 (and I think arm).

[Bug bootstrap/82045] [8 regression] SPARC bootstrap broken: ICE in emit_library_call_value_1, at calls.c:4565

[rsandifo at gcc dot gnu.org]

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

--- Comment #9 from rsandifo at gcc dot gnu.org  
---
Created attachment 42098
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42098=edit
first cut of fix

Here's the patch I'm testing.  Only sanity-checked on aarch64-linux-gnu and
cross sparc-sun-solaris2.11 so far.

[Bug c/82063] issues with arguments enabled by -Wall

[jim.wilson at linaro dot org]

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

--- Comment #2 from jim.wilson at linaro dot org ---
On Thu, Aug 31, 2017 at 1:32 PM, manu at gcc dot gnu.org
 wrote:
> This is already possible:
> https://gcc.gnu.org/onlinedocs/gccint/Option-properties.html
>
> LangEnabledBy(language, opt)
> LangEnabledBy(language, opt, posarg, negarg)
> ...
>
> See examples in c.opt.

I did already look at examples, and read the docs, and step through
code in the debugger.  Posarg and negarg are integers, which are
ignored for options that take a string as an argument.  So no, this
doesn't work.

Note in optc-gen.awk, where the handle_generated_option call is
generated, the fourth argument is always NULL. This is "const char
*arg" which is the argument for options that take string arguments.
The fifth argument, int value, is where the posarg/negarg value gets
passed.  Also, note, in the file opts-common.c, in the function
set_options, in the case CLVC_STRING, it uses only arg, it does not
use value.  Since the posarg/negarg values end up in value here, they
are ignored, and are useless.

I would rather ask why the -Walloc-size-larger-than= option is
(unsuccessfully) being enabled by -Wall.  It seems an odd one to try
to enable by default.

Another weirdness I just noticed, the docs say that a size suffix is
optional, but in the function alloc_max_size in calls.c, if no suffix
is specified, it does
  unit = 0;
 ...
  w *= unit;
which means the argument always gets ignored unless there is a size
suffix.  I think that should be
  unit = 1;
instead.

[Bug bootstrap/82045] [8 regression] SPARC bootstrap broken: ICE in emit_library_call_value_1, at calls.c:4565

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #6)
[...]
> Ah!  Thanks for debugging it.  I guess the problem is that we're
> passing the new machine_mode classes through ... and interpreting
> them as int in emit_library_call_value_1.  This will only work on
> ABIs that pass the two in the same way.

Which they don't: according to the SPARC psABI, structs are passed by
reference.  And indeed interpreting mode as a scalar_float_mode * yields
the expected E_TFmode value for m_mode.

Rainer

[Bug fortran/82065] New: gfortran rejects redundant use of intrinsic module constant

[damian at sourceryinstitute dot org]

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

Bug ID: 82065
   Summary: gfortran rejects redundant use of intrinsic module
constant
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: damian at sourceryinstitute dot org
  Target Milestone: ---

gfortran 6, 7, and 8 generate compiler error messages when a variable in the 
iso_fortran_env intrinsic model is accessed via use association where it is
also available via host association:

$ cat use-intrinsic-module-twice.f90 
  use iso_fortran_env
  implicit none
  print *, integer_kinds
  call testsub
contains
  subroutine testsub
use iso_fortran_env
print * , integer_kinds
  end subroutine
end

$ gfortran use-intrinsic-module-twice.f90 
/tmp/ccoAKOqk.s: Assembler messages:
/tmp/ccoAKOqk.s:134: Error: symbol `__iso_fortran_env_MOD_integer_kinds' is
already defined

$ gfortran --version
GNU Fortran (GCC) 8.0.0 20170731 (experimental)

[Bug middle-end/81512] duplicate note in -Walloca-larger-than and alloca in a return statement

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  ---
This is a general problem of the diagnostics machinery:

* Macro trace is generated after each diagnostic

* There is no way to create one diagnostic that contains several messages.

However, in this particular case, I think the warning could be smarter in one
of two ways:

* The second note could point the argument instead of the alloca call:

a.c:1:16: warning: argument to ‘alloca’ is too large [-Walloca-larger-than=]
 #define alloca __builtin_alloca
^
a.c:5:10: note: in expansion of macro ‘alloca’
   return alloca (12345);
  ^~
a.c:1:23: note: limit is 12344 bytes, but argument is 12345
   return alloca (12345);
  ^

* Alternatively, if the note is always going to be at exactly the same location
as the warning, why not simply include the text in the warning?

a.c:1:16: warning: argument to ‘alloca’ is too large (limit is 12344 bytes, but
argument is 12345) [-Walloca-larger-than=]
 #define alloca __builtin_alloca
^
a.c:5:10: note: in expansion of macro ‘alloca’
   return alloca (12345);
  ^~

Much shorter, saves vertical space.

[Bug c++/69953] [5/6 Regression] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail

[dilfridge at gentoo dot org]

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

--- Comment #35 from Andreas K. Huettel  ---
Oops sorry, that should have been:

According to https://bugs.gentoo.org/show_bug.cgi?id=629342 *not* fixed for
gcc-6.

[Bug c++/69953] [5/6 Regression] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail

[dilfridge at gentoo dot org]

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

Andreas K. Huettel  changed:

   What|Removed |Added

 CC||dilfridge at gentoo dot org

--- Comment #34 from Andreas K. Huettel  ---
According to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953 *not* fixed for
gcc-6.

[Bug c++/65324] -Wzero-as-null-pointer-constant: incorrect location for function templates

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #6 from Manuel López-Ibáñez  ---
(In reply to Jonathan Wakely from comment #5)
> Bug 52718 has some useful discussion about how to fix this.

I thought David had proposed some mechanism to add locations to constants. That
would fix this issue.

[Bug c/82063] issues with arguments enabled by -Wall

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-31
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Manuel López-Ibáñez  ---
(In reply to Jim Wilson from comment #0)
> Noticed this while looking at the -Wall documentation.
> 
> -Walloc-alloc-size-larger-than= is listed in the c-family/c.opt file as
> being enabled by -Wall, however, nothing is provided for the enable/disable
> values, as is done for every other -Wall enabled options that takes an
> argument.  The code tries to enable it using the default value of 1 and a
> NULL string, but since the option takes a string argument, the 1 value is
> ignored, and the NULL string is used, so it gets set to zero, which disables
> it.  I stepped through cc1 code in the debugger to verify this.  If we
> really do want this enabled by -Wall, then we probably need an extension to
> LangEnabledBy to specify on/off strings for arguments that take strings.

This is already possible:
https://gcc.gnu.org/onlinedocs/gccint/Option-properties.html

LangEnabledBy(language, opt)
LangEnabledBy(language, opt, posarg, negarg)

When compiling for the given language, the option is set to the value of
-opt, if not explicitly set. opt can be also a list of || separated options. In
the second form, if opt is used in the positive form then posarg is considered
to be passed to the option, and if opt is used in the negative form then negarg
is considered to be passed to the option. It is possible to specify several
different languages. Each language must have been declared by an earlier
Language record. See Option file format.

See examples in c.opt.

[Bug target/81504] [7/8 Regression] gcc-7 regression: vec_st in loop misoptimized

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #11 from Bill Schmidt  ---
Fixed.

[Bug target/81504] [7/8 Regression] gcc-7 regression: vec_st in loop misoptimized

[wschmidt at gcc dot gnu.org]

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

--- Comment #10 from Bill Schmidt  ---
Author: wschmidt
Date: Thu Aug 31 20:28:17 2017
New Revision: 251575

URL: https://gcc.gnu.org/viewcvs?rev=251575=gcc=rev
Log:
2017-08-31  Bill Schmidt  

Backport from mainline
2017-08-25  Bill Schmidt  

PR target/81504
* config/rs6000/rs6000.c (find_alignment_op): Add reference
parameter and_insn and return it.
(recombine_lvx_pattern): Insert a copy to ensure availability of
the base register of the copied masking operation at the point of
the instruction replacement.
(recombine_stvx_pattern): Likewise.


Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/rs6000/rs6000.c

[Bug bootstrap/82045] [8 regression] SPARC bootstrap broken: ICE in emit_library_call_value_1, at calls.c:4565

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-08-31
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #7 from rsandifo at gcc dot gnu.org  
---
(In reply to r...@cebitec.uni-bielefeld.de from comment #6)
> >> --- Comment #4 from rsandifo at gcc dot gnu.org  >> gnu.org> ---
> > [...]
> >>> Natively, I can easily reproduce the ICE with
> >>> 
> >>> $ cc1 -fpreprocessed libgcc2.i -quiet -mcpu=v9 -o libgcc2.s
> >>> 
> >>> Please note that I'm using a 32-bit compiler; maybe the problem doesn't
> >>> occur on a 64-bit host?
> >>
> >> That's certainly a possibility, although I don't *think* we changed
> >> anything in terms of variable sizes.
> >
> > Just to be sure, I've just built a bi-arch sparcv9-sun-solaris2.11
> > compiler: the 64-bit _multc3.o builds just fine, but the compiler ICEs
> > for the 32-bit just as the 32-bit compiler does.
> 
> On top of that, I've tried both x86_64-pc-linux-gnu x
> sparc-sun-solaris2.11 and i686-pc-linux-gnu x
> sparc-sun-solaris2.11 compilers.  Both compile the preprocessed input
> just fine.
> 
> I've now run the native cc1 under gdb.  This is the full stacktrace:
> 
> #0  fancy_abort (file=file@entry=0x2b86f8
> "/var/gcc/reghunt/trunk/gcc/calls.c", line=line@entry=4563,
> function=function@entry=0x2b8fa0  rtx_def*, libcall_type, machine_mode, int, void*)::__FUNCTION__>
> "emit_library_call_value_1") at /var/gcc/reghunt/trunk/gcc/diagnostic.c:1487
> #1  0x005a06dc in emit_library_call_value_1 (retval=retval@entry=0,
> orgfun=orgfun@entry=0xfa98e540, value=value@entry=0x0,
> fn_type=fn_type@entry=LCT_NORMAL, outmode=outmode@entry=E_SImode,
> nargs=nargs@entry=2, p=0xffbfdfc4, p@entry=0xffbfdfbc) at
> /var/gcc/reghunt/trunk/gcc/calls.c:4562
> #2  0x005a69ac in emit_library_call (orgfun=orgfun@entry=0xfa98e540,
> fn_type=fn_type@entry=LCT_NORMAL, outmode=outmode@entry=E_SImode,
> nargs=nargs@entry=2) at /var/gcc/reghunt/trunk/gcc/calls.c:5146
> #3  0x00eac154 in sparc_emit_float_lib_cmp (x=x@entry=0xfa98c948,
> y=0xfa98c960, comparison=NE) at
> /var/gcc/reghunt/trunk/gcc/config/sparc/sparc.c:8144
> #4  0x00eac3d0 in emit_scc_insn (operands=operands@entry=0xffbfe098) at
> /var/gcc/reghunt/trunk/gcc/config/sparc/sparc.c:3170
> #5  0x0104c5d0 in gen_cstoretf4 (operand0=0xfa98c978, operand1=0xfa98e530,
> operand2=0xfa98c948, operand3=0xfa98c960) at
> /var/gcc/reghunt/trunk/gcc/config/sparc/sparc.md:779
> #6  0x0099b108 in insn_gen_fn::operator() (a3=, a2= out>, a1=, a0=, this=0x50a0) at
> /var/gcc/reghunt/trunk/gcc/recog.h:303
> #7  maybe_gen_insn (icode=icode@entry=CODE_FOR_cstoretf4, nops=nops@entry=4,
> ops=ops@entry=0xffbfe1d8) at /var/gcc/reghunt/trunk/gcc/optabs.c:7046
> #8  0x0099b6ec in maybe_expand_insn (icode=icode@entry=CODE_FOR_cstoretf4,
> nops=nops@entry=4, ops=ops@entry=0xffbfe1d8) at
> /var/gcc/reghunt/trunk/gcc/optabs.c:7076
> #9  0x006eaea4 in emit_cstore (target=target@entry=0xfa9830e0,
> icode=icode@entry=CODE_FOR_cstoretf4, code=code@entry=NE,
> mode=mode@entry=E_TFmode, compare_mode=compare_mode@entry=E_TFmode,
> unsignedp=unsignedp@entry=0, x=0xfa98c948, x@entry=0xfa98e4d0, y=0xfa98c960,
> y@entry=0xfa98e4f0, normalizep=normalizep@entry=1,
> target_mode=target_mode@entry=E_QImode) at
> /var/gcc/reghunt/trunk/gcc/expmed.c:5325
> #10 0x006eb5f0 in emit_store_flag_1 (target=target@entry=0xfa9830e0,
> code=NE, op0=op0@entry=0xfa98e4d0, op1=op1@entry=0xfa98e4f0,
> mode=mode@entry=E_TFmode, unsignedp=unsignedp@entry=0,
> normalizep=normalizep@entry=1, target_mode=target_mode@entry=E_QImode) at
> /var/gcc/reghunt/trunk/gcc/expmed.c:5563
> #11 0x006eb050 in emit_store_flag (target=target@entry=0xfa9830e0,
> code=code@entry=NE, op0=op0@entry=0xfa98e4d0, op1=op1@entry=0xfa98e4f0,
> mode=mode@entry=E_TFmode, unsignedp=unsignedp@entry=0, normalizep= out>, normalizep@entry=1) at /var/gcc/reghunt/trunk/gcc/expmed.c:5823
> #12 0x006ec308 in emit_store_flag_force (target=target@entry=0xfa9830e0,
> code=code@entry=NE, op0=0xfa98e4d0, op1=0xfa98e4f0,
> mode=mode@entry=E_TFmode, unsignedp=unsignedp@entry=0, normalizep= out>, normalizep@entry=1) at /var/gcc/reghunt/trunk/gcc/expmed.c:5956
> #13 0x00713fe0 in do_store_flag (mode=, target=0xfa9830e0,
> ops=0xffbfe458) at /var/gcc/reghunt/trunk/gcc/expr.c:11511
> #14 expand_expr_real_2 (ops=ops@entry=0xffbfe500,
> target=target@entry=0xfa9830e0, tmode=,
> modifier=modifier@entry=EXPAND_NORMAL) at
> /var/gcc/reghunt/trunk/gcc/expr.c:9259
> #15 0x005b968c in expand_gimple_stmt_1 (stmt=0xfa89a2a0) at
> /var/gcc/reghunt/trunk/gcc/cfgexpand.c:3691
> #16 expand_gimple_stmt (stmt=stmt@entry=0xfa89a2a0) at
> 

[Bug c++/81942] ICE on empty constexpr constructor with C++14

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jose.marchesi at oracle dot com

--- Comment #6 from Paolo Carlini  ---
It would be nice if somebody with a fully functional ARM toolchain could check
whether something like the below at least avoids the ICE without causing any
regressions. I hope it does.

Index: constexpr.c
===
--- constexpr.c (revision 251553)
+++ constexpr.c (working copy)
@@ -3679,7 +3679,7 @@ breaks (tree *jump_target)
 {
   return *jump_target
 && ((TREE_CODE (*jump_target) == LABEL_DECL
-&& LABEL_DECL_BREAK (*jump_target))
+&& (LABEL_DECL_BREAK (*jump_target) || DECL_ARTIFICIAL
(*jump_target)))
|| TREE_CODE (*jump_target) == EXIT_EXPR);
 }

[Bug c++/81942] ICE on empty constexpr constructor with C++14

[paolo.carlini at oracle dot com]

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

--- Comment #5 from Paolo Carlini  ---
Such labels are special: they are DECL_ARTIFICIAL and are created by
create_artificial_label called by start_preparsed_function.

[Bug bootstrap/81926] go/parse.o differs between stage2 and stage3

[ebotcazou at gcc dot gnu.org]

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

--- Comment #23 from Eric Botcazou  ---
OK, I can reproduce with BUILD_CONFIG set to empty:

Comparing stages 2 and 3
Bootstrap comparison failure!
gcc/go/parse.o differs
make[2]: *** [compare] Error 1

$ grep BUILD_CONFIG config.log
configure:6993: checking for default BUILD_CONFIG
BUILD_CONFIG=''

so this is indeed similar to PR bootstrap/77995.

 35 .debug_info   0016367a      0001faf8  2**0
  CONTENTS, RELOC, READONLY, DEBUGGING

 35 .debug_info   00163670      0001faf8  2**0
  CONTENTS, RELOC, READONLY, DEBUGGING

The most glaring difference in the assembly file is:

.byte   0   ! end of children of DIE 0x161dbc
.byte   0   ! end of children of DIE 0x161d9c
.byte   0   ! end of children of DIE 0x161d5b
-   .byte   0xf2,0x1! uleb128 0xf2; (DIE (0x161dd2)
DW_TAG_ptr_to_member_type)
-   .uaword 0x10445d! DW_AT_containing_type
-   .uaword 0x14806e! DW_AT_type
-   .byte   0xa5,0x1! uleb128 0xa5; (DIE (0x161ddc)
DW_TAG_subprogram)
+   .byte   0xa5,0x1! uleb128 0xa5; (DIE (0x161dd2)
DW_TAG_subprogram)
.uaword 0x146733! DW_AT_abstract_origin

[Bug c++/81942] ICE on empty constexpr constructor with C++14

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  ---
Adding more details.
The GOTO_EXPR is generated for such targets in finish_return_stmt:

 903   if (DECL_DESTRUCTOR_P (current_function_decl)
 904   || (DECL_CONSTRUCTOR_P (current_function_decl)
 905   && targetm.cxx.cdtor_returns_this ()))
 906 {
 907   /* Similarly, all destructors must run destructors for
 908  base-classes before returning.  So, all returns in a
 909  destructor get sent to the DTOR_LABEL; finish_function emits
 910  code to return a value there.  */
 911   return finish_goto_stmt (cdtor_label);
 912 }

[Bug tree-optimization/82060] [7/8 Regression] ICE in refs_may_alias_p_1 with devirtualization enabled

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |7.3

[Bug fortran/82064] [OOP] multiple incompatible definitions of extended derived type via module use

[daanvanvugt at gmail dot com]

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

--- Comment #1 from Daan van Vugt  ---
the
!use mod_boris
should be
!use mod_f
to work around the problem in the attachment and code below

[Bug fortran/82064] New: [OOP] multiple incompatible definitions of extended derived type via module use

[daanvanvugt at gmail dot com]

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

Bug ID: 82064
   Summary: [OOP] multiple incompatible definitions of extended
derived type via module use
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daanvanvugt at gmail dot com
  Target Milestone: ---

Created attachment 42097
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42097=edit
Makefile, base type, extra module and test program

When using an extended derived type from a module through two, different, other
modules they become incompatible.
The interesting part is that I use `private` everywhere so the type itself is
not actually shared.

This results in interesting phenomena such as select type not working as
expected, and errors of class(t1) not matching class(t1).

In the attached zip file are the files needed to reproduce.
Run `make` to create `test_sep` from test_sep.f90 which prints ERR twice on my
machine.
Putting all the modules and the program together in one file yields a program
that prints OK twice. (test.f90)

I have written some changes that cause the problem to disappear as comments.



module mod_types
  type, abstract :: t
  end type t
  type, extends(t) :: t2
  end type t2
end module mod_types

module mod_f
  use mod_types
  implicit none
  private
contains
! Remove this function to fix
subroutine f(particle)
  ! if the classname here matches the type name in test_sep it breaks
  class(t2), intent(inout) :: particle
  ! using type instead of class here also works
end subroutine f
end module mod_f

module mod_test
  use mod_types
  !use mod_boris ! uncomment for a fix
  implicit none
  private
  public :: init
contains

subroutine init(p)
  class(t), intent(inout) :: p
  select type (p)
  type is (t2)
write(*,*) "OK"
  class default
write(*,*) "ERR"
  end select
end subroutine init
end module mod_test




program test_sep
use mod_types
use mod_f ! remove this to fix
use mod_test

class(t), allocatable :: p
type(t2) :: p2
allocate(t2::p)
call init(p)
call init(p2)
end program test_sep

[Bug other/82063] New: issues with arguments enabled by -Wall

[wilson at gcc dot gnu.org]

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

Bug ID: 82063
   Summary: issues with arguments enabled by -Wall
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wilson at gcc dot gnu.org
  Target Milestone: ---

Noticed this while looking at the -Wall documentation.

-Walloc-alloc-size-larger-than= is listed in the c-family/c.opt file as being
enabled by -Wall, however, nothing is provided for the enable/disable values,
as is done for every other -Wall enabled options that takes an argument.  The
code tries to enable it using the default value of 1 and a NULL string, but
since the option takes a string argument, the 1 value is ignored, and the NULL
string is used, so it gets set to zero, which disables it.  I stepped through
cc1 code in the debugger to verify this.  If we really do want this enabled by
-Wall, then we probably need an extension to LangEnabledBy to specify on/off
strings for arguments that take strings.

Both -Warray-bounds and -Warray-bounds= are listed in the c.opt file as being
enabled by -Wall, but they are the same option, and it causes this one option
to be processed twice in the C_handle_option_auto function in the generated
options.c file.  It gets set to the same value twice, so it does work as
intended, but this is wasteful.

[Bug middle-end/82062] New: [8 regression] simple conditional expressions no longer folded

[ebotcazou at gcc dot gnu.org]

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

Bug ID: 82062
   Summary: [8 regression] simple conditional expressions no
longer folded
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ebotcazou at gcc dot gnu.org
  Target Milestone: ---

The patch

2017-08-17  Marek Polacek  

PR middle-end/81814
* fold-const.c (operand_equal_for_comparison_p): Remove code that used
to mimic what shorten_compare did.  Change the return type to bool.
(fold_cond_expr_with_comparison): Update call to
operand_equal_for_comparison_p.
(fold_ternary_loc): Likewise.

has introduced regressions in the folding of simple conditional expressions,
which happens quite a lot in Ada.  Trivial examples for 64-bit targets:

unsigned long foo (int x)
{
  return x > 0 ? (unsigned long) x : 0;
}

unsigned long bar (int x, int y)
{
  return x > y ? (unsigned long) x : (unsigned long) y;
}

The COND_EXPRs are no longer folded into MAX_EXPRs.

[Bug c++/82047] non-existent variable template used to initialize variable

[ldionne.2 at gmail dot com]

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

--- Comment #7 from Louis Dionne  ---
Then, I think there's another bug in GCC (or maybe just a QOI issue), since the
following code compiles (wandbox[1]):

  template  constexpr T v;
  template  constexpr T v(888);

  struct S {
constexpr S() : value(999) { }
constexpr S(int x) : value(x) { }
int value;
  };

  static_assert(v.value == 888);


Instead, I would expect to get some error saying that I'm redefining `v` on the
second line. FWIW, Clang does think it's only a declaration [2].


[1]: https://wandbox.org/permlink/c5An5PbMbJdxa9Hj
[2]: https://wandbox.org/permlink/m9VSksjjtFhiQSab

[Bug other/82061] -Wall documentation needs updating

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||documentation
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-31
 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=71283
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed, related to bug 71283.

[Bug libstdc++/21549] Configure options hard to find

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
There's always ./configure --help=recursive from the top level; the "recursive"
makes it print the help text from subdirs like libstdc++ too.

[Bug c++/82047] non-existent variable template used to initialize variable

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
I don't think it does mandate that. I think I was wrong to say (in comment 1)
that it's only a declaration. I believe it's a definition too.

[Bug other/82061] New: -Wall documentation needs updating

[wilson at gcc dot gnu.org]

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

Bug ID: 82061
   Summary: -Wall documentation needs updating
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wilson at gcc dot gnu.org
  Target Milestone: ---

I see multiple problems with the -Wall documentation.

There are generic options missing, such as -Wframe-address.  There are C++
specific options missing, such as -Wclass-memaccess.  There are C++ specific
options present, but not mentioned as C++ specific, such as -Wreorder.  The
*.opt files need to be checked to see if there are other similar issues.

There are multiple ways to specify that an option is language dependent, e.g.
only for X, only in X, X only, in X.  This is inconsistent, we should probably
choose one and use it consistently.

[Bug c++/82047] non-existent variable template used to initialize variable

[ldionne.2 at gmail dot com]

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

Louis Dionne  changed:

   What|Removed |Added

 CC||ldionne.2 at gmail dot com

--- Comment #5 from Louis Dionne  ---
I don't understand why the standard mandates that

  template  constexpr T v;

though it is only a declaration, would actually default-initialize the object
if you try to use it (am I understanding this properly?). I understand that
this is consistent with

  constexpr T x;

which default-initializes `x`, but that is a definition, not a declaration. In
this case, maybe it doesn't make sense to pretend that

  template  constexpr T v;

is only a declaration?

[Bug c++/82039] -Wzero-as-null-pointer-constant triggers when calling std::allocate<...>::allocate

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Thu Aug 31 16:45:37 2017
New Revision: 251570

URL: https://gcc.gnu.org/viewcvs?rev=251570=gcc=rev
Log:
PR c++/82039 suppress -Wzero-as-null-pointer-constant warning

PR c++/82039
* include/ext/new_allocator.h (__gnu_cxx::new_allocator::allocate):
Adjust null pointer constant to avoid warning.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/ext/new_allocator.h

[Bug middle-end/82051] [mips]mips emit different results when compiling union var using -O0/-O2

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
On Thu, 31 Aug 2017, zwzhangwen.zhang at huawei dot com wrote:

>volatile long long  f1;

> printf ("g_121.f1=%x\n",g_121.f1);

In addition to the other points people have made about active union 
members, %x is not the correct format for long long; use %llx.

[Bug c++/82029] [8 Regression] bogus error: ‘__PRETTY_FUNCTION__’ was not declared in this scope

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  ---
Fixed.

[Bug c++/82029] [8 Regression] bogus error: ‘__PRETTY_FUNCTION__’ was not declared in this scope

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Thu Aug 31 15:39:04 2017
New Revision: 251567

URL: https://gcc.gnu.org/viewcvs?rev=251567=gcc=rev
Log:
PR c++/82029 - __PRETTY_FUNCTION__ in lambda in template

* pt.c (enclosing_instantiation_of, lambda_fn_in_template_p)
(regenerated_lambda_fn_p): New.
(tsubst_decl) [VAR_DECL]: Use enclosing_instantiation_of.
(tsubst_copy) [VAR_DECL]: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-__func__2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug c++/82047] non-existent variable template used to initialize variable

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Because std::complex has a default constructor that initializes all its
members. If you replace S with a type that leaves some members uninitialized
when default-initialized, it fails:

template struct S {};
template constexpr T v;
constexpr auto c = v;  // ok
struct init { int i = 0; };
constexpr auto ok = v;// ok
struct no_init { int i; };
constexpr auto fails = v;  // error

This is consistent with:

constexpr init x;  // ok
constexpr no_init y;   // error
constexpr no_init z{}; // ok