e template for every type and export the symbol
void matmul_r4(gfc_array_r4* a, gfc_array_r4* b, gfc_array_r4* c, ...)
{
matmul(a, b, c, ...);
}
// And so on for other types
}
--
Janne Blomqvist
I'm not personally working on
GFortran at this time so somebody else would have to pick it up.
--
Janne Blomqvist
-of discussed this issue back when the Linux kernel dropped
support for i386. See thread starting at
https://gcc.gnu.org/legacy-ml/gcc/2012-12/msg00079.html (a thread
where you participated as well)
--
Janne Blomqvist
ur changes to your
previous commit.
Another option is the interactive rebase (git rebase -i). That allows
you to e.g. "squash" commits, that is, combine two or more commits
into one.
--
Janne Blomqvist
On Thu, Sep 19, 2019 at 5:43 PM Damian Rouson
wrote:
>
>
>
> On Thu, Sep 19, 2019 at 5:04 AM Janne Blomqvist
> wrote:
>>
>>
>> One thing that's unclear to me is how should I actually make my stuff
>> appear in the public repo? Say I want to wor
runk?), then commit and push?
4b) Or do I first rebase my branch on top of the latest master, to
produce a slightly less branchy history?
4c) Or do I (manually?) apply my patch on master, to create a linear history?
4d) Something else entirely?
Thanks,
--
Janne Blomqvist
To be specific: deprecate -traditional-cpp for GCC10, remove in GCC11.
The Fortran frontend uses traditional mode, for reasons I can't recall
at the moment.
--
Janne Blomqvist
first (PDF) search (Blelloch 1999) as an alternative to work
stealing. Here's a presentation about some recent work in this area,
although for Julia and not OpenMP (no idea if PDF would fit with OpenMP at
all): https://www.youtube.com/watch?v=YdiZa0Y3F3c
--
Janne Blomqvist
)
> for the function that spawns new threads or awakes the ones waiting for
> work, or gomp_thread_start in the same file for the function actually run by
> the libgomp library created threads.
>
> > I can't find the entry point of the worker threads from the event tracing
&g
. Particularly
> > those targeting enterprise users. And those are glacially slow.
> >
> > As an aside, it was not being able to build the RTEMS documentation that
> > pushed me off RHEL 6 as my primary personal environment last year. I
> wanted
> > to be using the oldest distribution I thought was in use in our
> community.
>
> doesn't RHEL 6 has overlays for that very reason to install a newer
> Python3?
>
EPEL provides python 3.4 for RHEL6.
(EPEL is a non-official add-on repository, but I suspect the vast majority
who aren't running some single-task server have it enabled)
Don't know if there's something equivalent for SLES.
> Please don't start with Python2 anymore. It's discontinued in less than two
> years and then you'll have distributions not having Python2 anymore.
+1
--
Janne Blomqvist
hat you contact equation.com for help with your issue with
their product.
(Added the fortran list to CC, in case other gfortran developers have
better up to date information about the equation.com builds)
--
Janne Blomqvist
e effects also
> Fortran code which calls C functions?
>
>
If it's a "normal" C function with NULL-terminated strings, then no. If
it's a C function which is designed to follow the Fortran procedure ABI
(where strings are passed as a pointer + a hidden length argument), then
yes.
--
Janne Blomqvist
ivation cases, good/conservative cost model.
>
> Yes, I guess before distribution you want to do maximum fusion and then
> apply (re-)distribution on the fused loop. The cost model should be the
> very same for distribution/fusion.
>
> Richard.
>
I recall Fujitsu bragging that the key to them getting good application
performance (read: outside linpack) on the K computer is extensive use of
loop FISSION + software pipelining. Though I guess sw-pipelining is only
useful if you have lots of architectural registers, which disqualifies
x86-64..
--
Janne Blomqvist
he default.
3) Warning for array that is large enough to be allocated on the heap.
4) Run-time error for automatic heap allocation.
Longer term, if somebody has the energy to deal with the (potential)
portability issues, Nicks secondary split stack approach could be good.
--
Janne Blomqvist
n(). Instead it generates a "call" to __builtin_sin(). And
similarly for other libm functions that have gcc builtins. The middle-end
optimizers are then free to do whatever optimizations they like on that
__builtin_sin call, such as constant folding, and at least as far as the
fortran frontend is concerned, vectorizing if -mveclibabi= or such is in
effect.
--
Janne Blomqvist
46018/sse-instructions-which-cpus-can-do-atomic-16b-memory-operations/7647825
for more discussion and a testcase.
--
Janne Blomqvist
the email message one
sends to gcc-patches when introducing a patch (in fact, if one uses
git format-patch + git send-email this kind of workflow is supported
out-of-the-box). I find that a lot more useful than a screenful of
"Likewise". YMMV.
--
Janne Blomqvist
https://gcc.gnu.org/ml/gcc-patches/2017-11/msg00575.html committed as
r254526.
But yeah, as Richard said, Fortran has logical types of different
sizes, you need to convert one to the other when comparing.
--
Janne Blomqvist
turns the
b(j)**c(j)
expression in your example into a "call" to __builtin_powf() (check
with -fdump-tree-original), and similarly for other math intrinsics
that have corresponding builtins. Ideally the middle-end optimizers
should to be able to turn that into calls to the appropriate vector
math library when -mveclibabi= is in effect.
--
Janne Blomqvist
27;d welcome
> discussion
> and other proposals for similar improvements.
What about the default behavior if no options are given? I think a
more reasonable default would be something roughly like
-O2 -Wall
or if debuggability is considered more important that speed & size, maybe
-Og -g -Wall
--
Janne Blomqvist
+*lib: %{static-libgfortran:-Bstatic} -lquadmath
> %{static-libgfortran:-Bdynamic} -lm %(libgcc) %(liborig)
On a semi-related note, it seems the recently released glibc 2.26
contains quad math functions. Does that mean we should change to use
those in preference to libquadmath when available? I suppose
libquadmath cannot be deprecated either, since it's still needed for
non-glibc targets.
Or to put it another way, what's the point of quad math support in
glibc, since libquadmath already exists?
--
Janne Blomqvist
server protocol", see
http://langserver.org/ . Though AFAIK nobody is working on GCC
integration so far.
--
Janne Blomqvist
Or while we're at it, why not drop i486 too at the same time, unless
there are, well, users? That would additionally guarantee availability
of x87 (should we be happy or cry?), cpuid, cmpxchg8b, rdtsc.
--
Janne Blomqvist
t
> support for pre-ANSI C was removed from the compiler proper at least a dozen
> years ago.
IIRC the Fortran frontend use CPP in traditional mode.
--
Janne Blomqvist
uspect.
>
> Do you think this is worth pursuing? If so, how could/should this
> be implemented= Does anybody do this kind of thing in gcc yet?
Check out https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html
, in particular the target_clones attribute.
Though I suspect you will have a hard time with all kinds of more or
less obscure targets.. Maybe just do it for x86-64?
--
Janne Blomqvist
heir past contributions, which we're
of course grateful for). Just to point out that we're not dependent on
maintainers with super-powers.
- a "2-week rule"; if a patch by a reviewer goes unreviewed for 2
weeks, the reviewer can commit it without review. A bit like your
option a).
The 2-week rule, in particular, came about due to frustration with
lack of reviews.
--
Janne Blomqvist
work than 1)? If you don't want to keep
track of a count, just generate a random number between 10 and 2^31,
and use that as the unit number? Should at least make conflicts rare.
>
> Any comments are welcome.
>
> Thanks
> Yvan
--
Janne Blomqvist
optimization whereby the
frontend uses __builtin_powi, but that's only for REAL(kind=whatever
corresponds to C float/double/long double) ** INT(kind=C_INT), whereas
the issue here is apparently int**int, for which there is no
equivalent builtin.
--
Janne Blomqvist
't know why this is not working. Everything looks fine in the
> a.out that you sent. Unfortunately, I think you sent the one built
> without libbacktrace. Can you send me the one built with libbacktrace?
> Thanks.
>
> Ian
You might also take a look at the patch posted to PR 54572 which was
my attempt to use libbacktrace a few years ago. While I got symbolic
backtraces working somewhat, unfortunately I never got it to work
completely since it crashed somewhere in libbacktrace in some cases,
but maybe whatever bugs caused that have been fixed in the meantime...
--
Janne Blomqvist
bvious fix
for a mingw-specific(?) segfault in libgfortran.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66861
https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01201.html
You set the milestone on the PR to 5.2 earlier today, but I'm not sure
if that constitutes an Ok to commit to the branch, hence I'm asking
explicitly.
--
Janne Blomqvist
whole testcase.
Don't know if this is the correct way to do it, but it seems to work.
--
Janne Blomqvist
On Fri, Oct 31, 2014 at 1:20 PM, N.M. Maclaren wrote:
> 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 ex
f the dejagnu environment.
>
> Within gfortran.dg we place a { dg-run } program that invokes the test
> scripts and checks the results.
>
> Is this doable? Anyone have any better ideas?
>
> Regards,
>
> Jerry
--
Janne Blomqvist
ncreased with fcntl(fd, F_SETPIPE_SZ, ...), perhaps worth
trying to see if it makes any difference?).
Still, it seems to me that making -pipe the default would make sense,
if the tradeoff appears to be a small loss in case when /tmp is a
tmpfs vs. a much larger gain when /tmp is a normal fs.
--
Janne Blomqvist
sure there are any interesting optimizations that would be
dependent on loosening -ffast-math further?
(One thing I wish wouldn't be included in -ffast-math is
-fcx-limited-range; the naive complex division algorithm can easily
lead to comically poor results.)
--
Janne Blomqvist
ay's GCC on today's
hardware.
Hope this helps,
--
Janne Blomqvist
deep buffers impractical.
And, IIRC scatter/gather instructions are featured as of some
recent-ish AVX-something version. That being said, maybe current
cache-based memory subsystems are different enough from the vector
supercomputers of yore that the above doesn't hold to the same extent
anymore..
--
Janne Blomqvist
FWIW, glibc hasn't really supported i386 for several years (at least with
>>the Linux kernel; I don't know about Hurd), since NPTL requires atomic
>>operations that i386 doesn't have, so fails to link unless you use
>>-march=i486 or later.
>>
>>--
>>Joseph S. Myers
>>jos...@codesourcery.com
--
Janne Blomqvist
p (SoC) family was originally designed to
provide product migration path to the existing
user of the DMP M6117D SoC, a 40 MHz x86 SoC introduced to the market
in the early 1990s that reached end-of-life
in 2007."
--
Janne Blomqvist
support has been dropped from the netbsd kernel, although at
least back in 2009 when that mail was written they still targeted
their toolchain for i386.
--
Janne Blomqvist
e embedded folk often end up with precisely this dichotomy :-)
> But if no sign of 386 embedded chips, then reasonable to deprecate
> I agree.
According to
http://web.archive.org/web/20061009060120/http://developer.intel.com/design/pcn/Processors/D0106013.pdf
Intel stopped producing
sg3.html).
So yes, it's a known problem, but so far nobody has found the time to
fix it.
--
Janne Blomqvist
improvement, in particular since
addr2line doesn't work on OSX, and all that piping stuff doesn't work
on Windows.
--
Janne Blomqvist
9/C++98 and older
POSIX standards would probably still be desirable, though.
--
Janne Blomqvist
--
Janne Blomqvist
On Fri, Apr 15, 2011 at 22:19, N.M. Maclaren wrote:
> 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
>> itsel
On Fri, Apr 15, 2011 at 15:04, Tobias Burnus wrote:
> On 04/15/2011 11:52 AM, Janne Blomqvist wrote:
>>
>> Q1: Is __sync_synchronize() sufficient?
>> I don't think this is correct. __sync_synchronize() just issues a
>> hardware memory fence instruction.That is,
he
fence instruction*. There is no synchronization with other
processors. SYNC ALL, OTOH is a full barrier; the implementation must
be something like a counter that every co-image increments atomically,
and then waits (blocking or spinning) until the counter equals the
number of co-images.
> Q2: Can this be optimized in some way?
Probably not. For general issues with the shared-memory model, perhaps
shared memory Co-arrays can piggyback on the work being done for the
C++0x memory model, see
http://gcc.gnu.org/wiki/Atomic/GCCMM
Hans Boehm maintains a collection of links to various papers on the topic at
http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/
--
Janne Blomqvist
On Fri, Apr 15, 2011 at 10:54, Jim Meyering wrote:
> Janne Blomqvist wrote:
>
>> On Thu, Mar 24, 2011 at 18:51, Jim Meyering wrote:
>>> Janne Blomqvist wrote:
>>>> On Tue, Mar 8, 2011 at 19:53, Jim Meyering wrote:
>>>>> Relative to v2, I'
, if so
maybe the interested party could step up to the plate and contribute
some configure checks or somesuch so that we could fall back to the
old ftruncate or chsize functions?
Ok for trunk?
2009-12-01 Janne Blomqvist
PR libfortran/40812
* libgfortran.h: typedef gfc_
is at r147078
>
> Suggestions anyone?
FWIW, there was recently some mention on gcc@ that the server now runs
svn 1.5 which supposedly has slightly less braindamaged merging,
making svnmerge.py superfluous. See http://gcc.gnu.org/wiki/SvnBranch
--
Janne Blomqvist
gt;>
>> Ok if there are no objections within the week.
>>
>> Thanks,
>> Richard.
>
> Great, thanks. Can I get an explicit ack from a fortran maintainer as well?
Ok.
--
Janne Blomqvist
Hello all,
apologies for causing a bootstrap failure when building libobjc due to
my patch for PR 35063 (r132800). As of r132802, I believe this issue
is now fixed. Big thanks to Jerry DeLisle for helping out with the
fix.
--
Janne Blomqvist
to
constant fold cpow* calls.
--
Janne Blomqvist
Janne Blomqvist wrote:
> Hello,
>
> the attached patch fixes PR:s c/35162 (just a documentation fix) and
> fortran/29549.
Uh, sorry, wrong list (I intended to send to gcc-patches and fortran).
--
Janne Blomqvist
signature.asc
Description: OpenPGP digital signature
libgfortran use that switch, gaining a factor of 4
speedup on complex matrix multplication.
Regtested on i686-pc-linux-gnu, doc changes tested with 'make info' and
'make pdf'. Ok for trunk?
--
Janne Blomqvist
gcc ChangeLog:
2008-02-19 Janne Blomqvist <[EMAIL PROTECTE
is written in perl (not my
favourite language, but...) so it should work on the current
webserver, is installable via CPAN, and contains a command-line
utility that can be used to generate an entire site in one go, see
http://www.template-toolkit.org/docs/tutorial/Web.html
--
Janne Blomqvist
ular value in pushing these
things to the middle-end, if nobody else is going to be interested in
maintaining them anyway.
--
Janne Blomqvist
, I think finding the
offending commit is your only hope if you want this fixed in a timely
manner.
--
Janne Blomqvist
H.J. Lu wrote:
On Sun, Jul 15, 2007 at 10:17:56AM +0300, Janne Blomqvist wrote:
On 7/14/07, H.J. Lu <[EMAIL PROTECTED]> wrote:
On Sat, Jul 14, 2007 at 06:03:33PM +0200, Tobias Schlüter wrote:
H.J. Lu wrote:
It looks like gcc assumes a functon marked with DECL_IS_MALLOC won'
the frontend be fixed in some other way so that we can still keep
internal_realloc marked with DECL_IS_MALLOC.
--
Janne Blomqvist
rk with limited applicability, and perhaps it's not really
needed, provided we do (2) well (allowing the middle-end to reorder
loops if needed)?
--
Janne Blomqvist
esult in supporting all
type kinds for many arguments to some intrinsics. Of course, for some
performance sensitive intrinsics we still want the library to have
specific versions for different type kinds.
--
Janne Blomqvist
Geert Bosch wrote:
On Apr 27, 2007, at 06:12, Janne Blomqvist wrote:
I agree it can be an issue, but OTOH people who care about precision
probably 1. avoid -ffast-math 2. use double precision (where these
reciprocal instrs are not available). Intel calls it -no-prec-div, but
it's enable
Richard Guenther wrote:
See also http://www.suse.de/~gcctest/c++bench/polyhedron/analysis.html
(same conclusion for gas_dyn).
Thanks, I seem to have completely missed that page (though I was aware
of your polyhedron tester).
>On 4/27/07, Janne Blomqvist <[EMAIL PROTECTED]> wrot
who can concievably help.
> That said, I would get on
> with it if I were you.
Again, agreed. Perhaps we can lure Richard into becoming a gfortran
developer before he notices it. ;-)
--
Janne Blomqvist
pgpl5hIAKKS5u.pgp
Description: PGP signature
pfr_subnormalize function.
> This would allow me to replace a homegrown hack that
> Tobi and I developed for dealing with subnormal numbers.
>
> For more info on mpfr versions, check
> http://www.mpfr.org/download.html
Would it be possible to replace gmp with mpfr entirely? Or do we use
gmp functionality that isn't found in mpfr?
--
Janne Blomqvist
66 matches
Mail list logo
