y help.
Ah - one detail that I forgot to mention: our code is "special" in the
sense that it uses 32-bit floats while it runs on 64-bit address space.
So its use of gather instructions is rather suboptimal, needing 2 gather
instructions for each actual "gather operation".
utational intensive part of the
code needs gather (either instructions or inline expansions of them).
Hope this helps,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
On 6/19/24 21:06, Richard Biener wrote:
Am 19.06.2024 um 20:25 schrieb Toon Moene :
On 6/17/24 16:05, Richard Biener wrote:
Automatic arrays that are not address-taken should not be subject to
store data races. This applies to OMP SIMD in-branch lowered
functions result array which for
, they are assigned
memory space on the stack.
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
me, as for you, it works for x86_64-linux-gnu:
https://gcc.gnu.org/pipermail/gcc-testresults/2024-February/807609.html
I hope this helps.
Kind regards,
Toon Moene.
On 2/9/24 11:26, Richard Biener wrote:
The following allows a base term to be derived from an existing
MEM_EXPR, notably the points
because it happens in the test suite of gmp, which I build
locally as part of the build.
It *is* visible in the full log of the bootstrap:
toon@moene:~/compilers$ grep ^FAIL log-thunderx-r14-8681
FAIL: libphobos.exceptions/rt_trap_exceptions.d output pattern test
FAIL: tacos
FAIL: tacosh
FAIL: ta
building with
bootstrap-lto and bootstrap-O3:
https://gcc.gnu.org/pipermail/gcc-testresults/2024-January/804807.html
?
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
x27;t given any values ...
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
While there is no "general method" for this, there exists a whole
Working Group under ISO whose responsibility is to identify and list
vulnerabilities in programming languages - Working Group 23.
Its web page is: https://www.open-std.org/jtc1/sc22/wg23/
Kind regards,
--
Toon Moen
ough there's no way in hell the Fortran Language Standard (any of
them) guarantees this.
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
ur_source&)
/home/toon/compilers/gcc/gcc/gimple-range-fold.cc:558
0x1ac50ba fold_using_range::fold_stmt(vrange&, gimple*, fur_source&,
tree_node*)
/home/toon/compilers/gcc/gcc/gimple-range-fold.cc:489
Please submit a full bug report, with preprocessed source (by using
It was just a comment on the code of the PR ...
Toon.
On 10/13/22 15:44, Aldy Hernandez wrote:
I'm not following. My patch doesn't affect this behavior.
What am I missing?
Aldy
On Thu, Oct 13, 2022 at 3:04 PM Toon Moene wrote:
On 10/13/22 14:36, Aldy Hernandez via Gcc-pat
feature: End expression in DO loop at (1) must be integer
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
+++ b/gcc/value-range-pretty-print.h
@@ -32,6 +32,7 @@ private:
void print_irange_bound (const wide_int &w, tree type) const;
void print_irange_bitmasks (const irange &) const;
void print_frange_nan (const frange &) const;
+ void print_real_value (tree type, const REAL_VALUE_TYPE
tude, longitude (and time [hour of
the day, day of the year]).
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
d there's a lot more headroom
for improvements in the FP space than the integer space IMHO.
One of the more interesting ones is to try to limit the range of the
input to the trigonometric functions - that way you could use ones
without any argument reduction phase ...
--
Toon Moene - e-mai
On 8/29/22 16:36, Aldy Hernandez wrote:
On Mon, Aug 29, 2022 at 4:30 PM Toon Moene wrote:
On 8/29/22 16:15, Aldy Hernandez wrote:
But even with -ffinite-math-only, is there any benefit to propagating
a known NAN? For example:
The original intent (in 2002) for the option -ffinite-math
nd regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
o not know offhand which MODE_ that is) ...
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
compilers differ in the
treatment of this case, there might be reason to ask the Fortran
Standard Committee for an Interpretation of the Standard ?
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Seems to have been fixed in r13-449.
Compare:
https://gcc.gnu.org/pipermail/gcc-testresults/2022-May/761443.html
with (r13-448):
https://gcc.gnu.org/pipermail/gcc-testresults/2022-May/761431.html
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738
rtran directories ?
I would recommend to send this message to the fort...@gcc.gnu.org list
too, then.
Not everyone reads the gcc and gcc-patches lists ...
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
to ask the Fortran Standardization Committee for an interpretation
(of the standard's text).
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
On 2/9/20 9:55 PM, Steve Kargl wrote:
On Sun, Feb 09, 2020 at 09:15:46PM +0100, Toon Moene wrote:
On 2/6/20 9:01 PM, David Malcolm wrote:
PR analyzer/93405 reports an ICE when attempting to use -fanalyzer on
certain gfortran code. The second patch in this kit fixes that, but
in the
gfortran.dg/analyzer subdirectory with an analyzer.exp,
setting DEFAULT_FFLAGS on the tests run within it.
I have seen no objections against this proposal, so please go ahead.
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The
that it is complicated, it is also a good idea to make math
function vectorization orthogonal to OpenMP.
Definitely agree. I always found it a strained relationship, and only
supported it being done that way because it worked.
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
sting enough to try on its own merits,
even if it's not committed by tomorrow morning ...
Fascinating analysis - thanks !
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http:/
2.0-3) ...
Processing triggers for libc-bin (2.27-6) ...
[ previously this led to apt errors, but not now. ]
and moved my own installation of the OpenCoarrays-2.2.0.tar.gz out of
the way:
toon@moene:~$ ls -ld *pen*
drwxr-xr-x 6 toon toon 4096 Aug 10 16:01 OpenCoarrays-2.2.0.opzij
drwxr-xr-x
install
After that, it was a breeze to test my mock weather program
(moene.org/~toon/random-weather.f90), that I had built until then only
with -fcoarray=single.
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: ht
).
gfortran82 -S -Ofast -march=native -mtune=native:
458 verint.s.82.loop3
gfortran90 -S -Ofast -march=native -mtune=native:
396 verint.s.90.loop3
But the most stunning difference is the use of the stack [ nn(rsp) ] -
see the attached files ...
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346
aining the function reference. In the
example above, evaluation of the expression causes Z to become undefined
if L defines its argument."
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.org/
The documentation of both options is still inconsistent, in both the
trunk and the gcc-8 branch.
The following is my suggestion to clear this up (and move
-floop-unroll-and-jam close to -floop-interchange.
ChangeLog:
2018-05-17 Toon Moene
* doc/invoke.texi: Move -floop-unroll
anges loops in a loop nest to
improve data locality. Both passes are enabled by default at -O3 and above."
However, the documentation of optimization options does not reflect this.
Is the following change to the documentation acceptable ?
ChangeLog
2018-04-19 Toon Moene
* doc/invoke
this comment a few years ago, when Jakub Jelinek
implemented support for gather in vectorization *of our loops*.
Before that, I had only seen programmers do it for our code by rewriting
the Fortran into something that was completely unreadable.
--
Toon Moene - e-mail: t...@moene.org - phone: +3
its work.
Without gather the most expensive loop in our code couldn't be
vectorized (there are only a handful of gather instructions in that loop
and dozens of other vector instructions).
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3
not in favor of eliminating it either.
I think for non-native speakers of English, using the full word is
easier to read (you can't take my experience as an example, as I was
exposed to written English 48 years ago).
I think replacing the few instances of can't with cannot is worth t
that couldn't cope with
it (I won't name names).
Thanks and kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
up in scripts and
make files ... Whether support for COTAN (in radians) should be part of
this option - I rather had it not.
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather:
e that you need to
overhaul most of the front end (and parts of the run-time library) to
get that correct ...
Thanks Paul et al. for working on this daunting task !
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlan
mid-April) to fix it, if necessary.
Thanks !
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
On 01/18/2016 08:55 PM, Toon Moene wrote:
On 01/17/2016 01:44 PM, Thomas Koenig wrote:
So... comments? Toon, would this help you? Could yo maybe give this
a spin?
Thanks, the nightly test at my home computer will build with your patch.
That was the plan; unfortunately, the system
On 01/18/2016 11:14 PM, Thomas Koenig wrote:
Hi Toon,
It will also perform the following tests (minus the
"inline_matmul_13.f90" one, which wasn't included in the attachements :-)
Well, here it is.
Included, thanks,
--
Toon Moene - e-mail: t...@moene.org - phone:
ld all kinds of
support libraries (for which I now depend on Debian Testing) by hand.
But I hope just testing your examples will at least give you an idea (on
-march=haswell).
Thanks, and kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Ma
On 12/23/2015 08:57 PM, Marc Glisse wrote:
On Wed, 23 Dec 2015, Toon Moene wrote:
On 12/22/2015 02:59 PM, Gerald Pfeifer wrote:
+ssh username@gcc.gnu.org append-key < KEYFILE
Hmm, I get:
toon@moene:~$ ssh t...@gcc.gnu.org append-key < .ssh/id_dsa.pub
/home/toon/.ssh/config line
On 12/22/2015 02:59 PM, Gerald Pfeifer wrote:
Jan (Beulich) ran into this, and indeed I could not find it
documented. So I added it. ;-)
+ssh username@gcc.gnu.org append-key < KEYFILE
Hmm, I get:
toon@moene:~$ ssh t...@gcc.gnu.org append-key < .ssh/id_dsa.pub
/home/toon/.ssh/confi
this.
And then there's this:
https://gcc.gnu.org/ml/gcc-testresults/2015-08/msg01036.html
[ Yes, that's at run time, not compile time ... ]
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moen
odules
the past week (it still has to go to several mail ballots, but still),
overwhelmingly prefering option 3:
[attached]
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.org/~toon/;
+
+
+
+
+
+
+
+New Languages and Language specific improvements
Aarghh - you forgot Fortran !
/snark.
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam
rray actual argument passed as "CALL SUB(.., A(2:), ..)", which is
extremely rare).
So this propagation of alignment information will result in basically
removing all alignment peeling for Fortran code.
Thanks !
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Sa
577:60:ESC[1mESC[31m
runtime error: ESC[1mESC[0mESC[1mload of value 32763, which is not a
valid value for type 'x86_64_reg_class'ESC[1mESC[0m
?
It makes precise grepping needlessly hard ...
Otherwise, thanks very much for this work - definitely appreciated !
--
Toon Moene - e-mail: t.
s to do a ubsan bootstrap, download mine from last night
(x86_64-linux-gnu): http://moene.org/~toon/gcc-tests.log.gz
[ I hope there is a way to discard color codings when writing error
messages to a file, ugh ]
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Satur
most common x86-64 one) would be helpful to find bugs in the
compilers' frontends, middle end and libraries ...
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http:/
On 01/03/2014 10:11 PM, Jakub Jelinek wrote:
Hi!
On Fri, Jan 03, 2014 at 08:58:30PM +0100, Toon Moene wrote:
I don't doubt that would work, what I'm interested in, is (cat verintlin.f):
Well, you need gather loads for that and there you hit PR target/59617.
I tried your patc
"go" and "ubsan" for "asan").
Kind regards,
--
Toon Moene, Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
this - it is really hard to get
a cross-language standard like this one correct, let alone its
implementation.
The reports I receive on the OpenMP implementation in GCC (from the
gfortran users' side) are without exception positive.
Thanks !
--
Toon Moene - e-mail: t...@moene.org - phone
)/libsanitizer/asan/ \
-B$$r/prev-$(TARGET_SUBDIR)/libsanitizer/asan/.libs
Ok.
Jakub
After this went in, I got further now:
http://gcc.gnu.org/ml/gcc-testresults/2013-02/msg02974.html
than before:
http://gcc.gnu.org/ml/gcc-testresults/2013-02/msg02749.html
--
Toon
_64 again (with tailc fix:
http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00310.html), ok now?
Ok. Let's watch for fallout...
Thanks,
Richard.
Maybe here:
http://gcc.gnu.org/ml/gcc-testresults/2013-02/msg00835.html
?
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturn
On 11/16/2012 04:35 PM, Ian Lance Taylor wrote:
I expect it's pronounced with a sort of throat-clearing noise that is
hard to write. Sort of like the gargling sound represented by "argh."
argh32 and argh64.
I thought it was a nice way to enshrine a Monty Python joke into si
segmentation
fault caused by corruption of the malloc arena ...
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/wiki
age:
http://gcc.gnu.org/ml/gcc-testresults/2012-08/msg01408.html
both for x86_64-unknown-linux-gnu native (note:
--with-build-config=bootstrap-lto).
As far as I can, little difference.
Congratulations, Diego and all the others who worked on this transition.
Kind regards,
--
Toon Moene - e-mail
On 05/12/2012 12:36 PM, Richard Guenther wrote:
On Sat, May 12, 2012 at 9:53 AM, Toon Moene wrote:
On 05/11/2012 01:59 PM, Richard Guenther wrote:
This fixes the dependency of vectorization of strided loads on
gather support. For that to work we need to lift the restriction
in data-ref
9
69: not vectorized: not suitable for gather load D.2051_74 =
*parg_73(D)[D.2050_72];
69: not vectorized: not suitable for gather load D.2051_74 =
*parg_73(D)[D.2050_72];
verintlin.f:1: note: vectorized 0 loops in function.
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Satu
plied to
trans-array.c ?
Or do I have to apply a different method ?
Thanks !
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://g
0) to the 4.6
branch, so it's needed there too.
Thanks for fixing this !
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
On 12/21/2011 10:00 PM, Steve Kargl wrote:
On Mon, Dec 19, 2011 at 06:54:08PM +0100, Toon Moene wrote:
The attached patch makes -finit-= generate default
initialization for automatic arrays.
It was OK for the trunk - is it also OK for the 4.6 branch ?
Strictly speaking, it doesn't
The attached patch makes -finit-= generate default
initialization for automatic arrays.
It was OK for the trunk - is it also OK for the 4.6 branch ?
Strictly speaking, it doesn't fix a regression, it is a fix for a
(non-default) debugging option.
2011-12-19 Toon Moene
PR fo
objects who knows this
field better than I do, OK for trunk.
Thanks - I'll wait two days for further comment and then apply.
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moen
On 12/07/2011 07:58 PM, Toon Moene wrote:
On 12/06/2011 08:32 PM, Steve Kargl wrote:
Looks good to me. You can apply it to the 4.6 branch
if you have time.
And then shortly before applying it, I realized that the proper
documentation of the limitations might be dependent on the
-fno
On 12/06/2011 08:32 PM, Steve Kargl wrote:
On Mon, Dec 05, 2011 at 07:21:59PM +0100, Toon Moene wrote:
2011-12-05 Toon Moene
PR/51310
invoke.texi: Itemize the cases for which -finit- doesn't
work.
OK for trunk ? (and perhaps later for the 4.6 branch ?
Looks
And, as indicated, the list might change in the future.
ChangeLog:
2011-12-05 Toon Moene
PR/51310
invoke.texi: Itemize the cases for which -finit- doesn't
work.
OK for trunk ? (and perhaps later for the 4.6 branch ?
--
Toon Moene - e-mail: t...@moene.org -
On 10/31/2011 03:23 PM, Jakub Jelinek wrote:
On Sat, Oct 29, 2011 at 03:53:37PM +0200, Toon Moene wrote:
I wonder whether it will work with the attached Fortran routine - it
sure would mean a boost to the 18%+ heaviest CPU user in our code.
Would be nice to cut down slightly this testcase
133 sldynm_
2.29 14950 phys_
2.19 14950 prevap_
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 | 4 more
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands | 4 44
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http
On 10/26/2011 11:56 PM, Jakub Jelinek wrote:
Hi!
This patch implements gather vectorization with -mavx2, if
dr_may_alias (which apparently doesn't use tbaa :(( ) can figure out
there is no overlap with stores in the loop (if any).
The testcases show what is possible to get vectorized.
I chose t
in later stages of the compiler.
In the days of g77 we had one person who made a program to insert random
one-character changes into valid programs until he hit an ICE.
Of course, that was all automated ... it lead to a *lot* of bug fixes.
--
Toon Moene - e-mail: t...@moene.org - phone: +31 34
why isn't a full
TKR (Type/Kind/Rank) comparison in order ?
[ I might easily be missing something from context here, but TKR is my
initial reaction to these kind of checks :-) ]
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Nethe
an Testing, updated 20110821 at 12:15 UTC ]
(h/t Mark Glisse).
Thanks in advance,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://g
On 07/20/2011 04:34 PM, Toon Moene wrote:
So I changed my "lto" bootstrap script to do the following:
language=fortran
if [ $RANDOM -lt 16384 ]
then
language=ada
fi
...
../gcc/configure \
...
--enable-languages=c++,$language \
Still have to see if this will fit in the 2:20 hour g
fortran
if [ $RANDOM -lt 16384 ]
then
language=ada
fi
...
../gcc/configure \
...
--enable-languages=c++,$language \
Still have to see if this will fit in the 2:20 hour gap between two
weather forecasting runs.
Cheers,
--
Toon Moene - e-mail: t...@moene.o
86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.1 (Debian 4.6.1-1)
toon@super:~$ gnat -v
GNAT 4.6.1
...
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: h
ran, where the programmer isn't even
supposed to know what the value of .FALSE. is, because it is
implementation dependent.
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://
On 05/18/2011 05:41 AM, Gabriel Dos Reis wrote:
On Tue, May 17, 2011 at 2:46 PM, Toon Moene wrote:
On 05/17/2011 08:32 PM, Uros Bizjak wrote:
Tested on x86_64-pc-linux-gnu {, m32} with --enable-build-with-cxx.
Committed to mainline SVN as obvious.
Does that mean that I can now remove
d the intricacies of the
infight^H^H^H^H^H^H differences between the C and C++ type model.
OK: 1/2 :-)
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress o
On 05/17/2011 07:50 PM, Toon Moene wrote:
On 05/14/2011 09:40 PM, Janne Blomqvist wrote:
Hi,
the current version of showing the backtrace is not async-signal-safe
as it uses backtrace_symbols() which, in turn, uses malloc(). The
attached patch changes the backtrace printing functionality to
malloc arena, which just hangs under the current implementation. ]
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org
use I assumed it
would just have copied g77's behavior.
Duh.
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/wik
[ Strong Typing Is For People With Weak Memories ]
The attached patch fixes the C++ (--disable-werror) bootstrap:
2011-05-12 Toon Moene
* objc-next-runtime-abi-02.c (objc_build_internal_classname):
Add const qualifier to constant variable pointer declaration.
Apply as
nable.
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
89 matches
Mail list logo
