Hello everyone,
I am struggling to build h8300 crosscompiler from GCC4.4.0.
I learned it is necessary to patch gcc for complying to double 64 bits.
I used next sources.
binutils-2.19.1.tar.bz2
gcc-4.4.0.tar.bz2
newlib-1.17.0.tar.gz
I've got patch for GCC3.3.2 source.
I appended it in
Concepts have recently been removed from the C++0x Standard Draft.
Will the concepts branch be discontinued?
On Tue, Jul 28, 2009 at 3:01 AM, Piotr Wyderskipiotr.wyder...@gmail.com wrote:
Concepts have recently been removed from the C++0x Standard Draft.
Will the concepts branch be discontinued?
I hope not. Concepts will be finished and re-added to C++, and it
would be immensely helpful in that
Thanks David.
I thought -mmininal-toc might have been a better workaround as well :-) .
Is there a Bugzilla number for this issue?
-Original Message-
From: David Edelsohn [mailto:dje@gmail.com]
Sent: Tuesday, July 28, 2009 9:46 AM
To: Tim Crook
Subject: Re: How to figure out the
James Dennett wrote:
On Tue, Jul 28, 2009 at 3:01 AM, Piotr Wyderskipiotr.wyder...@gmail.com wrote:
Concepts have recently been removed from the C++0x Standard Draft.
Will the concepts branch be discontinued?
I hope not. Concepts will be finished and re-added to C++, and it
would be
On Tue, Jul 28, 2009 at 10:44 AM, Tim Crooktcr...@adobe.com wrote:
Thanks David.
I thought -mmininal-toc might have been a better workaround as well :-) .
Is there a Bugzilla number for this issue?
I believe this was GCC Bugzilla Bug 24779. It partially was fixed in
GCC 4.1, but not fully
Ed Smith-Rowland wrote:
James Dennett wrote:
On Tue, Jul 28, 2009 at 3:01 AM, Piotr
Wyderskipiotr.wyder...@gmail.com wrote:
Concepts have recently been removed from the C++0x Standard Draft.
Will the concepts branch be discontinued?
I hope not. Concepts will be finished and re-added
struct cgraph_edge *edge = cgraph_edge (id-src_node,
orig_stmt);
POINT_A
int flags;
switch (id-transform_call_graph_edges)
{
case CB_CGE_DUPLICATE:
if (edge)
On 07/28/2009 10:16 AM, Jan Hubicka wrote:
There is code in cgraph_copy_node_for_versioning that redirect callers
in the list to new location. Since clonning might render some code
unreachable and remove edges, this can lead to ICE. But since this
was formely invented for IPA-CP, that is now
Apologies if you receive multiple copies of this call.
CALL FOR PAPERS
2nd Workshop on
GCC Research Opportunities
2009/7/28 Basile STARYNKEVITCH:
It could perhaps be not a branch, but a plugin, but I know not much about
C++ concepts, and absolutely nothing about the existing C++ concepts
branch[es].
I don't think that would work - the standard library changes that go
along with the language feature could
Snapshot gcc-4.4-20090728 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090728/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On 07/28/2009 10:44 AM, Richard Henderson wrote:
I guess I'll poke at cleaning this up today. I've got to
familiarize myself with how virtual clones work...
The virtual clones that ipa-cp makes seems to be easy.
My thought here is that since (virtual) clones don't
have actual bodies (and when
On s390x it produces this insn:
(insn 8 7 9 3 323444.c:15 (set (mem/s:DI (reg:DI 46) [0 S8 A64])
(mem/s:DI (reg/v/f:DI 45 [ tp ]) [0 S8 A64])) -1 (nil))
Note that the alignments are 64 bit again, despite the field being
packed. mep-elf has similar results.
void *memcpy(void *dest,
--- Comment #5 from bmerry at gmail dot com 2009-07-28 07:28 ---
Thanks, I wasn't aware of that. It's slightly annoying that the behaviour is
different from glibc (I use -std=c89 so that the compiler keeps me honest,
since I'm working on code that has to compile on compilers that still
--- Comment #42 from jv244 at cam dot ac dot uk 2009-07-28 07:37 ---
another issue I found is this:
gfortran -fwhole-file test.f90
/tmp/cciOiaMB.o: In function `__m_MOD_b':
test.f90:(.text+0xa): undefined reference to `c_'
collect2: ld returned 1 exit status
cat test.f90
SUBROUTINE
--- Comment #2 from aph at gcc dot gnu dot org 2009-07-28 08:02 ---
This is actually a regression in debuginfo: the line number info is being
corrupted, somewhere after the front end. I don't know if this was caused by
the gimplify unit-at-a-time patch.
--
aph at gcc dot gnu dot
--- Comment #41 from irar at il dot ibm dot com 2009-07-28 08:12 ---
That requires pattern recognition. MIN/MAX_EXPR are recognized by the first
phiopt pass, so MIN/MAXLOC should be either also recognized there or in the
vectorizer. (The phiopt pass transforms if clause to MIN/MAX_EXPR.
--- Comment #2 from ramana at gcc dot gnu dot org 2009-07-28 08:29 ---
(In reply to comment #0)
Consider the following code:
int (*indirect_func)();
int indirect_call()
{
return indirect_func();
}
gcc 4.4.0 generates the following with -O2 -mcpu=cortex-a8 -S:
--- Comment #1 from burnus at gcc dot gnu dot org 2009-07-28 08:33 ---
In a similar vain: One could introduct an option to disable warning for the
deleted features (such as using real-valued loops) - currently, those warnings
alre always printed, hiding other warnings in all the output.
--- Comment #3 from lessen42+gcc at gmail dot com 2009-07-28 08:45 ---
(In reply to comment #2)
The point made is correct but there is something you've missed in your patch !
loading lr with the address of the function you want to call, destroys the
return address ,- so your code is
--- Comment #13 from tkoenig at gcc dot gnu dot org 2009-07-28 09:04
---
Still missing in intrinsics (at least as far as
grep -L bounds `grep -l gfc_array *.c` tells me):
associated.c
date_and_time.c
dtime.c
etime.c
iso_c_binding.c
move_alloc.c
random.c
stat.c
unpack_generic.c
--- Comment #14 from burnus at gcc dot gnu dot org 2009-07-28 09:57 ---
(In reply to comment #13)
Still missing in intrinsics (at least as far as
For those which have one-dimensional arrays, one should consider adding the
checks in trans*.c as this is faster for the non -fcheck=bounds
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-28 11:09 ---
The tree optimizers canonicalize the loop to
bb 3:
# i_5 = PHI i_3(4), 0(2)
# ivtmp.23_1 = PHI ivtmp.23_4(4), 10(2)
f2 ();
i_3 = i_5 + 1;
ivtmp.23_4 = ivtmp.23_1 - 1;
if (ivtmp.23_4 != 0)
goto bb 4;
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-07-28 11:22 ---
After early SRA we get
f$x_8 = g;
D.2142_6 = f$x_8;
D.2141_7 = D.2142_6 (3);
which now misses a constant propagation of g into the call which is why
inlining doesn't catch this opportunity. Put one in and
--- Comment #2 from per at bitempire dot com 2009-07-28 11:23 ---
Sorry, you're right - it works fine with gcc 4.3 and later. I must have
accidentally linked to libgomp 4.2 which is a part of llvm-gcc.
I apologize for the inconvenience.
--
per at bitempire dot com changed:
--- Comment #2 from janus at gcc dot gnu dot org 2009-07-28 11:40 ---
Subject: Bug 40882
Author: janus
Date: Tue Jul 28 11:40:42 2009
New Revision: 150154
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150154
Log:
2009-07-28 Janus Weil ja...@gcc.gnu.org
PR
When trying to use gcj -C instead of a symlink to ecj as gcj's javac (with
options appropriately changed with a script), I ran across an interesting issue
building OpenJDK:
gcj -C -g -d lib/hotspot-tools -fsource=1.5
--- Comment #17 from joseph at codesourcery dot com 2009-07-28 11:55
---
Subject: Re: String not extracted for translation
On Mon, 27 Jul 2009, manu at gcc dot gnu dot org wrote:
--- Comment #3 from manu at gcc dot gnu dot org 2009-07-27 16:55 ---
(In reply to comment #2)
--- Comment #4 from ramana at gcc dot gnu dot org 2009-07-28 12:09 ---
(In reply to comment #3)
(In reply to comment #2)
The point made is correct but there is something you've missed in your
patch !
loading lr with the address of the function you want to call, destroys the
--- Comment #3 from janus at gcc dot gnu dot org 2009-07-28 12:14 ---
Fixed with r150154. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jakub at gcc dot gnu dot org 2009-07-28 12:20 ---
I certainly can't reproduce any kind of segfault with this.
And, it is unclear to me whether this restriction (why it is there at all,
doesn't make much sense) is meant just for statement functions referenced
within
--- Comment #3 from dodji at gcc dot gnu dot org 2009-07-28 12:39 ---
Subject: Re: New: namespaces represented incorrectly in
debug_pubnames
Patch submitted to http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01579.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39706
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-28 13:12 ---
We have the following cgraph nodes related to daxpy:
daxpy/17(-1) @0x75fc8700
called by: dgesl/3 (1.00 per call) dgesl/3 (1.00 per call)
calls:
dgefa/7(7) @0x75f7b100 174 time, 45 benefit 138 size, 36
--- Comment #5 from jamborm at gcc dot gnu dot org 2009-07-28 13:28 ---
Honza, unless there are any new problems, can you commit the patch? Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40759
--- Comment #4 from janus at gcc dot gnu dot org 2009-07-28 13:31 ---
Fixed with r150134. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
/home/rainer/software/build/i686-pc-mingw32/gcc-4.5.0/gcc/./prev-gcc/xgcc
-B/home/rainer/software/build/i686-pc-mingw32/gcc-4.5.0/gcc/./prev-gcc/
-B/mingw/gcc/gcc-4.5.0/i686-pc-mingw32/mingw/i686-pc-mingw32/bin/
--- Comment #2 from longb at cray dot com 2009-07-28 13:47 ---
The text at [75:19-20] of the OpenMP 2.5 standard, May 2008, says:
Variables that appear in namelist statements, in variable format expressions,
and in Fortran expressions for statement function definitions, may not appear
Revision 150143:
http://gcc.gnu.org/ml/gcc-cvs/2009-07/msg01026.html
caused:
FAIL: gcc.dg/cdce1.c scan-tree-dump cdce cdce1.c:16: note: function call is
shrink-wrapped into error conditions.
FAIL: gcc.dg/cdce2.c scan-tree-dump cdce cdce2.c:16: note: function call is
shrink-wrapped into error
--- Comment #1 from jwakely dot gcc at gmail dot com 2009-07-28 14:04
---
You didn't say how you configured the build, but you might want to use
something like:
--with-host-libstdcxx='/usr/local/gcc-4.4/lib/libstdc++.a -lm'
as documented at http://gcc.gnu.org/install/configure.html
--- Comment #5 from mans at mansr dot com 2009-07-28 14:24 ---
Just to be clear, this bug report is about *all* calls through function
pointers. PR19599 only mentions a failed tail-call optimisation. That the
example in this bug would benefit from this optimisation is secondary.
I
--- Comment #3 from jv244 at cam dot ac dot uk 2009-07-28 14:34 ---
(In reply to comment #1)
I certainly can't reproduce any kind of segfault with this.
It could be that it segfaults for Bill because 'ftn' adds -static to the
compiler options, but doesn't link libpthread with
--- Comment #4 from burnus at gcc dot gnu dot org 2009-07-28 14:43 ---
(In reply to comment #1)
I certainly can't reproduce any kind of segfault with this.
Neither can I. Regarding both examples (comment 0 and comment 1), ifort 11.1
happily accepts both.
I am not sure whether it is
--- Comment #1 from gandalf at gcc dot gnu dot org 2009-07-28 15:08 ---
Subject: Bug 40616
Author: gandalf
Date: Tue Jul 28 15:08:12 2009
New Revision: 150161
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150161
Log:
Fix for PR40616: missing java.io.PrintStream constructors.
--- Comment #2 from gnu_andrew at member dot fsf dot org 2009-07-28 15:09
---
Fixed with above commit.
--
gnu_andrew at member dot fsf dot org changed:
What|Removed |Added
cp/error.c:maybe_warn_cpp0x takes a string that is an English language
fragment and inserts it into a sentence for a diagnostic; the string in
question is neither translated nor extracted for gcc.pot. Whole sentences
should be used for diagnostics; either pass an enum to this function
rather than
--- Comment #1 from jakub at gcc dot gnu dot org 2009-07-28 16:10 ---
Subject: Bug 40891
Author: jakub
Date: Tue Jul 28 16:09:58 2009
New Revision: 150163
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150163
Log:
PR testsuite/40891
* gcc.dg/cdce1.c: Adjust note
--- Comment #2 from jakub at gcc dot gnu dot org 2009-07-28 16:11 ---
Subject: Bug 40891
Author: jakub
Date: Tue Jul 28 16:11:21 2009
New Revision: 150164
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150164
Log:
PR testsuite/40891
* gcc.dg/cdce1.c: Adjust note
--- Comment #1 from jakub at gcc dot gnu dot org 2009-07-28 16:16 ---
Subject: Bug 40878
Author: jakub
Date: Tue Jul 28 16:15:47 2009
New Revision: 150165
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150165
Log:
PR fortran/40878
* openmp.c
--- Comment #2 from dominiq at lps dot ens dot fr 2009-07-28 16:21 ---
Could somone check if this pr has not been fixed (hidden) by some recent
changes? It works on powerpc-apple-darwin9 at revision 150097 (it did not work
on i686-apple-darwin9 at this revision) on i686-apple-darwin9 at
--- Comment #3 from jakub at gcc dot gnu dot org 2009-07-28 16:21 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
Consider the following C code:
#include inttypes.h
void dct2x2dc_dconly( int16_t d[2][2] )
{
int d0 = d[0][0] + d[0][1];
int d1 = d[1][0] + d[1][1];
d[0][0] = d0 + d1;
d[0][1] = d0 - d1;
}
The following is generated with arm-none-linux-gnueabi-gcc-4.4.0 -O3
-mcpu=cortex-a8 -S
--- Comment #2 from jakub at gcc dot gnu dot org 2009-07-28 16:33 ---
Subject: Bug 40878
Author: jakub
Date: Tue Jul 28 16:33:08 2009
New Revision: 150167
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150167
Log:
PR fortran/40878
* openmp.c
--- Comment #3 from jakub at gcc dot gnu dot org 2009-07-28 16:34 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from hubicka at gcc dot gnu dot org 2009-07-28 16:38 ---
Subject: Bug 40759
Author: hubicka
Date: Tue Jul 28 16:37:50 2009
New Revision: 150168
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150168
Log:
PR tree-optimization/40759
* tree-ssa-dce.c
--- Comment #7 from hjl at gcc dot gnu dot org 2009-07-28 16:51 ---
Subject: Bug 40822
Author: hjl
Date: Tue Jul 28 16:51:19 2009
New Revision: 150169
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150169
Log:
2009-07-28 H.J. Lu hongjiu...@intel.com
Backport from
--- Comment #5 from hjl at gcc dot gnu dot org 2009-07-28 16:51 ---
Subject: Bug 40848
Author: hjl
Date: Tue Jul 28 16:51:19 2009
New Revision: 150169
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150169
Log:
2009-07-28 H.J. Lu hongjiu...@intel.com
Backport from
--- Comment #2 from hjl at gcc dot gnu dot org 2009-07-28 16:51 ---
Subject: Bug 40829
Author: hjl
Date: Tue Jul 28 16:51:19 2009
New Revision: 150169
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150169
Log:
2009-07-28 H.J. Lu hongjiu...@intel.com
Backport from
--- Comment #7 from htl10 at users dot sourceforge dot net 2009-07-28
17:53 ---
I probably have a similiar bug about length of commend line with 4.4.1 which I
shall file now.
--
htl10 at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #8 from htl10 at users dot sourceforge dot net 2009-07-28
18:06 ---
I have a slightly different message on alphaev68-dec-osf5.1a with gcc 4.4.1,
but possibly the same problem: (I can bootstrap 4.3.3, but no luck with
4.4.0/4.4.1):
find
--- Comment #3 from burnus at gcc dot gnu dot org 2009-07-28 18:09 ---
Could somone check if this pr has not been fixed (hidden) by some recent
changes? It works on powerpc-apple-darwin9 at revision 150097 (it did not work
on i686-apple-darwin9 at this revision) on i686-apple-darwin9
--- Comment #2 from hjl dot tools at gmail dot com 2009-07-28 18:12 ---
Shouldn't test_summary remove ^M? when sending out emails?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40704
--- Comment #1 from rainer at emrich-ebersheim dot de 2009-07-28 18:28
---
Doesn't reproduce, please close as invalid.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40890
make bootstrap4-lean failed with 4.4.0 and 4.4.1 with crtfastmath.o comparison.
The last gcc version I can make bootstrap4-lean was 4.3.3 (and before that,
4.3.1) which was what I tried building 4.4.x with.
Strangely make (which I understand do a 3 stage boostrap) doesn't have this
problem, but
--- Comment #6 from dave at boost-consulting dot com 2009-07-28 18:42
---
The next step would be to verify that the penalty is eliminated when using
boost::function / tr1::function
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40874
--- Comment #4 from hjl dot tools at gmail dot com 2009-07-28 18:58 ---
It still fails on Linux/ia64.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #7 from paolo dot carlini at oracle dot com 2009-07-28 19:38
---
One step at a time, Dave ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40874
--- Comment #3 from ubizjak at gmail dot com 2009-07-28 20:01 ---
What about using ^ and $ throughout the testsuite instead of inventing regular
expressions involving \n and \r in all possible combinations (i.e. (\n|\r\n|\r)
)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40704
With G++ 4.3.3 and 4.4.0 from Ubuntu Jaunty, I get:
ice.cpp: In instantiation of âs0â:
ice.cpp:19: instantiated from here
ice.cpp:14: internal compiler error: in tsubst, at cp/pt.c:9687
from this test program:
int foo(int x, ...);
templateint x
int bar()
{
return 0;
}
templateint
--- Comment #6 from jamborm at gcc dot gnu dot org 2009-07-28 20:14 ---
When I move e-inline_failed = CIF_OK in cgraph_mark_inline_edge()
until after call to cgraph_clone_inlined_nodes(), the endless
recursion goes away. However, I now get an assert in
--- Comment #9 from htl10 at users dot sourceforge dot net 2009-07-28
20:30 ---
Sorry for the noise - the 'find: bad option -path' error message of mine is
genuine - gcc 4.4 (classpath) requires GNU findutils syntax which doesn't work
with DEC/Tru64 find. Am filing a separate bug now.
--- Comment #1 from paolo dot carlini at oracle dot com 2009-07-28 20:36
---
Already fixed in 4.4.1.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #10 from htl10 at users dot sourceforge dot net 2009-07-28
20:42 ---
The 'find bad option' problem was already reported for solaris as bug 38715 .
just FYI.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38251
--- Comment #7 from jamborm at gcc dot gnu dot org 2009-07-28 20:59 ---
Ha, please disregard the previous message, obviously I had to make a
fool out of myself before realizing that loops in the inlining plan
are the bug, not how we handle them.
The reason there are such loops is that
I currently am keeping the Haiku operating system up to date with GCC 4.4 and
trunk, with plans of eventually getting the code for our GCC port committed
into GCC's repository.
I was keeping up to date by doing builds periodically based on 4.4 snapshots,
and assumed all would be well when 4.4.1
--- Comment #8 from jamborm at gcc dot gnu dot org 2009-07-28 21:33 ---
I can confirm that if we schedule pass_ccp right after pass_sra_early,
g gets inlined. Moreover, if we schedule one more pass_forwprop right
afterwards, even the testcase for PR 3713, comment #12 gets optimized
as
--- Comment #3 from rmh at gcc dot gnu dot org 2009-07-28 22:11 ---
ping
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40191
--- Comment #1 from lessen42+gcc at gmail dot com 2009-07-28 22:27 ---
More specifically, on x86_64 the following is generated with gcc-4.4 -O3
-march=core2 -S
_dct2x2dc_dconly:
movswl 2(%rdi),%edx
pushq %rbp
addw(%rdi), %dx
movswl 6(%rdi),%eax
The following code fails to compile:
std::tr1::shared_ptrconst sbuild::chroot_facet_session psess;
psess = this-chroot-get_facetsbuild::chroot_facet_session();
However, this code compiles without error:
std::tr1::shared_ptrconst sbuild::chroot_facet_session psess;
psess =
--- Comment #12 from htl10 at users dot sourceforge dot net 2009-07-28
22:49 ---
Still broken with 4.3.1, with alphaev68-dec-osf5.1a -
http://gcc.gnu.org/ml/gcc-testresults/2008-08/msg02507.html
Am about to submit the testsuite result for 4.3.3 and 4.4.1, and I think the
result is
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-07-28 22:51 ---
Does:
psess = this-chroot-template get_facetsbuild::chroot_facet_session();
make it work? Is the class where you use this a template?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40897
--- Comment #2 from rleigh at debian dot org 2009-07-28 23:00 ---
Yes, the class for the this pointer is a template:
template class T
class test_chroot_base : public TestFixture
Adding template as you suggest
psess = this-chroot-template get_facetsbuild::chroot_facet_session();
--- Comment #3 from rleigh at debian dot org 2009-07-28 23:02 ---
Created an attachment (id=18262)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18262action=view)
Preprocessed source for g++-4.3.3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40897
--- Comment #4 from rleigh at debian dot org 2009-07-28 23:02 ---
Created an attachment (id=18263)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18263action=view)
Preprocessed source for g++-4.4.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40897
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-07-28 23:03 ---
If it is getting you an internal error, then it is usually it is because the
attachments are too big.
As for the other issue, there is a C++ defect report about this case, which
consider this as dependent but a
--- Comment #6 from rleigh at debian dot org 2009-07-28 23:03 ---
Created an attachment (id=18264)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18264action=view)
Preprocessed source for g++-4.5.0 (svn 149777)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40897
--- Comment #7 from rleigh at debian dot org 2009-07-28 23:15 ---
Ah, so it's a defect in the actual C++ standard rather than GCC?
I was somewhat confused because while this fails:
psess = this-chroot-get_facetsbuild::chroot_facet_session();
splitting it into its component parts
--- Comment #1 from danglin at gcc dot gnu dot org 2009-07-29 01:29 ---
Introduced in revision 147980 (SRA).
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from mckelvey at maskull dot com 2009-07-29 01:47 ---
(In reply to comment #3)
Created an attachment (id=18254)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18254action=view) [edit]
patch to fix the failure
This patch fixes the failure on x86_64 - alpha
--- Comment #1 from spop at gcc dot gnu dot org 2009-07-29 04:11 ---
Hi,
From what I read this has nothing to do with Graphite. Could you
please reduce the bug using ideas from:
http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction
I am using to compile everything with a working
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2009-07-29 04:40
---
Created an attachment (id=18265)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18265action=view)
A simple patch to resolve the problem
This patch solves the original test case. It does require modification
91 matches
Mail list logo
