Order confirmation

2020-04-09 Thread Account via Gcc
<<< image/gif: EXCLUDED >>>


Re: Mathematical Statistics Functions for libgo

2020-04-09 Thread Florian Weimer via Gcc
* Arjunlal M. A.:

> I was wondering if libgo contained any modules for high precision
> statistics functions. If it doesn't, would implementing something like that
> really necessary?

I think these functions would have to go into the mainline Go codebase
first before they appear in libgo.

Thanks,
Florian



Order Confirmation,

2020-04-09 Thread Sales via Gcc
<<< image/gif: EXCLUDED >>>


Request to deprecate offloading to HSAIL in GCC

2020-04-09 Thread Martin Jambor
Hello,

HSAIL - the intermediate language bit of HSA - has not been much of a
success.  I don't know about anybody using it, planning to use it or
being interested in any way, except possibly me.  There really isn't any
finalizer targeting GPUs (or APUs), the one we use to test HSAIL
generation is a proprietary executable hacked into an old HSA run-time
in a way that makes me afraid to touch the computers set up this way.

The HSAIL code generation is fortunately mostly a rather separate bit of
code which does not really cause much trouble.  That is, except the
OpenMP bits which is how we feed the HSA back-end and which were
unfortunately badly designed (mostly by me) and very likely will soon
pose big problems during implementation of new OpenMP features.  They
have to go away.

Right at the beginning of the next stage 1, I will set aside a few days
to try and change the OpenMP bits of HSA offloading to something similar
to what we use for NVPTX.  But I will not hide that I plan to do it
mostly so that I learn something new, a few days is probably not enough,
and generally speaking, I do not think that any big effort invested into
HSAIL is now worth it.

Therefore it is only fair to warn the community and any possible hidden
users or would-be users that it is very likely that I will propose
removal of HSAIL offloading in the course of GCC 11 development cycle
and I would like to formally deprecate it.

So how is it done, by proposing a patch to changes.html?

Note that this deprecation does not include the BRIG front-end.  That
does not cause any real problems that I am aware of and I think that at
least at this point we can and should keep it.

Thanks,

Martin



Re: Not usable email content encoding

2020-04-09 Thread Florian Weimer
* Maciej W. Rozycki:

> On Tue, 7 Apr 2020, Christopher Faylor wrote:
>
>> >In a way that's amusing and just reinforces my p.o.v. that DMARC is 
>> >bollocks.
>> 
>> Not that it means anything but I agree 100%.
>> 
>> It's like whoever made the "standard" just said "to hell with mailing
>> lists".
>
>  Maybe they just didn't know of their existence.  Seriously.

I think that's extremely unlikely.  If you do not do header munging in
the mailing list software, things will work.  That suggests to me that
the people who worked on DKIM and DMARC had this use case in mind.

But of course if you add subject prefixes, rewrite attachments (and
thus the message body), or enable the Mailman duplicate suppression
feature (which edits To:/Cc: lists of the messages posted to the
list), then things will break.  But that's not required to run a
mailing list.


Re: Request to deprecate offloading to HSAIL in GCC

2020-04-09 Thread Jakub Jelinek via Gcc
On Thu, Apr 09, 2020 at 07:43:02PM +0200, Martin Jambor wrote:
> Therefore it is only fair to warn the community and any possible hidden
> users or would-be users that it is very likely that I will propose
> removal of HSAIL offloading in the course of GCC 11 development cycle
> and I would like to formally deprecate it.

LGTM.

> So how is it done, by proposing a patch to changes.html?

I'd say so.

Jakub



Re: Can we please have the old mailing list back

2020-04-09 Thread Bernd Edlinger



On 4/2/20 10:06 AM, Andreas Schwab wrote:
> On Apr 02 2020, Bernd Edlinger wrote:
> 
>> What happens to the e-mails when they are not archive, but forwarded
>> to the subscribers, like mark.info who just subscribes the mails,
>> and archived them they have a lot of hard disks for that and can
>> handle attachments quite well.  The point is previously the attachment
>> were stored on marc.info, but now they are no longer reaching mark.info
>> we mangle the e-mails that we do not archive.
> 
> You should reach out to the maintainers of mark.info and ask them how
> they receive the messages.  On gmane.io, all mails were received in
> their complete, unmangled form.
> 

Interesting point with gmane.io, do they have a web-interface?

I do not want to do the NNTP blues, you know ;-)

Thanks
Bernd.

> Andreas.
>