Am 07.01.25 um 17:52 schrieb Jakub Jelinek via Gcc:
But the compiler does in every ICE message in which -freport-bug isn't
enabled.
It seems that -freport-bug does nothing for Fortran, or at least the
Fortran front end (which why it was unfamiliar to me). Grabbing a
random ICE off bugzilla, sli
Am 07.01.25 um 18:04 schrieb Andreas Schwab:
On Jan 07 2025, Thomas Koenig via Gcc wrote:
Side remark (which I will also address): https://gcc.gnu.org/bugs/ does
not mention -freport-bug.
But the ICE message does.
Hm, OK.
Question: Would it make sense to enable -freport-bug by default on
Am 07.01.25 um 16:41 schrieb Thomas Koenig via Gcc:
Thanks for the explanation. I think it might be good to add a bit
of this to the docs. I will prepare a patch.
Side remark (which I will also address): https://gcc.gnu.org/bugs/ does
not mention -freport-bug.
Best regards
Thomas
Am 07.01.25 um 16:14 schrieb Jakub Jelinek via Gcc:
It is "debug information" in the sense that it is everything needed
to debug the ICE.
Which isn't just preprocessed source, but also used compiler options,
and details on how the compiler has been configured and what ICE has been
emitted. Plus,
Am 07.01.25 um 15:48 schrieb Jakub Jelinek:
On Tue, Jan 07, 2025 at 03:45:02PM +0100, Thomas Koenig via Gcc wrote:
Would it be reasonable to dump a preprocessed file (if any) on an ICE,
and point the user to it? The error message could then be something
like "Please submit the preproc
Hello world,
when an ICE occurs somewhere when building a complex software package,
it can be cumbersome for the user to obtain the preprocessed file
that we ask people to submit to us.
Would it be reasonable to dump a preprocessed file (if any) on an ICE,
and point the user to it? The error me
Am 13.11.24 um 15:55 schrieb Toon Moene:
Since the Fortran 95 Standard it does (in the current Standard: 7.4.3.2
Real type):
The real type includes a zero value. Processors that distinguish between
positive and negative zeros shall treat them as mathematically equivalent
• in all intrinsic
Hello world,
J3, the US Fortran standards committee, has passed
https://j3-fortran.org/doc/year/24/24-179.txt
which states (with a bit of an overabundance of
clarity) that, in Fortran, it is possible special-case
complex multiplication when one of the numbers is known
to have a zero component, fo
Am 12.11.24 um 17:25 schrieb Michael Matz via Gcc:
If you think of float as
approximated reals, then yes, division by zero is undefined (not
somewhat undefined!).
Depends on how you look at it.
IEEE 754-2008, for example, says in 7.3
"The default result of divideByZero shall be an ∞ correctl
[For the fortran people: Discussion on gcc@]
Just a general remark.
There are people, such as myself, who regularly mess up
their git repositories because they have no mental model
of what git is doing (case in point: The Fortran unsigned
branch, which I managed to put into an unrepairable state
Am 10.08.24 um 10:17 schrieb Thomas Schwinge:
Hi!
I'm not sure I understand what actually the issue is, but:
On 2024-08-09T20:00:42+0200, Thomas Koenig wrote:
I have managed to bring the fortran-unsigned branch into a state where
First, I see that the upstream devel/fortran_unsigned b
Am 09.08.24 um 21:57 schrieb Dimitar Dimitrov:
You are redoing the rebase again. So it is expected to get the same
warnings.
I need to get the changes from master into my branch, or else
things will not compile due to changes in master. But it seems
that this is no longer possible, thanks to
Am 09.08.24 um 21:17 schrieb Dimitar Dimitrov:
I assume you reset your local branch? The branch on the server does not
seem to be affected. I suggest to rebase the remote branch using
another local branch. Example:
# Just in case, see which is your old local branch.
$ git branch
#
Hi Dimitar,
On Fri, Aug 09, 2024 at 08:00:42PM +0200, Thomas Koenig via Gcc wrote:
Hi,
I have managed to bring the fortran-unsigned branch into a state where
it can no longer be rebased. When I do a
$ git rebase master
It's unknown what is the state of your local master branch. So I
Hi,
I have managed to bring the fortran-unsigned branch into a state where
it can no longer be rebased. When I do a
$ git rebase master
I get
...
warning: skipped previously applied commit a6399bb27b3
hint: use --reapply-cherry-picks to include skipped commits
hint: Disable this message with "
Am 29.07.24 um 22:14 schrieb Thomas Schwinge:
By the way: I did see your recent announcement; wow -- Fortran finally
getting an UNSIGNED type! 🙂
Yep, at lest J3 accepted a propoasl.
I would like to be able to run all
existing Fortran tests also with -funsigned, to make sure the option
does
Am 29.07.24 um 11:22 schrieb Jonathan Wakely via Gcc:
> # If a testcase doesn't have special options, use these.
> global DEFAULT_FFLAGS
> if ![info exists DEFAULT_FFLAGS] then {
> set DEFAULT_FFLAGS " -pedantic-errors"
> }
I tried using that, still saw a lot of errors when compiling
C files.
Hi,
for the fortran-unsigned branch, I would like to be able to run all
existing Fortran tests also with -funsigned, to make sure the option
does not break anything on existing code.
Question is: How?
I came as far as
$ make check-fortran RUNTESTFLAGS="--target_board=unix/-funsigned"
but that
Hi everybody,
now that a proposal for unsigned number inclusion in Fortran has
passed the J3 hurdle, https://j3-fortran.org/doc/year/24/24-116.txt ,
I thought I would put my working hours where my mouth is and try
my hand at a testbed implementation for gfortran. I am still
grateful to Reinhold
Am 25.06.24 um 21:08 schrieb Arsen Arsenović via Gcc:
Richard Biener writes:
I'd welcome this - care to create a patch for
contrib/gcc-git-customization.sh?
Sure - I've attached a partial patch. I didn't find the hook which runs
on each push to check commits, so the current patch is minim
Am 18.04.24 um 01:27 schrieb Mark Wielaard:
We also should make sure that all generated files (either in git or in
the release/snapshot tar balls) can be reliably and reproducibly
regenerated. This also helps the (pre-commit) CI buildbots. We already
have the autoregen bots for gcc and binutils-g
Hi,
is there some sort of concise explanation of how to use the
scripts in contrib/reghunt? There is no real documentation
for what is in the directory, specifically not how to invoke
them, and which directory to invoke them from. I have also
not been able to do run the examples from contrib/reg
Hi Jakub,
It is worse than that, usually the LTO format changes e.g. any time any
option or parameter is added on a release branch (several times a year) and
at other times as well.
Hm, that makes LTO not very well suited for libraries...
Though, admittedly GCC is the single package that act
Hi Toon,
During the GNU Tools Cauldron we discussed (at the BoF: IPA & LTO) the
possibility (and hazards) of building the run time libraries for various
compilers with -flto, enabling an -flto -static linking of programs with
the run time library available during link time optimizations.
Thi
Am 27.07.23 um 15:43 schrieb Michael Matz:
I've recently submitted a patch that adds some attributes that basically
say "these-and-those regs aren't clobbered by this function" (I did them
for not clobbered xmm8-15). Something similar could be used for the new
GPRs as well. Then it would be a
With the upcoming Intel APX extension, Intel processors will
finally gain 32 general-purpose registers and three-operand
arithmetic, see
https://www.intel.com/content/www/us/en/developer/articles/technical/advanced-performance-extensions-apx.html
Intel recommends to have the new registers as cal
Hi,
I'm not sure who on this mailing list reads comp.compilers, but there is
an interesting article about built-in regression search in the go
compiler at https://compilers.iecc.com/comparch/article/23-05-003 .
Using a similar approach could also be interesting for gcc,
complementing tools like
On 13.05.23 02:45, Po Lu via Gcc wrote:
Gabriel Ravier writes:
...You're joking, right ? You can't possibly be seriously arguing
this, you have to be kidding... right ?
No, I'm not. The meaning of a variable declaration with only a storage
class specifier is extremely clear: the type of the
On 12.05.23 09:53, Eli Zaretskii via Gcc wrote:
I described in an earlier message how this breakage looks in real
life, and why it causes a lot of frustration. The main problem is
discovering that things broke because GCC defaults, and then
discovering how to pacify GCC with the least effort.
On 10.05.23 14:03, Jakub Jelinek via Gcc wrote:
We do such changes several times a year, where we reject something that has
been previously accepted in older standards, admittedly mostly in C++.
... and in Fortran.
Not replying to anybody in particular, just a bit of history, with
some potential parallels.
In gfortran, we have had two major issues with interfaces. One was that
code which had happily violated the compiler ABI started failing, due
to a fix in the gfortran front end which meant that we were n
On 30.01.23 23:07, Gerald Pfeifer wrote:
Hmm, so any digit, parenthesis, or bracket in the Subject, and mails gets
to /dev/null?
Sending mail with special graphics in Subject lines is what spammers do,
to attract special attention. (And no, umlauts are not included :-).
So, If I ever happen t
On 30.01.23 14:52, Mark Wielaard wrote:
Hi Steve,
On Sun, 2023-01-29 at 22:27 -0800, Steve Kargl via Gcc wrote:
Please remove the skull and cross bones in the subject line.
That is the default "hazard symbol" buildbot uses if a build turns from
success to failure. If you have a better suggest
On 09.01.23 12:35, Stefan Kanthak wrote:
20 superfluous instructions of the total 102 instructions!
The proper place for bug reports is https://gcc.gnu.org/bugzilla/ .
Feel free to submit these cases there.
On 17.12.22 01:26, NightStrike wrote:
On Fri, Dec 16, 2022 at 1:44 AM Thomas Koenig wrote:
On 16.12.22 03:20, NightStrike via Fortran wrote:
When I run the testsuite under wine, I'm getting a lot of ANSI escape
sequences. We had fixed this long ago, but it seems to be back. Any
idea
Hi Cynthia,
> Hello, my name is Cynthia and I am a Supply Chain Risk Management
> Analyst at NASA. NASA is currently conducting a supply chain
> assessment of gfortran. As stated in Sections 208 and 514 of the
> Consolidated Appropriations Act, 2022, Public Law 117-103,
> enacted March 15, 2022
On 02.01.22 23:58, Thomas Koenig wrote:
Hi Michael,
If you are building libraries that contain modules with multiple long
double
types, you must use the '-mno-gnu-attribute'. We also use the
'-Wno-psabi'
option, which silences the warning that you are switching long dou
Hi Michael,
If you are building libraries that contain modules with multiple long double
types, you must use the '-mno-gnu-attribute'. We also use the '-Wno-psabi'
option, which silences the warning that you are switching long double types (if
glibc is not 2.34 or newer). We may need to tweak
Hi,
looking at what the REAL(KIND=17) numbers should be compiled for, I see
the following options that should be considered:
a) xsaddqp and friends are not supported by the CPU; libquadmath should
be called for all operations, including simple arithmetic.
b) xsaddqp and friends are support
On 05.12.21 01:35, Peter Bergner wrote:
Instead of setting LD_LIBRARY_PATH=/home/tkoenig/lib64 could you try
setting it to LD_LIBRARY_PATH='$ORIGIN/lib64' instead? This would
allow the other system binaries to not find your /home/tkoenig/lib64
directory so they'd behave normally. However, any
On 04.12.21 17:12, Peter Bergner via Fortran wrote:
As long as you keep the AT15 bin path before the system bin dirs, you should
be fine.
OK, what I have now is
tkoenig@gcc-fortran:~$ echo $PATH
/home/tkoenig/bin:/opt/at15.0/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/u
On 04.12.21 11:29, Jakub Jelinek wrote:
If zlib devel isn't installed, drop --with-system-zlib option
or use --without-system-zlib.
You've asked in another mail how to configure gcc to default to
-mabi=ieeelongdouble, that is
--with-long-double-format=ieee
Thanks for those hints.
I have now m
On 04.12.21 07:39, Michael Meissner via Fortran wrote:
I have loaded Advance Toolchain 15.0 on the system. It is located in
/opt/at15.0. AT 15 provides a GCC 11.2 compiler and GLIBC 2.34.
I tried bootstrapping (from a separate account I set up on the
machine to make sure I don't mess up any
Hi,
I have loaded Advance Toolchain 15.0 on the system. It is located in
/opt/at15.0. AT 15 provides a GCC 11.2 compiler and GLIBC 2.34.
Thanks!
I built a trunk compiler using the options:
--enable-languages=c,c++,fortran \
--disable-plugin \
--enable-checking
Hi Jakub,
Note, we want to test both building gcc on ppc64le with older glibc
and newer glibc (and that libgfortran will have the same ABI between both
and one can move gcc including libgfortran and libquadmath from the older
glibc setup to newer and make -mabi=ieeelongdouble work in Fortran t
On 03.12.21 10:28, Jakub Jelinek wrote:
On Fri, Dec 03, 2021 at 08:29:53AM +0100, Thomas Koenig wrote:
On 01.12.21 21:54, Jakub Jelinek via Fortran wrote:
Inside of libgfortran, I think it should depend on some macro defined
in libgfortran.h.
#if defined(__powerpc64__) && __BYTE
On 01.12.21 21:54, Jakub Jelinek via Fortran wrote:
Inside of libgfortran, I think it should depend on some macro defined
in libgfortran.h.
#if defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ \
&& defined __GLIBC_PREREQ && __GLIBC_PREREQ (2, 32)
then
#define MATHFUNC(f
I am currently working on implementing the IEEE 128-bit floating
on POWER. One of the things to decide is what to call the
math functions for the library calls.
Example: libgfortran/generated/bessel_r16.c currently has
#if defined(GFC_REAL_16_IS_FLOAT128)
#define MATHFUNC(funcname) funcname ##
... which has been resolved. There was a stray semicolon in
quite another place which led to this error.
Thanks to Andreas for finding this so quickly!
Best regards
Thomas
On 29.11.21 20:42, Florian Weimer via Fortran wrote:
What's the whitespace situation? Usually the error means that the
recipe is indented using spaces instead of tab.
The error is on the line
$(i_matmulavx128_c): m4/matmulavx128.m4 m4/matmul_internal.m4 $(I_M4_DEPS)
where there is no whit
... in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103476, a very
strange error where an invalid Makefile is generated with
--enable-maintainer-mode on POWER.
I'm not sure how to proceed from here. Maybe somebody
with more make debug fu could take a look?
Best regards
Thomas
Hi Jakub,
On Sat, Oct 30, 2021 at 11:30:29AM +0200, Thomas Koenig wrote:
- Have a compiler switch which selects between IEEE_QP and IBM_QP.
This was a suggestion by Steve Lionel formerly of DEC and Intel,
and they did that when they had a few floating point formats on
the Alpha to
Hi Michael,
It adds target hooks so the back end can overwrite the kind number for types.
I made the IBM long double type use KIND=15 instead of KIND=16, and Float128
uses KIND=16 as we've discussed. The tests for long double are still
failing, so I suspect we will need some way of signalling
Hi Michael,
I tried this out on the one POWER machine where I can get something
installed :-) It runs Ubuntu 20.04, but does not appear to have the
right glibc version; it has
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 20.04.1 LTS
Release:
On 15.10.21 20:11, Jakub Jelinek wrote:
On Fri, Oct 15, 2021 at 08:05:38PM +0200, Thomas Koenig wrote:
with -mabi=ibmlongdouble, I see 31 and 291, while with -mabi=ieeelongdouble
33 and 4931. The 0.0_8 precision/range values are 15 and 307, so neither
precision of C long double if it is
On 15.10.21 16:20, Jakub Jelinek wrote:
[...]
when one compiles
integer function foo ()
foo = precision (0.0_16)
end function foo
integer function bar ()
bar = range (0.0_16)
end function bar
with -mabi=ibmlongdouble, I see 31 and 291, while with -mabi=ieeelongdouble
33 and 4931. The 0
On 09.10.21 01:18, Iain Sandoe wrote:
I meant the case where the user writes, with an old, KIND=16 is double
double compiler,
subroutine foo(a)
real(kind=16) :: a
a = a + 1._16
end subroutine foo
and puts it in a library or an old object file, and in new code with an
IEEE QP compi
Hi Iain,
Things get interesting for user code, calling a routine compiled
for double double with newer IEEE QP will result in breakage.
That would not happen with the proposal above, since the library would
have different entry points for the two formats.
I meant the case where the user wri
Hi Iain,
If one wanted to prioritize library SO name stability - then, perhaps, the
approach Jonathan mentioned has been used for libstdc++ (add new
symbols for ieee128 with a different mangling to the existing r/c_16 ..)
would be preferable (the FE then has to choose the relevant symbol/
mangli
On 07.10.21 17:33, Jakub Jelinek wrote:
It will also be a compatibility issue if users have code compiled on a LE
system with GCC 11 and earlier with KIND=16, it will not link with GCC 12.
libgfortran ABI changed multiple times in the past already, e.g. the
so.1 -> so.2 transition in 4.2
so.2
On 07.10.21 05:35, Michael Meissner via Fortran wrote:
I tried this at one point. There are a lot of hidden assumptions that the kind
number is the number of bytes. I'm sure it can be tracked down, but the
problem is with these assumptions is you can't prove a negative (i.e. you never
know that
On 05.10.21 23:54, Segher Boessenkool wrote:
Hi!
On Tue, Oct 05, 2021 at 10:16:47PM +0200, Thomas Koenig wrote:
On 04.10.21 16:14, Jakub Jelinek via Fortran wrote:
Based on some IRC discussion, yet another option would be bump libgfortran
SONAME (on all arches), make real(kind=16) on
On 04.10.21 16:14, Jakub Jelinek via Fortran wrote:
Based on some IRC discussion, yet another option would be bump libgfortran
SONAME (on all arches), make real(kind=16) on powerpc64le-linux mean
always IEEE quad (starting with GCC 12) and if wanted add support for
real(kind=15) meaning double
Hi,
I just got an error when accessing the gcc git pages at
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git , it is:
This page contains the following errors:
error on line 91 at column 6: XML declaration allowed only at the start
of the document
Below is a rendering of the page up to the first er
On 16.07.21 20:22, Sandra Loosemore wrote:
So it seems to me rather surprising to take the position that we should
not be committing any new test cases that need to be XFAILed
It is what I was told in no uncertain terms some years ago, which
is where my current state of knowledge comes from.
S
Hello world,
realising that my e-mails may have done more harm than good,
I will now unsubscribe from the gcc mailing list, so please
don't expect a reply unless you copy me in.
Best regards
Thomas
On 16.04.21 10:54, Iain Sandoe via Gcc wrote:
This forum (barring the current discussion where, frankly, the dissent
is not
coming from people who are actually active contributors),
Maybe I should have been less diplomatic :-)
I dissent, strongly.
From the discussion, it seems that there is concern about some of the
the technical directions imposed on gcc by the FSF. If we want to
resolve the current crisis without causing a fatal split within the
gcc community, we need a way at least to address those.
Therefore, a proposal for a procedur
David,
for some reason or other, I did not get your mail, so I will
just reply copying in from the archive.
First, thanks for injecting some sanity into the discussion.
I will not discuss RMS' personal shortcomings or the lack of them.
In today's toxic political climate, such allegations are of
My 0.02 Euro-Cent:
There is a minor problem with contributors being overly harsh/
borderline abusive on the mailing list. In my > 15 years with
the project, I have only had that problem with one single
person, and I have resolved that by never again touching the
system that particular person is
On 14.04.21 16:49, Jonathan Wakely via Gcc wrote:
On Wed, 14 Apr 2021 at 15:39, Thomas Koenig wrote:
On 14.04.21 15:18, Eric S. Raymond wrote:
A strong norm about off-list behavior and politics being
out of bounds here is also helpful.
That would have banned the whole discussion about the
On 14.04.21 15:18, Eric S. Raymond wrote:
A strong norm about off-list behavior and politics being
out of bounds here is also helpful.
That would have banned the whole discussion about the potential
fork from the start.
On 14.04.21 09:57, Jonathan Wakely wrote:
On Wed, 14 Apr 2021 at 08:46, Thomas Koenig via Gcc wrote:
There is no discussion at the moment. Most people on the fortran
mailing list do not follow gcc. I know of at least two contributors
(myself incluced) who would in all probability stop
On 14.04.21 01:41, Jeff Law wrote:
On 4/13/2021 11:32 AM, Thomas Koenig via Gcc wrote:
On 13.04.21 19:19, Jeff Law via Gcc wrote:
I'm not sure there'll be that much of a community split. Based on
what I've seen *so far* it'd be less of a split than we had with
EGCS.
On 13.04.21 19:19, Jeff Law via Gcc wrote:
I'm not sure there'll be that much of a community split. Based on what
I've seen *so far* it'd be less of a split than we had with EGCS. But
that's precisely why I want folks to chime in, particularly those doing
the day-to-date development work --
On 13.04.21 16:40, Jeff Law via Gcc wrote:
An EGCS-like split like we had in the late 90s is, IMHO, a definite
possibility here
Such a move would, in all probability, leave both parts of the split
GCC with too few developers to compete against LLVM, thus rendering
GCC irrelevant and ruining an
On 12.04.21 11:32, Richard Biener via Gcc wrote:
Please concentrate on the important things, we're supposed to get a
release of GCC 11 out of the door.
Amen.
On 01.04.21 22:33, Joseph Myers wrote:
And while in that case RMS probably learned of modules and libcody through
the SC mailing list, in general he has this habit of asking GNU package
developers random questions related to their packages.
I've been asked a few questions about gfortran by ra
Hi,
I committed a test case for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67539
with
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=80198c701a7fc09e736ccffe470ee5033ca59a69
but that commit did not make it into the PR, I put it
in by hand.
I had this problem previously, then it was thought t
Hi Tobias,
which binutil version do you have?
$ as -v
GNU assembler version 2.35.1 (x86_64-suse-linux) using BFD version (GNU
Binutils; openSUSE Leap 15.1) 2.35.1.20201123-lp151.3.12
I am asking because Jakub just
submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564206.
Hi Tobias,
Does this constitute a regression?
From your description, yes. Can you give more details how to reproduce it?
$ cat hello.f90
print *,"Hello, world!"
end
$ valgrind --version
valgrind-3.15.0
$ gfortran -g hello.f90
$ valgrind ./a.out
[...]
--4184-- WARNING: Serious error when
Hi Tobias,
On 08.12.20 19:34, Thomas Koenig via Fortran wrote:
I would like to know the name of a variable created with
create_tmp_var_raw, but it is not clear to my how to do it.
...
t = create_tmp_var_raw (type, prefix);
-
+ dprintf (2, "%s\n", IDENTIFIER_POINTER (DECL_NAME
Hi,
I would like to know the name of a variable created with
create_tmp_var_raw, but it is not clear to my how to do it.
gimple_decl_printable_name sounded like a likely candidate,
but that just returns a null pointer. Any combination of
IDENTIFIER_POINTER and DECL_NAME that I tried also led to
Hi,
it seems that git commits are no longer automatically transferred
to the relevant PRs.
Recent example: I don't see
https://gcc.gnu.org/pipermail/gcc-cvs/2020-December/338684.html
in PR98156, although the ChangeLog was
Upper cobound is determined by num_images(), not this_image().
Am 27.11.20 um 00:50 schrieb Jonathan Wakely via Gcc:
Does anybody object to raising the line length for libstdc++ code
(not the rest of GCC) to 100 columns?
In gfortran, we have a habit of using long and expressive function
names (which is good) which lead to lots of columns of indentation,
wh
Hi,
Don't use git gcc-verify for development branches or user branches,
it checks the rules required for release branches and the trunk only.
Other branches have different rules.
Thanks to everybody for their help.
I have now pushed the merge to the branch successfully. I'm glad
that the par
I tried to update the coarray_native branch to current master with
"git merge master" as given by
https://gcc.gnu.org/gitwrite.html#branches
That worked without any error message.
Next, I tried to verify that a "git push" would succeed, and
got an error:
$ git gcc-verify
Checking bf6dad60c338a
Am 24.10.20 um 01:29 schrieb David Edelsohn via Fortran:
The GNU Compile Farm has a wide variety of systems on which you can
test bootstrap.
I tried bootstrapping gcc (current trunk) on every BSD system (the BSD
variants probably being the most relevant systems, apart from Linux) on
the gcc com
Hi Iain,
If the last node in the list is void_list_node (a TREE_LIST node whose
TREE_VALUE is the void_type_ node), then functions of this type do not
take variable arguments. Otherwise, they do take a variable number of
arguments.
> HTH
That does help, a lot.
It means that this decl is
Hi,
I am currently trying to get the argument lists for calling
intrinsic functions right, and I have run across something in a
tree I do not understand.
The declaration is:
unit-size
align:32 warn_if_not_align:0 symtab:0 alias-set -1
canonical-type 0x7feefcfec5e8 pre
Hello world,
for review of its patches, gfortran relies on a group of people
who can approve patches. Unfortuntately, many of them are not
active. Others, who have the capability and who have acted as
de facto approvers (without anybody minding) are missing.
This (somewhat overdue) patch rectif
Am 09.09.20 um 17:36 schrieb Segher Boessenkool:
You can use both __ibm128 and __ieee128 in one program, so it isn't an
ABI change. Only the default of what "long double" means changes. And
we have been there before, there is the "e" mangling as well...
For Fortran, it is an ABI change unless
Hi Andreas,
make: *** No rule to make target
'../build-x86_64-pc-linux-gnu/libiberty/libiberty.a', needed by
'build/genmodes'. Stop.
Looks like you didn't run make in the toplevel. This is created by the
all-build-libiberty target.
That would have been strange, especially since there is no
Hi,
I recently updated a branch which tracked master to current HEAD, and
got a compilation failure with --enable-maintainer-mode (see PR 96735):
make: *** No rule to make target
'../build-x86_64-pc-linux-gnu/libiberty/libiberty.a', needed by
'build/genmodes'. Stop.
Switching the branch to
Hi Chung-Lin,
I think you need to initialize the 'vec extrema' field with
vNULL,
or maybe some other constructor.
Thanks, I'll give it a try.
Regards
Thomas
Hi,
in a patch I am developing, I have the following code:
typedef struct {
gfc_code *c;
int branch_level;
bool seen_goto;
vec extrema;
} do_t;
static vec doloop_list;
[...]
do_t loop;
doloop_list.safe_push (loop);
doloop_list.last().extrema.reserve (1 << doloop_level);
wher
Jonathan,
now I remember, it was PR82856 which prompted this
change (and I put in the wrong version number :-)
Looking back at that PR, the uppper level of Perl as reqirement can
probably be lifted.
I would still prefer a test with --enable-maintainer-mode, to test
that the orginal bug has actu
Hi Jonathan,
On the page https://gcc.gnu.org/install/prerequisites.html it says:
Perl version between 5.6.1 and 5.6.24
Necessary when targeting Darwin, building ‘libstdc++’, and not using
--disable-symvers. Necessary when targeting Solaris 2 with Solaris ld and
not using --disable-symvers.
Ne
Am 18.06.20 um 20:34 schrieb Jonathan Wakely via Gcc:
On Thu, 18 Jun 2020 at 19:22, Thomas Koenig via Gcc wrote:
Hi,
I just found a few unversioned files called .intrinsic.c.swp and
similar in my "git status" output.
Could somebody please put .*.swp into .gitignore? I'm
Hi,
I just found a few unversioned files called .intrinsic.c.swp and
similar in my "git status" output.
Could somebody please put .*.swp into .gitignore? I'm sure this
would save at least 10 reverts :-)
Regards
Thomas
1 - 100 of 209 matches
Mail list logo
