public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: middle-end/1557: Regrename macro not documented
@ 2002-02-23 16:04 rodrigc
  0 siblings, 0 replies; 2+ messages in thread
From: rodrigc @ 2002-02-23 16:04 UTC (permalink / raw)
  To: gcc-bugs, gcc-prs, nobody, rearnsha

Synopsis: Regrename macro not documented

State-Changed-From-To: open->closed
State-Changed-By: rodrigc
State-Changed-When: Sat Feb 23 15:57:59 2002
State-Changed-Why:
    RENAME_EXTENDED_BLOCKS macro removed:
    2002-01-05  Craig Rodrigues  <crodrigu@bbn.com>
     
            PR middle-end/1557
            * config/ia64/ia64.h (RENAME_EXTENDED_BLOCKS): Remove.
    
    
    More documentation for HARD_REGNO_RENAME_OK added, for
    example in arm.h:
    /* Interrupt functions can only use registers that have already been
       saved by the prologue, even if they would normally be
       call-clobbered.  */
    #define HARD_REGNO_RENAME_OK(SRC, DST)

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=1557


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: middle-end/1557: Regrename macro not documented
@ 2001-04-01  0:00 Richard Henderson
  0 siblings, 0 replies; 2+ messages in thread
From: Richard Henderson @ 2001-04-01  0:00 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 14647 bytes --]

The following reply was made to PR middle-end/1557; it has been noted by GNATS.

From: Richard Henderson <rth@redhat.com>
To: Richard Earnshaw <rearnsha@arm.com>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: middle-end/1557: Regrename macro not documented
Date: Sat, 6 Jan 2001 02:12:30 -0800

 On Fri, Jan 05, 2001 at 11:24:07AM +0000, Richard Earnshaw wrote:
 > 	/* Define this macro if the compiler should use extended basic blocks
 > 	   when renaming registers.  Define this macro if the target has 
 > 	   predicate registers.  */
 > 
 > 	#define RENAME_EXTENDED_BLOCKS
 > 
 > 	However, the latter seems to be unused.
 
 It was used before Bernd and I rewrote the pass the last time.
 This macro should go away now...
 
 
 
 r~
>From hyrosen@mail.com Sun Apr 01 00:00:00 2001
From: hyrosen@mail.com
To: gcc-gnats@gcc.gnu.org
Subject: c++/1784: Internal error: Segmentation Fault when optimizing
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010126180650.3338.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg00739.html
Content-length: 1325

>Number:         1784
>Category:       c++
>Synopsis:       Internal error: Segmentation Fault when optimizing
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    unassigned
>State:          open
>Class:          ice-on-legal-code
>Submitter-Id:   net
>Arrival-Date:   Fri Jan 26 10:16:01 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     Hyman Rosen
>Release:        gcc version 2.97 20010124 (experimental)
>Organization:
>Environment:
Compile with 'g++ -O3'.
>Description:
The following code makes the compiler segfault when compiled with -O3.

template <class T> class Q;
template <class T> struct N { };
template <class T> struct QI { QI (Q<T> &, int = 0); N<T> *c; Q<T> &q; };
template <class T> struct Q { QI<T> e (); };
template <class T> QI<T> Q<T>::e () { return QI<T> (*this, 1); }
template <class T> QI<T>::QI (Q<T> &q, int) : q(q) { }
struct V { int c (void); unsigned a; char *b; unsigned l; Q<char *> q; };
int
V::c (void)
{
                                               ;
  if (a <= 0) return -1;
  delete [] b;
  try { b = new char[l + a]; }
  catch (...) { }
  QI<char *> iter (q);
  char **arg;
  char *ptr = b;
  unsigned len;
  int more = 0;
  *ptr = '\0';
  return 0;
}
template class Q<char *>;
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
>From bkoz@gc Sun Apr 01 00:00:00 2001
From: bkoz@gc
To: egcs@cygnus.com
Cc: gcc-prs@gcc.gnu.org
Subject: Re: libstdc++/1884
Date: Sun, 01 Apr 2001 00:00:00 -0000
X-SW-Source: 2001-q1/msg02344.html
Content-length: 74

The following reply was made to PR libstdc++/1884; it has been noted by G
>From mattias@virtutech.se Sun Apr 01 00:00:00 2001
From: mattias@virtutech.se
To: gcc-gnats@gcc.gnu.org
Cc: gustav@virtutech.se
Subject: c++/1760: inline asm: "=m" output doesn't force operand in memory
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010124171217.31490.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg00671.html
Content-length: 1253

>Number:         1760
>Category:       c++
>Synopsis:       inline asm: "=m" output doesn't force operand in memory
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          rejects-legal
>Submitter-Id:   net
>Arrival-Date:   Wed Jan 24 09:16:01 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     Mattias Engdegård
>Release:        g++ version 2.97 20010120 (experimental), generating code for x86 on x86
>Organization:
>Environment:
linux 2.2, glibc 2.1.3
>Description:
Specifying an output operand as "=m" does not seem to force
the operand to be in memory. The code below results in the
errors

urk.c:6: output number 0 not directly addressable
urk.c:6: inconsistent operand constraints in an `asm'

when compiled with g++ -O2 :

typedef unsigned long long uint64;
uint64 fstps(void)
{
	uint64 ret;
	asm volatile("fstps %0" : "=m" (ret));
	return ret;
}

Compiling with gcc instead of g++, removing -O2, or declaring
'ret' as volatile are workarounds.
>How-To-Repeat:
Compile with g++ -O2 :

typedef unsigned long long uint64;
uint64 fstps(void)
{
	uint64 ret;
	asm volatile("fstps %0" : "=m" (ret));
	return ret;
}
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
>From dlr@cs.cmu.edu Sun Apr 01 00:00:00 2001
From: dlr@cs.cmu.edu
To: gcc-gnats@gcc.gnu.org
Subject: c++/1899: Omitting template arg gives "Internal compiler error"
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010207060814.6125.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg01015.html
Content-length: 9065

>Number:         1899
>Category:       c++
>Synopsis:       Omitting template arg gives "Internal compiler error"
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Feb 06 22:16:00 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     dlr@cs.cmu.edu
>Release:        g++ 2.95.3
>Organization:
>Environment:
Debian GNU/Linux Woody, kernel 2.4.0, libstdc++ 2.10 (taken from the CVS gcc-2_95-branch, dated 20010101).
>Description:
I expected the attached .ii file to generate this error:

> use of class template `template <class _Tp> multiplies<_Tp>' as expression

But instead I get an internal compiler error:

> g++ -v -save-temps broken.C
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.3/specs
gcc version 2.95.3 20010125 (prerelease)
 /usr/lib/gcc-lib/i386-linux/2.95.3/cpp0 -lang-c++ -v -D__GNUC__=2 -D__GNUG__=2 
-D__GNUC_MINOR__=95 -D__cplusplus -D__ELF__ -Dunix -D__i386__ -Dlinux -D__ELF__ 
-D__unix__ -D__i386__ -D__linux__ -D__unix -D__linux -Asystem(posix) -D__EXCEPTI
ONS -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ broken.C broken.ii
GNU CPP version 2.95.3 20010125 (prerelease) (i386 Linux/ELF)
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc-lib/i386-linux/2.95.3/../../../../include/g++-3
 /usr/local/include
 /usr/lib/gcc-lib/i386-linux/2.95.3/include
 /usr/include
End of search list.
The following default directories have been omitted from the search path:
 /usr/lib/gcc-lib/i386-linux/2.95.3/../../../../i386-linux/include
End of omitted list.
 /usr/lib/gcc-lib/i386-linux/2.95.3/cc1plus broken.ii -quiet -dumpbase broken.cc
 -version -o broken.s
GNU C++ version 2.95.3 20010125 (prerelease) (i386-linux) compiled by GNU C vers
ion 2.95.3 20010125 (prerelease).
broken.C: In function `int main()':
broken.C:5: Internal compiler error.
broken.C:5: Please submit a full bug report.
broken.C:5: See <URL: http://www.gnu.org/software/gcc/bugs.html > for instructions
.
Exit 1


I understand that fixing bugs on broken code is a low priority.  I didn't see this in the frequently reported bugs list, though, so I thought I should submit it. :)
Thanks,
David
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: unknown; name="broken.ii.bz2"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="broken.ii.bz2"

QlpoOTFBWSZTWaZxOrsADAV/gH//+fH7f///P+/fKr////5gG396gA6aDp9L3dt72bp723ryrovI
963rre93c9d7b2cdzF3e669nekqpNF5u40bNNvdkUQOvRnJNVRSPTdKDKaNRhJCEyINRpphDVPU9
T1GmEeUNNAaAZADQ0ANAANBKaaQgk00oeKNABoGgBtTI2o9NQAAAAGhkAONDQ0NANAYgaAyAADTQ
ANAMgAAAYSaSSAgp6R6k9qTzUTTRoyPSDJkDQaAANBoBoGgARJIIxU/RMQU9TanpR6CekNGmjT1D
RkN6QjRiGjQADaJkCokhCGgRKeyp+SnjRT1GnqeoZNNoIDTQAAAAD1DRo9najtpYsmQLLCkmKuMJ
LFIpEjILAZZCevgCCWgKrlKNkNCSfMihJPob1LvWSX6WsmlZkLCoNLaUYhB4NVgwDGKFYIxYRSFQ
K7FOOGQIOSJK0g6iqVDGFbhbmJMWgNqWkyeTMV1qBD/xqgCiatjArYS45gNywpUKizEtayIqxXiU
Mmq6MGAwSCMQRIyIzBtxtsi1owcEsEBKWZkjZSCzflDW7K3oyYyQmMqtCsqRKILIjICpBQgiRYpB
ZUAKgsjIpAP+s54Zw3h7NquGMxIqnwWXY9W5EzOgok4FPePe4XecQ4xlOVAQKTnyFlY7TGcbZhni
3zIG83bpGkTFQA06RezOhw2opSjhV3qGTqoSgQyMVUSt8fLhhpRMKjuc7cIbaHYDq99PB/O0hzd5
RBZvYw9Vhw1QFCCJKu1kWrj02VC1YsiarGw7qKF2hQBDUHDarTIAphKyCmMCskiyTZK5SFpYFtlS
djguI22xQWxYqqs96nQczhigyw9/oA/o9X9drvOLyJBe9rOr3b3vXq7WVCMIyRyYgsEYCkiRkYSS
9/raOHp/D28Wrs30fGfJ1twfRQVRNyX9Y6seRyZbZbZGeMxOVmsxKCCGdnDB6ihYuQQ3NZ5Ou5zJ
Z4PT9TJ1Q3cybtdGtYVsE3ZT1BDi747mTYEiPBF4qwhsw3IAHkw9W4ueeB2h4nw+LIPrS/nceEDF
JGEYb5UTcREUYCIL1KwOl1JwHbioEDiM2axQIFkZC2QzhQhWTOloIwUGEIPsRRdplKERkEkVKgD4
YoHhj+1HLz5RPm83XfjJ9fHPRhTeedyXQslJeEVlnlnYsTnAFiaLCopEMkVGDhD7sp94YnaZMyXd
7jFMEYiiJIiIiImg3/y9z4DtPoiIhCETaI3tm7k2F9jmCUKZORDqmUqF000WJNOJR+ttjvfhoL4z
cz6CGR5KSPUQjup0kR7skJoK62SqqiqXuS5LZFWSpZJJStsIhhFPePIyUDt1FP/c26SS6vThvPKk
/54fYlDxShUe5qsdN7wM1Efvq27C42KyQIjh1fW8F3g8HcuMDGuMTbIG7V2gOfYDcFlCXJM0Q86U
UC2kpvWBV18csfV9IY/JeXs28+nor62zuVw6Ok7miiijcSG+SSEhgGMM6KBFUSVskxphhs0aTRnf
bseM1Jt0tqOUbhhG3FvJsmiRzUcHCEpZsTUnb3+eYeXv3RVydohU1vp3rmjIskUET0vWChvjlE3c
KPP4VjJDPGnIM6GpJv4/AdPNUk9/Mr6w5THWZgvlX7tedWyHfxGU3sYmO6c2fC6ddbuyE2DgyILF
fkdNnWhDY0yhnYQTlleOxTGdOo54btevXOXCbwY8UcGafGIU3lKJ5mZmNkGdnfuEBTw7ZhWaCSeg
MmDICSiYgAysYMhjGMYxtjG3wFXtZttttjiA4pjolzTUBRvROBIlF6bpVTTArGmRxMJcurWZW9Am
oOR1XazHClSrxGsmpqMYxjqFRVMY23B0Bh5G6jJJVeru0GtLt16tUEmtD1BhjHk8+Wba1qnslqut
6jiyIuRZ7kWqoW0qWJEL0pzDrDXYw1510pBmn5bMTlOqgaERN5taJWzcrNs6urXbCG11rbfv2WGK
ZBQUxgM2KYBjCdqbLIg05EGTewTQ0pJsTIk1Hy/HspPGpGJbKrEO2Px/KiSAIUqp6/jndD2fbKnu
V3TCT2qR/XMPbpT4Z6WNfliVnRsJ8UA7p8JLj36xg/DVG/TzTXzvmfT8L3PnHxssxke1WTZnKagz
lWRMpfzee3NW/ZxteTRz90j6MdoTSfNSbpOn/N7dNgV05n5VWZmLncNxvBPmJR3wfgo5ICoA44Fu
hQu+ZzyzRouL3bEnUzAZDrPGQs8Bv4S0tcsS2bhv27BB6Eb0hdEb+gwPbTmmBNez5+aQqozxvqMY
0+G02boNC0YAfBMHKU3Z+KXOVe2xnkx6lmLim3dvEzWegaiqrFVOPgNTzR5beV5XHHuATqmb5oCo
ktDal64a01g0LEO4t88ZbbUcr6YbMhQgzUTybkFZ0Wxm4uXnivxrG6ysXtx+/2O1VbevjxJ03Nyl
PxX8f1ik8bFWWgioUD2gPD+wVWgWqq8DaaCNipAoAi0EXre7GblbK7RP9eTQ5hrjD5OXl/DZqtnW
4ZiTReKGIkG1RLFuNzYBvKlCmN41SUnQMw3nS23QfIp7nPhXcsHbvZpV5ms5Kqu6UAZy3RVHka2p
boAskQiQIhYlqKroTnVsBXsqj8So6AdwK9gK+iqOio8xu8A6/X9HI6LGMtfazJLUWZsyaHReItNh
kK0xdRawpISiLFnVE42niK6IpZUelAvIlyxX51RgRUchjiSU2EWQN03EaHy41H8cSRh2Al3jW/Pk
yHKHF3tM0dHS4E2RMaza2A+Y4hSRRY256WRKOnqIwkIdlEeHMYOPNiBjiUtGMmTy7uTxqM550Ntk
79kciuju37GTdAp5vEPOtR4dPL3ejlsEE48hjFToDr5FyIl0qimR7FRx3Q0iN4YG2jFkCVv3hcbs
w31UJtRU5uXHgUaPeDrV95YAkA2PJIheG8+EnOskhY2vClGyTIuSaT6mbf1AriNiSFdSjIaSK1ae
KSFQTtu+Lj+TfUmKUVnRlYThEb8YQYLbdiUVEkKFYxvnaaLmNKSFXXzMlyAySLaOkH6Vffsy4shP
zyR6yRv1L3RR8Zy6TQooaXRvgB2STPyP4j1NG5mIzbWQwfypVH6DYIaBk3eK+LiafY16W/hIQxcu
7F/f8bPoGLUxGODNvZA0uRiuY0NGRjBjJg+iduDpmshlVWvGq+WuBainx3lSM5XC7SymyTDIzM4l
1GXC23AwbK9y3mlQcYGGGdurCnhpLvHiMu2lmym3mrzJJ5vXeyqsg52Ac/GTlzoeALi4NwMGgGAu
zmMVBLKXAUifg/D4/gtVrXHfw83kSnrKU09nfvdk3K3mGMb7bNtPFu1JHPAF77SUWyvQngxBWGGl
yQcCFM5mmVFQ30ZwKdiqqqq7b91vCTFmczgb4btj1QNX2OyuzyxAQHY6RbtXCPqm+DmnmRnXNVfu
II7SFLpt+WSjKbDy4nzeVuyxJiiDljTrQXo7i6fwIi+1zQEBuwqLKiIDEYzyEOiIgBuTXNwz5QtT
NDTEJJf24X0QsmvTz7vakI5ey3XZzr18XsXSrt6BeB7Eij6TT/MCWiRslLGAlmKMIQWFdnvTprEH
8yYLRYLvnwsXnXAD3QA5+2Z7kzDMSYyesJNh2Yp+P89k4hypJ4UssTxqVZbBiqqqKoUsN/ILKwmG
lbIUrYqVsDQQQkwCYB1mQmlVWQgqiOlVUIIaChYqitEjSDSpS2NUr3x+dHuNycFh1qZXSw0qfdMJ
sTWrQxIqgskVYKxKxGeUIjCdVE0Xa2jFloqsUYJgZGLQlAQMSuMUiqRGSSxBjCNWyJTCkxYUqkWn
j9GaolEIPj9b5qqjFROwKHtw+JgH3meyBuPJwRRDRDdH63mUz14lo1LvCzgff2XH2HpyHzgqlUlK
UpKTkcbM35ZrW2tLd9s1pO5jEvDm7TGsIYYwkwd1kDeqHiimMDMHNqGdWYapfUjUAymUOT8GtN4o
3lk6klGL47+P3l7xu8LyUvXLYtW2ltVaarlQ2WB21uUrXofjU0m06ltvjgdr8y21SqqKQhnncdjv
pTTlWUB4Iy0MG+ZeyTOiWO49MwBwhW8lNhseElkkpSUpWLaT69py4771b99bYc68WuRxyWek5Bst
ZyY2t4sPWO3Lbvcay1tbXacAKKXwUqsZi+b3pFe88HSNWL4rUtKdcIa6eWANsMYbBDuVlDtg8ck5
DJCQjYPMpRQpFzd4vSBIbzP6NmZgGfV90X6cjgAbGjjR6rcurcoG/yWAOZWgQ0PA5YB7jBhAk7Zt
UE3OICJ5jyF9psoR4pjwgxO80YMk9Dxkg1SJ8Xd0pemGZwFR4TcGCSEZJBHxEAv9YG7pPIpzoodN
31JJsV9RD6K98xzSO41AXkqMQdvmwpzICa9Co3G869+qp6lKXzaBwyBOUlEfmTgyMCJEiERjFQgq
qthbbbapSyHphObsiSPie2rqNlPVC1asjk+eWWFP7/+tSNKVSKgQMgq9tUfvSUUfNctkAdsBp5Au
+A+WinqkdanuVItWWJKMJUsPKQPOc8sJrIuWEUUYsmCsUdz3LliLDQCBsQSYYGbomCy0DBuqoXFj
arMQEuTYipzpgWIKp2gIvLdkYsA14nBUBHNni+RZGWRTAKVzGbjCxEVXwA5tWRK0tUn9CvJw2ba2
MmiKl5eqXTG065bHFcCxaxgFlqMSGCkDEPPcG0WMtVcZt1RNyZI/SZSSSSW3mPJ3xI5GVavythma
bdeptK3O8kjgjZ2JyOCSNkoiklc9Q2+4teTjvIOrlIR8LO0HhyTeOCTtj1vLYC96K2BgBRrNkEuU
V3Vu5dOyYb5JIEIVo14PwJExJQjko20kFic53Qe6uup3x5vV7yCaDvCqVKUKUUomCPS8cMUWUNEn
yRtwnl2SN57viXWG293eOWTQiSKKaLFBvHgJBSKNlYLmpEFsQEL0LhFvRDRmCKWyOy7ER0RU7LRF
MtR4qFrgygZKjGi56FUdoRFDtegEoEwmoo5W5+WNdHM9m1y6VMkUyaLjvEOPWeuCnBFSGhANgOCL
VOMAtodijrcWVIRT6sWlYQUO7awqGeAVVVL6Z5hDDq5SQl6jQRA4JOi6ngLxU6gTabFu4I7MSRiA
o4dY1ALbCFpsFSRJMWWiJC5Q+lMlallYhvg0pDNYSOsMAETkoJ5hrqp5oHTyOpUfvqj4MEUNoJrH
nOByFcVR3OI3HMwv3lGjAiJA14KgXIqbFrMtHsek37wgCVNcLDGG0gGtE7nSqoiiIiqrGMrVVVVE
VUV3uSib6bY1pNbSEckZ8Ps3nr3cvIMy3EJilTpWqoroqTFJUFkJUZAmFJDEmqAG7tdbLEVURREW
JGIiCMIwRkUVUd1hJCyB9c62abXldGhpKaI2xkSfkRIvJOtT23eRtO3ISrjsWIbWXwcugbwhkmIq
jhitoohGSF5AkDmYGEksK1NpI0Nm0jibRnbjBJqEX1+lXpwEidZmedQHZyXK8uhAvFHpE4AaCNU+
MjqhDliJyRKiB6kTJyeZd4Si+goEbtzbUEdnWmYu8NAMgxdR0PaFJTRgZhkIUZCYSNYuSJKmnq7P
pQcWSBT78kFImQ3Qen0yEfERyno9t+Ojt9PReaMkeyDdR3d7UuWJ4Aoav6KRGkGyl4TB74JLcbSN
tVCczgqnBswbyPGJI2Gxyx13znulZzb8XGuMaZpGpkoZIklz35D2HUJ6oJooHYk8AbxgR5EUk+Ci
mQWEVIQPIoIZqmgZd7fSBkZigXU20JDtOlsBxU2JtFA2ZASKIZVCckERirVs6CGW0qCtv3ONuvLq
aZCMGQ5deXZ9ZWjhHIMRwgeh0LhC4wGxhRtJYJWaNoMiBIyLn6FvjgdPpUb5fOdyNEVNLAIktn47
SyJCqk+SjDBhJWpkkvtr1Qzj2gQpJtQOM1Ia74XrSnoBaMylEVq4sZYlXjJ3EHDTwfDajs+VUpwS
cG1u8wtnqvGpKbaZw2I2WSqRNQ0AuCUpIWittILIIiLShhRkrwqa1HwblGDeWN9DI4cxtrZWHDeZ
pdSM2wibSbchpjBibijfZvOCMYmCZzscJmYlkcpJNqTVKauuOW82qOdcVs91TNYYDohquYsbDR06
cqtuxJy3jgq1bC2pajGo0FoG4WlNl4rxIglyIBQRNoGYFaqLuipmmI3RCZEimxj35DrO5exwqlKo
sJLISydZxGpzUwVvBG7EDvknFvALWDAUDaLitRNwoEsOCKcB1UD5IBUJEYR7ov0wMGCftE9cQUoh
WCr7Xh89FR9vy+iQPxC+hyRQ5cnvigdQIOHSbF8OAIHpuuhoI1eIJvDFJGSANKAQeyCztaXjBO0N
6iG4zqtr3uKKmBuDc7FRwGKPtqTA7J3Zj2Eei76Rui2k7x94co6zvKTfhrYQHtVHvmoNk84oAOJY
QO2uGkmeYqkhuxCR1bPOQ+DrJFUsSrJUsWiqWLQd9kg+q6tlUWRTX1LZJpZGsC01ZEwstsRQyIKS
Ap/8XckU4UJCmcTq7A==
>From rodrigc@gcc.gnu.org Sun Apr 01 00:00:00 2001
From: rodrigc@gcc.gnu.org
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: c++/1029
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010311181601.24154.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg02211.html
Content-length: 671

The following reply was made to PR c++/1029; it has been noted by GNATS.

From: rodrigc@gcc.gnu.org
To: Peter.Bienstman@rug.ac.be, gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org
Cc:  
Subject: Re: c++/1029
Date: 11 Mar 2001 18:10:35 -0000

 Synopsis: ICE at -O3 in overloaded operator
 
 State-Changed-From-To: open->closed
 State-Changed-By: rodrigc
 State-Changed-When: Sun Mar 11 10:10:35 2001
 State-Changed-Why:
     Your testcase does not result in an internal compiler
     error in the GCC 3.0 branch.
     You may want to test it yourself at:
     http://www.codesourcery.com/gcc-compile.shtml
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=1029&database=gcc


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2002-02-23 23:58 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-02-23 16:04 middle-end/1557: Regrename macro not documented rodrigc
  -- strict thread matches above, loose matches on Subject: below --
2001-04-01  0:00 Richard Henderson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).