[Bug target/13722] [3.4/3.5 regression] [ia64] ICE in push_secondary_reload
--- Additional Comments From zack at codesourcery dot com 2004-01-22 08:22 --- Subject: Re: [3.4/3.5 regression] [ia64] ICE in push_secondary_reload "wilson at specifixinc dot com" <[EMAIL PROTECTED]> writes: > The simple fact is that you have broken the IA-64 compiler a number of > times, and you have not always been responsive to fixing the problems > you have caused. This is very annoying. There are many people using > the IA-64 port, and you inconvience them everytime you break it. > > I have important work to do also, but instead I am forced to do your > work for you, and I am not happy about this. > > If you aren't going to try to do IA-64 work properly, then you could at > least post patches for review instead of just blindly checking them in > and waiting to see what breaks. Or you could voluntarily revert patches > when it is proven that they don't work. This is much more friendly to > the rest of us, particularly those of us using the IA-64 gcc port for > real work. The fact of the matter is that I *have* always tested these changes on an ia64 machine. It runs HP/UX, which (a) is big-endian, and (b) does not (to my knowledge) have an Ada port yet. Therefore testing on ia64-linux is, unfortunately, going to show problems that my testing cannot. It is not feasible for me to change the operating system on the machine. The implication of what you are saying above is that you don't think anyone without access to an ia64-linux box should be allowed to touch the ia64 back end, which I think is bad policy. It is certainly the case that I don't know as much about coding machine descriptions as some people do, and if you would like, I will stop checking backend patches in immediately, to give others a chance to find problems - but my experience is that everyone ignores me when I ask for a second opinion on my patches, so I don't expect this to help much. I *have* managed to reproduce the original bootstrap failure with an i686-linux->ia64-hpux Ada cross compiler, for the record. > It has always worked this way. I know this is lame, but one should > never underestimate the difficulty of trying to change how reload works. > It is much easier to change all md file than to change reload. I > think there is an important reason why it works this way, but it > probably isn't possible to figure it out without spending an > unreasonable amount of time messing with the code. RTH and I talked this over on IRC and came up with a clever plan, which I intend to implement tonight and post for review, assuming it works, tomorrow morning. zw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13722 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
Don't Want To Be Busted ? ? ? . . . . . . . . scent
Title: cleanactpro Keep Your Job - Keep Your Marriage - Keep Out Of Trouble DID YOU KNOW! That anyone who uses your computer can see what websites you've visited? And that simply deleting history only removes part of the records. If someone starts typing a web site, your browser will recall old sites you've visited? Your boss or wife can start typing "www.dateline.com" and the browser will recall "www.datingclub.com" Every picture on every site you've ever visited has been copied to your hard drive? Deleting the cache does not permanently remove them! And there are many more ways you are secretly tracked... Download Our Software Today To Be Safe No More Emailz Plz parakeet , abjectly
[Bug ada/13670] [3.4/3.5 Regression] xnmake gets miscompiled during bootstrap with ada enabled
--- Additional Comments From gianni at mariani dot ws 2004-01-22 15:34 --- I'm getting this build error on a Linux build using gcc 3.3.2 on RH9 - is this the same problem ? make[1]: Entering directory `/home/gianni/downloads/gcc/gcc-3.4-20040121-build/gcc' mkdir -p ada/bldtools cp -p ../../gcc-3.4-20040121/gcc/ada/sinfo.ads ../../gcc-3.4-20040121/gcc/ada/nmake.adt ../../gcc-3.4-20040121/gcc/ada/xnmake.adb ada/bldtools (cd ada/bldtools; gnatmake -q xnmake ; ./xnmake -b ../nmake.adb ) fatal error, run-time library not installed correctly cannot locate file system.ads compilation abandoned gnatmake: "xnmake.adb" compilation error /bin/sh: line 1: ./xnmake: No such file or directory make[1]: *** [ada/nmake.adb] Error 127 make[1]: Leaving directory `/home/gianni/downloads/gcc/gcc-3.4-20040121-build/gcc' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13670 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Bug ada/13670] [3.4/3.5 Regression] xnmake gets miscompiled during bootstrap with ada enabled
--- Additional Comments From charlet at act-europe dot fr 2004-01-22 15:42 --- Subject: Re: [3.4/3.5 Regression] xnmake gets miscompiled during bootstrap with ada enabled > I'm getting this build error on a Linux build using gcc 3.3.2 on RH9 - is this > the same problem ? No, this problem is most likely a set up issue. The default/system gnatmake is apparently misconfigured/misinstalled. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13670 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Bug c++/11295] [3.4/3.5 regression] ICE in cp_expr_size, at cp/cp-lang.c:314 when using a non-trivial object in a compound statement expression
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-01-22 16:07 --- I do not see this on 3.5 on i686-pc-linux or powerpc-apple-darwin, I do not think the C++ front- end is different between 3.4 and 3.5 at all, I am wonding if this was just a fluk or you have a problem with your sources with a tag. -- What|Removed |Added GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|*-*-* |ia64-suse-linux-gnu Summary|[3.3/3.4 regression] ICE in |[3.4/3.5 regression] ICE in |cp_expr_size, at cp/cp- |cp_expr_size, at cp/cp- |lang.c:314 when using a non-|lang.c:314 when using a non- |trivial object in a compound|trivial object in a compound |statement expression|statement expression http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11295 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Bug c++/11295] [3.4/3.5 regression] ICE in cp_expr_size, at cp/cp-lang.c:314 when using a non-trivial object in a compound statement expression
--- Additional Comments From schwab at suse dot de 2004-01-22 17:41 --- It still fails in both 3.4 and 3.5 as of today. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11295 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Bug c++/11295] [3.4/3.5 regression] ICE in cp_expr_size, at cp/cp-lang.c:314 when using a non-trivial object in a compound statement expression
--- Additional Comments From schwab at suse dot de 2004-01-22 17:54 --- Subject: Re: [3.4/3.5 regression] ICE in cp_expr_size, at cp/cp-lang.c:314 when using a non-trivial object in a compound statement expression It still fails with both 3.4 and 3.5 as of today. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11295 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Bug pch/11654] incorrect stabs when using pre-compiled headers
-- What|Removed |Added Summary|gcc seg fault when using|incorrect stabs when using |pre-compiled headers and - |pre-compiled headers |gstabs | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11654 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Bug target/13722] [3.4/3.5 regression] [ia64] ICE in push_secondary_reload
--- Additional Comments From zack at gcc dot gnu dot org 2004-01-22 20:14 --- Several messages regarding this bug were sent to PR 13772 by mistake. -- What|Removed |Added Status|NEW |ASSIGNED Last reconfirmed|2004-01-21 14:13:11 |2004-01-22 20:14:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13722 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Bug target/13722] [3.4/3.5 regression] [ia64] ICE in push_secondary_reload
--- Additional Comments From zack at codesourcery dot com 2004-01-22 20:20
---
Subject: Re: PR 13722 candidate fix
[Note corrected bug number. 13722, not 13772.]
Richard Henderson <[EMAIL PROTECTED]> writes:
> On Thu, Jan 22, 2004 at 02:07:12PM +0100, Andreas Schwab wrote:
>> (mem/s:TI (post_modify:DI (reg/f:DI 36 loc4 [400])
>> (plus:DI (reg/f:DI 36 loc4 [400])
>> (const_int 8 [0x8]))) [4 opt__R47s+0 S16 A128])
>
> Yep, looking at the patch, I was about to remind Zack that
> (1) post-modify can take registers as well as constants, and
> (2) you have to check for overflowing the 9-bit post-modify
> constant.
That shouldn't be hard... I suppose the thing to do is emit adddi3
instructions to fix up, if either condition is true.
> Hum, and, actually, that post-modify seems very improbable.
> addr += addr? There's sure to be a typo somewhere.
Okay, what is the form of a post_modify expression supposed to be?
This is coming from
switch (base) {
...
case POST_MODIFY:
/* Extract and adjust the modification. */
offset = XEXP (base, 1);
base = XEXP (base, 0);
out[0] = change_address (in, DImode,
gen_rtx_POST_INC (Pmode, base));
out[1] = change_address (in, DImode,
gen_rtx_POST_MODIFY
(Pmode, base, plus_constant (offset, -8)));
break;
and it sure *looks* consistent with what it says in the manual about
the post_modify RTL, which gives
(mem:SF (post_modify:SI (reg:SI 42) (plus (reg:SI 42)
(reg:SI 48
as an exemplar.
(Still looking for a clue about the differences among change_address,
adjust_address, offset_address, etc.)
zw
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13722
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
Bug#229088: g++-3.3: nested namespaces error msg
Package: g++-3.3
Version: 1:3.3.3-0pre2
Severity: minor
In this example the error message mentions the wrong namespace:
namespace outer { namespace inner { void foo(); } }
void outer::foo()
{
// error: `void outer::foo()' should have been declared inside `outer'
}
-- System Information:
Debian Release: testing/unstable
Architecture: powerpc
Kernel: Linux bulletproof 2.6.1-ben1-jtv1 #1 Fri Jan 16 01:54:06 CET 2004 ppc
Locale: LANG=en_IN, LC_CTYPE=en_IN
Versions of packages g++-3.3 depends on:
ii gcc-3.31:3.3.3-0pre2 The GNU C compiler
ii gcc-3.3-base 1:3.3.3-0pre2 The GNU Compiler Collection (base
ii libc6 2.3.2.ds1-10 GNU C Library: Shared libraries an
ii libstdc++5-3.3-dev 1:3.3.3-0pre2 The GNU Standard C++ Library v3 (d
-- no debconf information
[Bug target/13722] [3.4/3.5 regression] [ia64] ICE in push_secondary_reload
--- Additional Comments From rth at redhat dot com 2004-01-22 22:05 --- Subject: Re: PR 13722 candidate fix On Thu, Jan 22, 2004 at 12:20:10PM -0800, Zack Weinberg wrote: > Okay, what is the form of a post_modify expression supposed to be? My eyes weren't awake, sorry. It's addr = addr + c, not +=. > (Still looking for a clue about the differences among change_address, > adjust_address, offset_address, etc.) change_address can make arbitrary changes to a memory. About all we assume is that we're pointing to the same object. But we lose track of offset within the object, and all alignment not inferrable from the mode of the memory. adjust_address modifies a memory by adding a HWI to the address. We get to keep a lot of data about alignment, offset within an object. offset_address is similar, except that it takes an rtx. adjust_automodify_address is like adjust_address in that it computes new MEM_ATTRS as if adding a HWI to a base address, except that it allows you to give a completely new rtx for the address at the same time. The assumption being that the new rtx is some automodify, but that's not actually checked. This last is the one you want. r~ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13722 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
they used to be the only ones.
The first worth substitute of all existing men`s remedies! Be aware that now the peak of your selxual activity is realy accessible! All you need is to visit http://cnmeds.com/mx/index.php?pid=genviag Thanks to the proprietary blend of unique herkbs the four wonderful efkfects are achieved: *blood stream to the penlis is restored *stored tesltosterone is unleashed *activation of the body's naltural holrmone production heightens your sensation *the peknis does enklarge, the changes are being permanent! At last you can enljoy your secxual life in full measure without any risk for your healkth! Don`t wakste your time! Get more inkfo straightforwardly at http://cnmeds.com/mx/index.php?pid=genviag
[Bug target/13722] [3.4/3.5 regression] [ia64] ICE in push_secondary_reload
--- Additional Comments From wilson at specifixinc dot com 2004-01-22 22:17 --- Subject: Re: [3.4/3.5 regression] [ia64] ICE in push_secondary_reload zack at codesourcery dot com wrote: > The implication of what you are saying above is that you don't think > anyone without access to an ia64-linux box should be allowed to touch > the ia64 back end, which I think is bad policy. This is one way to solve the problem, but not the only way. I mention it because I think it is the most expedient. Another solution would be for you to build an ia64-hpux Ada compiler. Another solution is for you to voluntarily revert patches when it is discovered that they don't work. Another solution is for you to ask for help testing patches before checking them in. > to find problems - but my experience is that everyone ignores me when > I ask for a second opinion on my patches, so I don't expect this to > help much. I don't ignore IA-64 backend patches, though I am sometimes a week or so behind on reading gcc-patches. I wouldn't mind if you cc'ed me on IA-64 backend patches so that I would see them sooner. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13722 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
