Re: Does TYPE_MAX_VALUE (size_type_node) overflow?
On Thu, Jan 20, 2011 at 9:50 PM, Florian Weimer wrote:
> * Richard Guenther:
>
>> On Wed, Jan 19, 2011 at 10:53 PM, Florian Weimer wrote:
>>> I get strange warnings when I do arithmetic involving TYPE_MAX_VALUE
>>> (size_type_node), in particular this code:
>>>
>>> /* Multiplies MUL1 with MUL2, and adds ADD. Returns (size_t)-1 if the
>>> result cannot be be represented as a size_t value. If ADD is
>>> null_tree, treat it as a zero constant.
>>> */
>>> tree
>>> build_size_mult_saturated (tree mul1, tree mul2, tree add)
>>> {
>>> tree max_mul1, result;
>>> max_mul1 = TYPE_MAX_VALUE (size_type_node);
>>> if (add != NULL_TREE)
>>> max_mul1 = size_binop(MINUS_EXPR, max_mul1, add);
>>> max_mul1 = size_binop(TRUNC_DIV_EXPR, max_mul1, mul2);
>>> result = size_binop (MULT_EXPR, mul1, mul2);
>>> if (add != NULL_TREE)
>>> result = size_binop (PLUS_EXPR, result, add);
>>> return build3 (COND_EXPR, sizetype,
>>> build2 (EQ_EXPR, sizetype, mul2, size_zero_node),
>>> add == NULL_TREE ? size_zero_node : add,
>>> build3 (COND_EXPR, sizetype,
>>> build2 (LE_EXPR, sizetype, mul1, max_mul1),
>>> result, TYPE_MAX_VALUE (size_type_node)));
>>> }
>>>
>>> Is size_type_node really signed, and does TYPE_MAX_VALUE
>>> (size_type_node) lie outside the representable range? Is there an
>>> easy way to get a GCC type closely matching size_t in C++?
>>
>> The size_* functions are supposed to be used with sizetype,
>> not with size_type ;) sizetypes are strange beast.
>
> Thanks for the suggestion. TYPE_MAX_VALUE (sizetype) appears to be
> -1, as the result of this code in stor-layout.c:
>
> /* sizetype is unsigned but we need to fix TYPE_MAX_VALUE so that it is
> sign-extended in a way consistent with force_fit_type. */
> max = TYPE_MAX_VALUE (sizetype);
> TYPE_MAX_VALUE (sizetype)
> = double_int_to_tree (sizetype, tree_to_double_int (max));
>
> Is there a way to obtain the actual maximum value?
It is the actual (sign-extended) maximum value (sizetype values are
always sign-extended). zero-extending the value gives you the "real"
maximum
value.
Richard.
Turn on -funroll-loops at -O3?
Hi, SInce -O3 turns on vectorizer, should it also turn on -funroll-loops? -- H.J.
Re: Turn on -funroll-loops at -O3?
On Fri, Jan 21, 2011 at 7:43 PM, H.J. Lu wrote: > Hi, > > SInce -O3 turns on vectorizer, should it also turn on > -funroll-loops? We need to split the tree and RTL effects of -funroll-loops (and -fpeel-loops). -funroll-loops can at the moment lead to unneccessary code bloat. But yes, something to consider for 4.7. Richard. > -- > H.J. >
Backporting the 4.5 plugin framework to 3.4.5
Hello, I currently have a plugin for gcc 4.5 that works great. However, the need has arisen to have the same plugin run on gcc 3.4.5. Knowing that the plugin api wasn't added until 4.5 I was wondering if anyone could tell me how much pain i would be in for if I attempt to backport the plugin api to gcc 3.4.5. Is it even possible or are 3.X.X and 4.5.X so different that it shouldn't even be attempted. Do I just have to insert call backs in a bunch of places or do I have to get way deeper in the guts of gcc to retrieve the same data as I can get in gcc 4.5? Cheers, Kyle
Re: Strangeness with SSE(1)
Can somebody please explain the behavior of the following program
to me?
cat >test.c <
#include
#include
int main(void){
register __m128 var;
fprintf(stdout,"pre %X\n",var);
var = _mm_setzero_ps();
fprintf(stdout,"post %X\n",var);
fprintf(stdout,"zerof %X\n",0.0f);
exit(EXIT_SUCCESS);
}
EOD
gcc -O0 -g -std=gnu99 -msse -mno-sse2 -m32 -o test test.c
./test
pre FFC5FC98
post FFC5FC98
zerof 0
gcc --version
gcc (GCC) 4.4.1
Now I know that var is 16 bytes, not 4, so the %X isn't appropriate to
show all of it, but apparently it doesn't show any of it, since any 4
bytes out of the 16 should have been 0.
Plus if this is run in valgrind there are
Conditional jump or move depends on uninitialised value(s)
at both of the print statements that access var.
Adding -Wall
test.c:7: warning: format '%X' expects type 'unsigned int', but argument
3 has type '__m128'
test.c:9: warning: format '%X' expects type 'unsigned int', but argument
3 has type '__m128'
test.c:10: warning: format '%X' expects type 'unsigned int', but
argument 3 has type 'double'
test.c:7: warning: 'var' is used uninitialized in this function
But the last one goes away if the first fprintf is commented out. So
gcc passes _something_ for var to fprintf, but what?
Thanks,
David Mathog
mat...@caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech
Re: Backporting the 4.5 plugin framework to 3.4.5
On 1/21/2011 4:12 PM, Kyle Girard wrote: Hello, I currently have a plugin for gcc 4.5 that works great. However, the need has arisen to have the same plugin run on gcc 3.4.5. Knowing that the plugin api wasn't added until 4.5 I was wondering if anyone could tell me how much pain i would be in for if I attempt to backport the plugin api to gcc 3.4.5. Is it even possible or are 3.X.X and 4.5.X so different that it shouldn't even be attempted. It should not be attempted. The differences between GCC 4.3 and 4.5 are already very difficult to deal with. Going all the way back to GCC 3.4, which has a very different tree structure in places, is really not a worthwhile effort. --BDS
Re: Turn on -funroll-loops at -O3?
On 1/21/2011 10:43 AM, H.J. Lu wrote: Hi, SInce -O3 turns on vectorizer, should it also turn on -funroll-loops? Only if a conservative default value for max-unroll-times is set 2<= value <= 4 -- Tim Prince
Re: Strangeness with SSE(1)
"David Mathog" writes:
> Can somebody please explain the behavior of the following program
> to me?
This question is not appropriate for the gcc@gcc.gnu.org mailing list,
which is for the development of gcc itself. It would be appropriate on
gcc-h...@gcc.gnu.org. Please take any followups to gcc-help. Thanks.
> cat >test.c < #include
> #include
> #include
>
> int main(void){
> register __m128 var;
> fprintf(stdout,"pre %X\n",var);
> var = _mm_setzero_ps();
> fprintf(stdout,"post %X\n",var);
> fprintf(stdout,"zerof %X\n",0.0f);
> exit(EXIT_SUCCESS);
> }
> EOD
> gcc -O0 -g -std=gnu99 -msse -mno-sse2 -m32 -o test test.c
> ./test
> pre FFC5FC98
> post FFC5FC98
> zerof 0
>
>
> gcc --version
> gcc (GCC) 4.4.1
>
> Now I know that var is 16 bytes, not 4, so the %X isn't appropriate to
> show all of it, but apparently it doesn't show any of it, since any 4
> bytes out of the 16 should have been 0.
SSE variables are passed in xmm registers. %X prints an unsigned int
value; unsigned int values are passed in regular registers. The %X is
seeing random garbage, it's not seeing the variable you are passing.
Ian
[pph] Merge from trunk r169107
I've merged trunk rev 169107 into the pph branch. No new failures. Lawrence, you will probably find little/no merge conflicts with your timevar patch. Diego.
