(as you did) without
attacking anyone.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
generating zillions of zero-initializations to
contiguous memory, rather than using memset, or an inline loop, that
seems unfortunate. Would you please file a bug report?
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
structures, which add
up to a ton of stack space.
I realize that we need a full bug report to be sure, though.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
be hard to stop emitting the warning without making that
assumption, and it may not be easy to make the assumption, but still
avoid the expensive masking operations.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
know of problems that you think should prevent a 4.1.2 release,
particularly critical regressions from earlier 4.1.x releases, please
make sure that there is a Bugzilla PR for the issue of concern to you,
and send an email to me with a pointer to the PR.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL
tbp wrote:
On 1/28/07, Mark Mitchell [EMAIL PROTECTED] wrote:
Certainly, if we're generating zillions of zero-initializations to
contiguous memory, rather than using memset, or an inline loop, that
seems unfortunate. Would you please file a bug report?
Because it takes, or seems to, a large
to get us to being
able to handle most of C.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Introduction
This document summarizes work remaining in the LTO front end to
achieve the initial goal of correct operation on single-file C
programs.
Changes to the DWARF Reader
less likely to do bad things, while making the rest of the system go
faster by not using the option.
I think we've selected a very reasonable path here.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
pick up 4.2.0. But, if 4.3 isn't
looking very stable, there will be a point when people decide that 4.2.0
is looking very attractive. The worst outcome of trying to do a 4.2.0
release is that we'll fix some things that are also bugs in 4.3; most
4.2 bugs are also in 4.3.
--
Mark Mitchell
in getting these closed out. On the other hand, if
someone wants to create an UNREPRODUCIBLE state (which is a terminal
state, like WONTFIX), that's OK with me too. But, let's not dither too
much over what state to use.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
part harder. If
someone handed me a contract to write a secure application, with a
penalty clause for security bugs, I'd sure be looking for a language
that raised exceptions on overflow, bounds-checking failures, etc.)
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
.
FYI,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
relative to the previous
4.1.x releases, and I'm going to grumble a lot about P2s.
So, I think we're relatively close to being able to do a 4.1.2 release.
Let's tentatively plan on a first release candidate on or about January
19th, with a final release approximately a week later.
Thanks,
--
Mark
than the $host-$target
compiler (which may be the one in the tree).
Given the constraints, I'm not sure that autoconf is a huge win. I'm
not violently opposed, but I'm not sure there are big benefits.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Richard Guenther wrote:
Perhaps Richard G. would be so kind as to turn this off in VRP, and
rerun SPEC with that change?
I can do this.
Thank you very much!
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
in VRP, and
rerun SPEC with that change?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
the assumption about signed overflow not
occurring during VRP (perhaps leaving that available under control of a
command-line option, for those users who think it will help their code),
is the right thing to try.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Paolo --
The GCC SC has appointed you as a co-maintainer of the build machinery.
Please add an appropriate MAINTAINERS entry.
Congratulations, and thank you for accepting this position!
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
:
./cc1 t.c
or
./xgcc -B. t.c
If I used the same prefix of an already installed GCC.
This makes debugging driver issues without installing the driver again.
What are the contents of t.c? What if you set GCC_EXEC_PREFIX?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
is described as a new feature (faster compiler, better
code), and the build system affects people building the compiler. The
change we're talking about seems to affect only people debugging the
compiler.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
it on their system can leverage that. So, we still
have to decide whether to allow older versions.
On that point, I agree with previous posters who have suggested we
should be liberal; we can issue a warning saying that we recommend
2.2.1, but not require it.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED
get no warnings? (I agree that a --param for that would be better;
if a user ever has to turn this on, we broke the compiler.)
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
be the preferred message?
I slightly prefer the more-grammatical C++ version, but, if there's any
controversy at all, I'm perfectly happy with the C version too, and it's
certainly a good thing to use the same message in both languages.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
these patches in the next couple of days.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
information (like GCC machine modes), but most things (types,
functions, variables) are present.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
, not blocks the release. (In my experience, severities
are normally things like mild, critical, emergency.)
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Michael Eager wrote:
GCC 4.1.1 for PowerPC generates a 162K executable for a
minimal program int main() { return 0; }. GCC 3.4.1
generated a 7.2K executable. Mark Mitchell mentioned the
same problem for ARM and proposed a patch to remove the
reference to malloc in atexit
(http
of type
pointer-to-lambda-function? Is this discussed, or am I missing something?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
believe that you need the personality routine if you will be unwinding
through a function, which is why -fno-exceptions is the test.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Michael Eager wrote:
Mark Mitchell wrote:
Generating __gxx_personality_v0 is suppressed with the -fno-exceptions
flag, but it would seem better if this symbol were only generated
when catch/throw was used. This happens in cxx_init_decl_processing(),
which is called before it's known whether
Michael Eager wrote:
Mark Mitchell wrote:
Michael Eager wrote:
Why should the personality routine be included in all C++ programs?
Because all non-trivial, exceptions-enabled programs, may need to do
stack unwinding.
It would seem that the place to require the personality
routine would
that needs cleaning up, we'll still need it in the
final executable, but omitting it would make our object files smaller,
and unwinding a little faster, since we don't call personality routines
that aren't there.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
:
http://gcc.gnu.org/wiki/GCC_4.1.2_Status
as you encounter such PRs.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Ian Lance Taylor wrote:
Mark Mitchell [EMAIL PROTECTED] writes:
Though, if we *are* doing the template-repository dance, we'll have to
do that for a while, declare victory, then invoke the LTO front end,
and, finally, the actual linker, which will be a bit complicated. It
might be that we
like that idea.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
to check compatibility as
often as equivalence. Certainly, in the big C++ test cases, Mike is
right that templates are the killer, and they're you're generally
testing equivalence.
So, if you separate same_type_p from compatible_type_p, and make
same_type_p fast, then that's still a big win.
--
Mark
Dave Korn wrote:
On 10 November 2006 20:06, Mark Mitchell wrote:
Dave Korn wrote:
It may seem a bit radical, but is there any reason not to modify the
option-parsing machinery so that either '-' or '=' are treated
interchangeably for /all/ options with joined arguments
).
Do you need new class types, or just an anonymous FUNCTION_DECL?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
the driver so that --lto passes -flto to the C front-end and
--lto to collect2.
Any objections to this plan?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Andrew Pinski wrote:
On Thu, 2006-11-09 at 12:32 -0800, Mark Mitchell wrote:
1. Add a --lto option to collect2. When collect2 sees this option,
treat all .o files as if they were .rpo files and recompile them. We
will do this after all C++ template instantiation has been done, since
we want
Ian Lance Taylor wrote:
Mark Mitchell [EMAIL PROTECTED] writes:
1. Add a --lto option to collect2. When collect2 sees this option,
treat all .o files as if they were .rpo files and recompile them. We
will do this after all C++ template instantiation has been done, since
we want
Ian Lance Taylor wrote:
Mark Mitchell [EMAIL PROTECTED] writes:
I assume that in the long run, the gcc driver with --lto will invoke
the LTO frontend rather than collect2. And that the LTO frontend will
then open all the .o files which it is passed.
Either that, or, at least, collect2
benefit.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
are talking about
canonicalizing. We already have only one pointer to each type, for example.
Yes, but to compare two types, you have to recur on them, because of
typedefs. In:
typedef int I;
int * and I * are distinct types, and you have to drill down to I
to figure that out.
--
Mark
patches I can write, because I'm not great at keeping track of
multiple patches at once.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
on a pass-by-pass basis.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Ross Ridge wrote:
There are other MSC library functions that MinGW doesn't provide, so
other libraries may not link even with a _chkstk alias.
Got a list?
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
standardization, especially without use of GNU
keywords/syntax), but I think we should preserve both cross-system
compatibility and Linux compilation in the meanwhile.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Ian Lance Taylor wrote:
Mark Mitchell [EMAIL PROTECTED] writes:
Ian Lance Taylor wrote:
Here is a review followed by a proposal.
How does this proposal handle the current problematic situation that
-std=c99 is broken on Linux?
According to the proposal, we will restore the GNU handling
problems for people that ensuring that only users putting new compilers
on old systems suffer might be a good goal.
On the other hand, I agree that if we have fixincludes in place, then
4.3 would not be in any way broken on GNU/Linux, so I think this is a
judgment call.
--
Mark Mitchell
build-system complexity, but
if it makes it easier for people, then it's worth it.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
salvage.
In contrast, as I understand it, Ian's perturbed about the idea of
having an external library at all.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
would expect in early
Stage 1 with any other kind of big infrastructure change.)
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
, in time for 4.3. We
should provide a tarball for it from gcc.gnu.org, if there isn't a
suitable GMP release by then.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
as you go is fine, in principle. Every little bit
helps. My only concern would be whether you'll disrupt other
large-scale projects that might find global changes hard to handle. I'd
suggest posting your patch and seeing if anyone makes unhappy sounds. :-)
--
Mark Mitchell
CodeSourcery
[EMAIL
Aldy Hernandez wrote:
Does the tuples branch include the CALL_EXPR reworking from the LTO branch?
No.
Though, that is a similar global-touch-everything project, so hopefully
whatever consensus develops from tuples will carry over.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331
branches, especially if they fix P1 regressions.
Sacrificing code quality for correctness is the right tradeoff for a
release branch, if we have to pick, so if a patch is only going to
pessimize code, it should be a very strong candidate for a release branch.
--
Mark Mitchell
CodeSourcery
[EMAIL
Mark Mitchell wrote:
Andrew Pinski wrote:
On Sun, 2006-10-22 at 12:58 +, Joseph S. Myers wrote:
All the bugs with 4.2 in their summaries ([4.1/4.2 Regression]
etc.) need to have it changed to 4.2/4.3. I don't know the
procedure for this, but perhaps it needs adding to the branching
with this.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
---BeginMessage---
Snapshot gcc-4.3-20061023 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20061023/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been
Jack Howarth wrote:
Mark,
What happened to the gcc 4.2 snapshot
tarball for this week?
It gets build on Tuesdays, or at least it does now according to crontab.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Daniel Berlin wrote:
Anyway, i made 43changer.pl and ran it, so the bug summaries have been
updated.
Thanks!
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
that's no problem. I continue to
think think that using DWARF (with extensions) since it makes this
information accessible to other tools (including GDB). I think that
before there ought to be a compelling reason to abandon a strategy based
on DWARF.
--
Mark Mitchell
CodeSourcery
[EMAIL
get by doing this in the front end?
In the worst case, we will provide a separate type attribute in DWARF
giving the GIMPLE type of the variable. Then, that type would be the
linearized array. LTO would use the GIMPLE type attribute (if present)
when reconstructing the type.
--
Mark Mitchell
that.
also seems OK, assuming that we need to do this at all.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
to the
translation project. Joseph, would you please do that, at your convenience?
The mainline is now in Stage 1.
Thanks to those who helped fix PRs to meet the 4.2 branch criteria!
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
a reasonable choice, especially if the
discriminator approach doesn't work.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
to class types, packed is a bad
example there too. (If you applied packed at the point of declaration
of S, then S has a different layout than it otherwise would, but we
don't need to do anything regarding mangling, etc.)
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385
is clearly at least one more release cycle away,
and IMA might be ready sooner. On the other hand, if the IMA changes
were disruptive to the C++ front end in general, then that might be a
problem. I guess we just have to evaluate the patch, when it's ready.
--
Mark Mitchell
CodeSourcery
[EMAIL
); do you think that's OK?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
that seems like a logical place to add header directories.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Ian Lance Taylor wrote:
Carlos O'Donell [EMAIL PROTECTED] writes:
A relocated compiler should not look in $prefix.
I agree.
I can't approve your patches, though.
This patch is OK, once we reach Stage 1.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
to a function expecting an S*, but can of course be passed to a
function expecting an __attribute__((packed)) S *, or a typedef for
such a type.
Thoughts?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Joseph S. Myers wrote:
On Sun, 15 Oct 2006, Mark Mitchell wrote:
We have a number of C++ PRs open around problems with code like this:
struct S {
void f();
virtual void g();
};
typedef __attribute__((...)) struct S T;
I was happy with the state before r115086 (i.e
that we should wait for LTO to be done to tackle devirtualization.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Kaveh R. GHAZI wrote:
On Mon, 9 Oct 2006, Mark Mitchell wrote:
Kaveh R. GHAZI wrote:
Has there been any thought to including GMP/MPFR in the GCC repository
like we do for zlib and intl?
I do not think we should be including more such packages in the GCC
repository. It's complicated from
certainly don't think removing zlib from our
repository is the most important improvement we can make to GCC. :-)
But, I do think we should resist incorporating more external components
into the GCC repository and into its own build process.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650
as a
GCC developer; they're in no way official.)
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
just as well choose to
normalize to BITS_PER_UNIT. So long as we can compute the starting
offset of the field, why does it matter what the normalization constant is?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
that release,
we'll not worry too much about it.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
status, since
the Apple versions of the compiler are sufficiently different from the
FSF versions that the FSF versions may not really work well on Apple's
released OS.
* Keep HPPA HP-UX as primary, or, perhaps, replace it with Itanium HP-UX.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650
. The person compiling the
library should use -Wno-deprecated, and accept that they be calling some
other deprecated function they don't intend to call.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
be incorporated into the
variably sized offset.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
field_byte_offset with a use of byte_position. Does
anyone else know?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
representation of integers, you have to be careful that you
have enough bits; for example, you need 72 bits to represent things in a
64-bit address space.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
^61 ?
I'm not sure -- but if it doesn't, it should. There are folks who like
to make structures corresponding to the entire address space, and then
poke at particular bytes by using fields.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
are fixed.
Is there a project page for this work?
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Kazu, Sandra --
I don't believe there is a GCC 4.3 project page to merge the work that
you folks did on CALL_EXPRs and TYPE_ARG_TYPEs. Would one of you please
create a Wiki page for that?
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Sandra Loosemore wrote:
Mark Mitchell wrote:
I don't believe there is a GCC 4.3 project page to merge the work that
you folks did on CALL_EXPRs and TYPE_ARG_TYPEs. Would one of you
please create a Wiki page for that?
There are already a bunch of notes about this on the LTO page:
http
Hans-Peter Nilsson wrote:
On Mon, 18 Sep 2006, Mark Mitchell wrote:
Andrew Pinski wrote:
The documention on VECTOR_CST is not clear if we can have missing
elements in that the remaining elements are zero. Right we produce such
VECTOR_CST for things like:
#define vector __attribute__
-- and hounding reviewers! -- as soon as
possible.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
what I think the
internal GCC IR semantics should be.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
for everyone.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
privileges reviewed the patches?
I'm not in any way trying to send a negative signal about this work. I
have every hope that it will be merged soon. I just want to better
understand the situation.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
of these projects in GCC 4.3 if all the pieces
come together in time.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Mark Mitchell wrote:
I have now reviewed the suggestions. Here is the mail that I plan to
recommend to the SC. (Of course, I can't guarantee what the SC will do
with it.) I've tried to take into account most of the feedback.
However, I've tried to note all of these suggestions in my draft
to get me input today. I will revise both
the branch date and 4.3 staging in response to feedback; consider
today's expected mail as a first try.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Danny Smith wrote:
cp/ChangeLog
PR target/27650
* class.c (check_for_override): Remove dllimport from virtual
methods.
testsuite/Changelog
PR target/27650
* g++.dg/ext/dllimport12.C: New file.
OK, thanks.
--
Mark Mitchell
CodeSourcery
[EMAIL
to sparc64-sun-solaris2.10?
4. Replace powerpc-apple-darwin with i686-apple-darwin. Apple's
hardware switch would seem to make the PowerPC variant less interesting.
5. Add i686-mingw32 as a secondary platform.
Reactions?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Mark Mitchell wrote:
My proposed changes:
1. Replace arm-none-elf with arm-none-eabi. Most of the ARM community
has switched to using the EABI.
2. Downgrade hppa2.0w-hp-hpux11.11 and powerpc-ibm-aix5.2.0.0 to
secondary platforms. Update HP-UX to 11.31? Update AIX to 5.3? I like
having
601 - 700 of 1279 matches
Mail list logo
