--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
|
--- Comment #9 from burnus at gcc dot gnu dot org 2009-06-29 07:49 ---
Can this be backported to 4.4? If so, it should happen soonish to be in 4.4.1.
Paul, shall I do it for you?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40443
$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /root/gcc-4.4.0/configure --prefix=/opt/gcc-4.4.0
--enable-languages=c,c++
Thread model: posix
gcc version 4.4.0 (GCC)
Here is a program to reproduce this problem :-
#include
#include
#define MinWordStr "-2147483648"
#de
--- Comment #3 from ubizjak at gmail dot com 2009-06-29 08:35 ---
(In reply to comment #2)
> Still present in GCC 4.5.0 20090513.
Are you sure?
config/rs6000/rs6000.c has:
static tree
rs6000_builtin_conversion (unsigned int tcode, tree type)
rs6000 target is also a member of vect_int
--- Comment #8 from ubizjak at gmail dot com 2009-06-29 08:47 ---
(In reply to comment #7)
> OTOH, doing integer arithmetics on 64bit _image_ of FP value has questionable
> usability, so the motivation to fix this PR is proportionally low...
So, wontfix.
--
ubizjak at gmail dot com
If one passes an ALLOCATABLE variable as actual to a dummy argument which is
not ALLOCATBLE, the should be an optional run-time to check whether the
variable is allocated.
For pointers, one could check whether a pointer is NULL as this means
non-associated. Checking for an uninitialized pointer is
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-06-29 09:10 ---
The following loop invokes undefined behavior:
long x = -2147483645;
int i;
for (i = 0; i < 4; ++i) {
p = itos(x);
printf("i=%d p=%s\n",i,p);
--x;
}
because at iteration wit
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-06-29 09:12 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
Found at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/b232bca9766094cc
which contains several tests:
- NR : Normal Routines
- ER : Elemental Routines
- NF : Normal Functions (scalar operators)
- EF : Elemental functions (vector operators)
- SC : Scalar Computation
The in
--- Comment #7 from pault at gcc dot gnu dot org 2009-06-29 09:20 ---
(In reply to comment #6)
> (In reply to comment #5)
> The following fixes the problem. It needs to be checked to see if it is
> over-restrictive.
Yes it is - there is no need for this when the lhs section is contiguo
--- Comment #10 from pault at gcc dot gnu dot org 2009-06-29 09:23 ---
(In reply to comment #9)
> Can this be backported to 4.4? If so, it should happen soonish to be in 4.4.1.
> Paul, shall I do it for you?
>
Thanks for the offer, Tobias - I'll be attending to it tonight.
Did you see
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-06-29 09:29 ---
Which is because we run into
static int
compare_values_warnv (tree val1, tree val2, bool *strict_overflow_p)
{
...
/* We cannot compare overflowed values, except for overflow
infinities. */
if
I just tried to compile the Suse Linux package sblim-sfcb-1.3.2-16.15
with the GCC compiler version 4.5 snapshot 20090625.
The compiler said
selectcond.c: In function '__eft_getSubCondAt':
selectcond.c:78:21: error: non-trivial conversion at assignment
struct CMPIInstance *
void *
# .MEM_38 = VDEF
--- Comment #1 from dcb314 at hotmail dot com 2009-06-29 10:42 ---
Created an attachment (id=18089)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18089&action=view)
C source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40582
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-06-29 11:10 ---
Confirmed. -fno-tree-sra fixes this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from jamborm at gcc dot gnu dot org 2009-06-29 11:16 ---
OK, I'll have a look at it after I am done with PR 40554.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from jamborm at gcc dot gnu dot org 2009-06-29 11:22 ---
I'm quite confident this is a cgraph bug => CCing honza. (I'll try to keep
this on my radar but there are other issues for which I am certainly
responsible now).
--
jamborm at gcc dot gnu dot org changed:
I do observe the behaviour with a gcc/gfortran installed from plain vanilla
upstream in Source Mage GNU/Linux; not with an older gfortran as packaged in
SuSE Linux. So I assume it's either a configuration issue (spec files?) or a
regression from 4.1.2 prerelease.
Anyhow: The automatic preprocessin
Note: This may be related to #40583 (possibly an issue with the installation)
I do observe the behaviour with a gcc/gfortran installed from plain vanilla
upstream in Source Mage GNU/Linux; not with an older gfortran as packaged in
SuSE Linux. So I assume it's either a configuration issue (spec fil
From
if (__p_91 != 0B)
goto ;
else
goto ;
# SUCC: 39 [100.0%] count:931 (true,exec) 40 (false,exec)
# BLOCK 39 freq:4175 count:931
# PRED: 38 [100.0%] count:931 (true,exec)
operator delete (__p_91);
# SUCC: 40 [100.0%] count:931 (fallthru,exec)
# BLOCK 40 freq:4188 cou
--- Comment #1 from ktietz at gcc dot gnu dot org 2009-06-29 11:54 ---
Well, I see. A redefinition issue. Does the following patch fixes your issue?
Index: gcc/gcc/ada/adaint.h
===
--- gcc.orig/gcc/ada/adaint.h 2009-06-22
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-06-29 11:57 ---
Subject: Bug 40579
Author: rguenth
Date: Mon Jun 29 11:57:15 2009
New Revision: 149046
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149046
Log:
2009-06-29 Richard Guenther
PR tree-optimization/
--- Comment #1 from steven at gcc dot gnu dot org 2009-06-29 12:00 ---
Ack. Honza, yours I would guess.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2009-06-29 12:02 ---
Richi, do you have a test case you can share? I have seen this problem in code
I can't take public...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40585
--- Comment #4 from reichelt at gcc dot gnu dot org 2009-06-29 12:04
---
Reduced tescase (crashes with "-O"):
=
struct A
{
void* q;
int i;
};
union U
{
char* p;
struct A a;
};
struct A foo(union U u)
{
struct A a = { 0, 0 };
a = u.a;
retu
--- Comment #3 from rguenther at suse dot de 2009-06-29 12:08 ---
Subject: Re: [4.3/4.4/4.5 Regression] tracer
duplicates blocks w/o adjusting EH tree
On Mon, 29 Jun 2009, steven at gcc dot gnu dot org wrote:
> --- Comment #2 from steven at gcc dot gnu dot org 2009-06-29 12:02
--- Comment #2 from laurent at guerby dot net 2009-06-29 12:10 ---
Might be safer to rename to GNAT_FOPEN or something like that? FOPEN is likely
to be taken on more than one platform.
--
laurent at guerby dot net changed:
What|Removed |Added
-
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-06-29 12:20 ---
Subject: Bug 38212
Author: rguenth
Date: Mon Jun 29 12:20:39 2009
New Revision: 149047
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149047
Log:
2009-06-29 Richard Guenther
PR middle-end/38212
--- Comment #16 from rguenth at gcc dot gnu dot org 2009-06-29 12:23
---
Subject: Bug 14187
Author: rguenth
Date: Mon Jun 29 12:23:21 2009
New Revision: 149048
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149048
Log:
2009-06-29 Richard Guenther
PR middle-end/14187
--- Comment #17 from rguenth at gcc dot gnu dot org 2009-06-29 12:24
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-06-29 12:25 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from burnus at gcc dot gnu dot org 2009-06-29 12:27 ---
Hmm, the following works here on x86_64-openSUSE (the -4.x are the ones of
openSUSE; the last one is today's vanilla trunk build):
gcc-4.2 -c aa.F90; gcc-4.3 -c aa.F90; gcc-4.4 -c aa.F90; gcc -c aa.F90
gfortran-4.2 a
I'm using OpenEmbedded to cross-compile xf86-input-keyboard-1.2.2 for the
OpenMoko FreeRunner.
It appears that the cross-compiler is inserting an invalid header location,
with -I/usr/include/xorg .
The exact error message is below.
I would imagine that "cc1: internal compiler error: in add_path
--- Comment #1 from cfriedt at visible-assets dot com 2009-06-29 12:33
---
Created an attachment (id=18090)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18090&action=view)
config.log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40586
--- Comment #1 from burnus at gcc dot gnu dot org 2009-06-29 12:41 ---
> The automatism works fine for .f90 files, so I suppose it is supposed to
> work for .f95, too?
>
> I guess a fix is simple (making that file suffix known). I am rather wondering
> why our install of (as far as possi
--- Comment #3 from ktietz at gcc dot gnu dot org 2009-06-29 12:45 ---
Yeah, this would be the best way to solve this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40578
See attached test-case, test.f:
> gfortran -c test.f -O1
Compiles OK
> gfortran -c test.f -O2
test.f: In function "test":
test.f:13: internal compiler error: in emit_swap_insn, at reg-stack.c:827
> gfortran -v
Using built-in specs.
Target: i586-redhat-linux
Configured with: ../configure --prefix
--- Comment #2 from thomas dot orgis at awi dot de 2009-06-29 12:51 ---
Thanks for confirming that it _should_ work.
Now the question is: What is wrong with the installation on my system so that
it does not work?
I see that gfortran is apparently trying to preprocess the .F95 files, but
--- Comment #1 from pmblakely at googlemail dot com 2009-06-29 12:51
---
Created an attachment (id=18091)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18091&action=view)
Minimal test-case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40587
--- Comment #2 from thomas dot orgis at awi dot de 2009-06-29 12:54 ---
Well, then, I have to assume that the Source Mage gcc install screws up.
As to "contact the vendor": I change that to "fix that install process", as I
am sort of part of said GNU/Linux vendor, the Source Mage distrib
Looking at the code, I think that the following lines from match_charkind_name
(primary.c:830):
if (!ISALNUM (c)
&& c != '_'
&& (gfc_option.flag_dollar_ok && c != '$'))
break;
should be changed to:
if (!ISALNUM (c)
&& c != '_'
&& !(gfc_
--- Comment #3 from kargl at gcc dot gnu dot org 2009-06-29 14:25 ---
(In reply to comment #1)
>
> It is extremely unlikely that such a change would go unnoticed. The GCC test
> suite contains .f90, .f03 and .f08 and .F90 files. (Admittedly, no .f95/.F95
> file.) The testsuite is run on
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-06-29 14:25 ---
Didn't GCC say report the bug to http://bugzilla.redhat.com/bugzilla ?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from pmblakely at googlemail dot com 2009-06-29 14:28
---
(In reply to comment #2)
> Didn't GCC say report the bug to http://bugzilla.redhat.com/bugzilla ?
>
Oh, yes. Sorry. I'll post it there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40587
--- Comment #4 from ubizjak at gmail dot com 2009-06-29 14:36 ---
The test also fails with FSF 4.4.1 and 4.5.0, but not with 4.3.4, which makes
for 4.4 regression.
--
ubizjak at gmail dot com changed:
What|Removed |Added
---
--- Comment #3 from kargl at gcc dot gnu dot org 2009-06-29 14:39 ---
(In reply to comment #2)
>
> # install part
>
> cd $SOURCE_DIRECTORY.bld &&
>
> make -C gcc lang.install-common lang.install-man &&
> install -c gcc/f951 ${INSTALL_ROOT}/usr/libexec/gcc/$HOST/$VERSION/ &&
> sedi
--- Comment #4 from kargl at gcc dot gnu dot org 2009-06-29 14:40 ---
See PR 40583 for a possible explanation.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40585
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-06-29 14:48 ---
Subject: Bug 40579
Author: rguenth
Date: Mon Jun 29 14:48:15 2009
New Revision: 149051
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149051
Log:
2009-06-29 Richard Guenther
PR tree-optimization/
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-06-29 14:52 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-06-29 14:52 ---
Subject: Bug 40579
Author: rguenth
Date: Mon Jun 29 14:52:20 2009
New Revision: 149052
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149052
Log:
2009-06-29 Richard Guenther
PR tree-optimization/
I am working on a port for the TriMedia processor family, and I was playing
around with the following example (extracted from
gcc.c-torture/execute/simd-2.c) to see how well our port takes advantage of the
addv2hi3 operator of our tm3271 processor.
test.c:
...
typedef short __attribute__((vector_s
--- Comment #20 from dave dot korn dot cygwin at gmail dot com 2009-06-29
15:12 ---
I think the best solution to this problem is to enable libstdc++ as a DLL, and
export _S_empty_rep from it. Then every C++ DLL and EXE will link against
libstdc++ and they'll all import the exact same i
--- Comment #1 from burnus at gcc dot gnu dot org 2009-06-29 15:17 ---
I agree that
&& (gfc_option.flag_dollar_ok && c != '$'))
is wrong and is should either be
&& !(gfc_option.flag_dollar_ok && c == '$'))
^^^ ^^
or equivalent
--- Comment #8 from pault at gcc dot gnu dot org 2009-06-29 15:18 ---
Created an attachment (id=18092)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18092&action=view)
Provisional fix for the PR
This is not yet regtested but will be in an hour or two.
I must also run through the
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-06-29 15:40 ---
Good observations. Patches should be sent to gcc-patc...@gcc.gnu.org together
with a changelog entry following existing practice and a note how you tested
the patch. See gcc.gnu.org/contribute.html.
--
http://
gcj does not mangle names correctly.
In particular, when a member name is a C++ keyword, "$" is appended to the
name. However, this is results in an illegal mangled name so it is not
possible to refer to the member from CNI code.
Also, the set of C++ keywords in gjavah is different from the set
--- Comment #1 from aph at gcc dot gnu dot org 2009-06-29 16:12 ---
See the thread at http://gcc.gnu.org/ml/java/2009-06/msg00066.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40590
--- Comment #2 from ramana at gcc dot gnu dot org 2009-06-29 16:14 ---
Try with a newer version of the compiler. The cross compiler shouldn't be
inserting a -I/usr/include/xorg . It must be a function of your environment.
Also we no longer support 4.1.2. Try using a more recent version
--- Comment #5 from hjl dot tools at gmail dot com 2009-06-29 16:18 ---
Revision 139590 (IRA):
http://gcc.gnu.org/ml/gcc-cvs/2008-08/msg01152.html
is very likely the cause.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
--- Comment #1 from burnus at gcc dot gnu dot org 2009-06-29 16:23 ---
Mine. I have a patch.
PR 29616 is related, but goes beyond by checking also assignments to pointers
and undefined pointers (not only for unassociated pointers). (For -std=f95 one
can also check assignments to allocat
--- Comment #2 from aph at gcc dot gnu dot org 2009-06-29 16:26 ---
Created an attachment (id=18093)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18093&action=view)
Test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40590
--- Comment #11 from pault at gcc dot gnu dot org 2009-06-29 16:45 ---
Subject: Bug 40443
Author: pault
Date: Mon Jun 29 16:44:49 2009
New Revision: 149056
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149056
Log:
2009-06-29 Paul Thomas
PR fortran/40443
* in
--- Comment #12 from pault at gcc dot gnu dot org 2009-06-29 16:46 ---
Fixed on trunk and 4.4
Thanks for the report
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from hjl dot tools at gmail dot com 2009-06-29 16:57 ---
Revision 139590 is the cause.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
The following program fails with:
procedure(sub), pointer :: pptr2
1
Error: Interface 'sub' of procedure 'pptr2' at (1) must be explicit
The question is whether it is valid or not. As both NAG f95 and ifort reject it
(g95 accepts it), it might be invalid.
I have been trying to build blackfin toolchain.
The command line that trigger the bug is:
$ ~/blackfin-sources/toolchain/buildscript/BuildToolChain -b
~/blackfin-sources/build -k
~/blackfin-sources/uClinux-dist-2008R1.5-RC3/linux-2.6.x -s
~/blackfin-sources/toolchain -u ~/blackfin-sources/u-boot-1.
--- Comment #5 from jamborm at gcc dot gnu dot org 2009-06-29 17:11 ---
Created an attachment (id=18094)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18094&action=view)
Fix
It turns out that build_ref_for_offset apparently needs to check for
full type compatibility and node ju
--- Comment #2 from janis at gcc dot gnu dot org 2009-06-29 17:13 ---
Subject: Bug 39902
Author: janis
Date: Mon Jun 29 17:13:33 2009
New Revision: 149058
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149058
Log:
PR c/39902
* tree.c (real_zerop, real_onep, real_
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
Component|c |bootstrap
ht
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-06-29 17:20 ---
> Please report an error to http://blackfin.uclinux.org/gf/project/toolchain
Did you read that part of the message?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Ad
Here, the proc-pointer result is passed as actual argument to a procedure which
does not want to have the pointer but the pointer target.
There are two problems: The first program shows wrong code:
sub (void (*) (integer(kind=4) &) f)
but passed is:
void (*) (integer(kind=4) &) D.1559;
D
--- Comment #1 from burnus at gcc dot gnu dot org 2009-06-29 17:40 ---
Hmm, something else goes wrong, too, my fix for PR 40580 does not generate a
check (for procpointer results), it does for pointer function results and it
does for normal proc pointers. Thus, it either gets fixed autom
--- Comment #10 from mckelvey at maskull dot com 2009-06-29 17:46 ---
(In reply to comment #9)
> Ok, then for now let's close it as WONTFIX...
>
Problem. With --enable-clocale=generic even the most basic locale support has
vanished.
try
{
us_locale = std::locale("en_US
--- Comment #3 from aph at gcc dot gnu dot org 2009-06-29 17:51 ---
Subject: Bug 40590
Author: aph
Date: Mon Jun 29 17:50:59 2009
New Revision: 149059
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149059
Log:
2009-06-29 Andrew Haley
PR java/40590
* tools/
The code I'm going to attach shows strange results with trunk, but works as
expected with 4.4.
In short, within a TYPE, a LOGICAL component is initialized to .FALSE.
(dummy_atom_init). The calling procedure (dummy_atom_model_init) that checks
the same LOGICAL component sees it as .TRUE. immediate
--- Comment #11 from paolo dot carlini at oracle dot com 2009-06-29 17:55
---
Of course, that's expected. Really, it's time to update your glibc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40511
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-06-29 17:57 ---
Created an attachment (id=18095)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18095&action=view)
Smallish testcase.
The testcase. Probably not minimal yet, but as close as I can get it now.
Compiled as:
$> r
--- Comment #1 from daney at gcc dot gnu dot org 2009-06-29 18:36 ---
Do either of these patches fix the problem?
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01267.html
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01978.html
--
daney at gcc dot gnu dot org changed:
What
template
struct S
{
typedef int type;
};
template
struct Get
{
static T get();
};
#ifdef BUG
# define ELLIPSIS ...
#else
# define ELLIPSIS
#endif
template
struct B
{
template
typename S::get() (Get::get() ELLIPSIS) )>::type
f(Args&& ELLIPSIS a);
};
struct X
{
boo
--- Comment #7 from vmakarov at redhat dot com 2009-06-29 19:44 ---
Paolo, Steven, thanks for looking into this problem. Using the mips approach
is a good idea. Although the costs of FLOAT_REGS and SSE_REGS are the same in
ira-costs.c, IRA should prefer SSE_REGS or FLOAT_REGS depending
--- Comment #14 from ppluzhnikov at google dot com 2009-06-29 20:11 ---
I verified that @146817 is not causing the current 32-bit breakage; I'll open a
separate PR.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40012
--- Comment #9 from pault at gcc dot gnu dot org 2009-06-29 20:39 ---
Subject: Bug 40551
Author: pault
Date: Mon Jun 29 20:38:59 2009
New Revision: 149062
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149062
Log:
2009-06-29 Paul Thomas
PR fortran/40551
* dep
--- Comment #3 from burnus at gcc dot gnu dot org 2009-06-29 21:00 ---
PR 40580 added an argument checking for pointer/proc-pointer/allocatable, i.e.
the example "call foo(r)" of comment 0 is now detected via -fcheck=pointer.
TODO:
a) call sub( uninit_alloc_returning_function() )
does
--- Comment #2 from burnus at gcc dot gnu dot org 2009-06-29 21:00 ---
-fcheck=pointer (remaining issues/features) is now tracked at PR 40593
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40593
The test case from bug 40012 still fails in current mainline @149059 in 32-bit
mode:
--- cut ---
struct list_s {
struct list_s* next;
};
typedef struct list_s list;
void f1(void*, list*);
int
f0(void* a,
void* b,
void* c,
list* d)
{
list* problem;
for(problem = d; problem; pro
--- Comment #2 from burnus at gcc dot gnu dot org 2009-06-29 21:02 ---
Subject: Bug 40580
Author: burnus
Date: Mon Jun 29 21:02:17 2009
New Revision: 149063
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149063
Log:
2009-06-29 Tobias Burnus
PR fortran/40580
*
--- Comment #3 from burnus at gcc dot gnu dot org 2009-06-29 21:02 ---
FIXED on the trunk (4.5). Follow up is PR 29616
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
---
On June 28th, the powerpc bootstrap was broken due to changes to expmed.c. The
bootstrap dies when compiling libgcc.a as mentioned in:
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg02180.html
emit_store_flag gets a GT test that it tries to convert to LE. Inside the
recursive call, it then tries t
--- Comment #1 from bonzini at gnu dot org 2009-06-29 21:32 ---
Mine of course. I was going to post the patch to the mailing list after it was
well into my x86_64-linux bootstrap, I'll add it here.
Thanks for the testcase BTW.
--
bonzini at gnu dot org changed:
What
--- Comment #2 from bonzini at gnu dot org 2009-06-29 21:34 ---
Created an attachment (id=18096)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18096&action=view)
patch currently in stage2
Here it is. A bit early for posting to gcc-patches, but if you want to approve
it I'll commi
--- Comment #3 from meissner at gcc dot gnu dot org 2009-06-29 21:36
---
Created an attachment (id=18097)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18097&action=view)
Proposed patch to fix the problem
This patch allows the powerpc64-gnu-linux system to boostrap once again.
--- Comment #4 from meissner at linux dot vnet dot ibm dot com 2009-06-29
21:46 ---
Subject: Re: Powerpc bootstrap is broken due to changes in expmed.c
On Mon, Jun 29, 2009 at 09:34:02PM -, bonzini at gnu dot org wrote:
>
>
> --- Comment #2 from bonzini at gnu dot org 2009-
--- Comment #1 from hjl dot tools at gmail dot com 2009-06-29 21:51 ---
This is caused by revision 147995:
http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00974.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--- Comment #2 from hjl dot tools at gmail dot com 2009-06-29 21:54 ---
This is related to PR 40304.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40596
--- Comment #3 from ppluzhnikov at google dot com 2009-06-29 22:36 ---
Confirmed working correctly @147994.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40596
--- Comment #2 from daney at gcc dot gnu dot org 2009-06-29 22:50 ---
Well the trunk at r149061 with both the afore mentioned patches applied does
not exhibit the ICE for me on x86_64-pc-linux-gnu. Without the patches I
obtain the ICE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #5 from jason at gcc dot gnu dot org 2009-06-29 23:16 ---
Subject: Bug 40274
Author: jason
Date: Mon Jun 29 23:15:43 2009
New Revision: 149066
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149066
Log:
PR c++/40274
* error.c (dump_template_parms): Pas
--- Comment #6 from jason at gcc dot gnu dot org 2009-06-29 23:18 ---
Subject: Bug 40274
Author: jason
Date: Mon Jun 29 23:18:46 2009
New Revision: 149067
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149067
Log:
PR c++/40274
* error.c (dump_template_parms): Pas
--- Comment #4 from jakub at gcc dot gnu dot org 2009-06-29 23:43 ---
The problem seems to be in based_loc_descriptor:
/* If drap register is used to align stack, use frame
pointer + offset to access stack variables. If stack
is aligned without drap,
1 - 100 of 111 matches
Mail list logo
