plugins vs. licensing
Couldn't the plugin interface require a copyrighted passphrase to be sent by the plugin when it registeres, and the passphrase can then be licensed under the GPL. Thus, plugins that want to interface with an official FSF gcc will have to be GPLed in order to talk to the plugin interface, and we don't need to tinker with the runtime licensing.
Re: plugins vs. licensing
Joern Rennecke wrote: Couldn't the plugin interface require a copyrighted passphrase to be sent by the plugin when it registeres, and the passphrase can then be licensed under the GPL. Thus, plugins that want to interface with an official FSF gcc will have to be GPLed in order to talk to the plugin interface, and we don't need to tinker with the runtime licensing. I must say that I am confused by this whole issue, it is clear to me that gcc and a plugin are part of an integrated program and not a mere aggregation, so I have no idea why a proprietary plugin would be allowed. If you write a program which can ONLY function as an extension of another program, it is clearly a deriviative work of that other program I would say. Oh well off topic for this list ...
P.S. to: plungins and licensing
To give it a bit more legal bite with respect to ruling out accidental infringement, I suppose the passphrase could include a statement that assures that the sending program is licensed under the GPL. Another thing is that if it is considered possible that the passphrase an be distributed as a separate entity and merely aggregated with the plugin, it could be licensed under a more stringent license than the GPL which is more effective at attaining the goal of requiring GPLed plugins. The plugin interface could compute a cryptographic hash which the license can then allow to be licensed under the GPL so it can be included into cc1 binary.
Re: GCC 4.2.2 arm-linux-gnueabi: c++ exceptions handling?
Hello Martin, Martin Guy wrote: On 9/26/08, Sergei Poselenov <[EMAIL PROTECTED]> wrote: Hello all, I've built the above cross-compiler and ran the GCC testsuite. Noted a lot of c++ tests failed with the same output: ... terminate called after throwing an instance of 'int' terminate called recursively Are you configuring cross glibc with --disable-libunwind-exceptions? This has been necessary for all ARM EABI cross-compilers I've built so far. Yes, I've tried this too, without success. Just of curiosity, I tried the exact prerelease version the http://gcc.gnu.org/ml/gcc-testresults/2007-09/msg00570.html was using for test - it failed too. I suppose the problem is in Gcc. Could someone having the 4.2 release series compiler configured for ARM EABI target try this simple test: I just tried it with the native Debian ARM EABI compiler: gcc-4.2.4, binutils-2.18.0.20080103, glibc-2.7 and it silently exits(0). I tried gcc-4.2.4-glibc-2.6 and glibc-2.7, with no avail. I suppose the Debian version of 4.2.4 has its own set of patches. Also, the combination of latest tools make it work: gcc-4.3.2-glibc-2.7-binutils-2.18. FWIW, their g++-4.2 is also configured with explicit --disable-sjlj-exceptions, although that seems to be the default. Yes, it is disabled by default. Thanks a lot! Sergei
Re: P.S. to: plungins and licensing
On Mon, Sep 29, 2008 at 03:10:28PM +0100, Joern Rennecke wrote: > To give it a bit more legal bite There are no lawyers on this list (that I'm aware of). If you want to discuss this, please contact the FSF or SC directly instead. It does no good here. -- Daniel Jacobowitz CodeSourcery
Re: P.S. to: plungins and licensing
You would not want a lawyer designing a compiler, so why... Honestly, this is not helping. This is a technological forum and this is not a technological issue but a legal one. So, even if you knew a lawyer who wishes to help and work with the FSF to address the legal issue, this is not the right mailing list. You/he/she should contact the FSF and the SFLC instead. Thanks, Manuel. 2008/9/29 Joern Rennecke <[EMAIL PROTECTED]>: > To give it a bit more legal bite with respect to ruling out accidental > infringement, I suppose the passphrase could include a statement that > assures that the sending program is licensed under the GPL. > > Another thing is that if it is considered possible that the passphrase > an be distributed as a separate entity and merely aggregated with the plugin, > it could be licensed under a more stringent license than the GPL which > is more effective at attaining the goal of requiring GPLed plugins. > The plugin interface could compute a cryptographic hash which the license > can then allow to be licensed under the GPL so it can be included into > cc1 binary. >
Re: P.S. to: plungins and licensing
On Mon, Sep 29, 2008 at 10:37 AM, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote: > You would not want a lawyer designing a compiler, so why... > Oh. I guess i'll just hang up my hat then ...
Re: plugins vs. licensing
On Mon, Sep 29, 2008 at 02:54:26PM +0100, Joern Rennecke wrote: > Couldn't the plugin interface require a copyrighted passphrase to be > sent by the plugin when it registeres, and the passphrase can then > be licensed under the GPL. Please, let's stop this.
Does IRA support stack slot sharing for locals and spilled pseudos?
Hello, I'm seeing a miscompilation on sel-sched branch that at first sight looks related to IRA merge. alias.c::anti_dependence disambiguates references to (mem/c:DI (reg:DI 122 r122 [121]) [64 ivtmp.743+0 S8 A64]) and (mem/c:DI (reg:DI 122 r122) [64 ivtmp.1640+0 S8 A64]) while there are no stores to r122 between corresponding insns. It does so because nonoverlapping_memrefs_p returns TRUE for these mems, which is, in turn, due to this code: 2118 /* If either RTL is not a MEM, it must be a REG or CONCAT, meaning they 2119 can't overlap unless they are the same because we never reuse that part 2120 of the stack frame used for locals for spilled pseudos. */ 2121 if ((!MEM_P (rtlx) || !MEM_P (rtly)) 2122 && ! rtx_equal_p (rtlx, rtly)) 2123 return 1; Corresponding RTL_DECLS are: rtlx = (reg:DI 97 r105 [orig:850 ivtmp.743 ] [850]) rtly = (mem/c:DI (plus:DI (reg/f:DI 111 r119) (const_int -1456 [0xfa50])) [64 ivtmp.1640+0 S8 A64]) Does IRA support stack slot sharing described in the comment? Thanks. -- Alexander Monakov
Re: Does IRA support stack slot sharing for locals and spilled pseudos?
Alexander Monakov <[EMAIL PROTECTED]> wrote on 09/29/2008 01:34:12 PM:
> I'm seeing a miscompilation on sel-sched branch that at first sight looks
> related to IRA merge.
>
> alias.c::anti_dependence disambiguates references to
> (mem/c:DI (reg:DI 122 r122 [121]) [64 ivtmp.743+0 S8 A64])
> and
> (mem/c:DI (reg:DI 122 r122) [64 ivtmp.1640+0 S8 A64])
> while there are no stores to r122 between corresponding insns.
>
> It does so because nonoverlapping_memrefs_p returns TRUE for these mems,
which
> is, in turn, due to this code:
>
> 2118 /* If either RTL is not a MEM, it must be a REG or CONCAT, meaning
they
> 2119 can't overlap unless they are the same because we never
> reuse that part
> 2120 of the stack frame used for locals for spilled pseudos. */
> 2121 if ((!MEM_P (rtlx) || !MEM_P (rtly))
> 2122 && ! rtx_equal_p (rtlx, rtly))
> 2123 return 1;
>
> Corresponding RTL_DECLS are:
> rtlx = (reg:DI 97 r105 [orig:850 ivtmp.743 ] [850])
> rtly = (mem/c:DI (plus:DI (reg/f:DI 111 r119)
> (const_int -1456 [0xfa50])) [64 ivtmp.1640+0 S8 A64])
>
> Does IRA support stack slot sharing described in the comment?
We just got done walking through a failure with 200.sixtrack that looks
like the same thing. The two insns involved are:
(insn 33168 33162 33175 27 maincr.f:1 (set (reg/f:DI 14 14 [orig:614
ivtmp.1309 ] [614])
(mem/c:DI (plus:DI (reg:DI 11 11)
(const_int -7080 [0xe458])) [101 ivtmp.1309+0
S8 A64])) 349 {*movdi_internal64} (nil))
(insn 33175 33168 33176 27 maincr.f:1 (set (mem/c:DF (plus:DI (reg:DI 11 11
[5])
(const_int -7080 [0xe458])) [101 D.3497+0 S8
A64])
(reg:DF 45 13 [orig:765 D.3497 ] [765])) 336 {*movdf_hardfloat64}
(expr_list:REG_DEAD (reg:DF 45 13 [orig:765 D.3497 ] [765])
(nil)))
The MEM refs are not seen as overlapping which then allows the scheduler to
reorder the store to MEM above the load. The problem is brought about
because an additional register is needed to access the stack location since
it is beyond the 32K limit for PPC. So before these references we have an
insn 'r11 = r1 + 64K'. The code in alias.c:stack_addr_p() does not
recognize r11 as pointing to the stack and therefor the IRA code in
nonoverlapping_memrefs_p() does not recognize the above MEMs as being stack
references and use the special code for reused ira spill slots. It seems
like stack_addr_p() doesn't handle reg+reg addressing also, only
recognizing reg+const references (unless those are meant to be caught
elsewhere).
Re: IRA accumulated costs
Richard Sandiford wrote:
If PARENT_A is a parent of allocno A, propagate_allocno_info does
the equivalent of:
ALLOCNO_HARD_REG_COSTS(parent_a)[i] += ALLOCNO_HARD_REG_COSTS(a)[i]
which is what you'd expect from the comments. But after that,
should each update ALLOCNO_HARD_REG_COSTS(a)[i] be reflected in
ALLOCNO_HARD_REG_COSTS(parent_a)[i]? It isn't entirely clear
from the code.
E.g. process_regs_for_copy (which I believe is called after
propagate_allocno_info) updates ALLOCNO_HARD_REG_COSTS:
ALLOCNO_HARD_REG_COSTS (a)[index] -= cost;
and I can't see how this update would ever propagate to parent allocnos.
That is true. I've checked and found that changes in
process_regs_for_copy are not propagated to upper level. It is a part
of add_copies and copies themself are propagated later but not changes
in hard register costs. It should be fixed. Thank you for finding this.
Also, color_pass has a loop that updates the costs of child allocnos
after a parent has been allocated:
I should think more about this. This propagation is actually intention
what is better to use in subloops. It could be fixed as 1) updating
costs in superloops or 2) restoring costs in subloops and changing
costs in subloops and superloops based on the allocation result in
subloops and superloops.
/* Update costs of the corresponding allocnos (not caps) in the
subloops. */
for (subloop_node = loop_tree_node->subloops;
subloop_node != NULL;
subloop_node = subloop_node->subloop_next)
{
...
}
A lot of the fields updated here are described as "accumulated",
but the updates to SUBLOOP_ALLOCNO aren't reflected in A (or A's parents).
You might be wondering why this matters. Well, ALLOCNO_HARD_REG_COSTS
is sometimes accessed after coloring is complete. move_spill_restore
is one such function, and has:
FOR_EACH_ALLOCNO (a, ai)
{
regno = ALLOCNO_REGNO (a);
loop_node = ALLOCNO_LOOP_TREE_NODE (a);
if (ALLOCNO_CAP_MEMBER (a) != NULL
|| ALLOCNO_CAP (a) != NULL
|| (hard_regno = ALLOCNO_HARD_REGNO (a)) < 0
|| loop_node->children == NULL
/* don't do the optimization because it can create
copies and the reload pass can spill the allocno set
by copy although the allocno will not get memory
slot. */
|| ira_reg_equiv_invariant_p[regno]
|| ira_reg_equiv_const[regno] != NULL_RTX
|| !bitmap_bit_p (loop_node->border_allocnos, ALLOCNO_NUM (a)))
continue;
mode = ALLOCNO_MODE (a);
rclass = ALLOCNO_COVER_CLASS (a);
index = ira_class_hard_reg_index[rclass][hard_regno];
ira_assert (index >= 0);
---> cost = (ALLOCNO_MEMORY_COST (a)
---> - (ALLOCNO_HARD_REG_COSTS (a) == NULL
---> ? ALLOCNO_COVER_CLASS_COST (a)
---> : ALLOCNO_HARD_REG_COSTS (a)[index]));
for (subloop_node = loop_node->subloops;
subloop_node != NULL;
subloop_node = subloop_node->subloop_next)
{
ira_assert (subloop_node->bb == NULL);
subloop_allocno = subloop_node->regno_allocno_map[regno];
if (subloop_allocno == NULL)
continue;
/* We have accumulated cost. To get the real cost of
allocno usage in the loop we should subtract costs of
the subloop allocnos. */
---> cost -= (ALLOCNO_MEMORY_COST (subloop_allocno)
--->- (ALLOCNO_HARD_REG_COSTS (subloop_allocno) == NULL
---> ? ALLOCNO_COVER_CLASS_COST (subloop_allocno)
---> : ALLOCNO_HARD_REG_COSTS (subloop_allocno)[index]));
...
As I understand it, the code marked "--->" is trying to calculate the
cost to A _in isolation_ of spilling to memory. Then the other (unmarked)
cost adjustments calculate the effect this has on the child allocnos.
If that's right, we're assuming here that ALLOCNO_MEMORY_COST,
ALLOCNO_COVER_CLASS_COST and ALLOCNO_HARD_REG_COST are still
accumulated. The comment above the second "--->" block seems to
bear out this intention.
The problem is that the costs aren't fully accumulated. After the
color_pass code quoted above, it is no longer true to say that:
ALLOCNO_HARD_REG_COSTS (a)[i] -
\Sigma ALLOCNO_HARD_REG_COSTS (subloop_allocno)[i])
is the cost of using I for A itself. Instead, each execution of:
cost = (ira_register_move_cost[mode][rclass][rclass]
* (exit_freq + enter_freq));
ALLOCNO_HARD_REG_COSTS (subloop_allocno)[index] -= cost;
will also subtract COST from the cost of spilling A (the parent allocno)
in move_spill_restore. Is this intentional?
No, it was not intentionally. We should fix it. As I understood this
implementation (inaccuracy in cost accumulation) hurts targets with slow
memory lik
Re: Does IRA support stack slot sharing for locals and spilled pseudos?
On Mon, Sep 29, 2008 at 2:04 PM, Pat Haugen <[EMAIL PROTECTED]> wrote: >> Does IRA support stack slot sharing described in the comment? > > We just got done walking through a failure with 200.sixtrack that looks > like the same thing. The two insns involved are: Looking into gcc.c-torture/execute/pr28982b.c's failure (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37447), I noticed that the struct there is big too and looks like the same issue. This testcase does fail on the trunk with --with-tune=cell. Thanks, Andrew Pinski
Re: plugins vs. licensing
Joe Buck wrote: On Mon, Sep 29, 2008 at 02:54:26PM +0100, Joern Rennecke wrote: Couldn't the plugin interface require a copyrighted passphrase to be sent by the plugin when it registeres, and the passphrase can then be licensed under the GPL. Please, let's stop this. Actually the above is a technical question, and the answer is yes, it would be possible to have the plugin interface require a copyrighted passphrase from a purely technical point of view, but this is GPL'ed code, so presymabvly this could be removed.
Re: GRAPHITE Prerequisites Documentation, System Issues
On Sat, 13 Sep 2008 23:05:27 -0500 "Aaron W. LaFramboise" <[EMAIL PROTECTED]> wrote: > I'm happy to see that GRAPHITE it is in trunk now! > > I don't see any documentation of prerequisites in install.texi yet; > perhaps we should add this so users can figure out what they need to > do to get this framework to work. > > In fact, 'grep -i graphite gcc/doc/*' doesn't match anything, so I > guess documentation is still in progress? > > Also, are there any system-specific issues that need to be worked on > (eg on Windows), or should GRAPHITE and its support libraries pretty > much work on all host platforms? Any word on this? Also will the libraries needed for graphite be available from gnu mirrors? -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
java announce mailing list
The java-announce mailing list hasn't had a single message (according to the archive on gcc.gnu.org) since 2001. Is there something wrong with the archive, or is the list dead?
Re: java announce mailing list
On Mon, Sep 29, 2008 at 10:30 PM, NightStrike <[EMAIL PROTECTED]> wrote: > The java-announce mailing list hasn't had a single message (according > to the archive on gcc.gnu.org) since 2001. Is there something wrong > with the archive, or is the list dead? We are very humble folk. Much has happened, but we don't like to make a big spectacle of it. I would recommend following [EMAIL PROTECTED] instead. David Daney
