Test Only no reply
Test Only no reply
This merge brings over all the changes I made when I committed
the plugin patches to mainline.
There are a few patches that still need to be moved from plugins, but
they are not too big. I will get to those later this week.
Tested on x86_64.
2009-04-14 Diego Novillo
Merge with main
Dave makes a very important point, who to believe:
Certainly System header prototypes, but then the
file, line-number, and prototype which the implementation contradicts,
whenever.
mfg, Brian
Snapshot gcc-4.4-20090414 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090414/
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/branches
2009/4/14 Arthur Schwarz :
>
> And there are competitive compilers. Some with better messaging and better
> messaging resources at the very point where g++ is weakest. You might argue
> that they are 'better in what way?', but I think the real argument is in what
> ways can these other products
The issues grow ever more complex. Suppose that we're dealing with macro's,
some similarly named, and there's a typo. Suppose several layers of template
expansion are involved and nested deep within one there is some error. Suppose,
suppose ... .
The motivation is not to expand the problem do
2009/4/14 Kai Henningsen:
> aschwarz1...@verizon.net schrieb:
>>
>> Thanks Kai. I do have what I hope is a more specific subjective reason for
>> saying that I think the existing diagnostics should be changed.
>> Fundamentally, what is provided in the messaging is not an indication of
>> what is wr
2009/4/14 Arthur Schwarz:
> --- On Mon, 4/13/09, Joe Buck wrote:
>
> them all.
>>
>> Consider
>>
>> #include
>> struct Foo { int bar;};
>> int main() {
>> std::cerr << Foo();
>> }
>>
>> Try it, the result is ugly, and I often encounter this one
>
> (Personal opinion - not to be construed as wi
> > I have to define __STDC_EXT__ under all circumstances to get consistency
> > of the long long types in the 32-bit runtime. Previously, gcc for hpux
> > tried to mirror the behavior of the HP C compiler wrt long long types.
>
> Rather then define __STDC_EXT__ all the time I was looking at defi
On Tue, Apr 14, 2009 at 9:21 AM, wrote:
>
> Thanks Kai. I do have what I hope is a more specific subjective reason for
> saying that I think the existing diagnostics should be changed.
> Fundamentally, what is provided in the messaging is not an indication of what
> is wrong, but an indication
Hello,
* Roberto Bagnara wrote on Tue, Apr 14, 2009 at 06:58:01PM CEST:
> Richard Guenther wrote:
>> It seems to build and test ok on {i586,ia64,ppc,ppc64,s390,x86_64}-linux
>> but I get
>>
>> PASS: nnc_writepolyhedron1
>> /bin/sh: line 4: 29952 Segmentation fault ${dir}$tst
>> FAIL: memory1
aschwarz1...@verizon.net schrieb:
Thanks Kai. I do have what I hope is a more specific subjective reason for
saying that I think the existing diagnostics should be changed. Fundamentally,
what is provided in the messaging is not an indication of what is wrong, but an
indication of what is requ
manjunatha srinivasan writes:
> Is GCC is supporting sigma design board processors? If so which SMP
> processor series is supported. If GCC doesn't support how to enable
> the support for sigma design boards in GCC sources.
This sort of question should be sent to gcc-h...@gcc.gnu.org, not to
g.
Richard Guenther wrote:
On Tue, Apr 14, 2009 at 3:02 PM, Roberto Bagnara wrote:
We are pleased to announce the availability of PPL 0.10.1, a new release
of the Parma Polyhedra Library.
It seems to build and test ok on {i586,ia64,ppc,ppc64,s390,x86_64}-linux
but I get
PASS: nnc_writepolyhedro
On Tue, 2009-04-14 at 12:18 -0400, John David Anglin wrote:
> I have a patch to provide stdint.h on HP-UX that I have been testing.
> I have resolved the consistency issues with inttypes.h although there
> are some slightly wierd aspects. For example, I found "signed char" and
> "char" are inconsi
Attached is my change as it currently stands.
Dave
--
J. David Anglin dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Index: config.gcc
===
-
On Mon, Apr 13, 2009 at 05:10:23PM -0700, Dave Korn wrote:
> Joe Buck wrote:
>
> > And this, of course, means we have to define relevance. There are two
> > cases: the first is when we fail to choose an overload because of
> > ambiguity; there we can just report all of the choices that are tied f
On Tue, Apr 14, 2009 at 9:18 AM, John David Anglin
wrote:
> I have a patch to provide stdint.h on HP-UX that I have been testing.
> I have resolved the consistency issues with inttypes.h although there
> are some slightly wierd aspects. For example, I found "signed char" and
> "char" are inconsis
Thanks Kai. I do have what I hope is a more specific subjective reason for
saying that I think the existing diagnostics should be changed. Fundamentally,
what is provided in the messaging is not an indication of what is wrong, but an
indication of what is required to repair the fault. My object
I have a patch to provide stdint.h on HP-UX that I have been testing.
I have resolved the consistency issues with inttypes.h although there
are some slightly wierd aspects. For example, I found "signed char" and
"char" are inconsistent, yet characters are signed. The specification
of some types d
On Tue, 2009-04-14 at 15:50 +, Joseph S. Myers wrote:
> > Is there a standard way of having GCC provide a new header file
> > for a given platform?
>
> You'd create an alternative setting to "provide", "wrap" and "none", say
> "hpux", and add code to handle it. But you shouldn't need to do
On Tue, Apr 14, 2009 at 3:02 PM, Roberto Bagnara wrote:
>
> We are pleased to announce the availability of PPL 0.10.1, a new release
> of the Parma Polyhedra Library.
>
> This release includes several important improvements to PPL 0.10,
> among which is better portability (including the support fo
On Tue, 14 Apr 2009, Steve Ellcey wrote:
> On HP-UX 11.11 there is no stdint.h but I think we want to provide one.
> I tried setting use_gcc_stdint to "provide" but that doesn't work
> because HP-UX 11.11 already has typedefs in other header files for some
> of the things the GCC provided stdint.
>
> So I guess, yes, I'm asking Arthur to suggest rules
> of relevance that would
> enable the compiler to decide what kind of user error is
> implied by a given
> syntax error.
>
> cheers,
> DaveK
>
You're asking for a lot. I've never been accused of being smart (the quip
being,
Hi
Is GCC is supporting sigma design board processors? If so which SMP
processor series is supported. If GCC doesn't support how to enable
the support for sigma design boards in GCC sources.
Regards
Manjunatha Srinivasan N
I am working on the c99 stdint.h support for HP-UX. On HP-UX 11.23 and
11.31 where stdint.h exists I am setting use_gcc_stdint to "wrap" and
adding some hacks to inclhack.def and that seems to be working.
On HP-UX 11.11 there is no stdint.h but I think we want to provide one.
I tried setting use
Eli Zaretskii writes:
> 2009-04-14 Eli Zaretskii
>
> * configure.ac (setobjs, msdosdjgpp): Move a-priori setting of
> existing and required library functions to with_target_subdir
> section, so that the native build does detect them at configure
> time.
This is OK.
T
On Tue, 14 Apr 2009, Eli Zaretskii wrote:
> The following snippet from libiberty/Makefile.in:
>
> # needed-list is used by libstdc++. NEEDED is the list of functions
> # to include there. Do not add anything LGPL to this list; libstdc++
> # can't use anything encumbering.
Since thi
The following snippet from libiberty/Makefile.in:
# needed-list is used by libstdc++. NEEDED is the list of functions
# to include there. Do not add anything LGPL to this list; libstdc++
# can't use anything encumbering.
NEEDED = atexit calloc memchr memcmp memcpy memmove memset
The following snippet from libiberty/Makefile.in:
# needed-list is used by libstdc++. NEEDED is the list of functions
# to include there. Do not add anything LGPL to this list; libstdc++
# can't use anything encumbering.
NEEDED = atexit calloc memchr memcmp memcpy memmove memset
The current libiberty misconfigures itself for native DJGPP builds,
because it tries to avoid compiling and linking test programs, for
cross-compilation's sake. But the necessary bits that tell the
configure script what functions are available in the DJGPP library are
in the wrong place: the one t
Status
==
Release Candidate 1 has been released today. The branch remains
open under the usual release branch rules; it is open for regression
and documentation fixes only, but please be very conservative at this
point in deciding what changes are needed before the 4.4.0 release
and what can
We are pleased to announce the availability of PPL 0.10.1, a new release
of the Parma Polyhedra Library.
This release includes several important improvements to PPL 0.10,
among which is better portability (including the support for
cross-compilation), increased robustness, better packaging and s
GCC 4.4.0 release candidate 1 is now available at:
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4.0-RC-20090414/
Please test the tarballs there and report any problems to Bugzilla. CC me
on the bugs if you believe they are regressions from previous releases
severe enough that they should block the
Interim note:
Apparently, calling compile_file() more than once has not been done
before?
I am seeing many global variables in cgraphunit.c that need to
be reinitialized in this case.
Also, some static variables are defined locally in functions, e.g.
'first_analyzed' and 'first_analyzed_var' in cg
2009/4/14 梁�� :
> GCC4.1.2 on a Intel Xeon CPU
> The test program is test.c:
>
> extern int bar(short);
>
> int foo(short arg1, short arg2)
> {
> short res;
> res = arg1 + arg2;
> return bar(res);
> }
>
> Compiled with : gcc -fdump-tree-all -S test.c
> The resulting test.c.t02.original is :
> ;;
GCC4.1.2 on a Intel Xeon CPU
The test program is test.c:
extern int bar(short);
int foo(short arg1, short arg2)
{
short res;
res = arg1 + arg2;
return bar(res);
}
Compiled with : gcc -fdump-tree-all -S test.c
The resulting test.c.t02.original is :
;; Function foo (foo)
;; enabled by -tree-
38 matches
Mail list logo
