[Bug c++/50442] Constructing T from implicit conversion to T ambiguous in C++0x mode, not C++98
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50442 Mike Hommey mh+gcc at glandium dot org changed: What|Removed |Added CC||mh+gcc at glandium dot org --- Comment #1 from Mike Hommey mh+gcc at glandium dot org 2011-09-17 06:21:28 UTC --- More specifically, r178746 from SVN gcc-4_6-branch is affected, while r178501 from the same branch is not.
[Bug libstdc++/50441] [C++0x] type_traits is missing GNU extension types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50441 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||joseph at codesourcery dot ||com --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-17 09:11:46 UTC --- The issue seems trivial at the type_traits level, but I'm not sure we want to do this right away (we have a similar one for numeric_limits and a preliminary patch sits on my machine): for instance I'm worried that if such types satisfy an enable_if in overload resolution, then must be handled by the code as any other integer (or floating point) type, and I don't think that with __int128_t and __uint128_t the full range of operations available for standard integer types is available. At least wasn't about a year ago. Also, I don't seem to remember such types are supported on all the targets. Moreover, when I was fiddling with numeric_limits, I remember Joseph pointing out the brittle status (in terms of specs, support, etc) of the 128 bits integer types. Maybe this has changed?
[Bug libstdc++/50441] [C++0x] type_traits is missing GNU extension types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50441 --- Comment #2 from Marc Glisse marc.glisse at normalesup dot org 2011-09-17 09:30:25 UTC --- Actually, gcc documents that __int128 is *not* an extended integer type: http://gcc.gnu.org/onlinedocs/gcc/Integers-implementation.html (the comment in the source file specifically mentions __int128) so the behavior is correct. And the standard only allows for 3 floating point types: float, double and long double. Now I agree that's not very helpful, I don't know what the libstdc++ policy is here.
[Bug fortran/50438] [F03] proc pointer to subroutine in structure constructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50438 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-17 Summary|proc pointer to subroutine |[F03] proc pointer to |in structure constructors |subroutine in structure ||constructors Ever Confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org 2011-09-17 09:39:50 UTC --- On this variant I get the same error on a different line: IMPLICIT NONE TYPE :: a PROCEDURE(aproc), POINTER, NOPASS :: p END TYPE TYPE(a) :: aa = a(aproc) CONTAINS SUBROUTINE aproc END SUBROUTINE END PROCEDURE(aproc), POINTER, NOPASS :: p 1 Error: Symbol 'aproc' at (1) has no IMPLICIT type
[Bug c++/50442] Constructing T from implicit conversion to T ambiguous in C++0x mode, not C++98
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50442 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-17 09:45:11 UTC --- maybe the fix for PR 49267 then, Jason?
[Bug c++/50442] Constructing T from implicit conversion to T ambiguous in C++0x mode, not C++98
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50442 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-17 09:48:55 UTC --- yep, confirmed that r178552 changed the behaviour
[Bug tree-optimization/50433] [4.7 Regression] ACATS c460010 fails to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50433 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Component|ada |tree-optimization --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-09-17 10:12:30 UTC --- I've already pinged Jan about it. http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00966.html
[Bug fortran/50403] SIGSEGV in gfc_use_derived
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50403 --- Comment #8 from janus at gcc dot gnu.org 2011-09-17 10:54:53 UTC --- Author: janus Date: Sat Sep 17 10:54:50 2011 New Revision: 178928 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178928 Log: 2011-09-17 Janus Weil ja...@gcc.gnu.org PR fortran/50403 * symbol.c (gfc_use_derived): Fix coding style. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/symbol.c
[Bug libstdc++/50441] [C++0x] type_traits is missing GNU extension types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50441 --- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot com 2011-09-17 11:23:43 UTC --- I have used the term sui generis extended type to refer to types such as __int128 that share many properties of integer types but are not such types (since intmax_t forms part of the ABI and these types are wider than intmax_t). I don't know what that means for type traits. All the C operations should work fine on __int128, and for __float128 where applicable (although it isn't possible to write _Complex __float128 at present since __float128 is not a keyword). ARM __fp16 is more restricted (in general values are promoted to float before arithmetic) and IA64 __fpreg is fairly clearly different from normal floating-point types. See PR 43622 and references therein. C++ support that should be present for such types, both integer-like and floating-point-like (not __fpreg in most cases, I suppose) includes typeinfo, numeric_limits (maybe with associated built-in macros), I/O (see libquadmath which libgfortran can use, and the associated complications of only linking it in static links if required) and mathematical functions in general.
[Bug c++/50443] New: ICE when using brace-enclosed initializer for C-style array in constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50443
Bug #: 50443
Summary: ICE when using brace-enclosed initializer for C-style
array in constructor
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: z...@sogetthis.com
Host: x86
Target: x86
The following code causes GCC 4.6.1 with -std=c++0x to crash:
struct Foo
{
Foo() : a{{5,7,3}} { }
int a[3];
};
Message: internal compiler error: in cxx_eval_bare_aggregate, at
cp/semantics.c:6539
[Bug testsuite/50185] [4.7 Regression] Bad AVX2 tests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50185 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-17 12:50:47 UTC --- I think this is fixed since r178302, hence closing. Please reopen if I am wrong.
[Bug libstdc++/50441] [C++0x] type_traits is missing GNU extension types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50441 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||paolo.carlini at oracle dot ||com --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-17 14:03:41 UTC --- Ok. I'm still not sure what we should here. In particular, as Marc pointed out, C++ is very clear about float, double and long double being the only floating point types. I guess to be safe, better starting with numeric_limits? In terms of operations, at some point for sure the extended integer types could not be default constructed, I'm sure because I helped a friend tweaking code to wa such issue. I suppose I should check again.
[Bug libstdc++/50441] [C++0x] type_traits is missing GNU extension types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50441 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-17 14:23:42 UTC --- Uhm, I noticed only now that submitter talks explicitly about -std=gnu++0x, not -std=c++0x. Sorry. Would be the first time I guess we enable a C++11 feature only for gnu but I think the whole idea makes much more sense.
[Bug fortran/50438] [F03] proc pointer to subroutine in structure constructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50438 --- Comment #2 from janus at gcc dot gnu.org 2011-09-17 15:00:33 UTC --- Contrary to what I suggested in http://gcc.gnu.org/ml/fortran/2011-09/msg00083.html this problem does not seem to be specific to SUBROUTINEs. It also happens when making proc/aproc FUNCTIONS.
[Bug c/50444] New: unaligned movdqa instruction after inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50444 Bug #: 50444 Summary: unaligned movdqa instruction after inlining Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: john.sal...@deshaw.com Created attachment 25309 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25309 C example On Linux, x86_64, the attached code segfaults when compiled with gcc4.6.1 and gcc4.6.0. There's no problem with gcc-4.5.3, nor when -O1 is removed. gdb reports that the instruction at the pc when it segfaults is: movdqa %xmm0, 0x28(%rbx) and that 0x28(%rbx) is only 8-bit aligned. It looks like the alignment requirement of the movdqa instruction has somehow been forgotten in the optimization that inlined the call to both caster() and ssefunc() and eliminated the memcpys. salm...@drdlogin0039.en.desres$ desres-cleanenv -m gcc/4.6.1-23A/bin gcc -Wall -O1 e2.c salm...@drdlogin0039.en.desres$ a.out Segmentation fault (core dumped) salm...@drdlogin0039.en.desres$ gdb a.out GNU gdb (GDB) 7.0.1 Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-unknown-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /d/en/salmonj-0/junk/misalign/a.out...done. (gdb) r Starting program: /d/en/salmonj-0/junk/misalign/a.out warning: no loadable sections found in added symbol-file system-supplied DSO at 0x2aaab000 Program received signal SIGSEGV, Segmentation fault. _mm_xor_si128 (e=0x7fffc070) at e2.c:51 51e-v = caster(*incr(e-c), e-key); (gdb) x /10i $pc 0x400504 method+28:movdqa %xmm0,0x28(%rbx) 0x400509 method+33:movq $0x4,0x20(%rbx) 0x400511 method+41:mov0x20(%rbx),%rax 0x400515 method+45:lea-0x1(%rax),%rdx 0x400519 method+49:mov%rdx,0x20(%rbx) 0x40051d method+53:mov0x24(%rbx,%rax,4),%eax 0x400521 method+57:pop%rbx 0x400522 method+58:retq 0x400523 main:push %rbx 0x400524 main+1:add$0xff80,%rsp (gdb) info reg rax0x7fffc080140737488339072 rbx0x7fffc070140737488339056 rcx0x4005704195696 rdx0x7fffc1a8140737488339368 rsi0x7fffc198140737488339352 rdi0x7fffc080140737488339072 rbp0x00x0 rsp0x7fffc0200x7fffc020 r8 0x3f8b3532d0272918459088 r9 0x3f8ac0d730272910833456 r100x00 r110x3f8b01d8a0272915093664 r120x00 r130x7fffc190140737488339344 r140x00 r150x00 rip0x4005040x400504 method+28 eflags 0x10202[ IF RF ] cs 0x3351 ss 0x2b43 ds 0x00 es 0x00 fs 0x00 gs 0x00 fctrl 0x37f895 fstat 0x00 ftag 0x65535 fiseg 0x00 fioff 0x00 foseg 0x00 fooff 0x00 fop0x00 mxcsr 0x1f80[ IM DM ZM OM UM PM ] (gdb)
[Bug libstdc++/50441] [C++0x] type_traits is missing GNU extension types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50441 --- Comment #6 from RétroX classixretrox at gmail dot com 2011-09-17 16:32:18 UTC --- Yeah, I was talking about specifically -std=gnu++0x, because that implies that you're accepting the GNU extensions into the standard. I suppose that in this case, because the standard is so strict, having more than the standard types would probably be a bad idea. However, having numeric_limits for them doesn't seem to have any negative impacts; on systems that support the type, you should be able to get information on the type.
[Bug tree-optimization/34265] Missed optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34265 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||irar at gcc dot gnu.org, ||wschmidt at gcc dot gnu.org --- Comment #36 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-17 17:09:59 UTC --- The pr 34265 and 49006 have been fixed by revision 176984: Author:wschmidt Date:Sun Jul 31 18:58:06 2011 UTC (6 weeks, 5 days ago) Changed paths:2 Log Message: 2011-07-29 Bill Schmidt wschm...@linux.vnet.ibm.com PR tree-optimization/49749 * tree-ssa-reassoc.c (get_rank): New forward declaration. (PHI_LOOP_BIAS): New macro. (phi_rank): New function. (loop_carried_phi): Likewise. (propagate_rank): Likewise. (get_rank): Add calls to phi_rank and propagate_rank. The following table compare the execution time and the line at which the vectorizer reports the vectorization for the twelve variants described in comment #34, showing that they are now all vectorized: revision 176983 176984 178905 num den rot time line time line time line o o o 2.154s 243 2.154s 243 2.133s 243 u o o 1.973s 243 1.970s 243 2.035s 243 o u o 2.024s 243 2.023s 243 1.977s 243 u u o 3.053s 1.817s 234 1.831s 234 o o u 3.015s 1.839s 234 1.841s 234 u o u 3.030s 1.828s 234 1.816s 234 o u u 3.049s 1.818s 234 1.834s 234 u u u 3.059s 1.820s 234 1.818s 234 o o f 3.010s 1.825s 234 1.822s 234 u o f 3.033s 1.836s 234 1.826s 234 o u f 3.061s 1.814s 234 1.828s 234 u u f 3.058s 1.825s 234 1.812s 234 graphite1.937s 243 1.938s 243 1.912s 243 (num, den and rot stand for numerator, denominator and rotate respectively; o, u, and f stand for original, unrolled, and folded. Since now gcc has (at least for this class of code;) the three properties I expect from a good optimizer: (1) it does not destroy the hand optimization I have done; (2) it optimizes the original code; (3) it has a consistent behavior across variants; I think a test should be added to the test suite to check that none of these properties are lost in future revisions.
[Bug fortran/50438] [F03] proc pointer to subroutine in structure constructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50438
--- Comment #3 from janus at gcc dot gnu.org 2011-09-17 17:44:25 UTC ---
I think the problem is that the structure constructor is resolved too early
(already when parsing the corresponding source line, where 'aproc' is not known
yet).
Here is a simple patch to avoid this:
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c(revision 178927)
+++ gcc/fortran/expr.c(working copy)
@@ -2654,7 +2654,6 @@ gfc_match_init_expr (gfc_expr **result)
{
gfc_expr *expr;
match m;
- gfc_try t;
expr = NULL;
@@ -2667,14 +2666,6 @@ gfc_match_init_expr (gfc_expr **result)
return m;
}
- t = gfc_reduce_init_expr (expr);
- if (t != SUCCESS)
-{
- gfc_free_expr (expr);
- gfc_init_expr_flag = false;
- return MATCH_ERROR;
-}
-
*result = expr;
gfc_init_expr_flag = false;
It cures both test cases, but I'm pretty sure it will have quite a number of
testsuite failures (haven't checked yet). If we remove it here,
'gfc_reduce_init_expr' should be called somewhere at resolution stage, of
course! We just need a suitable place for doing this ...
[Bug fortran/50438] [F03] proc pointer to subroutine in structure constructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50438 --- Comment #4 from janus at gcc dot gnu.org 2011-09-17 17:53:01 UTC --- (In reply to comment #3) I think the problem is that the structure constructor is resolved too early Btw, there was a similar problem recently (PR 49112 comment 6), which was fixed by this patch: http://gcc.gnu.org/ml/fortran/2011-07/msg00305.html
[Bug target/50223] AVRGCC - dont clear r26 and r27.....its a (small) waste of CPU cycles.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50223
Georg-Johann Lay gjl at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Known to work||4.6.1
Resolution||WORKSFORME
--- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-09-17
18:35:52 UTC ---
Following test program
extern uint8_t leadingZeros[];
#define pgm_read(a,b) asm (lpm %0,%a1 : =r (a) : z ((uint16_t)(b)))
uint8_t ldgZeroCntNormU32 (uint32_t* x)
{
uint8_t zCount = 0;
uint8_t shft;
uint32_t quad = *x;
while (!(uint8_t)(quad 24))
{
zCount += 8;
quad =8;
}
pgm_read (shft, leadingZeros[(uint8_t)(quad 24)]);
*x = quad shft;
return zCount + shft;
}
yields with avr-gcc-4.6.1 -Os -mmcu=atmega8 -S following result:
ldgZeroCntNormU32:
movw r26,r24
ld r20,X+
ld r21,X+
ld r22,X+
ld r23,X
sbiw r26,3
ldi r24,lo8(0)
rjmp .L2
.L3:
subi r24,lo8(-(8))
mov r23,r22
mov r22,r21
mov r21,r20
clr r20
.L2:
mov r30,r23
tst r23
breq .L3
ldi r31,lo8(0)
subi r30,lo8(-(leadingZeros))
sbci r31,hi8(-(leadingZeros))
/* #APP */
; 20 foo.c 1
lpm r30,Z
; 0 2
/* #NOAPP */
mov r0,r30
rjmp 2f
1:lsl r20
rol r21
rol r22
rol r23
2:dec r0
brpl 1b
st X+,r20
st X+,r21
st X+,r22
st X,r23
sbiw r26,3
add r24,r30
ret
So there is no CLR for the while (!(uint8_t)(quad 24))
Closed as works for me.
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #12 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-09-17 19:35:56 UTC --- (In reply to comment #11) With fix I commited for PR50430 and the workaround for PR50383 my build dies on java modules. I believe it is the problem we run into with Michael on the opensuse conference and we made that module to be last (it is because on my setup sun java does not work and ibm java apparently breaks with current libreoffice). So perhaps this is all needed? It will build fine with LTO (and --without-java), but the resulting binary crashes during startup: terminate called after throwing an instance of 'com::sun::star::container::NoSuchElementException' It throws an exception in: xmlreader::XmlReader::XmlReader(rtl::OUString const) () from image/usr/ure/lib/libxmlreader.so. This happens in xmlreader/source/xmlreader.cxx. I haven't looked deeper yet, but a non LTO build shows no problems at all.
[Bug libstdc++/50441] [C++0x] type_traits is missing GNU extension types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50441 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-17 CC|paolo.carlini at oracle dot | |com | AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Ever Confirmed|0 |1
[Bug libstdc++/50441] [C++0x] type_traits is missing GNU extension types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50441 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-17 19:51:48 UTC --- Ok, I'm doing this. By the way, the type for which we had weird problems was __m128i, not __int128_t (not my idea using it...)
[Bug libstdc++/50441] [C++0x] type_traits is missing GNU extension types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50441 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-17 20:33:31 UTC --- (In reply to comment #4) In terms of operations, at some point for sure the extended integer types *Ahem!* __int128 is not an extended integer type! GCC does not support any extended integer types! :) http://gcc.gnu.org/onlinedocs/gcc/Integers-implementation.html
[Bug c++/50445] New: Rejects use of constant expression using a pointer non-type template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50445
Bug #: 50445
Summary: Rejects use of constant expression using a pointer
non-type template parameter
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: schaub.johan...@googlemail.com
This is rejected by GCC:
extern int const values[] = { 1, 2, 3 };
templateint const *values struct X {
static int const val0 = values[0];
};
int array[Xvalues::val0];
GCC error message:
error: non-constant in-class initialization invalid for static member
'X((const int*)( values))::val0'
However, as far as I can see, values[0] is a valid integral constant
expression.
[Bug libstdc++/50441] [C++0x] type_traits is missing GNU extension types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50441 --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-17 20:40:30 UTC --- Sorry, I didn't mean *extended* in any technical sense, but in the same sense used by Joseph, sui generis.
[Bug c++/50443] ICE when using brace-enclosed initializer for C-style array in constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50443 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-17 20:49:21 UTC --- works fine with gcc version 4.7.0 20110917 (experimental) [trunk revision 178930] (GCC) and gcc version 4.6.2 20110917 (prerelease) [gcc-4_6-branch revision 178930] (GCC)
[Bug c++/50443] ICE when using brace-enclosed initializer for C-style array in constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50443
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-17
20:55:14 UTC ---
by works fine I mean no ICE, there's an error because it should be a{5,7,3}
[Bug libstdc++/50441] [C++0x] type_traits is missing GNU extension types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50441 --- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-17 21:19:05 UTC --- I'd like to have some help about the best way to figure out whether the target supports __int128_t and __uint128_t: is __CHAR_BIT__ * __SIZEOF_LONG__ = 64 good enough?
[Bug libstdc++/50441] [C++0x] type_traits is missing GNU extension types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50441 --- Comment #11 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-17 21:32:49 UTC --- Better adding configure tests...
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #13 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-09-17 21:42:57 UTC --- (In reply to comment #12) (In reply to comment #11) With fix I commited for PR50430 and the workaround for PR50383 my build dies on java modules. I believe it is the problem we run into with Michael on the opensuse conference and we made that module to be last (it is because on my setup sun java does not work and ibm java apparently breaks with current libreoffice). So perhaps this is all needed? It will build fine with LTO (and --without-java), but the resulting binary crashes during startup: terminate called after throwing an instance of 'com::sun::star::container::NoSuchElementException' It throws an exception in: xmlreader::XmlReader::XmlReader(rtl::OUString const) () from image/usr/ure/lib/libxmlreader.so. This happens in xmlreader/source/xmlreader.cxx. I haven't looked deeper yet, but a non LTO build shows no problems at all. The above happened when I configured --with-max-jobs=4 and --with-num-cpus=4. With -with-max-jobs=1 and --with-num-cpus=4 I get a different crash on startup: Program received signal SIGABRT, Aborted. 0x77db7695 in __GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); #0 0x77db7695 in __GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x77db8b3d in __GI_abort () at abort.c:93 #2 0x77bc486d in _Unwind_SetGRValue (val=optimized out, index=optimized out, context=optimized out) at /var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/gcc-4.5.3/libgcc/../gcc/unwind-dw2.c:253 #3 uw_update_context_1 (context=0x7fffbdc0, fs=0x7fffbc40) at /var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/gcc-4.5.3/libgcc/../gcc/unwind-dw2.c:1368 #4 0x77bc4b91 in uw_update_context (context=0x7fffbdc0, fs=0x7fffbc40) at /var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/gcc-4.5.3/libgcc/../gcc/unwind-dw2.c:1388 #5 0x77bc57cb in _Unwind_RaiseException (exc=0xe64150) at /var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/gcc-4.5.3/libgcc/../gcc/unwind.inc:122 #6 0x77d0d741 in __cxa_throw () from /usr/lib64/libstdc++.so.6 #7 0x718915c8 in gcc3::raiseException(_uno_Any*, _uno_Mapping*) () from /var/tmp/portage/app-office/libreoffice--r1/image/usr/ure/lib/libgcc3_uno.so #8 0x71892dff in cpp2uno_call(bridges::cpp_uno::shared::CppInterfaceProxy*, _typelib_TypeDescription const*, _typelib_TypeDescriptionReference*, int, _typelib_MethodParameter*, void**, void**, void**, unsigned long*) () from /var/tmp/portage/app-office/libreoffice--r1/image/usr/ure/lib/libgcc3_uno.so #9 0x71893553 in cpp_vtable_call () from /var/tmp/portage/app-office/libreoffice--r1/image/usr/ure/lib/libgcc3_uno.so #10 0x71895356 in privateSnippetExecutor () from /var/tmp/portage/app-office/libreoffice--r1/image/usr/ure/lib/libgcc3_uno.so #11 0x779389f3 in cppu::throwException(com::sun::star::uno::Any const) () from /var/tmp/portage/app-office/libreoffice--r1/image/usr/program/../basis-link/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 #12 0x769cd7ec in ucbhelper::cancelCommandExecution(com::sun::star::ucb::IOErrorCode, com::sun::star::uno::Sequencecom::sun::star::uno::Any const, com::sun::star::uno::Referencecom::sun::star::ucb::XCommandEnvironment const, rtl::OUString const, com::sun::star::uno::Referencecom::sun::star::ucb::XCommandProcessor const) () from /var/tmp/portage/app-office/libreoffice--r1/image/usr/program/../basis-link/program/libucbhelper4gcc3.so #13 0x in ?? ()
[Bug c++/50443] ICE when using brace-enclosed initializer for C-style array in constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50443 --- Comment #3 from Kerrek SB z0sh at sogetthis dot com 2011-09-17 21:50:05 UTC --- Alright, if it's fixed already, that's fine. I only have the full release versions, so I didn't test anything newer than 4.6.1. Thanks!
[Bug c++/50442] [4.6 regression] Constructing T from implicit conversion to T ambiguous in C++0x mode, not C++98
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50442 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-09-17 Version|4.6.1 |4.6.2 AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Summary|Constructing T from |[4.6 regression] |implicit conversion to T |Constructing T from |ambiguous in C++0x mode,|implicit conversion to T |not C++98 |ambiguous in C++0x mode, ||not C++98 Ever Confirmed|0 |1
[Bug c++/50442] [4.6 regression] Constructing T from implicit conversion to T ambiguous in C++0x mode, not C++98
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50442 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2011-09-17 22:35:15 UTC --- Author: jason Date: Sat Sep 17 22:35:10 2011 New Revision: 178932 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178932 Log: PR c++/50442 Revert: PR c++/49267 * call.c (compare_ics): rvaluedness_matches_p can differ based on the source type, not just target. Removed: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/rv-conv1.C Modified: branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/call.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug c++/49267] Ambiguity with conversion functions T and T, initializing a T
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49267 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.6.2 |4.7.0 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2011-09-17 22:37:08 UTC --- The fix in 4.6.2 caused bug 50442, so I've reverted it; still fixed for 4.7.
[Bug c++/49267] Ambiguity with conversion functions T and T, initializing a T
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49267 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org 2011-09-17 22:35:15 UTC --- Author: jason Date: Sat Sep 17 22:35:10 2011 New Revision: 178932 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178932 Log: PR c++/50442 Revert: PR c++/49267 * call.c (compare_ics): rvaluedness_matches_p can differ based on the source type, not just target. Removed: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/rv-conv1.C Modified: branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/call.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug c++/50442] [4.6 regression] Constructing T from implicit conversion to T ambiguous in C++0x mode, not C++98
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50442 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.2 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org 2011-09-17 22:35:48 UTC --- Fixed by reverting the earlier patch.
[Bug libstdc++/50441] [C++0x] type_traits is missing GNU extension types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50441 --- Comment #12 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-09-17 23:53:30 UTC --- Author: paolo Date: Sat Sep 17 23:53:26 2011 New Revision: 178933 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178933 Log: 2011-09-17 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/50441 * acinclude.m4 ([GLIBCXX_ENABLE_INT128_FLOAT128]): Add. * configure.ac: Call it. * include/std/type_traits (__is_integral_helper__int128_t, __is_integral_helper__uint128_t, __is_floating_point_helper__float128, __make_unsigned__int128_t, __make_signed__uint128_t): Add. * testsuite/20_util/make_signed/requirements/typedefs-1.cc: Extend. * testsuite/20_util/make_signed/requirements/typedefs-2.cc: Likewise. * testsuite/20_util/make_unsigned/requirements/typedefs-1.cc: Likewise. * testsuite/20_util/make_unsigned/requirements/typedefs-2.cc: Likewise. * testsuite/20_util/is_signed/value.cc: Likewise. * testsuite/20_util/is_unsigned/value.cc: Likewise. * testsuite/20_util/is_integral/value.cc: Likewise. * testsuite/20_util/is_floating_point/value.cc: New. * testsuite/20_util/is_floating_point/requirements/typedefs.cc: Likewise. * testsuite/20_util/is_floating_point/requirements/ explicit_instantiation.cc: Likewise. * testsuite/20_util/make_signed/requirements/typedefs_neg.cc: Adjust dg-error line numbers. * testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc: Likewise. * testsuite/20_util/declval/requirements/1_neg.cc: Likewise. * configure: Regenerate. * config.h.in: Likewise. Added: trunk/libstdc++-v3/testsuite/20_util/is_floating_point/ trunk/libstdc++-v3/testsuite/20_util/is_floating_point/requirements/ trunk/libstdc++-v3/testsuite/20_util/is_floating_point/requirements/explicit_instantiation.cc trunk/libstdc++-v3/testsuite/20_util/is_floating_point/requirements/typedefs.cc trunk/libstdc++-v3/testsuite/20_util/is_floating_point/value.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/config.h.in trunk/libstdc++-v3/configure trunk/libstdc++-v3/configure.ac trunk/libstdc++-v3/include/std/type_traits trunk/libstdc++-v3/testsuite/20_util/declval/requirements/1_neg.cc trunk/libstdc++-v3/testsuite/20_util/is_integral/value.cc trunk/libstdc++-v3/testsuite/20_util/is_signed/value.cc trunk/libstdc++-v3/testsuite/20_util/is_unsigned/value.cc trunk/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs-1.cc trunk/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs-2.cc trunk/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs_neg.cc trunk/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs-1.cc trunk/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs-2.cc trunk/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc
[Bug libstdc++/50441] [C++0x] type_traits is missing GNU extension types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50441 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #13 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-17 23:55:22 UTC --- Done.
