t; debug format).
I propose to deprecate the *-*-solaris2.5 and *-*-solaris2.6 targets, the OS
were released more than a decade ago. The minimal supported version would
then be Solaris 7, the first version that can support DWARF-2 debug info.
--
Eric Botcazou
I guess that the argument of the user defined command in gdbinit.in
should be $arg0. Also, due to the changes of the structure tree node,
ptc should be,
define ptc
-output (enum tree_code) $.common.code
+output (enum tree_code) $arg0.base.code
echo \n
end
Here's the patch,
--- gcc/gdbinit.in
oesn't exist somewhere already, can the criteria that Joseph used be set
as a recurring policy and documented somewhere? Can we have an FAQ set up
somewhere for the inevitable questions/concerns that follow the release of a
proposed target deprecation list?
Eric Weddington
> -Original Message-
> From: Manuel López-Ibáñez [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, January 23, 2008 9:35 AM
> To: Weddington, Eric
> Cc: Andrew Haley; NightStrike; gcc@gcc.gnu.org
> Subject: Re: GCC 4.3 target deprecation proposals
>
> On 23/0
> It has callers and callees which should not be inlined in order to
> reproduce the bug.
__attribute__((noinline))?
--
Eric Botcazou
> I'm not sure what to do about bit-aligned TImode fields
> for example, or other things that appearantly can be done with Ada
> (which allows bit-packing).
I think that we can live without TImode bitfields, up to DImode would be fine.
--
Eric Botcazou
> with Ada, right?).
Actually no, it's not possible. Once something is BLKmode, it's at least
aligned on a byte boundary. It's only possible for integral modes.
--
Eric Botcazou
compiler expects DImode to be aligned according to its
size, like other integral modes. I'd suggest to distill a reduced testcase
and debug side-by-side in decl.o (the error message is issued there) against
the pristine compiler, maybe it's only an oversight.
--
Eric Botcazou
int in decl.c where
the error message is issued and try to find out why it is issued with the
modified compiler and why it is not with the pristine compiler.
--
Eric Botcazou
> I opened
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35186
Thanks!
--
Eric Botcazou
of WinAVR.
The build failure does not *seem* to be on anything target specific; it
fails on makeinfo and can't seem to find libiberty/at-file.texi. See the
bug for details.
Any help in getting this resolved would be appreciated.
Thanks,
Eric Weddington
Atmel
> -Original Message-
> From: Richard Guenther [mailto:[EMAIL PROTECTED]
> Sent: Saturday, February 16, 2008 12:34 PM
> To: Weddington, Eric
> Cc: GCC; Denis Chertykov; Anatoly Sokolov; Joerg Wunsch; Lamo, Jo Inge
> Subject: Re: AVR port broken on 4.3 20080215 snaps
> -Original Message-
> From: FX Coudert [mailto:[EMAIL PROTECTED]
> Sent: Sunday, February 17, 2008 11:00 AM
> To: Ralf Wildenhues
> Cc: Richard Guenther; Joerg Wunsch; GCC Development;
> Weddington, Eric; Denis Chertykov; Anatoly Sokolov; Lamo, Jo Inge
> Subject:
> -Original Message-
> From: Ralf Wildenhues [mailto:[EMAIL PROTECTED]
> Sent: Sunday, February 17, 2008 11:05 AM
> To: FX Coudert
> Cc: Richard Guenther; Joerg Wunsch; GCC Development;
> Weddington, Eric; Denis Chertykov; Anatoly Sokolov; Lamo, Jo Inge
> Subject:
> -Original Message-
> From: FX Coudert [mailto:[EMAIL PROTECTED]
> Sent: Sunday, February 17, 2008 11:06 AM
> To: Ralf Wildenhues
> Cc: Gerald Pfeifer; Richard Guenther; Joerg Wunsch; GCC
> Development; Weddington, Eric; Denis Chertykov; Anatoly
> Sokolov;
> -Original Message-
> From: Ralf Wildenhues [mailto:[EMAIL PROTECTED]
> Sent: Sunday, February 17, 2008 1:18 PM
> To: Weddington, Eric
> Cc: FX Coudert; Gerald Pfeifer; Richard Guenther; Joerg
> Wunsch; GCC Development; Denis Chertykov; Anatoly Sokolov;
>
> -Original Message-
> From: Ralf Wildenhues [mailto:[EMAIL PROTECTED]
> Sent: Sunday, February 17, 2008 3:05 PM
> To: Weddington, Eric; FX Coudert; Gerald Pfeifer; Richard
> Guenther; Joerg Wunsch; GCC Development; Denis Chertykov;
> Anatoly Sokolov; Lamo, Jo Inge
> -Original Message-
> From: Ralf Wildenhues [mailto:[EMAIL PROTECTED]
> Sent: Sunday, February 17, 2008 3:39 PM
> To: Weddington, Eric
> Cc: FX Coudert; Gerald Pfeifer; Richard Guenther; Joerg
> Wunsch; GCC Development; Denis Chertykov; Anatoly Sokolov;
>
ccessful releases.
Well, why not mirror the Primary and Secondary Platform lists on the
back end, and have Primary Languages and Secondary Languages on the
front end, with separate criteria for each category? For examples,
Primary Languages would be C and C++, and put Ada, Java, and Fortran in
the Secondary Languages group.
Eric Weddington
support links. The easiest
way around this is to just copy the file.
I don't know if there is a bug report around for this.
Eric Weddington
> -Original Message-
> From: Brian Dessent [mailto:[EMAIL PROTECTED]
> Sent: Friday, February 29, 2008 9:35 PM
> To: Weddington, Eric
> Cc: Ralf Wildenhues; dju; gcc@gcc.gnu.org
> Subject: Re: Successfull build of gcc 4.2.3 with MinGW 5.13
> in windows XP
>
&g
> -Original Message-
> From: Brian Dessent [mailto:[EMAIL PROTECTED]
> Sent: Friday, February 29, 2008 10:12 PM
> To: Weddington, Eric
> Cc: gcc@gcc.gnu.org; Ralf Wildenhues; dju
> Subject: Re: Successfull build of gcc 4.2.3 with MinGW 5.13
> in windows XP
>
> Well let's see .. we (AdaCore) will try to focus more attention on this
> to evaluate whether it is feasible to get this feature working well
> enough to use in GNAT.
We already did that several times: -ftrapv is too broken to be used for Ada.
--
Eric Botcazou
Of course we would be happy to lend a hand. :-)
--
Eric Botcazou
> I meant Ada can have non-integral members that are do not occupy an
> integral number of bytes.
Right, but the middle-end shouldn't need to touch them globally, the front-end
is supposed to break up the accesses.
--
Eric Botcazou
> This is:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35493
>
> Patch by H.J. Lu to fix the issue was approved but not commited yet:
>
> http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00466.html
It has been committed now.
--
Eric Botcazou
> I think something has broken for GNU/Linux x86 in
> the past week on the head. It was building fine last
> week. Does anyone else see this?
You just need to browse Bugzilla, it's PR tree-opt/35493.
--
Eric Botcazou
> It builds now.
Thanks for the confirmation, and to H.J. for the fix.
--
Eric Botcazou
e branch and not from
> point-releases anyway.
Seconded.
--
Eric Botcazou
> fixincludes/fixincl.x changed to GPLv3 on 4.1 branch a month ago.
By accident I presume?
--
Eric Botcazou
s OK with this. This makes
things simpler for distributors. And I think that creating a special branch
would create more confusion than anything else.
So I'd simply revert the patch that (presumably) accidentally changed the
licence of this particular file and ask people to be careful about t
ed.
If maintaining it is now too much of a burden, then let's close it.
--
Eric Botcazou
hi
I'm not clear why we have 'udiv', but don't have 'umul' for Standard
Pattern Names. Does I need to define a nameless pattern for it?
Thanks in advance.
eric
Hi,
Since yesterday I'm having seemingly random bootstrap comparisons failures on
i586-suse-linux: for caller-save.o yesterday, for build/gensupport.o today at
revision 133861. But a second tree at the same revision bootstrapped fine.
Is anyone else seeing this?
--
Eric Botcazou
inter_align does not need length
attribute. Move x_regno_reg_rtx to ...
(regno_reg_rtx): ... new global array.
(reg_rtx_no, seq_stack, REGNO_POINTER_ALIGN): Update accestors.
[...]
Jan, any idea as to what could be going on here?
--
Eric Botcazou
)
> (nil))
Are you talking about flow.c:propagate_one_insn? If so, how do you map
"live in" and "live out" exactly, given that flow.c doesn't use these
but operates on a struct propagate_block_info instead?
--
Eric Botcazou
> Yes, I'm talking about propagate one insn in flow.c. How I map live in
> and live out, please see the code below.
Thanks, but AFAICS this code doesn't update insn_live_in at all.
--
Eric Botcazou
> Yes, I'm talking about propagate one insn in flow.c. How I map live in
> and live out, please see the code below.
Thanks, but AFAICS this code doesn't update insn_live_in at all.
--
Eric Botcazou
le (file, insn_live_in);
and
fprintf(file, "after propagate, insn live in:\n");
debug_bitmap_file (file, insn_live_in);
be different if you don't update insn_live_in? You need to say what you're
really dumping here.
--
Eric Botcazou
> Start from the bb's live out and calculate each insn's live in&out.
> Where the first insn's live in must be the bb's live in, but the
> assertion failed.
So you're dumping pbi->reg_live after the call to propagate_one_insn as "insn
live in", right?
--
Eric Botcazou
> Yes. Any help?
This doesn't make any sense to me. I would put a breakpoint on the few lines
that update pbi->reg_live in flow.c and see why one of them triggers.
--
Eric Botcazou
> That appears to be caused by this change:
>
> 2008-04-17 Eric Botcazou <[EMAIL PROTECTED]>
>
> * decl.c (gnat_to_gnu_entity) : Promote the alignment of
> objects by default.
> * fe.h (Debug_Flag_Dot_A): Delete.
> * debug.adb (-gnatd.a): U
> Fails here on ia64.
OK, this should be fixed everywhere now.
--
Eric Botcazou
-gnatpg -gnata"
Looks like you're building the 4.4 cross-compiler with the 4.1.2 system
compiler. Use the 4.4 native compiler instead.
--
Eric Botcazou
hi
Is there anyone working on the loongson support of gcc? I notice
that loongson has been added into the currently developing binutils.
ericfisher
ot;
+ "nmadd.s\t%0,%1,%2"
+ [(set_attr "type""fmadd")
+ (set_attr "mode""SF")])
+
+(define_insn ""
+ [(set (match_operand:DF 0 "register_operand" "=f")
+ (minus:DF (match_dup 0)
+ (mult:DF (match_operand:DF 1
> I wasn't under those recipients.
For the sake of completeness, I wasn't among them either. But I can only
offer diligent review of SPARC specific patches these days and help for
severe problem reports.
--
Eric Botcazou
> If it doesn't today, then there's no tests covering the problems.
It does if you have a 64-bit HOST_WIDE_INT on your 32-bit host and this is now
enforced for most 64-bit targets.
--
Eric Botcazou
gt; [...]
> Things go wrong in "call_insn/u 215". Target has R0 and R1 are the
> parameter registers.
There should probably be a USE for R1 on the call insn then, like for R0.
Why is it there for the latter and not for the former?
--
Eric Botcazou
ore a call_insn
then the registers containing the arguments of the call are
live_throughout in the new insn.
--
Eric Botcazou
> Any suggestions on how to fix this issue?
gen_int_mode
--
Eric Botcazou
usr/local/sparc-solaris/include is old.
Or a configuration problem, see PR target/28097.
--
Eric Botcazou
quot;incorrect"?
Quad cores are available for exactly 1 architecture (x86) at affordable
prices, GCC is supposed to support more than just x86.
--
Eric Botcazou
> Is there a way to know whether an operand is signed or unsigned from its
> rtx?
Basically no, this information is not encoded in the operand, rather in the
operator (if it matters).
--
Eric Botcazou
ng about the initial
processing (i.e. during RTL expansion), the information is encoded in the
trees fed to the expander.
--
Eric Botcazou
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jerry DeLisle on 6/29/2008 11:45 AM:
| Ian Lance Taylor wrote:
|> CC'ed to Eric. This may require some configury patches somewhere.
|>
|>>>> Adjust strsignal to POSIX 200x prototype.
|>>>> * st
if ((TREE_CODE (exp) == VAR_DECL || TREE_CODE (exp) == FUNCTION_DECL)
&& DECL_DLLIMPORT_P (exp))
return false;
return true;
}
--
Eric Botcazou
that !DECL_INITIAL => DECL_INITIAL == 0 for TREE_READONLY+TREE_STATIC
and not TREE_READONLY alone.
--
Eric Botcazou
> this patch of yours
>
> 2008-08-01 Eric Botcazou <[EMAIL PROTECTED]>
>
> * gcc-interface/utils.c (convert_vms_descriptor): Add
> gnu_expr_alt_type parameter.
> Convert the expression to it instead of changing its type in place.
> (build_
> 2008-08-01 Eric Botcazou <[EMAIL PROTECTED]>
>
> * gcc-interface/utils.c (convert_vms_descriptor): Add
> gnu_expr_alt_type parameter.
> Convert the expression to it instead of changing its type in place.
> (build_function_stub): Adjust call
stack.
Could someone please mark this test as unsupported for avr-*-*? I don't have
copyright assignment yet (but we're currently working with the FSF on it).
Thanks for your help.
Eric Weddington
Atmel
> -Original Message-
> From: Dave Korn [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 06, 2008 11:04 AM
> To: Weddington, Eric; gcc@gcc.gnu.org
> Cc: 'Andy Hutchinson'; 'Anatoly Sokolov'; 'Andreas Krebbel';
> [EMAIL PROTE
internal compiler error)
>
> These are showing up in gcc.log as below.
They all look to be the same bug. I'd track down what's trying to emit
that instruction.
-eric
On Thu, Aug 7, 2008 at 9:13 PM, Jack Howarth <[EMAIL PROTECTED]> wrote:
> Eric,
> Thanks for looking into this. FYI, the problem also occurs in...
>
> FAIL: gcc.dg/torture/fp-int-convert-double.c -Os (internal compiler error)
> FAIL: gcc.dg/torture/fp-int-convert-dou
> Please open a bug report. They also fail on Linux with SSE fpmath:
>
>
That'd be why they fail on darwin then - we default to sse2 :)
-eric
t;blocker" though.
--
Eric Botcazou
> But is "fixed" on the branch and the trunk.
Then it should probably not be "blocker" anymore.
--
Eric Botcazou
same way. gimple.c:gimple_build_asm_vec
is miscompiled at -O2 -fomit-frame-pointer by regalloc/reload because of
inconsistent elimination offsets at a block boundary. It's the IRA merge.
I'd suggest opening a PR, I'll attach a reduced testcase and the analysis.
--
Eric Botcazou
compiler error: Bus Error
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <http://gcc.gnu.org/bugs.html> for instructions.
Confirmed (on Solaris 9). Would you mind opening a PR? There is already one
for Linux (37344) but the failure is a little different. Thanks in advance.
--
Eric Botcazou
...
if n > 0 || ReadyTry[0]
...
here should be
if n > 0 && ReadyTry[0]
since 'the algorithm guarantees that the instruction with the highest
priority will be issued on the current cycle).'
Of course, implemented code in gcc is right :-)
Eric Fisher
2008-9-9
faults to --with-cpu=v9. On Linux things are
probaby more complicated to set up; Jakub is the resident expert for that.
--
Eric Botcazou
ved
> the issue and the compiler successfully bootstrapped:
>
> http://gcc.gnu.org/ml/gcc/2008-09/msg00139.html
Thanks for reporting this. I now can close PR 37424.
> There was one reply to this message; I don't know if the patch is being
> reworked or been formally submitted yet, but it did fix my build.
OK, I'll take a look.
--
Eric Botcazou
hasn't been recognized upon reaching these
parts of haifa-sched.c? Will it be only mis-scheduled, i.e. will this only
result in inferior, but still correct code? If so, the assertion shouldn't
be enabled in release mode but only if ENABLE_CHECKING is defined.
--
Eric Botcazou
for this bug. I'm ready to approve
Adam's patch but only if the assertion is downgraded to ENABLE_CHECKING.
--
Eric Botcazou
it was unacceptable in general (speaking for myself).
Anyhow, I hope to see all of this resolved at some point.
-eric
(symbol_ref:DI ("local") local>) ] 110))) -1 (nil)
> (expr_list:REG_EQUAL (const:DI (unspec:DI [
> (symbol_ref:DI ("local") local>) ] 110))
> (nil)))
Is (reg/f:DI 974) loop invariant or only conditionally invariant?
--
Eric Botcazou
would it be enough to weaken the condition of the removal test to
if (loop_invariant_p (loop, ...) != 1)
in order to solve your problem?
--
Eric Botcazou
t happen with unconditional loop invariants?
> Maybe it can be consider safe since loop.c is *always* able to hoist
> unconditional loop invariants?!
I guess that real loop invariants are not supposed to be modified in the loop
at all, so it's OK to move up insns consuming them to the loop pre-header.
--
Eric Botcazou
-05/msg00093.html instead.
--
Eric Botcazou
the while libcall
> sequence 63-152-61-62 is dead and can be deleted, without ever checking
> insns 63, 152 or 61 for liveness.
Because it's the semantics of libcall sequences. My take is that the lower
subreg pass breaks it in this case.
--
Eric Botcazou
insn 64 62 65 3 memcmp.c:81 (set (reg:HI 76)
(reg:HI 93)) 23 {*movhi} (nil)
(nil))
which is in my opinion not valid because the live range of (reg:HI 93) crosses
the libcall boundary. But Ian has the final say on this stuff.
--
Eric Botcazou
libiberty, since it's job is to provide
> portability
> > between systems.
>
> This is also true, so I suppose it's not entirely correct to say that
> this is not a gcc issue in the slightest. This above should indeed go
> into libiberty as the long term solution.
I would have thought that too.
For reference, there is this GCC bug report:
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30972>
Eric Weddington
On May 13, 2007, at 3:48 AM, Tom Womack wrote:
I have some code of the form
This really isn't enough, I put a bit of a testcase together, but
nothing that would give bad behavior at -O3 (there is no -O9).
Have more of a testcase? Something compilable?
-eric
)
#endif
but then, you might have to have something like:
#define CPP_SPEC \
"%{msoft-float: -D_SOFT_FLOAT} \
(picked at random from lynx.h) in the .h file for your port.
:-) But I'm sure there would be more work to do.
FWIW the backend already does this in rs6000-c.c :)
-eric
poorly) mimics the 2nd. The revision
history shows that this 4th step predates the 2nd.
--
Eric Botcazou
appears to be a general issue. Should look
to see if we can track
down which patch did it.
-eric
in the source directory which is not a well
supported way of compiling GCC.
Yeah, but I wasn't and still ran into that (or similar) problem. :)
-eric
hich includes one new failure (Process_5). Shouldn''t the changes in
revision 120684 be backported to gcc 4.2.1? Also does anyone know
if additional fixes to eliminate these remaining failures currently
reside in gcc trunk? Thanks in advance.
Sure, seems reasonable.
-eric
> I suppose that there are some bugs in the snapshot gcc-4.1-20070514.
Dozens, literally, just browse the bug database. If you want to help, pick
one of them and try to fix it.
--
Eric Botcazou
> I can not browse http://gcc.gnu.org/bugzilla/ because has not the
> 'browse' button.
Well, your favorite browser very likely hasn't got one either and yet you can
browse the Internet, so there must be a similar way with Bugzilla...
Hint: look for a button called 'Search'.
--
Eric Botcazou
if there is any failed logic or not.
loop.c is gone in the mainline sources. Patching it on the 4.1 branch is
allowed only if you have a testcase that exposes a serious bug.
--
Eric Botcazou
er can be "a perfectly normal dynamically linked program",
especially if it's the system compiler? IMHO the less dependencies the
better in this case.
--
Eric Botcazou
MPFR bug, even if it
has nothing to do with MPFR.
I think that the compiler, especially the system compiler, should not depend
on dynamic libraries that are lower than it in the system hierarchy, which
pretty much leaves only the libc.
--
Eric Botcazou
> That just means that it's an application you care about. And now an
> upgrade of MPFR which fixes bugs will require you to rebuild the
> compiler.
Exactly. By design. What goes in the system compiler should be closely
scrutinized.
--
Eric Botcazou
sh sparc stormy16 v850 vax
OK, I'll do SPARC in the near future.
--
Eric Botcazou
On May 25, 2007, at 2:10 PM, Eric Botcazou wrote:
I don't personally have time to convert all ports, and it is
better if
people who know each individual backend and have access to hardware
do the conversions, anyway. So I'd like to invite port
maintainers to
convert their por
or your machine (i386-
redhat-linux).
-eric
; make -j8 all-gcc all-target
and you'll get this:
configure: error: none of the known symbol names works
make: *** [configure-target-libmudflap] Error 1
which means that libmudflap needs to be ported to sh-elf.
-eric
builtin_extract_return_addr in except.c.
--
Eric Botcazou
f the CIE on SPARC, see extract_cie_info
in unwind-dw2.c.
--
Eric Botcazou
1301 - 1400 of 1858 matches
Mail list logo
