Nicholas Nethercote [EMAIL PROTECTED] writes:
On Sun, 2 Dec 2007, Andreas Schwab wrote:
| 2007-11-30 Jan Hubicka [EMAIL PROTECTED]
|
| * ggc-common.c (dump_ggc_loc_statistics): Reset ggc_force_collect
| flag.
How could a newcomer guess why the gcc_force_collect flag
Nicholas Nethercote [EMAIL PROTECTED] writes:
Commit logs are basically invisible;
That's just a (fixable) problem in your coding setup. In other
projects it is very common to use tools like cvs annotate / cvsps /
git blame / git log / etc. to find the reasons for why code is the way
it is. In
Oliver.
Have you got a chance to take a look at the materials?
If yes, what do you think on it?
Yours sincerely,
George.
[EMAIL PROTECTED] ?:
Thank you for your reply, Oliver.
Briefly speaking the solution to the problems you have mentioned looks
like this:
1. take a loot at the first
Sorry, but again, this is not a good enough justification to me.
We do a lot of things different than The GNU Project.
So do plenty of parts of the official GNU project.
They use different coding standards, bug tracking systems, version
control systems, checkin policies, etc, than each other.
OK, sounds reasonable, but then I don't understand the logic behind
avoiding this instruction sequence for the volatile case, this is
two accesses at the bus level so what's the difference?
There's no difference from that perspective. The logic behind what's
generated is that instead of
From the last GCC Summit we learned about (Fortran) Frontend Based
Optimizations from Toon and it was suggested to tackle one issue by
promoting arrays to a first-class middle-end type. Discussion with
Sebastian also reveals that this makes sense to ease the analysis
of the into-GRAPHITE
Richard Kenner wrote:
OK, sounds reasonable, but then I don't understand the logic behind
avoiding this instruction sequence for the volatile case, this is
two accesses at the bus level so what's the difference?
There's no difference from that perspective. The logic behind what's
generated
On Mon, Dec 03, 2007 at 04:16:17PM +0300, [EMAIL PROTECTED] wrote:
Have you got a chance to take a look at the materials?
If yes, what do you think on it?
Nope, sorry, too busy with other things.
OG.
Eric Botcazou wrote:
On the SPARC, this produced an executable I couldn't run
on the simulator. It looked like the .text segment may
have increased enough to not fit in the simulator.
Weird. The EH tables should probably not end up in .text.
RTEMS applications are statically linked
There are in fact, already programs that will generate GNU format
changelogs from svn log (see http://ch.tudelft.nl/~arthur/svn2cl/)
It would be very easy to run these as part of the release process.
Sure, but I think that's bad for this project since I support the idea
that the svn log should
On 12/3/07, Richard Kenner [EMAIL PROTECTED] wrote:
Sorry, but again, this is not a good enough justification to me.
We do a lot of things different than The GNU Project.
So do plenty of parts of the official GNU project.
They use different coding standards, bug tracking systems, version
Right, but it would seem this is a good canididate for combination. This
is especially true since often Volatile is used with the sense of Atomic
in Ada, and it is not a bad idea to combine these in practice, giving an
atomic update (right, nothing in the language requires it, but it is
Mark Mitchell [EMAIL PROTECTED] writes:
Richard Sandiford wrote:
Anyway, given that there have been objections to the patch generally,
I realise that the pre-approval is void.
I think there's no controversy over the libstdc++ change, so let's put
that in. If nothing else, it makes the
[EMAIL PROTECTED] (Richard Kenner) writes:
Yes, but none of those are visible other than to the development community.
People who obtain the source distributions of projects don't get to see
those things. They DO see things like the ChangeLog format and coding
and documentation conventions
Except they aren't, across large parts of the GNU project.
You may find it the same in the traditional parts of the GNU project
(IE coreutils, emacs, etc).
It's certainly not the same across any of the newer parts of the GNU project.
Perhaps, but GCC has always been considered, like emacs,
It would be probably reasonable these days to require of someone who
wants to do serious development to just download a SVN checkout
for that [or they can use svnweb on http://gcc.gnu.org]
I agree. But I think the idea of the ChangeLog is for somewhere just short
of serious development. I'm
On 12/02/07 05:05, Samuel Tardieu wrote:
Maybe we should consider dropping ChangeLogs and using better checkin
messages.
I'm not sure people will want to drop ChangeLogs anytime soon. I don't
find them all that useful, but I *have* used them extensively when doing
archeology. It gives you
t1 = y | 2;
y = t1;
are very hard to tell apart at the RTL level. Though it's clear that
a single instruction might best match the expect semantics of the former,
it's a lot less clear that it would for the latter.
I think it would still be OK for the latter, why not?
I would like to reinterpret (not convert/cast) a 32-bit integer to a
32-bit float in GIMPLE. Is using a NOP_EXPR with the wanted type the
correct way of doing this?
The reinterpretation of a value is needed to optimize reads and writes
to unions. I modified the value numbering pass which worked
On Mon, Dec 03, 2007 at 04:07:35PM +, Richard Sandiford wrote:
And I haven't yet looked at why the tests are failing. I was just noting
that they did. It looks from PR21185 that Rask was seeing the same thing
on mipsisa64-elf, and TBH, I was so unsurprised that they were failing that
I
Diego Novillo wrote:
The history is something one finds on the mailing lists. So, my
proposal is to add a commit-time check that makes sure that the commit
message contains a URL to the message describing the change. IIUC, such
check shouldn't be hard to implement (Dan?)
I'd much prefer the
On 12/3/07, Sjodin, Jan [EMAIL PROTECTED] wrote:
I would like to reinterpret (not convert/cast) a 32-bit integer to a
32-bit float in GIMPLE. Is using a NOP_EXPR with the wanted type the
correct way of doing this?
You want to use the tree code called VIEW_CONVERT_EXPR.
Thanks,
Andrew Pinski
Bernd Schmidt [EMAIL PROTECTED] writes:
Diego Novillo wrote:
The history is something one finds on the mailing lists. So, my
proposal is to add a commit-time check that makes sure that the commit
message contains a URL to the message describing the change. IIUC, such
check shouldn't be
Bernd Schmidt wrote:
I'd much prefer the text from the mail message be repeated in the commit
log. Removes one step of indirection both when writing and reading the log.
I guess that could work, but that wouldn't give a way into the history
for the change. Several times there is a
I'd much prefer the text from the mail message be repeated in the commit
log. Removes one step of indirection both when writing and reading the log.
I would as well. Especially if you're trying to scan a large part of
the log looking for something.
On 12/03/07 13:50, Richard Kenner wrote:
I guess that could work, but that wouldn't give a way into the history
for the change. Several times there is a post-mortem discussion on the
patch, leading to more patches.
How about both?
Sure.
Diego.
I guess that could work, but that wouldn't give a way into the history
for the change. Several times there is a post-mortem discussion on the
patch, leading to more patches.
How about both?
On Mon, 2007-12-03 at 13:58 -0500, Diego Novillo wrote:
On 12/03/07 13:50, Richard Kenner wrote:
I guess that could work, but that wouldn't give a way into the history
for the change. Several times there is a post-mortem discussion on the
patch, leading to more patches.
How about
Richard Kenner wrote:
t1 = y | 2;
y = t1;
are very hard to tell apart at the RTL level. Though it's clear that
a single instruction might best match the expect semantics of the former,
it's a lot less clear that it would for the latter.
I think it would still be OK for the
Hello!
What is the reason for GCC (trunk version) installing the limits.h
header file as `PREFIX/lib/gcc/*/*/include-fixed/limits.h' instead of
putting it into `PREFIX/lib/gcc/*/*/include/', which is what
gcc-4_2-branch and earlier have been doing?
The leads to a problem as follows. You're
Snapshot gcc-4.1-20071203 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20071203/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Thomas Schwinge [EMAIL PROTECTED] writes:
Is this a GCC issue or should the glibc build system be adding a
``-isystem [GCC target]/4.3.0/include-fixed''?
The latter.
http://sourceware.org/ml/libc-alpha/2007-03/msg00017.html
Ian
Hello!
On Mon, Dec 03, 2007 at 03:18:42PM -0800, Ian Lance Taylor wrote:
Thomas Schwinge [EMAIL PROTECTED] writes:
Is this a GCC issue or should the glibc build system be adding a
``-isystem [GCC target]/4.3.0/include-fixed''?
The latter.
Thomas Schwinge [EMAIL PROTECTED] writes:
Hello!
On Mon, Dec 03, 2007 at 03:18:42PM -0800, Ian Lance Taylor wrote:
Thomas Schwinge [EMAIL PROTECTED] writes:
Is this a GCC issue or should the glibc build system be adding a
``-isystem [GCC target]/4.3.0/include-fixed''?
The latter.
Hello!
On Mon, Dec 03, 2007 at 05:05:10PM -0800, Ian Lance Taylor wrote:
Thomas Schwinge [EMAIL PROTECTED] writes:
On Mon, Dec 03, 2007 at 03:18:42PM -0800, Ian Lance Taylor wrote:
Thomas Schwinge [EMAIL PROTECTED] writes:
Is this a GCC issue or should the glibc build system be adding a
Hello!
Execuse me but I have something bothering me.
I inserted a method into rest_of_compilation() (before calling
rest_of_handle_life()) to insert some new insn before insn were
translated to asm. But after my modification, when processing some
insn moving one pseudo reg to another
On Mon, 3 Dec 2007, Andi Kleen wrote:
Commit logs are basically invisible;
That's just a (fixable) problem in your coding setup. In other
projects it is very common to use tools like cvs annotate / cvsps /
git blame / git log / etc. to find the reasons for why code is the way
it is. In fact
--- Comment #1 from ismail at pardus dot org dot tr 2007-12-03 08:00
---
Also the check-localplt test fail :
cat build-default-i686-pc-linux-gnu-nptl/elf/check-localplt.out
--- ../scripts/data/localplt-i386-linux-gnu.data2006-01-30
11:29:48.0 +0200
+++ - 2007-12-03
Someone reported a problem with the Windows binaries that is related to how we
deal with CRLF-formatted module files. This issue can be reproduced on non-CRLF
systems by the following:
$ cat a.f90
module foo
end module foo
$ gfortran -c a.f90
$ cat b.f90
use foo
end
$ gfortran
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
The price A users storyUK Prime Minister Tony Blair has promised to give every
school university.
Mean most people will instantly recognise this as suspicious said Mr.
--- Comment #27 from bonzini at gnu dot org 2007-12-03 10:17 ---
It seems to me that the old RAW_CXX_FOR_TARGET is unused after the patch.
Can you confirm?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
--- Comment #5 from steven at gcc dot gnu dot org 2007-12-03 10:13 ---
Inlining is driven by heuristics. See ipa-inline.c. Heuristics cannot be
perfect for all applications, of course. The current tuning of the heuristics
is based on SPEC2k scores on Opteron, i.e. mostly for programs
--- Comment #1 from jakub at gcc dot gnu dot org 2007-12-03 10:46 ---
Subject: Bug 34317
Author: jakub
Date: Mon Dec 3 10:45:53 2007
New Revision: 130579
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130579
Log:
PR middle-end/34317
* opts.c
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-12-03 10:46 ---
Can you provide a testcase please?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ismail at pardus dot org dot tr 2007-12-03 11:01
---
Created an attachment (id=14687)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14687action=view)
glibc double test
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34321
--- Comment #5 from ismail at pardus dot org dot tr 2007-12-03 11:02
---
Just run ./build.sh to build and ./test-double to run. Gives the following
error with gcc 4.3 trunk here :
testing double (without inline functions)
Failure: Real part of: csin (-0 + inf i) == -0 + inf i:
--- Comment #2 from jakub at gcc dot gnu dot org 2007-12-03 10:53 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from ismail at pardus dot org dot tr 2007-12-03 10:49
---
I will try to get two tests out of glibc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34321
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-12-03 11:12 ---
I see the failure with 4.1.2, 4.2.2 and 4.3 but not with 4.0.3. With
optimization
turned on, the test also succeeds.
I think this is related to PR33088.
--
rguenth at gcc dot gnu dot org changed:
--- Comment #4 from antoine64leca at hotmail dot com 2007-12-03 10:39
---
If this works for you, I will check it in.
OK, it works OK here.
Many thanks for your quick and efficient help.
Antoine
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34288
--- Comment #10 from ismail at pardus dot org dot tr 2007-12-03 11:17
---
This breaks glibc 2.7 regression tests.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33088
--- Comment #2 from ubizjak at gmail dot com 2007-12-03 11:25 ---
Created an attachment (id=14688)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14688action=view)
reduced c testcase
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #3 from ubizjak at gmail dot com 2007-12-03 11:28 ---
Confirmed. Register allocator issue.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-12-03 11:13 ---
In fact, it looks like the same problem.
*** This bug has been marked as a duplicate of 33088 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-12-03 11:13 ---
*** Bug 34321 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
This is similar to PR 32151
$ gfortran --version
GNU Fortran (GCC) 4.3.0 20071109 (experimental) snip
$cat aa.f90
program aa
implicit none
real(kind=8)::r1=0
if ((3*r1)**2)0) stop
end
$ gfortran -c aa.f90
aa.f90:4.14:
if ((3*r1)**2)0) stop
1
Error: Cannot assign to a named
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-12-03 12:56 ---
GCC 4.1 (and above) is correct, the overloaded set of resolveName should be
either the direct namespace of which A resides (the global one) or the ones
which are defined before getName.
This is the specific
--- Comment #28 from peb at mppmu dot mpg dot de 2007-12-03 12:57 ---
(In reply to comment #27)
It seems to me that the old RAW_CXX_FOR_TARGET is unused after the patch.
Can you confirm?
I don't think so. The toplevel Makefile.in contains the lines
RAW_CXX_TARGET_EXPORTS = \
--- Comment #6 from dominiq at lps dot ens dot fr 2007-12-03 12:41 ---
Form the gcc manual:
-finline-limit=n
... . The default value of n is 600. ...
This does not seem accurate: ddx and ddy are inlined for n=318, but not for
n=317 (corresponding respectively to 2.7s and 1.6s for the
--- Comment #20 from jakub at gcc dot gnu dot org 2007-12-03 13:09 ---
Andrew, do you have any testcases to back up #c17 claim?
Anyway, some things can be handled already without VCE (and it is undesirable
to generate VCE), like the #c11 testcase.
Here are 2 alternatives I've been
--- Comment #29 from bonzini at gnu dot org 2007-12-03 13:17 ---
It might be me, but I cannot see when they are used. Or better, yes, they are
used in LTCXXCOMPILE but there a few -L... switches shouldn't make any
difference, so you could use CXX_FOR_LIB also in LTCXXCOMPILE (and the
--- Comment #4 from ubizjak at gmail dot com 2007-12-03 13:45 ---
This all comes down to PR 19398. Since JamoClusterSearch() is defined as
static, gcc switches to register passing convention, and this uses %eax, %edx
and %ecx. %ebx is used as a PIC register, so we are out of QImode
--- Comment #11 from bechir dot zalila at gmail dot com 2007-12-03 14:00
---
After a lot of investigation, I succeeded to isolate the problem. The added
-mmacosx-min-version is not done when processing the CC1_SPEC: It is done in
the main function in gcc.c using the
--- Comment #10 from bechir dot zalila at gmail dot com 2007-12-03 13:54
---
Created an attachment (id=14689)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14689action=view)
Patchfile that solves the problem
This patchfile solves the problem by adding a new switch (-gnatea)
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #27 from dominiq at lps dot ens dot fr 2007-12-03 14:32 ---
I have had a look at the failure of gfortran.dg/array_1.f90 with patch #5. The
following reduced code gives the same failure:
! { dg-do run }
! PR 15553 : the array used to be filled with garbage
! this problem
--- Comment #28 from dominiq at lps dot ens dot fr 2007-12-03 14:33 ---
Created an attachment (id=14691)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14691action=view)
result of -fdump-tree-optimized with patch #5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34265
--- Comment #26 from dominiq at lps dot ens dot fr 2007-12-03 14:08 ---
IMO, SLP should vectorize the sequence.
Uros,
What is the meaning of the above sentence?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34265
--- Comment #12 from bechir dot zalila at gmail dot com 2007-12-03 14:23
---
Created an attachment (id=14690)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14690action=view)
Patchfile that solves the problem
Fixed a typo in comment
--
bechir dot zalila at gmail dot com
--- Comment #29 from dominiq at lps dot ens dot fr 2007-12-03 14:34 ---
Created an attachment (id=14692)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14692action=view)
result of -fdump-tree-optimized without patch #5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34265
--- Comment #7 from jakub at gcc dot gnu dot org 2007-12-03 15:00 ---
This isn't one bug, but many unrelated ones.
I have a fix for #c3 testcase, a fix for the p+ issue in the initial testcase
and also a different ICE with missing DECL_GIMPLE_REG_P created by parloop.
But those aren't
--- Comment #21 from jakub at gcc dot gnu dot org 2007-12-03 15:08 ---
Ping.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #5 from pault at gcc dot gnu dot org 2007-12-03 15:05 ---
(In reply to comment #4)
Just for the record, the following, very crude patch works and produces the
same output as NAG. It needs a lot of cleaning up and I should understand why
the inclusion of LEN works fine,
--- Comment #5 from bonzini at gnu dot org 2007-12-03 15:15 ---
As a start, let's limit register passing convention to regparm=2. The risk of
running out QImode registers is quite real, as is the risk of getting extremely
bad code...
--
bonzini at gnu dot org changed:
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |sam at gcc dot gnu dot org
|dot org
--- Comment #22 from hp at gcc dot gnu dot org 2007-12-03 15:23 ---
Ping for me or John David Anglin?
I suppose it's for him, as I don't see the failure on currentish (130398)
trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32636
--- Comment #13 from bechir dot zalila at gmail dot com 2007-12-03 15:26
---
Created an attachment (id=14693)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14693action=view)
Patchfile that solves the problem
Added the support of registring non-(g*m*) switches
--
bechir dot
--- Comment #2 from sam at gcc dot gnu dot org 2007-12-03 16:03 ---
This bug has been fixed in SVN trunk.
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from sam at gcc dot gnu dot org 2007-12-03 16:02 ---
Subject: Bug 34287
Author: sam
Date: Mon Dec 3 16:01:57 2007
New Revision: 130582
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130582
Log:
2007-12-03 Robert Dewar [EMAIL PROTECTED]
Samuel Tardieu
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-12-03 15:44 ---
Re-confirmed with SCCVN. Note that while it value numbers the COND_EXPR on
the RHS it does not simplify the condition in the COND_EXPR stmt:
Value numbering tmp_3 stmt = tmp_3 = a_2(D) 2;
Setting value number of
--- Comment #6 from jsjodin at gcc dot gnu dot org 2007-12-03 15:41 ---
Indeed the extra load disappeared when with the patch. The store did not get
deleted as expected. I looked at the differences between the good and bad
case.
After doing some more investigation an attempt to
--- Comment #2 from doko at ubuntu dot com 2007-12-03 15:56 ---
sorry, I was unclear: I changed it from -O3 -fno-strict-aliasing to -O2
-fno-strict-aliasing; didn't try -O2 alone.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34304
--- Comment #23 from dave at hiauly1 dot hia dot nrc dot ca 2007-12-03
15:43 ---
Subject: Re: [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related
verify_ssa failure
Ping.
Sorry, I don't have an update and haven't had a chance to try the
suggestions in #20. I've been
I was surprised that gcc did not find an error in the following example.
My understanding is that assignment to a void pointer is ok, but arithmetic
is _not_ ok. I have tried this code on my arm cross compiler gcc v. 4.1.1 and
my ubuntu system compiler 4.1.3. Gcc treats the void pointer type as
--- Comment #1 from jmparker at marvell dot com 2007-12-03 16:03 ---
Created an attachment (id=14694)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14694action=view)
simple .c example
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34326
--- Comment #3 from brian at dessent dot net 2007-12-03 16:25 ---
Subject: Re: New: pointer arithmetic on void pointers does not
generate an error
This is a GNU C extension, see
http://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html. I think you can
disable it with -std=c89 or
--- Comment #30 from ubizjak at gmail dot com 2007-12-03 16:30 ---
(In reply to comment #26)
IMO, SLP should vectorize the sequence.
What is the meaning of the above sentence?
Uh, sorry for being terse. If there are no loops, then straight-line
parallelization [SLP] should vectorize
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-12-03 16:24 ---
This is a GCC extension. Use -pedantic to get a warning, -pedantic-errors to
get an error.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-12-03 16:32 ---
Instead, -fPIC should unconditionally decrease the available regparm by 1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34312
--- Comment #3 from rask at gcc dot gnu dot org 2007-12-03 17:34 ---
Created an attachment (id=14695)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14695action=view)
testcase
This testcase fails with revision 130561.
./xgcc -B./ -O2 /tmp/hashtab.c -S -o /dev/null
(gdb) call
--- Comment #7 from rask at gcc dot gnu dot org 2007-12-03 17:52 ---
Note that reload asks for Q_REGS when the constraints allow GENERAL_REGS, so
the root cause is just reload being stupid. I bet it is this optimization from
find_reloads() that causes it:
if (! win !
I compiled the following program with the Windows port of gfortran. When I run
it in a MinGW shell, I do not see the output of the PRINT statement until after
the READ statement has been executed. The problem does not exist if the program
is run in a Cygwin shell, or in a DOS Window.
PROGRAM test
--- Comment #10 from jakub at gcc dot gnu dot org 2007-12-03 18:11 ---
The problem as I see it is that result is uninitialized in the inline routine
and in addition to that is SSA_NAME_OCCURS_IN_ABNORMAL_PHI. After inlining the
empty_stmt SSA_NAME_DEF_STMT is considered to be live from
--- Comment #31 from dominiq at lps dot ens dot fr 2007-12-03 18:58 ---
If there are no loops, then straight-line parallelization [SLP] should
vectorize
your manually unrolled sequence in comment #24.
Yes it should, but if does not after patch #5. The unanswered question so far
--- Comment #1 from burnus at gcc dot gnu dot org 2007-12-03 19:00 ---
Is screen output buffered when gfortran
Generally, gfortran buffers output. (Or more precisely, it lets the C library
do the buffering.) Seemingly, in the MinGW shell there is more buffering.
PRINT *, In the
Summary: After building 4.2.2, `make install` failed due to unrecognized
option `-Wno-overlength-strings`. Removing `-Wno-overlength-strings`
everywhere from BUILDIR/gcc/Makefile fixed it.
These are the source packages used:
gcc-core-4.2.2.tar.bz2
gcc-g++-4.2.2.tar.bz2
This is the exact command
$ cat write_formatted_stream.f90
program main
implicit none
integer :: i
open(2003,form=formatted,access=stream)
do i=1,100
write (2003,'(A)') 'a'
end do
end program main
$ gfortran write_formatted_stream.f90
$ strace -e write,read,_llseek ./a.out
read(3,
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2007-12-03 20:48
---
Instead, -fPIC should unconditionally decrease the available regparm by 1.
Yes, this seems to be the best solution in the short term.
--
ebotcazou at gcc dot gnu dot org changed:
What
1 - 100 of 120 matches
Mail list logo
