; expressable using builtin_expect as-is, at least when it comes
> to the syntax?
That was my first thought as well. Before we add __builtin_expect_call,
I think there needs to be a justification of why this can't be done with
__builtin_expect as-is.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
to work on now. The problem there is that importance is in
the eye of the beholder. The PN system expressions something about
regressions that's moderately useful, but nothing else. I suspect that
we need more database fields, so that people could run more interesting
searches.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
amount = GEN_INT (offsets->saved_args + saved_regs
> - - offsets->outgoing_args);
> + + static_chain_size - offsets->outgoing_args);
>
>insn = emit_insn (gen_addsi3 (stack_pointer_rtx, stack_pointer_rtx,
> amount));
>
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Gerald Pfeifer wrote:
> On Tue, 23 Oct 2007, Mark Mitchell wrote:
>> [...]
>
> I realized that the documentation we currently have up at
> http://gcc.gnu.org/bugs/management.html
> was partly incorrect (only listing P1 to P2) and certainly
> quite incomplete, so I tried
h is
progress. So, I think we've moved forward a bit more than the raw
numbers might indicate.
Previous Report
===
http://gcc.gnu.org/ml/gcc/2007-11/msg00109.html
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
like:
sizeof(__builtin_expect(1, 1))
will change its value. And, the current prototype is documented in the
manual.
What do people think? Do we have the leeway to change this? Or should
we add __builtin_expect2? Or add an -fno-polymorphic-builtin-expect?
Or...?
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
sible. I can't think of a way in which it changes
current behavior, unless you call __builtin_expect with a long long, and
that's probably not going to do what you expect right now anyhow.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
s no sane C++ programmer would do at this point, but we
want to support for legacy C++ code.
I don't see any a priori problem with changing to match the C front end.
We could of course change some of the pedwarns into errors if we really
think they ought to be errors. Or, some of them could b
d Richard all agreed to help out
in this way. Please join me in thanking and congratulating our new co-RMs!
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Joe Buck wrote:
> Mark Mitchell wrote:
>>> I don't see any a priori problem with changing to match the C front end.
>>> We could of course change some of the pedwarns into errors if we really
>>> think they ought to be errors. Or, some of them could be ordin
g() {
f();
}
A valid GNU C compiler cannot eliminate the call to "f", as long as the
call itself is reachable.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
ions in future, if we add mangling support
for attributes.
But, yes, if we need to mangle these types, we need to have a mangling
for attributes.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
nt conversion
between them.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
ems.
Or, is it the case that the patch to use abs_srcdir means that no matter
what Texinfo you have, it's not going to work on MinGW?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
save whatever AltiVec registers its using? Is
that what you're suggesting?
Daniel, perhaps you can put a full proposal on the table so that we can
try to get consensus on thsi?
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
erPC ELF ABI
group decides what to do with them.
It's certainly good to minimize the number of times we introduce ABI
changes, so waiting for a definitive plan makes sense.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
're doing and what
impact it might have on the various stakeholders.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
David Edelsohn wrote:
Mark Mitchell writes:
Mark> However, if I understand correct, some users have probably been
Mark> implicitly using those options because they were using "-mcpu=970", or
Mark> otherwise specifying an AltiVec CPU. It seems desirable in the abstract
M
o you agree?
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
of the patches have introduced additional
thunks of some kind. Actually giving both names to the same entry point
would avoid the ABI problems, and thus be non-controversial. (The ABI
explicitly endorses multiple entry points as a solution.)
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 33
fully
enforced that on all platforms, and if the copies aren't all in the same
COMDAT group, then, indeed, I can imagine that you could end up with one
of the constructors coming from one place, and one from another -- which
might be unfortunate.
--
Mark Mitchell
CodeSourcery
[EMAIL PROT
release branch unless you are also
patching all later branches.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
t how good of a
language Fortran is, or how solid the Fortran front-end is; it's just a
comment about usage of GCC.
That said, I think that the RMs do -- and should -- pay attention to
Fortran. I just think that the statement that only C and C++
regressions are release-critical is importan
bout what status Darwin might
have in the future; if there's active maintenance -- as, it looks like,
there may very well be, given that we have a volunteer for the position
-- then that might well reactivate Darwin, even for later 4.3.x releases.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMA
ug in the use of install-leaf.
I didn't mean to imply otherwise. My statement was simply that
Darwin-only problems are not in and of themselves release-blockers for
4.3.0.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
block removing libcall notes by it).
Why doesn't it work? Can it be made to work relatively easily? Do we
need functionality like this for Ada or Java?
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
you've withdrawn the deprecation request, so maybe this is
something of a moot point now? I certainly agree that we shouldn't let
a non-working feature stand in the way of improvements in 4.4.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
eliminating them before
gimplification would be a false negative, so less of a problem. Since
this feature is designed to crash your program when it has a bug,
crashing your program somewhat less often doesn't make the feature
useless; just less useful.
--
Mark Mitchell
CodeSourcery
[
when the problems that it causes for darwin are solved)?
I think it's important, since, IIUC, it improves our ability to test on
all platforms. But, I certainly encourage you to figure out why it
breaks Darwin and work out how to fix it!
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
ayout than the eventual installation), making the
driver depend on shared libraries created during the build is certainly
going to be tricky. In particular, on most platforms LD_LIBRARY_PATH
(or equivalent) will have to be set just so whenever xgcc is run.
--
Mark Mitchell
CodeSourcery
[EMAIL
tions using those codes -- but after gimplification
these tree codes are no longer used.
3. Plumb the new operations through the TREE-SSA optimizers, add support
for generating the checks during expand for those trapping operations
that make it to that point, and disable the insertion of check
chance yet, but I will try to
figure out what's going on soon.)
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
e a checkout on the branch from
whatever point they prefer.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
re!" not "Gee, how frustrating, that
sometimes works, but often just lies to me."
I wouldn't object to having the functionality in the compiler as an
option (but off by default), until we fix the accuracy, though.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
release be made
aggressively obvious.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
have an update release have a new and
different license, with which you might not be familiar.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
CLASSTYPE_VBASECLASSES is valid?
No; if the class is presently being defined, that will not be set.
However, it should be safe to check that for a complete class when
!processing_template_decl.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
page?
What would be the adverse consequences of just replacing our gpl.texi
with the FSF GPLv3 version?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
For something as
big and complex as GCC, info/HTML/PDF all seem like better media.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
'd hate to lose them.
Well, would anyone like to volunteer to update our manual, then?
I think that this is a critical defect in the current sourcebase; do we
have a PR open? If not, I can file one.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
an issue; you're not concerned about
putting a new application into the field on an old OS, but rather about
rolling out a new device with kernel, applications, and all.
So, I think we want both options here.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
(buf + len < buf)
return 1;
return 0;
}
If you know of a non-GCC compiler that optimizes away the test (so that
the function always returns 0), please post here, and let me know the
name, version number, command-line options, etc. you used to demonstrate
that.
Thanks,
--
Mark Mitchel
ew to something like:
"Some compilers (including, at least, GCC, PathScale, and xlc) optimize
away incorrectly coded checks for overflow. Applications containing
these incorrectly coded checks may be vulnerable if compiled with these
compilers."
?
--
Mark Mitchell
CodeSourcery
[E
Mark Mitchell wrote:
"Some compilers (including, at least, GCC, PathScale, and xlc) optimize
away incorrectly coded checks for overflow. Applications containing
these incorrectly coded checks may be vulnerable if compiled with these
compilers."
I've now been told that th
ocusing on GCC exclusively is misleading.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Mark Mitchell wrote:
I've been told that Intel's ICC compiler also does this optimization:
ICC 10.0 and earlier releases perform
the same optimization, but not on straight-line code, such as the
testcase. ICC performs the transformation inside loops.
Thanks,
--
Mark Mitchell
Co
Mark Mitchell wrote:
I've been told that Intel's ICC compiler also does this optimization:
Apparently, IAR's Atmel AVR compiler does this optimization as well.
That CPU has 16-bit addresses, so the tester changed the test case to
use "1 << 14" instead of &qu
has to know that the value of len is non-negative in
order to do the optimization. Using an "unsigned int len" parameter
should also give it that information, but the version I had was designed
to closely resemble the case shown to my by CERT, which used a signed
variable.
Th
Mark Mitchell wrote:
Mark Mitchell wrote:
I've been told that Intel's ICC compiler also does this optimization:
Apparently, IAR's Atmel AVR compiler does this optimization as well.
That CPU has 16-bit addresses, so the tester changed the test case to
use "1 <&l
n 1;
return 0;
}
which is what the person who emailed me about MSVC tested. I did
include the optimization flags they used in that email; they appeared in
a comment in the MSVC output. I don't know what those flags mean,
though; I'm not an expert on MSVC usage.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
to do
a post-increment -- but is there anything especially clever out there?
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
kes it easy for people to move code
from icc to GCC.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
_MAX
#endif
to host-linux.c. Or some autoconf check that determines whether
SSIZE_MAX is available and defines it if it is not, based on the size of
size_t. Or something. (I don't know Linux well enough to how
consistent these things are across targets.)
Thanks,
--
Mark Mitchell
H.J. Lu wrote:
Icc and gcc will use the same filename. The question is what filename
to use.
Oh, OK. If we get to pick, then, yes, I think is nice.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
finding out that we
have to change them in ways that are not backwards compatible. And, I'd
like to know what our C maintainers make of the proposal overall; if
they see language issues, then we might want to resolve those with WG14.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Robert C. Seacord wrote:
Gerald,
There was a report (forwarded by Mark Mitchell) of Microsoft
Visual C++ 2005 performing that optimization (the resultant
object code was shown). Have you verified that this report
was false?
both chad and i have tested this with various options on Visual C
er
compilers that do the same optimization. Why is the status for
compilers from Microsoft, Intel, IBM, etc. listed as "Unknown" instead
of "Vulnerable"?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
g degree to which vitally
important software is built with GCC.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
e completed that investigation? I
can appreciate the desire for an independent investigation, but given
the data we have already provided, it should be a pretty simple matter
to verify this.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
ata for those people. But, it should be made clear that
switching from GCC to icc (or whatever) is not a solution, since many of
those compilers also do the optimization. (Never mind the risks that
making a major change to your build environment entails...)
--
Mark Mitchell
CodeSourcery
[EMAIL
CPU with AltiVec support, or something.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Status
==
The GCC 4.3 branch is open for commits under normal release branch
rules.
GCC 4.3.1 is scheduled for 2008-05-05. As we have not yet built
4.3.1-rc1, we will slip that date. As shown below, there are 2 P1s on
the 4.3 branch, so we are not yet ready to build RC1.
One of the P1s
Probably not. Though, I suppose:
#if !defined(__PPC405__)
asm("haha here is a 405 insn");
#else
/* The real test goes here. */
#endif
might...
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
like the wrong way to go.
Vladimir, if you feel that Peter's code cannot be used directly in IRA,
would you please explain why not? It does seem like it would be easier
for everyone if we could leverage what has already been done.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
pshot-only-if-something-changed, that seems fine too -- but from the
FSF point of view 4.1 is now dormant.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
ow to start the
discussion.
== Repackaging ==
Under this proposal, WPA repackages its input files.
FWIW, I'd suggest going this way. I agree that this is probably the way
to go in the long term, and avoiding the throw-away stage seems beneficial.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTE
cific DECLs and TYPEs after
gimplification should be for generating debug information. And if
that's already been done, then you shouldn't need it at all.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
like a good
idea to me.
I agree. And, I think in the source code is the right answer, even over
the long term. For one thing, one often needs to know what the API
*was* for some old version of GCC.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
to finish this
project, that would be very much appreciated. We don't want this to be
a case where we improved the infrastructure of the compiler -- but made
the user experience worse.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
===
http://gcc.gnu.org/ml/gcc/2008-06/msg00155.html
The next report for the 4.3 branch will be sent by Joseph.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Jonathan --
Thanks for pushing this forward!
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
On Jun 15, 2008, at 7:06 PM, "Jonathan Wakely" <[EMAIL PROTECTED]>
wrote:
2008/6/13 Mark Mitchell:
Jonathan Wakely wrote:
Hi Volker, thanks for picking th
, DTRT
implies not, but should tf_error be changed to tf_warning?
I think "DTRT" here means "do what whoever wrote this code thinks the
standard should say" not "do what the standard says". Please make these
permerrors.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Jonathan Wakely wrote:
2008/6/18 Mark Mitchell:
* I don't think the pedwarn in joust() in cp/call.c should be a
permerror, is this a GNU extension?
if (warn)
{
pedwarn ("\
ISO C++ says that these are ambiguous, even \
though the worst conversion for th
Jonathan Wakely wrote:
Thanks for the review, here's another patch ...
Shall I commit this?
Yes, please.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
that after-the-fact auto-testing can delivery much of the same value.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
articularly if that isn't
yielding results -- then we revert?
To be clear, I have no special decision-making power here. I'm hoping
we can build a consensus to move in this direction, but it has to be a
consensus decision.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
if the user said "-ofoo.o", and
that was missing, we'd delete "foo.o" which we should not. (There is
already some code involving have_o_argbuf_index which looks like it may
mishandle things like "gcc -c -x c -- -o", but that's another matter.)
This idea of going back and looking at argbuf is, therefore, broken by
design. I don't see a way to really make %W make sense, in this context.
Ideas?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
then the caller must *add* code to catch the
exceptions thrown by callees and raise std::unexpected.
So, you want to work bottom-up, putting "throw()" on the leaf functions,
and then on callers that call only "throw()" functions and so forth.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
a future project;
it only affects other C++ library implementations, and we don't care so
much about that.
Does that help?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
" spelling, and -- if necessary
-- to collapse the spelling for the output. If there really are tools
that require "-ofoo.o" this will improve the user experience, since
presently saying "-o foo.o" will not work on such platforms. (Because
that's true, I doubt
y checkins that are already in flight.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
H.J. Lu wrote:
Mainline is currently broken on a few platforms:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36907
I think we should fix it first before another big merge.
Diego, what do you think?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Diego Novillo wrote:
In terms of regressions versus mainline, the only regressions introduced
by tuples wrt mainline are the matrix-reorg pass that still has not been
converted.
Why not fix that before merging, then?
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385
ld be committed to fixing this pass
ASAP after it's checked in; waiting until late August to fix it seems
bad. Is there someone else who can commit to working on it as a high
priority after the main tuples checkin?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Steven Bosscher wrote:
If this pass is effectively unmaintained, why not just remove it?
Unmaintained passes that are not enabled at any optimization level are
usually broken anyway.
That's an option, too; the question is whether it has any value. I
don't know.
--
Mar
nk we should be dismissive of "benchmark toy" passes if they
actually improve benchmarks significantly. We don't have to like it,
but we should accept that people are going to benchmark GCC against its
proprietary competition, and that having good benchmark results matters.
Thanks,
with this?
Diego, I think that given Aldy's offer, we can remove this as an issue.
Go ahead with the merge, if you're ready.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
to only be a problem for
AIX at this point, so that may not be that much of a problem.
This is the approach I would suggest. Dump out the debug info for types
before you throw away all the information, and then leave it aside.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
te value for the
symbol at link time.
I'm curious what we do with SRA at the moment. This is the same sort of
problem; do we have any solutions at present?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
ld be better than modifying the
debugger to make assumptions about magic variable names.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
hat's what everyone is talking about, I think. "Emit"
here may also mean "cache in memory some place", rather than "write to a
file". It could mean, for example, fill in the data structures we
already use for types in dwarf2out.c early, and then throw away th
ot;could I stick a
random data byte there and have it affect the function". For example,
for a Thumb function whose ISA address is "0x0001", I would consider
for size purposes that it starts at "0x", since altering that
byte at run-time would change the me
non-DWARF debug info. As long as it we design it
carefully, there's no reason we should have that limitation.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Kenneth Zadeck wrote:
Paolo Bonzini wrote:
Mark Mitchell wrote:
For that matter, "print sizeof(X)" should print the same value when
debugging optimized code as when debugging unoptimized code, even if
the compiler has optimized X away to an empty structure!
I disagree. sizeof
don't escape --
or if the user explicitly tells you that they are.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
nt that has that ABI-specified value. If the compiler emits code
that behaves differently based on whether I wrote "sizeof (X)" or "12"
(assuming X is a 12-byte structure), then the compiler is broken.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
at we need at that point,
based only on what we are going to output. (And for DECL_COMDAT things,
we should be outputting LTO information only if actually referenced.)
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
sk. Maybe we should just not write the data out to the LTO
file, rather than trying to free it early. If you like, have a
free-it-early mode for error-checking (to make sure that we aren't
relying on that data) in the same way that we have an always-collect
mode for GC (to make sure w
appy if GCC "tricked"
me into violating some other license as well. So, if we have a
configuration that we know is undistributable, then making me hack the
source code to disable the error, or making me use a configure-time
override option seems like a good call.
Thanks,
--
Mark Mitc
probably be difficult to fix.
Previous Report
===
http://gcc.gnu.org/ml/gcc/2008-04/msg00539.html
Next Report
===
The next report for 4.4.0 will be sent by Richard.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
301 - 400 of 1305 matches
Mail list logo