Re: subversion status on gcc.gnu.org

[Martin Liška]

On 4/6/20 1:57 AM, Frank Ch. Eigler wrote:

Hi -

Courtesy of a lovely httpd RewriteMap-basd hack courtesy of Martin, we
have all the svn r# redirects working, and faster than before.


Great. Thank you application of the RewriteMap!

Martin



- FChE

Re: subversion status on gcc.gnu.org

[Jakub Jelinek via Gcc]

On Mon, Apr 06, 2020 at 10:09:24AM +0200, Martin Liška wrote:
> On 4/6/20 1:57 AM, Frank Ch. Eigler wrote:
> > Hi -
> > 
> > Courtesy of a lovely httpd RewriteMap-basd hack courtesy of Martin, we
> > have all the svn r# redirects working, and faster than before.
> 
> Great. Thank you application of the RewriteMap!

E.g. https://gcc.gnu.org/r105377 or https://gcc.gnu.org/r12345
don't work.

Jakub

Re: subversion status on gcc.gnu.org

[Martin Liška]

On 4/6/20 10:37 AM, Jakub Jelinek wrote:

On Mon, Apr 06, 2020 at 10:09:24AM +0200, Martin Liška wrote:

On 4/6/20 1:57 AM, Frank Ch. Eigler wrote:

Hi -

Courtesy of a lovely httpd RewriteMap-basd hack courtesy of Martin, we
have all the svn r# redirects working, and faster than before.


Great. Thank you application of the RewriteMap!


E.g. https://gcc.gnu.org/r105377 or https://gcc.gnu.org/r12345
don't work.


These look not valid by svn-rev:

$ git svn-rev 105377 | wc -l
0
$ git svn-rev 12345 | wc -l
0

Martin



Jakub

Re: subversion status on gcc.gnu.org

[Jakub Jelinek via Gcc]

On Mon, Apr 06, 2020 at 10:46:34AM +0200, Martin Liška wrote:
> On 4/6/20 10:37 AM, Jakub Jelinek wrote:
> > On Mon, Apr 06, 2020 at 10:09:24AM +0200, Martin Liška wrote:
> > > On 4/6/20 1:57 AM, Frank Ch. Eigler wrote:
> > > > Hi -
> > > > 
> > > > Courtesy of a lovely httpd RewriteMap-basd hack courtesy of Martin, we
> > > > have all the svn r# redirects working, and faster than before.
> > > 
> > > Great. Thank you application of the RewriteMap!
> > 
> > E.g. https://gcc.gnu.org/r105377 or https://gcc.gnu.org/r12345
> > don't work.
> 
> These look not valid by svn-rev:
> 
> $ git svn-rev 105377 | wc -l
> 0
> $ git svn-rev 12345 | wc -l
> 0

Dunno about the latter, but the former then looks like a repo conversion
bug:
https://gcc.gnu.org/legacy-ml/gcc-cvs/2005-10/msg01053.html
(that is the first commit to svn after cvs conversion).

Jakub

Re: subversion status on gcc.gnu.org

[Martin Liška]

On 4/6/20 10:55 AM, Jakub Jelinek wrote:

On Mon, Apr 06, 2020 at 10:46:34AM +0200, Martin Liška wrote:

On 4/6/20 10:37 AM, Jakub Jelinek wrote:

On Mon, Apr 06, 2020 at 10:09:24AM +0200, Martin Liška wrote:

On 4/6/20 1:57 AM, Frank Ch. Eigler wrote:

Hi -

Courtesy of a lovely httpd RewriteMap-basd hack courtesy of Martin, we
have all the svn r# redirects working, and faster than before.


Great. Thank you application of the RewriteMap!


E.g. https://gcc.gnu.org/r105377 or https://gcc.gnu.org/r12345
don't work.


These look not valid by svn-rev:

$ git svn-rev 105377 | wc -l
0
$ git svn-rev 12345 | wc -l
0


Dunno about the latter, but the former then looks like a repo conversion
bug:
https://gcc.gnu.org/legacy-ml/gcc-cvs/2005-10/msg01053.html
(that is the first commit to svn after cvs conversion).


I hope we can live with that one missing :) The date of the commit seems 
suspicious:

commit d3e5a995ec5ceb2c474dd52b9d8558265187829a
Author: Daniel Berlin 
Date:   Fri Oct 28 13:21:13 2005 +

SVN was not moved to SVN :)

From-SVN: r105929


while:
r105377 - /trunk/gcc/DATESTAMP
Date: Thu Oct 27 14:59:55 2005

Based on the SVN revision it should live somewhere:

commit 6c06fbce5c77ffbb0be281d22780a919de4877fe
Author: Mark Mitchell 
Date:   Thu Oct 13 23:59:57 2005 +

re PR c++/20721 (crossing of a initialization left undetected on goto)

PR c++/20721

* cp-tree.h (DECL_NONTRIVIALLY_INITIALIZED_P): New macro.
* decl.c (duplicate_decls): Merge it into new declarations.
(decl_jump_unsafe): Use it, rather than DECL_INITIAL.
(cp_finish_decl): Set it, when appropriate.
PR c++/20721
* g++.dg/init/goto2.C: New test.

From-SVN: r105380


commit 02f3e085c7ba33279329aae728aaf42dc922add6
Author: Andrew Haley 
Date:   Thu Oct 13 17:36:07 2005 +

re PR java/24251 (BC-compiled interfaces in libgcj can't be called from 
non-BC code)

2005-10-12  Andrew Haley  

PR java/24251

* link.cc (ensure_method_table_complete): Install Miranda methods
for interfaces too.

From-SVN: r105375


Martin



Jakub

Re: subversion status on gcc.gnu.org

[Andreas Schwab]

On Apr 06 2020, Jakub Jelinek via Gcc wrote:

> On Mon, Apr 06, 2020 at 10:46:34AM +0200, Martin Liška wrote:
>> On 4/6/20 10:37 AM, Jakub Jelinek wrote:
>> > On Mon, Apr 06, 2020 at 10:09:24AM +0200, Martin Liška wrote:
>> > > On 4/6/20 1:57 AM, Frank Ch. Eigler wrote:
>> > > > Hi -
>> > > > 
>> > > > Courtesy of a lovely httpd RewriteMap-basd hack courtesy of Martin, we
>> > > > have all the svn r# redirects working, and faster than before.
>> > > 
>> > > Great. Thank you application of the RewriteMap!
>> > 
>> > E.g. https://gcc.gnu.org/r105377 or https://gcc.gnu.org/r12345
>> > don't work.
>> 
>> These look not valid by svn-rev:
>> 
>> $ git svn-rev 105377 | wc -l
>> 0
>> $ git svn-rev 12345 | wc -l
>> 0
>
> Dunno about the latter, but the former then looks like a repo conversion
> bug:
> https://gcc.gnu.org/legacy-ml/gcc-cvs/2005-10/msg01053.html
> (that is the first commit to svn after cvs conversion).

This is strange.  Accoding to "svn diff -c 105377
svn://gcc.gnu.org/svn/gcc" this is a revision on
branches/libstdcxx_so_7-branch.  There is also a gap between r105390 and
r105927 on the gcc-cvs archive, where the latter is the first revision
that agrees with the online repository.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: subversion status on gcc.gnu.org

[Andrew Pinski via Gcc]

On Mon, Apr 6, 2020 at 2:15 AM Andreas Schwab via Overseers
 wrote:
>
> On Apr 06 2020, Jakub Jelinek via Gcc wrote:
>
> > On Mon, Apr 06, 2020 at 10:46:34AM +0200, Martin Liška wrote:
> >> On 4/6/20 10:37 AM, Jakub Jelinek wrote:
> >> > On Mon, Apr 06, 2020 at 10:09:24AM +0200, Martin Liška wrote:
> >> > > On 4/6/20 1:57 AM, Frank Ch. Eigler wrote:
> >> > > > Hi -
> >> > > >
> >> > > > Courtesy of a lovely httpd RewriteMap-basd hack courtesy of Martin, 
> >> > > > we
> >> > > > have all the svn r# redirects working, and faster than before.
> >> > >
> >> > > Great. Thank you application of the RewriteMap!
> >> >
> >> > E.g. https://gcc.gnu.org/r105377 or https://gcc.gnu.org/r12345
> >> > don't work.
> >>
> >> These look not valid by svn-rev:
> >>
> >> $ git svn-rev 105377 | wc -l
> >> 0
> >> $ git svn-rev 12345 | wc -l
> >> 0
> >
> > Dunno about the latter, but the former then looks like a repo conversion
> > bug:
> > https://gcc.gnu.org/legacy-ml/gcc-cvs/2005-10/msg01053.html
> > (that is the first commit to svn after cvs conversion).
>
> This is strange.  Accoding to "svn diff -c 105377
> svn://gcc.gnu.org/svn/gcc" this is a revision on
> branches/libstdcxx_so_7-branch.  There is also a gap between r105390 and
> r105927 on the gcc-cvs archive, where the latter is the first revision
> that agrees with the online repository.

>From what I can tell is
https://gcc.gnu.org/legacy-ml/gcc-cvs/2005-10/msg01053.html to
https://gcc.gnu.org/legacy-ml/gcc-cvs/2005-10/msg01066.html was done a
testing SVN repo.  The first real commit to the final SVN conversion
was done at https://gcc.gnu.org/legacy-ml/gcc-cvs/2005-10/msg01067.html
BUT the hooks were not converted over by the repo conversion so
https://gcc.gnu.org/legacy-ml/gcc-cvs/2005-10/msg01068.html was the
first real commit; that is

That is r105377 till r105390 was only ever done on a test SVN repo and
r105927 (hooks) was the first commit to SVN after the conversion from
CVS and r105928 was the first commit to SVN  that is visable in GIT
(SVN hooks history did not copy over).

Thanks,
Andrew Pinski
.

>
> Andreas.
>
> --
> Andreas Schwab, sch...@linux-m68k.org
> GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
> "And now for something completely different."

Re: subversion status on gcc.gnu.org

[Joseph Myers]

On Mon, 6 Apr 2020, Andrew Pinski via Gcc wrote:

> That is r105377 till r105390 was only ever done on a test SVN repo and
> r105927 (hooks) was the first commit to SVN after the conversion from

Actually r105926 (creating the hooks directory) was the first commit in 
the real SVN conversion.  But in addition to SVN hooks deliberately not 
being converted to git, commits that only create / remote empty 
directories generally weren't converted, as git doesn't represent empty 
directories so such commits would be empty, and thus not idiomatically 
present at all, in git.

As for the question about r12345 (cvs2svn-generated creation of a tag that 
was deleted shortly after the move from CVS to SVN), it's in git as commit 
229098288e4883d3b78400650e0b4143e12d0a76.  Given a mirror of the full 
repository, refs/deleted/r106023.256/tags/libc-960701 points to that 
commit - it's not a very useful commit, but it's there if you have the 
full repository.  Maybe the RewriteMap was generated based on the 
fetched-by-default parts of the repository and should be regenerated based 
on a mirror clone to get everything converted from an SVN commit to a git 
commit?

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

Ask a question

[MAHDI LOTFI via Gcc]

Hello
I am a researcher from Jam Petrochemical company I want to use OpenACC with
GCC compiler(FORTRAN language). I have a question about your compiler.
I could not offload OpenACC computing block  on AMD Radeon GPU!! and
OpenACC code run on the host(CPU).
How can I select AMD Radeon GPU as target device?
I run mu code with :
gfortran -fopenacc -fno-automatic -s Test.f90 -o Test
 And code is :

 Program Test
   use openacc
   Implicit None
  integer(8)::I
  !$acc parallel
   !$acc loop
  Do I=1,1000
  Data1(I)=I
  if (acc_on_device (acc_device_host))then
   print*, "no GPU"
  endif
  enddo
 !$acc end  parallel

 Thanks very mch
-- 
Mahdi Lotfi
Student at Sharif University of Technology

Re: Not usable email content encoding

[Maciej W. Rozycki via Gcc]

On Wed, 18 Mar 2020, Frank Ch. Eigler via Gcc wrote:

> > Out of curiousity, is this rewriting you are talking about the cause for a
> > lot of mails showing up as "From: GCC List" rather than their real senders?
> > This has become very annoying recently.
> 
> Yes, for emails from domains with declared interest in email
> cleanliness, via DMARC records in DNS.  We have observed mail
> -blocked- at third parties, even just days ago, when we failed to
> sufficiently authenticate outgoing reflected emails.
> 
> AIUI, all this effort is driven by wanting to defeat not just spammers
> but also real security problems like phishing enabled by forgery,
> including specifically the From: header.

 And it has actually broken GCC's patchwork: 
, which I used to use to 
track my patches.  Now I cannot do that anymore as patches submitted from 
my WDC address are marked as coming from , which 
obviously means they are not attributed to me.

 I am fairly sure it breaks `git am' too, requiring a `From' override in 
the change description for author attribution in patch application to work 
reliably (I tend to work on my outbox when applying my own patches, so I 
avoid this issue, but I am sure the issue will hit someone sooner or 
later).

 And of course I cannot use the `macro@' pattern anymore to select mailing 
list messages in my inbox that I sent myself.  Frankly it's the least of 
the annoyances, but still, and they all add up.

 This is all silly, requiring the SMTP envelope sender to match the `From' 
header breaks even the most basic e-mail mechanisms like the use of a 
`.forward' file.  Can we please do something about it?  Is functional 
regression the price we absolutely need to pay for progress?

 How come the Linux kernel people who do e-mail patch management on a 
vastly larger scale than we do, both in terms of traffic and the number of 
mailing list subscribers, can get away without all these odd quirks in 
their list server management?  Perhaps it would be good asking them how 
they handle their stuff?

  Maciej

Re: Not usable email content encoding

[Frank Ch. Eigler via Gcc]

Hi -


> [...]
>  I am fairly sure it breaks `git am' too, requiring a `From' override in 
> the change description for author attribution in patch application to work 
> reliably (I tend to work on my outbox when applying my own patches, so I 
> avoid this issue, but I am sure the issue will hit someone sooner or 
> later).

That part is at least pretty easy: use
  git format-patch --from "Real Name git "
which will then force a second fake From: header into the body of
the commit email, where git-am can find it.

> This is all silly, requiring the SMTP envelope sender to match the `From' 
> header breaks even the most basic e-mail mechanisms like the use of a 
> `.forward' file.  [...]

Unfortunately naive .forward based forwarding looks exactly like faked
or spam email to a third party MTAs.


> How come the Linux kernel people who do e-mail patch management on a
> vastly larger scale than we do, both in terms of traffic and the
> number of mailing list subscribers, can get away without all these
> odd quirks in their list server management?  [...]

I'm not sure, but their mails tend to be laden with a vast number of
Cc:'s, which bypass mailing list reflectors.


- FChE

Re: Not usable email content encoding

[Maciej W. Rozycki via Gcc]

Hi Frank,

> >  I am fairly sure it breaks `git am' too, requiring a `From' override in 
> > the change description for author attribution in patch application to work 
> > reliably (I tend to work on my outbox when applying my own patches, so I 
> > avoid this issue, but I am sure the issue will hit someone sooner or 
> > later).
> 
> That part is at least pretty easy: use
>   git format-patch --from "Real Name git "
> which will then force a second fake From: header into the body of
> the commit email, where git-am can find it.

 Sure, there are various ways to deal with that, both on the sender's and 
the receiver's side, however all require a manual intervention and are 
therefore prone to a human error.  Which will obviously happen sooner or 
later.

> > This is all silly, requiring the SMTP envelope sender to match the `From' 
> > header breaks even the most basic e-mail mechanisms like the use of a 
> > `.forward' file.  [...]
> 
> Unfortunately naive .forward based forwarding looks exactly like faked
> or spam email to a third party MTAs.

 And can certainly score a positive though not a definite rating in spam 
qualification.  I don't think we ought to encourage bad IT management 
practices by trying to adapt to them too hard and hurting ourselves (our 
workflow) in the process.

> > How come the Linux kernel people who do e-mail patch management on a
> > vastly larger scale than we do, both in terms of traffic and the
> > number of mailing list subscribers, can get away without all these
> > odd quirks in their list server management?  [...]
> 
> I'm not sure, but their mails tend to be laden with a vast number of
> Cc:'s, which bypass mailing list reflectors.

 Surely all the bots receive messages via a mailing list subscription 
though.  Cc's are solely for maintainers, reviewers or other explicitly 
interested parties.  Some maintainers actually require submissions to come 
via the relevant mailing list rather directly to them.  Somehow it works.

 Thank you for your input regardless!

  Maciej

Re: Not usable email content encoding

[Segher Boessenkool]

Hi!

On Mon, Apr 06, 2020 at 09:58:27PM +0100, Maciej W. Rozycki wrote:
> On Wed, 18 Mar 2020, Frank Ch. Eigler via Gcc wrote:
> > > Out of curiousity, is this rewriting you are talking about the cause for a
> > > lot of mails showing up as "From: GCC List" rather than their real 
> > > senders?
> > > This has become very annoying recently.
> > 
> > Yes, for emails from domains with declared interest in email
> > cleanliness, via DMARC records in DNS.  We have observed mail
> > -blocked- at third parties, even just days ago, when we failed to
> > sufficiently authenticate outgoing reflected emails.
> > 
> > AIUI, all this effort is driven by wanting to defeat not just spammers
> > but also real security problems like phishing enabled by forgery,
> > including specifically the From: header.
> 
>  And it has actually broken GCC's patchwork: 
> , which I used to use to 
> track my patches.

Yes, I noticed (I run that patchwork).

> Now I cannot do that anymore as patches submitted from 
> my WDC address are marked as coming from , which 
> obviously means they are not attributed to me.

Yup.

>  I am fairly sure it breaks `git am' too, requiring a `From' override in 
> the change description for author attribution in patch application to work 
> reliably (I tend to work on my outbox when applying my own patches, so I 
> avoid this issue, but I am sure the issue will hit someone sooner or 
> later).

Yup.

>  And of course I cannot use the `macro@' pattern anymore to select mailing 
> list messages in my inbox that I sent myself.  Frankly it's the least of 
> the annoyances, but still, and they all add up.

It would break even the built-in mutt "you sent this yourself" detection.

>  This is all silly, requiring the SMTP envelope sender to match the `From' 
> header breaks even the most basic e-mail mechanisms like the use of a 
> `.forward' file.

This even *never* is true for my mail setups, and never has been, and it
all works fine.

> Can we please do something about it?  Is functional 
> regression the price we absolutely need to pay for progress?
> 
>  How come the Linux kernel people who do e-mail patch management on a 
> vastly larger scale than we do, both in terms of traffic and the number of 
> mailing list subscribers, can get away without all these odd quirks in 
> their list server management?  Perhaps it would be good asking them how 
> they handle their stuff?

If someone cannot connect to them because they have a broken mail setup,
the kernel people say "your problem, get a working mail setup", and that
works fine so far (99.999% of people *can* get working mail, just not
always company mail).


Segher