request of copyright assignment form
HI all. Could someone please send me the "copyright assignment form"? Thanks. Daniel
Re: Source code of CIL back-end
Paolo Bonzini wrote: The SC discussed it with Richard Stallman, and he agrees that it is not "dangerous" (the FSF had raised objections to byte-code systems in the past, so many of us assumed there would be a problem). So there is no political/legal objection to including a CIL back end. If it passes technical review, it can be included. Hello, Thanks for the answer, this is great news! It is indeed. It's good to see GCC moving forward on these aspects! We have to start working on the paperwork. Could anybody point us at the relevant forms for the copyright assignment? I am almost sure that you do not need that, because ST Microelectronics has an assignment for many projects including GCC. But just in case, please wait for a confirmation. If you want to assign copyright personally to FSF, it would mean that you could keep working on GCC (in the FSF repository) even if you leave ST. If that is the case, just ask for the relevant forms. My understanding is that the next step is the creation of a development branch. Is it dependent on the paperwork, or can it be done in parallel? It is dependent on the paperwork. However, as I said, I am almost sure that your employer took care of that for you. As soon as somebody confirms that no further paperwork is necessary, you can create the branch. Paolo It turns out that Paolo was right. The Copyright clerk confirmed to me that ST already has the following assignment on file: GCC STMicroelectronics 2004-11-02 Assigns past and future changes. Thanks for letting us know. -- Erven.
gcc 4.2 more strict check for "function called through a non-compatible type"
Compiling openssl-0.9.8b with gcc-4.2 snapshots, I found gcc 4.2
fortifies its check for function pointer conversion and generates
abort for PEM_read_X509_AUX() and similar wrappers.
There was an old discussion about casting pointer to function
issue - "Why does casting a function generate a run-time abort?",
see http://gcc.gnu.org/ml/gcc/2004-06/msg01017.html
While understanding the reasoning of gcc develepers to catch
unportable code earlier, I want to rise question again in a hope
it would be useful to think of the whole issue again.
First of all, I did not find an answer why among many ways to shoot
yourself in a portability foot gcc chooses to fight so seriously
this particular case - function pointer conversions (it generates
runtime abort instead of function call). In a modern C world,
there are many portability issues triggered by undefined behavior
that can be detected at compile time. Is it feasible to generate
abort() for famous "a[i] = i++" code? For incompatible data pointer
conversion? For possible int types size mismatch? For non-portable
varargs manipulations?
Historically in C it was possible to workaround portability issues
in highly platform-dependent code with various #ifdef tricks -
selection of right snippet for target platform was in programmers
hand for well-written code. By generating runtime abort
unconditionally in a tricky case, we prevent a programmer from
using C as a "high level assembler" to write platform-dependent
code like threads/co-routines/message dispatcher libraries -
remember objective-c runtime.
Second, even with all that efforts put in guarding against
function pointer conversion, they failed to catch all cases.
Supposedly it is due to C language abstract machine philosophy -
it allows programmer to see target machine data and address
types. Unless C pointers goes far away from cpu-dependant
address, there should be impossible to catch all cases.
But that language will not be C language.
Consider the following code snippet, we see different
behavior from various gcc versions:
- cast_direct() generates abort since one of 3.x versions
- cast_via_void_fptr() still works with 4.1 but aborts with 4.2
- cast_via_assignment() works for 4.2 too
- cast_via_union() works and I suppose it should be a legally C
- cast_via_memcpy()... I did not bother to write it but you
see it is just another *legally* way to knowingly shoot compiler
check in a foot.
So it is still possible to generate call sequence with casted type despite
additional barriers from the 4.2 compiler.
Isn't it better to stop trying unstoppable ways of using C?
For example, in that particular openssl case introducing
runtime abort resulted in a following check-in from
openssl develepors:
"[13329]: Some C compilers produce warnings or compilation errors
if an attempt is made to directly cast a function of one type to what
it considers and incompatible type. In particular gcc 3.4.2.
Add new openssl_fcast macro to place functions into a form
where the compiler will allow them to be cast. "
Notice! You did not archive your goal - making programmers
writing portable code. Instead, they put a workaround against
your particular compiler, insisting on doing things in a way
they like.
With gcc 4.2 stricter check going in release, I foresee another
check-in, to cast via assign, union or other *workaround*.
To prevent that ridiculous compiler vs develepers war,
my proposition is:
At least revert back 4.2 conversion behavior to 4.1 behavior:
i.e. warn about direct function pointer conversion but
allow casts via void_fptr. That catches most illegal unintentional
code but allow people to use explisit type conversions for saying
compiler that they know that they do (for example, casting
const void* argument to void * agrument - that should
safe for all possible targets, I think).
At most, revert back even 3.4.2 introduced behavior and
do not generate illegal insn for warned suspicious conversion
but generate casted type function call as usual.
It is just impractical to make artificial barriers for
some undefined behavior while leaving others intact.
Abort for all undefined behavior - that is not a C way, too.
By the way, portability warnings should be just warnings.
To summarize my opinion let me say that in guarding programmer
against undefined behavior current gcc made some steps in
a particular way. But the whole direction is wrong - when it will
be completed, we will have gcc be a compiler for other language then C.
Fortunately, for now that way is incomplete. ;)
here is a sample code
typedef void (*void_fptr) (void);
int foo (void * a) { return 0; }
int cast_direct(void)
{
return (((int (*) (const void *)) foo) (0));
}
int cast_via_void_fptr(void)
{
return (((int (*) (const void *)) ((void_fptr) foo)) (0));
}
int cast_via_assignment(void)
{
int (*bar) (const void *) = (int (*) (const void *))foo;
return bar (0);
}
int cast_via_union(void)
{
union {
int (*foo)
bootstrap failed during 'make check'
Revision: 115174 build/host/target: i686-pc-linux-gnu # This directory was configured as follows, # on host linsvr6: # # ../srcw/configure --with-arch=i686 --disable-gdb --enable-languages=c,c++,ja va,objc make[3]: Leaving directory `/mnt/scratch/nightly/2006-07-04/i686' Comparing stages 2 and 3 warning: ./cc1-checksum.o differs warning: ./cc1plus-checksum.o differs warning: ./cc1obj-checksum.o differs Bootstrap comparison failure! ./cfg.o differs ./cfgloopanal.o differs ./loop-iv.o differs ./predict.o differs ./profile.o differs ./value-prof.o differs ./ipa-inline.o differs make[2]: *** [compare] Error 1 make[2]: Leaving directory `/mnt/scratch/nightly/2006-07-04/i686' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/mnt/scratch/nightly/2006-07-04/i686' make: *** [bootstrap] Error 2
Re: gcc 4.2 more strict check for "function called through a non-compatible type"
Yuri Pudgorodsky <[EMAIL PROTECTED]> writes: > Compiling openssl-0.9.8b with gcc-4.2 snapshots, I found gcc 4.2 > fortifies its check for function pointer conversion and generates > abort for PEM_read_X509_AUX() and similar wrappers. Personally speaking, I agree with you that the compiler should issue a warning and then go ahead and compile the call. I don't think we gain anything useful by compiling a runtime abort in this case. The spirit of C is to let the user shoot themselves in the foot if they really want to. Any contrary opinions? Ian
Re: bootstrap failed during 'make check'
> Revision: 115174 > > build/host/target: i686-pc-linux-gnu > > make[3]: Leaving directory `/mnt/scratch/nightly/2006-07-04/i686' > Comparing stages 2 and 3 > warning: ./cc1-checksum.o differs > warning: ./cc1plus-checksum.o differs > warning: ./cc1obj-checksum.o differs > Bootstrap comparison failure! That might be my SRA patch (revision 115160) although it bootstraps fine for me on i586 and for Joe on i686: http://gcc.gnu.org/ml/gcc-testresults/2006-07/msg00157.html On the other hand, I now get tons of failures in libjava on x86-64 while Andreas' testsuite is clean: http://gcc.gnu.org/ml/gcc-testresults/2006-07/msg00164.html Not sure what's going on exactly... -- Eric Botcazou
Re: gcc 4.2 more strict check for "function called through a non-compatible type"
Ian Lance Taylor writes: > Yuri Pudgorodsky <[EMAIL PROTECTED]> writes: > > > Compiling openssl-0.9.8b with gcc-4.2 snapshots, I found gcc 4.2 > > fortifies its check for function pointer conversion and generates > > abort for PEM_read_X509_AUX() and similar wrappers. > > Personally speaking, I agree with you that the compiler should issue a > warning and then go ahead and compile the call. I don't think we gain > anything useful by compiling a runtime abort in this case. The spirit > of C is to let the user shoot themselves in the foot if they really > want to. > > Any contrary opinions? The answer is here: keating> Because if you *do* try to inline the call, you will get an ICE. We could allow this iff someone fixes the ICE. But we've provided a union cast to do the work if it's *really* needed; insn't that enough? Andrew.
dejaGNU testsuite files for 2.95.3 20010315 (release)
Hi folks, Im involved in testing some old stuff about gcc 2.95.3 for an specific arch and i realize after looking at gcc.gnu.org that there are not the corresponding test cases for dejaGNU fw (testsuite folder), to be more precise there is not a testsuite folder at http://gcc.gnu.org/viewcvs/tags/gcc-2_95_3/ Please, does anybody knows where i can get them? Actually im using the last release testsuite files i found prior the noted release, iow, testsuite for release 2.95.2.1 at gnu. Thanks all IA Jose.
Re: bootstrap failed during 'make check'
Eric Botcazou wrote: Not sure what's going on exactly... The machines I use have the 'security enhancement' enabled which makes addresses vary between program invocations. So if code generation depends on pointer values at any point, this will cause varying behaviour. A common mistake is to hash on pointers, and do a hash table traversal where the ordering matters. Or doing a quicksort with a missing or address-based tie-breaker.
Re: bootstrap failed during 'make check'
Joern Rennecke wrote: Eric Botcazou wrote: Not sure what's going on exactly... The machines I use have the 'security enhancement' enabled which makes addresses vary between program invocations. So if code generation depends on pointer values at any point, this will cause varying behaviour. Hmm, I've tried re-building cfg.o by hand, and stage1 produces consistently a smaller cfg.o than stage2. So this doesn't seem to be related to random pointers. Are you using --with-arch=i686 ?
Re: bootstrap failed during 'make check'
Eric Botcazou wrote:
Not sure what's going on exactly...
Using -fdump-unnumbered dumps, I find the first significant difference
in 144r.peephole2:
13868a13869,13880
> (set (reg:SI 2 cx)
> (ior:SI (ashiftrt:SI (reg:SI 2 cx)
> (const_int 1 [0x1]))
> (ashift:SI (reg:SI 3 bx [+4 ])
> (minus:QI (const_int 32 [0x20])
> (const_int 1 [0x1])
> (clobber (reg:CC 17 flags))
> ])# (nil)
> (expr_list:REG_UNUSED (reg:CC 17 flags)
> (nil)))
>
> (insn# # # 2 ../../srcw/gcc/cfg.c:980 (parallel [
13897a13910,13921
> (set (reg:SI 1 dx [+4 ])
> (ior:SI (ashift:SI (reg:SI 1 dx [+4 ])
> (const_int 16 [0x10]))
> (lshiftrt:SI (reg:SI 0 ax [94])
> (minus:QI (const_int 32 [0x20])
> (const_int 16 [0x10])
> (clobber (reg:CC 17 flags))
> ])# (nil)
> (expr_list:REG_UNUSED (reg:CC 17 flags)
> (nil)))
>
> (insn# # # 2 ../../srcw/gcc/cfg.c:980 (parallel [
14792a14817,14828
> (set (reg:SI 0 ax [123])
> (ior:SI (ashiftrt:SI (reg:SI 0 ax [123])
> (const_int 16 [0x10]))
> (ashift:SI (reg:SI 1 dx [+4 ])
> (minus:QI (const_int 32 [0x20])
> (const_int 16 [0x10])
> (clobber (reg:CC 17 flags))
> ])# (nil)
> (expr_list:REG_UNUSED (reg:CC 17 flags)
> (nil)))
>
> (insn# # # 15 ../../srcw/gcc/cfg.c:992 (parallel [
15244a15281,15292
> (set (reg:SI 0 ax [147])
> (ior:SI (ashiftrt:SI (reg:SI 0 ax [147])
> (const_int 16 [0x10]))
> (ashift:SI (reg:SI 1 dx [+4 ])
> (minus:QI (const_int 32 [0x20])
> (const_int 16 [0x10])
> (clobber (reg:CC 17 flags))
> ])# (nil)
> (expr_list:REG_UNUSED (reg:CC 17 flags)
> (nil)))
>
> (insn# # # 19 ../../srcw/gcc/cfg.c:997 (parallel [
16008a16057,16068
> (set (reg:SI 0 ax [172])
> (ior:SI (ashiftrt:SI (reg:SI 0 ax [172])
> (const_int 16 [0x10]))
> (ashift:SI (reg:SI 1 dx [+4 ])
> (minus:QI (const_int 32 [0x20])
> (const_int 16 [0x10])
> (clobber (reg:CC 17 flags))
> ])# (nil)
> (expr_list:REG_UNUSED (reg:CC 17 flags)
> (nil)))
>
> (insn# # # 38 ../../srcw/gcc/cfg.c:1007 (parallel [
16587a16648,16659
> (set (reg:SI 0 ax [187])
> (ior:SI (ashiftrt:SI (reg:SI 0 ax [187])
> (const_int 16 [0x10]))
> (ashift:SI (reg:SI 1 dx [+4 ])
> (minus:QI (const_int 32 [0x20])
> (const_int 16 [0x10])
> (clobber (reg:CC 17 flags))
> ])# (nil)
> (expr_list:REG_UNUSED (reg:CC 17 flags)
> (nil)))
>
> (insn# # # 51 ../../srcw/gcc/cfg.c:1009 (parallel [
19776c19848
< (symbol_ref/f:SI ("*.LC28") [flags 0x2] ))#
{*movsi_1} (nil)
---
> (symbol_ref/f:SI ("*.LC28") [flags 0x2] ))#
> {*movsi_1} (nil)
20134c20206
< (symbol_ref/f:SI ("*.LC30") [flags 0x2] ))#
{*movsi_1} (nil)
---
> (symbol_ref/f:SI ("*.LC30") [flags 0x2] ))#
> {*movsi_1} (nil)
20463c20535
< (symbol_ref/f:SI ("*.LC31") [flags 0x2] ))#
{*movsi_1} (nil)
---
> (symbol_ref/f:SI ("*.LC31") [flags 0x2] ))#
> {*movsi_1} (nil)
Re: gcc 4.2 more strict check for "function called through a non-compatible type"
Andrew Haley <[EMAIL PROTECTED]> writes: > Ian Lance Taylor writes: > > Yuri Pudgorodsky <[EMAIL PROTECTED]> writes: > > > > > Compiling openssl-0.9.8b with gcc-4.2 snapshots, I found gcc 4.2 > > > fortifies its check for function pointer conversion and generates > > > abort for PEM_read_X509_AUX() and similar wrappers. > > > > Personally speaking, I agree with you that the compiler should issue a > > warning and then go ahead and compile the call. I don't think we gain > > anything useful by compiling a runtime abort in this case. The spirit > > of C is to let the user shoot themselves in the foot if they really > > want to. > > > > Any contrary opinions? > > The answer is here: > > keating> Because if you *do* try to inline the call, you will get an ICE. Yes, I agree that the ICE, if it still exists, would have to be fixed, but to me that seems like a separate issue. > We could allow this iff someone fixes the ICE. But we've provided a > union cast to do the work if it's *really* needed; insn't that enough? I don't think gcc should go down the path of inserting trap calls for all undefined code. That is reasonable if there is nothing else that can be done. But in this case there is something easy to do: compile the function call as directed. I'm all for interpreting undefined code such that we can apply better optimizations, but that is not the case here. We aren't optimizing by inserting a trap in this case; we're just breaking code gratuitously. Ian
Re: dejaGNU testsuite files for 2.95.3 20010315 (release)
On Jul 4, 2006, at 10:58 AM, J.J.Garcia wrote: Im involved in testing some old stuff about gcc 2.95.3 for an specific arch and i realize after looking at gcc.gnu.org that there are not the corresponding test cases for dejaGNU Please, does anybody knows where i can get them? Actually im using the last release testsuite files i found prior the noted release, iow, testsuite for release 2.95.2.1 at gnu. svn ls -r40553 svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-2_95-branch/ gcc/testsuite appears to be fairly close. Don't know why the tag was messed up. This number comes from the tags/gcc-2_95_3 tag.
Re: bootstrap failed during 'make check'
> Are you using --with-arch=i686 ? Yes, I cannot reproduce the bootstrap failure with [EMAIL PROTECTED]:~/build/gcc/native32> gcc/xgcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /home/eric/svn/gcc/configure i686-pc-linux-gnu --prefix=/home/eric/install/gcc --with-as=/usr/i586-suse-linux/bin/as --with-ld=/usr/i586-suse-linux/bin/ld --with-arch=i686 --enable-languages=c,c++,objc,java Thread model: posix gcc version 4.2.0 20060703 (experimental at revision 115172. -- Eric Botcazou
Re: gcc 4.2 more strict check for "function called through a non-compatible type"
So that ICE still exist for objective-c and is just hidden with
warn/trap workaround
for c/c++:
double foo(double arg)
{
return arg;
}
int bar(int d)
{
d = ((int (*) (int)) foo)(d);
return d *d;
}
If you compile the above example in objective-c mode (gcc -O3 -x
objective-c),
current mainline as well as all 3.4.2 ... 4.1 versions hits an ICE:
[EMAIL PROTECTED] ~/tmp $ gcc-4.2 -O3 -x objective-c bbb1.c -S
bbb1.c: In function 'bar':
bbb1.c:8: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugs.gentoo.org/> for instructions.
Preprocessed source stored into /tmp/ccO8k5QS.out file, please attach
this to your bugreport.
[EMAIL PROTECTED] ~/tmp $ gcc-3.4.5 -O3 -x objective-c bbb1.c -S
bbb1.c: In function `bar':
bbb1.c:3: internal compiler error: in convert_move, at expr.c:564
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugs.gentoo.org/> for instructions.
Preprocessed source stored into /tmp/ccj3pUVx.out file, please attach
this to your bugreport.
Original PR/12085 fix was proposed to simply not inline function call:
http://gcc.gnu.org/ml/gcc-patches/2003-12/msg00683.html.
2003-12-07 Eric Botcazou <[EMAIL PROTECTED]>
PR optimization/12085
* tree-inline.c (expand_call_inline): Do not inline functions at
calling points where they are viewed with too different a prototype
than the actual one.
But later it has been changed to warn/trap for c/c++ mode, leaving ICE
for objc intact:
http://gcc.gnu.org/ml/gcc-patches/2003-12/msg01767.html
2003-12-19 Eric Botcazou <[EMAIL PROTECTED]>
PR c/12085
* c-typeck.c (build_function_call): Issue a warning if a
function is called through an incompatible prototype and
replace the call by a trap in this case.
May be it's time to implement better fix for that ICE than generating
trap instead of actual call
for all (even valid on a particular platform) function pointer conversions?
Can someone make the decision to reopen PR optimization/12085?
Re: gcc 4.2 more strict check for "function called through a non-compatible type"
On Jul 4, 2006, at 5:07 PM, Yuri Pudgorodsky wrote: Can someone make the decision to reopen PR optimization/12085? And I posted a patch to do the same in Objective-C mode as C mode :). http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01013.html -- Pinski
Does SIMD optimization of GCC 3.4.6 work?
Hello GCC list: I am wondering if i have used -O, -O2 or -O3, do i still benifit from flags such as -march -fmpmath -ffast-math -mmx -sse -sse2 -3dnow? I am optimizing a video codec and i see barely any performance difference whether i use just -O2 or "-ffast-math -march=athlon-xp -mmmx -msse -msse2 -m3dnow -mfpmath=sse,387 -O3". The codec is at http://www.sourceforge.net/projects/openavs/. Currently, it requires a 3Ghz or better CPU to get a resonable framerate. I would like the codec to be useful even on 586 ( 1Ghz or so ). Any ideas? Regards Lionel __ 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: bootstrap failed during 'make check'
> That might be my SRA patch (revision 115160) although it bootstraps fine > for me on i586 and for Joe on i686: > http://gcc.gnu.org/ml/gcc-testresults/2006-07/msg00157.html Or might not because... > On the other hand, I now get tons of failures in libjava on x86-64 while > Andreas' testsuite is clean: > http://gcc.gnu.org/ml/gcc-testresults/2006-07/msg00164.html ... I get the tons of failures in libjava at rev 115159 too! -- Eric Botcazou
Re: bootstrap failed during 'make check'
On Jul 4, 2006, at 8:35 PM, Eric Botcazou wrote: On the other hand, I now get tons of failures in libjava on x86-64 while Andreas' testsuite is clean: http://gcc.gnu.org/ml/gcc-testresults/2006-07/msg00164.html ... I get the tons of failures in libjava at rev 115159 too! Those should be fixed by rev 115181 and 115188. I no longer get any libjava failures on i686-linux-gnu now. -- Pinski
Re: bootstrap failed during 'make check'
> make[3]: Leaving directory `/mnt/scratch/nightly/2006-07-04/i686'
> Comparing stages 2 and 3
> warning: ./cc1-checksum.o differs
> warning: ./cc1plus-checksum.o differs
> warning: ./cc1obj-checksum.o differs
> Bootstrap comparison failure!
Does the attached patch make any difference?
--
Eric Botcazou
Index: tree-sra.c
===
--- tree-sra.c (revision 115175)
+++ tree-sra.c (working copy)
@@ -579,6 +579,69 @@ lookup_element (struct sra_elt *parent,
return elt;
}
+/* Return true if [MIN, MAX] is a valid range for ARRAY, an ARRAY_TYPE. */
+
+static bool
+is_valid_array_range (tree min, tree max, tree array)
+{
+ tree t, dom = TYPE_DOMAIN (array);
+
+ /* Watch out for stupid user tricks, indexing outside the array.
+
+ Careful, we're not called only on scalarizable types, so do not
+ assume constant array bounds. We needn't do anything with such
+ cases, since they'll be referring to objects that we should have
+ already rejected for scalarization, so returning false is fine. */
+
+ if (dom == NULL)
+return false;
+
+ t = TYPE_MIN_VALUE (dom);
+ if (!t || TREE_CODE (t) != INTEGER_CST)
+return false;
+ if (tree_int_cst_lt (min, t))
+return false;
+
+ t = TYPE_MAX_VALUE (dom);
+ if (!t || TREE_CODE (t) != INTEGER_CST)
+return false;
+ if (tree_int_cst_lt (t, max))
+return false;
+
+ return true;
+}
+
+/* Return true if the ARRAY_REF in EXPR is a constant, in bounds access. */
+
+static bool
+is_valid_const_index (tree expr)
+{
+ tree idx = TREE_OPERAND (expr, 1);
+
+ if (TREE_CODE (idx) != INTEGER_CST)
+return false;
+
+ return is_valid_array_range (idx, idx, TREE_TYPE (TREE_OPERAND (expr, 0)));
+}
+
+/* Same as above, but for an ARRAY_RANGE_REF. */
+
+static bool
+is_valid_const_range (tree expr)
+{
+ tree min, max, range_type = TYPE_DOMAIN (TREE_TYPE (expr));
+
+ min = TYPE_MIN_VALUE (range_type);
+ max = TYPE_MAX_VALUE (range_type);
+ if (!min
+ || !max
+ || TREE_CODE (min) != INTEGER_CST
+ || TREE_CODE (max) != INTEGER_CST)
+return false;
+
+ return is_valid_array_range (min, max, TREE_TYPE (TREE_OPERAND (expr, 0)));
+}
+
/* Create or return the SRA_ELT structure for EXPR if the expression
refers to a scalarizable variable. */
@@ -599,7 +662,7 @@ maybe_lookup_element_for_expr (tree expr
case ARRAY_REF:
/* We can't scalarize variable array indices. */
- if (in_array_bounds_p (expr))
+ if (is_valid_const_index (expr))
child = TREE_OPERAND (expr, 1);
else
return NULL;
@@ -607,7 +670,7 @@ maybe_lookup_element_for_expr (tree expr
case ARRAY_RANGE_REF:
/* We can't scalarize variable array indices. */
- if (range_in_array_bounds_p (expr))
+ if (is_valid_const_range (expr))
{
tree domain = TYPE_DOMAIN (TREE_TYPE (expr));
child = build2 (RANGE_EXPR, integer_type_node,
@@ -746,7 +809,7 @@ sra_walk_expr (tree *expr_p, block_stmt_
the effort. */
/* ??? Hack. Figure out how to push this into the scan routines
without duplicating too much code. */
- if (!in_array_bounds_p (inner))
+ if (!is_valid_const_index (inner))
{
disable_scalarization = true;
goto use_all;
@@ -759,7 +822,7 @@ sra_walk_expr (tree *expr_p, block_stmt_
break;
case ARRAY_RANGE_REF:
- if (!range_in_array_bounds_p (inner))
+ if (!is_valid_const_range (inner))
{
disable_scalarization = true;
goto use_all;
