This testcase should only be run if there is a 128-bit integer kind
available. This looks like it's not the case here, but then why is
check_effective_target_fortran_large_int returning true?
I can't really understand that. What are you tcl/expect/dejagnu versions?
eport.
Thanks for your help,
FX
still
check-in small patches that add support for things g77 supported but
gfortran does not yet?
Thanks,
FX
ompiler in distros before .
The fortran patches are always fortran-contained, and I think if the
community thinks it worth to have a different development model (until
some point in the future, defined in advance) why shouldn't it be so?
FX
Steven Bosscher wrote:
Als je wil, kan ik wel een handje helpen door e.e.a. te analyzeren
voordat je de problemen voorlegt aan de mailing-list.
Erg interessant, als dit werkt. Gaat het KNMI ook daadwerkelijk
gfortran gebruiken of zijn we nog lang niet ver genoeg daarvoor?
For [EMAIL PROTECTED
a test for the testsuite, conditionnal on a new effective
target. Could someone OK this part?
Thanks,
FX
2005-10-30 Francois-Xavier Coudert <[EMAIL PROTECTED]>
PR libfortran/22298
* runtime/main.c (stupid_function_name_for_static_linking): New
function.
se it is allowed, we then need some very clever way to
get options go where they need (C-only options for b.c and Fortran-only
options to a.f)
gfortran developers, C front-end maintainers, specs gurus, release
managers, please speak up! :)
FX
2005-10-31 Francois-Xavier Coudert <[EMAIL
New version of the patch attached, to answer Joseph's remark. Original
questions still apply, including:
What should "gfortran -fdollar-ok a.f b.c" do, if -fdollar-ok if a
fortran-only option?
FX
New version of the patch attached (this time), to answer Joseph's
remark. Original questions still apply, including:
What should "gfortran -fdollar-ok a.f b.c" do, if -fdollar-ok if a
fortran-only option?
FX
2005-10-31 Francois-Xavier Coudert <[EMAIL PROTECTED]>
c1: warning: command line option "-Wredundant-modifiers" is valid for
Java but not for C
So, I guess we need to align on that...
FX
,fortran -- howdy, how long is that C testsuite to run!
:(
OK for mainline when it reopens before branching?
FX
:ADDPATCH fortran,c:
preproc.ChangeLog
Description: Binary data
preproc.diff
Description: Binary data
oc, please fix
that.
Sorry for these stupid errors, I should really have read that one
through one more time before posting. Attached is an updated version
with both errors corrected. OK?
FX
2005-11-02 Francois-Xavier Coudert <[EMAIL PROTECTED]>
PR libfortran/22298
#x27;t run; why isn't $(RPATH_ENVVAR) including HOST_LIB_PATH
for the testsuite?
Thanks,
FX
Index: Makefile.tpl
===
--- Makefile.tpl (revision 106019)
+++ Makefile.tpl (working copy)
@@ -216,6 +216,7 @@
# Where to find GMP
HOS
ess someone who cares about it enough patches the GMP sources.
Steve, how did you hack gmp to get it run?
In the short term, that also means that we don't have to care about
supporting __float80 in gfortran ;-)
FX
PS: I'm amazed that a "GNU project" can have exactly two de
e the
fortran/ front-end, so I think we can consider backporting it to 4.1.
$ diff gcc/gcc/fortran gcc-4.1/gcc/fortran|wc -l
743
$ diff gcc/libgfortran gcc-4.1/libgfortran|wc -l
1747
The last number falls down to 484 if we don't count the regenerated files.
FX
an -g large_real_kind_2.F90 && ./a.out
0.5403023058681397650104827000.540302305868140
1.984153572718682756025749000E-0004
But I can't make a C testcase for that. Is "long double" supposed to be
usable on ppc-darwin7.9 ?
FX
Moreover, removing the first test makes libgomp build on targets (as
Tru64) where the -pthread option is required to include pthread.h.
Commited after approval by Alexandre Oliva on IRC. The exact patch
commited is attached.
FX
libgomp.diff
Description: Binary data
Should I file a bug ?
I think it might be better to wait for the opinion of the gomp
maintainers, as I'm fairly new to that stuff and could have missed
something important.
Jakuk, Diego? Is this a bug or a feature? :)
Hum... for trunk on i686-linux, I do see the following. Dynamic
linkin
library, and it would be a pity
not to be able to run OpenMP on this platform.
FX
penmp/prev-gcc/as" "-o" "C:/DOCUME~1/coudert/LOCALS~1/Temp/
ccgHbaaa.o" "C
:/DOCUME~1/coudert/LOCALS~1/Temp/ccIV.s", ...)^M
xgcc.exe: CreateProcess: No such file or directory^M
I'm trying to understand exactly why all this only happens for --
enable-libgomp builds (it's 100% reproducible for me, with different
versions of mainline, bootstrapping everytime). So, is what I'm
seeing an expected behaviour? How can I investigate further?
Thanks,
FX
And I forgot to ask: who the heck is supposed to set USE_MINGW_MSYS?
(grep is soo sloow on my win32 machine)
FX
re posting
it, but is not related to the real problem here.
FX
petence; find someone you
know, that you have leverage on, to do it :)
Now, for an idea of how much work it represents... perhaps someone
here can tell us?
FX
Something is marking random_seed as noreturn.
As far as I understand, symbols are marked as noreturn by use of
TREE_THIS_VOLATILE, which is done on a few selected trees and is also
done whenever a symbol has the noreturn attribute. This noreturn
attribute can be set to 1 by make_noreturn,
My first patch didn't even compile :(
Here's a new one.
Something is marking random_seed as noreturn.
As far as I understand, symbols are marked as noreturn by use of
TREE_THIS_VOLATILE, which is done on a few selected trees and is
also done whenever a symbol has the noreturn attribute. T
lddir}/${target}/libgfortran/kinds.h
Thanks,
FX
ing your whole ${builddir}/${target}/libgfortran directory.
That should work.
FX
ecific (it happens
also on i686-linux) and it looks like a middle-end issue. Now, we have
to hope that it gets more attention than PR 27889 :(
FX
d issue the error
message on stderr and indicate to dejagnu that non-zero exit codes does
not mean that the test FAILed). How can I do that?
Thanks for any help,
FX
' and 'continue' lines, see if it's still
broken. Try to compile without linking (gfortran -O3 -g -c assign.f90).
FX
Hi everyone,
I am developing on a custom design using the LatticeMico32
architecture and I use gcc 4.5.1 to compile C code for this arch.
In this architecture, the loading of an address 0x always
takes two assembly instructions to fetch the address because
immediates are on 16 bits :
ill give it a try based on other relaxations done for other platforms...
Thank you for your input and I will let you know if I have any success
FX
st, but I wrote
pointer_map for my private work on gcc and it was not needed at the
time.
But didn't you say the need to remove entries (quite frequently,
actually) makes pointer_map unsuitable?
FX
--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
The error here is the same:
../../trunk/gcc/doc//invoke.texi:1243: @include `/home/FX/ibin/
gcc/../../trunk/gcc/../libiberty/at-file.texi': No such file or
sdirectory.
What's interesting is that the file actually exists:
$ wc -l /home/FX/ibin/gcc/../../trunk/gcc/../libiberty/at-fi
we have PR35218 which seems to be the same issue?
Yes, it is exactly, it was open by Eric and I added my information. I
should have given the PR number in my mail.
FX
--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
bstitute it.
* configure: Regenerate.
I'm willing to try, but running "autoconf" doesn't regenerate the
configure file, what am I missing?
FX
--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
One question I have, Eric and FX: do you both have self-built
texinfo on
MinGW?
Yes, because the one provided with MSYS is from texinfo 4.3, which
GCC finds too old. Apparently, MSYS-1.0.11 will come with texinfo
4.11, but it's still labeled "technology preview" for now.
and v850-elf.
As a Fortran maintainer, I don't feel strongly about being or not
being listed as a primary language.
Thanks,
FX
--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
c-apple-darwin9.2.0 with C and
Fortran, and regtested with both -m32 and -m64 for these same
languages. OK for trunk? (I need a Darwin maintainer approval for the
target stuff, and a Fortran maintainer for Fortran parts.)
FX
--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~u
ne. For now, it's of limited
importance, because it's not among the builtins used in Fortran.
Thanks for the review and comments,
FX
--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
follow
that in fold_convert().
FX
--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
C: integer overflow undefined, checking desirable at least for
debugging purposes.
I think latest Fortran is same as C, can someone confirm?
Yes, it is. Overflow undefined and no checking required; I think very
few Fortran users actually use (or would use) checking on signed
overflow.
FX
t the Fortran array is)
and a VECTOR_TYPE?
I'm CCing the main GCC devel list, since we might have more answers
form there.
FX
--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
t; Fortran programmers
don't use integers except for array subscripts. Real life is floating-
point based!
FX
--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
rs 99%
of cases is better than nothing.
Thanks,
FX
--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
intfast-1.diff
Description: Binary data
width integer types */
typedef int8_tint_fast8_t;
typedef int16_t int_fast16_t;
To do the right thing, do I have to #define INT_FAST8_TYPE in
darwin.h to be "int8_t", or "signed char"? I'd go for the second, but
as I know nothing about C++, I
efully crafted testcase in the testsuite might
help checking that and adding information about these targets when we
see the testcase FAILing.
FX
--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
i386? In any case, this
most probably isn't a Fortran issue.
Daniel, Zdenek, I assume you being "linear loop transforms" and "loop
infrastructure" maintainers means you're the right persons to CC, so
there you go.
FX
--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
doing it.
The fact is: the FSF doesn't request such a disclaimer. Little use
being more royalist than the king (don't know if that translates well
from the French idiom, but you get the idea).
FX
--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
'd point out that other GNU (or not) projects have the same form on
their website, e.g. http://wiki.list.org/display/DEV/GNU+copyright
+assignment+request+form or http://www.g95.org/contrib.html, in
addition to many mailing-list archives.
FX
--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
maintainer that is taking care of your contributions) to obtain the
relevant forms
to
contact us (either via the gcc@gcc.gnu.org list or a GCC Steering
Commitee member) to obtain the relevant forms
to reflect this.
FX
--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
int’
make[3]: *** [build/print-rtl.o] Error 1
make[3]: Leaving directory `/home/fxcoudert/gfortran_nightbuild/
ibin-20070515/gcc'
make[2]: *** [all-stage2-gcc] Error 2
Probably related to http://gcc.gnu.org/ml/gcc/2007-05/msg00354.html
FX
can I post to help people debug this? (I have kept the build
directory intact for further debugging, I just don't know what to do
and where to start fishing.)
FX
now cygwin bootstrap is
awfully slow)
FX
oices in the past not to worry
about this MAINTAINERS category not 100% describing our policy.
FX
[1] I'm sorry if I'm misunderstanding the policy that is applied to
us; and I want to note that I'm only speaking about maintainership,
not the development and branches rules, for which we're going slowly
toward the standard GCC practices.
e, but I never wrote code to emit
GIMPLE arrays before, and don't know where to look exactly. I'll
continue looking for the reason, but if someone thinks of something
trivial I'd be interested in knowing!
Thanks for the help, and sorry (in advance) if it's a completely
stup
pass the array as a pointer. That's
how C works.
Hum, I really thought it was something stupid, and it actually was
even more stupid than I thought. Sorry for the noise, and thanks for
the answer!
FX
.html> for instructions.
make[3]: *** [selected_int_kind.lo] Error 1
Anyone else experiencing this? Should I upgrade GMP/MPFR?
Depends what is your current version, I guess. Can you get us a
backtrace?
FX
My automated nightly build failed to bootstrap this evening on i386-
pc-linux-gnu. This is for trunk rev. 127311, and the error is:
/home/fx/gfortran_nightbuild/ibin-20070809/./prev-gcc/xgcc -B/home/
fx/gfortran_nightbuild/ibin-20070809/./prev-gcc/ -B/home/fx/
gfortran_nightbuild/irun
ne that doesn't
work (it displays "1900--"), so I removed it.
Comments are highly welcome, both on the idea itself, and on the Perl
script (my Perl is a bit rusty since I haven't used it for years).
Thanks,
FX
[1] As a record, here's what my "final" status is
issue with the target printf() implementation,
so if you spot these failures on your favorite target, please report
them to the [EMAIL PROTECTED] mailing-list so that we can xfail them.
Thanks,
FX
03: Attribute
PUBLIC" }
| 1
| Error: Fortran 2003: Attribute PUBLIC at (1) in a TYPE definition
and there.
FX
nstantiation of undefined template
'wi::int_traits >'
BINARY_PREDICATE (operator ==, eq_p)
^
../../gcc/gcc/wide-int.h:3266:3: note: expanded from macro 'BINARY_PREDICATE'
OP (const T1 &x, const T2 &y) \
^
I would welcome:
1. confirmation that the C++11 code in aarch64-builtins.c is indeed a bug, and
that a patch for it would be welcome
2. guidance about how to fix that next issue
Thanks,
FX
-darwin machines.
Cheers,
FX
gned long);
+std::string aarch64_get_extension_string_for_isa_flags (uint64_t, uint64_t);
struct aarch64_arch_extension
{
Although I admit that’s almost trivial (and it breaks build on aarch64-darwin),
I’d prefer to be sure and ask. Then I’ll commit the two patches, if you think
that’s OK.
FX
known as Francois-Xavier Coudert
(and for the record, I do have a copyright assignment in place)
Happy new year to all,
FX
commit 96a9d0950453ca571b3999c2f4d4168da9d770f0
Author: Francois-Xavier Coudert
Date: 2020-12-21 22:06:59 +0100
Fix prototype for aarch64_get_extension_string_for_
variants? Should it?
I’m happy to investigate more, but I’m not sure what to do.
Best,
FX
__ set to 16 supposed to be portable across all
targets? Or is it linux-only, and should marked as such?
Thanks for any help you can give.
FX
use fixinclude to make
the darwin headers happy, but we don’t really have a macro to provide the right
value. Like a __FLT_EVAL_METHOD_OLDSTYLE__ macro.
What should be the float_t and double_t types for FLT_EVAL_METHOD == 16? float
and double, if I understand right?
FX
pe for a DEC C internal asm() function,
Sucks to have to fix headers… and we certainly can’t fix people’s code that may
depend on __FLT_EVAL_METHOD__ have well-defined values. So not convinced this
is the right approach.
FX
something together, unless you think it’s a big project. Any pointers as to how
to start would be appreciated.
Best,
FX
is still a difference. If we define a new macro
__FLT_EVAL_METHOD_OLDSTYLE__ (however it is named), it means we can make a more
robust fixinclude, using that macro. If we fixinclude right now to handle the
value of 16, then we might have to update the fixinclude for any new value that
comes along in the future.
FX
alling NaNs in libgfortran. Could someone either confirm that
the behavior observed above is a bug, or if not, kindly explain to me why it
happens?
Thanks,
FX
e may be no guarantee, it sounds like a reasonable
expectation in the case I posted. I’ve filed a PR:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103883
Thanks,
FX
Hi David,
May I kindly ping you on that? Or anyone with knowledge of the static analyzer?
Thanks,
FX
> Le 23 déc. 2021 à 22:49, FX a écrit :
>
> Hi David, hi everone,
>
> I’m trying to understand how best to fix or silence the several failures in
> gcc.dg/analyzer th
well?
The tests even compiled with -S still fail:
spawn -ignore SIGHUP /Users/fx/ibin/gcc/xgcc -B/Users/fx/ibin/gcc/
exceptions_enabled42475.cc -fdiagnostics-plain-output -S -o excep
tions_enabled42475.s
FAIL: gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c -O1 (test for
excess errors)
E
nalyzer/torture/asm-x86-linux-cpuid-paravirt-2.c
FAIL: gcc.dg/analyzer/torture/asm-x86-linux-rdmsr-paravirt.c
still fail with dg-do compile, as explained, become the error comes from the C
front-end, not the assembler:
/Users/fx/gcc/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-cpuid-pa
Hi David,
> Thanks. I extended your patch as follows, which works successfully for
> me on x86_64-pc-linux-gnu.
>
> Does the following look OK for the analyzer asm failures on
> x86_64-apple-darwin?
Sorry for the late reply… yes it does!
FX
reater !(x>y)
compareSignalingLessUnordered !(x=>y)
compareSignalingNotLess !(xhttps://gcc.gnu.org/bugzilla/show_bug.cgi?id=77928). Is there a fundamental
problem with creating one, and could someone help there?
Thanks,
FX
e:
1. defined in builtins.def
2. lowered in builtins.cc
3. type-checked in c-family/c-common.cc
4. documented in doc/extend.texi
5. tested in fp-test.cc
6. covered in the testsuite
Is that right?
Thanks,
FX
PS: I see that reclassify is not covered in fp-test.cc, is that file obsolete?
ns: first
one does not raise invalid, second one does.
With -O2 -fno-unsafe-math-optimizations -frounding-math -fsignaling-nans: no
invalid raised at all.
FX
iseqsig.diff
Description: Binary data
printf("%d\n", iseqsig(x, __builtin_inff()));
foo();
}
$ ./bin/gcc a.c -lm -fno-unsafe-math-optimizations -frounding-math
-fsignaling-nans -O0 && ./a.out
0
Invalid raised
0
Invalid raised
$ ./bin/gcc a.c -lm -fno-unsafe-math-optimizations -frounding-math
-fsignaling-nans -O1 && ./a.out
0
0
Do you want me to file a bug report?
FX
For the record, this is now PR 106805
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106805
FX
I’ll propose a middle-end + C patch first. But I do
not need it absolutely.
Thanks,
FX
l” way to perform it is? I do not want to mess up corners cases, which
is so easy to do…
Thanks again,
FX
EFAULT_STK_CLASH_GUARD_SIZE
which I think are because this commit
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0a85544e1aaeca41133ecfc438cda913dbc0f122
should have regenerated and committed config.in <http://config.in/>
Christina, can you please have a look?
FX
mean, from an almost-external point of view, these tests should probably be
xfail'ed and a PR opened against them to reenable them.
FX
lation of noise just decreases the value of
the the test results.
FX
am unsure: is the warning
warranted here? If so, we should adjust the check to silence warnings, or use a
cast. Or is the warning emitted in error?
Any help would be appreciated.
Thanks,
FX
Hi Jakub,
I should have pinged you, I see you recently touched that code.
FX
> Le 18 août 2023 à 21:07, FX Coudert a écrit :
>
> Hello,
>
> On the WIP aarch64-darwin port of GCC
> (https://github.com/iains/gcc-darwin-arm64), there are some C++ testsuite
> failures
prevents the warning:
> float dummy = (float) 1.0q;
Yes, I think a cast does the job. It will still error out when q suffix is not
supported, and will not have other messages.
FX
_node in the aarch64-darwin
port. I will do that. Am I correct in reading that this “new” way of handling
extended types in C++ was introduced in 2022-09-27? If so, my port to
aarch64-darwin was done two years ago, and that explains why I missed that
entirely…
Thanks a lot Jakub for the help!
FX
Hi David,
I’m seeing the following failures on building GCC with Apple’s clang:
> /Users/fx/devel/gcc/gcc-repo-write/gcc/analyzer/region-model.cc:3426:16:
> error: unexpected type name 'byte_size_t': expected expression
>std::max (by
> std::max and std::min, introduced by d99d73c77d1e and 2bad0eeb5573, are not
> available because is not included.
I originally thought this was only seen in cross-compilers, but it actually
broke bootstrap on darwin.
Attached patch restores it, OK to commit?
FX
0001-Analyzer-i
-getaddrinfo-server.c
FAIL: c-c++-common/analyzer/fd-symbolic-socket.c
They all have an unexpected analyzer warning, like this:
/Users/fx/gcc-upstream/gcc/testsuite/c-c++-common/analyzer/fd-glibc-byte-stream-socket.c:
In function 'int main()':
/Users/fx/gcc-upstream/gcc/testsuite/c-c++-common/a
/sum_c4.c generated/sum_i1.c generated/sum_i2.c
generated/sum_i8.c generated/sum_r16.c generated/sum_r4.c
We could imagine having a single file for all sum intrinsics.
How do Fortran maintainers feel about that?
FX
arwin, and I could
potentially add it to “skip”. But… is it really necessary anywhere? It is from
before 1998.
I would welcome guidance on how to handle these, or advice on what the second
is supposed to achieve.
Thanks,
FX
math_exception.diff
Description: Binary data
*
3 *-*-solaris*
3 *-*-netbsd*
The question is: out of the remaining ~100, how many trigger on common targets,
when they are actually useless. Having the information in the test summary
would be great, I think.
Best,
FX
> Laugh or cry.
Wow. But how does any other compiler deal with them?
I’ve pushed the change as
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=66d6b1861ec57ba29540a5fa7854df3978ba5409
Please let me know if you see any issue in the next tests.
FX
idiom in GCC is to #define INCLUDE_STRING (for example)
before “system.h” is included, rather than #include directly. The
attached patch fixes the issue.
Best,
FX
gm2.diff
Description: Binary data
201 - 300 of 305 matches
Mail list logo
