Hi:
I know GCC is a wonderful compiler collection. I like it and trust
it. But, I can't find any formal docs about Testing GCC, both unit
testing and integrat testing. I think, as a software, GCC should be
tested and own a test report.
Can someone give me some infomation about how the GCC wo
On Mon, 2007-07-23 at 19:00 -0700, Tim Prince wrote:
> Should we know which version of Paranoia this is?
It's the version having been integrated into the rtems source tree many
years ago:
http://www.rtems.org/cgi-bin/viewcvs.cgi/rtems/testsuites/samples/paranoia/paranoia.c
> or guess which fla
I recall one of the Ada developers mentioning that there
were patches available from another Mac OS X Ada project
which could be backported to gcc trunk to complete the
support for Ada on Mac OS X. I believe the issues were
related to the creation of shared libraries for Ada
on Darwin. Does any
[EMAIL PROTECTED] wrote:
Hi,
In analyzing the output of paranoia, Eric Norum
and I have noticed that when compiled at
default optimization levels, the results
are reported to have a flaw. When compiled
with no optimization, paranoia reports no flaws.
I tried this with RTEMS running on psim usi
Andrew Pinski wrote:
On 7/23/07, Joel Sherrill <[EMAIL PROTECTED]> wrote:
Given the age of paranoia (the version included
with RTEMS is from Cygnus circa 1993), does this
sound familiar or is this a new issue?
What happens if you use -mno-fused-madd option?
Same result for me using RTEMS on
On 7/23/07, Joel Sherrill <[EMAIL PROTECTED]> wrote:
Given the age of paranoia (the version included
with RTEMS is from Cygnus circa 1993), does this
sound familiar or is this a new issue?
What happens if you use -mno-fused-madd option?
Thanks,
Andrew Pinski
Hi,
In analyzing the output of paranoia, Eric Norum
and I have noticed that when compiled at
default optimization levels, the results
are reported to have a flaw. When compiled
with no optimization, paranoia reports no flaws.
I tried this with RTEMS running on psim using
gcc 4.2.1. RTEMS uses
Snapshot gcc-4.1-20070723 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070723/
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 7/23/07 3:45 PM, Matt Hargett wrote:
> Okay, thanks for the clarification! Is this something that will be addressed
> before GCC 4.3 is released? Interestingly, PC-Lint can only track the size of
> the dynamic array if the const qualifier is used on the size parameter.
Not that I know of.
Diego,
Thanks so much for the quick reponse! Some more questions below :)
On Monday 23 July 07 11:54:58 Diego Novillo wrote:
> On 7/23/07 2:44 PM, Matt Hargett wrote:
> > #include
> >
> > int main(int argc, char **argv)
> > {
> > size_t size = 16;
> > char p[size];
> > p[
On Mon, Jul 23, 2007 at 08:56:11PM +0200, Jan Hubicka wrote:
> > On Mon, Jul 23, 2007 at 07:33:46PM +0200, Jan Hubicka wrote:
> > It's mostly supposed to be a space optimization. We get e.g. the
> > names and (sometimes) types of local variables from the origin copy,
> > and only need a location a
"Dave Korn" <[EMAIL PROTECTED]> writes:
> On 23 July 2007 19:13, Ian Lance Taylor wrote:
>
> > "Venkatesan Jeevanandam" <[EMAIL PROTECTED]> writes:
> >
> >> DISCLAIMER:
> >> This message (including attachment if any) is confidential and may be
> >> privileged.
>
> > Please do not include this
> On Mon, Jul 23, 2007 at 07:33:46PM +0200, Jan Hubicka wrote:
> > The particular problem here is that the abstract origin pointers points
> > to the blocks within functions they was constructed from. These are used
> > by dwarf2out to output abstract copy of the function and then use it
> > as a d
On 7/23/07 2:44 PM, Matt Hargett wrote:
> #include
>
> int main(int argc, char **argv)
> {
> size_t size = 16;
> char p[size];
> p[16] = 0;
> }
>
>
> --
>
> #include
>
> int main(int argc, char **argv)
> {
> char p[16];
> p[16] = 0;
> }
>
> --
In th
Hi,
I'll be teaching a class this week on code analysis and I wanted to
demonstrate GCC 4.3's new array bounds analysis capabilities.
Unfortunately, I can't seem to get the new array bounds warnings to appear in
gcc-4.3-20070720 using the commandline of '-O2 -Warray-bounds' with either of
the f
On 23 July 2007 19:13, Ian Lance Taylor wrote:
> "Venkatesan Jeevanandam" <[EMAIL PROTECTED]> writes:
>
>> DISCLAIMER:
>> This message (including attachment if any) is confidential and may be
>> privileged.
> Please do not include this sort of disclaimer in messages sent to
> mailing lists host
Basile STARYNKEVITCH <[EMAIL PROTECTED]> writes:
> Given that my copyright assignment is ok (and I already got small
> patches accepted) what is the way to make branches, in particular with
> GPLv3? I don't want to mess with copyrights & license files, so I am
> waiting a few weeks for these quest
"Venkatesan Jeevanandam" <[EMAIL PROTECTED]> writes:
> DISCLAIMER:
> This message (including attachment if any) is confidential and may be
> privileged. Before opening attachments please check them for viruses and
> defects. MindTree Consulting Limited (MindTree) will not be responsible for
> a
On Mon, Jul 23, 2007 at 07:33:46PM +0200, Jan Hubicka wrote:
> The particular problem here is that the abstract origin pointers points
> to the blocks within functions they was constructed from. These are used
> by dwarf2out to output abstract copy of the function and then use it
> as a destination
Hello Ben,
* Ben Elliston wrote on Sat, Jul 21, 2007 at 10:33:54PM CEST:
> Before I open a PR for this, I'd like to make sure I'm not doing
> anything wrong .. :-)
I don't think you are.
> It used to be the case that the Cygnus top-level configure script would
> pass any configure options to all
Hi,
to add some extra data
> At the summit, I discovered two things about the internal representation
> of debugging information:
>
> 1) According to Honza, the instances of the BLOCK tree type take 30% of
> the space in a compilation.
this large portion appears on C++ testcases doing a lot of in
> We explicitly pull out initializers from variables that are:
> /* Pull out any truly constant values. */
> if (TREE_READONLY (rhs)
> && TREE_STATIC (rhs)
> && DECL_INITIAL (rhs)
> && valid_gimple_expression_p (DECL_INITIAL (rhs)))
>ret
Dmitry Antipov wrote:
Hello all,
I have a question about possible cooperation between the compiler and
hypothetical
garbage collector. Unfortunately, my experience around GCC internals is
too small,
so I would like to ask compiler specialists before re-inventing an ugly
bicycle...
The most
Dmitry Antipov writes:
>
> with write barrier inside ? The short answers are:
> 1) If 'struct obj' has 100 trapped members, having 100 set_XXX functions
> or macros just to set the fields is ugly;
> 2) Migration from explicit memory management to garbage collection - if you
> h
Hello all,
I have a question about possible cooperation between the compiler and
hypothetical
garbage collector. Unfortunately, my experience around GCC internals is too
small,
so I would like to ask compiler specialists before re-inventing an ugly
bicycle...
The most non-straightforward garb
On Sun, Jul 22, 2007 at 11:46:59PM +0200, Gerald Pfeifer wrote:
> On Thu, 5 Jul 2007, Tom Tromey wrote:
> > In this case the library has to follow the external project policy:
> >
> > http://gcc.gnu.org/ml/gcc/2006-03/msg00558.html
> >
> > It at least needs an entry on the "coding conventions
Kai Tietz <[EMAIL PROTECTED]> writes:
> Hmm... Ok, but why in stor-layout.c in initialize_sizetypes () SImode is
> explicit used ?
See stor-layout.c:set_sizetype and c-common.c:c_common_nodes_and_builtins.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxf
Andreas Schwab <[EMAIL PROTECTED]> wrote on 23.07.2007 15:22:34:
> Kai Tietz <[EMAIL PROTECTED]> writes:
>
> > may this is a stupid question, but why is the type "sizetype" used in
> > i386.c as a pointer type equivalent in TARGET_64BIT case ? The
variable
> > "sizetype" has SImode, but on 64-
Kai Tietz <[EMAIL PROTECTED]> writes:
> may this is a stupid question, but why is the type "sizetype" used in
> i386.c as a pointer type equivalent in TARGET_64BIT case ? The variable
> "sizetype" has SImode, but on 64-bit I would expected DImode instead.
sizetype is defined from SIZE_TYPE, whi
Hi,
may this is a stupid question, but why is the type "sizetype" used in
i386.c as a pointer type equivalent in TARGET_64BIT case ? The variable
"sizetype" has SImode, but on 64-bit I would expected DImode instead. May
somebody can give me the answer for that.
Thanks in advance,
i.A. Kai Tie
ok, thanks, sunzir.
On Sun, Jul 22, 2007 at 07:37:43PM -0400, Kenneth Zadeck wrote:
> I find it somewhat surprising that we need so many blocks. My
> experience is that in real programs few blocks actually have any local
> declarations and it appears that we do not bother to get rid of the
> blocks that have no local
Sunzir Deepur wrote:
On 7/22/07, Robert Dewar <[EMAIL PROTECTED]> wrote:
Sunzir Deepur wrote:
is there a meaning for control flow graphs of assembly files (.S)
(e.g. those that are emitted using -fdump-rtl-*) ?
this is neither possible nor desirable.
Ok. but is there a way to produce CFG d
On 7/23/07 7:07 AM, Sunzir Deepur wrote:
> Ok. but is there a way to produce CFG data out of assembly files ?
You would have to modify the assembler and it would have to be processor
specific. GCC just emits assembly as text output.
On 7/22/07, Robert Dewar <[EMAIL PROTECTED]> wrote:
Sunzir Deepur wrote:
> is there a meaning for control flow graphs of assembly files (.S)
> (e.g. those that are emitted using -fdump-rtl-*) ?
this is neither possible nor desirable.
Ok. but is there a way to produce CFG data out of assembly
On 21 July 2007 18:17, Jerry DeLisle wrote:
> I experimented with your simple Hello World in C running on Cygwin, writing
> to CONOUT$. It does not error out, but does nothing.
>
> On the gfortran side it creates a file named CONOUT$.
>
> I would like to intercept this file name on mingw and cy
36 matches
Mail list logo
