On 3/23/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
On 23 Mar 2007 05:01:00 -, spark at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> The problematic STRIP_SIGN_NOPS() call is from fold_unary()
> which is called from try_combine_conversion() in tree-ssa-pre.c.
>
> STRIP_SIGN_NOPS() is cal
--- Comment #9 from pinskia at gmail dot com 2007-03-23 08:01 ---
Subject: Re: [4.2 Regression] FRE ignores bit-field truncation (C and C++
front-end don't produce bit-field truncation
On 3/23/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> On 23 Mar 2007 05:01:00 -, spark at gcc do
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-03-23 08:17
---
The good question is why does FRE not do anything on the trunk:
s.b6 = 31;
D.1597_1 = s.b6;
that really should be optimized at the FRE level.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31136
Compiling gcc 4.0.4 with a target of m68k-elf on a x86_64 Linux architecture
(SuSE 10.1), an internal error is generated when compiling libgcc2.c:
Command line that generated internal error:
/home/zdenekjs/68k/gcc-4.0.4-build/gcc/xgcc
-B/home/zdenekjs/68k/gcc-4.0.4-build/gcc/ -nostdinc -B/home/zde
--- Comment #1 from zdenekjs at sarpeidon dot net 2007-03-23 08:47 ---
Created an attachment (id=13257)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13257&action=view)
preprocessed file saved with -save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31324
--- Comment #2 from zdenekjs at sarpeidon dot net 2007-03-23 08:48 ---
Created an attachment (id=13258)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13258&action=view)
Assembly output saved with -save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31324
--- Comment #3 from zdenekjs at sarpeidon dot net 2007-03-23 08:50 ---
Same internal error appears to happen in 4.1.2 and 3.4.6 as well
--
zdenekjs at sarpeidon dot net changed:
What|Removed |Added
--
--- Comment #4 from zdenekjs at sarpeidon dot net 2007-03-23 08:52 ---
only occurs on x86_64 host. If I switch machines to a i686 and compile, error
does not occur. Error still occurs even if I configure with --host=i686-linux
on the x86_64-unknown-linux-gnu machine.
--
http://gcc
--- Comment #2 from ahmadyan at gmail dot com 2007-03-23 09:46 ---
Created an attachment (id=13259)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13259&action=view)
the ii file of the problem.
the following code can trigger the bug in g++ version 4.2 with the following
specs:
Conf
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-03-23 10:05 ---
> I'll run some tests as soon as possible and report back to the mailing list.
See
http://gcc.gnu.org/ml/fortran/2007-03/msg00440.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31234
--- Comment #3 from vda dot linux at googlemail dot com 2007-03-23 12:00
---
You are right, in current svn it is fixed.
BTW I think I see a bug created by this change: with -Os x86_86 ABI will be
violated - arrays larger than 16 bytes will still be aligned only to 4 bytes
because if's a
Currently there is no gcj support on the ARM EABI platform. I have gathered
together a number of patches that allow it to build and will be attaching them
to this bug.
I would like to see this moving forward and getting support into mainline,
there are inevitably going to be issues.
--
--- Comment #1 from s_j_newbury at yahoo dot co dot uk 2007-03-23 12:53
---
Created an attachment (id=13260)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13260&action=view)
libffi completion support for ARM EABI
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31325
--- Comment #2 from s_j_newbury at yahoo dot co dot uk 2007-03-23 12:55
---
Created an attachment (id=13261)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13261&action=view)
add softfloat support to libffi for ARM EABI
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31325
--- Comment #1 from pault at gcc dot gnu dot org 2007-03-23 12:55 ---
This is a case of cyclic specification so I have changed the keyword to
ice-on-ivalid.
Confirmed
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from s_j_newbury at yahoo dot co dot uk 2007-03-23 13:03
---
Created an attachment (id=13262)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13262&action=view)
EABI can't implement _Unwind_Backtrace
This patch is from this bug:
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #4 from s_j_newbury at yahoo dot co dot uk 2007-03-23 13:08
---
Created an attachment (id=13263)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13263&action=view)
enable the libgcj interpreter for arm platforms
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31325
--- Comment #5 from s_j_newbury at yahoo dot co dot uk 2007-03-23 13:11
---
--disable-sjlj-exceptions needs to be supplied to configure since it is not
automatically detected
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31325
--- Comment #6 from s_j_newbury at yahoo dot co dot uk 2007-03-23 13:13
---
I have encountered a strange build failure with classpath. It is somehow
getting the build order wrong resulting in this error:
/home/tmp/portage/dev-java/gcj-4.2.0_beta20070307/work/build/gcc/gcj
-B/home/tmp/
--- Comment #7 from s_j_newbury at yahoo dot co dot uk 2007-03-23 13:22
---
Created an attachment (id=13264)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13264&action=view)
arm-iwmmxt-linux-gnueabi platform support
I'm using arm-iwmmxt-linux-gnueabi instead of arm-none-linux-gnu
G++ incorrectly rejects the following valid code
struct A { int x; };
struct B { int x; };
struct C : virtual A, virtual B { int x; };
struct D : virtual A, virtual B, virtual C { };
int main()
{
D* d = new D();
d->x = 42;
}
--
Summary: data members in multiple inheritance
--- Comment #11 from joseph at codesourcery dot com 2007-03-23 13:41
---
Subject: Re: [4.2 Regression] FRE ignores
bit-field truncation (C and C++ front-end don't produce bit-field truncation
On Fri, 23 Mar 2007, pinskia at gmail dot com wrote:
> No, STRIP_SIGN_NOPS is correct, just
--- Comment #1 from gdr at gcc dot gnu dot org 2007-03-23 13:45 ---
.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #3 from bangerth at dealii dot org 2007-03-23 14:09 ---
Confirmed, but this has already been fixed after release 3.4.4 and
before release 3.4.5. None of the newer releases are affected.
W.
--
bangerth at dealii dot org changed:
What|Removed
--- Comment #10 from mmitchel at gcc dot gnu dot org 2007-03-23 15:00
---
What does the C standard say about calloc? That's a similar case; the
multiplication is in calloc. Does it have to report an error?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19351
gcc information:
Using built-in specs.
Target: i686-linux
Configured with: ../gcc-4.1.1/configure
--prefix=/build/toolchain/lin32/gcc-4.1.1 --disable-nls --enable-shared
--enable-threads=posix --enable-languages=c,c++ --with-gnu-as --with-gnu-ld
--target=i686-linux
--with-as=/build/too
--- Comment #1 from thutt at vmware dot com 2007-03-23 15:02 ---
Created an attachment (id=13265)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13265&action=view)
Simple script to build test program at all optimization levels
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3132
--- Comment #2 from thutt at vmware dot com 2007-03-23 15:03 ---
Created an attachment (id=13266)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13266&action=view)
Simple source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31327
--- Comment #3 from thutt at vmware dot com 2007-03-23 15:03 ---
Created an attachment (id=13267)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13267&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31327
--- Comment #11 from schwab at suse dot de 2007-03-23 15:09 ---
"The calloc function allocates space for an array of nmemb objects, each of
whose size is size."
There is no mentioning of overflow, but the allocated space must surely be big
enough to hold the array, and calloc shall fail
--- Comment #8 from s_j_newbury at yahoo dot co dot uk 2007-03-23 15:20
---
I've now hit:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24154
I only have 64M RAM + 256M swap, make is running out of memory and getting
killed.
Maybe I can add some more swap over NFS...?
--
http://gcc
--- Comment #12 from fw at deneb dot enyo dot de 2007-03-23 15:23 ---
Subject: Re: operator new[] can return heap blocks which are too small
* mmitchel at gcc dot gnu dot org:
> What does the C standard say about calloc? That's a similar case; the
> multiplication is in calloc. Does
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-23 15:37 ---
*** This bug has been marked as a duplicate of 26719 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #14 from pinskia at gcc dot gnu dot org 2007-03-23 15:37
---
*** Bug 31327 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-23 15:48 ---
Maybe this is not obvious to me why this is valid code, why is this valid code?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31326
--- Comment #15 from thutt at vmware dot com 2007-03-23 15:51 ---
In regards to comment #13: In what tarball is this defect fixed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26719
--- Comment #16 from pinskia at gcc dot gnu dot org 2007-03-23 15:54
---
> In regards to comment #13: In what tarball is this defect fixed?
The 4.1.2 release as indicated by the target milestone and the known to work
field.
--
pinskia at gcc dot gnu dot org changed:
Wha
The C++ code below demonstrates how gcc treats an instance of a temporary as a
variable declaration instead. Without ugly syntax work-arounds, it is not
possible to instantiate the temporary.
[ Code Begins ]
struct Obj
{
int a ;
} ;
typedef Obj * Obj_P ;
class Foo
{
--- Comment #1 from danq at acacetus dot com 2007-03-23 16:13 ---
Created an attachment (id=13268)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13268&action=view)
Example C++ source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31328
--- Comment #2 from danq at acacetus dot com 2007-03-23 16:14 ---
Created an attachment (id=13269)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13269&action=view)
The compiler output and error messages
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31328
--- Comment #3 from danq at acacetus dot com 2007-03-23 16:14 ---
Created an attachment (id=13270)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13270&action=view)
The preprocessed output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31328
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-23 16:17 ---
IIRC this is what the C++ standard says this is parsed as.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31328
--- Comment #10 from patchapp at dberlin dot org 2007-03-23 16:20 ---
Subject: Bug number PR31199
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/2007-03/msg01554.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #10 from rth at gcc dot gnu dot org 2007-03-23 16:31 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from mstein at phenix dot rootshell dot be 2007-03-23 17:19
---
The Revision 123119 no longer has the reported problem.
--
mstein at phenix dot rootshell dot be changed:
What|Removed |Added
--
--- Comment #2 from mstein at phenix dot rootshell dot be 2007-03-23 17:24
---
The Revision 123136 no longer has the reported problem.
--
mstein at phenix dot rootshell dot be changed:
What|Removed |Added
--
--- Comment #7 from s_j_newbury at yahoo dot co dot uk 2007-03-23 18:16
---
make version 3.81 on Gentoo (ARM EABI) needs 712MB at this point with
gcc-4.2-20070307. I've had to use a CF disk to add enough swapspace :(. make
3.80-r4 (Gentoo includes a memory usage patch) uses even more.
--- Comment #3 from gdr at cs dot tamu dot edu 2007-03-23 18:33 ---
Subject: Re: data members in multiple inheritance
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| Maybe this is not obvious to me why this is valid code, why is this
| valid code?
paragrpah 10.2/2 fro
--- Comment #9 from tromey at gcc dot gnu dot org 2007-03-23 19:32 ---
I didn't read the patches yet.
Do you have a copyright assignment? That is a prerequisite for
getting these changes in. Once that is resolved we can proceed
with the normal patch review process.
If you don't have
/*
the following example crashes g++:
4:13pm [EMAIL PROTECTED] /wga/dev/ilya > g++ -v
Using built-in specs.
Target: ia64-unknown-linux-gnu
Configured with: ../configure --prefix=/wga1/gcc-4.1.1
Thread model: posix
gcc version 4.1.1
4:13pm [EMAIL PROTECTED] /wga/dev/ilya > echo $OSTYPE
linux
4:13pm
--- Comment #1 from tkoenig at alice-dsl dot net 2007-03-23 20:14 ---
The eoshift.f90 case is 'mostly harmless'. We are doing calculations
with the value, but don't actually use this for anything.
We can "fix" this (cosmetic fix for valgrind, really) by
setting sstride[0] to an arbitra
--- Comment #31 from janis at gcc dot gnu dot org 2007-03-23 20:51 ---
As for the puzzle in comment #30, I don't understand it either, but didn't try
very hard. This works for the current testsuite and the patch:
struct g g2 = { { 0, { 1 } } }; /* { dg-error "nested context.*g2.f.x" "n
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|fortran |libfortran
--- Comment #32 from janis at gcc dot gnu dot org 2007-03-23 21:15 ---
Manuel, I'm starting to clean up tests so they can be used with or without the
patch, like the fixes you've been posting. First I'm doing tests in
gcc.dg/dfp. Let me know if there's an area you're not already lookin
Program:
__attribute__ ((naked)) int main(void)
{
return 0;
}
Compiled with 4.1.1 for the AVR target:
Compiling C: test.c
avr-gcc -c -mmcu=atmega128 -I. -gdwarf-2 -DF_CPU=800UL -Os -funsigned-char
-funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes
-Wa,-adhlns=./tes
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|fortran |libfortran
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known t
--- Comment #3 from fb at frank-buss dot de 2007-03-23 21:27 ---
I can reproduce the problem on a Linkstation Pro with an ARM926EJ CPU. I
compiled GCC SVN revision 123155 from the gcc-4_2-branch on it. Creating wrong
assembler code is at least a major bug, even when using the optimizing
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2007-03-23 21:28
---
Confirming this as a low-priority enhancement. After all, even though we have
historical reasons to implement GETLOG using getlogin(), if the information
returned by another scheme is more relevant *in all cases*
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-23 21:32
---
We could do that, I even know precisely how and it's not too hard. It requires
creating a call to a va_arg function in the front-end, which I would need to
research because I've never done that.
--
fxcoudert a
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-03-23 21:34
---
We probably don't want to add all the g77 case options, but I can see why
-fcase-preserve would be a good one to add.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-03-23 21:41
---
There are only two restrictions on the namelist-group-objects, and this one is
not in the list:
C574 (R553) A namelist-group-object shall not be an assumed-size array.
C575 (R552) A namelist-group-object shall no
--- Comment #33 from manu at gcc dot gnu dot org 2007-03-23 21:52 ---
(In reply to comment #32)
> Manuel, I'm starting to clean up tests so they can be used with or without the
> patch, like the fixes you've been posting. First I'm doing tests in
> gcc.dg/dfp. Let me know if there's an
--- Comment #34 from manu at gcc dot gnu dot org 2007-03-23 21:59 ---
Created an attachment (id=13271)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13271&action=view)
Script to make automatic fixes to the testsuite
This script fixes the work-arounds used in the testsuite with som
--- Comment #35 from manu at gcc dot gnu dot org 2007-03-23 22:06 ---
(In reply to comment #32)
> Manuel, I'm starting to clean up tests so they can be used with or without the
> patch, like the fixes you've been posting. First I'm doing tests in
> gcc.dg/dfp.
I don't see any failure
--- Comment #36 from manu at gcc dot gnu dot org 2007-03-23 22:13 ---
Created an attachment (id=13272)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13272&action=view)
List of broken testcases at revision 123028
Janis, this is the list of testcases broken by the last version of th
--- Comment #11 from tobi at gcc dot gnu dot org 2007-03-23 22:27 ---
I've implemented Steven's bitmap idea (see PR18540). spaghetti 9 compiles
within the blink of an eye. Unfortunately, my current patch foregos step four
from resolve_branch, which is necessary to establish validit
--- Comment #12 from tobi at gcc dot gnu dot org 2007-03-23 22:35 ---
Well, "within the blink of an eye" because I was looking at spaghetti 1000 :-)
But the increase in time is linear.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18937
--- Comment #27 from anlauf at gmx dot de 2007-03-23 22:39 ---
Created an attachment (id=13273)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13273&action=view)
Another variant of the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
--- Comment #28 from anlauf at gmx dot de 2007-03-23 22:39 ---
Created an attachment (id=13274)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13274&action=view)
Namelist for the modified demo
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
--- Comment #29 from anlauf at gmx dot de 2007-03-23 22:43 ---
(In reply to comment #27)
Jerry,
with the latest variant of your patch I get a failing namelist read
with the new reduced testcase gfcbug61a.f90 (uses gfcbug61a.nml).
If I remove one of the entries in the namelist file,
th
--- Comment #37 from janis at gcc dot gnu dot org 2007-03-23 22:48 ---
The tests in gcc.dg/dfp are only run for a compiler configured with
--enable-decimal-float; the diagnostics tests there often just have "error" or
"warning" as the expression to match. I have patches for those and fo
--- Comment #38 from janis at gcc dot gnu dot org 2007-03-23 23:52 ---
For comment #32 I get the failure but don't understand the problem; the regexp
matches the message, doesn't it? This doesn't seem any different from other
Fortran tests but it's the only one that fails; perhaps there
--- Comment #1 from fang at csl dot cornell dot edu 2007-03-24 00:26
---
PR 27102 dup?
using template parameter as a class name of member function.
--
fang at csl dot cornell dot edu changed:
What|Removed |Added
---
--- Comment #39 from manu at gcc dot gnu dot org 2007-03-24 00:28 ---
(In reply to comment #37)
> The tests in gcc.dg/dfp are only run for a compiler configured with
> --enable-decimal-float; the diagnostics tests there often just have "error" or
> "warning" as the expression to match.
--- Comment #2 from tprince at computer dot org 2007-03-24 01:22 ---
Note that the newly built bootstrap compiler fails the configure tests which
have a trailing -V on the command line. Nearly all the various configure
scripts provoke this failure. The one cited here happens to be the
--- Comment #3 from tprince at computer dot org 2007-03-24 03:06 ---
The failure can be worked around by commenting out the section of in
the cygwin distribution which sets __SCLE (conversion of \r\n to \n, according
to comments). The code thus commented out apparently requires some
78 matches
Mail list logo
