[Bug tree-optimization/58627] [4.9 Regression] crash during compilation of boost testsuite

2013-10-05 Thread markus at trippelsdorf dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58627

--- Comment #1 from Markus Trippelsdorf markus at trippelsdorf dot de ---
Created attachment 30957
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30957action=edit
testcase


[Bug tree-optimization/58627] New: [4.9 Regression] crash during compilation of boost testsuite

2013-10-05 Thread markus at trippelsdorf dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58627

Bug ID: 58627
   Summary: [4.9 Regression] crash during compilation of boost
testsuite
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: markus at trippelsdorf dot de

Crash happened during compilation of the boost testsuite.
It's hard to reduce the testcase, because it appears to be a bug in the 
garbage-collector.

[With --enable-checking=release]
 % g++ -O0 -std=c++11 -c test.ii 
test.ii: In member function ‘boost::chrono::durationRep, Period
boost::chrono::durationRep, Period::operator--() [with Rep = double; Period =
boost::ratio1l]’:
test.ii:3207:286: internal compiler error: Segmentation fault

[gcc-4.8.1 is fine]
 % /usr/x86_64-pc-linux-gnu/gcc-bin/4.8.1/g++ -O2 -std=c++11 -c test.i
 % 

[Backtrace with --enable-checking]
 % gdb --args /var/tmp/gcc_test/usr/local/bin/g++ -w -O0 -std=c++11
-Wfatal-errors -c test.ii -pipe -o /dev/null
Reading symbols from /var/tmp/gcc_test/usr/local/bin/g++...done.
(gdb) run
Starting program: /var/tmp/gcc_test/usr/local/bin/g++ -w -O0 -std=c++11
-Wfatal-errors -c test.ii -pipe -o /dev/null
[New process 20470]
process 20470 is executing new program:
/var/tmp/gcc_test/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/cc1plus

Program received signal SIGSEGV, Segmentation fault.
[Switching to process 20470]
0x00c8e9f8 in tree_class_check_failed (node=optimized out,
cl=optimized out, file=0xff512d ../../gcc/gcc/c-family/c-common.h,
line=1063, 
function=0xff514f c_tree_chain_next) at ../../gcc/gcc/tree.c:9223
9223../../gcc/gcc/tree.c: No such file or directory.
(gdb) bt
#0  0x00c8e9f8 in tree_class_check_failed (node=optimized out,
cl=optimized out, file=0xff512d ../../gcc/gcc/c-family/c-common.h,
line=1063, 
function=0xff514f c_tree_chain_next) at ../../gcc/gcc/tree.c:9223
#1  0x006807f1 in tree_class_check (__class=optimized out,
__f=optimized out, __l=optimized out, __g=optimized out, __t=optimized
out, 
__class=optimized out, __f=optimized out, __l=optimized out,
__g=optimized out) at ../../gcc/gcc/tree.h:2732
#2  c_tree_chain_next (t=optimized out) at
../../gcc/gcc/c-family/c-common.h:1063
#3  gt_ggc_mx_lang_tree_node (x_p=optimized out) at ./gt-cp-tree.h:158
#4  0x0067f79a in gt_ggc_mx_lang_tree_node (x_p=optimized out) at
./gt-cp-tree.h:706
#5  0x00680ba3 in gt_ggc_mx_tinst_level (x_p=optimized out) at
./gt-cp-tree.h:124
#6  0x0057b363 in gt_ggc_mx_pending_template (x_p=optimized out) at
./gt-cp-pt.h:44
#7  0x008dfa6b in ggc_mark_root_tab (rt=optimized out) at
../../gcc/gcc/ggc-common.c:133
#8  ggc_mark_roots () at ../../gcc/gcc/ggc-common.c:152
#9  0x0072d91b in ggc_collect () at ../../gcc/gcc/ggc-page.c:2077
#10 0x0079f9c3 in cgraph_finalize_function (decl=optimized out,
no_collect=optimized out) at ../../gcc/gcc/cgraphunit.c:456
#11 0x0065c3fc in expand_or_defer_fn (fn=0x7fffeeb57500) at
../../gcc/gcc/cp/semantics.c:3949
#12 0x00574935 in instantiate_decl (d=0x7fffeeb57500, defer_ok=error
reading variable: Cannot access memory at address 0x0,
expl_inst_class_mem_p=optimized out)
at ../../gcc/gcc/cp/pt.c:19406
#13 0x00577738 in instantiate_pending_templates (retries=optimized
out) at ../../gcc/gcc/cp/pt.c:19493
#14 0x005b9454 in cp_write_global_declarations () at
../../gcc/gcc/cp/decl2.c:4065
#15 0x00aa2196 in compile_file () at ../../gcc/gcc/toplev.c:560
#16 0x00aa1f67 in do_compile () at ../../gcc/gcc/toplev.c:1893
#17 toplev_main (argc=16, argv=0x7fffe028) at ../../gcc/gcc/toplev.c:1969
#18 0x774d3a6e in __libc_start_main () from /lib/libc.so.6
#19 0x004e090d in _start ()

[Bug libstdc++/58625] std::signbit always converts to double

2013-10-05 Thread olegendo at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58625

--- Comment #4 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Paolo Carlini from comment #1)
 Weird that nobody noticed for so much time.

Probably not everybody is practicing the neurotic habit of checking the asm
output for every bit and piece ;)

(In reply to Paolo Carlini from comment #2)
 Well, now I see this can be certainly a correctness issue, for eg very small
 negative long doubles. Thus I think we should certainly do the change anyway
 for 4.9. For c_std I'm afraid we have to add overloads (I think, essentially
 copy over the corresponding bits of c_global without constexpr). Can you
 send a patch to the libstdc++-v3 mailing list? And, please, double check
 isnan and isinf. Thanks!

Yes, I can do that.  But how to check this in a target independent way?  Tree
dump and check whether the correct builtin names appear?

There's another place in file libstdc++-v3/include/c_std/cmath:

  templatetypename _Tp
inline typename __gnu_cxx::__enable_if__is_arithmetic_Tp::__value,
   int::__type
signbit(_Tp __f)
{
  typedef typename __gnu_cxx::__promote_Tp::__type __type;
  return __builtin_signbit(__type(__f));
}

I guess that this is supposed to be used when C++ code pulls in math.h and
uses the C macro signbit instead of std::signbit.  It doesn't happen on my SH /
newlib cross config -- I get something like ((sizeof(x) == sizeof(float)) ?
__signbitf(x) : __signbitd(x)).  But if on some config it does happen, then the
problem would be the same, thus requiring signbit (and friends) overloads as
it's done for sqrt etc in the same file, right?


[Bug libstdc++/58625] std::signbit always converts to double

2013-10-05 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58625

--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org ---
Some builtins are type generic, meaning that you can use just the non-{l,f}
suffixed variant always, but __builtin_signbit isn't among them.
Grep shows that these builtins have type generic attribute:

DEF_GCC_BUILTIN(BUILT_IN_FPCLASSIFY, fpclassify,
BT_FN_INT_INT_INT_INT_INT_INT_VAR, ATTR_CONST_NOTHROW_TYPEGENERIC_LEAF)
DEF_GCC_BUILTIN(BUILT_IN_ISFINITE, isfinite, BT_FN_INT_VAR,
ATTR_CONST_NOTHROW_TYPEGENERIC_LEAF)
DEF_GCC_BUILTIN(BUILT_IN_ISINF_SIGN, isinf_sign, BT_FN_INT_VAR,
ATTR_CONST_NOTHROW_TYPEGENERIC_LEAF)
DEF_C99_C90RES_BUILTIN (BUILT_IN_ISINF, isinf, BT_FN_INT_VAR,
ATTR_CONST_NOTHROW_TYPEGENERIC)
DEF_C99_C90RES_BUILTIN (BUILT_IN_ISNAN, isnan, BT_FN_INT_VAR,
ATTR_CONST_NOTHROW_TYPEGENERIC_LEAF)
DEF_GCC_BUILTIN(BUILT_IN_ISNORMAL, isnormal, BT_FN_INT_VAR,
ATTR_CONST_NOTHROW_TYPEGENERIC_LEAF)
DEF_GCC_BUILTIN(BUILT_IN_ISGREATER, isgreater, BT_FN_INT_VAR,
ATTR_CONST_NOTHROW_TYPEGENERIC_LEAF)
DEF_GCC_BUILTIN(BUILT_IN_ISGREATEREQUAL, isgreaterequal,
BT_FN_INT_VAR, ATTR_CONST_NOTHROW_TYPEGENERIC_LEAF)
DEF_GCC_BUILTIN(BUILT_IN_ISLESS, isless, BT_FN_INT_VAR,
ATTR_CONST_NOTHROW_TYPEGENERIC_LEAF)
DEF_GCC_BUILTIN(BUILT_IN_ISLESSEQUAL, islessequal, BT_FN_INT_VAR,
ATTR_CONST_NOTHROW_TYPEGENERIC_LEAF)
DEF_GCC_BUILTIN(BUILT_IN_ISLESSGREATER, islessgreater, BT_FN_INT_VAR,
ATTR_CONST_NOTHROW_TYPEGENERIC_LEAF)
DEF_GCC_BUILTIN(BUILT_IN_ISUNORDERED, isunordered, BT_FN_INT_VAR,
ATTR_CONST_NOTHROW_TYPEGENERIC_LEAF)


[Bug regression/58603] [4.9 Regression] hash-table.h:962: error: anachronistic old-style base class initia

2013-10-05 Thread rsandifo at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58603

--- Comment #6 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 
---
(In reply to dave.anglin from comment #5)
 KDE added a trailing underscore to work around this issue.

Seems easier just to #undef m_slot for hpux in system.h.


[Bug libstdc++/58628] New: Incorrect std::isalpha results with UTF-8 locale on illumos

2013-10-05 Thread alp at rsu dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58628

Bug ID: 58628
   Summary: Incorrect std::isalpha results with UTF-8 locale on
illumos
   Product: gcc
   Version: 4.4.7
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alp at rsu dot ru

The following example when compiled with gcc 3.4,4.7 or 4.4  and launched with
en_US.UTF-8 locale on illumos says that char with 196 code is alphabetic,
however it's not a correct UTF-8 symbol.


$ env LANG=en_US.UTF-8 ./test_ctype
�
letter is �
(int)letter is 196
std::use_facet:true

If this program is compiled with Sun Studio Compiler (CC) results are:
$ env LANG=en_US.UTF-8 ./test_ctype_CC
�
letter is �
(int)letter is 196
std::use_facet:false

if I compile this program on Linux / FreeBSD , results are correct.

Related OpenIndiana bug report: 
https://www.illumos.org/issues/4173
Discussion on illumos-dev:
http://comments.gmane.org/gmane.os.illumos.devel/14193

[Bug libstdc++/58628] Incorrect std::isalpha results with UTF-8 locale on illumos

2013-10-05 Thread alp at rsu dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58628

--- Comment #1 from Alexander Pyhalov alp at rsu dot ru ---
Created attachment 30958
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30958action=edit
ctype test


[Bug libstdc++/58625] std::signbit always converts to double

2013-10-05 Thread olegendo at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58625

--- Comment #6 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #5)
 Some builtins are type generic, meaning that you can use just the non-{l,f}
 suffixed variant always, but __builtin_signbit isn't among them.

Yep.  So libstdc++-v3/include/c_std/cmath (signbit) would require a fix, too in
this case, right?  Or maybe rather make the signbit builtin type generic?


[Bug target/56993] power gcc built 416.gamess generates wrong result

2013-10-05 Thread mikpelinux at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56993

--- Comment #2 from Mikael Pettersson mikpelinux at gmail dot com ---
Can you provide a reduced test case?


[Bug target/58621] With -fsection-anchors, a superfluous 'add' is performed

2013-10-05 Thread rearnsha at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58621

Richard Earnshaw rearnsha at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
Your suggested optimization would be invalid if .LANCHOR0 had the address
0x?FFC, whereupon adding 4 would wrap the offset component but not
the base component in x0.


[Bug c++/56746] [4.8 regression] increased memory usage when compiling C++

2013-10-05 Thread ofv at wanadoo dot es
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56746

ofv at wanadoo dot es changed:

   What|Removed |Added

 CC||ofv at wanadoo dot es

--- Comment #13 from ofv at wanadoo dot es ---
My case is similar to the one described by Mathias Gaunard, but with a
difference of 3x memory usage when -ftrack-macro-expansion=0 is not added to
the command line.

I use Boost Preprocessor plus a number of macros to define and instantiate lots
of templates. That's the case that requires 3x more memory (low estimate) with
some TUs requiring way more than 1GB to compile (on a 32 bit machine, which
means that parallel builds usually ends with massive swapping and the compile
jobs killed due to memory starvation.)

I have a version of the same code base that uses variadic templates instead of
Boost Preprocessor, although the macros for instantiating the templates are
still there. That requires about 1.5x more memory.


[Bug fortran/58618] ICE with character substring and ASSOCIATE

2013-10-05 Thread burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58618

Tobias Burnus burnus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-10-05
 CC||burnus at gcc dot gnu.org
Summary|ICE with character array|ICE with character
   |and ASSOCIATE   |substring and ASSOCIATE
 Ever confirmed|0   |1
  Known to fail||4.8.1, 4.9.0

--- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org ---
The ICE occurs in resolve_fl_variable
10795 e = sym-ts.u.cl-length;

Here, sym is x and ts.u.cl == NULL. Without the substring, ts.u.cl matches
s's ts.u.cl (same pointer address).

The variable is set in parse.c's parse_associate:
3404  sym-ts = a-target-ts;

If the RHS is not a substring, it works. If it is, a-target-ts.u.cl is NULL
and the length is only in the REF_SUBSTRING expression at
a-target-ref-next-u.ss.length-length


[Bug libstdc++/58625] std::signbit always converts to double

2013-10-05 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58625

--- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org ---
I don't think it is a good idea to extend the number of type generic builtins
unless strictly necessary, the overloading in C is quite ugly hack.


[Bug libstdc++/58625] std::signbit always converts to double

2013-10-05 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58625

--- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org ---
That said, I'd say that every conversion to double that would change the sign
looks wrong to me, no matter of what the rounding mode is, except perhaps for
NaN canonicalization and that sNaN could be signalled.  So IMHO this is mostly
an optimization thing, not correctness.


[Bug c/58626] possible array wrong code bug

2013-10-05 Thread mikpelinux at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58626

--- Comment #1 from Mikael Pettersson mikpelinux at gmail dot com ---
Started with r202775, still occurs with today's trunk.


[Bug c++/58629] New: Do not implicit move instance for throw operator

2013-10-05 Thread dmitriy-hshg at mail dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58629

Bug ID: 58629
   Summary: Do not implicit move instance for throw operator
   Product: gcc
   Version: 4.7.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmitriy-hshg at mail dot ru

Created attachment 30959
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30959action=edit
Example

It is good idea to use move semantics for throw operator: 

std::runtime_error error(message);
...
throw error; // execution of this block ends = we can implicit move
'error'.

but it may be used only for instances (variables) defined in try {} block. For
other instances a copy semantics must be applied:

std::runtime_error error(message);
...
try {
...
throw error; // we can return to outside block and get access to
'error' again = we must copy 'error' 
} catch (std::runtime_error e) {
std::cout  error.what(); // It must be OK!
}

I have attached an example of code. In GCC instance is always implicity moved.



Expected result:

'error' must be valid in catch(){} block

Actual result:

'error' is invalid in catch(){} block because it is moved in throw error;


[Bug libstdc++/58625] std::signbit always converts to double

2013-10-05 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58625

--- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com ---
Ok, thanks a lot for the comments. Thus, Oleg, given in particular the last
comment from Jakub, let's just apply to mainline your initial proposed change,
let's leave for now include/c_std alone. Just test the change, send it to the
mailing lists as preapproved. Please also add a short comment before the code,
explaining that a type generic signbit builtin isn't available. Thanks!


[Bug c++/58629] Do not implicit move instance for throw operator

2013-10-05 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58629

--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com ---
Did you search bugzilla before filing the bug? I'm asking because I'm pretty
sure we already have something closely related.


[Bug libstdc++/58625] std::signbit always converts to double

2013-10-05 Thread daniel.kruegler at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58625

--- Comment #10 from Daniel Krügler daniel.kruegler at googlemail dot com ---
(In reply to Oleg Endo from comment #4)
 There's another place in file libstdc++-v3/include/c_std/cmath:
 
   templatetypename _Tp
 inline typename __gnu_cxx::__enable_if__is_arithmetic_Tp::__value,
  int::__type
 signbit(_Tp __f)
 {
   typedef typename __gnu_cxx::__promote_Tp::__type __type;
   return __builtin_signbit(__type(__f));
 }

I think this template should no longer exist after resolution of

http://cplusplus.github.io/LWG/lwg-defects.html#1327

(The P/R doesn't become very clear in the quoted reference. In essence it
replaced the previous template by the three overloads mentioned above, see
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3289.pdf
)

[Bug c++/58629] Do not implicit move instance for throw operator

2013-10-05 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58629

--- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com ---
Please compare c++/57533


[Bug c++/57533] When throwing local variable, it's being move-constructed even if not going out of scope.

2013-10-05 Thread dmitriy-hshg at mail dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57533

Dmitry dmitriy-hshg at mail dot ru changed:

   What|Removed |Added

 CC||dmitriy-hshg at mail dot ru

--- Comment #2 from Dmitry dmitriy-hshg at mail dot ru ---
*** Bug 58629 has been marked as a duplicate of this bug. ***


[Bug c++/58629] Do not implicit move instance for throw operator

2013-10-05 Thread dmitriy-hshg at mail dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58629

Dmitry dmitriy-hshg at mail dot ru changed:

   What|Removed |Added

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

--- Comment #3 from Dmitry dmitriy-hshg at mail dot ru ---
Thank you!

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


[Bug libstdc++/58625] std::signbit always converts to double

2013-10-05 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58625

--- Comment #11 from Paolo Carlini paolo.carlini at oracle dot com ---
At some point, as we discussed already a bit, we should even try to remove
completely the c_std version. For now as I said, let's just leave it alone.


[Bug bootstrap/39968] Should plugins use shared library?

2013-10-05 Thread dominiq at lps dot ens.fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39968

Dominique d'Humieres dominiq at lps dot ens.fr changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from Dominique d'Humieres dominiq at lps dot ens.fr ---
 Any point to keep this four year old PR open?

No answer since two months, closing as fixed.
Please open a new PR for plugin problems.


[Bug rtl-optimization/38711] ira should not be using df-lr except at -O1.

2013-10-05 Thread dominiq at lps dot ens.fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38711

Bug 38711 depends on bug 54961, which changed state.

Bug 54961 Summary: FAIL: gfortran.dg/pr48757.f  -O  (internal compiler error) 
after revision 192440
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54961

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED


[Bug middle-end/54961] FAIL: gfortran.dg/pr48757.f -O (internal compiler error) after revision 192440

2013-10-05 Thread dominiq at lps dot ens.fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54961

Dominique d'Humieres dominiq at lps dot ens.fr changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Dominique d'Humieres dominiq at lps dot ens.fr ---
 This PR disappeared from my tests between revisions 192878 and 193318. 
 Was it fixed or hidden?

No answer since two months, closing as fixed.


[Bug ipa/58398] [4.9 Regression] gcc.dg/attr-ifunc-4.c runfail regression after r202111

2013-10-05 Thread bernd.edlinger at hotmail dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58398

--- Comment #8 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
How can I set this PR to FIXED?


[Bug c++/53756] [C++1y] ICE: in gen_type_die_with_usage, at dwarf2out.c:18774 with -g and operator auto ()

2013-10-05 Thread tim at klingt dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53756

tim blechmann tim at klingt dot org changed:

   What|Removed |Added

 CC||tim at klingt dot org

--- Comment #5 from tim blechmann tim at klingt dot org ---
i think i experienced the same issue, but with a different line number:

internal compiler error: in gen_type_die_with_usage, at dwarf2out.c:19486

g++-4.8 -std=c++1y -g -x c++

code:
struct
{
auto a1 ();
}

g++-4.8 -v
Using built-in specs.
COLLECT_GCC=/usr/bin/g++-4.8.real
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.8.1-2ubuntu1~13.04' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.1 (Ubuntu 4.8.1-2ubuntu1~13.04)


[Bug c/52991] attribute packed broken on mingw32?

2013-10-05 Thread mikpelinux at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991

--- Comment #14 from Mikael Pettersson mikpelinux at gmail dot com ---
Ping -- there's been a patch for this bug for almost 10 months now...


[Bug target/58630] New: [4.9 Regression] Revision 203171 breaks several MS-ABI tests

2013-10-05 Thread dominiq at lps dot ens.fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58630

Bug ID: 58630
   Summary: [4.9 Regression] Revision 203171 breaks several MS-ABI
tests
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: hjl.tools at gmail dot com, iains at gcc dot gnu.org, jh at 
suse dot cz,
ktietz at gcc dot gnu.org
Target: i?86-*-* x86_64-*-*

Revision 203171 breaks several MS-ABI tests:

FAIL: gcc.target/i386/pr43662.c (internal compiler error)
FAIL: gcc.target/i386/pr43662.c (test for excess errors)
FAIL: gcc.target/i386/pr43869.c (internal compiler error)
FAIL: gcc.target/i386/pr43869.c (test for excess errors)
FAIL: gcc.target/i386/pr57003.c (internal compiler error)
FAIL: gcc.target/i386/pr57003.c (test for excess errors)
FAIL: gcc.target/i386/pr9771-1.c (test for excess errors)
FAIL: gcc.target/x86_64/abi/callabi/func-1.c (test for excess errors)
FAIL: gcc.target/x86_64/abi/callabi/func-2a.c (test for excess errors)
FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2a.c (internal compiler
error)
FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2a.c (test for excess errors)
FAIL: gcc.target/x86_64/abi/callabi/func-indirect.c (test for excess errors)
FAIL: gcc.target/x86_64/abi/callabi/vaarg-1.c (test for excess errors)
FAIL: gcc.target/x86_64/abi/callabi/vaarg-2.c (test for excess errors)
FAIL: gcc.target/x86_64/abi/callabi/vaarg-3.c (test for excess errors)
FAIL: gcc.target/x86_64/abi/callabi/vaarg-4a.c (test for excess errors)
FAIL: gcc.target/x86_64/abi/callabi/vaarg-5a.c (test for excess errors)

(see http://gcc.gnu.org/ml/gcc-regression/2013-10/msg00026.html or
http://gcc.gnu.org/ml/gcc-testresults/2013-10/msg00388.html ).

The failure for gcc.target/i386/pr9771-1.c is

[macbook] f90/bug% gfc -O2 -fomit-frame-pointer -ffixed-ebp
/opt/gcc/work/gcc/testsuite/gcc.target/i386/pr9771-1.c -m32
/opt/gcc/work/gcc/testsuite/gcc.target/i386/pr9771-1.c: In function 'test':
/opt/gcc/work/gcc/testsuite/gcc.target/i386/pr9771-1.c:46:1: error: bp cannot
be used in asm here
 }

and the others are of the kind

sorry, unimplemented: ms_abi attribute requires -maccumulate-outgoing-args or
subtarget optimization implying it

Notes:

(1) Compiling the failing gcc.target/i386/pr4* and
gcc.target/x86_64/abi/callabi/func-indirect-2a.c gives an ICE:

/opt/gcc/work/gcc/testsuite/gcc.target/i386/pr43662.c:20:9: internal compiler
error: in expand_call, at calls.c:3153

or

internal compiler error: in expand_call, at calls.c:3453

for the others.

(2) Some tests are restricted to Linux but can be run on Darwin without
failure.

(3) The following patch fixes the failures related to
-maccumulate-outgoing-args

diff -up ../_clean/gcc/testsuite/gcc.target/i386/pr43662.c
gcc/testsuite/gcc.target/i386/pr43662.c
--- ../_clean/gcc/testsuite/gcc.target/i386/pr43662.c2011-08-01
14:36:41.0 +0200
+++ gcc/testsuite/gcc.target/i386/pr43662.c2013-10-05 16:51:56.0
+0200
@@ -1,5 +1,5 @@
 /* { dg-do compile { target lp64 } } */
-/* { dg-options -O2 } */
+/* { dg-options -O2 -maccumulate-outgoing-args } */

 void __attribute__ ((ms_abi)) foo (void)
 {
diff -up ../_clean/gcc/testsuite/gcc.target/i386/pr43869.c
gcc/testsuite/gcc.target/i386/pr43869.c
--- ../_clean/gcc/testsuite/gcc.target/i386/pr43869.c2011-08-01
14:36:41.0 +0200
+++ gcc/testsuite/gcc.target/i386/pr43869.c2013-10-05 16:53:09.0
+0200
@@ -1,4 +1,5 @@
 /* { dg-do compile { target lp64 } } */
+/* { dg-options -maccumulate-outgoing-args } */

 int __attribute__((__noinline__))
 bugged(float f1, float f2, float f3, float f4,
diff -up ../_clean/gcc/testsuite/gcc.target/i386/pr57003.c
gcc/testsuite/gcc.target/i386/pr57003.c
--- ../_clean/gcc/testsuite/gcc.target/i386/pr57003.c2013-04-26
11:07:25.0 +0200
+++ gcc/testsuite/gcc.target/i386/pr57003.c2013-10-05 16:53:52.0
+0200
@@ -1,6 +1,6 @@
 /* PR rtl-optimization/57003 */
 /* { dg-do run } */
-/* { dg-options -O2 } */
+/* { dg-options -O2 -maccumulate-outgoing-args } */

 #define N 2001
 unsigned short *b, *c, *d;

diff -up ../_clean/gcc/testsuite/gcc.target/x86_64/abi/callabi/func-1.c
gcc/testsuite/gcc.target/x86_64/abi/callabi/func-1.c
--- ../_clean/gcc/testsuite/gcc.target/x86_64/abi/callabi/func-1.c   
2009-11-25 18:14:50.0 +0100
+++ gcc/testsuite/gcc.target/x86_64/abi/callabi/func-1.c2013-10-05
16:45:39.0 +0200
@@ -2,7 +2,7 @@
 */
 /* Origin: Kai Tietz kai.ti...@onevision.com */
 /* { dg-do run } */
-/* { dg-options -std=gnu99 -ffast-math } */
+/* { dg-options -std=gnu99 -ffast-math -maccumulate-outgoing-args } */
 #include callabi.h

 extern void abort (void);
diff -up ../_clean/gcc/testsuite/gcc.target/x86_64/abi/callabi/func-2a.c

[Bug c++/58631] New: Internal compiler error: Error reporting routines re-entered.

2013-10-05 Thread bsamim at yahoo dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58631

Bug ID: 58631
   Summary: Internal compiler error: Error reporting routines
re-entered.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bsamim at yahoo dot com

Created attachment 30960
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30960action=edit
Preprocessed source stored into /tmp/cc1xZWpN.out file, please attach this to
your bugreport.

g++ -I/usr/include -I/usr/local/include -std=c++11 -pthread -ggdb -g3 -Wall -c
Deck.cpp -o Deck.o
‘
Internal compiler error: Error reporting routines re-entered.
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.7/README.Bugs for instructions.
Preprocessed source stored into /tmp/cc1xZWpN.out file, please attach this to
your bugreport.
make: *** [Deck.o] Error 1

[Bug c++/58631] Internal compiler error: Error reporting routines re-entered.

2013-10-05 Thread bsamim at yahoo dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58631

--- Comment #1 from bsamim at yahoo dot com ---
It seems this happens in the following code when the copy constructor for is
set as Card(Card ) = delete;It will crash the compiler on this as I
believe it is because the vector is expecting it to be copyable even though it
is doing a move. After changing the code a bit and putting it as private I was
able to get the following output but it still crashed the compiler at the end.

Card.h:28:5: error: ‘Card::Card(const Card)’ is private
In file included from /usr/include/c++/4.7/bits/move.h:57:0,
 from /usr/include/c++/4.7/bits/stl_pair.h:61,
 from /usr/include/c++/4.7/bits/stl_algobase.h:65,
 from /usr/include/c++/4.7/vector:61,
 from Card.h:4,
 from Deck.h:4,
 from Deck.cpp:1:
/usr/include/c++/4.7/type_traits:762:43: error: within this context
In file included from Deck.h:4:0,
 from Deck.cpp:1:
/usr/include/c++/4.7/type_traits: In instantiation of ‘struct
std::__is_nt_constructible_implCard, Card’:
/usr/include/c++/4.7/type_traits:116:12:   required from ‘struct
std::__and_std::is_constructibleCard, Card,
std::__is_nt_constructible_implCard, Card ’
/usr/include/c++/4.7/type_traits:1002:12:   required from ‘struct
std::is_nothrow_constructibleCard, Card’
/usr/include/c++/4.7/type_traits:1033:12:   required from ‘struct
std::__is_nothrow_move_constructible_implCard, false’
/usr/include/c++/4.7/type_traits:1039:12:   required from ‘struct
std::is_nothrow_move_constructibleCard’
/usr/include/c++/4.7/type_traits:126:12:   required from ‘struct
std::__not_std::is_nothrow_move_constructibleCard ’
/usr/include/c++/4.7/type_traits:116:12:   required from ‘struct
std::__and_std::__not_std::is_nothrow_move_constructibleCard ,
std::is_copy_constructibleCard ’
/usr/include/c++/4.7/bits/move.h:107:12:   required from ‘struct
std::__move_if_noexcept_condCard’
/usr/include/c++/4.7/bits/stl_iterator.h:1129:32:   required from
‘_ForwardIterator std::__uninitialized_move_if_noexcept_a(_InputIterator,
_InputIterator, _ForwardIterator, _Allocator) [with _InputIterator = Card*;
_ForwardIterator = Card*; _Allocator = std::allocatorCard]’
/usr/include/c++/4.7/bits/vector.tcc:413:6:   required from ‘void
std::vector_Tp, _Alloc::_M_emplace_back_aux(_Args ...) [with _Args =
{Card}; _Tp = Card; _Alloc = std::allocatorCard]’
/usr/include/c++/4.7/bits/vector.tcc:102:4:   required from ‘void
std::vector_Tp, _Alloc::emplace_back(_Args ...) [with _Args = {Card}; _Tp =
Card; _Alloc = std::allocatorCard]’

[Bug c++/58631] Internal compiler error: Error reporting routines re-entered.

2013-10-05 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58631

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

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

--- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com ---
Dup

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


[Bug c++/57086] Internal compiler error: Error reporting routines re-entered.

2013-10-05 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57086

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 CC||bsamim at yahoo dot com

--- Comment #11 from Paolo Carlini paolo.carlini at oracle dot com ---
*** Bug 58631 has been marked as a duplicate of this bug. ***


[Bug c++/58632] New: [4.8/4.9 Regression] ICE reusing template parameter name as class name

2013-10-05 Thread reichelt at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58632

Bug ID: 58632
   Summary: [4.8/4.9 Regression] ICE reusing template parameter
name as class name
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org

The following invalid line of code triggers an ICE since GCC 4.8.0:

=
templatetemplateint class A class A {};
=

bug.cc:1:39: internal compiler error: tree check: expected record_type or
union_type or qual_union_type, have template_template_parm in xref_basetypes,
at cp/decl.c:12220
 templatetemplateint class A class A {};
   ^
0xcd860a tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9176
0x560941 tree_check3
../../gcc/gcc/tree.h:2649
0x560941 xref_basetypes(tree_node*, tree_node*)
../../gcc/gcc/cp/decl.c:12220
0x63776f cp_parser_class_head
../../gcc/gcc/cp/parser.c:19541
0x63776f cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:18842
0x638230 cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:19111
0x638230 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:14090
0x64d739 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:11337
0x651dc3 cp_parser_single_declaration
../../gcc/gcc/cp/parser.c:22591
0x654be8 cp_parser_template_declaration_after_export
../../gcc/gcc/cp/parser.c:22467
0x65c9d9 cp_parser_declaration
../../gcc/gcc/cp/parser.c:10737
0x65b5aa cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10659
0x65ce76 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:3939
0x65ce76 c_parse_file()
../../gcc/gcc/cp/parser.c:28911
0x7708b3 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1046
Please submit a full bug report, [etc.]


[Bug c++/58633] New: [4.7/4.8/4.9 Regression] ICE with decltype of destructor call

2013-10-05 Thread reichelt at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58633

Bug ID: 58633
   Summary: [4.7/4.8/4.9 Regression] ICE with decltype of
destructor call
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org

The following valid code snippet (compiled with -std=c++0x) triggers an ICE
since GCC 4.7.0:


void foo(int i)
{
  typedef int I;
  __decltype(i.I::~I())* p;
}


bug.cc: In function 'void foo(int)':
bug.cc:4:22: internal compiler error: in cp_parser_abort_tentative_parse, at
cp/parser.c:24356
   __decltype(i.I::~I())* p;
  ^
0x62fa03 cp_parser_abort_tentative_parse
../../gcc/gcc/cp/parser.c:24355
0x64270c cp_parser_decltype_expr
../../gcc/gcc/cp/parser.c:11708
0x64270c cp_parser_decltype
../../gcc/gcc/cp/parser.c:11791
0x65a192 cp_parser_simple_type_specifier
../../gcc/gcc/cp/parser.c:14298
0x637ea5 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:14168
0x64d739 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:11337
0x6517e9 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:10927
0x653810 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:10876
0x654930 cp_parser_declaration_statement
../../gcc/gcc/cp/parser.c:10523
0x63d147 cp_parser_statement
../../gcc/gcc/cp/parser.c:9274
0x63e452 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:9552
0x63e596 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:9506
0x64f95b cp_parser_function_body
../../gcc/gcc/cp/parser.c:18328
0x64f95b cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:18364
0x6509af cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:22351
0x6516d5 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:22272
0x6516d5 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16357
0x65198f cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:10995
0x653810 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:10876
0x65c83e cp_parser_declaration
../../gcc/gcc/cp/parser.c:10773
Please submit a full bug report, [etc.]


[Bug rtl-optimization/58517] icvt (after combine) puts ccreg clobbering insn between ccset insn and cc use

2013-10-05 Thread olegendo at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58517

Oleg Endo olegendo at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-10-05
  Component|target  |rtl-optimization
Summary|[SH] wrong code with subc   |icvt (after combine) puts
   |and movsicc |ccreg clobbering insn
   |(-mpretend-cmove) after ce2 |between ccset insn and cc
   ||use
 Ever confirmed|0   |1

--- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org ---
This seems to be a bug in ifcvt.c

Reduced test cases:

int
test_subc (int q, int read, int end)
{
  return q  read ? (read - q - 1) : (end - q);
}

int
test_addc (int q, int read, int end)
{
  return q  read ? (read + q + 1) : (end + q);
}

compiled with -O2 -m4 -mpretend-cmove:

_test_subc:
sett
mov r5,r0
sub r4,r6
subcr4,r0   ! 36*subc
bf  0f  ! 34*movsicc_t_true/1
mov r6,r0
0:
rts
nop

_test_addc:
sett
mov r4,r0
add r4,r6
addcr5,r0   ! 34*addc
bf  0f  ! 32*movsicc_t_true/1
mov r6,r0
0:
rts
nop

In both above cases the comparison 'q  read' is eliminated, because ifcvt
moves the T_REG clobbering subc/addc insn between the 'q  read' comparison
(sets T_REG) and the conditional branch (uses T_REG).


[Bug c++/58634] New: [c++11] ICE initializing static class member via an anonymous class

2013-10-05 Thread reichelt at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58634

Bug ID: 58634
   Summary: [c++11] ICE initializing static class member via an
anonymous class
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org

The following valid code snippet (compiled with -std=c++0x) triggers an ICE
on trunk (since at least 4.9.0 20130920):

===
struct A
{
  static const int i;
};

const int A::i = (struct { int j=0; }){}.j;
===

bug.cc:6:26: internal compiler error: in nested_anon_class_index, at
cp/mangle.c:1403
 const int A::i = (struct { int j=0; }){}.j;
  ^
0x6eca7e nested_anon_class_index
../../gcc/gcc/cp/mangle.c:1403
0x6eca7e write_unnamed_type_name
../../gcc/gcc/cp/mangle.c:1417
0x6eca7e write_unqualified_name
../../gcc/gcc/cp/mangle.c:1277
0x6f5937 write_prefix
../../gcc/gcc/cp/mangle.c:1059
0x6ed0c6 write_nested_name
../../gcc/gcc/cp/mangle.c:963
0x6ed6fc write_name
../../gcc/gcc/cp/mangle.c:864
0x6edd7f write_encoding
../../gcc/gcc/cp/mangle.c:719
0x6ee10d write_mangled_name
../../gcc/gcc/cp/mangle.c:689
0x6f6ac5 mangle_decl_string
../../gcc/gcc/cp/mangle.c:3446
0x6f6cf8 get_mangled_id
../../gcc/gcc/cp/mangle.c:3468
0x6f6cf8 mangle_decl(tree_node*)
../../gcc/gcc/cp/mangle.c:3491
0xcda6d0 decl_assembler_name(tree_node*)
../../gcc/gcc/tree.c:546
0x60ff4f comdat_linkage(tree_node*)
../../gcc/gcc/cp/decl2.c:1636
0x6b7a25 expand_or_defer_fn_1(tree_node*)
../../gcc/gcc/cp/semantics.c:3911
0x6b7f68 expand_or_defer_fn(tree_node*)
../../gcc/gcc/cp/semantics.c:3944
0x6e65c7 maybe_clone_body(tree_node*)
../../gcc/gcc/cp/optimize.c:428
0x6b798f expand_or_defer_fn_1(tree_node*)
../../gcc/gcc/cp/semantics.c:3874
0x6b7f68 expand_or_defer_fn(tree_node*)
../../gcc/gcc/cp/semantics.c:3944
0x69e8a1 synthesize_method(tree_node*)
../../gcc/gcc/cp/method.c:809
0x615789 mark_used(tree_node*, int)
../../gcc/gcc/cp/decl2.c:4719
Please submit a full bug report, [etc.]


[Bug c++/58624] gcc internal compiler error: Segmentaion fault

2013-10-05 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58624

--- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com ---
Doesn't look like a C++ front-end issue.


[Bug rtl-optimization/58517] icvt (after combine) puts ccreg clobbering insn between ccset insn and ccreg use

2013-10-05 Thread olegendo at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58517

--- Comment #2 from Oleg Endo olegendo at gcc dot gnu.org ---
The problem also happens on 4.8.


[Bug c++/58635] New: [c++11] ICE with __transaction_atomic and noexcept(false)

2013-10-05 Thread reichelt at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58635

Bug ID: 58635
   Summary: [c++11] ICE with __transaction_atomic and
noexcept(false)
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org

The following three code snippets (compiled with -std=c++0x -fgnu-tm)
trigger slightly different ICEs in build_transaction_expr since GCC 4.7.0.
The first two snippets are valid, the last one is invalid:

===
int foo()
{
  return __transaction_atomic noexcept(false) (false);
}
===

bug.cc: In function 'int foo()':
bug.cc:3:53: internal compiler error: tree check: expected class 'expression',
have 'constant' (integer_cst) in build_transaction_expr, at cp/semantics.c:5224
   return __transaction_atomic noexcept(false) (false);
 ^
0xcd8c59 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/gcc/tree.c:9227
0x6bcf7a expr_check
../../gcc/gcc/tree.h:2778
0x6bcf7a build_transaction_expr(unsigned int, tree_node*, int, tree_node*)
../../gcc/gcc/cp/semantics.c:5224
0x6443e9 cp_parser_transaction_expression
../../gcc/gcc/cp/parser.c:28568
0x6443e9 cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:6845
0x644cff cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:7701
0x6451bf cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:7937
0x647023 cp_parser_expression
../../gcc/gcc/cp/parser.c:8099
0x63dbf2 cp_parser_expression
../../gcc/gcc/cp/parser.c:8138
0x63dbf2 cp_parser_jump_statement
../../gcc/gcc/cp/parser.c:10472
0x63dbf2 cp_parser_statement
../../gcc/gcc/cp/parser.c:9182
0x63e452 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:9552
0x63e596 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:9506
0x64f95b cp_parser_function_body
../../gcc/gcc/cp/parser.c:18328
0x64f95b cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:18364
0x6509af cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:22351
0x6516d5 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:22272
0x6516d5 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16357
0x65198f cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:10995
0x653810 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:10876
Please submit a full bug report, [etc.]


===
int foo(int i)
{
  return __transaction_atomic noexcept(false) (i);
}
===

bug.cc: In function 'int foo(int)':
bug.cc:3:49: internal compiler error: tree check: expected class 'expression',
have 'declaration' (parm_decl) in build_transaction_expr, at
cp/semantics.c:5224
   return __transaction_atomic noexcept(false) (i);
 ^
0xcd8c59 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/gcc/tree.c:9227
[etc.]


===
int foo()
{
  return __transaction_atomic noexcept(false) (x);
}
===

bug.cc: In function 'int foo()':
bug.cc:3:48: error: 'x' was not declared in this scope
   return __transaction_atomic noexcept(false) (x);
^
bug.cc:3:49: internal compiler error: tree check: expected class 'expression',
have 'exceptional' (error_mark) in build_transaction_expr, at
cp/semantics.c:5224
   return __transaction_atomic noexcept(false) (x);
 ^
0xcd8c59 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/gcc/tree.c:9227
[etc.]


[Bug c++/57945] [4.9 Regression] ICE: in varpool_get_node, at cgraph.h:840

2013-10-05 Thread reichelt at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57945

Volker Reichelt reichelt at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Last reconfirmed|2013-07-27 00:00:00 |2013-10-05
 CC||reichelt at gcc dot gnu.org
  Known to work||4.7.0, 4.8.0
  Known to fail||4.9.0

--- Comment #1 from Volker Reichelt reichelt at gcc dot gnu.org ---
Here's an even simpler testcase which is probably valid (at least it was
accepted in 4.8.x):

=
static int i __attribute__((weakref(j)));
=

cc1plus: internal compiler error: in varpool_get_node, at cgraph.h:891
0x512ddc varpool_get_node
../../gcc/gcc/cgraph.h:891
0xd2d101 varpool_get_node
../../gcc/gcc/varpool.c:389
0xd2d101 varpool_analyze_node(varpool_node*)
../../gcc/gcc/varpool.c:396
0x804217 analyze_functions
../../gcc/gcc/cgraphunit.c:1035
0x805739 finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2260
0x618920 cp_write_global_declarations()
../../gcc/gcc/cp/decl2.c:4365
Please submit a full bug report, [etc.]


[Bug c++/58466] [4.8/4.9 Regression] ICE in cxx_eval_constant_expression

2013-10-05 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58466

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-10-05
 Ever confirmed|0   |1


[Bug c++/58636] New: [4.7/4.8/4.9 Regression] ICE with initializer_list and rvalue references

2013-10-05 Thread reichelt at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58636

Bug ID: 58636
   Summary: [4.7/4.8/4.9 Regression] ICE with initializer_list and
rvalue references
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org

The following similar invalid code snippets (compiled with -std=c++11)
trigger ICEs in different parts of the compiler:


#include initializer_list

int foo(std::initializer_listint);

int i = foo({ 0 });


bug.cc:5:18: error: 'const' qualifiers cannot be applied to 'int'
 int i = foo({ 0 });
  ^
In file included from bug.cc:1:0:
.../include/c++/4.9.0/initializer_list: In instantiation of 'class
std::initializer_listint':
bug.cc:5:18:   required from here
.../include/c++/4.9.0/initializer_list:54:26: error: forming pointer to
reference type 'int'
   typedef const _E*  iterator;
  ^
.../include/c++/4.9.0/initializer_list:55:26: error: forming pointer to
reference type 'int'
   typedef const _E*  const_iterator;
  ^
bug.cc: In function 'void __static_initialization_and_destruction_0(int, int)':
bug.cc:5:18: internal compiler error: in gimplify_init_ctor_eval, at
gimplify.c:3734
 int i = foo({ 0 });
  ^
0x96977d gimplify_init_ctor_eval
../../gcc/gcc/gimplify.c:3734
0x96fbd4 gimplify_init_constructor
../../gcc/gcc/gimplify.c:4133
0x970a7e gimplify_modify_expr_rhs
../../gcc/gcc/gimplify.c:4518
0x970de4 gimplify_modify_expr
../../gcc/gcc/gimplify.c:4834
0x9661d5 gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:7332
0x9691a6 gimplify_stmt(tree_node**, gimple_statement_d**)
../../gcc/gcc/gimplify.c:5709
0x964130 gimplify_and_add
../../gcc/gcc/gimplify.c:329
0x964130 internal_get_tmp_var
../../gcc/gcc/gimplify.c:594
0x964bae gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:8163
0x96dec9 gimplify_call_expr
../../gcc/gcc/gimplify.c:2635
0x96567a gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:7303
0x970f58 gimplify_modify_expr
../../gcc/gcc/gimplify.c:4875
0x9661d5 gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:7332
0x9691a6 gimplify_stmt(tree_node**, gimple_statement_d**)
../../gcc/gcc/gimplify.c:5709
0x9656fe gimplify_cleanup_point_expr
../../gcc/gcc/gimplify.c:5485
0x9656fe gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:7669
0x9691a6 gimplify_stmt(tree_node**, gimple_statement_d**)
../../gcc/gcc/gimplify.c:5709
0x964f9b gimplify_statement_list
../../gcc/gcc/gimplify.c:1525
0x964f9b gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:7721
0x9691a6 gimplify_stmt(tree_node**, gimple_statement_d**)
../../gcc/gcc/gimplify.c:5709
Please submit a full bug report, [etc.]


===
#include initializer_list

auto i = std::initializer_listint{ 0 };
===

In file included from bug.cc:1:0:
.../include/c++/4.9.0/initializer_list: In instantiation of 'class
std::initializer_listint':
bug.cc:3:42:   required from here
.../include/c++/4.9.0/initializer_list:54:26: error: forming pointer to
reference type 'int'
   typedef const _E*  iterator;
  ^
.../include/c++/4.9.0/initializer_list:55:26: error: forming pointer to
reference type 'int'
   typedef const _E*  const_iterator;
  ^
bug.cc:3:42: error: 'const' qualifiers cannot be applied to 'int'
 auto i = std::initializer_listint{ 0 };
  ^
bug.cc:3:42: internal compiler error: in split_nonconstant_init_1, at
cp/typeck2.c:597
0x5dd883 split_nonconstant_init_1
../../gcc/gcc/cp/typeck2.c:597
0x5e0f12 split_nonconstant_init
../../gcc/gcc/cp/typeck2.c:692
0x5e0f12 store_init_value(tree_node*, tree_node*, vectree_node*, va_gc,
vl_embed**, int)
../../gcc/gcc/cp/typeck2.c:810
0x557478 check_initializer
../../gcc/gcc/cp/decl.c:5728
0x56a35c cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/gcc/cp/decl.c:6347
0x651267 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16577
0x65198f cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:10995
0x653810 

[Bug c++/58527] Failures when a function parameter pack is not final

2013-10-05 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58527

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

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

--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com ---
Closing.


[Bug rtl-optimization/58517] icvt (after combine) puts ccreg clobbering insn between ccset insn and ccreg use

2013-10-05 Thread olegendo at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58517

Oleg Endo olegendo at gcc dot gnu.org changed:

   What|Removed |Added

 CC||steven at gcc dot gnu.org

--- Comment #3 from Oleg Endo olegendo at gcc dot gnu.org ---
The problematic transformation happens in ifcvt.c (noce_try_cmove_arith).
I've only briefly looked over that code and can think of the following options
how to fix the issue:

1) Check whether insn_a and insn_b modify the src reg (ccreg) of the
conditional branch.  If they do, don't do the transformation.
On SH, the resulting code would be the same as not specifying -mpretend-cmove:

cmp/ge  r5,r4
mov r6,r0
bf/s.L6
sub r4,r0
rts
nop
.L6:
sett
mov r5,r0
rts
subcr4,r0

2) Check whether insn_a and insn_b modify the src reg (ccreg) of the
conditional branch.  If they do, try to move the insn that sets the ccreg
before the conditional branch, _after_ the emitted insn_a and insn_b and right
before the conditional move.
On SH, the resulting code would look something like this:

sett
mov r5,r0
sub r4,r6
subcr4,r0
cmp/ge  r5,r4
bf  0f
mov r6,r0
0:
rts
nop

Steven, since you're RTL optimizers reviewer, could you please provide some
feedback regarding the matter?


[Bug c++/58466] [4.8/4.9 Regression] ICE in cxx_eval_constant_expression

2013-10-05 Thread reichelt at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58466

Volker Reichelt reichelt at gcc dot gnu.org changed:

   What|Removed |Added

 CC||reichelt at gcc dot gnu.org
  Known to work||4.7.0, 4.8.0
  Known to fail||4.8.1, 4.8.2, 4.9.0

--- Comment #1 from Volker Reichelt reichelt at gcc dot gnu.org ---
Here's an even simpler testcase:

=
templatechar, char... struct A;

templatetypename struct B;

templatechar... C struct BAC... {};

BA'X' b;
=


[Bug c++/58466] [4.8/4.9 Regression] ICE in cxx_eval_constant_expression

2013-10-05 Thread reichelt at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58466

--- Comment #2 from Volker Reichelt reichelt at gcc dot gnu.org ---
Crash stack trace:

PR58466.cc:7:11: internal compiler error: unexpected expression 'C' of kind
template_parm_index
 BA'X' b;
   ^
0x6c40ce cxx_eval_constant_expression
../../gcc/gcc/cp/semantics.c:8197
0x6c7036 cxx_eval_outermost_constant_expr
../../gcc/gcc/cp/semantics.c:8217
0x6c9cab maybe_constant_value(tree_node*)
../../gcc/gcc/cp/semantics.c:8327
0x5b164e convert_nontype_argument
../../gcc/gcc/cp/pt.c:5576
0x5b164e convert_template_argument
../../gcc/gcc/cp/pt.c:6453
0x5aa702 coerce_template_parameter_pack
../../gcc/gcc/cp/pt.c:6577
0x5aa702 coerce_template_parms
../../gcc/gcc/cp/pt.c:6776
0x5b327a lookup_template_class_1
../../gcc/gcc/cp/pt.c:7398
0x5b327a lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/gcc/cp/pt.c:7695
0x5b894e tsubst_aggr_type
../../gcc/gcc/cp/pt.c:9977
0x5ac34b tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:11367
0x5b7f1a tsubst_template_args
../../gcc/gcc/cp/pt.c:9774
0x5ac09f tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:11672
0x5c6ee0 get_class_bindings
../../gcc/gcc/cp/pt.c:18177
0x5c7ad2 most_specialized_class
../../gcc/gcc/cp/pt.c:18401
0x5d85f0 instantiate_class_template_1
../../gcc/gcc/cp/pt.c:8687
0x5d85f0 instantiate_class_template(tree_node*)
../../gcc/gcc/cp/pt.c:9216
0x66445b complete_type(tree_node*)
../../gcc/gcc/cp/typeck.c:132
0x555239 start_decl_1(tree_node*, bool)
../../gcc/gcc/cp/decl.c:4670
0x57f03d start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../gcc/gcc/cp/decl.c:4633
Please submit a full bug report, [etc.]


[Bug c++/58637] New: [c++1y] ICE with wrong usage of template in front of function containing auto parameter

2013-10-05 Thread reichelt at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58637

Bug ID: 58637
   Summary: [c++1y] ICE with wrong usage of template in front of
function containing auto parameter
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org

The following invalid line of code (compiled with -std=c++1y) triggers an ICE
on trunk (since at least 4.9.0-20130920):

=
template void foo(auto);
=

bug.cc:1:21: internal compiler error: in add_implicit_template_parms, at
cp/parser.c:28978
 template void foo(auto);
 ^
0x64f044 add_implicit_template_parms
../../gcc/gcc/cp/parser.c:28978
0x64f044 cp_parser_parameter_declaration_list
../../gcc/gcc/cp/parser.c:18067
0x64f356 cp_parser_parameter_declaration_clause
../../gcc/gcc/cp/parser.c:17882
0x649f04 cp_parser_direct_declarator
../../gcc/gcc/cp/parser.c:16834
0x649f04 cp_parser_declarator
../../gcc/gcc/cp/parser.c:16705
0x650cc7 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16268
0x651fd4 cp_parser_single_declaration
../../gcc/gcc/cp/parser.c:22665
0x6553fd cp_parser_explicit_specialization
../../gcc/gcc/cp/parser.c:13986
0x65cac5 cp_parser_declaration
../../gcc/gcc/cp/parser.c:10726
0x65b5aa cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10659
0x65ce76 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:3939
0x65ce76 c_parse_file()
../../gcc/gcc/cp/parser.c:28911
0x7708b3 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1046
Please submit a full bug report, [etc.]


[Bug rtl-optimization/58517] icvt (after combine) puts ccreg clobbering insn between ccset insn and ccreg use

2013-10-05 Thread steven at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58517

--- Comment #4 from Steven Bosscher steven at gcc dot gnu.org ---
So if I understand correctly, this is what happens (sorry, reading
LIPSy RTL is still just too unnatural to me! ;-))

before ifcvt-after-combine:
r147:=(r424r178)
r190:=r423-r189
if (r147==0) goto L433
{r190:=(~r189)+r424; r147:=X}
L433:

after ifcvt-after-combine:
r147:=(r424r189)
r190:=r423-r189
{r945:=(~r189)+r424; r147:=X}
r946:=r423-r189
r190:=(r147==0) ? r946:r945  // but r147 was clobbered!
r147:=(r190==0)
if (r147==0) goto L501


This is noce_try_cmove_arith:

  /* if (test) x = a + b; else x = c - d;
 = y = a + b;
x = c - d;
if (test)
  x = y;
  */

with (test) being clobbered by the assignment to y or x on the
code after the transformation has been applied.  noce_try_cmove_arith
does not expect that the arithmetic insns emitted to load vtrue or
vfalse into general operands may clobber the condition.  There should
be tests like this:

Index: ifcvt.c
===
--- ifcvt.c (revision 203224)
+++ ifcvt.c (working copy)
@@ -1573,6 +1573,8 @@ noce_try_cmove_arith (struct noce_if_info *if_info
 optimize_bb_for_speed_p (BLOCK_FOR_INSN (insn_a)));
   if (insn_cost == 0 || insn_cost  COSTS_N_INSNS (if_info-branch_cost))
return FALSE;
+  if (modified_in_p (if_info-cond, insn_a))
+   return FALSE;
 }
   else
 insn_cost = 0;
@@ -1584,6 +1586,8 @@ noce_try_cmove_arith (struct noce_if_info *if_info
  optimize_bb_for_speed_p (BLOCK_FOR_INSN (insn_b)));
   if (insn_cost == 0 || insn_cost  COSTS_N_INSNS (if_info-branch_cost))
 return FALSE;
+  if (modified_in_p (if_info-cond, insn_b))
+   return FALSE;
 }

   /* Possibly rearrange operands to make things come out more natural.  */



That's option 1 of comment #3.  Option 2 is only viable if the insn
computing cond is nearby (i.e. immediately above insn_a / insn_b),
otherwise it'll be necessary to solve a code motion dataflow problem.
Within one basic block that still would be doable (modified_between_p),
but I doubt it's worth the trouble.


[Bug c++/56060] ICE on invalid code in type_dependent_expression_p, at cp/pt.c:19742

2013-10-05 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56060

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

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

--- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com ---
Mine.


[Bug fortran/58226] negative subscript pos at fortran/options.c:1205

2013-10-05 Thread bdavis at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58226

Bud Davis bdavis at gcc dot gnu.org changed:

   What|Removed |Added

 CC||bdavis at gcc dot gnu.org

--- Comment #2 from Bud Davis bdavis at gcc dot gnu.org ---
works for me.
GNU Fortran (GCC) 4.9.0 20131005 (experimental)


[Bug libstdc++/58638] New: libstdc++ builds as non-PIC when --with-pic is specified

2013-10-05 Thread skunk at iskunk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58638

Bug ID: 58638
   Summary: libstdc++ builds as non-PIC when --with-pic is
specified
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: skunk at iskunk dot org
  Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
 Build: x86_64-unknown-linux-gnu

I built GCC 4.8.1 with --disable-shared --with-pic so that I can statically
link libgcc/libstdc++ into executables, including shared-library builds.
However, when I attempted to build a C++ shared object on Linux/amd64 using the
new compiler, I got this:

libtool: link: g++  -fPIC -DPIC -shared -nostdlib /usr/lib/../lib64/crti.o
/opt/tg-opt/gcc--4.8.1--linux64/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.1/crtbeginS.o
 .libs/Dqa_wrap.o .libs/dqa_func.o [...]
-L/opt/tg-opt/gcc--4.8.1--linux64/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.1/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/opt/tg-opt/gcc--4.8.1--linux64/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.1/../../..
/opt/tg/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/libstdc++.a -lm -lc -lgcc
/opt/tg-opt/gcc--4.8.1--linux64/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.1/crtendS.o
/usr/lib/../lib64/crtn.o -march=opteron -mno-3dnow -O0   -pthread -Wl,-soname
-Wl,libdqa_swig_interface.so -o .libs/libdqa_swig_interface.so
/usr/bin/ld:
/opt/tg/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/libstdc++.a(eh_throw.o):
relocation R_X86_64_32S against `a local symbol' can not be used when making a
shared object; recompile with -fPIC
/opt/tg/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/libstdc++.a: could not read
symbols: Bad value
collect2: error: ld returned 1 exit status
make[6]: *** [libdqa_swig_interface.la] Error 1


This is a regression from 4.7.x, when --with-pic correctly caused all (static)
runtime libraries to be built with PIC code.


[Bug c++/58639] New: ICE on self-referential struct member

2013-10-05 Thread dirtyepic at gentoo dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58639

Bug ID: 58639
   Summary: ICE on self-referential struct member
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dirtyepic at gentoo dot org

#include vector

struct node
{
node parent;
};

void f()
{
std::vectornode v;
v.push_back({});
}

$ g++ -std=c++11 487010.cxx
g++: internal compiler error: Segmentation fault (program cc1plus)

ICE with trunk, 4.8.1, 4.7.3, and 4.6.4 with -std=c++0x.  4.5.4 correctly gives
an error.


[Bug tree-optimization/58640] New: wrong code (segfaults) at -O3 on x86_64-linux-gnu

2013-10-05 Thread su at cs dot ucdavis.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58640

Bug ID: 58640
   Summary: wrong code (segfaults) at -O3 on x86_64-linux-gnu
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu

The current gcc trunk mis-compiles the following code on x86_64-linux at -O3 in
both 32-bit and 64-bit modes, resulting in a segfault. 

This is a regression from 4.8.x. 


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure
--enable-languages=c,c++,objc,obj-c++,fortran,lto --disable-werror
--enable-checking=release --with-gmp=/usr/local/gcc-trunk
--with-mpfr=/usr/local/gcc-trunk --with-mpc=/usr/local/gcc-trunk
--with-cloog=/usr/local/gcc-trunk --prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 4.9.0 20131005 (experimental) [trunk revision 203223] (GCC) 
$ 
$ gcc-trunk -O2 small.c; a.out
$ gcc-4.8 -O3 small.c; a.out
$ gcc-trunk -O3 small.c; a.out
Segmentation fault (core dumped)
$ 


-


int a, b, c, d = 1, e;

static signed char
foo ()
{
  int f, g = a;

  for (f = 1; f  3; f++)
for (; b  1; b++)
  {
if (d)
  for (c = 0; c  4; c++)
for (f = 0; f  3; f++)
  {
for (e = 0; e  1; e++)
  a = g;
if (f)
  break;
  }
else if (f)
  continue;
return 0;
  }
  return 0;
}

int
main ()
{
  foo ();
  return 0;
}