Jack Howarth <[EMAIL PROTECTED]> wrote:
> What exactly is the implication of having a hundred or more of this in
> an application being built with gcc/g++ 4.x at -O3? Does it only risk
> random crashes in the generated code or does it also impact the
> quality
> of the generated code in terms of e
J.C. wrote:
*** gcc-4.0-20051124/gcc/config/i386/i386.c Mon Nov 7 18:55:03 2005
--- gcc-4.0-20051201/gcc/config/i386/i386.c Thu Dec 1 01:53:01 2005
! #if defined(HAVE_GAS_HIDDEN) && defined(SUPPORTS_ONE_ONLY)
! #if defined(HAVE_GAS_HIDDEN) && (SUPPORTS_ONE_ONLY - 0)
Why did he remove
Giovanni,
I'll see what I can do in terms of profiling the xplor-nih code
with Shark on MacOS X. However in the near term, I would strongly
urge the gcc developers to backport the changes necessary to have
-Wstrict-aliasing issue warnings for c++ in gcc 4.1. I rebuilt
xplor-nih under gcc trunk
Shouldn't the compiler behave in the following way, concerning the signedness
of pointer arguments?
void f (long *l, signed long *sl, unsigned long *ul);
// - Make NO assumptions about the signedness of *l and accept long,
//slong and ulong without a warning
// - treat *sl as signed l
> > > So, in short, my questions are: is gmp-4.1.4 supposed to work on
> > > ia64-hpux?
> > >
> > > No, it is not. It might be possible to get either the LP64 or
> > > the ILP32 ABI to work, but even that requires the workaround you
> > > mention. Don't expect any HP compiler to compile GMP c
On Mon, Dec 05, 2005 at 07:57:43AM -0800, Steve Ellcey wrote:
> > > > So, in short, my questions are: is gmp-4.1.4 supposed to work on
> > > > ia64-hpux?
> > > >
> > > > No, it is not. It might be possible to get either the LP64 or
> > > > the ILP32 ABI to work, but even that requires the work
On Mon, Dec 05, 2005 at 03:27:56PM +0100, [EMAIL PROTECTED] wrote:
> Shouldn't the compiler behave in the following way, concerning the signedness
> of pointer arguments?
>
> void f (long *l, signed long *sl, unsigned long *ul);
"long" and "signed long" are the same type. You are confused abou
Oh right, what I really meant was 'char' instead of 'long'.
In fact I just took the type from the referenced article. Sorry for that.
So am I right that the compiler should distinguish between char, signed char
and unsigned char in the proposed way?
>
> "long" and "signed long" are the same typ
Is there some place where all the existing forms of strict-aliasing
warnings are documented? So far I have only seen the error...
dereferencing type-punned pointer will break strict-aliasing rules
when building c++ code with gcc trunk (4.2). I am wondering how many other
types of warnings ca
Jack Howarth writes:
> My second question is how univeral are the strict-aliasing
> rules used by gcc?
They are applicable to every compiler that implements ISO C++. In
other words, code that violates aliasing constrains is not legal C++.
> In other words, is it safe to say that by corr
On Dec 5, 2005, at 12:03 AM, Giovanni Bajo wrote:
Jack Howarth <[EMAIL PROTECTED]> wrote:
What exactly is the implication of having a hundred or more of this in
an application being built with gcc/g++ 4.x at -O3? Does it only risk
random crashes in the generated code or does it also impact the
q
Mark Mitchell <[EMAIL PROTECTED]> writes:
> There is one advantage I see in the LTO design over LLVM's design. In
> particular, the LTO proposal envisions a file format that is roughly at
> the level of GIMPLE. Such a file format could easily be extended to be
> at the source-level version of Tr
[EMAIL PROTECTED] (Jack Howarth) writes:
> Where exactly are the compiler flags new to gcc 4.1.0 described.
http://gcc.gnu.org/gcc-4.1/changes.html
Ian
On Saturday 03 December 2005 20:43, Mark Mitchell wrote:
> There is one advantage I see in the LTO design over LLVM's design. In
> particular, the LTO proposal envisions a file format that is roughly at
> the level of GIMPLE. Such a file format could easily be extended to be
> at the source-level
Steven Bosscher <[EMAIL PROTECTED]> writes:
| On Saturday 03 December 2005 20:43, Mark Mitchell wrote:
| > There is one advantage I see in the LTO design over LLVM's design. In
| > particular, the LTO proposal envisions a file format that is roughly at
| > the level of GIMPLE. Such a file format
Hi
I have a question. Consider this code:
#include
void global_init();
class A {
public:
int i;
A() : i(10) {
global_init();
}
};
const A obj;
void global_init() {
std::cout << "obj.i = " << obj.i << std::endl;
}
int main() {
return EXIT_SUCCESS;
}
Here, global_init() is a
On Dec 5, 2005, at 11:48 AM, Steven Bosscher wrote:
On Saturday 03 December 2005 20:43, Mark Mitchell wrote:
There is one advantage I see in the LTO design over LLVM's
design. In
particular, the LTO proposal envisions a file format that is
roughly at
the level of GIMPLE. Such a file format
On Dec 4, 2005, at 3:09 PM, Jack Howarth wrote:
I have noticed that there was a significant speed regression in the
c++ code generation between gcc 3.3 and gcc 4.0.x.
Gotta wonder if changing the inlining parameters would help you.
Hello all,
Sorry if this is off-topic; there's not a mailing list described for
this kind of issue.
I have a problem with making an email change for my bugzilla account.
The old email address no longer exists, so bugzilla won't allow me to
update my account to the new email address (because
Mike,
Do you mean using -fno-threadsafe-statics or do you have any other
inlining changes in mind?
Jack
> On Mon, Dec 05, 2005 at 07:57:43AM -0800, Steve Ellcey wrote:
> > > > > So, in short, my questions are: is gmp-4.1.4 supposed to work on
> > > > > ia64-hpux?
> > > > >
> > > > > No, it is not. It might be possible to get either the LP64 or
> > > > > the ILP32 ABI to work, but even that requi
On Dec 5, 2005, at 9:53 AM, [EMAIL PROTECTED] wrote:
Oh right, what I really meant was 'char' instead of 'long'.
In fact I just took the type from the referenced article. Sorry for
that.
So am I right that the compiler should distinguish between char,
signed char
and unsigned char in the p
On 12/5/05, Chris Lattner <[EMAIL PROTECTED]> wrote:
> That said, having a good representation for source-level exporting is
> clearly useful. To be perfectly clear, I am not against a source-
> level form, I am just saying that it should be *different* than the
> one used for optimization.
Debug
On Mon, 5 Dec 2005, Mike Stump wrote:
> On Dec 5, 2005, at 9:53 AM, [EMAIL PROTECTED] wrote:
> > Oh right, what I really meant was 'char' instead of 'long'.
> > In fact I just took the type from the referenced article. Sorry for that.
> >
> > So am I right that the compiler should distinguish bet
On Dec 5, 2005, at 2:33 PM, Jack Howarth wrote:
Do you mean using -fno-threadsafe-statics or do you have any other
inlining changes in mind?
That option mentions the word inline 0 times, while interesting and
worthwhile to test, I did mean these (from the man page):
-finline-limit=n
an
On Tuesday 06 December 2005 00:23, Jim Blandy wrote:
> Debug information describes two things: (...snip...)
> Keeping the two representations separate (which I could easily
> see being beneficial for optimization) shifts that burden onto some
> new party which isn't being discussed, and which will
Has GCC 3.4.5 been officially released? I don't recall seeing an
announcement in gcc@gcc.gnu.org or [EMAIL PROTECTED] and when I
looked on the main GCC page and I see references to GCC 3.4.4 but not
3.4.5. But I do see a 3.4.5 download on the GCC mirror site that I
checked and I see a gcc_3_4_5_
On Dec 5, 2005, at 3:25 PM, Joseph S. Myers wrote:
OBringing bit-fields into the matter is just confusing things since
you
can't have pointers to bit-fields, but anyway char is not in a
comma-separated set with signed char or unsigned char and for
DR#315 it
was proposed to say that whether ch
Adam Nemet wrote:
Now if I am correct and this last thing is really a bug then the
obvious question is whether it has anything to do with the more
restrictive form for conditional branches on MIPS64? And of course if
I fix it then whether it would be OK to lift the mode restrictions in
the condi
Jack Howarth wrote:
Is there some place where all the existing forms of strict-aliasing
warnings are documented? So far I have only seen the error...
We don't have such documentation unfortunately. There are 3 errors.
There is the one you have seem. There is a similar one for incomplete
Mohamed Ghorab wrote:
linux, it tries to compile some files but outputs the following error:
/usr/include/c++/3.2.2/bits/fpos.h:60: 'streamoff' is used as a type,
but is not defined as a type.
This is a more appropriate question for the gcc-help list than the gcc
list. The gcc list is primari
Eric Weddington wrote:
I have a problem with making an email change for my bugzilla account.
sysadmin requests can be sent to [EMAIL PROTECTED]
--
Jim Wilson, GNU Tools Support, http://www.specifix.com
Ian Lance Taylor wrote:
> In short, while this is an important issue, I don't see it as strongly
> favoring either side. What it means, essentially, is that LTO is not
> quite as much work as it might otherwise seem to be, because we are
> going to do some of the work anyhow. So when considering
Steven Bosscher wrote:
> On Saturday 03 December 2005 20:43, Mark Mitchell wrote:
>
>>There is one advantage I see in the LTO design over LLVM's design. In
>>particular, the LTO proposal envisions a file format that is roughly at
>>the level of GIMPLE. Such a file format could easily be extended
Shaun Jackman wrote:
The following code snippet produces code that loads a register, r5,
from memory, but never uses the value.
You can report things like this into our bugzilla database, marking them
as enhancement requests. We don't keep track of issues reported to the
gcc list.
I took a
Chris Lattner wrote:
> I totally agree with Steven on this one. It is *good* for the
> representation hosting optimization to be different from the
> representation you use to represent a program at source level. The two
> have very different goals and uses, and trying to merge them into one
On Dec 5, 2005, at 5:27 PM, Mark Mitchell wrote:
Steven Bosscher wrote:
IMVHO dumping for "export" and front-end tools and for the optimizers
should not be coupled like this. Iff we decide to dump trees, then I
would hope the dumper would dump GIMPLE only, not the full front end
and middle-end
On Dec 5, 2005, at 5:43 PM, Mark Mitchell wrote:
Chris Lattner wrote:
I totally agree with Steven on this one. It is *good* for the
representation hosting optimization to be different from the
representation you use to represent a program at source level.
The two
have very different goals a
Giovanni Bajo wrote:
Bernd,
I read you're interested in code-size optimizations. I'd like to point you
to this patch:
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00554.html
which was never finished nor committed (I don't know if RTH has a newer
version though). This is would be of great help f
> I don't see anything about Tree that I find inherently awful; in fact,
> it looks very much like what I see in other front ends. There are
> aspects I dislike (overuse of pointers, lack of type-safety, unncessary
> copies of types), but I couldn't possibly justify changing the C++
> front-end, f
Chris Lattner wrote:
[Up-front apology: If this thread continues, I may not be able to reply
for several days, as I'll be travelling. I know it's not good form to
start a discussion and then skip out just when it gets interesting, and
I apologize in advance. If I'd been thinking better, I would
The m32c-elf port uses PSImode for pointers, which, for m32c (vs m16c)
only have 24 bits of precision in a 32 bit word. The address
registers are 24 bit unsigned registers.
The "-1" sentinal used for CTOR_LIST is not a representable address,
and the code gcc ends up using compares 0x (th
> The "-1" sentinal used for CTOR_LIST is not a representable address,
> and the code gcc ends up using compares 0x (the -1) with
> 0x00ff (what ends up in $a0) and it doesn't match.
>
> Suggestions?
Use ELF .init_array/.fini_array
Paul
Well I tried a few different builds of xplor-nih tonight with the
following optimization flags for the gcc and g++ compilers...
testsuite in seconds
xplorpython tcl
-O3 -ffastma
Steven Bosscher <[EMAIL PROTECTED]> writes:
[...]
| I'd be surprised if there a compiler exists that runs optimizations
| on EDG's C++ specific representation.
CFront was very good at implementing optimizations "native" compilers
could not match at the time (or with 2 years lag). KCC did a grea
Steve Ellcey <[EMAIL PROTECTED]> writes:
| Has GCC 3.4.5 been officially released?
Yes, tarballs are on gcc.gnu.org and ftp.gnu.org since Dec 1st. Only
official announcement is missing.
[...]
| I also notice we have a "Releases" link under "About GCC" in the top
| left corner of the main GCC p
> Steve Ellcey <[EMAIL PROTECTED]> writes:
>
> | Has GCC 3.4.5 been officially released?
>
> Yes, tarballs are on gcc.gnu.org and ftp.gnu.org since Dec 1st. Only
> official announcement is missing.
What are you waiting for?
--
Kaveh R. Ghazi [EMAIL PROTECTED]
I want to warn at the use of unadorned "NULL" as sentinel value in C
programs. Why is this option (-Wstrict-null-sentinel) restricted to
C++ programs? Or is there some other way to get this warning?
-chris
(Please 'cc'; not subscribed)
Steven Bosscher wrote:
> What makes EDG so great is that it represents C++ far closer to the
> actual source code than G++ does.
I know the EDG front-end very well; I first worked with it in 1994, and
I have great respect for both the EDG code and the EDG people.
I disagree with your use of "far
hi mark,
On Mon, 2005-12-05 at 21:33 -0800, Mark Mitchell wrote:
> I'm not saying that having two different formats is necessarily a bad
> thing (we've already got Tree and RTL, so we're really talking about two
> levels or three), or that switching to LLVM is a bad idea, but I don't
> think ther
50 matches
Mail list logo
