DJ Delorie d...@redhat.com writes:
On xstormy16, when structures with variable-length arrays are passed
to functions (execute/20020412-1.c), it appears that they're passed by
reference (based on examining the stack), despite the port not
explicitly requesting that.
This causes a mis-match
Hi Ian, Hi Diego,
Diego Novillo wrote:
--help=other?
That works. :-)
Actually, there already is a qualifier which will select
-fstack-protector, I had just forgotten about it:
% gcc --help=common | grep stack
-Wstack-protector Warn when not issuing stack smashing
Hello
Sorry, I hope it's not an offensive or boring topic.
Some of my friends asked me if it's true that gcc will be replaced by
other compilers on a few OS and what is the problem.
Any comment?
Best wishes
Eric Fisher
Hi there. The architecture I'm working is a 32 bit, word based
machine with a 16x16 - 32 unsigned multiply. For some reason the
combine stage is converting the umulhisi3 into a mulsi3 and I'm not
sure how to track this down.
The test code is part of an alpha blend:
void blend(uint8_t* sb,
On Wed, 3 Jun 2009 21:39:34 +1200
Michael Hope micha...@juju.net.nz wrote:
How does the combine stage work? It looks like it could get multiple
potential matches for a set of RTLs. Does it use some type of costing
function to pick between them? Can I tell combine that a umulhisi3 is
Thanks for the response Mukti. I think the options could be:
|-mlong-calls -mno-ep and ||-mno-prolog-function. Could please tell me
how to sepcify these options in makefile? Because I use gmake (in
Cygwin shell)
Thanks,
-Vijay
|
mukti jain wrote:
Can you experiment with optionmization
On Wed, 2009-06-03 at 16:33 +0800, Eric Fisher wrote:
Sorry, I hope it's not an offensive or boring topic.
No, just off-topic. This list is for developing gcc, not plotting our
demise.
Cheers, Ben
Hello,
I noticed that the restrict doesn't work fully on 4.4.0 (used to work on
our port based on 4.3 branch). The problem is that tree optimizer can do a
lot of optimization regarding pointer, e.g., at -O3. The alias set property
is not propagated accordingly.
Is the following RTL expansion
On Wed, Jun 3, 2009 at 12:41 PM, Bingfeng Mei b...@broadcom.com wrote:
Hello,
I noticed that the restrict doesn't work fully on 4.4.0 (used to work on
our port based on 4.3 branch). The problem is that tree optimizer can do a
lot of optimization regarding pointer, e.g., at -O3. The alias set
Trying to work-around PR40269 (which doesn't happen
anymore on trunk, so you may close it) I've commented
out the dllexport/dllimport section:
#define BASE_DLLEXPORT /*__declspec(dllexport)*/
#define BASE_DLLIMPORT /*__declspec(dllimport)*/
Then the program compiled
Richard,
Yes, my original code does have restrict qualified decl:
void foo(int byte, char *a, char *b){
int * restrict dest = (int *)a;
int * restrict src = (int *)b;
for(int i = 0; i byte/8; i++){
*dest++ = *src++;
}
}
The code I shown is produced by tree level compilation.
Piotr Wyderski wrote:
Trying to work-around PR40269 (which doesn't happen
anymore on trunk, so you may close it) I've commented
out the dllexport/dllimport section:
#define BASE_DLLEXPORT /*__declspec(dllexport)*/
#define BASE_DLLIMPORT /*__declspec(dllimport)*/
This is the beta release of binutils 2.19.51.0.8 for Linux, which is
based on binutils 2009 0603 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been
On Wed, Jun 3, 2009 at 1:02 PM, Bingfeng Mei b...@broadcom.com wrote:
Richard,
Yes, my original code does have restrict qualified decl:
void foo(int byte, char *a, char *b){
int * restrict dest = (int *)a;
int * restrict src = (int *)b;
for(int i = 0; i byte/8; i++){
*dest++ =
On Wed, Jun 3, 2009 at 5:34 PM, Bingfeng Mei
b...@broadcom.com wrote:
Richard,
Thanks. I tried your patch and the -fno-tree-ter, and none works. The problem
is that
decl = find_base_decl (TREE_OPERAND (inner, 0)); --- Cannot find the
base declaration, so decl = 0
if (decl
Hello,
Is there a way to get the REG for a given regno? I am building a
register renumbering map that is just a pair of unsigned int
old_regno, new_regno, but I can't figure out how to get the REG for
new_regno without remembering a pointer to it myself. Is there an
easier/better way?
Ciao!
Steven Bosscher stevenb@gmail.com writes:
Is there a way to get the REG for a given regno? I am building a
register renumbering map that is just a pair of unsigned int
old_regno, new_regno, but I can't figure out how to get the REG for
new_regno without remembering a pointer to it myself.
Hi,
I'm doing a port of gcc 4.3.3 on a custom architecture and I'm having trouble
when initializing the bit fields of a structure.
The testcase is based on a modified gcc torture testcase, the natural
registers are 16 bits, and long long is defined to be 64 bit wide:
struct itmp
{
long long
On Wed, Jun 03, 2009 at 07:49:29PM +0200, Stelian Pop wrote:
I'm doing a port of gcc 4.3.3 on a custom architecture and I'm having trouble
when initializing the bit fields of a structure.
Ok, after further analysis, it looks like a genuine bug in gcc,
in store_bit_field_1(): when a field is
Stelian Pop stel...@popies.net writes:
On Wed, Jun 03, 2009 at 07:49:29PM +0200, Stelian Pop wrote:
I'm doing a port of gcc 4.3.3 on a custom architecture and I'm having trouble
when initializing the bit fields of a structure.
Ok, after further analysis, it looks like a genuine bug in gcc,
On Wed, Jun 03, 2009 at 01:07:08PM -0700, Ian Lance Taylor wrote:
- unsigned int wordnum = (backwards ? nwords - i - 1 : i);
+ unsigned int wordnum = (backwards
+ ? GET_MODE_SIZE(fieldmode) / UNITS_PER_WORD
+ - i - 1
+
Good morning everyone,
I have an interesting situation. In this bit of code below, extracted from
a simple testcase, I have a singly-linked list:
--snip!--
template class list_node class List
{
public:
List() : head(__null)
{
Hi, all. I have a basic question about GENERIC trees.
I'm playing with writing a front end, and find the distinction between
BLOCK and BIND_EXPR to be somewhat confusing. In particular, I'm trying
to get a handle on how to represent a function in GENERIC form.
On the surface the texi docs and
The attached Fortran source, when compiled with a recent version of the trunk,
gives the above ICE.
Compile options: -O3 -c.
--
Summary: internal compiler error: in set_ssa_val_to, at tree-
ssa-sccvn.c:1811
Product: gcc
Version: 4.5.0
--- Comment #7 from matz at gcc dot gnu dot org 2009-06-03 09:51 ---
I'm looking at this now.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from steven at gcc dot gnu dot org 2009-06-03 10:36 ---
This code comes from the split2 (split insns after reload). So this is target
specific. It surprises me that non-legitimate constants are accepted before
reload on ARM (at least in thumb mode). It may be (and
--- Comment #7 from paolo at gcc dot gnu dot org 2009-06-03 10:37 ---
Subject: Bug 40296
Author: paolo
Date: Wed Jun 3 10:37:20 2009
New Revision: 148122
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148122
Log:
2009-06-03 Paolo Carlini paolo.carl...@oracle.com
PR
--- Comment #8 from paolo at gcc dot gnu dot org 2009-06-03 10:37 ---
Subject: Bug 40296
Author: paolo
Date: Wed Jun 3 10:37:32 2009
New Revision: 148123
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148123
Log:
2009-06-03 Paolo Carlini paolo.carl...@oracle.com
PR
--- Comment #9 from paolo dot carlini at oracle dot com 2009-06-03 10:40
---
Fixed 4.4.1 and mainline.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2009-06-03 10:57 ---
FWIW it looks like the define_split at arm.c:5060 (of r147729) is triggered.
Richard E., is there a reason for lowering load-immediates so late in the
pipeline?
--
steven at gcc dot gnu dot org changed:
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-06-03 11:25 ---
Mine. We fail to fold COMPLEX_EXPR 0, 0 to COMPLEX_CST.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-06-03 11:31 ---
I am testing the following:
Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 148119)
+++ gcc/fold-const.c(working copy)
@@ -2643,9
--- Comment #8 from jamborm at gcc dot gnu dot org 2009-06-03 11:56 ---
Subject: Bug 40323
Author: jamborm
Date: Wed Jun 3 11:56:05 2009
New Revision: 148126
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148126
Log:
2009-06-03 Martin Jambor mjam...@suse.cz
PR
--- Comment #9 from jamborm at gcc dot gnu dot org 2009-06-03 12:54 ---
I have just verified this is fixed on the current trunk.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from toon at moene dot org 2009-06-03 12:55 ---
It works for the testcase with your change (over revision 148127).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40328
--- Comment #8 from ramana at gcc dot gnu dot org 2009-06-03 13:17 ---
Also broken on arm-eabi cross. Using gdb and the exact steps as in Comment #0
shows me problem as 0x100.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40012
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-06-03 14:00
---
The problem seems to be the asymmetry wrt handling of NAMEs vs. SSA_NAME
operands
in NARYs and REFERENCEs. We happily translate NAMEs and do not clean them
if they are in AVAIL_OUT, but we only can translate
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|internal compiler error: in |[4.5 Regression] internal
|set_ssa_val_to, at
--- Comment #10 from ich at az2000 dot de 2009-06-03 15:00 ---
Thanks a lot, works just fine. :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40323
--- Comment #13 from dberlin at gcc dot gnu dot org 2009-06-03 15:16
---
Subject: Re: [4.4/4.5 Regression] internal
compiler error: in compute_antic, at tree-ssa-pre.c:2501
Hmmm, clean should only have to check set1 and set2, not AVAIL_OUT.
I'm not sure why it looks at
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-06-03 15:31 ---
Subject: Bug 40328
Author: rguenth
Date: Wed Jun 3 15:30:52 2009
New Revision: 148134
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148134
Log:
2009-06-03 Richard Guenther rguent...@suse.de
PR
On freebsd-6.4-stable alpha gcc-4.5 fails to build after 20090507. Until then
built ok. Tried with default system compiler gcc-3.4 or with gcc-4.4.
#gcc44 -v
Using built-in specs.
Target: alpha-portbld-freebsd6.4
Configured with: ./../gcc-4.4-20090526/configure --disable-nls
--with-system-zlib
right now, 4.4 branch is broken for CP2K, there seems to be some error in
libfortran that causes incorrect writes. The diff in the restarts looks like:
56,58c56,58
FORCEFIELD
PARMTYPE CHM
PARM_FILE_NAME ../sample_pot/water.pot
---
FORCEFIELD,
,PARMTYPE CHM
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-06-03 15:44 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from jv244 at cam dot ac dot uk 2009-06-03 15:46 ---
CCed the experts
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
CC|
Using either the std::tr1 or C++0x std:: random number generators, the
uniform_real distribution produces numbers that are completely wrong.
For instance, using Boost.Random the test program produces this sequence of
floating point numbers:
Random real: 0.0975404
Random real: 0.547221
Random
--- Comment #1 from colin at gibibit dot com 2009-06-03 15:52 ---
Created an attachment (id=17948)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17948action=view)
Test case that generates random reals using Boost, TR1, and C++0x
Uncomment exactly one of RNG_BOOST, RNG_TR1, or
--- Comment #2 from dominiq at lps dot ens dot fr 2009-06-03 15:54 ---
Did you try 4.5?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40330
--- Comment #9 from matz at gcc dot gnu dot org 2009-06-03 15:57 ---
Bah, simply not expanding those variables (whose SSA partitions were already)
by clearing TREE_USED on them fixes the problem, but makes those variables
have no debug info at all, as the DECLs then have no DECL_RTL_SET
--- Comment #6 from eduardo dot m dot costa at gmail dot com 2009-06-03
16:06 ---
Are you using tree-parallelize-loops? I got the same problem, and using -O2
-fno-tree-parallelize-loops worked for me...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39780
--- Comment #3 from jv244 at cam dot ac dot uk 2009-06-03 16:08 ---
(In reply to comment #2)
Did you try 4.5?
unfortunately trunk currently fails for other reasons. I'll try to look into
that afterwards.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40330
--- Comment #4 from jv244 at cam dot ac dot uk 2009-06-03 16:31 ---
OK, a good hint from valgrind. The following error is present if I use 4.4.1
but not if I link against the runtime from 4.4.0:
==30712== Invalid read of size 1
==30712==at 0x4A22DF9: strncmp
--- Comment #5 from jv244 at cam dot ac dot uk 2009-06-03 16:47 ---
OK, now with easy testcase, as you'll notice from the output, the loop is
important:
IMPLICIT NONE
character(len=100) :: fmt1,str1,fmt2,str2
real*8 :: r(3)=0
integer :: i,iunit
fmt1=(T2,A2,
str1=a
iunit=6
DO i=1,10
--- Comment #2 from paolo dot carlini at oracle dot com 2009-06-03 16:49
---
*** This bug has been marked as a duplicate of 40263 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #6 from jv244 at cam dot ac dot uk 2009-06-03 16:49 ---
compiled with trunk this is also buggy (with new bugs about dwarf2):
--690-- DWARF2 CFI reader: unhandled CFI instruction 0:10
--690-- DWARF2 CFI reader: unhandled CFI instruction 0:10
--690-- DWARF2 CFI reader:
--- Comment #3 from paolo dot carlini at oracle dot com 2009-06-03 16:49
---
*** Bug 40331 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Target Milestone|--- |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40330
/gcc_trunk/build/
--with-cloog=/data03/vondele/gcc_trunk/build/
Thread model: posix
gcc version 4.5.0 20090603 (experimental) [trunk revision 148132] (GCC)
leads to these errors at link time:
/usr/bin/ld: error in
/data03/vondele/clean/cp2k/src/../lib/Linux-x86-64-gfortran/sdbg/libcp2k_lib.a
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-06-03 17:09 ---
What binutils version are you using? do ld --version. This might be a bug in
binutils really.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40332
--- Comment #2 from jv244 at cam dot ac dot uk 2009-06-03 17:14 ---
(In reply to comment #1)
What binutils version are you using? do ld --version. This might be a bug in
binutils really.
it is recent, I think:
ld -v
GNU ld (GNU Binutils; openSUSE 11.0) 2.18.50.20080409-11.1
--
--- Comment #7 from jb at gcc dot gnu dot org 2009-06-03 17:39 ---
Confirmed on trunk.
This seems to be due to the format caching stuff?
The regression on the 4.4 branch would be explained by the I/O backport
(r147887).
--
jb at gcc dot gnu dot org changed:
What
--- Comment #3 from jason at gcc dot gnu dot org 2009-06-03 18:12 ---
Subject: Bug 40308
Author: jason
Date: Wed Jun 3 18:11:53 2009
New Revision: 148141
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148141
Log:
PR c++/40308
PR c++/40311
* typeck.c
--- Comment #3 from jason at gcc dot gnu dot org 2009-06-03 18:12 ---
Subject: Bug 40307
Author: jason
Date: Wed Jun 3 18:11:53 2009
New Revision: 148141
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148141
Log:
PR c++/40308
PR c++/40311
* typeck.c
--- Comment #3 from jason at gcc dot gnu dot org 2009-06-03 18:12 ---
Subject: Bug 40311
Author: jason
Date: Wed Jun 3 18:11:53 2009
New Revision: 148141
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148141
Log:
PR c++/40308
PR c++/40311
* typeck.c
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-06-03 18:15 ---
Fixed by:
2009-06-03 Julian Brown jul...@codesourcery.com
* config/arm/arm.c (arm_hard_regno_mode_ok): Permit values of four
words or less (including TImode) in core registers.
--
pinskia at
--- Comment #3 from jason at gcc dot gnu dot org 2009-06-03 18:12 ---
Subject: Bug 40306
Author: jason
Date: Wed Jun 3 18:11:53 2009
New Revision: 148141
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148141
Log:
PR c++/40308
PR c++/40311
* typeck.c
--- Comment #8 from jb at gcc dot gnu dot org 2009-06-03 18:49 ---
Created an attachment (id=17949)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17949action=view)
Proposed patch
This patch seems to fix it, will formally submit as soon as it regtests.
--
--- Comment #8 from burnus at gcc dot gnu dot org 2009-06-03 18:58 ---
(In reply to comment #7)
Fixed on trunk.
I'll backport to 4.4. branch in a week.
* ping *
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39893
--- Comment #9 from jb at gcc dot gnu dot org 2009-06-03 19:19 ---
Proper patch submitted.
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
URL|
--- Comment #5 from burnus at gcc dot gnu dot org 2009-06-03 19:39 ---
Subject: Bug 40019
Author: burnus
Date: Wed Jun 3 19:39:09 2009
New Revision: 148143
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148143
Log:
2009-06-03 Francois-Xavier Coudert fxcoud...@gcc.gnu.org
--- Comment #6 from burnus at gcc dot gnu dot org 2009-06-03 19:40 ---
Now also FIXED on the 4.4 branch. - CLOSE
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.4.0
Target Milestone|--- |4.4.1
--- Comment #10 from jb at gcc dot gnu dot org 2009-06-03 21:07 ---
Subject: Bug 40330
Author: jb
Date: Wed Jun 3 21:07:19 2009
New Revision: 148149
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148149
Log:
PR libfortran/40330
Use heap memory for cached format strings.
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2009-06-03 21:12
---
No news for a year and a half. 4.2 branch is now closed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2009-06-03 21:13
---
4.2 branch is closed, works in 4.3.0
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2009-06-03 21:18
---
Here's what it gives with Apple's gcc:
_r:
pushl %ebp
movl%esp, %ebp
subl$72, %esp
movaps %xmm0, -24(%ebp)
movaps %xmm1, -40(%ebp)
movaps %xmm2,
The following SSE2 code crashes because the non-static global variable breaks
the alignment of the static data section.
align.cpp:
#include emmintrin.h
int nonstatic_padding;
static int static_padding[3];
static __attribute__((aligned(16))) __m128i sse_data;
int main() {
static_padding[0] =
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-06-03 21:26 ---
*** This bug has been marked as a duplicate of 37216 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #62 from pinskia at gcc dot gnu dot org 2009-06-03 21:26
---
*** Bug 40333 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2009-06-03 21:29
---
Not target-specific, can reproduce on x86_64-linux (don't know what you expect,
though).
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2009-06-03 21:35
---
Changing subject according to comment #6.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from fxcoudert at gcc dot gnu dot org 2009-06-03 21:47
---
Still fails on both ppc-darwin and i386-darwin, for 4.3.2, 4.4.0 and current
trunk:
$ cat a.c
extern int puts (const char *);
extern void abort (void);
int main ()
{
__label__ l1;
void foo ()
{
void
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2009-06-03 21:50
---
*** This bug has been marked as a duplicate of 10901 ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from fxcoudert at gcc dot gnu dot org 2009-06-03 21:50
---
*** Bug 22119 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10901
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2009-06-03 21:58
---
(In reply to comment #3)
So I don't know what people want to do about this bug. Over the years some
people have worked to fix such problems as bugs; and some people want to point
to the documentation and say
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2009-06-03 22:00
---
Works for me on 4.3.2, 4.4.0 and 4.5.0. Suppose it's fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2009-06-03 22:16
---
I'm not seeing that one with 4.3.2 (nor with 4.4.0 or current trunk).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34584
--- Comment #8 from rearnsha at gcc dot gnu dot org 2009-06-03 23:31
---
Subject: Bug 10242
Author: rearnsha
Date: Wed Jun 3 23:31:12 2009
New Revision: 148156
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148156
Log:
PR target/10242
* arm.md (arm_addsi3):
--- Comment #9 from rearnsha at gcc dot gnu dot org 2009-06-03 23:34
---
fixed
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from dalej at gcc dot gnu dot org 2009-06-04 00:06 ---
Yeah. Looking through our local changes, I think you just need this line in
i386.h:
#define SSE_REGPARM_MAX (TARGET_64BIT ? 8 : (TARGET_MACHO ? 4 : (TARGET_SSE ? 3
: 0)))
However Apple employees can't currently
The following program (also attached) reads to eof, backspace, reads (eof
detected), backspace, and reads again. The last read gets the last line with
gfortran 4.5 (tested: r148116) but eof with gfortran = 4.4, g95, g77 and Sun
f95.
From reading comp.lang.fortran I know that EOF/BACKSPACE
--- Comment #1 from bartoldeman at users dot sourceforge dot net
2009-06-04 00:30 ---
Created an attachment (id=17950)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17950action=view)
Test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40334
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2009-06-04 01:13
---
Confirmed on 4.4 and 4.5. I checked with 4.3, ifort, open64, and Sun
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Summary|4.5 regression: changed |4.4,4.5 regression: changed
|BACKSPACE behaviour
--- Comment #19 from bartoldeman at users dot sourceforge dot net
2009-06-04 04:03 ---
Thanks for all the work -- another text processing program which changes some
headers in big ASCII files (which is what inspired this bug) went from around
real0m2.026s
user0m1.764s
sys
--- Comment #11 from jv244 at cam dot ac dot uk 2009-06-04 05:16 ---
(In reply to comment #9)
Proper patch submitted.
Thanks, don't wait too long with 4.4 as this should make it in 4.4.1 which
could be released this month, and some further testing on the branch would be
good:
--- Comment #12 from burnus at gcc dot gnu dot org 2009-06-04 05:36 ---
Thanks, don't wait too long with 4.4 as this should make it in 4.4.1 which
could be released this month, and some further testing on the branch would be
good:
Planned for June 21, see (better link):
97 matches
Mail list logo
