[PATCH] Recognize '-' as special -MF argument (write to stdout)

[Boris Kolpackov]

Hi,

Sometimes it is useful to generate pre-processed output to a file and
the dependency information to stdout for further analysis/processing.
For example:

g++ -E -MD -fdirectives-only -o test.ii test.cxx

This will generate the dependency information to test.d (as per the
documentation). While changing this behavior is probably unwise, one
traditional (e.g., supported by -o) way to handle this is to recognize
the special '-' file name as an instruction to write to stdout:

g++ -E -MD -fdirectives-only -o test.ii -MF - test.cxx

Currently this will create a file named '-'. The included patch changes
this behavior to write to stdout.

Note also that Clang has supported this from at least version 3.5.

The patch should apply cleanly to trunk. I would also like to see it
backported to previous versions, if possible. If this requires any
additional work, I am willing to do it.

Thanks,
Boris
Index: gcc/ChangeLog
===
--- gcc/ChangeLog	(revision 247825)
+++ gcc/ChangeLog	(working copy)
@@ -1,3 +1,6 @@
+
+	* doc/cppopts.texi: Document '-' special value to -MF.
+
 2017-05-09  Marek Polacek  
 
 	* doc/invoke.texi: Fix typo.
Index: gcc/c-family/ChangeLog
===
--- gcc/c-family/ChangeLog	(revision 247825)
+++ gcc/c-family/ChangeLog	(working copy)
@@ -1,3 +1,6 @@
+
+	* c-opts.c (c_common_finish): Handle '-' special value to -MF.
+
 2017-05-09  Marek Polacek  
 
 	PR c/80525
Index: gcc/c-family/c-opts.c
===
--- gcc/c-family/c-opts.c	(revision 247825)
+++ gcc/c-family/c-opts.c	(working copy)
@@ -1164,6 +1164,8 @@
 	 output stream.  */
   if (!deps_file)
 	deps_stream = out_stream;
+  else if (deps_file[0] == '-' && deps_file[1] == '\0')
+	deps_stream = stdout;
   else
 	{
 	  deps_stream = fopen (deps_file, deps_append ? "a": "w");
@@ -1177,7 +1179,7 @@
  with cpp_destroy ().  */
   cpp_finish (parse_in, deps_stream);
 
-  if (deps_stream && deps_stream != out_stream
+  if (deps_stream && deps_stream != out_stream && deps_stream != stdout
   && (ferror (deps_stream) || fclose (deps_stream)))
 fatal_error (input_location, "closing dependency file %s: %m", deps_file);
 
Index: gcc/doc/cppopts.texi
===
--- gcc/doc/cppopts.texi	(revision 247825)
+++ gcc/doc/cppopts.texi	(working copy)
@@ -125,6 +125,8 @@
 When used with the driver options @option{-MD} or @option{-MMD},
 @option{-MF} overrides the default dependency output file.
 
+If @var{file} is @file{-}, then the dependencies are written to @file{stdout}.
+
 @item -MG
 @opindex MG
 In conjunction with an option such as @option{-M} requesting

Re: dejagnu version update?

[Richard Biener]

On Mon, May 15, 2017 at 12:09 AM, NightStrike  wrote:
> On Sat, May 13, 2017 at 4:39 PM, Jeff Law  wrote:
>> On 05/13/2017 04:38 AM, Jakub Jelinek wrote:
>>>
>>> On Sat, May 13, 2017 at 12:24:12PM +0200, Bernhard Reutner-Fischer wrote:

 I guess neither redhat
 (https://access.redhat.com/downloads/content/dejagnu/ redirects to a
 login page but there seem to be 1.5.1 packages) nor SuSE did update
 dejagnu in the meantime.
>>>
>>>
>>> Fedora has dejagnu-1.6 in Fedora 25 and later, dejagnu-1.5.3 in Fedora 24,
>>> older
>>> Fedora versions are EOL.  RHEL 7 has dejagnu-1.5.1, RHEL 6 as well as RHEL
>>> 5 has
>>> dejagnu-1.4.4, older RHEL versions are EOL.
>>
>> RHEL-5 is old enough that IMHO it ought not figure into this discussion.
>> RHEL-6 is probably close to if not past that same point as well.
>
> FWIW, I still run the testsuite on RHEL 6.

Both SLE-11 and SLE-12 use dejagnu 1.4.4, so does openSUSE Leap 42.[12].
Tumbleweed uses 1.6 so new SLE will inherit that.  But I still do all
of my testing
on systems with just dejagnu 1.4.4.

Richard.

Re: [RFC] GCC 8 Project proposal: Extensions supporting C Metaprogramming, pseudo-templates

[Vincent Lefevre]

On 2017-05-12 15:59:44 -0500, Daniel Santos wrote:
> [...] But from a conceptual standpoint, I believe the term
> "constant-expression" would be incorrect because the C standard
> defines this constraint: (6.6.3 of C11) "Constant expressions shall
> not contain assignment, increment, decrement, function-call, or
> comma operators, except when they are contained within a
> subexpression that is not evaluated." I definitely do need to study
> the C specs more carefully to make sure I fully understand how this
> is used and how it's changed over different revisions of the spec.

GCC already regards some function calls are acceptable in
constant expressions, when builtins are used, e.g. fabs (2.0),
contrary to Clang. The builtin is even used when  is
not included (note that Clang has the same behavior here). So,
there may be several issues. I've reported:

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80756

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Help with rich_location and GIMPLE stmts

[Martin Liška]

Hi.

I sent this email to David some time ago, but it should be probably answered
on gcc mailing list.

I have idea one to improve gcov tool and I'm interested in more precise 
locations for gimple
statements. For gcov purpose, we dump location in ipa-profile pass, which is an 
early IPA
pass and this data is used by gcov tool to map statements (blocks) to lines of 
code.

I did a small experiment on the place we emit the location data:
  inform (gimple_location (stmt), "output_location");

and it shows for:
$ cat m2.c
unsigned int
UuT (void)
{ unsigned int true_var = 1; unsigned int false_var = 0; unsigned int ret = 0; 
if (true_var) /* count(1) */ { if (false_var) /* count(1) */ ret = 111; /* 
count(#) */ } else ret = 999; /* count(#) */ return ret; }

int
main (int argc, char **argv)
{
  UuT ();
  return 0;
}

$ gcc --coverage m2.c
m2.c: In function ‘main’:
m2.c:8:3: note: output_location
   UuT ();
   ^~
# .MEM_2 = VDEF <.MEM_1(D)>
UuT ();
m2.c:9:10: note: output_location
   return 0;
  ^
_3 = 0;
m2.c: In function ‘UuT’:
m2.c:3:16: note: output_location
 { unsigned int true_var = 1; unsigned int false_var = 0; unsigned int ret = 0; 
if (true_var) /* count(1) */ { if (false_var) /* count(1) */ ret = 111; /* 
count(#) */ } else ret = 999; /* count(#) */ return ret; }
^~~~
true_var_3 = 1;
m2.c:3:43: note: output_location
 { unsigned int true_var = 1; unsigned int false_var = 0; unsigned int ret = 0; 
if (true_var) /* count(1) */ { if (false_var) /* count(1) */ ret = 111; /* 
count(#) */ } else ret = 999; /* count(#) */ return ret; }
   ^
false_var_4 = 0;
m2.c:3:71: note: output_location
 { unsigned int true_var = 1; unsigned int false_var = 0; unsigned int ret = 0; 
if (true_var) /* count(1) */ { if (false_var) /* count(1) */ ret = 111; /* 
count(#) */ } else ret = 999; /* count(#) */ return ret; }
   ^~~
ret_5 = 0;
m2.c:3:83: note: output_location
 { unsigned int true_var = 1; unsigned int false_var = 0; unsigned int ret = 0; 
if (true_var) /* count(1) */ { if (false_var) /* count(1) */ ret = 111; /* 
count(#) */ } else ret = 999; /* count(#) */ return ret; }

   ^
if (true_var_3 != 0)
m2.c:3:114: note: output_location
 { unsigned int true_var = 1; unsigned int false_var = 0; unsigned int ret = 0; 
if (true_var) /* count(1) */ { if (false_var) /* count(1) */ ret = 111; /* 
count(#) */ } else ret = 999; /* count(#) */ return ret; }

  ^
if (false_var_4 != 0)
m2.c:3:145: note: output_location
 { unsigned int true_var = 1; unsigned int false_var = 0; unsigned int ret = 0; 
if (true_var) /* count(1) */ { if (false_var) /* count(1) */ ret = 111; /* 
count(#) */ } else ret = 999; /* count(#) */ return ret; }

 ^
ret_7 = 111;
m2.c:3:182: note: output_location
 { unsigned int true_var = 1; unsigned int false_var = 0; unsigned int ret = 0; 
if (true_var) /* count(1) */ { if (false_var) /* count(1) */ ret = 111; /* 
count(#) */ } else ret = 999; /* count(#) */ return ret; }


  ^
ret_6 = 999;
m2.c:3:215: note: output_location
 { unsigned int true_var = 1; unsigned int false_var = 0; unsigned int ret = 0; 
if (true_var) /* count(1) */ { if (false_var) /* count(1) */ ret = 111; /* 
count(#) */ } else ret = 999; /* count(#) */ return ret; }


   ^~~
_8 = ret_2;
m2.c:3:215: note: output_location
# VUSE <.MEM_9(D)>
return _8;

Which is not optimal, for some assignments I see just LHS (false_var_4 = 0), 
for return statements only a returned value is displayed. For conditions, only 
condition beginning is showed.
Is this known behavior or do I miss something?

Thanks,
Martin

Transformation of contrib/check_GNU_style.sh to a python script

[Martin Liška]

Hello.

Recently I've been working on bigger changes to dump infrastructure and I had to
fix tens of formatting issues reported by check_GNU_style.sh script. The script 
works
quite fine, but it's very unpleasant that it reports problematic lines in the 
patch,
not in original patches. I decided to substitute part of functionality by Python
script that uses a library that parses patches. So that reported errors can be
easily converted to quickfix list for VIM. That makes navigation very easy.

I'm attaching simple version that I made in couple of minutes and I would like 
to
ask whether the bash script is broadly used and whether community would be 
interested
in transformation of the script?

Thanks,
Martin
#!/usr/bin/env python3
#
# Script to analyze results of our branch prediction heuristics
#
# This file is part of GCC.
#
# GCC is free software; you can redistribute it and/or modify it under
# the terms of the GNU General Public License as published by the Free
# Software Foundation; either version 3, or (at your option) any later
# version.
#
# GCC is distributed in the hope that it will be useful, but WITHOUT ANY
# WARRANTY; without even the implied warranty of MERCHANTABILITY or
# FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
# for more details.
#
# You should have received a copy of the GNU General Public License
# along with GCC; see the file COPYING3.  If not see
# .  */
#
#
#
# This script is used to calculate two basic properties of the branch prediction
# heuristics - coverage and hitrate.  Coverage is number of executions
# of a given branch matched by the heuristics and hitrate is probability
# that once branch is predicted as taken it is really taken.
#
# These values are useful to determine the quality of given heuristics.
# Hitrate may be directly used in predict.def.
#
# Usage:
#  Step 1: Compile and profile your program.  You need to use -fprofile-generate
#flag to get the profiles.
#  Step 2: Make a reference run of the intrumented application.
#  Step 3: Compile the program with collected profile and dump IPA profiles
#  (-fprofile-use -fdump-ipa-profile-details)
#  Step 4: Collect all generated dump files:
#  find . -name '*.profile' | xargs cat > dump_file
#  Step 5: Run the script:
#  ./analyze_brprob.py dump_file
#  and read results.  Basically the following table is printed:
#
# HEURISTICS   BRANCHES  (REL)  HITRATECOVERAGE  (REL)
# early return (on trees) 3   0.2%  35.83% /  93.64%  66360   0.0%
# guess loop iv compare   8   0.6%  53.35% /  53.73%   11183344   0.0%
# call   18   1.4%  31.95% /  69.95%   51880179   0.2%
# loop guard 23   1.8%  84.13% /  84.85%13749065956  42.2%
# opcode values positive (on trees)  42   3.3%  15.71% /  84.81% 6771097902  20.8%
# opcode values nonequal (on trees) 226  17.6%  72.48% /  72.84%  844753864   2.6%
# loop exit 231  18.0%  86.97% /  86.98% 8952666897  27.5%
# loop iterations   239  18.6%  91.10% /  91.10% 3062707264   9.4%
# DS theory 281  21.9%  82.08% /  83.39% 7787264075  23.9%
# no prediction 293  22.9%  46.92% /  70.70% 2293267840   7.0%
# guessed loop iterations   313  24.4%  76.41% /  76.41%10782750177  33.1%
# first match   708  55.2%  82.30% /  82.31%22489588691  69.0%
# combined 1282 100.0%  79.76% /  81.75%32570120606 100.0%
#
#
#  The heuristics called "first match" is a heuristics used by GCC branch
#  prediction pass and it predicts 55.2% branches correctly. As you can,
#  the heuristics has very good covertage (69.05%).  On the other hand,
#  "opcode values nonequal (on trees)" heuristics has good hirate, but poor
#  coverage.

import sys
import os
import re
import argparse

from math import *

counter_aggregates = set(['combined', 'first match', 'DS theory',
'no prediction'])

def percentage(a, b):
return 100.0 * a / b

def average(values):
return 1.0 * sum(values) / len(values)

def average_cutoff(values, cut):
l = len(values)
skip = floor(l * cut / 2)
if skip > 0:
values.sort()
values = values[skip:-skip]
return average(values)

def median(values):
values.sort()
return values[int(len(values) / 2)]

class Summary:
def __init__(self, name):
self.name = name
self.branches = 0
self.successfull_branches = 0
self.count = 0
self.hits = 0
self.fits = 0

def get_hitrate(self):
return 100.0 * self.hits / self.count

def get_branch_hitrate(self):
return 100.0 * self.successfull_branches / self.branches

def c

Re: Transformation of contrib/check_GNU_style.sh to a python script

[Martin Liška]

Sorry, wrong file.

Martin
#!/usr/bin/env python3

import sys
import re

from unidiff import PatchSet

def report_error(filename, line_no, error):
print('%s:%d:%s' % (filename, line_no, error))

def validate(filename, line_no, line):
# 1: validate line length
line_expanded = line.replace('\t', ' ' * 8)
if len(line_expanded) > 80:
report_error(filename, line_no, 'line should not exceed 80 characters')

# 2) 8 spaces check
if ' ' * 8 in line:
report_error(filename, line_no, '8 spaces should be replace with a tab')

# 3) trailing white space
if line.endswith(' '):
report_error(filename, line_no, 'trailing whitespace')

# 4) Dot, space, space, new sentence.
if re.search('\w+\.(\s|\s{3,})\w', line):
report_error(filename, line_no, 'dot, space, space, new sentence')

# 5) Dot, space, space, end of comment.
if re.search('\w+\.(\s{0,1}|\s{3,})\*/', line):
report_error(filename, line_no, 'dot, space, space, end of comment')

with open(sys.argv[1], 'rb') as diff_file:
patch = PatchSet(diff_file, encoding = 'utf-8')

for pfile in patch.modified_files:
for hunk in pfile:
delta = 0
for line in hunk:
if line.is_added and line.target_line_no != None:
validate(pfile.target_file.lstrip('b/'), line.target_line_no, line.value)

Re: Transformation of contrib/check_GNU_style.sh to a python script

[Tom de Vries]

On 05/15/2017 03:55 PM, Martin Liška wrote:

... check_GNU_style.sh script. The script works
quite fine, but it's very unpleasant that it reports problematic lines in the 
patch,
not in original patches.


Agreed.


I decided to substitute part of functionality by Python
script that uses a library that parses patches. So that reported errors can be
easily converted to quickfix list for VIM. That makes navigation very easy.

I'm attaching simple version that I made in couple of minutes and I would like 
to
ask whether the bash script is broadly used


I use it regularly.


and whether community would be interested
in transformation of the script?


I think it's a good idea.

Thanks,
- Tom

Re: dejagnu version update?

[Martin Jambor]

Hi,

On Wed, Sep 16, 2015 at 01:25:18PM -0400, Trevor Saunders wrote:
> On Wed, Sep 16, 2015 at 10:36:47AM -0600, Jeff Law wrote:
> >

...

> > I'd rather just move to 1.5 and get on with things.  If some systems don't
> > have a new enough version, I'm comfortable telling developers on those
> > platforms that they need to update.  It's not like every *user* needs
> > dejagnu, it's just for the testing side of things.
> 
> yeah, it seems like a poor idea to slow down progress we make for all
> users to benefit a few people who want to develope on rather old
> machines.
> 

Could we at least make sure that machines in the FSF compile farm have
a new enough dejagnu before move to requiring at least 1.5?

I understand that may be a tall order, given that some machines
(e.g. gcc117) do not have dejagnu at all and this was reported some
time ago :-(

Martin

Re: Duplicating loops and virtual phis

[Steve Ellcey]

On Sat, 2017-05-13 at 08:18 +0200, Richard Biener wrote:
> On May 12, 2017 10:42:34 PM GMT+02:00, Steve Ellcey  om> wrote:
> > 
> > (Short version of this email, is there a way to recalculate/rebuild
> > virtual
> > phi nodes after modifying the CFG.)
> > 
> > I have a question about duplicating loops and virtual phi nodes.
> > I am trying to implement the following optimization as a pass:
> > 
> > Transform:
> > 
> >   for (i = 0; i < n; i++) {
> > A[i] = A[i] + B[i];
> > C[i] = C[i-1] + D[i];
> >   }
> > 
> > Into:
> > 
> >   if (noalias between A&B, A&C, A&D)
> > for (i = 0; i < 100; i++)
> > A[i] = A[i] + B[i];
> > for (i = 0; i < 100; i++)
> > C[i] = C[i-1] + D[i];
> >   else
> > for (i = 0; i < 100; i++) {
> > A[i] = A[i] + B[i];
> > C[i] = C[i-1] + D[i];
> > }
> > 
> > Right now the vectorizer sees that 'C[i] = C[i-1] + D[i];' cannot be
> > vectorized so it gives up and does not vectorize the loop.  If we split
> > up the loop into two loops then the vector add with A[i] could be
> > vectorized
> > even if the one with C[i] could not.
> Loop distribution does this transform but it doesn't know about
> versioning for unknown dependences.
> 

Yes, I looked at loop distribution.  But it only works with global
arrays and not with pointer arguments where it doesn't know the size of
the array being pointed at.  I would like to be able to have it work
with pointer arguments.  If I call a function with 2 or
more integer pointers, and I have a loop that accesses them with
offsets between 0 and N where N is loop invariant then I should have
enough information (at runtime) to determine if there are overlapping
memory accesses through the pointers and determine whether or not I can
distribute the loop.

The loop splitting code seemed like a better template since it already
knows how to split a loop based on a runtime determined condition. That
part seems to be working for me, it is when I try to
distribute/duplicate one of those loops (under the unaliased condition)
that I am running into the problem with virtual PHIs.

Steve Ellcey
sell...@cavium.com

Re: dejagnu version update?

[Pedro Alves]

On 05/15/2017 04:54 PM, Martin Jambor wrote:
> Hi,
> 
> On Wed, Sep 16, 2015 at 01:25:18PM -0400, Trevor Saunders wrote:
>> On Wed, Sep 16, 2015 at 10:36:47AM -0600, Jeff Law wrote:
>>>
> 
> ...
> 
>>> I'd rather just move to 1.5 and get on with things.  If some systems don't
>>> have a new enough version, I'm comfortable telling developers on those
>>> platforms that they need to update.  It's not like every *user* needs
>>> dejagnu, it's just for the testing side of things.
>>
>> yeah, it seems like a poor idea to slow down progress we make for all
>> users to benefit a few people who want to develope on rather old
>> machines.
>>

The relying on system dejagnu on old distributions has been a sure
recipe for people avoiding fixing / improving dejagnu.  I mean,
why bother, if your fix will only be generally available in 10 years
when older distros are finally phased out?

> Could we at least make sure that machines in the FSF compile farm have
> a new enough dejagnu before move to requiring at least 1.5?
> 
> I understand that may be a tall order, given that some machines
> (e.g. gcc117) do not have dejagnu at all and this was reported some
> time ago :-(
> 

Maybe download_prerequisites could be taught to handle downloading
and setting up dejagnu [1], making it mostly a non-issue?

[1] Last time I needed to do it, it was mostly plain old
configure/make/make install IIRC, assuming new-enough tcl/expect.
Building a newer tcl/expect would be a bit more work of course.

Thanks,
Pedro Alves

Re: Duplicating loops and virtual phis

[Richard Biener]

On May 15, 2017 6:56:53 PM GMT+02:00, Steve Ellcey  wrote:
>On Sat, 2017-05-13 at 08:18 +0200, Richard Biener wrote:
>> On May 12, 2017 10:42:34 PM GMT+02:00, Steve Ellcey > om> wrote:
>> > 
>> > (Short version of this email, is there a way to recalculate/rebuild
>> > virtual
>> > phi nodes after modifying the CFG.)
>> > 
>> > I have a question about duplicating loops and virtual phi nodes.
>> > I am trying to implement the following optimization as a pass:
>> > 
>> > Transform:
>> > 
>> >   for (i = 0; i < n; i++) {
>> >A[i] = A[i] + B[i];
>> >C[i] = C[i-1] + D[i];
>> >   }
>> > 
>> > Into:
>> > 
>> >   if (noalias between A&B, A&C, A&D)
>> >for (i = 0; i < 100; i++)
>> >A[i] = A[i] + B[i];
>> >for (i = 0; i < 100; i++)
>> >C[i] = C[i-1] + D[i];
>> >   else
>> >for (i = 0; i < 100; i++) {
>> >A[i] = A[i] + B[i];
>> >C[i] = C[i-1] + D[i];
>> >}
>> > 
>> > Right now the vectorizer sees that 'C[i] = C[i-1] + D[i];' cannot
>be
>> > vectorized so it gives up and does not vectorize the loop.  If we
>split
>> > up the loop into two loops then the vector add with A[i] could be
>> > vectorized
>> > even if the one with C[i] could not.
>> Loop distribution does this transform but it doesn't know about
>> versioning for unknown dependences.
>> 
>
>Yes, I looked at loop distribution.  But it only works with global
>arrays and not with pointer arguments where it doesn't know the size of
>the array being pointed at.  I would like to be able to have it work
>with pointer arguments.  If I call a function with 2 or
>more integer pointers, and I have a loop that accesses them with
>offsets between 0 and N where N is loop invariant then I should have
>enough information (at runtime) to determine if there are overlapping
>memory accesses through the pointers and determine whether or not I can
>distribute the loop.

Not sure where you got that from. Loop distribution works with our data 
reference / dependence analysis.  The cost model might be more restricted but 
that can be fixed.

>The loop splitting code seemed like a better template since it already
>knows how to split a loop based on a runtime determined condition. That
>part seems to be working for me, it is when I try to
>distribute/duplicate one of those loops (under the unaliased condition)
>that I am running into the problem with virtual PHIs.

There's mark_virtual*for_renaming (sp?).

But as said you are performing loop distribution so please enhance the existing 
pass rather than writing a new one.

Richard.

>Steve Ellcey
>sell...@cavium.com

Re: dejagnu version update?

[Mike Stump]

On May 15, 2017, at 1:06 AM, Richard Biener  wrote:
> 
> Both SLE-11 and SLE-12 use dejagnu 1.4.4, so does openSUSE Leap 42.[12].
> Tumbleweed uses 1.6 so new SLE will inherit that.  But I still do all
> of my testing on systems with just dejagnu 1.4.4.

So dejagnu is independent of most things and downloads and installs in seconds, 
upgrading it shouldn't pose a problem for anyone that can build gcc.

That said, a little surprising that SLE is lagging everyone else so hard.  
Looking at the 42.2 EOL plans, and that would put switching degagnu versions at 
around 13 months from now, if we waited.

So, how much would you mind, for trunk to require a newer a dejagnu?  If just a 
little, I'm inclined to not wait and support updating now.  If please god no, 
then I don't see the harm in waiting 13 months.  Leap 42.3 is out in 3 months, 
so the sooner update time would be just 3 months.  Could you jump to Leap 42.3 
at that time?

Re: Transformation of contrib/check_GNU_style.sh to a python script

[Florian Weimer]

* Martin Liška:

> validate(pfile.target_file.lstrip('b/'), line.target_line_no, 
> line.value)

Violates line length constraint. :)

My own egrep script also checks for/switch/if/while/do on the same
line as "{", and "(" not preceded by whitespace (currently has false
positves with the definition of function-like macros, among other
things).

Re: Ada gcc compiler for ia64-hp-openvms

[David SAUVAGE - AdaLabs Ltd]

On 04/29/2017 06:31 PM, David SAUVAGE - AdaLabs Ltd wrote:
> On 04/28/2017 06:47 PM, David Edelsohn wrote:
>> On Thu, Apr 27, 2017 at 10:55 AM, David SAUVAGE - AdaLabs Ltd
>>  wrote:
>>> Dear GCC Steering Committee,
>>>
>>> I am David, founder of AdaLabs Ltd, a software engineering startup
>>> having expertise in Ada programming language technologies. As a summary,
>>> we would like to know if gcc has interest in an assignment of copyright
>>> to FSF from our work. We are not used to this process, and are kindly
>>> soliciting your support on this task. Our work is about Ada compiler
>>> support on GCC for OpenVMS.
>>>
>>> AdaLabs Ltd (http://adalabs.com) and PIA-SOFER SARL
>>> (http://pia-sofer.fr) have worked hard to make Ada available again on
>>> OpenVMs using GCC (ia64-hp-openvms). Both entities share ownership,
>>> while AdaLabs is also the author of the work.
>>>
>>> Our work is based on gcc-4.7.4, and consists in building a gcc compiler
>>> for openvms ia64 (through native, cross and canadian build, starting
>>> from x86_64-linux-gnu to finally reach ia64-hp-openvms). The
>>> modifications are of two flavours:
>>> - patches to make the builds successful (in native, cross and canadian
>>> builds)
>>> - patches/backports to implement Ada/VMS related features, that are
>>> present in gcc version after gcc-4.7.4 (in native, cross and canadian
>>> builds).
>>>
>>> In the case you are interested in our copyright assignment proposal, we
>>> would be pleased to continue this process.
>>>
>>> In the case you are not interested in our copyright assignment proposal,
>>> we would be pleased if you could advise us on the best way to make our
>>> work available to the GNU/FSF community, especially concerning the
>>> licenses and copyrights management.
>>>
>>> I am at your disposal concerning any information you may need to take a
>>> stand concerning this proposal.
>> Hi, David
>>
>> The GCC Community always is open to considering patches to support new
>> languages, new targets and new features.
>>
>> When you say that the work is based on GCC 4.7.4, does that mean that
>> the patches are relative to GCC 4.7.4, as opposed to the current
>> development version of GCC?
>>
>> GCC only accepts patches relative to the current development sources.
>> Patches for bug fixes can be considered for backporting to an actively
>> maintained branch, but GCC does not accept patches for completely new
>> features to a release branch.  Also, GCC 4.7 initially was released 5
>> years ago and no longer accepts patches.
>>
>> Does the offer include continued support and maintenance of Ada/VMS to
>> ensure that it continues to function?  The GCC community requires
>> someone to assume responsibility for the continued function of the new
>> feature.
>>
>> Can you clarify some of the details of the offer?
>>
>> Thanks, David
> Great thanks for your feedbacks David,
> we will revert soon
>
> Regards
>
Dear David,

our 'assignment of copyright' proposal only target a set of patches for
GCC version 4.7.4. That is, as you clearly stated on your email above,
not part of GCC current development sources. As a consequence, I
understand that FSF/GCC is not in position to accept our proposal.

Grateful if you could confirm my understanding, as Gérard in copy of
this email is not used to the Libre Software world ...

This lead us to the last section of my initial email:
"[...] we would be pleased if you could advise us on the best way to
make our
work available to the GNU/FSF community, especially concerning the
licenses and copyrights management."

Any feedbacks on the above are most welcome.
Thanks again for your time,

Best Regards,

-- 

David SAUVAGE

Software Agile Architect, Director
AdaLabs Ltd - Mauritius
http://adalabs.com
+230 542 818 32
skype sauvaged
BRN C10097052




signature.asc
Description: OpenPGP digital signature

Re: Ada gcc compiler for ia64-hp-openvms

[David Edelsohn]

On Mon, May 15, 2017 at 12:54 PM, David SAUVAGE - AdaLabs Ltd
 wrote:
> On 04/29/2017 06:31 PM, David SAUVAGE - AdaLabs Ltd wrote:
>> On 04/28/2017 06:47 PM, David Edelsohn wrote:
>>> On Thu, Apr 27, 2017 at 10:55 AM, David SAUVAGE - AdaLabs Ltd
>>>  wrote:
 Dear GCC Steering Committee,

 I am David, founder of AdaLabs Ltd, a software engineering startup
 having expertise in Ada programming language technologies. As a summary,
 we would like to know if gcc has interest in an assignment of copyright
 to FSF from our work. We are not used to this process, and are kindly
 soliciting your support on this task. Our work is about Ada compiler
 support on GCC for OpenVMS.

 AdaLabs Ltd (http://adalabs.com) and PIA-SOFER SARL
 (http://pia-sofer.fr) have worked hard to make Ada available again on
 OpenVMs using GCC (ia64-hp-openvms). Both entities share ownership,
 while AdaLabs is also the author of the work.

 Our work is based on gcc-4.7.4, and consists in building a gcc compiler
 for openvms ia64 (through native, cross and canadian build, starting
 from x86_64-linux-gnu to finally reach ia64-hp-openvms). The
 modifications are of two flavours:
 - patches to make the builds successful (in native, cross and canadian
 builds)
 - patches/backports to implement Ada/VMS related features, that are
 present in gcc version after gcc-4.7.4 (in native, cross and canadian
 builds).

 In the case you are interested in our copyright assignment proposal, we
 would be pleased to continue this process.

 In the case you are not interested in our copyright assignment proposal,
 we would be pleased if you could advise us on the best way to make our
 work available to the GNU/FSF community, especially concerning the
 licenses and copyrights management.

 I am at your disposal concerning any information you may need to take a
 stand concerning this proposal.
>>> Hi, David
>>>
>>> The GCC Community always is open to considering patches to support new
>>> languages, new targets and new features.
>>>
>>> When you say that the work is based on GCC 4.7.4, does that mean that
>>> the patches are relative to GCC 4.7.4, as opposed to the current
>>> development version of GCC?
>>>
>>> GCC only accepts patches relative to the current development sources.
>>> Patches for bug fixes can be considered for backporting to an actively
>>> maintained branch, but GCC does not accept patches for completely new
>>> features to a release branch.  Also, GCC 4.7 initially was released 5
>>> years ago and no longer accepts patches.
>>>
>>> Does the offer include continued support and maintenance of Ada/VMS to
>>> ensure that it continues to function?  The GCC community requires
>>> someone to assume responsibility for the continued function of the new
>>> feature.
>>>
>>> Can you clarify some of the details of the offer?
>>>
>>> Thanks, David
>> Great thanks for your feedbacks David,
>> we will revert soon
>>
>> Regards
>>
> Dear David,
>
> our 'assignment of copyright' proposal only target a set of patches for
> GCC version 4.7.4. That is, as you clearly stated on your email above,
> not part of GCC current development sources. As a consequence, I
> understand that FSF/GCC is not in position to accept our proposal.
>
> Grateful if you could confirm my understanding, as Gérard in copy of
> this email is not used to the Libre Software world ...

Your understanding is correct.  GCC never accepts patches for a
specific version / release -- even if it is the current release.
Patches for new features or support must be contributed to the current
development version.

>
> This lead us to the last section of my initial email:
> "[...] we would be pleased if you could advise us on the best way to
> make our
> work available to the GNU/FSF community, especially concerning the
> licenses and copyrights management."
>
> Any feedbacks on the above are most welcome.
> Thanks again for your time,

Ideally, you should create a general copyright assignment to GCC -- a
"futures" assignment of all patches for GCC.  you can select which
patches to contribute.

If you insist on limiting it, you can specify files.  But that always
runs into the potential problem of files that were omitted from the
list (such as a configuration file) or changes to additional files
requested by reviewers.  Also, GCC generally likes developers to
continue to maintain contributions.

I don't know the relationship / friendliness between AdaLabs and
AdaCore.  Another possibility is that you make a private arrangement
to assign the copyright to AdaCore and they contribute the actual
patches to the GCC Project.

Thanks, David

Re: Transformation of contrib/check_GNU_style.sh to a python script

[Martin Sebor]

On 05/15/2017 07:55 AM, Martin Liška wrote:

Hello.

Recently I've been working on bigger changes to dump infrastructure and I had to
fix tens of formatting issues reported by check_GNU_style.sh script. The script 
works
quite fine, but it's very unpleasant that it reports problematic lines in the 
patch,
not in original patches.


I was a little confused by this but in the end decided that you
must have meant "not in the original sources."  I can see how
having the script generate a patch to fix the problems it finds
could be handy.

 I decided to substitute part of functionality by Python

script that uses a library that parses patches. So that reported errors can be
easily converted to quickfix list for VIM. That makes navigation very easy.

I'm attaching simple version that I made in couple of minutes and I would like 
to
ask whether the bash script is broadly used and whether community would be 
interested
in transformation of the script?


I use the script less and less as I become more comfortable with
the GCC style, and I don't expect to be making significant changes
to it.  I'm sure it can be improved and/or simplified but I have
developed a (shell/awk/sed) script of my own that automatically
fixes most of these little things for me while applying a patch,
so I don't have to worry about them while writing code.

That said, I don't really see a very compelling reason to rewrite
this script in Python or other high-level language, or add another
dependency for contributors to have to remember to install to use
it.  I'd rather see the effort invested into a smart commit hook
that would format all code for us the expected way automatically.
(That would save enough hassle to justify introducing a dependency
on almost any language or library ;-)

Martin

Re: dejagnu version update?

[Andreas Schwab]

On Mai 15 2017, Mike Stump  wrote:

> That said, a little surprising that SLE is lagging everyone else so
> hard.

DejaGnu doesn't exactly have frequent releases.  Missing just one
release can easily put you more than 5 years behind.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."