libgomp: Thread creation failed: Invalid argument
I am very happy to see that gfortran from current gcc snapshots can successfully compile an 18000 lines Fortran 77 numerics program I wrote. Results are indeed the same as obtained with other compilers (g77, PGI, ifort), and also execution speed seems roughly comparable, although I haven't yet done any precise measurements. A big thank you to the developers for that! Now I am trying to get the program to run with OpenMP, which works (although slower than anticipated) with PGI and ifort compilers. While I can successfully build and execute small OpenMP test programs, starting my large program fails with the message libgomp: Thread creation failed: Invalid argument resulting from a failing call to pthread_create() in libgomp/team.c. Using gdb I see that pthread_create() is called with the same gomp_thread_attr argument as for the smaller, succeeding testcases. strace shows that pthread_create() fails without trying to call clone(), while the clone() call of course does happen for the succeeding testcases. How to further debug this problem? I am currently using gcc-4.2-20060812 on i686 and x86_64 SuSE 10.0 Linux systems. Thank you, Tim
Re: libgomp: Thread creation failed: Invalid argument
Tim Schmielau wrote on 08/15/06 10:15: > How to further debug this problem? > I am currently using gcc-4.2-20060812 on i686 and x86_64 SuSE 10.0 Linux > systems. > Please submit a bug report including the code you are trying to compile. ( http://gcc.gnu.org/bugs.html) How many threads are you trying to spawn?
Re: libgomp: Thread creation failed: Invalid argument
On Tue, 15 Aug 2006, Diego Novillo wrote: > Tim Schmielau wrote on 08/15/06 10:15: > > > How to further debug this problem? > > I am currently using gcc-4.2-20060812 on i686 and x86_64 SuSE 10.0 Linux > > systems. > > > Please submit a bug report including the code you are trying to compile. > ( http://gcc.gnu.org/bugs.html) > > How many threads are you trying to spawn? The problem appears for any OMP_NUM_THREADS value other than 1 (I tried up to 8 on an 8-way machine). Extracting a testcase from the 18.000 lines of code will probably require some work, so I was looking for easier things to chek first. But I'll try to do that, then. Thanks, Tim
Re: libgomp: Thread creation failed: Invalid argument
Tim Schmielau wrote on 08/15/06: The problem appears for any OMP_NUM_THREADS value other than 1 (I tried up to 8 on an 8-way machine). Extracting a testcase from the 18.000 lines of code will probably require some work, so I was looking for easier things to chek first. But I'll try to do that, then. Are you using a lot of threadprivate variables? Try setting the GOMP_STACKSIZE environment variable to a large value (in kB) and see if the problem persists.
Re: type consistency of gimple
Hi Diego,
Jeff's point about our optimizers is also true. Nick, remember that
issue with MIPS optimizations you were discussing with Jeff a few days
ago? I didn't follow most of the details, but it involved ivopts and
sign issues. Could you send a summary?
Sure:
I was looking at how a gcc 4.1 based compiler optimized a fast
fourier transform algorithm for the MIPS target. What I found was the
it was producing much worse code than a similarly configured gcc 3.4
based compiler, and the culprit was the creation of the induction
variables used in the inner loop.
The nested loops look like this:
signed short i,j,k,DataSizeExponent,DataSize;
signed short RealBitRevData[MAX], ImagBitRevData[MAX];
signed short * CosineV, * SineV;
for (k = 1; k <= DataSizeExponent; k++)
{
signed short n1 = 1 << k;
signed short n2 = n1 >> 1;
signed short ArgIndex = 0;
signed short DeltaIndex = (DataSize >> 1) / n2;
for (j = 0; j < n2; j++)
{
signed int WReal = CosineV[ArgIndex];
signed int WImag = SineV[ArgIndex];
ArgIndex += DeltaIndex;
for (i = j; i < DataSize; i += n1)
{
signed short l = i + n2;
signed int tRealData = (WReal * RealBitRevData[l]) +
(WImag * ImagBitRevData[l]);
signed int tImagData = (WReal * ImagBitRevData[l]) -
(WImag * RealBitRevData[l]);
tRealData = tRealData >> BUTTERFLY_SCALE_FACTOR;
tImagData = tImagData >> BUTTERFLY_SCALE_FACTOR;
RealBitRevData[l] = RealBitRevData[i] - tRealData;
ImagBitRevData[l] = ImagBitRevData[i] - tImagData;
RealBitRevData[i] += tRealData;
ImagBitRevData[i] += tImagData;
}
}
}
and the inner loop was being transformed into:
short int D.2046, D.2043;
long int D.2038, D.2035;
int D.2033, D.2024, D.2020, D.2008, D.2001;
[...]
:;
D.2033 = (int) (signed short) ivtmp.67;
D.2035 = (long int) RealBitRevData[D.2033];
D.2038 = (long int) ImagBitRevData[D.2033];
tRealData = WReal * D.2035 + WImag * D.2038;
tImagData = WReal * D.2038 - WImag * D.2035;
D.2001 = (int) i;
D.2043 = (short int) (tRealData >> 15);
RealBitRevData[D.2033] = RealBitRevData[D.2001] - D.2043;
D.2046 = (short int) (tImagData >> 15);
ImagBitRevData[D.2033] = ImagBitRevData[D.2001] - D.2046;
RealBitRevData[D.2001] = D.2043 + RealBitRevData[D.2001];
ImagBitRevData[D.2001] = D.2046 + ImagBitRevData[D.2001];
i = (signed short) ((short unsigned int) i + ivtmp.78);
ivtmp.68 = ivtmp.68 + ivtmp.78;
ivtmp.67 = ivtmp.67 + ivtmp.78;
if (DataSize > (signed short) (ivtmp.68 - ivtmp.78)) goto ; else
goto ;
The net result of these induction variables, and especially the type
translations necessary to go between signed and unsigned and shorts and
ints was an inner loop consisting of 42 instructions, as opposed to an
inner loop of 32 instructions as produced by the gcc 3.4 compiler.
Cheers
Nick
copyright assignment form
Please seend me the copyright assignment form required for contribution to gcc. Thanks in advance. Jack Howarth
Re: type consistency of gimple
Nick Clifton wrote:
> Hi Diego,
>
>> Jeff's point about our optimizers is also true. Nick, remember that
>> issue with MIPS optimizations you were discussing with Jeff a few days
>> ago? I didn't follow most of the details, but it involved ivopts and
>> sign issues. Could you send a summary?
>
> Sure:
>
> I was looking at how a gcc 4.1 based compiler optimized a fast
> fourier transform algorithm for the MIPS target. What I found was the
> it was producing much worse code than a similarly configured gcc 3.4
> based compiler, and the culprit was the creation of the induction
> variables used in the inner loop.
>
I think that you are pointing the gun at the wrong suspect. I believe
that the true villain is some where down stream in the backend passes
that cannot see thru the type conversions. This is one case of us
having "degraded" the back end because the middle end likes to break
things up into smaller pieces and the back end has too small of a window
to look thru to do its work.
We should be looking at the back end to see where it cannot see what it
needs to see rather than trying to stop getting the middle end code into
a reasonable form.
> The nested loops look like this:
>
> signed short i,j,k,DataSizeExponent,DataSize;
> signed short RealBitRevData[MAX], ImagBitRevData[MAX];
> signed short * CosineV, * SineV;
>
> for (k = 1; k <= DataSizeExponent; k++)
> {
> signed short n1 = 1 << k;
> signed short n2 = n1 >> 1;
> signed short ArgIndex = 0;
> signed short DeltaIndex = (DataSize >> 1) / n2;
>
> for (j = 0; j < n2; j++)
> {
> signed int WReal = CosineV[ArgIndex];
> signed int WImag = SineV[ArgIndex];
>
> ArgIndex += DeltaIndex;
> for (i = j; i < DataSize; i += n1)
> {
> signed short l = i + n2;
> signed int tRealData = (WReal * RealBitRevData[l]) +
> (WImag * ImagBitRevData[l]);
> signed int tImagData = (WReal * ImagBitRevData[l]) -
> (WImag * RealBitRevData[l]);
>
> tRealData = tRealData >> BUTTERFLY_SCALE_FACTOR;
> tImagData = tImagData >> BUTTERFLY_SCALE_FACTOR;
> RealBitRevData[l] = RealBitRevData[i] - tRealData;
> ImagBitRevData[l] = ImagBitRevData[i] - tImagData;
> RealBitRevData[i] += tRealData;
> ImagBitRevData[i] += tImagData;
> }
> }
> }
>
> and the inner loop was being transformed into:
>
> short int D.2046, D.2043;
> long int D.2038, D.2035;
> int D.2033, D.2024, D.2020, D.2008, D.2001;
>[...]
>
> :;
> D.2033 = (int) (signed short) ivtmp.67;
> D.2035 = (long int) RealBitRevData[D.2033];
> D.2038 = (long int) ImagBitRevData[D.2033];
> tRealData = WReal * D.2035 + WImag * D.2038;
> tImagData = WReal * D.2038 - WImag * D.2035;
> D.2001 = (int) i;
> D.2043 = (short int) (tRealData >> 15);
> RealBitRevData[D.2033] = RealBitRevData[D.2001] - D.2043;
> D.2046 = (short int) (tImagData >> 15);
> ImagBitRevData[D.2033] = ImagBitRevData[D.2001] - D.2046;
> RealBitRevData[D.2001] = D.2043 + RealBitRevData[D.2001];
> ImagBitRevData[D.2001] = D.2046 + ImagBitRevData[D.2001];
> i = (signed short) ((short unsigned int) i + ivtmp.78);
> ivtmp.68 = ivtmp.68 + ivtmp.78;
> ivtmp.67 = ivtmp.67 + ivtmp.78;
> if (DataSize > (signed short) (ivtmp.68 - ivtmp.78)) goto ; else
> goto ;
>
>
> The net result of these induction variables, and especially the type
> translations necessary to go between signed and unsigned and shorts
> and ints was an inner loop consisting of 42 instructions, as opposed
> to an inner loop of 32 instructions as produced by the gcc 3.4 compiler.
>
> Cheers
> Nick
>
Re: libgomp: Thread creation failed: Invalid argument
On Tue, 15 Aug 2006, Asher Langton wrote: > Tim Schmielau wrote on 08/15/06: > > The problem appears for any OMP_NUM_THREADS value other than 1 (I tried > > up to 8 on an 8-way machine). > > Extracting a testcase from the 18.000 lines of code will probably require > > some work, so I was looking for easier things to chek first. But I'll try > > to do that, then. > > Are you using a lot of threadprivate variables? Try setting the > GOMP_STACKSIZE environment variable to a large value (in kB) and see > if the problem persists. That's it! Yes, I do use a large set of threadprivate variables. I tried different settings of GOMP_STACKSIZE before. However, I somehow didn't hit a working setting as I didn't know it was measured in kB. The program now works on x86_64 with SETENV GOMP_STACKSIZE 1048576. On i686 I do not find a working stacksize, as for too large stacksizes the program dies with a segfault. Wonder how PGI and ifort deal with the limited address space. Thanks a lot! Tim
Re: type consistency of gimple
Kenneth Zadeck wrote on 08/15/06 11:57: > We should be looking at the back end to see where it cannot see what it > needs to see rather than trying to stop getting the middle end code into > a reasonable form. > You're confused. This is a middle-end mis-optimization. However, it is true that we should probably make the optimizers smarter. First, though, we must define a GIMPLE type system.
Re: libgomp: Thread creation failed: Invalid argument
On 8/15/06, Tim Schmielau <[EMAIL PROTECTED]> wrote: On Tue, 15 Aug 2006, Asher Langton wrote: > Tim Schmielau wrote on 08/15/06: > > The problem appears for any OMP_NUM_THREADS value other than 1 (I tried > > up to 8 on an 8-way machine). > > Extracting a testcase from the 18.000 lines of code will probably require > > some work, so I was looking for easier things to chek first. But I'll try > > to do that, then. > > Are you using a lot of threadprivate variables? Try setting the > GOMP_STACKSIZE environment variable to a large value (in kB) and see > if the problem persists. That's it! Yes, I do use a large set of threadprivate variables. I tried different settings of GOMP_STACKSIZE before. However, I somehow didn't hit a working setting as I didn't know it was measured in kB. The program now works on x86_64 with SETENV GOMP_STACKSIZE 1048576. On i686 I do not find a working stacksize, as for too large stacksizes the program dies with a segfault. Wonder how PGI and ifort deal with the limited address space. Ifort has a similar environment variable, but I found that I didn't actually need it. On a side note: I just posted a patch on the fortran list that implements threadprivate without using Thread Local Storage (so that it works on Darwin, AIX, etc.). One unintended result was that I no longer needed to set GOMP_STACKSIZE to compile programs with lots of threadprivates. Would you mind trying your code against this patch, and letting me know if it works (at all), and whether you still need to set GOMP_STACKSIZE? http://gcc.gnu.org/ml/fortran/2006-08/msg00191.html -Asher
Re: type consistency of gimple
On Tue, 2006-08-15 at 11:57 -0400, Kenneth Zadeck wrote: > Nick Clifton wrote: > > Hi Diego, > > > >> Jeff's point about our optimizers is also true. Nick, remember that > >> issue with MIPS optimizations you were discussing with Jeff a few days > >> ago? I didn't follow most of the details, but it involved ivopts and > >> sign issues. Could you send a summary? > > > > Sure: > > > > I was looking at how a gcc 4.1 based compiler optimized a fast > > fourier transform algorithm for the MIPS target. What I found was the > > it was producing much worse code than a similarly configured gcc 3.4 > > based compiler, and the culprit was the creation of the induction > > variables used in the inner loop. > > > I think that you are pointing the gun at the wrong suspect. I believe > that the true villain is some where down stream in the backend passes > that cannot see thru the type conversions. This is one case of us > having "degraded" the back end because the middle end likes to break > things up into smaller pieces and the back end has too small of a window > to look thru to do its work. > > We should be looking at the back end to see where it cannot see what it > needs to see rather than trying to stop getting the middle end code into > a reasonable form. No. If you look *really* closely at the conversions, all are necessary because of need to propagate sign bits. The type selection for the induction variables and our demand for simple ints for array indexing causes us to generate horrific code. Choosing better types for the induction variables and/or having a more relaxed set of rules for array indexing would help this code greatly. While there may be some chance to optimize away a couple of the conversions by improving combine's ability to combine a load with extension, we'd be much better off fixing these issues at the tree-ssa level. jeff
Re: type consistency of gimple
Diego Novillo wrote: > Kenneth Zadeck wrote on 08/15/06 11:57: > > >> We should be looking at the back end to see where it cannot see what it >> needs to see rather than trying to stop getting the middle end code into >> a reasonable form. >> >> > You're confused. This is a middle-end mis-optimization. However, it is > true that we should probably make the optimizers smarter. > > First, though, we must define a GIMPLE type system. > I most likely am. You are right, we need a type system. kenny
Re: type consistency of gimple
Kenneth Zadeck wrote: > Nick Clifton wrote: >> Hi Diego, >> >>> Jeff's point about our optimizers is also true. Nick, remember that >>> issue with MIPS optimizations you were discussing with Jeff a few days >>> ago? I didn't follow most of the details, but it involved ivopts and >>> sign issues. Could you send a summary? >> Sure: >> >> I was looking at how a gcc 4.1 based compiler optimized a fast >> fourier transform algorithm for the MIPS target. What I found was the >> it was producing much worse code than a similarly configured gcc 3.4 >> based compiler, and the culprit was the creation of the induction >> variables used in the inner loop. >> > I think that you are pointing the gun at the wrong suspect. I believe > that the true villain is some where down stream in the backend passes > that cannot see thru the type conversions. This is one case of us > having "degraded" the back end because the middle end likes to break > things up into smaller pieces and the back end has too small of a window > to look thru to do its work. > > We should be looking at the back end to see where it cannot see what it > needs to see rather than trying to stop getting the middle end code into > a reasonable form. Uh, well, since the backend doesn't have real type information, it would be hard to make it see through type conversions.
Re: How to GTYize a struct properly?
At the risk of stating the obvious, those parentheses after "GTY" look unbalanced to me. Of course, these were fixed very soon :) -- Laurynas
Re: How to GTYize a struct properly?
gengtype doesn't support anonymous structures or unions, you need to
give them a name. (I don't remember if this is simply a limitation of
the existing implementation or if it's more fundamental.)
OK, naming them has helped. Out of curiosity, why does following
typedef int *lambda_vector;
typedef lambda_vector *lambda_matrix;
typedef struct GTY(())
{
lambda_matrix matrix; /* < here */
int rowsize;
int colsize;
int denominator;
} *lambda_trans_matrix;
make gengtype complain about unknown type "lambda_matrix"?
--
Laurynas
Re: Feature request - error for implicit int return in pointer context
On Mon, Aug 14, 2006 at 08:38:38PM -0400, Pavel Roskin wrote: > On Mon, 2006-08-14 at 22:44 +0200, Andreas Schwab wrote: > > Try -Werror-implicit-function-declaration. Not the same, but pretty > > close. > > Thanks! I know. In fact, I'm using at least "-Wall -Werror" for my > code and for the code I'm working with, so it's implied. I'm talking > about code that I have never seen until the binary did a poo-poo on my > machine. > > Sure, I can petition Fedora, Novell, Debian and others to use > -Werror-implicit-function-declaration, but I don't think I'll have > convincing arguments. You seem to think that if GCC gets stricter about rejecting bad code, things will get magically better and software distributions will produce better code. It tends not to work that way, and the attempt will just cause the sloppier distros to delay upgrading to new gcc versions. The basic problem is the unfortunate "implicit int" rule from K&R C that we still haven't killed. And your proposed solution, in my view, is a hack. You want to detect the one case where a result of an implicit int function is converted into a pointer, and treat this as a hard error while still giving only a warning for the conversion of some other int into a pointer (even though these other conversions may also be 64-bit bugs).
RE: does gcc support multiple sizes, or not?
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Mark Mitchell > Sent: Monday, August 14, 2006 12:50 PM > To: DJ Delorie > Cc: [EMAIL PROTECTED]; gcc@gcc.gnu.org > Subject: Re: does gcc support multiple sizes, or not? > > DJ Delorie wrote: > >> And back to my original answer: it's up to each language to decide > >> that. > > > > Hence my original question: is it legal or not? What did the C++ > > developers decide? > > The C++ standard implies that for all pointer-to-object types have the > same size and that all pointer-to-function types have the same size. > (Technically, it doesn't say that that; it says that you can convert T* > -> U* -> T* and get the original value.) However, nothing in the > standard says that pointer-to-object types must have the same size as > pointer-to-function types. The C standard says that all pointer to structure and unions must have the same size and format as each other, since otherwise declaring pointers to structure tags that aren't declared in this module would not be compatible with the same declaration in another module where you do declare the structure tag. When the ANSI C-89 (and later ISO C-90) standard came out, I was working on a C compiler for a machine with different flavors of pointers, and so I was very aware of the ins and outs. Pointers to functions can be a different size than pointers to data, which is one of the reasons in C-89 you can't assign a function pointer to a void *. Because of the rule for functions with no prototypes (since deprecated in C-99), all function pointers must be the same size as each other. > In theory, I believe that G++ should permit the sizes to be different. > However, as far as I know, none of the G++ developers considered that > possibility, which probably means that we have made the assumption that > they are all the same size at some points. I would consider places > where that assumption is made to be bugs in the front end. I think having pointers be the same size is ingrained in the whole compiler, not just the front ends. I did a port to a machine (Mitsubshi D10V) that had different flavors of pointers, though thankfully they were the same size (pointers to functions were pointers to 32-bit instruction words, while pointers to data were bytes to 8-bit bytes). When I did that compiler (GCC 2-3 time frame), there were many limitations caused by this, including the prohibition against trampolines. -- Michael Meissner AMD, MS 83-29 90 Central Street Boxborough, MA 01719
Re: Feature request - error for implicit int return in pointer context
On Tue, 2006-08-15 at 10:06 -0700, Joe Buck wrote: > On Mon, Aug 14, 2006 at 08:38:38PM -0400, Pavel Roskin wrote: > > On Mon, 2006-08-14 at 22:44 +0200, Andreas Schwab wrote: > > > Try -Werror-implicit-function-declaration. Not the same, but pretty > > > close. > > > > Thanks! I know. In fact, I'm using at least "-Wall -Werror" for my > > code and for the code I'm working with, so it's implied. I'm talking > > about code that I have never seen until the binary did a poo-poo on my > > machine. > > > > Sure, I can petition Fedora, Novell, Debian and others to use > > -Werror-implicit-function-declaration, but I don't think I'll have > > convincing arguments. > > You seem to think that if GCC gets stricter about rejecting bad code, > things will get magically better and software distributions will produce > better code. It tends not to work that way, and the attempt will just > cause the sloppier distros to delay upgrading to new gcc versions. That's unfortunate. Although it's hard to imagine that is would stop Fedora. > The basic problem is the unfortunate "implicit int" rule from K&R C that > we still haven't killed. And your proposed solution, in my view, is a > hack. You want to detect the one case where a result of an implicit int > function is converted into a pointer, and treat this as a hard error while > still giving only a warning for the conversion of some other int into a > pointer (even though these other conversions may also be 64-bit bugs). The thing is, one can call the function properly, using 0 for integers, 0L for longs and NULL for pointers, and gcc will do the right thing (I think so). In the same time, using the function result "properly", i.e. placing a pointer into a pointer variable, will not work. Anyway, it was just an idea from an outsider, and I'm not going to argue too much about it. -- Regards, Pavel Roskin
define_expand
I'm having trouble understanding part of the machine description for PowerPC floating point operations. There are a number of places where there are pairs of templates, one with define_expand, the other with define_insn or define_insn_and_split. For example, the fp negate templates: (define_expand "negsf2" [(set (match_operand:SF 0 "gpc_reg_operand" "") (neg:SF (match_operand:SF 1 "gpc_reg_operand" "")))] "TARGET_HARD_FLOAT" "") (define_insn "*negsf2" [(set (match_operand:SF 0 "gpc_reg_operand" "=f") (neg:SF (match_operand:SF 1 "gpc_reg_operand" "f")))] "TARGET_HARD_FLOAT && TARGET_FPRS" "fneg %0,%1" [(set_attr "type" "fp")]) I've read the docs (sect 13.15) which describe define_expand, but I have a feeling that I'm missing something that would make it clear how these two templates interact. Clearly, the define_insn template says that when the insn pattern is found, generate the "fneg" instruction. What is the define_expand template doing? Thanks! -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: define_expand
On Tue, Aug 15, 2006 at 10:52:01AM -0700, Michael Eager wrote: > (define_expand "negsf2" > [(set (match_operand:SF 0 "gpc_reg_operand" "") > (neg:SF (match_operand:SF 1 "gpc_reg_operand" "")))] > "TARGET_HARD_FLOAT" > "") > I've read the docs (sect 13.15) which describe define_expand, > but I have a feeling that I'm missing something that would make > it clear how these two templates interact. Clearly, the define_insn > template says that when the insn pattern is found, generate the > "fneg" instruction. What is the define_expand template doing? The important thing about the define_expand pattern, in this case, is that it has a name. A call to gen_negsf2 will generate the RTL specified by that expander. This also gets automatically handled by optabs.c when generating negation, and there may be macros like HAVE_negsf2. Then, the *negsf2 define_insn is used to actually emit the operation (and for things like combine, which test if an instruction is valid). -- Daniel Jacobowitz CodeSourcery
Re: [C frontend] Wtraditional / Wconversion and decimal float
On 14/08/06, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote: Does this mean that I should remove the corresponding code from gcc/c-typeck.c:convert_arguments() and also remove gcc.dg/dfp/Wconversion-2.c ? add also the testcase gcc.dg/dfp/wtr-conversion-1.c to the list.
Re: does gcc support multiple sizes, or not?
> I think having pointers be the same size is ingrained in the whole > compiler, not just the front ends. Having *implicit* pointers be *a specific* size certainly is. Made the m32c project a lot harder. There's a lot of places that use POINTER_SIZE instead of MODE_SIZE(x), or Pmode instead of GET_MODE (x), even when doing the "right" thing would be trivial.
Re: does gcc support multiple sizes, or not?
> I'm not sure if I understand. In ISO C++, it would be fine for "char *"
> to have more bits than all other pointers. The standard says X* -> Y*
> -> X* is value-preserving if Y has no stricter alignment than X. Since
> "char" has weak alignment requirements, Y can be "char". Is that what
> you mean?
No, I meant if we go A -> B -> A, it's defined iff sizeof(B) >= sizeof(A)
> In ISO C++, there's of course no notion of "char *far" or "char
> *near"; there's just "char *". So, there's no way to directly map
> your intended type system onto the conversion sequence above.
The problem seems to revolve around casts. How about if I turn the
abort into a useful message about casting between pointer sizes, and
require the user to use a builtin to convert pointers? In the case of
TPF, a "normal" cast wouldn't do the right thing anyway. Of course,
we should make C give a similar warning, so as to not surprise users.
I strongly request we continue supporting the use of attribute((mode))
to create pointers of different sizes, at least for copying and
passing. The m32c reset vector and interrupt table really want to be
set up like this example:
typedef void (*ifunc)() __attribute__((mode(SI)));
ifunc __attribute__((section(".resetvec"))) reset_vector = start;
extern ifunc ivects[];
ivects[i] = dummy_handler;
memcpy(ivects+1, ivects, 63*4);
if (...)
ivects[A0_VEC] = timer_a0_handler;
if (...)
ivects[A1_VEC] = timer_a1_handler;
It seems like there are plenty of examples of OSs which would benefit
from an easy way to manage nondefault pointer sizes, even if we can't
use them for everything a default pointer can be used for.
RE: GCC 3.4.5 has been released
Is this version for windows or linux? Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: > >I'm pleased to announce that GCC 3.4.5 has been released. > > This version is a minor release, from the 3.4.x series, fixing >regressions with respect to previous versions of GCC. It can be >downloaded from the FTP servers listed here > > http://www.gnu.org/order/ftp.html > >A list of known fixed bugs is available from here > > > http://gcc.gnu.org/gcc-3.4/changes.html > > > Many thanks to GCC contributors who made this release possible. > >-- > Gabriel Dos Reis > [EMAIL PROTECTED] > __ Switch to Netscape Internet Service. As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register Netscape. Just the Net You Need. New! Netscape Toolbar for Internet Explorer Search from anywhere on the Web and block those annoying pop-ups. Download now at http://channels.netscape.com/ns/search/install.jsp
Re: GCC 3.4.5 has been released
> All the above and more. It is a source release of GCC. -- Pinski
incorrect semantics of 'using'
Hi,
for the following test case:
struct A {
virtual int x () {return 1;}
};
struct B: A {
virtual int x () {return 0;}
};
struct C: B{
using A::x;
};
int main()
{
C c;
return c.x();
}
all g++ 4.x will return 1
It seems C++ standard would want to see 0.
Using-declaration introduces the virtual method x() in the class C and
it's supposed to stay 'virtual', whereas g++ seems to treat it as it overrides
the B's method. In other words using-declaration should effectively be
ignored in this case.
Alex.
Re: building gcc 4.1.1 on HP-UX 10.20
> > Bug reports should be filed for these two problems. Do you have > > PHCO_20721 and PHCO_26158 installed? Locale might the behavior > > of awk in generating options.h. > > I have PHCO_20721 installed, but not PHCO_26158. And I just wasted > about a half hour of my life trying to *find* it. It seems that HP > has not only stopped writing patches for HP-UX 10.20 (which is fine, > understandable) but has also removed them all from their machines. > I haven't tried the Bit Torrent networks yet :-/ It seems that patches for old hardware are not currently available via ftp access. If you get an ITRC account, there is a link from the patch database page to archived patches for older hardware and software. I see that PHCO_31920 was actually the last libc patch for HP-UX 10.20. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Wannabe Contributor: Questions related to Dev Box setup and other issues
Hi, I guess will refer me to read the web site. While I am doing that, I am not clear about my issue. It goes.. I want to contribute to GCC dev and I will start at basic projects for beginners. While I am setting up my dev box for GCC work, I want to know? 1) Any advise on selecting Linux distro? I know its based on preference but is there any specific distro having advantage towards GCC dev related requirement? 2) The requirement+howto list for GCC installation seemed toward user of GCC (who will compile developed apps for a specific target). My understanding is that if I make changes to GCC code itself then I will need to make sure that the change is OK for all target platform where GCC can be compiled and used. How will I ensure that while sitting on a specific platform? What are the tools / env setup required for this? 3) Do I need to follow any formal procedure to start on a contribution item? like expressing interest, getting the project assigned etc? Also if I want to start with deleting garbage code where most of the module owners will be needed to be in closed loop how can I go about it? I will stop here for now. Don't want to make it too much in first go :P Thanks. -- Soyuz On Yahoo!7 The new Yahoo!7 home page - scan your email inbox, start an IM conversation or update your blog http://au.yahoo.com/
Re: Wannabe Contributor: Questions related to Dev Box setup and other issues
On Aug 15, 2006, at 6:11 PM, Mahafuzur Rahaman wrote: 1) Any advise on selecting Linux distro? This is akin to asking ones religion. :-) We generally don't push religion around here... gnu.misc.discuss would be the usual place to discuss religious questions. Just select one and follow it, oops, I mean, load it... You didn't ask what editor, but, be sure to use emacs. :-) I will need to make sure that the change is OK for all target platform where GCC can be compiled and used. How will I ensure that while sitting on a specific platform? You gotta use your brain here. It helps if you have experience writing portable code. For example, if you want to add a #include <>, don't, unless it is already included in another file of the same class. If you want to anyway, you'll have to know if it is portable and how to use autoconf if not. In the end, you'll write it, submit it, and others will let you know if it is (was) portable. For example, we run a builder on darwin that just checks out the top of the tree and builds it, and loops. If you break it, it will stop working and people will eventually track it down to you. 3) Do I need to follow any formal procedure to start on a contribution item? No. Though, letting people know you're going to start working on item X is at times nice. Others might have pointers/tip/tricks/code to share. Also if I want to start with deleting garbage code where most of the module owners will be needed to be in closed loop how can I go about it? We don't have any garbage code in gcc... ;-) Just submit the patches as normal. If you want a more experienced person to review your plan, share the plan on the gcc list first.
Re: Wannabe Contributor: Questions related to Dev Box setup and other issues
> 1) Any advise on selecting Linux distro? Any one will do. Or Windows, MS-DOS, AIX, IRIX, Solaris, Mac OS/X, or any other platform GCC runs on. Use whatever you're comfortable with.
Re: GCC 3.4.5 has been released
[EMAIL PROTECTED] writes: | Is this version for windows or linux? this is not a binary release; it is source release. -- Gaby
Wannabe Contributor: My plan + Need guidance
Thanks DJ & Mike for your quick replies. This is to summarise my plan so that others can guide/help me. Considering that GCC has no garbage code (Right? Mike!) I would like to rephrase my task as removing dead code, unwanted code, any fat that we can get rid of from the source tree .. [Somebody should change the "Delete garbage" statement on the simple GCC projects ;) ] I will appreciate all the pointers in line of what can be removed. Since its the start I want to focus on the "absolute sure" ones like (#if 0, if they are still there or likes). But please feel free to provide anything that you have in mind. My primary goal from this task is to get to know GCC and its source tree. I hope to get some partners on this. I will try to setup a web location to dump the task items so that we can accumulate and list them. Having said my plan, I want to add that, at the start its gonna be slow in terms of output considering the learning curve and getting my time table adjusted. Thanks, Soyuz Do you Yahoo!? Check out gigs in your area on the comprehensive Yahoo! Music Gig Guide http://au.music.yahoo.com/gig-guide
Re: Wannabe Contributor: Questions related to Dev Box setup and other issues
On Tue, 15 Aug 2006, Mike Stump wrote: > On Aug 15, 2006, at 6:11 PM, Mahafuzur Rahaman wrote: > > 1) Any advise on selecting Linux distro? > > This is akin to asking ones religion. :-) We generally don't push > religion around here... gnu.misc.discuss would be the usual place to > discuss religious questions. Just select one and follow it, oops, I > mean, load it... > > You didn't ask what editor, but, be sure to use emacs. :-) that's a religion too... :( -- ~Randy
Re: Wannabe Contributor: Questions related to Dev Box setup and other issues
> 1) Any advise on selecting Linux distro? Any one will do. Or Windows, MS-DOS, AIX, IRIX, Solaris, Mac OS/X, or any other platform GCC runs on. Use whatever you're comfortable with. But note that on Windows (Cygwin) GCC testsuite runs several orders of magnitude slower than on Linux: it literally takes days to complete... -- Laurynas
Re: define_expand
(define_expand "negsf2" [(set (match_operand:SF 0 "gpc_reg_operand" "") (neg:SF (match_operand:SF 1 "gpc_reg_operand" "")))] "TARGET_HARD_FLOAT" "") (define_insn "*negsf2" [(set (match_operand:SF 0 "gpc_reg_operand" "=f") (neg:SF (match_operand:SF 1 "gpc_reg_operand" "f")))] "TARGET_HARD_FLOAT && TARGET_FPRS" "fneg %0,%1" [(set_attr "type" "fp")]) I've read the docs (sect 13.15) which describe define_expand, but I have a feeling that I'm missing something that would make it clear how these two templates interact. Clearly, the define_insn template says that when the insn pattern is found, generate the "fneg" instruction. What is the define_expand template doing? You are missing another template, which is used on the E500 (see spe.md). This has a condition of "TARGET_HARD_FLOAT && !TARGET_FPRS". (define_insn "*negsf2_gpr" [(set (match_operand:SF 0 "gpc_reg_operand" "=r") (neg:SF (match_operand:SF 1 "gpc_reg_operand" "r")))] "TARGET_HARD_FLOAT && !TARGET_FPRS" "efsneg %0,%1" [(set_attr "type" "fpsimple")]) We need a define_expand to generate the RTL, and two define_insns to emit different code depending on the actual subtarget. Paolo
