--- Comment #10 from bonzini at gnu dot org 2007-03-07 08:22 ---
Unfortunately, if I fix the fwprop bug (which is actually caused by wrong df
information), I get again
leal-4(%edi), %eax
movl%eax, %edi
movl(%eax), %eax
testl %eax, %eax
The
I tried to build SpiderMonkey 1.60 (http://www.mozilla.org/js/spidermonkey/) on
SunOS 5.9/SPARC, and I got this ICE. That code compiles successfully using GCC
4.1.1 bundled with Linux Fedora Core 6 (x86, 32-bit).
gcc -o SunOS5.9_DBG.OBJ/jscpucfg.o -c -g -DXP_UNIX -DSVR4 -DSYSV -DSOLARIS
-DHAVE_LOC
--- Comment #1 from bugzilla at poradnik-webmastera dot com 2007-03-07
08:32 ---
Created an attachment (id=13156)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13156&action=view)
Preprocessor output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31065
--- Comment #3 from rakdver at gcc dot gnu dot org 2007-03-07 09:15 ---
The same problem appears in the following testcase.
int a[100];
void test (int real_length_of_a)
{
int x = 110;
if (x < real_length_of_a)
a[x]++;
}
--
rakdver at gcc dot gnu dot org changed:
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-03-07 09:33 ---
But real length of a cannot be greater than 100. I guess VRP could be improved
to derive a value range for x in this case ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31058
--- Comment #5 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2007-03-07 09:38 ---
Subject: Re: bogus array overflow warnings in unreachable code
> But real length of a cannot be greater than 100. I guess VRP could be
> improved
> to derive a value range for x in this case
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-03-07 09:39 ---
Uh, yes. So let's teach CCP to convert a[110]++; to builtin_trap then ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31058
--- Comment #1 from pault at gcc dot gnu dot org 2007-03-07 09:41 ---
confirmed - this is an arithmetic error in expr.c(find_array_section).
The following fixes the problem, although it has not yet been regtested.
Paul
Index: gcc/fortran/expr.c
--- Comment #1 from pault at gcc dot gnu dot org 2007-03-07 09:55 ---
Confirmed
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCO
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-07 10:07 ---
Confirmed. For reference:
struct Dummy
{
int operator&(signed int &) { return 4; }
};
struct ICE
{
template
void aj(void)
{
signed int kalle = 9;
int size = Dummy() & kalle;
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-07 10:09 ---
*** This bug has been marked as a duplicate of 26881 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #29 from rguenth at gcc dot gnu dot org 2007-03-07 10:09
---
*** Bug 31065 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #45 from michael dot klein at fazi dot de 2007-03-07 10:13
---
Created an attachment (id=13157)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13157&action=view)
Patch to configure test for comdat support work with binutils snapshots
gcc's configure test for COMDAT sup
On the following testcase:
program test
integer, parameter :: n = 25000
integer :: i
real, dimension(n) :: iener, dens, pres, temp, gamma, cs
do i = 1, 3
call eos (iener, dens, pres, temp, gamma, cs, sheat, cgamma)
end do
contains
subroutine eos (iener, dens, pres, temp, gam
--- Comment #46 from michael dot klein at fazi dot de 2007-03-07 10:20
---
Created an attachment (id=13158)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13158&action=view)
Non-reversed patch to make configure test for comdat support work with binutils
snapshots
--
michael dot
[see http://www.polyhedron.co.uk/pb05/linux/f90bench_AMD.html for the original
polyhedron benchmark results, an explanation of what the benchmark is and the
source code]
Typical timings for the gas_dyn.f90 benchmark on my AMD64/linux system are:
* ifort -O3 -xW -ipo -static -V gas_dyn.f90 -o gas_
I saw the -fipa-pta option in the GCC manual, and decided to try it on
mainline. But... I can't get it to work with any C code (or Fortran):
$ cat a.c
void foo() { ; }
$ gcc -c -O1 -fipa-pta a.c
a.c: In function foo:
a.c:5: error: stmt (0x2a983e4140) marked modified after optimization pass:
re
--- Comment #4 from pault at gcc dot gnu dot org 2007-03-07 10:53 ---
(In reply to comment #3)
> fortran/trans-const.c:278 (because the expr is not an EXPR_CONSTANT). This
> will
> all be fixed when the simplifcation routine for TRANSFER is written.
FX, You are correct - this is effec
--- Comment #7 from mueller at gcc dot gnu dot org 2007-03-07 10:59 ---
I don't think this is the same testcase. you will get any warning in this case,
because the compiler cannot determine that it is supposed to be dead code.
--
mueller at gcc dot gnu dot org changed:
W
--- Comment #8 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2007-03-07 11:02 ---
Subject: Re: bogus array overflow warnings in unrolled loops
> I don't think this is the same testcase. you will get any warning in this
> case,
> because the compiler cannot determine that i
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-03-07 11:27 ---
(In reply to comment #0)
> Maybe we should have MINLOC inlined when there's no mask, stride 1 and
> one-dimensional?
Definitely. We do this for minval, and from glancing at
gfc_conv_intrinsic_minmaxval and gfc_con
--- Comment #9 from mueller at gcc dot gnu dot org 2007-03-07 11:34 ---
well, the unrolled body is generated code, it could set TREE_NO_WARNING (for
example). or it could avoid unrolling if its not a flex array.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31058
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-03-07 12:18
---
(In reply to comment #1)
> We do this for minval, and from glancing at
> gfc_conv_intrinsic_minmaxval and gfc_conv_intrinsic_minmaxloc,
> it should happen already.
No, because we never get into gfc_conv_intrinsic
This bug only occurs with gcc 4.x.x on hpux.
In certain circumstances the parameter for the environment will be assigned as
argument for the command.
I've written some code which will show you the exact problem. You need openssl
to reproduce this test.
The expected output is:
Generating a 1024
--- Comment #1 from b dot krumboeck at rewe-group dot at 2007-03-07 12:33
---
Created an attachment (id=13161)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13161&action=view)
example code to reproduce the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31069
Aurora SPARC Linux release 2.90 (Aurora Corona)/TI UltraSparc IIi (Sabre)
sun4u:
binutils-2.17.50.0.3-6.sparc.sparc
bison-2.3-2.1.sparc
dejagnu-1.4.4-5.1.noarch
expect-5.43.0-5.1.sparc
gcc-4.1.1-30.1.sparc
glibc-2.5-3.1.sparcv9
glibc-2.5-3.1.sparc64
glibc-devel-2.5-3.1.sparc
glibc-devel-2.5-3.1.sp
In spec langauge, %{...} and %W{...} are exactly same, except that %W{...} mark
last argument supplied within as a file to be deleted on failure. According to
this definition, the handling of these two commands is descrepant.
In do_spec_1, the handling of %W{...} is:
4943 case 'W':
{
--- Comment #7 from tkoenig at gcc dot gnu dot org 2007-03-07 14:24 ---
*** Bug 31053 has been marked as a duplicate of this bug. ***
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from tkoenig at gcc dot gnu dot org 2007-03-07 14:24 ---
(In reply to comment #2)
> I believe this has been fixed already by PR30005 since December 5.
Correct. The fix isn't in 4.2 though (which is what I tried :-)
Closing as a duplicate of 30005.
*** This bug has be
--- Comment #1 from dberlin at gcc dot gnu dot org 2007-03-07 14:31 ---
Subject: Re: New: ICE at -O1 -fipa-pta
On 7 Mar 2007 10:32:37 -, fxcoudert at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> I saw the -fipa-pta option in the GCC manual, and decided to try it on
> mainline.
--- Comment #47 from hjl at lucon dot org 2007-03-07 14:33 ---
(In reply to comment #45)
> Created an attachment (id=13157)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13157&action=view) [edit]
> Patch to configure test for comdat support work with binutils snapshots
>
> gcc's c
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-07 14:34 ---
Your argv array is too small.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from lloyd at randombit dot net 2007-03-07 14:47 ---
This is also true for C++ unless -pedantic is specified (which is confusing
since I thought -pedantic-errors was the default for C++, but apparently this
changed at some point). Using '-Wall -Wextra -ansi -std=c++98' giv
--- Comment #3 from b dot krumboeck at rewe-group dot at 2007-03-07 15:27
---
Oh, you're right! Thank you!
I tried to debug for 3 days, without success.
Linux, HPUX, GCC 4.X and GCC 3.4.2, .
You are a hero!
Once again, thank you very much.
PS: Sorry for wasting your time.
best
I tracked it down to the following code, which is not compiled as expected, if
optimization (> O1) is turned on.
Contents of fg.c:
---8<--8<-8<---
extern volatile int ReadyFlag_NotProperlyInitialized;
volatile int ReadyFlag_NotProperlyInitialized=1;
volatile int ReadyFlag_Initializat
--- Comment #1 from a_fisch at gmx dot de 2007-03-07 15:41 ---
Created an attachment (id=13162)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13162&action=view)
Preprocessed source of code sample
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31072
--- Comment #2 from a_fisch at gmx dot de 2007-03-07 15:44 ---
Created an attachment (id=13163)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13163&action=view)
Generated assembler output: powerpc-elf-gcc -O1 -S -o fg_O1.s fg.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31
GNU Fortran 95 (GCC) 4.3.0 20061021 (experimental), MINGW build
I am trying to compile f90 code into objects that generate the symbol names
in stdcall syntax, i.e. [EMAIL PROTECTED]
We need the stdcall decorations since we build a dll that is called from an
app that needs to do all calls with std
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-07 17:11 ---
.sbss is .sdata but in the bss part of it.
If your loader does not zero bss, then you can use -fno-zero-initialized-in-bss
to get the variable not stored in the bss section.
--
pinskia at gcc dot gnu dot org chan
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-07 17:13 ---
> I am trying to compile f90 code into objects that generate the symbol names
> in stdcall syntax, i.e. [EMAIL PROTECTED]
I think you are not looking for -mrtd but for versioned symbols.
-mrtd does:
"Use a different
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-07 17:15 ---
actually this function should be inlined as it is a nested function.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31066
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-03-07 17:19
---
(In reply to comment #1)
> actually this function should be inlined as it is a nested function.
It is inlined. It's the vectorization of the inlined function that is
suboptimal (at least, that's what I diagnose,
--- Comment #4 from a_fisch at gmx dot de 2007-03-07 17:43 ---
Subject: Re: Wrong code for volatile var with initalization
and optimization
My runtime environment is clearing .bss but the problem is that the
initialization value is != 0 . Because of the value != 0 it's not
allo
--- Comment #2 from manu at gcc dot gnu dot org 2007-03-07 17:57 ---
The documentation says that you should use -pedantic to warn about GCC
extensions[*], so I am not sure whether this is valid. But honestly, from the
description of "-std=", I would understand that GNU extensions are dis
--- Comment #3 from joseph at codesourcery dot com 2007-03-07 18:04 ---
Subject: Re: -std=c89 doesn't warn about gcc's "?:" extension
On Wed, 7 Mar 2007, manu at gcc dot gnu dot org wrote:
> The documentation says that you should use -pedantic to warn about GCC
> extensions[*], so I a
--- Comment #4 from satyaakam at yahoo dot co dot in 2007-03-07 18:07
---
Created an attachment (id=13164)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13164&action=view)
assembly code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31049
--- Comment #4 from manu at gcc dot gnu dot org 2007-03-07 18:11 ---
(In reply to comment #3)
> Subject: Re: -std=c89 doesn't warn about gcc's "?:" extension
>
> Where the standard specified with @option{-std} represents a GNU
> extended dialect of C, such as @samp{gnu89} or @samp{gnu99
--- Comment #2 from rth at gcc dot gnu dot org 2007-03-07 18:13 ---
Subject: Bug 30848
Author: rth
Date: Wed Mar 7 18:13:29 2007
New Revision: 122669
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122669
Log:
PR target/30848
* reg-stack.c (emit_swap_insn): If a
--- Comment #9 from ahs3 at fc dot hp dot com 2007-03-07 18:43 ---
Ah, my fault; I wasn't being clear. I still get the error message with -E,
that is true. However, the resulting code from cpp I thought was correct -- it
just produces what I thought was a normal C label, and if I ignor
When casting a const reference of a derived class (which inherits from multiple
classes with virtual methods) to a non-const reference of one of it's base
classes, the resulting non-const base class reference points to an incorrect
address.
system type/gcc build options/version:
Target: x86_64-r
--- Comment #3 from pcarlini at suse dot de 2007-03-07 19:05 ---
Well Ahmed, right now you can't possibly see the exact same error, because
stl_algobase.h does *not* include anymore... Please provide more info.
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915
--- Comment #3 from rth at gcc dot gnu dot org 2007-03-07 19:16 ---
Subject: Bug 30848
Author: rth
Date: Wed Mar 7 19:15:46 2007
New Revision: 122671
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122671
Log:
PR target/30848
* reg-stack.c (emit_swap_insn): If a
--- Comment #4 from rth at gcc dot gnu dot org 2007-03-07 19:18 ---
Subject: Bug 30848
Author: rth
Date: Wed Mar 7 19:18:22 2007
New Revision: 122672
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122672
Log:
PR target/30848
* reg-stack.c (emit_swap_insn): If a
--- Comment #5 from rth at gcc dot gnu dot org 2007-03-07 19:21 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
testing if LLONG_MIN-1 == LLONG_MAX gives different results with -O3 and
without. Here's a short example and the output I get on my machine.
mamie:/home/distrib/lang/pas$cat mini64.c
#include
typedef signed long long int int64;
#define MAXINT64 9223372036854775807LL
#define MININT64 ((-92233720
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-07 20:23 ---
Signed integer overflow is undefined. Either use unsigned or -fwrapv.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-03-07 20:37
---
> well, the unrolled body is generated code, it could set TREE_NO_WARNING (for
> example). or it could avoid unrolling if its not a flex array.
Except it cannot tell sorry, this is exactly the same issue as the b
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-03-07 20:54
---
Sorry, but I don't agree a bit with you. It doesn't have as much false
positives
as other warnings in -Wall. And I think a warning for the testcase in comment
#3
is ok -- the code looks very suspicious. Also the
--- Comment #3 from tkoenig at gcc dot gnu dot org 2007-03-07 21:00 ---
(In reply to comment #2)
> No, because we never get into gfc_conv_intrinsic_minmaxloc. We translate the
> expression directly into a function call by calling
> gfc_conv_intrinsic_funcall() at the head of gfc_conv_in
--- Comment #5 from joseph at codesourcery dot com 2007-03-07 21:06 ---
Subject: Re: -std=c89 doesn't warn about gcc's "?:" extension
On Wed, 7 Mar 2007, manu at gcc dot gnu dot org wrote:
> Sorry, I still don't understand what is the difference between -std=c89 and
> -std=gnu89.
-st
--- Comment #4 from fxcoudert at gmail dot com 2007-03-07 21:09 ---
Subject: Re: MINLOC should sometimes be inlined (gas_dyn is so slw)
> In gfc_conv_intrinsic_function, expr->rank is 0 for minval
> and 1 for minloc (which is bogus).
It's not bogus. The MINLOC is an array of
--- Comment #5 from tkoenig at gcc dot gnu dot org 2007-03-07 21:09 ---
(In reply to comment #3)
> In gfc_conv_intrinsic_function, expr->rank is 0 for minval
> and 1 for minloc (which is bogus). I wonder where this is
> set...
To answer my own question: This is set in gfc_resolve_mi
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-03-07 21:21
---
(In reply to comment #11)
> Sorry, but I don't agree a bit with you. It doesn't have as much false
> positives
> as other warnings in -Wall.
Actually if you read the documention for -Wall, it says enable warnings
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-03-07 21:22
---
Actually comment #3 shows this warning is not easy to avoid at all and should
not be turned on with -Wall at all.
I still had allways said it should not be included in -Wall.
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-03-07 21:22
---
This is why we have this bug -- because loop unrolling creates possibly
unreachable code with out-of-bounds array access.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31058
--- Comment #15 from pinskia at gcc dot gnu dot org 2007-03-07 21:24
---
(In reply to comment #14)
> This is why we have this bug -- because loop unrolling creates possibly
> unreachable code with out-of-bounds array access.
But the warning code is the real cause, sorry but there is no
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-03-07 21:25
---
We might now be able to disable the warning in the second vrp pass -- Dirk, did
you try that after all the early optimizations we now got?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31058
--- Comment #1 from brett dot albertson at stratech dot com 2007-03-07
21:29 ---
(In reply to comment #0)
As of last night, these now PASS again.
Brett
--
brett dot albertson at stratech dot com changed:
What|Removed |Added
-
--- Comment #6 from tkoenig at gcc dot gnu dot org 2007-03-07 21:29 ---
Created an attachment (id=13165)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13165&action=view)
Setting the correct rank in minloc
This makes minloc have rank 0, and allows for
inlining. I guess we'll find
--- Comment #17 from gdr at cs dot tamu dot edu 2007-03-07 21:35 ---
Subject: Re: bogus array overflow warnings in unrolled loops
"rguenth at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| This is why we have this bug -- because loop unrolling creates possibly
| unreachable code w
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-03-07 21:39
---
(In reply to comment #9)>
> If none of those are the case, what bit of info am I not understanding?
Yes "alldone:" are really two seperate tokens in C :).
If you change the definition of LABEL to:
#define LABEL(a
--- Comment #3 from v dot lesk at ic dot ac dot uk 2007-03-07 21:44 ---
Created an attachment (id=13166)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13166&action=view)
Code which triggers bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31027
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfi
--- Comment #18 from mueller at gcc dot gnu dot org 2007-03-07 22:03
---
IIRC there are some cases that are only caught in the 2nd vrp run. It is still
a possibility if this bug cannot be fixed otherwise.
However, I don't see the issue with this testcase.
a) its not a flex array
b)
--- Comment #19 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2007-03-07 22:17 ---
Subject: Re: overflow warnings should not be enabled with -Wall
> IIRC there are some cases that are only caught in the 2nd vrp run. It is still
> a possibility if this bug cannot be fixed ot
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-03-07 22:33 ---
Woops.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|RESOLVED
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-03-07 22:34 ---
I was looking at the bug wrong the first time.
Anyways this is caused by section anchors.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-07 22:39 ---
*** This bug has been marked as a duplicate of 28879 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-07 22:39 ---
*** Bug 31064 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from sdirkse at gams dot com 2007-03-07 22:52 ---
Thanks for telling me about the -fwrapv flag, that's good to know - I should
have double-checked my K&R 2nd Edition before sending the bug. But I tried
running the above example with the addition of the -fwrapv flag, and i
--- Comment #23 from paolo at gcc dot gnu dot org 2007-03-07 22:59 ---
Subject: Bug 28080
Author: paolo
Date: Wed Mar 7 22:59:24 2007
New Revision: 122676
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122676
Log:
2007-03-06 Paolo Carlini <[EMAIL PROTECTED]>
PR libst
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-07 23:00 ---
[EMAIL PROTECTED] ~]$ ~/gcc-mainline/bin/gcc t.c -O2 -fwrapv
[EMAIL PROTECTED] ~]$ !./
./a.out
mini64: test 2's-complement arithmetic
minint64-1 = 9223372036854775807
minint64 - 1 == MAXINT64
[EMAIL PROTECTED] ~]$ ~/
--- Comment #4 from sdirkse at gams dot com 2007-03-07 23:10 ---
DOH! I wasn't running the executable compiled with -fwrapv. Using the -fwrapv
flag does indeed make things work as I hoped and as documented.
--
sdirkse at gams dot com changed:
What|Removed
I use
$ ~/gcc/bin/gcc --version
gcc (GCC) 4.3.0 20070307 (experimental)
to compile
double rdtsc_cputick;
double
rdtsc ()
{
unsigned long eax, edx;
asm volatile ("rdtsc" : "=a" (eax), "=d" (edx));
return rdtsc_cputick * ((unsigned long long) edx << 3
--- Comment #53 from js at linuxtv dot org 2007-03-08 01:03 ---
I read all this and the mailing list thread with great interest,
however I think there is a fundamental flaw in the reasoning:
C90 6.2.1.2 / C99 6.3.1.3 defines signed integer overflow
as "implementation-defined behaviour",
--- Comment #54 from pinskia at gcc dot gnu dot org 2007-03-08 01:14
---
(In reply to comment #53)
> I read all this and the mailing list thread with great interest,
> however I think there is a fundamental flaw in the reasoning:
>
> C90 6.2.1.2 / C99 6.3.1.3 defines signed integer ove
--- Comment #6 from roger at eyesopen dot com 2007-03-08 01:55 ---
I suspect this problem is now fully resolved. The patch for PR24427 has been
backported to the gcc-4_1-branch, and additionally on mainline, simplify-rtx.c
has been enhanced to also perform the missed-optimization at the
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-08 02:06 ---
Confirmed, related to PR 22132. The difference between this and that PR is
this one has references while that one was only pointers.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-08 02:09 ---
Oh and PR 22132 was already fixed :).
And the reason why the patch for PR 22132 did not fix this bug is because
comp_ptr_ttypes_const does not take into account REFERENCE_TYPEs.
--
pinskia at gcc dot gnu dot org
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-03-08 03:41 ---
I have a very simple fix to the C front-end that I am testing. The C front-end
causes the DECL_RTL to be created early on.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-03-08 05:50
---
(In reply to comment #6)
> This makes minloc have rank 0, and allows for
> inlining.
No, it's wrong. See F95 13.14.71: "Result Characteristics. The result is of
type default integer. If DIM is absent, the result
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2007-03-08 05:51
---
Here is a patch. Herald, do you want to see if this fixes it for you.
I tested here, but it does not hurt to test some more.
Index: file_pos.c
==
--- Comment #2 from patchapp at dberlin dot org 2007-03-08 06:25 ---
Subject: Bug number PR31011
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-03/msg00459.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #4 from patchapp at dberlin dot org 2007-03-08 06:55 ---
Subject: Bug number PR c++/30917
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-03/msg00463.html
--
http://gcc.gnu.org/bugzil
--- Comment #4 from reichelt at gcc dot gnu dot org 2007-03-08 07:26
---
Subject: Bug 30534
Author: reichelt
Date: Thu Mar 8 07:26:43 2007
New Revision: 122685
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122685
Log:
PR c++/30534
* pt.c (any_template_argument
--- Comment #1 from reichelt at gcc dot gnu dot org 2007-03-08 07:31
---
Subject: Bug 30852
Author: reichelt
Date: Thu Mar 8 07:31:47 2007
New Revision: 122686
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122686
Log:
PR c++/30852
* c-common.c (fold_offsetof_1
--- Comment #2 from reichelt at gcc dot gnu dot org 2007-03-08 07:36
---
Subject: Bug 30852
Author: reichelt
Date: Thu Mar 8 07:36:17 2007
New Revision: 122687
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122687
Log:
PR c++/30852
* c-common.c (fold_offsetof_1
--- Comment #3 from reichelt at gcc dot gnu dot org 2007-03-08 07:39
---
Subject: Bug 30852
Author: reichelt
Date: Thu Mar 8 07:39:04 2007
New Revision: 122688
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122688
Log:
PR c++/30852
* c-common.c (fold_offsetof_1
--- Comment #5 from reichelt at gcc dot gnu dot org 2007-03-08 07:48
---
Fixed on mainline.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #4 from reichelt at gcc dot gnu dot org 2007-03-08 07:49
---
Fixed on mainline, 4.2 branch, and 4.1 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
---
100 matches
Mail list logo
