Since revision 159443, there are multiple failures in the objc and libgomp test
suites (see http://gcc.gnu.org/ml/gcc-testresults/2010-05/msg01478.html ). They
are all of the form:
/var/tmp//ccIspVYP.s:816:non-relocatable subtraction expression,
"___emutls_v.baz.1169" minus "L002$pb"^M
/va
--- Comment #22 from dominiq at lps dot ens dot fr 2010-05-17 07:21 ---
I have open pr44163 for the testsuite failures on ppc-darwin. Since they are
fixed by reverting revision 159371, I think pr44163 is related to this one (if
not a duplicate).
--
http://gcc.gnu.org/bugzilla/show_b
--- Comment #23 from dominiq at lps dot ens dot fr 2010-05-17 07:25 ---
Although it may be unrelated, pr44163 reports intermittent bootstrap failures
related to TLS found or not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
--- Comment #1 from iains at gcc dot gnu dot org 2010-05-17 07:43 ---
@159462 on powerpc64 with:
http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01119.html
(and needed for m32, but not to solve the tls problem)
http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01125.html
ObjC/C++ tls fails are
--- Comment #18 from siarhei dot siamashka at gmail dot com 2010-05-17
07:53 ---
Created an attachment (id=20676)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20676&action=view)
powerpc64-broken-unreachable.i
With the attached file (and '-O2 -c' options):
1. powerpc64 crosscompi
--- Comment #4 from krebbel at gcc dot gnu dot org 2010-05-17 07:54 ---
Subject: Bug 44078
Author: krebbel
Date: Mon May 17 07:53:20 2010
New Revision: 159475
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159475
Log:
2010-05-17 Christian Borntraeger
PR 44078
--- Comment #6 from janus at gcc dot gnu dot org 2010-05-17 08:25 ---
Subject: Bug 44044
Author: janus
Date: Mon May 17 08:25:06 2010
New Revision: 159476
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159476
Log:
2010-05-17 Janus Weil
PR fortran/44044
* reso
Using Boost.Bind/Boost.Function triggers what seems to be an aliasing bug with
G++ 4.5.0. The minimal test case (including Boost.Bind and Boost.Function) is
attached.
It works and no errors are detected by valgrind with either flags :
-O0
-O1
-O2 -fno-inline
-O2 -fno-strict-aliasing
-Os
It c
--- Comment #7 from janus at gcc dot gnu dot org 2010-05-17 08:31 ---
Comment #0 and #1 are fixed at this point. I think the runtime checking in
comment #2 one can ignore for the moment, since most usage cases of ordinary
pointers are also not checked for.
So the only ToDo item left her
--- Comment #1 from maxime at altribe dot org 2010-05-17 08:31 ---
Created an attachment (id=20677)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20677&action=view)
Test case including Boost.Bind and Boost.Function.
I had to gzip the .ii file because of size limit.
--
http://
--- Comment #2 from dominiq at lps dot ens dot fr 2010-05-17 08:45 ---
> Reverting revision 159371 fixes these failures.
I had to revert revision 159371 at revision 159429 with the patch
inhttp://gcc.gnu.org/ml/gcc-patches/2010-04/msg00129.html .
--
http://gcc.gnu.org/bugzilla/show
--- Comment #3 from iains at gcc dot gnu dot org 2010-05-17 08:54 ---
(In reply to comment #2)
> > Reverting revision 159371 fixes these failures.
>
> I had to revert revision 159371 at revision 159429 with the patch
> inhttp://gcc.gnu.org/ml/gcc-patches/2010-04/msg00129.html .
You had
--- Comment #14 from sebastian dot huber at embedded-brains dot de
2010-05-17 09:04 ---
This bug is present since r130052 which is related to:
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01814.html
If this is a generic bug or not is quite irrelevant since this is a very
serious bug o
--- Comment #19 from siarhei dot siamashka at gmail dot com 2010-05-17
09:06 ---
Can anybody knowledgeable verify whether it was commit r151790 (
http://repo.or.cz/w/official-gcc.git/commit/9dbb96fec5e08762f97dda771522283f1fe9710f
) that is causing troubles when __builtin_unreachable()
--- Comment #20 from jakub at gcc dot gnu dot org 2010-05-17 09:08 ---
Perhaps dup of PR44071 that got fixed recently?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42347
--- Comment #4 from dominiq at lps dot ens dot fr 2010-05-17 09:08 ---
> You had to revert 159371 in addition to the patch:
> http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01119.html
>
> or instead of that patch?
Sorry for the confusion.
In my powerpc-apple-darwin9 tree I have the pat
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-05-17 09:10 ---
(In reply to comment #3)
> It might be useful to compare the two decls that invoke the mismatch that
> triggers the gcc_assert:
>
> prevailing->decl is:
>
> type type align 8 symtab 0 al
--- Comment #3 from paolo dot carlini at oracle dot com 2010-05-17 09:35
---
Ok, then please open a new PR including a *minimal* testcase.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-17 09:39 ---
It's not a dup of PR42834 (but it might be the same issue as PR42832 which
was a libstdc++ bug or a frontend bug).
It happens to work on trunk, so it might also be a dup of PR43987 (though
unlikely), rather differen
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-05-17 09:44 ---
The boost folks may be able to tell if they at any place copy a
function_buffer object via the assignment operator.
I see they also have funny stuff like get_vtable() and are playing with
typeinfos.
--
rguenth a
--- Comment #21 from siarhei dot siamashka at gmail dot com 2010-05-17
10:07 ---
(In reply to comment #18)
> Created an attachment (id=20676)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20676&action=view) [edit]
> powerpc64-broken-unreachable.i
>
> With the attached file (and '
--- Comment #22 from siarhei dot siamashka at gmail dot com 2010-05-17
11:31 ---
(In reply to comment #20)
> Perhaps dup of PR44071 that got fixed recently?
The problem is still reproducible with SVN rev 159480 in
'branches/gcc-4_5-branch', so the fix from PR44071 does not seem to help
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--- Comment #14 from fxcoudert at gcc dot gnu dot org 2010-05-17 12:07
---
Appears to be fixed. Please reopen if that's not the case.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from dodji at gcc dot gnu dot org 2010-05-17 12:30 ---
Created an attachment (id=20678)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20678&action=view)
Candidate patch
On Fri, May 14, 2010 at 07:25:18AM -, jakub at gcc dot gnu dot org wrote:
> That said, it wou
--- Comment #3 from jamborm at gcc dot gnu dot org 2010-05-17 12:48 ---
Subject: Bug 44133
Author: jamborm
Date: Mon May 17 12:48:34 2010
New Revision: 159482
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159482
Log:
2010-05-17 Martin Jambor
PR middle-end/44133
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2010-05-17 12:53
---
On Mac OS X (all versions), the correct fix is to use _NSGetEnviron() instead
of extern variable environ, and to include . Example of use:
#include
#include
#include
int main (void)
{
// Instead of: extern
When I attempt to compile the snapshot of 5/15/2010 on an HPPA workstation
under Debian Linux 5.0 I get the following messages:
checking whether the C compiler works... configure: error: in
`/home/mrichmon/gcc-4.6-20100515/g95/hppa1.1-unknown-linux-gnu/libgomp':
configure: error: cannot run C comp
--- Comment #4 from maxime at altribe dot org 2010-05-17 13:10 ---
(In reply to comment #3)
> The boost folks may be able to tell if they at any place copy a
> function_buffer object via the assignment operator.
It seems so. From Peter Dimov :
> [...] after stepping through the code, i
--- Comment #23 from jakub at gcc dot gnu dot org 2010-05-17 13:24 ---
Created an attachment (id=20679)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20679&action=view)
gcc46-pr42347.patch
Ah, I see. returnjump_p is considered onlyjump_p, yet it has side-effect that
prevent it fr
--- Comment #2 from bergner at gcc dot gnu dot org 2010-05-17 13:41 ---
Subject: Bug 44075
Author: bergner
Date: Mon May 17 13:41:22 2010
New Revision: 159487
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159487
Log:
Backport from mainline:
2010-05-14 Alan Mod
-fvisibility=protected doesn't work?
a...@xlin2:~$ cat 1.c
void F1() { }
void* F2() { return F1; }
j...@xlin2:~$ $HOME/bin/gcc 1.c -fPIC -shared -fvisibility=protected
/usr/bin/ld: /tmp/cc0d6EQ3.o: relocation R_386_GOTOFF against protected
function `F1' can not be used when making a shared objec
--- Comment #5 from iains at gcc dot gnu dot org 2010-05-17 13:43 ---
(In reply to comment #4)
> In my powerpc-apple-darwin9 tree I have the patch in
> http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01119.html for a quite long time
OK, might be worth double-checking - both parts are need
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-05-17 13:47 ---
Can you give the output of ld --version ? There might have been a binutils bug
about this before.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-05-17 13:49 ---
*** This bug has been marked as a duplicate of 37611 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-05-17 13:49 ---
*** Bug 44166 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
The following code (see below) triggers an ICE.
Command line:
g++ -save-temps -Wall -std=c++0x testcase.cc -o testcase
Error message:
testcase.cc: In function int main():
testcase.cc:42: internal compiler error: in tsubst_copy, at cp/pt.c:10077
Please submit a full bug report,
with preproce
--- Comment #1 from marc dot hofmann at gmail dot com 2010-05-17 13:51
---
Created an attachment (id=20680)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20680&action=view)
Testcase source file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44167
The following code (see below) triggers an ICE.
Command line:
g++ -save-temps -Wall -std=c++0x testcase.cc -o testcase
Error message:
testcase.cc: In function int main():
testcase.cc:42: internal compiler error: in tsubst_copy, at cp/pt.c:10077
Please submit a full bug report,
with preproce
--- Comment #4 from dodji at gcc dot gnu dot org 2010-05-17 13:54 ---
Created an attachment (id=20681)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20681&action=view)
Don't warn for integral constants
Jakub, this one line patch implements the first idea which is to not warn for
i
--- Comment #2 from redi at gcc dot gnu dot org 2010-05-17 13:55 ---
*** Bug 44168 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44167
--- Comment #3 from marc dot hofmann at gmail dot com 2010-05-17 13:55
---
Created an attachment (id=20682)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20682&action=view)
Preprocessed file.
Created with:
g++ -save-temps -Wall -std=c++0x testcase.cc -o testcase
--
http://g
--- Comment #1 from redi at gcc dot gnu dot org 2010-05-17 13:55 ---
*** This bug has been marked as a duplicate of 44167 ***
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from redi at gcc dot gnu dot org 2010-05-17 14:00 ---
4.5 doesn't ICE
pr44167.cc: In function 'int main()':
pr44167.cc:7:44: sorry, unimplemented: use of 'type_pack_expansion' in template
pr44167.cc:41:35: error: no matching function for call to 'apply(int (&)(int,
double
--- Comment #5 from redi at gcc dot gnu dot org 2010-05-17 14:03 ---
(In reply to comment #4)
>
> possibly a dup of bug 43382
actually I don't think it is a dup, because 43382 crashes with 4.5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44167
--- Comment #26 from rguenth at gcc dot gnu dot org 2010-05-17 14:28
---
The problem from comment #12 seems to be back.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
libgomp testsuite fails with a segfault. It segfaults in
gomp_resolve_num_threads(), accessing the second TLS value.
The first access:
.LBB28:
.file 2 "../../../src/libgomp/libgomp.h"
.loc 2 380 0
bcl 20,31,$+8
.long _GLOBAL_OFFSET_TABLE_-$
mflr 9
--- Comment #1 from gcc at breakpoint dot cc 2010-05-17 15:44 ---
Created an attachment (id=20683)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20683&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44169
--- Comment #2 from gcc at breakpoint dot cc 2010-05-17 15:44 ---
Created an attachment (id=20684)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20684&action=view)
rtl pass 185r.cprop_hardreg
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44169
--- Comment #3 from gcc at breakpoint dot cc 2010-05-17 15:45 ---
Created an attachment (id=20685)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20685&action=view)
rtl pass 186r.dce
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44169
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-05-17 15:50 ---
(In reply to comment #4)
> (In reply to comment #3)
> > The boost folks may be able to tell if they at any place copy a
> > function_buffer object via the assignment operator.
>
> It seems so. From Peter Dimov :
>
The following code crashes the compiler with this message:
> g++ gccbug.cpp
gccbug.cpp: In destructor 'VEXPR::~VEXPR() [with T = VECTOR_PAIR]':
gccbug.cpp:32: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-05-17 15:57 ---
Basically the middle-end sees this the same as
int i = 1, j;
float *p = new (&i) float(0.0);
j = i;
return *reinterpret_cast(&j);
and you expect to return 0.0.
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #1 from redi at gcc dot gnu dot org 2010-05-17 16:34 ---
4.1.1 is no longer maintained. This doesn't cause an ICE with 4.4.3 or 4.5.0
pr44170.cc:29: error: specialization of 'VEXPR::~VEXPR() [with T =
VECTOR_PAIR]' after instantiation
--
redi at gcc dot gnu dot org chang
--- Comment #2 from davek at gcc dot gnu dot org 2010-05-17 17:02 ---
Yes, it certainly does, in fact it omits to compile any definition for 'foo'
whatsoever!
But isn't this the expected behaviour of using '-fwhole-program' on something
that is not the whole program? I'm not sure if th
--- Comment #6 from dominiq at lps dot ens dot fr 2010-05-17 17:09 ---
The patch in comment #5 fixes the ICE without side effects (AFAICT!-), but it
does not fix PR43895 (see comments #3 and #4).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43990
--- Comment #1 from jakub at gcc dot gnu dot org 2010-05-17 17:18 ---
Subject: Bug 44102
Author: jakub
Date: Mon May 17 17:18:24 2010
New Revision: 159495
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159495
Log:
PR middle-end/44102
* cfgcleanup.c (try_optimize_
--- Comment #24 from jakub at gcc dot gnu dot org 2010-05-17 17:20 ---
Subject: Bug 42347
Author: jakub
Date: Mon May 17 17:19:46 2010
New Revision: 159496
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159496
Log:
PR bootstrap/42347
* cfglayout.c (fixup_reorder_
--- Comment #5 from jakub at gcc dot gnu dot org 2010-05-17 17:25 ---
Subject: Bug 44108
Author: jakub
Date: Mon May 17 17:24:32 2010
New Revision: 159497
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159497
Log:
PR c++/44108
* decl.c (compute_array_index_type):
--- Comment #25 from jakub at gcc dot gnu dot org 2010-05-17 17:26 ---
Subject: Bug 42347
Author: jakub
Date: Mon May 17 17:26:22 2010
New Revision: 159499
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159499
Log:
PR bootstrap/42347
* cfglayout.c (fixup_reorder_
In testing patches to support Solaris 9/x86 with Sun as on Solaris 11/x86, I
noticed that several testcases with -gdwarf-2 -dA failed, producing invalid
assembler output. I could trace this down to dwarf2asm.c
(dw2_asm_output_nstring)
unconditionally emitting .ascii, which the Solaris 8/x86 as doe
I was trying to create a tree. I have realized that the following code makes
the g++ compiler to never stop compilation.
#include
#include
#include
#include
using namespace std;
namespace gumocap{
namespace core{
namespace tree{
template
class Node: public vector< Node* >
{
public:
--- Comment #26 from jakub at gcc dot gnu dot org 2010-05-17 17:31 ---
Subject: Bug 42347
Author: jakub
Date: Mon May 17 17:30:54 2010
New Revision: 159500
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159500
Log:
PR bootstrap/42347
* cfglayout.c (fixup_reorder_
--- Comment #27 from jakub at gcc dot gnu dot org 2010-05-17 17:33 ---
The http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159499
commit was actually for PR44102.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from jakub at gcc dot gnu dot org 2010-05-17 17:34 ---
On branches/gcc-4_5-branch fixed by
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159499
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from janus at gcc dot gnu dot org 2010-05-17 17:41 ---
(In reply to comment #6)
> but it does not fix PR43895 (see comments #3 and #4).
... which I take as an indication that the two are indeed not so much related.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43990
--- Comment #1 from dougsemler at gmail dot com 2010-05-17 17:46 ---
This is the offender:
Node(const T& v,Node Tparent=NULL) {_parent=Tparent;_data=v;}
It looks like you have transposed the *> (it should be the following, right?
Node(const T& v,Node* Tparent=NULL) {_parent=Tparent;_d
--- Comment #2 from rmsalinas at uco dot es 2010-05-17 17:50 ---
Subject: Re: Compiling never ends
My god! you work really fast!
Yes, I've found the error just few seconds ago.
Great work!
dougsemler at gmail dot com escribió:
> --- Comment #1 from dougsemler at gmail dot com
--- Comment #10 from davek at gcc dot gnu dot org 2010-05-17 18:25 ---
Re-opening. It turns out that GCC fails to actually apply the dllexport
attribute to TLS control vars. So solving the binutils problem allows
auto-export of a TLS variable to work, but as auto-export gets disabled i
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |davek at gcc dot gnu dot org
|dot org
--- Comment #3 from davek at gcc dot gnu dot org 2010-05-17 18:28 ---
Consensus seems to be that this is indeed "how it's meant to work", but that
figuring out which are the externally visible functions and marking them
automatically would be a nice enhancement that would make the -fwhol
--- Comment #7 from ro at gcc dot gnu dot org 2010-05-17 18:29 ---
Posted new patch.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
URL|
--- Comment #3 from paolo dot carlini at oracle dot com 2010-05-17 18:32
---
Ok.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|U
--- Comment #3 from zsojka at seznam dot cz 2010-05-17 18:45 ---
Stil appears in r159500, x86_64-linux.
Uninitialised read is at gcc/haifa-sched.c:1589, more exactly it is read of
BLOCK_FOR_INSN (insn)
When gcc/haifa-sched.c:1589 is changed to:
insn != NULL_RTX && (printf("%p %p\n", (v
--- Comment #10 from siarhei dot siamashka at gmail dot com 2010-05-17
18:48 ---
Maybe I'm too impatient, but is there anything that prevents this patch from
getting committed to SVN?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43698
/src/gcc-4.5.0/configure -verbose -disable-shared -enable-static -disable-bo
otstrap -disable-fixincludes -prefix=$HOME
/bin/sh /src/gcc-4.5.0/gcc/../move-if-change tmp-fixinc_list fixinc_list
echo timestamp > s-fixinc_list
make[2]: *** No rule to make target
`../build-i686-pc-linux-gnu/fixinclu
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-05-17 18:53 ---
I don't think this can ever work except when you know 100% that the headers
don't need to be fix included. Only newer glibc don't need it and newlib
either. But the majority of the other OS's need it really.
--
--- Comment #7 from pdimov at gmail dot com 2010-05-17 19:10 ---
(In reply to comment #6)
> Basically the middle-end sees this the same as
> int i = 1, j;
> float *p = new (&i) float(0.0);
> j = i;
> return *reinterpret_cast(&j);
> and you expect to return 0.0.
The int/float exa
--- Comment #8 from pinskia at gcc dot gnu dot org 2010-05-17 19:17 ---
The first example I think does as there is no way to "transfer" the dynamic
type via the struct copy. The second one does not as the union still has a
field that is float and it is only unspecified behavior if you a
/* { dg-do compile } */
/* { dg-options "-O2 -fpic" { target fpic } } */
int f0 (int, int, int, int, int);
int f1 (void);
void
f2 (void)
{
unsigned v1, v2, v3, v4;
__asm__ ("" : "=a" (v1), "=d" (v2), "=c" (v3), "=r" (v4));
f0 (f1 (), f1 (), f1 (), f1 (), (v4 >> 8) & 0xff);
}
used to compile
--- Comment #8 from paolo dot carlini at oracle dot com 2010-05-17 19:29
---
DJ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43918
See attached testcase.
Several things can happen when decltype is used in a function template's return
type to refer to another specialization of the same template.
- The right thing (not easily produced from the current code, but see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44162)
- Non-produ
--- Comment #1 from potswa at mac dot com 2010-05-17 19:38 ---
Created an attachment (id=20686)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20686&action=view)
recursive decltype crashes g++
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44175
--- Comment #2 from paolo dot carlini at oracle dot com 2010-05-17 19:40
---
Many thanks. Let's add Jason in CC.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
--- Comment #6 from dodji at gcc dot gnu dot org 2010-05-17 19:45 ---
This should be fixed in trunk (4.6)
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from jason at gcc dot gnu dot org 2010-05-17 19:54 ---
Subject: Bug 44158
Author: jason
Date: Mon May 17 19:53:45 2010
New Revision: 159508
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159508
Log:
PR c++/44158
* call.c (build_over_call): Don't do
--- Comment #1 from jason at gcc dot gnu dot org 2010-05-17 19:54 ---
Subject: Bug 44157
Author: jason
Date: Mon May 17 19:53:55 2010
New Revision: 159509
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159509
Log:
PR c++/44157
* call.c (build_over_call): Limit in
contrib/dg-cmp-results.sh contains several unportabilities:
* sort -s seems to be specific to GNU sort, neither POSIX.1 nor the vendor
tools
on Solaris 2, IRIX 6 or Tru64 UNIX have it.
* sed support for EREs (via -r or -E) isn't present on those platforms either.
--
Summary: dg-cm
--- Comment #8 from janus at gcc dot gnu dot org 2010-05-17 19:59 ---
Subject: Bug 43990
Author: janus
Date: Mon May 17 19:58:48 2010
New Revision: 159511
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159511
Log:
2010-05-17 Janus Weil
PR fortran/43990
* tran
--- Comment #9 from janus at gcc dot gnu dot org 2010-05-17 20:05 ---
Fixed with r159511. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pedzsan at gmail dot com 2010-05-17 20:05 ---
The general reply to this was "your GCC was not compiled for your system".
That isn't the case. I have two compiles on two different systems. One if
version 4.5.0 and the other version is 4.3.1 compiled on AIX 5.3 TL05
--- Comment #3 from potswa at mac dot com 2010-05-17 20:10 ---
Created an attachment (id=20687)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20687&action=view)
recursive decltype crashes g++
fix minor error (no change in behavior)
--
potswa at mac dot com changed:
--- Comment #9 from pdimov at gmail dot com 2010-05-17 20:12 ---
But the standard says in [basic.types] that "For any trivially copyable type T,
if two pointers to T point to distinct T objects obj1 and obj2, where neither
obj1 nor obj2 is a base-class subobject, if the underlying bytes
System info: uname -a
CYGWIN_NT-5.1 harryr-pc 1.7.5(0.225/5/3) 2010-04-12 19:07 i686 Cygwin
gfortran -v
Using built-in specs.
Target: i686-pc-cygwin
Configured with:
/gnu/gcc/releases/packaging/4.3.4-3/gcc4-4.3.4-3/src/gcc-4.3.4/configure
--srcdir=/gnu/gcc/releases/packaging/4.3.4-3/gcc4-4.3.4-3/s
--- Comment #14 from iains at gcc dot gnu dot org 2010-05-17 20:22 ---
Created an attachment (id=20688)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20688&action=view)
Work-In-Progress...
here is a modification of comment #7 which gets us a bit further .. but I'm a
bit stumped in
--- Comment #7 from burnus at gcc dot gnu dot org 2010-05-17 20:22 ---
Propagate comment from PR 43990:
There seems to be an inconsistency with CLASS with POINTER
or ALLOCATABLE attribute: Is "class.$DATA" or "class" the pointer variable. If
one adds "b = ALLOCATED(x)" one finds:
x.a
--- Comment #5 from wilson at gcc dot gnu dot org 2010-05-17 20:24 ---
A little more debugging. I traced through the true_dependence call that is
returning 0 when it should return 1.
We end up calling rtx_refs_may_alias_p at the end. This calls
refs_may_alias_p_1, which calls indirect
--- Comment #8 from ro at gcc dot gnu dot org 2010-05-17 20:29 ---
Subject: Bug 44074
Author: ro
Date: Mon May 17 20:28:56 2010
New Revision: 159512
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159512
Log:
PR target/44074
* configure.ac (HAVE_AS_IX86_REP_LOCK_P
--- Comment #1 from kargl at gcc dot gnu dot org 2010-05-17 20:29 ---
Given this code
real foo(2) /2*0.0/
data foo/0.0, 0.0/
print *, foo
end
Trunk compiles the code. Gfortran 4.5 has the ICE.
troutmask:sgk[211] gfc4x -o z -Wall t.f90
troutmask:sgk[212] ./z
0.000
1 - 100 of 135 matches
Mail list logo
