--- Comment #10 from jvdelisle at gcc dot gnu dot org 2008-02-27 04:38
---
Fixed on trunk.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-02-27 02:14
---
The problem exists in gfortran 4.2 but is fixed in 4.3 Suggest you update to
4.3.
You can get binaries at http://gcc.gnu.org/wiki/GFortranBinaries if your distro
does not provide 4.3 yet.
--
http://gcc.gnu.o
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-02-27 01:59 ---
(In reply to comment #3)
> Subject: Re: Invalid vector code generated with -O2
>
> Oops. Sorry for the false alarm. But shouldn't there be an error, or
> at least a warning?
There should be a warning but someti
--- Comment #3 from kes at smolek dot com 2008-02-27 01:50 ---
Subject: Re: Invalid vector code generated with -O2
Oops. Sorry for the false alarm. But shouldn't there be an error, or
at least a warning?
pinskia at gcc dot gnu dot org wrote:
> --- Comment #2 from pinskia at gcc
--- Comment #10 from hp at gcc dot gnu dot org 2008-02-26 23:37 ---
(In reply to comment #9)
> You'll probably want to make the truncate a no-op if we
> are at the end of file already.
No, that'd be an unrelated change. I don't wanna mix things up and/or
together.
--
http://gcc.gn
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-02-26 23:20 ---
You are violating C/C++ aliasing rules:
typedef float v4sf __attribute__ ((vector_size(16)));
v4sf vSum;
complex *vp = (complex *) &vSum;
...
spectra[4*j] = vp[0];
spectra[4*j+2] = vp[1];
--
pinskia at
--- Comment #9 from tkoenig at gcc dot gnu dot org 2008-02-26 23:19 ---
(In reply to comment #8)
> > b) fail at runtime (noisily) and xfail the
> >corresponding test cases
>
> *sigh* ok, I'll do it, except for the noise.
Thanks a lot!
You'll probably want to make the truncate a
--- Comment #1 from kes at smolek dot com 2008-02-26 23:17 ---
Created an attachment (id=15234)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15234&action=view)
temp file output demonstrating the bug
Command line: gcc -v -save-temps -O2 -S -msse3 ComputeEven.cpp
Note: bug occurs
A simple vector addition loop fails to generate any addition code when -O2
optimization is used; the loop is essentially empty.
--
Summary: Invalid vector code generated with -O2
Product: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: majo
--- Comment #4 from ubizjak at gmail dot com 2008-02-26 22:59 ---
(In reply to comment #3)
> That seems too complicated for a simple diagnostics test. Moreover, I couldn't
> find a single example of that in the testsuite. Why not simply?
What about this:
--cut here--
/* { dg-do compil
--- Comment #8 from hp at gcc dot gnu dot org 2008-02-26 22:47 ---
(In reply to comment #7)
> If we don't have a way to truncate a file, we won't have an
> easy time enforcing Fortran semantics. Are there any other
> ways of truncating a file on that particular target?
I can certainly
--- Comment #3 from rwild at gcc dot gnu dot org 2008-02-26 22:47 ---
Fixed.
--
rwild at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #2 from rwild at gcc dot gnu dot org 2008-02-26 22:42 ---
Subject: Bug 28800
Author: rwild
Date: Tue Feb 26 22:41:16 2008
New Revision: 132690
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132690
Log:
gcc/:
PR c/28800
* c-parser.c (c_parser_translation_unit): Warn f
--- Comment #5 from burnus at gcc dot gnu dot org 2008-02-26 22:41 ---
FIXED on the trunk (4.4.0).
The not-so-helpful error message is now PR 35267.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from burnus at gcc dot gnu dot org 2008-02-26 22:34 ---
Subject: Bug 35033
Author: burnus
Date: Tue Feb 26 22:33:35 2008
New Revision: 132689
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132689
Log:
2008-02-26 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
--- Comment #7 from tkoenig at gcc dot gnu dot org 2008-02-26 21:45 ---
If we don't have a way to truncate a file, we won't have an
easy time enforcing Fortran semantics. Are there any other
ways of truncating a file on that particular target?
If there aren't, we could
a) refuse to co
--- Comment #14 from jb at gcc dot gnu dot org 2008-02-26 21:15 ---
Closing as fixed. Timings for a small test program comparing matrix
multiplication done manually vs. libgfortran for real and complex.
Results without the committed patch (-O3 -funroll-loops, 1.6 GHz Pentium-M):
Manual
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-02-26 21:09 ---
>Converting avar from a pointer to an array like
this however does work:
static char avar[] = {"some string"};
This is an array value which is initialized via a string literal. The array is
writable.
The behavio
--- Comment #4 from Quinlan at ACM dot org 2008-02-26 21:05 ---
If the problem is that the char pointer is pointing to a constant value in:
static char * avar = "some string";
then perhaps initializing with an array of one string as in this line work:
static char * avar = {"some stri
--- Comment #2 from tromey at gcc dot gnu dot org 2008-02-26 20:48 ---
I agree, closing as dup.
I have a patch for that bug. I forget what happened to it, but I'll
look into it soon.
*** This bug has been marked as a duplicate of 22168 ***
--
tromey at gcc dot gnu dot org changed:
--- Comment #16 from tromey at gcc dot gnu dot org 2008-02-26 20:48 ---
*** Bug 35312 has been marked as a duplicate of this bug. ***
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from manu at gcc dot gnu dot org 2008-02-26 20:14 ---
(In reply to comment #2)
> You can use
>
> /* { dg-add-options register } */
>
> register int * volatile x asm REGISTER; /* { dg-warning "optimization may
> eliminate reads and/or writes to register variables" } */
>
--- Comment #3 from Quinlan at ACM dot org 2008-02-26 20:10 ---
I appreciate your answer, however shouldn't this declaration:
static char * avar = "some string";
be identical to this:
static char * avar = NULL;
avar = "some string";
Yet when the application executes:
avar[4] = '
COCO is part 3 of the Fortran 95 standard. Dan Nagle provides a GPL licensed
implementation at http://users.erols.com/dnagle/coco.html, perhaps it's
possible to use that?
--
Summary: gfortran does not support the COCO preprocessor
Product: gcc
Version: 4.4.0
--- Comment #2 from hjl dot tools at gmail dot com 2008-02-26 19:30 ---
(In reply to comment #1)
> Could you suggest a more robust testcase?
>
> Or if that is not possible, there should be a way to only compile the testcase
> for valid targets. Ideas?
>
You can use
/* { dg-add-option
--- Comment #1 from manu at gcc dot gnu dot org 2008-02-26 19:02 ---
H.J.
Could you suggest a more robust testcase?
Or if that is not possible, there should be a way to only compile the testcase
for valid targets. Ideas?
--
manu at gcc dot gnu dot org changed:
What|
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-02-26 19:00 ---
"some string" is a string literal so it is constant. What you are trying to do
is change the string literal which is undefined behavior so you are getting a
runtime seg fault.
--
pinskia at gcc dot gnu dot org c
--- Comment #1 from Quinlan at ACM dot org 2008-02-26 18:59 ---
I am building with compiler flags set to:
-c -DLINUX -gdwarf-2 -g3 -g -O -DDEBUG
--
Quinlan at ACM dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-26 18:59 ---
>func(hold.item); // OK for Wilma, but fails for Foo::Fred, see below
This is correct.
> func2(hold.item); // OK, not overloaded name
This is not and we still have a bug with respect of not having any overl
A variable is declared similar to this:
static char * avar = "some string";
Then an attempt to change the value like this will throw a SIGSEGV:
avar[4] = '_';
The problem occurs when the variable is declared locally in a function, and
when the variable is declared globally. Adding a cast to the
Can someone confirm if this is the same non-bug reported in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29844 or if it is a regression?
The code compiles in gcc 3.4.4 and 4.0.2 but not in 4.1.2, and I don't
understand why. Especially since func2() doesn't have the same problem that
func() does.
--- Comment #3 from vgodunko at rostel dot ru 2008-02-26 18:43 ---
I have trace and compare execution of the two program, one use anonymous access
type to tagged type and another use anonymous access type to interface type. In
the program which use tagged type GNAT:
- creates not only f
--- Comment #8 from ghazi at gcc dot gnu dot org 2008-02-26 18:29 ---
(In reply to comment #7)
> > Isn't this a dup of 34168?
> >
> It appears to be.
Can you implement Uros' suggestion?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34878
--- Comment #2 from jason at gcc dot gnu dot org 2008-02-26 18:09 ---
Subject: Bug 35315
Author: jason
Date: Tue Feb 26 18:09:02 2008
New Revision: 132681
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132681
Log:
PR c++/35315
* attribs.c (decl_attributes): Leave
--- Comment #7 from sgk at troutmask dot apl dot washington dot edu
2008-02-26 18:00 ---
Subject: Re: fast-math-pr33299.f90 failure with illegal instruction due to
-ffast-math.
On Tue, Feb 26, 2008 at 05:53:52PM -, ghazi at gcc dot gnu dot org wrote:
>
> --- Comment #6 from g
I got
/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/pr34351.c:4: error: invalid
register name for 'x'
on Linu/ia32 since r13
register int * volatile x asm ("r13");
isn't a valid register.
--
Summary: Invalid gcc.dg/pr34351.c
Product: gcc
Version: 4.4.0
--- Comment #10 from mark at codesourcery dot com 2008-02-26 17:57 ---
Subject: Re: [4.1/4.2/4.3/4.4 Regression] With #pragma visibility,
`vtable for __cxxabiv1::__class_type_info' is emitted as a hidden-visibility
relocation
benjamin at smedbergs dot us wrote:
> --- Comment #8 f
--- Comment #6 from ghazi at gcc dot gnu dot org 2008-02-26 17:53 ---
Isn't this a dup of 34168?
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from jakub at gcc dot gnu dot org 2008-02-26 17:39 ---
BTW, not sure why 4.1.x/4.2.x is listed as broken. Only 4.3+ has H.J's:
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119764
Without that change, although __cxxabiv1::* symbols are incorrectly marked
as hidden, GCC
--- Comment #1 from thomas dot orgis at awi dot de 2008-02-26 17:37 ---
I stripped a bit more and I think I got the root of the problem, illustrated by
this more minimal example:
MODULE data
IMPLICIT NONE
PRIVATE
INTEGER, PARAMETER :: dat_dimension = 2
TYPE dat_sigtype
rea
--- Comment #8 from benjamin at smedbergs dot us 2008-02-26 17:25 ---
Yes, to make it clear: the class typeinfo object may have hidden visibility...
it's the __cxxabiv1::__class_type_info "class" that should have default
visibility always.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
We have a set of code that works with SUN and Intel compilers and that should
be correct to the best of our knowledge, but triggers a strange error by
gfortran 4.1.0 and 4.2.3 .
The stripped-down exapmple here has been tested with 4.1.0 on x86-64, I got the
qualitatively same error on the full sour
--- Comment #7 from jakub at gcc dot gnu dot org 2008-02-26 17:19 ---
Created an attachment (id=15233)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15233&action=view)
gcc43-pr35368.patch
Patch I'm testing.
The reasons it should IMNSHO have default visibility is:
1) these are comp
--- Comment #57 from howarth at nitro dot med dot uc dot edu 2008-02-26
17:15 ---
Uros,
You changes in d.diff.txt are fine with the exception of the missing extra
set of parentheses for the ACONCAT macro call. I have tested the patch with
those corrections and powerpc-apple-darwin9 p
--- Comment #6 from mmitchel at gcc dot gnu dot org 2008-02-26 17:06
---
We need to be careful about this. We have a lot of ways to specify visibility:
dllimport/dllexport attributes, notshared attribute, visibility attributes on
classes.
I actually think the compiler is behaving as i
--- Comment #5 from jakub at gcc dot gnu dot org 2008-02-26 16:30 ---
Testing a patch.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|una
--- Comment #3 from segher at kernel dot crashing dot org 2008-02-26 16:16
---
> > Not equivalent in the presence of overflow.
>
> You mean defined overflow :).
No, I mean overflow.
Let's assume int is 16-bit (just to keep the numbers smallish);
now take i=1, j=1000, k=1000. i/j/k i
The following program produces an ICE on my machine
#include
class Foo
{
char foo[3];
};
int main(){
std::tr1::array bar;
}
Output:
cd /home/haile/sander/tmp/
g++ test.cc
test.cc: In function int main():
test.cc:9: internal compiler error: Speicherzugriffsfehler
Please submit a full b
--- Comment #1 from rwild at gcc dot gnu dot org 2008-02-26 14:48 ---
> (the redundant spaces may interfere with make operation, apparently)
Can you show in which way they interfere? If they cause an error, then
post it, please. Which make implementation?
--
rwild at gcc dot gnu d
--- Comment #13 from manu at gcc dot gnu dot org 2008-02-26 14:45 ---
Fixed in GCC 4.4
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2008-02-26
14:31 ---
Subject: Re: Bootstrap fails with BOOT_CFLAGS="-g -O0"
> Did you check if it is only debug info that differs? That is, does
> BOOT_CFLAGS="-O0" work?
Removing "-g" works.
Dave
--
http://gcc.gnu.org
Precondition: an empty file named "dummy.c" exists in the current directory.
The following command:
arm-elf-gcc -c -MM -MT
123456789a123456789b123456789c123456789d123456789e123456789f123456789g123
dummy.c
generates the following output:
\
123456789a123456789b123456789c123456789d123456789e123456
--- Comment #12 from manu at gcc dot gnu dot org 2008-02-26 14:17 ---
Subject: Bug 26264
Author: manu
Date: Tue Feb 26 14:16:13 2008
New Revision: 132677
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132677
Log:
2008-02-26 Manuel Lopez-Ibanez <[EMAIL PROTECTED]>
PR 2
--- Comment #5 from manu at gcc dot gnu dot org 2008-02-26 14:06 ---
Fixed in 4.4.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #4 from manu at gcc dot gnu dot org 2008-02-26 14:04 ---
Subject: Bug 34351
Author: manu
Date: Tue Feb 26 14:04:09 2008
New Revision: 132675
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132675
Log:
2008-02-26 Manuel Lopez-Ibanez <[EMAIL PROTECTED]>
PR 34
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-26 13:01 ---
Did you check if it is only debug info that differs? That is, does
BOOT_CFLAGS="-O0" work?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35378
th: ../gcc/configure --build=i686-apple-darwin9
--host=i686-apple-darwin9 --target=i686-apple-darwin9 --with-gnu-as
--enable-shared --prefix=/opt/gnu/gcc/gcc-4.3.0 --enable-debug=no --disable-nls
--enable-languages=c,c++,objc,fortran,obj-c++,java
Thread model: posix
gcc version 4.3.0 20080226 (prerele
--- Comment #12 from pault at gcc dot gnu dot org 2008-02-26 12:44 ---
Have changed the keyword to represent comment #6
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
-
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Component|bootstrap |target
Keywords||build
Targe
--- Comment #1 from pavel dot shved at gmail dot com 2008-02-26 12:33
---
(In reply to comment #0)
Well, my comment has typos as well...
> real N3437 (`Explicit conversion operators')
is is N2437, of course.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35375
--- Comment #2 from vgodunko at rostel dot ru 2008-02-26 12:17 ---
GNAT register allocated object of the T type in the finalization list at the
creation time, but at the deallocation time it only free object storage and
don't remove reference to the deallocated object from the finalizati
--- Comment #1 from jsm28 at gcc dot gnu dot org 2008-02-26 12:13 ---
Mark confirms this should not be accepted for scalar types, so a regression.
Working on a patch.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
---
I was compiled and installed gcc-4.2.3 on Linux 2.4, glibc 2.3.6
main configure options was:
--enable-shared=libstdc++
--enable-static
--disable-debug
--enable-cpp
--enable-languages=c,c++
--enable-threads
After successfully compile and install got some problems when compiling apps
using the -fs
#pragma GCC diagnostic clear // added to clear all current in file diagnostic
over rides.
#pragma GCC diagnostic warning clear // Clear all warnings alerations done by
diagnostic.
#pragma GCC diagnostic error clear // same as above but for error
#pragma GCC diagnostic ignored clear //same as above
Some links ot the page http://gcc.gnu.org/gcc-4.3/cxx0x_status.html contain
typos:
strongly-typed enums paper is called N2347 (not N2437);
real N3437 (`Explicit conversion operators') has the wrong link, it should
refer to pdf file instead of html;
link to 2346 has an unnecessary `l'; correct li
--- Comment #15 from pcarlini at suse dot de 2008-02-26 10:57 ---
*** Bug 35374 has been marked as a duplicate of this bug. ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #1 from pcarlini at suse dot de 2008-02-26 10:57 ---
*** This bug has been marked as a duplicate of 13740 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
The following code:
// START of CODE, FILE 'try.cpp'
template
typeof(A(0)+B(0)) add( A a , B b )
{
return a + b;
}
void f( double & S , double X , int Y )
{
S = add( X , Y );
}
// END OF CODE
causes g++ to emit an ICE error, as shown of the following sessions transcript.
I joine
As reported in http://gcc.gnu.org/ml/gcc-patches/2008-02/msg01134.html,
bootstraping on powerpc-apple-darwin9 fails with revision 132578:
...
libtool: compile: /opt/gcc/darwin_buildw/./gcc/xgcc
-B/opt/gcc/darwin_buildw/./gcc/ -B/opt/gcc/gcc4.4w/powerpc-apple-darwin9/bin/
-B/opt/gcc/gcc4.4w/powerp
--- Comment #10 from simon dot marshall at misys dot com 2008-02-26 10:36
---
With CFLAGS="-g -O1 -fno-unit-at-a-time -fno-crossjumping -Wno-pointer-sign", I
cannot hit the breakpoint on error (ie, if I put a breakpoint on error itself).
Also, I cannot hit the breakpoint at intervals2.
--- Comment #1 from vgodunko at rostel dot ru 2008-02-26 10:33 ---
Created an attachment (id=15232)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15232&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35372
Unchecked deallocation of the access to interface classwide type has corupt
memory.
Valgrind output:
==8176== Invalid read of size 4
==8176==at 0x804EF32: system__finalization_implementation__finalize_list
(s-finimp.adb:360)
==8176==by 0x804EFE8:
system__finalization_implementation__final
--- Comment #2 from paolo at gcc dot gnu dot org 2008-02-26 10:10 ---
Subject: Bug 35323
Author: paolo
Date: Tue Feb 26 10:09:43 2008
New Revision: 132669
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132669
Log:
/cp
2008-02-26 Paolo Carlini <[EMAIL PROTECTED]>
PR c+
--- Comment #24 from jh at suse dot cz 2008-02-26 09:43 ---
Subject: Re: Stack not aligned at mod 16 byte boundary in x86_64 code
> I guess we need
> 1) Get the patch to check overwritability of body to mainline and branch,
> since
> it is quite wrong to optimize based on knowledge of
--- Comment #23 from hubicka at gcc dot gnu dot org 2008-02-26 09:31
---
I guess we need
1) Get the patch to check overwritability of body to mainline and branch, since
it is quite wrong to optimize based on knowledge of body that might be replaced
2) Figure out how to get Apple's linke
75 matches
Mail list logo
