We've had the testcase below in autovect-branch for a while, testing that
the 3 loops get vectorized. On mainline the third loop now gets eliminated
by DCE (.t44.dce3). Not sure I understand why... isn't the print loop
enough to keep it alive?
==
subroutine foo(a,b)
real a,
Mark Mitchell <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
|
| >In standard C++, constructors cannot be recursive functions. I'm
| > wondering whether the multiple entry-points implementation strategy used
| > by GCC depends in anyway on the absence of recursive definition.
|
| Ech
Hi, Ian,
Sorry for this delayed reply, just because bug chasing is time-cosumping to
a beginner. I think I found the root cause of the problem and post my ideas
to it for your reference.
As mentioned before in this thread, A new floating point type of 32 bit was
introduced into GCC, and this
sir
i am installing gcc-4.0.1 in mandrake (k ) linux.actually i want to
install apache server .for that gcc is neded.when i
i start configuring gcc it is showing a message like
configure:error:no acceptable cc found in $path
sir plz help me to come out of this
HItha
Hi,
When I try to compile something like:
foo(){
int a[] = {1,2};
}
gcc is combining them into a double (DImode) and handling as such. Is
there a switch by which I can direct gcc not to do so? I am using gcc
2.95.2.
When the array has three elements this issues does not exist any mor
Hello,
It's my new port of gcc. Libgcc is almost compiled for now, except
unwind-dw2-fde.c.
The error information is
'../../gcc-3.4.4/gcc/unwind-dw2-fde.c:968: internal compiler error:
in insert_save,
at caller-save.c:728
Please submit a full bug report'
Of course, there are some thing wrong abo
On Mon, Sep 19, 2005 at 05:33:54PM -0700, Dale Johannesen wrote:
> Do you have any constructive suggestions for how the RA might be fixed,
> then?
Short term? No. But I don't see this as a short term problem.
r~
Etienne Lorrain wrote:
> Hello,
>
> You really do not want to get a correction for:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23631
> before release?
I'd love to get a patch for this problem. -- but there's no readily
available prospect, and this is not a regression from 4.0.x. The
pri
Gabriel Dos Reis wrote:
>In standard C++, constructors cannot be recursive functions. I'm
> wondering whether the multiple entry-points implementation strategy used
> by GCC depends in anyway on the absence of recursive definition.
Echoing others, I do not forsee any problem with multiple en
On Mon, 2005-09-19 at 17:33 -0700, Dale Johannesen wrote:
> On Sep 19, 2005, at 5:30 PM, Richard Henderson wrote:
> >> (define_insn "*addmixed3"
> >> [(set (match_operand:V2DI 0 "register_operand" "=x")
> >>(subreg:V2DI (plus:SSEMODE124
> >> (match_operand:SSEMODE124 2 "nonimmediate_oper
Another correction:
Shin-ming Liu (HP) attended the meeting. In fact, he led the call :-)
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Mark K. Smith
> Sent: Monday, September 19, 2005 4:00 PM
> To: Gelato-GCC; GCC
> Subject: 15 Sept notes from G
"Zack Weinberg" <[EMAIL PROTECTED]> writes:
[...]
| Also: why do you care so much about this corner case? I only care from the
| implementation perspective, since I doubt it matters to any real software that
| GCC might compile. I'm pointing out an approach to the problem which would
| avoid ha
On Sep 19, 2005, at 5:30 PM, Richard Henderson wrote:
(define_insn "*addmixed3"
[(set (match_operand:V2DI 0 "register_operand" "=x")
(subreg:V2DI (plus:SSEMODE124
(match_operand:SSEMODE124 2 "nonimmediate_operand" "xm")
(subreg:SSEMODE124 (match_operand:V2DI 1 "nonimmediat
On Mon, Sep 19, 2005 at 05:19:20PM -0700, Dale Johannesen wrote:
> (Although just which subregs are safe to look under will require more
> attention than I've given it, if we want this in.)
Look at MODES_TIEABLE or something.
> Really I don't think this is an RA problem at all.
You don't?!? Ple
Just to review, the second function here was the problem:
(-march=pentium4 -mtune=prescott -O2 -mfpmath=sse -msse2)
#include
__m128i foo3(__m128i z, __m128i a, int N) {
int i;
for (i=0; i
where the inner loop compiles to
movdqa %xmm2, %xmm0
paddw %xmm1, %xmm0
Gabriel Dos Reis said:
[...]
> Good. It seems to me like those who would be spending a great deal of
> time and money are not sufficiently convinced by your arguments.
> Consequently, it appears that they are not in position to explain your
> strong opinion to the committees -- personally, I'm not
On Sun, Sep 18, 2005 at 09:41:54AM -0700, Mark Mitchell wrote:
> Please test, post test results to gcc-testresults, and send me an email
> pointing at the results.
OK for powerpc64-unknown-linux-gnu:
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00942.html
Janis
> Please test, post test results to gcc-testresults, and send me an email
> pointing at the results.
OK for sh4-unknown-linux-gnu:
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00902.html
Regards,
kaz
On Mon, 2005-09-19 at 16:00 -0500, Mark K. Smith wrote:
> ON THE CALL: Bob Kidd (UIUC), Vladimir Makarov (Red Hat), Mark Smith
> (Gelato), Wenguang Chen (Tsinghua), Mark Davis (Intel), Diego Novillo
> (Red Hat), Andrey Belevantsev (RAS), Dan Berlin (dberlin.org), Wen-mei
> Hwu (UIUC)
Just FYI, my
ON THE CALL: Bob Kidd (UIUC), Vladimir Makarov (Red Hat), Mark Smith
(Gelato), Wenguang Chen (Tsinghua), Mark Davis (Intel), Diego Novillo
(Red Hat), Andrey Belevantsev (RAS), Dan Berlin (dberlin.org), Wen-mei
Hwu (UIUC)
The call covered:
- current status / updates on the 3 improvement areas
- br
> I filed them as bugs, not fixed them.
OK, thanks for confirming.
--
Eric Botcazou
On Sep 19, 2005, at 4:21 PM, Eric Botcazou wrote:
Anyways, all of the known failures with the obj-c++ with the GNU
runtime have been filed and someone needs to look into them.
Are you talking about these?
I filed them as bugs, not fixed them.
Thanks,
Andrew Pinski
> Anyways, all of the known failures with the obj-c++ with the GNU
> runtime have been filed and someone needs to look into them.
Are you talking about these?
=== obj-c++ tests ===
Running target unix
FAIL: obj-c++.dg/bitfield-1.mm (test for excess errors)
FAIL: obj-c++.dg/bitfi
On Sep 19, 2005, at 3:21 PM, Mike Stump wrote:
On Sep 18, 2005, at 2:43 PM, Ulrich Weigand wrote:
In fact, as far as I can recall, 4.0.2 will be the first
ever GCC release with zero testsuite FAILs across all
languages on s390-ibm-linux ...
[ rub eyes ]
[ head explodes ]
[ desperately tryi
> You didn't test --enable-languages=obj-c++
Yeah, it's a plot, we positively refuse to test everything Apple has *not*
contributed. ;-)
--
Eric Botcazou
> GCC 4.0.2 RC2 is now available here
Sill ok on arm-none-elf:
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00938.html
Paul
Original Message
>From: Andreas Schwab
>Sent: 19 September 2005 20:20
> Erik Leunissen <[EMAIL PROTECTED]> writes:
>
>> gcc -pipe -o myLib.so myLib.c -lm
>>
>> How does the linker get the object code for myLib?
>> a. from a temporary file, saved by the compiler?
>> b. on stdin from a
Mike Stump <[EMAIL PROTECTED]> writes:
| On Sep 17, 2005, at 3:33 PM, Gabriel Dos Reis wrote:
| > C++98 came before C99, so who diverged from whom?
|
| You seem to not not how the C++ standard was made.
Thank you very much.
| In fact, it come before C99, like it or not.
Oh really? What did I
On Sep 18, 2005, at 2:43 PM, Ulrich Weigand wrote:
In fact, as far as I can recall, 4.0.2 will be the first
ever GCC release with zero testsuite FAILs across all
languages on s390-ibm-linux ...
[ rub eyes ]
[ head explodes ]
[ desperately trying to make sense of the world ]
You didn't test -
Erik Leunissen <[EMAIL PROTECTED]> writes:
> gcc -pipe -o myLib.so myLib.c -lm
>
> How does the linker get the object code for myLib?
> a. from a temporary file, saved by the compiler?
> b. on stdin from a pipe that connects to the compilers stdout?
> c. ???
It's case a. The -pipe option is
On Sep 17, 2005, at 3:33 PM, Gabriel Dos Reis wrote:
C++98 came before C99, so who diverged from whom?
You seem to not not how the C++ standard was made. In fact, it come
before C99, like it or not. The intention was that C++ would come up
with a follow on standard that tracked C99, in ne
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
| On Mon, Sep 19, 2005 at 01:50:35PM -0400, Andrew Pinski wrote:
| >
| > On Sep 19, 2005, at 1:44 PM, Gabriel Dos Reis wrote:
| >
| > >
| > >Hi,
| > >
| > > We're assessing many proposals to add "forwarding constructors" and
| > >forwarding functio
L.S.
A simple question:
When I build a shared object (or executable) by doing:
gcc -pipe -o myLib.so myLib.c -lm
How does the linker get the object code for myLib?
a. from a temporary file, saved by the compiler?
b. on stdin from a pipe that connects to the compilers stdout?
c. ???
The re
Andrew Pinski <[EMAIL PROTECTED]> writes:
| On Sep 19, 2005, at 1:44 PM, Gabriel Dos Reis wrote:
|
| >
| > Hi,
| >
| >We're assessing many proposals to add "forwarding constructors" and
| > forwarding functions to C++0x; and I got a question.
| >
| >In standard C++, constructors cannot be
On Mon, Sep 19, 2005 at 01:50:35PM -0400, Andrew Pinski wrote:
>
> On Sep 19, 2005, at 1:44 PM, Gabriel Dos Reis wrote:
>
> >
> >Hi,
> >
> > We're assessing many proposals to add "forwarding constructors" and
> >forwarding functions to C++0x; and I got a question.
> >
> > In standard C++, con
> Please test, post test results to gcc-testresults, and send me an email
> pointing at the results.
Still OK for SPARC/Solaris:
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00929.html
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00930.html
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg
On Sep 19, 2005, at 1:44 PM, Gabriel Dos Reis wrote:
Hi,
We're assessing many proposals to add "forwarding constructors" and
forwarding functions to C++0x; and I got a question.
In standard C++, constructors cannot be recursive functions. I'm
wondering whether the multiple entry-point
Hi,
We're assessing many proposals to add "forwarding constructors" and
forwarding functions to C++0x; and I got a question.
In standard C++, constructors cannot be recursive functions. I'm
wondering whether the multiple entry-points implementation strategy used
by GCC depends in anyway o
On Monday 19 September 2005 01:10, Joe Buck wrote:
> On Sun, Sep 18, 2005 at 06:54:26PM +0200, Florian Weimer wrote:
> Generally speaking, we want -Wall to be safe to use. gcc has some
> warnings that can't be silenced without making correct programs
> worse (-Weffc++ comes to mind); these are not
WHY are you resurrecting this discussion?
On Mon, Sep 19, 2005 at 03:30:37PM +0200, Gerald Pfeifer wrote (after a 2+ week
delay):
>On Fri, 2 Sep 2005, Christopher Faylor wrote:
>>Huh? What does "Red Hat" have to do with anything? "Red Hat" doesn't
>>provide the tools. Cygwin is a volunteer eff
On Sep 19, 2005, at 5:14 AM, Sebastian Pop wrote:
Hi,
I was working on improving the results of scev, when VRP has broken
the bootstrap, eliminating loops that were estimated as running a
single time. These loop bound estimates come from the undefined
behavior of accessing over the bounds of
I understand a tree, perhaps height balanced would give me a O(logn).
I am also worried abt
the constant factor for these or in other words the quality of
compiler generated code for such mechanisms. Any ideas on that ?
Shrey
On 9/19/05, Paul Koning <[EMAIL PROTECTED]> wrote:
> > "shreyas"
Florian Weimer wrote:
Doesn't it eleminate too many checks, even? 8-/
Not that I know of
And, to be absolutely honest, Ada only requires a small subset of all
the checks that are required to make pointers completely safe. Once
you use 'Unchecked_Access, Unchecked_Deallocation, or GNAT's
'Un
> "shreyas" == shreyas krishnan <[EMAIL PROTECTED]> writes:
shreyas> Hi , I am looking for an efficient data structure to map
shreyas> from a range of addresses to a single address. As it is
shreyas> used at runtime, I want it to be as efficient as possible,
shreyas> with perhaps updaing
shreyas krishnan wrote:
Hi ,
I am looking for an efficient data structure to map from a
range of addresses to a single address. As it is used at runtime, I
want it to be as efficient as possible, with perhaps updaing more
important that retreiving. Are there any examples of such data
Hi ,
I am looking for an efficient data structure to map from a
range of addresses to a single address. As it is used at runtime, I
want it to be as efficient as possible, with perhaps updaing more
important that retreiving. Are there any examples of such data
structure ( and optimized
Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
> Do you suppose the idiom is common enough that VRP could
special-case
> "arrays of size 1 at the end of a struct" ? And still obtain the
> benefits of the optimisation in 99.99% of all
> non-variable-length-tail-array cases?
>>>
Original Message
>From: [EMAIL PROTECTED]
>Sent: 19 September 2005 14:01
> "Dave Korn" <[EMAIL PROTECTED]> writes:
>
> [...]
>
>> I've seen this trick used again and again and again, and *I* haven't
>> _ever_ seen anyone use anything except an array size of [1] in this
>> place.
>
>
1. Not interprocedurally.
True, it was written before the IPA infrastructure was added.
For 4.2 the plan is to rewrite it using Diego's propagator and then
IPA propagation should be added too. It will be useful for both
__builtin_object_size builtin itself as well as other passes that might
use
On Mon, Sep 19, 2005 at 09:22:56AM -0400, Daniel Berlin wrote:
> On Mon, 2005-09-19 at 15:07 +0200, Jakub Jelinek wrote:
> > On Mon, Sep 19, 2005 at 09:03:48AM -0400, Daniel Berlin wrote:
> > > Anyway, the real fix is to simply not attempt to derive information when
> > > the access is through a po
On 9/19/05, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
>
> > I applied the patch by hand (not working with CVS) and it
> > does _not_ solve the problem.
> >
> In this case, I am sorry but the probability of a fix before the release
> is close to zero.
The problem with 4.0 is that it behaves comple
On Fri, 2 Sep 2005, Christopher Faylor wrote:
> Huh? What does "Red Hat" have to do with anything? "Red Hat" doesn't
> provide the tools. Cygwin is a volunteer effort.
According to http://cygwin.com/license.html (and the link from there)
Red Hat does provide tools for some set of users at least
On Mon, 2005-09-19 at 15:07 +0200, Jakub Jelinek wrote:
> On Mon, Sep 19, 2005 at 09:03:48AM -0400, Daniel Berlin wrote:
> > Anyway, the real fix is to simply not attempt to derive information when
> > the access is through a pointer (IE it is not related to structs at all,
> > it's the fact that t
Robert Dewar <[EMAIL PROTECTED]> writes:
> Per Abrahamsen wrote:
>
>> The idea was that you would be sure to get all the (boolean) warnings
>> that are relevant for your project, and can give an explicit reason
>> for each warning you don't want.
>> It would be particularly useful when upgrading G
Daniel Berlin <[EMAIL PROTECTED]> writes:
| > |
| > | Do you suppose the idiom is common enough that VRP could special-case
| > | "arrays of size 1 at the end of a struct" ?
| >
| > it could be array of size 2, 3, 4, 5, ...
|
| Except that anything but array of size 1 is not "such a C idomati
On Mon, Sep 19, 2005 at 09:03:48AM -0400, Daniel Berlin wrote:
> Anyway, the real fix is to simply not attempt to derive information when
> the access is through a pointer (IE it is not related to structs at all,
> it's the fact that these are heap allocated), unless you have info about
> the mallo
> If this is still correct, I will just restrict the analyzer to not
> infer any property from data defined in structs.
This is wrong :).
>
> If accessing "p->bar" via "p->before_end[5]" is not correct, I can
> restrict the analyzer to work only on "non last array in a struct".
>
You can
"Dave Korn" <[EMAIL PROTECTED]> writes:
[...]
| I've seen this trick used again and again and again, and *I* haven't
| _ever_ seen anyone use anything except an array size of [1] in this place.
[...]
| Have you?
Yes. It wasn't attempt at pedantism.
-- Gaby
> |
> | Do you suppose the idiom is common enough that VRP could special-case
> | "arrays of size 1 at the end of a struct" ?
>
> it could be array of size 2, 3, 4, 5, ...
Except that anything but array of size 1 is not "such a C idomatic
construct than I would not have expected any "optimizer
I applied the patch by hand (not working with CVS) and it
does _not_ solve the problem.
In this case, I am sorry but the probability of a fix before the release
is close to zero.
Paolo
"Giovanni Bajo" <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
|
| >>> Do you suppose the idiom is common enough that VRP could special-case
| >>> "arrays of size 1 at the end of a struct" ? And still obtain the
| benefits
| >>> of the optimisation in 99.99% of all n
--- Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> Etienne Lorrain wrote:
> > Hello,
> >
> > You really do not want to get a correction for:
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23631
> > before release?
> >
> > I checked again with 4.0.2 20050917, and nothing
> > has changed sinc
Per Abrahamsen wrote:
The idea was that you would be sure to get all the (boolean) warnings
that are relevant for your project, and can give an explicit reason
for each warning you don't want.
It would be particularly useful when upgrading GCC, in order to be
sure you get the benefit of any new
Etienne Lorrain wrote:
Hello,
You really do not want to get a correction for:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23631
before release?
I checked again with 4.0.2 20050917, and nothing
has changed since:
http://gcc.gnu.org/ml/gcc/2005-09/msg00251.html
Etienne, does the patch
Hello,
You really do not want to get a correction for:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23631
before release?
I checked again with 4.0.2 20050917, and nothing
has changed since:
http://gcc.gnu.org/ml/gcc/2005-09/msg00251.html
Etienne.
_
On Mon, 19 Sep 2005, Giovanni Bajo wrote:
>> I see that I reviewed it with two days back then. Not everything I
>> could/can approve as web pages maintainer (because it looks like
>> policy changes), but I see that about half of the changes I only
>> had minor editorial comments on.
>>
>> Would yo
Andrew Pinski wrote:
On Sep 19, 2005, at 12:46 AM, H. J. Lu wrote:
http://people.redhat.com/dnovillo/spec2000/
shows that gcc 4.1 has been failing vortex in SPEC CPU 2000 on
Linux/EM64T and Linux/PPC64 at least since Aug. 7, 2005. The current
gcc 4.1 also failed vortex on Linux/ia64. Is that
Original Message
>From: [EMAIL PROTECTED]
>Sent: 19 September 2005 12:09
> "Dave Korn" writes:
>
>> Original Message
>>> From: Richard Henderson
>>> Sent: 19 September 2005 11:26
>>> In the case of the (fake) flexible array member, you do not know
>>> how large the object allocat
Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
>>> Do you suppose the idiom is common enough that VRP could special-case
>>> "arrays of size 1 at the end of a struct" ? And still obtain the
benefits
>>> of the optimisation in 99.99% of all non-variable-length-tail-array
cases?
>>
>> It makes sense
Thanks for all the explanations.
Richard Henderson wrote:
>
> In the case of the (fake) flexible array member, you do not know
> how large the object allocated from malloc was unless you can
> track down the actual malloc call.
>
Gabriel Dos Reis wrote:
> typedef struct {
> int dat
"Giovanni Bajo" <[EMAIL PROTECTED]> writes:
| Dave Korn <[EMAIL PROTECTED]> wrote:
|
| > Do you suppose the idiom is common enough that VRP could special-case
| > "arrays of size 1 at the end of a struct" ? And still obtain the benefits
| > of the optimisation in 99.99% of all non-variable-len
"Dave Korn" <[EMAIL PROTECTED]> writes:
| Original Message
| >From: Richard Henderson
| >Sent: 19 September 2005 11:26
|
| > On Mon, Sep 19, 2005 at 12:07:45PM +0200, Sebastian Pop wrote:
| >> By the way, how is this different than detecting a bound on: ...
| >> int foo[1335];
| > ...
|
Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
>> I suggest you to double check also the list present in this mail:
>> http://gcc.gnu.org/ml/gcc-patches/2004-06/msg01625.html
>>
>> This was never publically approved, but it reflects views of many GCC
>> maintainers. Surely it does not hurt to follow th
On Mon, 12 Sep 2005, Giovanni Bajo wrote:
> I suggest you to double check also the list present in this mail:
> http://gcc.gnu.org/ml/gcc-patches/2004-06/msg01625.html
>
> This was never publically approved, but it reflects views of many GCC
> maintainers. Surely it does not hurt to follow those g
Dave Korn <[EMAIL PROTECTED]> wrote:
> Do you suppose the idiom is common enough that VRP could special-case
> "arrays of size 1 at the end of a struct" ? And still obtain the benefits
> of the optimisation in 99.99% of all non-variable-length-tail-array cases?
It makes sense to me. We could s
Original Message
>From: Richard Henderson
>Sent: 19 September 2005 11:26
> On Mon, Sep 19, 2005 at 12:07:45PM +0200, Sebastian Pop wrote:
>> By the way, how is this different than detecting a bound on: ...
>> int foo[1335];
> ...
>> some_struct{ int foo[1335];} s;
>
> Because here the
* Sebastian Pop:
> By the way, how is this different than detecting a bound on:
>
> {
> int foo[1335];
>
> for (i = 0; i < some_param; i++)
> foo[i];
> }
>
> vs.
>
> {
> some_struct{ int foo[1335];} s;
>
> for (i = 0; i < some_param; i++)
> s.foo[i];
> }
Nothing. But in the genau
Sebastian Pop <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| >
| > If VRP is doing what you described in the comment as "its work", then
| > VRP is broken. Period. The fix is to fix VRP. It is such a C
| > idomatic construct than I would not have expected any "optimizer" to
| > break
On Mon, Sep 19, 2005 at 12:07:45PM +0200, Sebastian Pop wrote:
> By the way, how is this different than detecting a bound on:
...
> int foo[1335];
...
> some_struct{ int foo[1335];} s;
Because here the variables are *known* to have a specific size.
Similarly with static and global variables,
> Oh, and I'll have to say that this idiom is *so* common in C90
> code, predating the specific C99 syntax, that you simply cannot
> add code that breaks it. At least not enabled by default.
I was worried for a few minutes after your first message. :-)
Definitely, we cannot (again) shoot ourselv
Gabriel Dos Reis wrote:
>
> If VRP is doing what you described in the comment as "its work", then
> VRP is broken. Period. The fix is to fix VRP. It is such a C
> idomatic construct than I would not have expected any "optimizer" to
> break it. And that is very worrisome and scary.
>
Okay, VR
Sebastian Pop <[EMAIL PROTECTED]> writes:
| Hi,
|
| I was working on improving the results of scev, when VRP has broken
| the bootstrap, eliminating loops that were estimated as running a
| single time. These loop bound estimates come from the undefined
| behavior of accessing over the bounds of
Joe Buck <[EMAIL PROTECTED]> writes:
> In that sense, -Wall effectively means "all the warnings we recommend
> that you use". Some people might want to argue with this, but that
> is the practical effect.
A -Weverything that turned on all boolean warnings would be nice. It
would be useless alon
On Mon, Sep 19, 2005 at 11:14:20AM +0200, Sebastian Pop wrote:
> + /* decls is statically declared as containing a single element, but
> + then, during the execution, other data is appended to the end of
> + this array, and elements over the statically allocated size are
> + access
On Mon, Sep 19, 2005 at 11:14:20AM +0200, Sebastian Pop wrote:
> + The fix is to declare this array as dynamically allocated as:
> +
> + decl_t *decls;
> +
> + then dynamically allocate its elements. */
> decl_t decls [1];
No, the fix is
#ifdef HAVE_FLEXIBLE_ARRAY_MEMBERS
Hi,
I was working on improving the results of scev, when VRP has broken
the bootstrap, eliminating loops that were estimated as running a
single time. These loop bound estimates come from the undefined
behavior of accessing over the bounds of statically allocated data in
genautomata.c:
*** genau
86 matches
Mail list logo
