Re: Anyone/anything still using CVS on gcc.gnu.org?
On Mon, Jul 21, 2008 at 6:09 AM, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote: > On Sun, 20 Jul 2008, Richard Guenther wrote: > >> > The mailing list webpage still refers to CVS: >> > http://gcc.gnu.org/lists.html >> > >> > Can we rename these lists (perhaps preserving an alias for the old names) >> > so that they reflect reality? >> >> I don't see a reason to rename the list. >> Richard. > > We don't use cvs, so "[EMAIL PROTECTED]" is misleading. Who cares? Richard.
http://gcc.gnu.org/projects/optimize.html Why is the biggest problem missing from this page.
Biggest problem is that gimple only works in source code to object. Not with a stack of objects to exe. This has major downsides for static building. To the point a lot of static builders end up sending all .c files into gcc at once so they get cross object optimised. One possible solution could be to cut gcc and gimple into to separate parts. So the build order of gcc binutils changes. To gimple binutils gcc. Reason binutils and gcc both using the same optimisation engine. LD then gets the means when building exe's to run all the gimple optimisations again looking for new dead code and new predictable code produced across objects. Binutils and Gcc both have to have optimisation engines. If binutils optimisation engine is poor it pulled gcc down with it. Some way of running equal quality optimisation on the linking stage has to be found. This problem need to be investigated. Reason this effects everything built with gcc and binutils. Peter Dolding
RE: http://gcc.gnu.org/projects/optimize.html Why is the biggest problem missing from this page.
Peter Dolding wrote on 21 July 2008 12:12: > Biggest problem is that gimple only works in source code to object. > Not with a stack of objects to exe. We're on the case. You're looking for the LTO project. http://gcc.gnu.org/wiki/LinkTimeOptimization cheers, DaveK -- Can't think of a witty .sigline today
Re: [RFH][tuples] Make Ada work
On 7/20/08 1:43 PM, Richard Guenther wrote:
--- 2318,2326
for (i = 0; i < gimple_num_ops (s); i++)
if (TREE_SIDE_EFFECTS (gimple_op (s, i)))
{
! /* FIXME tuples. This assign is over-eager at least
! for Ada.
! gcc_assert (gimple_has_volatile_ops (s)); */
I can't parse the comment. What do you mean by 'This assign is over-eager'?
Diego.
Re: [RFH][tuples] Make Ada work
On Mon, 21 Jul 2008, Diego Novillo wrote:
> On 7/20/08 1:43 PM, Richard Guenther wrote:
>
> > --- 2318,2326
> > for (i = 0; i < gimple_num_ops (s); i++)
> > if (TREE_SIDE_EFFECTS (gimple_op (s, i)))
> > {
> > ! /* FIXME tuples. This assign is over-eager at least
> > ! for Ada.
> > ! gcc_assert (gimple_has_volatile_ops (s)); */
>
> I can't parse the comment. What do you mean by 'This assign is over-eager'?
I fixed the real cause of the asserts triggering. See
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg01545.html
Richard.
Re: Anyone/anything still using CVS on gcc.gnu.org?
> Kaveh R GHAZI writes: Kaveh> On Sun, 20 Jul 2008, Richard Guenther wrote: >> > The mailing list webpage still refers to CVS: >> > http://gcc.gnu.org/lists.html >> > >> > Can we rename these lists (perhaps preserving an alias for the old names) >> > so that they reflect reality? >> >> I don't see a reason to rename the list. >> Richard. Kaveh> We don't use cvs, so "[EMAIL PROTECTED]" is misleading. So? That's life. There are plenty of historical artifacts in GCC development and on the website. I agree that there is no reason to rename these lists at this late date. David
Porting gcc 4.x on tangent A4
Hi all I have need to compile code for an old ARC tangent A4 core. 1) Gcc 3.x does support ARC Tangent-A4 2) Gcc 4.x dose support ARC Tangent-A4 if answer is 'not' for both question i will try to introduce code in arc.md and arc.c files to compile code for ARC Tangent-A4. Is this an hard task ? Thanks Ing Giuseppe 'Geppo' Monteleone
Scratch register in "jump" instruction ?
Hi, (I finally resumed the work on my microcontroller I posted about 3 months ago...) I have a problem with the jump instructions: my direct jumps are very limited in displacements, and I want to always generate indirect jumps instead. So I wrote this: (define_insn "jump" [(set (pc) (label_ref (match_operand 0 "" ""))) (clobber (match_scratch:QI 1 "=w"))] "" "ldih %1,hi(%l0)\n\tldil %1,lo(%l0)\n\tijmp (%1)" [(set_attr "cc" "none")] ) gcc and libgcc get compiled ok, but several testsuite tests fail because gcc is eating all the virtual memory when compiling the file. One of those is for example gcc.c-torture/compile/2120-2.c . The problem is coming from the usage of 'match_scratch' here, because removing it makes the problem go away. Before going deeper and trying to see if I'm hitting a bug in gcc, can someone please advice whether my define_insn is correct ? I'm using gcc-4.3.1. A stack trace from gdb seems to show that gcc is looping around here: #0 0x080f70df in df_insn_rescan (insn=0x80951c08) at /wip/src/gcc-4.3.1/gcc/df-scan.c:1078 #1 0x0811b5ad in add_insn_after (insn=0x80951c08, after=0x80951be0, bb=0xb7c17924) at /wip/src/gcc-4.3.1/gcc/emit-rtl.c:3495 #2 0x0811b870 in emit_jump_insn_after_noloc (x=0x80950c58, after=0x80951be0) at /wip/src/gcc-4.3.1/gcc/emit-rtl.c:4085 #3 0x080da84c in try_redirect_by_replacing_jump (e=0xb7c26460, target=0xb7c179d8, in_cfglayout=0 '\0') at /wip/src/gcc-4.3.1/gcc/cfgrtl.c:822 #4 0x08360a08 in cleanup_cfg (mode=1) [...] Thanks, -- Stelian Pop <[EMAIL PROTECTED]>
ICE in flow.c - Gcc 4.1.2 private port
Hello all,
For the target that i am porting if support for partial argument
passing is enabled i get the following error:
error: Attempt to delete prologue/epilogue insn:
internal compiler error: in propagate_one_insn, at flow.c:1699
This is 16bit target with 4 argument registers. FRAME_POINTER_REQUIRED
is defined to 0.
The code that is being complied is :
f(float a[],int b[],int c,float d)
{
}
>>
>From *.c.00.expand
;; Start of basic block 0, registers live: (nil)
(note 15 2 6 0 [bb 0] NOTE_INSN_BASIC_BLOCK)
(insn 6 15 7 0 (set (reg/v/f:HI 24 [ a ])
(reg:HI 0 R0 [ a ])) -1 (nil)
(nil))
(insn 7 6 8 0 (set (reg/v/f:HI 25 [ b ])
(reg:HI 1 R1 [ b ])) -1 (nil)
(nil))
(insn 8 7 9 0 (set (reg/v:HI 26 [ c ])
(reg:HI 2 R2 [ c ])) -1 (nil)
(nil))
(insn 9 8 12 0 (set (mem/c/i:HI (reg/f:HI 18 virtual-incoming-args) [0
d+0 S2 A16])
(reg:HI 3 R3)) -1 (nil)
(nil))
(insn 12 9 10 0 (clobber (reg/v:SF 27 [ d ])) -1 (nil)
(nil))
(insn 10 12 11 0 (set (subreg:HI (reg/v:SF 27 [ d ]) 0)
(mem/c/i:HI (reg/f:HI 18 virtual-incoming-args) [0 d+0 S2
A16])) -1 (nil)
(nil))
(insn 11 10 13 0 (set (subreg:HI (reg/v:SF 27 [ d ]) 2)
(mem/c/i:HI (plus:HI (reg/f:HI 18 virtual-incoming-args)
(const_int 2 [0x2])) [0 d+2 S2 A16])) -1 (nil)
(nil))
(note 13 11 14 0 NOTE_INSN_FUNCTION_BEG)
>
from *.c.37.lreg
(note 2 0 15 NOTE_INSN_DELETED)
;; Start of basic block 0, registers live: 3 [R3] 12 [R12]
(note 15 2 9 0 [bb 0] NOTE_INSN_BASIC_BLOCK)
(insn 9 15 13 0 (set (mem/c/i:HI (reg/f:HI 12 R12) [0 d+0 S2 A16])
(reg:HI 3 R3)) 1 {movhi_internal} (nil)
(nil))
(note 13 9 17 0 NOTE_INSN_FUNCTION_BEG)
>
from *.c.40.flow2
(note 15 2 31 0 [bb 0] NOTE_INSN_BASIC_BLOCK)
(insn/f 31 15 32 0 (set (reg/f:HI 12 R12)
(minus:HI (reg/f:HI 12 R12)
(const_int 2 [0x2]))) -1 (nil)
(nil))
(insn/f 32 31 33 0 (set (mem:HI (reg/f:HI 12 R12) [0 S2 A16])
(reg:HI 3 R3)) -1 (nil)
(nil))
(note 33 32 9 0 NOTE_INSN_PROLOGUE_END)
(insn 9 33 13 0 (set (mem/c/i:HI (reg/f:HI 12 R12) [0 d+0 S2 A16])
(reg:HI 3 R3)) 1 {movhi_internal} (nil)
(nil))
(note 13 9 17 0 NOTE_INSN_FUNCTION_BEG)
>
When argument is passed partially then
'current_function_pretend_args_size' is initialized and prologue will
set stack space accordingly. Based on the live information
'propagate_one_insn()' is trying to delete the insn from the
prologue. My question is is gcc suppose to delete insn 9, even before
prologue generation ?
If its not the case where am i going wrong?
Regards,
Shafi
RE: Anyone/anything still using CVS on gcc.gnu.org?
David Edelsohn wrote on 21 July 2008 13:33: >> Kaveh R GHAZI writes: > > Kaveh> On Sun, 20 Jul 2008, Richard Guenther wrote: The mailing list webpage still refers to CVS: http://gcc.gnu.org/lists.html Can we rename these lists (perhaps preserving an alias for the old names) so that they reflect reality? >>> >>> I don't see a reason to rename the list. >>> Richard. > > Kaveh> We don't use cvs, so "[EMAIL PROTECTED]" is misleading. > > So? That's life. There are plenty of historical artifacts in GCC > development and on the website. > > I agree that there is no reason to rename these lists at this late > date. > > David Hear, hear. The name of the list is an arbitrary label, not instructions on what kind of client to use to access the repository; why, just for the sake of making it "correct" in some non-functional sense of the word should everyone in the world have to adjust their whitelists/forwards/spamfilters/webarchives/etc.? There should be a fairly clear benefit before asking all those people to do all that work. cheers, DaveK -- Can't think of a witty .sigline today
Re: Porting gcc 4.x on tangent A4
> I have need to compile code for an old ARC tangent A4 core. > 1) Gcc 3.x does support ARC Tangent-A4 > 2) Gcc 4.x dose support ARC Tangent-A4 Both contain a port which in principle targets the ARCtangent-A4. I don't know if it actually works, it might be subject to bitrot. We at ARC have a more up-to-date that we want to contribute once the Copyright assignemt is on file. However, our focus is on the more modern cores ARC600 and ARC700; we don't test the ARCtangent-A4 support and intend to remove it at some point, so again that functionality might be bitrotted. Your best bet is probably to get the toolchain that has been provided by Codito (they have renamed itself in the meantime to Celunite and then Azingo, but the website for this toolchain is still named after codito) You can find it at http://www.codito.com/arc/download.html .
Re: [WWW] Updating GCC Links and Selected Readings
On Sun, 20 Jul 2008, Arnaud Charlet wrote: > Yes, the suggested changes are good. Thanks for the review, Arnaud, and thanks again for the patch, Santiago! I committed this with minor formatting changes and fixed some markup issues directly afterwards. Gerald
Re: Anyone/anything still using CVS on gcc.gnu.org?
From: "Dave Korn" <[EMAIL PROTECTED]> Hear, hear. The name of the list is an arbitrary label, not instructions on what kind of client to use to access the repository; why, just for the sake of making it "correct" in some non-functional sense of the word should everyone in the world have to adjust their whitelists/forwards/spamfilters/webarchives/etc.? There should be a fairly clear benefit before asking all those people to do all that work. Jeez, I didn't realize people felt so viscerally against this. I thought the impact on users would be small. I.e. I'm curious who actually subscribes to the gcc-cvs list. Is it a large list? (I don't know.) I don't think humans post to it either, it only gets machine generated messages from checkins. So it's not like address books would have to be updated. (Personally I only access it from the website if I'm looking for something specific). But seems like you think I'm wrong on how difficult this change would be for users. Okay, no big deal. A comment on the webpage I mentioned could be another way to address my point about the name being misleading...
Re: Anyone/anything still using CVS on gcc.gnu.org?
On Mon, Jul 21, 2008 at 11:50:43AM -0700, Kaveh R. Ghazi wrote: > Jeez, I didn't realize people felt so viscerally against this. I thought > the impact on users would be small. I.e. I'm curious who actually > subscribes to the gcc-cvs list. Is it a large list? (I don't know.) Just come up with a backronym or something, the same way we painlessly renamed gcc (from GNU C Compiler to GNU Compiler Collection).
Re: Anyone/anything still using CVS on gcc.gnu.org?
"Kaveh R. Ghazi" <[EMAIL PROTECTED]> writes: > Jeez, I didn't realize people felt so viscerally against this. I thought > the impact on users would be small. I.e. I'm curious who actually > subscribes to the gcc-cvs list. Is it a large list? (I don't know.) There are 105 subscribers to the gcc-cvs mailing list. A few of the subscribers appear to be mailing lists themselves. Let's just call it the gcc "Commits to Versioned Sources" list. Ian
RE: Anyone/anything still using CVS on gcc.gnu.org?
Kaveh R. Ghazi wrote on 21 July 2008 19:51: > From: "Dave Korn" <[EMAIL PROTECTED]> >> Hear, hear. The name of the list is an arbitrary label, not >> instructions on what kind of client to use to access the repository; >> why, just for the sake of making it "correct" in some non-functional >> sense of the word should everyone in the world have to adjust their >> whitelists/forwards/spamfilters/webarchives/etc.? >> >> There should be a fairly clear benefit before asking all those people to >> do all that work. > > > Jeez, I didn't realize people felt so viscerally against this. "Visceral" is too strong a word for how I feel about it; sorry if I was a bit hyperbolic there! > I don't think humans post to it either, it only gets machine generated > messages from checkins. So it's not like address books would have to be > updated. (Personally I only access it from the website if I'm looking for > something specific). But seems like you think I'm wrong on how difficult > this change would be for users. I'm thinking mostly of the independent external ML archives like MARC, nabble, archives.free.net, archivum.info, gmane they'd all have to adjust their setups and/or break indexing across the name change. "Viscerally against" is too strong, but it seemed to me that the costs, although not huge, could outweigh the benefits, which seemed very very minor. > Okay, no big deal. A comment on the webpage I mentioned could be another > way to address my point about the name being misleading... It's pretty obvious the moment you read the content of any of the posts that it can't be cvs and has to be svn, even more so if you follow one of the viewvc links... but it couldn't hurt to make it explicit, I'm sure. cheers, DaveK -- Can't think of a witty .sigline today
Re: How to determine if a decl is a class member in GCC
Hi,
I haven't heard anything back on my questions. Can any of C++ frontend
maintainers please shed some light (or comment on my proposed patch)?
Thanks a lot.
Le-chun
On Fri, Jul 18, 2008 at 10:22 AM, Le-Chun Wu <[EMAIL PROTECTED]> wrote:
> Hi,
>
> In my attribute handlers that handle the new thread-safety attributes
> (in c-common.c), I need to check if a decl is a class member. How do
> people do that? My original code was checking if a decl is a
> FIELD_DECL but that doesn't work for static members. I also tried to
> use DECL_CONTEXT but it is not set (in the C++ front-end) for data
> members. (I was able to use DECL_CONTEXT for member functions,
> though.) Is there any other way that I should use?
>
> BTW, as an experiment, I went ahead and made the following change in
> C++ front-end to set the DECL_CONTEXT of class data members. The patch
> appears to work and doesn't seem to break any g++ and gcc regression
> tests. (I will be running gdb testsuite later.) I think there must be
> a reason why the DECL_CONTEXT of data members wasn't set in the
> front-end, but it's not clear to my why. Can someone kindly explain
> why that is and whether the patch is OK?
>
> Thanks,
>
> Le-chun
>
>
> Index: cp/decl.c
> ===
> --- cp/decl.c (revision 137849)
> +++ cp/decl.c (working copy)
> @@ -9074,6 +9074,11 @@ grokdeclarator (const cp_declarator *dec
>
> if (thread_p)
> DECL_TLS_MODEL (decl) = decl_default_tls_model (decl);
> +
> +/* Since a static class data member is a VAR_DECL (instead of
> + a FIELD_DECL), setting the decl_context here allows us to
> + tell if it is a class member. */
> +DECL_CONTEXT (decl) = ctype ? ctype : current_class_type;
> }
> else
> {
>
real machine
- Moving pairs Given something like a checkers board, moving pairs would be checkers paired together and arranged on the board Given something like a checkers board, moving pairs are checker pieces said to be paired. The pairs don't have to be next to eachother. Any way arranged is fair for how this works, but it matters for how they work. There's no such thing as an empty space. They are the idea of how they move, and the problem with finding how to move them. - Moving a pair Find the pair to be what doesn't have any way to move. Each of the pair is to move together at the same time. A pair can only move to another pair. A pair moves to another pair, and each of the pair becomes paired with each of the other pair. So now both pairs are new pairs, with a pair that moved to a pair not being a pair anymore, but both a pair with the pair that moved to another pair. A pair moves to another pair, but the other pair is what moves away at the same time. A pair moves to another pair, the pair it moves to has to move at the same time to another pair, and left to move as a pair but became the new pair with the pair that goes where it's leaving from. You can't know what any pair's first move is until you know it's last move. There's nowhere to think in the way moving pairs can move how it has any inbetween to stop moving. It's always that a pair moving is making another pair move, and is having a pair move it. For any pair there's always one way to move it. To think of pairs in the middle of moving is to think of needing to know the end and beginning at the same time. When a pair moves it's what is moving away from what had to move it, and is moving what needs to move at the same time for whre it's going. Each time a pair is moved, all the pairs involved in moving are alternated as new pairs. You can't know how a pair moves, it's to figure out as the problem they have. The last pair to move has to be discovered before the first pair to move has a place to move. The answer to how to make a pair move is to find how to move the pair, that goes to another pair and becomes a new pair, and carries on until a pair goes back where the first pair left. That's to even know the first place a pair can move. All the pairs have a way to move, but may involve more or less of the other pairs to move at the same time. - Moving pairs are a machine They can be arranged in any way so that the movement of a few pairs makes for the movement of a few other in any way. Pairs can store how to associate any letter with any number by having it so some pairs say a letter and other pairs say a number, so how you move some pairs to say which letter is for some other pairs to move to say which number. Any pair that is moved can make it so other pairs to move have another answer to how they move. Pairs that work in moving together can be close or far apart, so they extend across the idea of how it's a machine as much as can make sense for any way to have a machine work. - Machine diagram See each pair for how it can be moved with the other pairs that move together. Draw pairs that move together with a line, or say one piece moves to another piece. Say for each group of pairs that move together. - The trick See the machine diagram? Make a pair move then see the machine diagram again. How did the machine move? Enjoy :)
