Mailing list stripping off attachments

[Thomas König]

Hi,

looks like the new mailing list setup is stripping off patches. Example:

 https://gcc.gnu.org/pipermail/fortran/2020-
March/054050.html

The attachments are also not distributed via mail.

This breaks the gfortran review process. Could somebody please fix this?

Regards

gcc ML archive: text/x-patch attachments no longer shown inline (was:Re: Mailing list stripping off attachments)

[Tobias Burnus]

CC overseers.

they are not stripped – I do see them both in my inbox and at
https://gcc.gnu.org/pipermail/fortran/2020-March/054050.html

However, attachments of the "text/x-…" format (here: text/x-patch)
are no longer shown inline but have to be downloaded (with the
inconvenient suffix: .bin) – which is very inconvenient.

Cheers,

Tobias

On 3/9/20 9:23 AM, Thomas König wrote:


Hi,

looks like the new mailing list setup is stripping off patches. Example:

  https://gcc.gnu.org/pipermail/fortran/2020-
March/054050.html

The attachments are also not distributed via mail.

This breaks the gfortran review process. Could somebody please fix this?

Regards




-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter

Re: gcc ML archive: text/x-patch attachments no longer shown inline (was:Re: Mailing list stripping off attachments)

[Thomas König]

> CC overseers.
> 
> they are not stripped – I do see them both in my inbox and at
> https://gcc.gnu.org/pipermail/fortran/2020-March/054050.html

They were stripped for me :-( I even mailed Paul about the (for me) missing 
attachment.

Not sure what is going on there, but whatever change was made clearly broke a 
lot of things.

Changes in Mail-list to Web integration.

[Iain Sandoe via Gcc]

Hi Folks,

thanks for the work to migrate to the new server.



In the transition, I observe some changes to the integration of mail with  
the web-pages.


In particular, my existing links seem to point now to:

https://gcc.gnu.org/legacy-ml/gxxx

If I reconnect from the GCC front page, following the mail-list links, I  
get to a pipemail archive in which the “date ordered” list is different in  
two important respects from the so-called “legacy” version.


see, for example:

https://gcc.gnu.org/legacy-ml/gcc-patches/2020-03/

c.f.

https://gcc.gnu.org/pipermail/gcc-patches/2020-March/date.html

===

The formatting is not (to me) so much of an issue, but the separation of  
days and (for me and some others who commented on irc anyway) the “most  
recent first” presentation is very useful and it would be good to get that  
restored.


was the change intentional or just a ‘glitch’ in the transition?

thanks
Iain

text/x-* attachments stripped (was: Re: gcc ML archive: text/x-patch attachments no longer shown inline (was:Re: Mailing list stripping off attachments))

[Tobias Burnus]

Hi Thomas, hi Overseers

I can confirm that those are stripped off!

I did sent an email with three attachments:
* test.txt (text/plain)
* test.diff (text/x-diff)
* the company's disclaimer

The attachment with 'text/x-diff' MIME was removed :-(
See: https://gcc.gnu.org/pipermail/fortran/current/054078.html

Tobias

-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter

List-Id header being stripped (was:Re: Mailing list stripping off attachments)

[Richard Bradfield]

On Mon, 9 Mar 2020 10:46:31 +0100, Tobias Burnus wrote:
> Hi Thomas, hi Overseers
> 
> I can confirm that those are stripped off!
> 
> I did sent an email with three attachments:
> * test.txt (text/plain)
> * test.diff (text/x-diff)
> * the company's disclaimer

It appears that since the migration (or whatever happened on the list
over the weekend), the List-Id header is also being stripped from
outbound mail. The last GCC mail I have where the header is intact was
from Friday 6th.

-- 
Richard

Re: Changes in Mail-list to Web integration.

[Jonathan Wakely]

On Mon, 9 Mar 2020 at 09:45, Iain Sandoe via Gcc  wrote:
> The formatting is not (to me) so much of an issue,

I frequently scanned down the right edge of the page looking for
specific email addresses. That's harder to do when the addresses
aren't right-aligned, but I guess I'll get used to it.

>but the separation of
> days and (for me and some others who commented on irc anyway) the “most
> recent first” presentation is very useful and it would be good to get that
> restored.

Yes, for the gcc-bugs, gcc-cvs and libstdc++-cvs archives having
newest first is maybe not essential, but much, much more convenient.

Also https://gcc.gnu.org/pipermail/gcc-bugs/current/ now redirects to
March-2020/thread.html not March-2020/date.html (which would be closer
to the old behaviour).

And as reported on IRC:

https://gcc.gnu.org/ml/ used to redirect to
https://gcc.gnu.org/lists.html but now goes to
https://gcc.gnu.org/pipermail which gives 403 Forbidden.

https://gcc.gnu.org/lists.html#subscribe doesn't work now. Submitting
a subscription request with that form gives a "403 Forbidden" error.

Re: Changes in Mail-list to Web integration.

[Jonathan Wakely]

On Mon, 9 Mar 2020 at 09:56, Jonathan Wakely wrote:
>
> On Mon, 9 Mar 2020 at 09:45, Iain Sandoe via Gcc  wrote:
> > The formatting is not (to me) so much of an issue,
>
> I frequently scanned down the right edge of the page looking for
> specific email addresses. That's harder to do when the addresses
> aren't right-aligned, but I guess I'll get used to it.
>
> >but the separation of
> > days and (for me and some others who commented on irc anyway) the “most
> > recent first” presentation is very useful and it would be good to get that
> > restored.
>
> Yes, for the gcc-bugs, gcc-cvs and libstdc++-cvs archives having
> newest first is maybe not essential, but much, much more convenient.
>
> Also https://gcc.gnu.org/pipermail/gcc-bugs/current/ now redirects to
> March-2020/thread.html not March-2020/date.html (which would be closer
> to the old behaviour).

It looks like I can use
https://gcc.gnu.org/pipermail/gcc-bugs/current/date.html#end to get
the current date archive, and jump to the newest posts.

So that's what I'll use in my pinned browser tab that I keep
refreshing to see new bug mail.

Re: text/x-* attachments stripped (was: Re: gcc ML archive: text/x-patch attachments no longer shown inline (was:Re: Mailing list stripping off attachments))

[Jakub Jelinek]

On Mon, Mar 09, 2020 at 10:46:31AM +0100, Tobias Burnus wrote:
> Hi Thomas, hi Overseers
> 
> I can confirm that those are stripped off!
> 
> I did sent an email with three attachments:
> * test.txt (text/plain)
> * test.diff (text/x-diff)
> * the company's disclaimer
> 
> The attachment with 'text/x-diff' MIME was removed :-(
> See: https://gcc.gnu.org/pipermail/fortran/current/054078.html

A different mail archiver is now used it seems.
For the mails before the sourceware move, one can access the old one too,
e.g.
https://gcc.gnu.org/legacy-ml/gcc-bugs/2020-03/
is the old one vs.
https://gcc.gnu.org/pipermail/gcc-bugs/2020-March/
I've been using the gcc-bugs mail archive all the time in the past, but I'm
afraid pipermail at least in current configuration is significant step back
and I'll likely just use my mailbox from now on.
Some reasons:
1) the by date monthly list of mails used to be ordered newest to oldest
mails first, now it is oldest to newest, so when dealing with new stuff one
has to always scroll down
2) the dates and times of mails used to be shown (date as a section in the
list, times in the left column), now there is nothing, so without clicking
something it is hard to guess how exactly old it is
3) the columns were nicer (date, subject left justified, email right
justified, now there are no columns)
4) some headers were shown, now there is nothing
5) emails used to be sanitized against harvesters, now they aren't
6) there used to be a Raw text URL to grab the raw email, now there is nothing

Jakub

Re: List-Id header being stripped

[Andreas Schwab]

On Mär 09 2020, Richard Bradfield wrote:

> It appears that since the migration (or whatever happened on the list
> over the weekend), the List-Id header is also being stripped from
> outbound mail.

Worksforme.  These are the list-related headers of your mail:

Precedence: list
List-Id: Fortran mailing list 
List-Unsubscribe: ,
 
List-Archive: 
List-Help: 
List-Subscribe: ,
 
Errors-To: fortran-boun...@gcc.gnu.org

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: List-Id header being stripped

[Florian Weimer]

* Richard Bradfield:

> It appears that since the migration (or whatever happened on the list
> over the weekend), the List-Id header is also being stripped from
> outbound mail. The last GCC mail I have where the header is intact was
> from Friday 6th.

There weren't any List-Id headers before the migration.  If you
previously filtered on Sender: headers, you have to change your
filters.  Other filters (List-Post:, for example) may keep working
unchanged, but details will be vary according to how you set up your
filters.

Re: List-Id header being stripped

[Richard Bradfield]

On Mon, 09 Mar 2020 11:27:46 +0100, Andreas Schwab wrote:
> On Mär 09 2020, Richard Bradfield wrote:
> 
> > It appears that since the migration (or whatever happened on the list
> > over the weekend), the List-Id header is also being stripped from
> > outbound mail.
> 
> Worksforme.  These are the list-related headers of your mail:

Two user errors from me, my client was hiding some (but not all) extra
headers, and my filter rule was 'exactly equals gcc@gcc.gnu.org' rather
than 'contains', post migration the List-Id includes the name portion,
so that broke which led to me checking the headers and missing them...

Thanks for looking!

-- 
Richard

Re: text/x-* attachments stripped (was: Re: gcc ML archive: text/x-patch attachments no longer shown inline (was:Re: Mailing list stripping off attachments))

[Jonathan Wakely]

On Mon, 9 Mar 2020 at 10:28, Jakub Jelinek wrote:
> 1) the by date monthly list of mails used to be ordered newest to oldest
> mails first, now it is oldest to newest, so when dealing with new stuff one
> has to always scroll down

You can use #end to jump to the bottom.

> 6) there used to be a Raw text URL to grab the raw email, now there is nothing

That is something I need.

I use that to reply to mails that I don't have in my mailbox, because
I'm not sub'd to the list. With the raw text link you could download a
mailbox file of the mail, and so open it in your local MUA and reply
(with a correct In-Reply-To header, so that threading is properly
preserved).

Re: List-Id header being stripped

[Richard Earnshaw]

On 09/03/2020 10:30, Florian Weimer wrote:

* Richard Bradfield:


It appears that since the migration (or whatever happened on the list
over the weekend), the List-Id header is also being stripped from
outbound mail. The last GCC mail I have where the header is intact was
from Friday 6th.


There weren't any List-Id headers before the migration. 


Yes there were (either that or the filters I've been using for years 
were psychic!)


R.


If you
previously filtered on Sender: headers, you have to change your
filters.  Other filters (List-Post:, for example) may keep working
unchanged, but details will be vary according to how you set up your
filters.

Re: gcc-10-20200308 is now available

[Jonathan Wakely]

On Sun, 8 Mar 2020 at 22:48, GCC Administrator wrote:
>
> Snapshot gcc-10-20200308 is now available on
>   https://gcc.gnu.org/pub/gcc/snapshots/10-20200308/
> and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
>
> This snapshot has been generated from the GCC 10 git branch
> with the following options: git://gcc.gnu.org/git/gcc.git branch master 
> revision 9de42a8e995451cb13dceb3970ae23ff88240bff
>
> You'll find:
>
>  gcc-10-20200308.tar.xz   Complete GCC
>
>   SHA256=cbd1498fcba449649142411ddcfc2bd08b52b8dccd0539a64af82ab13d54f5bf
>   SHA1=41dce5595797f5bf7f59e87f9cba696d98857f29

Is it expected that
https://gcc.gnu.org/pub/gcc/snapshots/10-20200308/sha512.sum is not
present?

There is a sha512.sum file in previous snapshot dirs.




>
> Diffs from 10-20200301 are available in the diffs/ subdirectory.
>
> When a particular snapshot is ready for public consumption the LATEST-10
> link is updated and a message is sent to the gcc list.  Please do not use
> a snapshot before it has been announced that way.

Re: text/x-* attachments stripped

[Andreas Schwab]

On Mär 09 2020, Jonathan Wakely wrote:

> I use that to reply to mails that I don't have in my mailbox, because
> I'm not sub'd to the list. With the raw text link you could download a
> mailbox file of the mail, and so open it in your local MUA and reply
> (with a correct In-Reply-To header, so that threading is properly
> preserved).

FWIW, you can also get them via NNTP from gmane.io.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: List-Id header being stripped

[Florian Weimer]

* Richard Earnshaw:

> On 09/03/2020 10:30, Florian Weimer wrote:
>> * Richard Bradfield:
>> 
>>> It appears that since the migration (or whatever happened on the list
>>> over the weekend), the List-Id header is also being stripped from
>>> outbound mail. The last GCC mail I have where the header is intact was
>>> from Friday 6th.
>> 
>> There weren't any List-Id headers before the migration. 
>
> Yes there were (either that or the filters I've been using for years 
> were psychic!)

Oh, right. They were added in 2006, after I had set up my filters
apparently. 8-/

So the difference is

List-Id: 

vs

List-Id: Gcc mailing list 

I guess now you need to perform a substring match.

Re: List-Id header being stripped

[Gerald Pfeifer]

On Mon, 9 Mar 2020, Florian Weimer wrote:
> So the difference is
> 
> List-Id: 
> 
> vs
> 
> List-Id: Gcc mailing list 
> 
> I guess now you need to perform a substring match.

Or remove the string.  Is that doable?

(It does not add value, and "Gcc" is wrong spelling anyway.)

Gerald

Re: text/x-* attachments stripped (was: Re: gcc ML archive: text/x-patch attachments no longer shown inline (was:Re: Mailing list stripping off attachments))

[Thomas König]

Hi,

I concur with what Jakub wrote. The new web interface is much less useful than 
the old one; a severe regression for developers, so to speak.

I also seem to have missed all discussion on this change (if there was 
anything). I do not understand why such a huge change was implemented that way, 
and who did this. Perhaos the person(s) responsible could speak up about this.

Will the old look and behavior be reinstated, at least in the most important 
aspects?

gcc mailing list is not being archived

[Thomas König]

Hi,

one more point: The gcc mailing list including this discussion is currently not 
being archived, the last message is from 2020-03-06.

Re: gcc mailing list is not being archived

[Frank Ch. Eigler]

Hi -

> one more point: The gcc mailing list including this discussion is
> currently not being archived, the last message is from 2020-03-06.

Found & fixed a permission problem with the mailmnan archives.
Let's see if this one makes it in now.

- FChE

Re: gcc-10-20200308 is now available

[Frank Ch. Eigler]

Hi -

> Is it expected that
> https://gcc.gnu.org/pub/gcc/snapshots/10-20200308/sha512.sum is not
> present?
> There is a sha512.sum file in previous snapshot dirs.

system & per-user cron job items have not been brought forward
en masse.  Copied a relevant one over now
(/sourceware/infra/bin/make-sha /var/ftp/pub)

- FChE

Re: text/x-* attachments strippe

[Gerald Pfeifer]

On Mon, 9 Mar 2020, Thomas König wrote:
> I also seem to have missed all discussion on this change (if there was 
> anything). I do not understand why such a huge change was implemented 
> that way, and who did this. Perhaos the person(s) responsible could 
> speak up about this.

Let's be careful - most people working on this are volunteers, and 
it's great that they took care and spent evenings and weekends.

Could this have gone a bit smoother? Yes.  More collaborative? Maybe.

But it's been old system and quite an upgrade, so changes (including
some inconvenient ones) are to be expected.  I have found and reported
and (with the little I can) helped address some issues and will continue
to do so -- and am confident this is heading in the right direction.

Gerald

Re: text/x-* attachments strippe

[Frank Ch. Eigler]

Hi -

Thanks for the kind words.

> Could this have gone a bit smoother? Yes.  More collaborative? Maybe.

We tried: the plan to migrate to mailman was included by reference
from the systemwide announcement blast two weeks ago:
https://sourceware.org/sourceware-wiki/MigrationStatus/

We continue to welcome advice & help.

- FChE

Re: How do I run SIMD Testcases on PPC64?

[GT via Gcc]

‐‐‐ Original Message ‐‐‐
On Thursday, March 5, 2020 6:59 PM, Segher Boessenkool 
 wrote:

> On Thu, Mar 05, 2020 at 05:04:16PM +, GT wrote:
>
> > At the top of that file is dejagnu directive:
> > /* { dg-require-effective-target vect_int } */
> >
> > 1.  How do I check to see if vect_int is defined? I suspect it as the reason
> > the test isn't run.
> >
>
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/testsuite/lib/target-supports.exp;h=ca3895c22690dc15b6c2beffb53ea6f39ad80b38;hb=HEAD#l3258
>
> (It is always true for powerpc, since we no longer support the
> linuxpaired target).
>
> You can look in the generated gcc.log, and if what you are looking for
> isn't there, you can pass --debug to runtest as well, and look in the
> relevant dbg.log . But first look in target-supports.exp if it is
> something trivial ;-)
>

Thanks.

target-supports.exp needed to set vect_simd_clones for the PPC64
system we are adding support for.

After that change, results of < make check RUNTESTFLAGS="vect.exp=*simd*" > 
improve.
Prior to change: 36 tests come back as UNSUPPORTED. Post change: There are no 
longer
any UNSUPPORTED. However, 16 tests now FAIL. 20 now PASS. Progress, I believe.

Line 8070 in gcc/expr.c is causing ICE. The assertion is 'gcc_assert (MEM_P 
(result))'.
Just above it is a comment explaining the assertion's failure as being either a
front-end bug or a tree optimizer bug. The bug being failure to mark a DECL as
TREE_ADDRESSABLE.

I am attempting to compare results in gdb sessions: the first on an x86_64 
system where
a SIMD testcase passes, the 2nd on a PPC64 system where the same testcase 
fails. I'm
looking to identify the point at which the implementations diverge. It's been a 
slog so
far.

Does anyone have a better idea of how to proceed? Perhaps that comment 
explaining the
assertion is more suggestive of where to look than I understand?

Bert.

Re: text/x-* attachments stripped (was: Re: gcc ML archive: text/x-patch attachments no longer shown inline

[Nathan Sidwell]

On 3/9/20 9:57 AM, Thomas König wrote:

Hi,

I concur with what Jakub wrote. The new web interface is much less useful than 
the old one; a severe regression for developers, so to speak.


OMG I've just looked.  It's awful.  Sorry, but No.

For example 
https://gcc.gnu.org/pipermail/gcc-patches/2020-March/date.html just 
gives a list of emails, no dates shown.  There's no indication what the 
ordering is -- and apparently it is not most recent first.


nathan

--
Nathan Sidwell

Re: text/x-* attachments stripped (was: Re: gcc ML archive: text/x-patch attachments no longer shown inline

[Andreas Schwab]

On Mär 09 2020, Nathan Sidwell wrote:

> For example https://gcc.gnu.org/pipermail/gcc-patches/2020-March/date.html
> just gives a list of emails, no dates shown.  There's no indication what
> the ordering is -- and apparently it is not most recent first.

Heading says:

Starting: Sun Mar 1 01:37:00 GMT 2020
Ending: Mon Mar 9 16:56:12 GMT 2020

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: text/x-* attachments stripped (was: Re: gcc ML archive: text/x-patch attachments no longer shown inline

[Jonathan Wakely]

On Mon, 9 Mar 2020 at 16:58, Nathan Sidwell wrote:
>
> On 3/9/20 9:57 AM, Thomas König wrote:
> > Hi,
> >
> > I concur with what Jakub wrote. The new web interface is much less useful 
> > than the old one; a severe regression for developers, so to speak.
>
> OMG I've just looked.  It's awful.  Sorry, but No.
>
> For example
> https://gcc.gnu.org/pipermail/gcc-patches/2020-March/date.html just
> gives a list of emails, no dates shown.  There's no indication what the
> ordering is -- and apparently it is not most recent first.

Oldest first. Add #end to jump to the newest.

(That's a workaround for now, I'm still not fond of the new format)

Re: text/x-* attachments stripped

[Nathan Sidwell]

On 3/9/20 1:07 PM, Jonathan Wakely wrote:

On Mon, 9 Mar 2020 at 16:58, Nathan Sidwell wrote:


On 3/9/20 9:57 AM, Thomas König wrote:

Hi,

I concur with what Jakub wrote. The new web interface is much less useful than 
the old one; a severe regression for developers, so to speak.


OMG I've just looked.  It's awful.  Sorry, but No.

For example
https://gcc.gnu.org/pipermail/gcc-patches/2020-March/date.html just
gives a list of emails, no dates shown.  There's no indication what the
ordering is -- and apparently it is not most recent first.


Oldest first. Add #end to jump to the newest.


You're joking, right?

nathan

--
Nathan Sidwell

X86 GCC automated testers are back online

[H.J. Lu]

X86 GCC automated testers are back online.   They bootstrap and run
testsuite for master
branch and the current 2 release branches on Linux/x86-64 and Linux/i686:

https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/555912.html
https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/555909.html
https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/37.html
https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/35.html
https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/555787.html
https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/555793.html

Regressions, new failures as well as new passes, are also reported:

https://gcc.gnu.org/pipermail/gcc-regression/2020-March/072492.html
https://gcc.gnu.org/pipermail/gcc-regression/2020-March/072495.html


-- 
H.J.

Re: gcc mailing list is not being archived

[Christopher Faylor]

On Mon, Mar 09, 2020 at 10:10:31AM -0400, Frank Ch. Eigler via Overseers wrote:
>Hi -
>
>> one more point: The gcc mailing list including this discussion is
>> currently not being archived, the last message is from 2020-03-06.
>
>Found & fixed a permission problem with the mailmnan archives.
>Let's see if this one makes it in now.

I'll repopulate the archive with the missing messages when I have the
chance.

cgf

Re: text/x-* attachments stripped (was: Re: gcc ML archive: text/x-patch attachments no longer shown inline (was:Re: Mailing list stripping off attachments))

[Thomas König]

Hi,

Some comments.

Generally, I found the old format to be very good for navigating, and I
would like to have the new one match the old one as closely as possible.


1) the by date monthly list of mails used to be ordered newest to oldest
mails first, now it is oldest to newest, so when dealing with new stuff one
has to always scroll dow

Also important if one just wants to search; it is often the newest
(or newer) message that is of interest.


2) the dates and times of mails used to be shown (date as a section in the
list, times in the left column), now there is nothing, so without clicking
something it is hard to guess how exactly old it is


I concur, that is irritating. You can guess, but you don't get the same
sort of what's happening just from a glance.


3) the columns were nicer (date, subject left justified, email right
justified, now there are no columns)


This does make it harder to see what's what, true.


4) some headers were shown, now there is nothing


Yep.


5) emails used to be sanitized against harvesters, now they aren't


Surely, there is a feature for this?


6) there used to be a Raw text URL to grab the raw email, now there is nothing


This is something that I have rarely used.

As far as the advantages go: A per-thread view is nice, but I don't
think having it outweighs the disadvantages above.

From my personal preference, having 1), 2) and 3) (basically, let the
new interface look like the old one) would be great.

Regards

Thomas

Re: text/x-* attachments stripped (was: Re: gcc ML archive: text/x-patch attachments no longer shown inline (was:Re: Mailing list stripping off attachments))

[Joseph Myers]

On Mon, 9 Mar 2020, Jakub Jelinek via Overseers wrote:

> 5) emails used to be sanitized against harvesters, now they aren't

The pipermail munging feature was unusably bad (it messed up Texinfo diffs 
very badly, including in the mbox version of the archive, e.g. "+@node" at 
the start of a line was interpreted as an email address).

I'm very doubtful that munging that produces human-readable results 
actually does anything against harvesters.  Spammers happily send mail to 
addresses that don't exist at all (taken from message-ids, using random 
names as local-parts, etc.); I expect they'll happily try generating 
addresses from " at ".

-- 
Joseph S. Myers
jos...@codesourcery.com

Compiling GCC using an older sysroot

[Paul Smith]

I have a somewhat complex makefile that I've been using for many years
to build GCC: it builds tools needed (make, bison, flex, m4, binutils),
downloads the source prerequisites and links them, etc.

I'd like some advice, hopefully an easy answer, that allows me to
simplify that system, which currently does a psuedo-cross-compile,
involving rebuilding GCC a few times.  Also I'd like to build GCC
profiled, which doesn't seem to work with my makefile system.

The tricky bit is that although both the host and target are always
x86_64/i686 GNU/Linux systems, I need the generated compiler to run on
much older systems than the one I build it on.

I have a sysroot I've created (downloading RPMs from older systems and
unpacking them) which is sufficient to build GCC (and binutils etc.)  I
need the GCC binaries I create to be compiled using this sysroot so
that they can run on older systems.

It seems that options like --with-sysroot and --with-build-sysroot are
more about how the compiler builds other things and less about how the
compiler itself is built.

Should it be sufficient to invoke configure with --sysroot options for
the compiler used to build GCC, like this?

   $ cd /obj

   $ ../gcc-9.2.0/configure CFLAGS=--sysroot=/sysroot \
CXXFLAGS=--sysroot=/sysroot \
LDFLAGS=--sysroot=/sysroot \
--disable-multilib --enable-gold \
--with-build-config=bootstrap-lto

When I try this I get a failure trying to create libstdc++.  I describe
it below, but I wonder if I'm just chasing down the wrong path
altogether here?

The failure:

/bin/bash ../libtool --tag CXX   --mode=link /obj/./gcc/xgcc -shared-
libgcc -B/obj/./gcc -nostdinc++ -L/obj/x86_64-pc-linux-gnu/libstdc++-
v3/src -L/obj/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/obj/x86_64-
pc-linux-gnu/libstdc++-v3/libsupc++/.libs -B/dist/x86_64-pc-linux-
gnu/bin/ -B/dist/x86_64-pc-linux-gnu/lib/ -isystem /dist/x86_64-pc-
linux-gnu/include -isystem /dist/x86_64-pc-linux-gnu/sys-include   -
fno-checking  -Wl,-O1 -Wl,-z,relro -Wl,--gc-sections  -std=gnu++98
-fPIC -DPIC -fno-implicit-templates  -Wall -Wextra -Wwrite-strings
-Wcast-qual -Wabi=2  -fdiagnostics-show-location=once   -ffunction-
sections -fdata-sections  -frandom-seed=libstdc++.la  -o libstdc++.la
-version-info 6:27:0 -Wl,--version-script=libstdc++-symbols.ver -lm
-rpath /dist/lib/../lib64 compatibility.lo compatibility-debug_list.lo
compatibility-debug_list-2.lo  compatibility-c++0x.lo compatibility-
atomic-c++0x.lo compatibility-thread-c++0x.lo compatibility-chrono.lo
compatibility-condvar.lo  ../libsupc++/libsupc++convenience.la
../src/c++98/libc++98convenience.la ../src/c++11/libc++11convenience.la
../src/c++17/libc++17convenience.la

Interestingly although my sysroot doesn't appear on this command, the
output generated by libtool does show it:

libtool: link:  /obj/./gcc/xgcc -shared-libgcc -B/obj/./gcc -nostdinc++
-L/obj/x86_64-pc-linux-gnu/libstdc++-v3/src -L/obj/x86_64-pc-linux-
gnu/libstdc++-v3/src/.libs -L/obj/x86_64-pc-linux-gnu/libstdc++-
v3/libsupc++/.libs -B/dist/x86_64-pc-linux-gnu/bin/ -B/dist/x86_64-pc-
linux-gnu/lib/ -isystem /dist/x86_64-pc-linux-gnu/include -isystem
/dist/x86_64-pc-linux-gnu/sys-include   -fno-checking  -fPIC -DPIC
-D_GLIBCXX_SHARED -shared -nostdlib
/sysroot/tools/usr/lib/../lib64/crti.o
/obj/./gcc/crtbeginS.o  .libs/compatibility.o .libs/compatibility-
debug_list.o .libs/compatibility-debug_list-2.o .libs/compatibility-
c++0x.o .libs/compatibility-atomic-c++0x.o .libs/compatibility-thread-
c++0x.o .libs/compatibility-chrono.o .libs/compatibility-condvar.o  -
Wl,--whole-archive ../libsupc++/.libs/libsupc++convenience.a
../src/c++98/.libs/libc++98convenience.a
../src/c++11/.libs/libc++11convenience.a
../src/c++17/.libs/libc++17convenience.a -Wl,--no-whole-archive  -
L/obj/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -L/obj/x86_64-
pc-linux-gnu/libstdc++-v3/src -L/obj/x86_64-pc-linux-gnu/libstdc++-
v3/src/.libs -lm -L/obj/./gcc -L/sysroot/tools/lib/../lib64
-L/sysroot/tools/usr/lib/../lib64 -L/sysroot/tools/lib
-L/sysroot/tools/usr/lib -lc -lgcc_s /obj/./gcc/crtendS.o
/sysroot/tools/usr/lib/../lib64/crtn.o  -Wl,-O1 -Wl,-z -Wl,relro -Wl,
--gc-sections -Wl,--version-script=libstdc++-symbols.ver   -Wl,-soname
-Wl,libstdc++.so.6 -o .libs/libstdc++.so.6.0.27

you can see the -L/sysroot/tools/... here.

However this command fails:

/tools/bin/ld: cannot find /lib64/libc.so.6
/tools/bin/ld: cannot find /usr/lib64/libc_nonshared.a
collect2: error: ld returned 1 exit status
make[6]: *** [Makefile:697: libstdc++.la] Error 1
make[5]: *** [Makefile:730: all-recursive] Error 1
make[4]: *** [Makefile:562: all-recursive] Error 1
make[3]: *** [Makefile:487: all] Error 2
make[2]: *** [Makefile:19557: all-stage1-target-libstdc++-v3] Error 2
make[1]: *** [Makefile:27618: stage1-bubble] Error 2
make: *** [Makefile:28760: profiledbootstrap-lean] Error 2

Well, I mean I don't want

Re: Compiling GCC using an older sysroot

[Joseph Myers]

On Mon, 9 Mar 2020, Paul Smith wrote:

> I have a sysroot I've created (downloading RPMs from older systems and
> unpacking them) which is sufficient to build GCC (and binutils etc.)  I
> need the GCC binaries I create to be compiled using this sysroot so
> that they can run on older systems.
> 
> It seems that options like --with-sysroot and --with-build-sysroot are
> more about how the compiler builds other things and less about how the
> compiler itself is built.

Yes.  The natural way to do this sort of thing is:

1. Build a cross compiler (GCC and binutils) that's configured using 
--with-sysroot to make use of the old-system sysroot.  (You can ensure 
it's configured as a cross compiler by making host and target slightly 
different after passing through config.sub, e.g. x86_64-pc-linux-gnu 
versus x86-64-none-linux-gnu.  If it's configured as a native compiler 
rather than a cross compiler, I'm not sure if it will always make use of 
the sysroot without ever searching native paths.)  The 
--with-build-sysroot option is mainly or only relevant if the compiler you 
build in this stage is being relocated (if the sysroot location it will 
search at runtime is not the same as the sysroot location when it is being 
built).

2. Use the compiler you built in the previous step whenever you want to 
build binaries (of GCC or anything else) that will run on older systems.  
If those binaries use C++, make sure to link them with -static-libstdc++ 
-static-libgcc, or else link them with a suitable RPATH and ship the 
required libgcc_s and libstdc++ shared libraries and associated library 
sources with them.  (Linking with RPATHs involving $ORIGIN, if you want 
the binaries to be relocatable, is unfortunately a pain when passing 
through multiple layers of shell and make interpretation, each of which 
needs a layer of quoting in the original linker flags passed to 
configure.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: text/x-* attachments stripped (was: Re: gcc ML archive: text/x-patch attachments no longer shown inline (was:Re: Mailing list stripping off attachments))

[Jonathan Wakely]

On Mon, 9 Mar 2020 at 19:57, Thomas König wrote:
> As far as the advantages go: A per-thread view is nice, but I don't
> think having it outweighs the disadvantages above.

We always had a threaded view:
https://gcc.gnu.org/legacy-ml/gcc-bugs/2020-03/threads.html
It just wasn't the default:
https://gcc.gnu.org/legacy-ml/gcc-bugs/2020-03/

Re: Compiling GCC using an older sysroot

[Paul Smith]

On Mon, 2020-03-09 at 22:01 +, Joseph Myers wrote:
> On Mon, 9 Mar 2020, Paul Smith wrote:
> > I have a sysroot I've created (downloading RPMs from older systems and
> > unpacking them) which is sufficient to build GCC (and binutils etc.)  I
> > need the GCC binaries I create to be compiled using this sysroot so
> > that they can run on older systems.
> > 
> > It seems that options like --with-sysroot and --with-build-sysroot are
> > more about how the compiler builds other things and less about how the
> > compiler itself is built.
> 
> Yes.  The natural way to do this sort of thing is:
> 
> 1. Build a cross compiler (GCC and binutils) that's configured using 
> --with-sysroot to make use of the old-system sysroot.
> 
> 2. Use the compiler you built in the previous step whenever you want to 
> build binaries (of GCC or anything else) that will run on older systems.

Heh.  That's sort of what my makefile was already doing (except for
some reason I was building GCC 3 times not twice... I can't remember
why.  Some kind of canadian-cross; probably I just got lost in the
weeds somewhere all those years ago... or maybe back then the
sysroot options were not as complete/capable as they are now).

Reducing the build to two steps would help me but I only do those once
a year or so, so that's not so important.  Mainly I want to build a
profiled GCC, to reduce compile times.

OK, I'll give this a whirl and see how it goes; thanks Joseph!

As you astutely surmise, the resulting output needs to be relocatable
but not just once: the entire toolchain is checked into a Git
repository and I have no control over the path it's checked out into on
a given system.  So I don't think --with-build-sysroot suffices.

What I do is use shell script wrappers around the compiler which sets
up the correct sysroot flags etc. based on the invocation path then
calls the real binaries.  I'm happy to continue doing that.

I do also use -static-libgcc / -static-libstdc++ as you suggest.

Re: text/x-* attachments stripped (was: Re: gcc ML archive: text/x-patch attachments no longer shown inline (was:Re: Mailing list stripping off attachments))

[Jonathan Wakely]

On Mon, 9 Mar 2020 at 10:28, Jakub Jelinek wrote:
> 6) there used to be a Raw text URL to grab the raw email, now there is nothing

Based on info from #overseers ...

While you can't download the raw text of an individual email now, you
can get the entire month's mail in a compressed archive, from
https://gcc.gnu.org/pipermail/gcc-bugs/

Also, in each mail in the web archives the sender's address at the top
of the page is a hyperlink which includes the message-id, allowing you
to reply to it and preserve threading.
I've adapted the script I was using to fetch the "raw text" mail and
reply to it, the new version is attached.


get_gcc_mail
Description: Binary data

How to extend SLP to support this case

[Kewen.Lin]

Hi all,

I'm investigating whether GCC can vectorize the below case on ppc64le.

  extern void test(unsigned int t[4][4]);

  void foo(unsigned char *p1, int i1, unsigned char *p2, int i2)
  {
unsigned int tmp[4][4];
unsigned int a0, a1, a2, a3;

for (int i = 0; i < 4; i++, p1 += i1, p2 += i2) {
  a0 = (p1[0] - p2[0]) + ((p1[4] - p2[4]) << 16);
  a1 = (p1[1] - p2[1]) + ((p1[5] - p2[5]) << 16);
  a2 = (p1[2] - p2[2]) + ((p1[6] - p2[6]) << 16);
  a3 = (p1[3] - p2[3]) + ((p1[7] - p2[7]) << 16);

  int t0 = a0 + a1;
  int t1 = a0 - a1;
  int t2 = a2 + a3;
  int t3 = a2 - a3;

  tmp[i][0] = t0 + t2;
  tmp[i][2] = t0 - t2;
  tmp[i][1] = t1 + t3;
  tmp[i][3] = t1 - t3;
}
test(tmp);
  }

With unlimited costs, I saw loop aware SLP can vectorize it but with very
inefficient codes.  It builds the SLP instance from store group {tmp[i][0]
tmp[i][1] tmp[i][2] tmp[i][3]}, builds nodes {a0, a0, a0, a0}, 
{a1, a1, a1, a1}, {a2, a2, a2, a2}, {a3, a3, a3, a3} after parsing operands
for tmp* and t*.  It means it's unable to make the isomorphic group for
a0, a1, a2, a3, although they appears isomorphic to merge.  Even if it can
recognize over_widening pattern and do some parallel for two a0 from two
iterations, but it's still inefficient (high cost).

In this context, it looks better to build  first by
leveraging isomorphic computation trees constructing them, eg:
  w1_0123 = load_word(p1)
  V1_0123 = construct_vec(w1_0123)
  w1_4567 = load_word(p1 + 4)
  V1_4567 = construct_vec(w1_4567)
  w2_0123 = load_word(p2)
  V2_0123 = construct_vec(w2_0123)
  w2_4567 = load_word(p2 + 4)
  V2_4567 = construct_vec(w2_4567)
  V_a0123 = (V1_0123 - V2_0123) + (V1_4567 - V2_4567)<<16

But how to teach it to be aware of this? Currently the processing starts
from bottom to up (from stores), can we do some analysis on the SLP 
instance, detect some pattern and update the whole instance?

Besides, I also tried whether the standalone SLP pass can handle it,
it failed to. It stops at a* due to incompatible vector types.

The optimal vectorized SLP codes can be:
  // p1 byte 0 to byte 7 
  d1_0_7 = load_dword(p1)
  // p1+i1 b0 to b7, rename it as 8 to 15   
  d1_8_15 = load_dword(p1 + i1)
  d1_16_23 = load_dword(p1 + 2*i1) 
  d1_24_31 = load_dword(p1 + 3*i1)

  V_d1_0_15 = construct_vec(d1_0_7,d1_8_15) // vector char
  V_d1_16_31 = construct_vec(d1_16_23,d1_24_31)
  V_d1_0_3_all = vperm(V_d1_0_15, V_d1_0_15, 
  {0 8 16 24 1 9 17 25 2 10 18 26 3 11 19 27})
  V_d1_4_7_all = vperm(V_d1_0_15, V_d1_0_15, 
  {4 12 20 28 5 13 21 29 6 14 22 30 7 15 23 31})

  // Do the similar for p2 with i2, get V_d2_0_3_all, V_d2_4_7_all

  // Do the subtraction together (all 4x4 bytes)
  V_sub1 = V_d1_0_3_all - V_d2_0_3_all
  V_sub2 = V_d1_4_7_all - V_d2_4_7_all
  
  // Do some unpack and get the promoted vector int
  V_a0_tmp = vec_promote(V_sub2, {0 1 2 3}) // vector int {b4 b12 b20 b28}
  V_a0_1 = V_a0_tmp << 16
  V_a0_0 = vec_promote(V_sub1, {0 1 2 3}).  // vector int {b0 b8 b16 b24}
  // vector int {a0_iter0, a0_iter1, a0_iter2, a0_iter3}
  V_a0 = V_a0_0 + V_a0_1
  
  // Get the similar for V_a1, V_a2, V_a3

  // Compute t0/t1/t2/t3
  // vector int {t0_iter0, t0_iter1, t0_iter2, t0_iter3}
  V_t0 = V_a0 + V_a1  
  V_t1 = V_a0 - V_a1
  V_t2 = V_a2 + V_a3
  V_t3 = V_a2 - V_a3

  // Compute tmps
  // vector int {tmp[0][0], tmp[1][0], tmp[2][0], tmp[3][0]}
  V_tmp0 = V_t0 + V_t2
  V_tmp2 = V_t0 - V_t2
  V_tmp1 = V_t1 + V_t3
  V_tmp3 = V_t1 - V_t3

  // Final construct the {tmp[0][0], tmp[0][1], tmp[0][2], tmp[0][3]} ...
  // with six further permutation on V_tmp0/V_tmp1/V_tmp2/V_tmp3

>From the above, the key thing is to group tmp[i][j] i=/0,1,2,3/ together, eg:
  tmp[i][0] i=/0,1,2,3/ (one group)
  tmp[i][1] i=/0,1,2,3/ (one group)
  tmp[i][2] i=/0,1,2,3/ (one group)
  tmp[i][3] i=/0,1,2,3/ (one group)

which tmp[i][j] group have the same isomorphic computations.  But currently
SLP is unable to divide group like this way. (call it as A-way for now)

It's understandable since it has better adjacent store groups like,
  tmp[0][i] i=/0,1,2,3/ (one group)
  tmp[1][i] i=/0,1,2,3/ (one group)
  tmp[2][i] i=/0,1,2,3/ (one group)
  tmp[3][i] i=/0,1,2,3/ (one group)

A-way requires some additional vector permutations.  However, I thought
if the existing scheme can't get any SLP chances, it looks reasonable to
extend it to consider this A-way grouping.  Does it make sense?

Another question is that even if we can go with A-way grouping, it can
only handle packing one byte (four iteration -> 4), what place is
reasonable to extend it to pack more?  How about scaning all leaf
nodes and consider/transform them together?  too hacky?

Any comments are highly appreciated.  Thanks in advance!


BR,
Kewen