rrays are auto
rather than static, you probably need to use the -mstackrealign and
-mpreferred-stack-boundary=16 as well.
It might be nice to think about an option that automatically aligns large
arrays without having to do the declaration (or even have the vectorizer
override the alignment for stati
There are 18 different ports that support 'extv' or
'extzv' in some fashion, and 20 different ports that support 'insv'.
--
Michael Meissner, AMD
90 Central Street, MS 83-29, Boxborough, MA, 01719, USA
[EMAIL PROTECTED]
maintainer responsible for a machine with an
unofficial e_machine number should eventually ask [EMAIL PROTECTED] for
an officially blessed number to be added to the list above. */
--
Michael Meissner, AMD
90 Central Street, MS 83-29, Boxborough, MA, 01719, USA
[EMAIL PROTECTED]
the global variables with the GTY(()) macro.
I would suggest having the JUMP insn patterns look like other ports, using the
IF_THEN_ELSE pattern, and then add the full COND_EXEC support.
--
Michael Meissner
email: [EMAIL PROTECTED]
http://www.the-meissners.org
racked?
> How gcc can know that free() is not supposed to be used like that?
Unless you use the -ffreestanding or -fno-builtin switches, the compiler is
free to know about any function mentioned in the ISO C standard (or C++,
etc. depending on your language).
--
Michael Meissner
email: [EMAIL PROTECTED]
http://www.the-meissners.org
On Tue, Jul 01, 2008 at 11:37:05AM +, Joseph S. Myers wrote:
> On Tue, 1 Jul 2008, Michael Meissner wrote:
>
> > On Tue, Jul 01, 2008 at 11:50:58AM +0200, Denys Vlasenko wrote:
> > > On Tuesday 01 July 2008 09:24, Sajish V wrote:
> > > > Thanks for the repl
bute stuff which now calls the optimzie attribute, which in turn
needs to call the parts of OVERRIDE_OPTIONS that are safe to do more than once
(adding a SECONDARY_OVERRIDE_OPTIONS).
Mea culpa. I'm sorry for problems I've caused with the addition of function
specific optimizations.
--
Michael Meissner
email: [EMAIL PROTECTED]
http://www.the-meissners.org
On Thu, Jul 24, 2008 at 12:48:30PM -0700, Daniel Berlin wrote:
> The easiest way to not delete trunk is to not delete trunk.
Yes of course, but mistakes do happen.
--
Michael Meissner
email: [EMAIL PROTECTED]
http://www.the-meissners.org
eware.org/ml/libc-alpha/2008-04/msg00050.html
--
Michael Meissner
email: [EMAIL PROTECTED]
http://www.the-meissners.org
is if the backend has added the support. Right
now, the i386/x86_64 backend has this support, and I'm working on the PowerPC
support for it.
--
Michael Meissner
email: [EMAIL PROTECTED]
http://www.the-meissners.org
checked in before he
left. I have been told by my management to either resurrect the patches, or
create new patches to fix the backends. Can you remind me what changes need to
be made? Sorry about this confusion.
--
Michael Meissner, AMD
90 Central Street, MS 83-29, Boxborough, MA, 01719, USA
[EMAIL PROTECTED]
nt function.
rs6000: Wants to know if the function is prototyped and wants to know if a
function is a variable argument function. It also has a simple loop to check
the arguments that could use nth_parm_type.
sh: Wants to know if the function is prototyped.
sparc: Wants to know if the function
rg_p, prototype_p,
etc. to the tree.
2) Change the back ends, 1 by 1 to use the new infrastructure support.
3) Change the front ends, 1 by 1 to use the new infrastructure support.
4) Remove/rename TYPE_ARG_TYPES, and fix any random breakage.
5) Switch the infrastructure underneath to use vector
On Wed, Jun 20, 2007 at 10:47:00AM -0700, Mark Mitchell wrote:
> Michael Meissner wrote:
>
> > I think a gradual approach is the right way. I think this can be done in
> > the
> > stage 2 time frame, but it could be pushed to gcc 4.4 (but we will have the
> > same
I submitted the first patch for the function argument infrastructure change
over at gcc-patches: http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01569.html
--
Michael Meissner, AMD
90 Central Street, MS 83-29, Boxborough, MA, 01719, USA
[EMAIL PROTECTED]
ackages or somehow
your compilation system is messed up. Stdarg.h should be installed in the
private diretory the compiler keeps its own include files (different revs of
GCC have needed different stdarg.h's in the past, so it is compiler specific).
For example on my Fedora 6 system it is in:
/
is a
> 32 bit operation, but shouldn't the compiler then up convert that to a
> 64 bit unsigned long?
'1' has signed int type (which on x86_64 is 32-bits), so (1 << 31) is a signed
int type and is negative. If you use 1LU instead of 1, then it is an unsigned
64-bit typ
ings, I would respond that changing the license terms *IS
A MAJOR THING*, and it furthers the political goals of the FSF.
Note, while disclaimers are generally implied, I must stress that in this
particular case, it is my opinion, and not necessarily the view of my
employer.
--
Michael Meissner, AMD
90 Central Street, MS 83-29, Boxborough, MA, 01719, USA
[EMAIL PROTECTED]
t for the SPU, which I needed to investigate the
builtins. Now that SSE5 is winding down, I can go back to this patch. Given
it has been reviewed in this list, I will leave it to Mark to decide whether it
should go into 4.3 or 4.4.
--
Michael Meissner, AMD
90 Central Street, MS 83-29, Boxborough, MA, 01719, USA
[EMAIL PROTECTED]
CK_SPACE_ABI), and if the old macro
is defined, code the new macro calling the earlier macro. This way you can
avoid changing the other backends. Otherwise, you probably need to work with
each maintainer to make sure you haven't broken their code.
--
Michael Meissner, AMD
90 Central Street, MS 83-29, Boxborough, MA, 01719, USA
[EMAIL PROTECTED]
reat job on the performance front. Our
posted benchmark results are at http://developer.amd.com/gcc.
--
Michael Meissner, AMD
90 Central Street, MS 83-29, Boxborough, MA, 01719, USA
[EMAIL PROTECTED]
have a multibyte encoding
that used " or ' as the second byte. ISO 2022-JP was certainly one of the
encodings that were talked about in the meetings.
--
Michael Meissner, AMD
90 Central Street, MS 83-29, Boxborough, MA, 01719, USA
[EMAIL PROTECTED]
de, double is aligned on a 4 byte boundary, not an 8
byte boundary, unless you use -malign-double, which breaks the ABI. This has
been a 'feature' of the original AT&T 386 System V ABI that Linux uses for
32-bit x86 processors. With the SCO mess, it may be hard to ever change tha
ield);
if (TARGET_64BIT || TARGET_ALIGN_DOUBLE)
return computed;
mode = TYPE_MODE (TREE_CODE (type) == ARRAY_TYPE
? get_inner_array_type (type) : type);
if (mode == DFmode || mode == DCmode
|| GET_MODE_CLASS (mode) == MODE_INT
|| GET_MODE_CL
, I will make a
branch for that. I and H. J. will be maintainers of the branch, and I would
imagine we will do merges from the official 4.2/4.1 branches.
svn+ssh://gcc.gnu.org/svn/gcc/branches/ix86/gcc-4_1-branch
svn+ssh://gcc.gnu.org/svn/gcc/branches/ix86/gcc-4_2-branch
--
Michael Meissner, AMD
ay on vacation from December 3-8th, and not reading mail during
that time.
--
Michael Meissner, AMD
90 Central Street, MS 83-29, Boxborough, MA, 01719, USA
[EMAIL PROTECTED]
interrupt handlers. The way we do it already
> is to look at DECL_ATTRIBUTES of the tree to figure this out. You
> would have to munge in the attributes into the DECL_ATTRIBUTES and the
> check later when you do the same but I guess you know that already.
Yes, though some of the work will be g
expert but there might be other folks on
> the list who might have better ideas about how to implement this.
I must admit I hadn't thought much about debugging. I guess I was assuming the
cloning that we already support in the compiler had solved the debug problem,
but that is a whole other d
On Thu, Nov 29, 2007 at 12:58:55PM +0100, Sylvain Pion wrote:
> Michael Meissner a écrit :
> >One of the things that I've been interested in is adding support to GCC to
> >compile individual functions with specific target options. I first
> >presented a
> >draf
On Thu, Nov 29, 2007 at 01:29:51PM -0700, Weddington, Eric wrote:
>
>
> > -Original Message-
> > From: Michael Meissner [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, November 28, 2007 1:58 PM
> > To: gcc@gcc.gnu.org; [EMAIL PROTECTED]
> > Cc: [EM
nctions are a hack, and think execv*
is better (where you pass the arguments & environment as a vector of char *),
but that is how the function is defined.
--
Michael Meissner, AMD
90 Central Street, MS 83-29, Boxborough, MA, 01719, USA
[EMAIL PROTECTED]
is is very space inefficient.
> This might preclude my earlier statement.
>
> >
> > The idea is to make use of the debugging information as provided by
> > the inline-cloner.
>
> All I wanted was the requirement of debug information consistency to
> be a part of the proposal for the inline cloner.
>
> cheers
> Ramana
> >
> > > cheers
> > > Ramana
> >
> > Karthik
> >
>
>
>
> --
> Ramana Radhakrishnan
> GNU Tools
> Celunite Inc.
>
>
--
Michael Meissner, AMD
90 Central Street, MS 83-29, Boxborough, MA, 01719, USA
[EMAIL PROTECTED]
On Fri, Nov 30, 2007 at 12:17:25AM +0100, Andreas Schwab wrote:
> "Michael Meissner" <[EMAIL PROTECTED]> writes:
>
> > These system calls are part of the Opengroup standard for UNIX (which Linux
> > adheres to), and they have been around for many years. At this
On Thu, Nov 29, 2007 at 03:18:01PM -0800, Joe Buck wrote:
> On Thu, Nov 29, 2007 at 05:44:02PM -0500, Michael Meissner wrote:
> > On Thu, Nov 29, 2007 at 05:39:33PM +0100, Paolo Bonzini wrote:
> > > >The more easy specification will be
> > > >
> > > >
7;t need the switch in this case. The -mlittle-endian switch is available on
ports that support both little endian and big endian, such as the ARM, MIPS,
POWERPC, etc.
--
Michael Meissner, AMD
90 Central Street, MS 83-29, Boxborough, MA, 01719, USA
[EMAIL PROTECTED]
support TImode on 32-bit systems. Some
parts of GCC require a supported integer that is the same size as basic types.
If somebody is motivated to do that work, that is fine, but I'm not planning to
do that work.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, M
;g" if long double is IBM
long double "u12_ieee128_ld"if long double is IEEE
__float128 "u9__ieee128"
__ibm128"g"
If we decide to change the __ibm128 mangling (or the long double when long
double i
version of libgfortran, but we would
> have to restrict that to POWER (would that be possible?).
> We cannot impose an ABI change on everybody else to this.
We do annotate each function that has long double arguments or returns long
double arguments already with gnu attributes. There are some issues with it,
and I want to delve into it deeper.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797
On Wed, Sep 09, 2020 at 02:42:36PM +0100, Jonathan Wakely wrote:
> Sorry for the slow reply to this.
>
> On Fri, 7 Aug 2020 at 22:14, Michael Meissner wrote:
> >
> > One issue with doing the transition is what mangling should be used with the
> > new long double.
the same type node and TFmode as long double uses if the default for long
double is IEEE 128-bit.
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554765.html
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1
On Mon, Sep 28, 2020 at 04:38:51PM +, Joseph Myers wrote:
> On Thu, 24 Sep 2020, Michael Meissner wrote:
>
> > As per the discussion in this thread, I did decide to keep things to two
> > types
> > within the compiler. This means that an explicit __float128 or _Fl
On Tue, Sep 29, 2020 at 05:34:55PM +0100, Jonathan Wakely wrote:
> On Mon, 28 Sep 2020 at 23:15, Joseph Myers wrote:
> >
> > On Mon, 28 Sep 2020, Michael Meissner via Gcc wrote:
> >
> > > > I'm not sure which patch in the series is supposed to be implemen
support for the
LE systems. If there is BE glibc support, we could certainly add support for
enabling IEEE 128-bit in BE systems if the compiler was configured for power8
or higher.
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
ld be nice if
any distro that changed the default used power9 as a base, instead of power8.
> Converting double-double to IEEE QP should not be hard or slow?
There are a lot of corner cases to get it right. IIRC, there are a few values
that double double can represent that are not expressable with exact precision
in IEEE 128-bit.
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
On Thu, Oct 07, 2021 at 08:08:21AM +0200, Thomas Koenig wrote:
> 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
ailures, due to
libgfortran still being marked as IBM long double and the fortran modules are
marked as IEEE long double.
Right now, the only way to avoid these things is to build the entire toolchain
defaulting to IEEE 128-bit.
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 014
thought it would be useful to share what I've done.
> From 443773ac040383311384577b48ecc0bd957ff328 Mon Sep 17 00:00:00 2001
> From: Michael Meissner
> Date: Thu, 28 Oct 2021 23:23:53 -0400
> Subject: [PATCH] Initial patch for PowerPC Fortran KIND=16
This is a work in progress pa
ies, because I get messages like you get.
I have a new version of the patch that makes new target hooks to allow the
backend to specify KIND numbers for types. I choose kind=16 to always be IEEE
128-bit, and kind=15 to be long double if long double is IBM (since I
discovered yesterday, Fortran n
d glibc 2.34
or later.
> From 80d617264d80eb86806aecb2db5f37adb9b37ff6 Mon Sep 17 00:00:00 2001
> From: Michael Meissner
> Date: Fri, 29 Oct 2021 18:35:42 -0400
> Subject: [PATCH] Second patch for PowerPC Fortran KIND=16.
This replaces the first patch, and it is a work in progress. This patch
adds three target
On Mon, Nov 01, 2021 at 10:56:33AM -0500, Bill Schmidt wrote:
> Would starting from Advance Toolchain 15 with the most recent glibc make
> things easier for Thomas to test?
The problem is gcc135 runs Centos 7.x which is not compatible with AT 13-15.
--
Michael Meissner, IBM
PO Box 98
that is pointed to
# is incomplete. The msgfmt program then aborts because it doesn't have the
# right symbols. This script allows us to not use those environment variables.
unset LD_LIBRARY_PATH
unset RPATH_ENVVAR
for x in /usr/local/bin /usr/bin /bin; do
if [ -x "${x}/msgfmt"
in is to get access to newer libraries. I don't know
Ubuntu at all, but I believe the version that is installed is too old to have
the necessary changes in it. There isn't a LTS (long time support) version of
Ubuntu yet available that has the library. There are newer versions that
are
ubious joys of dynamic linking and use
> -static-libgfortran instead.
Yes, I tend to use -static-libgfortran for running Fortran spec things, and
-static-libstdc++ for C++, since it can be a quaqmire getting the right library
when you have several libraries on the system.
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
y to force long double to be IBM 128-bit, no matter what the defaults
are use:
-mabi=iibmlongdouble -Wno-psabi -mno-gnu-attribute
The no-gnu-attribute says to disable setting the GNU attribute that says what
the default long double type is. It is necessary when building libraries with
both 128-
i to the options as well as
-mabi={ieee,ibm}longdouble. This suppresses the warning that says you are
changing the long double type. If you have configred GCC against GLIBC 2.32 or
newer, then you don't need the -Wno-psabi option. Unfortunately, you can't use
-Wno-psabi on languages like Fortran.
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
evious GCC's that use explicit __ibm128 and
__float128 keywords. I don't how the users of these keywords (i.e. typically
libstdc++ and glibc developers, but potentially others as well).
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
them as
full fledged types, or are they just convenient ways to compile code with both
names rather than building two modules, with the different long double types?
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
ompiled with previous GCC's that use explicit __ibm128 and
__float128 keywords. I don't how the users of these keywords (i.e. typically
libstdc++ and glibc developers, but potentially others as well).
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
On Thu, Aug 04, 2022 at 10:14:10PM +0100, Jonathan Wakely wrote:
> On Thu, 4 Aug 2022 at 18:58, Michael Meissner via Gcc wrote:
> >
> > On Thu, Aug 04, 2022 at 10:49:24AM +0200, Nathan Sidwell wrote:
> > > Not a problem. I don't think I have anything to add- I presu
On Thu, Aug 04, 2022 at 03:53:55PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Aug 04, 2022 at 01:48:51PM -0400, Michael Meissner wrote:
> > At the moment, GCC 12 on the server PowerPC systems supports multiple
> > 128-bit
> > floating point types:
> >
&g
101 - 160 of 160 matches
Mail list logo
