https://gcc.gnu.org/g:66d6b1861ec57ba29540a5fa7854df3978ba5409
commit r15-1173-g66d6b1861ec57ba29540a5fa7854df3978ba5409
Author: Francois-Xavier Coudert
Date: Fri Jun 7 11:05:39 2024 +0200
fixincludes: bypass the math_exception fix on __cplusplus
fixincludes/ChangeLog:
https://gcc.gnu.org/g:e4f1c1be61d916345655d5edba309502046c9473
commit r15-1095-ge4f1c1be61d916345655d5edba309502046c9473
Author: Francois-Xavier Coudert
Date: Sun Jun 2 21:07:23 2024 +0200
fixincludes: bypass some fixes for recent darwin headers
fixincludes/ChangeLog:
https://gcc.gnu.org/g:1dba1d860a1e3e32e5d061a1d6dc600c96d2597f
commit r15-50-g1dba1d860a1e3e32e5d061a1d6dc600c96d2597f
Author: Francois-Xavier Coudert
Date: Tue Mar 19 14:16:38 2024 +0100
Fortran: add F2023 ISO_FORTRAN_ENV named constants
gcc/fortran/ChangeLog:
*
https://gcc.gnu.org/g:3bd3ca05b519b99b5ea570c10fd80737cd4c6c49
commit r14-9937-g3bd3ca05b519b99b5ea570c10fd80737cd4c6c49
Author: Ian McInerney
Date: Thu Apr 4 16:16:32 2024 +0100
libgfortran: Fix compilation of gf_vsnprintf
The fallback function (gf_vsnprintf) to provide a
https://gcc.gnu.org/g:5213047b1d50af63dfabb5e5649821a6cb157e33
commit r14-9500-g5213047b1d50af63dfabb5e5649821a6cb157e33
Author: Francois-Xavier Coudert
Date: Sat Mar 16 09:50:00 2024 +0100
libcc1: fix include
Use INCLUDE_VECTOR before including system.h, instead of directly
https://gcc.gnu.org/g:0ed6e5b4820e01fa86b48a7b1d62f752ec97ea41
commit r14-9367-g0ed6e5b4820e01fa86b48a7b1d62f752ec97ea41
Author: Francois-Xavier Coudert
Date: Thu Mar 7 17:27:17 2024 +0100
testsuite, darwin: improve check for -shared support
The undefined symbols are allowed for
https://gcc.gnu.org/g:9970b576b7e4ae337af1268395ff221348c4b34a
commit r14-9360-g9970b576b7e4ae337af1268395ff221348c4b34a
Author: Francois-Xavier Coudert
Date: Thu Mar 7 14:36:03 2024 +0100
Include safe-ctype.h after C++ standard headers, to avoid over-poisoning
When building
Hi Uros,
It sounds like a great idea! I'm forwarding this to the Fortran list,
because I think it might raise quite some interest there also :
http://gcc.gnu.org/ml/gcc/2007-11/msg00164.html
FX
Bootstrap on i386-linux has been broken for a week now, from what I
can see. I have reported it as PR33679
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33679), but AFAIK noone
has reproduced it, as most people now build for i686-linux. Could
someone please spare a cycle to confirm this problem? I
ping? Gerald, being web pages maintainers, what's your opinion?
Answering to Janne's comment, I'm certainly not opposed to any
preprocessor/templating system. My own goal is to rewrite the fortran
pages, including the common navigation bar, and I can't use MetaHTML
to do that.
On 9/29/07, FX
Hi there,
Mainline currently doesn't bootstrap on mips-sgi-irix6.5 due to an ICE
while compiling mips-sgi-irix6.5/64/libgcc/_powitf2.o at stage 1. This
happens, afaict, with any use of the TF mode with either -mabi=64 or
-mabi=n32:
$ cat foo.i
void __powitf2 (float x __attribute__ ((mode (TF
The documentation for different releases of GCC in the same branch
vary only slightly. For that reason, I think it would be nice to be
able to have a URL for the doc of a given branch, meaning the doc
of the last released version of this branch. For example, that would
be achieved by creating a
Hi all,
I'm currently rewriting the fortran/ part of the GCC website and
trying to use the website preprocessor locally, to check my
modifications (which include bringing fortran/ to the website common
style). The script needs mhc, which seems to be the metahtml
compiler. I tried to compile
The last few days have seen a regression in the Fortran testsuite on
i386-linux and x86_64-linux (filed as PR33391). The following code
gives wrong results at -O2 while it works at -O1:
program test
integer(kind=1) :: i
do i = -128, 127
end do
if (i /= -128) call abort
end
Does anyone knows the answer? or should it be asked on comp.lang.fortran?
It's very specific to the problem at hand, so I doubt c.l.f could give
us much input on that. As I understand, in this case, it actually is
the right thing to do.
FX
Because of the famous duplicated declaration problem
This sentence is reminding me that I forgot to send the following update:
As I said I was going to give it a shot over the week-end, here's an
update on this: it won't make it into 4.3, because it's a big change
and my current patch is
As I said I was going to give it a shot over the week-end, here's an
update on this: it won't make it into 4.3, because it's a big change
and my current patch is triggering a very long string of
Huh, still I would be interested in seeing the patch.
It's based on Michal Matz's patch at
Well, at least the culprit is easy to find!
2007-08-16 H.J. Lu [EMAIL PROTECTED]
* Makefile.in (REVISION): New.
(REVISION_c): New.
(REVISION_s): New.
(version.o): Also depend on $(REVISION). Add
-DREVISION=$(REVISION_s).
* version.c
FAIL: gfortran.dg/g77/980310-3.f (internal compiler error)
FAIL: gfortran.dg/g77/980310-3.f (test for excess errors)
I saw this one on x86_64-linux with -m32, and filed it as PR33074. I
asked about it on IRC yesterday, and if I understood Andrew Pinksi, it
probably is a middle-end problem, as
Hi all,
Bootstrap including gfortran has been broken on native i386-pc-mingw32
for at least 10 days, with the C compiler having an ICE while
compiling libgfortran/io/write.c. I finally found the opportunity to
reduce the ICE to the following code:
$ cat write.i
extern void fflush (int);
extern
Hello,
It too is possible that you
have completed your assignment process with the FSF, but have yet to be
removed from the list of outstanding assignments. If this is the case
please let me know so that I can update the record.
This is the case: I have had a copyright assignment on file for
Hi,
When the commit which introduced the regression is known, why not
simply assign the bug to the committer? Surely, people do follow
regularly the bugs that are assigned to them, don't they?
In my opinion, all regressions should always be assigned to someone,
at all times. Either to the
We already do that, and in lots of cases it doesn't work. CCing is not
coercive enough, you only receive a few more mails (and some people
don't even read their bugzilla mail).
Coercion isn't an option that is available to us.
Hum, I checked the Merriam-Webster dictionary, and clearly
Sorry about the (possibly off) question: would this apply also to
GMP/MPFR, if not, wouldn't it make sense?
GMP and MPFR are host libraries, so it is actually an independent
issue. However, it might be worth having --with-static-gmp and
--with-static-mpfr to request static linking of these
You want more bugs fixed, it would seem a better way would be to build
a better sense of community (Have bugfix-only days, etc) and encourage
it through good behavior, not through negative reinforcement.
I do agree with that in a general way, but I think there should also
be a real effort done
The mea culpa is to permit for long time to modify configure instead of
configure.ac or configure.in that is used by autoconf and/or automake.
[...]
I'm sorry, but I don't understand at all what you propose, what your
proposal is supposed to fix or how that is related to the mail you're
libdecnumber/aclocal.m4:# generated automatically by aclocal 1.9.5 -*-
Autoconf -*-
That's a problem in the last regeneration of this file. I'm CCing M.
Meissner, H. J. Lu and M. Cornea, since they appear to have last
changed this file, although there's no ChangeLog entry for it in their
Hi Aurélien,
A few remarks:
1. you don't show us the actual compilation error message: why is
make failing?
2. maybe you don't know, but there are binaries available from
http://gcc.gnu.org/wiki/GFortranBinaries, if that helps.
3. you should definitely quote the system compiler and cctools
out_make is the output of the make. In fact it is the output of the
make launch a second time. (To big otherwise.)
Yes, but it's missing the standard error file. Please use:
make out_make 2 err_make
or something similar.
FX
Hi all,
Could someone give me a pointer to doc or code about building a
function decl and function call expr that take a variable number of
arguments (like printf)?
Thanks,
FX
Hi Zack, hi all,
A bootstrap of GCC mainline, rev. 123324, fails because of:
gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-Wold-style-definition
I'm CCing Zack
Away on vacation until March 31st, said the automated reply.
PS: I've launched a cross build to see if I can reproduce it there,
which would of course make it easier for tracking down.
Works OK on the cross. So, it's probably a host problem in gengtype.
It appears to exist on
Yeah, it appears I was overly optimistic in hoping vsnprintf() would
do what C99 says it does. I do not have access to any system that
shows the problem, but I've attached a patch that should fix it (it
just reverts the oprintf() changes, which were not really necessary, I
was just trying to be
I tried to apply on the SoC website, but the application form only
reloaded 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?)
Problem fixed. The Google form doesn't work if you 1) use Safari and
2) come from a
My nightly bootstrap of mainline on i386-linux failed tonight, on
revision 123192.
This issue is still not fixed as of now. A diff was posted to PR31344
with the mention This isn't a real patch. Is a real patch planned in
the near future, or is there any other short-time plan to get
i386-linux
is there any other short-time plan to get
i386-linux bootstrap back?
Just configure gcc with --disable-decimal-float. I don't think
dfp works on x86 very well.
Thanks for suggesting --disable-decimal-float.
Note that, in my above sentence, any other short-time plan includes
disabling it by
Hi all,
I'm working on implementing a correct Fortran rounding (rounding to
nearest-integer, with half integer values rounded to the integer of
maximum absolute value) in the Fortran front-end, following
ada/trans.c (convert_with_check) and
http://gcc.gnu.org/ml/fortran/2005-04/msg00139.html
Hi all,
A bootstrap attempt of GCC mainline on a i386-unknown-netbsdelf2.0.2 with:
Memory: 378M Act, 264M Inact, 3520K Wired, 4664K Exec, 633M File, 151M Free
Swap: 129M Total, 129M Free
failed due to a compilation error in stage1:
cc1: out of memory allocating 138677280 bytes after a total
It might be considered a backend issue, but in general it
is a binutils (so OP is in the wrong list!).
I beg to disagree with the in general it is a binutils issue part.
One of the posters explained why the information needed for name
decoration can't be determined at link-time (nor at
Hi Tobias,
What is the proper way to obtain this information?
I fear the answer to this question is there's no way. We already
discussed that a few months ago, at the thread starting here: http://
gcc.gnu.org/ml/gcc/2006-10/msg00346.html From private discussion,
with Paul Brook Joseph
I noticed a performance regression on the following code:
$ cat a.c
#include stdint.h
#include stdio.h
void
add256 (uint64_t x[4], const uint64_t y[4])
{
unsigned char carry;
x[0] += y[0];
carry = (x[0] y[0]);
x[1] += y[1]+carry;
carry = carry ? (x[1] = y[1]) : (x[1] y[1]);
x[2] +=
Hi Richard,
I found the following in my build logs, and thought it was worth
reporting to you. Although I don't speak texinfo, the lines in
questions are the ones introduced by your ColdFire 9/63 patch
(commited as rev. 120713):
perl
Hi all,
There are two platforms on which mainline is broken:
* bootstrap is broken for i386-netbsd, see PR30058
* the compiler built on i386-mingw32 is unusable, see PR30589
Both regressions were introduced by Geoffrey Keating
(http://gcc.gnu.org/ml/gcc-patches/2006-11/msg3.html) in a C99
As it turns out, I do now have access to a NetBSD system, and will
look at that problem when I next get time.
Thanks. When you provid a patch, I will test it. (If someone else ever
wants access to a netbsd system, it's worth noting there's one on the
GCC compile farm!)
My understanding from
[sorry for breaking the thread; stupid gmail doesn't want to add
custom References headers]
It may be that not too many people pick up 4.2.0. But, if 4.3 isn't
looking very stable, there will be a point when people decide that 4.2.0
is looking very attractive. The worst outcome of trying to
And why would you think (twice) that the best place for reporting this
is neither the gfortran mailing-list, nor bugzilla?
I suggest that you test the following patch and report back to us:
Index: libgfortran/runtime/error.c
===
I suggest that you test the following patch and report back to us:
I got the patch wrong (it's not a real printf function we have there):
Index: libgfortran/runtime/error.c
===
--- libgfortran/runtime/error.c (revision 118806)
+++
Hi all,
I'm not sure whom to write about the workings of the GCC bugzilla
database, so I'm writing here and CCing Daniel Berlin, since IIRC he
handles part of that work.
I think it would be nice (although not high priority) to remove the
libf2c component in bugzilla, since we don't ship libf2c
First, please note that having gfortran testresults for one platform
only means that some version of the compiler was able to correctly
compile GMP MPFR, not that GCC trunk is able to correctly compile
GMP MPFR. Nevertheless:
* i386-unknown-freebsd (alpha-unknown-freebsd5.4)
Hi,
I'm trying to understand PR 13615, where a used-uninitialized Fortran
character string induces the following diagnostic:
'c[1]{lb: 1 sz: 1}t.f: In function 'warn_character':
t.f:33: warning: ' is used uninitialized in this function
I see that this error message is emitted from tree-ssa.c,
I'd say the FE is not setting the name properly into whatever _DECL we
found.
var_decl 0xb7b907e8 c$1
type integer_type 0xb7b95114 char public unsigned string-flag QI
size integer_cst 0xb7b851f8 constant invariant 8
unit size integer_cst 0xb7b85210 constant invariant 1
I've been doing some benchmarking of gfortran, and reducing the
testcase leads to what seems a missed optimization in the following
code:
$ cat a.c
void foo (float * restrict x, float * restrict y)
{
int i;
for (i = 0; i 1; i++)
x[i] = y[i] * y[i];
}
$ gcc a.c -O1 -ffast-math -msse
[CCing the OpenMP experts]
Henry,
The -fopenmp option doesn't work under mingw32. Since I am the one
building the Windows (mingw32) binary packages you downloaded, I'm
rather interesting in getting it to work... So here are a few things
we could sort out:
1. currently, using the -fopenmp
you just port libgomp to mingw32 + pthreads-win32
and assuming pthreads-win32 is sufficiently rich and not too buggy, it will
just work.
With the attached patch, I can compile libgomp with
../gcc/configure --prefix=/mingw --disable-nls --with-ld=/mingw/bin/ld
--with-as=/mingw/bin/as
Hi all,
The following regression appeared between 20060504 and 20060505 on
i686-linux. It is filed as PR 27443,and appears to be a consequence of
a new optimization pass introduced by revision 113518.
FAIL: gfortran.fortran-torture/execute/entry_3.f90 compilation, -O3
-fomit-frame-pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27437
Humpf. Does that mean that the patch wasn't regtested before being applied?
FX
I'm experiencing a strange gfortran bug, i686-pc-mingw32 specific,
with options -march=pentium4 -mfpmath=sse -msse.
Some more input... the bug appears when SSE sqrtsd is called, but only
if libgfortran contrusctors have been run:
cat a.s
.file a.f90
.section .rdata,dr
Hi all,
I'm experiencing a strange gfortran bug, i686-pc-mingw32 specific,
with options -march=pentium4 -mfpmath=sse -msse. I reproduce it below,
and post it here before filing it because I can't manage to create a C
testcase, and have no idea if this is something already known (though
my
[sorry for breaking the thread, stupid gmail interface doesn't allow
adding custom headers]
i tried to compile gcc 4.1.0 (the final release) on windows, too. I'm using
msys and configured the buildprocess with --enable-threads=win32
--with-win32-nlsapi=unicode. On the msys console i type make
I started again (deleted the generated files) and configured with sh
../gcc-4.1.0/configure --prefix=/home/gcc41 --enable-threads=win32
--with-ld=/mingw/bin/ld --with-win32-nlsapi=unicode and fired make
bootstrap. I think this time make made more than the last time, but ejected
an error again
I might be missing out on something but I get a segmentation fault when
manualy executing omp_hello.f from libgomp testsuite
(libgomp/testsuite/libgomp.fortran/omp_hello.f)...
Compiled using gfortran -static -fopenmp -g omp_hello.f -o omp_hello
Hum... for trunk on i686-linux, I do see the
Hi all,
libgomp currently doesn't configure well on Tru64 (PR
bootstrap/26161), because the configury is testing the usability of
pthread.h system headers, while on Tru64 this can only work when the
compiler is used with the -pthread option.
While this flag could be added on a per-target basis
Hi all,
I'm sending this mail because I'm a bit confused about the
-mlong-double-128 option on (for example) ppc64-linux, and its impact
on gfortran/libgfortran.
When I simply bootstrap a compiler with configure
--with-cpu=default32, I get a gfortran that does only have kind=4 and
kind=8 reals
I guess libgfortran has configury to figure out if kind=16 is available?
Yes.
If so then libgfortran should be built with -mlong-double-128, as this
should only add extra symbols that do not conflict with kind=4 and kind=8
ones.
Hum, that has to be done early in the configury (before all
Having gfortran magically know about certain ABI breaking options, and doing
funny things on certain targets seems a very bad precedent to me.
Then, I think we should have the front-end refuse the option. It's
annoying to have a compiler accept code, and only tell you at runtime
(at the end of
I have got massive FORFRAN test failures on Linux/ia64 and
Linux/x86-64:
http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg00730.html
http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg00729.html
Most of failures look like:
Hi,
I am stuck with PR libfortran/22097 because currently, the libgfortran
configury isn't clever enough to get cabsl (among others) right on
mips-irix6.5. config.h has
#define HAVE_CABSF 1
and
/* #undef HAVE_COMPLEX_H */
while the correct definition of cabsl is provided in complex.h. Can
Testing done on i686-linux (built with --languages=c,fortran and
a shared libgmp in /foo/bar, and regtested).
OK for mainline? OK for 4.0?
ping**3, build machinery maintainers in Cc.
This patch makes --with-gmp and --with-mpfr similar to --with-as and
others, where you don't need to have the
Basic testing done on i686-linux (built with --languages=c,fortran and
a shared libgmp in /foo/bar, and regtested). Extended testing (which
takes ages on my computer) in progress.
OK for mainline? OK for 4.0?
*ping*
This patch has both a toplevel part and a part in gcc/, so I don't
know
Or did I miss the point entirely?
Right now, having the GMP/MPFR libraries (later refered as GMP) in
/home/gmp and typing:
configure --with-gmp=/home/gmp --enable-languages=c,fortran
does configure fine but running make then fails when it attempts to
build libgfortran. This is PR 21547, see
Basic testing done on i686-linux (built with --languages=c,fortran and
a shared libgmp in /foo/bar, and regtested). Extended testing (which
takes ages on my computer) in progress.
OK for mainline? OK for 4.0?
*ping*
This patch has both a toplevel part and a part in gcc/, so I don't
know
You can use make check-target-libgfortran, which is what I thought you
were using to test.
There's no testsuite for libgfortran (the command you mentionned does
not test anything). The only way I'm aware of to run the gfortran
testsuite is make check-fortran inside $builddir/gcc. I think I will
Here is a patch to fix PR libfortran/21547: when building with
--with-gmp=/foo/bar and a shared libgmp in /foo/bar, the
$(RPATH_ENVVAR) variable (usually LD_LIBRARY_PATH) is not set
correctly when using the freshly built gfortran to build libgfortran.
The same thing happens for the gfortran
The newest version of mpfr will build a shared library.
In fact, we should move to using the newest version,
but I think some/many people would object to having two
external library dependencies.
What advantages have the newest version? And (sorry for the obvious
question) why isn't it kept
- with this patch, the libgfortran is built, but the gfortran
testsuite doesn't run; why isn't $(RPATH_ENVVAR) including HOST_LIB_PATH
for the testsuite?
It should
Well, it doesn't. The problem is that the gfortran testsuite is not
run with the toplevel Makefile, but by going into the
PR fortran/18452
* gcc/c.opt: Add a -lang-fortran option.
* gcc/c-opts.c: Add a lang_fortran flag.
(c_common_init_options): Handling the -lang-fortran option.
(c_common_handle_option): Add a case for Fortran options in
preprocessing. Remove cases for
core_rel.f90:179: internal compiler error: in fold_convert, at
fold-const.c:2028
This might be either PR19362 or PR20244 in bugzilla.
FX
Since there is a big brainstorming, I will sum up my opinion here (and
then stop spending time on this issue). From the discussion, it looks
like the switch seems the most important constraint imposed by the switch
is about hardware/software requirements, and I do strongly second this
point.
For
Hi all,
I've been playing with the svn test repo during the last few days,
updating my own (few) scripts and all, and it's been going very
smoothly. The only thing that's worrying me is disk usage.
I do only have small involvement in gcc, preparing few patches (never
more than 5 at a time) on
Not that I know of. As Daniel Berlin said, Subversion 1.4 will probably have
support for checking out repositories with compressed local copies (or no copy
at all -- but I wouldn't suggest this, as you'd start to be slow in svn
diff,
svn stat, etc).
I guess no local copy would be fine with
Patches needed to build on mingw32 include
http://gcc.gnu.org/ml/gcc-patches/2005-08/msg9.html and
http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00097.html . The first
one contains the fix to your problem, the second one is the latest
version of the patch to fix dllimport.
However, on mingw32,
Coming back to this topic.
Nobody has answered to one of my questions: if the mingw/cygwin
maintainers can't approve such a patch, who can?
FX
* builtins.def: Add DEF_EXT_C99RES_BUILTIN to define builtins
that C99 reserve for future use. Use it to define clog10, clog10f
and clog10l.
Ok.
Commited.
Thanks,
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?
Thanks,
François-Xavier
Index: gcc/builtins.def
Knowing that you do regular Cygwin builds of gcc, I wonder can you advise
me, please? For the better part of a month, I have not succeeded in
building gcc from the CVS tree under Cygwin_NT-5.1 for one reason or
another.
That's PR 21766 (appropriately named Bootstrap failure on
85 matches
Mail list logo
