Eric Fisher wrote:
hi
I'm not clear why we have 'udiv', but don't have 'umul' for Standard
Pattern Names. Does I need to define a nameless pattern for it?
Because non-widening multiplication is the same for signed and unsigned.
We have:
mulmode13
mulmode1mode23 (signed x signed)
hi
I'm not clear why we have 'udiv', but don't have 'umul' for Standard
Pattern Names. Does I need to define a nameless pattern for it?
Thanks in advance.
eric
On 3/17/08, Ian Lance Taylor [EMAIL PROTECTED] wrote:
If you are interested, please sign up at
http://code.google.com/soc/mentor_step1.html
You will need to have a gmail.com account.
How does someone become a student for the gcc project instead of a mentor?
Am 17.03.2008 um 17:45 schrieb Jim Wilson:
Boris Boesler wrote:
But some basic blocks seem to point to insns which are not in the
insn-list. I had a short look at dbr_schedule() in reorg.c and the
basic blocks are not updated. Are they evaluated in a later pass?
No. See pass_free_cfg,
[EMAIL PROTECTED] wrote on 17/03/2008 19:33:23:
I have looked more closely at the messages generated by the gcc 4.3
vectorizer
and it seems that they fall into two categories:
1) complaining about aligmnent.
For example:
Unknown alignment for access: D.33485
Unknown alignment for
[EMAIL PROTECTED] wrote on 17/03/2008 21:08:43:
It might be nice to think about an option that automatically aligns large
arrays without having to do the declaration (or even have the vectorizer
override the alignment for statics/auto).
The vectorizer is already doing this.
Ira
--
On 18/03/2008, NightStrike [EMAIL PROTECTED] wrote:
On 3/17/08, Ian Lance Taylor [EMAIL PROTECTED] wrote:
If you are interested, please sign up at
http://code.google.com/soc/mentor_step1.html
You will need to have a gmail.com account.
How does someone become a student for the gcc
NightStrike [EMAIL PROTECTED] writes:
On 3/17/08, Ian Lance Taylor [EMAIL PROTECTED] wrote:
If you are interested, please sign up at
http://code.google.com/soc/mentor_step1.html
You will need to have a gmail.com account.
How does someone become a student for the gcc project instead of a
Ian Lance Taylor wrote:
GCC has been approved as a supported project for Google's Summer of
Code 2008. Summer of Code is a program in which Google pays students
to work on open source projects.
Perhaps a bit off topic, but on the GCC page:
http://code.google.com/soc/2008/gcc/about.html
David Daney [EMAIL PROTECTED] writes:
Ian Lance Taylor wrote:
GCC has been approved as a supported project for Google's Summer of
Code 2008. Summer of Code is a program in which Google pays students
to work on open source projects.
Perhaps a bit off topic, but on the GCC page:
Boris Boesler [EMAIL PROTECTED] writes:
The following code generators use FOR_EACH_BB[_REVERSE] in the
target machine dependent reorg pass:
- bfin
- frv
- ia64
- mt
- s390
Are these invalid code generators then? Or are we talking about
different things?
Boris Boesler wrote:
The following code generators use FOR_EACH_BB[_REVERSE] in the target
machine dependent reorg pass:
- bfin
- frv
- ia64
- mt
- s390
The very first thing that ia64_reorg does is
compute_bb_for_insn ();
Just taking a quick look, I don't see any bb
Intel will publish spec for Intel AVX at IDF in April:
http://www.intel.com/pressroom/archive/releases/20080317fact.htm?iid=pr1_releasepri_20080317fact
Intel AVX: The next step in the Intel instruction set -- Gelsinger
also discussed Intel AVX (Advanced Vector Extensions) which, when used
by
Am 18.03.2008 um 16:21 schrieb Jim Wilson:
Boris Boesler wrote:
The following code generators use FOR_EACH_BB[_REVERSE] in the
target machine dependent reorg pass:
- bfin
- frv
- ia64
- mt
- s390
The very first thing that ia64_reorg does is
compute_bb_for_insn ();
On Tue, Mar 18, 2008 at 6:40 PM, Boris Boesler [EMAIL PROTECTED] wrote:
Am 18.03.2008 um 16:21 schrieb Jim Wilson:
Boris Boesler wrote:
The following code generators use FOR_EACH_BB[_REVERSE] in the
target machine dependent reorg pass:
- bfin
- frv
- ia64
-
Hello All,
in gcc/Makefile.in there are many different *CFLAGS, notablye
ALL_CFLAGS = $(X_CFLAGS) $(T_CFLAGS) \
$(CFLAGS) $(INTERNAL_CFLAGS) $(COVERAGE_FLAGS) $(WARN_CFLAGS)
$(XCFLAGS) @DEFS@
Do anyone have a precise idea of what all these *CFLAGS are exactly for?
(I guessed a bit some of
Hi Joern,
Thanks for the answer,
Joern Rennecke [EMAIL PROTECTED] writes:
1) Is it possible to have a MODE_PARTIAL_INT inner register that is bigger
than a word?
Yes. You might have a 20 bit register, which is considered Pmode == PHImode,
with a lower half QImode (16 bit, word addressed)
(First post to gcc mailing list)
I have been making use of the Freescale (Motorola) HC11/12 functionality
within gcc and binutils on the 9S12C64 target.
I plan to extend gcc to cover the newer S12X CPU as the existing
compiler only utilises the S12 subset. Is anyone working on this
presently?
James Murray wrote:
I have attempted to build gcc-4.3.0 with --target=m6812-elf and using
plain binutils-2.18 built with the same target, prefix and program
prefix as gcc, however gcc fails:
../../../gcc-4.3.0/libgcc/../gcc/libgcc2.c: In function ‘__negdi2’:
On Tue, 2008-03-18 at 16:23 -0700, David Daney wrote:
James Murray wrote:
I have attempted to build gcc-4.3.0 with --target=m6812-elf and using
plain binutils-2.18 built with the same target, prefix and program
prefix as gcc, however gcc fails:
Dave Korn wrote:
Jakub Jelinek wrote on 17 March 2008 12:00:
On Mon, Mar 17, 2008 at 10:27:17AM -, Dave Korn wrote:
Eric Botcazou wrote on :
fixincludes/fixincl.x changed to GPLv3 on 4.1 branch a month ago.
By accident I presume?
As an epiphenonmenal side-effect of being
It appears that gcj in gcc 4.3.0 is broken on Darwin. If
one builds gcc 4.3.0 executing...
contrib/download_ecj
before running configure, the build succeeds in creating an
ecj1 but when gcj is used to compile an example like testme.java...
public class testme {
public static void
The web page
http://gcc.gnu.org/gcc-4.3/changes.html
states that The -ftree-vectorize option is now on by default under -
O3., but on
http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Optimize-Options.html
-ftree-vectorize is not listed as one of the options enabled by -O3.
Is the first
--- Comment #6 from ubizjak at gmail dot com 2008-03-18 06:54 ---
The test works OK for 32bit x86 target with -O3 and
gcc version 4.4.0 20080318 (experimental) [trunk revision 133304] (GCC)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35621
--- Comment #3 from J dot Gorka at osmosys dot tv 2008-03-18 07:57 ---
Ok. Now version 4.3.0 from Debian. The same problem
gcc-4.3 --version
gcc-4.3 (Debian 4.3.0-1) 4.3.1 20080309 (prerelease)
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-03-18 08:01 ---
Can you include the contents of function.h, it seems to be missing ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35616
--- Comment #5 from J dot Gorka at osmosys dot tv 2008-03-18 08:17 ---
All is fine. My friend copy that program from here, compile on gcc-4.3 and give
me result that is in comment #3 But ok, i copy one more time what is in
function.h file:
typedef void (*listener_fun)(
int
command is as below.
arm-elf-gcc -v -save-temps -O2 -ffreestanding -c -msoft-float -nostdinc test.c
Using built-in specs.
Target: arm-elf
Configured with: ./configure --target=arm-elf
--prefix=/rdisk1/users/wangqiang/tool-chain --enable-interwork
--enable-multilib --with-float=soft
--- Comment #2 from jakub at gcc dot gnu dot org 2008-03-18 09:55 ---
Subject: Bug 35625
Author: jakub
Date: Tue Mar 18 09:55:09 2008
New Revision: 133307
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133307
Log:
PR libgomp/35625
* iter.c
--- Comment #3 from jakub at gcc dot gnu dot org 2008-03-18 09:57 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
int
main (void)
{
#pragma omp parallel
{
#pragma omp for schedule (guided, 10)
for (int i = 0; i 1826; i += 10)
;
#pragma omp for schedule (guided, 10)
for (int i = 0; i -1826; i -= 10)
;
}
return 0;
}
hangs - after going through all iterations keeps
--- Comment #1 from jakub at gcc dot gnu dot org 2008-03-18 09:55 ---
Subject: Bug 35625
Author: jakub
Date: Tue Mar 18 09:54:21 2008
New Revision: 133306
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133306
Log:
PR libgomp/35625
* iter.c
--- Comment #1 from rurality dot wq at gmail dot com 2008-03-18 09:29
---
Created an attachment (id=15341)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15341action=view)
C source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35624
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
|
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-03-18 10:51 ---
This looks like a target issue.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jakub at gcc dot gnu dot org 2008-03-18 11:14 ---
Seems OMP_ATOMIC_LOAD isn't properly regimplified and so i in TREE_OPERAND
(omp_atomic_load, 1) isn't replaced with .omp_data_i-i. For targets with
sync builtins this doesn't matter, as expand_omp_atomic for them
--- Comment #5 from jakub at gcc dot gnu dot org 2008-03-18 12:21 ---
Subject: Bug 35611
Author: jakub
Date: Tue Mar 18 12:21:02 2008
New Revision: 133309
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133309
Log:
PR middle-end/35611
* gimplify.c (gimplify_expr):
Compiling the following simple code sample with
-O3 on CELL spu produces very poor performing
code:
#include spu_intrinsics.h
typedef struct _vec_tri {
vector float x;
vector float y;
vector float z;
} vec_tri;
vec_tri add_tri(vec_tri a, vec_tri b)
{
vec_tri c;
c.x = spu_add(a.x,
--- Comment #6 from jakub at gcc dot gnu dot org 2008-03-18 12:32 ---
Subject: Bug 35611
Author: jakub
Date: Tue Mar 18 12:31:28 2008
New Revision: 133310
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133310
Log:
PR middle-end/35611
* gimplify.c (gimplify_expr):
--- Comment #7 from jakub at gcc dot gnu dot org 2008-03-18 12:41 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from deuling at de dot ibm dot com 2008-03-18 13:43 ---
Hi,
I build binutils from head and you're right. This issue is fixed:
[EMAIL PROTECTED] binutils]$ ./readelf --debug-dump=loc ~/fortran/neg_array
Contents of the .debug_loc section:
Offset BeginEnd
--- Comment #7 from ubizjak at gmail dot com 2008-03-18 14:34 ---
asm dump with GCC: (GNU) 4.4.0 20080318 (experimental) and -O2
-fomit-frame-pointer:
function_calling_listener:
movl20(%esp), %eax # data.d, data.d
movl16(%esp), %ecx # data.c, data.c
--- Comment #8 from ubizjak at gmail dot com 2008-03-18 14:45 ---
It works when function.c is compiled with -O2 -fno-optimize-sibling-calls.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35616
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-03-18 14:53 ---
The stack modifications before the sibcall look indeed interesting. Micha,
maybe you want to poke into this somewhat?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35616
--- Comment #10 from matz at gcc dot gnu dot org 2008-03-18 14:55 ---
The tree dumps already look wrong. from .130t.final_cleanup:
function_calling_listener (data)
{
bb 2:
data (data.a, data.c, data.d) [tail call];
return;
}
Note how the function pointer is replaced with the
--- Comment #11 from ubizjak at gmail dot com 2008-03-18 15:01 ---
cse1 pass somehow figures out that:
(insn 11 10 12 2 function.c:5 (set (reg/f:SI 61)
(mem/s/f/c:SI (plus:SI (reg/f:SI 16 argp)
(const_int 4 [0x4])) [4 data.listener+0 S4 A32])) 41 {*movsi_1}
--- Comment #2 from chris at bubblescope dot net 2008-03-18 15:02 ---
#include vector
#include tr1/unordered_map
using namespace std;
int main(void)
{
vectortr1::unordered_mapint,int v;
}
Runs fine here, using:
Using built-in specs.
Target: i386-apple-darwin9.2.0
Configured with:
--- Comment #12 from matz at gcc dot gnu dot org 2008-03-18 15:03 ---
Uros: the problem isn't cse. It's already expand which creates broken code
(it reads from and writes to (mem (plus (virtual-incoming-regs) (4)).
But it does that only because the input tree is completely wrong (TER
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-03-18 15:25
---
Actually the trees are correct, just the dumping of function names in call
exprs
is interesting. Still expand is the primary suspect here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35616
--- Comment #14 from ubizjak at gmail dot com 2008-03-18 15:30 ---
(In reply to comment #12)
Uros: the problem isn't cse. It's already expand which creates broken code
(it reads from and writes to (mem (plus (virtual-incoming-regs) (4)).
But it does that only because the input tree
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-03-18 15:31
---
Similar case that SCCVN could also handle (store_ccp and DOM handle this):
int G;
void __attribute__((noinline))
foo (int i)
{
if (i 0)
G = 3;
else
G = 3;
if (G != 3)
link_error ();
}
--- Comment #15 from matz at gcc dot gnu dot org 2008-03-18 15:37 ---
We can either force expanding the call address before the arguments (if
it overlaps with them) or simply validate the thing after the fact.
Validating seems a bit easier (and is in line with what is done already for
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |matz at gcc dot gnu dot org
|dot org
Hi: The following program fails to read the namelist file below.
test program:
program test
implicit none
LOGICAL :: nlco(200) ! (1:nbeam)
REAL*8 :: xlbtna(200) ! (1:nbeam)
NAMELIST/nbdrive_naml/ nlco,xlbtna
INTEGER :: nbshapa(200) ! (1:nbeam)
NAMELIST/nbdrive_naml/ nbshapa
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-18 16:19 ---
This is a dup of bug 33927 and 33790 which both have the same example as below
but are talking about different passes :).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35626
--- Comment #6 from deuling at de dot ibm dot com 2008-03-18 16:52 ---
./readelf --debug-dump=line give
for gfortran 4.1.2:
The Directory Table:
fortran
The File Name Table:
EntryÂDir····Time···Size···Name
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-03-18 16:53 ---
While this is a regression the underlying problem was latent and thus this
should be an enhacement report. But I'll have a look.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #12 from tromey at gcc dot gnu dot org 2008-03-18 17:03 ---
I agree we should probably change ecj1's interpretation of -Wall.
But, ecj1 can't be part of gcc. That was already decided.
I believe the installation instructions have information on what
to download so that gcj
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-03-18 17:24 ---
Subject: Bug 35593
Author: rguenth
Date: Tue Mar 18 17:23:35 2008
New Revision: 133318
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133318
Log:
2008-03-18 Richard Guenther [EMAIL PROTECTED]
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35616
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35617
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-03-18 17:28 ---
And the branch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Hello, It's the code:
http://www.nabble.com/file/p16128572/1.c 1.c
Try enter the number 0010 (number then), 00010, etc.. and see the bizarre
output..
Thanks..
--
View this message in context:
http://www.nabble.com/Works-on-dev-c..-tp16128572p16128572.html
Sent from the gcc - bugs mailing
I built gmp-4.2.2:
./configure --prefix=/opt/pkg/gmp-4.2.2
make
make install
And mpfr-2.3.1:
./configure --prefix=/opt/pkg/mpfr-2.3.1 --with-gmp=/opt/pkg/gmp-4.2.2/
--with-gmp-build=/opt/src/gmp-4.2.2/
make
make install
Oh the compiler I'm trying to install 4.3.0 (as well as gmp and mpfr) with:
--- Comment #4 from uros at gcc dot gnu dot org 2008-03-18 20:01 ---
Subject: Bug 35504
Author: uros
Date: Tue Mar 18 20:00:12 2008
New Revision: 133324
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133324
Log:
PR target/35504
* config/i386/i386.c
--- Comment #7 from ubizjak at gmail dot com 2008-03-18 20:12 ---
(In reply to comment #3)
Actually it looks like all the ssse3-*.c testcase violate C aliasing rules.
I can confirm this, the test works OK with -fno-strict-aliasing.
--
--- Comment #8 from hjl dot tools at gmail dot com 2008-03-18 20:16 ---
Close it. We can reopen it if it fails at -O2.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-03-18 20:24 ---
Why is this closed as won't fix. The testcase invokes undefined behavior and
should be fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #10 from hjl dot tools at gmail dot com 2008-03-18 20:28
---
Just add -fno-strict-aliasing.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #11 from pluto at agmk dot net 2008-03-18 20:48 ---
(In reply to comment #10)
Just add -fno-strict-aliasing.
just use __builtin_memcpy to avoid ugly casting.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35621
testcases 35
# of unsupported tests 269
/home/jrp/build/gcc/xgcc version 4.4.0 20080318 (experimental) (GCC)
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure -v --enable-languages=c,c++,fortran
--enable-shared --with-system-zlib --without-included
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-18 21:32 ---
Confirmed. PREDICT_EXPR seems to force BBs unmerged and confuses loop
discovery.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||missed-optimization
Summary|gcc.dg/tree-ssa/loop-25.c
--- Comment #1 from burnus at gcc dot gnu dot org 2008-03-18 21:50 ---
Confirmed. Again a GCC 4.3.0/4.4.0 regression.
Seemingly caused between 2007-12-07-r130671 and 2007-12-10-r130736. Probably
caused by my NaN/INF patch (PR fortran/34319 - or, less likely, fortran/34404).
--
--- Comment #2 from burnus at gcc dot gnu dot org 2008-03-18 22:02 ---
The problem is that we don't properly rewind properly for nbshapa; the parser
sees 'n'; it then try whether NaN matches. It checks the next character 'b'
and fails. The problem is that only 'b' and not 'nb' are put
this code does not compile with g++-4.3 (4.1 and 4.2 are able to compile it):
template typename T
struct set
{};
struct derived:
public setint
{
typedef setint base;
void set(void) {}
};
[EMAIL PROTECTED]:~$ g++-4.3 -v
Using built-in specs.
Target: i486-linux-gnu
Configured with:
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-03-18 23:57
---
Namelist bugs are just a tradition. :) Assigning myself.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from amodra at bigpond dot net dot au 2008-03-19 00:54
---
Following up on comment #4, it was this part of Nick's patch that fixed the
--debug-dump=loc problem:
Correct list of attributes which can reference a location list.
--- Comment #8 from amodra at bigpond dot net dot au 2008-03-19 01:17
---
Can you attach the object file that has the odd file name entry? I can't
reproduce this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35615
The following example demonstrates the issue:
#include utility
#include iostream
#define INLINE_FRIEND
class Outer {
enum InnerEnum {
Value0 = 0
};
typedef std::pairInnerEnum, int InnerPair;
friend bool operator==(const InnerPair lhs, const InnerPair
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-19 02:57 ---
No, 4.1,4.2, and 4.3 are correct.
Read http://gcc.gnu.org/gcc-4.1/changes.html, the ARM-style name-injection of
friend declarations is no longer the default. section.
--
pinskia at gcc dot gnu dot org changed:
Someone has broken gfortran and/or the middle/backend.
FAIL: gfortran.dg/ltrans-7.f90 -O scan-tree-dump-times ltrans transformed
loop 1
--
Steve
--- Comment #2 from hp at gcc dot gnu dot org 2008-03-19 03:07 ---
My autotester says loop-25 fails in the same way for cris-elf, due to a patch
committed in the range 133311:133318.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
What's going on?
WARNING: program timed out.
FAIL: gfortran.dg/streamio_4.f90 -O0 execution test
--
Steve
This commit:
2008-03-05 Hans-Peter Nilsson [EMAIL PROTECTED]
PR libfortran/35293
* io/unix.c (fd_truncate): Fold s-special_file case into
success case of ftruncate/chsize call instead of the failure case.
Make failure case actually return failure. Properly
This commit:
2008-03-05 Hans-Peter Nilsson [EMAIL PROTECTED]
PR libfortran/35293
* io/unix.c (fd_truncate): Fold s-special_file case into
success case of ftruncate/chsize call instead of the failure case.
Make failure case actually return failure. Properly
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-03-19 03:46
---
*** This bug has been marked as a duplicate of 35632 ***
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-03-19 03:46
---
*** Bug 35633 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35632
--- Comment #2 from kargl at gcc dot gnu dot org 2008-03-19 04:09 ---
Hmmm, reverting Hans-Peter's patch does not fix the problem. Apologies
to Hans-Peter for jumping the gun.
Going back further in time, reverting r132512 fixes the problem with
streamio_4.f90, but
leads to
Running
--- Comment #3 from hp at gcc dot gnu dot org 2008-03-19 04:43 ---
(In reply to comment #2)
Hmmm, reverting Hans-Peter's patch does not fix the problem. Apologies
to Hans-Peter for jumping the gun.
Apology accepted. FWIW, looking at your strace output and streamio_4.f90, it
seems
--- Comment #2 from hp at gcc dot gnu dot org 2008-03-19 05:04 ---
You're updating the source and destination register but marking them only as
input in the asm. That's invalid. You trick GCC into believing that as it
hasn't changed, it can re-use the register with the source-address.
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-03-19 05:25
---
Since I do not have access to this system, can you try this:
Index: transfer.c
===
--- transfer.c (revision 133275)
+++ transfer.c (working copy)
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-03-19 05:40
---
Steve, also please replace the aborts in the test case and see what is really
happening. streamio_4.f90 is doing a large number of individual WRITEs in the
loop and your ktrace shows no failure of truncate. This
/* The next program is aborted with avr-gcc 4.1.2, 4.2.3, 4.3.0:
result of char promotion comes out of CHAR_MIN/MAX.
Options: -W -Wall -Os
Know to work:
3.3.6, 3.4.6 - good code
4.0.4 - correct, but not the best
4.1.2, 4.2.3, 4.3.0 - without optimization only
*/
95 matches
Mail list logo
