--- Comment #16 from hosking at cs dot purdue dot edu 2006-08-31 05:37
---
It turns out there were problems with aliasing in the trees generated by the
Modula-3 front end. There are multiple places where aliasing is used to
loophole values from one type to another, and this was probabl
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-08-31 05:28
---
Setting the parameter n=65535, the program appears to execute correctly.
However, the pr28914.f90.003t.original file is 706800 bytes long and embedded
with a very large static declaration of the array. As if it
--- Comment #33 from guenter at roeck-us dot net 2006-08-31 05:15 ---
(In reply to comment #32)
> I do not mean one evlwwsplat. I mean two in place of the two lwz, to
> correspond to the evmergelo/evmergehi pair.
>
Hmm ... what would be the point ? evlwwsplat copies 32 bit memory cont
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-31 04:34 ---
well, the syntax would be more like:
addis 9,(.LC42716-.LCTOC1)@ha(30)
lwz 0,.LC42716-.LCTOC1)@l(9)
But I don't know if this syntax will work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2890
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-31 04:30 ---
Hmm, I am going to go out on a limb and say we should
produce about the following (hopefully I get the right macros):
la temp, ha16(.LC42716-.LCTOC1)(30)
lwz rn, lo16(.LC42716-.LCTOC1)(temp)
This is like what Darwi
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-31 03:19 ---
Note the error is recent because one of my builds from 4.2.0 20060826 does not
have the error while the other one does (I don't have the svn revision on my
either).
--
pinskia at gcc dot gnu dot org changed:
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-31 03:17 ---
Confirmed, we now get an error before ICEing:
t.cc:3: error: name of class shadows template template parameter B
t.cc:3: internal compiler error: tree check: expected record_type or union_type
or qual_union_type, h
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-31 03:13 ---
Confirmed, the special casing for inc/dec should be added to the sync_add
patterns also.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-31 03:10 ---
I almost think it was caused by the patch which fixed PR 27115.
Martin, can you try a newer gcc 4.1.2 to double check that it is not a
regression there also?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28899
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-31 03:06 ---
Oh:
if (current_function_limit_stack
&& GET_CODE (stack_limit_rtx) == SYMBOL_REF)
asm_fprintf (stream, "\tcmp" ASM_DOT "l %I%s+%wd,%Rsp\n\ttrapcs\n",
XSTR (stack_limit_rtx, 0), current_fr
--- 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
--- 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 #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 #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 #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)
--
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 #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|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28904
--- 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
--- 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 #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
-
!
! 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]
!
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
--- 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
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 #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
--- 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 #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 #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
--
+++ 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
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
--- 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
"(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:
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
--
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
--- 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
--- 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
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
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 #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();
}
--
--- 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 #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 #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
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:
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- 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,
--- 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
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 #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();
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- 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
--- 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 #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 #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 #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 #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'
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 #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
--- 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 #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)
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 #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
--- 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 #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 #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 #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 #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
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.2.0
Known to work||4.1.1
Target
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
--
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
--- 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
--- 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
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 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
--- 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
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 #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
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: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
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 #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
--- 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 #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 #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
1 - 100 of 110 matches
Mail list logo
