--- Additional Comments From TazForEver at dlfp dot org 2004-11-02 09:21 ---
>> Alternatively, why don't you simply use "static"?
because everybody tells me that 'static' is deprecated in favor of 'namespace{}'
>> gcc could invoke the as-if rule to give these functions internal linkage
--- Additional Comments From nathan at gcc dot gnu dot org 2004-11-02 09:48
---
2004-11-02 Nathan Sidwell <[EMAIL PROTECTED]>
PR rtl-optimization/17104
* config/rs6000/rs6000.c (rs6000_emit_move): Don't wrap small
loads in zero_extend.
--
What
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-02 09:50
---
Subject: Bug 17104
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-11-02 09:50:35
Modified files:
gcc: ChangeLog
gcc/config/rs6000:
--- Additional Comments From giovannibajo at libero dot it 2004-11-02 11:55
---
(In reply to comment #7)
> This point has been discussed in a number of PRs already. I maintain
> my position that gcc could invoke the as-if rule to give these functions
> internal linkage if they aren't
SUBROUTINE SPFFT1(IMAX)
IMPLICIT NONE
INTEGER,INTENT(IN):: IMAX
REAL:: AUX1(25000+INT(0.82*IMAX))
END SUBROUTINE
using precompiled linux gfortran snapshot of 20041102, this gives:
# gfc -v -c gaga.f
Reading specs from /usr/local/gfortran/irun/bin/../lib/gcc/i686-pc
--- Additional Comments From joel at gcc dot gnu dot org 2004-11-02 12:28 ---
I emailed Chris privately. The stack is properly aligned. But his target is
not setup at the moment and he would have to build a special toolset without his
workwound/fix in place. He won't be able to do this
If a function returns an auto_ptr, it is impossible to dereference the return
value on the fly and then use it, the temporary object seems to be destroyed
on the next line.
However, if there is a subsequent call to this function that releases another
return value, it works.
#include
#include
u
g++ fails to generate debug info for some methods. Please refer to the
following files, posted here: http://www.adam-mckee.net/files/gccbug
--
TotalCostEvaluator_bug.ii : to reproduce the bug
TotalCostEvaluator_ok.ii
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-02 13:35
---
I think it was caused by:
2004-11-01 Andrew MacLeod <[EMAIL PROTECTED]>
PR tree-optimization/16447
* tree-cfg.c (bsi_commit_one_edge_insert): Rename from
bsi_commit_edge_inserts_1,
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-02 13:37
---
Confirmed, here is the backtrace:
#0 0x000169f4 in check_inquiry (e=0x42103d20) at
/Users/pinskia/src/local/gcc/gcc/fortran/expr.c:
1334
#1 0x00017038 in check_restricted (e=0x5a7aa4) at
/Users/pinskia/s
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-11-02 13:48
---
Confirmed. Reduced testcase:
=
struct A
{
int *p;
int i;
};
void foo(struct A* a)
{
int *q, j=0;
static void *L[]={ &&L1 };
goto *q;
L0:
*q=j;
The documentation of -mhard-float on ARM claims that this is the default. This
is incorrect on practically all configurations these days (the only notable
exception is Linux)
This PR is a reminder that this needs fixing before 4.0 is shipped
--
Summary: Documentation for -mhard-float
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18274
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-02 14:01
---
Just look at the tree dump before going out of SSA.
;; Function foo (foo)
foo (aD.1115)
{
voidD.30 * gotovar.0D.1135;
voidD.30 L0L.0 = <<< error >>>;
voidD.30 L1L.5 = <<< error >>>;
static voidD.30
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-11-02 14:12
---
Even shorter testcase:
void foo()
{
void **p;
int *q, i=0;
static void *L[]={ &&L1 };
goto **p;
L0:
*q=i;
i=1;
if (q<*p) *q=0;
if (q<*p) *
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-02 14:14
---
I think this is correct and here is why:
auto_ptr > res1 = ert(); // OK <-- we call the copy construtor so we
increment the
refence
vector& res2 = *res1; // OK <-- this is reference alr
--- Additional Comments From amacleod at redhat dot com 2004-11-02 14:23 ---
Is there a rule for make_forwarder_block that says it cannot forward a block
which has *any* abnormal edges?
The code is attempting
--
What|Removed |Added
Known to work||4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18273
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-02 14:31
---
Confirmed but not reduced, it works on the mainline also.
--
What|Removed |Added
K
--- Additional Comments From philippe dot haution at mines-paris dot org
2004-11-02 14:54 ---
You wrote about reference incrementing, but as far as auto_ptrs are concerned,
there's only ownership transfer of the underlying pointer.
res1 and res2 are OK, no problem about that.
But res5
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-02 14:57
---
Because it is just a flock that is all. the memory has been released but you can still
access it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18272
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-02 14:59
---
Is there any news on this patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7257
[Bug does not appear in 2.96/3.x and forward]
'gcc -v'
Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/specs
gcc version 2.95.3 20010315 (release)
To duplicate bug, build the following (gcc -o test main.c)
The program attempts to take t, print it bit-by-bit, byte swap it, print that
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-02 15:23
---
What can I say other than if it is fixed in 3.0 and above just use 3.0 or above. There
is not going to be
another release of 2.95.x, 3.0.x, 3.1.x, or 3.2.x at all.
--
What|Removed
Hi!
The following program compiled with gcc 3.3.3
#include
using namespace std;
int main() {
double x = 0.55;
int v1 = (int) (x * UINT_MAX);
int v2 = (int) (0.55 * UINT_MAX);
cout << dec << v1 << "\t" << hex << v1 << endl;
cout << dec << v2 << "\t" << hex << v2 << endl;
}
produc
--- Additional Comments From dsracic at gmail dot com 2004-11-02 15:28 ---
Subject: Re: Copying float that is nan to another variable twiddles bit
It'd be nice if we could upgrade compilers on production systems to a
new major revision, but alas, that's not an option; this platform has
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-02 15:48
---
Jan can you look into this testcase, this is one where we don't inline as much as 3.4
did.
(for ppc-darwin, it is much worse as templates have to go through a stub now so it is
much worse
there). Maybe t
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-02 15:52
---
: Search converges between 2001-11-11-trunk (#45) and 2001-11-18-trunk (#46).
--
What|Removed |Added
--- Additional Comments From philippe dot haution at mines-paris dot org
2004-11-02 15:58 ---
Well OK, I'll check with purify that res3 and res4 memory area is released
whether or not res5 has been intialized.
I will from now on use
vector& res5 = *(ert().release());
as the correct way
--- Additional Comments From bangerth at dealii dot org 2004-11-02 16:10 ---
I don't want to have these symbols not mangled (they need indeed be
mangled and randomized), the problem is that the randomness is sometimes
not enough. See PR 9393 for a case that would have been solved with
--- Additional Comments From mckinlay at redhat dot com 2004-11-02 16:11 ---
Would it make more sense for GCJ to accept ':' instead of/as well as ';' on
mingw? Perhaps with some logic to distinguish a drive-letter ':'? The Makefiles
are sure ugly now with all this CLASSPATH_SEPARATOR stuf
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-02 16:30
---
Subject: Bug 18228
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-11-02 16:30:49
Modified files:
gcc/ada: ChangeLog Makefile.in
Log message:
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-02 16:30
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-02 16:38
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-02 16:38
---
Subject: Bug 16808
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-11-02 16:38:18
Modified files:
gcc: ChangeLog tree-ssa.c
gcc/tes
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-02 16:52
---
Subject: Bug 17265
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-11-02 16:52:55
Modified files:
gcc/java : ChangeLog class.c
Log message:
I am not positive about this bug report, but I cannot see what G++
wants from me, and in addition all the other compilers I have access
to accept the following code (including 3.4).
template < template class Traits_ >
struct Factory
{
};
template < templ
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-02 17:10
---
Confirmed, the error is wrong.
here is the reduced testcase:
template < template class >
struct Factory { };
template < template class >
struct Product
{
template < template class >
friend class Factor
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-02 17:11
---
: Search converges between 2004-08-25-trunk (#524) and 2004-08-26-trunk (#525).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18276
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-11-02 17:48
---
Even simpler testcase:
template class> struct A;
template struct B
{
template class> friend class A;
};
B<0> b;
==
Next gcc bootstrap problem at FreeBSD:
---8X---
/usr/home/wanderer/pkg/build/gcc/obj/gcc/xgcc -shared-libgcc -
B/usr/home/wanderer/pkg/build/gcc/obj/gcc/ -nostdinc++ -
L/usr/home/wanderer/pkg/build/gcc/obj/i386-unknown-freebsd5.3/libstdc++-
v3/src -L/usr/home/wander
--- Additional Comments From wanderer at rsu dot ru 2004-11-02 17:57 ---
Created an attachment (id=7457)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7457&action=view)
.ii file (original commandline + -save-temps)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18277
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-02 17:58
---
__gthread_recursive_mutex_t static_mutex::mutex
#ifdef __GTHREAD_RECURSIVE_MUTEX_INIT
= __GTHREAD_RECURSIVE_MUTEX_INIT
#endif
;
Is __GTHREAD_RECURSIVE_MUTEX_INIT defined wrong for freebsd?
--
--- Additional Comments From wanderer at rsu dot ru 2004-11-02 18:14 ---
I think problem related to commit:
2004-10-29 Eric Botcazou <[EMAIL PROTECTED]>
* gthr-posix.h (__gthread_recursive_mutex_init_function): Guard
with #ifdef PTHREAD_MUTEX_RECURSIVE/#endif pairs.
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-11-02 18:43
---
> I think problem related to commit:
>
> 2004-10-29 Eric Botcazou <[EMAIL PROTECTED]>
>
> * gthr-posix.h (__gthread_recursive_mutex_init_function): Guard
> with #ifdef PTHREAD_MUTEX_REC
--- Additional Comments From wanderer at rsu dot ru 2004-11-02 18:46 ---
from /usr/include/pthread.h:
enum pthread_mutextype {
PTHREAD_MUTEX_ERRORCHECK= 1,/* Default POSIX mutex */
PTHREAD_MUTEX_RECURSIVE = 2,/* Recursive mutex */
PTHREAD_M
If a JNI function returns a weak reference created with NewWeakGlobalRef, you'll
get a class cast exception like this:
java.lang.ClassCastException: gnu.gcj.runtime.JNIWeakRef cannot be cast to
org.gnu.glib.GObject
at _Jv_CheckCast (/usr/lib/libgcj.so.6.0.0)
--
Summary: JNI functio
--- Additional Comments From tromey at gcc dot gnu dot org 2004-11-02 18:55
---
Do you have some sample code or something?
I tend to suspect your code, simply for the reason
that GObject is not part of libgcj.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18278
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-11-02 18:55
---
Fixing.
--
What|Removed |Added
CC|ebotcazou at libertysurf dot|
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-02 19:00
---
Subject: Bug 17922
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-11-02 19:00:19
Modified files:
libstdc++-v3 : ChangeLog
libstdc++-v3/confi
GCC-4.0.0 has a regression in that -fdump-translation-unit no longer output
function bodies.
Tentative patch at
http://gcc.gnu.org/ml/gcc-bugs/2004-07/msg03341.html
--
Summary: missing function bodies from -fdump-translation-unit
Product: gcc
Version: 4.0.0
--- Additional Comments From laurent at bearteam dot org 2004-11-02 20:09 ---
(In reply to comment #1)
> Do you have some sample code or something?
> I tend to suspect your code, simply for the reason
> that GObject is not part of libgcj.
I should have mentionned that GObject is the clas
$ /usr/local/bin/g++-3.4 -v
Reading specs from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/specs
Configured with: ./configure --enable-languages=c,c++ --enable-shared
--with-system-zlib --enable-nls --program-suffix=-3.4 --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --enable-clocale=
--
What|Removed |Added
Keywords||ice-on-valid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18280
--- Additional Comments From boris at kolpackov dot net 2004-11-02 20:16 ---
Created an attachment (id=7458)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7458&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18280
--
What|Removed |Added
Known to fail||3.4.0
Known to work||4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18280
--- Additional Comments From laurent at bearteam dot org 2004-11-02 20:34 ---
Created an attachment (id=7460)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7460&action=view)
Sample JNI c code
This is jni.i.gz, as produced by:
cc -c -save-temps weakref.c -o weakref.o
gzip weakref.i
--- Additional Comments From laurent at bearteam dot org 2004-11-02 20:38 ---
Created an attachment (id=7461)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7461&action=view)
Sample java code
Here's how I compiled to whole thing:
cc -c weakref.c -o weakref.o
cc -shared -Xlinker -
If gcj is called while the environment variable CLASSPATH contains backslashes
instead of slashes, jc1 (called by gcj) hangs without any error message. Could
gcj/jc1 be made "backslash tolerant"?
--
Summary: Backslashes in CLASSPATH cause jc1 to hang
Product: gcc
--- Additional Comments From amacleod at redhat dot com 2004-11-02 21:04 ---
whups. That new patch was bootstrapped and tested for no new regressions on
i686-pc-linux-gnu
presumably its OK for mainline? I may rework this for 4.1 to not use
make_forwarder_block() after all, since this se
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni dot cz
2004-11-02 21:23 ---
Subject: Re: [4.0 Regression] internal compiler error: in
tree_redirect_edge_and_branch, at tree-cfg.c:4146
Hello,
> Is there a rule for make_forwarder_block that says it cannot forw
typedef enum { B1 = 1 } B;
B __attribute__ ((mode (QI))) b;
doesn't compile since 2004-10-13 on gcc-3_4-branch, while it is accepted
by GCC 3.3.x, 3.4.2 and current CVS HEAD.
enum with mode attribute is used e.g. by DHCP, so it would be bad if
3.4.3 was released with this.
--
Summary
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-02 21:52
---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-11-02 22:31
---
I agree with you with regards to the ugliness.
The entire situation is really too bad; the mutually incompatible path
separators used by Unix and Windows is definitely one of the top ten
compatibility probl
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org |
Status|NEW
--- Additional Comments From rth at gcc dot gnu dot org 2004-11-02 23:14 ---
NOT a regression. The mode argument was IGNORED, silently, by previous versions.
See http://gcc.gnu.org/ml/gcc/2004-10/msg00715.html
--
What|Removed |Added
--
--- Additional Comments From mark at codesourcery dot com 2004-11-02 23:18 ---
Subject: Re: PR c/17384 patch causes regression from 3.4.2
Jakub --
Since Richard says this is not a regression, but rather a case where the
compiler is now correctly diagnosing code that previously did not
--- Additional Comments From bkoz at gcc dot gnu dot org 2004-11-02 23:45 ---
Compiled like so, after setting LD_LIBRARY_PATH to ACE libs:
g++ -g -O2 -pthread -I$bld/H-x86-ACE/include -L$bld/H-x86-ACE/lib -lACE 17664.cc
As suspected, only the safe_iterator bits in the original patch nee
Hi,
the following code snippet does not compile:
program gfcbug20
implicit none
type :: a_t
character, pointer :: line
! character (len=1), pointer :: line
end type a_t
type (a_t) :: a = a_t ( NULL() )
character, target :: b
! character (len=1), targe
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-02 23:54
---
I think this is the same as PR 18023.
--
What|Removed |Added
BugsThisDependsOn|
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org |
Status|NEW
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-02 23:57
---
Subject: Bug 17627
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-11-02 23:56:57
Modified files:
libstdc++-v3 : ChangeLog
libstdc++-v3/src:
--- Additional Comments From bkoz at gcc dot gnu dot org 2004-11-03 00:04 ---
Chris, excellent. Since this is being held in libstdcxx_so_7-branch, there is no
danger in these improvements getting lost.
I'm going to close this now, since it appears likely to be fixed in some future
versi
--- Additional Comments From anlauf at hep dot tu-darmstadt dot de 2004-11-03
00:09 ---
(In reply to comment #1)
> I think this is the same as PR 18023.
Well, actually I get slightly different line numbers with my example and
the example of PR 18023 (1982 vs. 1986). Maybe they're relat
--- Additional Comments From bkoz at gcc dot gnu dot org 2004-11-03 00:12 ---
Joel, you might want to talk to the m68k maintainers.
Take your pick:
m68hc11 portStephane Carrez [EMAIL PROTECTED]
m68k port (?) Jeff Law[EMAIL PROTECTED]
m68k-m
--- Additional Comments From bkoz at gcc dot gnu dot org 2004-11-03 00:18 ---
Simple grep:
/include/std/std_complex.h: __complex_arg(__complex__ float __z) { return
__builtin_cargf(__z); }
Simple theory: on targets without __builtin_cargf, cargf gets referenced with
this call. However,
--- Additional Comments From bkoz at gcc dot gnu dot org 2004-11-03 00:20 ---
Yo RTH, any word on this?
-benjamin
--
What|Removed |Added
CC|
--- Additional Comments From gdr at cs dot tamu dot edu 2004-11-03 00:28 ---
Subject: Re: Test failures due to missing C99 symbols
"bkoz at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| Simple grep:
|
| /include/std/std_complex.h: __complex_arg(__complex__ float __z) { return
|
--- Additional Comments From sebor at roguewave dot com 2004-11-03 00:49 ---
FWIW, if you missed it there was a discussion of this issue
on [EMAIL PROTECTED], starting with c++std-core-10643. Mike
Miller said he'd open an issue for it. I don't see it on the
list yet but I assume it will b
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-03 00:54
---
Subject: Bug 17583
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-11-03 00:54:02
Modified files:
gcc/fortran: ChangeLog module.c
gcc/tests
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-03 00:54
---
Subject: Bug 17535
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-11-03 00:54:02
Modified files:
gcc/fortran: ChangeLog module.c
gcc/tests
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-03 00:54
---
Subject: Bug 17713
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-11-03 00:54:02
Modified files:
gcc/fortran: ChangeLog module.c
gcc/tests
--- Additional Comments From tobi at gcc dot gnu dot org 2004-11-03 00:57 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From tobi at gcc dot gnu dot org 2004-11-03 00:57 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--
Bug 15164 depends on bug 17583, which changed state.
Bug 17583 Summary: internal compiler error: same names, but not conflicting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17583
What|Old Value |New Value
-
--- Additional Comments From tobi at gcc dot gnu dot org 2004-11-03 00:58 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From Jim_Brownfield at radical dot com 2004-11-03 01:05
---
Created an attachment (id=7462)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7462&action=view)
auto-edited math.h file
I'm having the same problem trying to build gcc on sco 3.2 5.0.6 i386
It app
--- Additional Comments From Jim_Brownfield at radical dot com 2004-11-03 01:07
---
Sorry, that's building gcc 3.4.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17995
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17713
open(unit=10,access='SEQUENTIAL')
do I = 1,200
write(10,*)I
end do
backspace(10)
backspace(10)
read(10,*)I
print*,I
end
gives a runtime error. it should report "199", just like g77.
--
Summary: BACKSPACE broken
Pro
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-03 02:48
---
Subject: Bug 18124
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-11-03 02:48:45
Modified files:
gcc/cp : ChangeLog parser.c typeck.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-03 02:48
---
Subject: Bug 18155
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-11-03 02:48:45
Modified files:
gcc/cp : ChangeLog parser.c typeck.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-03 02:48
---
Subject: Bug 18177
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-11-03 02:48:45
Modified files:
gcc/cp : ChangeLog parser.c typeck.c
--- Additional Comments From mmitchel at gcc dot gnu dot org 2004-11-03 02:56
---
Fixed in GCC 4.0.
--
What|Removed |Added
Summary|[3.4/4.0 regression] typedef|[3
--- Additional Comments From mmitchel at gcc dot gnu dot org 2004-11-03 02:56
---
Fixed in GCC 4.0.
--
What|Removed |Added
Status|ASSIGNED|RE
--- Additional Comments From mmitchel at gcc dot gnu dot org 2004-11-03 02:58
---
Fixed in GCC 4.0.
--
What|Removed |Added
Summary|[3.4/4.0 regression] ICE|[3
--- Additional Comments From kghazi at verizon dot net 2004-11-03 05:13 ---
Subject: Re: C testsuite failures in compile/simd-5.c w/-m64 or on sparcv9/sparc64
The problem appears to be fixed in every multilib combination.
http://gcc.gnu.org/ml/gcc-testresults/2004-11/msg00098.html
http:
--- Additional Comments From giovannibajo at libero dot it 2004-11-03 05:18
---
Introduced by:
2004-08-25 Kriang Lerdsuwanakij <[EMAIL PROTECTED]>
PR c++/14428
* pt.c (redeclare_class_template): Check the type of non-type and
template template parameter.
http
--- Additional Comments From jakub at gcc dot gnu dot org 2004-11-03 07:45 ---
Seems the attribute worked before (and with the patch I posted on gcc-3_4-branch
as well) when used on a decl with enum type, but not when used on enum's typedef.
On the other side, current trunk works when it
99 matches
Mail list logo
