Hi All,
Can you please let me know why GCC does not crib when we try to free a static
array?
main ()
{
char array[100];
free (array);
}
The above code compiles without any hitch.
Thanks,
Sajish.
I would like to see that GCC define a macro in the case it is being used to
compile a program. Currently there is a __GNUC__ macro defined by the GNU C
preprocessor CPP. That does not suit the need. As the CPP Manual says:
__GNUC__ is "defined by all GNU compilers that use the C preprocessor"
On Fri, Jun 27, 2008 at 03:52:22PM +0530, Mohamed Shafi wrote:
> Hello all,
>
> For the 16-bit target that i porting now to gcc 4.1.2 doesn't have any
> branch instructions. It only has jump instructions. For comparison
> operation it has this instruction:
>
> if cond Rx Ry
> execute this insn
>
On Mon, Jun 30, 2008 at 11:04:43AM -0400, David Edelsohn wrote:
> > Andreas Jaeger writes:
>
> Andreas> So, it means that --relax is not the right solution for the problem.
>
> Andreas> I'll continue with the STAGE1_CFLAG flag but if anybody else wants
> me to
> Andreas> test something, plea
Snapshot gcc-4.1-20080630 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20080630/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Mon, Jun 30, 2008 at 01:59:19PM -0700, David VomLehn wrote:
> This sounds like really good stuff and, on first reading, it all seems to
> make sense to me. My only real concern is documentation of these changes.
FWIW, I'll be posting our version of this project shortly, and it
includes an ABI
On Mon, Jun 30, 2008 at 11:09:28PM +0200, Basile STARYNKEVITCH wrote:
>> /usr/src/Lang/basile-melt-gcc/gcc/doc//melt.texi:146: `Reference on MELT'
>> has no Up field (perhaps incorrect sectioning?).
You have to add it to the menu manually. Look at any of the other
included files for an example;
Hello all,
in the MELT branch (I just committed rev 137290)
http://gcc.gnu.org/wiki/MiddleEndLispTranslator
I have the attached melt.texi file in gcc/doc/
and my gcc/doc/gccint.texi file contains
@include c-tree.texi
@include tree-ssa.texi
@include melt.texi
@include loop.texi
@include rtl.
Art Haas wrote:
The build also failed on my sparc-sun-solaris2.10 system.
The mmap()/munmap() calls in these functions are the cause of the
problem.
I have a fix in the queue. There are some more failures.
Stay tuned.
Andreas
Hi,
When I encounter a FUNCTION_DECL, I want to access the node BIND_EXPR
where I can find the artificial declarations of the current functions
that the compiler adds. Following what the documentation says, I use the
macro DECL_SAVED_TREE which should point to the node BIND_EXPR (used as
follows,
Hi.
This mornings bootstrap failed on my Solaris machine due to the recent
introduction of the various C++ compatibility warnings. Here's the
snippet from the build log where things failed:
/export/home/arth/gnu/gcc-0630/./prev-gcc/xgcc
-B/export/home/arth/gnu/gcc-0630/./prev-gcc/
-B/usr/local/i3
> Andreas Jaeger writes:
Andreas> So, it means that --relax is not the right solution for the problem.
Andreas> I'll continue with the STAGE1_CFLAG flag but if anybody else wants me
to
Andreas> test something, please tell me,
Maybe Alan will have some insight about --relax not worki
David Edelsohn <[EMAIL PROTECTED]> writes:
>>> checking for suffix of object files... configure: error: in
>>> `/abuild/aj/gcc-tst/powerpc64-suse-linux-gnu/libgcc':
>>> configure: error: cannot compute suffix of object files: cannot compile
>>> See `config.log' for more details.
>
> This is
>> checking for suffix of object files... configure: error: in
>> `/abuild/aj/gcc-tst/powerpc64-suse-linux-gnu/libgcc':
>> configure: error: cannot compute suffix of object files: cannot compile
>> See `config.log' for more details.
This is the friendly way the GCC build process reports th
[EMAIL PROTECTED] writes:
> Selon Andreas Jaeger <[EMAIL PROTECTED]>:
>
>> This gets me a bit further but I do get later a build failure in
>> configure:
>>
>> checking for powerpc64-suse-linux-gnu-strip... strip
>> checking whether ln -s works... yes
>> checking for powerpc64-suse-linux-gnu-gcc..
Selon Andreas Jaeger <[EMAIL PROTECTED]>:
> This gets me a bit further but I do get later a build failure in
> configure:
>
> checking for powerpc64-suse-linux-gnu-strip... strip
> checking whether ln -s works... yes
> checking for powerpc64-suse-linux-gnu-gcc... /abuild/aj/gcc-tst/./gcc/xgcc
> -B
David Edelsohn <[EMAIL PROTECTED]> writes:
>> Andreas Jaeger writes:
>
> Andreas> I'm not a build machinery expert - if anybody has a patch, I'll
> happily test it,
> Andreas> I'm building on Linux/Powerpc64.
>
> Andreas> Adding the above line to rs6000/x-linux64 did not help me. Btw.
> Andr
Bingfeng Mei wrote:
> Sorry, I made a mistake. My local copy of mainline version (still 4.3.0
> 20080213) doesn't gave warning. I just updated my mainline GCC and it
> does give warning now.
I think that you'll find the release 4.3 version does too.
While we try to ensure that gcc warns whenever
Sorry, I made a mistake. My local copy of mainline version (still 4.3.0
20080213) doesn't gave warning. I just updated my mainline GCC and it
does give warning now.
-Original Message-
From: Andrew Haley [mailto:[EMAIL PROTECTED]
Sent: 30 June 2008 13:45
To: Bingfeng Mei
Cc: gcc@gcc.gnu.
Bingfeng Mei wrote:
> Hello,
>
> In following code, gcc (mainline version as well as previous versions)
> produces wrong code without giving any warning regarding strict aliasing
> violation.
>
> ~/work/trunk-x86/bin/gcc tst.c -O3 -o tst -Wstrict-aliasing=2
> ./tst
> barrier1
> Miscompilation
>
Hello,
In following code, gcc (mainline version as well as previous versions)
produces wrong code without giving any warning regarding strict aliasing
violation.
~/work/trunk-x86/bin/gcc tst.c -O3 -o tst -Wstrict-aliasing=2
./tst
barrier1
Miscompilation
If I compile with
~/work/trunk-x86/bin/
Hi Ho!
--- On Mon, 6/30/08, Mojmir Svoboda <[EMAIL PROTECTED]> wrote:
> i have registered gcc mailing list as [EMAIL PROTECTED]
> via web form,
> but my client was sending the requests as
> [EMAIL PROTECTED] when i fixed this
> everything seems
> to be working.
I am glad to hear that!
> thanks
Hello,
I am working on a research project in which I want to export a whole
syntax/semantic tree of a c++ program from the compiler. My current
solution is to use the -fdump-tree-all option and take the *.t00.tu
files (translation unit dump). I've hacked the gcc/tree-dump.c so the
exported graph is
> Andreas Jaeger writes:
Andreas> I'm not a build machinery expert - if anybody has a patch, I'll
happily test it,
Andreas> I'm building on Linux/Powerpc64.
Andreas> Adding the above line to rs6000/x-linux64 did not help me. Btw.
Andreas> we would need it for other files - like gnat1 - as w
24 matches
Mail list logo
