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
. 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
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
as a
GCC developer; they're in no way official.)
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
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
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
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
); 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 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
,
--
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
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
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
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
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
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
, 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
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
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
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
on a pass-by-pass basis.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
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
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
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
to
me.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
tell. It's another case where we've
discovered an inability to implement the full language with the current
scheme, and have therefore been forced to make a change.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
version. That sounds theoretically right to me, but awfully complicated
in practice.
Do we have another libstdc++ ABI change coming? I'd suggest doing this
as -fabi-version=4, and making that the default at that point.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
, do you consider ABIv3 there only as a theoretical conformance
option? In other words, not something we're going to make the default
in any forseeable future? (Those aren't meant to be rhetorical
questions -- I'm just asking.)
Thanks,
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331
be expected to move in the future if/when we
find another feature we can't implement due to current mangling issues.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
a lot of complexity to me, and I still think inserting
a new version between 2 and 3 is odd. If we need the complexity, I
think we have to introduce a new orthogonal option for vector mangling,
independent of the ABI version, but implied by ABI version 4.
--
Mark Mitchell
CodeSourcery
m
version 4.
How is mangling orthogonal to the ABI?
It's certainly possible to have ABIv2-with-vector-change and
ABIv2-without. I never claimed that they were the same ABI.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
not a position I'd argue for strongly.
Whatever we do, I think the C and C++ front-ends should have the same
behavior.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
B { struct A a; int j; };
and I write:
struct C c = { 1, 2 };
?
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
. -Wmissing-braces is explicitly about not having all
the brace groups fully specified.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
, and if you're in C++ land, you're now
doomed, since creating named temporaries can change the semantics of
programs.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
be to disable the
pass, or to do nothing at all.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
--- ---
Total 124 + 13
Previous Report
===
http://gcc.gnu.org/ml/gcc/2010-01/msg00398.html
The next report for 4.5.0 will be sent by Richard.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
for any critical defects reported in GCC
4.5.0, is expected in July, 2010.
As always, a vast number of people contributed to this GCC release --
far too many to thank individually!
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
in an announcement. Of course, you're
entirely free to publicize plug-ins as you like in any forum you find
appropriate.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
at the Linux
Foundation Collaboration Summit last Friday in San Francisco. So,
you're right, I'm not writing a beautiful white paper, but I'm very
happy to promote GCC. (Since I don't get to write much code these days,
that may be the most useful thing for me to do.)
Thanks,
--
Mark Mitchell
; I just want -O3 to
generate fast code.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
Richard Earnshaw wrote:
Speaking of which, we should probably formally deprecate the old arm-elf
derived targets in 4.6 so that we can remove them in 4.7.
Similarly, we should deprecate support for the FPA on ARM.
I agree.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385
the defaults to match up,
but making it explicit is the right thing to do.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
it there too.
But, of course, arm-elf is really a dead ABI at this point...
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
systems (not just GNU/Linux, but embedded operating systems
too) have switched to the EABI, not just for compatibility with one
another, but because it's technically superior.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
some EABI functionality there. If, on the other hand, you think
there's a problem when using the EABI, then we should talk about how to
solve it.
Thanks,
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
://gcc.gnu.org/wiki/Release%20Manager%20Q%26A
We'll try to give somewhat intelligent answers to those questions, as
well as to those asked live.
Thanks!
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
discussed. It
would also probably be better if it were a moderated discussion so that
everyone doesn't talk at once.
Thanks,
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
are possible in GCC
and to drive funding for those features. I gave a talk at the Linux
Foundation Collaboration Summit recently where I specifically
highlighted plugin infrastructure and link-time/whole-program
optimization as things I saw as potentially very valuable.
--
Mark Mitchell
it.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
, and also the problem that you can't mix code within a file,
which does sometimes have performance advantages. (For example, because
calls to static functions need not have the standard ABIs.)
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
.
Thanks,
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
for not *deprecating* them. We may
as well deprecate them now, and then we can remove them later. The
actual removal won't happen until at least 4.7, which is probably
another couple of years away.
Thanks,
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
a
feature; whether to remove it is an independent decision for later. I
think deprecation of FPA is reasonable; at what point removal is
reasonable isn't something we have to answer until *at least* the 4.7
release cycle.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
completely agree. This is a tractable problem, approximately on the
same scale as GIMPLE tuples. I would guess approximately a person-year,
perhaps spread out over a longer time.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
accept either set of patches, if someone were to provide them.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
. It will, of course, take some
work to achieve, but in concept I completely agree that the front ends
should have no knowledge whatsoever of RTL.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
the assumption that it will not be
possible to combine GFDL manuals and GPL code in the near future.
Thanks,
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
by people who
will apparently be unable to participate. We'll try to answer those as
breaks in the conversation occur.
Thanks,
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
, of course, does not apply to not-FSF GCC, e.g.,
to a release that Basile does himself.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
to eliminate macros.
Yes, the (informally agreed) policy is to have hooks, not macros. There
may be situations where that is technically impossible, but I'd expect
those to be very rare.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
-in if you chose to do that.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
with the FSF over the years, and they've all been lengthy processes. If
I knew how to do it faster, I certainly would. The best way to work
with the FSF on license issues is always to explain how whatever request
you are making furthers the FSF's goals.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
.
* config/spu/spu.h (TARGET_ADDR_SPACE_KEYWORDS): Remove.
(REGISTER_TARGET_PRAGMAS): Call c_register_addr_space.
* doc/tm.texi (Named Address Spaces): Mention c_register_addr_space.
Remove TARGET_ADDR_SPACE_KEYWORDS.
OK.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
branch. You could
generate GPL'd documentation, though.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
that at least in
the context of GCC it would do so), but I don't think any of us have the
right to do that without the FSF's permission.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
that
this is true for the manual pages.
But, if we could get the documentation for command-line options into
GPL'd code in a structured way, then I think you could probably generate
GPL'd manual pages from that.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
in GFDL manuals and vice versa, particularly in the context
of GCC's manuals, as a way of reducing developer effort and improving
the documentation.
Thanks,
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
501 - 600 of 1279 matches
Mail list logo
