--- Comment #15 from dje at watson dot ibm dot com 2007-12-22 20:52 ---
Subject: Re: AIX g++ -D_LARGE_FILES fails to compile #include iostream
tcoleman at autowares dot com writes:
Tom Does G++ really have to be either one way or the other? Can't it also
include
Tom conditional
--- Comment #10 from dje at watson dot ibm dot com 2007-12-21 14:58 ---
Subject: Re: AIX g++ -D_LARGE_FILES fails to compile #include iostream
Why is this? -D_LARGE_FILES simply enables LFS. xlC works with and without
-D_LARGE_FILES. Shouldn't G++ work as effectively as xlC
--- Comment #11 from dje at watson dot ibm dot com 2007-09-05 17:13 ---
Subject: Re: nint_2.f90 abort compiled with -O0
fxcoudert at gcc dot gnu dot org writes:
FX look into ${builddir}/${target_triplet}/libgfortran/config.h to
FX see what value have the HAVE_LROUND{F,,L
--- Comment #12 from dje at watson dot ibm dot com 2007-09-05 17:19 ---
Subject: Re: nint_2.f90 abort compiled with -O0
fxcoudert at gcc dot gnu dot org writes:
FX David, could you test my C program in comment #4
$ ./xgcc -B./ -W -Wall -O1 fx.c
fx.c: In function 'main':
fx.c:46
--- Comment #28 from dje at watson dot ibm dot com 2007-08-13 15:17 ---
Subject: Re: Bootstrap with vectorization enabled fails with ICE on PPC
Most everyone else bootstraps GCC on PPC64 with
--with-cpu=default32. Are you missing some packages on SUSE? This really
isn't
--- Comment #18 from dje at watson dot ibm dot com 2007-07-29 11:57 ---
Subject: Re: Bootstrap with vectorization enabled fails with ICE on PPC
rakdver at kam dot mff dot cuni dot cz writes:
it's on ppc-linux.
rakdver I mean, I did the testing on ppc-linux; it is possible
--- Comment #10 from dje at watson dot ibm dot com 2007-07-28 19:40 ---
Subject: Re: Bootstrap with vectorization enabled fails with ICE on PPC
Should this test be using -mabi=altivec or is there a general
assumption of -mabi=altivec when using autovec? That conditionally
--- Comment #12 from dje at watson dot ibm dot com 2007-07-28 19:48 ---
Subject: Re: Bootstrap with vectorization enabled fails with ICE on PPC
And we default to ALTIVEC ABI for powerpc-linux:
/* Set Altivec ABI as default for powerpc64 linux. */
if (TARGET_ELF
--- Comment #15 from dje at watson dot ibm dot com 2007-07-28 21:48 ---
Subject: Re: Bootstrap with vectorization enabled fails with ICE on PPC
rakdver at kam dot mff dot cuni dot cz writes:
rakdver Probably the problem is that -maltivec does not
rakdver imply -mabi=altivec
--- Comment #5 from dje at watson dot ibm dot com 2007-07-23 18:05 ---
Subject: Re: [4.3 Regression] glibc ICE's gcc-4.3.0 SSA corruption
michelin60 at gmail dot com writes:
michelin60 Doing a search of PR's filed I came up, surprise, with no remotely
equivalent
michelin60 report
--- Comment #16 from dje at watson dot ibm dot com 2007-06-22 16:44 ---
Subject: Re: ICE on gcc/testsuite/gcc-dg/vmx/ops.c
There are much more constructive ways in which to interact with
the GCC community, GCC developers, and port maintainers than you have
chosen to pursue
--- Comment #22 from dje at watson dot ibm dot com 2006-10-03 18:09 ---
Subject: Re: [4.2 Regression] Performace problem with indexed load/stores on
powerpc
I am not suggesting that the problem has to be solved in
swap_commutative_operands, etc. I would think that GCC should
--- Comment #36 from dje at watson dot ibm dot com 2006-09-01 19:56 ---
Subject: Re: [4.1/4.2 Regression] returning constant double
What is confusing to me is that the r-r case is using evmergehi
and evmergelo. This is placing the value in both halves of the SIMD
register
--- Comment #34 from dje at watson dot ibm dot com 2006-08-31 13:50 ---
Subject: Re: [4.1/4.2 Regression] returning constant double
guenter at roeck-us dot net writes:
guenter Hmm ... what would be the point ? evlwwsplat copies 32 bit memory
content into
guenter the upper and lower
--- Comment #35 from dje at watson dot ibm dot com 2006-08-31 14:23 ---
Subject: Re: [4.1/4.2 Regression] returning constant double
guenter at roeck-us dot net writes:
guenter Hmm ... what would be the point ? evlwwsplat copies 32 bit memory
content into
guenter the upper and lower
--- 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 #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 #22 from dje at watson dot ibm dot com 2006-08-29 19:26 ---
Subject: Re: [4.1 Regression] returning constant double
One of the patterns probably needs a r-m case as well, but we
need a testcase to figure out which one.
--
http://gcc.gnu.org/bugzilla
--- Comment #10 from dje at watson dot ibm dot com 2006-07-13 16:31 ---
Subject: Re: [4.1/4.2 Regression] returning constant double
edmar at freescale dot com writes:
edmar I tried the patch on comment 7 on gcc main line from yesterday. It did
not work
edmar for me:
Tried
--- Comment #12 from dje at watson dot ibm dot com 2006-07-13 19:58 ---
Subject: Re: [4.1/4.2 Regression] returning constant double
edmar at freescale dot com writes:
edmar And to kill the last shread of doubt, here I am using the xgcc present
on the
edmar very same build directoty
--- Comment #14 from dje at watson dot ibm dot com 2006-07-13 20:36 ---
Subject: Re: [4.1/4.2 Regression] returning constant double
What, exactly, is your testcase foo.c? The example at the top of
PR 28287?
$ cat foo.c
double f (void) { return 0; }
$ ./xgcc -B./ -O2 -S
--- Comment #7 from dje at watson dot ibm dot com 2006-04-25 15:21 ---
Subject: Re: [4.2 regression] ICE in final_scan_insn, at final.c:2448 - could
not split insn
The patch may be necessary, but does not fix the testcase. The testcase
needs the patch that Andrew originally tested
--- Comment #12 from dje at watson dot ibm dot com 2006-04-14 14:32 ---
Subject: Re: [4.1/4.2 Regression] Invalid altivec constant loading code
One can produce a few more values fairly easily, but having GCC
know the optimal sequence for all constants could be rather bulky
--- Comment #11 from dje at watson dot ibm dot com 2006-02-28 15:19 ---
Subject: Re: [3.4 only] ICE: unable to find a register to spill in class
`FLOAT_REGS'
If Alan and Gaby want the patch backported to GCC 3.4 branch, it's
okay with me. The patch is fine.
--
http
--- Comment #14 from dje at watson dot ibm dot com 2005-12-19 15:32 ---
Subject: Re: [4.1 Regression] ICE during kernel build.
Okay.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25180
--- Comment #9 from dje at watson dot ibm dot com 2005-11-17 15:17 ---
Subject: Re: [4.0 Regression] Python miscompilation - TOC reload
Reliably is the wrong word. The patch will fix the problem reliably for
the default case; it will not fix it for a particular set of options
--- Comment #5 from dje at watson dot ibm dot com 2005-11-16 17:45 ---
Subject: Re: Python miscompilation - TOC reload
Appended is a proposed patch to backport the easy_fp_constant
change to 4.0. Can you check if this fixes the problem? This patch may
hurt performance
--- Comment #21 from dje at watson dot ibm dot com 2005-11-14 01:58 ---
Subject: Re: [4.0/4.1 Regression] mgrid loop performance regression with
ivopts (register pressure)
And mesa has taken a performance dive...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18048
--- Comment #13 from dje at watson dot ibm dot com 2005-10-06 13:30 ---
Subject: Re: gcc-4.x fails to build on AIX 5.2.0.0-ML04
That worked. But I still saw the -B added to all the lines, but now that
that folder is not there, all goes smooth
As you can see: *I* did not put any
--- Comment #15 from dje at watson dot ibm dot com 2005-10-06 14:07 ---
Subject: Re: gcc-4.x fails to build on AIX 5.2.0.0-ML04
The -Wl,-bbigtoc fix has been committed to GCC 4.1 sources.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24119
--- Comment #7 from dje at watson dot ibm dot com 2005-10-04 15:00 ---
Subject: Re: gcc-4.x fails to build on AIX 5.2.0.0-ML04
h dot m dot brand at xs4all dot nl writes:
h Next step is to upgrade vac-6.0.0.11 to vac-7.0.0.3
You said that you are bootstrapping with GCC-4.0
--- Comment #9 from dje at watson dot ibm dot com 2005-10-04 19:24 ---
Subject: Re: gcc-4.x fails to build on AIX 5.2.0.0-ML04
I bootstrap GCC every day without seeing this problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24119
--- Additional Comments From dje at watson dot ibm dot com 2005-09-15
18:38 ---
Subject: Re: [4.1 Regression] pb_assoc header build and install overflows exec
bkoz at gcc dot gnu dot org writes:
Ben This looks fixed now. Can I close this?
Yes, the latest version appears
--- Additional Comments From dje at watson dot ibm dot com 2005-07-26
16:58 ---
Subject: Re: Darwin alignment ignores attribute packed for first 'double'
element of a struct
If Chris and Apple want to change the behavior for Darwin, be my
guest.
David
--
http
--- Additional Comments From dje at watson dot ibm dot com 2005-07-20
14:26 ---
Subject: Re: [4.1 Regression] pb_assoc header build and install overflows exec
Please for completeness sake put in the generated command that kills AIX, and
the AIX output.
make[1]: Entering directory
--- Additional Comments From dje at watson dot ibm dot com 2005-07-13
18:23 ---
Subject: Re: Character length incorrect.
What about the testcase, David?
I was focussing on the patch itself. Here's a testcase:
! PR fortran/21730
! {do-do run}
character*2
--- Additional Comments From dje at watson dot ibm dot com 2005-07-14
03:37 ---
Subject: Re: Character length incorrect.
fengwang at gcc dot gnu dot org writes:
fengwang IMHO, your patch only handles the scalar character and is not entire,
though a
fengwang different bug
--- Additional Comments From dje at watson dot ibm dot com 2005-07-14
03:49 ---
Subject: Re: Character length incorrect.
fengwang at gcc dot gnu dot org writes:
Feng Having a good start, why not fix entirely? If somebody agrees to fix step
by
Feng step, I have no objection
--- Additional Comments From dje at watson dot ibm dot com 2005-04-25
19:20 ---
Subject: Re: [4.1 Regression] use of poisoned ggc memory causes cpu2000 build
failures
The patch fixes the testcase for me on AIX.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21048
--- Additional Comments From dje at watson dot ibm dot com 2005-04-08
18:57 ---
Subject: Re: New: ICE in extract_insn for test vmx/varargs-1.c
In addition to the previous change, altivec_register_operand needs
to accept SUBREG.
David
Index: predicates.md
--- Additional Comments From dje at watson dot ibm dot com 2005-04-07
22:09 ---
Subject: Re: New: ICE in extract_insn for test vmx/varargs-1.c
Let me know if the appended patch fixes the ICE. The definition
of the and predicates was ignoring CONST_INT that matched predicate
--- Additional Comments From dje at watson dot ibm dot com 2005-01-27
19:09 ---
Subject: Re: PPC64 64-bit build failure
I configured with:
--build=powerpc64-linux --host=powerpc64-linux --target=powerpc64-linux
--with-cpu=default32 --enable-threads=posix --enable-shared
--enable
--- Additional Comments From dje at watson dot ibm dot com 2005-01-27
21:20 ---
Subject: Re: PPC64 64-bit build failure
--with-cpu=default32 builds 32bit by default IIRC.
You obviously replied without reading my message. I said, I am building
everything with -m64.
--
http
--- Additional Comments From dje at watson dot ibm dot com 2004-12-06
17:16 ---
Subject: Re: [4.0 Regression] Another ICE caused by reload of a psuedo reg
into f0 for a DImode expr
The following patch implements the two suggestions. It fixes the
ICE on AIX, but continues
--- Additional Comments From dje at watson dot ibm dot com 2004-12-07
03:10 ---
Subject: Re: [4.0 Regression] Another ICE caused by reload of a psuedo reg
into f0 for a DImode expr
There are two open questions:
1) Do we want to change the register preferencing?
2) Should
--- Additional Comments From dje at watson dot ibm dot com 2004-11-24
15:21 ---
Subject: Re: PowerPC - Unnecessary rldicl
The test for mode == Pmode is present because most of the fast scc
patterns depend on carry. PowerPC carry depends on the mode of the
processor
--- Additional Comments From dje at watson dot ibm dot com 2004-10-25 16:47
---
Subject: Re: ICE cause by reload
uweigand at gcc dot gnu dot org writes:
Ulrich Does this patch help?
It changes the error, but I'm not sure if it helps.
pr15286.c: In function 'GMRESSolver
--- Additional Comments From dje at watson dot ibm dot com 2004-10-25 18:04
---
Subject: Re: ICE cause by reload
With both patches, the testcase works. This probably is a correct
fix for reload.
The code is a little messy and is cleaned up by implementing
--- Additional Comments From dje at watson dot ibm dot com 2004-10-25 19:07
---
Subject: Re: ICE cause by reload
I applied the last two patch, but it didn;t help:
The simplify-rtx.c patch is not *two* patches.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15286
--- Additional Comments From dje at watson dot ibm dot com 2004-10-25 21:11
---
Subject: Re: ICE cause by reload
With the earlier *two* patches from Ulrich, the compiler no longer
ICE.
The latest patch to alter_subreg() (with the missing GET_MODEs)
does not fix
--- Additional Comments From dje at watson dot ibm dot com 2004-10-25 23:43
---
Subject: Re: ICE cause by reload
Try again with what patch? I have all patches applied and I
consistently get the output I emailed earlier with a native Mac OS X
compiler.
David
--
http
--- Additional Comments From dje at watson dot ibm dot com 2004-10-26 00:13
---
Subject: Re: ICE cause by reload
There is a reduced testcase attached to the Bugzilla PR. Please
do not confuse discussion with other examples.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Additional Comments From dje at watson dot ibm dot com 2004-10-26 04:28
---
Subject: Re: ICE cause by reload
I found a typo in my sourcebase introduced when applying one of
the patches. Fixing that typo (matching the complete patch attached to
the PR) produces
--- Additional Comments From dje at watson dot ibm dot com 2004-10-18 01:50
---
Subject: Re: ICE cause by reload
(subreg:SI (reg:DI)) normally isn't a problem, except when reg:DI
is assigned to an FPR. If reg:DI was assigned to an FPR, CLASS probably
is NON_SPECIAL_REGS
54 matches
Mail list logo
