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 negotiate_twisty_little_pas
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 at
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 expr
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 operators
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
curr
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 doesn'
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 resu
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 w
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 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 Nov 23 2013, Andrew Pinski wrote:
On Sat, Nov 23, 2013 at 12:16 PM, Steve Kargl
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 review their parts without have to
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
libgcc/config/i386/
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 n
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 functions.
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 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 unlikel
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 compati
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
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 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
ini
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,
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:
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. S
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 leng
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 9 2011, Magnus Fromreide wrote:
There is actually a much better approach, which was done in Algol 68
and seems now to be done only in Ada. As far as the compiler
implementation goes, it is a trivial variation on what you have done,
but there is a little more work in the run-time system.
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 muc
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 r
29 matches
Mail list logo
