--- Comment #8 from pinskia at gcc dot gnu dot org 2007-03-20 22:46 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-03-20 23:51
---
I think test.f is not valid Fortran, because size(p,1) is not a valid
specification expression. See 7.1.6 of the F2003 standard: it is a array
inquiry function (size) with an argument that is a variable (p) whose
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-21 00:01
---
(In reply to comment #0)
> CHARACTER(LEN=3), DIMENSION(10) :: Z
> CHARACTER(LEN=10) :: res
> Z(:)="123"
> write(*,'(10A1)') TRANSPOSE(RESHAPE(Z(:)(2:2),(/5,2/)))
> END
Same thing happens with
write(*,'(10A1)')
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-03-21 00:10
---
(In reply to comment #2)
> interface.c:567 is where it all starts.
Thanks for the pointer.
> If complex is excluded from product, we run into a
> problem with the test for the shape of the two operands.
I think
// BUG DEMO for gcc 4.1.2 (and 4.1.1) for 32-bit x86
//
// If operator delete() is over-ridden in a base class, then
// if the implementation of delete() stores into the storage used
// by the object, the store seems to be removed by the compiler
// (maybe because the compiler thinks stores to a d
While looking into a testsuite failure when I folded while expanding, I found
gcc.c-torture/execute/920612-1.c failed because it depends on overflow of
signed integer being undefined.
--
Summary: gcc.c-torture/execute/920612-1.c depends on overflow
being defined
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-21 00:49 ---
The testcase contains:
f(j)int j;{return j++>0;}
Which is equialvant to:
f(j)int j;{return(j+1)>0;}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31290
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-21 01:13 ---
This is definitely a C/C++ aliasing violation as you are first accessing it as
a MyHeap::Node and then as derived.
Here is how I would fix it for the first one I would change it to:
void * newnode = malloc(bytes_
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-21 01:14 ---
Note memcpy is the only way to be aliasing safe in this case, oh and make sure
you don't cast the incomming pointer from malloc or from your free.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31289
--- Comment #3 from jima at cadence dot com 2007-03-21 01:32 ---
Can you point me to a description of the C++ aliasing rules?
Is the memcpy() workaround specific to GCC, or is memcpy
part of the standard with special rules regarding aliasing?
(I ask because our code base has to work on
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-21 01:40 ---
(In reply to comment #3)
> Can you point me to a description of the C++ aliasing rules?
You can find some of it on http://gcc.gnu.org/bugs.html under the non bug
section. There are a lot more pages on then I can
--- Comment #5 from jima at cadence dot com 2007-03-21 02:31 ---
(In reply to comment #4)
> (In reply to comment #3)
>... Why do you think 1 or 2 more
> instructions will be a hit, most of the problems you are going to hit into now
> is cache issues anyways unless you do a better malloc
--- Comment #6 from bangerth at dealii dot org 2007-03-21 03:59 ---
(In reply to comment #4)
> so in other words you're saying the solution to this is
> "if you want it to work with GCC, make your code non-portable"
>
> afaik "__attribute__ (( weak ))" is not part of the standard, its
The purpose of the attached code is to print out the internal representation of
some floating points. However, when compiling with optimizations turned on the
behaviour of the compiled program is not the expected one (i.e. the proper hex
representation is not printed out, but something else, here 0
--- Comment #1 from mail at sebastianbauer dot info 2007-03-21 07:14
---
Created an attachment (id=13240)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13240&action=view)
The simple test source.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31291
--- Comment #2 from mail at sebastianbauer dot info 2007-03-21 07:15
---
Created an attachment (id=13241)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13241&action=view)
The output of the compiler invocation and the executable.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
101 - 116 of 116 matches
Mail list logo
