--- Comment #8 from drewmccormack at mac dot com 2006-08-30 07:01 ---
Thanks Paul!
I am just using binaries, so I can't test this, but I trust you ;-)
Drew
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28873
--- Comment #10 from dpatel at apple dot com 2006-08-30 07:47 ---
Pinski,
Please do not reinsert my email address in CC list, again (and learn to not
jump to conclusion based on biased views)
May be it is not a good idea to ask dwarf generator to handle a case where two
shallow copy of
--- Comment #4 from rakdver at gcc dot gnu dot org 2006-08-30 08:07 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2006-08/msg01124.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-08-30 08:14 ---
Subject: Bug 27735
Author: rakdver
Date: Wed Aug 30 08:14:29 2006
New Revision: 116582
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116582
Log:
PR rtl-optimization/27735
* cfgloopmanip.c (f
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-08-30 08:27 ---
Oh, it was indeed me.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Assig
Respekt! Die Aktion ist ja der Hammer!
Die sieht gut uns und setzt es für ne gute Sache ein ;-)
--- Weitergeleitete Nachricht ---
Von: "Klaus Becker" <[EMAIL PROTECTED]>
An: [EMAIL PROTECTED];
Betreff: Fwd:FW: Echte Tierliebe :-)
Datum: Wed, 18 Aug 2006 17:49:02 +0100 (MET)
> > >
> > > Hallo
// /usr/libexec/gcc/i386-redhat-linux/4.1.0/cc1plus -fpreprocessed a.ii -quiet
-dumpbase a.cpp -mtune=generic -auxbase a -version -o - -frandom-seed=0
# 1 "a.cpp"
# 1 ""
# 1 ""
# 1 "a.cpp"
# 45 "a.cpp"
template
class B {
public:
B() { i = 0; }
A a;
static int i;
};
template
int B::i;
int main(
I am testing the OpenMP support of the current gcc and use the following test
program:
long long i, num_steps = 100;
double x, sum=0.0;
double step=1.0/(double) num_steps;
#pragma omp parallel for private(i,x) reduction(+:sum)
for(i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=28898
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-08-30 09:43 ---
*** This bug has been marked as a duplicate of 24791 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-08-30 09:43 ---
*** Bug 28897 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from stefan dot lankes at rwth-aachen dot de 2006-08-30
09:45 ---
I discovered that program works with OMP_NUM_THREADS<=2. If OMP_NUM_THREADS is
larger than 2, the program crashes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28898
--- Comment #2 from stefan dot lankes at rwth-aachen dot de 2006-08-30
09:55 ---
If I compile my test program with the current gcc and set OMP_NUM_THREADS to 2,
the program calculates a wrong value for PI. If I use Intel's C compiler, the
program calculates the correct value. Does the r
--- Comment #2 from rakdver at gcc dot gnu dot org 2006-08-30 10:35 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2006-08/msg01131.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from tbm at cyrius dot com 2006-08-30 11:10 ---
This bug happens *a lot* compiling the Debian archie with -ftree-vectorize -O3.
Additional testcases available on request.
--
tbm at cyrius dot com changed:
What|Removed |Added
The attached testcase produces an ICE "gimplification failed". Works fine with
gcc 4.1 and 4.2.0 20060819, but fails with 4.2 20060823 and 20060830.
gimplification failed:
{
register unsigned int __v;
register unsigned int __x;
D.2493 = data + 4B;
D.2494 = (const uint32_t
--- Comment #1 from tbm at cyrius dot com 2006-08-30 11:27 ---
Created an attachment (id=12152)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12152&action=view)
test case
Testcase from application "lcdf-typetools".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28899
ICE verify_stmts failed (invalid operand to unary operator) with
-ftree-vectorize and -O:
(sid)105:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -ftree-vectorize
-O1 -c
linphone-synths.c
linphone-synths.c: In function 'synths_':
linphone-synths.c:9: error: invalid operand to unary operator
--- Comment #1 from tbm at cyrius dot com 2006-08-30 11:38 ---
Created an attachment (id=12153)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12153&action=view)
test case
Testcase from application "linphone".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28900
gcc -Wunused-variable -c test.c, where test.c contains the
following code, fails to warn that variable a is unused:
--begin-test.c-
static const int a = 27;
static const int b = 42;
const int *f(void) { return &b; }
--end-test.c--
However, gcc -Wunused-variable -c -Dconst= test.c does
produce the
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-08-30 12:21 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-30 12:37 ---
I bet this is tree-ifcvt that is causing it and not really the vectorizer, I
will check later today.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
The avr target gives that alignment warning for every polymorphic class,
because it doesn't define TARGET_VTABLE_ENTRY_ALIGN, which means the default
kicks in, which is the size of a pointer. Since the AVR as an 8 bit platform
has no alignment requirements, BIGGEST_ALIGNMENT is 8, which is less tha
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-30 13:00 ---
Confirmed, reduced testcase:
int check_table (int t)
{
unsigned length = 0;
if ((length =__extension__ ({register unsigned __v; __v;})))
;
}
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-08-30
13:11 ---
(In reply to comment #2)
The standard is unambiguous: A string element must be written as charr(i:i).
character(*) :: charr
.
print *, charr(i)
will always be interpreted as a call to an assumed ch
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
Testcase:
template
struct View
{
int n;
};
template
struct ViewDom : View
{
using View::n;
ViewDom();
};
template
ViewDom::ViewDom()
{
char a[n];
}
void element( )
{
ViewDom a;
}
--
Summary: [4.2 Regression] Rejects VLA in template class's member
wi
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.2.0
Known to work||4.1.1
Target
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-30 15:05 ---
Remove the template from View and this works.
Janis,
Could you do a regression hunt on this bug?
Thanks,
Andrew
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Adde
--- Comment #3 from eweddington at cso dot atmel dot com 2006-08-30 15:06
---
The AVR does not have an Add Immediate instruction (addi), so this is normally
done using sbi with a negative number as Andrew correctly points out.
In Ralf's unoptimized output, it correctly shows a -2 (0xFE
--- Comment #2 from tbm at cyrius dot com 2006-08-30 15:06 ---
Note that this must be very recent. gcc started rejecting this code between
20060806 and 20060823.
--
tbm at cyrius dot com changed:
What|Removed |Added
---
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-30 15:09 ---
This is just unrolling/removing empty loops so invalid.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-30 15:15 ---
And I was correct.
4.1.2 has the bug too:
_ifc_.33_28 = !(r__2_11 <= 9.90095367431640625e-1) || _ifc_.30_3;
that is invalid gimple.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #27 from guenter at roeck-us dot net 2006-08-30 15:16 ---
Created an attachment (id=12154)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12154&action=view)
possible patch
This might be a possible patch. It reverts to the original insn declaration,
except for replacing
When trying to build CrystalSpace3d, which is a very big application, on
GNU/Linux, I get errors like this :
{standard input}:1236795: Error: operand out of range (0x8220 is
not between 0x8000 and 0x7fff)
(repeated about 300 times)
The file, cs_pyth.cpp generat
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-30 15:23 ---
Confirmed, reduced testcase:
int synths_ ( float * rc)
{
float r1, r2;
int i;
for (i = 0; i < 128; ++i)
{
r2 = rc[i];
r1 = ((r2) <= (.99f) ? (r2) : (.99f));
rc[i] = ((r1) >= (-.99f) ? (r1)
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-08-30 15:47 ---
Fixed so closing as such.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from patchapp at dberlin dot org 2006-08-30 15:50 ---
Subject: Bug number PR middle-end/27567
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/2006-08/msg01134.html
--
http://gcc.gnu.org
I get the following ICE:
[EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/g++ -c -O2
djvulibre-JB2EncodeCodec.cc
djvulibre-JB2EncodeCodec.cc: In member function 'void
DJVU::JB2Dict::JB2Codec::Encode::code_comment(DJVU::GUTF8String&)':
djvulibre-JB2EncodeCodec.cc:60: internal compiler error: in
compa
--- Comment #12 from jason at gcc dot gnu dot org 2006-08-30 15:51 ---
Subject: Bug 26670
Author: jason
Date: Wed Aug 30 15:51:17 2006
New Revision: 116591
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116591
Log:
PR c++/26670
* class.c (check_field_decls): Don'
--- Comment #1 from tbm at cyrius dot com 2006-08-30 15:51 ---
I get this with 4.2.0 20060823 but not with 20060721 - I wonder if it's related
to the fix for PR28814?
--
tbm at cyrius dot com changed:
What|Removed |Added
---
--- Comment #5 from patchapp at dberlin dot org 2006-08-30 15:51 ---
Subject: Bug number PR 28887
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/2006-08/msg01124.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #13 from jason at gcc dot gnu dot org 2006-08-30 15:52 ---
Subject: Bug 26670
Author: jason
Date: Wed Aug 30 15:52:12 2006
New Revision: 116592
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116592
Log:
PR c++/26670
* class.c (check_field_decls): Don'
--- Comment #2 from tbm at cyrius dot com 2006-08-30 15:52 ---
Created an attachment (id=12155)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12155&action=view)
test case
Testcase from application "djvulibre".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28905
--- Comment #14 from jason at gcc dot gnu dot org 2006-08-30 15:52 ---
fixed on 4.1 branch too.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
S
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-30 16:07 ---
Confirmed, but it looks unrelated to that PR but rather a change from SCEV
might had caused this.
Reduced testcase:
void f(void) __attribute__ ((noreturn));
int g(void);
void code_comment (void)
{
int size = g();
Works gcc 4.2 20060806, fails with 20060823:
(sid)579:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c texlive-t1rw.cc
texlive-t1rw.cc:19: error: conflicting declaration 'unsigned char
Efont::Type1Reader::xvalue_store [257]'
texlive-t1rw.cc:5: error: 'Efont::Type1Reader::xvalue_store' has a
--- Comment #1 from tbm at cyrius dot com 2006-08-30 16:16 ---
Created an attachment (id=12156)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12156&action=view)
test case
Testcase from application "texlive-bin".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28906
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-30 16:24 ---
Reduced testcase:
extern unsigned char xvalue_store[];
bool reserve (int want)
{
new unsigned char[want];
}
unsigned char xvalue_store[257];
I almost think this was casued by the patch to fix PR 27184.
Janis,
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
ICE. Works with gcc 4.2 20060806, fails with 20060823.
(sid)630:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c
ragel-parsedata.cc
ragel-parsedata.cc:19: internal compiler error: tree check: did not expect
class 'type', have 'type' (template_type_parm) in contains_placeholder_p, at
tree.c:
--- Comment #1 from tbm at cyrius dot com 2006-08-30 16:57 ---
Created an attachment (id=12157)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12157&action=view)
test case
Testcase from application "ragel".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28907
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-30 17:18 ---
*** Bug 28907 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28906
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-30 17:18 ---
It is the same bug as PR 28906.
*** This bug has been marked as a duplicate of 28906 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-30 17:20 ---
This also causes wrong code:
extern char machineMain[];
void sort (long len)
{
new char[100];
}
char machineMain[] = "main";
int main(void)
{
if (sizeof(machineMain)!=sizeof("main"))
__builtin_abort();
}
--
This testcase coms from SPEC CPU 2006:
[EMAIL PROTECTED] wrf-1]$ cat foo.f90
module foo
use bar
implicit none
private
type ESMF_Clock
type(ESMF_Time) :: CurrTime
end type
interface operator (+)
function add (x, y)
use bar
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-30 17:50 ---
When reporting regressions can you at least give the version of GCC you are
using as it might had been fixed already.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28908
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-30 17:52 ---
Also saying what is the last known version to work is also nice.
Note I am going to say this is related to PR 28630 and either is caused by it
or fixed by it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28908
--- Comment #28 from guenter at roeck-us dot net 2006-08-30 18:00 ---
Created an attachment (id=12158)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12158&action=view)
Another possible patch
Another possible patch. This one retains m->r handling, and thus produces
somewhat more ef
--- Comment #3 from hjl at lucon dot org 2006-08-30 18:02 ---
The regression was introduced between revision 116091 and 116362. revision
116590
still has this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28908
--- Comment #29 from dje at watson dot ibm dot com 2006-08-30 18:08 ---
Subject: Re: [4.1/4.2 Regression] returning constant double
Yes, I was testing out the same change as your second patch. That
looks reasonable if it works.
By the way, the use of "%H" in the frob
--- Comment #4 from hjl at lucon dot org 2006-08-30 18:41 ---
Revision 116268 is the cause. There are several bug fixes in one checkin. It is
hard to just back out one bug fix.
--
hjl at lucon dot org changed:
What|Removed |Added
--
--- Comment #30 from dje at watson dot ibm dot com 2006-08-30 18:42 ---
Subject: Re: [4.1/4.2 Regression] returning constant double
In other words, should the lwz actually be evlwwsplat?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27287
--- Comment #31 from amylaar at gcc dot gnu dot org 2006-08-30 18:47
---
(In reply to comment #29)
> (In reply to comment #28)
>
> > 2006-08-29 Nathan Sidwell <[EMAIL PROTECTED]>
> > J"orn Rennecke <[EMAIL PROTECTED]>
> >
> > PR tree-optimization/17506
> >
--- Comment #5 from hjl at lucon dot org 2006-08-30 18:55 ---
This patch:
http://gcc.gnu.org/ml/fortran/2006-08/msg00154.html
is the cause.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28908
--- Comment #32 from amylaar at gcc dot gnu dot org 2006-08-30 18:58
---
Subject: Bug 17506
Author: amylaar
Date: Wed Aug 30 18:57:54 2006
New Revision: 116593
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116593
Log:
Fixed attribution for patch for PR tree-optimization/17506
--- Comment #6 from hjl at lucon dot org 2006-08-30 19:40 ---
Before the change, gfc_get_derived_type will search a module to reuse
TREE_TYPE.
The current one will create a new TREE_TYPE for the same type. But fold_convert
has
if (type == orig)
return arg;
Although TYPE and ORIG
--- Comment #7 from paulthomas2 at wanadoo dot fr 2006-08-30 20:01 ---
Subject: Re: [4.2 Regression]: fold_convert fails for
Fortran operator
hjl at lucon dot org wrote:
>--- Comment #6 from hjl at lucon dot org 2006-08-30 19:40 ---
>Before the change, gfc_get_derived_type w
--- Comment #8 from pault at gcc dot gnu dot org 2006-08-30 20:05 ---
Created an attachment (id=12159)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12159&action=view)
Patch for the PR
This is regtesting as I write. I do not doubt that it will pass because none
of the tests caugh
86_64-unknown-linux-gnu/4.2.0/finclude
GNU F95 version 4.2.0 20060830 (experimental) [trunk revision 116593]
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.2.0 20060830 (experimental) [trunk revision
116593].
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=1
--- Comment #31 from guenter at roeck-us dot net 2006-08-30 20:40 ---
>
> By the way, the use of "%H" in the frob patterns is completely
> wrong and should be removed. %H does not mean high register.
>
I did wonder about that, since it does not seem to be used elsewhere,
but I
--- Comment #5 from ralf-engels at gmx dot de 2006-08-30 20:43 ---
Wow,
you mean that unrolling the loop three times but not removing it is the right
behaviour?
Anyway, 4.1.1 seems to do it right. It's removing the whole loop as expected.
delay.h is working.
--
http://gcc.gnu.org
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |lmillward at gcc dot gnu dot
|dot org
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |lmillward at gcc dot gnu dot
|dot org
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |lmillward at gcc dot gnu dot
|dot org
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |lmillward at gcc dot gnu dot
|dot org
work for me:
>
>Starting program: /export/build/gnu/gcc-next/build-x86_64-linux/gcc/f951
>xxx.f90 -quiet -dumpbase xxx.f90 -mtune=generic -auxbase-strip xxx.s -version
>-o xxx.s -I /usr/gcc-next/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/finclude
>GNU F95 version 4.2.0 20060830 (experiment
"(void) __sync_fetch_and_add(d, 1)" and variations on that theme (i.e. the sync
sub builtins and -1/1) should be generating "lock inc" and "lock dec" instead
of "lock add" and "lock sub"
--
Summary: Missed optimization with x86 sync builtins
Product: gcc
Version:
--- Comment #17 from eweddington at cso dot atmel dot com 2006-08-30 21:13
---
Note that you cannot completely restrict this bug to "unified tree" builds.
Building GCC 4.1.1 for the AVR target still fails unless one uses
--disable-libssp, AND this is not a unified tree build. Binutils h
After configure; make bootstrap; make test; make install:
find . -user root
./gcc/libgcc_s.1.dylib.tmp
./gcc/ppc64/libgcc_s.1.dylib.tmp
./powerpc-apple-darwin8.7.0/libjava/.libs/libgij.8.0.0.dylibT
./powerpc-apple-darwin8.7.0/libjava/.libs/libjvm.dylibT
./powerpc-apple-darwin8.7.0/ppc64/libjava/.l
+++ This bug was initially created as a clone of Bug #23442 +++
Attempting to build a cross-compiler for m68k-unknown-elf on x86_64-linux-gnu
fails with an internal error:
/home/lpowell/build-gcc/./gcc/xgcc -B/home/lpowell/build-gcc/./gcc/
-B/home/lpowell/m68k-gcc/m68k-elf/bin/ -B/home/lpowell/m68
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-30 21:38 ---
Yes try the mainline for the cross compiler.
*** This bug has been marked as a duplicate of 23442 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-08-30 21:38 ---
*** Bug 28911 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23442
--- Comment #2 from luke dot powell at bjservices dot com 2006-08-30 21:46
---
I'm not familiar with that term, mainline. Is that the current CVS snapshot or
something else? Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28911
--- Comment #11 from paulthomas2 at wanadoo dot fr 2006-08-30 21:56 ---
Subject: Re: [4.2 Regression]: fold_convert fails for
Fortran operator
HJ,
I have cross-checked the patch between the two machines; it is the
same. One regtests fine and the other segfaults in switch_types. I
Given the following source:
1: #include
3: unsigned char *p = NULL;
4: char *s = NULL;
6: unsigned char *p1 = "p";
7: char *s1 = "s";
9: int main() {
10:s = p;
12:char c=255;
13:printf("%d",c);
15:return 0;
}
gcc -Wall _.c -o _ && ./_
produces:
_.c:6:
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-30 22:45 ---
This is not a bug as char pointers are special by the C standard. char is a
different type from either unsigned char or signed char. Also you should not
use -funsigned-char/-fsigned-char unless you know what you ar
gfortran and libgomp tests do not link the just-built libraries when "make
check" is run unless the libraries are first installed in $prefix/lib.
This results in the following differences in the reported error rate for
gfortran:
Testing after running make install:
< # of expected passes
!
! Un-comment the DO and ENDDO and the compiled program
! hangs after the first output line.
!
! Compiled with: gfortran junk.f90
! where: gfortran --version gives
! GNU Fortran 95 (GCC 4.0.2 20051125 (Red Hat 4.0.2-8))
! Running on Fedora Core 4, Opteron
!
! E. Kornkven, [EMAIL PROTECTED]
!
--- Comment #1 from kargl at gcc dot gnu dot org 2006-08-31 02:06 ---
Upgrade gfortran to at least 4.1.1. The code works
fine with gfortran 4.2.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-31 02:14 ---
I don't have this issue on any target that I test on, which includes
x86_64-linux-gnu and i686-linux-gnu and powerpc64-linux-gnu and yes I do
testing of -m64/-m32 on both powerpc64-linux-gnu and x86_64-linux-gnu.
-
--- Comment #32 from dje at gcc dot gnu dot org 2006-08-31 02:36 ---
I do not mean one evlwwsplat. I mean two in place of the two lwz, to
correspond to the evmergelo/evmergehi pair.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27287
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28904
--- Comment #2 from kargl at gcc dot gnu dot org 2006-08-31 02:47 ---
Well, you do need to upgrade your compiler, but there appears to be
a bug :(
If n <= 65000, the program works fine. For larger n, the combination
of
do i = 1, 1
a = (/ (i, i = 1, n) /)
end do
i
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28906
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-31 02:50 ---
Actually it is not just -fstack-limit-symbol that could go wrong but it is also
builtin_trap:
(define_insn "conditional_trap"
[(trap_if (match_operator 0 "valid_dbcc_comparison_p"
[(cc0)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-31 02:53 ---
Confirmed, this is a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-31 02:55 ---
Can you provide a compilable source?
This is related to PR 28468.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-31 02:58 ---
(In reply to comment #2)
> I'm not familiar with that term, mainline. Is that the current CVS snapshot or
> something else? Thanks.
It is the SVN trunk, so a svn snapshot will be a snapshot of the mainline.
--
--- Comment #2 from kazu at gcc dot gnu dot org 2006-08-31 02:58 ---
trapcs for -fstack-limit-symbol is printed as text in m68k.c,
not as an insn in m68k.md.
Search for trapcs in m68k.c.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
1 - 100 of 110 matches
Mail list logo
