Has this been considered in the past, but rejected for some reason?
Don't see why it would. Could be useful.
Should I have posted this to a different GCC list? :P
This is fine.
-eric
We're thinking of including these libraries in the next version of OS
X on the system so that 4.2 will work out of the box when either a) it
is released, or b) leopard is released, whichever happens last. Since
we need to keep abis stable, I was wondering if anyone planned on
changing abi o
On Oct 19, 2006, at 2:50 PM, Diego Novillo wrote:
Eric Christopher wrote on 10/19/06 17:33:
I was wondering if anyone planned on changing abi or if we can depend
on all changes not breaking the abi of these libraries?
There is nothing planned in that area, but I wouldn't want to
guar
On Oct 23, 2006, at 4:15 PM, Paolo Bonzini wrote:
if test -d ${srcdir}/gcc && test x$have_gmp != xyes; then
...
fi
but I think that the whole test now belongs in the GCC
subdirectory, not in the toplevel (it was anyway a hack for the
sake of disabling Fortran).
Moving it is not reall
Maintainability first. If something fails with parallel make, and
is reproducible with plain "make" (i.e. doesn't screw up the build
directory), I don't see a reason not to move it. You'd do "make"
anyway to check if a dependency is missing, wouldn't you?
Really, all I care about is hav
I ended up including both your preference and mine. Hopefully one or
other other (or both) end up being useful to users.
Thanks, this will help with some of the questions I received
internally today.
-eric
Right now after patches by the Apple folks causes you to need a
newer
dwarfutils which don't exist outside of Apple so the community of Free
Source and GCC is not helped by making Darwin a primary platform.
Maybe we should list a specific version of darwin which changes the
confusion of whi
On Nov 6, 2006, at 8:59 PM, Andrew Pinski wrote:
On Mon, 2006-11-06 at 20:57 -0800, Eric Christopher wrote:
As far as 4.2 this is the first I've heard of it. What's the problem?
Well you need a new cctools which does not exist for 10.2.
While I'm sure you could be less
Except this is a different issue as the patch is for Darwin.
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00168.html
Geoff appears to have given a workaround for the problem and has
promised to inquire further about more up to date solutions. Another
solution, of course, is to revert the defaul
On Nov 7, 2006, at 5:24 AM, David Edelsohn wrote:
Eric Christopher writes:
Eric> We're in stage1, breakages happen - see the current fun with
gmp/mpfr as
Eric> well as c99 inlining. File a bug or bring a problem up for
discussion.
Yes, breakage happens in Stage 1, b
Eric> Well, yes, did you see anything in what I wrote that argued
differently?
Yes, what I quoted, the comparison with gmp/mpfr and c99 inlining.
Those other problems are irrelevant.
I disagree, they were other examples of breakages.
-eric
On Nov 7, 2006, at 4:40 PM, 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 s
On Nov 7, 2006, at 4:40 PM, 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 s
You appear to have regenerated configure, on both mainline and 4.2
branch,
with autoconf 2.60. Could you please regenerate it with 2.59 in both
places?
Sure, I'll have to dig it up somewhere. It appears to be the default
on FC6, I'll use that.
-eric
On Nov 14, 2006, at 11:32 AM, Eric Christopher wrote:
You appear to have regenerated configure, on both mainline and 4.2
branch,
with autoconf 2.60. Could you please regenerate it with 2.59 in both
places?
Sure, I'll have to dig it up somewhere. It appears to be the default
o
On Nov 15, 2006, at 8:59 PM, Jack Howarth wrote:
Mike,
The problem is that the Geoff rejected the configure.in patch
that removes libgcj from noconfigdirs...
http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00642.html
...as being too invasive for gcc 4.2. If you manually
apply that, it should
It isn't only on the AVR that bswap_32() is nontrivial to get
right.
These two versions would rule on the i386 if GCC would be just a
little bit
smarter:
I prefer the single instruction bswap that we now generate for
__builtin_bswap[32,64] myself...
-eric
to see if that eliminates the problems. Also I
assume Bradley remembered to install the build
before running make check. I see lots of libgomp
failures I believe those could be due to that.
Also, Bradley, did you remember to patch the
prune.exp scripts in the testsuite? You will
get a huge numbe
make -k -j 8 check >& check.log ; make mail-report-with-warnings.log
I got results that appear not much different from the powerpc-apple-
darwin8.8.0 (i.e., 32-bit) results:
http://gcc.gnu.org/ml/gcc-testresults/2006-12/msg00267.html
i.e., these results don't show a particular fortran proble
On Dec 23, 2006, at 10:28 AM, Dominique Dhumieres wrote:
Building gcc4-4.3.0-20061223 on OSX 10.3 failed with:
...
gcc -g -fkeep-inline-functions -no-cpp-precomp -
DHAVE_DESIGNATED_INITIALIZERS=0 -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-format
On Jan 13, 2007, at 6:13 AM, Jack Howarth wrote:
I noticed that Apple's gcc compiler in MacOS X 10.4
creates fat binaries in /usr/lib rather than using a
ppc64 or x86_64 subdirectory like FSF gcc. Do the Darwin
gcc developers ever intend to replicate the use of fat
binaries for FSF gcc (in g
On Jan 13, 2007, at 8:28 AM, Jack Howarth wrote:
Eric,
So will FSF gcc on Darwin maintain the current 64-bit subdirectory
or will it eventually migrate to using fat binaries as Apple gcc does?
Current is likely.
-eric
On Jan 17, 2007, at 5:19 PM, Jack Howarth wrote:
I noticed today that gcc 4.2 branch seems to create a bogus symlink
on Darwin PPC. A symlink for libgcc_s_x86_64.1.dylib is created that
points at libgcc_s.1.dylib. However libgcc_s.1.dylib is not a quad
binary...
file libgcc_s.1.dylib
libgcc_s
One target is to identify more places where we can get rid of
_Unwind_Word.
Other places exist where we definitely need a data type like
_Unwind_Word
representing a general purpose register. So we have to find a way
to define
_Unwind_Word without using the mode(word) attribute.
So, I mi
There was a long discussion about this a couple of months ago. The
summary was that __attribute__ ((mode (word))) was considered harmful.
It's safe enough when you use it within a program, but when you start
to use in a data structure shared by different codes you run into ABI
problems. A typic
Hi Michael,
Two questions about Apple's Objective-C 2.0 work:
1) Does anyone know when the syntax extensions will be available &
working
in the gcc compiler?
2) Will their garbage collection & accelerated message dispatch
mechanisms
also be supported?
Fairborz is working on them, I ima
This and the register changes come close to multi-arch gcc. Is that a
direction we want to go? Historically we have not tried to support
Personally I'd love to see us go this way if it doesn't inconvenience
us too much.
From what I remember of the MeP port it was pretty clean and wouldn't
Thanks for the answer, but I understand very little of it.
The above can be read as:
If TARGET_64BIT is true, then TARGET_C99_FUNCTIONS is true,
otherwise if we're targeting 10.3 or later, then TARGET_C99_FUNCTIONS
is true, otherwise, TARGET_C99_FUNCTIONS is false.
So far so good.
we are ta
On Mar 17, 2007, at 4:15 PM, Dominique Dhumieres wrote:
Eric,
Thanks for the explanations.
The idea, I believe, is that the default will be the system that you
are currently on.
It would be nice, but it is not the way it seems to work (at least
for gcc,
for g++ and gfortran it may, but
On Mar 17, 2007, at 4:31 PM, Dominique Dhumieres wrote:
The new method will be that the default will be the system that
you are
currently on. It's not the default now.
How new is new? As far as I can tell, it did not work for the
20070309 snapshot. Form the regtests gcc.dg/builtins-59.c and
../../../gcc-4.2.0-20070316/fixincludes/fixincl.x:7597: warning:
string length '575' is greater than the length '509' ISO C89
compilers are required to support
Are these expected?
Yup.
-eric
That said, though, there's something weird going on in your build that
should probably be tracked down. It didn't happen to me last time I
built...
Here's a patch that fixes it though it doesn't fix the testsuite
results yet and is likely not quite what Daniel will want...
Dan?
The basic
I didn't just pull this out of a hat, you know :-) Where do you think
it's going to install the library if you do that?
Yeah, I know. I said it wasn't a good patch, but I was on my way out
of the office for the evening and wanted to get Doug something and
have you look at the code too :)
On Apr 12, 2007, at 10:17 PM, Daniel Berlin wrote:
On 12 Apr 2007 15:14:01 -0700, Geoffrey Keating <[EMAIL PROTECTED]>
wrote:
I would recommend using the system libstdc++ and system libgcc_s
rather than one you build yourself from FSF sources, unless you're
actually developing libstdc++.
T
increase code size? I feel I must be missing something really
obvious... is
it just that the other optimisations that become possible on inline
code
usually compensate?
That or the savings from not having to save/restore registers, set up
the frame, etc as well.
-eric
On Apr 20, 2007, at 1:24 AM, Victor Librado wrote:
Hello all,
I`m working with an arm core 9260EJ-S under Linux (Linux kernel
2.6.15; armv5l-linux toolchain with compiler gnu gcc 3.4.2). I
would like to take advantage of the asm DSP like functions the core
provides. I compile this way:
> > Now, I wouldn't object to hacking GCC to avoid cross-jumping calls to
> > abort. It's just that I don't think that the common GNU use of abort
> > serves the users.
> Agreed. And as someone suggested, rather than treating abort
> specially within GCC, I think we'd be better off with a functi
> What we might want to do is provide an option to disable all such
> optimizations.
>
We have had enough requests for -Odebug or something like that.
Probably could be just dce, ccp, and a couple of other optimizations...
-eric
On Tue, 2005-03-22 at 13:21 +0100, Mile Davidovic wrote:
> Hello all
> I am using gcc for MIPS ( 3.3.x, target mips-elf).
> I had problem during linking, (MIPS_GPREL_16 relocation truncated to fit
> error occurs).
> I set value of gp registers to appropriate value and used -mlong-calls and
> -G0 sw
> If my conclusion is correct, is it possible to rebuild this libraries with
> -mlong-calls and -G0 option?
Yes. You'll need to modify the multilib options.
-eric
On Wed, 2005-03-23 at 18:17 +0100, Mile Davidovic wrote:
> Hello
>
> I will try to modify multilib options.
> I have question regarding how to add my changes in gcc (see thread Mips
> question)
> I already sent FSF copyright agreement and I receive confirmation. So I
> would like
> to introduc
On Tue, 2005-03-29 at 11:08 +0200, Mile Davidovic wrote:
> Hell all
> But where I have to look?
> I could easily change libstdc++v3 -> Makefile.am (AM_MAKEFLAGS) and
> regenerate all but I am not shure is it good way to do it.
For mips-elf you'll want to look in gcc/config/mips/t-elf.
gcc/config
On Tue, 2005-04-05 at 22:25 +0100, Richard Sandiford wrote:
> [EMAIL PROTECTED] writes:
> > asm("cop2a %0, %1;", :: "r" (cp2rb(i)) : "r" (cp2rb(j)));
>
> In addition to Daniel's reply: you wouldn't want to use "r" here.
> That's for general registers only.
>
> The MIPS port does in theory support
>
> Ok about the "r" convention I wrongfully used, it is assumed for the integer
> register-file.
>
Correct.
> I am currently using MIPS + soft-float + some other functionalities in
> Coprocessor #2 with success (somewhat tested in a functional simulator). About
> 10-12 special-purpose instruc
On Thu, 2005-04-07 at 16:48 +0200, Eric Botcazou wrote:
> > That was my thoughts too. You could take a look at how I fixed it on
> > ARM.
>
> Thanks. So basically you bypass the apply_result_mode array entirely, which
> is still wrong as it is on SPARC?
>
Personally, I think that builtin_appl
> You mean this?
>
> /* For each hard register, the widest mode object that it can contain.
>This will be a MODE_INT mode if the register can hold integers. Otherwise
>it will be a MODE_FLOAT or a MODE_CC mode, whichever is valid for the
>register. */
>
> But take a look at the hea
On Sun, 2005-04-10 at 21:13 +0200, Thomas Koenig wrote:
> Toon Moene wrote:
>
> > I'm still thinking about the text to warn gfortran users for the fact
> > that this compiler at present doesn't cover all of Fortran 77 - and that
> > we assume distributors to provide access to g77 as long as that
On Sun, 2005-04-10 at 12:23 -0700, Zack Weinberg wrote:
> Eric Christopher <[EMAIL PROTECTED]> writes:
>
> >> "This compiler at present doesn't cover all of Fortran 77. We assume
> >> distributors to provide access to g77 as long as that's us
> the patch just for the sake of discussion. Does anyone have some
> insight on this? I am using binutils-2.15, glibc-2.3.4, 2.6.12-rc2
> kernel headers and gcc-4.1.0-20050418. Thanks.
>
I'd use 2.16 binutils, especially if using mainline gcc, but that's not
as relevant here...
> /home/sjhill/m
> >
> > Though of course, this doesn't mean that we can't have an option to
> > control it. -Wno-cast-qual doesn't seem like the right choice, as
> > there is no user cast here. Maybe something like -Wno-discard-
> > qual, where -Wdiscard-qual is the default.
> >
> > I notice that these are
>
> I like the more and simplier patterns approach but I'm wondering what
> the general recommendation is?
Mostly what I go for in individual insns,though I try to make sure that
the lengths are equal and it's something generated by the named
patterns. I.e. make sure that the patterns you do hav
On Fri, 2005-05-06 at 07:06 +0200, Stephane Wirtel wrote:
> Hi all,
>
> I would like to know how many stages are there ?
> What's the first stage ?
>
http://gcc.gnu.org/develop.html
-eric
On Thu, 2005-05-05 at 15:58 +0400, Nadezhda IvanĂvna Vyukova wrote:
> The __builtin_isless, __builtin_islessequal functions are provided as
> implementations of standard C99 functions 'isless', 'isgreater'. Please,
> explain why gcc for mips implements them via instructions
>
> c.lt.FMT and
> We'd unslush when the primary platforms have clean test results.
>
> Thoughts?
Aye :)
-eric
> > http://gcc.gnu.org/wiki/GCC%204.1%20Slush
>
> Just to let folks know that mips-elf fails to build newlib.
> There's a segfault in is_gimple_reg_type(), which is being
> passed a null type. I'm not sure if I'll have time to look
> at it tonight.
I took a look and it seemed to work for me,
> Eric (and anyone else who wasn't aware): there's been a lot of
> discussion about this on gcc-patches since I posted that message:
>
> http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02029.html
>
> It's also PR21638:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21638
>
> It looks lik
On Mon, 2005-05-23 at 19:35 +0200, Steven Bosscher wrote:
> On Monday 23 May 2005 18:20, Jeffrey A Law wrote:
> > I'd much rather take the time to fix all these problems, install the
> > fixes along with the checking bits to ensure they never come back
> > rather than to iterate on each one separat
> main.o tree-browser.o libbackend.a ../libcpp/libcpp.a ../libcpp/libcpp.a
> ../
> libiberty/libiberty.a
> libbackend.a(modulo-sched.o): In function `doloop_register_get':
> ../../gcc/gcc/modulo-sched.c:284: undefined reference to
> `doloop_condition_get'
>
> doloop_end isn't defined
On Mon, 2005-06-06 at 11:05 +0100, Richard Sandiford wrote:
> Thanks for the summary. It sounds from your message, and particularly
> the quote from RMS, that we should be accepting the patches unless we
> have a particular reason not to trust MIPS to do what they said they'd
> do. I certainly ha
On Tue, 2005-06-14 at 01:04 -0700, Jim Gifford wrote:
> I just wanted to ask a question about the tri-arch setup for MIPS under
> IRIX.
>
> Is this planned for libraries other than IRIX based shared libraries,
> will this capability be extended to the linux shared libraries?
>
Short answer: it
On Mon, 2005-06-20 at 15:02 +0930, Mark Williams (MWP) wrote:
> Thought i should report this...
>
> Building 4.0.1 RC2, i get this error:
>
> make[1]: Leaving directory `/data/backup/linux/gcc/gcc-4.0.1-20050616/intl'
> make[1]: Entering directory
> `/data/backup/linux/gcc/gcc-4.0.1-20050616/buil
>
> Yes i did... i always do and have never had a problem doing so before.
> I will try building in a different directory though and report back.
http://gcc.gnu.org/install/configure.html
To be honest I'm always surprised when it works at all.
-eric
ng like this for
mainline too?
-eric
2005-06-21 Eric Christopher <[EMAIL PROTECTED]>
* configure.in: Reject building in the source directory.
Index: configure.in
===
RCS file: /cvs/gcc/gcc/configure.in,v
retrieving
On Tue, 2005-06-21 at 18:24 -0400, DJ Delorie wrote:
> > Like so? Tested by building outside the source directory and
> > attempting to build in the source directory. Did we want something
> > like this for mainline too?
>
> We've historically put a lot of effort into making "./configure" work,
>
On Tue, 2005-06-21 at 15:31 -0700, Eric Christopher wrote:
> On Tue, 2005-06-21 at 18:24 -0400, DJ Delorie wrote:
> > > Like so? Tested by building outside the source directory and
> > > attempting to build in the source directory. Did we want something
> > &
On Wed, 2005-06-22 at 07:06 -0700, Mark Mitchell wrote:
> Eric Christopher wrote:
> >>
> >>If someone wishes to submit a patch for that bug for 4.0 branch, I expect
> >>it could be considered for 4.0.2 but might be too risky for 4.0.1 now.
> >>
> >
> So your target audience is "people who use newlib, use the uberbaum
> build, and who work on multiple gcc trees", right? Seems
> like such a small audience it's not likely to be widely used,
> but that's just my impression.
I agree unfortunately. Really if you're not wanting to have a single
t
> [It's not a real scenario of course, but it does have the right flavor
> of the problem I wish to solve.]
> It's the day-to-day development of a fresh port that I want to speed up.
> If I've gone through a run of "make check-gcc" and fixed some random
> bugs, with fixes in any or all of libgloss
On Fri, 2005-07-08 at 20:43 +0800, IM.Nobody wrote:
> I can hardly believe there is no port of GCC to MIPS-X. Any clue would
> be helpful and greatly appreciated.
The question has been asked numerous times on the list. There's no port
because no one has done the work. Patches to support this will
> What do others think about this patch? If people think, it is OK
> to have one additional knob for users then I'll test and submit
> formal patch.
>
> I'll treat silence as, this idea is not OK for FSF GCC. I'd like to
> give Jason and our customers compiler with such fix ASAP. And if
> it is c
> Would be nice if someone could approve it.
>
It's not in a state that could be approved yet, but hopefully after some
cleanup it will be.
-eric
On Wed, 2005-07-13 at 14:05 -0700, Mike Stump wrote:
> On Jul 13, 2005, at 12:39 PM, Eric Christopher wrote:
> >> Would be nice if someone could approve it.
> >
> > It's not in a state that could be approved yet, but hopefully after
> > some
> > cleanu
On Aug 3, 2005, at 5:48 PM, Jack Howarth wrote:
Does anyone know if the -fstack-protector option in gcc 4.1 branch
works on Darwin 8 (Tiger)? I can compile binaries with it but I'm not
sure how to test its functionality. Also, this is based on IBM's
ProPolice
code, right?
I'm surprised
Would that be useful, or is it overkill?
Very useful. Though if you can occasionally go back through them to
verify they're still bugs it'd be appreciated.
-eric
On Aug 19, 2005, at 5:07 PM, Andrew Pinski wrote:
Hi,
With this page from Wikipedia, http://en.wikipedia.org/wiki/
GNU_Compiler_Collection, in the "See also" section,
there is a sentence about a Garbage collected included in GCC.
There's also boehm-gc:
http://www.hpl.hp.com/personal/H
I have met the same question. My solution to this is just to
remove ./config.cache in every sub-directories and try again. This
solution is effective although I am not sure about it. Anyone
could confirm or deny this.
I think "make distclean" should be done before ./configure if the
On Aug 25, 2005, at 5:53 PM, Ivan Novick wrote:
Yes understood, but thats the whole point, cygwin runs on a windows
machine... I would like to use a UNIX machine to compile the
Windows DLL.
You can cross compile to cygwin using gcc.
An old link from google with "cross compiler cygwin" is
On Aug 31, 2005, at 3:40 PM, girish vaitheeswaran wrote:
I do not see this flag in gcc3.4.4.
Am I missing something?
you may try adding -fmove-loop-invariants flag,
which enables new
invariant motion pass.
The "new invariant motion pass".
-eric
Exactly to say, the target is neither mips-elf nor mips-linux-gnu.
I just
use mips-elf as the start. It's a new target with little endian and
own ISA.
We need to port binutils and gcc and also library.
For a port then yes *-elf is easier to start, especially if you're
planning on going f
I would prefer a recipe to build the toolchain myself
from source, but if you happen to know of a site with
binaries for the SB1 under Linux, I wouldn't be
horribly opposed.
For the latter I'd try broadcom, they've been pretty good about
shipping tools that are known to work on the board. Tha
On Sep 6, 2005, at 6:44 PM, Mike Stump wrote:
On Sep 6, 2005, at 6:16 PM, Gabriel Dos Reis wrote:
wrong-code generation that was fixed.
Customers validate their app and are `happy' with the code
generation, so this appears to not be a real an issue. Failure to
compile their app to the
On Sep 9, 2005, at 10:28 AM, sean yang wrote:
Hi
I am looking for the source code related to linking stage--coz I am
trying to modify (very slightly) the linker. I understand that 'ld'
is the linker in Linux. My question is:
Is 'ld' a part of gcc toolchain?
--If it is, I should be able to
=
Both binutils and glibc's configure scripts will see
it as a mips32, because it does not start off with
mips64 in the name.
Should probably fix the configury to recognize mipsisa64 as a 64-bit
target. binutils should already do this for mipsisa64-linux-gnu, but
I don't know about current g
On Sep 12, 2005, at 7:17 PM, Steven J. Hill wrote:
Greetings.
I attempted to search through Bugzilla, but I did not find anything
that
matched my query. When using the options '-O0' and '-g' together
with GCC-4.1.0,
I get an executable that will segfault. If I use all the other
optimizat
I assume you mean using the gdb simulator, or what? Sorry for my
ignorance.
Yup.
Otherwise, what's the code look like where they segfault?
Let me quantify that and I will post a tarball tomorrow. Thanks.
OK. I don't have any mips hardware at the moment, but I should be
able to he
I am the opposite of an expert on this topic. But in fact gcc does
appear to have code related to (A), (B), and (C). I repeat those
choices here from Paul's original e-mail:
A. Convert everything to UCNs in basic source characters as soon
as possible, that is, in translation phase 1
The only issue I can see is that someone who uses an older versions
of Mac OS X but don't have
access to the newer GDB because building Apple's version of GDB is
a little harder than
building than gcc. If you provide a gdb version which is runnable
on All of Mac OS X,
this becomes a littl
Actually it enables more than the builtins. It enables the use sse3
instructions. This is just like -maltivec on PowerPC and -msse and
-msse
on x86, etc.
Right, so the manual disagrees and should probably be fixed.
And then RTH agreed:
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01432.h
On Oct 12, 2005, at 4:40 PM, guru venky wrote:
I am trying to add a mips instruction with operands to gcc. Basically
I want an instruction that acts as marker for a future instruction.
as an example,
if i want a marker for addi R1,constant (add immediate) instruction, i
would do something lik
On Oct 24, 2005, at 3:52 PM, Neil Booth wrote:
Howard Hinnant wrote:-
I've been reviewing the age-old issue of interpreting
* as the end-of-line indicator as is the current
practice with gcc.
FWIW I support abandoning this behaviour too.
I filed bugzilla 24531 about this.
Haven't heard J
Oh, one more thing. This seems like the normal problem of not
reading the docs
if something does not work the way you want it to work.
So?
The only thing we can do is point it out that it is documented
behavior and
then move on to the next issue. Also why are we discussing this when
th
This is not a regression really.
It is a regression against 2.95.
-eric
As I said, no it is not. A behavior change is only a regression when
the first behavior is correct and the second is not.
Fair enough. :)
-eric
I don't see either is true here.
Actually, I agree. While I'd like the change to the compiler, I don't
want it to be a switch. Either we do it, or we don't.
-eric
Don't you think it is reasonable to fix horrible coding
errors like this, you are just asking for maintenance
problems. In the short term, kludging may make sense,
in the long term it sounds a bad idea to keep such
non-portable code around.
The problem is that it's portable to every other compi
On Oct 26, 2005, at 5:55 PM, Joe Buck wrote:
On Thu, Oct 27, 2005 at 01:48:57AM +0200, Vincent Lefevre wrote:
On 2005-10-26 12:39:31 -0400, Andrew Pinski wrote:
But in a way you are defending it as you want GCC to change. If
there
was any other reason besides ASCII art, some people would be
I'm good with this proposal. I was against the flag in the first
place for a desire to pick something and let's do that, but it seems
like with so much furor over it we should probably just have a flag. :)
-eric
apps built w/ -fstack-protector-all segfault
You will have to give us more info. Most gcc developers probably
don't have a copy of UClibc, and plus it sounds like you have made
gcc changes that weren't included in your message. So there isn't
much we can do here except ask for more det
this should also influence the -fstack-protector behaviour, but
that seems
to be OK.
__builtin_trap is used as I can see only if a vulnerability is
found, this
happens though on a simple hello world.
Aaah. You'll probably need to step through the program in a debugger
then and find out
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22082
Unfortunately, even with my Apple Developer account I can't seem to
figure out how to look up radar reports that I haven't submitted.
I took a look at the radar. Says, effectively, that the bug has been
fixed in ld64 and will be in the next
1 - 100 of 189 matches
Mail list logo
