Hi all,
I am interested in being able to mark-up C++ code with special
meta-information. This is kind of like the existing __attribute__ for GCC but
the semantics are quite different (I.e. Not just function/type level but
statement level meta-data). I wish to ask if anyone knows of anything
Hi,
(This message is a duplicate of a message to `gcc-help' where I did not
get a definitive answer[*].)
I read parts of Drepper's [0] and Oliva's [1] work on TLS access. From
my understanding, the `initial-exec' model can be used safely when
compiling an executable. However, it's still
On 06 August 2007 02:13, Rodolfo Lima wrote:
Rodolfo Schulz de Lima escreveu:
Dave Korn escreveu:
Thanks, and do drop a note back with a summary of what you find out over
there when you're done; if there's definitely a bug in gcc's
understanding of the resolution rules, obviously we'd like
Michael Matz [EMAIL PROTECTED] wrote on 31/07/2007 18:05:53:
Hi,
On Tue, 31 Jul 2007, Daniel Berlin wrote:
2. Store-sinking/load hoisting may have an overhead and may degrade
performance unless the relevant conditional branch gets if-converted.
I agree with you for conditional
Is there any reason why this contribution from Mikkel Krautz is still
not in the current sources?
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01592.html
Hans Kester
===
This email and any files transmitted with it are confidential and intended
solely for the use
Hans Kester Ellips B.V. [EMAIL PROTECTED] writes:
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom
they are addressed. If you have received this email in error please
notify Ellips B.V. This message contains
Hi,
On Mon, 6 Aug 2007, Tehila Meyzels wrote:
in if-conv (or phi-opt), but in ssa-sink (or some similar transformation
which can or can not use value numbers and the like).
OK.
And what's your opinion WRT conditional loads/stores?
Since you've sent your conditional store
Tristan Wibberley [EMAIL PROTECTED] writes:
I've found a case which looks like it should be possible to optimise but
gcc (very recent trunk) isn't doing which could give improvements in
many cases - certainly in a case I've come across:
Looks reasonable to me. Please open a
I am running into a problem running the gfortran.dg/c_kind_params.f90
and am wondering how to address it. This test has a C language
component in gfortran.dg/c_kinds.c. This C file includes stdint.h and
uses types like int32_t and int64_t. On HPPA HP-UX platforms we don't
have a stdint.h
2007-07-23 Ralf Wildenhues [EMAIL PROTECTED]
* configure.ac (TOPLEVEL_CONFIGURE_ARGUMENTS, baseargs):
Pass --silent if $silent.
Ok.
On Mon, 2007-08-06 at 07:38 -0700, Ian Lance Taylor wrote:
Tristan Wibberley [EMAIL PROTECTED] writes:
I've found a case which looks like it should be possible to optimise but
gcc (very recent trunk) isn't doing which could give improvements in
many cases - certainly in a case I've come
On 8/6/07, Tristan Wibberley [EMAIL PROTECTED] wrote:
Any chance of moving to launchpad.net?
And launchpad.net forces everyone else to remember a new username and password.
Anyways the username for gcc bugzilla is your email address.
-- Pinski
On Mon, Aug 06, 2007 at 07:08:04PM +0100, Tristan Wibberley wrote:
On Mon, 2007-08-06 at 07:38 -0700, Ian Lance Taylor wrote:
Tristan Wibberley [EMAIL PROTECTED] writes:
I've found a case which looks like it should be possible to optimise but
gcc (very recent trunk) isn't doing which
On Mon, 2007-08-06 at 10:28 -0700, Steve Ellcey wrote:
I am running into a problem running the gfortran.dg/c_kind_params.f90
and am wondering how to address it. This test has a C language
component in gfortran.dg/c_kinds.c. This C file includes stdint.h and
uses types like int32_t and
Any chance of moving to launchpad.net?
And launchpad.net forces everyone else to remember a new username
and password.
Launchpad is also non-free software.
and the test runs on powerpc64-linux for both -m32 and -m64. Did
you have it in a different position? If so I'll try that and see
if I can figure out why it would be skipped. Also, which target
were you testing?
I was testing on an IA64 Linux platform (Debian). I had this:
! { dg-do run
On Mon, 2007-08-06 at 13:16 -0700, Steve Ellcey wrote:
and the test runs on powerpc64-linux for both -m32 and -m64. Did
you have it in a different position? If so I'll try that and see
if I can figure out why it would be skipped. Also, which target
were you testing?
I was testing on
[ CVS HEAD's ltmain.sh containing as first line:
# Generated from ltmain.m4sh; do not edit by hand
]
* DJ Delorie wrote on Thu, Aug 02, 2007 at 05:09:09PM CEST:
I don't think this is much of a problem. ltmain.sh is always
distributed with libtool and you would need the full libtool
Yes. I tried it in the order your used, and the compile to check
for inttypes.h tried to also compile c_kinds.c, which wasn't
available from where the compile was done. In general it's best
to check effective targets before adding files or options, unless
the options are required for the
Snapshot gcc-4.1-20070806 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070806/
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
I was looking at PR tree-optimization/32941 after seeing a bootstrap
failure on my IA64 Linux box. I was wondering if anyone knows why it
has started failing now? It looks like this sorting of the goto queue
has been around for quite a while (since 4.1 at least). Do we have more
goto's than we
Hi people,
I'm looking for simulators of 64-bit processors for my 32-bit PC and
i've found one.
qemu-system-x86_64 works simulating a x86-64 linux as slamd64, ubuntu, etc.
http://fabrice.bellard.free.fr/qemu/status.html indicates that x86-64
is OK for System emulation but is not supported for
This doesn't really have much to do with GCC. Perhaps you'd like to ask
on comp.arch?
Ben
--- Comment #13 from gianni at mariani dot ws 2007-08-06 06:26 ---
This seems like a serious bug and it has been around for 6 years and there has
been a patch to fix this as noted by Gaby.
Is someone of the opinion that this should not be fixed ?
--
--- Comment #8 from rob1weld at aol dot com 2007-08-06 06:44 ---
GCC 4.2.2 20070804 is able to compile newer kernels as is 4.2.1 20070628. I
guess 4.3 and 4.1 are the only series lacking this ability.
I am not allowed to change the Summary: to add [4.3 Regression] to the
begining
--- Comment #39 from bonzini at gnu dot org 2007-08-06 08:08 ---
committed??
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
--- Comment #1 from nickc at redhat dot com 2007-08-06 08:12 ---
Subject: Re: New: -frecord-gcc-switches issues
Hi Jakub,
.ascii -isystem ./include-fixed
.zero 1
.ascii -D_GNU_SOURCE a.c
.zero 1
The main issue I have with this is the
--- Comment #9 from zhouyi04 at ios dot cn 2007-08-06 08:40 ---
(In reply to comment #8)
I try to compile my giving C program using gcc-4.2.1, the problem still exists.
As my solution 1 suggests:
a caller function is inlinable only if all of its callee functions are
inlinable. while
--- Comment #8 from sgh at sgh dot dk 2007-08-06 09:08 ---
also fails on 4.2.1
--
sgh at sgh dot dk changed:
What|Removed |Added
CC|
--- Comment #3 from pcarlini at suse dot de 2007-08-06 09:13 ---
Yes, the standard is clear that array of unknown bound of T and array of N of T
are different types. And we are all implementing the is_array trait with 2
specializations (Vandevoorde and Josuttis included in their book).
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
--- Comment #2 from paolo at gcc dot gnu dot org 2007-08-06 09:18 ---
Subject: Bug 19532
Author: paolo
Date: Mon Aug 6 09:18:39 2007
New Revision: 127238
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127238
Log:
2007-08-06 Paolo Carlini [EMAIL PROTECTED]
PR c++/19532
--- Comment #3 from pcarlini at suse dot de 2007-08-06 09:19 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-08-06 09:20
---
Without any more news, let's consider this fixed. Douglas, if it so happens
that your bug wasn't fixed by the patch, please reopen this bug-report.
--
fxcoudert at gcc dot gnu dot org changed:
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-08-06 09:49
---
OK, I downloaded GlobSol and have a reduced testcase:
$ cat pr32926.f90
subroutine foo (fcn)
external fcn
contains
subroutine bar
call fcn
end subroutine bar
end subroutine foo
$ gfortran pr32926.f90
d1mach.f:90.43:
DATA LARGE(1), LARGE(2) / Z'', Z'7FEF' /
1
Error: Arithmetic overflow converting INTEGER(16) to INTEGER(4) at (1)
--
Summary: error with hexadecimal DATA
Product: gcc
--- Comment #1 from sliwa at cft dot edu dot pl 2007-08-06 11:03 ---
Created an attachment (id=14028)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14028action=view)
sample source that does not compile
This is a SLATEC machine file
--
Statements like:
DATA DMACH(1) / Z'0010' /
DATA DMACH(2) / Z'7FEF' /
DATA DMACH(3) / Z'3CA0' /
DATA DMACH(4) / Z'3CB0' /
DATA DMACH(5) / Z'3FD34413509F79FF' /
generate incorrect data.
--
Summary: 64-bit
--- Comment #1 from sliwa at cft dot edu dot pl 2007-08-06 11:15 ---
Created an attachment (id=14029)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14029action=view)
sample source that demonstrates the problem
This is a SLATEC machine file
--
--- Comment #17 from gerald at gcc dot gnu dot org 2007-08-06 11:10 ---
Subject: Bug 13676
Author: gerald
Date: Mon Aug 6 11:10:19 2007
New Revision: 127239
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127239
Log:
PR pch/13676
* doc/invoke.texi: Add .hp, .hxx,
--- Comment #2 from sliwa at cft dot edu dot pl 2007-08-06 11:18 ---
There is also bug #33001. Both the bugs together make life difficult.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33002
--- Comment #3 from sliwa at cft dot edu dot pl 2007-08-06 11:21 ---
Now I see that 32-bit data is incorrect also.
DATA RMACH(1) / Z'0080' /
DATA RMACH(2) / Z'7F7F' /
DATA RMACH(3) / Z'3380' /
DATA RMACH(4) / Z'3400' /
DATA RMACH(5) /
--- Comment #40 from pinskia at gcc dot gnu dot org 2007-08-06 11:35
---
(In reply to comment #39)
committed??
This is now more like a meta-bug, see the other two bugs which are opened for
the current issues (yes both are assigned to me and both are actively being
worked on, well one
--- Comment #6 from pcarlini at suse dot de 2007-08-06 11:52 ---
The subtle issue here is that this specific error message should be emitted
*only* when the incorrectly specified return type doesn't match, thus a plain
error instead of a pedwarn:
case sfk_conversion:
if (type
--- Comment #41 from paolo dot bonzini at lu dot unisi dot ch 2007-08-06
11:52 ---
Subject: Re: [4.2/4.3 Regression] Performace problem
with indexed load/stores on powerpc
This is now more like a meta-bug, see the other two bugs which are opened for
the current issues (yes both
class X
{
public:
static X instance();
static void init();
private:
X();
};
void f()
{
X x = X::instance();
x.init();
}
in this case the 'x' variable is initialized and unused.
gcc-4.2 accepts this w/o any warning at -Wall -Wextra
but vs2005-express
--- Comment #2 from burnus at gcc dot gnu dot org 2007-08-06 12:11 ---
DATA LARGE(1), LARGE(2) / Z'', Z'7FEF' /
Error: Arithmetic overflow converting INTEGER(16) to INTEGER(4) at (1)
The error message is correct: You cannot fit the number into an
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-06 12:33 ---
To the developer (and me), x is not unused.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33003
On 6 Aug 2007 12:42:18 -, pluto at agmk dot net
[EMAIL PROTECTED] wrote:
moreover i'm wondering why gcc uses movdqa for unaligned loads?
Because __m128i is assumed to be aligned.
-- Pinski
--- Comment #4 from sliwa at cft dot edu dot pl 2007-08-06 12:45 ---
With -fno-range-check I get:
d1mach.f: In function 'd1mach':
d1mach.f:2: fatal error: gfc_todo: Not Implemented: Initialization of
overlapping variables
compilation terminated.
See also bug #33002.
--
--- Comment #12 from aph at gcc dot gnu dot org 2007-08-06 12:48 ---
Subject: Bug 32843
Author: aph
Date: Mon Aug 6 12:48:07 2007
New Revision: 127241
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127241
Log:
PR testsuite/32843
* src/x86/sysv.S
--- Comment #2 from pluto at agmk dot net 2007-08-06 12:42 ---
thanks for ths explanation about aligned attribute.
moreover i'm wondering why gcc uses movdqa for unaligned loads?
it should use movdqu for *((__m128i*)ptr) and _mm_set_epi8(ptr[15],...,ptr[0]).
--
--- Comment #3 from sliwa at cft dot edu dot pl 2007-08-06 12:41 ---
1. The attached d1mach.f works fine with g77.
2. The numbers are 32-bit, so why an overflow? Maybe the number is extended as
a signed number (padded with ones), and the conversion is unsigned.
--
--- Comment #4 from burnus at gcc dot gnu dot org 2007-08-06 12:49 ---
Using
REAL RMACH(5)
DATA RMACH(1) / Z'0080' /
is invalid Fortran 77/90/95/2003 as Fortran only allows:
If a data-stmt-constant is a boz-literal-constant, the corresponding variable
shall be of type
--- Comment #13 from aph at gcc dot gnu dot org 2007-08-06 12:53 ---
The 32bit psABI specifies Integral Arguments as 'Functions pass all
integer-valued
arguments as words, expanding or padding signed or unsigned bytes and
halfwords as needed'. For return values the best I can find
--- Comment #4 from pluto at agmk dot net 2007-08-06 12:56 ---
(In reply to comment #3)
Subject: Re: missed memcpy - movdqa optimization.
On 6 Aug 2007 12:42:18 -, pluto at agmk dot net
[EMAIL PROTECTED] wrote:
moreover i'm wondering why gcc uses movdqa for unaligned loads?
--- Comment #3 from pinskia at gmail dot com 2007-08-06 12:43 ---
Subject: Re: missed memcpy - movdqa optimization.
On 6 Aug 2007 12:42:18 -, pluto at agmk dot net
[EMAIL PROTECTED] wrote:
moreover i'm wondering why gcc uses movdqa for unaligned loads?
Because __m128i is assumed
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-08-06 13:15
---
Maybe I'm completely off, but isn't the -fpack-derived option what is needed to
play with this padding? (it's hard for me to tell exactly, because I don't
really read assembly) If so, could we close the PR?
--
--- Comment #2 from drow at gcc dot gnu dot org 2007-08-06 13:21 ---
Subject: Re: New: [Regression] gdb has symbol table issues
On Sat, Aug 04, 2007 at 11:13:11PM -, scovich at gmail dot com wrote:
When debugging code produced by g++-4.3.0-20070716 the debugger regularly
--- Comment #5 from burnus at gcc dot gnu dot org 2007-08-06 13:06 ---
The numbers are 32-bit, so why an overflow?
huge(0): 2147483647 ! biggest (positive) number fitting into integer(4)
Z'': 4294967295
I would argue that 4294967295 is bigger than 2147483647. If one
--- Comment #14 from aph at gcc dot gnu dot org 2007-08-06 13:35 ---
In addition: I suspect that this bug also is manifested on x86 Darwin, but my
patch should not affect that system at all, and therefore I suspect that this
bug is still manifested on that system.
--
--- Comment #1 from hjl at lucon dot org 2007-08-06 13:44 ---
Can you verify if it is the same as PR 31868? There is a a patch for PR 31868.
--
hjl at lucon dot org changed:
What|Removed |Added
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|2007-01-31 23:01:50 |2007-08-06 13:47:12
date|
The following code doesn't compile under gcc-4.2.1 on i686-pc-linux-gnu:
template class T void foo(T);
void foo(int);
void bar()
{
foo;
}
According to the discussion that began on thread
http://gcc.gnu.org/ml/gcc/2007-07/msg00663.html, then resumed on thread
The code below doesn't compile under gcc-4.2.1 on a i686-pc-linux-gnu
template class T void foo(T);
void bar()
{
fooint;
}
The compiler returns the following error message:
teste.cpp: In function void bar():
teste.cpp:4: error: statement cannot resolve address of overloaded function
As
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-06 13:57 ---
*** This bug has been marked as a duplicate of 11407 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-08-06 13:57
---
*** Bug 33005 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 2007-08-06 13:58 ---
*** This bug has been marked as a duplicate of 5458 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-08-06 13:58
---
*** Bug 33004 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
|
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-08-06 14:18 ---
Subject: Bug 30731
Author: pinskia
Date: Mon Aug 6 14:17:59 2007
New Revision: 127242
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127242
Log:
2007-08-06 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-08-06 14:18 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #12 from rodolfo at rodsoft dot org 2007-08-06 14:18 ---
This is an yet simpler case where this bug shows up:
template class T void foo(T);
void foo(int);
void bar()
{
foo;
}
i686-pc-linux-gnu-g++-4.2.1 fails with:
teste.cpp: In function void bar():
teste.cpp:6:
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-08-06 14:41 ---
We get a different ICE now:
t1.cc:4: internal compiler error: same canonical type node for different types
A and A
Please submit a full bug report,
with preprocessed source if appropriate.
See
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-08-06 14:57
---
Has this been fixed now?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30589
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
Keywords||error-recovery
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-08-06 15:12 ---
I no longer get a segfault for the trunk for the first testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31749
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-06 15:25 ---
Fixed. And has been for a while.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-06 15:28 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-06 15:29 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-06 15:38 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-06 15:44 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from pinskia at gcc dot gnu dot org 2007-08-06 15:47
---
Fixed for the trunk.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-06 15:53 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from dcb314 at hotmail dot com 2007-08-06 16:06 ---
(In reply to comment #6)
This is one which you need huge dataflow analysis
Doubtful. Yes/No/Don't know flag on each pointer data
member of a class would be some of it.
and whole program to detect this problem.
I'd
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2007-08-06 16:16
---
Not that I know. For my purposes, I use a hand-modified version of the _mingw.h
header; maybe more recent versions of mingw have been fixed. Still, current
trunk doesn't work with older mingw (more than a few
--- Comment #2 from bkoz at gcc dot gnu dot org 2007-08-06 16:16 ---
thanks for adding this bug report here and ccing me.
Is there an easy way to separate out the include and link (-I, -L) bits from
the macro defines and compiler option flags? Could the just the include bits be
put
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
GCC build triplet|powerpc64-unknown-linux-gnu |
GCC host triplet|powerpc64-unknown-linux-gnu |
GCC target
--- Comment #6 from kargl at gcc dot gnu dot org 2007-08-06 17:30 ---
*** This bug has been marked as a duplicate of 18026 ***
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from kargl at gcc dot gnu dot org 2007-08-06 17:30 ---
*** Bug 33001 has been marked as a duplicate of this bug. ***
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
When I attempt to compile the program listed below I get the following message:
a.f90: In function 'MAIN__':
a.f90:2: internal compiler error: in simplify_subreg, at simplify-rtx.c:4676
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html
--- Comment #5 from kargl at gcc dot gnu dot org 2007-08-06 17:32 ---
*** This bug has been marked as a duplicate of 18026 ***
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from kargl at gcc dot gnu dot org 2007-08-06 17:32 ---
*** Bug 33002 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18026
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-06 17:35 ---
3. The program was compiled with the flag -fdefault-integer-8. It does not
produce the error without this flag.
Yes we know, we are trying to resolve more and more of these
-fdefault-integer-8 bugs.
*** This bug
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-08-06 17:35 ---
*** Bug 33006 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from pluto at agmk dot net 2007-08-06 17:49 ---
(In reply to comment #17)
(In reply to comment #16)
(In reply to comment #15)
(In reply to comment #14)
(In reply to comment #13)
Created an attachment (id=13550)
--
--- Comment #19 from hjl at lucon dot org 2007-08-06 18:02 ---
If we can find which patch causes this regression, it will help find a
solution for 4.2.
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #7 from patchapp at dberlin dot org 2007-08-06 18:20 ---
Subject: Bug number PR33001
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/2007-08/msg00374.html
--
--- Comment #20 from pluto at agmk dot net 2007-08-06 18:28 ---
(In reply to comment #19)
If we can find which patch causes this regression, it will help find a
solution for 4.2.
i'll we do a bisect hunting...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30961
--- Comment #3 from roland at redhat dot com 2007-08-06 19:19 ---
Absolute file names are a very bad idea. That makes for gratuitous differences
in builds due to the build or source directory name, i.e. unrepeatable builds.
The names in .debug_line and .debug_info are already expected
1 - 100 of 131 matches
Mail list logo
