ratio?
And finally:
- portability of svn to non-Linux systems
Thanks in advance.
--
Eric Botcazou
> Irrespective of the other issues currently discussed, this is a very
> good idea!
Seconded!
--
Eric Botcazou
libgcc, it is not ok in _pack_df.o.
So what's the problem?
Thanks.
Eric.
> It does not fail for power and I'm trying to figure out why it fails for
> x86 architecture.
SPARC is also affected, but in 32-bit mode only.
--
Eric Botcazou
e not defined then
they will use 'bcond' like. But while I omit 'scond', gcc will fail
error that such operation rtl doesn't define. So why?
Thanks again.
Eric
>It shouldn't. What is the actual error message?
>
>Ian
Such as follows,
dp-bit.c: In function `__pack_d':
dp-bit.c:435: error: unrecognizable insn:
(insn 33 32 34 0 dp-bit.c:167 (set (reg:SI 159)
(ltu:SI (reg:SI 158 [ .class ])
(const_int 2 [0x2]))) -1 (insn_list 32 (nil))
itten in glibc (in
particular the 'alloc' line) is quite annoying. Or is that a lost cause and
should profiling require static linking in presence of nested functions?
Thanks in advance.
--
Eric Botcazou
da to be used in that cases either, but who knows. ;-)
Thanks for your decisive help.
--
Eric Botcazou
hich is the codes as following at emit-rtl.c:819,
/* Don't let anything called after initial flow analysis create new
registers. */
if (no_new_pseudos)
abort ();
Why can't I create a new register? So how should I do to implement it?
Thanks for your help time after time.
Eric.
believe that
option a is needed at least.
This is, as Mr. Buck has noted, a regression from 2.95.
-eric
there are more important bugs to fix currently as this behavior has
been documented
for a long time, at least 4 years.
Your important and my important are two different things.
-eric
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
"=r")
(mem:QI (match_operand:SI 1 "general_operand" "r")))]
""
"lbu.u\t%0,0(%1)"
)
The compiler comes out such error,
error: insn does not satisfy its constraints
(insn 349 53 46 4 ../../gcc-3.4.4/gcc/unwind-pe.h:212 (set (reg:QI 1 $1)
(mem/s:QI (plus:SI (reg/v/f:SI 9 $9 [orig:154 p ] [154])
(const_int 1 [0x1])) [12 S1 A8])) 45 {} (nil)
(nil))
Well, it seems not work.
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
very other compiler we've
tested. I am curious what icc and xlc do, but those are the only
two not tested.
-eric
ntioned it. :)
However, the "this is a small implementation defined issue that's
easy to change for users that are migrating from other compilers"
issue remains.
-eric
register_operand (src, mode))
{
src=force_reg (mode, src);
return true;
}
I think since emit_move_insn (dest, force_reg (mode, src)) precedes
the rtl template
[(set (match_operand:SI 0 "nonimmediate_operand" "")
(match_operand:SI 1 "" ""))]
Then they are overlapped. There will be two move insns.
Thanks.
Eric.
nsn within the preparation
statements; the RTL template will not be generated.
No need to reply for saving your time.
Thank.
Eric
What should we do about that? Conditionalize the combined FP operations on
-ffast-math or something along these lines?
Thanks in advance.
--
Eric Botcazou
extern void abort (void);
typedef struct
{
float X;
float Y;
float Z;
float S;
} Unit_Quaternion_Type;
Unit_Quaternion_Type M
n", but I might be wrong.
--
Eric Botcazou
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
> Fused multiply-add always uses "infinite precision" in the intermediate
> result. Only a single rounding is performed at the end.
Of course, but I was implicitly referring to the 82-bit thing. But it seems I
was wrong, as the testcase fails on PowerPC w/ -mfused-madd too.
--
Eric Botcazou
(dw2_output_indirect_constant_1): Try to output indirect constants
into linkonce sections if possible.
(dw2_force_const_mem): Likewise. Register indirect_pool with GGC.
(dw2_output_indirect_constants): Likewise.
Thoughts?
--
Eric Botcazou
#include
extern void b
he bug is in the C++ front end in how we
> mangle (or not) the local class.
Yes, I think that's the crux of the matter: for the time being, neither the
C++ nor the Ada front-end mangles local exceptions. Either they should or
the problem lies in the EH machinery.
--
Eric Botcazou
and add in GCC but I would hate to see its use turned off
> by default.
If that's the consensus among IA-64 maintainers, it's fine with me.
--
Eric Botcazou
posed to be local to the translation unit.
--
Eric Botcazou
.weak DW.ref._ZTIZ3foovE1S#
.section.gnu.linkonce.s.DW.ref._ZTIZ3foovE1S,"aws",@progbits
.align 8
.type DW.ref._ZTIZ3foovE1S#, @object
.size DW.ref._ZTIZ3foovE1S#, 8
DW.ref._ZTIZ3foovE1S:
data8 _ZTIZ3foovE1S#
Found both in u.S and
So,
while the 2 DW.ref._ZTIZ3foovE1S symbols are advertised as being identical,
their contents would *not* be identical at link-time.
--
Eric Botcazou
only in Ada. I suspect it's not so easy in C++.
Anyway the generic fix turns out to be straightforward so I think we should
take that path.
--
Eric Botcazou
(set (reg:SI 3 $3 [296])
(ltu:SI (subreg:SI (reg:DI 12 $12 [294]) 0)
(subreg:SI (reg/v:DI 263 [ pp_ll ]) 0))) 74 {sltu_internal} (insn_li
st 415 (nil))
(nil))
dp-bit.c:957: internal compiler error: in find_reloads, at reload.c:3690
Best regards.
Eric
onst_int 0 [0x0])
(nil))
(expr_list (use (reg:SI 6 $6))
(expr_list (use (reg:SI 5 $5))
(expr_list (use (reg:SI 4 $4))
(nil)
Can you where is the memcpy? And how the compiler call this funcion
implicitly?
Need I implement it?
Thanks.
Eric.
to be restored too. Incidentally, the current code
probably works in that case, but I think it cannot happen in practice.
--
Eric Botcazou
with Ada.Text_IO;
procedure P is
type Int_Ptr is access all Integer;
Data : Int_Ptr := null;
begin
Data.all := 0;
exception
when others =>
Ada.Text_IO.Put_Line ("Exception handled");
end P;
e on Solaris 9):
check_effective_target_static_libgfortran doesn't work because it doesn't
compile with -static:
/opt/build/eric/gcc-4_0-branch/gcc/xgcc
Testing gfortran.dg/static_linking_1.f, -O0
check_effective_target_static_libgfortran: `' `unix'
check_effective_target_static_libgfortran compili
> Why O3 rather than O2, I thought O3 was just O2 + implicit inlining
In the old days only, i.e. that has not been true since 3.1 at least.
--
Eric Botcazou
> I'm using "sparc-sun-solaris2.9" for the target... Does the 2.9 indicate
> the target version of Solaris, or the version of the SPARC architecture, or
> ??? .
2.9 means Solaris 9.
--
Eric Botcazou
l/apps/.software/linux/gcc-3.4.4-x86-sparc-build/sysroot/lib/libc.a when
> searching for -lc
What does 'sparc-sun-solaris2.9-objdump -f' return on these objects?
--
Eric Botcazou
l tests,
both on RHEL 3 which uses MD_FALLBACK_FRAME_STACK_FOR and on SLES 9 which
uses MD_HANDLE_UNWABI. I'll submit it shortly.
--
Eric Botcazou
> Anyways, I found a mistake in my sysroot and these messages seem to have
> vanished I had a symlink pointing to my local (linux) /lib instead of
> the sysroot's /lib (oops)
That would indeed explain the problem you were having.
--
Eric Botcazou
27;:
> ../../gcc/libgcc2.c:511: error: total size of local objects too large
>
> which does not make any sense. The above is for a x86_64 host, but I
> see this errors everywhere.
I guess the sanity check I've added doesn't apply to micro-cont
short.
>
> call to g : g (a, 3);
> definition of g : int g (float b, short c)
>
> I am not sure which part of the compiler is responsible to have the the
> types matched, but I think they should at this point.
> I am still working on this.
Any news on this?
--
Eric Botcazou
> A patch to fix this regression was committed earlier today to GCC4.1.
Works fine on SPARC. Thanks!
--
Eric Botcazou
eeping with tradition, "6" is in honor of #UD.
So you may be seeing something mapped odd, or...
-eric
d out where and why it segfaults.
-eric
're thinking in x86 here. SPARC uses the -mtune/-mcpu idiom.
--
Eric Botcazou
rc3 as opposed to the UltraSparc3cu?
No, that's unexpected.
--
Eric Botcazou
c is fine.
For the 64-bit compiler (sparc64-sun-solaris2.9), CC="cc -xarch=v9" is fine.
--
Eric Botcazou
> Also, sparc-sun-solaris2.9 doesn't mean "32-bit compiler", it means
> "build both compilers, defaulting to 32 bits".
No, the compiler is purely 32-bit, only the libraries are of both flavors.
--
Eric Botcazou
ler" for
sparc-sun-solaris and "64-bit multilib compiler" for sparc64-sun-solaris.
--
Eric Botcazou
sparc where the sparcv9-*-solaris2* which sent me to sparc64-*-solaris2*
> on install/specific. html. Should I have been looking somewhere else?
http://gcc.gnu.org/install/specific.html#sparc-sun-solaris2
http://gcc.gnu.org/install/specific.html#sparc-sun-solaris27
--
Eric Botcazou
arget libiberty is not supposed to be built with the bootstrap compiler.
Please verify that CC is not set in your environment.
--
Eric Botcazou
shell?
- what is your version of GNU make?
--
Eric Botcazou
> Although I had #!/bin/sh at the beginning, it was taking my
> SHELL as tcsh. I have stuck in (via notes) SHELL=/bin/ksh;export SHELL
> and I am rebuilding it right now. Thanks!
Could you post the config.log file of the target libiberty?
--
Eric Botcazou
> It is 4325 lines, should I just email it to you instead
> of the whole group?
Yes, compressed.
--
Eric Botcazou
> > Tree-SSA managed to add new technology to the compiler without major
> > slowdowns.
>
> You must be looking at different timings than I do.
>
> GCC 4.1 is on average almost 40% slower than GCC 3.3.
That's not true for GCC 4.0.
--
Eric Botcazou
4.1 (something like 15%-20% wrt. GCC 3.3, iirc).
Yes, Tree-SSA per se is not responsible for the 40% slowdown you reported.
--
Eric Botcazou
> So before submitting a bug report (if necessary), I wanted to know if
> someone knows something about it.
PR ada/22533.
--
Eric Botcazou
> There is an upsteam for beohm_gc (Boehm himself).
Yes, but you usually can modify the local copy and simply CC Hans.
--
Eric Botcazou
s (because of the confirmation
process). Is there someone who could help me with this offline?
Thanks for your time.
Eric Weddington
ubdi3.
Thanks for your reply.
Eric.
be in the next release.
-eric
Hello,
For such a program,
int a=0;
int main(void)
{
...
}
We will see the compiler put the variable 'a' into the bss section.
That means that 'a' is a non-initialized variable. I don't know if this
is the gcc's strategy.
Happy Christmas.
Eric.
>Yes for zero'd initialized variables, GCC puts them into BSS to say
>space in the executable.
Thanks. But, you say 'to say space in the executable'. I'm not clear
what does it mean.
Eric.
Hi,
I guess it's about the gcc version. Gcc 3.4.4 does put the zero'd
variables into bss section. But I'd like to know if the older one does
it too. Say 2.95.2 19991024 (release)?
Thanks again.
Eric.
ummit proceedings.
Thanks.
Eric.
Gnu and Tcl.
Thanks.
Eric.
Hello,
I'd like to know since gcc implicitly call memset function to perform
optimization and my c libraries are unusable for now. Can I take
another way? Say don't call memset. How to do that?
Yours,
Eric.
The
> 64-bit version is installed in prefix/lib, while 32-bit version is
> installed in prefix/lib/sparcv7!?
How many libraries do you have in prefix/lib/sparcv7? Which one(s)?
--
Eric Botcazou
o. :-) http://gcc.gnu.org/PR16513
--
Eric Botcazou
ort LD_LIBRARY_PATH=/usr/local/lib/sparcv9" or equivalent magic.
--
Eric Botcazou
ment that one passes
> CC="cc -xildoff -xarch=v9" is still in effect with studio10/solaris11
Actually -xildoff is unnecessary.
--
Eric Botcazou
itional or Wconversion.
As far as I can tell there's no required diagnostic for this in C++,
though I could have missed it.
So, either a) did I miss something? or b) any objections to
conditionalizing the warnings on Wconversion (or some method of
turning them off)?
-eric
g ul;
f = 1.5f;
l = f;
ul = -1;
func1(f);
return 0;
}
OK? Did you want me to add this as a testcase? If so, would you like
me to check that it compiles silently by default or that -Wconversion
turns the warnings on? :)
-eric
2006-01-12 Eric Christopher <[EMAIL PROTECTED]>
se of the regsets doesn't match after reload. But
can you give me any clues? I think it's hard to check the bugs.
Thanks a lot.
Eric.
them:
sparc-sun-solaris2.* compiler -> 32-bit GMP
sparc64-sun-solaris2.* compiler -> 64-bit GMP.
--
Eric Botcazou
velopers are probably the best persons to ask about that.
--
Eric Botcazou
> GMP is used by the compiler, not by the application, so you only need
> the version that the compiler will use.
Right, that's what I previously said. :-) But Aleksandar apparently insists
on having both versions installed.
--
Eric Botcazou
kes several hours.
Glad to see that a GWP maintainer eventually speaks up. :-)
> This is a serious regression for me.
FWIW I personally think this toplevel bootstrap thing is a step backward, now
typing "make" triggers such a complex machinery that nobody seems to able to
unde
that they aren't necessary and can be
conditionalized, but I wanted to double check.
-eric
2006-01-13 Eric Christopher <[EMAIL PROTECTED]>
* call.c (convert_like_real): When issuing conversion
warnings, depend on OPT_Wconversion.
* cvt.c (build_expr_t
On Jan 13, 2006, at 8:13 AM, Dan Kegel wrote:
Hi Eric!
I agree, moving warnings on benign conversions to -Wconversion
would help groups porting large codebases from earlier versions of
gcc.
As long as you're in that area, got any opinion on
http://gcc.gnu.org/PR9072
FWIW I agree
oid *directive)
{
fprintf (asm_out_file, "\t.csect %s[RW],3\n",
*(const char *const *) directive);
}
As a result, the Ada compiler cannot pass the ACATS testsuite on AIX 32-bit.
We therefore are proposing to revert to the pre-Altivec setting.
--
Eric Botcazou
--disable-bootstrap && make bootstrap", which currently triggers the
> old-style GCC-only bootstrap, will disappear.
That's good news and actually sufficient to allay most of my concerns. And
you can count on me to yell if --disable-bootstrap breaks. :-)
--
Eric Botcazou
T setting until Altivec is
supported? That would be more in keeping with all the other settings on AIX.
--
Eric Botcazou
message on Darwin because
TARGET_ALTIVEC_ABI is set to 1 there, so STACK_BOUNDARY == BIGGEST_ALIGNMENT.
--
Eric Botcazou
ffsets are not sufficiently
rounded, even if the stack register is aligned on BIGGEST_ALIGNMENT on
function entry.
--
Eric Botcazou
> The conflict is actually 32bit, AIX, Altivec, and Ada (together).
Not quite.
> My point is that I'd like to keep Altivec support on 32bit AIX for
> other languages.
Well, GCC has *no* Altivec support on AIX.
--
Eric Botcazou
ALIGNMENT
Biggest alignment that any data type can require on this machine,
in bits.
My reading is that a local variable is entitled to require BIGGEST_ALIGNMENT.
--
Eric Botcazou
> Couldn't (and shouldn't) the start sequence in crt0 align the stack?
> It seems someone somewhere has to do that eventually anyway. I would
> not assume the OS is going to cooperate.
Yes, but that's not sufficient. The compiler must align local objects too.
--
Eric Botcazou
and "make
bootstrap" respectively, that's all (and sufficient as far as I'm concerned).
--
Eric Botcazou
I wanted my blurb to convey. :-)
--
Eric Botcazou
nd ia64 so you don't see the failure there.
--
Eric Botcazou
ing, there is a gcc_assert in the never-taken path. I presume it's
with --enable-bootstrap? Which stage?
--
Eric Botcazou
> 2006-01-16 H.J. Lu <[EMAIL PROTECTED]>
>
> * fold-const.c (fold_minmax): Always initialize compl_code.
That's not very elegant. Let's use gcc_unreachable () instead.
--
Eric Botcazou
> - powerpc-darwin doesn't bootstrap => PR 22533, regression from 4.0),
> Richard, Eric, Andrew, do you have a status for powerpc-darwin on 4.1?
PR 22533 is presumably fixed now. powerpc-darwin may or may not bootstrap
Ada, but it looks like a target problem if it doesn'
> They now need to be compiled with -fstack-check to pass on 64-bit platforms;
In fact they need to be compiled with -fstack-check everywhere. They pass on
32-bit platforms with some OSes and don't with others.
--
Eric Botcazou
working on mips?
I've never tried, but I think that mudflap isn't guaranteed to work
for cross compilers. Frank?
If not would it be a good idea to disable mudflap by default on mips?
Tried native? If that also doesn't work I'd be up for disabling.
-eric
The overall patch is OK. Please could add testcases that test
-Wno-conversion? Thanks for doing this.
Thanks. I've committed the patch and a testcase that makes sure we
don't emit a warning if Wconversion is turned off.
-eric
arget-libada] Error 2
> make[1]: *** [all] Error 2
> make: *** [bootstrap] Error 2
OK, I can reproduce the failure.
Darwin specialists, what are we missing here?
--
Eric Botcazou
3]: *** [../../gnatmake] Error 1
make[2]: *** [gnattools-native] Error 2
make[1]: *** [all-gnattools] Error 2
make: *** [all] Error 2
I presume we need to pass -fexceptions here. More generally, do we need to
pass -fexceptions in any link against the static Ada runtime? How does that
work for C++ for example?
--
Eric Botcazou
> -Original Message-
> From: Daniel Jacobowitz [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, January 18, 2006 1:17 PM
> To: Eric Lemings
> Cc: '[EMAIL PROTECTED]'
> Subject: Re: Excluding C++ Library Code
>
>
> On Wed, Jan 18, 2006 at 01:08:55PM -07
301 - 400 of 1857 matches
Mail list logo
