; Is there any place where one can contribute procedures to the library?
Ask on the gcc general mailing list: gcc@gcc.gnu.org
FX
e to
memory alignment, and you could use aligned_alloc() instead?
FX
some other stuff
too (PR 36757).
I don’t know where to start and how to achieve that, though. Could someone who
knows this middle-end FP stuff help?
Thanks,
FX
EXT_LIB_BUILTIN(BUILT_IN_SIGNBITD32, "signbitd32", BT_FN_INT_DFLOAT32,
ATTR_CONST_NOTHROW_LEAF_LIST)
But does that mean the middle-end will handle it completely?
FX
cluding
the whole tree if need be).
Thanks for helping with this,
FX
ct solution for libgfortran, given it is already used in the compiler
itself (and thus well-maintained).
Obviously, the major target for which support is missing is Darwin (Mach-O
object files). I have looked at implementing it, but it is well beyond my
simple understanding of object files’ inner working :(
FX
0xf75e6aa7 _gfortrani_sys_abort
../../../../trunk/libgfortran/runtime/error.c:176
#2 0xf769a7a7 _gfortran_abort
../../../../trunk/libgfortran/intrinsics/abort.c:33
#3 0x80486e4 bar
/home/fx/gcc/irun/a.f90:9
#4 0x8048706 foo
/home/fx/gcc/irun/a.f90:5
#5 0x80486f2 test
/home/
> Patch tested and committed with this ChangeLog entry.
>
> 2015-08-13 Ian Lance Taylor
>
> * dwarf.c (read_function_entry): Add vec_inlined parameter.
> Change all callers.
Thanks, this is great! I am going to submit the libgfortran patch to use
libbacktrace today.
Cheers,
FX
iltins.def, add some aborts() or sorry() in
gcc/builtins.c if we can’t expand (which should never happen)?
Thanks in advance for your help,
FX
signbit.diff
Description: Binary data
UWIN support was apparently removed from GCC in 2008. Yet some traces can still
be found in gcc/config.* files.
Attached patch would remove them. OK to commit?
FX
PS: gcc/config.host and gcc/config.build include some other such targets…
without checking them all, I think the following could
are not supported.)
FX
for me be changed from:
fxcoudert = François-Xavier Coudert
(which has been inactive for many years now) to
fxcoudert = François-Xavier Coudert
Thanks,
FX
mits to a very small subset of files
(gcc/fortran/ChangeLog*), with “svn log”, I get the list of committers (Unix
usernames) below. Many of them aren’t in the map at
http://thyrsus.com/gitweb/?p=gcc-conversion.git;a=blob_plain;f=gcc.map;hb=HEAD
Out of the 10 first usernames, 3 are not (ak, aldot, b
more, which we’ll miss if we have to rely on manual modifications of that list…
How was the map generated?
FX
PS: I found one username that first escaped my scripts because it contained a
period, so I am raising a flag here, so the same doesn’t happen to you: m.hayes
(commit 34779).
=/Users/fx/devel/gcc/deps-static/x86_64
--enable-languages=c,c++,fortran,objc,obj-c++ --build=x86_64-apple-darwin15
Thanks,
FX
ing libgfortran has:
fincludedir =
$(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/finclude
notice the extra $(MULTISUBDIR).
So this is apparently not a new bug
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60670), but it probably should be
fixed.
FX
a.f90 -m32
a.f90:1:6:
use omp_lib
1
Fatal Error: Can't open module file ‘omp_lib.mod’ for reading at (1): No such
file or directory
compilation terminated.
Bootstrapped and tested on x86_64-apple-darwin15. OK to commit?
FX
2016-05-03 Francois-Xavier Coudert
PR li
ping
> Le 3 mai 2016 à 23:25, FX a écrit :
>
> The attached patch allows libgomp to install its Fortran modules in the
> correct multilib-aware directories, just like libgfortran does.
> Without it, multilib Fortran OpenMP code using the modules fails to compile
> because t
d and tested on x86_64-apple-darwin15. OK to commit?
FX
2016-05-03 Francois-Xavier Coudert
PR libgomp/60670
* Makefile.am: Make fincludedir multilib-aware.
* Makefile.in: Regenerate.
Index: libgomp/Makefi
its .mod files into the
multilib-specific finclude directory, just like libgfortran does.
FX
> How do I initialize a __complex128 variable? I found no documentation.
$ cat a.c
#include
#include
#include
int main(void)
{
char s1[50], s2[50];
const __complex128 z = -0.3Q + 0.1Qj;
quadmath_snprintf (s1, sizeof(s1), "%20Qe", __real__ z);
quadmath_snprintf (s2, sizeof(s2), "%20Qe"
s was done in GMP. This
code should be cleaned up, and it will fix bootstrap on clang-based target
coincidentally, without adding another kludge.
FX
cgi?id=61315).
Since my PR has been closed twice by Andrew Pinski (“it’s clang’s fault, bouh
ouh”), I’d ask the maintainers to step in. Can we please provide a GCC that
works for the default darwin setup? Or at least drop darwin as secondary target
and document the failure?
FX
> Please post a patch.
How about that? I’m not doing a full clean-up of the longlong.h code outside
the area affected. This restores bootstrap on darwin, confirming that both the
system compiler and later-stage-gcc accepts it.
FX
longlong.diff
Description: Binary data
longlong.Change
o do the tedious work of proposing
a full patch, but I won’t be able to test it (and I didn’t want to do it if it
had no chance of being accepted).
Thanks,
FX
longlong.ChangeLog
Description: Binary data
longlong.ChangeLog
Description: Binary data
o
these other archs is suitable, I’m willing to do the tedious work of proposing
a full patch, but I won’t be able to test it (and I didn’t want to do it if it
had no chance of being accepted).
Thanks,
FX
longlong.diff
Description: Binary data
longlong.ChangeLog
Description: Binary data
ef/gnu/coreutils/src/longlong.h).
FX
d on x86_64-apple-darwin due to error below. Richard, could
this be due to your revision 211013?
FX
../../trunk/gcc/rtl.c: In function ‘void cwi_output_hex(FILE*, const_rtx)’:
../../trunk/gcc/rtl.c:239:62: error: format ‘%llx’ expects argument of type
‘long long unsigned int’, but argument 3 h
> I suppose casting the result of CWI_ELT () to uint64_t fixes this. Do
> similar errors happen elsewhere?
I don’t think you can cast to uint64_t, as host wide int might be some other
type, no?
There are others:
../../trunk/gcc/print-rtl.c: In function ‘void print_rtx(const_rtx)’:
../../trunk/
bootstrap on x86_64-apple-darwin13.
Thanks!
FX
patch
Description: application/applefile
CL
Description: Binary data
his is news to me. The
syntax is not immediately clear, and neither a Google search nor a grep of the
trunk’s numerous .texi files reveals any information. I’m creating new decls,
what I am to do with it?
FX
Top-level configure has two quadmath-related options: --disable-libquadmath and
--disable-libquadmath-support . The first disables the building of libquadmath
itself, the second disables quadmath support in the Fortran front-end. They are
currently independent, but it would make a lot of sense f
y vs.
fpresetsticky, for example) and I could only test on a limited set. Hopefully,
the list shouldn’t be that long.
Cheers,
FX
is none, would it be okay to add a new bool field to the structure, named
“ieee” or “ieee_format”, to discriminate?
Thanks,
FX
[1] The Fortran standard defines such as types as having an "IEC 60559:1989
floating-point format”. Decimal formats are out, as they are unsupported in
gfortran,
at
> config/i386/i386.md:2071
Google and bugzilla search don’t find anything particularly recent like that,
but the scale of it is weird. I have isolated a very small reproducer, attached
(gives the above ICE with no compile options).
Has anyone seen this on another platform? Is it known?
In fact, after looking at the latest gcc-patches messages, I think it may be
due to this commit: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01107.html
(based purely on the fact that the unrecognized insn is a call, and the patch
deals with CALL_EXPR).
FX
> I am testing trunk on darwi
, cause it’s apparently not committed yet (at least, not in
rev. 215234 which is the one failing for me).
But now, I’ve found it is PR 61387
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61387), already known.
FX
decl should work, would someone
have a hint of how to fix this?
Thanks,
FX
PS: the attached patch emits isfinite instead of isnan to test the built-in
changes with minimal. With that patch, the Fortran source attached triggers the
ICE above.
problem.diff
Description: Binary data
b.f90
bit is not type generic, is there any
reason for it not to be? Is there any reason for it not to be? I ask for two
reasons: 1. it would make my life easier, and 2. it’s generated in the folding
of BUILT_IN_ISINF_SIGN, which is weird because the later is type generic.
Thanks again,
FX
get a minute to look at the
dumps/assembly.
FX
a.f90
Description: Binary data
a.f90.003t.original
Description: Binary data
a.f90.174t.optimized
Description: Binary data
a.s
Description: Binary data
a.s.floatstore
Description: Binary data
so are not
generic, they’re in c-family, which probably means I can’t use them.
Any idea how I could get to the result I want? (setting options from the
Fortran front-end)
Thanks,
FX
Index: trans-decl.c
===
--- trans-decl.c
g_finite_math_only (0x1)
> 71a68
> > flag_signed_zeros (0x1)
> 78a76
> > flag_trapping_math (0x1)
> 113d110
> < flag_unsafe_math_optimizations (0x1)
Is that a bug in optimization handling, or am I missing something?
FX
fault_options_optimization() has
overwritten the value of the flags handled in set_fast_math_flags():
flag_finite_math_only, flag_signed_zeros, flag_trapping_math and
flag_unsafe_math_optimizations.
I’m CC’ing the maintainers who added the optimize attribute in the first place,
as they might have an idea how to fix this. This is way beyond my league!
Thanks Steven for your help!
FX
n idea how to fix this. This is way beyond my
> league!
>
>
> Thanks Steven for your help!
> FX
> The __builtin_remainderf on x86 expands to x87 fprem1 instruction [1].
> According to the table in [1], +inf is not handled, and generates
> division-by-zero exception.
>
> IMO, we have to add "&& flag_finite_math_only" to expander enable
> condition of remainder{sf,df,xf}3 expanders in i386.md
missed optimizations in routines using the
IEEE modules, so at least it’s not wrong code for us :)
Cheers,
FX
:
2005-01-19 Neil Booth
* MAINTAINERS: Remove self as cpplib maintainer.
I suppose it would make sense to remove it “option handling” maintainer.
FX
directly from the system.h header. I do not know
enough about the state of our mixed C/C++ build to understand if that would
work or create chaos, so I’m dropping a line here so that “awareness of this
general issue is raised”, as they say rather pompously :)
Cheers,
FX
PS: Ilya, I tried to CC you
our configure’s.
How is libtool handled in GCC? Do we import from upstream, or merge the changes
that we need? It looks like it’s done manually and selectively, but I’d like
confirmation of that.
Thanks,
FX
t, too.
Thanks for the feedback. On the src repository, is it documented somewhere how
to change it? (I have probably done it in the past, but don’t remember)
FX
) but not with
$(POSTSTAGE1_HOST_EXPORTS).
However, I do not know how to fix that. As I understand it, this part of the
Makefile is generated from the information in the toplevel Makefile.def, but I
do not know how to enter that information there. Could someone help?
Thanks,
FX
> -L/opt/gcc/p_build/x86_64-apple-darwin14.0.0/libstdc++-v3/src/.libs
> Why aren't they sufficient for MacOS linker to find libstdc++.a?
Because it’s gonna also use -static-libstdc++, which relies on spec
substitution, for which -L is not enough.
FX
bootstrap with clang as system compiler).
OK to commit?
FX
PS: HJ, the reason only don’t see this on Linux is that only Darwin (AFAIK)
plays spec tricks with static-libstdc++ (in gcc/config/darwin.h)
libcc1.ChangeLog
Description: Binary data
libcc1.diff
Description: Binary data
but their
> webpage only mentions read-only CVS.
>
> Could someone do it for me?
>
> Thanks,
> FX
>
>
>
>
> commit 8d25b840ce688bfa601b0ad5f53c4185627c8975
> Author: FX
> Date: Wed Nov 12 13:26:06 2014 +0100
>
>* libtool.m4: Fix gl
> Done:
> https://sourceware.org/ml/binutils/2014-11/msg00318.html
Thanks!
is in the
> toplevel configure.ac, where we already pass down the respective -L options.
> Indeed, the attached patch restores bootstrap on x86_64-apple-darwin14 with
> gcc as system compiler (and doesn’t break the bootstrap with clang as system
> compiler).
>
> OK to commi
> While in my testing, 64-bit Mac OS X 10.10.1 (x86_64-apple-darwin14.0.0)
> now bootstraps, but 32-bit (i386-apple-darwin14.0.0) does not:
Is it due to my patch, or pre-existing bootstrap failure?
How do you configure this 32-bit compiler? target/build/host/CFLAGS/CXXFLAGS/etc
FX
config/mh-darwin says that -mdynamic-no-pic is there because it “speeds
compiles by 3-5%”. I don’t think we care about speed when the bootstrap fails,
so can we remove it altogether?
FX
darwin.diff
Description: Binary data
> Can you try adding it as
>
> T_CFLAGS += -mdynamic-no-pic
>
> in gcc/config/t-tarwin instead?
Nope, doing so fails to link libgcc_s.dylib:
/Users/fx/devel/gcc/i/./gcc/xgcc -B/Users/fx/devel/gcc/i/./gcc/
-B/Users/fx/devel/gcc/i2/i386-apple-darwin14.0.0/bin/
-B/Users/fx/de
schedule it for:
- daily bootstrap + regtest of trunk
- weekly bootstrap of latest release branch (currently 4.9)
If you have other ideas, I’m open to suggestions.
FX
Yes, the ubsan issues are about setting DYLD_LIBRARY_PATH:
dyld: Symbol not found: __ZTIN10__cxxabiv117__class_type_infoE
Referenced from:
/Users/fx/autobuilds/builds/gcc-trunk-218778/x86_64-apple-darwin14.0.0/i386/libsanitizer/ubsan/.libs/libubsan.0.dylib
Expected in: /usr/lib/libstdc++.6
results/2014-12/msg02096.html.
If Mike thinks it’s a good idea, I’ll do it. I’ve tested 4.8 with it multiple
times, and it works well.
FX
> Ok.
Committed to the 4.8 branch as rev. 218873
FX
front-ends
emitted. I have read the release notes and can’t find anything related.
Any advice?
Thanks,
FX
ary under another name?
Thanks,
FX
32-bit libgcc_s_sjlj-1.dll, it fails because it is
searching for 32-bit libmingwthrd.a in the 64-bit library directory:
/Users/fx/devel/mingw-w64/cross/x86_64-w64-mingw32/bin/ld: skipping
incompatible
/Users/fx/devel/mingw-w64/cross/x86_64-w64-mingw32/lib/libmingwthrd.a when
searching for
aries are in ${prefix}/${target}/lib.
Anyone knows how we can make toplevel configure aware of the multilib nature of
the system?
Cheers,
FX
PS: The gcc specs know how to deal with that, as we have in the target
configuration file:
$ cat gcc/config/i386/t-mingw-w64
MULTILIB_OPTIONS = m6
April 2015
(https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01438.html), for the GCC 5
branch.
Do GCC 5, GCC 6 and current trunk support powerpc-apple-darwin? The target code
is still there, apparently, and the compiler is not on the “obsolete” list.
FX
implementation of coarrays into
gfortran, or coexistence as a separate package (as is currently the case, for
example in Mac Homebrew, where it ships as a separate — but compatible —
package)?
FX
;
> We’re all in agreement here so hopefully Jerry’s submission will be
> approved.
Currently, I don’t think we can integrate it in this form, due to build
requirements. Maybe the threshold is lower for integrating it into GCC’s
contrib scripts directory?
FX
the reverse (integrate
opencoarrays build into gcc).
In any case, thanks for exploring it. I really think we should find a way to
integrated tightly the coarray features into gfortran, but we need to find the
right technical solution.
FX
omplex piece of code, which runs on tons of
different platforms, and so is very conservative about its requirements.
FX
e opinion of other maintainers would be good
to hear.
FX
build system.
Also, there is the question of bootstrap: GCC can be bootstrapped on a compiler
with a non-GCC compiler, but on such system libgfortran we be built as part of
the compiler, while a GCC-adapted MPI library may not yet be available (because
the compiler has not yet finished building).
FX
> We choose mpich as a default only because it is very stable.
Why are why tying ourselves to one MPI implementation?
FX
Hi,
I’m suggesting we apply the following patch to provide links to macOS package
managers, where users can download binaries for GCC on macOS. I have included
the two major ones, Homebrew and MacPorts.
FX
macos.diff
Description: Binary data
GCC 6, and I’m
considering simply dropping support for it when GCC 8 comes. Is there a chance
I can this issue being fixed, or should I simply drop it?
Cheers,
FX
x, if you want. Let me know off-list
what you need.
FX
However, the fact should be documented on the installation notes
(http://gcc.gnu.org/install/specific.html#x-x-cygwin) and probably on the
release notes as well, with something like "The GCC 4.6 series requires Cygwin
x.y.z or later".
FX
t;%lu ", sizeof (long long int));
> printf ("%lu\n", sizeof (__int128));
> }
gives : 8 4 8 8 16
> Is __builtin_clzll available on all platforms?
Yes, we emit calls to this built-in unconditionally in the Fortran front-end,
and it has caused no trouble.
FX
tion page at
http://gcc.gnu.org/install/specific.html#x-x-cygwin
Possibly one of the target maintainers might want to update that?
FX
ntion).
Regards,
FX
> Francois,
>
> I have a question about the GCC Quad-Precision Math Library.
>
> Can I use this library with a regular ANSI-C compiler?
>
> I ask this question because I see in the code (power function)
> that you multiply two 128-bit qua
> The following languages will be built: c,c++,fortran
Thanks!
FX
The merge breaks bootstrap in 3 different ways (at least) on x86_64-darwin11:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51031
FX
it, but I've not been
able to get any luck at all. I hope maybe a dejagnu expert could point
me in the right direction! (is it possible, what do I put in the
wine.exp, where do I put this file and how to I get it to be called?)
Many thanks in advance,
FX
Filed as PR 41245.
FX
n math lib
-- there is a GNU Fortran mailing-list where Fortran-related issues
are welcome
Regards,
FX
ly sure. Could someone
confirm the two are equivalent?
Thanks,
FX
PS: the patch is:
> Index: gcc/config/i386/i386.h
> ===
> --- gcc/config/i386/i386.h(revision 155505)
> +++ gcc/config/i386/i386.h(w
jmpfuncs
Hope this can be fixed quickly, as it seriously hamper other regtesting.
FX
ortran/Makefile.am, so I
reverted to the simpler "../libiberty".
Thanks for your help,
FX
PS: the current draft of the complete patch, if you are interested in
it, is attached (it was put together by Tobias Burnus)
memleak2.diff
Description: Binary data
PPS, to Dominique: this is the promised fix for Darwin :)
roval
to distribute them as GPL + exception? We'd like to be able to use
them in the GNU Fortran runtime library.
Thanks for your explanations,
FX
ey have already made that choice, so we should
focus on talking about how to work around the current licence issue.
FX
type_node));
because identifier_global_value (char16_type_node) is NULL. The patch
I use is attached. Joseph, could you help us to proceed further?
Thanks,
FX
diff -pur trunk.unmodified/gcc/config/darwin.h trunk/gcc/config/darwin.h
--- trunk.unmodified/gcc/config/darwin.h 2009-04-03 10:48:59.
uot; is. So we have to write
in our target macros the following form: "(short|long|long long)
unsigned int". I don't understand why, but it appears to work :)
FX
ch is of type "long long", while
intptr_t is still "long".
Is this a bug in darwin's headers?
FX
ixincludes.
Thanks to anyone who can help,
FX
darwin-stdint.diff
Description: Binary data
headers
need fixing (I'm particularly worried about int_fast8_t, which is
"char" rather than "signed char", and I suspect this could spell
trouble).
I hope this can help,
FX
mingw-stdint.diff
Description: Binary data
confirm
that tests gcc.dg/c99-stdint-*.c do not fail.
For more information about why this is necessary, see http://gcc.gnu.org/ml/gcc/2009-04/msg00000.html
.
FX
irix-stdint.diff
Description: Binary data
Hi Alison,
This issue is not specific to Fortran, but it's specific to Darwin
(you say that "the large object files have been observed on many other
platforms", but could you give a list of such platforms?):
$ cat a.c
int x[999] = { 0 };
$ gcc -c a.c && ls -
Thanks Kaveh for taking care of this. The Fortran front-end will
really benefit from the use of MPC. Regarding your options, #1 seems
the most reasonable to me; I'm forwarding to the Fortran list to hear
to opinion of Fortran maintainers.
FX
1 - 100 of 305 matches
Mail list logo
