On Nov 4 2014, Jeff Law wrote:
On 11/04/14 09:11, Jakub Jelinek wrote:
The point is, if the target can implement just a subset of the Fortran
(or C or C++) standards, then ideally if you use anything that is not
supported would just cause always host fallback, the code will still
work, but
On Sep 18 2014, Janne Blomqvist wrote:
Apparently libgfortran is not compiled with -Werror, at least
not for crosses. Maybe -Werror is there for native but I'm not
sure as I see some warning: array subscript has type 'char'
[-Wchar-subscripts] which seems generic and also some others.
Though
On Mar 18 2011, Tobias Burnus wrote:
Thomas Koenig wrote:
+ if (!(*e)-value.function.esym-attr.pure
+ !(*e)-value.function.esym-attr.implicit_pure
+ !(*e)-value.function.esym-attr.elemental)
+ return 0;
I have not followed the discussion nor have I fully read the
On Apr 8 2011, Michael Matz wrote:
It adds a new option -fstack-arrays which makes the frontend put
all local arrays on stack memory. ...
Excellent!
I haven't rechecked performance now, but four months ago this was the
result for the fortran benchmarks in cpu2006:
There is actually a
On Apr 11 2011, H.J. Lu wrote:
Is that possible to raise stack limit when -fstack-arrays is used?
In some systems, yes. In others (including most Unices), not without
evil contortions that will assuredly break something else (like
debuggers and some MPIs).
Regards,
Nick Maclaren.
On Apr 12 2011, Michael Matz wrote:
On Mon, 11 Apr 2011, Steven Bosscher wrote:
Isn't there a way to put a maximum on the size of the arrays on stack,
e.g. -fstack-arrays-limit= or something like that?
Not without generating contorded code. The problem is that these arrays
are variable
On May 8 2011, Janne Blomqvist wrote:
the error printing functionality (in io/unix.c) st_printf and
st_vprintf are not thread-safe as they use a static buffer. ...
While this patch makes error printing thread-safe, it's no longer
async-signal-safe as the stderr lock might lead to a deadlock.
Sorry - I should have clarified that ANYTHING that can't be used
independently in multiple threads and at multiple levels in the same thread
counts as a resource, and that includes stderr.
Regards,
Nick Maclaren.
On May 8 2011, Janne Blomqvist wrote:
It's theoretically insoluble, given the constraints you are working
under. Sorry. It is possible to do reasonably well, but there will
always be likely scenarios where all you can do is to say Aargh!
I give up.
Well, I realize perfection is impossible,
On May 24 2011, FX wrote:
One solution could be to search the PATH for addr2line during library
initialization (where we don't need to be async-signal-safe), and then
store it somewhere and use it in show_backtrace().
That's one way. Another way is just to store a copy of the PATH during
On Nov 21 2013, FX wrote:
Note: Gradual underflow control is implemented as not supported by the
processor (its SUPPORT function returns false, and the GET and SET
procedures abort if you call them), because we probably don't have
targets where it would work (and I don't think people use it
On Nov 21 2013, Uros Bizjak wrote:
Indeed, 387/SSE has flush-to-zero modes. But other APIs do not (glibc,
SysV, AIX). I'm perfectly willing to add it, especially to 387/SSE, if
given a bit of help (someone to write the assembly code).
Just set FTZ bit in mxcsr. Please see
On Nov 21 2013, Joseph S. Myers wrote:
On Thu, 21 Nov 2013, FX wrote:
Indeed, 387/SSE has flush-to-zero modes. But other APIs do not (glibc,
SysV, AIX).
Note that glibc libm functions may not work when called in a flush-to-zero
mode, only in modes that can be established by the fenv.h
On Nov 21 2013, FX wrote:
That's a reasonable decision, but it is actually used at least ten
times as much as everything else put together, possibly a hundred times
as much.
I believe we are in pretty different parts of the community. Around me I
rarely see it used, while people check for
On Nov 23 2013, Andrew Pinski wrote:
On Sat, Nov 23, 2013 at 12:16 PM, Steve Kargl
s...@troutmask.apl.washington.edu wrote:
On Sat, Nov 23, 2013 at 11:21:21AM -0800, Mike Stump wrote:
Richi has asked the we break the wide-int patch so that the individual
port and front end maintainers can
On Nov 24 2013, Kenneth Zadeck wrote:
Thank you for your posting. That certainly clears up my understanding.
If there is a clear description of the subset
of C++ that the front-end is allowed to use, a pointer to it for the
benefit of Fortran/C/Ada/whatever people would be useful. But that's
On Mar 19 2013, Tobias Burnus wrote:
Am 19.03.2013 13:15, schrieb Janne Blomqvist:
now that the Fortran frontend is C++ we can use the primitive bool
type instead of inventing our own.
Well, C99's bool (_Bool) was already used before. ...
Er, that is making a serious mistake or, at least,
On Mar 21 2013, Joseph S. Myers wrote:
now that the Fortran frontend is C++ we can use the primitive bool
type instead of inventing our own.
Well, C99's bool (_Bool) was already used before. ...
Er, that is making a serious mistake or, at least, running the risk of
one. C++'s bool
On Mar 22 2013, Miles Bader wrote:
That is another matter entirely. The code of gcc/gfortran is supposed
to be compilable with other compilers, and it is foolish to make
unnecessary assumptions by relying on undefined behaviour.
The simple facts are that C++ does NOT define bool to be
On Mar 22 2013, Tobias Burnus wrote:
The front end and the backend are both compiled with the same compiler
and in the same binary. Even without bootstrapping, trying to compile
them with different compilers, will require some heavy editing of
makefiles. Thus, it seems to be extremely
On Jun 27 2018, Janus Weil wrote:
It is very unfortunate, and it means that the Fortran standard simply
does not provide a measure for "more correct" here. (My common-sense
drop-in notion of correctness would be that an optimization is
'correct' as long as it can be proven to not change any
On Jun 27 2018, Janus Weil wrote:
I'm not completely sure what you deduce from all these quoted
paragraphs, but applied to the cases we're discussing here, e.g.
A = .false. .and. my_boldly_impure_function()
I read them as saying that a compiler does not have to invoke the
function if it
On Jun 28 2018, Steve Kargl wrote:
You continue to miss my point or conveniently ignore it.
You want to special case the forced evaluation of the
operands in two specific logical expressions; namely, .and.
and .or. If you want to force evaluation of operands, then
do it for all binary
On Jun 28 2018, Toon Moene wrote:
And - most interesting - that's how Fortran 77 formulated it (way before
PURE/IMPURE functions entered the language):
"6.6.1 Evaluation of Operands
It is not necessary for a processor to evaluate all of the operands of
an expression if the value of the
On Jun 28 2018, Janus Weil wrote:
You mean compilers which transform "if (func() .and. flag)" into "if
(flag .and. func())", and then possibly remove the call? If yes, could
you tell us which compilers you are talking about specifically?
I am 70, and haven't supported multiple compilers for
On Jun 28 2018, Janus Weil wrote:
if we add a warning, we should add it both for
if (flag .and. func())
and for
if (func() .and. flag)
because the standard also allows reversing the test (which my
original test did).
well, I really don't want to warn for hypothetical problems. Since we
On Aug 20 2019, Steve Kargl wrote:
On Tue, Aug 20, 2019 at 09:56:27PM +0200, Thomas Koenig wrote:
I wrote:
> Committed as r274551.
Well, this revision appears to have woken quite a few bugs from their
slumber. While argument mismatch was always illegal, it seems to have
been a common idiom
On Dec 5 2019, Michael Matz wrote:
(oh a flame bait :) )
Quite. I shall try not to make it too much worse, but there's another point
that needs mentioning.
I find long names hard to read, with either short or long lines, especially
when combined with variants like
28 matches
Mail list logo
