The SPASS theorem prover (see below) is miscompiled at -O2 by:
gcc version 3.4.3
gcc version 3.4.4 20050314 (prerelease) (Debian 3.4.3-13)
gcc version 4.0.0 (release)
gcc version 4.1.0 20050509 (experimental)
it is compiled correctly by:
gcc version 3.3.6 (Debian 1:3.3.6-3)
gcc version 3.3.5
--- Additional Comments From duraid at octopus dot com dot au 2005-05-09
06:44 ---
oops, my mistake. this bug appears on x86 too, at least:
gcc version 3.4.4 20050314 (prerelease) (Debian 3.4.3-13)
fails (at -O2), but:
gcc version 3.3.6 (Debian 1:3.3.6-3)
works. Perhaps this is a bug
--- Additional Comments From tsandnes at norway dot atmel dot com
2005-05-09 07:01 ---
Subject: Re: Overflowed address in dwarf debug line information
bjoern dot m dot haase at web dot de wrote:
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-05-06 14:12
--- Additional Comments From trauscher at loytec dot com 2005-05-09 07:04
---
The problem is that -march=xxx -mtune=yyy doesn't work.
The arm_override_option function scans the options
in the order -mtune, -march, -mcpu. So when -mtune is
given, 'arm_tune' first set by -mtune and then
--- Additional Comments From giovannibajo at libero dot it 2005-05-09
07:07 ---
Zack, this is a regression of part of your c-decl stuff. Can you possibly give
it a look? It breaks builds of glibc on primary platforms.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16676
--- Additional Comments From benh at kernel dot crashing dot org
2005-05-09 07:11 ---
Ben Elliston just produced a patch for it that I tested. It fixed building of
glibc on debian powerpc with -g1 (used by debian rules for nptl).
The patch is on it's way to the patch list (which didn't
--- Additional Comments From giovannibajo at libero dot it 2005-05-09
07:25 ---
I analyzed this PR again. The problem seems not related to attribute strong
itself, but rather the way v3 namespaces work. Basically, without debug
support, the failing code looks like:
Consider the following short program:
#include algorithm
void Tst1(short* __restrict__ SrcP, short* __restrict__ MinP, int Len)
{
for (int x=0; xLen; x++)
MinP[x] = SrcP[x] ? MinP[x];
}
void Tst2(short* __restrict__ SrcP, short* __restrict__ MinP, int Len)
{
for (int x=0; xLen;
--- Additional Comments From micis at gmx dot de 2005-05-09 08:24 ---
I cannot reproduce this bug any longer. Maybe the fix for pr20122 also helps
here.
Michael Cieslinski
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19716
I don't quite know how to characterize this one, so i'll let it up to those in
the know to fix the summary/description.
Primo, AFAIK, gcc has always struggled to get this right but 4.1 is setting a
new record; so i'll qualify that as a regression vs 3.3/3.4.
Secundo, i haven't found any related
--- Additional Comments From tbptbp at gmail dot com 2005-05-09 08:46
---
I'm going to ping this bugreport because there's still some very bad interaction
with gcse in current gcc.
Just compile the 'packet_intersection.cpp' testcase with ie g++-4.1-4120050501
for ia32 to convince
--- Additional Comments From tbptbp at gmail dot com 2005-05-09 08:50
---
I forgot to say that using ternary operators or if/else while changing the
codegen slightly doesn't make much difference.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21463
--- Additional Comments From pcarlini at suse dot de 2005-05-09 09:04
---
- Fully qualify all references to std names from code within namespace
_GLIBCXX_STD (which expands to __gnu_norm in debug mode). This is hard
because
it's impossible to fully check it, and it's pervasive.
--- Additional Comments From pcarlini at suse dot de 2005-05-09 09:16
---
I found something in the archive:
http://gcc.gnu.org/ml/libstdc++/2002-12/msg9.html
That's why we didn't qualify less co... In mainline (vs v7-branch), where we
still don't have anything special for those
input:
== a.c =
#include stdio.h
#include inttypes.h
int main() {
uint64_t pos = 1;
pos = 1;
if (pos 1 || pos 0xULL) {
printf(fail\n);
return 1;
}
printf(ok\n);
return 0;
}
= end of a.c =
command lines:
$ gcc a.c
$
--
What|Removed |Added
OtherBugsDependingO||21418
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21442
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-05-09
10:03 ---
The problem is that, while looking for AbstractInterruptibleChannel (a
superclass of SelectableChannel), we do not look into the imports of
SelectableChannel.
*** This bug has been marked as a duplicate of
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-05-09
10:03 ---
*** Bug 21442 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--
Bug 21418 depends on bug 21442, which changed state.
Bug 21442 Summary: problem with imports and multifile builds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21442
What|Old Value |New Value
Consider the following short function:
void Tst1(float* __restrict__ SrcP, float* __restrict__ DstP, int Len)
{
for (int x=0; xLen; x++)
{
DstP[x] = SrcP[x] * SrcP[x];
}
}
If this function is compiled with:
g++41 -O -S TstPow.cpp
--- Additional Comments From vaclav dot ovsik at i dot cz 2005-05-09 10:47
---
Subject: Re: thread lib posix = runtime gij segfaults on Debian G/L Woody
On Fri, May 06, 2005 at 01:45:49PM -, pinskia at gcc dot gnu dot org wrote:
This sounds like recursive mutexes are not working
The following function is not vectorised while there is a sqrt vector function
available.
#include math.h
void Tst1(float* __restrict__ SrcP, float* __restrict__ DstP, int Len)
{
for (int x=0; xLen; x++)
DstP[x] = sqrt(SrcP[x]);
}
Compiled with
g++41 -O -ffast-math -S
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-09
11:15 ---
Reduced testcase is following. The root of the problem is that when we declare
strings of different length in the same character(len=*) declaration, all
strings are truncated to the length of the first
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-05-09
11:18 ---
Ah! I understand now. Sorry, your initial report wasn't clear. Yes, I agree
this is incorrect.
--
What|Removed |Added
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-09
11:27 ---
Subject: Bug 19155
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-09 11:21:02
Modified files:
libgfortran/io : unix.c
libgfortran:
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org |org
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-05-09 11:30 ---
Could you please post backtrace of segfault? with both gcc-4.0 and gcc-3.4 if it
is different.
--
What|Removed |Added
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-09
11:31 ---
Subject: Bug 19155
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-09 11:27:06
Modified files:
gcc/testsuite :
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-09
11:37 ---
I don't close this one since NIST test FM110 is not fixed with this patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19155
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-09
11:53 ---
Subject: Bug 21427
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-05-09 11:48:12
Modified files:
gcc/cp :
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-09
11:56 ---
Subject: Bug 21427
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-09 11:52:45
Modified files:
gcc/testsuite : ChangeLog
Added files:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
12:01 ---
Does -fno-strict-aliasing fix the problem?
Also is there any warnings from -Wstrict-aliasing?
If so this might not be a bug in gcc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21461
--- Additional Comments From tobi at gcc dot gnu dot org 2005-05-09 12:05
---
Are you going to review that patch, Paul? I don't think anybody else is
qualified.
--
What|Removed |Added
--- Additional Comments From tobi at gcc dot gnu dot org 2005-05-09 12:06
---
I don't think so. Several people have used it, and noone complained about weird
things happening.
--
What|Removed |Added
--- Additional Comments From giovannibajo at libero dot it 2005-05-09
12:18 ---
There are others unqualified names as default template parmaters, for
instance allocator. A good testcase would be something like:
--
struct less;
struct allocator;
struct
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
12:20 ---
Closing as works for me.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From duraid at octopus dot com dot au 2005-05-09
12:20 ---
(In reply to comment #3)
Does -fno-strict-aliasing fix the problem?
Yes, oops.
Also is there any warnings from -Wstrict-aliasing?
No.
If so this might not be a bug in gcc.
Indeed. Sorry!
--
--- Additional Comments From nathan at gcc dot gnu dot org 2005-05-09
12:21 ---
2005-05-08 Nathan Sidwell [EMAIL PROTECTED]
PR c++/21427
Backport 2005-03-01 Nathan Sidwell [EMAIL PROTECTED]
* class.c (update_vtable_entry_for_fn): Don't crash on invalid
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
12:21 ---
Confirmed.
--
What|Removed |Added
Severity|normal
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
12:21 ---
Confirmed.
--
What|Removed |Added
Severity|normal |minor
--- Additional Comments From duraid at octopus dot com dot au 2005-05-09
12:24 ---
Actually, I shouldn't have closed this so hastily. The code _is_ pretty dirty
but I'm not sure GCC is really doing something legal at -O2.
--
What|Removed |Added
--- Additional Comments From pcarlini at suse dot de 2005-05-09 12:29
---
I see, thanks. Indeed, I don't remember having paid attention to default
template
arguments. Let's wait a bit for Gaby's opinion on the whole issue, and, in case,
let's quickly fix those problems.
--
The following code makes g++ 3.4.4 and g++ 3.3.6 (Debian) crash on my system.
Adding the missing default argument for arg1 fixes the crash
templatetypename F
void test(F function, bool arg0 = false, bool arg1)
{
}
int main()
{
test(main);
}
Detailed G++ versions:
g++-3.3
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
12:53 ---
Confirmed and not a regression.
Here is the backtrace:
#0 convert_default_arg (type=0xb7bf9804, arg=0x0, fn=0xb7c8c948, parmnum=2)
at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/cp/call.c:4513
#1
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-09
13:00 ---
Looking into it for AdaCore.
--
What|Removed |Added
AssignedTo|unassigned at gcc
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-05-09 13:23 ---
yes, please do not close this bug as i can reproduce it even with
-fno-strict-aliasing, but it seems it breaks at least in four files
(dfgparser.c, list.c, sharing.c, subst.c) so it could take
--- Additional Comments From tobi at gcc dot gnu dot org 2005-05-09 13:40
---
What is wrong is this from the .t02.original dump:
create (temp_ptr, _temp_ptr)
{
char[1:15] * new_item;
{
void * * ptr.0;
ptr.0 = (void * *) new_item;
_gfortran_allocate (ptr.0, 15, 0);
}
--- Additional Comments From duraid at octopus dot com dot au 2005-05-09
13:41 ---
Building on ia64 with the 3.4.4 compiler mentioned above, I get:
#0 red_ReduceInput (Search=0x600ac338, ClauseList=0x60112e18)
at clause.h:525
#1 0x4010dd90 in
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-09
13:41 ---
Subject: Bug 19285
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-09 13:32:30
Modified files:
libjava:
--- Additional Comments From rth at gcc dot gnu dot org 2005-05-09 13:44
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From rth at gcc dot gnu dot org 2005-05-09 13:46
---
Powerpc fixed; ia64 still broken.
--
What|Removed |Added
Summary|[PowerPC] ICE
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-09
13:48 ---
Subject: Bug 19285
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-09 13:34:33
Modified files:
libjava/java/lang:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-09
13:54 ---
Subject: Bug 21285
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-09 13:39:35
Modified files:
libffi :
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-09
13:55 ---
Subject: Bug 21285
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-05-09 13:40:16
Modified files:
libffi :
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-05-09
13:58 ---
This is a call clobbering bug.
We don't pass the address of c to the call, we pass the address of some
substructure.
As a result, we don't think foo can touch c.b, when it can beause of the upcast.
Whee.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-09
14:00 ---
Subject: Bug 19285
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-09 13:50:01
Modified files:
gcc/java :
--- Additional Comments From giovannibajo at libero dot it 2005-05-09
14:03 ---
The real bug is this accepts-invalid:
templatetypename F
void test(F function, bool arg0 = false, bool arg1)
{}
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-05-09
14:04 ---
This is, of course, a regression from 3.4.x
--
What|Removed |Added
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-09
14:20 ---
Subject: Bug 21397
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-09 14:15:51
Modified files:
gcc: ChangeLog
gcc/config/arm :
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
14:22 ---
*** This bug has been marked as a duplicate of 16829 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
14:22 ---
*** Bug 21467 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
Libgfortran doesn't vectorize very well at the moment.
I added some vectorization options to the Makefile on
ia64-unknown-linux-gnu, ran make under script and grepped
for VECTORIZED. This is what I got:
../../../gcc-4.1-20050508/libgfortran/intrinsics/date_and_time.c:235: note:
LOOP
Compiling the following code with gcc -march=i386 -O2 gives and ICE.
-march=i686 doesn't have the same failure.
gcc version 4.1.0 20050507 (experimental)
3.3 and 3.4 both compile the code OK.
typedef unsigned char uint8_t;
typedef unsigned short uint16_t;
typedef union {
uint8_t _b[8];
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-09
14:46 ---
Subject: Bug 21237
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-09 14:45:59
Modified files:
gcc: ChangeLog
Log message:
PR
Fortran subroutine arguments should be marked as
__restrict__. Currently, the following code isn't
vectorized:
$ cat loopsum.f90
subroutine foo(a,b,c,n)
real, dimension(n), intent(in) :: a,b
real, dimension(n), intent(out) :: c
do i=1,n
c(i) = a(i)+b(i)
end do
end
$ gfortran -O -S
--
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21470
Hi!
I am under the impression that the gfortran compiler doesn't (at least in some
cases) handle well the APPEND file access, and rather overwrites the contents
of the file...
Can you help me with that?
Thanks!
Philippe
PS: gfortran -vUsing built-in specs.
Target: i686-pc-linux-gnu
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
14:50 ---
*** This bug has been marked as a duplicate of 9085 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
14:51 ---
*** Bug 13565 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
14:51 ---
Why do people use global registers :(.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21469
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-09
14:53 ---
Subject: Bug 21397
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-09 14:53:20
Modified files:
gcc:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
14:53 ---
Actually -fargument-noalias-global is set to true for fortran and should be
respected instead of
marking them as restrict.
--
What|Removed |Added
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-05-09
15:04 ---
fixed
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From jakub at gcc dot gnu dot org 2005-05-09 15:26
---
Do we really have to call walk_subobject_offsets on every single array element?
Couldn't we delay that to the time anybody would be looking at that info?
Say extend the offsets splay tree, so that there would
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
15:54 ---
If the aliasing information is correct on the VOPS, I would assume that the
vectorizer would not have
problems with it.
Note there is another bug about this option, see PR 17064.
--
What
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-05-09
16:06 ---
That's right Tobi
The patch that fixes this bug and regtests is:
Index: trans-expr.c
===
RCS file:
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-05-09
16:08 ---
Subject: Re: Pointers not passed as subroutine arguments
The following fixes PR16939 and regtests. I'll do a full synchronisatio,
bootstrap and regtest before posting it on the lists:
Best regards
Paul
Compiling lib/csu/common_elf/crtbegin.c in the NetBSD 1.6.2 source tree with gcc
4.0.0 and binutils 2.16, I get complaints from ld:
crtbeginS.o: CALL16 reloc at 0xfc not against global symbol
The call16 is in the .s file generated by gcc, but I can't tell why it's any
different from the others.
--- Additional Comments From pkoning at equallogic dot com 2005-05-09
16:30 ---
Created an attachment (id=8845)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8845action=view)
Preprocessed source file of the code that shows the problem
--
--- Additional Comments From pkoning at equallogic dot com 2005-05-09
16:31 ---
Created an attachment (id=8846)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8846action=view)
Assembly file generated by gcc 4.0.0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21472
I have not found in the bug list of the GCC Bugzilla something about an
invalid warning:
warning: imaginary constants are a GCC extension
when _Complex_I is used with -std=c99 -pedantic. Did I missed something?
Laurent.
errors)
WARNING: gcc.dg/20020523-2.c compilation failed to produce executable
./xgcc -B ./ -v -m32 -march=pentium3 -msse -ffast-math -O2 20020523-1.c
Reading specs from ./specs
Configured with: ../configure --enable-languages=c,c++
Thread model: posix
gcc version 3.4.4 20050509 (prerelease)
./cc1
This bug was reported back in 1998/07/19 by Alexander Favorov msg00504.html .
It is well described by him. The bug still exists as of gcc 3.3.3 .
Its a simple parsing error.
My understanding of C is:
'\10' is ten (decimal)
'\010' is eight (octal)
'\0x10' is sixteen (hexadecimal)
For a
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
17:07 ---
Not in charactors. '/xx' is octal aways.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
17:15 ---
lw $25,%call16(fini_fallthru)($28)
I want to say the above is the problem and it is a local symbol but to GCC it
is a global one.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
17:21 ---
It is a bug in the library as it is being passed correctly to it:
_gfortran_ioparm.position = APPEND;
_gfortran_ioparm.position_len = 6;
--
What|Removed |Added
The program below gives some expressions which gcc could, but does not, evaluate
to true. E.g. gcc considers p-a true, even when a is the first element
of the struct (is this a bug?), but does not consider p-b[3] to be true.
struct foo {int a, b[10];};
int subr(int i, struct foo *p)
{
int
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
17:26 ---
Actually I don't think it is safe to fold any of these.
--
What|Removed |Added
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-09
17:44 ---
Subject: Bug 20695
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-09 17:42:56
Modified files:
gcc/doc: invoke.texi
gcc/config/sh
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-05-09 17:45 ---
This code:
memory.h:413:
*(POINTER *)Freepointer = memory_ARRAY[Size]-free;
memory_ARRAY[Size]-free = Freepointer;
is invalid, because you are changing object of some type via pointer
--- Additional Comments From janis at gcc dot gnu dot org 2005-05-09 19:32
---
sixtrack works fine for me with -m64 -O2 with both SPEC's test input and its
ref output, for all of my daily builds since 20050503, while with the addition
of -fmodulo-sched it gets miscompares. lucas is now
--
What|Removed |Added
Component|tree-optimization |middle-end
Keywords||ice-on-valid-code
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-09
19:59 ---
Subject: Bug 21238
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-09 19:59:17
Modified files:
libstdc++-v3 :
--- Additional Comments From pcarlini at suse dot de 2005-05-09 20:01
---
Fixed for 4.0.1.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-05-09
20:04 ---
Annother testcase. This one fails at -O2 with gcc 4.1.0 20050507 and 4.0.1
20050430.
This is a regression from 3.4.
typedef unsigned long long uint64_t;
register int *env asm (ebp);
register long T0 asm
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-09
20:20 ---
Subject: Bug 18655
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-09 20:20:26
Modified files:
gcc: ChangeLog dwarf2out.c
Log message:
--- Additional Comments From js at jeannot dot org 2005-05-09 20:21 ---
The bug is still present gcc version 3.4.4 20050506.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21351
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-05-09 20:28 ---
*** This bug has been marked as a duplicate of 16185 ***
--
What|Removed |Added
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-05-09 20:28 ---
*** Bug 21469 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
20:30 ---
Hmm, I think only the second example is a dup.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21469
1 - 100 of 179 matches
Mail list logo
