Janus Weil wrote:
Jerry DeLisle wrote:
Tim Prince wrote:
I verified your report of 2 new problems (new since 2 weeks ago, the
last time I could bootstrap on cygwin):
use_only_1.f90 segfaults the compiler at all optimization levels.
array_constructor_24.f seems to get into a non-terminating loo
Jerry DeLisle wrote:
Tim Prince wrote:
I verified your report of 2 new problems (new since 2 weeks ago, the
last time I could bootstrap on cygwin):
use_only_1.f90 segfaults the compiler at all optimization levels.
array_constructor_24.f seems to get into a non-terminating loop at
run-time, whi
Tim Prince wrote:
I verified your report of 2 new problems (new since 2 weeks ago, the
last time I could bootstrap on cygwin):
use_only_1.f90 segfaults the compiler at all optimization levels.
array_constructor_24.f seems to get into a non-terminating loop at
run-time, which segfaults eventual
Jerry DeLisle wrote:
Here are gfortran failures I am seeing on Cygwin as of a few hours
ago. I noticed some of these are at -O3, implying some optimization
passes at fault. IIRC nint_2.f90 and default_format_denormal_1.f90 are
not new. The rest of these are fairly recent.
Maybe we need a me
Here are gfortran failures I am seeing on Cygwin as of a few hours ago. I
noticed some of these are at -O3, implying some optimization passes at fault.
IIRC nint_2.f90 and default_format_denormal_1.f90 are not new. The rest of
these are fairly recent.
Maybe we need a meta-bug to track these.
On Fri, May 2, 2008 at 11:39 AM, Peter Collingbourne <[EMAIL PROTECTED]> wrote:
> In the C++ frontend, record_types maintain list(s) of the parameters
> which were used to instantiate the type, one list for each "level" of
> the instantiation. I would like to know how to determine the list of
>
On Sat, May 3, 2008 at 3:13 PM, Richard Sandiford
<[EMAIL PROTECTED]> wrote:
> "Mohamed Shafi" <[EMAIL PROTECTED]> writes:
> > The gcc port that i am currently working on has both long calls and
> > short calls. If no 'shortcall' attribute is provided in the function
> > declaration then calls t
Hello all,
In the gcc port that i am currently working on delay slots are getting
filled with instructions that require a nop between them.
Say,
call fun
lw R0, R8
add R1, R0
This is an example where both the delay slots have been filled.
But 'add' instruction has a true data dependency on 'lw'
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
> The gcc port that i am currently working on has both long calls and
> short calls. If no 'shortcall' attribute is provided in the function
> declaration then calls to that function is made as long call. This is
> happening when no optimization is enable
