This also occurred with the latest snapshot:
Configure syntax was:
./configure --prefix=/opt/gcc-4.3
Configure completed fine. Make is getting stuck at:
/part/build/mark/gcc/host-x86_64-unknown-linux-gnu/gcc/xgcc
-B/part/build/mark/gcc/host-x86_64-unknown-linux-gnu/gcc/
-B/opt/gcc-4.3
#x27;t know how to re-generate libgcc/configure from the alterred
libgcc/configure.ac. I checked the install instructions and couldn't
find a reference to this. I tried both autoconf and automake. Neither
did the 'right' thing. :-)
Cheers,
mark
--
[EMA
to have official
support for Java 5 syntax and class libraries. Not that I would like
to rush you - or skip any valuable merges - but if the code that is in
right now is in a near ready state, waiting up to a year before
releasing seems unfortunate. :-(
Cheers,
mark
--
[EMAIL PR
n to be silently disabled? Or would you expect it to guess based
on the variables names?
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
__
.
ered a blessing when it comes
to programming languages. Also, an impossibility.
I don't understand what is being requested. Have one structure with
four fields, and another with two, and allow them to be used
automatically interchangeably? How is this a good thing? How will
this prevent the im
On Wed, Jun 27, 2007 at 11:36:23PM -0700, michael.a wrote:
> mark-28 wrote:
> > I don't understand what is being requested. Have one structure with
> > four fields, and another with two, and allow them to be used
> > automatically interchangeably? How is this a goo
> Mark Mielke wrote "Why not This?":
> > class Rectangle {
> > Vector2d position;
> > Vector2d size;
> > };
> > ... rectangle.position.x = ... ...
On Thu, Jun 28, 2007 at 03:00:07AM -0700, michael.a wrote:
> My foremost pe
tested) one below. Does
that sound reasonable? It seems right to try to fix the generic code here,
even though the testcase in hand is target-specific. If this approach
is unreasonable, I guess some target-specific hooks will be needed.
Mark
--
Index: gcc/c-common.c
Andrew Pinski wrote:
On Thu, 2006-10-12 at 13:03 +0100, Mark Shinwell wrote:
typedef __builtin_neon_qi int8x8_t __attribute__ ((__vector_size__ (8)));
typedef __builtin_neon_hi int16x4_t __attribute__ ((__vector_size__ (8)));
...
int8x8_t f (int16x4_t a)
{
return a;
}
This should
.
So please check the Altivec programming manual.
Will do, thanks.
Mark
ify the alignment of memory
returned by "operator new", or a GNU attribute that libstdc++ could add
to the default declaration (with a system-dependent value, of course),
etc. seems fine to me, but I'd be very hesitant to change the ABI proper.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
of these restrictions in
future, if we add mangling support for attributes.)
A variable declaration involving attributes, like:
__attribute__((...)) S v;
is treated as syntactic sugar for:
typedef __attribute__((...)) S T;
T v;
where T is some invented type name different from all others in the program.
For example given:
__attribute__((packed)) S v;
the type of "&v" is "__attribute__((packed)) S *", and cannot be passed
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. with it
e you'd never be able to
get a "this" pointer for them); do you think that's OK?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
raries, so 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
ass with
that type.
Right. And, since there seems to be consensus that you shouldn't be
able to apply semantic attributes 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
at's not a
bad thing, since LTO 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
hanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
al-name).
That's true, but is there a reason not to use the discriminator
encoding? There might well be an ambiguity, but I didn't see at first
blush. If so, that would seem most natural to me.
I do think that your proposed encoding is unambiguous, though, so it
certainly seems
onsider the proposal amended to
have that.
also seems OK, assuming that we need to do this at all.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
, or sent them off 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
signed to be extended, so 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.
--
Mar
. LTO would use the GIMPLE type attribute (if present)
when reconstructing the type.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
ill now ask Daniel to help with the SQL bits.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
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 perha
Thanks to Joseph for helping me with this.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
--- Begin Message ---
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 de
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
try to put
patches on release 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
merging 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
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
readily buildable
GMP available, including one that works on OS X, 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
to that. It's a bit more 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
Ian Lance Taylor wrote:
Mark Mitchell <[EMAIL PROTECTED]> writes:
I would strongly oppose downloading stuff during the build
process. We're not in the apt-get business; we can leave that to the
GNU/Linux distributions, the Cygwin distributors, etc. If you want to
build a KDE appli
st case, declare that external library beyond 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
examples like this. What do
others think?
Mark
Ian Lance Taylor wrote:
Mark Shinwell <[EMAIL PROTECTED]> writes:
I would now like to propose that the check in that function be made
even stronger such that it disallows conversions between vectors
whose element types differ -- even if an implicit conversion exists
between those element
y're too immature; the problems we're seeing
don't seem particularly worse than the problems I would expect in early
Stage 1 with any other kind of big infrastructure change.)
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
tensions before 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 ha
ges. fixincludes causes sufficient
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
roved in principle.
Mark
l change
to an error in a later version.
Thoughts?
Mark
es, that was it. Does it have a PR number?
I don't believe so (but there will be a patch submitted soon).
Mark
Ian Lance Taylor wrote:
I would vote for: break the code, but provide an option to restore the
old behaviour, and mention the option in the error message.
I like this -- I shall prepare a patch and circulate it for review.
Mark
And, there are lots of
people that have reported link failures involving _chkstk.
So, my (perhaps naive) question is: why don't we define _chkstk as an
alias for _alloca in MinGW, so that we can link with these MSVC libraries?
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650
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
sm, though, we could
add thresholding on a pass-by-pass basis.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
ing
it a near-free operation would be a huge benefit.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
e 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&q
David Edelsohn wrote:
Kaveh R GHAZI writes:
Kaveh> I tried many years ago and Mark objected:
Kaveh> http://gcc.gnu.org/ml/gcc-patches/2000-10/msg00756.html
Kaveh> Perhaps we could take a second look at this decision? The average system
Kaveh> has increased in speed many time
Modify 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
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 instantiat
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
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
DRESS
that my patch at http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00858.html is
aimed at preventing. (This patch is currently only applied to addrmodes
branch.)
Mark
file, the parser accepts either?
I like that idea.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
same_type_p fast, then that's still a big win.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
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
>
nodes should be
> necessary (I think).
Do you need new class types, or just an anonymous FUNCTION_DECL?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
[EMAIL PROTECTED] wrote:
From: Mark Shinwell <[EMAIL PROTECTED]>
[EMAIL PROTECTED] wrote:
My port, based on (GCC) 4.2.0 20061002 (experimental), is producing
incorrect code for the following test case:
[snip]
I've only had a very quick look at your code, but I have a feeling
tha
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
Sohail Somani wrote:
> On Fri, 2006-11-10 at 19:46 -0800, Andrew Pinski wrote:
>> On Fri, 2006-11-10 at 15:23 -0800, Sohail Somani wrote:
>>>> Do you need new class types, or just an anonymous FUNCTION_DECL?
>>> Hi Mark, thanks for your reply.
>>>
>>
re it's known whether or not EH is really needed.
I 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(),
&
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
the personality routine here. Unless the entire program doesn't
contain anything 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
Daniel Jacobowitz wrote:
> On Sun, Nov 12, 2006 at 05:11:39PM -0800, Mark Mitchell wrote:
>> Daniel Jacobowitz wrote:
>>
>>> If you try what Michael's been saying, you'll notice that trivial
>>> C++ files get the personality routine reference even if the
e the list here:
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
[EMAIL PROTECTED] wrote:
> So, are we using "P1" instead to mark release-blocking bugs? Should
> we fix the severities of existing bugs?
I am using priorities to indicate how important it is to fix a bug
before the next release. This is consistent with the meanings of the
term
yet written out to the
DWARF information (like GCC machine modes), but most things (types,
functions, variables) are present.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
l review these patches in the next couple of days.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
meone against fixing this? What would 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
ndomly"
choosing between two equally good choices?
Have you tested with flag_check_canonical_types on, and verified that
you 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
ng an external MPFR, so that
people who do have 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 req
> Jan Kratochvil writes:
>
> > currently (on x86_64) the gdb backtrace does not properly stop at
> > the outermost frame:
> >
> > #3 0x0036ddb0610a in start_thread () from
> /lib64/tls/libpthread.so.0
> > #4 0x0036dd0c68c3 in clone () from /lib64/tls/libc.so.6
> > #5 0x
an hold any value.
>
> Sure, we already know that, as has been clear. The question is *if*
> %rbp may be used as a general callee-saved register that can hold any
> value.
The amd64 ABI is specifically *designed* to allow this.
Mark
I can no longer do inside a just built GCC do:
> ./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?
--
M
w I have to set that now.
> Seems like a change like this should be mentioned on
> http://gcc.gnu.org/gcc-4.3/changes.html
> Because some people liked the old behavior when debugging the driver.
This not a user-visible change; it does not affect installed compilers.
It only affects GCC deve
27;s fine by me.
But, fwprop 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
;); perhaps even that isn't the case.
If anyone could offer any advice as to how to proceed here, I'd be most
grateful. I've copied this to Alexandre since a colleague suggested he
might know the answer :-)
Mark
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
ctice, we probably won't "miscompile" many
non-conforming programs, and we probably won't miss two many useful
optimization opportunities.
Perhaps Richard G. would be so kind as to turn this off in VRP, and
rerun SPEC with that change?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Ian, and I are all agreed on that point,
and, I think, that disabling 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
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
e using to build the libraries), rather 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
ith a final release approximately a week later.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
being made.
FYI,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
gree with Joe
that there's benefit 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
y
provide performance advantages, but makes the security 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
d I
think requiring a newer version should not be done lightly.
Mark
were enough people unhappy about bugs, there would be more people
contributing bug fixes.
It may be that not too many people 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 d
at security-critical packages are that much
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
ed 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 R
state the problem and ask for help (as you did) without
attacking anyone.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
t seen a
response to this point.
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?
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
with arrays. Another
possibility is that we're SRA-ing a lot of small 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
unspecified* behavior.
In practice, this warning from GCC is keyed off what it thinks the
effective range of "E" is. If it starts assuming that "e" can only have
the values { 0, 1 }, it will also stop warning about the missing case.
It would 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
1 - 100 of 1839 matches
Mail list logo
