[Bug c/61191] cilkplus ICE on syntax error

[izamyatin at gmail dot com]

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

--- Comment #6 from Igor Zamyatin  ---
Thanks!

[Bug middle-end/60102] [4.9/4.10 Regression] powerpc fp-bit ices at dwf_regno

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.1
Summary|powerpc fp-bit ices at  |[4.9/4.10 Regression]
   |dwf_regno   |powerpc fp-bit ices at
   ||dwf_regno

--- Comment #10 from Richard Biener  ---
Please specify more exactly the affected target triplet and specify a
known-to-work version.

Marking as regression for now.

[Bug bootstrap/61326] bootstrap failure of gcc-4.8.3 on ia64-hpux

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2014-05-27
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Can you attach preprocessed source so we can investigate with a cross compiler?

[Bug ipa/61324] [4.10 Regression] ICE: SIGSEGV at ipa-comdats.c:321 with -fno-use-cxa-atexit -fkeep-inline-functions

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org
   Target Milestone|--- |4.10.0

[Bug rtl-optimization/61325] [4.10 regression] aarch64_be build fails

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||build
   Target Milestone|--- |4.10.0

[Bug middle-end/60102] [4.9/4.10 Regression] powerpc fp-bit ices at dwf_regno

[sebastian.hu...@embedded-brains.de]

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

--- Comment #11 from Sebastian Huber  ---
(In reply to Richard Biener from comment #10)
> Please specify more exactly the affected target triplet and specify a
> known-to-work version.
> 
> Marking as regression for now.

A target is for example "powerpc-eabispe" or "powerpc-rtems".

Known to work are GCC 4.8.0, 4.8.1, 4.8.2 and 4.8.3.

[Bug c/61328] New: valgrind finds problem in find_bswap_or_nop_1

[dcb314 at hotmail dot com]

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

Bug ID: 61328
   Summary: valgrind finds problem in find_bswap_or_nop_1
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com

Created attachment 32859
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32859&action=edit
C source code

I just compiled the attached code with gcc trunk 20140526 with flag -O2 under
valgrind and it said

==24014== Conditional jump or move depends on uninitialised value(s)
==24014==at 0xA8F1F5: find_bswap_or_nop_1(gimple_statement_base*,
symbolic_number*, int) (tree-ssa-math-opts.c:1918)
==24014==by 0xA8FD14: (anonymous
namespace)::pass_optimize_bswap::execute(function*) (tree-ssa-math-opts.c:2034)
==24014==by 0x8AA350: execute_one_pass(opt_pass*) (passes.c:2180)
==24014==by 0x8AAAF7: execute_pass_list_1(opt_pass*) (passes.c:2233)
==24014==by 0x8AADC7: execute_pass_list(function*, opt_pass*)
(passes.c:2234)
==24014==by 0x64757C: expand_function(cgraph_node*) (cgraphunit.c:1783)
==24014==by 0x64926C: compile() [clone .part.31] (cgraphunit.c:1917)

tree-ssa-math-opts.c:1918 is

  if (n1.size != n2.size || !source_expr2)
return NULL_TREE;

Maybe

  if (!source_expr2)
return NULL_TREE;

  if (n1.size != n2.size)
return NULL_TREE;

would be better code.

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #1 from Richard Biener  ---
> gcc/java/jcf.h:#define GET_u2(PTR) (((PTR)[0] << 8) | ((PTR)[1]))
>
> smells like
>
> 2014-05-23  Thomas Preud'homme  
>
> PR tree-optimization/54733
> * tree-ssa-math-opts.c (nop_stats): New "bswap_stats" structure.
> ...

I've now confirmed that this patch is indeed the culprit.

Rainer

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
Thomas,

btw, I noticed that you use duplicate dg-options in
gcc.dg/optimize-bswapsi-[12].c.  Please use dg-additional-options for
the s390-*-* case to avoid the duplication.

Thanks.
Rainer

[Bug testsuite/61319] The tests c-c++-common/ubsan/float-cast-overflow-(1|2|4).c fail on x86_64-apple-darwin*

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-05-27
  Component|target  |testsuite
 Ever confirmed|0   |1

--- Comment #7 from Dominique d'Humieres  ---
> This test also fails on Centos 5 for the same reason.

Reset component to testsuite.

[Bug libstdc++/61329] New: #include and _GLIBCXX_DEBUG causes multiple symbol definition.

[pluto at agmk dot net]

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

Bug ID: 61329
   Summary: #include  and _GLIBCXX_DEBUG causes multiple
symbol definition.
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pluto at agmk dot net

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

% g++ t.cpp -Og -g0 -c -std=c++11 -D_GLIBCXX_DEBUG
% g++ u.cpp -Og -g0 -c -std=c++11 -D_GLIBCXX_DEBUG
% g++ t.o u.o -s -o /dev/null 

u.o: In function
`std::__detail::__7::_State_base::_M_print(std::__7::basic_ostream >&) const':
u.cpp:(.text+0x0): multiple definition of
`std::__detail::__7::_State_base::_M_print(std::__7::basic_ostream >&) const'
t.o:t.cpp:(.text+0x0): first defined here
u.o: In function
`std::__detail::__7::_State_base::_M_dot(std::__7::basic_ostream >&, long) const':
u.cpp:(.text+0x1ae): multiple definition of
`std::__detail::__7::_State_base::_M_dot(std::__7::basic_ostream >&, long) const'
t.o:t.cpp:(.text+0x1ae): first defined here
collect2: error: ld returned 1 exit status


% g++ -v 
Using built-in specs.
COLLECT_GCC=/ahome/pawels/dvm/master/toolchain/gcc/sysroot/x86_64-gnu-linux/bin/x86_64-gnu-linux-g++
COLLECT_LTO_WRAPPER=/home/pawels/dvm/master/toolchain/gcc/sysroot/x86_64-gnu-linux/bin/../lib64/gcc/x86_64-gnu-linux/4.9.1/lto-wrapper
Target: x86_64-gnu-linux
Configured with: ../configure --target=x86_64-gnu-linux --with-arch=x86-64
--prefix=/home/pawels/toolchain.git/gcc/sysroot/x86_64-gnu-linux
--with-sysroot=/home/pawels/toolchain.git/gcc/sysroot/x86_64-gnu-linux
--libdir=/home/pawels/toolchain.git/gcc/sysroot/x86_64-gnu-linux/lib64
--libexecdir=/home/pawels/toolchain.git/gcc/sysroot/x86_64-gnu-linux/lib64
--with-slibdir=/home/pawels/toolchain.git/gcc/sysroot/x86_64-gnu-linux/lib64
--with-gmp-include=/home/pawels/toolchain.git/gcc/x86_64-gnu-linux/gcc-math-runtime/include
--with-gmp-lib=/home/pawels/toolchain.git/gcc/x86_64-gnu-linux/gcc-math-runtime/lib
--with-mpfr-include=/home/pawels/toolchain.git/gcc/x86_64-gnu-linux/gcc-math-runtime/include
--with-mpfr-lib=/home/pawels/toolchain.git/gcc/x86_64-gnu-linux/gcc-math-runtime/lib
--with-mpc-include=/home/pawels/toolchain.git/gcc/x86_64-gnu-linux/gcc-math-runtime/include
--with-mpc-lib=/home/pawels/toolchain.git/gcc/x86_64-gnu-linux/gcc-math-runtime/lib
--with-linker-hash-style=both --disable-multilib --enable-nls --disable-libssp
--disable-libquadmath --disable-libitm --enable-tls
--enable-libstdcxx-allocator=new --enable-extern-template
--enable-libstdcxx-time=rt --enable-libstdcxx-threads
--enable-symvers=gnu-versioned-namespace --disable-libstdcxx-pch --enable-lto
--enable-plugin --enable-c99 --enable-long-long --enable-linux-futex
--enable-threads=posix --enable-shared --with-pic --enable-gold
--enable-libgomp --enable-__cxa_atexit --disable-initfini-array
--disable-gnu-unique-object --enable-languages=c,c++ --enable-checking=release
--with-long-double-128 --disable-cld --disable-bootstrap
Thread model: posix
gcc version 4.9.1 20140505 (prerelease) (GCC)

[Bug libstdc++/61329] #include and _GLIBCXX_DEBUG causes multiple symbol definition.

[pluto at agmk dot net]

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

--- Comment #1 from Pawel Sikora  ---
Created attachment 32861
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32861&action=edit
testcase

[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[thomas.preudhomme at arm dot com]

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

--- Comment #6 from Thomas Preud'homme  ---
Sure, I'll push a patch for this as soon as I finish fixing the regressions
that poped up due to the change I made to the bswap pass.

[Bug testsuite/61319] The tests c-c++-common/ubsan/float-cast-overflow-(1|2|4).c fail on x86_64-apple-darwin*

[dominiq at gcc dot gnu.org]

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

--- Comment #8 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Tue May 27 08:36:37 2014
New Revision: 210958

URL: http://gcc.gnu.org/viewcvs?rev=210958&root=gcc&view=rev
Log:
2014-05-27  Dominique d'Humieres 

PR testsuite/61319
* c-c++-common/ubsan/float-cast-overflow-1.c: Make the sign of
-nan optional.
* c-c++-common/ubsan/float-cast-overflow-2.c: Likewise.
* c-c++-common/ubsan/float-cast-overflow-4.c: Likewise.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-1.c
trunk/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-2.c
trunk/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-4.c

[Bug libgcc/61152] Missing GCC Runtime Library Exception in some files that are included in libgcc

[gjl at gcc dot gnu.org]

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

--- Comment #1 from Georg-Johann Lay  ---
Author: gjl
Date: Tue May 27 08:41:24 2014
New Revision: 210959

URL: http://gcc.gnu.org/viewcvs?rev=210959&root=gcc&view=rev
Log:
PR libgcc/61152
* config/arm/arm-opts.h (License): Add GCC Runtime Library Exception.
* config/arm/arm-cores.def (License): Same.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm-cores.def
trunk/gcc/config/arm/arm-opts.h

[Bug libstdc++/61329] #include and _GLIBCXX_DEBUG causes multiple symbol definition.

[pluto at agmk dot net]

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

--- Comment #2 from Pawel Sikora  ---
_M_dot/_M_print declaration from include/c++/4.9.1/bits/regex_automaton.h needs
inline attribute.

[Bug bootstrap/61326] bootstrap failure of gcc-4.8.3 on ia64-hpux

[alm at sibmail dot ru]

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

--- Comment #2 from Alexander  ---
Created attachment 32862
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32862&action=edit
the preprocessed file 1

[Bug bootstrap/61326] bootstrap failure of gcc-4.8.3 on ia64-hpux

[alm at sibmail dot ru]

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

--- Comment #3 from Alexander  ---
preprocessed source added in attachment

[Bug c++/56947] [4.7 Regression] Bogus 'XX' was not declared in this scope

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Blocks||52026

--- Comment #3 from Richard Biener  ---
Confirmed that.  I suppose rejects-valid is "better" than wrong-code in some
sense but the former only was for C++11 code.  If there isn't a safe fix for
this issue I'd consider reverting the patch for PR52026.

[Bug target/61330] New: Thumb ICE for case 920507-1.c

[tony.wang at arm dot com]

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

Bug ID: 61330
   Summary: Thumb ICE for case 920507-1.c
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tony.wang at arm dot com

I'm running regression test for the latest GCC trunk for cortex-m0, I run into
below ICE, but after I remove the commit at trunk@210901, the test case will
pass.

How to reproduce:
Executing on host: /work/terguo01/trunk-t1/build-native/gcc-final/gcc/xgcc
-B/work/terguo01/trunk-t1/build-native/gcc-final/gcc/
/work/terguo01/trunk-t1/src/gcc/gcc/testsuite/gcc.dg/noncompile/920507-1.c 
-fno-diagnostics-show-caret -fdiagnostics-color=never   -O1  -ffat-lto-objects
-S-mthumb -mcpu=cortex-m0 -o 920507-1.s(timeout = 300)
spawn /work/terguo01/trunk-t1/build-native/gcc-final/gcc/xgcc
-B/work/terguo01/trunk-t1/build-native/gcc-final/gcc/
/work/terguo01/trunk-t1/src/gcc/gcc/testsuite/gcc.dg/noncompile/920507-1.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O1 -ffat-lto-objects -S
-mthumb -mcpu=cortex-m0 -o 920507-1.s^M
/work/terguo01/trunk-t1/src/gcc/gcc/testsuite/gcc.dg/noncompile/920507-1.c: In
function 'x':^M
/work/terguo01/trunk-t1/src/gcc/gcc/testsuite/gcc.dg/noncompile/920507-1.c:5:16:
error: invalid register name for 'a'^M
/work/terguo01/trunk-t1/src/gcc/gcc/testsuite/gcc.dg/noncompile/920507-1.c:3:1:
internal compiler error: in symtab_get_node, at cgraph.h:1021^M
0xc1920c symtab_get_node^M
/work/terguo01/trunk-t1/src/gcc/gcc/cgraph.h:1018^M
0xc1920c symtab_get_node^M
/work/terguo01/trunk-t1/src/gcc/gcc/varasm.c:1134^M
0xc1920c decl_comdat_group^M
/work/terguo01/trunk-t1/src/gcc/gcc/cgraph.h:1629^M
0xc1920c get_block_for_decl^M
/work/terguo01/trunk-t1/src/gcc/gcc/varasm.c:1146^M
0xc1cadf make_decl_rtl(tree_node*)^M
/work/terguo01/trunk-t1/src/gcc/gcc/varasm.c:1376^M
0x8d6b4f rest_of_decl_compilation(tree_node*, int, int)^M
/work/terguo01/trunk-t1/src/gcc/gcc/passes.c:215^M
0x6206a3 expand_one_hard_reg_var^M
/work/terguo01/trunk-t1/src/gcc/gcc/cfgexpand.c:1108^M
0x6206a3 expand_one_var^M
/work/terguo01/trunk-t1/src/gcc/gcc/cfgexpand.c:1295^M
0x620e0b expand_used_vars_for_block^M
/work/terguo01/trunk-t1/src/gcc/gcc/cfgexpand.c:1338^M
0x62c1e6 expand_used_vars^M

[Bug libgcc/61152] Missing GCC Runtime Library Exception in some files that are included in libgcc

[gjl at gcc dot gnu.org]

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

--- Comment #2 from Georg-Johann Lay  ---
Author: gjl
Date: Tue May 27 09:05:12 2014
New Revision: 210960

URL: http://gcc.gnu.org/viewcvs?rev=210960&root=gcc&view=rev
Log:
gcc/
Backport from 2014-05-12 mainline r210322.
Backport from 2014-05-27 mainline r210959.
PR libgcc/61152
* config/arm/arm.h (License): Add GCC Runtime Library Exception.
* config/arm/arm-cores.def (License): Same.
* config/arm/arm-opts.h (License): Same.
* config/arm/aout.h (License): Same.
* config/arm/bpabi.h (License): Same.
* config/arm/elf.h (License): Same.
* config/arm/linux-elf.h (License): Same.
* config/arm/linux-gas.h (License): Same.
* config/arm/netbsd-elf.h (License): Same.
* config/arm/uclinux-eabi.h (License): Same.
* config/arm/uclinux-elf.h (License): Same.
* config/arm/vxworks.h (License): Same.
libgcc/
Backport from 2014-05-27 mainline r210322.
PR libgcc/61152
* config/arm/bpabi-lib.h (License): Add GCC Runtime Library Exception.


Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/arm/aout.h
branches/gcc-4_9-branch/gcc/config/arm/arm-cores.def
branches/gcc-4_9-branch/gcc/config/arm/arm-opts.h
branches/gcc-4_9-branch/gcc/config/arm/arm.h
branches/gcc-4_9-branch/gcc/config/arm/bpabi.h
branches/gcc-4_9-branch/gcc/config/arm/elf.h
branches/gcc-4_9-branch/gcc/config/arm/linux-elf.h
branches/gcc-4_9-branch/gcc/config/arm/linux-gas.h
branches/gcc-4_9-branch/gcc/config/arm/netbsd-elf.h
branches/gcc-4_9-branch/gcc/config/arm/uclinux-eabi.h
branches/gcc-4_9-branch/gcc/config/arm/uclinux-elf.h
branches/gcc-4_9-branch/gcc/config/arm/vxworks.h
branches/gcc-4_9-branch/libgcc/ChangeLog
branches/gcc-4_9-branch/libgcc/config/arm/bpabi-lib.h

[Bug target/61330] [4.10 Regression] Thumb ICE for case 920507-1.c

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
   Target Milestone|--- |4.10.0
Summary|Thumb ICE for case  |[4.10 Regression] Thumb ICE
   |920507-1.c  |for case 920507-1.c

--- Comment #1 from Richard Biener  ---
Seems the parser fails to set DECL_HARD_REGISTER on that bogus decl.

[Bug c/61328] valgrind finds problem in find_bswap_or_nop_1

[thomas.preudhomme at arm dot com]

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

--- Comment #1 from Thomas Preud'homme  ---
*facepalm*

Yes indeed. Does this qualify for an obvious fix as per commiting rules?

[Bug target/59904] [ARM] tls-reload-1.c fails

[christophe.lyon at st dot com]

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

--- Comment #10 from christophe.lyon at st dot com ---
Created attachment 32863
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32863&action=edit
ELF binary file #2

Compiled with arm-none-linux-gnueabi-gcc -O1 -pie -fpie -mthumb -march=armv5t
tls-reload-1.c -o tls-reload-1.exe

Binutils Linaro 2014.03

[Bug c/61328] valgrind finds problem in find_bswap_or_nop_1

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
(In reply to Thomas Preud'homme from comment #1)
> *facepalm*
> 
> Yes indeed. Does this qualify for an obvious fix as per commiting rules?

Yes.

[Bug c++/61327] Problem with friend template object

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-05-27
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Reduced:

template
struct A;

template
struct A
{
  template
  void f(U* u) {
u->T::g();
  }
};

struct B {
protected:
  void g() { }
};

struct C : B {
  template friend struct A;
};

int main()
{
  C c;
  A a;
  a.f(&c);
}

The partial specialization does not match the friend declaration for some
reason, I think it should do.

[Bug testsuite/61319] The tests c-c++-common/ubsan/float-cast-overflow-(1|2|4).c fail on x86_64-apple-darwin*

[ubizjak at gmail dot com]

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

--- Comment #9 from Uroš Bizjak  ---
CentOS 5 still fails with:

./float-cast-overflow-1.c:75:7: error: 'LLONG_MIN' undeclared (first use in
this function)
./float-cast-overflow-1.c:79:7: error: 'LLONG_MAX' undeclared (first use in
this function)
./float-cast-overflow-1.c:84:7: error: 'ULLONG_MAX' undeclared (first use in
this function)

[Bug target/59904] [ARM] tls-reload-1.c fails

[tony.wang at arm dot com]

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

--- Comment #11 from wangzheyu  ---
Hi,
Could you please provide an elf file compiled with arm-none-linux-gnueabi-gcc
-Os -g3 -pie -fpie -mthumb -march=armv5t So that we can debug under our
hardware and easy to compared with the former one. Thanks a lot.

(In reply to christophe.lyon from comment #10)
> Created attachment 32863 [details]
> ELF binary file #2
> 
> Compiled with arm-none-linux-gnueabi-gcc -O1 -pie -fpie -mthumb
> -march=armv5t tls-reload-1.c -o tls-reload-1.exe
> 
> Binutils Linaro 2014.03

[Bug target/59904] [ARM] tls-reload-1.c fails

[christophe.lyon at st dot com]

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

--- Comment #12 from christophe.lyon at st dot com ---
Created attachment 32864
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32864&action=edit
ELF binary file #3

Compiled with -Os -g3 -pie -fpie -march=armv5t -mthumb

[Bug testsuite/61319] The tests c-c++-common/ubsan/float-cast-overflow-(1|2|4).c fail on x86_64-apple-darwin*

[mpolacek at gcc dot gnu.org]

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

--- Comment #10 from Marek Polacek  ---
Ah.  I hope the following will help:

--- a/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-1.c
+++ b/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-1.c
@@ -5,6 +5,16 @@
 #include 
 #include "float-cast.h"

+#if !defined LLONG_MAX && defined __LONG_LONG_MAX__
+# define LLONG_MAX __LONG_LONG_MAX__
+#endif
+#if !defined LLONG_MIN && defined __LONG_LONG_MAX__
+# define LLONG_MIN (-__LONG_LONG_MAX__ - 1LL)
+#endif
+#if !defined ULLONG_MAX && defined __LONG_LONG_MAX__
+# define ULLONG_MAX (__LONG_LONG_MAX__ * 2ULL + 1ULL)
+#endif
+
 int
 main (void)
 {

[Bug testsuite/61319] The tests c-c++-common/ubsan/float-cast-overflow-(1|2|4).c fail on x86_64-apple-darwin*

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
(In reply to Marek Polacek from comment #10)
> Ah.  I hope the following will help:
> 
> --- a/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-1.c
> +++ b/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-1.c
> @@ -5,6 +5,16 @@
>  #include 
>  #include "float-cast.h"
>  
> +#if !defined LLONG_MAX && defined __LONG_LONG_MAX__
> +# define LLONG_MAX __LONG_LONG_MAX__
> +#endif
> +#if !defined LLONG_MIN && defined __LONG_LONG_MAX__
> +# define LLONG_MIN (-__LONG_LONG_MAX__ - 1LL)
> +#endif
> +#if !defined ULLONG_MAX && defined __LONG_LONG_MAX__
> +# define ULLONG_MAX (__LONG_LONG_MAX__ * 2ULL + 1ULL)
> +#endif
> +
>  int
>  main (void)
>  {

__LONG_LONG_MAX__ is always defined, no need to test for that.

[Bug c++/57543] decltype needs explicit 'this' pointer in member function declaration of template class with trailing return type

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com
   Target Milestone|--- |4.10.0

--- Comment #3 from Paolo Carlini  ---
Mine.

[Bug testsuite/61319] The tests c-c++-common/ubsan/float-cast-overflow-(1|2|4).c fail on x86_64-apple-darwin*

[mpolacek at gcc dot gnu.org]

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

--- Comment #12 from Marek Polacek  ---
Thus

--- a/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-1.c
+++ b/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-1.c
@@ -5,6 +5,16 @@
 #include 
 #include "float-cast.h"

+#ifndef LLONG_MAX
+# define LLONG_MAX __LONG_LONG_MAX__
+#endif
+#ifndef LLONG_MIN
+# define LLONG_MIN (-__LONG_LONG_MAX__ - 1LL)
+#endif
+#ifndef ULLONG_MAX
+# define ULLONG_MAX (__LONG_LONG_MAX__ * 2ULL + 1ULL)
+#endif
+
 int
 main (void)
 {

[Bug libstdc++/61329] #include and _GLIBCXX_DEBUG causes multiple symbol definition.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-05-27
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |4.9.1
 Ever confirmed|0   |1

[Bug libstdc++/61329] #include and _GLIBCXX_DEBUG causes multiple symbol definition.

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Tue May 27 11:14:17 2014
New Revision: 210968

URL: http://gcc.gnu.org/viewcvs?rev=210968&root=gcc&view=rev
Log:
PR libstdc++/61329
* include/bits/regex_automaton.tcc (_State_base::_M_print): Add
inline specifier.
(_State_base::_M_dot): Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/regex_automaton.tcc

[Bug testsuite/61319] The tests c-c++-common/ubsan/float-cast-overflow-(1|2|4).c fail on x86_64-apple-darwin*

[ubizjak at gmail dot com]

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

--- Comment #13 from Uroš Bizjak  ---
(In reply to Marek Polacek from comment #12)
> Thus
> 
> --- a/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-1.c
> +++ b/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-1.c

Yes, this patch works for me on x86_64-pc-linux-gnu {,-m32} Centos 5.

BTW: IMO, the new defines should be put in float-cast.h, alongside INT128
defines.

Thanks!

[Bug testsuite/61319] The tests c-c++-common/ubsan/float-cast-overflow-(1|2|4).c fail on x86_64-apple-darwin*

[mpolacek at gcc dot gnu.org]

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

--- Comment #14 from Marek Polacek  ---
Thanks, will post the patch to ML.

[Bug middle-end/61207] Win64 gcc 4.9.0: ICE at -Os compiling some C++ code

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-05-27
 Ever confirmed|0   |1

--- Comment #1 from Kai Tietz  ---
ICE happens in in expand_expr_addr_expr_1 because the result is (reg/v:TI 86 [
func ]), which is obviously no memory.
Issue seems here to be that x64 ABI has pre-allocated stack-area on call, so
for the first 4 arguments no stack-allocation is necessary.  So we might need
to specialize allocate_stack_slots_for_args-hook for this target.

[Bug libgcc/61152] Missing GCC Runtime Library Exception in some files that are included in libgcc

[gjl at gcc dot gnu.org]

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

--- Comment #3 from Georg-Johann Lay  ---
Author: gjl
Date: Tue May 27 11:37:49 2014
New Revision: 210969

URL: http://gcc.gnu.org/viewcvs?rev=210969&root=gcc&view=rev
Log:
PR libgcc/61152
* config/arm/arm.h (License): Add note to COPYING.RUNTIME.
* config/arm/arm-cores.def (License): Same.
* config/arm/arm-opts.h (License): Same.
* config/arm/aout.h (License): Same.
* config/arm/bpabi.h (License): Same.
* config/arm/elf.h (License): Same.
* config/arm/linux-elf.h (License): Same.
* config/arm/linux-gas.h (License): Same.
* config/arm/netbsd-elf.h (License): Same.
* config/arm/uclinux-eabi.h (License): Same.
* config/arm/uclinux-elf.h (License): Same.
* config/arm/vxworks.h (License): Same.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/aout.h
trunk/gcc/config/arm/arm-cores.def
trunk/gcc/config/arm/arm-opts.h
trunk/gcc/config/arm/arm.h
trunk/gcc/config/arm/bpabi.h
trunk/gcc/config/arm/elf.h
trunk/gcc/config/arm/linux-elf.h
trunk/gcc/config/arm/linux-gas.h
trunk/gcc/config/arm/netbsd-elf.h
trunk/gcc/config/arm/uclinux-eabi.h
trunk/gcc/config/arm/uclinux-elf.h
trunk/gcc/config/arm/vxworks.h

[Bug testsuite/61319] The tests c-c++-common/ubsan/float-cast-overflow-(1|2|4).c fail on x86_64-apple-darwin*

[mpolacek at gcc dot gnu.org]

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

--- Comment #15 from Marek Polacek  ---
Author: mpolacek
Date: Tue May 27 11:41:45 2014
New Revision: 210970

URL: http://gcc.gnu.org/viewcvs?rev=210970&root=gcc&view=rev
Log:
PR testsuite/61319
* c-c++-common/ubsan/float-cast.h: Conditionally define LLONG_MAX,
LLONG_MIN, and ULLONG_MAX.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/ubsan/float-cast.h

[Bug libgcc/61152] Missing GCC Runtime Library Exception in some files that are included in libgcc

[gjl at gcc dot gnu.org]

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

--- Comment #4 from Georg-Johann Lay  ---
Author: gjl
Date: Tue May 27 11:42:10 2014
New Revision: 210971

URL: http://gcc.gnu.org/viewcvs?rev=210971&root=gcc&view=rev
Log:
PR libgcc/61152
* config/arm/arm.h (License): Add note to COPYING.RUNTIME.
* config/arm/arm-cores.def (License): Same.
* config/arm/arm-opts.h (License): Same.
* config/arm/aout.h (License): Same.
* config/arm/bpabi.h (License): Same.
* config/arm/elf.h (License): Same.
* config/arm/linux-elf.h (License): Same.
* config/arm/linux-gas.h (License): Same.
* config/arm/netbsd-elf.h (License): Same.
* config/arm/uclinux-eabi.h (License): Same.
* config/arm/uclinux-elf.h (License): Same.
* config/arm/vxworks.h (License): Same.


Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/arm/aout.h
branches/gcc-4_9-branch/gcc/config/arm/arm-cores.def
branches/gcc-4_9-branch/gcc/config/arm/arm-opts.h
branches/gcc-4_9-branch/gcc/config/arm/arm.h
branches/gcc-4_9-branch/gcc/config/arm/bpabi.h
branches/gcc-4_9-branch/gcc/config/arm/elf.h
branches/gcc-4_9-branch/gcc/config/arm/linux-elf.h
branches/gcc-4_9-branch/gcc/config/arm/linux-gas.h
branches/gcc-4_9-branch/gcc/config/arm/netbsd-elf.h
branches/gcc-4_9-branch/gcc/config/arm/uclinux-eabi.h
branches/gcc-4_9-branch/gcc/config/arm/uclinux-elf.h
branches/gcc-4_9-branch/gcc/config/arm/vxworks.h

[Bug testsuite/61319] The tests c-c++-common/ubsan/float-cast-overflow-(1|2|4).c fail on x86_64-apple-darwin*

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #16 from Marek Polacek  ---
I hope this is fixed now.

[Bug target/61044] Computed goto on AVR fails to use word-addressing

[senthil_kumar.selvaraj at atmel dot com]

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

--- Comment #3 from Senthil Kumar Selvaraj  ---
Johann,

The primary reason I added the diff relocs was to prevent linker relaxation
messing up DWARF line number information - as you know, relaxation can shorten
instruction sequences, and the addresses in DWARF then go out of sync.

I guess I must add some user documentation about this, but ideally, this is
supposed to be transparent to the user - just passing -mrelax to the compiler
should work.

I turned diff reloc generation on only if -mlink-relax is passed because this
is what other ports (xtensa) do, and I wasn't sure of the consequences of
resolving every subtraction expression at link time.

I tried assembling .word pm(.L3-.L2) with -mlink-relax, but the assembler gave
up with an "expression too complex" error. Like you said, I guess documenting
that this is not supported is the way to go.

[Bug other/61321] demangler crash on casts in template parameters

[palves at redhat dot com]

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

--- Comment #3 from Pedro Alves  ---
https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02279.html

[Bug other/61233] Demangler crash (GDB PR 16957)

[palves at redhat dot com]

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

--- Comment #2 from Pedro Alves  ---
This fixes it:

 https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02279.html

See bug 61321.

[Bug target/61170] FAIL: libgomp.fortran/declare-simd-[12].f90 on darwin

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Dominique d'Humieres  ---
Fixed by revision 210961 (tests now unsupported)

Author:uros
Date:Tue May 27 09:14:53 2014 UTC (3 hours, 28 minutes ago)
Log Message:
* testsuite/libgomp.fortran/declare-simd-1.f90: Require
vect_simd_clones effective target.
* testsuite/libgomp.fortran/declare-simd-2.f90: Ditto.

[Bug libfortran/59513] [4.7/4.8/4.9] Fortran runtime error: Sequential READ or WRITE not allowed after EOF marker, possibly use REWIND or BACKSPACE

[giorgio.signorini at unifi dot it]

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

giorgio.signorini at unifi dot it changed:

   What|Removed |Added

 CC||giorgio.signorini at unifi dot 
it

--- Comment #13 from giorgio.signorini at unifi dot it ---
(In reply to Dominique d'Humieres from comment #11)
> No error with gfortran  4.4.7, 4.5.4, but gfortran 4.6.4 gives the error. So
> marked as a 4.7/4.8/4.9 regression. 
> 
> When I'll have learnt how to build foil myself, I'll try to do some
> bisection and some reduction.

I think this is connected to bug 44477
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44477), which has been fixed in
gfortran 4.6.

Could it be that the POSITION='APPEND' option acts like a sequence of READs up
to EOF, which in gfortran < 4.6 did a silent, non-standard BACKSPACE?

[Bug libstdc++/61329] #include and _GLIBCXX_DEBUG causes multiple symbol definition.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
fixed for 4.9.1

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Tue May 27 13:12:55 2014
New Revision: 210972

URL: http://gcc.gnu.org/viewcvs?rev=210972&root=gcc&view=rev
Log:
PR libstdc++/61329
* include/bits/regex_automaton.tcc (_State_base::_M_print): Add
inline specifier.
(_State_base::_M_dot): Likewise.

Modified:
branches/gcc-4_9-branch/libstdc++-v3/ChangeLog
branches/gcc-4_9-branch/libstdc++-v3/include/bits/regex_automaton.tcc

[Bug libstdc++/61329] #include and _GLIBCXX_DEBUG causes multiple symbol definition.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
fixed for 4.9.1

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Tue May 27 13:12:55 2014
New Revision: 210972

URL: http://gcc.gnu.org/viewcvs?rev=210972&root=gcc&view=rev
Log:
PR libstdc++/61329
* include/bits/regex_automaton.tcc (_State_base::_M_print): Add
inline specifier.
(_State_base::_M_dot): Likewise.

Modified:
branches/gcc-4_9-branch/libstdc++-v3/ChangeLog
branches/gcc-4_9-branch/libstdc++-v3/include/bits/regex_automaton.tcc

[Bug target/61331] New: [ARM] GCC build broken since r210964/r210954

[christophe.lyon at st dot com]

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

Bug ID: 61331
   Summary: [ARM] GCC build broken since r210964/r210954
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christophe.lyon at st dot com

Build of GCC trunk is broken since commits 210964 and 210965 for ARM targets.

$
/work1/lyon/Work/ARM/Linaro/builds/gcc-fsf-trunk/obj-arm-none-linux-gnueabihf/gcc1/./gcc/xgcc
-B/work1/lyon/Work/ARM/Linaro/builds/gcc-fsf-trunk/obj-arm-none-linux-gnueabihf/gc\
c1/./gcc/
-B/work1/lyon/Work/ARM/Linaro/builds/gcc-fsf-trunk/tools/arm-none-linux-gnueabihf/bin/
-B/work1/lyon/Work/ARM/Linaro/builds/gcc-fsf-trunk/tools/arm-none-linux-gnueabihf\
/lib/ -g -O2-fPIC -fno-inline -g  -fbuilding-libgcc -fno-stack-protector  
-fPIC -fno-inline -o unwind-arm.o -fexceptions -c unwind-arm.i
-fvisibility=hidden
/work1/lyon/Work/ARM/Linaro/sources/gcc-fsf/trunk/libgcc/config/arm/unwind-arm.c:
In function '_Unwind_VRS_Pop':  
/work1/lyon/Work/ARM/Linaro/sources/gcc-fsf/trunk/libgcc/config/arm/unwind-arm.c:446:1:
internal compiler error: in lra_update_insn_recog_data, at lra.c:1363  
   }  
^   
0x86af74 lra_update_insn_recog_data(rtx_def*)  

/work1/lyon/Work/ARM/Linaro/sources/gcc-fsf/trun/gcc/lra.c:1362 
0x881692 eliminate_regs_in_insn 
   
/work1/lyon/Work/ARM/Linaro/sources/gcc-fsf/trunk/gcc/lra-eliminations.c:1077   
0x881c44 process_insn_for_elimination  
   
/work1/lyon/Work/ARM/Linaro/sources/gcc-fsf/trunk/gcc/lra-eliminations.c:1344   
0x881c44 lra_eliminate(bool,bool)
   
/work1/lyon/Work/ARM/Linaro/sources/gcc-fsf/trunk/gcc/lra-eliminations.c:1408   
0x87bc0a lra_constraints(bool) 
   
/work1/lyon/Work/ARM/Linaro/sources/gcc-fsf/trunk/gcc/lra-constraints.c:4049
0x86c84c lra(_IO_FILE*) 
/work1/lyon/Work/ARM/Linaro/sources/gcc-fsf/trunk/gcc/lra.c:2332
0x82b80e do_reload 
/work1/lyon/Work/ARM/Linaro/sources/gcc-fsf/trunk/gcc/ira.c:5444
0x82b80e execute  
/work1/lyon/Work/ARM/Linaro/sources/gcc-fsf/trunk/gcc/ira.c:5605

GCC configured with --target=arm-none-linux-gnueabihf --disable-nls
--without-headers --with-newlib --disable-shared --disable-threads
--disable-libssp --disable-libgomp --disable-libmudflap --disable-libatomic
--without-libquadmath --disable-libquadmath --enable-languages=c
--with-float=hard --enable-build-with-cxx --with-mode=arm --with-cpu=cortex-a9
--with-fpu=neon

[Bug target/61331] [ARM] GCC build broken since r210964/r210954

[christophe.lyon at st dot com]

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

--- Comment #1 from christophe.lyon at st dot com ---
Created attachment 32865
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32865&action=edit
unwind-arm.i

[Bug target/61202] gcc generates invalid sqdmulh instruction

[java4ada at yahoo dot com]

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

java4ada at yahoo dot com changed:

   What|Removed |Added

 CC||java4ada at yahoo dot com

--- Comment #5 from java4ada at yahoo dot com ---
Will this bug cover 4.8.x as well? (or file separate bug for 4.8.x)

[Bug bootstrap/61315] wide-int.cc cannot be built by darwin system compiler

[howarth at nitro dot med.uc.edu]

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

Jack Howarth  changed:

   What|Removed |Added

 CC||howarth at nitro dot med.uc.edu

--- Comment #5 from Jack Howarth  ---
(In reply to Andrew Pinski from comment #3)
> Still does not matter, the compiler is broken and should be reported to
> Apple.  The time for work around in broken compilers is so 90s and really
> should not be done.  This is clang being broken and really should be fixed
> there instead.

Is the object here to burn all bridges with the darwin target and leave those
users only the option of using llvm based compilers as of gcc 4.10? While I
realize you are all frustrated with the abandonment of post-GPLv2 tools in
darwin., this action simply makes it extremely easy for Apple to depreciate
their ancient gas assembler in the next Xcode for darwin14 since Apple can
rightly say that FSF gcc no longer bootstraps on darwin anyway. I am certain
that gas will be depreciated from some future darwin but hopefully will be
replaced by a stand-alone assembler based on the clang built-in assembler.
However, if FSF gcc starts to get overly self-self-rightous about the compiler
details of clang, we might as well fold up our tents on the darwin target.

ps Be careful what you wish for. I just updated the llvm34-3.4.1-0e package in
fink to use the openmp svn trunk and a back port of the current clang-omp
github based on clang 3.4. The resulting clang/clang++ compilers have excellent
OpenMP performance defaulted to -fopenmp as -liomp5 rather than -lgomp.

http://fink.9193.n7.nabble.com/llvm34-3-4-1-0e-and-OpenMP3-1-Validation-tt46118.html

While you are still lucky that there has been little effort on a fortran
llvm-based compiler, the rest is a work in rapid progress. So go ahead and
dismiss that user base if that is what you desire.

[Bug c++/13590] [DR39] Non-existing ambiguity when inheriting through virtuals two identical using declarations.

[darkdragon-001 at web dot de]

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

darkdragon-001 at web dot de changed:

   What|Removed |Added

 CC||darkdragon-001 at web dot de

--- Comment #20 from darkdragon-001 at web dot de ---
I think that non abiguous cases should be allowed. My basic inheritance
structure is as follows:

01 class Base {
02 public:
03virtual void foo() { cout << "Base" << endl; }
04 };
05 class A : public Base {
06public:
07//using Base::foo;
08//virtual void foo() { cout << "A" << endl; }
09//virtual void foo() { Base::foo(); }
10 };
11 class B : public Base {
12public:
13//virtual void foo() { cout << "B" << endl; }
14 };
15 class AB : public A,B {
16public:
17 //using Base::foo;
18//using A::foo;
19//using A::Base::foo;
20//virtual void foo() { cout << "AB" << endl; }
21 };
22 
23 int main() {
24 //Base *p = new AB;
25 AB *p = new AB;
26 //p->foo();
27 
28 return 0;
29 }

Currently only the following case is possible:
0.) uncomment line 09, 18, 26 which is the worst option I think

The following cases should be allowed:
1.) uncomment line 24 // virtual and non virtual functions are unambiguous
2.) uncomment line 26 // it is clear to use HW::foo() -> both paths same
properties
3.) uncomment line 17 // clear to use HW::foo()
4.) uncomment line 18 (perhaps together with line 07) // clear to use the
inherited A::foo() which inherits from the HW::foo()
5.) change line 11 to "class B : private Base {" // only A::foo is accessible,
B::foo not
6.) doing the the cases above without virtual

[Bug bootstrap/61315] wide-int.cc cannot be built by darwin system compiler

[howarth at nitro dot med.uc.edu]

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

--- Comment #6 from Jack Howarth  ---
I would also add that you are playing with fire here. Currently no company has
a motivation to expend money or resources for fortran development on llvm as
long as FSF gcc is buildable. If you start removing competing compilers from
bootstrapping FSF gcc, it is much more likely that someone will fund such a
llvm-based fortran compiler project. You may get some short-term satisfaction
from walling off FSF-gcc from clang, the long-term outcome for the FSF gcc
project might not be so happy.

[Bug bootstrap/61315] wide-int.cc cannot be built by darwin system compiler

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  ---
A patch has been posted at
https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02173.html.

[Bug target/61296] Excessive alignment in ix86_data_alignment

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  ---
The comdat definition needs to the biggest alignment
generated by any compilers.

[Bug bootstrap/61315] wide-int.cc cannot be built by darwin system compiler

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Jack Howarth from comment #5)
> (In reply to Andrew Pinski from comment #3)
> > Still does not matter, the compiler is broken and should be reported to
> > Apple.  The time for work around in broken compilers is so 90s and really
> > should not be done.  This is clang being broken and really should be fixed
> > there instead.
> 
> Is the object here to burn all bridges with the darwin target and leave
> those users only the option of using llvm based compilers as of gcc 4.10?

Well they burned a bridge with saying to the user of their front-end they
support GNU C when they do not.

[Bug rtl-optimization/61222] [4.10 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu in decompose, at rtl.h:1456

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #6 from rsandifo at gcc dot gnu.org  
---
Fixed on trunk.

[Bug c++/61327] Problem with friend template object

[isak50 at mail dot ru]

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

--- Comment #2 from Pavel  ---
// Clang compiles without errors.
class B {
protected:
  void f() {}
};

template 
struct S;

template 
struct S{
template 
static void caller(T *p) {p->B::f();}   // error: 'void B::f()' is
protected
//static void caller(T *p) {p->f();}// Ok
};

class Q : B{
template  friend struct S;
};

int main(){
Q q;
S::caller(&q);
return 0;
}

[Bug bootstrap/61315] wide-int.cc cannot be built by darwin system compiler

[howarth at nitro dot med.uc.edu]

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

--- Comment #9 from Jack Howarth  ---
(In reply to Andrew Pinski from comment #8)

> > Is the object here to burn all bridges with the darwin target and leave
> > those users only the option of using llvm based compilers as of gcc 4.10?
> 
> Well they burned a bridge with saying to the user of their front-end they
> support GNU C when they do not.

Well it is kind of late in the game to decide that this is a show-stopper for
supporting any target which uses clang as the system compiler. At this point
closing bug reports and refusing to even discuss a simple workaround via
preprocessor statements in FSF gcc bugzilla just looks petty.

[Bug c++/13590] [DR39] Non-existing ambiguity when inheriting through virtuals two identical using declarations.

[redi at gcc dot gnu.org]

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

--- Comment #21 from Jonathan Wakely  ---
Since I'm not sure if any of the examples here are meant to be accepted (some
definitely aren't) here's the example from the standard which should compile:


struct A { int x; };// S(x,A) = { { A::x }, { A }}
struct B { float x; };  // S(x,B) = { { B::x }, { B }}
struct C: public A, public B { }; // S(x,C) = { invalid, { A in C, B in C } }
struct D: public virtual C { }; // S(x,D) = S(x,C)
struct E: public virtual C { char x; }; // S(x,E) = { { E::x }, { E }}
struct F: public D, public E { };   // S(x,F) = S(x,E)
int main() {
  F f;
  f.x = 0; // OK, lookup finds E::x
}

[Bug libobjc/61332] New: libobjc unsafe malloc use instead objc_malloc

[max at cert dot cx]

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

Bug ID: 61332
   Summary: libobjc unsafe malloc use instead objc_malloc
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: libobjc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: max at cert dot cx

Hi,

I have found interesting examples of dynamic memory allocation use in libobjc

libobjc/selector.c -
SEL *
sel_copyTypedSelectorList (const char *name, unsigned int
*numberOfReturnedSelectors)
{
  unsigned int count = 0;
  SEL *returnValue = NULL;
  sidx i;

  if (name == NULL)
{
  if (numberOfReturnedSelectors)
*numberOfReturnedSelectors = 0;
  return NULL;
}

  objc_mutex_lock (__objc_runtime_mutex);

  /* Count how many selectors we have.  */
  i = (sidx) objc_hash_value_for_key (__objc_selector_hash, name);
  if (i != 0)
{
  struct objc_list *selector_list = NULL;
  selector_list = (struct objc_list *) sarray_get_safe
(__objc_selector_array, i);

  /* Count how many selectors we have.  */
  {
struct objc_list *l;
for (l = selector_list; l; l = l->tail)
  count++;
  }

  if (count != 0)
{
  /* Allocate enough memory to hold them.  */
  returnValue = (SEL *)(malloc (sizeof (SEL) * (count + 1)));
<===

  /* Copy the selectors.  */
  {
unsigned int j;
for (j = 0; j < count; j++)
  {
returnValue[j] = (SEL)(selector_list->head);
<===
selector_list = selector_list->tail;
  }
returnValue[j] = NULL;
 libobjc/selector.c -

 or 

 libobjc/ivars.c  -
 struct objc_ivar ** class_copyIvarList (Class class_, unsigned int
*numberOfReturnedIvars)
{
  unsigned int count = 0;
  struct objc_ivar **returnValue = NULL;
  struct objc_ivar_list* ivar_list;

  if (class_ == Nil  ||  CLS_IS_IN_CONSTRUCTION (class_))
{
  if (numberOfReturnedIvars)
*numberOfReturnedIvars = 0;
  return NULL;
}

  /* Count how many ivars we have.  */
  ivar_list = class_->ivars;
  count = ivar_list->ivar_count;

  if (count != 0)
{
  unsigned int i = 0;

  /* Allocate enough memory to hold them.  */
  returnValue = (struct objc_ivar **)(malloc (sizeof (struct objc_ivar *) *
(count + 1))); <==

  /* Copy the ivars.  */
  for (i = 0; i < count; i++)
returnValue[i] = &(ivar_list->ivar_list[i]); <===

  returnValue[i] = NULL;
}
libobjc/ivars.c  -  

 or

libobjc/protocols.c  -
Protocol **
objc_copyProtocolList (unsigned int *numberOfReturnedProtocols)
{
  unsigned int count = 0;
  Protocol **returnValue = NULL;
  node_ptr node;

  objc_mutex_lock (__protocols_hashtable_lock);

  /* Count how many protocols we have.  */
  node = objc_hash_next (__protocols_hashtable, NULL);
  while (node)
{
  count++;
  node = objc_hash_next (__protocols_hashtable, node);
}

  if (count != 0)
{
  unsigned int i = 0;

  /* Allocate enough memory to hold them.  */
  returnValue = (Protocol **)(malloc (sizeof (Protocol *) * (count + 1)));
<===

  /* Copy the protocols.  */
  node = objc_hash_next (__protocols_hashtable, NULL);
<===
  while (node)
{
  returnValue[i] = node->value;
libobjc/protocols.c  -


Why malloca() was used instead objc_malloc()? Is there any sensible reason?
In terms of safety, if you can create a properly buffer length (FREE_MEMORY / 2
+1) may end up to crash at this point. 

http://cwe.mitre.org/data/definitions/252.html

Thanks for taking the time.

Maksymilian
http://cifrex.org

[Bug c++/61182] [4.9/4.10 Regression] Forming pointer to qualified function type

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #12 from Jason Merrill  ---
So, not a GCC bug.

[Bug c/56724] sub-optimal location in error

[mpolacek at gcc dot gnu.org]

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

--- Comment #11 from Marek Polacek  ---
Author: mpolacek
Date: Tue May 27 20:14:22 2014
New Revision: 210980

URL: http://gcc.gnu.org/viewcvs?rev=210980&root=gcc&view=rev
Log:
PR c/56724
* c-typeck.c (convert_arguments): Get location of a parameter.  Change
error and warning calls to error_at and warning_at.  Pass location of
a parameter to it.  Call warning_at with OPT_Wtraditional_conversion.
(convert_for_assignment): Add parameter to WARN_FOR_ASSIGNMENT and
WARN_FOR_QUALIFIERS.  Pass expr_loc to those.

* gcc.dg/pr56724-1.c: New test.
* gcc.dg/pr56724-2.c: New test.
* gcc.dg/wtr-conversion-1.c: Use -Wtraditional-conversion instead of
-Wtraditional.
* gcc.dg/dfp/wtr-conversion-1.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/pr56724-1.c
trunk/gcc/testsuite/gcc.dg/pr56724-2.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/dfp/wtr-conversion-1.c
trunk/gcc/testsuite/gcc.dg/wtr-conversion-1.c

[Bug libobjc/61332] libobjc unsafe malloc use instead objc_malloc

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
The difference between malloc and objc_malloc is minor when not using GC.  In
fact the program will crash is malloc returns NULL anyways.

[Bug bootstrap/61315] wide-int.cc cannot be built by darwin system compiler

[mrs at gcc dot gnu.org]

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

mrs at gcc dot gnu.org  changed:

   What|Removed |Added

 CC||mrs at gcc dot gnu.org
 Resolution|INVALID |DUPLICATE

--- Comment #10 from mrs at gcc dot gnu.org  ---
This is a duplicate of 61146.  Non-technical content to gnu.misc.discuss
please.

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

[Bug other/61146] wide-int error when building GCC with clang

[mrs at gcc dot gnu.org]

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

mrs at gcc dot gnu.org  changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu.org

--- Comment #5 from mrs at gcc dot gnu.org  ---
*** Bug 61315 has been marked as a duplicate of this bug. ***

[Bug other/61146] wide-int error when building GCC with clang

[mrs at gcc dot gnu.org]

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

mrs at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|RESOLVED|ASSIGNED
   Last reconfirmed||2014-05-27
 CC||mrs at gcc dot gnu.org
 Resolution|INVALID |---
 Ever confirmed|0   |1

--- Comment #6 from mrs at gcc dot gnu.org  ---
Don't worry, gcc will build with clang.

[Bug other/61146] wide-int error when building GCC with clang

[mrs at gcc dot gnu.org]

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

--- Comment #7 from mrs at gcc dot gnu.org  ---
Patch posted https://gcc.gnu.org/ml/gcc/2014-05/msg00316.html

[Bug libobjc/61332] libobjc unsafe malloc use instead objc_malloc

[max at cert dot cx]

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

--- Comment #2 from Maksymilian A  ---
It seems that we have two problems here:
1 The first is memory allocation without GC_malloc (when GC used) 
2 If OBJC_WITH_GC is not definied, objc_malloc() also check result of malloc()

-
 objc_malloc (size_t size)
{
  void *res = (void *)(malloc (size));
  if (! res)
_objc_abort ("Virtual memory exhausted\n");
  return res;
}
-

related to

https://www.securecoding.cert.org/confluence/display/cplusplus/EXP34-CPP.+Ensure+a+null+pointer+is+not+dereferenced

Thank you for your attention

Maksymilian Arciemowicz
http://cifrex.org

[Bug target/60732] FAIL: g++.dg/ext/altivec-7.C -std=* scan-assembler _Z3fooDv*

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-05-27
 Ever confirmed|0   |1

--- Comment #6 from Iain Sandoe  ---
(In reply to Dominique d'Humieres from comment #5)
> > Mike, what do you think is the best solution here?  We could use Dominique's
> > patch with a comment to the effect that "New-ABI symbols are always emitted
> > on Linux, but only with -fabi-version=4 or later on Darwin."  We could 
> > revert
> > my change and hardcode -fabi-version=2 for all targets.  Or we could take 
> > the
> > suggestion from your original review email and duplicate the test into 
> > new-ABI
> > and old-ABI versions, and do both of those.
> 
> I am in favor of the duplicated test.

It looks to me like the ELF toolchain is emitting a non-weak alias for the
alternate symbol.

We don't (currently) support that in Darwin (and it's pretty unlikely we will
given ld64's atom rules).

Therefore, I concur that the correct action is to have two tests - one for each
ABI and run both tests on all targets.

[Bug libgomp/61333] New: potential target specific performance issue with libgomp

[howarth.at.gcc at gmail dot com]

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

Bug ID: 61333
   Summary: potential target specific performance issue with
libgomp
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: howarth.at.gcc at gmail dot com
CC: jakub at gcc dot gnu.org

While benchmarking the new openmp/clang-omp support against gcc/libgomp on
x86_64-apple-darwin13, I noticed a potential performance issue in gcc/libgomp
on darwin. Using the attached heated_plate_openmp.c and heated_plate_gcc.sh
shell script, I am seeing reproducible timing on darwin that ratio to the
timing for one thread as..

gcc 4.8.3   1:1.90:3.31
gcc 4.9.0   1:1.90:3.30
clang 2.4   1:1.99:3.71

compared to Fedora 15 linux 

gcc 4.6.3   1:1.99:3.92

This is where the timings for the one, two and four OMP processes are
normalized to the timing for one OMP process.

Unfortunately I don't have access to gcc 4.8.3 or 4.9.0 to test on linux.
The timings are reproducible and suggest that darwin may have a performance
issue for higher number of OMP threads.

[Bug libgomp/61333] potential target specific performance issue with libgomp

[howarth.at.gcc at gmail dot com]

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

--- Comment #1 from Jack Howarth  ---
Created attachment 32866
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32866&action=edit
heated_plate_openmp.c test code

[Bug libgomp/61333] potential target specific performance issue with libgomp

[howarth.at.gcc at gmail dot com]

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

--- Comment #2 from Jack Howarth  ---
Created attachment 32867
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32867&action=edit
heated_plate_gcc.sh shell script to collect timings

[Bug libgomp/61333] potential target specific performance issue with libgomp

[howarth.at.gcc at gmail dot com]

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

--- Comment #3 from Jack Howarth  ---
FYI, the timings on clang are for clang 3.4.1 with a merge of current clang-omp
github commit f9e2fd7640f8fc06ebe1ef2f065c6158f6b4b6ef and openmp svn trunk
from llvm.org at r208472/

[Bug libgomp/61333] potential target specific performance issue with libgomp

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
The reason why GCC on linux is better is because it uses the futex syscall to
have better locking (lower overhead).  See config/linux/{mutex,lock}.c.

While on Darwin, it directly calls into pthread_mutex calls.

[Bug middle-end/58670] asm goto miscompilation

[gccbugzilla at limegreensocks dot com]

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

David  changed:

   What|Removed |Added

 CC||gccbugzilla@limegreensocks.
   ||com

--- Comment #5 from David  ---
What's the status here?  While there was a checkin (r203383 & r203384), this
sample code still does not work correctly (4.9.0 x86_64-w64-mingw32).  The
fall-thru case works, but if the jump inside the asm is taken, eax does not get
set to zero when it clearly should.

My -O2 output is:

004014e0 :
  4014e0:test   ecx,ecx
  4014e2:movDWORD PTR [rsp+0x10],edx
  4014e6:jne4014f3 
  4014e8:btsDWORD PTR [rsp+0x10],0x1
  4014ee:jb 401500 
  4014f0:xoreax,eax
  4014f2:ret
  4014f3:moveax,0xfffd
  4014f8:nopDWORD PTR [rax+rax*1+0x0]
  401500:repz ret 
  401502:data32 data32 data32 data32 nop WORD PTR cs:[rax+rax*1+0x0]

[Bug lto/61334] New: [4.10 Regression] lto-cgraph.c:976:68: error: 'strnlen' was not declared in this scope

[danglin at gcc dot gnu.org]

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

Bug ID: 61334
   Summary: [4.10 Regression] lto-cgraph.c:976:68: error:
'strnlen' was not declared in this scope
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Host: hppa2.0w-hp-hpux11.11
Target: hppa2.0w-hp-hpux11.11
 Build: hppa2.0w-hp-hpux11.11

g++ -c   -g -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables
-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format
-Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I.
-I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include
-I../../gcc/gcc/../libcpp/include -I/opt/gnu/gcc/gmp/include 
-I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd
-I../libdecnumber -I../../gcc/gcc/../libbacktrace-o lto-streamer.o -MT
lto-streamer.o -MMD -MP -MF ./.deps/lto-streamer.TPo
../../gcc/gcc/lto-streamer.c
../../gcc/gcc/lto-cgraph.c: In function 'tree_node*
read_comdat_group(lto_input_block*)':
../../gcc/gcc/lto-cgraph.c:976:68: error: 'strnlen' was not declared in this
scope
make[3]: *** [lto-cgraph.o] Error 1

[Bug libgomp/61333] potential target specific performance issue with libgomp

[howarth.at.gcc at gmail dot com]

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

--- Comment #5 from Jack Howarth  ---
It would be interesting to find out what Intel openmp is doing differently on
darwin since it is significantly faster on four threads.

[Bug libgomp/61333] potential target specific performance issue with libgomp

[howarth.at.gcc at gmail dot com]

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

--- Comment #6 from Jack Howarth  ---
There is a call to pthread_cond_timedwait() in the libiomp5 implementation but
I don't see any such calls in libgomp. Perhaps this is the related to the
increased performance in libiomp5 on darwin?

[Bug libgomp/61333] potential target specific performance issue with libgomp

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Jack Howarth from comment #6)
> There is a call to pthread_cond_timedwait() in the libiomp5 implementation
> but I don't see any such calls in libgomp. Perhaps this is the related to
> the increased performance in libiomp5 on darwin?

I also see direct use of spin locks rather than calling into the pthread
library.  Maybe the pthread library has an syscall overhead.

[Bug lto/61123] With LTO, -fno-short-enums is ignored, resulting in ABI mis-matching in linking.

[Hale.Wang at arm dot com]

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

--- Comment #2 from Hale Wang  ---
(In reply to Richard Biener from comment #1)
> All ABI changing options should be also enabled for LTO and they also deserve
> handling in lto-opts.c (always stream, not only if explicitely set) and
> lto-wrapper.c (diagnose mismatches and force a setting for the link stage).
> 
> At least enabling them for LTO is minimally required, like you suggest.


Hi Richard,

I was dealing with the fno-short-enum bug that LTO ignore the options of
fshort-enum and fshort-wchar(fshort-wchar is similar with fshort-enum). I tried
to fix this bug by adding these options to LTO group. And this solution works.

Right now, I am trying to add some test cases to report some error message for
these cases in the previous gcc versions. And these cases will be passed after
I add these options to LTO group.

For the option of fshort-enum, I catch the Tag_ABI_enum_size from the final
executable. And this test case can work very well now.

But for  the option of fshort-wchar, if I compile the source files without
"-flto" option, I can catch the Tag_ABI_PCS_wchar_t from the final executable.
If I add the "-flto" option to the compile command, the Tag_ABI_PCS_wchar_t is
totally disappeared in the final executable.

So I think this is another bug which means the final executable file (or the
ABI) is different if we add "-flto" or not. 

I generated a minimal example.I have two source files:

wchar_0.c:
 #include 
 wchar_t wc0[]=L”abc”;
 const wchar_t   wc1[]=L”abc”; 

wchar_1.c:
 #include 
 wchar_t   b0[]={ L”abc” };
 const wchar_t   b1[]={ L”abc” }; 

Firstly, I compile these files without “-flto”:

$ arm-none-eabi-gcc  -fshort-wchar  wchar_0.c  wchar_1.c  -Wl,-Ur  -o 
without_flto.o  -nostdlib  -Os
$ arm-none-eabi-readelf  -A  without_flto.o

Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "ARM7TDMI"
  Tag_CPU_arch: v4T
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-1
  Tag_ABI_PCS_wchar_t: 2
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_align_preserved: 8-byte, except leaf SP
  Tag_ABI_enum_size: small
  Tag_ABI_optimization_goals: Aggressive Size


Then I compile these files with –flto:

$ arm-none-eabi-gcc  -fshort-wchar  wchar_0.c  wchar_1.c  -Wl,-Ur  -o 
with_flto.o  -nostdlib  -Os –flto
$ arm-none-eabi-readelf  -A  with_flto.o

Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "ARM7TDMI"
  Tag_CPU_arch: v4T
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-1
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_align_preserved: 8-byte, except leaf SP
  Tag_ABI_enum_size: small
  Tag_ABI_optimization_goals: Aggressive Size

So we can see the Tag_ABI_PCS_wchar_t attribute is totally disappeared. 

What do you think about this?