Interested in submitting sponsored posts on your blog

[Malik Bilal via Gcc]

Hi,

I’m looking for the best blog to post one of my client’s articles. During
my search, I came across your blog. Well, I found that the posts on your
blogs are quite edifying and admirable to read. So, I’d like to suggest
your bloghttp://https://gcc.gnu.org// /
)  to my clients. My articles and links will
be General not related to *Casino,Loan,Adult and Gambling*. So let me
your *price
in $* without adding casino prices.

Now, I’m reaching out to you to ask if you are interested in publishing
guest post articles on your blog without sponsored tags. If so, please
devote some time to tell me your thoughts in your busy schedule.

I hope our post will definitely bring you valuable information to your avid
readers.

I’m eagerly waiting to hear from you soon.

Thank you,

Regard

Re: Missing commit in gcc-cvs mailing list

[Martin Liška]

On 10/7/20 8:52 AM, Martin Liška via Overseers wrote:

My commit 190c04ba36d9c6c3dce41f12012aa97c6d7f22f5 is missing in the
mailing list (and so was not propagated to the corresponding PR):
https://gcc.gnu.org/pipermail/gcc-cvs/2020-October/date.html

There's previous and next commit:
[gcc r11-3678] [PATCH][GCC] arm: Move iterators from mve.md to iterators.md to 
maintain consistency.   SRINATH PARVATHANENI
... should be here ...
[gcc r11-3680] [openacc] Fix acc declare for VLAs   Tom de Vries

Can please anybody check that?
Thanks,
Martin


I've got it. It's caused by fact that I copied a strange character to
the git commit message. My testing script fails for it as well:

UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 954: 
ordinal not in range(128)

Martin

Re: First set of patches to allow changing the long double default were posted:

[Michael Meissner via Gcc]

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 implementing
> > > > that, but C requires that long double and _Float128 are distinct types 
> > > > (so
> > > > you can use _Generic to choose between them, for example) even if they
> > > > have the same ABI.
> > >
> > > Hmmm, but others said that it would complicate things if __float128 were
> > > different than long double.  I've implemented it both ways (I would have 
> > > to dig
> > > up the patches to have separate types).
> > >
> > > And doing so might break all of the glibc efforts to provide dual symbols.
> > >
> > > I could obviously use __float128 to be the same as long double, and 
> > > _Float128
> > > being a unique type if long double is IEEE.  And since C++ doesn't have
> > > _Float128, it would 'work' without introducing a new mangling name.
> >
> > My comment is specifically about _Float128, in C; it doesn't say anything
> > about what should happen for C++ (though it would be nice to resolve the
> > ICEs that occur when _FloatN / _FloatNx types leak into C++ code via
> > built-in functions, bug 85518).  Maybe it makes sense for the type (or at
> > least the type used by the built-in functions and __float128, since
> > _Float128 itself can't be accessed directly in C++) to be the same in the
> > C++ case.
> 
> I imagine C++  will want to support _Float128 at some point, with
> similar semantics to C.
> 
> But if __float128 is the same type as __ieee128 (which is sometimes
> the same as long double), which is a different type to _Float128, then
> I think that will work for both C and C++.
> 
> If the standards say we have a standard _Float128 type which is
> different to long double, that's fine. If the standard wants a
> different type, we'll support that. What I'd like to avoid is a
> non-standard __float128 type that is a different type to long double
> even if they use the same representation. That seems like a needless
> difference just for the sake of it.

As Segher says, I sometimes confuse 'types' with 'modes'.

I looked into this a bit, and I think we want to keep the current behavior (as
modified by the patches).  As Joseph says, the _Float types have their own
types, but may/may not use the same modes as other types.  Obviously if these
types leak into C++ (i.e. but 85518), then something needs to be done about
mangling.  But that is a machine independent issue, not a PowerPC issue.

Note, when I began the thread, I had talked about separating the types so that
internally we have 3 types (__float128, __ibm128, and long double), and in fact
I had made changes to that effect in a local sandbox.  The discussion convinced
me that we probably don't want to go down this path.

I did play around with making _Float128 always use KFmode, but it will cause us
to need other changes.  I can do these changes if needed, but it seems like a
lot of pointless work.

To summarize, the current state is:

1) If long double is IEEE 128-bit floating point.

_Float128 has its own type, and uses TFmode;

__float128/__ieee128 uses the long double type and uses TFmode;

__ibm128 uses its own type, and uses IFmode.

Mangling:
__float128  => "u9__ieee128"
__ibm128=> "g"
long double => "u9__ieee128"

2) If long double is IBM extended double:

_Float128 has its own type, and uses KFmode;

__float128/__ieee128 uses its own type, and uses KFmode.

__ibm128 uses the long double type and uses TFmode.

Mangling:
__float128  => "u9__ieee128"
__ibm128=> "g"
long double => "g"

3) If long double is 64-bits:

_Float128 has its own type, and uses KFmode;

__float128/__ieee128 uses its own type, and uses KFmode.

__ibm128 uses its own type and uses IFmode.

Mangling:
__float128  => "u9__ieee128"
__ibm128=> "g"
long double => "e"

-- 
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

Re: First set of patches to allow changing the long double default were posted:

[Segher Boessenkool]

Hi!

On Wed, Oct 07, 2020 at 08:00:49PM -0400, Michael Meissner wrote:
> I looked into this a bit, and I think we want to keep the current behavior (as
> modified by the patches).  As Joseph says, the _Float types have their own
> types, but may/may not use the same modes as other types.  Obviously if these
> types leak into C++ (i.e. but 85518), then something needs to be done about
> mangling.  But that is a machine independent issue, not a PowerPC issue.

There is DF128_ defined for just this, fwiw.  (See
.)

> I did play around with making _Float128 always use KFmode, but it will cause 
> us
> to need other changes.  I can do these changes if needed, but it seems like a
> lot of pointless work.

It would be ideal if we would never have TFmode stuff in the instruction
stream, only IFmode and KFmode.  Hey, I can dream :-)


Segher