Hi,
since the change to the new list management, there has been
an uptick of spam getting through. Spam is bounced by my ISP,
and this just resulted in a warning that there were too many
bounces and that I would get removed from the list unless I
confirmed it (which I then did).
So, a request:
Of course, better would be to remove ChangeLogs entirely (including not
putting anything like them into a commit message), because they are
largely not useful and are just make-work.
I disagree. I find them quite useful.
Hi,
I have a test case which does a double free on a pointer,
at runtime. I have to narrow it down a bit before
comitting, but it indicates a regression.
Assuming I put this into the testsuite, how can I make sure
that this actually fails if the problem ever re-occurs?
Is there a combination
Hi Martin,
Thanks to Jakub, we finally set up an experimental environment:
gcc.gnu.org/home/gccadmin/gcc-reposurgeon-8.git
How does one go about testing this? It would be helpful if you
could explain this assuming that the Fortran people have at best
an extremely shallow knowledge of git and
Hi,
since the change to the new list management, there has been
an uptick of spam getting through. Spam is bounced by my ISP,
and this just resulted in a warning that there were too many
bounces and that I would get removed from the list unless I
confirmed it (which I then did).
This has now
Am 21.03.20 um 21:29 schrieb Frank Ch. Eigler via Gcc:
Hi -
since the change to the new list management, there has been
an uptick of spam getting through. Spam is bounced by my ISP,
and this just resulted in a warning that there were too many
bounces and that I would get removed from the list
Am 21.05.20 um 13:05 schrieb Andreas Schwab:
On Mai 21 2020, Thomas Koenig wrote:
An error message or warning from git might have been nice, though.
How can it know?
Obviously, reverting the already applied patch was a no-op.
I would assume that git noticed that, and could issue a message
What is the current established way of reverting a patch, with
the current state of the tools?
I did
$ git revert r9-8541-g2a732dbdfcc0a3bc2b4bdb5387fffa193fea6df6
on origin/releases/gcc-9, and now only the ChangeLog entries reversed
(which is not wanted), but the code is unchanged (which is
Am 21.05.20 um 11:45 schrieb Andreas Schwab:
On Mai 21 2020, Thomas Koenig via Gcc wrote:
$ git revert r9-8541-g2a732dbdfcc0a3bc2b4bdb5387fffa193fea6df6
on origin/releases/gcc-9, and now only the ChangeLog entries reversed
(which is not wanted), but the code is unchanged (which is even
less
Hi Andreas,
git is not doing a plain patch, it is doing a merge. It is not unusual
for a merge to have changes that are already present on both sides.
... which just goes to show that it is very easy to make a fool of
yourself with git if you have no mental model of what it does.
That's not
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
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
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 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 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
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
Hi Martin,
On 5/27/20 4:13 PM, Martin Liška wrote:
Yes, I'm aware of the limitation and let me do it now.
I've just backported the script to all active branches.
Please try it.
Works without a hitch, thanks! I have just successfully pushed r9-8628
to the gcc-9 branch.
Regards
Hi Martin,
currently, doing git gcc-backport from a gcc9 branch results in
$ git gcc-backport r11-588-g8df7ee67f6fdc780e9453f2baa8d1bf62c000761
environment: /home/ig25/Gcc/gcc9/contrib/git-backport.py: No such file
or directory
Would it make sense to push the git-backport.py file to the
Am 26.05.20 um 00:48 schrieb Jakub Jelinek via Gcc:
I've turned the strict mode of Martin Liška's hook changes,
This means that it is no longer possible to do a git gcc-backport
followed by a git push. If there is a procedure for this, it
is not documented on
Am 26.05.20 um 11:04 schrieb Thomas Koenig via Gcc:
Am 26.05.20 um 00:48 schrieb Jakub Jelinek via Gcc:
I've turned the strict mode of Martin Liška's hook changes,
This means that it is no longer possible to do a git gcc-backport
[CC'ing fortran to warn other people against currently
Hi Martin,
For now, I would recommend doing 1:1 backports. Otherwise, you'll need
to merge
all ChangeLog entries in a format the server hook accepts. That can
require some
work.
If the first commit caused a regression, which the second one fixed,
this would keep the first regression, right?
Hi,
I just noticed that the convention for dump file names appears
to have changed. Previously, "gfortran -fdump-tree-original hello.f90"
resulted in the file hello.f90.004t.original being generated, now
it is a-hello.f90.004t.original .
I assume this is intentional. Does the letter prefix
Am 01.06.20 um 14:20 schrieb Jonathan Wakely via Gcc:
It will only "keep" it for a matter of seconds, between that
backported commit and the backported fix. And unless you push the
first commit before pushing the fix, nobody will ever see the
regression without also seeing the fix (unless they
Hi Jakub,
On Tue, May 26, 2020 at 12:42:41PM +0200, Thomas Koenig wrote:
So, two questions:
- How do I get my gcc-10 branch back into a consistent state?
That works, thanks.
git reset --hard origin/releases/gcc-10
should do it (if you want to throw all your local changes).
- How are
Hi,
what's currently in trunk (as of a few hours ago) fails for me with
File "contrib/mklog.py", line 36, in
from unidiff import PatchSet
ModuleNotFoundError: No module named 'unidiff'
I think this is an error which would have to be taken into account
one way or another - maybe include
Hm, one question: I find the r11-1234 type commit to be much more
readable, in ChangeLog files and everywhere else.
Would it be possible to have that format instead of
"cherry picked from commit $HEX_SOUP" ?
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
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
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 sure
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
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.
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
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().
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
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 (t)));
I
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,
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
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
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
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:
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
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
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
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
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 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.
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 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 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 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 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
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
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
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. But that's precisely
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
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
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 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
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
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/
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
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
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
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
... 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
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
... 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
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 \
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
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
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
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 double
types (if
glibc
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 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
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:
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 ##
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
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,
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_ORDER__ ==
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
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
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.
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
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.
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
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,
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 what
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
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
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
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
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
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.
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
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.
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
Hi Paul,
***ping***
OK. Thanks for the patch!
Regards
Thomas
1 - 100 of 432 matches
Mail list logo
