> So, I think we could ignore signed zeros (from the Fortran standard
> perspective)
>
> - for complex arithmetic, always
> - for real arithmetic, if none of the IEEE modules is USEd
That seems like a very backward-incompatible change to introduce :(
I might break a lot of existing codes.
FX
build libgcc_s.1.dylib on macOS 15
for Intel, is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
Best,
FX
g the naming of M_SQRT1_2q, it simply follows the traditional M_SQRT1_2
macro which, according to glibc doc: "These constants come from the Unix98
standard and were also available in 4.4BSD”. I agree with you that logic would
dictate M_1_SQRT2, but we simply follow the existing pattern there.
t is done for the other use
of flex.
FX
page should be
amended: https://gcc.gnu.org/install/prerequisites.html
Best,
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
> 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
*
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
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
/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
-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
> 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
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
_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
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
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
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
lation of noise just decreases the value of
the the test results.
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
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
l” way to perform it is? I do not want to mess up corners cases, which
is so easy to do…
Thanks again,
FX
I’ll propose a middle-end + C patch first. But I do
not need it absolutely.
Thanks,
FX
For the record, this is now PR 106805
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106805
FX
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
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
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?
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
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
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
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
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
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
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
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
something together, unless you think it’s a big project. Any pointers as to how
to start would be appreciated.
Best,
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
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
__ 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
variants? Should it?
I’m happy to investigate more, but I’m not sure what to do.
Best,
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_
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
-darwin machines.
Cheers,
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
e to
memory alignment, and you could use aligned_alloc() instead?
FX
; Is there any place where one can contribute procedures to the library?
Ask on the gcc general mailing list: gcc@gcc.gnu.org
FX
ary under another name?
Thanks,
FX
front-ends
emitted. I have read the release notes and can’t find anything related.
Any advice?
Thanks,
FX
x, if you want. Let me know off-list
what you need.
FX
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
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
> We choose mpich as a default only because it is very stable.
Why are why tying ourselves to one MPI implementation?
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
e opinion of other maintainers would be good
to hear.
FX
omplex piece of code, which runs on tons of
different platforms, and so is very conservative about its requirements.
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
;
> 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
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
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
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
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
> 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"
its .mod files into the
multilib-specific finclude directory, just like libgfortran does.
FX
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
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
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
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
=/Users/fx/devel/gcc/deps-static/x86_64
--enable-languages=c,c++,fortran,objc,obj-c++ --build=x86_64-apple-darwin15
Thanks,
FX
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).
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
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
are not supported.)
FX
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
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
> 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
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/
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
cluding
the whole tree if need be).
Thanks for helping with this,
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
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
> Ok.
Committed to the 4.8 branch as rev. 218873
FX
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
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
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
> 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
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
> 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
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
> Done:
> https://sourceware.org/ml/binutils/2014-11/msg00318.html
Thanks!
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
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
> -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
) 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
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
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
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
:
2005-01-19 Neil Booth
* MAINTAINERS: Remove self as cpplib maintainer.
I suppose it would make sense to remove it “option handling” maintainer.
FX
missed optimizations in routines using the
IEEE modules, so at least it’s not wrong code for us :)
Cheers,
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
n idea how to fix this. This is way beyond my
> league!
>
>
> Thanks Steven for your help!
> 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
1 - 100 of 305 matches
Mail list logo
