change to gcc from lcc
Hello,
The following code works in lcc in windows but it does not work in gcc in unix.
I think it is memory problem. In lcc there is an option to use more temporary
memory than the default. Is there something similar in gcc?
#include
#include
#include
#include
int main()
{
int i, j;
int buffer1[250][100];
for (i=0; i<250; i++) {
for (j=0; j<100; j++) {
buffer1[i][j]=0;
}
}
printf("\nThe program finished successfully\n");
return 0;
}
Many Thanks,
Anna
Re: change to gcc from lcc
On Friday 14 November 2008 10:09:22 Anna Sidera wrote:
> Hello,
>
> The following code works in lcc in windows but it does not work in gcc in
> unix. I think it is memory problem. In lcc there is an option to use more
> temporary memory than the default. Is there something similar in gcc?
>
> #include
> #include
> #include
> #include
> int main()
> {
> int i, j;
> int buffer1[250][100];
> for (i=0; i<250; i++) {
> for (j=0; j<100; j++) {
> buffer1[i][j]=0;
> }
> }
> printf("\nThe program finished successfully\n");
> return 0;
> }
>
> Many Thanks,
> Anna
Anna,
the code you provided tries to allocate a huge chunk of memory on the stack.
This is not the way things should be done. Even if the compiler allows
for "using more temporary memory than the default", the solution is by no
means portable. A way more elegant solution is to use memory on the heap:
int main()
{
int i, j;
int *buf = (int*) malloc (250 * 100 * sizeof(int));
for (i=0; i<250; i++) {
for (j=0; j<100; j++) {
buf[i][j]=0;
}
}
free (buf);
printf("\nYay! :D\n");
return 0;
}
Tim
Cygwin support
Hi All Looking over the bugzilla data base and archives of this (and other) lists I was wondering about the level of support there is for GCC on Cygwin. (I realise that it is weird half-way house to many people and so does get a fair amount of "abuse" from both the Windoze & Linux/Un*x purist camps but I like it :-) ) Reason, I ask is I would like to start to contribute and for me Cygwin is the easiest target for me. But looking over things I'm not sure it would be the best place to start to help things out. Andy -- Brain upgrade required: a working hypothalamus
Re: change to gcc from lcc
Interesting. At least. There should be a warning from gcc.
Eric
2008/11/14 Tim München <[EMAIL PROTECTED]>:
> On Friday 14 November 2008 10:09:22 Anna Sidera wrote:
>> Hello,
>>
>> The following code works in lcc in windows but it does not work in gcc in
>> unix. I think it is memory problem. In lcc there is an option to use more
>> temporary memory than the default. Is there something similar in gcc?
>>
>> #include
>> #include
>> #include
>> #include
>> int main()
>> {
>> int i, j;
>> int buffer1[250][100];
>> for (i=0; i<250; i++) {
>> for (j=0; j<100; j++) {
>> buffer1[i][j]=0;
>> }
>> }
>> printf("\nThe program finished successfully\n");
>> return 0;
>> }
>>
>> Many Thanks,
>> Anna
>
> Anna,
>
> the code you provided tries to allocate a huge chunk of memory on the stack.
> This is not the way things should be done. Even if the compiler allows
> for "using more temporary memory than the default", the solution is by no
> means portable. A way more elegant solution is to use memory on the heap:
>
> int main()
> {
> int i, j;
> int *buf = (int*) malloc (250 * 100 * sizeof(int));
> for (i=0; i<250; i++) {
> for (j=0; j<100; j++) {
> buf[i][j]=0;
> }
> }
> free (buf);
> printf("\nYay! :D\n");
> return 0;
> }
>
>
> Tim
>
>
Re: Cygwin support
Andy Scott wrote: > Looking over the bugzilla data base and archives of this (and other) > lists I was wondering about the level of support there is for GCC on > Cygwin. (I realise that it is weird half-way house to many people and > so does get a fair amount of "abuse" from both the Windoze & > Linux/Un*x purist camps but I like it :-) ) Cygwin has been a secondary target for a number of years. MinGW has been a secondary target since 4.3. This generally means that they should be in fairly good shape, more or less. To quote the docs: > Our release criteria for the secondary platforms is: > > * The compiler bootstraps successfully, and the C++ runtime library > builds. > * The DejaGNU testsuite has been run, and a substantial majority of the > tests pass. Generally the problem that the PE/COFF targets face is that because of different semantics compared to ELF systems they often lag behind in certain areas. For example the lack of support for shared libgcc/libstdc++/etc. has been a continual problem for a long time but recent progress has moved things ahead somewhat. Another long standing issue is the desire to get away from SJLJ based exception handling and move to table-based Dwarf unwinding for performance reasons, but this is coupled with the need for working shared target libs. But this is as much a "system integration" problem as it is a gcc problem, as with any large switch. More recently I've seen Danny Smith report that the IRA merge broke MinGW (and presumably Cygwin, since they share most of the same code) bootstrap. I haven't tested this myself recently so I don't know if it's still broken or not. The real heart of the matter though is that most of the people that contribute to gcc aren't themselves users of these targets, and so it's only natural that they don't know about or care about the status of any target-specific issues. What has worried me lately however is how much ELF-specific design has been creeping into gcc, notably in the areas of plugins and LTO. If this trend continues it will result in the PECOFF targets becoming even more of a backwater than they already are, which I find to be a sad future for the 90%. > Reason, I ask is I would like to start to contribute and for me Cygwin > is the easiest target for me. But looking over things I'm not sure it > would be the best place to start to help things out. Well, you can certainly use Cygwin as a base for contributing, however, unless you are doing target-specific work[1] it doesn't make a lot of sense to do so. Running the dejagnu testsuite on Cygwin is excruciatingly slow due to the penalty incurred from emulating fork. Even with the overhead of vmware/colinux/virtualbox you're probably looking at a reduction from 20-30 hours down to several hours for a full testsuite run on an virtualized linux image compared to a native run (depending on which languages are enabled.) Brian [1] And of course, don't get me wrong, that would be fantastic, as these targets need all the TLC they can get.
Re: change to gcc from lcc
> > the code you provided tries to allocate a huge chunk of memory on the > > stack. > Interesting. At least. There should be a warning from gcc. The limit is nothing to do with GCC. It is an OS setting (ulimit -s). Paul
Re: Cygwin support
> The real heart of the matter though is that most of the people that > contribute to gcc aren't themselves users of these targets, and so it's > only natural that they don't know about or care about the status of any > target-specific issues. What has worried me lately however is how much > ELF-specific design has been creeping into gcc, notably in the areas of > plugins and LTO. If this trend continues it will result in the PECOFF > targets becoming even more of a backwater than they already are, which I > find to be a sad future for the 90%. If you really want to solve this then you could always stop using PE/COFF. The ARM EABI (and in particular the arm-none-symbianelf target) demonstrates how this can be done. Basically the toolchain generates ELF objects, executables and DSOs, then you feed them through a postlinker to generate target (PE/COFF) images. Paul
Re: Cygwin support
On 14/11/2008, Brian Dessent <[EMAIL PROTECTED]> wrote: > Andy Scott wrote: > > > Looking over the bugzilla data base and archives of this (and other) > > lists I was wondering about the level of support there is for GCC on > > Cygwin. (I realise that it is weird half-way house to many people and > > so does get a fair amount of "abuse" from both the Windoze & > > Linux/Un*x purist camps but I like it :-) ) > > > Cygwin has been a secondary target for a number of years. MinGW has > been a secondary target since 4.3. This generally means that they > should be in fairly good shape, more or less. To quote the docs: > > > Our release criteria for the secondary platforms is: > > > > * The compiler bootstraps successfully, and the C++ runtime library > builds. > > * The DejaGNU testsuite has been run, and a substantial majority of > the tests pass. > > Well, you can certainly use Cygwin as a base for contributing, however, > unless you are doing target-specific work[1] it doesn't make a lot of > sense to do so. Running the dejagnu testsuite on Cygwin is > excruciatingly slow due to the penalty incurred from emulating fork. > Even with the overhead of vmware/colinux/virtualbox you're probably > looking at a reduction from 20-30 hours down to several hours for a full > testsuite run on an virtualized linux image compared to a native run > (depending on which languages are enabled.) > > Brian > > [1] And of course, don't get me wrong, that would be fantastic, as these > targets need all the TLC they can get. > Thanks for the information - and the heads up on the testsuite running times :-) I tend to use weird and whacky versions of GCC for my work on embedded devices so helping maintain it for another semi-weird platform will stand me in good stead :-D Andy -- Brain upgrade required: a working hypothalamus
Re: Cygwin support
Brian Dessent wrote: > Cygwin has been a secondary target for a number of years. MinGW has > been a secondary target since 4.3. This generally means that they > should be in fairly good shape, more or less. To quote the docs: > >> Our release criteria for the secondary platforms is: >> >> * The compiler bootstraps successfully, and the C++ runtime library >> builds. >> * The DejaGNU testsuite has been run, and a substantial majority of the >> tests pass. > > > More recently I've seen Danny Smith report that the IRA merge broke > MinGW (and presumably Cygwin, since they share most of the same code) > bootstrap. I haven't tested this myself recently so I don't know if > it's still broken or not. > I've run the bootstrap and testsuite twice in the last month. The bootstrap failures are due to a broken #ifdef specific to cygwin in the headers provided with cygwin, the requirement for a specific version of autoconf (not available in setup), and the need to remove the -werror in libstdc++ build (because of minor discrepancies in cygwin headers). All of those are easy to rectify, but fixes seem unlikely to be considered by the decision makers. However, the C++ testsuite results are unacceptable, with many internal errors. For some time now, gfortran has been broken for practical purposes, even when it passes testsuite, as it seems to have a memory leak. This shows up in the public wiki binaries. So, there are clear points for investigation of cygwin problems, and submission of PRs, should you be interested. > Running the dejagnu testsuite on Cygwin is > excruciatingly slow due to the penalty incurred from emulating fork. It runs over a weekend on a Pentium D which I brought back to life by replacing the CPU cooler system. I have no problem with running this if I am in the office when the snapshot is released, but I think there is little interest in fixing the problems which are specific to g++ on cygwin, yet working gcc and gfortran aren't sufficient for gcc upgrades to be accepted. Support for 64-bit native looks like it will be limited to mingw, so I no longer see a future for gcc on cygwin.
Re: warning: #import is a deprecated GCC extension
2008/11/13 Jack Howarth <[EMAIL PROTECTED]>:
> The darwin-specific gcc.dg/cpp/subframework1.c -fno-show-column test case
> is failing under gcc trunk for the excessive errors test because we now
> get warnings...
>
> warning: #import is a deprecated GCC extension
>
> Is there a particular way to modify an excessive errors test case to
> have a particular warning like this be ignored? Thanks in advance for
> any hints on solving this issue.
> Jack
-Wno-deprecated?
Or even better:
/* { dg-warning "import is a deprecated GCC extension" "deprecated" {
target *-*-* } 0 } */
Does that help?
Manuel.
Re: change to gcc from lcc
Anna Sidera <[EMAIL PROTECTED]> writes: > The following code works in lcc in windows but it does not work in > gcc in unix. I think it is memory problem. In lcc there is an option > to use more temporary memory than the default. Is there something > similar in gcc? In gcc, no. But if you are using gcc on Windows, you are probably using the GNU linker. The GNU linker Windowsport supports a --stack option to set the size of the stack. This is documented in the GNU linker manual. Ian
Re: Cygwin support
Paul Brook wrote: > If you really want to solve this then you could always stop using PE/COFF. > The ARM EABI (and in particular the arm-none-symbianelf target) demonstrates > how this can be done. Basically the toolchain generates ELF objects, > executables and DSOs, then you feed them through a postlinker to generate > target (PE/COFF) images. Using ELF as an intermediary format doesn't really change the situation facing the design of plugins in any meaningful way though. If the end result is still PE/COFF executables and DLLs then the same problems and restrictions still exist that would make the current proposed design unworkable on these Windows targets. If you recall the issue is that plugins want unfettered access to the full symbol table of the executable. Doing this with PE/COFF is possible, but it binds the plugin DLL to the specific name of the executable that it was linked against, such that the same plugin wouldn't be loadable from cc1.exe, cc1plus.exe, f951.exe, etc. To get around this you'd have to either link a separate copy of the plugin for each executable, or access the symbols in the executable indirectly through GetProcAddress and function pointers. Brian
Re: [ping] Re: m32c: pointer math vs sizetype again
> > 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/execute/loop-ivopts-1.c execution, -O3 -fomit-frame-pointer -funroll-loops
Re: Cygwin support
Brian Dessent wrote: > Paul Brook wrote: > >> If you really want to solve this then you could always stop using PE/COFF. >> The ARM EABI (and in particular the arm-none-symbianelf target) demonstrates >> how this can be done. Basically the toolchain generates ELF objects, >> executables and DSOs, then you feed them through a postlinker to generate >> target (PE/COFF) images. > > Using ELF as an intermediary format doesn't really change the situation > facing the design of plugins in any meaningful way though. If the end > result is still PE/COFF executables and DLLs then the same problems and > restrictions still exist that would make the current proposed design > unworkable on these Windows targets. If you recall the issue is that > plugins want unfettered access to the full symbol table of the > executable. Doing this with PE/COFF is possible, but it binds the > plugin DLL to the specific name of the executable that it was linked > against, such that the same plugin wouldn't be loadable from cc1.exe, > cc1plus.exe, f951.exe, etc. To get around this you'd have to either > link a separate copy of the plugin for each executable, So do that, then. Where's the problem? Andrew.
Re: Cygwin support
Tim Prince wrote: > bootstrap failures are due to a broken #ifdef specific to cygwin in the > headers provided with cygwin, If you mean the strsignal change in libiberty, that's been fixed in CVS for a long time. > the requirement for a specific version of > autoconf (not available in setup), You are never supposed to need any version of autoconf to simply build gcc, only if you need to rebuild generated files. If the timestamps are correct (either by using a tarball or contrib/update_gcc to update from SVN) then autoconf should never be invoked, otherwise something is wrong with your setup. > and the need to remove the -werror in > libstdc++ build (because of minor discrepancies in cygwin headers). All That is what --disable-werror is for. > be accepted. Support for 64-bit native looks like it will be limited to > mingw, so I no longer see a future for gcc on cygwin. I don't know where you keep getting this conjecture from. Porting the Cygwin runtime library itself to x64 is a lot more work than getting a 64 bit MinGW environment working because Microsoft has already done the work in the case of a 64 bit MSVCRT, and because there is a lot more going on in the Cygwin runtime than in the Microsoft. But just because that porting work hasn't happened yet doesn't mean it won't eventually. Moreover, from the standpoint of gcc the two targets share virtually all the same code and there is very little substantial difference between them aside from miscellaneous specs file differences and driver bits, so once that porting of the Cygwin runtime happens there should be minimal work left on the gcc side. Brian
Re: "__throw_logic_error" abort, but print no error message out
2008/11/12 Bernd Roesch:
>
> But in libstdc++v3/src/functexcept.cc
>
> void
> __throw_logic_error(const char*)
> { std::abort(); }
>
> this call abort and there is no string print out, because abort get no
> Parameter as far i see.
>
> How can this work ?
It works by calling abort(), as intended.
If you take another look in functexcept.cc you'll see that when
__EXCEPTIONS is defined the following definition is used:
void
__throw_logic_error(const char* __s)
{ throw logic_error(_(__s)); }
This allows the library to call __throw_logic_error without caring
whether the target supports exceptions, or whether they have been
disabled with -fno-exceptions. If exceptions are enabled
__throw_logic_error will throw std::logic_error, otherwise it will
call abort().
It seems that the 68k amigaos port does not support exceptions, or
your GCC was configured without support for exceptions.
Hope that helps,
Jonathan
Re: Cygwin support
Andrew Haley wrote: > So do that, then. Where's the problem? I suppose it's not a problem if the alternative is no plugin support at all. It just seems a little ugly for the plugin author to have to distribute 'n' trivially different but substantially identical copies of their plugin binary for Windows users where a single file suffices for users of ELF systems. (And I'm sure that the required build-system magic to cope with that will not be particularly pretty.) Brian
Re: Cygwin support
On Fri, 14 Nov 2008, Brian Dessent wrote: > Andrew Haley wrote: > > > So do that, then. Where's the problem? > > I suppose it's not a problem if the alternative is no plugin support at > all. It just seems a little ugly for the plugin author to have to > distribute 'n' trivially different but substantially identical copies of > their plugin binary for Windows users where a single file suffices for > users of ELF systems. (And I'm sure that the required build-system > magic to cope with that will not be particularly pretty.) As I understand it, there is an alternative - put all the shared code in a DLL on Windows if configuring with plugins enabled, and link both the plugins and cc1, cc1plus etc. with that DLL. If people wish to enable plugins on Windows I see no reason for them not to implement this. (And the basic build support for building plugins and taking accounts of host differences would hopefully be provided with GCC for people to copy into their plugins.) -- Joseph S. Myers [EMAIL PROTECTED]
Invalid code generated for Coldfire target
Hello all,
I tracing bug in GCC for Coldfire target, but I end in dead water and
I need some help from real experts :).
Both gcc 4.4 and 4.3 have same problem
GCC miscompile this small test case.
//-
//m68k-elf-gcc -save-temps -da -fdump-tree-all -fdump-ipa-all -c test.c -o
test.o
void dummy(char *arg);
static void test1(void)
{
char tmp[2] = "0";
}
void test2(void)
{
dummy("0");
}
//--
The file is compiled to:
#NO_APP
.file "test.c"
.section.rodata
.LC0:
.string "0"
.text
.align 2
.type test1, @function
test1:
link.w %fp,#-4
lea .LC0,%a0
move.w (%a0),-2(%fp)
unlk %fp
rts
.size test1, .-test1
.align 2
.globl test2
.type test2, @function
test2:
link.w %fp,#0
move.l %a0,-(%sp) <-- note: a0 is used uninitialized here
jsr dummy
addq.l #4,%sp
unlk %fp
rts
.size test2, .-test2
.ident "GCC: (GNU) 4.4.0 20081031 (experimental)"
And relevant part of RTL after expand pass:
;; Function test1 (test1)
;; Generating RTL for gimple basic block 2
;; tmp ={v} "0";
(insn 5 4 0 test.c:8 (set (mem/s/c:HI (plus:SI (reg/f:SI 26 virtual-stack-vars)
(const_int -2 [0xfffe])) [0 tmp+0 S2 A16])
(mem/s:HI (symbol_ref/f:SI ("*.LC0") [flags 0x2] ) [0 S2 A8])) -1 (nil))
;; Function test2 (test2)
;; Generating RTL for gimple basic block 2
;; dummy (&"0"[0]);
<--- bad insn here -
(insn 5 4 6 test.c:15 (set (mem/f/i:SI (pre_dec:SI (reg/f:SI 15 %sp)) [0 S4
A16])
(reg:SI 8 %a0)) -1 (nil))
<--
(call_insn 6 5 7 test.c:15 (call (mem:QI (symbol_ref:SI ("dummy") [flags 0x41]
) [0 S1 A8])
(const_int 4 [0x4])) -1 (nil)
(nil))
(insn 7 6 0 test.c:15 (set (reg/f:SI 15 %sp)
(plus:SI (reg/f:SI 15 %sp)
(const_int 4 [0x4]))) -1 (nil))
After some debugging, I found cause of this bug, but proper solution is
not clear for me. When "char tmp[2] = "0";" is compiled, the function
"output_constant_def"
is called and proper insn is stored into cache:
(gdb) call debug_rtx(desc->rtl)
(mem/s:HI (symbol_ref/f:SI ("*.LC0") [flags 0x2] ) [0
S2 A8])
Later, in ira pass, this insn is spitted to this (Coldfire has no memory to
memory move):
Reloads for insn # 5
Reload 0: reload_in (SI) = (symbol_ref/f:SI ("*.LC0") [flags 0x2] )
ADDR_REGS, RELOAD_FOR_INPUT (opnum = 1), inc by 2
reload_in_reg: (symbol_ref/f:SI ("*.LC0") [flags 0x2] )
reload_reg_rtx: (reg:SI 8 %a0)
...
(note 2 3 14 2 NOTE_INSN_FUNCTION_BEG)
(insn 14 2 5 2 test.c:7 (set (reg:SI 8 %a0)
(symbol_ref/f:SI ("*.LC0") [flags 0x2] )) 38
{*movsi_cf} (nil))
(insn 5 14 13 2 test.c:7 (set (mem/s/c:HI (plus:SI (reg/f:SI 14 %a6)
(const_int -2 [0xfffe])) [0 tmp+0 S2 A16])
(mem/s:HI (reg:SI 8 %a0) [0 S2 A8])) 41 {*m68k.md:906} (nil))
;; End of basic block 2 -> ( 1)
;; lr out 14 [%a6] 15 [%sp] 24 [%argptr]
The first insn is newly allocated, but second one overwrites original insn.
>From local point of view, this is still OK, but this corrupt the
>output_constant_def
cache (cache holds pointer to overwritten insn. So every
next access to "0" constat returns
(mem/s:HI (reg:SI 8 %a0) [0 S2 A8])) 41 {*m68k.md:906} (nil))
and not
(symbol_ref/f:SI ("*.LC0") [flags 0x2] )) 38
{*movsi_cf} (nil))
But how to fix this? By my mean, the cache must hold own immutable copy of insn.
But im not gcc expert, so I need help with proper solution. Is this patch OK?
Any other solution?
--- varasm.c.orig 2008-11-14 18:04:27.693643900 +0100
+++ varasm.c2008-11-14 17:58:06.522748300 +0100
@@ -3245,7 +3245,7 @@
}
maybe_output_constant_def_contents (desc, defer);
- return desc->rtl;
+ return copy_rtx (desc->rtl);
}
/* Subroutine of output_constant_def: Decide whether or not we need to
-
Moreover, this can be common problem on more places (at least at
gen_rtx_CONST_INT).
Ohh, and sorry for my english.
Many thanks
Michal Meloun
Re: Endianess attributes
On Thu, Nov 13, 2008 at 11:46:04PM +, Paul Brook wrote: > On Thursday 13 November 2008, Michael Meissner wrote: > > On Thu, Nov 13, 2008 at 09:14:06PM +0100, Paul Chavent wrote: > > > Hi. > > > > > > I wonder why there aren't any endianess attributes ? > > > > > > For example we could write this : > > > int x __attribute__ ((endianess (lil))) = 0; > > > > > > Is it a silly suggestion ? > > > No one need it ? > > > Is it a bad design need ? > > > > > > Could someone give me some information ? > > > > One of the problems has been you often times lose the endianess information > > in the rtl phases, and when you recreate a MEM, it might be for the wrong > > endianess. The memory attributes that keep track of const, volatile (and > > soon named address support) are probably sufficient so that may not be as > > much of a problem nowadays. > > The biggest problem is probably that you really what the attribute to apply > to > pointers and types, not variables. In the example above you want to be able > to do p = &x; *p = 42; and have it DTRT. It's the same problem that you have > with taking the address of __attribute__((packed)) stricture members[1]. Yes, that has been the problem the last couple of times an endianess attribute has been proposed. > Last time I checked gcc didn't have any real support for different types of > pointer, so it's quite a bit more work than you might expect to implement > this feature. I'm currently working on finishing patches that Ben Elliston wrote to add support for named address spaces to GCC. Named addresses come from a draft proposal from the ISO WG14 committee (the C standard committee). For example on the SPU, the __ea keyword would allow you to declare pointers and data items in the host address as opposed to the local it allows you to add new attributes that bind like const and volatile. So while named address spaces solves a somewhat different problem, it touches a lot of the places in the RTL backend that would be needed to be modified for endianess. I do think if endianess is added, it really needs to be understood at the gimple level, so that optimizations can take this into effect. -- Michael Meissner, IBM 4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA [EMAIL PROTECTED]
Re: Cygwin support
"Joseph S. Myers" wrote: > As I understand it, there is an alternative - put all the shared code in a > DLL on Windows if configuring with plugins enabled, and link both the > plugins and cc1, cc1plus etc. with that DLL. If people wish to enable The problem with that approach is that people have so far said they want access to every aspect of the compiler from within the plugin, i.e. to poke and prod at the full symbol table, without being tied down by a limited, designated access route of a plugin API. This means you'd have to move essentially everything into this mega-DLL, leaving cc1 and friends as merely stubs that set a flag and then call into the DLL never to return, since anything left in cc1 would not be accessible from the plugin. That would present a problem to packagers. Since the code for all the language backends would be in this one mega-DLL, it would be impossible to install one language's compiler without installing all of them. Sure, you could still split it up into separate packages for the sake of the other runtime library support components and headers, but the user would still be paying the price in terms of disk and memory consumption of this mega-DLL that supports all languages when only using one of them. Of course this would only happen if you enabled plugin support, but from the standpoint of the packager/disto role you wouldn't want to ship a plugin-disabled gcc because then your users would have to go to the trouble of building gcc themselves from source if they wanted to try a plugin. Not having to do that is supposed to be one of the major reasons for developing plugins in the first place. So you end up with all users paying the cost of the entire compiler suite condensed into this monolithic chunk even if only a small fraction of users are interested in trying a plugin. Brian
gcc-4.4-20081114 is now available
Snapshot gcc-4.4-20081114 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20081114/ 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 revision 141871 You'll find: gcc-4.4-20081114.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20081114.tar.bz2 C front end and core compiler gcc-ada-4.4-20081114.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20081114.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20081114.tar.bz2 C++ front end and runtime gcc-java-4.4-20081114.tar.bz2 Java front end and runtime gcc-objc-4.4-20081114.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20081114.tar.bz2The GCC testsuite Diffs from 4.4-20081107 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: [ping] Re: m32c: pointer math vs sizetype again
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/execute/loop-ivopts-1.c execution, -O3 > -fomit-frame-pointer -funroll-loops Ok. I'll think of a "complete" patch and bootstrap, test and install it. Richard.
