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
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
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 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 Jan 27 2019, Steve Kargl wrote:
On Sun, Jan 27, 2019 at 01:19:08PM -0800, Andrew Pinski wrote:
On Sun, Jan 27, 2019 at 1:02 PM Thomas König wrote:
>
> > In fact, I would be in favor of removing -Wall, as it is misnamed,
> > in favor of -Wlevel=0,1,2,3... -Wlevel=0 default warnings.
> >
On Jan 23 2019, Thomas König wrote:
Am 23.01.2019 um 12:36 schrieb Jonathan Wakely :
When there are new warnings that aren't enabled by -Wall -Wextra,
there's probably a reason they aren't enabled by default.
are a higher form of life than mere Fortran
-Wconversion-extra is an example of
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, 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, 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 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 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 Apr 12 2018, Thomas König wrote:
with Fortran 2018, recursive is becoming the default. This will likely
have a serious impact on many user codes, which often declare large
arrays which could then overflow stacks, leading to segfaults without
further explanation.
Yes. Been there - seen
On Dec 16 2016, Janus Weil wrote:
thanks for this lengthy comment, but that's really not the kind of
discussion I wanna get into here. (And I don't actually agree to all
of your points, but that doesn't matter.)
Sorry - I misunderstood.
Regards,
Nick Maclaren.
On Dec 16 2016, Janus Weil wrote:
What I'd like to know is: In the current state of things in GCC, is it
possible/reasonable to use any of the STL containers (like
std::vector, std::string, whatever) in GCC and its front ends (in
particular gfortran)?
That question has two parts:
1) Is it
On Dec 1 2014, Dodji Seketeli wrote:
Just for the record -- as I am trimming the original post for legibility
-- the initial message I am replying to can be read at
https://gcc.gnu.org/ml/gcc/2014-11/msg00357.html.
Tobias Burnus bur...@net-b.de writes:
Do you have a suggestion how to best
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 Oct 31 2014, Janne Blomqvist wrote:
what would be the best way to test stuff like two binaries
communicating via a pipe, FIFO or such with DejaGNU? The gfortran
testsuite has by now quite extensive coverage of all the weird and
quirky corner cases of Fortran I/O behavior, but practically all
On Oct 31 2014, Janne Blomqvist wrote:
My main aim here really is to just get the basics right before
worrying about corner cases. For instance, I recall we have failed in
a simple sequential reading of a access=sequential, form=formatted
unit connected to a pipe or such, because libgfortran
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
Here is some information from a Cambridge resident. Use it as you will.
Don't even think of driving anywhere near Cambridge city centre, unless
you either know it or are a complete masochist. Taxis are available
but expensive and have to be requested.
Bus timetables are here:
On Jul 3 2014, Uros Bizjak wrote:
Maybe a new hook should be introduced instead: TARGET_IEEE_FORMAT_P
(mode). For some targets, even soft-fp supports required rounding
modes and can generate exceptions.
Before doing anything, it would be a good idea to decide on what IEEE
conformance means.
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 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 7 2013, FX wrote:
Given how murky signaling NaNs are in practice, I think it's worth
asking: why do you want to know?
Because I am writing an implementation of the IEEE support modules in GNU
Fortran, which are part of the Fortran 2003 standard. And the standard
provides for a
On Nov 6 2013, FX wrote:
GCC has a number of floating-point-related type-generic built-ins, which
are great and which we largely rely on in the gfortran runtime library
(rather than depending on the possibly poor-quality target math library).
However, I have not been able to find a way to
Yes, due to the poor quality of the IEEE 754 specifications. In 1984,
the distinction was left completely unspecified (even in intent). In
2008, there is a recommendation (no more) that the top bit of the payload
is used, with no specification of what to do if that is zero (which is
the most
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 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 6 2013, Russell Brennan wrote:
Ouch.
This seems to be at odds with C's unions, where it is not allowed to do
type punning.
As of gcc 4.4.6, the description above seems to match the C behavior:
Er, no. One simple test does not prove that it will always work; this
sort of thing is
On Mar 6 2013, Russell Brennan wrote:
Perhaps I misunderstand how you are defining failure here... what
would be the failure mode? Perhaps if you could provide an example of
the ill-effects that could be seen as a result of this behavior it
would clarify the issue?
Generating bad code. In:
On Mar 6 2013, Andrew Pinski wrote:
Except GCC implements C's unions as allowing to do type punning as an
extension and as far as GCC is concerned that is not going to change
any time soon.
This is a documented exception to the aliasing/type punning rules.
The problem is that this is worse
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 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 Apr 15 2011, Tobias Burnus wrote:
(Frankly, I am not 100% sure about the exact semantics of ASYNCHRONOUS;
I think might be implemented by preventing all code movements which
involve swapping an ASYNCHRONOUS variable with a function call, which is
not pure. Otherwise, in terms of the
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 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 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 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 Aug 12 2010, Steve Kargl wrote:
Your observation re-enforces the notion that doing
benchmarks properly is difficult. I forgot about
the lapack inquiry routines. One would think that
some 20+ year after F90, that Dongarra and colleagues
would use the intrinsic numeric inquiry functions.
48 matches
Mail list logo
