--- Comment #5 from burnus at gcc dot gnu dot org 2008-04-11 07:45 ---
> If on the other hand Tobias is right in the assumption he made in comment #3,
> then one could something along the lines of
> if (f1->sym->as->type != f2->sym->as->type)
I would not be surprised if foo(*) and foo
Bug is present in 4.2.3 also.
building 32bit code with architecture greater than sparcv8 fails like this:
/home/users/builder/rpm/BUILD/gcc-4.3.0/builddir/./gcc/xgcc
-B/home/users/builder/rpm/BUILD/gcc-4.3.0/builddir/./gcc/
-B/usr/sparc-pld-linux/bin/ -B/usr/sparc-pld-linux/lib/ -isystem
/usr/spar
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #4 from ubizjak at gmail dot com 2008-04-11 10:16 ---
Patch in testing.
--
ubizjak at gmail dot com changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #18 from jakub at gcc dot gnu dot org 2008-04-11 10:25 ---
Seems I forgot to provide the testcase I was talking about. Here it is:
__attribute__((preserve_stack)) void f1 (int a, int b, int c, int d, int e)
{
int i;
for (i = 0; i < 50; i++)
{
// Simulate high
--- Comment #9 from pault at gcc dot gnu dot org 2008-04-11 09:54 ---
It's mine, it's mine! I even posted a fix for it last night but have not had a
chance to commit it. I'll try to do so over the weekend.
As Jerry remarks, it sometimes goes away; such as on my x86_ia64/FC8, on which
--- Comment #5 from ubizjak at gmail dot com 2008-04-11 11:44 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2008-04/msg00930.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #10 from burnus at gcc dot gnu dot org 2008-04-11 12:23 ---
> It's mine, it's mine! I even posted a fix for it last night but have not had
> a chance to commit it. I'll try to do so over the weekend.
The mentioned patch was posted here:
http://gcc.gnu.org/ml/fortran/2008-
build_trtable function from posix/regex.c is miscompiled on ppc64-linux with
-mcpu=power6. The $v31 register is used within the function and is therefore
saved in prologue and restored in epilogue, but as the function uses alloca,
it is restored from different memory slot than it was saved into.
O
--- Comment #1 from jakub at gcc dot gnu dot org 2008-04-11 14:01 ---
Created an attachment (id=15466)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15466&action=view)
regex.i.bz2
bzip2ed testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35907
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-04-11 14:14 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-04-11 14:14 ---
Subject: Bug 35869
Author: rguenth
Date: Fri Apr 11 14:14:04 2008
New Revision: 134197
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134197
Log:
2008-04-11 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #2 from jakub at gcc dot gnu dot org 2008-04-11 14:25 ---
Smaller testcase:
/* { dg-do run } */
/* { dg-options "-O2 -mcpu=power6" } */
#define vector __attribute__((vector_size (16)))
union
{
vector int k;
int c[16];
} u, v, w;
vector int m;
void __attribute__((noinlin
--- Comment #3 from jakub at gcc dot gnu dot org 2008-04-11 14:31 ---
On this smaller testcase and supposedly on the large testcase too:
@@ -90,7 +90,7 @@ foo:
li 3,0
lvx 30,1,0
li 0,128
- lvx 31,1,0
+ lvx 31,31,0
ld 1,0(1)
lwz 12,-28(1
GCC accepts the following with -ansi -pedantic -Wall without diagnostics
#include
wchar_t z[] = L"a" "\xff";
GCC claims a default execution charset of UTF-8; presumably the default
execution wide character set is UTF-32. But "\xff" is a two-character narrow
execution character set string litera
--- Comment #5 from hjl at gcc dot gnu dot org 2008-04-11 15:53 ---
Subject: Bug 35897
Author: hjl
Date: Fri Apr 11 15:52:19 2008
New Revision: 134199
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134199
Log:
2008-04-11 H.J. Lu <[EMAIL PROTECTED]>
PR middle-end/35897
--- Comment #6 from hjl at gcc dot gnu dot org 2008-04-11 15:56 ---
Subject: Bug 35897
Author: hjl
Date: Fri Apr 11 15:55:57 2008
New Revision: 134200
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134200
Log:
2008-04-11 H.J. Lu <[EMAIL PROTECTED]>
PR middle-end/35897
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-04-11 16:09 ---
I would rather have -fdump-rtl-expand back.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35843
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-04-11 16:26 ---
I wonder if this was caused by:
2007-05-16 Eric Christopher <[EMAIL PROTECTED]>
* config/rs6000/rs6000.c (rs6000_emit_prologue): Move altivec register
saving after stack push. Set sp_offset wheneve
--- Comment #1 from joseph at codesourcery dot com 2008-04-11 16:58 ---
Subject: Re: New: Dubious charset conversions
On Fri, 11 Apr 2008, neil at gcc dot gnu dot org wrote:
> GCC accepts the following with -ansi -pedantic -Wall without diagnostics
>
> #include
> wchar_t z[] = L"a"
--- Comment #5 from bergner at gcc dot gnu dot org 2008-04-11 17:20 ---
Created an attachment (id=15467)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15467&action=view)
Restore altivec regs after frame pointer setup
I agree with Andrew, it looks like Eric's patch moved the restor
--- Comment #9 from bkoz at gcc dot gnu dot org 2008-04-11 17:32 ---
OK'd by Richard in private email, so I'm adjusting the Target Milestone to
4.3.1.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from bergner at gcc dot gnu dot org 2008-04-11 17:33 ---
FYI, it results in the updated asm:
--- glibc02-bad.s 2008-04-11 12:21:48.0 -0500
+++ glibc02-good.s 2008-04-11 12:21:33.0 -0500
@@ -66,12 +66,12 @@
mr 3,30
vadduwm 2,31,2
I just tried to compile the Suse Linux package tse3-0.3.1
with the GNU C compiler version 4.4 snapshot 20080404
The compiler said
g++ -DHAVE_CONFIG_H -I. -I../../.. -I../../../src -O2 -g -fmessage-length=0
-D_FORTIFY_SOURCE=2 -W -Wall -ansi -pedantic -MT Alsa-0.9.lo -MD -MP -MF
.deps/Alsa-0.9.Tp
--- Comment #1 from dcb314 at hotmail dot com 2008-04-11 18:08 ---
Created an attachment (id=15468)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15468&action=view)
C++ source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35909
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |sam at gcc dot gnu dot org
|dot org
Hi,
building the target arm-elf fails with:
gcc -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I.
-I/home/mstein/svn/trunk/gcc -I/home/mstein/svn/
--- Comment #3 from mstein dot lists at googlemail dot com 2008-04-11
18:28 ---
Fixed.
--
mstein dot lists at googlemail dot com changed:
What|Removed |Added
--- Comment #2 from mstein dot lists at googlemail dot com 2008-04-11
18:31 ---
Fixed.
--
mstein dot lists at googlemail dot com changed:
What|Removed |Added
--- Comment #7 from jakub at gcc dot gnu dot org 2008-04-11 18:37 ---
Is it safe to have live data in memory below stack pointer on ppc/ppc64?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35907
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-04-11 19:07 ---
(In reply to comment #7)
> Is it safe to have live data in memory below stack pointer on ppc/ppc64?
powerpc64-*-* yes , powerpc-linux-gnu no. the SysV abi does not define a red
zone.
--Pinski
--
http://gcc.gn
--- Comment #9 from bergner at gcc dot gnu dot org 2008-04-11 19:08 ---
This isn't accessing data below the stack pointer, it's accessing below the
previous stack pointer value which is in the current stack frame.
>From a technical standpoint, the ppc64 ABI allows us to access some numb
--- Comment #10 from jakub at gcc dot gnu dot org 2008-04-11 19:19 ---
Well, for -m64 the code in between the old and new Altivec reg restoring spot
when use_backchain_to_restore_sp will ld 1,0(1). Is altivec_save_offset
guaranteed to be not lower than 288 bytes below this? For -m32, I
Hi,
building m32c-elf fails here:
gcc -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I.
-I/home/mstein/svn/trunk/gcc -I/home/mstein/svn/trunk/gcc/
--- Comment #24 from d at domob dot eu 2008-04-11 20:26 ---
(In reply to comment #23)
> (In reply to comment #22)
> > I think your patch is in a good enough shape to post it to [EMAIL PROTECTED]
> > and ask there for comments; this ensures that all gfortraners read it (and
> > not
> > o
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Summary|ice for legal code |[4.
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-04-11 21:24 ---
Honza?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-04-11 21:24 ---
Honza?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35708
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|jump to label enters catch |[4.2 Regression] jump to
|block
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-04-11 21:29 ---
This is most likely caused by PR 35708.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #11 from bergner at gcc dot gnu dot org 2008-04-11 22:04
---
Hacking the test case to use up more stack space, I did get it to access more
than 288 bytes below the stack frame for -m64, so we obviously need something
more here.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #3 from wilson at tuliptree dot org 2008-04-12 00:45 ---
Subject: Re: New: unsinged long long and while loop evaluation
regression?
I can reproduce this on a 32-bit x86-linux machine (i.e. a 32-bit HWI).
The unsigned long long 0x becomes a (const_double -1 0),
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |sam at gcc dot gnu dot org
|dot org
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |sam at gcc dot gnu dot org
|dot org
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-04-12 03:10 ---
I think this is one of the reasons why x86 should change to HWI is 64bits, it
will get the same code generation between using -m32 on x86_64 and i?86.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-04-12 03:21 ---
On the trunk we get a better ICE:
fs/sfs_xplatform.h:250: internal compiler error: tree check: expected class
'expression', have 'gimple_stmt' (gimple_modify_stmt) in expand_call_inline, at
tree-inline.c:2872
--
--- Comment #3 from sam at gcc dot gnu dot org 2008-04-12 03:23 ---
This appears to be fixed in 4.3.0.
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from sam at gcc dot gnu dot org 2008-04-12 03:24 ---
Confirmed on gcc (GCC) 4.4.0 20080411
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-04-12 03:35 ---
Reduced testcase:
void sfs_freeblocks(void)
{
int a = sfs_native_read_block ();
}
void sfs_native_read_block (void) {}
--- CUT ---
With -pedantic-errors, we error out.
--
pinskia at gcc dot gnu dot org changed
I just write the following code:
int main() {
int i = 0;
int s = 0;
#pragma omp parallel for
for(i = 0; i < 10001; i++) {
/* uncommenting the follow line, it works */
printf("thread %d : %d\n", omp_get_thread_
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-12 04:27 ---
I don't think this is a bug as you did not mark the operations on s as atomic.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35912
--- Comment #2 from neil at daikokuya dot co dot uk 2008-04-12 04:40
---
Subject: Re: Dubious charset conversions
joseph at codesourcery dot com wrote:-
> > GCC accepts the following with -ansi -pedantic -Wall without diagnostics
> >
> > #include
> > wchar_t z[] = L"a" "\xff";
> >
53 matches
Mail list logo
