ml
For 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 poi
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: tadd_si
FAIL
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
values ...
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
s 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 Moene - e-mail: t...@moe
gh 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-patches wrote
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
2,6 +32,7 @@ private:
void print_irange_bound (const wide_int , 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 ) const;
pretty_printer *pp;
};
(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
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-mail: t...@moene.org - phone
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
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
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
nd 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
a 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
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
,
--
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
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://moene.org
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
all
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: http://moene
).
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
ining 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/~toon
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 <t...@moene.org>
* doc/invoke.texi
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 <t...@moen
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: +31 346
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, 3738 XG Ma
ither.
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 the
clarity.
Kind regards,
--
Toon Moene -
ith
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
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: http
Compiler writers on the committee tell me 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
Saturnu
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
will be *a lot of work*, because I have to build 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 -
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: +31
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
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
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://moene.org/~toon/; weather: http://moene.org
passed the following (attached) interpretation on submodules
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
--
+
+
+!-- .. --
+h2 id=languagesNew Languages and Language specific improvements/h2
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
(.., 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
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
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
Saturnushof 14, 3738
[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...@moene.org - phone
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://moene.org
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 patch
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: +31
/msg02749.html
--
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
/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
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
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 silicon.
--
Toon
of a 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
:
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: t
: 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
Saturnushof 14
in a (temporary) consecutive buffer, then load it
into a vector register ...
--
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
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
?
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://gcc.gnu.org/wiki
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-type=constant generate default
initialization for automatic arrays.
It was OK for the trunk - is it also OK for the 4.6 branch ?
Strictly speaking
The attached patch makes -finit-type=constant 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 t
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://moene.org
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 Moenet...@moene.org
PR/51310
invoke.texi: Itemize the cases for which -finit-type doesn't
work.
OK for trunk ? (and perhaps later for the 4.6
And, as indicated, the list might change in the future.
ChangeLog:
2011-12-05 Toon Moene t...@moene.org
PR/51310
invoke.texi: Itemize the cases for which -finit-type doesn't
work.
OK for trunk ? (and perhaps later for the 4.6 branch ?
--
Toon Moene - e-mail: t
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
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
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://gcc.gnu.org/wiki/GFortran#news
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 346 214290
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 Netherlands
, 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://gcc.gnu.org
=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
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 gap between two
--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: http://moene.org
, that still wouldn't make it possible to implement C++
solutions for C hacks because the --disable-build-with-cxx crowd would
cry foul over 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
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://moene.org/~hirlam/
Progress of GNU
of the
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
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
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 of GNU
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/wiki/GFortran
[ Strong Typing Is For People With Weak Memories ]
The attached patch fixes the C++ (--disable-werror) bootstrap:
2011-05-12 Toon Moene t...@moene.org
* objc-next-runtime-abi-02.c (objc_build_internal_classname):
Add const qualifier to constant variable pointer declaration
84 matches
Mail list logo
