--- Comment #3 from pinskia at gcc dot gnu dot org 2007-02-27 07:01 ---
Before we would produce:
i = &a + 12B;
i = i - 4B;
D.1616 = &a - 4B;
if (i > D.1616)
Now we produce:
i = &a + 12B;
D.1620 = i > &a;
i = i - 4B;
if (D.1620)
Which is better because we can actually f
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-02-27 06:55 ---
The comment from the code:
For pointer types we assume overflow doesn't happen.
That is true but you can cause an overflow to happen when you transform the
code this way.
Mine, I have a fix.
--
pinskia at gcc
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-02-27 01:59 ---
It works in the official 3.3.3 and 3.4.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30962
--- Comment #6 from gzljg at hotmail dot com 2007-02-27 01:57 ---
Subject: RE: cause compile error for "const anonymous class object"
Hi Pinskia,
I update the notes there, can you take a look?
Thanks.
Gavin
>From: "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]>
>Reply-To: [EM
--- Comment #2 from zsojka at seznam dot cz 2007-02-27 00:36 ---
(In reply to comment #1)
>
> *** This bug has been marked as a duplicate of 29473 ***
>
Sorry, I was searching at http://gcc.gnu.org/bugzilla/query.cgi in 'Open' bugs
only. (anyway, this is another case this bug appears)
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29473
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-02-27 00:22 ---
*** Bug 30976 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-02-27 00:22 ---
*** This bug has been marked as a duplicate of 29473 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
gcc versions tested (all have this problem on both architectures):
x86_64
3.4.6 4.1.1 4.1.2
i686
3.4.6 4.1.1
Reduced testcase: main.cpp
---
struct o {
virtual void a() { }
};
int main(int,char**) {
new o();
return 0;
}
When a() is removed or set as non-virtual,
--- Comment #5 from gzljg at hotmail dot com 2007-02-26 23:35 ---
Subject: RE: cause compile error for "const anonymous class object"
CORRECTION: "Suse 10" should be read as "Suse 9".
Can some one verify the official release of gcc 3.3.5?
>From: "pinskia at gcc dot gnu dot org" <[EM
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-26 23:20 ---
I think this is a case where combine (and other passes) don't know that eq is
always signed extended (when the true is not -1):
(insn 9 8 10 2 (set (reg:SI 123)
(eq:SI (reg:SI 3 3 [ a ])
(reg:SI 4
--- Comment #4 from gzljg at hotmail dot com 2007-02-26 23:14 ---
I would rather to blame on Suse 10(I happend to verify on that machine). It
doesn't work for a gcc 3.3.5(prerelease) version ===>
myweb:> g++ -v
Reading specs from /usr/lib/gcc-lib/i586-suse-linux/3.3.5/specs
Configured w
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-02-26 23:00 ---
(In reply to comment #2)
> Not sure what you mean by "MyAnonymous = {};" to initialize it... if change
> to:
You example which you gave works for me with that:
const class
{
public:
int foo() const
{
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-02-26 22:56 ---
Well this is undefined code really. You are calling the function via the wrong
type.
If you do:
c.t((FPTR)(FPTR1)&C::C_bad);
And use it as a FPTR1, it works.
FPTR1 is defined as:
typedef void (B::*FPTR1)();
--- Comment #2 from gzljg at hotmail dot com 2007-02-26 22:55 ---
Not sure what you mean by "MyAnonymous = {};" to initialize it... if change to:
const class { /* */ } MyAnonymous = {};
will cause another error:
"MyAnonymous' must be initialized by constructor, not by '{...}'
--
--- Comment #2 from ingo dot donasch at L-3com dot com 2007-02-26 22:51
---
Created an attachment (id=13118)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13118&action=view)
output from: g++ -v -save-temps -g -Wall a.cpp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30975
--- Comment #1 from ingo dot donasch at L-3com dot com 2007-02-26 22:49
---
Created an attachment (id=13117)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13117&action=view)
ref to C_good is ok, ref to C_bad crashes
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30975
if a ptr to member function declaration differs from the prototype of the
actual function being used, and the function is implemented in a subclass, and
inherits from multiple base classes, the 4.x compiler generates a 0 for the
__delta which cause the appl to crash when the function is called thro
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot
|dot org
--- Comment #3 from hbent at cs dot oberlin dot edu 2007-02-26 21:38
---
I'm not clear on what you're saying. Is binutils not going to work at all for
this target? It can't be built natively AFAIK, so I'm not sure what toolchain
I should be using if binutils isn't going to work.
--
--- Comment #3 from burnus at gcc dot gnu dot org 2007-02-26 21:36 ---
> Tobias, the same happens if the MODULE foo contains anything and the ONLY part
> actually lists something. I omitted this to keep the testcase short.
Good news. That means that indicates that my patch does the righ
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-02-26 21:32 ---
Actually wait, you are using binutils but this target really defaults to the
old as and not binutils at all.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30974
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-26 21:30 ---
static bool
pdp11_assemble_integer (rtx x, unsigned int size, int aligned_p)
{
if (aligned_p)
switch (size)
{
case 1:
fprintf (asm_out_file, "\t.byte\t");
output_addr_const_pdp11 (as
I have an x86 NetBSD box and am attempting to build gcc for pdp11-dec-bsd. I
have binutils 2.17 installed and configured for that target, and I have
includes and libraries from the latest revision of 2.11BSD.
configure is run as
../configure --target=pdp11-dec-bsd --enable-languages=c --with-gmp=
--- Comment #10 from tkoenig at gcc dot gnu dot org 2007-02-26 21:16
---
Subject: Bug 30865
Author: tkoenig
Date: Mon Feb 26 21:16:00 2007
New Revision: 122342
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122342
Log:
2007-02-26 Thomas Koenig <[EMAIL PROTECTED]>
--- Comment #9 from mmitchel at gcc dot gnu dot org 2007-02-26 20:19
---
I'm sorry; I did apparently misunderstand. My reading of the report was that x
did not become 2, and that this made the submitter unhappy.
I agree that x should not become 2. Although "2" is a valid *representat
--- Comment #3 from burnus at gcc dot gnu dot org 2007-02-26 20:17 ---
Patch.
Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c (Revision 122328)
+++ gcc/fortran/primary.c (Arbeitskopie)
@@ -773,7 +773,
--- Comment #2 from tkoenig at gcc dot gnu dot org 2007-02-26 19:53 ---
(In reply to comment #1)
> I have a patch to permit gfc_check_random_seed to deal with arguments
> with the optional attribute set. I was waiting on pault's size0/size1
> patch to hit the tree to see if it does the
--- Comment #3 from ubizjak at gmail dot com 2007-02-26 19:51 ---
(In reply to comment #2)
> Shouldn't rtl invariant motion catch this?
It would be nice, but the problem is again in the fact that we lie to the
compiler about supported instructions. This one is not a valid x86 insn:
(in
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2007-02-26 19:18
---
Investigating.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Assign
--- Comment #8 from bangerth at dealii dot org 2007-02-26 19:10 ---
Mark,
I think you misunderstood: the value *should* be set to 'true' (==1), but is
set to '2'. Or do you mean that '2' is another valid representation of 'true'
and that therefore this is ok?
W.
--
bangerth at deali
--
bangerth at dealii dot org changed:
What|Removed |Added
Keywords||wrong-code
Target Milestone|--- |4.2.0
http:/
--- Comment #10 from eres at il dot ibm dot com 2007-02-26 18:34 ---
I think that the way -fnsafe-math-optimization violates ieee is important.
Introducing flag_signed_zeros, as you mensioned before, enforce
-fnsafe-math-optimization to honor signed zero. So I think MVE should honor
that
--- Comment #3 from eres at il dot ibm dot com 2007-02-26 18:26 ---
Sure, sorry about that,-funsafe-math-optimizations is more suitable here.
The testcase also fails when -funsafe-math-optimizations is used (fsigned-zeros
is set in that case which means the testcase should not have been
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-02-26 18:24 ---
Both -ffast-math and -funsafe-math-optimizations violate IEEE math specs so
this is an invalid bug. At one point -funsafe-math-optimizations used to not
honor signed zero but recently you have:
-flag_signed_zeros wi
--- Comment #8 from eres at il dot ibm dot com 2007-02-26 18:11 ---
MVE is enabled with -funsafe-math-optimizations as it changes the order of
summation. I think it should honor signed zero, which it does not in the
current implantation. I agree that -funsafe-math-optimizations is mor
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-02-26 18:02 ---
Actually it turns out this is not a bug but rather you did not read the full
documentation:
http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/SH-Options.html
-mieee
Increase IEEE-compliance of floating-point code. At the
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-02-26 17:57 ---
-ffast-math violates the IEEE standard in some cases so why is this option
being used to test an ieee math testcase?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-02-26 17:54 ---
Closing as works for me as requested by the reporter.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-02-26 17:54 ---
> Still works on x86_64, so it's a target issue.
There really has not been any rs6000 changes lately so I am going to say
middle-end until I get to look into it on powerpc-linux-gnu.
--
pinskia at gcc dot gnu do
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.3.0 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30970
--- Comment #4 from dominiq at lps dot ens dot fr 2007-02-26 17:50 ---
Subject: Re: The polyhedron test 'fatigue.f90' is no longer working.
> Still works on x86_64, so it's a target issue.
Nevertheless a regression.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30969
--- Comment #2 from burnus at gcc dot gnu dot org 2007-02-26 17:39 ---
> The bug in gfortran is that "Hello" & is correctly seen as non-character
> context whereas "Hello" & is wrongly regarded as character context.
The last line should be: "Hello"& without space between " and
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-02-26 17:37 ---
With -ffast-math -0 is treated the same as 0. Which would make this report
invalid...?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30971
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-02-26 17:35 ---
Shouldn't rtl invariant motion catch this?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-02-26 17:34 ---
Still works on x86_64, so it's a target issue.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-02-26 17:33 ---
They also don't on x86_64:
f:
.LFB2:
movslq %edi,%rdi
movslq %esi,%rsi
cmpq%rsi, %rdi
sete%al
movzbl %al, %eax
ret
.LFE2:
.size f, .-f
.globl f1
--- Comment #1 from burnus at gcc dot gnu dot org 2007-02-26 17:11 ---
Confirmed.
One needs the second "&" for:
"Hello&
& World"
But one does not need it for:
"Hello" &
, "World"
The following seems to be a gfortran/ifort extension:
"Hello&
World"
For this case, the warning
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-02-26 16:54 ---
Tobias, the same happens if the MODULE foo contains anything and the ONLY part
actually lists something. I omitted this to keep the testcase short.
Same problem here:
$> cat foo2.f90
MODULE foo
INTEGER :: x
END MOD
--- Comment #1 from burnus at gcc dot gnu dot org 2007-02-26 16:47 ---
I checked: " USE foo, ONLY:" is syntactically correct.
The problem is that "only_flag = 1;" and no symbol is in the only-list.
I think one needs to modify module.c's "read_module", but I fail quickly to see
were th
--- Comment #2 from uwe at netbsd dot org 2007-02-26 16:35 ---
(In reply to comment #1)
> On the second thought, I might be confused here. Please, leave UNCONFIRMED.
> I'll do more testing and get back with an update later today. Sorry.
That was a pilot error. Please close. Sorry fo
--- Comment #1 from ubizjak at gmail dot com 2007-02-26 15:48 ---
It is a target issue. Working on a fix.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #6 from doug dot gregor at gmail dot com 2007-02-26 15:26
---
This looks like a straightforward fix to build_common_tree_nodes2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30666
--- Comment #6 from eres at il dot ibm dot com 2007-02-26 15:01 ---
It seems that initializing the expansion with -zero (instead of +zero)
will solve this problem.
According IEEE standard if we have -
x += something; initializing x with -0 will cause x to get the sign of
something.
-0
--- Comment #2 from istvan at benedek-home dot de 2007-02-26 14:52 ---
>?: is a lvalue in C++
Why? I'm missing the quotation from the Holy Standard!
IMHO:
we deal with two nonmodifiable lvalues here.
from HS 5.12 3:
Because E1 can't be converted to type 'reference to T2', the Section '
$> cat foo.f90
MODULE foo
END MODULE
PROGRAM test_foo
USE foo, ONLY:
INTEGER :: foo
foo = 1
END PROGRAM
$> gfortran-svn -g -Wall foo.f90 && echo ok
ok
$> gfortran-svn -v
gcc version 4.3.0 20070220 (experimental)
If ", ONLY:" is removed in the USE, gfortran gives:
foo.f90:6.16:
INTEGER
On Thursday 08 February 2007 16:02, Graham Stott wrote:
> All,
>
> Not a bug in GCC the result is correct as you've only asked for a 32-bit
> multiply.
Hi again,
The problem was not that "mull" is used, but that "gcc 3.4.6" generates highly
un-optimized code when I for example multiply a 16-bit
WinAVR, the AVR compiler package for Windows has some problems with Vista. I
looked into it and think I have found the problem, which is in the GCC compiler
and possibly in other parts of the GCC toolchain.
The error shows up in any compilation with avr-gcc.exe:
avr-gcc: _spawnvp: No such file o
--- Comment #5 from eres at il dot ibm dot com 2007-02-26 13:51 ---
The reason that this tescase fails is because the expansion is been initialized
with +0, which means that it's final result will be +0 and not -0 as expected.
expansion += d --> expansion += -0 --> +0
--
http://gc
--- Comment #1 from eres at il dot ibm dot com 2007-02-26 13:38 ---
Created an attachment (id=13116)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13116&action=view)
assembly file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30971
When changing n to be 0 (instead of 10) in
testsuite/gcc.c-torture/execute/ieee/mzero6.c the return value is 0 but it
should be -0,
which causes the program to abort the execution.
gcc mzero6.c -w -O2 -fno-show-column -lm -funroll-loops --fast-math -O2
-o out -da
if (__builtin_copysign (1.0
The testcase:
--cut here--
#define N 256
int b[N];
void test()
{
int i;
for (i = 0; i < N; i++)
b[i] = 0;
}
--cut here--
compiles with '-O2 -msse2 -ftree-vectorize' into:
test:
movl$16, %eax
pxor%xmm0, %xmm0
movdqa %xmm0, b
.p2align 4,,7
.L2:
--- Comment #2 from dominiq at lps dot ens dot fr 2007-02-26 13:31 ---
Created an attachment (id=13115)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13115&action=view)
test working with -O3 -ffast-math -funroll-loops
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30969
--- Comment #1 from dominiq at lps dot ens dot fr 2007-02-26 13:30 ---
Created an attachment (id=13114)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13114&action=view)
this test works only without optimization
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30969
With powerpc-apple-darwin7.9.0, version 4.3.0 20070223,
the polyhedron test 'fatigue.f90' (see
http://www.polyhedron.co.uk/pb05/polyhedron_benchmark_suite.html)
gives
...
Simulation terminated.
This sample will never fracture.
The imposed stress is below the fatigue limit.
See the output file for
The following program gives a bogus warning when
compiled with -Wall or -std=f95 or -std=f2003:
program gfcbug59
print *, "Hello"&
// " World" ! Bogus warning with -Wall or -std=f95 or -std=f2003
end program gfcbug59
% gfc -Wall gfcbug59.f90
gfcbug59.f90:3.8:
// " World"
--- Comment #9 from anlauf at gmx dot de 2007-02-26 13:05 ---
(In reply to comment #8)
> the below patch looks like it fixes the problem. any chance this could be
> tryed on the reported problem ?
If somebody with sufficient resources can provide a binary
(like FX's snapshots), I will
--- Comment #7 from filippo dot arcidiacono at gmail dot com 2007-02-26
13:01 ---
> is wrong, it should be instead:
> mov #1, r1
OK!
This is what I get if I use __builtin_nanf() instead of nanf.
But using nanf there isn't any undefined nanf symbol in the obiect
generated, as expected,
--- Comment #4 from eres at il dot ibm dot com 2007-02-26 11:46 ---
Created an attachment (id=13113)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13113&action=view)
assembly file (PPC)
It seems that problem is in the initialization of the expansion
(which related to the sign of t
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30967
Testcase:
int f1(int a, int b)
{
return a == b;
}
--
We produce right now:
_f1:
xor r4,r3,r4
cntlzw r4,r4 <--- sign never 1
srwi r4,r4,5 <--- upper bits defined as 0
extsw r3,r4
blr
The sign extend is incorrect as r4's sign will never be 1 and all t
Both of these functions should produce the same asm:
int f(int a, int b)
{
long long c = a;
long long d = b;
return c == d;
}
int f1(int a, int b)
{
return ((long long) a) == ((long long)b);
}
But don't at least on powerpc-darwin:
_f:
srawi r0,r3,31
srawi r2,r4,31
--- Comment #17 from rguenth at gcc dot gnu dot org 2007-02-26 10:33
---
I split the issue in comment #10 to PR30965 as it is a slightly different
issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19431
(split from PR19431)
#include
#include
extern void assign( long* variable, long v )
{
std::transform( variable, variable + 1, variable,
std::tr1::bind( std::plus< long >(), 0L, v ) );
}
extern void assign( long& variable, long v )
{
std::transform( &variable, &var
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-02-26 09:52 ---
>In attach you can find the nanf-test.s that doesn't contains any reference
> to nanf symbol.
That is ok, because nanf("") is foldded into a constant and the function is not
called.
I don't read sh asm that well bu
--- Comment #16 from paolo at gcc dot gnu dot org 2007-02-26 09:36 ---
Subject: Bug 28080
Author: paolo
Date: Mon Feb 26 09:36:39 2007
New Revision: 122329
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122329
Log:
2007-02-26 Paolo Carlini <[EMAIL PROTECTED]>
PR libst
--- Comment #5 from filippo dot arcidiacono at gmail dot com 2007-02-26
09:29 ---
Created an attachment (id=13112)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13112&action=view)
assembler code of nanf-test.c
Following a piece of the objdump of the nanf-test:
:
:
int
main (void)
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-02-26 08:21 ---
No, the const attribute does not cause to produce wrong code.
On powerpc-darwin with your testcase, I get:
mflr r0
lis r3,ha16(LC0)
la r3,lo16(LC0)(r3)
stw r0,8(r1)
stwu r1,-64
--- Comment #3 from filippo dot arcidiacono at gmail dot com 2007-02-26
08:08 ---
Created an attachment (id=13111)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13111&action=view)
prerprocessed file of nanf-test.c
In attach you can find the preprocessed file nanf-test.i of nanf-
79 matches
Mail list logo
