g95 sets DECL_COMMON on these variable decls (only for Darwin
targets). This seems like a hack to me (see below). The problem is
darwin-specific, not related to the front-end. On darwin:
$ cat a.c int x[999] = { 0 }; $ gcc -c a.c && ls -lh a.o -rw-r--
r-- 1 fx wheel 38M May 12 1
CC development cycle. A change such as this
to the way intrinsics are handled (front-end change) would require heavy
testing, of course, to be sure not to break anything.
I hope you will have many comments about this idea and my possible plans.
Thanks in advance.
Regards,
FX
t flex and the autotools
are not required.
I'm forwarding this to the gcc list for others' insight.
FX
I know is planned anyway).
Comments and help are very much welcome!
FX
Tobias' address doesn't accept my mails. Tobias, I hope you get those I send to
the list.
FX
Le 28 août 2010 à 11:58, Mail Delivery Subsystem
a écrit :
> Delivery to the following recipient failed permanently:
>
> bur...@net-b.de
>
> Technical details of per
h the default 64-bit compiler, you'll only have
libquad support in the -m64 variant of libgfortran, and not the -m32 variant.
All comment are of course welcome. I think the two preliminary commits allowed
to keep the size of this final patch to a reasonable value under 1kLOC (less
GCC >= 4.5 is needed. I'll add a check to libquad's configure.
FX
Le 29 août 2010 à 02:56, Steve Kargl a
écrit :
> On Sat, Aug 28, 2010 at 05:47:28PM -0700, Steve Kargl wrote:
>> On Sun, Aug 29, 2010 at 01:24:47AM +0200, FX wrote:
>>> Before I submit it off
capable of handling some of the fp modes) than those from the system headers?
I don't expect so, but I'd be glad to have someone familiar with the middle-end
confirm this for me.
Thanks,
FX
#x27;s a pretty strong argument for it!
Thanks,
FX
ific version, -lquad1.0? what if you link directly by specifying
the archive file, /path/to/libquad.a?)
All ideas are welcome!
FX
a major change, I'd like to get this in before the end of stage1,
probably submitting it next week-end, if we can agree on a path for me to
implement.
Thanks for the help!
FX
appened to
someone already? How do you fix it?
Thanks,
FX
> This is a known issue and related to timestamps of those generated
> .texi files. By touching generated .texi it can be solved. This test
> in make is here a bit broken IMHO, as a content check would satisfy
> needs for validity-check alone.
I'm wondering about this part of the Makefile:
"cpmd -s" returns false, the build dies right
there.
FX
nough time to do so, and we need to move
forward to fix this Fortran regression. Also, I believe my patch does not make
it any harder to move to hooks in the future.
Thanks in advance for your help,
FX
cpu_cpp.ChangeLog
Description: Binary data
cpu_cpp.diff
Description: Binary data
present is just for the line-map code.
In the longer term, it sure makes sense to move all this to a more generic
hooks-based mechanism.
FX
rever), and 2. make a broad announcement on gcc-patches
with a list of targets modified, and give their maintainers a week to speak up
if they have remarks. Is that enough? Is that overkill?
Thanks for your insight into these issues!
FX
;t even compiled the docs with it, as I'm on my
laptop with little battery.)
FX
Index: install.texi
===
--- install.texi(revision 201292)
+++ install.texi(working copy)
@@ -255,6 +255,26 @@ may need to use @op
I received no feedback, I'd like to submit this doc patch formally.
Tested by doing "make info html pdf".
OK to commit to trunk? What about other active release branches?
FX
Index: install.texi
===
--- install.texi
currently get stuck at stage 2 with the "gnu/stubs-32.h" error, while being
invisible to a large majority of the power users.
Question: what are the pitfalls of the test proposed above? are there typical
use cases that I have not thought of, and that would trigger this check?
FX
P
; it’s actually their purpose!
Moreover, if people want to check their codebase (as is RMS’s provided user
case), they can simply grep for these macros, so it’s not like a warning in GCC
is the simplest way to achieve their goal.
FX
/gcc/$host/$version/{cc1*,f951,collect2,lto*}
I can understand that debug builds are built with full symbols, but why don’t
we strip binaries when we install them on release version?
FX
> make install-strip
OK, great. Any reason why it should not be the “default” install?
FX
> The GNU Coding Standards explain this:
Pretty clear, thanks!
FX
_arithmetic.lo' defined here
So: is it possible to add a dependency without overriding the rule? I like
automake’s compilation line fine, I just want to add a dependency.
Thanks for any help, this is driving me nuts and preventing completion of my
patch…
FX
?
Thanks,
FX
E_CLASS) to distinguish between IEEE_SIGNALING_NAN and
IEEE_QUIET_NAN. It doesn’t explicitly state that supporting sNaN is required,
so I can also just not return it.
FX
he installation notes.
Is bootstrap broken, or am I missing something?
FX
t documented?
I don’t remember that bootstraping used to be so hard :(
Thanks for any help,
FX
Not a word.
I don’t like that building GCC has such strict dependencies on
kernels/binutils/whatever versions. E.g., Linux 2.6.18 is the kernel in
Redhat’s RHEL 5, which is still sold and supported. But that’s only my opinion.
However, the fact that it is not tested/detected at compile-time is uncool. The
fact that it is not documented is, plain and simple, bad behavior.
FX
ideally, but I know it is more work: disable libsanitizer automatically
from toplevel configure if requirements are not met
This is what is done for dependencies of all default parts of the compiler, as
far as I can tell.
FX
-Wreturn-type also warns about "return type defaults to ‘int’” for functions
where the return type is not explicitly given.
FX
is unchanged, while constant case with
-frounding-math -m32 follows the linux results.
I don’t think this is right, since remainder() is supposed to be unaffected by
the rounding mode. Yet, before I open a PR, I wanted to see if someone
understands what’s going on…
Any ideas?
FX
> Did you really test on x86_64-linux? I am only seeing this -2.71e-20 when
> using -mfpmath=387.
Duh, you’re right: I tested on a x86_64-linux, but whose system compiler
(4.7.2) actually defaults to 32-bit.
FX
, it should not be built by default (or build it only if it’s
supported). Causing such bootstrap issues would not be tolerated in other parts
of the compiler.
FX
figure --prefix=/usr/local/gfortran
--with-gmp=/Users/fx/devel/gcc/deps-static/x86_64
--enable-languages=c,c++,fortran,objc,obj-c++ --build=x86_64-apple-darwin13
Maybe you want to dichotomize your configure options and find out what’s
brinding trouble?
FX
a GMP problem, but you can never
be too sure.
> I do not have gdb for windows for the time being.
That's why I gave you a download link for MS debuggers (I don't think
gdb is supported on x86_64-mingw32). I'm not sure much can be done
without a debugger.
FX
blish.
That's great news nonetheless!
--
FX Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
file '(null)'
Slot 0x503250 in file 'gee'
Slot 0x503258 in file '(null)'
I'd be glad if someone familiar with libiberty could give me a hint of
what's going wrong.
Thanks,
FX
--
FX Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
a->p = p;
> a->file = file;
This should have been:
allocation_t **a;
/* Register this allocation. */
a = (allocation_t **) htab_find_slot (tab, p, INSERT);
*a = malloc (sizeof (allocation_t));
(*a)->p = p;
(*a)->file = file;
and later according
avoid slowing the program down more than necessary.
I guess that, because I need to delete entries, the pointer_map
wouldn't work, is that right? Plus, pointer_map is not library code...
Thanks for the suggestion, I'll look more deeply into pointer-set.c.
FX
--
FX Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
ly, and gfortran maintainers
because it prevents us from testing other parts of long double support
on ppc-darwin).
Thanks,
FX
--
FX Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
ype
node, go through all the other derived types nodes and see if there's
one that fits... but is that a reasonable thing to do? Or would it
break other stuff that I don't think off?
Thanks,
FX
--
FX Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
an't handle RECORD_TYPEs, but in fold_convertible_p()
it falls into the default case and returns TRUE, in my case. Is it
considered a middle-end bug?
FX
--
FX Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
+case COMPLEX_TYPE:
+case VECTOR_TYPE:
+case VOID_TYPE:
return TREE_CODE (type) == TREE_CODE (orig);
+
+default:
+ return false;
}
}
--
FX Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
u.org/wiki/CopyrightAssignment. Feel free to improve it
or correct it.
FX
--
FX Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
. Feel free to stress that more on the wiki page if you feel
it's necessary.
FX
--
FX Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
that ring a bell to anyone? Any idea why it's showing up now even
though it looks like this code wasn't modified in the recent past (and
my winbase.h hasn't changed since my last successful bootstrap, a
month ago).
Thanks,
FX
PS: My exact configure line is: ../trunk/configure --prefix=/
es
where it is needed?
It currently is inside:
#if defined(WINNT) && ! defined(__CYGWIN__) && ! defined (_UWIN)
...
#ifdef __i386__
So, if it's WINNT and neither cywin nor uwin, are we guaranteed it's mingw?
FX
--
FX Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
, (long long) 1);
}
$ ../prev-gcc/xgcc.exe -S foo.i -pedantic -Wall -Wno-long-long
foo.i: In function 'format_gcov':
foo.i:3: warning: ISO C does not support the '' ms_printf length modifier
I don't think it's the intended behaviour, as the error message is
rather u
testcases + doc + ChangeLog entries for formal review.
Thanks,
FX
PS: though this is a first step towards implementing a fallback
stdint.h header file for targets that don't have one, I don't plan to
do this work; having them available to Fortran is what I am
interested in :)
My strong preference is to just predefine:
__INT8_T__
[...]
Along with all the rest of the predefined bits here:
I think that would defeat the purpose of knowing these types in the
Fortran front-end.
FX
--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
ranch? When compiling, are there any options
necessary/useful?
Thanks,
FX
--
FX Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
s 3.63 0.18
(The testcase is 400k lines of preprocessed Fortran code, 16M is size,
available here:
http://www.pci.unizh.ch/vandevondele/tmp/all_cp2k_gfortran.f90.gz)
FX
--
FX Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
ngs and runtime
performance with various options) during the next few days, and I'll
post a summary to the list later on.
Thanks for your quick reply,
FX
--
FX Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
in
intl/config.log.
Thanks,
FX
--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
lp of its maintainers (and
possibly by identifying the patch that broke bootstrap).
FX
--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
ic check of
memory consumption of the compiler, but I think it'd be nice if
someone could do that.
FX
PS: I attach the file containing all timings. For each set of option,
I ran the compiler twice; when timings differ significantly, that's
because of other users using the machine (whic
2814.508
cache size : 1024 KB
FX
--
FX Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
IRA branch, or has it just not been merged recently and we
had a recent great improvement of induct on trunk? I'd appreciate if
you could enlighten me on this point.
So, other than that small question, everything seems mostly good on
the Fortran performance front.
Cheers,
FX
Comparison of
ith C and Fortran enabled, except for
gcc.dg/tree-ssa/builtin-{v,}{f,}printf-1.c which need their
scan-tree-dump patterns adjusted accordingly. If there is no
objection, I'll do that and build and regtest C++, objc and objc++ as
well before going ahead.
Thanks,
FX
--
FX Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
wide_char_part6_gcc.diff
Description: Binary data
ke the
semantics of tree dumps depend on the language compiled? (which seems
a bad idea)
FX
--
FX Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
a pain. As only developers do read
tree dumps, I think having a lot of \0 in them is fine.
FX
--
FX Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
t a standardized endianness. Otherwise some targets
> will need to scan "I\0\0\0" and others will need to scan "\0\0\0I".
That's debatable. I prefer being able to see the byte sequence in the
tree dumps to make sure it's as expected.
FX
--
FX Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
I'm forwarding this to the generic GCC development list, as more
people might be of help there (including the darwin maintainers), as
it's more of a darwin and build system issue.
FX
Début du message réexpédié :
De : IainS <[EMAIL PROTECTED]>
Date : 10 juin 2008 16:5
happens now if you do a -static compilation, does it pick
libgfortran_static automagically? Shouldn't we make that darwin-
specific, in order to not change the situation on the majority of
other systems that don't have a problem with the current situation?
Thanks,
FX
--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
As I explained in a lenghtier note to [EMAIL PROTECTED], lack of
time and new projects mean I have to resign from my maintainership. I
really want to thank all people outside the gfortran community who
have been very kind and helpful, both by mail and on IRC. GCC is a
great community to wor
number of suggestions around
on how to implement that.
FX
g.h.in, because
when I regenerate it there's nothing changed.
FX
ething here or is there actually
no way to keep that scheme and have ABI compatibility?
FX
then make the private part of the structure wider,
to accomodate any new flags (for things like extension, or the way
we'll really handle asynchronous I/O).
FX
s one more requirement on the code we write :)
But we can do it, I guess.
FX
jump? (and before the last
jump to zero)? What patches have been commited in that time that
could affect this? I can't see anything on the fortran patches...
FX
Thanks a lot Steve for taking time to prepare and write this mail.
FX
Is there any reason why libgomp and libdecnumber don't have a
svn:ignore property containing autom4te.cache? I noticed the
following always showing up in my "svn status" after a maintainer-
mode build:
? libdecnumber/autom4te.cache
? libgomp/autom4te.cache
Thanks,
FX
Then it's filed as PR 30801.
FX
I'd like to ping these two problems :)
i386-unknown-netbsdelf2.0.2 (and possibly newer versions) and i386-pc-
mingw32 (latest released version) are still completely broken on
mainline, as they have been for more that three months.
As it turns out, I do now have access to a NetBSD system, an
t for some
people. Fortran code is used for internal routines, built into shared
libraries that are later plugged into commercial apps.
How hard do you think it would be to implement a -mrtd-naming option
(or another name) to go with -mrtd and add name decorations?
FX
thing needed to get this support? I admit I'm a bit
lost in the gigantic GCC build system, but I thought the target
libraries were actually rather... standalone, autoconf-ly speaking. I
bet I was wrong.
Thanks for any help or hint,
FX
s ago.
What should be used with a recent libtool? And where is it documented?
FX
Did you put it in the toplevel configure.in or in
libgfortran/configure.ac? I suspect it needs to be in the former,
because the latter probably shares the same config.cache and thus it
won't be checked a second time when running configure for libgfortran.
Tried to put it into the toplevel confi
compiler error: in extract_insn, at recog.c:
2119
The last revision known to compile OK on that particular setup was:
123178. I filed it as PR 31344 in bugzilla. The compilation fails for
-mtune=i[345]86 while it doesn't ICE for -mtune=i686.
FX
aded when I hit "Become a mentor", neither saying if it worked or
didn't work. So, I hope it worked. Can someone check it (Ian, maybe?)
FX
asked a few times already, but nothing seems to be done: can
this be fixed? A simple workaround is to disable decimal float for i
[345]86-linux, and it would be nice if people who commit patches
acted as if they felt responsible for the consequences of their commits.
FX
l_1.f failures, which
should be fixed by now
Note2: I also omitted a couple of gfortran.dg/secnds.f failures; this
testcase should be reworked
Thanks,
FX
wrt to the Subject of the mail, I'm not sure "Call to arms" means
what I thought it meant, after all... I really wanted it to sound
like "call for help" or "call for more arms". Sorry if there was any
confusion in the tone.
FX
);
else
return 0;
}
Andrew suggested on bugzilla that this might be a GLIBC issue (I use
glibc-2.4 from redhat), with "pthreads not linking in correctly".
Does this ring a bell? Can someone confirm that it's not a GCC issue
(or that it is)? Details can be found in PR 31604.
Thanks,
FX
on i686-linux (make
info && make html). OK for mainline?
FX
Index: gcc/doc/trouble.texi
===
--- gcc/doc/trouble.texi(revision 124144)
+++ gcc/doc/trouble.texi(working copy)
@@ -234,20 +234,6 @@ y
emove?
All that said, C99 has to control just about anything you
could want about the fpu.
No, you can't control FPEs or precision, for example. AFAIK, those need
special functions (for i387-linux, e.g.) or assembly code (for ppc-darwin).
FX
gfortran.dg/vect/vect-5.f90, but
that one is not new.
They were not present in 20050615, and appeared in 20050616. It is due
to an ICE, at -O3:
O3.f: In function ‘MAIN__’:
O3.f:11: internal compiler error: in tree_verify_flow_info, at
tree-cfg.c:3716
This is now known as PR 22100.
FX
The fortran front-end needs to recognize clog10, clog10f and clog10l a
proper built-ins. Attached patch tries to add them to clog10, under a
new category: DEF_EXT_C99RES_BUILTIN (as suggested by jsm28).
Can someone review this? Is it OK?
Just realized I forgot the ChangeLog entry to go with it.
's investigating. We can only hope this can be
done soon.
FX
OK to commit?
Ping.
This problem is really blocking a very nice gfortran feature (support
for large real kinds). Since it is very short, could someone review it?
FX
2005-07-19 Francois-Xavier Coudert <[EMAIL PROTECTED]>
* builtins.def: Add DEF_EXT_C99RES_BUILTIN to
PING. Could one of the mingw/cygwin maintainers review this patch? Or
can someone else do it?
http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00086.html
eds, that's not the
problem.
Only the remaining case, which creates a shell script, fails on mingw32.
The shell script is spawned to call the assembler, which fails. Only
real win32 executables can be spawned.
FX
m what I have understood, none of the mingw
maintainers have anything against the patch, but they can't approve it.
Can someone with approval privilege over the build system look at this,
and OK it? (it's a very simple patch)
Thanks,
FX
:ADDPATCH build:
2005-08-06 Francois-Xavie
I have only tested it on Linux, can you give it a try? Ok if FX's
testing succeeds?
Testing succeeded on i686-mingw32. Configures and builds fine.
Can someone review this patch?
FX
reate a reduced
preprocessed testcase and file this regression in bugzilla.
FX
those, a rather different OS than the typical linux or freebsd where
developpers usually test their patches. I was thinking of Solaris, but
the FSF might not want it install on this hardware (though i don't think
it being non free is a relevant issue).
FX
chanism of language names, so I might
have forgotten some changes. Built and regtested on i686-linux. Comments?
FX
2005-08-31 Francois-Xavier Coudert <[EMAIL PROTECTED]>
* configure.in: Recognize f95 in the --enable-languages option,
and substitute it for fortran, issuing
101 - 200 of 305 matches
Mail list logo
