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 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.
> > -Wle
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 suc
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 that
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 techn
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 writes:
Do you have a suggestion how to best implement this whi
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 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
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:
http://www.cambr
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. T
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 procedu
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 obv
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 te
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 tha
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, 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 mos
On Apr 15 2011, Janne Blomqvist wrote:
Indeed, I assumed you were discussing how to implement CAF via shared
memory. If we use MPI, surely the implementation of MPI_Barrier should
itself issue any necessary memory fences (if it uses shared memory),
so I don't think __sync_synchronize() would b
On Apr 15 2011, Richard Guenther wrote:
On Fri, Apr 15, 2011 at 2:04 PM, Tobias Burnus wrote:
Q2: Can this be optimized in some way?
For simple types you could use atomic instructions for the modification
itself instead of two SYNC ALL calls.
Well, even with atomic you need to have a barri
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 variab
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.
Al
22 matches
Mail list logo
