On Apr 1, 2007, at 10:42 PM, Joe Buck wrote:
On Sun, Apr 01, 2007 at 02:20:10PM +0200, Marcin Dalecki wrote:
Wiadomość napisana w dniu 2007-04-01, o godz13:58, przez Paul
Brook:
If you're already switching compilers, moving to an already
obsolete release
(3.3) seems a strange choice. At
Hi Murali/Everybody
1: I am keen on understanding how does the offset of L32 from
_GLOBAL_OFFSET_TABLE_ generated ? I mean if assembly is
Movl [EMAIL PROTECTED](%ebx,%eax),%eax then how does is gets converted to mov
0xbd14(%eax,%ebx,1),%eax. I guessed that L32 is at start of .rodata
hi
if not for the real compiler as such, what advantages would i get on using
newer glibc, libstdc++ ??
would these features be tied to some kernel version linux-2.4 vs 2.6 (
something like thread support).
thanks
ganesh
- Original Message
From: Chris Lattner [EMAIL PROTECTED]
To:
I have for a while been working on a tool that performs static analysis
of exception propagation through C/C++ code. It is very close to
complete (I estimate the first release within the month).
Implementing static analysis of C++ exception propagation in g++ alone
is not really possible well at
if not for the real compiler as such, what advantages would i get on
using newer glibc, libstdc++ ?? would these features be tied to
some kernel version linux-2.4 vs 2.6 ( something like thread
support).
Let's step back a bit.
If you look at this page:
http://gcc.gnu.org/releases.html
Hi again,
Here is the err_make file.
Thanks,
Aurélien
2007/3/30, François-Xavier Coudert [EMAIL PROTECTED]:
out_make is the output of the make. In fact it is the output of the
make launch a second time. (To big otherwise.)
Yes, but it's missing the standard error file. Please use:
make
Hi,
I have no idea of what is a gcc-4.2 snapshot ?
Could you explain a bit.
Thanks,
Aurélien
2007/3/30, Mike Stump [EMAIL PROTECTED]:
On Mar 30, 2007, at 7:45 AM, Aurélien Benoit-Lévy wrote:
Do you have any idea of what went wrong and any idea of what should
I do ?
Hum, I'd be tempted to
Andrew Pinski writes:
On 4/1/07, David Daney [EMAIL PROTECTED] wrote:
The issue is that for some things (the java front-end) we need the
trapping behavior. I just want to optimize it if the divisor is known
to be non-zero. VRP knows, but by the time we generate the code it
seems
Aurélien Benoit-Lévy writes:
I have no idea of what is a gcc-4.2 snapshot ?
Could you explain a bit.
Why, instead, do you not simply go to http://gcc.gnu.org/ and follow
thw link marked snapshots?
Andrew.
--
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire,
On 01/04/07, Martin Michlmayr [EMAIL PROTECTED] wrote:
We have some real numbers about these new errors now. I've compiled
the whole Debian archive in the last week for Gelato to test GCC 4.3
on IA64. Out of just slightly under 7000 packages in Debian, we have
the following new failures:
* Manuel López-Ibáñez [EMAIL PROTECTED] [2007-04-02 12:58]:
missing newline: 42
error: xxx redefined: 33
Martin, are those programs compiled with -pedantic or -pedantic-errors
enabled?
Nope.
--
Martin Michlmayr
http://www.cyrius.com/
On Fri, Mar 30, 2007 at 09:52:22AM -0700, Richard Henderson wrote:
I think the problem is that we've not told libcpp what the correct
narrow character set is. I suggest adding something like
if (BITS_PER_UNIT = 32)
cpp_opts-narrow_charset = BYTES_BIG_ENDIAN ? UTF-32BE : UTF-32LE;
On 02/04/07, Martin Michlmayr [EMAIL PROTECTED] wrote:
* Manuel López-Ibáñez [EMAIL PROTECTED] [2007-04-02 12:58]:
missing newline: 42
error: xxx redefined: 33
Martin, are those programs compiled with -pedantic or -pedantic-errors
enabled?
Nope.
Then, if the warnings are not very useful
* Manuel López-Ibáñez [EMAIL PROTECTED] [2007-04-02 13:57]:
Just out of curiosity, does any of those programs use -Werror?
No, otherwise the problems would have been found and fixed before.
Remember, there has always been a warning about this, but now it's an
error.
--
Martin Michlmayr
While doing (or trying to) some cleanup thanks to -mcx16, i've been a
bit surprised that
-- cut --
typedef int TItype __attribute__ ((mode (TI)));
TItype m_128;
void test(TItype x_128)
{
m_128 = __sync_val_compare_and_swap (m_128, x_128, m_128);
}
#include xmmintrin.h
typedef __m128i
On 02/04/07, Martin Michlmayr [EMAIL PROTECTED] wrote:
* Manuel López-Ibáñez [EMAIL PROTECTED] [2007-04-02 13:57]:
Just out of curiosity, does any of those programs use -Werror?
No, otherwise the problems would have been found and fixed before.
Remember, there has always been a warning about
Andrew Haley wrote:
Andrew Pinski writes:
It seems wrong that the java front-end thinks we don't have to use
the divide subroutine for MIPS. Really I think it is wrong that
the mips back-end thinks it should enable by default trap on divide
by zero.
I'm not sure about that: the MIPS
On Apr 2, 2007, at 2:32 AM, Brendon Costa wrote:
I have for a while been working on a tool that performs static
analysis
Ah, yeah, that I suspect would be a even better way to do this...
Itt would be nice if gcc/g++ had more support for static analysis
tools... Maybe with LTO.
On Mon, Apr 02, 2007 at 04:23:21PM +0200, tbp wrote:
Am i just wrong believing that ought to work?
Yes.
r~
Joe Buck wrote:
No, one does not have to adapt gradually. It is no harder to switch from
2.95 to 4.1.2 than it is to switch from 2.95 to 3.3. Either way, you'll
have to get out a C++ book, learn C++, and recode your code in actual C++.
There will be some cases where going to 3.3 will require
Andrew Pinski [EMAIL PROTECTED] writes:
Maybe one of the MIPS maintainers can explain why this option exists
in the first place.
As far as I can tell this has option has existed before the egcs/gcc
split. I still say the back-end should not worry about this and
divide by zero should always
Therefore, only -Wswitch is enabled by -Wall but neither of
Wswitch-default or Wswitch-enum are.
The statement for -Wall says:
-Wall
All of the above `-W' options combined. This enables all the warnings about
constructions that some users consider questionable, and that are easy to avoid
On 02/04/07, Ching, Jimen (US SSA) [EMAIL PROTECTED] wrote:
Therefore, only -Wswitch is enabled by -Wall but neither of
Wswitch-default or Wswitch-enum are.
Note; a bunch of -W options has the sentence This warning is enabled by -Wall.
But there are a few that doesn't, but they are in the
On Mon, Apr 02, 2007 at 09:34:39PM +0100, Manuel López-Ibáñez wrote:
On 02/04/07, Ching, Jimen (US SSA) [EMAIL PROTECTED] wrote:
Therefore, only -Wswitch is enabled by -Wall but neither of
Wswitch-default or Wswitch-enum are.
Note; a bunch of -W options has the sentence This warning is
Many x86 SSE source codes use __declspec. I'd like to make
__declspec available for Linux/x86. We can do one of the
following:
1. Define TARGET_DECLSPEC for Linux/x86.
2. Define TARGET_DECLSPEC for x86.
3. Add -mdeclspec.
Any comments?
H.J.
On 4/2/07, H. J. Lu [EMAIL PROTECTED] wrote:
Many x86 SSE source codes use __declspec. I'd like to make
__declspec available for Linux/x86. We can do one of the
following:
Do the following in the sources:
#ifndef __WIN32__
#define __declspec(x)
#endif
or in the makefiles:
Add -D__declspec(x)=
On Mon, Apr 02, 2007 at 02:06:15PM -0700, Andrew Pinski wrote:
On 4/2/07, H. J. Lu [EMAIL PROTECTED] wrote:
Many x86 SSE source codes use __declspec. I'd like to make
__declspec available for Linux/x86. We can do one of the
following:
Do the following in the sources:
#ifndef __WIN32__
On 4/2/07, H. J. Lu [EMAIL PROTECTED] wrote:
It won't work with
__declspec(align(16)) double x [4];
And the code should be converted over to use GCC style attributes.
So really the code should be something like:
#ifndef __WIN32__
#define __align16 __attribute__((align(16) ))
#else
#define
On Apr 2, 2007, at 2:03 PM, H. J. Lu wrote:
Many x86 SSE source codes use __declspec. I'd like to make
__declspec available for Linux/x86. We can do one of the
following:
1. Define TARGET_DECLSPEC for Linux/x86.
2. Define TARGET_DECLSPEC for x86.
3. Add -mdeclspec.
Any comments?
I suspect
On 4/2/07, Mike Stump [EMAIL PROTECTED] wrote:
I suspect I'd want this for x86 darwin as well.
Why emulate Windows compilers on non windows machine? That is wrong.
GCC for Linux/Darwin/any other OS besides Windows is not a Windows
compiler and should not act like one. If people want to port
On 4/2/07, Andrew Pinski [EMAIL PROTECTED] wrote:
Why emulate Windows compilers on non windows machine? That is wrong.
GCC for Linux/Darwin/any other OS besides Windows is not a Windows
compiler and should not act like one. If people want to port their
code, they should write their code to be
On 4/2/07, Andrew Pinski [EMAIL PROTECTED] wrote:
On 4/2/07, Mike Stump [EMAIL PROTECTED] wrote:
I suspect I'd want this for x86 darwin as well.
Why emulate Windows compilers on non windows machine? That is wrong.
GCC for Linux/Darwin/any other OS besides Windows is not a Windows
compiler
Matt Thomas wrote:
For instance, gcc emits:
movab rpb,%r0
movab 100(%r0),%r1
cvtwl (%r1),%r0
but the movab 100(%r0),%r1 is completely unneeded, this should have
been emitted as:
movab rpb,%r0
cvtwl 100(%r0),%r0
Ah ! A clear case of all the world's a
Snapshot gcc-4.1-20070402 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070402/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On 4/2/07, Toon Moene [EMAIL PROTECTED] wrote:
Ah ! A clear case of all the world's a RISC syndrome.
Actually I think it is a case of CSE/frowprop not doing the correct
thing for the addressing modes. So it might be the real problem is
the back-end's addressing mode cost are incorrect or
Hi!
I've applied for Google's Summer of Code 2007 with GCC as mentor
organization. I want to make GCC working faster on the algorithmic
level. I left out the detailed aims of the project, since i want to
discuss them with gcc developers/mentors first. Do you have any
suggestions what I
On Mon, Apr 02, 2007 at 11:26:16PM +0200, Steven Bosscher wrote:
On 4/2/07, Andrew Pinski [EMAIL PROTECTED] wrote:
On 4/2/07, Mike Stump [EMAIL PROTECTED] wrote:
I suspect I'd want this for x86 darwin as well.
Why emulate Windows compilers on non windows machine? That is wrong.
GCC for
On 4/2/07, Joe Buck [EMAIL PROTECTED] wrote:
If the Windows version of GCC has to recognize __declspec to function
as a hosted compiler on Windows, then the work already needs to be done
to implement it. So what's the harm in allowing it on other platforms?
If it makes it easier for Windows
On Mon, Apr 02, 2007 at 03:11:06PM -0700, Andrew Pinski wrote:
On 4/2/07, Joe Buck [EMAIL PROTECTED] wrote:
If the Windows version of GCC has to recognize __declspec to function
as a hosted compiler on Windows, then the work already needs to be done
to implement it. So what's the harm in
On 4/2/07, Richard Henderson [EMAIL PROTECTED] wrote:
On Mon, Apr 02, 2007 at 04:23:21PM +0200, tbp wrote:
Am i just wrong believing that ought to work?
Yes.
It's hard to argue with a terse compiler or maintainer. Perhaps i
should have picked an easier target like
On 4/2/07, H. J. Lu [EMAIL PROTECTED] wrote:
I believe __declspec in Intel C++ compiler comes from:
http://msdn2.microsoft.com/en-us/library/dabb5z75.aspx
How is Microsoft documentation, the real documentation for Intel C++
compiler? Have you seen the Cell language extension document [1]?
On Tue, Apr 03, 2007 at 01:54:16AM +0200, tbp wrote:
Am i just wrong believing that ought to work?
Yes.
It's hard to argue with a terse compiler or maintainer. Perhaps i
should have picked an easier target like
http://gcc.gnu.org/onlinedocs/gcc/Atomic-Builtins.html: GCC will
allow any
Hi,
I am working on integrating GCC 4.1.x series into FreeBSD src/ tree.
I've been running with the new compiler on FreeBSD 7.0 for quite a while
now, but was hesitant to commit my changes because of a couple of
unsolved issues. I would really appreciate your input on the way to
overcome them.
--- Comment #41 from anlauf at gmx dot de 2007-04-02 08:42 ---
(In reply to comment #40)
New Revision: 123404
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123404
Log:
2007-04-01 Jerry DeLisle [EMAIL PROTECTED]
Jerry,
thanks so far, but now I am back to the situation
I get the following ICE:
test.f90: In function MAIN__:
test.f90:29: internal compiler error: in gfc_get_symbol_decl, at
fortran/trans-decl.c:877
Please submit a full bug report,
when compiling this code:
module InternalCompilerError
type Byte
private
character(len=1) ::
Motohisa Moriya wrote:
-#if defined (__SH3E__) || defined (__SH4__)
+#if defined (__SH4E__) || defined (__SH4__)
There's no such thing as an SH4E. There is an SH3E and it shares the
same single-precision support as SH4, thus there are some places where I
would expect to see such an #if.
I
--- Comment #65 from bkoz at redhat dot com 2007-04-02 09:49 ---
Subject: Re: __cplusplus defined to 1, should be 199711L
Weird, when solaris is the easiest one.
That's certainly a matter of perspective.
Based on Solaris 11 x86, I don't see a way for say cstdlib to have only the
Andrew STUBBS wrote:
There's no such thing as an SH4E. There is an SH3E and it shares the
same single-precision support as SH4, thus there are some places where I
would expect to see such an #if.
It is said that the libgcc.a multi-library cannot be made because an impossible
register is
--- Comment #4 from pluto at agmk dot net 2007-04-02 10:13 ---
attached testcase works fine with vs2k3/boost-1.33/stlport.
it also works with g++-4.0.0/20050519(RH 4.0.0-8)/boost/libstdc++
on x86_64-gnu-linux. in the other. indeed, it fails with 4.1.2
and 4.2.0 (4.3 not tested).
--
Motohisa Moriya wrote:
Andrew STUBBS wrote:
There's no such thing as an SH4E. There is an SH3E and it shares the
same single-precision support as SH4, thus there are some places where I
would expect to see such an #if.
It is said that the libgcc.a multi-library cannot be made because an
--- Comment #11 from pcarlini at suse dot de 2007-04-02 10:32 ---
Ok, therefore we cannot consider anymore the issue a libstdc++ issue.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #5 from paolo at gcc dot gnu dot org 2007-04-02 11:09 ---
Subject: Bug 31401
Author: paolo
Date: Mon Apr 2 11:08:50 2007
New Revision: 123422
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123422
Log:
2007-04-02 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #6 from paolo at gcc dot gnu dot org 2007-04-02 11:09 ---
Subject: Bug 31401
Author: paolo
Date: Mon Apr 2 11:09:07 2007
New Revision: 123423
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123423
Log:
2007-04-02 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #9 from paolo at gcc dot gnu dot org 2007-04-02 11:16 ---
Subject: Bug 31370
Author: paolo
Date: Mon Apr 2 11:15:50 2007
New Revision: 123424
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123424
Log:
2007-04-02 Matthew Levine [EMAIL PROTECTED]
Paolo
--- Comment #10 from pcarlini at suse dot de 2007-04-02 11:19 ---
Fixed for 4.3.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from pault at gcc dot gnu dot org 2007-04-02 11:33 ---
(In reply to comment #0)
As indicated in the comments, the ICE is caused by the line passing a function
Sort of: In order to find out the size of the function result, gfortran
evaluates transfer(user,
Andrew STUBBS wrote:
Sorry, I find this very hard to read. I think you found it very hard to
write. :)
I do not say that the code is right. I say that changing SH3E to SH4E is
wrong. It might be that completely removing SH3E is right. Perhaps the
error is somewhere else.
Kaz, I don't know if
Motohisa Moriya wrote:
I am wishing that all of SH2,SH2E, SH3, SH3E, SH4, and SH4E can be compiled with
sh-unknown-linux-gnu-gcc.
SH4E does not exist.
Perhaps you mean SH4A?
--- Comment #2 from pault at gcc dot gnu dot org 2007-04-02 12:51 ---
To my amazement, the brute force:
Index: gcc/fortran/trans-decl.c
===
*** gcc/fortran/trans-decl.c(révision 122688)
--- gcc/fortran/trans-decl.c
Hi All,
I am trying to compile cfengine. I was using gcc version 4.0.2 and was facing
an error. I found that the my problem is due to a bug that has been fixed and
in version 4.1 onwards.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26189
I rebuild it with gcc version 4.1.2 (binary available on
Andrew STUBBS wrote:
Perhaps you mean SH4A?
yes
Because my debian environment has crashed, -m option cannot be confirmed
Please point it out if the mistake is found in my idea.
SH2A Core
SH2,SH3
SH4A Core
SH4
(SH5 is unknown)
Motohisa
Hi Andrew,
Andrew STUBBS [EMAIL PROTECTED] wrote:
I do not say that the code is right. I say that changing SH3E to SH4E is
wrong. It might be that completely removing SH3E is right. Perhaps the
error is somewhere else.
Kaz, I don't know if you have already seen this message. Perhaps you
--- Comment #42 from jvdelisle at gcc dot gnu dot org 2007-04-02 14:35
---
Will keep open until we get them all!. Looks like I need another test case. :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
--- Comment #3 from pault at gcc dot gnu dot org 2007-04-02 14:43 ---
(In reply to comment #2)
an ICE in the same place, but it appears it isn't fixed. Paul, since the
previous PRs were really related, you might understand this one easily?
I had hoped so, but the problem here turns
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
When the compiler is provided with -std=c++0x to enable the experimental C++0x
mode, includes of TR1 facilities (e.g., tr1/tuple) do not put TR1 functionality
into namespace std::tr1, breaking backward compatibility. Here's an example
program that compiles without -std=c++0x but does not compile
--- Comment #3 from hjl at gcc dot gnu dot org 2007-04-02 15:54 ---
Subject: Bug 31380
Author: hjl
Date: Mon Apr 2 15:53:48 2007
New Revision: 123428
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123428
Log:
2007-04-02 H.J. Lu [EMAIL PROTECTED]
* Backport from
--- Comment #4 from hjl at gcc dot gnu dot org 2007-04-02 15:55 ---
Subject: Bug 31380
Author: hjl
Date: Mon Apr 2 15:55:17 2007
New Revision: 123429
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123429
Log:
2007-04-02 H.J. Lu [EMAIL PROTECTED]
* Backport from
--- Comment #5 from hjl at lucon dot org 2007-04-02 15:57 ---
Fixed in gcc 4.1.3 and 4.2.0.
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-04-02 16:18 ---
isn't that a feature?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31426
--- Comment #94 from bonzini at gnu dot org 2007-04-02 16:20 ---
I think that Uros' patch to add a -mpc switch for precision control would fix
this.
The real fix would be to automatically insert fldcw instructions before
float/double operations, in order to limit the precision of the
--- Comment #7 from bonzini at gnu dot org 2007-04-02 16:21 ---
Reopened...
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|RESOLVED
--- Comment #8 from bonzini at gnu dot org 2007-04-02 16:22 ---
... because GCC now has -mpc to limit precision for float/double operations.
Even as far as x86 is concerned, this is a special case of PR323, and thus
I'm closing it as fixed.
--
bonzini at gnu dot org changed:
--- Comment #2 from dgregor at gcc dot gnu dot org 2007-04-02 16:32 ---
I don't think it is a feature.
In C++0x mode, if one includes tuple, one should get std::tuple. That's what
the C++0x working paper says.
In any mode, if one includes tr1/tuple, one should get std::tr1::tuple.
--- Comment #31 from sje at cup dot hp dot com 2007-04-02 16:36 ---
When configuring with --with-system-libunwind, GCC should not include
unwind-compat.o (or any unwind code) in the build of libgcc_s. Then the
configure check will work correctly.
--
--- Comment #2 from pault at gcc dot gnu dot org 2007-04-02 16:38 ---
This fixes the problem and regtests:
Index: gcc/fortran/parse.c
===
*** gcc/fortran/parse.c (révision 123426)
--- gcc/fortran/parse.c (copie de travail)
--- Comment #1 from bangerth at dealii dot org 2007-04-02 17:09 ---
Confirmed.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC|
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-04-02 17:26 ---
Ah, I see.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from eweddington at cso dot atmel dot com 2007-04-02 17:41
---
Can someone please commit this patch? I need this for mingw-hosted cross
toolchains.
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
--- Comment #14 from tkoenig at gcc dot gnu dot org 2007-04-02 17:44
---
I'll give this another shot.
Maybe inlining isn't even necessary for good performance...
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
When I compile the following program I get the message GNU MP: Cannot
reallocate memory
PROGRAM test
INTEGER(KIND=1) :: i(1)
i = (/ TRANSFER(a, 0) /)
END PROGRAM test
--
Summary: When I compile the following program I get the message
GNU MP: Cannot reallocate
--- Comment #7 from jason at gcc dot gnu dot org 2007-04-02 18:49 ---
Subject: Bug 31187
Author: jason
Date: Mon Apr 2 18:49:21 2007
New Revision: 123432
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123432
Log:
PR c++/31187
When I compile the following program I get the message GNU MP: Cannot
reallocate memory
PROGRAM test
INTEGER(KIND=1) :: i(1)
i = (/ TRANSFER(a, 0) /)
END PROGRAM test
--
Summary: When I compile the following program I get the message
GNU MP: Cannot reallocate
--- Comment #1 from kargl at gcc dot gnu dot org 2007-04-02 19:06 ---
*** Bug 31428 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31427
--- Comment #1 from kargl at gcc dot gnu dot org 2007-04-02 19:06 ---
*** This bug has been marked as a duplicate of 31427 ***
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--
Summary: Is anybody monitoring the daily regression tests on
Darwin 8.5?
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at
(~100) of regressions: gcc.c-torture/execute/builtins/memcpy-chk.c, ...,
gcc.c-torture/execute/built-in-setjmp.c. Looking at the list, I have found
that this has started on 20070325 for Darwin8:
http://gcc.gnu.org/ml/gcc-testresults/2007-03/msg01225.html
Note that the errors are all of the
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-02 20:05 ---
This was caused by the conversion of l constaint to hard registers. I sent a
patch to Andreas T. to test as I don't have an up todate sources on my
ppc-darwin machine that I use to test patches.
--
pinskia at
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-02 20:05 ---
*** This bug has been marked as a duplicate of 31429 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-04-02 20:05 ---
*** Bug 31430 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31429
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-04-02 20:10 ---
Can confirm a crash in f951. Since there were quite a lot of TRANSFER related
reports lately, I can not tell if this a new one.
Backtrace:
Starting program:
--- Comment #8 from jason at gcc dot gnu dot org 2007-04-02 20:12 ---
Subject: Bug 31187
Author: jason
Date: Mon Apr 2 20:12:15 2007
New Revision: 123434
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123434
Log:
PR c++/31187
The following (IMHO invalid) code snippet triggers an ICE on mainline:
===
templatetypename..., typename void foo();
void bar()
{
fooint();
}
===
bug.cc: In function 'void bar()':
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31431
More fallout from the variadic templates on mainline:
===
templatetypename..., typename struct A
{
enum { N };
};
Aint,int a;
===
bug.cc:1: error: parameter pack
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-04-02 20:27 ---
Adding this to TRANSFER meta-bug, as frame 3 in the backtrace indicates a
relation. No confirmation as I can not tell whether it is a dupe or not.
(gdb) bt
#0 fancy_abort (file=0x86e4fec
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31432
More fallout from the variadic templates on mainline:
===
templatetypename..., typename struct A
{
static int i;
};
Aint, int a;
Achar,int b;
===
bug.cc:1: error: parameter pack
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31433
More fallout from the variadic templates on mainline:
===
templatetypename... T void foo(const T...) {}
void bar()
{
foo(0);
}
===
bug.cc: In function 'void foo(T ...) [with T =
1 - 100 of 161 matches
Mail list logo
