Re: gcc-in-cxx branch created

[Gabriel Dos Reis]

First, many thanks to Ian for stepping forward to make this happen.

On Thu, Jun 19, 2008 at 1:55 AM, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
> On Thu, 19 Jun 2008, Kaveh R. GHAZI wrote:
>
>> [...] I believe some work could be done (maybe even on mainline) to
>> activate -Wc++-compat during bootstrap as a warning only, (not an
>> error).  E.g.:
>>
>>   #pragma GCC diagnostic warning "-Wc++-compat"
>>
>> This would help clean up some of the easy stuff and make the branch diffs
>> much smaller.
>
> Some stats, I ran a quick make including the above #pragma in system.h, I
> get 1089 new warnings.  Running this grep pipe on the output file:
>
>grep 'request for implicit conversion' output|sed 
> 's%[^/]*\.[chl]:.*%%'|sort |uniq -c
>
> yields:
>
>  6
>754 ../../egcc-SVN20080619/gcc/
>231 ../../egcc-SVN20080619/gcc/fortran/
> 72 ../../egcc-SVN20080619/gcc/java/
> 26 ../../egcc-SVN20080619/gcc/objc/
>
> The blank 6 are from insn-automata.c, which has no path prefix and gets
> nulled out by my shellism.  There are no warnings from the C++ dir because
> someone already cleaned it up and added -Wc++-compat, likewise for
> libiberty.  (Who did that, Gaby?)

Yes, I already did the work for cp/.
I also got help from a GCC contributor (whose name I temporariy
forgot) and Thomas
on some C files.

Main offenders (last time I checked) seem be to
  (1) middle end and back end files who play `enum inheritance' tricks.
  (2) use of C++ keywords as variable names.
  (3) implicit conversion from void* to T* -- but we should have ver
few of those
  now, because I did eliminate those I was aware of
  (4) minor: some differences in `const' semantics.

-Wc++-compat needs to be augmented to check for C++ keywords
(a deficiency in current implementation).

I'm `on the road' and my laptop is a `windows only' box.

>
> These are mechanical and can be fixed with simple casts.  Again, IMHO
> these non-controversial patches should go straight into mainline.
> Once done we can -Werror this warning and avoid regressions.

Strongly agree.  Would you mind submitting the patch for activation of
-Wc++-compat?

There was also a suggestion to specificy a version for C++.  I believe
C++98 should
be enough for our purposes -- GCC-3.4.x should be good enough.

-- Gaby

Re: gcc-in-cxx branch created

[Kaveh R. GHAZI]

On Thu, 19 Jun 2008, Gabriel Dos Reis wrote:

> Main offenders (last time I checked) seem be to
>   (1) middle end and back end files who play `enum inheritance' tricks.
>   (2) use of C++ keywords as variable names.
>   (3) implicit conversion from void* to T* -- but we should have ver
> few of those
>   now, because I did eliminate those I was aware of

Um, no.  I see 1089 warnings of type #3. :-/


>   (4) minor: some differences in `const' semantics.
>
> -Wc++-compat needs to be augmented to check for C++ keywords
> (a deficiency in current implementation).

Yes, PR21759.  Will you be able to work on that?  (Or at least, list in
the PR what the reserved keywords are in case someone else wants to?)


>
> I'm `on the road' and my laptop is a `windows only' box.
>
> >
> > These are mechanical and can be fixed with simple casts.  Again, IMHO
> > these non-controversial patches should go straight into mainline.
> > Once done we can -Werror this warning and avoid regressions.
>
> Strongly agree.  Would you mind submitting the patch for activation of
> -Wc++-compat?

Done.

--Kaveh
--
Kaveh R. Ghazi  [EMAIL PROTECTED]

Re: C++ warnings vs. errors

[Jonathan Wakely]

2008/6/18 Mark Mitchell:
> Jonathan Wakely wrote:
>
>> Could a C++ maintainer please review this patch to turn most pedwarns
>> into permerrors.
>
> This patch is OK, with minor nits below.  Thanks for working on this!

Thanks Mark, I'll submit a revised patch this evening.

Jonathan

Re: gcc-in-cxx branch created

[Gabriel Dos Reis]

On Thu, Jun 19, 2008 at 3:10 AM, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
> On Thu, 19 Jun 2008, Gabriel Dos Reis wrote:
>
>> Main offenders (last time I checked) seem be to
>>   (1) middle end and back end files who play `enum inheritance' tricks.
>>   (2) use of C++ keywords as variable names.
>>   (3) implicit conversion from void* to T* -- but we should have ver
>> few of those
>>   now, because I did eliminate those I was aware of
>
> Um, no.  I see 1089 warnings of type #3. :-/

gasp :-(

>
>
>>   (4) minor: some differences in `const' semantics.
>>
>> -Wc++-compat needs to be augmented to check for C++ keywords
>> (a deficiency in current implementation).
>
> Yes, PR21759.  Will you be able to work on that?  (Or at least, list in
> the PR what the reserved keywords are in case someone else wants to?)

Yes, I'll work on it.

>> I'm `on the road' and my laptop is a `windows only' box.
>>
>> >
>> > These are mechanical and can be fixed with simple casts.  Again, IMHO
>> > these non-controversial patches should go straight into mainline.
>> > Once done we can -Werror this warning and avoid regressions.
>>
>> Strongly agree.  Would you mind submitting the patch for activation of
>> -Wc++-compat?
>
> Done.

Many thanks.

-- Gaby

Can register rename pass rename a callee-saved register?

[Mohamed Shafi]

Hello everyone,

I am involved in gcc port in which i found the following problem.

Before register renaming pass, callee registers was being used in the
body of the code. Hence function prologue saved the register and
epilogue restored the register. But register renaming pass removed
this particular callee saved register.The output and code generation
is proper, but there is an unnecessary save and restore of a callee
saved register in the prologue and epilogue even though the reference
of the callee saved register has been removed by the renaming pass.
I am using the prologue/epilogue patterns instead of the target macros.

So is the rename pass allowed to rename a callee saved register? Where
might this going wrong?

Thanks for you help.

Regards,
Shafi

Re: gcc-in-cxx branch created

[Gabriel Dos Reis]

On Wed, Jun 18, 2008 at 1:01 AM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> As I promised at the summit today, I have created the branch
> gcc-in-cxx (I originally said gcc-in-c++, but I decided that it was
> better to avoid possible meta-characters).  The goal of this branch is
> to develop a version of gcc which is compiled with C++.  Here are my
> presentation slides in PDF format: http://airs.com/ian/cxx-slides.pdf .

Excellent slides.  Many thanks for doing this.

>
> I have not yet committed any patches to the branch--at present it is
> just a copy of the trunk.  I will start committing patches soon, and
> anybody else may submit patches as well.  The branch will follow the
> usual gcc maintainership rules, except that any non-algorithmic
> maintainer may additionally approve or commit patches which permit
> compilation with C++.

I have a question:  I suspect that in concreteness you would prefer declarations
in GCC headers have a C++ linkage, as opposed to C linkage -- except where
for interoperability  with common runtime systems, we want the
declarations to have
C linkage (e.g. in libgcc for example).  Am I correct?
The reason I'm asking is that a fresh build o gcc-in-cxx dies on my machine with
complains that `program' has conflicting declarations: once in
libcpp.h as having
C++ linkage, once in toplev.h with a C declaration.  It is the
tradition in modern
C++ to avoid having many `sources' for the same declaration.

-- Gaby

Re: gcc-in-cxx branch created

[Ian Lance Taylor]

"Kaveh R. GHAZI" <[EMAIL PROTECTED]> writes:

> I read through your slides and I'm interested in contributing.  I didn't
> see the presentation itself so I don't know if this suggestion is
> redundant.  However I believe some work could be done (maybe even on
> mainline) to activate -Wc++-compat during bootstrap as a warning only,
> (not an error).  E.g.:
>
>   #pragma GCC diagnostic warning "-Wc++-compat"
>
> This would help clean up some of the easy stuff and make the branch diffs
> much smaller.
>
> We could also extend -Wc++-compat to warn about more things, using C++
> reserved keywords like "class" in C comes to mind.

Yes, I agree that both steps would be quite useful.  There is already
some support in the gcc configure system and Makefile to do this;
search for CXX_COMPAT_WARN in gcc/Makefile.in.  Adding
$(CXX_COMPAT_WARN) to $(GCC_WARN_CFLAGS) will make -Wc++-compat be
used when the build compiler supports it.

> Some stats, I ran a quick make including the above #pragma in system.h, I
> get 1089 new warnings.

Yes.  I am testing a mainline patch to clean up the tree codes now
(now that we've gone to 16 bits for tree codes, there is no need to
force each frontend to use a separate set of codes).

> These are mechanical and can be fixed with simple casts.  Again, IMHO
> these non-controversial patches should go straight into mainline.
> Once done we can -Werror this warning and avoid regressions.

Yes, I agree.

Ian

Re: gcc-in-cxx branch created

[Ian Lance Taylor]

[ Dropping gcc-patches. ]

"Gabriel Dos Reis" <[EMAIL PROTECTED]> writes:

>> I have not yet committed any patches to the branch--at present it is
>> just a copy of the trunk.  I will start committing patches soon, and
>> anybody else may submit patches as well.  The branch will follow the
>> usual gcc maintainership rules, except that any non-algorithmic
>> maintainer may additionally approve or commit patches which permit
>> compilation with C++.
>
> I have a question:  I suspect that in concreteness you would prefer 
> declarations
> in GCC headers have a C++ linkage, as opposed to C linkage -- except where
> for interoperability  with common runtime systems, we want the
> declarations to have
> C linkage (e.g. in libgcc for example).  Am I correct?

Yes, I think that makes the most sense.

> The reason I'm asking is that a fresh build o gcc-in-cxx dies on my machine 
> with
> complains that `program' has conflicting declarations: once in
> libcpp.h as having
> C++ linkage, once in toplev.h with a C declaration.  It is the
> tradition in modern
> C++ to avoid having many `sources' for the same declaration.

Yes.  I'm working around that for now by editing toplev.h, to avoid
pushing libcpp and libiberty to C++ right away.

#ifdef __cplusplus
extern "C" {
#endif

/* This is used by cpplib and libiberty.  */
extern const char *progname;

#ifdef __cplusplus
}
#endif


I'll try to get my current set of patches committed to the branch
later today.

Ian

Re: gcc-in-cxx branch created

[Gabriel Dos Reis]

On Thu, Jun 19, 2008 at 7:24 AM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:

>> The reason I'm asking is that a fresh build o gcc-in-cxx dies on my machine 
>> with
>> complains that `program' has conflicting declarations: once in
>> libcpp.h as having
>> C++ linkage, once in toplev.h with a C declaration.  It is the
>> tradition in modern
>> C++ to avoid having many `sources' for the same declaration.
>
> Yes.  I'm working around that for now by editing toplev.h, to avoid
> pushing libcpp and libiberty to C++ right away.
>
> #ifdef __cplusplus
> extern "C" {
> #endif
>
> /* This is used by cpplib and libiberty.  */
> extern const char *progname;
>
> #ifdef __cplusplus
> }
> #endif

Yes that makes sense.

>
>
> I'll try to get my current set of patches committed to the branch
> later today.

I'll wait until your patches are in.
Thanks!

-- Gaby

Re: Can register rename pass rename a callee-saved register?

[Ian Lance Taylor]

"Mohamed Shafi" <[EMAIL PROTECTED]> writes:

> Before register renaming pass, callee registers was being used in the
> body of the code. Hence function prologue saved the register and
> epilogue restored the register. But register renaming pass removed
> this particular callee saved register.The output and code generation
> is proper, but there is an unnecessary save and restore of a callee
> saved register in the prologue and epilogue even though the reference
> of the callee saved register has been removed by the renaming pass.
> I am using the prologue/epilogue patterns instead of the target macros.

Which version of gcc?  I was under the impression that this
longstanding buglet was cleaned up by the dataflow work.

> So is the rename pass allowed to rename a callee saved register? Where
> might this going wrong?

If this is the buglet I'm thinking of, the resulting code does work,
despite being suboptimal.  It just does an unnecessary save and
restore.

Ian

Re: gcc-in-cxx branch created

[Joseph S. Myers]

On Thu, 19 Jun 2008, Ian Lance Taylor wrote:

> Yes.  I'm working around that for now by editing toplev.h, to avoid
> pushing libcpp and libiberty to C++ right away.

I'm not convinced there's much value in building libiberty as C++ for GCC, 
given that it needs to remain buildable as C for now for the other 
projects using it and those projects may be built along with GCC in a 
combined tree (so sharing a single build of libiberty for the host).  
Much the same applies to libdecnumber, shared with GDB (and externally 
maintained).  (I can however see the potential use of a library of C++ 
infrastructure shared between any C++ host tools in GCC and src, but think 
that would best be kept separate from libiberty.  Much of libiberty could 
probably do with being replaced by, or merged into, gnulib anyway.)

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: Can register rename pass rename a callee-saved register?

[Mohamed Shafi]

2008/6/19 Ian Lance Taylor <[EMAIL PROTECTED]>:
> "Mohamed Shafi" <[EMAIL PROTECTED]> writes:
>
>> Before register renaming pass, callee registers was being used in the
>> body of the code. Hence function prologue saved the register and
>> epilogue restored the register. But register renaming pass removed
>> this particular callee saved register.The output and code generation
>> is proper, but there is an unnecessary save and restore of a callee
>> saved register in the prologue and epilogue even though the reference
>> of the callee saved register has been removed by the renaming pass.
>> I am using the prologue/epilogue patterns instead of the target macros.
>
> Which version of gcc?  I was under the impression that this
> longstanding buglet was cleaned up by the dataflow work.
>

   I am doing a port in gcc 4.1.2. The register is actually replaced
by register copy-propagation optimization pass.
   Here is the rtl dumps before .rnreg (the relevant portions)


(insn/f 42 41 43 0 (set (mem:HI (reg/f:HI 12 R12) [0 S2 A16])
(reg:HI 4 R4)) -1 (nil)
(expr_list:REG_DEAD (reg:HI 4 R4)
(nil)))

(note 43 42 9 0 NOTE_INSN_PROLOGUE_END)

(note 9 43 14 0 NOTE_INSN_FUNCTION_BEG)

(insn 14 9 37 0 (set (reg:HI 4 R4 [orig:26+2 ] [26])
(reg:HI 0 R0 [ pExtern ])) 1 {*movhi_internal}
(insn_list:REG_DEP_ANTI 16 (nil))
(expr_list:REG_DEAD (reg:HI 0 R0 [ pExtern ])
(expr_list:REG_NO_CONFLICT (reg/v:SI 0 R0 [orig:23 pExtern ] [23])
(nil

(insn 37 14 18 0 (set (reg:HI 8 R8)
(const_int 42 [0x2a])) 1 {*movhi_internal} (nil)
(nil))

(insn 18 37 38 0 (set (unspec:HI [
(reg:HI 8 R8)
] 2)
(unspec_volatile:HI [
(reg:HI 4 R4 [orig:26+2 ] [26])
] 6)) 6 {out} (insn_list:REG_DEP_TRUE 17
(insn_list:REG_DEP_ANTI 14 (insn_list:REG_DEP_TRUE 7
(insn_list:REG_DEP_TRUE 6 (nil)
(expr_list:REG_DEAD (reg:HI 8 R8)
(expr_list:REG_DEAD (reg:HI 4 R4 [orig:26+2 ] [26])
(nil


And this is the after the optimization pass


insn 18: replaced reg 4 with 0

.
(insn/f 42 41 43 0 (set (mem:HI (reg/f:HI 12 R12) [0 S2 A16])
(reg:HI 4 R4)) 1 {*movhi_internal} (nil)
(expr_list:REG_DEAD (reg:HI 4 R4)
(nil)))

(note 43 42 9 0 NOTE_INSN_PROLOGUE_END)

(note 9 43 37 0 NOTE_INSN_FUNCTION_BEG)

(insn 37 9 18 0 (set (reg:HI 8 R8)
(const_int 42 [0x2a])) 1 {*movhi_internal} (nil)
(nil))

(insn 18 37 38 0 (set (unspec:HI [
(reg:HI 8 R8)
] 2)
(unspec_volatile:HI [
(reg:HI 0 R0 [orig:26+2 ] [26])
] 6)) 6 {out} (insn_list:REG_DEP_TRUE 17
(insn_list:REG_DEP_ANTI 14 (insn_list:REG_DEP_TRUE 7
(insn_list:REG_DEP_TRUE 6 (nil)
(expr_list:REG_DEAD (reg:HI 8 R8)
(expr_list:REG_DEAD (reg:HI 0 R0 [orig:26+2 ] [26])
(nil




>> So is the rename pass allowed to rename a callee saved register? Where
>> might this going wrong?
>
> If this is the buglet I'm thinking of, the resulting code does work,
> despite being suboptimal.  It just does an unnecessary save and
> restore.

  The resulting code is proper except for the unnecessary save and
> restore.
>
> Ian
>

reg "use" replacement vs match_dup operand ?

[Olivier Hainque]

Hello,

(Having a great time in Ottawa :)

move_invariant_reg has this code:

  /* Replace the uses we know to be dominated.  It saves work for copy
 propagation, and also it is necessary so that dependent invariants
 are computed right.  */
  if (inv->def)
{
  for (use = inv->def->uses; use; use = use->next)
{
  *use->pos = reg;
  df_insn_rescan (use->insn);
}
}

and we're observing a case where this updates only one of two
match_dup related ioperands. This is on i386-mingwin and the insn in
question is coming from this pattern:

   (define_insn "allocate_stack_worker_32"
 [(set (match_operand:SI 0 "register_operand" "+a")
   (unspec_volatile:SI [(match_dup 0)] UNSPECV_STACK_PROBE))
  (set (reg:SI SP_REG) (minus:SI (reg:SI SP_REG) (match_dup 0)))
  (clobber (reg:CC FLAGS_REG))]
 "!TARGET_64BIT && TARGET_STACK_PROBE"
 "call\t___chkstk"

I think the intent is to convey that __chkstk is using eax as
an argument and is clobbering it.

Is this a valid pattern ?


FWIW, we're observing the anomaly on the Ada testcase below, which
produces 

   .152r.loop2_done
   ...
   (insn 46 109 48 4 p.adb:10 (parallel [
   (set (reg:SI 90)
   (unspec_volatile:SI [
   (reg:SI 105)
   ] 1))
   ...

when compiled by mainline with -O1.

Later on, we're observing bogus code calling __chkstk without reloading
eax with the proer value at a loop branch point:

.004t.gimple
  ...
  D.1376 = __builtin_alloca (D.1363);
  ...

.s
...
movl-28(%ebp), %eax  # D.1363, tmp102
addl$30, %eax#, tmp102
shrl$4, %eax #, tmp103
sall$4, %eax #, tmp104
movl%eax, -32(%ebp)  # tmp104, <=== compute arg in 
eax
L5:  
movl%esi, %edi   # ivtmp.34, J8b.7
movl%esp, -16(%ebp)  # saved_stack.8, saved_stack.8
call___chkstk  < allocate
leal27(%esp), %eax   #, tmp91
movl%eax, %edx   # tmp91, A14b.4
andl$-16, %edx   #, A14b.4
testl   %ebx, %ebx   # l.0
jle L3   #,
movb$0, (%edx)   #,* A14b.4
cmpl$1, %ebx #, l.0
je  L3   #,
movl$1, %eax #, J15b.6
L4:
addl$1, %eax #, J15b.6
movb$0, -1(%edx,%eax)#,
cmpl%eax, %ebx   # J15b.6, l.0
jne L4   #,
L3:
leal-1(%edi), %eax   #, tmp94
imull   -28(%ebp), %eax  # D.1363, tmp95
addl-20(%ebp), %eax  # blob.2, tmp96  < clobber eax
movl-28(%ebp), %ecx  # D.1363,
movl%ecx, 8(%esp)#,
movl%edx, 4(%esp)# A14b.4,
movl%eax, (%esp) # tmp96,* saved_stack.8
call_memcpy  #
movl-16(%ebp), %esp  # saved_stack.8, saved_stack.8
cmpl-24(%ebp), %edi  # D.1366, J8b.7
je  L2   #,
addl$1, %esi #, ivtmp.34
jmp L5   #<=== branch back 
here
   eax clobbered

Should we remove java from the default bootstrap languages?

[Diego Novillo]

I posted this question to the SC panel at the GCC Summit today.  I 
wanted to consider the possibility of making java a non-default language.


Would the Java maintainers agree to this?

The rationale is mostly that Java takes a very long time to build, and 
it does not seem to be used widely enough (maybe I'm wrong the latter 
point).



Thanks.  Diego.

Re: Should we remove java from the default bootstrap languages?

[Andrew Haley]

Diego Novillo wrote:
> 
> I posted this question to the SC panel at the GCC Summit today.  I
> wanted to consider the possibility of making java a non-default language.
> 
> Would the Java maintainers agree to this?
> 
> The rationale is mostly that Java takes a very long time to build, and
> it does not seem to be used widely enough (maybe I'm wrong the latter
> point).

Heh.  How widely is enough?

If this were to happen it would break repeatedly.  It's used as part of
every Fedora and Debian system, even in the presence of OpenJDK, as OpenJDK
only runs on x86_)64 and 386 systems, although there's a (very slow) version
that runs on PPC.  gcj is essential for bootstrapping OpenJDK on new systems.
gcj is the only free java on some systems, particularly ARM and embedded MIPS.

I'm seriously considering porting the openJDK library to gcj.

I wonder if some compromise less than disabling it as a default everywhere
is possible.

Andrew.

GCC v 2.3.x

[DimitryASuplatov]

Hello,
could you give me a link or any tip on how to download gcc version 2.3.3
or any other late 1992 version of your compiler?
Thank you very much for your help and I very appreciate your work.
Sincerely yours, Dimitry.

Re: GCC v 2.3.x

[Luis Felipe Strano Moraes]

You can find 2.3.3 and others here :
http://gcc-uk.internet.bs/old-releases/gcc-2/

--lf


On Thu, Jun 19, 2008 at 11:25 AM, DimitryASuplatov <[EMAIL PROTECTED]> wrote:
> Hello,
> could you give me a link or any tip on how to download gcc version 2.3.3
> or any other late 1992 version of your compiler?
> Thank you very much for your help and I very appreciate your work.
> Sincerely yours, Dimitry.
>
>



-- 
"One may tolerate a world of demons for the sake of an angel." --
Jeanne-Antoinette Poisson

Re: Should we remove java from the default bootstrap languages?

[Tom Tromey]

> "Andrew" == Andrew Haley <[EMAIL PROTECTED]> writes:

Diego> I posted this question to the SC panel at the GCC Summit today.  I
Diego> wanted to consider the possibility of making java a non-default language.

Andrew> If this were to happen it would break repeatedly.

Yeah, our experience back when libgcj was not in the tree was not very
good.  It broke all the time.

But, I am actually ok with having it be disabled by default, provided
that regressions affect gcj are treated seriously: fixed in a timely
way by the person causing the regression, or, if not, letting gcj
maintainers start the patch-reversion clock.

If we make this change I'll set up an auto-tester on the compile farm
that builds gcj along with everything else.  I think this would
provide a pretty reasonable compromise.  Ideally we could find a PPC
box somewhere to do this as well -- anyone have some cycles to spare?

What do you think of this?

Another idea is to build jc1 but not libgcj.  That would prevent a
certain (more minor) class of breakage.

What is behind my thinking here is just the fact that gcj development
has dropped off quite a bit.

Tom

Re: gcc-in-cxx branch created

[Ian Lance Taylor]

"Joseph S. Myers" <[EMAIL PROTECTED]> writes:

> On Thu, 19 Jun 2008, Ian Lance Taylor wrote:
>
>> Yes.  I'm working around that for now by editing toplev.h, to avoid
>> pushing libcpp and libiberty to C++ right away.
>
> I'm not convinced there's much value in building libiberty as C++ for GCC, 
> given that it needs to remain buildable as C for now for the other 
> projects using it and those projects may be built along with GCC in a 
> combined tree (so sharing a single build of libiberty for the host).  

Good point.

Ian

Re: Can register rename pass rename a callee-saved register?

[Ian Lance Taylor]

"Mohamed Shafi" <[EMAIL PROTECTED]> writes:

>> Which version of gcc?  I was under the impression that this
>> longstanding buglet was cleaned up by the dataflow work.
>>
>
>I am doing a port in gcc 4.1.2. The register is actually replaced
> by register copy-propagation optimization pass.

I believe that in gcc 4.3 this unnecessary store and load should no
longer happen.

Ian

Re: Should we remove java from the default bootstrap languages?

[Andrew Haley]

Tom Tromey wrote:
>> "Andrew" == Andrew Haley <[EMAIL PROTECTED]> writes:
> 
> Diego> I posted this question to the SC panel at the GCC Summit today.  I
> Diego> wanted to consider the possibility of making java a non-default 
> language.
> 
> Andrew> If this were to happen it would break repeatedly.
> 
> Yeah, our experience back when libgcj was not in the tree was not very
> good.  It broke all the time.
> 
> But, I am actually ok with having it be disabled by default, provided
> that regressions affect gcj are treated seriously: fixed in a timely
> way by the person causing the regression, or, if not, letting gcj
> maintainers start the patch-reversion clock.
> 
> If we make this change I'll set up an auto-tester on the compile farm
> that builds gcj along with everything else.  I think this would
> provide a pretty reasonable compromise.  Ideally we could find a PPC
> box somewhere to do this as well -- anyone have some cycles to spare?
> 
> What do you think of this?
> 
> Another idea is to build jc1 but not libgcj.  That would prevent a
> certain (more minor) class of breakage.

My suggestion is that we build jc1 but not libgcj by default.
HOWEVER, we build libgcj on the autobuilders and make very sure that
if anyone breaks the libgcj build they have to fix their breakage,
even tho it's not part of the default build.  That will prevent most
of the bitrot while we figure out how to go forward.

Andrew.

Re: Should we remove java from the default bootstrap languages?

[Ian Lance Taylor]

Andrew Haley <[EMAIL PROTECTED]> writes:

[ Java ]

> I wonder if some compromise less than disabling it as a default everywhere
> is possible.

Is it possible to only build and test a subset of libjava by default,
and still get useful coverage of Java?  The issue I see is simply that
building libjava is half of the time required for a bootstrap.

Ian

-fstack-protector on mips target

[Andrew Anderson]

I have a suspected stack corruption problem on a mips-based embedded
system (using uclibc on a linux 2.4 kernel).  I have tried using the
-fstack-protector compile option but get the error message:

warning: -fstack-protector not supported for this target

My toolchain configuration is:
GCC version 4.1.2
binutils version 2.16.1
uclibc version 0.9.28


Does anyone know:
 - if mips support for the stack protector has been added in a later GCC 
version?
 - if there is a technical reason why it's not implemented for mips?
 - if there is a patch or workaround out there somewhere?

Re: Should we remove java from the default bootstrap languages?

[Tom Tromey]

> "Ian" == Ian Lance Taylor <[EMAIL PROTECTED]> writes:

Ian> Is it possible to only build and test a subset of libjava by default,
Ian> and still get useful coverage of Java?  The issue I see is simply that
Ian> building libjava is half of the time required for a bootstrap.

We could look into this.  The minimum subset is probably several
hundred classes.  For instance, Class refers to URL, which will
probably pull in most of java.net.

Maybe David Daney already knows what is minimal...?

Tom

Re: Should we remove java from the default bootstrap languages?

[Janis Johnson]

On Fri, 2008-06-20 at 10:41 -0600, Tom Tromey wrote:
> > "Andrew" == Andrew Haley <[EMAIL PROTECTED]> writes:
> 
> Diego> I posted this question to the SC panel at the GCC Summit today.  I
> Diego> wanted to consider the possibility of making java a non-default 
> language.
> 
> Andrew> If this were to happen it would break repeatedly.
> 
> Yeah, our experience back when libgcj was not in the tree was not very
> good.  It broke all the time.
> 
> But, I am actually ok with having it be disabled by default, provided
> that regressions affect gcj are treated seriously: fixed in a timely
> way by the person causing the regression, or, if not, letting gcj
> maintainers start the patch-reversion clock.
> 
> If we make this change I'll set up an auto-tester on the compile farm
> that builds gcj along with everything else.  I think this would
> provide a pretty reasonable compromise.  Ideally we could find a PPC
> box somewhere to do this as well -- anyone have some cycles to spare?

I'll continue to include java in my nightly builds on
powerpc64-unknown-linux-gnu, for which I test with both -m32 and -m64.
My test results for trunk are sent to gcc-testresults daily.  I also
do regular (not daily) builds for release branches as well as trunk,
but mailing to the outside world hasn't been working lately on the
machine where those builds are done; I'll get that fixed.

Janis

Re: Should we remove java from the default bootstrap languages?

[Andrew Haley]

Janis Johnson wrote:
> On Fri, 2008-06-20 at 10:41 -0600, Tom Tromey wrote:
>>> "Andrew" == Andrew Haley <[EMAIL PROTECTED]> writes:
>> Diego> I posted this question to the SC panel at the GCC Summit today.  I
>> Diego> wanted to consider the possibility of making java a non-default 
>> language.
>>
>> Andrew> If this were to happen it would break repeatedly.
>>
>> Yeah, our experience back when libgcj was not in the tree was not very
>> good.  It broke all the time.
>>
>> But, I am actually ok with having it be disabled by default, provided
>> that regressions affect gcj are treated seriously: fixed in a timely
>> way by the person causing the regression, or, if not, letting gcj
>> maintainers start the patch-reversion clock.
>>
>> If we make this change I'll set up an auto-tester on the compile farm
>> that builds gcj along with everything else.  I think this would
>> provide a pretty reasonable compromise.  Ideally we could find a PPC
>> box somewhere to do this as well -- anyone have some cycles to spare?
> 
> I'll continue to include java in my nightly builds on
> powerpc64-unknown-linux-gnu, for which I test with both -m32 and -m64.
> My test results for trunk are sent to gcc-testresults daily.  I also
> do regular (not daily) builds for release branches as well as trunk,
> but mailing to the outside world hasn't been working lately on the
> machine where those builds are done; I'll get that fixed.

That would be really helpful.

Andrew.

Re: Should we remove java from the default bootstrap languages?

[Tom Tromey]

Andrew> My suggestion is that we build jc1 but not libgcj by default.
Andrew> HOWEVER, we build libgcj on the autobuilders and make very sure that
Andrew> if anyone breaks the libgcj build they have to fix their breakage,
Andrew> even tho it's not part of the default build.  That will prevent most
Andrew> of the bitrot while we figure out how to go forward.

Good idea.

Maybe instead of removing libgcj from the default builds, we can just
say that maintainers can --disable-libjava for regression testing
purposes.  This would make testers continue to test libgcj by default.

Tom

[EMAIL PROTECTED]: v850-elf failure in gcc-make]

[DJ Delorie]

All my builds returned this error last night.  Is anyone else seeing this?

--- Start of forwarded message ---
Date: Thu, 19 Jun 2008 02:41:26 -0400
From: DJ Delorie <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: v850-elf failure in gcc-make

Failure step: v850-elf-gcc-make.log

  calls: void *.LTHUNK4()/525 (1.00 per call) 
void std::strstream::_ZThn8_NSt9strstreamD0Ev()/287(-1): availability:available 
18 insns needed tree finalized inlinable
  called by: 
  calls: void *.LTHUNK7()/528 (1.00 per call) 
void std::strstream::_ZThn8_NSt9strstreamD1Ev()/286(-1): availability:available 
18 insns needed tree finalized inlinable
  called by: 
  calls: void *.LTHUNK5()/526 (1.00 per call) 
/sata/dj/gnu/gcc/gcc/libstdc++-v3/src/strstream.cc:419: internal compiler 
error: nodes with no released memory found
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[4]: *** [strstream.lo] Error 1
make[4]: Leaving directory `/sata/dj/gnu/gcc/v850-elf/v850-elf/libstdc++-v3/src'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/sata/dj/gnu/gcc/v850-elf/v850-elf/libstdc++-v3'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/sata/dj/gnu/gcc/v850-elf/v850-elf/libstdc++-v3'
make[1]: *** [all-target-libstdc++-v3] Error 2
make[1]: Leaving directory `/sata/dj/gnu/gcc/v850-elf'
make: *** [all] Error 2


=done=
--- End of forwarded message ---

Re: gcc-in-cxx branch created

[Jens-Michael Hoffmann]

Am Mittwoch, 18. Juni 2008 08:01:35 schrieb Ian Lance Taylor:

> I have not yet committed any patches to the branch--at present it is
> just a copy of the trunk.  I will start committing patches soon, and
> anybody else may submit patches as well.  The branch will follow the
> usual gcc maintainership rules, except that any non-algorithmic
> maintainer may additionally approve or commit patches which permit
> compilation with C++.

Should the branch compile right now? I'm asking because I get the following
error when I try to bootstrap:

make[3]: Entering directory `/home/jm/src/gcc/gcc-in-cxx/build/gcc'
g++ -x 
c++ -c  -g -fkeep-inline-functions -g -fkeep-inline-functions -DIN_GCC   -W 
-Wall -Wwrite-strings -Wmissing-format-attribute -pedantic -Wno-long-long 
-Wno-variadic-macros 
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc 
-I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include  
-I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/bid 
-I../libdecnumber  ../../gcc/gcc/c-lang.c -o 
c-lang.o
In file included from ../../gcc/gcc/double-int.h:24,
 from ../../gcc/gcc/tree.h:30,
 from ../../gcc/gcc/c-lang.c:26:
/usr/include/gmp.h:520: Fehler: »std::FILE« wurde nicht deklariert


Best regards

Jens-Michael

question about cygwin C++ sockets

[Lisa Anthony]

I have an application I've been working on for a couple years now that 
uses this C++ socket library: http://www.alhem.net/Sockets/index.html.


I recently decided to try upgrading the sockets library I had to the 
latest one, and have been having conflict problems with building my app 
with the new library, which now depends on the winsock32 library.  I am 
unable to build my app now, because cygwin's implementation of the 
gethostname function conflicts with winsock's:


/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:635: 
error: declaration of C function `int gethostname(char*, int)' conflicts 
with /usr/include/sys/unistd.h:206: error: previous declaration `int 
gethostname(char*, size_t)' here


I found this message, and was wondering if the OP's suggestion has been 
addressed or included in later versions of cygwin gcc?  (I'm guessing no.)


http://gcc.gnu.org/ml/gcc/2006-05/msg00627.html

It was quite a while ago, but I'm having the same problem as the OP 
describes, with recent releases of cygwin and gcc (the version included 
in the current cygwin distro).


Compiling with the -mno-cygwin flag (recommended by the socket library 
author) gives me different errors (can't find pthread.h).


Any input would be appreciated,
Thanks,
*Lisa



--
*Lisa Anthony
PhD Candidate
http://www.cs.cmu.edu/~lanthony/
Human-Computer Interaction Institute
Carnegie Mellon University, Pittsburgh, PA

"The best way to predict the future is to invent it."
   Alan Kay

Re: gcc-in-cxx branch created

[Ian Lance Taylor]

Jens-Michael Hoffmann <[EMAIL PROTECTED]> writes:

> Am Mittwoch, 18. Juni 2008 08:01:35 schrieb Ian Lance Taylor:
>
>> I have not yet committed any patches to the branch--at present it is
>> just a copy of the trunk.  I will start committing patches soon, and
>> anybody else may submit patches as well.  The branch will follow the
>> usual gcc maintainership rules, except that any non-algorithmic
>> maintainer may additionally approve or commit patches which permit
>> compilation with C++.
>
> Should the branch compile right now?

No.  I've flipped the branch to start compiling the source files in
gcc with C++.  Unfortunately a number of issues will need to be
addressed before all the code will compile in C++.  Most of this work
can and will be contributed back to mainline gcc as well.

I'll send out a note when everything on the branch compiles in C++.

Ian

Re: Should we remove java from the default bootstrap languages?

[Andrew Haley]

Tom Tromey wrote:
>> "Ian" == Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> 
> Ian> Is it possible to only build and test a subset of libjava by default,
> Ian> and still get useful coverage of Java?  The issue I see is simply that
> Ian> building libjava is half of the time required for a bootstrap.
> 
> We could look into this.  The minimum subset is probably several
> hundred classes.  For instance, Class refers to URL, which will
> probably pull in most of java.net.
> 
> Maybe David Daney already knows what is minimal...?

Yeah.  Let's not disable java as default until we've at least
investigated this.

Andrew.

Re: gcc-in-cxx branch created

[Jens-Michael Hoffmann]

Am Donnerstag, 19. Juni 2008 18:20:43 schrieb Ian Lance Taylor:

> > Should the branch compile right now?
>
> No.  I've flipped the branch to start compiling the source files in
> gcc with C++.  Unfortunately a number of issues will need to be
> addressed before all the code will compile in C++.  Most of this work
> can and will be contributed back to mainline gcc as well.
>
> I'll send out a note when everything on the branch compiles in C++.

Is there a todo list? I would like to contribute to this branch, how can I 
help?

Jens-Michael

Re: Should we remove java from the default bootstrap languages?

[Diego Novillo]

On 6/19/08 11:06 AM, Janis Johnson wrote:


I'll continue to include java in my nightly builds on
powerpc64-unknown-linux-gnu, for which I test with both -m32 and -m64.


Likewise.  I will keep including java in my ppc64, i686 and x86_64 daily 
testers.  I'm only trying to address the every day experience for 
developers.


I also agree that java breakages should be treated the same way as any 
other bootstrap breaking patch.



Diego.

Re: Should we remove java from the default bootstrap languages?

[Andrew Haley]

Diego Novillo wrote:
> On 6/19/08 11:06 AM, Janis Johnson wrote:
> 
>> I'll continue to include java in my nightly builds on
>> powerpc64-unknown-linux-gnu, for which I test with both -m32 and -m64.
> 
> Likewise.  I will keep including java in my ppc64, i686 and x86_64 daily
> testers.  I'm only trying to address the every day experience for
> developers.
> 
> I also agree that java breakages should be treated the same way as any
> other bootstrap breaking patch.

Well, it won't be quite the same, since developers won't
be expected to know they've broken Java.  We need to make
sure this "you broke it, you fix it" policy is written in
stone somewhere.

Ok, we have a plan.

Andrew.

Re: gcc-in-cxx branch created

[Ian Lance Taylor]

Jens-Michael Hoffmann <[EMAIL PROTECTED]> writes:

>> No.  I've flipped the branch to start compiling the source files in
>> gcc with C++.  Unfortunately a number of issues will need to be
>> addressed before all the code will compile in C++.  Most of this work
>> can and will be contributed back to mainline gcc as well.
>>
>> I'll send out a note when everything on the branch compiles in C++.
>
> Is there a todo list? I would like to contribute to this branch, how can I 
> help?

Well, one approach would be to compile code on the branch.  Where it
fails, fix it so that it compiles.  Then, if appropriate, move the
patch back to mainline, test the patch there, and submit it for
mainline.

The other major TODO is to work out the details of using STL
containers with GC allocated objects.  This means teaching gengtype
how to generate code to traverse STL containers, which would then be
used during GC.  This is not a task for the faint-hearted.

Ian

Re: gcc-in-cxx branch created

[Kaveh R. GHAZI]

On Thu, 19 Jun 2008, Ian Lance Taylor wrote:

> > These are mechanical and can be fixed with simple casts.  Again, IMHO
> > these non-controversial patches should go straight into mainline.
> > Once done we can -Werror this warning and avoid regressions.
>
> Yes, I agree.
> Ian

Okay, the patch to activate -Wc++-compat is installed on mainline.  I'd
like to clean up some of the new warnings, but it sounds like you've got
some of this already done behind the scenes.  E.g.:
http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01264.html

I'd like to avoid stomping on each other and duplicating work.  Can you
tell me what you've already done and/or plan to do?

Also from a workflow perspective, if I fix the void*->T* warnings from
-Wc++-compat, I'd like to just put them on mainline first and let you
merge it to the branch rather than the reverse.  Mainline is blathering
lots of new warnings right now and I'd like to address those quickly.

Thanks,
--Kaveh
--
Kaveh R. Ghazi  [EMAIL PROTECTED]

PowerPC lwsync Instruction

[Joel Sherrill]

Hi,

I ran into something tracking down a test
failure on psim and now thing there is a
target specific issue that needs addressing.

libstdc++-v3/config/cpu/powerpc/atomic_word.h
uses the lwsync instruction if __NO_LWSYNC__
is not defined. 


psim does not implement the lwsync instruction.
I checked my 601, 603, and 403 manuals and did
not find this instruction in any of them.

I think the powerpc port is enabling this instruction
on variants that don't have it.  Which PowerPC
cores have this instruction?

It should be fairly straightforward to address since
it is just a matter of setting the __NO_LWSYNC__
macro correctly for each CPU variant.

Thanks.

--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED]On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
  Support Available (256) 722-9985

Re: gcc-in-cxx branch created

[Ian Lance Taylor]

"Kaveh R. GHAZI" <[EMAIL PROTECTED]> writes:

> Okay, the patch to activate -Wc++-compat is installed on mainline.  I'd
> like to clean up some of the new warnings, but it sounds like you've got
> some of this already done behind the scenes.  E.g.:
> http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01264.html
>
> I'd like to avoid stomping on each other and duplicating work.  Can you
> tell me what you've already done and/or plan to do?

I have a bunch of patches, but as far as getting them into mainline
I'm limited by the time it takes to run a bootstrap and test run (I'm
at the summit and am just working on my laptop).  Right now I am
testing the appended patch for mainline; that should clear up a lot of
enum warnings.  I recommend applying this patch to your working
directory, and look at the warnings that remain.

Other than that, everything I've done is minor stuff like the message
to which you refer.  I don't know how to avoid duplicating work at
that level.  If you want to pick a set of files to start with, that
works for me.

> Also from a workflow perspective, if I fix the void*->T* warnings from
> -Wc++-compat, I'd like to just put them on mainline first and let you
> merge it to the branch rather than the reverse.  Mainline is blathering
> lots of new warnings right now and I'd like to address those quickly.

Yes, agreed.

Ian

Index: gencheck.c
===
--- gencheck.c	(revision 136955)
+++ gencheck.c	(working copy)
@@ -26,12 +26,12 @@ along with GCC; see the file COPYING3.  
 #define DEFTREECODE(SYM, NAME, TYPE, LEN) #SYM,
 
 static const char *const tree_codes[] = {
-#include "tree.def"
-#include "c-common.def"
-#include "gencheck.h"
+#include "all-tree.def"
 (char*) 0
 };
 
+#undef DEFTREECODE
+
 static void usage (void);
 
 static void
Index: java/Make-lang.in
===
--- java/Make-lang.in	(revision 136955)
+++ java/Make-lang.in	(working copy)
@@ -242,7 +242,7 @@ java.stagefeedback: stageprofile-start
 
 #
 # .o:.h dependencies.
-JAVA_TREE_H = $(TREE_H) $(HASHTAB_H) java/java-tree.h java/java-tree.def
+JAVA_TREE_H = $(TREE_H) $(HASHTAB_H) java/java-tree.h
 
 java/jcf-dump.o: $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(JAVA_TREE_H) \
   java/jcf-dump.c java/jcf-reader.c java/jcf.h java/javaop.h java/javaop.def \
Index: java/lang.c
===
--- java/lang.c	(revision 136955)
+++ java/lang.c	(working copy)
@@ -69,43 +69,6 @@ static enum classify_record java_classif
 # define TARGET_OBJECT_SUFFIX ".o"
 #endif
 
-/* Table indexed by tree code giving a string containing a character
-   classifying the tree code.  Possibilities are
-   t, d, s, c, r, <, 1 and 2.  See java/java-tree.def for details.  */
-
-#define DEFTREECODE(SYM, NAME, TYPE, LENGTH) TYPE,
-
-const enum tree_code_class tree_code_type[] = {
-#include "tree.def"
-  tcc_exceptional,
-#include "java-tree.def"
-};
-#undef DEFTREECODE
-
-/* Table indexed by tree code giving number of expression
-   operands beyond the fixed part of the node structure.
-   Not used for types or decls.  */
-
-#define DEFTREECODE(SYM, NAME, TYPE, LENGTH) LENGTH,
-
-const unsigned char tree_code_length[] = {
-#include "tree.def"
-  0,
-#include "java-tree.def"
-};
-#undef DEFTREECODE
-
-/* Names of tree components.
-   Used for printing out the tree and error messages.  */
-#define DEFTREECODE(SYM, NAME, TYPE, LEN) NAME,
-
-const char *const tree_code_name[] = {
-#include "tree.def"
-  "@@dummy",
-#include "java-tree.def"
-};
-#undef DEFTREECODE
-
 /* Table of machine-independent attributes.  */
 const struct attribute_spec java_attribute_table[] =
 {
Index: java/java-tree.h
===
--- java/java-tree.h	(revision 136955)
+++ java/java-tree.h	(working copy)
@@ -30,15 +30,6 @@ The Free Software Foundation is independ
 
 #include "hashtab.h"
 
-/* Java language-specific tree codes.  */
-#define DEFTREECODE(SYM, NAME, TYPE, LENGTH) SYM,
-enum java_tree_code {
-  __DUMMY = LAST_AND_UNUSED_TREE_CODE,
-#include "java-tree.def"
-  LAST_JAVA_TREE_CODE
-};
-#undef DEFTREECODE
-
 struct JCF;
 
 /* Usage of TREE_LANG_FLAG_?:
Index: tree.c
===
--- tree.c	(revision 136955)
+++ tree.c	(working copy)
@@ -52,6 +52,38 @@ along with GCC; see the file COPYING3.  
 #include "pointer-set.h"
 #include "fixed-value.h"
 
+/* Tree code classes.  */
+
+#define DEFTREECODE(SYM, NAME, TYPE, LENGTH) TYPE,
+
+const enum tree_code_class tree_code_type[] = {
+#include "all-tree.def"
+};
+
+#undef DEFTREECODE
+
+/* Table indexed by tree code giving number of expression
+   operands beyond the fixed part of the node structure.
+   Not used for types or decls.  */
+
+#define DEFTREECODE(SYM, NAME, TYPE, LENGTH) LENGTH,
+
+const unsigned char tree_code_length[] = {
+#include "all-tree.def"
+};
+
+#und

Re: PowerPC lwsync Instruction

[Andrew Pinski]

On Thu, Jun 19, 2008 at 1:36 PM, Joel Sherrill
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> I ran into something tracking down a test
> failure on psim and now thing there is a
> target specific issue that needs addressing.

lwsync is sync with the bit 9 set.  So it should be ok as it was a
reserved field and was supposed to be ignored on the hardware which
did not implement those bits and have it as a sync (but I could be
wrong).

The Power ISA 2.05 describes the sync/lwsync behavior but I can't find
where it says it is ignored if not implemented.  I bet you have to
goto the ISA for those processors to find what is the current behavior
for sure.

Thanks,
Andrew Pinski

Re: gcc-in-cxx branch created

[Daniel Berlin]

On Thu, Jun 19, 2008 at 1:26 PM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> Jens-Michael Hoffmann <[EMAIL PROTECTED]> writes:
>
>>> No.  I've flipped the branch to start compiling the source files in
>>> gcc with C++.  Unfortunately a number of issues will need to be
>>> addressed before all the code will compile in C++.  Most of this work
>>> can and will be contributed back to mainline gcc as well.
>>>
>>> I'll send out a note when everything on the branch compiles in C++.
>>
>> Is there a todo list? I would like to contribute to this branch, how can I
>> help?
>
> Well, one approach would be to compile code on the branch.  Where it
> fails, fix it so that it compiles.  Then, if appropriate, move the
> patch back to mainline, test the patch there, and submit it for
> mainline.
>
> The other major TODO is to work out the details of using STL
> containers with GC allocated objects.  This means teaching gengtype
> how to generate code to traverse STL containers, which would then be
> used during GC.  This is not a task for the faint-hearted.
>

One way to avoid having gengtype generate the walks is to have a
container base class that implements walking using iterators.   Then
we can have gcc::vector instead of std::vector, etc.

Gengtype would then just have to use this interface when walking
container roots, instead of having to generate it's own walking
functions for containers.

Then again, it's not clear this is worth it, since at some point you
will probably want to have a base class for gc'd objects and have the
walking function be a member, instead of what gengtype does now, so
gengtype will have to learn some stuff anway.

mac os x 10.5.3

[Hal Wigoda]

i need to get the binaries for a c compiler for my mac.


where would i go?

Re: gcc-in-cxx branch created

[Paweł Sikora]

On Thursday 19 of June 2008 19:26:27 Ian Lance Taylor wrote:
> Jens-Michael Hoffmann <[EMAIL PROTECTED]> writes:
> >> No.  I've flipped the branch to start compiling the source files in
> >> gcc with C++.  Unfortunately a number of issues will need to be
> >> addressed before all the code will compile in C++.  Most of this work
> >> can and will be contributed back to mainline gcc as well.
> >>
> >> I'll send out a note when everything on the branch compiles in C++.
> >
> > Is there a todo list? I would like to contribute to this branch, how can
> > I help?
>
> Well, one approach would be to compile code on the branch.  Where it
> fails, fix it so that it compiles.  Then, if appropriate, move the
> patch back to mainline, test the patch there, and submit it for
> mainline.
>
> The other major TODO is to work out the details of using STL
> containers with GC allocated objects.

there's also a http://www.aei.mpg.de/~peekas/tree/ that may be useful
for modeling abstract trees used in compiler.

Re: GCC v 2.3.x

[Diego Novillo]

On 6/19/08 10:25 AM, DimitryASuplatov wrote:


could you give me a link or any tip on how to download gcc version 2.3.3
or any other late 1992 version of your compiler?


Try ftp://gcc.gnu.org/pub/gcc/old-releases/gcc-2/


Diego.

forcing non-cse'd symbols

[DJ Delorie]

The R8C has a 20-bit addressing mode for data outside its normal
addressing range.  However, gcc *really* wants to CSE these and put
their addresses in registers, which is not going to work (pointers are
16 bit, these addresses are 20 bit).  How can I force gcc to use [sym]
or [sym+reg] addressing, and not copy &sym to a register?

Alternately, can we fix the "gcc assumes all pointers are the same
size" assumption?  Specifically this code hurts m32c:

rtx
memory_address (enum machine_mode mode, rtx x)
{
  rtx oldx = x;

  x = convert_memory_address (Pmode, x);

  /* By passing constant addresses through registers
 we get a chance to cse them.  */
  if (! cse_not_expected && CONSTANT_P (x) && CONSTANT_ADDRESS_P (x))
x = force_reg (Pmode, x);


1. It discards the actual pointer mode and substitutes Pmode, whether
   it's valid or not, and

2. It forces the address into a register whether it's valid or not.

GCC and OpenMP

[Sophia Han]

Hi,

I am currently working on installing OpenMP(2.5v or 3.0v specification) 
on my linux machine (GCC 4.1.2 SuSE10.2).  It requires at least GCC 4.3 
version.  It seems 
that I need to upgrade to GCC4.3.1 or GCC 4.4 from my current version of 
GCC 4.1.2.  Which GCC version do you suggest in order to use OpenMP on my linux 
machine? 

Thanks,
Sophia.

Re: gcc-in-cxx branch created

[Ian Lance Taylor]

Paweł Sikora <[EMAIL PROTECTED]> writes:

> there's also a http://www.aei.mpg.de/~peekas/tree/ that may be useful
> for modeling abstract trees used in compiler.

Thanks.  I want to be clear that the initial goal of the gcc-in-cxx
branch will be to produce code which is quite close to mainline, but
compiles gcc with C++.  Changing the structure of tree to be a class
would be appropriate for a different branch, probably one based on
gcc-in-cxx.

Ian

Re: GCC and OpenMP

[Antoniu Pop]

Hi,

> I am currently working on installing OpenMP(2.5v or 3.0v specification)
> on my linux machine (GCC 4.1.2 SuSE10.2).  It requires at least GCC 4.3 
> version.  It seems
> that I need to upgrade to GCC4.3.1 or GCC 4.4 from my current version of
> GCC 4.1.2.  Which GCC version do you suggest in order to use OpenMP on my 
> linux machine?

For the time being OpenMP 2.5 is supported in GCC 4.3, so that's what
I'd recommend.
If you need OpenMP 3.0 features, you need to wait for GCC 4.4,
otherwise GCC 4.3.1 would be the best choice.

Best,
Antoniu

[Tuples] gimple_build_call_from_tree vs NeXT runtime Objective-C

[Andrew Pinski]

Hi,
  When looking into stret-1.m failure, I noticed that
gimple_build_call_from_tree calls get_callee_fndecl to get the "real"
function decl.  Well for OBJ_TYPE_REF in Objective-C, it will return
objc_msgSendSuper_stret/objc_msgSendSuper which is correct but after
on we crash as that function decl really does not match the function
type so we crash while expanding.  I don't know what the correct way
to fix this but I think it might be to ignore get_callee_fndecl if we
have an OBJ_TYPE_REF.  Does that seem reasonable?

Thanks,
Andrew Pinski

Re: gcc-in-cxx branch created

[Kaveh R. GHAZI]

On Thu, 19 Jun 2008, Ian Lance Taylor wrote:

> "Kaveh R. GHAZI" <[EMAIL PROTECTED]> writes:
>
> > I'd like to avoid stomping on each other and duplicating work.  Can you
> > tell me what you've already done and/or plan to do?
>
> I have a bunch of patches, but as far as getting them into mainline
> I'm limited by the time it takes to run a bootstrap and test run (I'm
> at the summit and am just working on my laptop).  Right now I am
> testing the appended patch for mainline; that should clear up a lot of
> enum warnings.  I recommend applying this patch to your working
> directory, and look at the warnings that remain.
>
> Other than that, everything I've done is minor stuff like the message
> to which you refer.  I don't know how to avoid duplicating work at
> that level.  If you want to pick a set of files to start with, that
> works for me.

Okay, looks like you have the enum problem under control.  I'm attacking
the void*->T* problem on mainline.  So far I've got most of the java
directory, the objc directory and a few top level files (gcc.c,
collect2.c, tlink.c) done and it's undergoing regtesting.  I'll install as
"obvious" on mainline since it's just casting and/or using the libiberty
C++ macros created explicitly for this purpose.

I'll do fortran next, then some top level files.  I'll post in this thread
which ones so we don't overlap.  Please do the same.

Thanks,
--Kaveh
--
Kaveh R. Ghazi  [EMAIL PROTECTED]

Re: PowerPC lwsync Instruction

[Joel Sherrill]

Andrew Pinski wrote:

On Thu, Jun 19, 2008 at 1:36 PM, Joel Sherrill
<[EMAIL PROTECTED]> wrote:
  

Hi,

I ran into something tracking down a test
failure on psim and now thing there is a
target specific issue that needs addressing.



lwsync is sync with the bit 9 set.  So it should be ok as it was a
reserved field and was supposed to be ignored on the hardware which
did not implement those bits and have it as a sync (but I could be
wrong).
  

I don't have access to a real 603e of this vintage but
my Sept 1995 603e User's Manual shows the sync
instruction has having:

0-5  - all 1's (value in table is 31)
6-20   - all 0's (dark grey indicating not implemented)
21-30 - 598
31   - 0

So bit 9 being 1 could be ignored or it could cause
a bad instruction fault.  psim makes it a fault.

The Power ISA 2.05 describes the sync/lwsync behavior but I can't find
where it says it is ignored if not implemented.  I bet you have to
goto the ISA for those processors to find what is the current behavior
for sure.

  

My 1994 copy of "PowerPC Microprocessor Architecture:
The Programming Environment" shows the bits that are
0 in the 603e manual as reserved.

I really don't know what to make of this now.  Should
gcc not generate lwsync for a 603e and psim is right
Or should psim be fixed to allow bit 9 to be set?

And if psim should be fixed, can you explain how to change
this?  I have never been able to grok this format and this
seems like the simplest possible change. :D


0.31,6./,11./,16./,21.598,31./:X::sync:Synchronize
*601: PPC_UNIT_IU,PPC_UNIT_IU,1,  1,  0
*603: PPC_UNIT_SRU,   PPC_UNIT_SRU,   1,  1,  0
*603e:PPC_UNIT_SRU,   PPC_UNIT_SRU,   1,  1,  0
*604: PPC_UNIT_LSU,   PPC_UNIT_LSU,   1,  1,  0
   /* do nothing */

What do you have to do to that first line to say the value
of bit 9 doesn't matter?  And where is this explained
in the code? :-D

I can scan the pages and email them to you if you like.


Thanks,
Andrew Pinski
  



--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED]On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
  Support Available (256) 722-9985

Re: mac os x 10.5.3

[Sean Callanan]

Hal,

http://developer.apple.com/tools/download/

Sean

On Jun 19, 2008, at 2:13 PM, Hal Wigoda wrote:


i need to get the binaries for a c compiler for my mac.


where would i go?

Re: PowerPC lwsync Instruction

[Joe Buck]

On Thu, Jun 19, 2008 at 03:50:34PM -0500, Joel Sherrill wrote:

> >On Thu, Jun 19, 2008 at 1:36 PM, Joel Sherrill
> ><[EMAIL PROTECTED]> wrote:
> >  
> >>Hi,
> >>
> >>I ran into something tracking down a test
> >>failure on psim and now thing there is a
> >>target specific issue that needs addressing.
> >>
> >
Andrew Pinski wrote:
> >lwsync is sync with the bit 9 set.  So it should be ok as it was a
> >reserved field and was supposed to be ignored on the hardware which
> >did not implement those bits and have it as a sync (but I could be
> >wrong).

Based on

http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01238.html

it appears that it is not ignored, but rather traps, on at least some
hardware.  As a rule (thanks to some bad experiences with the Motorola
68000) processor architects tend to make sure that reserved bits and
unused bits generate a trap, otherwise the software developers start using
those bits for some other purpose and constrain future processor
development.

> I really don't know what to make of this now.  Should
> gcc not generate lwsync for a 603e and psim is right
> Or should psim be fixed to allow bit 9 to be set?

If psim's going to support both older and newer processors,
simulated, it appears it has to depend on the specific processor
being simulated (so psim should make both behaviors possible).

Re: PowerPC lwsync Instruction

[Joel Sherrill]

Joe Buck wrote:

On Thu, Jun 19, 2008 at 03:50:34PM -0500, Joel Sherrill wrote:

  

On Thu, Jun 19, 2008 at 1:36 PM, Joel Sherrill
<[EMAIL PROTECTED]> wrote:

  

Hi,

I ran into something tracking down a test
failure on psim and now thing there is a
target specific issue that needs addressing.



Andrew Pinski wrote:
  

lwsync is sync with the bit 9 set.  So it should be ok as it was a
reserved field and was supposed to be ignored on the hardware which
did not implement those bits and have it as a sync (but I could be
wrong).
  


Based on

http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01238.html

it appears that it is not ignored, but rather traps, on at least some
hardware.  As a rule (thanks to some bad experiences with the Motorola
68000) processor architects tend to make sure that reserved bits and
unused bits generate a trap, otherwise the software developers start using
those bits for some other purpose and constrain future processor
development.
  

I agree completely and my 13 year old 603e manual shows
bit 9 as reserved and 0.  So using your argument,
gcc should not generate an lwsync for 603e.

Is the set of CPU models gcc can generate an lwsync for
to generous?


I really don't know what to make of this now.  Should
gcc not generate lwsync for a 603e and psim is right
Or should psim be fixed to allow bit 9 to be set?



If psim's going to support both older and newer processors,
simulated, it appears it has to depend on the specific processor
being simulated (so psim should make both behaviors possible).
  

Yep.  But I don't see anything too new in the
set of 601, 603, 603e and 604. :-D

--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED]On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
  Support Available (256) 722-9985

[Tuples] Creating a GIMPLE_MODIFY_STMT unnecessary for gimplify_omp_for

[Andrew Pinski]

Hi,
  When I was comparing the tuples branch to the trunk, I noticed that
inside gimplify_omp_for, we call build_gimple_modify_stmt and then
fall through to GIMPLE_MODIFY_STMT but really we don't need it.  I
have not tested removing it but I thought I would send out what I
found while reviewing gimplify.c.

Thanks,
Andrew Pinski

Re: C++ warnings vs. errors

[Jonathan Wakely]

2008/6/18 Mark Mitchell:
>> * I don't think the pedwarn in joust() in cp/call.c should be a
>> permerror, is this a GNU extension?
>>  if (warn)
>>{
>>  pedwarn ("\
>> ISO C++ says that these are ambiguous, even \
>> though the worst conversion for the first is better than \
>> the worst conversion for the second:");
>>  print_z_candidate (_("candidate 1:"), w);
>>  print_z_candidate (_("candidate 2:"), l);
>>}
>
> Yes, that is a historical GNU extension.  I think this should just be a
> warning, given that the whole section of code is guarded with !pedantic.

OK. Should I also get rid of the escaped newlines and rely on string
concatenation for the text?

Jon




>> * I don't know if these in cp/typeck.c should be permerrors, DTRT
>> implies not, but should tf_error be changed to tf_warning?
>
> I think "DTRT" here means "do what whoever wrote this code thinks the
> standard should say" not "do what the standard says".  Please make these
> permerrors.
>
> Thanks,
>
> --
> Mark Mitchell
> CodeSourcery
> [EMAIL PROTECTED]
> (650) 331-3385 x713
>
>

Re: C++ warnings vs. errors

[Mark Mitchell]

Jonathan Wakely wrote:

2008/6/18 Mark Mitchell:

* I don't think the pedwarn in joust() in cp/call.c should be a
permerror, is this a GNU extension?
 if (warn)
   {
 pedwarn ("\
ISO C++ says that these are ambiguous, even \
though the worst conversion for the first is better than \
the worst conversion for the second:");
 print_z_candidate (_("candidate 1:"), w);
 print_z_candidate (_("candidate 2:"), l);
   }

Yes, that is a historical GNU extension.  I think this should just be a
warning, given that the whole section of code is guarded with !pedantic.


OK. Should I also get rid of the escaped newlines and rely on string
concatenation for the text?


It's fine if you want to do that, but I don't think it's important 
either way.


Thanks,

--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

gcc-4.3-20080619 is now available

[gccadmin]

Snapshot gcc-4.3-20080619 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20080619/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch 
revision 136970

You'll find:

gcc-4.3-20080619.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.3-20080619.tar.bz2 C front end and core compiler

gcc-ada-4.3-20080619.tar.bz2  Ada front end and runtime

gcc-fortran-4.3-20080619.tar.bz2  Fortran front end and runtime

gcc-g++-4.3-20080619.tar.bz2  C++ front end and runtime

gcc-java-4.3-20080619.tar.bz2 Java front end and runtime

gcc-objc-4.3-20080619.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.3-20080619.tar.bz2The GCC testsuite

Diffs from 4.3-20080612 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.3
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: GCC and OpenMP

[Sophia Han]

Hi,

It seems that GCC 4.3.1 does not like the SuSE 10. 2v.  It failed when I
install GCC 4.3.1 on my linux machine.  Should I upgrade to SuSE 11v in
order to use GCC 4.3.1 or what do you suggest?

Thanks,
Sophia.

Antoniu Pop wrote:
> Hi,
>
>   
>> I am currently working on installing OpenMP(2.5v or 3.0v specification)
>> on my linux machine (GCC 4.1.2 SuSE10.2).  It requires at least GCC 4.3 
>> version.  It seems
>> that I need to upgrade to GCC4.3.1 or GCC 4.4 from my current version of
>> GCC 4.1.2.  Which GCC version do you suggest in order to use OpenMP on my 
>> linux machine?
>> 
>
> For the time being OpenMP 2.5 is supported in GCC 4.3, so that's what
> I'd recommend.
> If you need OpenMP 3.0 features, you need to wait for GCC 4.4,
> otherwise GCC 4.3.1 would be the best choice.
>
> Best,
> Antoniu
>   

Re: C++ warnings vs. errors

[Jonathan Wakely]

Thanks for the review, here's another patch ...

2008/6/18 Mark Mitchell:
>
>> * Should it really be a hard error for a class to declare itself as a
>> friend? I don't think it's expressly forbidden
>> e.g. class A { friend class A; };
>> I changed this to a permerror, restoring the old  behaviour.
>
> I think this should just be a warning.  I can't find anything in the WP that
> says this is invalid.  (That's why I try to cite the WP when making changes
> -- so that we can go back and check later!)  Please change it to a warning.

Done, plain old warning now.
Declaring a member function a friend of its own class is still a
permerror, which is consistent with comeau.

>> * I don't think the pedwarn in joust() in cp/call.c should be a
>> permerror, is this a GNU extension?
>>  if (warn)
>>{
>>  pedwarn ("\
>> ISO C++ says that these are ambiguous, even \
>> though the worst conversion for the first is better than \
>> the worst conversion for the second:");
>>  print_z_candidate (_("candidate 1:"), w);
>>  print_z_candidate (_("candidate 2:"), l);
>>}
>
> Yes, that is a historical GNU extension.  I think this should just be a
> warning, given that the whole section of code is guarded with !pedantic.

Done, plain old warning.

>> * I don't know if these in cp/typeck.c should be permerrors, DTRT
>> implies not, but should tf_error be changed to tf_warning?
>
> I think "DTRT" here means "do what whoever wrote this code thinks the
> standard should say" not "do what the standard says".  Please make these
> permerrors.

Done.

tested linux/x86-64

Shall I commit this?

Jon


ChangeLog
Description: Binary data


permerrors-2.patch
Description: Binary data

Re: GCC and OpenMP

[Sean Callanan]

Sophia,

As a general rule, it's best to try building the source and installing  
it; that will get you the most repeatable results and the most  
informative help from mailing lists.


If you're getting errors during the source build, please send the text  
of the error and a description of what you did to the "[EMAIL PROTECTED] 
" mailing list.  As a general rule, your Linux distribution version  
should not matter for this.


Sincerely,
Sean Callanan

On Jun 19, 2008, at 7:40 PM, Sophia Han wrote:


Hi,

It seems that GCC 4.3.1 does not like the SuSE 10. 2v.  It failed  
when I
install GCC 4.3.1 on my linux machine.  Should I upgrade to SuSE 11v  
in

order to use GCC 4.3.1 or what do you suggest?

Thanks,
Sophia.

Antoniu Pop wrote:

Hi,


I am currently working on installing OpenMP(2.5v or 3.0v  
specification)
on my linux machine (GCC 4.1.2 SuSE10.2).  It requires at least  
GCC 4.3 version.  It seems
that I need to upgrade to GCC4.3.1 or GCC 4.4 from my current  
version of
GCC 4.1.2.  Which GCC version do you suggest in order to use  
OpenMP on my linux machine?




For the time being OpenMP 2.5 is supported in GCC 4.3, so that's what
I'd recommend.
If you need OpenMP 3.0 features, you need to wait for GCC 4.4,
otherwise GCC 4.3.1 would be the best choice.

Best,
Antoniu

Re: gcc-in-cxx branch created

[Aaron Gray]

Hi,

Just in case you are interested in it I have a 4.2.1 compiling and built 
using C++.


I have not really worked on it for quite a while now.

   http://www.gccpp.org

Download at :-

   http://www.gccpp.org/download/

Aaron

Re: GCC and OpenMP

[Tim Prince]

Sophia Han wrote:

Hi,

It seems that GCC 4.3.1 does not like the SuSE 10. 2v.  It failed when I
install GCC 4.3.1 on my linux machine.  Should I upgrade to SuSE 11v in
order to use GCC 4.3.1 or what do you suggest?

Thanks,
Sophia.

Antoniu Pop wrote:

Hi,

  

I am currently working on installing OpenMP(2.5v or 3.0v specification)
on my linux machine (GCC 4.1.2 SuSE10.2).  It requires at least GCC 4.3 
version.  It seems
that I need to upgrade to GCC4.3.1 or GCC 4.4 from my current version of
GCC 4.1.2.  Which GCC version do you suggest in order to use OpenMP on my linux 
machine?


For the time being OpenMP 2.5 is supported in GCC 4.3, so that's what
I'd recommend.
If you need OpenMP 3.0 features, you need to wait for GCC 4.4,
otherwise GCC 4.3.1 would be the best choice.
My OpenSUSE 10.3 installed gcc 4.2.1 with OpenMP, when I ran Online 
Update.  If you want a newer gcc with an older SUSE, most likely your 
course is to build from source, or install an updated binutils and gcc 
binary from someone who has built it.

Re: Should we remove java from the default bootstrap languages?

[Florian Weimer]

* Tom Tromey:

> We could look into this.  The minimum subset is probably several
> hundred classes.  For instance, Class refers to URL, which will
> probably pull in most of java.net.

Can't you fallback to the interpreter for the URL class?

Re: Can register rename pass rename a callee-saved register?

[Mohamed Shafi]

2008/6/19 Ian Lance Taylor <[EMAIL PROTECTED]>:
> "Mohamed Shafi" <[EMAIL PROTECTED]> writes:
>
>>> Which version of gcc?  I was under the impression that this
>>> longstanding buglet was cleaned up by the dataflow work.
>>>
>>
>>I am doing a port in gcc 4.1.2. The register is actually replaced
>> by register copy-propagation optimization pass.
>
> I believe that in gcc 4.3 this unnecessary store and load should no
> longer happen.
>
   Can you tell me what was done in gcc 4.3 so that i can back port
the changes to gcc 4.1.2

Regards,
Shafi

Re: Can register rename pass rename a callee-saved register?

[Andrew Pinski]

On Thu, Jun 19, 2008 at 11:56 PM, Mohamed Shafi <[EMAIL PROTECTED]> wrote:
>   Can you tell me what was done in gcc 4.3 so that i can back port
> the changes to gcc 4.1.2

It was a rewrite of life information of flow.c really.  It is very
hard to backport (trust me I have tried already).

Thanks,
Andrew Pinski

Re: Can register rename pass rename a callee-saved register?

[Mohamed Shafi]

2008/6/20 Andrew Pinski <[EMAIL PROTECTED]>:
> On Thu, Jun 19, 2008 at 11:56 PM, Mohamed Shafi <[EMAIL PROTECTED]> wrote:
>>   Can you tell me what was done in gcc 4.3 so that i can back port
>> the changes to gcc 4.1.2
>
> It was a rewrite of life information of flow.c really.  It is very
> hard to backport (trust me I have tried already).
>
   So i should do something in the machine reorg pass to catch cases like these.
   I guess that is the only hack that is possible. Is there any other way?

  Was there a bug report filed for this case?

  Regards,
  Shafi

Re: gcc-in-cxx branch created

[Kaveh R. GHAZI]

On Thu, 19 Jun 2008, Kaveh R. GHAZI wrote:

> I'll do fortran next, then some top level files.  I'll post in this thread
> which ones so we don't overlap.  Please do the same.

Okay, I'm starting on the top level files.  I'll go backwards through the
alphabet.  Doing [t-z]* right now, that's probably all I'll get to today.

--Kaveh
--
Kaveh R. Ghazi  [EMAIL PROTECTED]

Re: Should we remove java from the default bootstrap languages?

[Tom Tromey]

> "Florian" == Florian Weimer <[EMAIL PROTECTED]> writes:

>> We could look into this.  The minimum subset is probably several
>> hundred classes.  For instance, Class refers to URL, which will
>> probably pull in most of java.net.

Florian> Can't you fallback to the interpreter for the URL class?

We prefer to build most of the core without -findirect-dispatch,
because it yields better performance.  This means that all the direct
dependencies must be compiled and linked in.

Of course we could try to change this.  But, then we'd need a special
mode for this kind of build (I think) and we wouldn't really be
testing things the same way that users build them.

Tom