--- Comment #70 from ebotcazou at gcc dot gnu dot org 2007-11-03 08:07
---
> Audit trail shows that this isn't a problem with 4.2. Target -> 4.1.3?
Yes, this has been fixed in the 4.2 series according to comment #54.
--
ebotcazou at gcc dot gnu dot org changed:
What
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-11-03 11:04
---
Yep.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONF
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2007-11-03 11:05
---
Investigating.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Assigne
--- Comment #23 from fxcoudert at gcc dot gnu dot org 2007-11-03 12:40
---
(In reply to comment #22)
> This is hard to debug without access to a big-endian
> machine. Renaming, unapplying myself.
This bug isn't present any more, AFAICT. I suspect it was fixed by your
GFOR_POINTER_TO_L
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-11-03 13:00
---
integer i, a(1)
logical(kind=8) s(1)
s = .true.
a = 42
forall (i=1:1, .not. s(1)) a(i) = 0
end
The ICE happens because we return false in validate_subreg(), called from
gen_rtx_SUBREG(). We come int
--- Comment #28 from jason at gcc dot gnu dot org 2007-11-03 13:40 ---
Fixed for 4.3.0.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Known to work|3.
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2007-11-03 14:14
---
It's indeed a target issue, exposed by PRE going out of control and creating
a bunch of new SSA names. I'll post the target fix but I wonder if it's the
right thing to do.
--
http://gcc.gnu.org/bugzilla/show
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |manu at gcc dot gnu dot org
|dot org
--- Comment #29 from hjl at lucon dot org 2007-11-03 14:21 ---
(In reply to comment #27)
>
> In this case, though, the contents of the linkonce section will never
> actually differ; and I believe in this case the offset is zero, so
> even if they did differ it would not matter. Perh
--- Comment #2 from manu at gcc dot gnu dot org 2007-11-03 14:22 ---
Working in a patch.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|un
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-11-03 14:57
---
Subject: Bug 33985
Author: jvdelisle
Date: Sat Nov 3 14:57:13 2007
New Revision: 129870
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129870
Log:
2007-11-03 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-11-03 15:06
---
Fixed on Trunk. Thomas if you think we should do more, please reopen.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from manu at gcc dot gnu dot org 2007-11-03 15:20 ---
This check could be implemented in builtins.c (fold_builtin_next_arg).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30457
--- Comment #2 from manu at gcc dot gnu dot org 2007-11-03 15:32 ---
What about this patch? Does it look correct?
Index: gcc/builtins.c
===
--- gcc/builtins.c (revision 129513)
+++ gcc/builtins.c (working copy)
@@
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-11-03 16:29
---
After discussing with Jerry, I'll close this one as WONTFIX because:
1. it breaks user .xor. operators, unless we hide it behind a
-fxor-intrinsic-operator flag
2. it has never been requested by any user AFAICT
The RM95 B.3.1 contains: "The type chars_ptr is C-compatible and
corresponds to the use of C's ``char *'' for a pointer to the first char
in a char array terminated by nul.".
Doesn't it imply that it has a C convention, or at least that it can be
converted to an access type with convention C witho
--- Comment #24 from jvdelisle at gcc dot gnu dot org 2007-11-03 16:48
---
Subject: Bug 24685
Author: jvdelisle
Date: Sat Nov 3 16:47:37 2007
New Revision: 129871
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129871
Log:
2007-11-03 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2007-11-03 17:21
---
Unassigning myself. I've manage to trim it down a bit, but not that much.
% gfortran foo.f -fcray-pointer -fno-automatic -g -O0 -c
foo.f:3598.19:
common/aux14/stfv(lnv),fni(lnv),fxi(lnv),fyi(lnv),fzi(lnv)
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2007-11-03 17:21
---
Created an attachment (id=14478)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14478&action=view)
Trimmed source
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
Testcase:
union a
{
int i;
float f;
};
void f(float *a, int *b, float e)
{
union a c;
c.f = *a + e;
*b = c.i;
}
--- CUT ---
Currently we get (on x86):
subl$28, %esp
movl32(%esp), %eax
flds40(%esp)
fadds (%eax)
movl36(%esp), %eax
--- Comment #5 from drow at gcc dot gnu dot org 2007-11-03 17:50 ---
Subject: Bug 33921
Author: drow
Date: Sat Nov 3 17:50:20 2007
New Revision: 129872
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129872
Log:
PR debug/33921
* reorg.c (emit_delay_sequence): Do
--- Comment #6 from drow at gcc dot gnu dot org 2007-11-03 17:54 ---
Checked in on trunk.
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
Status|A
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-11-03 17:55 ---
The true cause of this is giving the union, TImode. For the PS3 compiler, I
remove the definition of MAX_FIXED_MODE_SIZE for performance reasons of unions
that had vectors in it.
--
http://gcc.gnu.org/bugzilla/
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-11-03 17:57 ---
This is a target issue for not using the SSE register when doing copies:
;; a = *p
Is expanded as sequences of load/stores.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-11-03 18:05 ---
Doing that (removing MAX_FIXED_MODE_SIZE), gets us:
.pack:
stfd 1,-16(1)
stfd 2,-8(1)
lfd 1,-16(1)
lfd 2,-8(1)
blr
.unpack:
stfd 1,-16(1)
stfd 2,-8(1)
l
--- Comment #19 from pinskia at gcc dot gnu dot org 2007-11-03 18:11
---
(In reply to comment #2)
> If you used GCC's extension of using an union as not violating aliasing rules,
> it works there but does not with using the portable ways:
These are all fixed on PowerPC on the trunk. O
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-11-03 18:13 ---
Ok, looking a little into this shows this is the same issue (or at least
related to) as PR 33989. We have SImode in some places where we could use
SFmode.
--
pinskia at gcc dot gnu dot org changed:
W
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-11-03 18:46 ---
Hmm:
D.561 = s[0];
D.562 = !D.561;
temp.4[mi.8] = D.562;
logical8 D.561;
logical1 D.562;
So we have a TRUTH_NOT_EXPR of a logical8 and that has an implicated cast to
logical1. So this is either a front-e
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-11-03 18:52 ---
The patch to fix the bug:
Index: ../../gcc/fold-const.c
===
--- ../../gcc/fold-const.c (revision 129871)
+++ ../../gcc/fold-const.c (working c
--- Comment #13 from dave at hiauly1 dot hia dot nrc dot ca 2007-11-03
19:37 ---
Subject: Re: FAIL: gfortran.dg/gamma_5.f90
> This implements the fallback functions, but naturally
> doesn't do anything on my linux system (which has all tgamma*
> and lgamma* functions).
You might hack
--- Comment #7 from manu at gcc dot gnu dot org 2007-11-03 19:41 ---
Subject: Bug 29062
Author: manu
Date: Sat Nov 3 19:41:20 2007
New Revision: 129873
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129873
Log:
2007-11-03 Manuel Lopez-Ibanez <[EMAIL PROTECTED]>
PR c/
--- Comment #8 from manu at gcc dot gnu dot org 2007-11-03 19:43 ---
Fixed for GCC 4.3
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-11-03 19:54 ---
I can no longer reproduce this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33458
--- Comment #15 from tkoenig at netcologne dot de 2007-11-03 20:19 ---
Subject: Re: FAIL: gfortran.dg/gamma_5.f90
> --- Comment #13 from dave at hiauly1 dot hia dot nrc dot ca 2007-11-03
> 19:37 ---
> Now, the hard part. The gfortran.dg/gamma_5.f90 test fails at n = 16.
T
--- Comment #6 from reichelt at gcc dot gnu dot org 2007-11-03 20:21
---
Still crashes for me with today's compiler.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33458
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-11-03 20:23 ---
I cannot reproduce this either on x86_64 or powerpc64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33319
--- Comment #9 from sebpop at gmail dot com 2007-11-03 20:39 ---
Subject: Re: [4.2/4.3 regression] g++.dg/tree-ssa/pr27549.C ICE with
vectorization
I cannot reproduce the bug on i686-linux either.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33319
--- Comment #16 from dave at hiauly1 dot hia dot nrc dot ca 2007-11-03
20:47 ---
Subject: Re: FAIL: gfortran.dg/gamma_5.f90
> This works on my i686-pc-linux-gnu system, and also fails when I use
> -ffloat-store. Seems like we have a roundoff problem with normal ieee
> double precisio
--- Comment #3 from jakub at gcc dot gnu dot org 2007-11-03 21:19 ---
Will work on this.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|u
In the code snippet below, the comparison (nullptr == pmf) in main should
compile but on gcc it fails to compile. Compiler fails to find appropriate
conversion operator and gives error saying:
error: no match for operator== in nullptr == pmf
class nullptr_t
{
public:
template
operat
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2007-11-03 22:02
---
Created an attachment (id=14480)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14480&action=view)
Revised preliminary patch that also fixes comment #19
This patch adds some similar code to resolve_unknown_
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2007-11-03 22:12
---
Subject: Bug 33881
Author: fxcoudert
Date: Sat Nov 3 22:12:03 2007
New Revision: 129874
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129874
Log:
PR fortran/33881
* trans-array.c (gfc_
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2007-11-03 22:14
---
Fixed. Thanks Paul!
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Hi
I am trying to compile pthread application , but getting the following error .
I think this is a bug in GCC libraries.
gcc -lpthread -c *.c
srtp_impl.c: In function ?srtp_init_connection?:
srtp_impl.c:8: error: expected expression before ?{? token
srtp_impl.c:9: error: expected expression befor
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-03 22:35 ---
yes we need a full testcase.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca 2007-11-03
22:49 ---
Subject: Re: FAIL: gfortran.dg/gamma_5.f90
> > Now, the hard part. The gfortran.dg/gamma_5.f90 test fails at n = 16.
>
> This works on my i686-pc-linux-gnu system, and also fails when I use
> -ffloat-st
--- Comment #25 from fxcoudert at gcc dot gnu dot org 2007-11-03 23:14
---
(In reply to comment #20)
> arm-unknown-elf has 8000+ failures.
> Some of them are similar to this one (which happen on the other targets as
> well):
> /n/12/rask/src/all/gcc/testsuite/gfortran.dg/chmod_1.f90:0:
--- Comment #10 from belyshev at depni dot sinp dot msu dot ru 2007-11-04
00:06 ---
Doesn't fail on trunk since r129797:
2007-10-31 Sebastian Pop <[EMAIL PROTECTED]>
PR tree-optimization/32377
...
before:
pr27549.C:58: note: create runtime check for data references *D.2383
--- Comment #3 from pcarlini at suse dot de 2007-11-04 00:44 ---
Hi Gaby. Any suggestions for this bug? The must_not_throw_expr thing is trivial
(just like non_dependent_expr, cxx-pretty-print.c is already ok), but what
about the rest, short term? Thanks.
--
pcarlini at suse dot de
Hello!
I am trying to build gcc-4.3 svn since a few days, using dirtyepic's Gentoo
ebuild. I am always getting this error:
/var/tmp/portage/sys-devel/gcc-4.3.0_pre20071028/work/build/./gcc/xgcc
-shared-libgcc
-B/var/tmp/portage/sys-devel/gcc-4.3.0_pre20071028/work/build/./gcc -nostdinc++
--- Comment #1 from lindevel at gmx dot net 2007-11-04 01:38 ---
(Make summary less cryptic)
--
lindevel at gmx dot net changed:
What|Removed |Added
Summary|Bu
--- Comment #2 from lindevel at gmx dot net 2007-11-04 02:02 ---
Created an attachment (id=14481)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14481&action=view)
build.log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33992
--- Comment #3 from dorit at gcc dot gnu dot org 2007-11-04 03:49 ---
Subject: Bug 33987
Author: dorit
Date: Sun Nov 4 03:48:58 2007
New Revision: 129880
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129880
Log:
PR tree-optimization/33987
* tree-vect-transform.
--- Comment #11 from dorit at gcc dot gnu dot org 2007-11-04 04:09 ---
(In reply to comment #10)
> Doesn't fail on trunk since r129797:
> 2007-10-31 Sebastian Pop <[EMAIL PROTECTED]>
> PR tree-optimization/32377
> ...
> before:
> pr27549.C:58: note: create runtime check for dat
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-11-04 06:31 ---
first don't use -fvisibility-inlines-hidden, it changes the ABI.
Second what happens if unset CFLAGS?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33992
--- Comment #30 from geoffk at geoffk dot org 2007-11-04 07:50 ---
Subject: Re: [4.3 Regression] typeinfo name referenced in ... defined in
discarded section
On 03/11/2007, at 7:21 AM, hjl at lucon dot org wrote:
> Local symbols should only be referenced within the same comdat group
>
57 matches
Mail list logo
