Re: Compiling programs licensed under the GPL version 2 with GCC 4.4

[Paolo Bonzini]

But if I change the run-time library, I still have to license those
changes under the GPLv3 if I want to distribute them, right?


Yes.  But if you change the runtime library and link something else with 
the modified runtime library, the "something else" does not fall 
automatically under the GPLv3, even if you distribute them together.


The runtime library must be accompanied by the preferred form for 
modification (source code), the "something else" can even be distributed 
as a binary.


Paolo

Re: trunk bootstrap failure in libgfortran for i686-pc-cygwin

[Tobias Burnus]

Hi Rainer,

Rainer Emrich wrote:
> error: 'I' undeclared (first use in this function)

That's PR 40863 and a patch has been posted to
http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01520.html

That patch should also remove all those
> warning: no previous prototype for 'csinhf'
warnings.

Tobias

Re: As-if Infinitely Ranged Integer Model

[Gabriel Paubert]

On Fri, Jul 24, 2009 at 06:25:12PM +0200, Laurent GUERBY wrote:
> On Fri, 2009-07-24 at 12:03 -0400, Robert Dewar wrote:
> > Indeed an alternative approach to handling this problem in GCC would
> > be to adapt the Ada model for C and C++ which would not be too hard
> > to do I suspect. Then gcc could be improved to handle this model
> > better and more effectively with respect to optimization, and both
> > C/C++ and Ada would benefit.
> 
> IIRC the Ada rules allows to raise Constraint_Error earlier
> rather than later which is interesting for check removal in loops for
> very common patterns:
> 
>for I in T'First .. Dynamic_N loop
>   T (I) := 0.0; -- generate check I in T'First .. T'Last
>end loop;
> 
> =>
> 
>if Dynamic_N >= T'First and Dynamic_N > T'Last then

Huh? I can't understand the first comparison. 

Actually Ada is not Fortran-66 and allows empty loops, no? 

>   raise Constraint_Error;
>end if;
>for I in T'First .. Dynamic_N loop
>   T (I) := 0.0; -- no generated check
>end loop; 
> 
> But I might be wrong in my recollection (and I don't think GNAT
> takes advantage of that), Robert?

I don't think so. And the code quality when checking for
overflows was abysmal last time I tried.

Regards,
Gabriel

Re: As-if Infinitely Ranged Integer Model

[Laurent GUERBY]

On Mon, 2009-07-27 at 09:34 +0200, Gabriel Paubert wrote:
> On Fri, Jul 24, 2009 at 06:25:12PM +0200, Laurent GUERBY wrote:
> >for I in T'First .. Dynamic_N loop
> >   T (I) := 0.0; -- generate check I in T'First .. T'Last
> >end loop;
> > 
> > =>
> > 
> >if Dynamic_N >= T'First and Dynamic_N > T'Last then
> 
> Huh? I can't understand the first comparison. 
> 
> Actually Ada is not Fortran-66 and allows empty loops, no? 

Ada for loop over "A .. B" will be empty if "A > B" and we obviously 
must not raise an exception if the loop is empty hence the first
comparison is equivalent to "not (T'First > Dynamic_N)" which is true
when the loop is not empty.

> I don't think so. And the code quality when checking for
> overflows was abysmal last time I tried.

We're talking about range checking here, not arithmetic overflow
checking (which is another topic where GCC infrastructure change
could help Ada of course).

Sincerely,

Laurent

Re: As-if Infinitely Ranged Integer Model

[Gabriel Paubert]

On Mon, Jul 27, 2009 at 10:46:53AM +0200, Laurent GUERBY wrote:
> On Mon, 2009-07-27 at 09:34 +0200, Gabriel Paubert wrote:
> > On Fri, Jul 24, 2009 at 06:25:12PM +0200, Laurent GUERBY wrote:
> > >for I in T'First .. Dynamic_N loop
> > >   T (I) := 0.0; -- generate check I in T'First .. T'Last
> > >end loop;
> > > 
> > > =>
> > > 
> > >if Dynamic_N >= T'First and Dynamic_N > T'Last then
> > 
> > Huh? I can't understand the first comparison. 
> > 
> > Actually Ada is not Fortran-66 and allows empty loops, no? 
> 
> Ada for loop over "A .. B" will be empty if "A > B" and we obviously 
> must not raise an exception if the loop is empty hence the first
> comparison is equivalent to "not (T'First > Dynamic_N)" which is true
> when the loop is not empty.

Thanks, this makes sense. I don't understand how I did not see it
when first reading the code. Sorry for the noise.

> 
> > I don't think so. And the code quality when checking for
> > overflows was abysmal last time I tried.
> 
> We're talking about range checking here, not arithmetic overflow
> checking (which is another topic where GCC infrastructure change
> could help Ada of course).

That would be a huge undertaking.

Regards,
Gabriel

Re: Compiling programs licensed under the GPL version 2 with GCC 4.4

[Florian Weimer]

* Paolo Bonzini:

>> But if I change the run-time library, I still have to license those
>> changes under the GPLv3 if I want to distribute them, right?
>
> Yes.  But if you change the runtime library and link something else
> with the modified runtime library, the "something else" does not fall
> automatically under the GPLv3, even if you distribute them together.

Yes---but we've been told repeatedly over the years that you cannot
link GPLv2 programs with libraries under a GPLv2-incompatible license
and ship both on the same media, even if the library license is not
copyleft-like and does not prevent this.  (If this was possible, it
would be rather trivial to work around the copyleft character of the
GPLv2.)

> The runtime library must be accompanied by the preferred form for
> modification (source code), the "something else" can even be
> distributed as a binary.

It's not the run-time library license that's the problem here.  It's
the GPLv2-only program whose license appears to be infringed by
linking against the run-time library and distributing the combined
result.

Keep in mind that for a GPLv2-only program, the GPLv3 is like a
proprietary license (quite similar in effect to the Apache License
2.0, or the OpenSSL license, or the QPL, or the BSD license with the
advertising clause).

I wouldn't object if the FSF publicly declared that under their
interpretation of the GPLv2, the system library exception in the GPLv2
allows us to link against libraries shipped in a separate Debian
package, dynamically or statically.  We likely have that permission
under copyright anyway.  It's just against everything the FSF has told
us over the years, so I don't think it will happen.

(Legally, a placet from the FSF doesn't buy as anything, of course,
because individual copyright holders may not share the FSF
interpretation.  But it would be a signal nevertheless.)

Re: Compiling programs licensed under the GPL version 2 with GCC 4.4

[Alfred M. Szmidt]

Please take this up with le...@gnu.org.

Re: Compiling programs licensed under the GPL version 2 with GCC 4.4

[Robert Dewar]

There is so much incorrect information in this thread that
I would not even try to start to fix it, since it would
just cause more confusion than is already there. I would
just remind people that

a) discussions of licensing issues are off topic on this mailing list

b) you should ignore all such discussions, since they invariablly
   include lots of legal-sounding opinions from people who are not
   lawyers and don't know, and often have significant misconceptions.

c) remember that even lawyers don't know what the exactly implications
   of copyright law are, juries often surprise. So even if you go ask
   a lawyer, you won't get a definitive opinion.

Re: Compiling programs licensed under the GPL version 2 with GCC 4.4

[Paolo Bonzini]

b) you should ignore all such discussions, since they invariablly
include lots of legal-sounding opinions from people who are not
lawyers and don't know, and often have significant misconceptions.


Indeed I'm not answering to Florian's latest message, because I'm not 
sure what he misunderstood of my message and I would probably give out 
wrong information.


But I don't see much misinformation in the replies so far (can't judge 
mine of course), unlike other recent licensing threads.


Paolo

Re: As-if Infinitely Ranged Integer Model

[Robert Dewar]

Laurent GUERBY wrote:


I don't think so. And the code quality when checking for
overflows was abysmal last time I tried.


We're talking about range checking here, not arithmetic overflow
checking (which is another topic where GCC infrastructure change
could help Ada of course).


Actually in terms of the thread (infinitely ranged integer model),
you are clearly to me talking about both, so you need to look at
the Ada model with overflow checks enabled (or GNAT with the
-gnato flag set).

BTW, the history is interesting here. The back end has never had
good support for overflow checking for integers (I keep getting
told that -ftrapv doesn't work, and in any case 15 years ago it
was not there).

So I implemented a temporary junk circuit to do the overflow
checking required by the standard (usually it works by using
double length arithmetic followed by a range check). It was
indeed nasty and intended to be temporary, which is why it is
still not on by default.

Recently however, Geert did a major renovation of overflow
checking and already it is much more efficient. Continued
improvements in the area of range/overflow checking that
are being worked on now will further improve matters and
greatly reduce the overhead from run time checking in GNAT.

We will probably make -gnato the default once this work
is complete, depending on how efficiency tests work out.

Robert

Re: As-if Infinitely Ranged Integer Model

[Robert Dewar]

Laurent GUERBY wrote:


   if Dynamic_N >= T'First and Dynamic_N > T'Last then
Huh? I can't understand the first comparison. 

Actually Ada is not Fortran-66 and allows empty loops, no? 


Ada for loop over "A .. B" will be empty if "A > B" and we obviously 
must not raise an exception if the loop is empty hence the first

comparison is equivalent to "not (T'First > Dynamic_N)" which is true
when the loop is not empty.


Right, the loop can be empty, so if you can't prove that at compile
time (you often can), then you need to do a dynamic test. Only if
you know the loop will run once can you hoist the check (or sink
it, but you might as well hoist!) GNAT does not do this kind of
hoisting, it is really something for the back end optimization
circuits, not front end fiddling, though this particular case
could be fiddled in the front end.

Re: As-if Infinitely Ranged Integer Model

[Robert Dewar]

Gabriel Paubert wrote:


We're talking about range checking here, not arithmetic overflow
checking (which is another topic where GCC infrastructure change
could help Ada of course).


That would be a huge undertaking.


Indeed, but such an undertaking might make sense if it was helpful
for C/C++ running in this special mode as well as helpful for Ada
with checks on.


Regards,
Gabriel

Re: Compiling programs licensed under the GPL version 2 with GCC 4.4

[Manuel López-Ibáñez]

2009/7/27 Robert Dewar :
> a) discussions of licensing issues are off topic on this mailing list
>
> b) you should ignore all such discussions, since they invariablly
>   include lots of legal-sounding opinions from people who are not
>   lawyers and don't know, and often have significant misconceptions.
>
> c) remember that even lawyers don't know what the exactly implications
>   of copyright law are, juries often surprise. So even if you go ask
>   a lawyer, you won't get a definitive opinion.

These three points could be included in a standard answer to licensing
questions posted to g...@. Invariably, all such threads are a waste of
time and bandwidth. Perhaps we can include the standard answer in some
webpage so we can copy+paste or just point to it. A first attempt at:
http://gcc.gnu.org/wiki/Licensing

Cheers,

Manuel.

Re: Compiling programs licensed under the GPL version 2 with GCC 4.4

[Dave Korn]

Robert Dewar wrote:

> b) you should ignore all such discussions, since they invariablly
>include lots of legal-sounding opinions from people who are not
>lawyers and don't know, and often have significant misconceptions.

  :) We have a name for that on the cygwin list:

  http://cygwin.com/acronyms/#YANALATEYHSMBSI

cheers,
  DaveK

Re: Compiling programs licensed under the GPL version 2 with GCC 4.4

[Florian Weimer]

* Robert Dewar:

> b) you should ignore all such discussions, since they invariablly
>include lots of legal-sounding opinions from people who are not
>lawyers and don't know, and often have significant misconceptions.

This is not about legal issues.  It's about FSF policy.  If I wanted
legal advice, I'd ask a lawyer, and rely on that advice (to the extent
that is possible), even if it is at odds with what the FSF or the GCC
developers presumably want (like an effective copyleft for GCC with
modules).

It seems to me that the new GCC run-time library license has the side
effect of forcing GPLed software to upgrade to GPL version 3 to remain
redistributable in compiled form.  If this is not your intent (as GCC
developers), I think the Steering Committee should ask the FSF for
official clarification on this matter.  I'd also like to know what we
should do with the Objective Caml compiler in Debian, by the way.

My main issue is that I don't see how, under the same set of policies,
it can be acceptable to link a GPLv2 program to GPLv3 system libraries
covered by the GCC library exception, but it's not okay to link
another GPLv2 program to Apache-2.0-licensed system libraries.  Both
library licenses do not infect the program, and both licenses are
incompatible with the GPLv2 (according to the FSF).  Or am I nuts and
this mismatch does not exist?

The problem with "go ask the FSF" is that they don't react in a
reasonable time frame (beyond an auto-ack from their trouble ticket
system).

Re: Compiling programs licensed under the GPL version 2 with GCC 4.4

[Alfred M. Szmidt]

   > a) discussions of licensing issues are off topic on this mailing list
   >
   > b) you should ignore all such discussions, since they invariablly
   > � include lots of legal-sounding opinions from people who are not
   > � lawyers and don't know, and often have significant misconceptions.
   >
   > c) remember that even lawyers don't know what the exactly implications
   > � of copyright law are, juries often surprise. So even if you go ask
   > � a lawyer, you won't get a definitive opinion.

   These three points could be included in a standard answer to
   licensing questions posted to g...@. Invariably, all such threads
   are a waste of time and bandwidth. Perhaps we can include the
   standard answer in some webpage so we can copy+paste or just point
   to it. A first attempt at: http://gcc.gnu.org/wiki/Licensing

The effort is laudable, but the above text has a negative sounding
tone.  It doesn't point users in the right direction.

How about the following wording,

  The most common questions and answers regarding the GNU GPL and how
  it applies can be found in the GNU GPL FAQ
  , if you cannot find the
  answer there please contact  instead of posting your
  question on one of the GCC mailing-lists.

Re: Compiling programs licensed under the GPL version 2 with GCC 4.4

[Robert Dewar]

Florian Weimer wrote:

* Robert Dewar:


b) you should ignore all such discussions, since they invariablly
   include lots of legal-sounding opinions from people who are not
   lawyers and don't know, and often have significant misconceptions.


This is not about legal issues.  It's about FSF policy.  If I wanted
legal advice, I'd ask a lawyer, and rely on that advice (to the extent
that is possible), even if it is at odds with what the FSF or the GCC
developers presumably want (like an effective copyleft for GCC with
modules).


Discussion of FSF policy on licensing issues is also off-topic for
this mailing list.

Re: Compiling programs licensed under the GPL version 2 with GCC 4.4

[Robert Dewar]

Dave Korn wrote:

Robert Dewar wrote:


b) you should ignore all such discussions, since they invariablly
   include lots of legal-sounding opinions from people who are not
   lawyers and don't know, and often have significant misconceptions.


  :) We have a name for that on the cygwin list:

  http://cygwin.com/acronyms/#YANALATEYHSMBSI


I would only add that being a lawyer does not mean that everything
you say should be taken at face value :-)


cheers,
  DaveK

Re: Compiling programs licensed under the GPL version 2 with GCC 4.4

[Manuel López-Ibáñez]

2009/7/27 Alfred M. Szmidt :
>   These three points could be included in a standard answer to
>   licensing questions posted to g...@. Invariably, all such threads
>   are a waste of time and bandwidth. Perhaps we can include the
>   standard answer in some webpage so we can copy+paste or just point
>   to it. A first attempt at: http://gcc.gnu.org/wiki/Licensing
>
> The effort is laudable, but the above text has a negative sounding
> tone.  It doesn't point users in the right direction.
>
> How about the following wording,
>

It is in the wiki precisely so people can freely modify/add/remove text.

Cheers,

Manuel.

Re: As-if Infinitely Ranged Integer Model

[Richard Kenner]

> Only if you know the loop will run once can you hoist the check (or
> sink it, but you might as well hoist!) GNAT does not do this kind of
> hoisting, it is really something for the back end optimization
> circuits, not front end fiddling, though this particular case could
> be fiddled in the front end.

You could hoist the check and conditionalize it on the condition under
which the loop will run at least once, but I don't think anybody has
code to do that sort of thing.

GCC 4.3.4 Status Report (2009-07-27), branch frozen

[Richard Guenther]

Status
==

The 4.3 branch is now frozen in preparation for the GCC 4.3.4 release.
I am creating a release candidate right now.  All patches require
release-manager approval.

Quality Data


Priority  # Change from Last Report
--- ---
P10 -1
P2  132 -5
P30 -2
--- ---
Total   132 -8

Previous Report
===

http://gcc.gnu.org/ml/gcc/2009-01/msg00233.html


The next report will be sent by me.

Re: As-if Infinitely Ranged Integer Model

[Paolo Bonzini]

On 07/27/2009 12:25 PM, Robert Dewar wrote:

Laurent GUERBY wrote:


if Dynamic_N >= T'First and Dynamic_N > T'Last then

Huh? I can't understand the first comparison.
Actually Ada is not Fortran-66 and allows empty loops, no?


Ada for loop over "A .. B" will be empty if "A > B" and we obviously
must not raise an exception if the loop is empty hence the first
comparison is equivalent to "not (T'First > Dynamic_N)" which is true
when the loop is not empty.


GNAT does not do this kind of hoisting, though this particular case
could be fiddled in the front end.


I suppose though that in Ada Dynamic_N will often be a subtype of T, at 
which point the hoisting is pointless because you know that the check 
passes.


Paolo

Re: As-if Infinitely Ranged Integer Model

[Laurent GUERBY]

On Mon, 2009-07-27 at 15:32 +0200, Paolo Bonzini wrote:
> On 07/27/2009 12:25 PM, Robert Dewar wrote:
> > Laurent GUERBY wrote:
> >
>  if Dynamic_N >= T'First and Dynamic_N > T'Last then
> >>> Huh? I can't understand the first comparison.
> >>> Actually Ada is not Fortran-66 and allows empty loops, no?
> >>
> >> Ada for loop over "A .. B" will be empty if "A > B" and we obviously
> >> must not raise an exception if the loop is empty hence the first
> >> comparison is equivalent to "not (T'First > Dynamic_N)" which is true
> >> when the loop is not empty.
> >
> > GNAT does not do this kind of hoisting, though this particular case
> > could be fiddled in the front end.
> 
> I suppose though that in Ada Dynamic_N will often be a subtype of T, at 
> which point the hoisting is pointless because you know that the check 
> passes.

In most Ada code array T index type will likely be "Natural range <>"
and so the type system will not give useful bounds for optimizations.

Laurent

Re: As-if Infinitely Ranged Integer Model

[Robert Dewar]

Laurent GUERBY wrote:


In most Ada code array T index type will likely be "Natural range <>"
and so the type system will not give useful bounds for optimizations.


Well very often the bounds of the loop are taken from the bounds
of the array, so I don't agree with that statement :-)


Laurent

Re: Compiling programs licensed under the GPL version 2 with GCC 4.4

[Frank Ch. Eigler]

Robert Dewar  writes:

> [...]
>>> b) you should ignore all such discussions, since they invariablly
>>>include lots of legal-sounding opinions from people who are not
>>>lawyers and don't know, and often have significant misconceptions.
>>
>> This is not about legal issues.  It's about FSF policy.  [...]

(Perhaps this was a poorly chosen summary sentence; Florian's next
paragraph more clearly asks the GCC developers' opinion:

# It seems to me that the new GCC run-time library license has the
# side effect of forcing GPLed software to upgrade to GPL version 3 to
# remain redistributable in compiled form.  If this is not your intent
# (as GCC developers), I think the Steering Committee should ask the
# FSF for official clarification on this matter.


> Discussion of FSF policy on licensing issues is also off-topic for
> this mailing list.

Perhaps, yet the libgcc exception licensing issues were quite
prominently discussed right here, and not too many months ago.
Florian's concern sounds linearly connected to that.  If this is as
trivial a matter as some people seem to hint, perhaps someone can
supply a link to a prior discussion for it.


- FChE

Re: As-if Infinitely Ranged Integer Model

[Laurent GUERBY]

On Mon, 2009-07-27 at 10:28 -0400, Robert Dewar wrote:
> Laurent GUERBY wrote:
> 
> > In most Ada code array T index type will likely be "Natural range <>"
> > and so the type system will not give useful bounds for optimizations.
> 
> Well very often the bounds of the loop are taken from the bounds
> of the array, so I don't agree with that statement :-)

It's likely true for loops handling only one array as in my choosen
example :). 

But as soon as you have more than one array - starting with not so
complex code as vector dot product or more than one string operations -
this is no longer true and you'll see "1 .. T1'Length" loop range and
some index arithmetic.

Laurent

Re: Failure in a complete build of current gcc snapshot

[Tom Tromey]

> "Ralf" == Ralf Wildenhues  writes:

Ralf> OK to install this trivial patch if it passes the build I'm running
Ralf> right now, as well as a normal and a DESTDIR install I'll be doing
Ralf> afterwards?

Ralf> AFAICS the python directory is new in trunk, so no stable releases
Ralf> affected.

Oops, sorry about that.

I think this patch qualifies as obvious.

Tom

GCC 4.3.4 release candidate available

[Richard Guenther]

A release candidate for the GCC 4.3.4 is now available at

ftp://gcc.gnu.org/pub/gcc/snapshots/4.3.4-RC-20090727

I plan to roll out the final release at the beginning of next week
if there are no major problems reported.

All checkins to the 4.3 branch require release manager approval.

Thanks,
Richard

-- 
Richard Guenther 
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex

Xilinx MicroBlaze port

[Michael Eager]

Hi --

This is just a heads-up that I'm working on GCC support
for the Xilinx MicroBlaze.  It is currently based on
gcc-4.1.2 and I'm porting it to gcc-4.5.0.

--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

removing -Wtraditional-conversion

[Manuel López-Ibáñez]

GCC 4.5 will remove protoize and unprotoize. I wonder whether we
should also remove -Wtraditional-conversion and their associated
warnings and testcases.


@item -Wtraditional-conversion @r{(C and Objective-C only)}
@opindex Wtraditional-conversion
@opindex Wno-traditional-conversion
Warn if a prototype causes a type conversion that is different from what
would happen to the same argument in the absence of a prototype.  This
includes conversions of fixed point to floating and vice versa, and
conversions changing the width or signedness of a fixed point argument
except when the same as the default promotion.


and from http://gcc.gnu.org/onlinedocs/gcc-4.4.0/gcc/Protoize-Caveats.html


Using unprotoize can easily introduce bugs. If the program relied on
prototypes to bring about conversion of arguments, these conversions
will not take place in the program without prototypes. One case in
which you can be sure unprotoize is safe is when you are removing
prototypes that were made with protoize; if the program worked before
without any prototypes, it will work again without them.

You can find all the places where this problem might occur by
compiling the program with the -Wtraditional-conversion option. It
prints a warning whenever an argument is converted."


However, this page does not exist anymore on trunk, so I wonder what
is the possible use of -Wtraditional-conversion now.

Cheers,

Manuel.

Re: removing -Wtraditional-conversion

[Mark Mitchell]

Manuel López-Ibáñez wrote:

> GCC 4.5 will remove protoize and unprotoize. I wonder whether we
> should also remove -Wtraditional-conversion and their associated
> warnings and testcases.

I don't see any reason to do that.  The warning is independent of
whether or not we provide tools to introduce or remove prototypes; it's
useful for people who still have (even partially) K&R codebases.  And
there are plenty of such people.

-- 
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713

Re: Failure in a complete build of current gcc snapshot

[Ralf Wildenhues]

* Tom Tromey wrote on Mon, Jul 27, 2009 at 06:03:54PM CEST:
> > "Ralf" == Ralf Wildenhues  writes:
> 
> Ralf> OK to install this trivial patch if it passes the build I'm running
> Ralf> right now, as well as a normal and a DESTDIR install I'll be doing
> Ralf> afterwards?

> I think this patch qualifies as obvious.

Alright.  Installed.

Thanks,
Ralf

Re: Compiling programs licensed under the GPL version 2 with GCC 4.4

[Paolo Bonzini]

On 07/25/2009 10:53 PM, Florian Weimer wrote:

The run-time library is GPL version 3 or
later, which is incompatible with GPL version 2, so it is not
permitted to link this with the GPLv2-only program and distribute the
result.  (Previous discussions have centered on infringing GCC's
license, so this is different.)


You should have said why here or at least further down in the thread. 
Instead you always used vague terms.


I now understand fully the issue because it was pointed out to me 
outside the ML in a much more complete way.  And it is definitely none 
of this list's business---which is why I'm not mentioning the real 
source of doubt in this message, either.


Paolo

Re: How to figure out the gcc -dP output?

[Steven Bosscher]

On Mon, Jul 27, 2009 at 6:58 PM, Tim Crook wrote:
> Hi again Steven.
>
>
>
> I found a possible compiler workaround, compiling with –mminimal-toc. Would
> I get better performance by using this, instead of turning off gcse?

I have no idea, but one of the AIX maintainers can probably help you.

Ciao!
Steven

Re: [trans-mem] cgraph edges vs function cloning

[Richard Henderson]

  struct cgraph_edge *edge = cgraph_edge (id->src_node, orig_stmt);

POINT_A

  int flags;

  switch (id->transform_call_graph_edges)
{
  case CB_CGE_DUPLICATE:
if (edge)
  cgraph_clone_edge (edge, id->dst_node, stmt,
   REG_BR_PROB_BASE, 1,
   edge->frequency, true);
break;

  case CB_CGE_MOVE_CLONES:
cgraph_set_call_stmt_including_clones (id->dst_node, orig_stmt, 
stmt);
break;

  case CB_CGE_MOVE:
if (edge)
  cgraph_set_call_stmt (edge, stmt);

POINT_B

break;

  default:
gcc_unreachable ();
}

edge = cgraph_edge (id->src_node, orig_stmt);

POINT_C

/* Constant propagation on argument done during inlining
   may create new direct call.  Produce an edge for it.  */
if ((!edge
 || (edge->indirect_call
 && id->transform_call_graph_edges == CB_CGE_MOVE_CLONES))
&& is_gimple_call (stmt)
&& (fn = gimple_call_fndecl (stmt)) != NULL)

POINT_D

This code cannot possibly work.

We begin by looking up the edge at POINT_A.
We then move the edge at POINT_B.
We then look up the edge *again* at POINT_C.
Ought we be surprised when we do not find the edge at POINT_D?

After POINT_D, we "fix" the missing edge by creating a new one, which of 
course is a duplicate, which then of course leads to verification failure.


I think POINT_B is additionally buggy in that we've just corrupted
the cgraph node for the source function when we wanted to change the 
destination function.  I believe we should have done


  case CB_CGE_MOVE:
edge = cgraph_edge (id->dst_node, orig_stmt);
cgraph_set_call_stmt (edge, stmt);
// Possibly fix up indirect->direct call here.

Although, frankly I think it would be easiest to *only* create edges 
here.  There ought to be no problem doing the cgraph_clone_edge here
instead of in cgraph_copy_node_for_versioning.  That would still 
preserve all of the information you wanted that's attached to the edges.


Thoughts?


r~

Re: Failure in a complete build of current gcc snapshot

[Angelo Graziosi]

Ralf Wildenhues ha scritto:

* Tom Tromey wrote on Mon, Jul 27, 2009 at 06:03:54PM CEST:

"Ralf" == Ralf Wildenhues  writes:

Ralf> OK to install this trivial patch if it passes the build I'm running
Ralf> right now, as well as a normal and a DESTDIR install I'll be doing
Ralf> afterwards?



I think this patch qualifies as obvious.


Alright.  Installed.


Shouldn't Makefile.in be rebuilt? On Cygwin without applying a similar 
patch to Makefile.in, it still fails.



Cheers,
Angelo.

Re: Compiling programs licensed under the GPL version 2 with GCC 4.4

[Russ Allbery]

f...@redhat.com (Frank Ch. Eigler) writes:
> Robert Dewar  writes:

>> Discussion of FSF policy on licensing issues is also off-topic for
>> this mailing list.

> Perhaps, yet the libgcc exception licensing issues were quite
> prominently discussed right here, and not too many months ago.
> Florian's concern sounds linearly connected to that.  If this is as
> trivial a matter as some people seem to hint, perhaps someone can supply
> a link to a prior discussion for it.

Furthermore, the people Robert is telling him to go ask are not replying
to their e-mail.  Given that, on-topic or not, I think it's hardly
surprising for the issue to come up here.  The most effective way to keep
it from coming up here would seem to be for them to start answering their
e-mail.

-- 
Russ Allbery (r...@stanford.edu) 

Re: Compiling programs licensed under the GPL version 2 with GCC 4.4

[Joe Buck]

On Mon, Jul 27, 2009 at 05:34:34PM -0700, Russ Allbery wrote:
> f...@redhat.com (Frank Ch. Eigler) writes:
> > Robert Dewar  writes:
> 
> >> Discussion of FSF policy on licensing issues is also off-topic for
> >> this mailing list.
> 
> > Perhaps, yet the libgcc exception licensing issues were quite
> > prominently discussed right here, and not too many months ago.
> > Florian's concern sounds linearly connected to that.  If this is as
> > trivial a matter as some people seem to hint, perhaps someone can supply
> > a link to a prior discussion for it.
> 
> Furthermore, the people Robert is telling him to go ask are not replying
> to their e-mail.  Given that, on-topic or not, I think it's hardly
> surprising for the issue to come up here.  The most effective way to keep
> it from coming up here would seem to be for them to start answering their
> e-mail.

I would suggest that affected distributors contact the SFLC for an opinion
and advice.  I think that they are in the best position to work both with
the FSF and with other free software distributors to determine if there
is a genuine problem, what the scope of it is, and make suggestions
for a resolution.  They've done work for many other free software projects
outside of the FSF.

Continued use of this list to discuss the matter isn't going to produce
any reliable conclusions or good results.

Re: Failure in a complete build of current gcc snapshot

[Ralf Wildenhues]

* Angelo Graziosi wrote on Tue, Jul 28, 2009 at 01:20:00AM CEST:
> Ralf Wildenhues ha scritto:
> >* Tom Tromey wrote on Mon, Jul 27, 2009 at 06:03:54PM CEST:
> >
> >>I think this patch qualifies as obvious.
> >
> >Alright.  Installed.
> 
> Shouldn't Makefile.in be rebuilt?

D'oh.  Fixed now.

Thanks,
Ralf