Hi,
Consider the 2 for loops given below.
for (i = 0; i < N ; i++)
{
a[i]= 1;
}
for (i = 0; i < N ; i++)
{
j = j+a[i];
}
The headers of these 2 loops are bb_3, bb_6 respectively. They are as follows.
bb_3 (preds = {bb_4 bb_2 }, succs = {bb_4 bb_5 })
{
:
# a_
On Thu, Apr 17, 2008 at 05:58:26PM -0700, Diego Novillo wrote:
> So, I see a couple different scenarios that we may want to consider:
>
> 1- Push back and tell us to come back at the next stage 1. This is
>certainly the easiest for everyone else, and will create a few
>challenges for us o
Hi,
I have some problems with an assert in purge_dead_edges in
cfgrtl.c:2319. I use gcc version 4.2.2. and I add a new function to
the callgraph with cgraph_add_new_function.
My new function body is obtained by current_function body using
move_sese_region_to_fn and all seems go well but when the ne
On Fri, Apr 18, 2008 at 9:34 AM, Sandeep Maram <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Consider the 2 for loops given below.
>
> for (i = 0; i < N ; i++)
> {
> a[i]= 1;
> }
>
> for (i = 0; i < N ; i++)
> {
> j = j+a[i];
> }
>
> The headers of these 2 loops are bb_3, bb_
> "Daniel" == Daniel Berlin <[EMAIL PROTECTED]> writes:
Daniel> I put my version of the gcc conversion (which has all branches
Daniel> but no tags) at git://gcc.gnu.org/git/gcc.git and set a script
Daniel> up to update it appropriately.
Daniel,
how is the GIT repository synced? Is there a ho
Ian,
Thanks. My pointer type is 32-bit. But when I tried the ARM target, GCC
4.3.0 does produce simpler code. It is likely my porting has some issue.
Bingfneg
-Original Message-
From: Ian Lance Taylor [mailto:[EMAIL PROTECTED]
Sent: 17 April 2008 18:31
To: Bingfeng Mei
Cc: gcc@gcc.gnu.
> Kunal Parmar <[EMAIL PROTECTED]> writes:
>
> > Is this correct :
> >ret_label = gen_label_rtx ();
> >emit_move_insn (gen_rtx_REG (HImode, 7),
> >gen_rtx_LABEL_REF (VOIDmode,
> > ret_label));
> >emit_call_insn (gen_brc_call_simulate (add
On Fri, Apr 18, 2008 at 6:31 AM, Samuel Tardieu <[EMAIL PROTECTED]> wrote:
> > "Daniel" == Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> Daniel> I put my version of the gcc conversion (which has all branches
> Daniel> but no tags) at git://gcc.gnu.org/git/gcc.git and set a script
> Daniel> u
On 18/04, Daniel Berlin wrote:
| > how is the GIT repository synced? Is there a hook which updates it
| > after a svn commit?
|
| No.
| It is synced every 30 minutes.
|
| >
| > I'm about to switch from infradead to gcc.gnu.org, and I want to make
| > sure that the latter is synced at least a
> I've moved ext/pb_assoc now. Looking in the libstdc++ directory,
> there are a couple of further files/directories I'm not sure about:
>
> -rw-r--r-- 1 bkoz gcc 1862 Feb 12 20:27 bk02.html
> -rw-r--r-- 1 gccadmin gcc724 Apr 12 00:55 bk02.html.gz
> -rw-r--r-- 1 bkoz gc
> Some changes I have committed already or plan to commit shortly, but
> there are some where I'd appreciate some help.
Sure.
> As a consequence of the restructuring of the libstdc++ documentation,
> the following prominent links are broken. Do you have current
> replacements for these?
>
>
On Fri, Apr 18, 2008 at 12:15 PM, Samuel Tardieu <[EMAIL PROTECTED]> wrote:
> On 18/04, Daniel Berlin wrote:
>
> | > how is the GIT repository synced? Is there a hook which updates it
> | > after a svn commit?
> |
> | No.
> | It is synced every 30 minutes.
> |
> | >
> | > I'm about to sw
On 18/04, Daniel Berlin wrote:
| > However, having it synced periodically rather than after every commit is
| > an annoyance.
|
| True, but it won't change anytime soon because it would place more
| load, and require more locking (since there is no guarantee a git sync
| will finish before the
Hi all,
I've tried to take into account the remarks from Joseph and Ian,
here's an updated patch. I welcome comments, ideas on how to best add
testcases in the testsuite (for example, comparing Fortran
information and C headers). After that, I will submit the complete
patch + testcases +
On Fri, 18 Apr 2008, FX wrote:
> I've tried to take into account the remarks from Joseph and Ian, here's an
> updated patch. I welcome comments, ideas on how to best add testcases in the
> testsuite (for example, comparing Fortran information and C headers). After
> that, I will submit the complet
error: non-trivial conversion at assignment
const struct string___XUB *
struct string___XUB *
_init->reference.P_BOUNDS = &ada__strings__unbounded__null_string.F.BOUNDS
+===GNAT BUG DETECTED======+
| 4.4.0 20080418 (experimental) (sparc-unknown-rt
> _init->reference.P_BOUNDS = &ada__strings__unbounded__null_string.F.BOUNDS
> +===GNAT BUG DETECTED==+
> | 4.4.0 20080418 (experimental) (sparc-unknown-rtems4.9) GCC error:|
> | verify_gimple failed |
Tha
On Fri, Apr 18, 2008 at 1:40 PM, Samuel Tardieu <[EMAIL PROTECTED]> wrote:
> On 18/04, Daniel Berlin wrote:
>
>
> | > However, having it synced periodically rather than after every commit is
> | > an annoyance.
> |
> | True, but it won't change anytime soon because it would place more
> | loa
Kunal Parmar wrote:
>> But my return label is getting optimized away. Could you please tell
>> me how to avoid this.
You may also need to add a (USE (REG RA)) to the call pattern. Gcc will
see that you set a register to the value of the return label, but it
won't see any code that uses tha
On 18/04, Daniel Berlin wrote:
| I know you think this is personal, as per your email below, but it really
isn't.
| I had it set up to do it after every commit, and it drove our load
| average up a noticeable amount.
| As such, I stopped doing it and set it to run every 30 minutes.
|
| > I know
On Fri, Apr 18, 2008 at 3:07 PM, Samuel Tardieu <[EMAIL PROTECTED]> wrote:
> On 18/04, Daniel Berlin wrote:
>
>
>
> I think the mistake is to have them (git & hg) hosted on the same
> machine as svn. Having them on "hg.gcc.gnu.org" and "git.gcc.gnu.org"
> would allow to split the load between ma
> That appears to be caused by this change:
>
> 2008-04-17 Eric Botcazou <[EMAIL PROTECTED]>
>
> * decl.c (gnat_to_gnu_entity) : Promote the alignment of
> objects by default.
> * fe.h (Debug_Flag_Dot_A): Delete.
> * debug.adb (-gnatd.a): Update documentation.
On which pl
Eric Botcazou wrote:
That appears to be caused by this change:
2008-04-17 Eric Botcazou <[EMAIL PROTECTED]>
* decl.c (gnat_to_gnu_entity) : Promote the alignment of
objects by default.
* fe.h (Debug_Flag_Dot_A): Delete.
* debug.adb (-gnatd.a): Update documentation.
Hi Jim,
>>> But my return label is getting optimized away. Could you please tell
>>> me how to avoid this.
>
>You may also need to add a (USE (REG RA)) to the call pattern. Gcc
will see that you set a register to the value of the
>return label, but it won't see any code that uses that register,
Eric Botcazou <[EMAIL PROTECTED]> writes:
>> That appears to be caused by this change:
>>
>> 2008-04-17 Eric Botcazou <[EMAIL PROTECTED]>
>>
>> * decl.c (gnat_to_gnu_entity) : Promote the alignment of
>> objects by default.
>> * fe.h (Debug_Flag_Dot_A): Delete.
>> * debug.adb
> Also, I think the conclusion was that the compiler should not claim
> any knowledge of these types unless specifically configured for a
> particular target - that is, defaults.h should not contain any default
> definitions.
My strong preference is to just predefine:
__INT8_T__
__INT16_T__
__IN
> I think the mistake is to have them (git & hg) hosted on the
> same machine as svn. Having them on "hg.gcc.gnu.org" and
> "git.gcc.gnu.org" would allow to split the load between machines
> (even if "hg.gcc.gnu.org" and "git.gcc.gnu.org" are the same
> machines originally).
My strong preference is to just predefine:
__INT8_T__
[...]
Along with all the rest of the predefined bits here:
I think that would defeat the purpose of knowing these types in the
Fortran front-end.
FX
--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
On Fri, Apr 18, 2008 at 3:57 PM, Alfred M. Szmidt <[EMAIL PROTECTED]> wrote:
>> I think the mistake is to have them (git & hg) hosted on the
>> same machine as svn. Having them on "hg.gcc.gnu.org" and
>> "git.gcc.gnu.org" would allow to split the load between machines
>> (even i
On Fri, 18 Apr 2008, Benjamin Kosnik wrote:
> My strong preference is to just predefine:
First the compiler needs to know all the types, in a way consistent with
existing headers (including the choice between long and int where they
have the same size, etc.) for any system which has such header
>> I think the mistake is to have them (git & hg) hosted on
>> the same machine as svn. Having them on "hg.gcc.gnu.org"
>> and "git.gcc.gnu.org" would allow to split the load between
>> machines (even if "hg.gcc.gnu.org" and "git.gcc.gnu.org"
>> are the same
Hi,
I switched to x86 Fedora to PowerPC and got farther.
There were some changes which did not get
reflected into the RTEMS specific files again but I
am past those and now have this failure which does
not appear to be RTEMS related. Remember .. I am
using a native compiler built from the trunk
Snapshot gcc-4.4-20080418 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20080418/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
Hi,
The first attempt at this one isn't showing up in the archives. :(
I switched to x86 Fedora to PowerPC and got farther.
There were some changes which did not get
reflected into the RTEMS specific files again but I
am past those and now have this failure which does
not appear to be RTEMS rela
BTW,
It occurs to me that the optimisation is just as likely (if not more
likely) to remove security holes as it is to introduce them.
If someone writes comparison involving 'buf+len' because they
incorrectly ignored a possibility of 'buf+len' wrapping, then
the optimisation fixes, not breaks, th
Hi,
I'm am the proprietor of a gcc compiler for the PDP10 architecture.
(This is a compiler previously worked on by Lars Brinkhoff who left XKL
some while before I joined XKL. It's possible some of you may have been
familiar with him or the compiler from that time.)
The compiler is currentl
> Fails here on ia64.
OK, this should be fixed everywhere now.
--
Eric Botcazou
Eric Botcazou wrote:
gnatmake -c -I/usr/lib/gcc/i386-redhat-linux/4.1.2/adalib/../adainclude
-I/usr/lib/gcc/i386-redhat-linux/4.1.2/adalib/ -I.
-I/home/joel/work-gnat/svn/gcc/gcc/ada gnatmake --GCC="gcc -g -O2 -W
-Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-fno-common -gna
> gnatmake -c -I/usr/lib/gcc/i386-redhat-linux/4.1.2/adalib/../adainclude
> -I/usr/lib/gcc/i386-redhat-linux/4.1.2/adalib/ -I.
> -I/home/joel/work-gnat/svn/gcc/gcc/ada gnatmake --GCC="gcc -g -O2 -W
> -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
> -fno-common -gnatpg -gnata"
Martin,
I did a port of GCC to the Analog Devices SHARC chip. I ended up
supporting 3 kinds of pointers for this chip (two for address
spaces and one for byte pointers - the chip itself is only word
addressable (although words can be from 16 to 48 bits in size
depending on what memory is
After consultation with Dan, I have set things up on gcc.gnu.org so that
the git repository is updated every time an email message is received
from the gcc-cvs mailing list.
We'll be monitoring the system to see if there is a load hit. If so,
we'll probably drop back to Dan's original method.
cg
Hi Joern,
>The insn that loads the return register with the label needs a REG_LABEL
>note to avoid the ref count dropping to zero.
The insn has a REG_LABEL (foo.c.110r.vregs) and the label also has a ref
count of 1.
>You would have to put a (set (pc) (reg RA)) into the pattern of the
>call in
42 matches
Mail list logo
