--- Comment #6 from ebotcazou at gcc dot gnu dot org 2006-04-11 06:06
---
Sorry, the patch doesn't seem to help at all.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from amodra at bigpond dot net dot au 2006-04-11 06:09
---
Current 4.0, 4.1, and mainline compile the testcase OK.
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
The following code aligns and increments a pointer twice. I expect an offset of
8 with respect to the original address. Works as expected with an unoptimized
build, but an an offset of 4 is reported when compiled with -O2. The problem
seems to be the cast to (long) before the arithmetic operations
if /bin/sh /usr/local/bin/libtool --silent --tag=CXX
--mode=compile c++ -DHAVE_CONFIG_H -I. -I. -I..
-I../dcop -I. -I../kio/kssl -I../kjs -I../kdefx
-I../kdecore/network -I../dcop -I../libltdl -I../kdefx
-I../kdecore -I../kdecore -I../kdeui -I../kio
-I../kio/kio -I../kio/kfile -I..
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-11 08:28 ---
Confirmed. The following aborts with -O2 and works with -O, optimized tree
dumps are identical.
extern C void abort(void);
struct Test { char *p; };
inline void align(char* p)
{
((long )p) += 3;
((long )p)
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-04-11
08:59 ---
Iguchi-san,
You are correct. The reference to foo with an integer argument is disambiguated
by the use of the keyword.
The only compiler that I have found that handles this correctly is DF5.0/6.0.
struct S
{
S () : d(1.0) {}
S (const double x) : d(x) {}
S (const S x) : d(x.d) {}
const S operator= (const S x) { d = x.d; return *this; }
bool operator (const S x) const { return d x.d; }
double d;
};
S
foo (S a, S b)
{
S c = ({ (a b) ? a : b; });
return c;
}
extern C void
--- Comment #1 from jakub at gcc dot gnu dot org 2006-04-11 09:01 ---
Well, the (void) *a; and (void) *b; certainly don't look ok, so the problem
is earlier. Sorry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27115
--- Comment #2 from falk at debian dot org 2006-04-11 09:40 ---
It seems to me that t.p, which is of type char*, is accessed via an lvalue
of type long. So this is undefined behavior. Or am I missing something?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27114
--- Comment #3 from pluto at agmk dot net 2006-04-11 10:03 ---
-O2 -fno-inline works (tested on x86-64).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27114
The following test demonstrates an incorrect sign in the following division :
#include stdio.h
int main (void)
{
volatile long int n;
n = -2;
printf (%ld\n, (-2147483647L - 1L) / (-n));
return 0;
}
I get a correct result with 4.0.3, and a wrong sign with snapshots 20060325 and
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-04-11 10:33 ---
Oh, right. I was confused about 'char' and didn't see the alias violating.
*** This bug has been marked as a duplicate of 21920 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #91 from rguenth at gcc dot gnu dot org 2006-04-11 10:33
---
*** Bug 27114 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
The cross build for sh64-elf on x86 hosts fails during compilation
of libiberty/ramdom.c for 32bit SHmedia with
libiberty/random.c:362: internal compiler error: in push_reload, at
reload.c:1265
The following is a reduced testcase. It ICEs with -O1 -m5-32media
on sh64-elf.
extern int tbl[32];
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-11 10:46 ---
Overflow flag set problem:
n = -2;
n.10 = n;
D.2132 = -08000 / n.10;
-fwrapv fixes the problem. This is a dup of ...
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--
laszlo dot szakony at philips dot com changed:
What|Removed |Added
Severity|normal |critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26846
I'm bootstrapping trunk on Solaris x86 after a fresh svn up and I get this:
gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute
-fno-common -DHAVE_CONFIG_H -I. -I. -I/u01/var/tmp/gcc_trunk_svn/gcc/gcc
--- Comment #1 from brett dot albertson at stratech dot com 2006-04-11
14:44 ---
nevermind. svn update error.
--
brett dot albertson at stratech dot com changed:
What|Removed |Added
--- Comment #2 from laurent at komite dot net 2006-04-11 15:06 ---
(In reply to comment #1)
Overflow flag set problem:
n = -2;
n.10 = n;
D.2132 = -08000 / n.10;
-fwrapv fixes the problem. This is a dup of ...
I'm not sure this is just an overflow problem, it might
--- Comment #3 from vincent at vinc17 dot org 2006-04-11 15:16 ---
(In reply to comment #2)
which is incorrect since the input domain is not symmetric wrt 0.
I disagree. Could you give an explicit example?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27116
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-04-11 15:25 ---
I mean the middle-end probably does some interesting foldings of -2147483647L
- 1L as the result -08000 has the overflow flag set. It doesn't do it with
-fwrapv though.
--
--- Comment #4 from avi at argo dot co dot il 2006-04-11 15:36 ---
Benchmark results, 32 bit code, various methods
On an athlon 64:
bts reg, (reg): 1 cycle
bts reg, (mem): 3 cycles
C code (reg):1 cycle
C code (mem):5 cycles
On a Xeon:
bts reg, (reg): 6
--- Comment #5 from avi at argo dot co dot il 2006-04-11 15:38 ---
Created an attachment (id=11243)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11243action=view)
benchmark for various set_bit() implementions
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25671
--- Comment #6 from avi at argo dot co dot il 2006-04-11 15:39 ---
oops, the benchmark was for bts. will do again for bt.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25671
--- Comment #5 from vincent at vinc17 dot org 2006-04-11 15:46 ---
(In reply to comment #4)
I mean the middle-end probably does some interesting foldings of
-2147483647L
- 1L as the result -08000 has the overflow flag set.
The bug also occurs with: (long) -2147483648LL.
--
--- Comment #6 from vincent at vinc17 dot org 2006-04-11 15:50 ---
BTW, concerning the overflow flag, I think it comes from the sign cancellation:
the long constant -2147483648 is replaced its opposite, but the opposite is not
representable in a long, hence the overflow.
--
--- Comment #7 from avi at argo dot co dot il 2006-04-11 15:53 ---
Created an attachment (id=11244)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11244action=view)
bt instruction benchmark
redone the test for test_bit(), this time always forcing a memory access:
Athlon 64:
--- Comment #7 from guillaume dot melquiond at ens-lyon dot fr 2006-04-11
15:55 ---
I disagree. Could you give an explicit example?
Sorry, my mistake, I should not have suggested this testcase: this optimization
is indeed fine (yet GCC 4.1 does not apply it). The following testcase
int foo(int i)
{
char buffer[10];
return buffer[i];
}
does not warn about the use of uninitialized array buffer. While
int foo(int i)
{
char buffer[10];
return buffer[2];
}
does. Likewise for C++.
--
Summary: Should warn about uninitialized use of variable array
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-11 17:25 ---
Can you give some sources that don't use automake? Because it is hard to
follow what is wrong in this bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-11 17:30 ---
Related to PR 10138.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-11 17:39 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code, wrong-
|
--- Comment #4 from rsandifo at gcc dot gnu dot org 2006-04-11 17:43
---
Subject: Bug 27073
Author: rsandifo
Date: Tue Apr 11 17:43:07 2006
New Revision: 112861
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112861
Log:
PR rtl-optimization/27073
* gcse.c
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-11 17:46 ---
This is why Changing reload is hard to do correctly :).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from mckinlay at redhat dot com 2006-04-11 18:08 ---
You are correct - I didn't notice that setTcpNoDelay, etc, call getImpl() -
however, this could be fixed if neccessary.
The question is whether this fix is the best one. Is there any disadvantage
(performance or
--- Comment #12 from aph at gcc dot gnu dot org 2006-04-11 18:10 ---
Not worth backporting to 4.0.
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-11 18:10 ---
I would not doubt this was PR 26986.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Using built-in specs.
Target: powerpc-apple-darwin8.5.0
Configured with: ../gcc/configure --prefix=/Users/dir/gfortran
--enable-languages=c,f95
Thread model: posix
gcc version 4.2.0 20060411 (experimental)
[dranta:~/tests] dir%
--
Summary: Undefined symbols: ___dso_handle
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-11 18:20 ---
You need a newer cctools.
See:
http://gcc.gnu.org/ml/gcc/2006-03/msg00507.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Binary operator functions require their arguments to have intent(in).
Gfortran currently doesn't enforce this, ifort does.
$ cat oper-fun.f90
module mymod
interface operator (.foo.)
module procedure foo_int
end interface
contains
function foo_int (a, b)
integer:: foo_int
G++ does not seem to search for classes for friend class declaration outside
the current namespace.
The following code does not work with G++ 4.0.3/4.1.0.
class bar;
namespace NS
{
class foo
{
private:
friend class bar;
static int var;
};
int foo::var = 0;
}
class
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-11 18:56 ---
You did not read the changes page:
http://gcc.gnu.org/gcc-4.0/changes.html
When declaring a friend class using an unqualified name, classes outside the
innermost non-class scope are not searched:
class A;
This PR was posted to the list by Philippe Schaffnit
http://gcc.gnu.org/ml/fortran/2006-04/msg00131.html
The testcase provided reduces to:
PROGRAM Test
INTEGER :: Array(2, 3) =
reshape ((/1,4,2,5,3,6/),(/2,3/)), Brray(2, 3) = 0
Array(1,:) = Function_Test (Array(1,:))
--- Comment #6 from gerald at gcc dot gnu dot org 2006-04-11 20:09 ---
Subject: Bug 23829
Author: gerald
Date: Tue Apr 11 20:09:32 2006
New Revision: 112865
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112865
Log:
PR libgcj/23829
* configure.ac: Link against
I was writing a routine to shift bits along an array. I want the compiler to
use the shrdl assembler command. It will do this if I load the values into an
(unsigned long long) value, bit it does a whole lot more - taking 22 seconds
to shift 102400 words on an 500MHz Intel PIII. The enclosed C
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-11 20:42 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from csm at gnu dot org 2006-04-11 20:58 ---
I'm not sure I understand your situation. Are you doing:
SecureRandom r = new SecureRandom ();
for (...)
r.getBytes (...); // produces the same bytes each time
Or
for (...)
{
SecureRandom r = new
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-04-11 21:24 ---
Bootstrapping the fix right now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19719
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-04-11 23:00
---
Subject: Bug 26122
Author: mmitchel
Date: Tue Apr 11 22:59:57 2006
New Revision: 112869
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112869
Log:
* g++.dg/parse/dtor7.C: New test.
*
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-04-11 23:00
---
Subject: Bug 26295
Author: mmitchel
Date: Tue Apr 11 22:59:57 2006
New Revision: 112869
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112869
Log:
* g++.dg/parse/dtor7.C: New test.
*
--- Comment #8 from steven at gcc dot gnu dot org 2006-04-11 23:03 ---
Code size issue
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO|
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-04-11 23:13 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-04-11 23:17
---
Fixed at least on the mainline but still needs to fixed on the 4.1 branch.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from kazu at gcc dot gnu dot org 2006-04-11 23:47 ---
Subject: Bug 26557
Author: kazu
Date: Tue Apr 11 23:47:35 2006
New Revision: 112870
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112870
Log:
Backport from mainline.
2006-03-13 Roger Sayle
--- Comment #8 from david at jpackage dot org 2006-04-12 00:11 ---
The first case. There is only one instance of SecureRandom. The calls to
nextBytes() are on the same object.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24481
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-04-12 01:14 ---
GRRR.
This is partly caused by the patch for PR 23669.
(In reply to comment #7)
I disagree. Could you give an explicit example?
Sorry, my mistake, I should not have suggested this testcase: this
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-12 01:17 ---
I don't see any attached sources or .s files.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-04-12 01:18
---
Subject: Bug 26122
Author: mmitchel
Date: Wed Apr 12 01:18:06 2006
New Revision: 112879
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112879
Log:
PR c++/26122
* parser.c
--- Comment #7 from mmitchel at gcc dot gnu dot org 2006-04-12 01:19
---
The ICE is now fixed.
I'm not sure if the failure to diagnose the fact that a non-virtual function
has a pure specifier in a template class is a regression or not.
--
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-04-12 01:20 ---
The C++ patch fixes the problem with this code and it also finished
bootstrapping without any regression so please test it fully and submit it
instead of your hack.
--
pinskia at gcc dot gnu dot org changed:
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27073
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27044
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26891
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26976
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26779
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25031
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26743
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11254
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10274
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26257
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2006-04-12 01:24
---
I only have access to the free versions of Intel version 8.0 and version 9.0
and both gave aborted compilation on the test case for ambiguity.
Next step is to check the standards, which I presume Paul has done.
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-12 01:25 ---
Reopening to ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-12 01:25 ---
AS works for me.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-04-12 02:05
---
Subject: Bug 26295
Author: mmitchel
Date: Wed Apr 12 02:05:21 2006
New Revision: 112881
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112881
Log:
PR c++/26295
* decl.c (grokdeclarator):
--- Comment #7 from mmitchel at gcc dot gnu dot org 2006-04-12 02:06
---
Fixed in 4.1.1.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-04-12 02:25
---
Looking at the standard:
Looking in the F95 Standard:
NOTE 12.4
The dummy argument names may be different because the name of a dummy argument
is not a characteristic.
Also, allowing the use of a keyword
--- Comment #17 from mmitchel at gcc dot gnu dot org 2006-04-12 03:06
---
The fix for the bug in Comment #7 is to implement DR224.
The problem here is that we think that A is a dependent type; as such, it might
be int, and the initialization would be valid. However, A is
--- Comment #9 from vapier at gentoo dot org 2006-04-12 04:01 ---
Created an attachment (id=11245)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11245action=view)
gcc-4.1.0-arm-bigendian.patch
gcc-4.1.x needs slight tweak since all the ARM_FLAG_* defines have been cut
this patch
--- Comment #9 from csm at gnu dot org 2006-04-12 04:46 ---
Created an attachment (id=11246)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11246action=view)
SecureRandom setSeed test
I'm testing a patch for this.
Note that the attached test case will repeatedly output the same
--- Comment #9 from guillaume dot melquiond at ens-lyon dot fr 2006-04-12
05:28 ---
This is undefined only if b is known to be negative otherwise it is defined.
What is undefined? The value of b does not matter here. As soon as a is
INT_MAX, the computed value with the optimization
81 matches
Mail list logo
