On Mon, Oct 13, 2008 at 4:38 PM, Andrew Haley <[EMAIL PROTECTED]> wrote:
> Andrew Pinski wrote:
>> On Fri, Oct 10, 2008 at 11:14 AM, Andrew Haley <[EMAIL PROTECTED]> wrote:
>>> Richard Guenther wrote:
>>>> On Fri, Oct 10, 2008 at 7:55 PM, Andrew Haley &l
On Thu, Oct 16, 2008 at 1:05 AM, Steve Ellcey <[EMAIL PROTECTED]> wrote:
> Dan and Richard,
>
> Are either of you aware of the gcc.dg/vect/vect-67.c failure that is
> occuring on some platforms? I see it on IA64 (Linux and HP-UX) but a
> scan of the gcc-testresults mailing lists shows failures on
On Fri, Oct 17, 2008 at 9:12 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
> We are starting to use the lto branch internally for testing and we
> would like to have some degree of stability for the next few months.
>
> Currently, the lto branch is tracking 4.4, but we will soon move to
> stage 1, w
On Thu, Oct 23, 2008 at 1:55 AM, Xinliang David Li <[EMAIL PROTECTED]> wrote:
>
> The patch is pretty big, so I am waiting for stage1 is reopened to submit.
Posting it when it's ready is a good idea usually to try to get
feedback and review
while you still remember every line of code. Of course,
On Thu, Oct 23, 2008 at 10:46 AM, Martin Schindewolf
<[EMAIL PROTECTED]> wrote:
> Hi all,
>
> how is the must-alias information represented in mainline?
> Is there something like DEF-USE chains for virtual operands?
> How can I access this kind of information and where should I look for some
> exam
On Mon, Oct 27, 2008 at 1:22 PM, Joseph S. Myers
<[EMAIL PROTECTED]> wrote:
> On Sun, 26 Oct 2008, David Edelsohn wrote:
>
>> Graphite's CLooG and PPL libraries use libgmpxx. Because cc1 is not linked
>> by g++, this effectively requires that libgmpxx must be a shared
>> library. libgmp
>
> I hop
On Fri, Oct 31, 2008 at 10:18 AM, wuxi <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>>
>> have a look at the flag -finstrument-functions for gcc.
>
> as far as I know, this could only record at function entry and return ?
>
> but sometimes recording all the "trace" of how program behaves i
On Sat, Nov 1, 2008 at 8:27 AM, Reza Roboubi <[EMAIL PROTECTED]> wrote:
> I believe gcc treats all function calls as fairly sacred and doesn't really
> optimize across function calls much. For example, the pcre(regex) library
> creates it's own stack frames and "simulates" the entire function recu
00404.html
The next report for 4.4.0 will be sent by Jakub.
--
Richard Guenther <[EMAIL PROTECTED]>
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex
On Sat, Nov 1, 2008 at 10:28 PM, Jack Howarth <[EMAIL PROTECTED]> wrote:
> What are the rules for porting patches back from the graphite
> branch that fix ICEs when -fgraphite is used to compile code?
> There doesn't seem to have been much movement of patches out of
> the graphite branch lately.
On Wed, Nov 12, 2008 at 10:40 AM, DJ Delorie <[EMAIL PROTECTED]> wrote:
>
> Ping? Is this the right thing to do? I'd like to get this (and a few
> other m32c bugs) resolved before the next release.
I don't think this is a suitable general solution. Can you instead try the
attached which again t
On Thu, Nov 13, 2008 at 5:25 PM, DJ Delorie <[EMAIL PROTECTED]> wrote:
>
>> I don't think this is a suitable general solution. Can you instead try the
>> attached which again tries to simply make sure we sign-extend a sizetype
>> offset if that is smaller than the pointer mode.
>
> Now I'm getting
On Fri, Nov 14, 2008 at 10:23 AM, DJ Delorie <[EMAIL PROTECTED]> wrote:
>
>> > Now I'm getting a ton of errors (like, around 5000) that look like this:
>>
>> Just remove that assert for testing.
>
> Looks good without the assert, 21 new passes and only 1 new failure:
>
> PASS-FAIL: gcc.c-torture/ex
On Mon, Nov 17, 2008 at 1:43 PM, DJ Delorie <[EMAIL PROTECTED]> wrote:
>
>> The old register allocator hasn't been removed yet, but will be
>> before branching. There are still several targets that haven't been
>> converted to IRA, so unless they are converted soon, they will be
>> dropped. The u
On Thu, Nov 20, 2008 at 1:24 PM, Laurent GUERBY <[EMAIL PROTECTED]> wrote:
> On Thu, 2008-11-20 at 00:39 +0100, Steven Bosscher wrote:
>> On Mon, Nov 17, 2008 at 11:15 AM, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
>> > Quality Data
>> >
>> >
>> > Priority # Change from Last
With looking at PRs 37742 and 37955 I reminded myself of our broken
restrict implementation which tries to model restrict semantics
within our type-based alias set framework. The implementation
heavily relies on correct tracking of restrict bases
(DECL_BASED_ON_RESTRICT_P/DECL_GET_RESTRICT_BASE)
On Fri, 21 Nov 2008, Diego Novillo wrote:
> On Fri, Nov 21, 2008 at 06:21, Richard Guenther <[EMAIL PROTECTED]> wrote:
>
> > I think the only reasonable thing to do is to rip out the broken
> > restrict pointer handling completely.
> >
> > Any better ideas?
On Fri, 21 Nov 2008, Jakub Jelinek wrote:
> On Fri, Nov 21, 2008 at 08:31:18AM -0500, Diego Novillo wrote:
> > On Fri, Nov 21, 2008 at 06:21, Richard Guenther <[EMAIL PROTECTED]> wrote:
> >
> > > I think the only reasonable thing to do is to rip out the broken
&
On Fri, 21 Nov 2008, Richard Guenther wrote:
> On Fri, 21 Nov 2008, Jakub Jelinek wrote:
>
> > On Fri, Nov 21, 2008 at 08:31:18AM -0500, Diego Novillo wrote:
> > > On Fri, Nov 21, 2008 at 06:21, Richard Guenther <[EMAIL PROTECTED]> wrote:
> > >
> > >
On Fri, Nov 21, 2008 at 10:14 PM, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> On Fri, Nov 21, 2008 at 2:23 PM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>> Michael Matz <[EMAIL PROTECTED]> writes:
>>
This program appears to me to be invalid according to C99 6.7.3.1,
which is the only def
On Sun, Nov 30, 2008 at 5:28 AM, Steve Kargl
<[EMAIL PROTECTED]> wrote:
> First, I'll preface this with "I'm probably doing something wrong."
> I'm adding support to gfortran for the ERRMSG argument to [DE]ALLOCATE.
> Here's, some code to demonstrate:
>
> program a
> call works
> call fails
> e
On Sun, Nov 30, 2008 at 5:28 AM, Steve Kargl
<[EMAIL PROTECTED]> wrote:
> First, I'll preface this with "I'm probably doing something wrong."
> I'm adding support to gfortran for the ERRMSG argument to [DE]ALLOCATE.
> Here's, some code to demonstrate:
>
> program a
> call works
> call fails
> e
On Sun, Dec 7, 2008 at 4:21 AM, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> Hi,
>
> After spending the better part of the evening finding a bug caused by
> an uninitialized pointer I would love to get a Warning about
> uninitialized variables from g++ in cases like Foo, Bar and Baz below:
>
>
On Tue, Dec 9, 2008 at 9:12 PM, Joel Sherrill <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Is this one in the list?
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37440
>
> Can Ada build on any Arm platform? arm-rtems had
> good test results for 4.3.2 but broke a few months ago.
> I suspect it doesn't bu
On Wed, Dec 10, 2008 at 5:44 PM, Дмитрий Дьяченко <[EMAIL PROTECTED]> wrote:
> g++-current generates messages which
> 1) contains compiler generated symbols
> 2) refers to gcc internal header (stl_tree.h)
>
> [EMAIL PROTECTED] gcc_err]# g++ -Wall -c -O3 test.cpp
> test.cpp: In member function 'void
On Fri, Dec 12, 2008 at 12:29 AM, Martin Jambor wrote:
> Hi,
>
> today I have encountered an unpleasant problem with the function
> get_ref_base_and_extent() when it claimed a known and constant offset
> for the expression insn_4(D)->u.fld[arg.82_3].rt_rtvec. (arg being a
> default_def pa
On Fri, Dec 12, 2008 at 11:59 AM, Jan Hubicka wrote:
>> On Fri, Dec 12, 2008 at 12:29 AM, Martin Jambor wrote:
>> > Hi,
>> >
>> > today I have encountered an unpleasant problem with the function
>> > get_ref_base_and_extent() when it claimed a known and constant offset
>> > for the express
On Fri, Dec 12, 2008 at 3:05 PM, Martin Jambor wrote:
> Hi,
>
> On Fri, Dec 12, 2008 at 12:26:38PM +0100, Richard Guenther wrote:
>> On Fri, Dec 12, 2008 at 11:59 AM, Jan Hubicka wrote:
>> >> On Fri, Dec 12, 2008 at 12:29 AM, Martin Jambor wrote:
>> >&
On Tue, Dec 23, 2008 at 11:28 AM, Andrew Haley wrote:
> Eric Botcazou wrote:
>>> Thanks. Are you holding this because we're in Stage 3?
>>
>> The patch was written very recently so I wanted to let it go through a good
>> deal of internal testing. Moveover I haven't measured its impact on anythin
On Wed, Dec 24, 2008 at 11:07 AM, Steven Bosscher wrote:
> On Tue, Dec 23, 2008 at 8:03 PM, Cary Coutant wrote:
>> Another approach is to generate the debug information earlier -- in
>> the front-end. This approach would significantly alter the structure
>> of the compiler and would be a major un
On Tue, Dec 30, 2008 at 1:08 PM, Kristian Spangsege
wrote:
> Hi
>
> A simple example (see below) seems to reveal that GCC considers the
> unoptimized size of a function rather that the optimized one, when
> deciding whether it is small enough to be inlined. In fact, it shows
> that GCC does consid
On Fri, Jan 2, 2009 at 12:36 PM, Richard Sandiford
wrote:
> Hi,
>
> Sorry in advance if this going over old ground. And if not, sorry
> for the somewhat negative message ;), but ... I think the current
> documentation and/or behaviour of the "optimize" attribute are a little
> confusing.
>
> The
Actually I have two questions. First, what is the difference between
-fargument-noalias-global and -fargument-noalias-anything (please
provide an example, not cite documentation ;))
Second question. Does "global memory" include memory that escaped?
Thus, with -fargument-noalias-global:
int *p;
On Sat, 3 Jan 2009, Toon Moene wrote:
> [ Happy New Year first of all - hope we don't have too many more of them
> ... Hey, you can recognize a Jimi Hendrix fan, don't you ]
;)
> Richard Guenther wrote:
>
> > Actually I have two questions. First, wh
On Sat, 3 Jan 2009, Toon Moene wrote:
> Richard Guenther wrote:
>
> > On Sat, 3 Jan 2009, Toon Moene wrote:
>
> > > The pointers used by the Fortran Front End to implement Fortran's argument
> > > association *cannot* point to anything else than the sto
On Sat, 3 Jan 2009, Steve Kargl wrote:
> On Sat, Jan 03, 2009 at 08:11:14PM +0100, Richard Guenther wrote:
> > On Sat, 3 Jan 2009, Toon Moene wrote:
> >
> > > [ Happy New Year first of all - hope we don't have too many more of them
> > > ... Hey, you can r
Status
==
The trunk remains Stage 4, so only fixes for regressions (and changes
to documentation) are allowed.
As stated previously, the GCC 4.4 branch will be created when there
are no open P1s and the total number of P1, P2, and P3 regressions is
under 100.
One issue that remains is remov
On Wed, Jan 7, 2009 at 1:46 AM, DJ Delorie wrote:
>
> I'm looking a failure for m32c-elf (-mcpu=m32c) in
> gcc.c-torture/execute/2412-6.c.
>
> I've narrowed it down to a transformation done in 107t.ivopts.
>
> In 104t.cunroll: (tmp_9 and tmp_16 are 24-bit pointer values):
>
> tmp_9 = tmp_16 +
On Wed, Jan 7, 2009 at 10:22 AM, Ye, Joey wrote:
> This is about http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38736 and I'd
> rather discuss it in gcc mail list. Basicly the problem is shown as following
> example:
>
> Case 1 (on x86 or x86_64):
> $ cat i.h
> struct s
> {
>char dummy0;
>/
On Wed, Jan 7, 2009 at 4:55 PM, Ian Lance Taylor wrote:
> "Ye, Joey" writes:
>
>> Option 3: Define BIGGEST_ALIGNMENT as a fixed value 32 bytes, for
>> all x86 target, and extend to 64 or more bytes in future.
>
> Assuming that code compiled with -mavx is intended to interoperate
> with code compi
On Wed, Jan 7, 2009 at 5:09 PM, DJ Delorie wrote:
>
>> As I repeatedly said having sizetype of a different precision than
>> pointer types will cause all sorts of problems ;)
>
> And as I've rebutted repeatedly, I can't change the chip.
>
>> The middle-end generally assumes it can cast between siz
On Wed, Jan 7, 2009 at 5:27 PM, Ian Lance Taylor wrote:
> "Richard Guenther" writes:
>
>> As there is no hardware implementation of AVX available I think
>> we definitely should stay with 16 for 4.4.
>
> That makes sense.
>
>> And IMNSHO also for
>&
On Thu, Jan 8, 2009 at 10:17 PM, H.J. Lu wrote:
> On Thu, Jan 8, 2009 at 12:40 PM, Ian Lance Taylor wrote:
>> "H.J. Lu" writes:
>>
>>> We can solve it with
>>>
>>> 1. A target should define MALLOC_ABI_ALIGNMENT properly.
>>> 2. g++ should issue an error when the default new operator
>>> is used
On Fri, Jan 9, 2009 at 2:22 AM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>>> For that matter, don't we have a problem on x86 GNU/Linux, where
>>> malloc returns an 8-byte alignment but attribute((aligned)) is a 16
>>> byte alignment?
>>
>> I don't think it is the same as MALLOC_ABI_ALIGNMENT
On Fri, Jan 9, 2009 at 4:31 PM, Ian Lance Taylor wrote:
> "Richard Guenther" writes:
>
>>> There are many ways to align data without exposing it in the
>>> ABI--e.g., the alignment of a global array is not part of the ABI, in
>>> that nothing breaks
On Fri, Jan 9, 2009 at 4:59 PM, Ian Lance Taylor wrote:
> "Richard Guenther" writes:
>
>> On Fri, Jan 9, 2009 at 4:31 PM, Ian Lance Taylor wrote:
>>> "Richard Guenther" writes:
>>>
>>>>> There are many ways to align data with
On Sat, Jan 10, 2009 at 12:19 PM, Raoul Gough wrote:
> I've been investigating a code-reordering question to do with g++ strict
> alias analysis, and I suspect there is a deficiency in the way type-based
> alias analysis works. I realise that's unlikely to be the case, so I'll try
> to present a c
On Sat, Jan 10, 2009 at 12:55 PM, Richard Guenther
wrote:
> On Sat, Jan 10, 2009 at 12:19 PM, Raoul Gough wrote:
>> I've been investigating a code-reordering question to do with g++ strict
>> alias analysis, and I suspect there is a deficiency in the way type-based
>&g
On Sat, Jan 10, 2009 at 3:33 PM, Laurent GUERBY wrote:
> Hi,
>
> It looks like the tests for -frtl-abstract-sequences are either skipped
> or xfailed for a long list of platforms:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33642
> "unrecognizable insn for -frtl-abstract-sequences"
> <<
> Almo
On Sun, Jan 11, 2009 at 7:59 PM, Raoul Gough wrote:
> Richard Guenther wrote:
>>
>> On Sat, Jan 10, 2009 at 12:55 PM, Richard Guenther
>> wrote:
>>
>>>
>>> On Sat, Jan 10, 2009 at 12:19 PM, Raoul Gough
>>> wrote:
>>>
>
> [sni
On Mon, Jan 12, 2009 at 12:03 AM, Raoul Gough wrote:
> Richard Guenther wrote:
>>
>> On Sun, Jan 11, 2009 at 7:59 PM, Raoul Gough
>> wrote:
>>
>
> [snip]
>>>
>>> I guess the situation is more complicated in C++, which has explicit
>>> d
On Mon, Jan 12, 2009 at 10:50 PM, Raoul Gough wrote:
> Richard Guenther wrote:
>>
>> On Mon, Jan 12, 2009 at 12:03 AM, Raoul Gough
>> wrote:
>>
>>>
>>> Richard Guenther wrote:
>>>
>
> [snip]
>>>>
>>>> This is
On Fri, Jan 16, 2009 at 4:19 PM, Ian Lance Taylor wrote:
> Adam Nemet writes:
>
>> struct s
>> {
>> char a:4;
>> char b:8;
>> char c:4;
>> } __attribute__ ((packed))
>>
>> is 3 bytes long because b gets pushed to the next byte boundary.
>
> Sounds like a bug.
>
>
>> The reason for this beha
It's not my turn to send a status report, but as I plan doing a release
candidate for GCC 4.3.3 soon I thought a status report for that would
be in order.
Status
==
The GCC 4.3 branch is now frozen in preparation for a release candidate
for the GCC 4.3.3 release. When the branch is unfrozen
On Fri, 16 Jan 2009, H.J. Lu wrote:
> On Fri, Jan 16, 2009 at 3:03 PM, Richard Guenther wrote:
> >
> > It's not my turn to send a status report, but as I plan doing a release
> > candidate for GCC 4.3.3 soon I thought a status report for that would
>
A release candidate for GCC 4.3.3 is available from
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3.3-RC-20090117/
and shortly its mirrors. It has been generated from SVN revision 143460.
The branch is still frozen and all checkins until after the final
release of GCC 4.3.3 require explicit RM approva
On Sat, 17 Jan 2009, John David Anglin wrote:
> On Sat, 17 Jan 2009, Richard Guenther wrote:
>
> > It's not my turn to send a status report, but as I plan doing a release
> > candidate for GCC 4.3.3 soon I thought a status report for that would
> > be in order.
>
On Sun, Jan 18, 2009 at 2:04 AM, Dave Korn
wrote:
> [Cc list trimmed]
>
> Richard Guenther wrote:
>> Status
>> ==
>>
>> The trunk remains Stage 4, so only fixes for regressions (and changes
>> to documentation) are allowed.
>
>Hello Richard,
On Sun, 18 Jan 2009, H.J. Lu wrote:
> On Sat, Jan 17, 2009 at 6:23 AM, Richard Guenther wrote:
> >
> > A release candidate for GCC 4.3.3 is available from
> >
> > ftp://gcc.gnu.org/pub/gcc/snapshots/4.3.3-RC-20090117/
> >
> > and shortly its mirrors.
On Sun, Jan 18, 2009 at 10:35 PM, H.J. Lu wrote:
> Hi,
>
> This 4.3 regression:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38905
>
> is caused by a backport, which also introduced a 4.3
> regression:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36765
It uncovered a latent problem. Of cou
On Sun, 18 Jan 2009, Richard Guenther wrote:
> On Sun, 18 Jan 2009, H.J. Lu wrote:
>
> > On Sat, Jan 17, 2009 at 6:23 AM, Richard Guenther wrote:
> > >
> > > A release candidate for GCC 4.3.3 is available from
> > >
> > > ftp://gcc.gnu.org/pub/
On Mon, 19 Jan 2009, H.J. Lu wrote:
> On Mon, Jan 19, 2009 at 1:27 AM, Richard Guenther wrote:
> > On Sun, 18 Jan 2009, Richard Guenther wrote:
> >
> >> On Sun, 18 Jan 2009, H.J. Lu wrote:
> >>
> >> > On Sat, Jan 17, 2009 at 6:23 AM, Richard Guenthe
On Tue, Jan 20, 2009 at 12:06 PM, Martin Jambor wrote:
> Hi,
>
> I have found the testcase gcc/testsuite/gcc.dg/noncompile/920507-1.c
> failing when I was testing my new SRA. The testcase is quite simple,
> should error out but no longer does:
>
>
> int
On Tue, Jan 20, 2009 at 2:17 PM, Paolo Bonzini wrote:
>
>>>
>>> int *
>>> x(void)
>>> {
>>> register int *a asm("unknown_register"); /* { dg-error "invalid register"
>>> } */
>>> int *v[1] = {a};
>>> return v[1];
>>> }
>>> -
Alias-Improvements Branch
=
The primary objective of the branch is to transition away from the use
of the virtual operand use-def chains as data-flow representation for
memory optimizations. Memory optimizers need to transition to the
use of the alias-oracle which is a qu
On Thu, 22 Jan 2009, Matthias Klose wrote:
> Richard Guenther schrieb:
> > A release candidate for GCC 4.3.3 is available from
> >
> > ftp://gcc.gnu.org/pub/gcc/snapshots/4.3.3-RC-20090117/
> >
> > and shortly its mirrors. It has been generated from SVN revis
The branch is open again for regression and documentation fixes.
The next status report will be sent by Jakub.
Richard.
On Sun, Jan 25, 2009 at 7:34 PM, H.J. Lu wrote:
> Hi,
>
> We have been running functional tests on SPEC CPU 2K/2006
> on Linux/ia32 and Linux/Intel64 at -O2 and -O3. We'd like to
> report pass and regressions. We may send SPEC CPU
> regressions to
>
> http://gcc.gnu.org/ml/gcc-regression/
>
> But
On Sun, Jan 25, 2009 at 7:56 PM, H.J. Lu wrote:
> On Sun, Jan 25, 2009 at 10:45 AM, Richard Guenther
> wrote:
>> On Sun, Jan 25, 2009 at 7:34 PM, H.J. Lu wrote:
>>> Hi,
>>>
>>> We have been running functional tests on SPEC CPU 2K/2006
>>> on L
On Mon, Jan 26, 2009 at 4:23 PM, Andrew Walrond wrote:
> I've tried two mirrors with the same results:
>
> $ cat md5.sum | grep gcc-4.3.3.tar.bz2
>
> d3338b75fa6f83be08908b1eed56d439 gcc-4.3.3.tar.bz2
>
> $ md5sum gcc-4.3.3.tar.bz2
> cc3c5565fdb9ab87a05ddb106ba0bd1f gcc-4.3.3.tar.bz2
>
> Can som
On Mon, Jan 26, 2009 at 5:41 PM, Richard Guenther
wrote:
> On Mon, Jan 26, 2009 at 5:29 PM, Hariharan wrote:
>> Hi,
>> I ran into some code-size/stack size bloat using -Os for a piece of code.
>> This seemed to happen only when certain single call-site functions are
>&g
On Mon, Jan 26, 2009 at 5:29 PM, Hariharan wrote:
> Hi,
> I ran into some code-size/stack size bloat using -Os for a piece of code.
> This seemed to happen only when certain single call-site functions are
> defined "static" and not otherwise. On investigating further on this, i see
> that the inli
On Mon, Jan 26, 2009 at 5:37 PM, H.J. Lu wrote:
> On Mon, Jan 26, 2009 at 7:49 AM, Richard Guenther
> wrote:
>> On Mon, Jan 26, 2009 at 4:23 PM, Andrew Walrond wrote:
>>> I've tried two mirrors with the same results:
>>>
>>
On Mon, Jan 26, 2009 at 7:53 PM, Ian Lance Taylor wrote:
> Richard Guenther writes:
>
>> On Mon, Jan 26, 2009 at 4:23 PM, Andrew Walrond wrote:
>>> I've tried two mirrors with the same results:
>>>
>>> $ cat md5.sum | grep gcc-4.3.3.tar.bz2
>>
On Tue, Jan 27, 2009 at 9:33 AM, Paolo Bonzini wrote:
> James Dennett wrote:
>> On Mon, Jan 26, 2009 at 11:52 PM, wrote:
>>> I was debugging a function and by inserting the debug statement crashed
>>> the system. Some investigation revealed that gcc 4.3.2 arm-eabi (compiled
>>> from sources) wit
On Tue, Jan 27, 2009 at 11:35 AM, Paolo Bonzini wrote:
Not for PTA though ;)
>>> Care to expand?
>>
>> PTA tracks points-to-NULL as pointing to "nothing".
>> This probably should be conditional on -fdelete-null-pointer-checks.
>> Otherwise *NULL and *anything won't alias.
>
> Yes, you're righ
On Tue, Jan 27, 2009 at 11:29 AM, Paolo Bonzini wrote:
>
>>> However, -fno-delete-null-pointer-checks will do.
>>
>> Not for PTA though ;)
>
> Care to expand?
PTA tracks points-to-NULL separately (as pointing to "nothing"). See
/* x = integer is all glommed to a single variable, which doesn't
On Tue, Jan 27, 2009 at 11:02 PM, Diego Novillo wrote:
> On Tue, Jan 27, 2009 at 16:58, H.J. Lu wrote:
>
>> LTO failed to bootstrap on RHEL5/ia32 and RHEL5/ia64:
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38992
>
> Thanks. This was known to us, though we had not filed a request.
> Essenti
On Wed, Jan 28, 2009 at 11:29 PM, Ben Elliston wrote:
> After reading about the new runtime license, I did some grepping through
> the gcc/ directory to see how many files would need updating. I was
> surprised to discover three files that are part of GCC proper, but are
> still under GPLv2. Sho
On Sat, Jan 31, 2009 at 5:01 AM, Sean Callanan wrote:
> Dear mailing list:
>
> My research group (the High-Confidence Operating Systems group at Stony
> Brook University;
> home page http://www.fsl.cs.sunysb.edu/hcos/) continues to use a modified
> branch of
> Subversion GCC that hosts plug-ins wr
On Sat, Jan 31, 2009 at 5:26 AM, Kaveh R. Ghazi wrote:
> From: "Tobias Burnus"
>
>> Hi Kaveh,
>>
>> Kaveh R. GHAZI wrote:
>>>
>>> I'm trying to create complex number expressions that contain inf or
>>> nan in the imaginary part. I.e. (0 + inf I) or (0 + nan I).
>>
>> If it does not need to be C
On Sat, Jan 31, 2009 at 2:11 PM, Diego Novillo wrote:
> On Fri, Jan 30, 2009 at 23:01, Sean Callanan wrote:
>
>> We've been off the ML for some time, but we're still out there.
>> Is this something that is wanted, or have we been overtaken
>> by events and should be porting to someone else's
>> i
On Sat, Jan 31, 2009 at 6:57 PM, John David Anglin
wrote:
>> removed. The 4.4 branch will be created when all the P1 fixes are committed
>> and the licensing changes (see the GCC Runtime Library Exception thread on
>> gcc mailing list) land on the trunk.
>
> I noticed sometime ago that two files
On Sat, Jan 31, 2009 at 6:48 PM, Dave Korn
wrote:
> H.J. Lu wrote:
>> On Sat, Jan 31, 2009 at 4:34 AM, Jakub Jelinek wrote:
>>> Status
>>> ==
>>>
>>> The trunk remains Stage 4, so only fixes for regressions (and changes
>>> to documentation) are allowed.
>>>
>>> The number of P1, P2 and P3 re
questions or comments about
this release. Instead, use the resources available from
http://gcc.gnu.org.
As always, a vast number of people contributed to this GCC release -- far
too many to thank individually!
--
Richard Guenther
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG
On Thu, 5 Feb 2009, Paul Brook wrote:
> > For -Os it should be enough to set PARAM_STACK_FRAME_GROWTH
> > to zero. Inlining at -Os should already only happen if it decreases
> > (overall!) code-size. Thus, inlining a function that is called once and
> > that does not need to be emitted will alwa
On Sat, Feb 7, 2009 at 7:27 PM, Dennis Clarke wrote:
>
> This is just a question. Hopefully someone can shed some light on what the
> fixincludes stage of "make install" does. I am making the assumption that
> the "make install" stage is where these headers get mangled or modified.
>
> This is on
On Fri, Feb 6, 2009 at 5:30 PM, Paolo Bonzini wrote:
> The current system for managing bugzilla priorities has a major problem,
> in that it does not identify bugs that reasonably cannot be fixed before
> the release.
>
> The current set of priorities is in practice like this:
>
> - P1: most wrong
On Wed, Feb 11, 2009 at 7:56 PM, Mark Mitchell wrote:
> Paolo Bonzini wrote:
>
>>> I think the only reasonable release criteria is zero P1 regressions over
>>> some period. 50 P2 regressions doesn't make a release blocker, neither
>>> is 49 P2 regressions a clear sign for a non-blocked release.
>
On Mon, Feb 16, 2009 at 11:19 AM, Narasimha Datta wrote:
> Hello,
>
> Here's a simple memory copy macro:
>
> #define MYMEMCOPY(dp, sp, len) \
> do { \
>long __len = len; \
>while (--__len >= 0) \
>(dp)[__len] = (sp)[__len]; \
> } while (0)
>
> void foo(unsigned char
On Sat, Feb 21, 2009 at 11:20 AM, Steven Bosscher wrote:
> Hi,
>
> No changes were checked in on the autovect-branch in the last ~15
> months, but the branch still gets a daily bump on DATESTAMP.
>
> Perhaps time to stop doing that?
Huh, we do that? Yeah, feel free to adjust
maintainer_scripts/u
On Sat, Feb 21, 2009 at 1:30 PM, Joseph S. Myers
wrote:
> On Sat, 21 Feb 2009, Steven Bosscher wrote:
>
>> Hi,
>>
>> No changes were checked in on the autovect-branch in the last ~15
>> months, but the branch still gets a daily bump on DATESTAMP.
>
> When I moved a lot of branches to the list of i
On Tue, Feb 24, 2009 at 4:38 PM, Vincent R. wrote:
> Hi,
>
> even if I am simple mortal I would like to understand or at least follow
> what is going on with gcc.
> Generally when I run gdb and try to breakpoint inside a function I get a
> undefined symbol or something like that.
> I suppose this
On Wed, Feb 25, 2009 at 4:43 PM, Florent DEFAY
wrote:
> Hi,
>
> I would like to know more about REAL_MODE_FORMAT and real_format_for_mode.
>
> I'm sorry because I already posted this email in gcc-help mailing-list
> but there was no answer and maybe its right place is here ?
>
> I am working on a
There have been numerous issues in the past with respect to the
undefinedness of signed overflow in our IL, with the non-semantics
of sizetype and friends and with the pessimization of using
unsigned arithmetic vs. signed arithmetic in loop optimizations.
The goal of the no-undefined-overflow bra
On Thu, 26 Feb 2009, Manuel López-Ibáñez wrote:
> 2009/2/26 Richard Guenther :
> >
> > There shall be no construct in the GIMPLE IL that invokes
> > undefined behavior.
>
> What about uninitialized variables?
That's unrelated and something I do not care about.
Richard.
On Thu, 26 Feb 2009, Joseph S. Myers wrote:
> On Thu, 26 Feb 2009, Richard Guenther wrote:
>
> > As a start there will be no-overflow variants of NEGATE_EXPR,
> > PLUS_EXPR, MINUS_EXPR, MULT_EXPR and POINTER_PLUS_EXPR.
>
> So you would have both wrapping and no-overflow
On Fri, 27 Feb 2009, Zdenek Dvorak wrote:
> Hi,
>
> in general, I like this proposal a lot. However,
>
> > As a start there will be no-overflow variants of NEGATE_EXPR,
> > PLUS_EXPR, MINUS_EXPR, MULT_EXPR and POINTER_PLUS_EXPR.
> >
> > The sizetypes will simply be operated on in no-overflow v
On Fri, 27 Feb 2009, Dave Korn wrote:
> Richard Guenther wrote:
> > On Fri, 27 Feb 2009, Zdenek Dvorak wrote:
>
> >> introducing new codes seems like a bad idea to me. There are many
> >> places that do not care about the distinction between PLUS_EXPR and
>
On Fri, 27 Feb 2009, Dave Korn wrote:
> Richard Guenther wrote:
>
> > It's definitely safer. Still we have to carefully modify existing
> > code to deal with the new tree codes as most of it carelessly
> > transitiones old codes to new trees. For example re-associ
1001 - 1100 of 2444 matches
Mail list logo
