Bootstrap failure caused by jvmti additions

[Volker Reichelt]

Hi Tom,

your patch http://gcc.gnu.org/ml/java-patches/2006-q3/msg00264.html
broke bootstrap (at least on x86_64-unknown-linux-gnu):

ranlib .libs/libgij.a
creating libgij.la
./.libs/libgcj.so: undefined reference to `JvNumMethods(java::lang::Class*)'
./.libs/libgcj.so: undefined reference to `JvGetFirstMethod(java::lang::Class*)'
collect2: ld returned 1 exit status
make[5]: *** [jv-convert] Error 1

Regards,
Volker

Re: reload getting the mode of (subreg:HI (reg:QI pseudo)) wrong

[Bernd Schmidt]

Rask Ingemann Lambertsen wrote:

The constraints are not met because the constraint "d" is register class
DX_REGS consisting of register 4 and 5, and (reg:HI 5 dh) spans register 5
and 6. Also, HARD_REGNO_NREGS (5, HImode) returns 0.

The lreg and greg dumps provide the clue that reload got the mode wrong:

(insn:HI 2485 2483 2486 39 libgcc2.c:1825 (set (subreg:HI (reg:QI 178) 0)
(ashiftrt:HI (reg:HI 641)
(const_int 15 [0xf]))) 31 {*ashrhi3_const15}
(insn_list:REG_DEP_TRUE 2480 (nil))
(expr_list:REG_DEAD (reg:HI 641)
(nil)))


Probably the compiler doesn't in general like a paradoxical subreg that 
can take more hard regs than its SUBREG_REG.  I think this is probably 
something that can be worked around with a proper combination of 
MODES_TIEABLE_P, CANNOT_CHANGE_MODE_CLASS, and maybe 
REG_CANNOT_CHANGE_MODE_P.  What are your definitions of those macros?



Bernd

Re: reload getting the mode of (subreg:HI (reg:QI pseudo)) wrong

[Rask Ingemann Lambertsen]

On Fri, Aug 04, 2006 at 02:30:34AM +0200, Rask Ingemann Lambertsen wrote:

> The constraints are not met because the constraint "d" is register class
> DX_REGS consisting of register 4 and 5, and (reg:HI 5 dh) spans register 5
> and 6. Also, HARD_REGNO_NREGS (5, HImode) returns 0.

I meant to say that HARD_REGNO_MODE_OK (5, HImode) returns 0.

-- 
Rask Ingemann Lambertsen

Re: reload getting the mode of (subreg:HI (reg:QI pseudo)) wrong

[Rask Ingemann Lambertsen]

On Fri, Aug 04, 2006 at 11:21:05AM +0200, Bernd Schmidt wrote:
> 
> Probably the compiler doesn't in general like a paradoxical subreg that 
> can take more hard regs than its SUBREG_REG.  I think this is probably 
> something that can be worked around with a proper combination of 
> MODES_TIEABLE_P, CANNOT_CHANGE_MODE_CLASS, and maybe 
> REG_CANNOT_CHANGE_MODE_P.  What are your definitions of those macros?

#define MODES_TIEABLE_P(MODE1, MODE2) \
(GET_MODE_SIZE(MODE1) > 1 && GET_MODE_SIZE(MODE2) > 1)

There are registers for which HARD_REGNO_MODE_OK (regno, QImode) returns
false but HARD_REGNO_MODE_OK (regno, HImode) (or larger) returns true.

#define CANNOT_CHANGE_MODE_CLASS(FROM, TO, CLASS) \
((FROM == QImode || (TO) == QImode) \
 && reg_classes_intersect_p (HI_REGS, (CLASS)))

HI_REGS is a class containing registers which can't hold QImode values. They
are 16-bit only (%si, %di, %bp and %sp). Is there an undocumented assumption
here that if CANNOT_CHANGE_MODE_CLASS() returns true, then the number of hard
regs used is unchanged?
 
I haven't heard of REG_CANNOT_CHANGE_MODE_P before, and it isn't mentioned
in the documentation.

-- 
Rask Ingemann Lambertsen

libgcc-math specification

[Sashan Govender]

Hi

Is there a specification that describes a set of routines for
libgcc-math? I read through previous emails on this topic and it seems
that it has been removed from head. I'd like to contribute but not
sure what direction to go in. Is there a specific branch that needs
checking out?

Re: reload getting the mode of (subreg:HI (reg:QI pseudo)) wrong

[Rask Ingemann Lambertsen]

On Thu, Aug 03, 2006 at 11:55:49PM -0700, Ian Lance Taylor wrote:
> 
> In general, operand_mode[] will be unreliable in cases where it is not
> specified.  This is frowned upon but more or less permitted, and a few
> backends take advantage of it for relatively nefarious purposes.

I only have modeless operands in "call_value" and "setmemhi" and I don't
know how that can be avoided. But presumably, GET_MODE_BITSIZE (VOIDmode)
returns something sensible like 0, so it shouldn't be a problem.
 
> Still, I can't think of a better approach for this problem.  It's
> worth a try to set rld[i].mode to operand_mode[] when operand_mode[]
> is larger.  I don't see that you will have to worry about matching
> constraints.  A big-endian system might be an issue; hopefully
> reload_adjust_reg_for_mode is called whereever necessary.

I tried this patch to find_reloads(), and it did solve the problem.

Index: gcc/reload.c
===
--- gcc/reload.c(revision 115810)
+++ gcc/reload.c(working copy)
@@ -4416,6 +4428,12 @@
   > GET_MODE_SIZE (rld[i].inmode)))
  ? rld[i].outmode : rld[i].inmode;
 
+  /* Don't be fooled by e.g. paradoxical subreg operands.
+We need a register which is at least as wide as the operand.  */
+  if (GET_MODE_BITSIZE (rld[i].mode)
+ < GET_MODE_BITSIZE (operand_mode[rld[i].opnum]))
+   rld[i].mode = operand_mode[i];
+
   rld[i].nregs = CLASS_MAX_NREGS (rld[i].class, rld[i].mode);
 }

Before reload:

(insn:HI 2485 2483 2486 39 ../../../cvssrc/gcc/gcc/libgcc2.c:1825 (set 
(subreg:HI (reg:QI 178) 0)
(ashiftrt:HI (reg:HI 641)
(const_int 15 [0xf]))) 31 {*ashrhi3_const15} 
(insn_list:REG_DEP_TRUE 2480 (nil))
(expr_list:REG_DEAD (reg:HI 641)
(nil)))

After reload:

Reloads for insn # 2485
Reload 0: reload_out (QI) = (reg:QI 178)
DX_REGS, RELOAD_FOR_OUTPUT (opnum = 0)
reload_out_reg: (reg:QI 178)
reload_reg_rtx: (reg:HI 4 d)

(insn:HI 2485 2483 2604 39 ../../../cvssrc/gcc/gcc/libgcc2.c:1825 (set (reg:HI 
4 d)
(ashiftrt:HI (reg:HI 2 a [641])
(const_int 15 [0xf]))) 31 {*ashrhi3_const15} 
(insn_list:REG_DEP_TRUE 2480 (nil))
(nil))

(insn 2604 2485 2486 39 ../../../cvssrc/gcc/gcc/libgcc2.c:1825 (set (mem/c:QI 
(plus:HI (reg/f:HI 10 bp)
(const_int -42 [0xffd6])) [10 S1 A8])
(reg:QI 4 d)) 34 {movqi} (nil)
(nil))

This is close to what it looked like before combine (in the life1 dump):

(insn 2483 2480 2485 40 ../../../cvssrc/gcc/gcc/libgcc2.c:1825 (set (reg:HI 643)
(ashiftrt:HI (reg:HI 641)
(const_int 15 [0xf]))) 31 {*ashrhi3_const15} 
(insn_list:REG_DEP_TRUE 2480 (nil))
(expr_list:REG_DEAD (reg:HI 641)
(nil)))

(insn 2485 2483 2486 40 ../../../cvssrc/gcc/gcc/libgcc2.c:1825 (set (reg:QI 178)
(subreg:QI (reg:HI 643) 0)) 34 {movqi} (insn_list:REG_DEP_TRUE 2483 
(nil))
(expr_list:REG_DEAD (reg:HI 643)
(nil)))

But nice try anyway, combine. :-)

-- 
Rask Ingemann Lambertsen

how to print an __int128_t integer?

[bacmoz]

i found in amd asm64-handout that gcc supports __int128_t and __uint128_t for
128-bit integers.
i test it's true.
but how to print an __int128_t integer? use printf, or any other methods.

thanks
-- 
View this message in context: 
http://www.nabble.com/how-to-print-an-__int128_t-integer--tf2051654.html#a5651886
Sent from the gcc - Dev forum at Nabble.com.

RE: how to print an __int128_t integer?

[Dave Korn]

On 04 August 2006 15:57, bacmoz wrote:

> i found in amd asm64-handout that gcc supports __int128_t and __uint128_t
> for 128-bit integers.
> i test it's true.
> but how to print an __int128_t integer? use printf, or any other methods.

  Please *READ* the group descriptions if you're going to use Nabble:

http://www.nabble.com/gcc---Dev-f1157.html
"  Please note this is NOT, I repeat NOT, a GCC users list - this is a GCC
developers list. For user general questions, post to GCC - Help.  "


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: reload getting the mode of (subreg:HI (reg:QI pseudo)) wrong

[Ian Lance Taylor]

Bernd Schmidt <[EMAIL PROTECTED]> writes:

> Rask Ingemann Lambertsen wrote:
> > The constraints are not met because the constraint "d" is register class
> > DX_REGS consisting of register 4 and 5, and (reg:HI 5 dh) spans register 5
> > and 6. Also, HARD_REGNO_NREGS (5, HImode) returns 0.
> > The lreg and greg dumps provide the clue that reload got the mode
> > wrong:
> > (insn:HI 2485 2483 2486 39 libgcc2.c:1825 (set (subreg:HI (reg:QI
> > 178) 0)
> > (ashiftrt:HI (reg:HI 641)
> > (const_int 15 [0xf]))) 31 {*ashrhi3_const15}
> > (insn_list:REG_DEP_TRUE 2480 (nil))
> > (expr_list:REG_DEAD (reg:HI 641)
> > (nil)))
> 
> Probably the compiler doesn't in general like a paradoxical subreg
> that can take more hard regs than its SUBREG_REG.  I think this is
> probably something that can be worked around with a proper combination
> of MODES_TIEABLE_P, CANNOT_CHANGE_MODE_CLASS, and maybe
> REG_CANNOT_CHANGE_MODE_P.  What are your definitions of those macros?

This also suggests the possibility of writing a QImode version of the
insn which uses a scratch register.

Ian

day to day quality report for the past 12.5 months

[Mike Stump]

If one asks Geoff's regression tester what it thinks of the day to  
day quality of gcc, one gets:


256 build native
  65 regress-8 native
  64 regress-6 native
  55 regress-5 native
  48 regress-9 native
  42 regress-4 native
  41 regress-7 native
  39 regress-3 native
  33 regress-11 native
  30 regress-2 native
  16 regress-1 native
  15 regress-10 native
  12 regress-12 native
   7 regress-268 native
   7 regress-26 native
   7 regress-25 native
   4 regress-30 native
   4 regress-24 native
   3 regress-32 native
   3 regress-200 native
   3 pass native
   2 regress-48 native
   2 regress-31 native
   2 regress-28 native
   1 regress-49 native
   1 regress-33 native
   1 regress-27 native
   1 regress-14 native
   1 regress-13 native

The first number being the count, the second is the status.  The  
curious thing we see here is that the pass rate is 3 out of 765 runs,  
that''s around 0.4%.  There were 34 transitions from building to not  
building.


Broken down on a per day basis:

246 regress
  63 build
   3 pass

meaning there were 3 days where things passed at least once that day,  
63 days when things failed to build at least once that day, and 246  
days when things built at least once that day but had regressions.   
There were roughly 383 days in the interval.


See http://gcc.gnu.org/regtest/HEAD/log.txt.gz for all the raw data.

Re: day to day quality report for the past 12.5 months

[Andrew Pinski]

> 
> If one asks Geoff's regression tester what it thinks of the day to  
> day quality of gcc, one gets:

This is only of C, C++, Objc, and Java.  This does include Objective-C++
or Fortran which would be more interesting anyways.  Also we would be
back down to 0 regressions (except for a timeout every once in a while)
if Java bootstrap was not broken.

Also I think most of the days with 1 regressions are really 0 regressions
but a timeout in the java testsuite.

Thanks,
Andrew Pinski

Re: Eric Botcazou appointed RTL maintainer

[Eric Botcazou]

> The GCC SC has appointed you an "RTL maintainer".  Congratulations!

A bit unexpected but thanks anyway. :-)

> That means that you have maintainership of all machine-independent RTL
> optimization passes, like jump, CSE, GCSE, flow, sched2,
> shorten_branches, etc.  This post doesn't cover back ends, dwarf2out.c,
> or other things that aren't optimization passes.  I know that it's hard
> to be exactly sure where the boundaries lie, but I've every confidence
> you'll use your judgment well.  Please feel free to ask if you're not sure.

Obvious question: what of the RTL expander(s)?

> Please adjust MAINTAINERS accordingly -- and then please fix PRs and
> approve patches for same. :-)

I see... :-)

-- 
Eric Botcazou

Mudflap and freeing C runtime memory upon exit (feature request)

[Vesselin Peev]

Hello,

I have a feature request for mudflap. It should have an option to run 
glibc's _libc_freeres function that forces the C runtime library to free all 
of its memory and does not leave that task to the underlying OS. When 
instrumented with mudflap, the following program reports upon exit tens of 
memory leaks, e.g. 58 leaks under one of several GNU/Linux distributions I 
have tested on, similar results on others. (Be sure to set the 
MUDFLAP_OPTIONS environment variable to "-print-leaks"; the program is, of 
course, built with "gcc -g -fmudflap  -lmudflap".) The gcc 
versions used are the 4.1.1 final and latest official release and 4.2.0 
20060729 on x86 (not x86-64).


#include 

// void __libc_freeres();

int main()
{
// atexit(__libc_freeres);
gethostbyname("www.gnu.org");
return 0;
}

Now, if the two lines are uncommented, mudflap does not report the leaks, 
but unfortunately it produces an equal amount of "mudflap warning: 
unaccessed registered object" warnings. With several lines printed for each 
of the tens of warnings, the console is swamped with text. There does not 
seem to exist a mudflap option to suppress this type of warning, and, in 
this case, it probably does not make sense to be suppressed, but rather 
something should be corrected on the mudflap / C runtime library side.


So, in short, what I request is the equivalent of the memory debugger 
Valgrind's option "--run-libc-freeres". The option defaults to yes, but can 
be set to no, because, according to the Valgrind documentation, some older 
versions of glibc segfault when __libc_freeres is called.


Regards,
Vesselin.

P.S.

Should I submit in the GCC Bugzilla? There are 2 other problems, strictly 
problems, not feature requests, I have submitted there.

Re: Mudflap and freeing C runtime memory upon exit (feature request)

[Frank Ch. Eigler]

"Vesselin Peev" <[EMAIL PROTECTED]> writes:

> [...]  I have a feature request for mudflap. It should have an
> option to run glibc's _libc_freeres function that forces the C
> runtime library to free all of its memory [...]

Good idea.  (It should not take more than a dozen lines of code - a
threshold below which one may not even need a copyright assignment in
order to contribute.)

- FChE

Re: How gcov handles untested files, prior and after GCC 3.4

[Nathan Sidwell]

Fredrik Johansson wrote:


Why I ask is because I need to extract the number of lines even in
untested files, and I need it to work both on 3.3.6 and on various
3.4.x versions.


This use case had not occurred to me.

nathan

--
Nathan Sidwell::   http://www.codesourcery.com   :: CodeSourcery
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk

gcc-4.1-20060804 is now available

[gccadmin]

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

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

You'll find:

gcc-4.1-20060804.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.1-20060804.tar.bz2 C front end and core compiler

gcc-ada-4.1-20060804.tar.bz2  Ada front end and runtime

gcc-fortran-4.1-20060804.tar.bz2  Fortran front end and runtime

gcc-g++-4.1-20060804.tar.bz2  C++ front end and runtime

gcc-java-4.1-20060804.tar.bz2 Java front end and runtime

gcc-objc-4.1-20060804.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.1-20060804.tar.bz2The GCC testsuite

Diffs from 4.1-20060728 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.1
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: Building libstdc++ for powerpc-eabi

[Geoffrey Keating]

Michael Eager <[EMAIL PROTECTED]> writes:

> I'm running into problems building libstdc++
> for powerpc-eabi.  It eventually fails with an
> error message saying "Link tests are not allowed
> after GCC_NO_EXECUTABLES" while it is checking
> to see if libgcc_s exists.
> 
> Meanwhile, config.log for libstdc++ shows lots
> of compile failures.  So I think that the error
> while looking for libgcc_s is really a red herring.

No, it's not; it's the actual problem.

> The compile failures are the result of ecrti.o
> not being included in the link.  Nick Clifton
> posted a message about this, with a patch
> (http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00039.html).
> After applying this patch, libstdc++ builds OK.
> 
> Following the discussion on that thread, it seems
> like the suggestion is that one should build gcc
> for some other similar target, such as powerpc-eabisim,
> which sort of misses the goal of building powerpc-eabi.
> 
> So, what is the right way to build g++ for powerpc-eabi?

You fix the bug, and then it works.

See follow-up messages to the message you quoted, notably

and
.

Re: Bootstrap failure caused by jvmti additions

[Mark Wielaard]

Hi,

On Fri, 2006-08-04 at 10:57 +0200, Volker Reichelt wrote:
> your patch http://gcc.gnu.org/ml/java-patches/2006-q3/msg00264.html
> broke bootstrap (at least on x86_64-unknown-linux-gnu):
> 
> ranlib .libs/libgij.a
> creating libgij.la
> ./.libs/libgcj.so: undefined reference to `JvNumMethods(java::lang::Class*)'
> ./.libs/libgcj.so: undefined reference to 
> `JvGetFirstMethod(java::lang::Class*)'
> collect2: ld returned 1 exit status
> make[5]: *** [jv-convert] Error 1

No idea if it is correct, but I am using the attached to get things to
compile again.

Cheers,

Mark
Index: jvmti.cc
===
--- jvmti.cc	(revision 115934)
+++ jvmti.cc	(working copy)
@@ -29,6 +29,8 @@
 #include 
 #include 
 
+#include 
+
 extern struct JNINativeInterface _Jv_JNIFunctions;
 
 struct _Jv_rawMonitorID
@@ -553,13 +555,10 @@
   if (klass->isArray())
 {
   jclass comp = klass->getComponentType();
-  jint base
-	= (jint) _Jv_GetArrayElementFromElementType(NULL,
-		klass->getComponentType());
   // FIXME: correct for primitive types?
   jint compSize = comp->size();
   __JArray *array = (__JArray *) object;
-  *result = base + array->length * compSize;
+  *result = klass->size() + array->length * compSize;
 }
   else
 {

does gcc support multiple sizes, or not?

[DJ Delorie]

In cp/cvt.c we have this code in cp_convert_to_pointer:

  if (INTEGRAL_CODE_P (form))
{
  if (TYPE_PRECISION (intype) == POINTER_SIZE)
return build1 (CONVERT_EXPR, type, expr);
  expr = cp_convert (c_common_type_for_size (POINTER_SIZE, 0), expr);
  /* Modes may be different but sizes should be the same.  There
 is supposed to be some integral type that is the same width
 as a pointer.  */
  gcc_assert (GET_MODE_SIZE (TYPE_MODE (TREE_TYPE (expr)))
  == GET_MODE_SIZE (TYPE_MODE (type)));

  return convert_to_pointer (type, expr);
}

Note that it always converts to a POINTER_SIZE pointer, regardless of
the size of TYPE (the target type), then asserts that the result is
the same size as TYPE.

However, in s390.c, we have:

static bool
s390_valid_pointer_mode (enum machine_mode mode)
{
  return (mode == SImode || (TARGET_64BIT && mode == DImode));
}

Note that more than one mode is supported simultaneously.  Thus, it's
legal for the application to specify SI or DI mode for pointer (via
__attribute__((mode))), but cc1plus then aborts.

So... who is right?  Are we supposed to support multiple pointer sizes
in the same compilation unit, or not?

gcc libraries

[supradip dey]

it will be so nice of you if you inform me :
What are the header files & functions used by 
gcc ?Is it same as borland turbo header files ?
regards,
supradip dey



__
Yahoo! India Answers: Share what you know. Learn something new
http://in.answers.yahoo.com/

Re: gcc libraries

[Mike Stump]

On Aug 4, 2006, at 6:31 PM, supradip dey wrote:

What are the header files & functions used by gcc?


There are many, please see the source.


Is it same as borland turbo header files ?


No.

Re: Bootstrap failure caused by jvmti additions

[Tom Tromey]

> "Volker" == Volker Reichelt <[EMAIL PROTECTED]> writes:

Volker> your patch http://gcc.gnu.org/ml/java-patches/2006-q3/msg00264.html
Volker> broke bootstrap (at least on x86_64-unknown-linux-gnu):

I'm very sorry about this.  I know it must not seem like it, but I
really did build with this patch.  I don't know what went wrong, but I
assume it is some mistake of mine.

I'm checking the appended subset of Mark's patch.
The other part, I believe, I have already taken care of.

Tom

Index: ChangeLog
from  Mark Wielaard  <[EMAIL PROTECTED]>

* jvmti.cc: Include gcj/method.h.

Index: jvmti.cc
===
--- jvmti.cc(revision 115942)
+++ jvmti.cc(working copy)
@@ -16,6 +16,8 @@
 #include 
 #include 
 
+#include 
+
 #include 
 #include 
 #include 

Re: does gcc support multiple sizes, or not?

[Richard Kenner]

> So... who is right?  Are we supposed to support multiple pointer sizes
> in the same compilation unit, or not?

Who's "we"? The middle-end and relevant back-ends support it, but clearly
not all the front ends.  C and Ada does but your experiment seems to show
that C++ does not.