[Bug tree-optimization/18463] [4.0 Regression] Moving floating point through an integer register
--- Additional Comments From rakdver at gcc dot gnu dot org 2004-11-26 08:12 --- The problem indeed is ivopts - dom interaction. Ivopts decide that since reg + 4 * reg is a cheap addressing mode, there is no reason to do anything else than what it does. To cure this we need to be able to allow ivopts to express more clearly that it does not want an expression to be played with; I think the best solution is to have a tree code that would map directly to the memory access (including the addressing mode). I am working on the patch. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18463
[Bug tree-optimization/17647] [4.0 regression] Missing i386 addressing modes
--- Additional Comments From uros at gcc dot gnu dot org 2004-11-26 08:50 --- (In reply to comment #6) > This is fully a IV-OPTS problem now. > With -fno-ivopts, I get I can't get the same code as you. With mainline gcc (gcc version 4.0.0 20041126 (experimental)) and 'gcc -O2 -S -fno-ivopts LU.c' I got: xorl%edx, %edx .p2align 4,,15 .L5: leal0(,%edx,8), %eax incl%edx fldl(%eax,%ecx) cmpl%edx, %edi fstpl (%ebx,%eax) jg .L5 leal is redundant in this case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17647
[Bug libstdc++/18678] std::time_put is broken with UTF-8 locales
--- Additional Comments From pcarlini at suse dot de 2004-11-26 09:25 --- Hi. I suppose your PR is about 3.4.x: 3.4.3, to be sure? Anyway, the most important point is that you are not telling us which is exactly your expectation! You are comparing, correctly, time_put with strftime, and there is a perfect match; however, you are *not* comparing time_put with wcsftime (I expect a perfect match also, since we are actually using wcsftime in the implementation). -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18678
[Bug target/12817] [SYSV] Altivec code generation error with many registers used
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net |dot org |dot au Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12817
[Bug rtl-optimization/8126] [3.3/3.4/4.0 regression] Floating point computation far slower in 3.2 than in 2.95
--- Additional Comments From uros at gcc dot gnu dot org 2004-11-26 09:38 --- (In reply to comment #15) > Hmm, 4.0.0 is faster and smaller at least on a pentium4. The faster and smaller code is produced because scheduler is disabled for pentium4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8126
[Bug libstdc++/18678] std::time_put is broken with UTF-8 locales
--- Additional Comments From pcarlini at suse dot de 2004-11-26 09:40 --- P.S. If, on the other hand, the non-ascii chars are troubling you, this is of course not a libstdc++-v3 issue, it's just that the shell is not able to correctly render UTF-8. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18678
[Bug target/12817] [SYSV] Altivec code generation error with many registers used
--- Additional Comments From amodra at bigpond dot net dot au 2004-11-26
09:54 ---
/* vrsave code in the prologue trashes frame pointer reg
-m32 -maltivec -mabi=altivec -mvrsave=yes -S pr12817.c */
#define vector __attribute__ ((vector_size (16)))
extern void foo (int *);
vector int
v_add (vector int a, vector int b)
{
int x[1];
foo (x);
return a + b;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12817
[Bug c++/18635] use of uninitialised reference accepted in C++ front end
--- Additional Comments From giovannibajo at libero dot it 2004-11-26 10:16 --- Do you have a comp.std.c++ link? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18635
[Bug target/12817] [SYSV] Altivec code generation error with many registers used
--- Additional Comments From amodra at bigpond dot net dot au 2004-11-26 10:53 --- http://gcc.gnu.org/ml/gcc-patches/2004-11/msg02247.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12817
[Bug libstdc++/18633] resource allocation problem with __gnu_cxx::hash_map
--- Additional Comments From pcarlini at suse dot de 2004-11-26 10:58 --- Actually, just moving down the resize is not ok, since __n and __first would need to be recomputed too, with a non-trivial overhead in case of insert. Also, the memory doubling happens only when one of the thresholds is encountered, not in the common case. Add to this that these are basically legacy and non-portable facilities (new ISO-mandated unordered containers will be provided soon). All in all, better not touching find_or_insert, sorry. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18633
[Bug libstdc++/18678] std::time_put is broken with UTF-8 locales
--- Additional Comments From rleigh at debian dot org 2004-11-26 12:13
---
Yes, I'm using 3.4.3 (and glibc-2.3.2.ds1-18). With respect to the comparisons,
I've now added wcsftime() to the test, and it /does/ match
std::time_put:
$ LANG=ru_RU.UTF-8 LC_ALL=ru_RU.UTF-8 ./date3
asctime:Fri Nov 26 11:32:47 2004
strftime: Птн 26 Ноя 2004 11:32:47
wcsftime: B= 26 >O 2004 11:32:47
std::time_put:Птн 26 Ноя 2004 11:32:47
std::time_put: B= 26 >O 2004 11:32:47
Viewed as hexadecimal (aligned for comparison):
"Narrow" UTF-8:
П т н2 6 Н о я
==> d0 9f d1 82 d0 bd 20 32 36 20 d0 9d d0 be d1 8f
2 0 0 4 1 1 : 3 2 : 4 7 \n
==> 20 32 30 30 34 20 31 31 3a 35 31 3a 30 34 0a
"Wide" unknown:
B = 2 6 > O
==> 1f 42 3d 20 32 36 20 1d 3e 4f
2 0 0 4 1 1 : 3 2 : 4 7 \n
==> 20 32 30 30 34 20 31 31 3a 35 31 3a 30 34 0a
However... I am using a UTF-8-capable terminal (GNOME-terminal, and the Linux
console with LatArCyrHeb font in UTF-8 mode). In both of these cases, the
output appears as above; the "narrow" output to cout is displayed correctly (I
verified this is valid UTF-8), but the "wide" output to wcout is not valid
UTF-8.
I expected valid UTF-8 in both cases, since this is what the locale codeset
specifies. I'm not sure what encoding wchar_t would be using, but I assumed I
would get readable output (maybe I am wrong about that?). It looks like the
"wide" output is a different encoding, but for some reason has not affected the
7-bit ASCII range (I would have expected something like padding with \0 if it
was outputting UCS-4).
Regards,
Roger
#include
#include
#include
#include
int main()
{
// Set up locale stuff...
std::locale::global(std::locale(""));
std::cout.imbue(std::locale());
std::wcout.imbue(std::locale());
// Get current time
time_t simpletime = time(0);
// Break down time.
std::tm brokentime;
localtime_r(&simpletime, &brokentime);
// Normalise.
mktime(&brokentime);
std::cout << "asctime:" << asctime(&brokentime);
// Print with strftime(3)
char buffer[40];
std::strftime(&buffer[0], 40, "%c", &brokentime);
std::cout << "strftime: " << &buffer[0] << '\n';
wchar_t wbuffer[40];
std::wcsftime(&wbuffer[0], 40, L"%c", &brokentime);
std::wcout << "wcsftime: " << &wbuffer[0] << '\n';
// Try again, but use proper locale facets...
const std::time_put& tp =
std::use_facet >(std::cout.getloc());
std::string pattern("std::time_put:%c\n");
tp.put(std::cout, std::cout, std::cout.fill(),
&brokentime, &*pattern.begin(), &*pattern.end());
// And again, but using wchar_t...
const std::time_put& wtp =
std::use_facet >(std::wcout.getloc());
std::wstring wpattern(L"std::time_put: %c\n");
wtp.put(std::wcout, std::wcout, std::wcout.fill(),
&brokentime, &*wpattern.begin(), &*wpattern.end());
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18678
[Bug libstdc++/18678] std::time_put is broken with UTF-8 locales
--- Additional Comments From pcarlini at suse dot de 2004-11-26 12:37 --- Hi again, and thanks for your feedback. Honestly, I'm not sure what the various consoles are supposed to do with wchar_t outputs. In any case, sorry, but this is not a libstdc++-v3 issue (anymore). -- What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18678
[Bug libstdc++/18678] std::time_put is broken with UTF-8 locales
--- Additional Comments From pcarlini at suse dot de 2004-11-26 12:55 --- > I expected valid UTF-8 in both cases, since this is what the locale codeset > specifies. I'm not sure what encoding wchar_t would be using, but I assumed I > would get readable output (maybe I am wrong about that?). In case of wchar_t output, I don't think you have any reason to expect a readable output. >It looks like the > "wide" output is a different encoding, but for some reason has not affected > the 7-bit ASCII range (I would have expected something like padding with \0 > if it was outputting UCS-4). I should double check, really, but I'm pretty sure that libc wcsftime (and therefore libstdc++) just outputs wchar_t in the internal, UCS-4 encoding (which is not supposed to be readable). Paolo. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18678
[Bug target/18510] GCC should have instrinsics for SPARC VIS instructions
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-26 13:18 --- Subject: Bug 18510 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-26 13:18:16 Modified files: gcc: ChangeLog gcc/doc: extend.texi Log message: 2004-11-26 James A. Morrison <[EMAIL PROTECTED]> PR target/18510 * doc/extend.texi (SPARC VIS Built-in Functions): New section. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6569&r2=2.6570 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/extend.texi.diff?cvsroot=gcc&r1=1.232&r2=1.233 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18510
[Bug ada/18680] New: pragma Linker_Section problems
Hello, there seems to be still a problem with 'pragma Linker_Section': package test is eeprom : constant String := "12345678901234567"; -- 17 byte pragma Linker_Section (Entity => eeprom, Section => ".eeprom"); type Eeprom_String is new String; pragma Linker_Section (Entity => Eeprom_String, Section => ".eeprom"); Data_1 : constant Eeprom_String := "12345678901234567"; -- 17 byte Data_2 : constant String := "1234567890123456"; -- 16 byte pragma Linker_Section (Entity => Data_2, Section => ".eeprom"); end; $ gcc -c test.ads $ readelf -a test.o [..] Section Headers: [Nr] Name TypeAddr OffSize ES Flg Lk Inf Al [ 0] NULL 00 00 00 0 0 0 [ 1] .text PROGBITS 34 00 00 AX 0 0 4 [ 2] .data PROGBITS 34 22 00 WA 0 0 4 [ 3] .bss NOBITS 58 00 00 WA 0 0 4 [ 4] .eeprom PROGBITS 58 11 00 WA 0 0 1 [..] Symbol table '.symtab' contains 12 entries: Num:Value Size TypeBind Vis Ndx Name [..] 9: 17 OBJECT GLOBAL DEFAULT4 test__eeprom 10: 000117 OBJECT GLOBAL DEFAULT2 test__data_1 11: 001216 OBJECT GLOBAL DEFAULT2 test__data_2 The problems I can see are: 1. The minimum usable length is 17 byte! 2. gcc ignors 'pragma Linker_Section' for types. gcc version 4.0.0 20041123 (experimental) -- Summary: pragma Linker_Section problems Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: berndtrog at yahoo dot com CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-gnu-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18680
[Bug fortran/18108] [gfortran] overloading does not work for functions
--- Additional Comments From martin at mpa-garching dot mpg dot de 2004-11-26 13:33 --- Created an attachment (id=7613) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7613&action=view) a test case for the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18108
[Bug c++/18681] New: template friend declaration not recognized
Dear all,
I would like to post a fault report for the GNU C/C++ compiler 3.3-e500.
We use the compiler to generate code for a PowerPC processor.
Used invokation line for the GNU C++ compiler:
ccppc -c -x c++ -ansi -Wall -Werror -mcpu=8540 -fverbose-asm -mbig
-fmerge-templates -mmultiple -mno-string -mstrict-align -O3
-fno-exceptions -fno-rtti -fno-builtin-printf
-I
-D
K.CPP -oK.O
// example program
template class C1;
template class C2;
template
class C2
{
typedef T_* T_PAR_TYPE;< k.CPP, line 7
friend class C1; < class C1 is a friend
};
template
class C1
{
//public: < k.CPP, line 14
typedef typename C2::T_PAR_TYPE T_PAR;
struct S1
{
T_PAR par; < k.CPP, line 18
};
static void fx (S1&);
public:
void f (T_PAR ptr);
};
template
void C1::f (T_PAR ptr_)
{
S1 s1; < k.CPP, line 31
fx (s1);
}
typedef int T_MEM[20];
void f (T_MEM* p1)
{
C1 c1;
c1.f (p1); < k.CPP, line 45
}
The compiler gives the following error messages:
k.CPP: In instantiation of `C1::S1':
k.CPP:31: instantiated from `void C1< >::f
(typename C2< >::T_PAR_TYPE) [with T_ = int
(*)[20]]'
k.CPP:45: instantiated from here
k.CPP:7: error: `typedef int (*C2::T_PAR_TYPE)[20]' is private
k.CPP:18: error: within this context
The error messages remain the same if line 14 is un-commented. This seems OK
since the access specification of C1<>::T_PAR should not affect C1<>::S1. The
compiler translates only without complaints if C2<>::T_PAR_TYPE is made public.
With kind regards
W. Roehrl
--
Summary: template friend declaration not recognized
Product: gcc
Version: 3.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wolfgang dot roehrl at de dot gi-de dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: sparc-sun-solaris2.5.1
GCC host triplet: i386-pc-mingw32
GCC target triplet: powerpc-wrs-vxworks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18681
[Bug libstdc++/18678] std::time_put is broken with UTF-8 locales
--- Additional Comments From rleigh at debian dot org 2004-11-26 13:52 --- Thanks for the fast response! I guess how wchar_t output works is implementation-defined, but I'll check up on how it should work--it's probably working entirely correctly. Many thanks, Roger -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18678
[Bug libgcj/13806] linking libgcj.so requires excessive time/memory
--- Additional Comments From phython at gcc dot gnu dot org 2004-11-26 13:52 --- This problem got worse after the BC branch merged in. I can't link libgcj on powerpc-linux anymore because the process gets killed every time. I only have 256MB of ram. I suspect I'll have the same trouble on sparc-linux and hppa-linux as those boxes also only have 256MB or ram. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13806
[Bug libfortran/18398] Formatted I/O problems
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-26 14:34:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18398
[Bug fortran/18108] [gfortran] overloading does not work for functions
--- Additional Comments From bdavis at gcc dot gnu dot org 2004-11-26 14:40 --- confirmed. [EMAIL PROTECTED] pr18398]$ gfc z.f90 In file z.f90:27 l = bar (3) 1 Error: Symbol 'bar' at (1) has no IMPLICIT type [EMAIL PROTECTED] pr18398]$ gfc --version GNU Fortran 95 (GCC 4.0.0 20041124 (experimental)) -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-26 14:40:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18108
[Bug ada/18680] pragma Linker_Section problems
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-26 15:23 --- *** This bug has been marked as a duplicate of 10670 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18680
[Bug ada/10670] gcc ignors 'pragma Machine_Attribute' directive
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-26 15:23 --- *** Bug 18680 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10670
[Bug target/18510] GCC should have instrinsics for SPARC VIS instructions
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-26 15:24 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18510
[Bug c++/18681] template friend declaration not recognized
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-26 15:33 --- *** This bug has been marked as a duplicate of 950 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18681
[Bug c++/950] Template problem: decay of pointer-to-member-of-derived to p-o-m-o-base
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-26 15:34 --- *** Bug 18681 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||wolfgang dot roehrl at de ||dot gi-de dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=950
[Bug tree-optimization/17647] [4.0 regression] Missing i386 addressing modes
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-26 15:40 --- (In reply to comment #7) > (In reply to comment #6) > > This is fully a IV-OPTS problem now. > > With -fno-ivopts, I get > > I can't get the same code as you. With mainline gcc (gcc version 4.0.0 > 20041126 > (experimental)) and 'gcc -O2 -S -fno-ivopts LU.c' I got: Now at -O1, I do get the leal: leal0(,%ebx,8), %edx movl(%edi), %ecx movl(%esi), %eax fldl(%edx,%eax) fstpl (%ecx,%edx) Likewise at -Os (which seems wrong): movl-16(%ebp), %eax leal0(,%ebx,8), %edx incl%ebx movl(%eax), %ecx movl(%edi), %eax fldl(%eax,%edx) fstpl (%ecx,%edx) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17647
[Bug ada/18680] pragma Linker_Section problems
--- Additional Comments From berndtrog at yahoo dot com 2004-11-26 15:45 --- >This is also a dup of bug 10670. Please note that PR10670 is about a broken 'pragma Machine_Attribute', not about 'pragma Linker_Section'. (It *may* be related to PR14115) -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18680
[Bug middle-end/15855] [3.4/4.0 Regression] g++ crash with -O2 and -O3 on input file
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-26 16:00 --- (In reply to comment #12) > These part are 4.0 regressions: Improvements already (note the scheduling goes away with -fno-PIC at least on ppc-darwin): tree alias analysis : 16.84 (12%) usr 0.40 ( 1%) sys 17.74 ( 8%) wall tree PHI insertion: 7.94 ( 5%) usr 1.00 ( 3%) sys 9.31 ( 4%) wall tree SSA rewrite : 10.79 ( 7%) usr 4.11 (12%) sys 17.07 ( 8%) wall tree SSA other: 20.02 (14%) usr 2.51 ( 7%) sys 24.59 (11%) wall tree operand scan : 8.15 ( 6%) usr 3.38 (10%) sys 11.66 ( 5%) wall scheduling: 13.15 ( 9%) usr 5.78 (17%) sys 19.44 ( 9%) wall -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15855
[Bug c++/18681] [3.3/3.4/4.0 regression] template friend declaration not recognized
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-11-26 16:30 --- Hmm. This code uses pointer to array, not pointer to member as in PR c++/950. It's also a regression from GCC 3.2.x but we didn't actually do access checking in templates in those earlier versions. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | Summary|template friend declaration |[3.3/3.4/4.0 regression] |not recognized |template friend declaration ||not recognized http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18681
[Bug c++/18681] [3.3/3.4/4.0 regression] template friend declaration not recognized
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-11-26 16:31 --- Confirmed as a bug, likely unrelated to PR950. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-26 16:31:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18681
[Bug c++/1016] [DR 166] friend class declarations not observing namespace rules.
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-11-26
16:31 ---
Kriang, according to your comment in #6 the original example should
compile, right?
And the following example should generate an error in line 12 since
the global class b is not a friend of foo::a, right?
=
class b { void bar(); };
namespace foo
{
class a
{
friend class b;
b b_;
};
}
void b::bar() { foo::a().b_; }
=
In this case we have a rejects-valid on mainline for the example in
comment #1. And an accepts-invalid for the example in this comment
for gcc 2.95.3 - 3.4.3.
--
What|Removed |Added
Keywords||rejects-valid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1016
[Bug c++/18681] [3.3/3.4/4.0 regression] template friend declaration not recognized
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-26 16:34 --- But likely related to PR 2892 (that was the one which I had ment to mark as a dup to). -- What|Removed |Added BugsThisDependsOn||2892 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18681
[Bug c++/1016] [DR 166] friend class declarations not observing namespace rules.
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-11-26 16:39 --- Right. The code example in comment #1 should compile and comment #8 should not. Class foo::b, which is still not declared yet, is the friend of class foo::a. So this bug is both accepts-invalid and rejects-valid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1016
[Bug c++/18652] [4.0 regression] ICE on invalid redeclaration
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |lerdsuwa at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18652
[Bug c++/18652] [4.0 regression] ICE on invalid redeclaration
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-11-26 17:00 --- Will take a look, maybe it's fixed already by Mark. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18652
[Bug java/18682] New: gcj doesnt reject invalid code
GCJ does not reject the following invalid code:
public class NullTest
{
public static void main (String[] args)
{
int index = 1;
if (index == null)
index++;
}
}
--
Summary: gcj doesnt reject invalid code
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: konqueror at gmx dot de
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18682
[Bug java/18682] gcj doesnt reject invalid code
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Known to fail||3.3.4 3.4.2 4.0.0 Last reconfirmed|-00-00 00:00:00 |2004-11-26 17:13:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18682
Re: [Bug libstdc++/18644] [3.3/3.4/4.0 regression] -Wsynth warning in
"bangerth at ices dot utexas dot edu" <[EMAIL PROTECTED]> writes: | > The diagnostic is nonsensical. The fix is to fix the diagnostic, not | > to paper over the problem. | | That's certainly the best solution. -Wsynth should just not trigger in | libstdc++ headers. yes, and even more in user codes where it does not make sense. Remember, we're currently compiling programs with ISO rules, and we have very very little provisions to compile programs with cfront rules (and you'd have to specify which version of cfront). -- Gaby
[Bug libstdc++/18644] [3.3/3.4/4.0 regression] -Wsynth warning in
--- Additional Comments From gdr at integrable-solutions dot net 2004-11-26 17:45 --- Subject: Re: [3.3/3.4/4.0 regression] -Wsynth warning in "bangerth at ices dot utexas dot edu" <[EMAIL PROTECTED]> writes: | > The diagnostic is nonsensical. The fix is to fix the diagnostic, not | > to paper over the problem. | | That's certainly the best solution. -Wsynth should just not trigger in | libstdc++ headers. yes, and even more in user codes where it does not make sense. Remember, we're currently compiling programs with ISO rules, and we have very very little provisions to compile programs with cfront rules (and you'd have to specify which version of cfront). -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18644
[Bug java/18682] gcj doesnt reject invalid code
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-26 17:46 --- Hmm interesting we even produce valid bytecode with the source, maybe we are converting into the correct type which is why this is accepted. -- What|Removed |Added Known to fail|3.3.4 3.4.2 4.0.0 |3.3.4 3.4.2 4.0.0 3.0.4 ||3.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18682
[Bug java/18305] Class initialization optimization is not done when compiled from .class
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-26 18:04 --- Subject: Bug 18305 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-26 18:04:46 Modified files: gcc/java : ChangeLog decl.c expr.c java-tree.h jcf-parse.c parse.y Log message: 2004-11-26 Andrew Pinski <[EMAIL PROTECTED]> PR java/18305 * decl.c (end_java_method): Call attach_init_test_initialization_flags on all the init_decls. * parse.y (attach_init_test_initialization_flags): Move to ... * expr.c (attach_init_test_initialization_flags): here and support BIND_EXPR also. * java-tree.h (attach_init_test_initialization_flags): Prototype. * jcf-parse.c (parse_class_file): Don't disable class init optimization. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gcc&r1=1.1506&r2=1.1507 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/decl.c.diff?cvsroot=gcc&r1=1.204&r2=1.205 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/expr.c.diff?cvsroot=gcc&r1=1.211&r2=1.212 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/java-tree.h.diff?cvsroot=gcc&r1=1.222&r2=1.223 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/jcf-parse.c.diff?cvsroot=gcc&r1=1.178&r2=1.179 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/parse.y.diff?cvsroot=gcc&r1=1.522&r2=1.523 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18305
[Bug java/18305] Class initialization optimization is not done when compiled from .class
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-26 18:05 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18305
[Bug middle-end/18683] New: [4.0 Regression] seg fault in local allocate
Using the code in PR 12850 at -O0, I get a seg fault on the mainline. I think this is a recent regression but I don't know for sure. -- Summary: [4.0 Regression] seg fault in local allocate Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: critical Priority: P2 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: powerpc-darwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18683
[Bug middle-end/18683] [4.0 Regression] seg fault in local allocate
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18683
[Bug c++/18677] [3.4/4.0 regression] ICE: Segmentation fault (program cc1plus)
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-11-26 21:00 --- *** This bug has been marked as a duplicate of 17431 *** -- What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18677
[Bug c++/17431] [3.4/4.0 regression] Internal error: Segmentation fault (program cc1plus)
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-11-26 21:00 --- *** Bug 18677 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||debian-gcc at lists dot ||debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17431
[Bug c++/18684] New: static member function not defined in std::locale::facet class
The g++ compiler version and machine information are as follows:
Reading specs from /usr/lib/gcc/ppc64-redhat-linux/3.4.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --
infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-
checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-
exceptions --enable-languages=c,c++,objc,java,f77 --enable-java-awt=gtk --
host=ppc64-redhat-linux --build=ppc64-redhat-linux --target=ppc64-redhat-linux -
-with-cpu=default32
Thread model: posix
gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)
Here is a simple testcase:
#include
template
class A: public std::locale::facet
{
public:
const char* a1;
void f(){
a1 = std::locale::facet::_S_get_c_name();
//a1=_S_get_c_name(); <- this line also gives the same error.
}
};
int main()
{
A obj;
obj.f();
}
Compiling the testcase with g++ compiler, I am getting the linking error:
/tmp/ccM4h5sR.o(.gnu.linkonce.t._ZN1AIiE1fEv+0x20): In function `A::f()':
: undefined reference to `std::locale::facet::_S_get_c_name()'
collect2: ld returned 1 exit status
The problem is the static member function _S_get_c_name() which is declared in
the is not defined.
--
Summary: static member function not defined in std::locale::facet
class
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P1
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yanliu at ca dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18684
[Bug libstdc++/18684] static member function not defined in std::locale::facet class
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-26 21:07 --- Most likely this is not exported as it works on the mainline on ppc-darwin which really does not use a version script at all. Also the underscoped functions are reserved so there might be a reason why this is not exported. And this is a libstdc++ problem and not a C++ front-end problem. -- What|Removed |Added Component|c++ |libstdc++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18684
[Bug c++/17431] [3.4/4.0 regression] Internal error: Segmentation fault (program cc1plus)
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-11-26
21:10 ---
Here's a slightly shorter testcase (inspired by PR18677):
===
struct A {};
struct B : A
{
B(int);
B(B&);
B(A);
};
B b=0;
===
--
What|Removed |Added
Known to fail|3.4.1 3.4.2 |3.4.1 3.4.2 4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17431
[Bug libstdc++/18684] static member function not defined in std::locale::facet class
--- Additional Comments From pcarlini at suse dot de 2004-11-26 21:36 --- The function is defined in src/locale.cc and is not tailored to the users of the library. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18684
[Bug target/18117] [4.0 Regression] Bootstrap fails on i386-k*bsd-gnu
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-26 21:38 --- Fixed now. Thanks for your report. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18117
[Bug ada/18685] New: Ada boostrap broken
Hi, I identified the patch that causes the Ada bootstrap failure on x86 and x86_64 (at least): ../../xgcc -B../../ -c -g -O2 -fPIC -W -Wall -gnatpg s-stratt.adb -o s-stratt.o +===GNAT BUG DETECTED==+ | 4.0.0 20041123 (experimental) (i686-pc-linux-gnu) GCC error: | | in gen_lowpart_general, at rtlhooks.c:58 | | Error detected at s-stratt.adb:671:1 | works: cvs up -D "2004/11/24 00:06:17 UTC" breaks: cvs up -D "2004/11/24 00:10:17 UTC" date: 2004/11/24 00:08:17; author: rth; state: Exp; lines: +11 -0 * rtl.h (validate_subreg): Declare. * emit-rtl.c (validate_subreg): New. (gen_rtx_SUBREG): Use it. * simplify-rtx.c (simplify_subreg): Likewise. (simplify_gen_subreg): Likewise. Remove duplicate asserts. * expr.c (emit_move_insn_1): Tidy complex move code. Use memory fallback whenever gen_realpart/gen_imagpart would not be able to create SUBREGs. -- Summary: Ada boostrap broken Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: laurent at guerby dot net CC: gcc-bugs at gcc dot gnu dot org,laurent at guerby dot net,rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18685
[Bug rtl-optimization/18685] [4.0 Regression] Ada boostrap broken
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-26 22:04 --- Also on ppc-darwin and ppc-linux. -- What|Removed |Added Status|UNCONFIRMED |NEW Component|ada |rtl-optimization Ever Confirmed||1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2004-11-26 22:04:29 date|| Summary|Ada boostrap broken |[4.0 Regression] Ada ||boostrap broken Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18685
[Bug tree-optimization/18291] [4.0 Regression]: ICE in merge_alias_info
--- Additional Comments From dberlin at gcc dot gnu dot org 2004-11-26 22:11 --- The real bug here is that may_propagate_copy (op, val) returns true, but we abort when domopts calls propagate_value with the same arguments. We think something has gone wrong horribly wrong with regards to flow-sensitive alias info because the block with the &k in it became dead, allowing us to copy propagate p_1 into p_2. However, p_2 still has the name tag that includes k (which is now gone completely), and p_1 doesn't, because alias info hasn't been rebuilt since CCP+DCE removed the block with &k in it. There are a couple options, i'll leave it to diego to decide what is best: 1. Make may_propagate_copy return false (conservatively) when we are trying to propagate and the name tags don't match. The propagation will still happen later after alias info gets rebuilt again. 2. Allow the propagation anyway, and just choose the "best" name tag (the one with the smallest number of pt_vars), under the assumption that we know what the heck we are doing :) Diego, if you are too busy, just let me know which you prefer and i'll implement it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18291
[Bug target/18686] New: #pragma longcall broken on 3.4.x
#pragma longcall (1)
extern int extfunc (void);
#pragma longcall (0)
long long
testfunc (long long a, long long b)
{
extfunc ();
return a / b;
}
results in
/src/tmp/pr12769.c:1: warning: number must be 0 or 1
/src/tmp/pr12769.c:1: warning: ignoring malformed #pragma longcall
/src/tmp/pr12769.c:4: warning: number must be 0 or 1
/src/tmp/pr12769.c:4: warning: ignoring malformed #pragma longcall
--
Summary: #pragma longcall broken on 3.4.x
Product: gcc
Version: 3.3.4
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: target
AssignedTo: amodra at bigpond dot net dot au
ReportedBy: amodra at bigpond dot net dot au
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: powerpc-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18686
[Bug target/18686] #pragma longcall broken on 3.4.x
-- What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Known to fail||3.3.4 Known to work||4.0.0 Last reconfirmed|-00-00 00:00:00 |2004-11-26 22:27:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18686
[Bug tree-optimization/17050] [4.0 Regression] Performance pessimisation as compared to GCC 3.4
--- Additional Comments From dberlin at gcc dot gnu dot org 2004-11-26 22:33 --- On my pentium-m, 3.4 gets: [EMAIL PROTECTED]:~> gcc -O3 -std=c99 coyotebench_mole.i -ffast-math -lrt -lm [EMAIL PROTECTED]:~> time ./a.out run time: 23.438668 real0m24.187s user0m23.147s sys 0m0.368s and the tree-cleanup-branch gets [EMAIL PROTECTED]:~/gcc-tcb/build/gcc> ./xgcc -B./ -std=c99 -O3 -ffast-math ~/coyotebench_mole.i -lrt -lm [EMAIL PROTECTED]:~/gcc-tcb/build/gcc> time ./a.out run time: 8.626844 real0m8.919s user0m8.803s sys 0m0.039s I haven't redone mainline yet. But it's good to know that TCB has this problem fixed, which means it will likely be gone in 4.1 if not sooner. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17050
[Bug c++/18681] [3.3/3.4/4.0 regression] template friend declaration not recognized
-- What|Removed |Added Target Milestone|--- |3.3.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18681
[Bug tree-optimization/17050] [4.0 Regression] Performance pessimisation as compared to GCC 3.4
--- Additional Comments From pcarlini at suse dot de 2004-11-26 22:48 --- Seems fixed in mainline too. On my P4-2400: 4.0.0 20041126 -- run time: 8.684465 8.810u 0.010s 0:08.86 99.5% 0+0k 0+0io 133pf+0w 3.4.3 - run time: 35.656412 36.200u 0.010s 0:36.37 99.5%0+0k 0+0io 133pf+0w -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17050
[Bug tree-optimization/18291] [4.0 Regression]: ICE in merge_alias_info
--- Additional Comments From dnovillo at gcc dot gnu dot org 2004-11-26 22:50 --- (In reply to comment #6) > Diego, if you are too busy, just let me know which you prefer and i'll implement it. > I'll take a look, but in principle it seems to me that NMT.1 and NMT.2 should actually be the same name tag. They have overlapping points-to sets, after all. I'm not sure at the moment what would be the best approach. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18291
[Bug c++/17431] [3.4/4.0 regression] Internal error: Segmentation fault (program cc1plus)
--- Additional Comments From giovannibajo at libero dot it 2004-11-26 22:50 --- Nathan, even if there is not an official committee position on the correct semantic of this program, is there way to get a patch in to stop cc1plus from segfaulting? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17431
[Bug tree-optimization/17050] [4.0 Regression] Performance pessimisation as compared to GCC 3.4
--- Additional Comments From giovannibajo at libero dot it 2004-11-26 22:51 --- Fixed then. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17050
Re: [Bug tree-optimization/18291] [4.0 Regression]: ICE in merge_alias_info
On Fri, 2004-11-26 at 22:50 +, dnovillo at gcc dot gnu dot org
wrote:
> --- Additional Comments From dnovillo at gcc dot gnu dot org 2004-11-26
> 22:50 ---
> (In reply to comment #6)
>
> > Diego, if you are too busy, just let me know which you prefer and i'll
> implement it.
> >
> I'll take a look, but in principle it seems to me that NMT.1 and NMT.2 should
> actually be the same name tag. They have overlapping points-to sets, after
> all.
> I'm not sure at the moment what would be the best approach.
>
By which, I mean:
$ cvs diff -dup tree-ssa-alias.c
Index: tree-ssa-alias.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-ssa-alias.c,v
retrieving revision 2.57
diff -d -u -p -r2.57 tree-ssa-alias.c
--- tree-ssa-alias.c25 Nov 2004 03:54:07 - 2.57
+++ tree-ssa-alias.c26 Nov 2004 22:52:46 -
@@ -771,7 +771,7 @@ create_name_tags (struct alias_info *ai)
if (qi
&& qi->pt_vars
&& qi->name_mem_tag
- && bitmap_equal_p (pi->pt_vars, qi->pt_vars))
+ && bitmap_intersect_p (pi->pt_vars, qi->pt_vars))
{
pi->name_mem_tag = qi->name_mem_tag;
break;
But that may be too pessimistic.
Diego.
[Bug tree-optimization/18291] [4.0 Regression]: ICE in merge_alias_info
--- Additional Comments From dnovillo at redhat dot com 2004-11-26 22:53
---
Subject: Re: [4.0 Regression]: ICE in
merge_alias_info
On Fri, 2004-11-26 at 22:50 +, dnovillo at gcc dot gnu dot org
wrote:
> --- Additional Comments From dnovillo at gcc dot gnu dot org 2004-11-26
> 22:50 ---
> (In reply to comment #6)
>
> > Diego, if you are too busy, just let me know which you prefer and i'll
> implement it.
> >
> I'll take a look, but in principle it seems to me that NMT.1 and NMT.2 should
> actually be the same name tag. They have overlapping points-to sets, after
> all.
> I'm not sure at the moment what would be the best approach.
>
By which, I mean:
$ cvs diff -dup tree-ssa-alias.c
Index: tree-ssa-alias.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-ssa-alias.c,v
retrieving revision 2.57
diff -d -u -p -r2.57 tree-ssa-alias.c
--- tree-ssa-alias.c25 Nov 2004 03:54:07 - 2.57
+++ tree-ssa-alias.c26 Nov 2004 22:52:46 -
@@ -771,7 +771,7 @@ create_name_tags (struct alias_info *ai)
if (qi
&& qi->pt_vars
&& qi->name_mem_tag
- && bitmap_equal_p (pi->pt_vars, qi->pt_vars))
+ && bitmap_intersect_p (pi->pt_vars, qi->pt_vars))
{
pi->name_mem_tag = qi->name_mem_tag;
break;
But that may be too pessimistic.
Diego.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18291
[Bug tree-optimization/18673] [4.0 Regression] Tree-PRE is O(N^4)
--- Additional Comments From dberlin at gcc dot gnu dot org 2004-11-26 23:00 --- Actually, Tree-PRE is provably O(n^2). We just have a larger constant than we'd like. On all the branches i have checked out (tcb, mainline) 150 loops takes 30 seconds, not 160. THis includes the constification patch i had posted, however, on these branches. I can solve this problem once and for all by using a scoped bitmap set representation instead of copying the sets around. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18673
[Bug target/18686] #pragma longcall broken on 3.4.x
--- Additional Comments From amodra at bigpond dot net dot au 2004-11-26 23:00 --- http://gcc.gnu.org/ml/gcc-patches/2004-11/msg02326.html -- What|Removed |Added Keywords||patch Known to fail|3.3.4 |3.4.3 Target Milestone|--- |3.4.4 Version|3.3.4 |3.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18686
[Bug middle-end/12769] -mlongcall doesn't convert all calls to long calls for builtin functions
--- Additional Comments From amodra at bigpond dot net dot au 2004-11-26 23:03 --- http://gcc.gnu.org/ml/gcc-patches/2004-11/msg02324.html -- What|Removed |Added Keywords||patch Known to fail||3.4.3 4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12769
[Bug middle-end/12769] -mlongcall doesn't convert all calls to long calls for builtin functions
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net |dot org |dot au Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12769
[Bug c/14635] [3.3 Regression] nan functions should not be C90 built-ins
--- Additional Comments From neroden at gcc dot gnu dot org 2004-11-26 23:07 --- This bug is fixed on mainline and 3.4.x; nan functions are not currently C90 builtins. Please open a different bug if there are other problems with nan builtin handling on mainline; meanwhile I'm marking 3.4.3 and 4.0.0 as known-to-work. I believe this is currently open solely for the 3.3.x branch? -- What|Removed |Added Known to work||3.4.3 4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14635
[Bug c++/18681] [3.3/3.4/4.0 regression] template friend declaration not recognized
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||rejects-valid Target Milestone|3.3.6 |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18681
[Bug c/14635] [3.3 Regression] nan functions should not be C90 built-ins
--- Additional Comments From joseph at codesourcery dot com 2004-11-26 23:12 --- Subject: Re: [3.3 Regression] nan functions should not be C90 built-ins On Fri, 26 Nov 2004, neroden at gcc dot gnu dot org wrote: > This bug is fixed on mainline and 3.4.x; nan functions are not currently C90 > builtins. Please open a different bug if there are other problems with nan > builtin handling on mainline; meanwhile I'm marking 3.4.3 and 4.0.0 as > known-to-work. I believe this is currently open solely for the 3.3.x branch? Yes, it's solely open for 3.3.x. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14635
[Bug tree-optimization/18572] [4.0 Regression] Bus error compiling makegpr.adb on Mac OS X 10.3
-- Bug 18572 depends on bug 18237, which changed state. Bug 18237 Summary: [4.0 regression] ICE in gen_lowpart_general, at rtlhooks.c:58 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18237 What|Old Value |New Value Status|NEW |ASSIGNED Status|ASSIGNED|NEW Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18572
[Bug rtl-optimization/18237] [4.0 regression] ICE in gen_lowpart_general, at rtlhooks.c:58
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-26 23:12 --- The orginal bug was fixed by my patch and the new bug was filed under PR 18685. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18237
[Bug c++/15674] [3.3/3.4/4.0 Regression] [DR214] template argument binding differs between member and static fumctions
--- Additional Comments From neroden at gcc dot gnu dot org 2004-11-26 23:22 --- Nathan's conclusion was that neither case was a regression (although both were wrong-code bugs). Should the "Regression" tag be removed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15674
[Bug c++/17053] [4.0 Regression] Repo functionality partially broken on AIX (collect2.c)
--- Additional Comments From neroden at gcc dot gnu dot org 2004-11-26 23:28 --- DJE said he'd develop the collect2 fix, so assigning... -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dje at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Summary|[4.0 Regression] Repo |[4.0 Regression] Repo |functionality partially |functionality partially |broken on AIX |broken on AIX (collect2.c) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17053
[Bug c++/14136] [4.0 Regression] double error message for typename used as destructor declarator
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-27 00:00 --- Any news it has been 9 months since you said you would look into it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14136
[Bug tree-optimization/17679] [4.0 Regression] Aliasing problem with ivopts
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-27 00:04 --- Then should we close this bug as fixed or at least move it from being a 4.0 regression? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17679
[Bug regression/16703] [4.0 Regression] g++ v4.0.0 produces slower code than v3.4.1 for loops.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-27 00:16 --- Fixed with the current mainline I get 1.4937 on the nestedloop test now. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16703
[Bug tree-optimization/17355] [4.0 Regression] ICE in calculate_live_on_entry, at tree-ssa-live.c:724
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-27 00:19 --- Assuming fixed so closing as I hear reports about eclipse building on running on the mainline. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17355
[Bug c++/18514] [3.4/4.0 Regression] Alternate "asm" name ignored for redeclared builtin function imported into namespace std
--- Additional Comments From neroden at gcc dot gnu dot org 2004-11-27 00:20 --- In 3.4.2 (Debian's version), I can import into *any* namespace (xxx, for instance) and get the same "problem". However, it *is* essential that the function be "snprintf", and not "bar". fancy_snprintf is invoked if gcc is invoked with -fno-builtin-snprintf. So this looks like an issue with builtins; the builtin is not being overridden by the explicit declaration. I believe this is semi-documented behavior, though I suppose it could be documented better. In 4.0.0, this indeed only happens when importing into std (otherwise fancy_snprintf is used). It still must be "snprintf" rather than, for instance, "bar", and the problem still goes away when -fno-builtin-snprintf is used. So it still seems to be a problem with builtins, but for some reason 4.0 treats importing a builtin into std differently from importing it into xxx, while 3.4 doesn't (so this bug should be hit *more* in 3.4). Resummarizing to note that this is strictly a builtin issue. -- What|Removed |Added Known to fail||3.4.2 4.0.0 Last reconfirmed|2004-11-16 04:37:01 |2004-11-27 00:20:57 date|| Summary|[3.4/4.0 Regression]|[3.4/4.0 Regression] |Alternate "asm" name ignored|Alternate "asm" name ignored |for function imported into |for redeclared builtin |namespace std |function imported into ||namespace std http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18514
[Bug rtl-optimization/17491] -fspeculative-prefetching fails on powerpc-*
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-27 00:24 --- Even though this huge failure, it is no longer a regression as -fspeculative-prefetching is not enabled wth -fprofile-generate/use but it still needs to be fixed but not necessarly for 4.0.0. Really someone should just approve Zdenek's fix for this. -- What|Removed |Added Severity|critical|normal Summary|[4.0 Regression]|-fspeculative-prefetching |profiledbootstrap fails on |fails on powerpc-* |powerpc-apple-darwin| Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17491
[Bug rtl-optimization/17428] internal compiler error: in spill_failure, at reload1.c:1880 (-fspeculative-prefetching)
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-27 00:25 --- Even though this huge failure, it is no longer a regression as -fspeculative-prefetching is not enabled wth -fprofile-generate/use but it still needs to be fixed but not necessarly for 4.0.0. Really someone should just approve Zdenek's fix for this. -- What|Removed |Added Severity|critical|normal Summary|[4.0 Regression] internal |internal compiler error: in |compiler error: in |spill_failure, at |spill_failure, at |reload1.c:1880 (- |reload1.c:1880 |fspeculative-prefetching) Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17428
[Bug tree-optimization/18673] [4.0 Regression] Tree-PRE is O(N^4)
--- Additional Comments From dberlin at gcc dot gnu dot org 2004-11-27 00:28 --- I have a patch that brings the time on 150 loops to 1.40 seconds, but i haven't decided whether to apply it or not. I have to do more testing on real code. I could make it nothing if i scoped the other bitmap tables, but tihs would probably slow down real code slightly. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dberlin at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18673
[Bug middle-end/17982] [4.0 regression] asm declaration ignored due to conflict with previous rename
--- Additional Comments From neroden at gcc dot gnu dot org 2004-11-27 00:30 --- HJ's latest patch probably doesn't fix the problem entirely :-(, but it is certainly correct to allow "renames" which don't change anything. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17982
[Bug preprocessor/16621] [4.0 Regression] C4x fails miserably
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-27 00:36 --- Any news on this bug, it has been opened for a while now (4 months) and no news about it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16621
[Bug c++/17278] [4.0 Regression] 24% C++ compile-time regression in comparison with 3.4.1 at -O1 optimization level
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-27 00:39 --- Anybody want to do new timings for typecode.ii at -O1 because I think that testcase is now fixed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17278
[Bug tree-optimization/15089] local register variable with a specified register is bad
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-27 00:44 --- Removing the regression markes but not removing the target milestone. Richard you want to add the documenation or should someone else do it? -- What|Removed |Added Severity|normal |minor Keywords|wrong-code | Summary|[3.4/4.0 Regression] [tree- |local register variable with |ssa] local register variable|a specified register is bad |with a specified register is| |bad | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15089
[Bug target/18686] #pragma longcall broken on 3.4.x
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-27 00:50 --- Subject: Bug 18686 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2004-11-27 00:50:22 Modified files: gcc: ChangeLog gcc/config/rs6000: rs6000-c.c Log message: PR target/18686 * config/rs6000/rs6000-c.c (rs6000_pragma_longcall): Use integer_zerop and integer_onep instead of comparing against canonical trees. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.705&r2=2.2326.2.706 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000-c.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.10.10.1&r2=1.10.10.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18686
[Bug target/18686] #pragma longcall broken on 3.4.x
--- Additional Comments From amodra at bigpond dot net dot au 2004-11-27 00:51 --- Fixed -- What|Removed |Added Status|ASSIGNED|RESOLVED Known to work|4.0.0 |4.0.0 3.4.4 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18686
[Bug other/7257] [3.4/4.0 regression] -O3 -fverbose-asm does not display -flag-inline-functions
--- Additional Comments From steven at gcc dot gnu dot org 2004-11-27 00:51 --- Did I mention this is fixed? -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7257
[Bug fortran/9972] [3.4 regression] Failure of g77.f-torture/execute/980520-1.f
-- Bug 9972 depends on bug 7257, which changed state. Bug 7257 Summary: [3.4/4.0 regression] -O3 -fverbose-asm does not display -flag-inline-functions http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7257 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9972
[Bug middle-end/15579] [4.0 Regression] always_inline ignored at -O0
-- Bug 15579 depends on bug 7257, which changed state. Bug 7257 Summary: [3.4/4.0 regression] -O3 -fverbose-asm does not display -flag-inline-functions http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7257 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15579
[Bug middle-end/17564] [4.0 Regression] New treatment of function pointers when used with equality operators, when casts are involved
--- Additional Comments From neroden at gcc dot gnu dot org 2004-11-27 00:53 --- I'm going to guess that one solution is to canonicalize any function pointer any time it's cast to a void pointer. (Or do you really, really want noncanonicalized pointers, which is likely to be harder?) This probably requires recognition at tree level that casts from function pointer to void pointer may be necessary (among other things). >From tree_ssa_useless_type_conversion_1 in tree_ssa.c: /* If both types are pointers and the outer type is a (void *), then the conversion is not necessary. The opposite is not true since that conversion would result in a loss of information if the equivalence was used. Consider an indirect function call where we need to know the exact type of the function to correctly implement the ABI. */ else if (POINTER_TYPE_P (inner_type) && POINTER_TYPE_P (outer_type) && TYPE_MODE (inner_type) == TYPE_MODE (outer_type) && TYPE_REF_CAN_ALIAS_ALL (inner_type) == TYPE_REF_CAN_ALIAS_ALL (outer_type) && TREE_CODE (TREE_TYPE (outer_type)) == VOID_TYPE) return true; So it seems that this type conversion isn't useless when converting from a function pointer to a void pointer (on targets where function pointers need canonicalization); it requires a canonicalization. (Or a forcing of non-canonicalization, which sounds harder.) Confirming. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-27 00:53:19 date|| Summary|[4.0 Regression] New|[4.0 Regression] New |treatment of function |treatment of function |pointers when used with |pointers when used with |equality operators |equality operators, when ||casts are involved http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17564
[Bug java/17915] [4.0 Regression] Compiling jars fails
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-27 01:02 --- I think this has been fixed by the merge of the BC branch but I have not tried it yet as I have not compiled a java compiler after. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17915
[Bug java/17963] [4.0 Regression] Compiling a .jar files fails when files within .jar are in a different order
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-27 01:03 --- I think this has been fixed by the merge of the BC branch but I have not tried it yet as I have not compiled a java compiler after. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17963
[Bug bootstrap/18107] [4.0 Regression] [meta-bug] Bootstrap fails on i686-pc-mingw32
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-27 01:05 --- Plus there is a new bootstrap failure also because of a change to use %I64 or what ever is the format is. -- What|Removed |Added Severity|normal |minor Last reconfirmed|2004-10-22 05:29:24 |2004-11-27 01:05:09 date|| Summary|[4.0 Regression] Bootstrap |[4.0 Regression] [meta-bug] |fails on i686-pc-mingw32|Bootstrap fails on i686-pc- ||mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18107
[Bug rtl-optimization/18685] [4.0 Regression] Ada boostrap broken
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-27 01:07 --- Should be fixed by: 2004-11-26 Richard Kenner <[EMAIL PROTECTED]> * expmed.c (extract_bit_field): When extracting from non-integer mode, force a SUBREG into a register because we may be taking a further SUBREG of it. Testing on ppc-darwin right now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18685
[Bug middle-end/12769] -mlongcall doesn't convert all calls to long calls for builtin functions
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-27 01:07 --- Subject: Bug 12769 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-27 01:06:59 Modified files: gcc: ChangeLog gcc/config/rs6000: rs6000.c Log message: PR target/12769 * config/rs6000/rs6000.c (init_cumulative_args): Set call_cookie from rs6000_default_long_calls for libcalls. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6579&r2=2.6580 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000.c.diff?cvsroot=gcc&r1=1.753&r2=1.754 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12769
[Bug middle-end/12769] -mlongcall doesn't convert all calls to long calls for builtin functions
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-27 01:08 --- Subject: Bug 12769 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2004-11-27 01:08:03 Modified files: gcc: ChangeLog gcc/config/rs6000: rs6000.c Log message: PR target/12769 * config/rs6000/rs6000.c (init_cumulative_args): Set call_cookie from rs6000_default_long_calls for libcalls. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.706&r2=2.2326.2.707 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.576.2.34&r2=1.576.2.35 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12769
