--
falk at debian dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28015
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2006-06-15 06:39
---
> I don't understand the assertion, given that removing it seems to generate
> correct output for this test case. Since you edited this code not to long
> ago,
> do you have thoughts?
Not really. I've only lo
--- Comment #4 from bonzini at gnu dot org 2006-06-15 06:35 ---
Also, fixing this PR would allow us to ship Objective-C++ in the objc tarball.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27063
--- Comment #1 from paul dot richard dot thomas at cea dot fr 2006-06-15
06:33 ---
(In reply to comment #0)
According to section 4.5 of the Fortran95 standard:
"If the ac-value expressions are of type character, each ac-value expression in
the array-constructor shall have the same char
--- Comment #3 from bonzini at gnu dot org 2006-06-15 06:33 ---
I agree it is a packaging issue, but we can work around it and it can be useful
for other front ends as well. Taking the bug.
--
bonzini at gnu dot org changed:
What|Removed |Added
--
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-06-15 06:32
---
The error orginally came from:
2005-09-01 DJ Delorie <[EMAIL PROTECTED]>
* varasm.c (output_constant): Let the target resolve
conversions of addresses to non-default pointer sizes.
And then ther
--- Comment #25 from kspiteri at ieee dot org 2006-06-15 06:25 ---
In reply to comment #24:
> No it should not be. a() is a temporary so it cannot be bound to "a&". At
> least it should not be.
Then this is not a bug. The C++ standard in 27.6.2.1 defines
* basic_ostream& operator<<(co
--- Comment #9 from mmitchel at gcc dot gnu dot org 2006-06-15 06:25
---
Eric --
Here, valid_initializer_constant_p returns true -- but output_constant aborts,
saying:
/* Make sure eliminating the conversion is really a no-op, except with
VIEW_CONVERT_EXPRs to allow
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|mark at codesourcery dot com|unassigned at gcc dot gnu
|
--- Comment #7 from mmitchel at gcc dot gnu dot org 2006-06-15 06:01
---
Subject: Bug 27648
Author: mmitchel
Date: Thu Jun 15 06:00:49 2006
New Revision: 114672
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114672
Log:
PR c++/27648
* parser.c (cp_parser_declara
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-06-15 05:49
---
Subject: Bug 26559
Author: mmitchel
Date: Thu Jun 15 05:49:19 2006
New Revision: 114671
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114671
Log:
PR c++/26559
* pt.c (tsubst_expr): Use fin
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-06-15 05:29
---
Fixed in 4.1.2.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Assigned
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-06-15 05:29
---
Subject: Bug 26559
Author: mmitchel
Date: Thu Jun 15 05:29:25 2006
New Revision: 114670
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114670
Log:
PR c++/26559
* pt.c (value_dependent_expre
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-15 04:39 ---
Confirmed.
Or
#ifdef __ELF__
.section .note.GNU-stack,""
#endif
which is yanked from config/alpha/qrnnd.asm in GCC.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |A
I noticed (on ubuntu) that libgcj had an executable stack; tracing this back, I
found that libffi also had an executable stack, and why. pinskia informs me
that libffi gets linked into libgcj so that solves that!
SCANELF:
[EMAIL PROTECTED]:/tmp/x$ scanelf -qeRt /usr/lib
RWX --- --- /usr/lib/lib
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-06-15 04:00
---
Fixed in 4.2.0.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Summa
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-06-15 03:51
---
Subject: Bug 27665
Author: mmitchel
Date: Thu Jun 15 03:51:51 2006
New Revision: 114669
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114669
Log:
PR c++/27665
* parser.c (cp_parser_unquali
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-06-15 03:47
---
Fixed in 4.2.0.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Summa
--- Comment #10 from bangerth at dealii dot org 2006-06-15 03:45 ---
This problem persists with gcc4.1.x from 2006-06-13. I believe I get the
same glibc fault in one of my codes, which isn't particularly surprising
given that Volker used widely used std:: components in his program as wel
--- Comment #1 from mmitchel at gcc dot gnu dot org 2006-06-15 03:40
---
Subject: Bug 26748
Author: mmitchel
Date: Thu Jun 15 03:40:42 2006
New Revision: 114667
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114667
Log:
PR c++/26748
* parser.c (cp_parser_declara
--- Comment #16 from bangerth at dealii dot org 2006-06-15 03:39 ---
(In reply to comment #13)
> and the test case never exceeded 1 GB vm with r11. I would certainly hope
> that gcc would politely report vm exhaustion as out-of-memory or some such
> rather than segfaulting.
That, u
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-06-15 03:35
---
Fixed in 4.2.0.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Summa
--- Comment #2 from mmitchel at gcc dot gnu dot org 2006-06-15 03:26
---
Subject: Bug 26559
Author: mmitchel
Date: Thu Jun 15 03:26:38 2006
New Revision: 114665
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114665
Log:
2006-06-14 Mark Mitchell <[EMAIL PROTECTED]>
PR
--- Comment #11 from malitzke at metronets dot com 2006-06-15 03:03 ---
Hans-Peter!
Thanks for shedding _some_ light on this murky corner. Perhaps, the "i"
constraint is now really inapropriate.
First of all, a kernel header appropriately replaces __FUNCTION__ with
__func__. Therefore
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-06-15 01:51
---
John and I talked about this a bit more, and he's going to update the core
issue.
To me, there are only a few options here:
1. S::i has non-dependent type "int[]".
In that case, the sizeof expression is an error
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2006-06-15 01:31
---
Try changing the C to a !
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28032
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-06-15 00:27
---
John Spicer and I discussed this issue, but I don't think we've got a clear
resolution. John believes the example is valid.
However, I asked:
=
template void g();
template
struct S {
static int i[];
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-06-15 00:06
---
The problem here is with the parser optimization by which the results of
parsing a nested-name-specifier is cached, even if the parser backs up. Here,
we consider that "class A::B::C" might be a class-head. In th
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-06-14 22:17
---
I'm not convinced this is a bug in G++.
If the first line were:
template struct type_name { static char const name[1]; };
then there would be no question that the specialization was invalid. Since the
type
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--- Comment #5 from sje at cup dot hp dot com 2006-06-14 20:59 ---
Looking at this bug and PR 20076, I believe they are different bugs.
builtin-apply4.c fails on ia64-*-* even without the inline keyword and it is
inlining that the PR 20076 defect is about.
This problem (at least on ia6
--- Comment #2 from w dot northcott at unsw dot edu dot au 2006-06-14
20:28 ---
(In reply to comment #1)
> What problem did you see when ld wasn't in build_gcc?
collect2: cannot find ld
when trying to link cross-compilers.
This is not seen whn building on a fat library machine becau
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-06-14 19:28
---
Fixed in 4.2.0.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-06-14 19:18
---
Subject: Bug 28018
Author: mmitchel
Date: Wed Jun 14 19:18:45 2006
New Revision: 114653
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114653
Log:
PR c++/28018
* typeck.c (build_modify_expr
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-06-14 19:17
---
Fixedin 4.1.2.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedT
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-06-14 19:17
---
Subject: Bug 27227
Author: mmitchel
Date: Wed Jun 14 19:17:19 2006
New Revision: 114652
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114652
Log:
PR c++/27227
* decl.c (decls_match): Allow
--- Comment #11 from gerald at pfeifer dot com 2006-06-14 18:33 ---
Sorry for the delay, Paolo: do you think you could provide a patched
configure script for the new patch as well? Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26188
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Summary|section anchors break - |[4.2 Regre
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-06-14 18:24 ---
*** Bug 28033 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-14 18:24 ---
This was just fixed and this is a dup of bug 28008.
*** This bug has been marked as a duplicate of 28008 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
Section anchors have broken profile data on powerpc*-linux; the problems
described here started with this mainline patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=113395
r113395 | dje | 2006-04-30 19:23:13 + (Sun, 30 Apr 2006)
Tests mesa, gap, and perlbmk in SPEC CPU2000 fail when com
Today's CVS:
mushroom:...src>uname -a
SunOS mushroom 5.7 Generic_106541-19 sun4u sparc SUNW,Ultra-2
mushroom:...src>g++ -v
Using built-in specs.
Target: sparc-sun-solaris2.7
Configured with: /mnt/home3/utilities/gcc/configure
--prefix=/mnt/home3/utilities --verbose --with-as=/mnt/home3/utilitie
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-06-14 17:50
---
Fixed in 4.2.0.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Summa
--- Comment #3 from tromey at gcc dot gnu dot org 2006-06-14 17:48 ---
I haven't looked at this since my last comment.
Your workaround is fine, you didn't break anything.
A real fix would have to work differently though.
Perhaps we should always compile these functions but just
have th
--- Comment #2 from mmitchel at gcc dot gnu dot org 2006-06-14 17:44
---
Subject: Bug 27227
Author: mmitchel
Date: Wed Jun 14 17:44:36 2006
New Revision: 114647
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114647
Log:
PR c++/27227
* decl.c (decls_match): Allow
--- Comment #1 from mrs at apple dot com 2006-06-14 17:11 ---
What problem did you see when ld wasn't in build_gcc?
Also, if the compiler is configured with isysroot, if gcc.c is taught to
default to using it, then I think the change to configure.ac isn't needed.
This also helps with p
--- Comment #3 from patchapp at dberlin dot org 2006-06-14 17:00 ---
Subject: Bug number PR28005
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00747.html
--
http://gcc.gnu.org/bugzilla/sh
The test gfortran.dg/secnds.f starts with:
C { dg-do run }
C { dg-options "-O0" }
But the test is run with -O0, -O1, -O2, etc options.
My guess is that dejagnu is not recognizing the dg-options setting because the
lines starts with a 'C' and not a more C/C++ like comment.
--
Summar
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-14 16:53 ---
This was caused by:
2006-05-24 Mark Mitchell <[EMAIL PROTECTED]>
PR c++/20103
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28031
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-14 16:52 ---
Here is a reduced testcase:
typedef struct terror_struct {int c; } terror;
int main(void)
{
terror e;
switch(1)
{
case 1:
e = (terror){400};
case 2:
break;
}
}
--
http://gcc.gnu.org/bugzilla/
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-14 16:49 ---
This is caused by the C99 initializer extension to C++.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
I'm pretty sure the following error is bogus. I don't see anything invalid in
this test case and it worked with g++ 4.1. It also works with gcc 4.2 20060419
but not with the current version.
(sid)1053:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c test.c
test.c: In function 'int main()':
--- Comment #6 from greed at pobox dot com 2006-06-14 15:37 ---
I am building from the gcc-4.1.1.tar.bz2 tarball downloaded from the
ftp.gnu.org server. I have this problem on systems without texinfo as well.
The problem is caused because, as of 4.1.0, fastjar requires a "gcc-vers.texi
--- Comment #24 from pinskia at gcc dot gnu dot org 2006-06-14 15:30
---
(In reply to comment #23)
> Instead, the output is:
> char
> void
No it should not be. a() is a temporary so it cannot be bound to "a&". At
least it should not be.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #23 from kspiteri at ieee dot org 2006-06-14 15:28 ---
The test case in attachment 11669 shows that this bug has nothing to do with
ostreams. The output from the test case should be:
char
char
Instead, the output is:
char
void
--
kspiteri at ieee dot org changed:
--- Comment #5 from pinskia at physics dot uc dot edu 2006-06-14 15:25
---
Subject: Re: [4.2 Regression] build failure due to PTHREAD_STACK_MIN not being
declared
On Jun 14, 2006, at 8:17 AM, rth at gcc dot gnu dot org wrote:
> --- Comment #2 from rth at gcc dot gnu dot org 200
On Jun 14, 2006, at 8:17 AM, rth at gcc dot gnu dot org wrote:
--- Comment #2 from rth at gcc dot gnu dot org 2006-06-14
15:17 ---
libgomp is a new feature, and therefore has no "regressions" per se,
and therefore any bug fix applies.
That does not matter. Please read Mark's email
--- Comment #22 from kspiteri at ieee dot org 2006-06-14 15:24 ---
Created an attachment (id=11669)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11669&action=view)
Minimal test case.
Test case showing bug is independant of ostreams.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #4 from rth at gcc dot gnu dot org 2006-06-14 15:20 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from rth at gcc dot gnu dot org 2006-06-14 15:20 ---
Subject: Bug 28008
Author: rth
Date: Wed Jun 14 15:20:01 2006
New Revision: 114643
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114643
Log:
PR libgomp/28008
* env.c (initialize_env): Avoid usin
--- Comment #2 from rth at gcc dot gnu dot org 2006-06-14 15:17 ---
libgomp is a new feature, and therefore has no "regressions" per se,
and therefore any bug fix applies. The problem report from llnl can
be legitimately considered a bug.
--
rth at gcc dot gnu dot org changed:
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-14 15:09 ---
I doubt this has anything to do with templates and more to do with the aliasing
info about the the load of this->size_ .
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |hp at gcc dot gnu dot org
|dot org |
--- Comment #10 from hp at gcc dot gnu dot org 2006-06-14 15:08 ---
I can't help but thinking the code is valid and that this is a valid bug.
Arguably, it *might* be hard to fix, and we'll have to cop out and adjust the
documentation instead.
I mean, the "i" constraint purpose is documen
The following code only gets vectorized with explicitly copying the "size_"
member to the local "sz" variable for 4.1.1, 4.2.0 rev. 114610 and autovect
branch.
=
template
class vec
{
public:
vec& multiply(const vec& other)
{
// do something to
--- Comment #7 from sayle at gcc dot gnu dot org 2006-06-14 14:46 ---
Subject: Bug 27858
Author: sayle
Date: Wed Jun 14 14:46:33 2006
New Revision: 114642
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114642
Log:
PR target/27858
Revert incorrect fix for PR targ
--- Comment #21 from sayle at gcc dot gnu dot org 2006-06-14 14:46 ---
Subject: Bug 27158
Author: sayle
Date: Wed Jun 14 14:46:33 2006
New Revision: 114642
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114642
Log:
PR target/27858
Revert incorrect fix for PR tar
--- Comment #20 from sayle at gcc dot gnu dot org 2006-06-14 14:43 ---
Subject: Bug 27158
Author: sayle
Date: Wed Jun 14 14:43:49 2006
New Revision: 114641
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114641
Log:
PR target/27158
* config/rs6000/rs6000.c (const
--- Comment #13 from pault at gcc dot gnu dot org 2006-06-14 14:26 ---
This, of course, was fixed on both trunk and 4.1.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from krebbel at gcc dot gnu dot org 2006-06-14 14:22 ---
Patch committed to mainline and gcc 4.1 branch.
--
krebbel at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from krebbel at gcc dot gnu dot org 2006-06-14 14:20 ---
Subject: Bug 27959
Author: krebbel
Date: Wed Jun 14 14:19:54 2006
New Revision: 114640
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114640
Log:
2006-06-14 Andreas Krebbel <[EMAIL PROTECTED]>
PR
--- Comment #2 from WILLIAMPAUL dot PHILIBERT at telus dot com 2006-06-14
14:12 ---
Subject: RE: Found a problem with the JNI methods declared and implemented
Do you have any development concerning this bug?
I did modify the code so it does not do the checking and it works fine but d
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-14 14:05 ---
The code is basicially the same as:
void multiply(float *data_, const float *op, unsigned int size_)
{
for (unsigned int i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=28029
--- Comment #5 from tromey at gcc dot gnu dot org 2006-06-14 14:00 ---
Thanks for the report.
I fixed this problem. But, as I don't have a Solaris box,
I can't test whether this means that the build works.
Please update and try again :)
--
tromey at gcc dot gnu dot org changed:
--- Comment #4 from tromey at gcc dot gnu dot org 2006-06-14 13:56 ---
Subject: Bug 28024
Author: tromey
Date: Wed Jun 14 13:56:22 2006
New Revision: 114639
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114639
Log:
PR java/28024:
* aclocal.m4, configure: Rebuilt
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-14 13:55 ---
Actually I think this is wrong code with 4.1.x.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28029
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-14 13:48 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
The following short testcase gets vectorized with 4.1.1 and doesn't with 4.2.0
revision 114610
template
class vec
{
public:
vec(unsigned int n) : size_(n)
{
data_ = new T[n];
}
vec& multiply(const vec& other)
{
--- Comment #3 from tromey at gcc dot gnu dot org 2006-06-14 13:46 ---
Subject: Bug 28024
Author: tromey
Date: Wed Jun 14 13:46:33 2006
New Revision: 114637
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114637
Log:
PR java/28024:
* aclocal.m4, configure: Rebuilt
--- Comment #2 from cvs-commit at developer dot classpath dot org
2006-06-14 12:42 ---
Subject: Bug 28024
CVSROOT:/cvsroot/classpath
Module name:classpath
Changes by: Tom Tromey 06/06/14 12:35:17
Modified files:
. : ChangeLog configure.ac
--- Comment #1 from tromey at gcc dot gnu dot org 2006-06-14 12:28 ---
Looks like classpath's configure uses the $(...) construct.
This isn't portable sh.
The fix is to replace with `...`
--
tromey at gcc dot gnu dot org changed:
What|Removed |Adde
--- Comment #2 from schwab at suse dot de 2006-06-14 11:13 ---
The expression the controls conditional inclusion shall be an integer constant
expression (6.10.1.1), which shall not contain comma operators (6.6.3).
--
schwab at suse dot de changed:
What|Removed
--- Comment #5 from micis at gmx dot de 2006-06-14 11:12 ---
I get a similar ICE with gcc-4.2-20060610 using the following command line:
g++42p -O1 -g -ftree-vectorize -ftree-vectorizer-verbose=5 -S source.ii
Program received signal SIGSEGV, Segmentation fault.
0x003d1cd6f1e0 in str
--- Comment #1 from joseph at codesourcery dot com 2006-06-14 11:03 ---
Subject: Re: New: Incorrect pedwarn for , expression
in #if in c99 mode
On Wed, 14 Jun 2006, sabre at nondot dot org wrote:
> This testcase:
>
> #if 1 , 0
> #endif
>
> Should not warn with -std=c99 -pedantic.
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-06-14
10:28 ---
Created an attachment (id=11668)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11668&action=view)
Development fix to the PR
Tobias,
I have fixed the problem for integer_4; I do not have the time t
--- Comment #4 from krebbel at gcc dot gnu dot org 2006-06-14 09:24 ---
Subject: Bug 27959
Author: krebbel
Date: Wed Jun 14 09:24:44 2006
New Revision: 114636
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114636
Log:
2006-06-14 Andreas Krebbel <[EMAIL PROTECTED]>
PR
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de
2006-06-14 09:17 ---
Paul,
> I presented a patch for this problem and for detected unassigned r-values that
> was rejected. I don't know what to say; I think that it's a bug, in
> principle,
> but the standard does n
This primarily affect Apple's gcc-5xxx but some of the issues are also in code
which is part of FSF gcc-4.x.x. There may be some connection with PR 26814.
The symptom is that building i386 hosted or i386 target compilers on powerpc
Darwin using the SDK fails. The problems would probably also aff
$ cat t.cc
class BaseSubmit
{
template friend class PeriodicSubmit;
};
template
class ValuesSubmit
{
template friend class PeriodicSubmit;
};
class A;
class MultiSubmit : public ValuesSubmit
{
};
$ g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /tools/inst/gcc-4
New bootstrap build:
SunOS vs1 5.8 Generic_108528-29 sun4u sparc SUNW,Ultra-Enterprise
../gcc-4.1.1/configure --prefix=/opt --with-local-prefix=/opt/include
--with-cpu=ultrasparc
make -j CFLAGS='-O2' LIBCFLAGS='-O2' LIBCXXFLAGS='-O2 -fno-implicit-templates'
bootstrap
Well into the overall build
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-06-14 07:57 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
The default value of max-inline-recursive-depth is 8 in the implementation. The
documentation differs, there the default value is 450.
--
Summary: documentation error max-inline-recursive-depth
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
--- Comment #4 from happyarch at gmail dot com 2006-06-14 07:03 ---
boostjam get segfault to build boost with gcc-4.2
> pwd
/home/keti/download/boost_1_33_1
>
> make
./tools/build/jam_src/bin.linuxx86/bjam -sPYTHON_ROOT=/usr -sPYTHON_VERSION=2.4
-sTOOLS=gcc
/bin/sh: line 1: 27533
96 matches
Mail list logo
