bug report, the problem is that CC1_SPEC
is the wrong one.
Adding EB/EL to CPP_SPEC will only fix the C/C++/Objective-C front-ends
and no others.
The attached patch is the more correct way to solve this.
Thanks,
Andrew Pinski
Index: mips.h
gt; }
This should error out and it is a regression from previous versions (I
can check which ones but I think 3.4.0 rejected it). The two targets
that I work on daily at work (including the language extension
specifications), both say this is invalid code and should be rejected.
Thanks,
Andrew Pinski
me thing because I just made sure
of it last week when I was editing that specifications.
Thanks,
Andrew Pinski
ET_CC1_SPEC "%{profile:-p}"
+
/* If we don't set MASK_ABICALLS, we can't default to PIC. */
#undef TARGET_DEFAULT
#define TARGET_DEFAULT MASK_ABICALLS
Thanks,
Andrew Pinski
T_CC1_SPEC is a good second idea of where it
should be defined.
Thanks,
Andrew Pinski
>
> With svn r117549 bootstrapped on mipsel-none-linux-gnu:
Usually people us gcc_update in contrib to update their
sources which fixes this problem by touching the files
which need to be touched.
Thanks,
Andrew Pinski
On Sat, 2006-10-14 at 21:14 +0100, Martin Michlmayr wrote:
> There have been some discussions recently about a possible release of
> 4.1.2 in the near future and the following information might be useful
> in this debate. Matthias Klose asked me to test 4.1.2 20061007 to
> see whether it can be us
testing ignore.
-- Pinski
> On 17/10/2006, at 11:45 AM, Jack Howarth wrote:
>
> > Geoff,
> >I noticed that the automake maintainers
> > accepted your patch for fixing the multilib
> > issues in automake. However they also seemed
> > to indicate that there would be no more 1.9.x
> > automake releases.
> >Is the r117
>
> msched-epilog
> Target Undocumented Var(TARGET_SCHED_PROLOG) VarExists
>
> This appears of course to be wrong.
Did you miss VarExists part of line?
Thanks,
Andrew Pinski
which can be found at
http://www.codesourcery.com/cxx-abi/ .
Thanks,
Andrew Pinski
You can have a whole program in one source module so the warning would
get in the way of that case. Plus -combine is useless in that case
also. In fact -combine will go away once LTO finishes.
Thanks,
Andrew Pinski
branching checklist.
As I understand it, it involves editing the mysql database by hand (well
by a script) instead of doing it inside bugzilla. Daniel Berlin has
done that the last couple of releases.
Thanks,
Andrew Pinski
n
you are noticing here is called forward propagation.
Thanks,
Andrew Pinski
>
> It seems that the GMP test is always run, even when installing binutils
> or gdb.
>
> You probably need something like
>
> 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 topleve
>
>
> >> 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 really a good thing
od?
Find how and what? Find the FUNCTION_DECL? (you should already have
that.) Find the body of the function? (function decl has that.) Find
where the function is defined in the source? (the lotus of the function
decl should say where that is).
Thanks,
Andrew Pinski
o CFG at the time you are looking
through the calls.
Why do you need to know the constructor anyways?
Thanks,
Andrew Pinski
On Wed, 2006-10-25 at 13:32 +0900, Paolo Bonzini wrote:
> > I'm more content with the gmp check at the top level and don't plan to
> > submit a change to that. Although I agree if this configure is shared
> > between binutils, gdb and gcc, and you're not compiling gcc, then it
> > shouldn't requir
toplevel
seems correct, maybe someone should add a plugin for the toplevel
configure so we don't end up in a case where they compile for hours and
then find out they need a program or a library installed.
For right now I say we keep this at the toplevel until that gets solved.
Thanks,
Andrew Pinski
On Wed, 2006-10-25 at 14:14 +0900, Paolo Bonzini wrote:
> Not as bad as you put it, if installing and typing "make" solves the
> issue (either for zip/unzip or gmp/mpfr, it is the same). I'll let the
> maintainers decide.
See my other email which explains why it is not user friendly. Waiting
2
>
> > and seeing the reaction of people,
> > I probably won't use it. The main reason for considering to use
> > the tree node for me was the possibility to make the number of iterations
> > of the loop as its operand, so that I would not need to worry about
> > keeping it alive through dce, copy
The question now has come to the following point:
Do we want to explict in the IR or have a side table which we use to mark the
SSA_NAME as still useful.
They both have pros and cons. But I say we want to be as explict in the IR
as possible.
Thanks,
Andrew Pinski
PS sorry about my return email add
On Thu, 2006-10-26 at 17:37 -0300, [EMAIL PROTECTED] wrote:
> Hi, I've come with a problem with g++ 4.1.1 and people at gcc-help said
> they think it's a bug, so I'll forward my original email to this list.
And this is the same issue as PR 11407, http://gcc.gnu.org/PR11407 .
-- Pinski
don't call fold but call the other functions, fold_buildN or fold_unary/binary,
etc. instead.
Also some tree optimizers use fold to calculate stuff like how many interations
a loop can run for so the number is bit useless in general if you gather it via
fold directly.
Why do what to know how many simplifications has happened?
Thanks,
Andrew Pinski
On Mon, 2006-10-30 at 09:57 -0800, Geoffrey Keating wrote:
> Hi Kaveh,
>
> 1. Is this intentional?
Yes, do you read any of the mailing lists?
>
> 2. Is it supposed to apply to the host, the target, or both?
HOST.
>
> 3. If it's intentional, what is the list of platforms that you
> intended
>
> On 10/30/06, Marcin Dalecki <[EMAIL PROTECTED]> wrote:
> >
> > On 2006-10-30, at 21:37, Daniel Berlin wrote:
> > > Honestly, I don't know any mac people who *don't* use either fink or
> > > macports to install unix software when possible, because pretty much
> > > everything has required some
ltivec PIM
is very clear about "vec_add(vector unsigned int, vector signed int)", it is
not valid code.
Likewise the "C/C++ Language extension for CBEA 2.2" is also clear with respect
of
"spu_add (vector unsigned int, vector signed int)". If we accept those what is
the return type?
Thanks,
Andrew Pinski
> > and that you break their code.
>
> ...is more of a concern, I agree, and is what I worry about most.
The other question how of this was accepted in 3.4.0 or earlier because
the behavior changed in 4.0.0 with respect of accepting these code.
Thanks,
Andrew Pinski
user code unless they are using 4.0.0 and above only.
Thanks,
Andrew Pinski
> So, now if I tell you that despite all reports that it 'works fine',
> I'm getting
>
> > FAIL: gcc.dg/torture/builtin-sin-mpfr-1.c -O0 (test for excess
> > errors)
>
> do you think this is likely to be:
> 1. some problem in gmp or mpfr,
> 2. some problem in my build of gmp and/or mpfr, th
>
> > So, now if I tell you that despite all reports that it 'works fine',
> > I'm getting
> >
> > > FAIL: gcc.dg/torture/builtin-sin-mpfr-1.c -O0 (test for excess
> > > errors)
> >
> > do you think this is likely to be:
> > 1. some problem in gmp or mpfr,
> > 2. some problem in my build o
>
> Steven Bosscher wrote:
>
> >
> > So you don't report any error messages at all and leave us guessing?
> >
>
> AFAIK fortran is not supposed to be configured at all for a cross-compiler.
> Or has that changed recently? It was certainly not configured in my
> previous
> builds of gcc 4.2
s the problem with this is that we have to support this flag for a long time
but the benifit is that we can change the default to the new way with just
flipping
a switch.
Also it would be nice to have an attribute or a new keyword to get the old
"extern
inline" behavior, something like __extern_but_inline? Or is there a real
equavilant
with C99 style inling (I have not followed this part close enough to figure
that out).
Thanks,
Andrew Pinski
uring compiling but the assembler does. Is
this correct or should we actually reject this during compiling?
Thanks,
Andrew Pinski
>
> Hello!
>
> Does anybody else get these errors in libgfortran during clean bootstrap:
>
> ...
>
> This happens on x86_64-pc-linux-gnu and i686-pc-linux-gnu, FC4.
Yes and it was already discussed in
http://gcc.gnu.org/ml/gcc/2006-11/msg6.html
-- Pinski
atest
release version of their OS and the previous version or we should remove
Darwin from being a primary/secondary platform until they are able to.
Thanks,
Andrew Pinski
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.
Thanks,
Andrew Pinski
(so is 10.3).
Thanks,
Andrew Pinski
rtl).
Andreas, next time can you report the options you pass to configure as
a simple bootstrap just passed for me without any extra flags.
Thanks,
Andrew Pinski
er pace than chip
> improvements over the years. :-)
The other thing we could do is enable it only for stage1 (bootstrap's stage1)
by default,
just like we do for normal checking[1].
Thanks,
Andrew Pinski
[1] well that was broken with toplevel bootstrap, see the patch at
http://gcc.g
On Wed, 2006-11-08 at 14:33 +0100, Bruno Haible wrote:
> Hi,
>
> 2006-11-07 Bruno Haible <[EMAIL PROTECTED]>
>
> * config/tls.m4 (GCC_CHECK_TLS): Also check whether the libc supports
> TLS via __thread.
How well does this work with cross compiler?
Thanks,
Andrew Pinski
e cases for -ffixed-form and
-ffixed-line-length. Add a case for -lang-fortran.
Thanks,
Andrew Pinski
>
> How do i determine if two type nodes in the C front end are equivilent?
> In C++ i use same_type_p() but do not see an equivilant for the C front end.
The function you want is comptypes.
Thanks,
Andrew Pinski
also to look into archives for files
with LTO info in them and be able to read them inside the compiler also.
Thanks,
Andrew Pinski
function mechanism that is already in GCC seems like a good
thing. In fact I think of lambda functions as nested functions.
Thanks,
Andrew Pinski
is
is not really part of the compiler so you will not get wrong code from
the compiler, just the testcase will break. If you find some, report it
instead of just complaining about it.
Thanks,
Andrew Pinski
cause foo might never be
called, the example given must be successfully translated by a
conforming implementation.
Thanks,
Andrew Pinski
e except via an unsigned/signed character type is undefined.
Thanks,
Andrew Pinski
doing what it is designed to do. -D_FORTIFY_SOURCE=2
means warn when you are ignoring return values and other stuff. If
chdir fails you should handle that case and not just ignore it like you
are doing.
Thanks,
Andrew Pinski
>
> All,
>
> So, again, Is gcc planning on automatically moving to gpl version 3, staying
> at gpl version 2, or having a protracted discussion? What happens if some
> developers decide they want to stay at 2 and others decide they want to
> go with 3?
We (developers/SC) don't have control over
On Sun, 2006-11-19 at 05:57 +0200, [EMAIL PROTECTED] wrote:
> > Errr, LOOP_EXPR doesn't actually exist anymore :)
> > Loops are always lowered to if-then-else and gotos.
>
> That's nice! I'll check on how things are handled now. Is this true for latest
> release, mainline - current gcc trunk, or g
On Wed, 2006-11-22 at 22:52 +0100, Daniel Franke wrote:
> The tarball of 4.1.1 includes fastjar/fastjar.info, but not
> libiberty/libiberty.info. The config file fastjar/configure.ac has the
> enable-...-srcdir flag, libiberty/configure.ac does not.
This is because libiberty's API is all interna
s, instead it
mentions compatibility of struct based on the element layout.
So what you are asking for is really not going to be the right thing.
For full C rules you might able to read the function comptypes_internal
in c-typeck.c or the C standard. In fact IIRC C99 has slightly
different rules than C89.
Thanks,
Andrew Pinski
(like 99% of the time), this means you GMP/MPFR are broken
and is causing gfortran to crash out.
You might want to try running mk-kinds-h.sh to see what the error
is?
Thanks,
Andrew Pinski
ned by: function_types_compatible_p() then the strings
> should be equal.
Again C has different rules from C++.
In C, the following two TUs combined together are still valid code while in C++,
they are invalid.
tu1.c:
struct a
{
int t;
};
void f(struct a);
---- cut -----
tu2.c:
typedef struct
{
int t;
}b;
void f(b a);
cut -
Thanks,
Andrew Pinski
the base+offset.
We have found that we currently get better results with our current IR,
with type based aliasing first.
Thanks,
Andrew Pinski
>
> I have code that goes something like this:
>
> char *foo(char *buf){
> *buf++ = 42;
> *((short*)buf) = 0xfeed;
> buf += 2;
> *((int*)buf) = 0x12345678;
> buf += 4;
> *((int*)buf) = 0x12345678;
> buf += 4;
> return buf;
> }
This does violate C aliasing rules.
>
> On 11/28/06, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> > > I often need to convince people that gcc is not just
> > > defective for doing random nonsense to code which
> > > violates the C and C++ aliasing rules. Not that I'm
> > >
On Thu, 2006-11-30 at 16:08 +1100, Brendon Costa wrote:
> Hi again,
> Is it safe to assume in the C++ front end that two functions declared in
> such a manner will always share the same implementation in which case it
> is kind-of like a "using" statement?
The C++ front-end is broken and needs t
in
the last couple of weeks.
> Is there any plan to enforce warnings about implicit type conversion ?
http://gcc.gnu.org/wiki/NewWconversion
-Wconversion in 4.3.0 and above.
Thanks,
Andrew Pinski
ces
> definitely want pointers.
Then create an union which contains the two different types of call
back.
You know:
union a
{
void (*callbackwithulong) (unsigned long);
void (*callbackwithptr) (void*);
};
And then you just use the correct in the correct place.
I don't see why there is
d away, so what's the point adjusting esp?
This testcase has already been fixed in 4.2.0. There are other related
memcpy cases which have not been fixed yet though.
The reason why the pointer adjust is happening is that the local
variable is not really optimized away until after it was already placed
on the stack.
Thanks,
Andrew Pinski
> You can work around this by using union's of pointers of both non-const
> and const types, but the reinterpret_cast solution would be more attractive.
>
> Thoughts?
This has nothing to do with const vs non-const but rather
a and a are two seperate types which are not related in any way.
The C+
>
> Andrew Pinski <[EMAIL PROTECTED]> writes:
>
> | > You can work around this by using union's of pointers of both non-const
> | > and const types, but the reinterpret_cast solution would be more
> attractive.
> | >
> | > Thoughts?
> |
>
TER code?
I would prefer you don't expose latent bugs and fix them before applying
the patch.
If we go by this, I would have applied my fold-const.c patch to convert
*(othertype*)&type to VIEW_CONVERT_EXPR a long time ago but it exposes
problems with stuff like ((structtype*)&b)
available?
> I suspect that this is yet another Darwin is a broken
> OS problem.
In case anyone does not know yet, the warning is the same as PR 29779.
I don't remember if this was mentioned or not.
Thanks,
Andrew Pinski
in
objc/objc-api.h in libobjc).
> Where should I look in the source code of gcc to know it?
objc-act.c
I don't know how much about how the NeXT runtime works except instead of
a function pointer, it uses a call to a function to call the messages.
Thanks,
Andrew Pinski
loops=0xa5e6358, flags=6)
at ../../gcc/loop-unroll.c:190
Also there is a progressions in that gcc.c-torture/compile/2804-1.c
no longer ICEs at -O3 -funroll-loops.
I will run the full testsuite tomorrow when I get to work as I have
access to hardware there.
Thanks,
Andrew Pinski
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.
Thanks,
Andrew Pinski
nu.org/gcc-4.3/changes.html
Because some people liked the old behavior when debugging the driver.
Thanks,
Andrew Pinski
>
> Andrew Pinski wrote:
> >> What are the contents of t.c? What if you set GCC_EXEC_PREFIX?
> >
> > t.c:
> >
> > #include
> > int main(void)
> > {
> > printf("Hello World\n");
> > return 0;
> > }
> >
>
es where the compiler you are
building with understand an option but the bootstrapping one does not.
An example of this is building GCC with a non GCC compiler. So how do
we handle that case, we split out STAGE1_CFLAGS and BOOT_CFLAGS.
Thanks,
Andrew Pinski
x27; on i686-pc-linux-gnu will cause bootstrap failure as
-mcpu= is deprecated in 3.4.0 and above.
Thanks,
Andrew Pinski
+ and has already been
documented
on http://gcc.gnu.org/gcc-4.1/changes.html:
# ARM-style name-injection of friend declarations is no longer the default. For
example:
struct S {
friend void f();
};
void g() { f(); }
will not be accepted; instead a declaration of f will need to be present
outside of the scope of S. The new -ffriend-injection option will enable the
old behavior.
Thanks,
Andrew Pinski
me on
this list.
> and I haven't tested GCC in several months before, so I have no idea
> when this was introduced.
-fwrapv was introduced on 2003-05-31, so for 3.4 to fix some Java
testcases which were failing already from the 1992 patch. We are only
recently taken into overflow being undefined more recently which is why
people are just seeing it now rather than back in 1992 :).
Thanks,
Andrew Pinski
d since loops are now more
important to optimize than anything else, well knowing the number of
iterations is very important.
Thanks,
Andrew Pinski
ut it being too strong is wrong because timming matters now a days.
Instruction
scheduling can cause the same issue as it forces a write too early for another
thread
to act on.
Thanks,
Andrew Pinski
On Fri, 2006-12-22 at 17:08 +, Dave Korn wrote:
> Misaligned accesses *kill* your performance!
Maybe on x86, but on PPC, at least for the (current) Cell's PPU
misaligned accesses for most cases unaligned are optimal.
Thanks,
Andrew Pinski
On Fri, 2006-12-22 at 12:30 -0500, Robert Dewar wrote:
>
> > Maybe on x86, but on PPC, at least for the (current) Cell's PPU
> > misaligned accesses for most cases unaligned are optimal.
>
> is that true across cache boundaries?
For Cell, crossing the 32byte boundary causes the microcode to hap
bvious after a bootstrap/test on i686-linux-gnu
(with C only).
Thanks,
Andrew Pinski
ChangeLog:
* vec.c: Don't include tree.h.
* Makefile.in (vec.o): Update dependencies.
(build/vec.o): Likewise.
I
and then see if an overflow happened
}
//etc. for the other type
This way you don't depend on either implemenetation defined behavior
of converting between integer with different sizes and undefined behavior
with signed type overflow.
Thanks,
Andrew Pinski
>
> Andrew Pinski <[EMAIL PROTECTED]> writes:
>
> | >
> | > Paul Eggert <[EMAIL PROTECTED]> writes:
> | >
> | > > * NEWS: AC_PROG_CC, AC_PROG_CXX, and AC_PROG_OBJC now take an
> | > > optional second argument specifying
printf("Need another integeral type sized, %d\n", sizeof(type)); \
abort (); \
} \
}
Yes people think macros can be less reabable, but this one case actually makes
it readable.
Thanks,
Andrew Pinski
Actually IIRC freebsd and netbsd has already corrected all of the aliasing
issues
in the BSD network stack. In fact I remember helping one place that was exposed
in the last 4 years.
Thanks,
Andrew Pinski
U tar. And Python. I'm sure there are
> many other significant programs. I don't have time to do a
> comprehensive survey right now.
Where does GCC rely on that? I don't see it anywhere?
If you can point out specific spots, please file a bug and
I will go and fix them.
Thanks,
Andrew Pinski
>
> Andrew Pinski <[EMAIL PROTECTED]> writes:
>
> | >
> | > C has been a portable assembler for years before it got normalized and
> | > optimizing compilers took over.
> |
> | 18 years. And now it has been 17 years since C has been standardized so
>
do you mean including the target
libraries?
Thanks,
Andrew Pinski
in code even if GCC did not create the "wrong" code yet.
The developer
was able to fix his code before he even started to compile the code.
Thanks,
Andrew Pinski
t as it is just a link to that
insn.
Attached is a patch which fixes the ICE though I have not bootstrapped and
tested
it yet.
Thanks,
Andrew Pinski
s the ICE though I have not bootstrapped and
> tested
> it yet.
Lets try to attach the patch this time.
Thanks,
Andrew Pinski
Index: emit-rtl.c
===
--- emit-rtl.c (revision 120287)
+++ emit-rtl.c (working copy)
@@ -5302,
>
> Andrew Pinski <[EMAIL PROTECTED]> writes:
>
> > >
> > > > Hi,
> > > > thanks for testing. I've bootstrapped/regtested this variant of patch
> > > > and comitted it as obvious.
> > >
> > > Since this is
> > Andrew Pinski <[EMAIL PROTECTED]> writes:
> >
> > > >
> > > > > Hi,
> > > > > thanks for testing. I've bootstrapped/regtested this variant of patch
> > > > > and comitted it as obvious.
> > > >
>
SA) tree TR has a position
> * and in that case fill the PFILENAME and PLINENO
> ***/
> bool comprobe_get_position(tree tr, char**pfilename, int* plineno)
> {
> if (EXPR_P (tr))
This really should be simplified to:
if (CAN_HAVE_LOCATION_P (tr) && EXPR_HAS_LOCATION (
>
> Gabriel Dos Reis wrote:
>
> > I have been looking into infer_loop_bounds_from_signedness() called
> > from infer_loop_bounds_from_undefined().
> > At some places, nowrap_type_p() is used but this function operates
> > only on types, so there will be too many false positive there; yet we
> > w
>
> Andrew Pinski wrote:
>
> >> -fwrapv-in-all-cases-except-loop-bounds
> >
> >
> > Again, please don't this the default for Fortran as integer
> > overflow has been undefined since at least 1977 so I don't think
> > it is a g
> ...
Did someone forget to tell you that AIX 4.3 and above are not really
supported by the GNU binutils anyways? So it is kinda of useless to
have a cross compiler which does not work anyways :).
Also since I have not seen in the thread at all, what options are you passing
to configure? Are you using a sysroot or some other way of having the
libraries?
Thanks,
Andrew Pinski
lict in some are wrapping, others are saturation (most of the
VRP and a-'0'>9) and then more are extending (a*10/5).
Thanks,
Andrew Pinski
On Mon, 2007-01-01 at 22:21 -0500, Richard Kenner wrote:
>
> Of course, this is an example where either the programmer is doing
> something
> very silly or else is expecting overflow and depending on wrap
> semantics.
or it comes from inlining of something like get() which has bounds
checking.
-
>
> Today I updated the Autoconf manual to contain the following
> description of the current situation with signed integer overflow.
> This section of the manual is intended to advise programmers what to
> do about portable C programs in this area.
>
> I think some discussion along these lines a
1 - 100 of 1801 matches
Mail list logo
