[Bug rtl-optimization/21527] New: BYTEmark bitmap test: Regression with Profiled Optimization
Another follow-on bug similar to bug 21485. The profiled optimizer on both 3.4.3 and 4.0.0 makes code worse than without it. Run times go up by 50% or more. Relevant flags are: -static -O3 -march=athlon-xp -fomit-frame-pointer This runs a fixed number of iterations; time from the command line to compare. This is probably an interesting bug on its own, or at least I hope so. However, what I originally discovered with the real BYTEmark code was that 3.4.3's profiled optimizer made the code better, but 4.0.0's made it worse. Somehow, in the process of combining things into one file and removing redundant code, 3.4.3's profiled optimizer started pessimizing the code as well. Let me know if I should attempt to reproduce that behavior again (though I might not be able to come up with the single-preprocessed-file testcase for that). -- Summary: BYTEmark bitmap test: Regression with Profiled Optimization Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jbucata at tulsaconnect dot com CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21527
[Bug rtl-optimization/21527] BYTEmark bitmap test: Regression with Profiled Optimization
--- Additional Comments From jbucata at tulsaconnect dot com 2005-05-12 07:39 --- Created an attachment (id=8869) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8869&action=view) preprocessed test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21527
[Bug java/17845] [4.1 Regression] More problems with simple type names as superclasses
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-05-12
08:09 ---
This code in do_resolve_class seems bogus to me. Fixing it removes the failure.
Note that java.security is in the package_list because of Dummy.java, but it
absolutely does *not* belong in the search path!
This is the only use of package_list, by the way.
/* 5- Try with a name qualified with the package names we've seen so far */
if (!QUALIFIED_P (TYPE_NAME (class_type)))
{
tree package;
/* If there is a current package (ctxp->package), it's the first
element of package_list and we can skip it. */
for (package = (ctxp->package ?
TREE_CHAIN (package_list) : package_list);
package; package = TREE_CHAIN (package))
if ((new_class_decl = qualify_and_find (class_type,
TREE_PURPOSE (package),
TYPE_NAME (class_type
return new_class_decl;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17845
[Bug target/21314] C++ size and performance regression with -Os
--- Additional Comments From dann at godzilla dot ics dot uci dot edu 2005-05-12 08:09 --- (In reply to comment #6) > hmm. code size is actually bigger with -Os. > > -rwxr-xr-x 1 dirtyepic users 15689 May 1 12:02 pr21314-O0 > -rwxr-xr-x 1 dirtyepic users 8333 May 1 12:02 pr21314-O1 > -rwxr-xr-x 1 dirtyepic users 8405 May 1 11:35 pr21314-O2 > -rwxr-xr-x 1 dirtyepic users 8157 May 1 12:03 pr21314-O3 > -rwxr-xr-x 1 dirtyepic users 12989 May 1 11:35 pr21314-Os Don't look at the sizes shown by 'ls -l' look at the text size (as shown by size -f) You can also use 'nm' to see the size of the main function (all the interesting code is in there, right?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21314
[Bug libgcj/21285] gij fails to handle NullPointerException exception
--- Additional Comments From tsv at solvo dot ru 2005-05-12 08:25 --- Your patch works a lot better than mine. Just tested and ant started to work. Thank you very much. -- What|Removed |Added Severity|normal |critical Component|libffi |libgcj http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21285
[Bug fortran/20876] error needed
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-12 08:27 --- This one currently segfaults. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-12 08:27:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20876
[Bug fortran/20877] result may not be entry
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-12 08:29 --- J cannot be used twice in this code. Right now, gfortran has an ICE on this one: $ gfortran a.f90 In file a.f90:4 ENTRY J() 1 Internal Error at (1): insert_bbt(): Duplicate key found! -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-12 08:29:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20877
[Bug fortran/20880] error needed
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-12 08:32 --- Confirmed. Lahey says "line 11: Interface block which is use associated by this USE statement containing an interface body for procedure 'my_sub' defined by this subprogram is not standard-conforming." -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-12 08:32:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20880
[Bug fortran/20882] error needed
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-12 08:33 --- Confirmed. Intel says: line 10: This object must not be used as the pointer-object or target of a pointer-assignment-stmt in a PURE procedure or an internal procedure contained in a PURE procedure. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-12 08:33:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20882
[Bug c++/21528] New: Boost shared_ptr_test.cpp fails with -O3
The following portion of shared_ptr_test.cpp:
#include
#include
int main()
{
boost::shared_ptr pi(new int);
boost::shared_ptr pv(pi);
boost::shared_ptr pi2 = boost::static_pointer_cast(pv);
BOOST_TEST(pi.get() == pi2.get());
BOOST_TEST(!(pi < pi2 || pi2 < pi));
BOOST_TEST(pi.use_count() == 3);
BOOST_TEST(pv.use_count() == 3);
BOOST_TEST(pi2.use_count() == 3);
return boost::report_errors();
}
(using the current Boost CVS HEAD that will become 1.33 soon) fails the three
use_count() tests with g++ 4.0.0 -O3, but not with -O0, 1, 2. It seems that a
reference count increment is being optimized away. This does not happen if
BOOST_TEST is replaced with assert.
--
Summary: Boost shared_ptr_test.cpp fails with -O3
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pdimov at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21528
[Bug c++/21528] Boost shared_ptr_test.cpp fails with -O3
--- Additional Comments From pdimov at gmail dot com 2005-05-12 08:42 --- Created an attachment (id=8871) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8871&action=view) Preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21528
[Bug c++/21528] Boost shared_ptr_test.cpp fails with -O3
-- What|Removed |Added CC||redi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21528
[Bug target/21518] [4.0/4.1 Regression] error: unable to find a register to spill in class 'Q_REGS' with -fPIC and -O2
--- Additional Comments From jakub at gcc dot gnu dot org 2005-05-12 08:59 --- Using regparm(3) with -fPIC is a really bad idea. i386 has 4 Q_REGS class registers, 3 of them are used for regparm(3) (%eax, %edx, %ecx) and the last one for PIC pointer (%ebx), so reload really has hard time to satisfy this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21518
[Bug c++/21528] Boost shared_ptr_test.cpp fails with -O3
--- Additional Comments From redi at gcc dot gnu dot org 2005-05-12 09:12 --- I can confirm this error for 4.0 on x86 and x86-64 but not with 4.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21528
[Bug c++/21528] Boost shared_ptr_test.cpp fails with -O3
--- Additional Comments From redi at gcc dot gnu dot org 2005-05-12 09:36 --- -O2 -finline-functions shows the errors, -O3 -fno-inline-functions does not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21528
[Bug libstdc++/21526] libstdc++-v3 testsuite hangs on cygwin
--- Additional Comments From pcarlini at suse dot de 2005-05-12 09:41
---
Hum, this problem appear to imply that something is not completely ok
with the recent try_mkfifo -> dg-require-mkfifo switch. If I understand
correctly, before the latter we effectively skipped at runtime this test
on cygwin (and mingw):
int
try_mkfifo (const char* filename, mode_t mode)
{
#if defined (_NEWLIB_VERSION) || defined (__MINGW32_VERSION)
/* Newlib and MinGW32 do not have mkfifo. */
exit(0);
#else
return mkfifo(filename, mode);
#endif
}
Now the compile-type DejaGNU check *enables* the test... Mark?
--
What|Removed |Added
CC||mmitchel at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21526
[Bug c/21529] New: code size regression (+40%) with -Os from GCC-3.4.3 to 4.1
Compiling this code with -Os is more than 40 % bigger in size with GCC-4.1
compared to GCC-3.4.3.
See also thread: http://gcc.gnu.org/ml/gcc/2005-05/msg00532.html
struct disk_interface_str {
unsignednb_IDE_found;
struct IDE_found_str {
unsigned short ideIOadr;
unsigned short ideIOctrladr;
unsigned char irq;
unsigned char bios_order;
unsigned short reserved;
} *IDE_found;
} DI;
void reorder_IDE_for_linux (void)
{
static const unsigned short idearray[] = {
0x1F0, 0x170,
0x1E8, 0x168,
0x1E0, 0x160,
};
unsigned short cpt, order;
for (order = 0; order < sizeof(idearray)/sizeof(idearray[0]); order++) {
for (cpt = order + 1; cpt < DI.nb_IDE_found; cpt++)
if (DI.IDE_found[cpt].ideIOadr == idearray[order])
break;
if (cpt < DI.nb_IDE_found) {
struct IDE_found_str save = DI.IDE_found[cpt];
unsigned short i;
for (i = order; i < cpt; i++) {
struct IDE_found_str tmp = DI.IDE_found[i];
DI.IDE_found[i] = save;
save = tmp;
}
DI.IDE_found[cpt] = save;
}
}
}
--
Summary: code size regression (+40%) with -Os from GCC-3.4.3 to
4.1
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: etienne_lorrain at yahoo dot fr
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i486-pc-linux-gnu
GCC host triplet: i486-pc-linux-gnu
GCC target triplet: i486-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21529
[Bug c++/21510] Possible bug
--- Additional Comments From sven at clio dot in-berlin dot de 2005-05-12 09:48 --- (In reply to comment #1) > I don't think you used SFINF correctly. The substitution of the formal parameter with the actual argument fails, thus it is a form of substitution failure. I do not know, if the example is conforming to the standard. It would be a working method to distinguish between classes and non classes. On the other hand the more stricter interpretation is more safe. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21510
[Bug libstdc++/21526] libstdc++-v3 testsuite hangs on cygwin
--- Additional Comments From pcarlini at suse dot de 2005-05-12 10:02 --- In other terms, we should tell DejaGNU that all the tests involving fifos must be skipped on such platform, because fifos are available but not completely ok. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21526
[Bug c++/21447] internal compiler error: output_operand
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-05-12 10:14 ---
(In reply to comment #4)
The patch for 21275 failed to take care of C++ class members which "inherit" a
dllimport attribute from the class type definition.
Here is a C++ testcase:
struct __attribute__ ((dllimport)) Foo
{
static int bar (void);
};
typedef int(*foobar)(void);
foobar my_foobar = (foobar) &Foo::bar;
int my_bar()
{
return my_foobar();
}
The code that marks Foo::bar as NON_ADDR_CONSTANT_P in winnt.c happens too
late.
I have a more invasive patch that fixes C and C++, replacing NON_ADDR_CONST_P
with a target hook (dll-supporting targets are currently the only ones that set
the tree_decl.non_addr_const_p flag). I'll submit as soon as I can access a
machine that will build and regtest Java on mingw.
Danny
--
What|Removed |Added
CC||dannysmith at users dot
||sourceforge dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21447
[Bug tree-optimization/21520] missing PRE opportunity with operand after operand
--- Additional Comments From steven at gcc dot gnu dot org 2005-05-12
10:23 ---
The failure I mentioned in comment #7 is caused by remove_dead_inserted_code,
which removes the statement setting that SSA name:
In the .pre dump file:
Removing unnecessary insertion:pretmp.308_35 = (unsigned char *)pretmp.307_36;
And the ICE message:
error: Missing definition for SSA_NAME: pretmp.308_35 in statement:
That remove_dead_inserted_code passlet doesn't work very well anyway, for
the original test case we also have dead code in the .pre dump:
do_locator1 (call)
{
int prephitmp.4;
int pretmp.3;
char prephitmp.2;
char pretmp.1;
int type;
char D.1566;
int D.1565;
:
if (call_3 != 0B) goto ; else goto ;
:;
goto ();
:;
type_7 = *call_3;
pretmp.1_2 = (char) type_7;
pretmp.3_10 = (int) pretmp.1_2;
# prephitmp.4_11 = PHI <1(3), pretmp.3_10(1)>;
# prephitmp.2_9 = PHI <1(3), pretmp.1_2(1)>;
# type_1 = PHI <1(3), type_7(1)>;
:;
D.1566_4 = prephitmp.2_9;
D.1565_5 = prephitmp.4_11;
return D.1565_5;
}
It may be better to just not have this ad-hoc DCE and move a real DCE pass
up in the pass schedule -- something like this:
Index: tree-optimize.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-optimize.c,v
retrieving revision 2.90
diff -u -3 -p -r2.90 tree-optimize.c
--- tree-optimize.c 11 May 2005 02:24:42 - 2.90
+++ tree-optimize.c 12 May 2005 09:09:53 -
@@ -405,10 +405,10 @@ init_tree_optimization_passes (void)
NEXT_PASS (pass_split_crit_edges);
NEXT_PASS (pass_pre);
NEXT_PASS (pass_sink_code);
+ NEXT_PASS (pass_dce);
NEXT_PASS (pass_loop);
NEXT_PASS (pass_dominator);
NEXT_PASS (pass_copy_prop);
- NEXT_PASS (pass_dce);
/* FIXME: If DCE is not run before checking for uninitialized uses,
we may get false warnings (e.g., testsuite/gcc.dg/uninit-5.c).
However, this also causes us to misdiagnose cases that should be
@@ -418,8 +418,8 @@ init_tree_optimization_passes (void)
account for the predicates protecting the set and the use of each
variable. Using a representation like Gated Single Assignment
may help. */
- NEXT_PASS (pass_late_warn_uninitialized);
NEXT_PASS (pass_cd_dce);
+ NEXT_PASS (pass_late_warn_uninitialized);
NEXT_PASS (pass_dse);
NEXT_PASS (pass_forwprop);
NEXT_PASS (pass_phiopt);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21520
[Bug target/21501] [4.1 regression] ICE in extract_insn, at recog.c:2082
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-12 10:36 --- Subject: Bug 21501 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-12 10:36:15 Modified files: gcc: ChangeLog gcc/config/arm : arm.c Log message: PR target/21501 * arm.c (arm_gen_constant): Sign-extend intermediate values when synthesizing a constant of the difference of two immediates. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8743&r2=2.8744 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/arm/arm.c.diff?cvsroot=gcc&r1=1.456&r2=1.457 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21501
[Bug c/21529] code size regression (+40%) with -Os from GCC-3.4.3 to 4.1
--- Additional Comments From steven at gcc dot gnu dot org 2005-05-12 10:39 --- Yada yada yada, you know the drill. SRA, out-of-ssa, and register allocation all working against each other: :; D.1605 = DI.IDE_found + (struct IDE_found_str *) ((long unsigned int) i * 8); tmp$reserved = D.1605->reserved; tmp$bios_order = D.1605->bios_order; tmp$irq = D.1605->irq; tmp$ideIOctrladr = D.1605->ideIOctrladr; tmp$ideIOadr = D.1605->ideIOadr; D.1605->reserved = save$reserved; D.1605->bios_order = save$bios_order; D.1605->irq = save$irq; D.1605->ideIOctrladr = save$ideIOctrladr; D.1605->ideIOadr = save$ideIOadr; i = i + 1; save$reserved = tmp$reserved; save$bios_order = tmp$bios_order; save$irq = tmp$irq; save$ideIOctrladr = tmp$ideIOctrladr; save$ideIOadr = tmp$ideIOadr; Wouldn't a block move be more efficient here than moving things one-by-one? -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ra Last reconfirmed|-00-00 00:00:00 |2005-05-12 10:39:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21529
[Bug target/21501] [4.1 regression] ICE in extract_insn, at recog.c:2082
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-05-12 10:40 --- Now fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21501
[Bug libstdc++/21530] New: libstdc++ not supported on this target
libstdc++ is not supported on h8300-hitachi-hms, so main configure should
skip it (as it does for h8500-*-*), otherwise sub-configure will bail out later.
Suggested patch:
--- gcc-3.4.3/configure
+++ gcc-3.4.3/configure
@@ -1232,7 +1232,7 @@
noconfigdirs="$noconfigdirs ${libgcj}"
;;
h8300*-*-*)
-noconfigdirs="$noconfigdirs target-libgloss ${libgcj} target-libf2c"
+noconfigdirs="$noconfigdirs target-libstdc++-v3 target-libgloss ${libgcj}
target-libf2c"
;;
h8500-*-*)
noconfigdirs="$noconfigdirs target-libstdc++-v3 target-libgloss ${libgcj}
target-libf2c"
--
Summary: libstdc++ not supported on this target
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at mailinator dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux
GCC host triplet: i686-pc-linux
GCC target triplet: h8300-hitachi-hms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21530
[Bug tree-optimization/21531] New: 4.0/4.1 Regression __builtin_expect
GNU C - maybe related to my bugreport 21513 but different.
Error:
src/aie_sql_meta.c: In Funktion aie_sql_meta_create_index:
src/aie_sql_meta.c:258: Warnung: tableid koennte in dieser Funktion
uninitialisiert verwendet werden
src/aie_sql_meta.c:259: Warnung: index_typ koennte in dieser Funktion
uninitialisiert verwendet werden
make: *** [obj/aie_sql_meta.o] Fehler 1
int tableid;
int index_typ;
could be unitilized in this function. It can but if not it's not used.
Difference to GCC 3.4.3. It is set but within another function. The function
itself resides in the same sourcefile so imo gcc would be able to figure out
that they are either initilized or not used. Especially when compiled with the
compiler switch -funit-at-a-time . btw if the initialisation would be in another
C sourcefile then the warning is ok imo because the compiler cannot know the
content - as tody - of two sourcefiles at the same time.
The function is to create a SQL Index out of a predefined structure. The two
variables are set within the function aie_sql_meta_get_index_def_from_id - see
below.
The function it is as follows:
bool aie_sql_meta_create_index(int indexid, struct aie_sql_meta_db
*aie_sql_meta_db)
{
bool rc = true;
const char *index_name = aie_sql_meta_get_index_name_from_id(indexid,
aie_sql_meta_db);
if (__builtin_expect((index_name != NULL),true))
{
unsigned int size_index_def = 0;
int tableid;
int index_typ;
struct aie_sql_index_def *index_def =
aie_sql_meta_get_index_def_from_id(indexid, &tableid, &index_typ,
&size_index_def,
aie_sql_meta_db);
if (__builtin_expect(((index_def == NULL) ||
(size_index_def <= 0) ||
(tableid <= 0)),false))
{
sys_log("%s(%d):Fehler Meta SQL Table Def Create index "
"IndexID[%d] index [%s] TableID[%d]!",
__FILE__,
__LINE__,
indexid,
index_name,
tableid);
rc = false;
}
else
{
const char *table_name = aie_sql_meta_get_table_name_from_id(tableid,
aie_sql_meta_db);
if (__builtin_expect((table_name != NULL),true))
{
if (__builtin_expect(
(!aie_sql_create_index(aie_sql_meta_db->aie_sql_data,
table_name,
index_name,
index_typ,
true,
index_def,
size_index_def)),false))
{
sys_log("%s(%d):Fehler Meta SQL Create index "
"IndexID[%d] index [%s] Tableid[%d]!",
__FILE__,
__LINE__,
indexid,
index_name,
tableid);
rc = false;
}
}
else
{
sys_log("%s(%d):Fehler Meta SQL Create index Table nicht gefunden "
"IndexID[%d] index [%s] Tableid[%d]!",
__FILE__,
__LINE__,
indexid,
index_name,
tableid);
rc = false;
}
}
}
else
{
sys_log("%s(%d): Create Table ID[%d] Table ID nicht gefunden!",
__FILE__,
__LINE__,
indexid);
rc = false;
}
return(rc);
}
struct aie_sql_index_def *aie_sql_meta_get_index_def_from_id(int indexid,
int *tableid,
[Bug target/21518] unable to find a register to spill in class 'Q_REGS' with -fPIC and -O2
--- Additional Comments From steven at gcc dot gnu dot org 2005-05-12 10:59 --- Andrew's test case shows that it is easy to make this fail with other GCC releases, and Jakub's comment #3 it seems that when constructs like this work, it only does so by luck. So, this is not really a regression, and it is also not really going to be fixed in GCC. -- What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX Summary|[4.0/4.1 Regression] error: |unable to find a register to |unable to find a register to|spill in class 'Q_REGS' with |spill in class 'Q_REGS' with|-fPIC and -O2 |-fPIC and -O2 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21518
[Bug rtl-optimization/20972] [4.0/4.1 Regression] Can't describe an early-clobber by an auto-inc
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-05-12 11:36 --- The ARM ARM says that STR Rd, [Rn], #4 and STR Rd, [Rn, #4]! are unpredictable if Rd == Rn. That is, the auto-inc side effect is permitted to take place before Rd is read. There's currently no way for a back-end to describe that an auto-inc operation might be an early-clobber. The obvious '&<>' in the constraint doesn't work, causing an abort in find_reloads(). This bug isn't really a regression (the limitation has always been there), but the vagaries of register allocation means that it is only recently that it's started doing this (either that, or the assembler has only recently started whining about it :-). -- What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org Component|target |rtl-optimization Last reconfirmed|2005-04-12 17:08:16 |2005-05-12 11:36:06 date|| Summary|[4.0/4.1 Regression]|[4.0/4.1 Regression] Can't |Compiler-generated code |describe an early-clobber by |produces an assembler |an auto-inc |warning | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20972
[Bug c/21529] code size regression (+40%) with -Os from GCC-3.4.3 to 4.1
--- Additional Comments From giovannibajo at libero dot it 2005-05-12 11:48 --- Maybe SRA could be tuned differently for -Os. RTH, do you think it is feasable, or is it only a register allocator problem and should not be handled at the tree level at all? -- What|Removed |Added CC||rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21529
[Bug libffi/21285] gij fails to handle NullPointerException exception
-- What|Removed |Added Severity|critical|normal Component|libgcj |libffi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21285
[Bug c++/21528] Boost shared_ptr_test.cpp fails with -O3
--- Additional Comments From redi at gcc dot gnu dot org 2005-05-12 11:56 --- Using 4.0.1 20050509 on x86-64 Linux -O2 -finline-functions -finline-limit=79 is OK -O2 -finline-functions -finline-limit=80 is not -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21528
[Bug target/21518] [4.0/4.1 Regression] unable to find a register to spill in class 'Q_REGS' with -fPIC and -O2
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 12:00 --- But the orginal code did not have regparm so we should not be changing the function to regparm 3 then. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | Summary|unable to find a register to|[4.0/4.1 Regression] unable |spill in class 'Q_REGS' with|to find a register to spill |-fPIC and -O2 |in class 'Q_REGS' with -fPIC ||and -O2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21518
[Bug target/21518] [4.0/4.1 Regression] unable to find a register to spill in class 'Q_REGS' with -fPIC and -O2
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 12:02 --- The code around: /* We can't use regparm(3) for nested functions as these use static chain pointer in third argument. */ if (DECL_CONTEXT (decl) && !DECL_NO_STATIC_CHAIN (decl)) regparm = 2; else regparm = 3; should be changed to take -fPIC into effect. -- What|Removed |Added Status|REOPENED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21518
[Bug tree-optimization/21531] 4.0/4.1 Regression __builtin_expect
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 12:12 --- Can you attached the preprocessed source code (The only reason why I did not ask for PR 21513 is because I figured out to compile it and reproduce it without it). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21531
[Bug bootstrap/21230] [4.0/4.1 Regression] bootstrap failed unless bootstrap compiler is gcc.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-12 12:22 --- Subject: Bug 21230 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-12 12:22:09 Modified files: config : ChangeLog warnings.m4 libcpp : ChangeLog configure Log message: config/ PR bootstrap/21230 * warnings.m4 (ACX_PROG_CC_WARNING_ALMOST_PEDANTIC): Add double quotes around GCC variable. libcpp/ PR bootstrap/21230 * configure: Regenerate. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/config/ChangeLog.diff?cvsroot=gcc&r1=1.64&r2=1.65 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/config/warnings.m4.diff?cvsroot=gcc&r1=1.2&r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libcpp/ChangeLog.diff?cvsroot=gcc&r1=1.69&r2=1.70 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libcpp/configure.diff?cvsroot=gcc&r1=1.15&r2=1.16 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21230
[Bug c++/21528] Boost shared_ptr_test.cpp fails with -O3
--- Additional Comments From redi at gcc dot gnu dot org 2005-05-12 12:22
---
Also, I *do* still see the failure if I replace BOOST_TEST() with assert().
This still fails with -finline-functions -finline-limit=80
#include
#include
int main()
{
boost::shared_ptr pi(new int);
boost::shared_ptr pv(pi);
boost::shared_ptr pi2 = boost::static_pointer_cast(pv);
assert(pi.get() == pi2.get());
assert(pi.use_count() == 3); // fails here
return 0;
}
*however* if I remove the first assertion it succeeds.
--
What|Removed |Added
Known to fail||4.0.0 4.0.1
Known to work||3.4.3 4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21528
[Bug bootstrap/21230] [4.0/4.1 Regression] bootstrap failed unless bootstrap compiler is gcc.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-12 12:24 --- Subject: Bug 21230 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-12 12:24:15 Modified files: config : ChangeLog warnings.m4 libcpp : ChangeLog configure Log message: config/ PR bootstrap/21230 * warnings.m4 (ACX_PROG_CC_WARNING_ALMOST_PEDANTIC): Add doubles quotes around GCC variable. libcpp/ PR bootstrap/21230 * configure: Regenerate. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/config/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.59.8.2&r2=1.59.8.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/config/warnings.m4.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.2&r2=1.2.10.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libcpp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.56.2.7&r2=1.56.2.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libcpp/configure.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.13.6.2&r2=1.13.6.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21230
[Bug bootstrap/21230] [4.0/4.1 Regression] bootstrap failed unless bootstrap compiler is gcc.
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-12 12:27 --- See http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01116.html -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21230
[Bug middle-end/21528] Boost shared_ptr_test.cpp fails with -O3
-- What|Removed |Added Component|c++ |middle-end Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21528
[Bug middle-end/21528] Boost shared_ptr_test.cpp fails with -O3
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 13:17 --- Hmm, -fno-sra works around the issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21528
[Bug middle-end/21528] [4.0 Regression] Boost shared_ptr_test.cpp fails with -O3
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 13:28 --- Hmm, I am starting to think there is an alias bug in 4.0.0 somewhere. -- What|Removed |Added Summary|Boost shared_ptr_test.cpp |[4.0 Regression] Boost |fails with -O3 |shared_ptr_test.cpp fails ||with -O3 Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21528
[Bug middle-end/21528] [4.0 Regression] Boost shared_ptr_test.cpp fails with -O3
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 13:35 --- The difference between the mainline and the 4.0.0 branch is the following additional SRA in 4.0.x: +Initial instantiation for pv + pv.pn.pi_ -> pv$pn$pi_ + pv.px -> pv$px +Initial instantiation for pi2 + pi2.pn.pi_ -> pi2$pn$pi_ + pi2.px -> pi2$px + -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21528
[Bug middle-end/21528] [4.0 Regression] Boost shared_ptr_test.cpp fails with -O3
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 13:38 --- Also the other major difference is: mainline: - # pi_503 = V_MAY_DEF ; - pi.pn.pi_ = this_45; 4.0.0: + # TMT.242_3 = V_MAY_DEF ; + pi.pn.pi_ = this_99; See how we used a TMT in 4.0.0 case and pi on the mainline. -- What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21528
[Bug middle-end/21529] [4.0/4.1 Regression] code size regression (+40%) with -Os from GCC-3.4.3 to 4.1
-- What|Removed |Added Known to fail||4.0.0 4.1.0 Known to work||3.4.3 Summary|code size regression (+40%) |[4.0/4.1 Regression] code |with -Os from GCC-3.4.3 to |size regression (+40%) with |4.1 |-Os from GCC-3.4.3 to 4.1 Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21529
[Bug java/17845] [4.1 Regression] More problems with simple type names as superclasses
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-05-12 14:10 --- Not fixing the hunk -- removing it actually! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17845
[Bug target/14563] new/delete much slower than malloc/free because of sjlj exceptions
-- What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14563
[Bug target/14563] new/delete much slower than malloc/free because of sjlj exceptions
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 14:54 --- If you used the non throw new, it would become faster. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14563
[Bug middle-end/21474] missed optimizations when comparing address to NULL
--- Additional Comments From trt at acm dot org 2005-05-12 15:08 --- I think it is reasonable to assume the address of an auto variable is non-NULL, and so the address of anything in the local "int x[10];" is non-NULL. So gcc can (and does) fold "if (x) ..." and "if (&x[0]) ..." gcc does not fold "if (&x[3]) ..." due to the the quirk that that it is represented as x+3 and fold does not recognize that to be non-NULL. Now consider "if (&x[i])". The only legal values for i are 0..10, which precludes any value of `i' that might cause &x[i] to be NULL. I suppose if x were a pointer, instead of an array, then we wouldn't know the legal range of values for `i'. But whatever the legal range happens to be would still (I think) preclude values which could cause &x[i] to be NULL. The argument for 'if (&p->b[3])' is more convoluted. Suppose p is non-NULL, then surely this address should be considered non-NULL for basically the same reason that &x[3] above is considered to be non-NULL. Suppose instead that p is NULL, then surely a non-zero offset added to p yields a non-NULL value. That leaves "if (&p->a)" which gcc folds even though a's offset is zero. I think this is arguably a bug. But if no one reports it as a bug ... well I think this one could be argued either way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21474
[Bug libstdc++/21526] libstdc++-v3 testsuite hangs on cygwin
--- Additional Comments From mark at codesourcery dot com 2005-05-12 15:15
---
Subject: Re: libstdc++-v3 testsuite hangs on cygwin
pcarlini at suse dot de wrote:
> --- Additional Comments From pcarlini at suse dot de 2005-05-12 10:02
> ---
> In other terms, we should tell DejaGNU that all the tests involving fifos must
> be skipped on such platform, because fifos are available but not completely
> ok.
Sorry; I assumed Cygwin must not have mkfifo, given that the test was
disabled there; I didn't consider has-mkfifo-but-broken!
The fix for this will be to modify target-supports.exp to check the
platform as well.
If you change check_mkfifo_available in target-supports.exp to do:
proc check_mkfifo_available {} {
if {[istarget *-*-cygwin*]} {
# Cygwin has mkfifo, but support is incomplete.
return 0
}
return [check_function_available "mkfifo"]
}
that should fix it. Would you mind trying that?
Thanks,
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21526
[Bug libstdc++/21526] libstdc++-v3 testsuite hangs on cygwin
--- Additional Comments From pcarlini at suse dot de 2005-05-12 15:23 --- Thanks a lot Mark. At this point, since your suggestion is complete as-is, I would ask David to try it himself. Then, if everything goes well on cygwin (which I don't have) I will take care of regtesting it on x86-linux too, and so on. Thanks again. -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21526
[Bug tree-optimization/21532] New: ICE caused by PRE dead instruction removal
The attached unreduced testcase from glibc generates an ICE using today's CVS. The only necessary option is -O2. regcomp.c: In function 'build_equiv_class': regcomp.c:3462: error: Missing definition for SSA_NAME: pretmp.2916_545 in statement: D.26795_433 = () pretmp.2916_545; regcomp.c:3462: internal compiler error: verify_ssa failed. -- Summary: ICE caused by PRE dead instruction removal Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: drow at gcc dot gnu dot org CC: dberlin at gcc dot gnu dot org,gcc-bugs at gcc dot gnu dot org,pinskia at gcc dot gnu dot org,stevenb at suse dot de GCC target triplet: arm-none-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21532
[Bug tree-optimization/21532] ICE caused by PRE dead instruction removal
--- Additional Comments From drow at gcc dot gnu dot org 2005-05-12 15:31 --- Created an attachment (id=8873) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8873&action=view) Testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21532
[Bug libstdc++/21526] libstdc++-v3 testsuite hangs on cygwin
--- Additional Comments From mark at codesourcery dot com 2005-05-12 15:32 --- Subject: Re: libstdc++-v3 testsuite hangs on cygwin pcarlini at suse dot de wrote: > --- Additional Comments From pcarlini at suse dot de 2005-05-12 15:23 > --- > Thanks a lot Mark. At this point, since your suggestion is complete as-is, > I would ask David to try it himself. Then, if everything goes well on > cygwin (which I don't have) I will take care of regtesting it on x86-linux > too, and so on. Thanks again. If you don't have time to do that, it's certainly my responsibility. Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21526
[Bug tree-optimization/21532] ICE caused by PRE dead instruction removal
-- What|Removed |Added OtherBugsDependingO||21520 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-12 15:35:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21532
[Bug tree-optimization/21532] ICE caused by PRE dead instruction removal
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dberlin at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-05-12 15:35:29 |2005-05-12 15:46:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21532
Internal compiler error in finish_function gcc version 2.96
Command:
gcc bug.cpp
Output (indented):
bug.cpp: In function `int _ ()':
bug.cpp:1: parse error before `0'
bug.cpp:1: Internal error #122.
bug.cpp:1: Internal compiler error in finish_function, at
../gcc/cp/decl.c:14422
Please submit a full bug report.
See http://www.gnu.org/software/gcc/bugs.html> for instructions.
Version:
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 2731 (Red Hat Linux 7.0)
File bug.cpp (also attached):
int _() {if 0 -> {};}
Yours,
Mark Weyer
int _() {if 0 -> {};}
Re: Internal compiler error in finish_function gcc version 2.96
Mark Weyer <[EMAIL PROTECTED]> wrote:
> Command:
>
> gcc bug.cpp
>
> Output (indented):
>
> bug.cpp: In function `int _ ()':
> bug.cpp:1: parse error before `0'
> bug.cpp:1: Internal error #122.
> bug.cpp:1: Internal compiler error in finish_function, at
> ../gcc/cp/decl.c:14422
> Please submit a full bug report.
> See http://www.gnu.org/software/gcc/bugs.html> for instructions.
>
> Version:
>
> Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
> gcc version 2.96 2731 (Red Hat Linux 7.0)
Thank you, but gcc 2.96 is not even an official FSF version of GCC.
Moreover, GCC 2.x is totally unsupported at this point, since already 3-4
years at least. You should try updating to a newer GCC version, like the
stable 3.4.4 (to be released in a few days), or the brand new GCC 4.0.0.
With GCC 3.4.3, I get this error trying to compile bug.cc:
bug.cc: In function `int _()':
bug.cc:1: error: expected `(' before numeric constant
--
Giovanni Bajo
[Bug tree-optimization/21532] ICE caused by PRE dead instruction removal
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-12 17:11 --- Subject: Bug 21532 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-12 17:11:20 Modified files: gcc: ChangeLog tree-ssa-pre.c Log message: 2005-05-12 Daniel Berlin <[EMAIL PROTECTED]> Fix PR tree-optimization/21532 * tree-ssa-pre.c (create_expression_by_pieces): stmt needs to go onto the inserted_exprs list. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8746&r2=2.8747 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-pre.c.diff?cvsroot=gcc&r1=2.84&r2=2.85 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21532
[Bug rtl-optimization/15513] loop peeling failed becuase of non-constant start
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 17:36 --- Actually this is a dup of bug 10624. *** This bug has been marked as a duplicate of 10624 *** -- What|Removed |Added Status|SUSPENDED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15513
[Bug rtl-optimization/10624] unroll-loops can't unroll nested constant loops
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 17:36 --- *** Bug 15513 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||kunert at physik dot tu- ||dresden dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10624
[Bug rtl-optimization/16541] code quality issue for bit manipulations with 64bit
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 17:40 --- Looks like a register allocation issue. -- What|Removed |Added Keywords||ra http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16541
[Bug c/21533] New: C99 array of variable length use causes segmentation fault
Platform: Linux GCC x86. I have generated a test case where the code I have using a C99 array with variable length causes a segmentation fault. The thing is, if I comment out an unrelated line of code that is impossible to be executed and not in the execution pathway (it's in the body of an if statement that can not be executed because of the conditional anyway and added to that, I put a return 0; in front of the line of code so if it did happen to get in there, it would return before executing the line of code) the segmentation fault does not happen. Also, if I don't do that, but I do comment out an unused automatic variable defined in the main() function (which calls the test function), the segmentation fault does not happen. The test code is ~40 lines long and contains all the temporary files requested, the version information, and a more detailed explanation of how to reproduce the segmentation fault. This is all in a tar.gz file that you can get from http://www.sinistershane.net/~shane/files/testcase.tar.gz The segv appears in both x86_64 and x86 (32bit) executables. -- Summary: C99 array of variable length use causes segmentation fault Product: gcc Version: 3.3.4 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: shane256 at hotmail dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21533
[Bug tree-optimization/17272] Extra store emitted when concatenating inline assembly sections.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 17:43 --- I mean on the setting side of the inline-asm. Otherwise we have a ra issue. -- What|Removed |Added Component|rtl-optimization|tree-optimization Keywords||ra Last reconfirmed|2005-03-03 02:54:36 |2005-05-12 17:43:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17272
[Bug c++/21515] problem with template and template function compilation in a namespace
-- What|Removed |Added Summary|problem with tempalte and |problem with template and |tempalte function |template function |compilation in a namespace |compilation in a namespace http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21515
[Bug c++/21515] problem with template and template function compilation in a namespace
--- Additional Comments From bangerth at dealii dot org 2005-05-12 17:49
---
You can't do this:
template
std::ostream & std::operator<< (std::ostream &, a::A const &);
If you want to overload something in namespace std, you have to open that
namespace, put the declaration in it, and close it again. If you do this
everything is fine, i.e. like so:
namespace std
{
template
ostream & operator<< (ostream &, a::A const &);
}
The fact that we don't reject the declaration is a bug in gcc in itself,
for which I'll open a PR in a minute.
W.
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21515
[Bug libfortran/21324] #undef GFC_CLEAR_MEMORY causes testsuite failures
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-12 17:50 --- Subject: Bug 21324 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-12 17:50:35 Modified files: libgfortran: ChangeLog libgfortran/io : open.c unit.c unix.c libgfortran/runtime: memory.c Log message: 2005-05-12 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/21324 * runtime/memory.c: Don't define GFC_CLEAR_MEMORY (it's a performance hog). * io/open.c (new_unit): Zero freshly allocated memory for unit structure. * io/unit.c (init_units): Zero freshly allocated memory for STDIN, STDOUT and STDERR. * io/unix.c (open_internal): Zero freshly allocated memory for unix_stream. (fd_to_stream): Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&r1=1.214&r2=1.215 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/open.c.diff?cvsroot=gcc&r1=1.13&r2=1.14 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/unit.c.diff?cvsroot=gcc&r1=1.8&r2=1.9 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/unix.c.diff?cvsroot=gcc&r1=1.24&r2=1.25 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/runtime/memory.c.diff?cvsroot=gcc&r1=1.6&r2=1.7 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21324
[Bug target/21412] ICE loading TLS address
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-12 17:50 --- Subject: Bug 21412 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-12 17:50:26 Modified files: gcc: ChangeLog gcc/config/ia64: ia64-protos.h ia64.c ia64.h ia64.md predicates.md Log message: PR target/21412 * config/ia64/ia64.c (TARGET_CANNOT_FORCE_CONST_MEM): New. (ia64_cannot_force_const_mem): New. (tls_symbolic_operand_type): New. (ia64_legitimate_constant_p): New. (ia64_expand_load_address): Return true on success. Improve checks for when we should not split. (ia64_expand_tls_address): New addend operand. Distribute it as appropriate to the tls_kind. Delay referencing gp. (ia64_expand_move): Split symbolic addend as necessary. Handle tls symbols with addends. * config/ia64/ia64-protos.h: Update. * config/ia64/ia64.h (CALL_REALLY_USED_REGISTERS): False for r0, p0, f0, f1, and r13. (LEGITIMATE_CONSTANT_P): Move to ia64_legitimate_constant_p. * config/ia64/ia64.md (UNSPEC_DTPMOD): New. (symbolic_operand splitter): Pass everything through ia64_expand_load_address and FAIL or DONE as appropriate. (load_fptr): Only accept after reload. (load_fptr_internal1, gprel64_offset, load_gprel64, load_symptr_high, load_symptr_low, load_ltoff_dtpmod, (load_dtpmod): New. (load_dtprel): Only accept tls symbols. (load_dtprel64, load_dtprel22): Likewise. (load_tprel, load_tprel64, load_tprel22): Likewise. (load_dtprel_gd, load_ltoff_dtprel, load_tprel_ie): New. (add_dtprel): Only accept tls symbols. Canonicalize PLUS. (add_dtprel14, add_dtprel22): Likewise. (add_tprel, add_tprel14, add_tprel22): Likewise. * config/ia64/predicates.md (small_addr_symbolic_operand): New. (any_offset_symbol_operand, aligned_offset_symbol_operand): New. (got_symbolic_operand): Check CONST offsets. (tls_symbolic_operand, ld_tls_symbolic_operand): New. (ie_tls_symbolic_operand, le_tls_symbolic_operand): New. (move_operand): Don't handle tls here. Check CONST offsets. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.241&r2=2.7592.2.242 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64-protos.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.70&r2=1.70.8.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.347.2.4&r2=1.347.2.5 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.193&r2=1.193.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64.md.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.146.8.2&r2=1.146.8.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/predicates.md.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5&r2=1.5.10.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21412
[Bug c++/21534] New: Declaration in wrong namespace not rejected
This code isn't rejected, though it should be:
namespace NS
{
template void f();
}
template void NS::f (int);
---
It _is_ rejected if NS::f is not a template.
FWIW, icc says this to the snippet:
tmp/y> icc -Xc -ansi -c x.cc
x.cc(6): error: function template "NS::f" may not be redeclared in the current
scope
template void NS::f (int);
^
W.
--
Summary: Declaration in wrong namespace not rejected
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at dealii dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21534
[Bug rtl-optimization/17935] Two consecutive movzbl are generated
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 17:52 --- With the patch for PR 21520, we will get better code. Right now on the mainline we get: bar: movl4(%esp), %eax testb $1, (%eax) jne .L7 movl8(%esp), %eax movb(%eax), %al andl$1, %eax xorl$1, %eax movzbl %al, %eax ret .p2align 2,,3 .L7: xorl%eax, %eax movzbl %al, %eax ret but after that patch we should be able to remove the extra movzbl in the second branch. -- What|Removed |Added BugsThisDependsOn||21520 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17935
[Bug libstdc++/21523] [3.4/4.0 Regression] 3.4.4 RC1 fails libstdc++ install on powerpc64-linux
-- What|Removed |Added Priority|P2 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21523
[Bug c++/21534] Declaration in wrong namespace not rejected
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 17:55 --- Confirmed, I thought I saw something like this before (and not in PR 21515). -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Known to fail||2.95.3 3.0.4 3.2.3 3.3.3 ||3.4.0 4.0.0 4.1.0 Last reconfirmed|-00-00 00:00:00 |2005-05-12 17:55:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21534
[Bug c/21535] New: Empty inline assembly cause the generated code to be wrong?
Two C file (p.c and q.c) attached bellows. With an inline assembly
line (even just a comment), the code sequence is different. As a
result, the function foo() in q.c is working OK but not the foo()
in p.c.
*** Command line ***
$ /utils/gcc/3.4.3/mipsel-linux-uclibc/i386/bin/mipsel-linux-gcc -v
Reading specs from
/utils/gcc/3.4.3/mipsel-linux-uclibc/i386/lib/gcc/mipsel-linux-uclibc/3.4.3/specs
Configured with:
/home/YH/MIPS/BR/buildroot/toolchain_build_mipsel/gcc-3.4.3/configure
--prefix=/utils/gcc/3.4.3/mipsel-linux-uclibc/i386 --build=i386-pc-linux-gnu
--host=i386-pc-linux-gnu --target=mipsel-linux-uclibc --enable-languages=c,c++
--enable-shared --disable-__cxa_atexit --enable-target-optspace --with-gnu-ld
--disable-nls --enable-multilib --enable-sjlj-exceptions
Thread model: posix
gcc version 3.4.3
$ /utils/gcc/3.4.3/mipsel-linux-uclibc/i386/bin/mipsel-linux-gcc -mno-abicalls
-O2 -c -o p.o p.c
$ /utils/gcc/3.4.3/mipsel-linux-uclibc/i386/bin/mipsel-linux-objdump -S p.o >
p.dasm
$ /utils/gcc/3.4.3/mipsel-linux-uclibc/i386/bin/mipsel-linux-gcc -mno-abicalls
-O2 -c -o q.o q.c
$ /utils/gcc/3.4.3/mipsel-linux-uclibc/i386/bin/mipsel-linux-objdump -S q.o >
q.dasm
p.c
int foo(int x, int y, int z)
{
__asm__ __volatile__ ("/* TEST */\n");
return((x + y) / z);
}
end of p.c
q.c
int foo(int x, int y, int z)
{
// __asm__ __volatile__ ("/* TEST */\n");
return((x + y) / z);
}
end of q.c
> with the inline assembly (p.dasm)
p.o: file format elf32-tradlittlemips
Disassembly of section .text:
:
0: 00851021adduv0,a0,a1
4: 14c2bneza2,10
8: 0046001adiv zero,v0,a2
c: 0007000dbreak 0x7
10: 1012mflov0
14: 03e8jr ra
18: nop
1c: nop
> without the inline assembly (q.dasm)
q.o: file format elf32-tradlittlemips
Disassembly of section .text:
:
0: 00851021adduv0,a0,a1
4: 0046001adiv zero,v0,a2
8: 14c2bneza2,14
c: nop
10: 0007000dbreak 0x7
14: 1012mflov0
18: 03e8jr ra
1c: nop
> assembly file (p.s)
.file 1 "p.c"
.section .mdebug.abi32
.previous
.text
.align 2
.globl foo
.entfoo
.type foo, @function
foo:
.frame $sp,0,$31 # vars= 0, regs= 0/0, args= 0, gp= 0
.mask 0x,0
.fmask 0x,0
#APP
/* TEST */
#NO_APP
addu$2,$4,$5
div $0,$2,$6
bne $6,$0,1f
break 7
1:
mflo$2
j $31
.endfoo
.ident "GCC: (GNU) 3.4.3"
> assembly file (q.s)
.file 1 "q.c"
.section .mdebug.abi32
.previous
.text
.align 2
.globl foo
.entfoo
.type foo, @function
foo:
.frame $sp,0,$31 # vars= 0, regs= 0/0, args= 0, gp= 0
.mask 0x,0
.fmask 0x,0
.setnoreorder
.setnomacro
addu$2,$4,$5
div $0,$2,$6
bne $6,$0,1f
nop
break 7
1:
mflo$2
j $31
nop
.setmacro
.setreorder
.endfoo
.ident "GCC: (GNU) 3.4.3"
--
Summary: Empty inline assembly cause the generated code to be
wrong?
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yhlin at sdesigns dot com
CC: gcc-bugs at gcc dot gnu dot org,yhlin at sdesigns dot
com
GCC build triplet: i686-pc-linux
GCC host triplet: i686-pc-linux
GCC target triplet: mipsel-linux-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21535
[Bug target/21412] ICE loading TLS address
--- Additional Comments From rth at gcc dot gnu dot org 2005-05-12 17:56 --- ia64 fixed; sparc still broken. But I'm not planning to work on that. -- What|Removed |Added AssignedTo|rth at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW GCC target triplet|ia64-*-*, sparc*-*-*|sparc*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21412
[Bug c/21536] New: C99 array of variable length use causes segmentation fault
Platform: Linux GCC x86. I have generated a test case where the code I have using a C99 array with variable length causes a segmentation fault. The thing is, if I comment out an unrelated line of code that is impossible to be executed and not in the execution pathway (it's in the body of an if statement that can not be executed because of the conditional anyway and added to that, I put a return 0; in front of the line of code so if it did happen to get in there, it would return before executing the line of code) the segmentation fault does not happen. Also, if I don't do that, but I do comment out an unused automatic variable defined in the main() function (which calls the test function), the segmentation fault does not happen. The test code is ~40 lines long and contains all the temporary files requested, the version information, and a more detailed explanation of how to reproduce the segmentation fault. This is all in a tar.gz file that you can get from http://www.sinistershane.net/~shane/files/testcase.tar.gz The segv appears in both x86_64 and x86 (32bit) executables. -- Summary: C99 array of variable length use causes segmentation fault Product: gcc Version: 3.3.4 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: shane256 at hotmail dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21536
[Bug c/21536] C99 array of variable length use causes segmentation fault
--- Additional Comments From shane256 at hotmail dot com 2005-05-12 18:05 --- Created an attachment (id=8874) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8874&action=view) Contains test case code, intermediate files, etc. demonstrating the issue -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21536
[Bug c/21536] C99 array of variable length use causes segmentation fault
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 18:06 --- *** Bug 21533 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21536
[Bug c/21533] C99 array of variable length use causes segmentation fault
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 18:06 --- *** This bug has been marked as a duplicate of 21536 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21533
[Bug libstdc++/21523] [3.4/4.0 Regression] 3.4.4 RC1 fails libstdc++ install on powerpc64-linux
--- Additional Comments From mark at codesourcery dot com 2005-05-12 18:06
---
Subject: Re: New: 3.4.4 RC1 fails libstdc++ install
on powerpc64-linux
Janis --
Would you please try the attached patch for 3.4? I have a similar patch
for 4.0 which I will attach soon.
If this doesn't work, I'm going to revert my previous backport, so as to
avoid holding up 3.4.4.
Thanks,
2005-05-12 Mark Mitchell <[EMAIL PROTECTED]>
2005-04-04 Mark Mitchell <[EMAIL PROTECTED]>
* testsuite/Makefile.am (check-local): Remove.
(curent_symbols.txt): Likewise.
(check-abi): Do not depend on current_symbols.txt.
* testsuite/Makefile.in: Regenerated.
* testsuite/libstdc++-abi/abi.exp: Build current_symbols.txt.
2005-04-01 Mark Mitchell <[EMAIL PROTECTED]>
* testsuite/Makefile.am (noinst_PROGRAMS): Remove.
(site.exp): Write out the path to the baseline file.
(check-abi): Use DejaGNU.
(check-abi-verbose): Remove.
* testsuite/Makefile.in: Regenerated.
* testsuite/abi_check.cc (main): Check the return value from
compare_symbols.
* testsuite/testsuite_abi.cc (compare_symbols): Return a value.
* testsuite/testsuite_abi.h (compare_symbols): Adjust prototype.
* testsuite/libstdc++-abi/abi.exp: New file.
2004-03-19 Phil Edwards <[EMAIL PROTECTED]>
* testsuite/Makefile.am (site.exp): New target, based on that
created by automake. Also set libiconv.
Index: testsuite/Makefile.am
===
RCS file: /cvs/gcc/gcc/libstdc++-v3/testsuite/Makefile.am,v
retrieving revision 1.33.4.3
diff -c -5 -p -r1.33.4.3 Makefile.am
*** testsuite/Makefile.am 15 May 2004 20:44:13 - 1.33.4.3
--- testsuite/Makefile.am 12 May 2005 17:22:43 -
*** noinst_LIBRARIES = libv3test.a
*** 46,64
libv3test_a_SOURCES = \
testsuite_abi.cc \
testsuite_allocator.cc \
testsuite_hooks.cc
- ## Build support utilities.
- if GLIBCXX_TEST_ABI
- noinst_PROGRAMS = abi_check
- else
- noinst_PROGRAMS =
- endif
- abi_check_SOURCES = abi_check.cc
- abi_check_DEPENDENCIES = libv3test.a
-
all-local: stamp_wchar testsuite_files
# Enable wchar_t tests if capable.
if GLIBCXX_TEST_WCHAR_T
stamp_wchar:
--- 46,55
*** lists_of_files = \
*** 76,85
--- 67,103
# This is automatically run after the generated check-DEJAGNU rule.
check-local: check-abi
+ # We need more things in site.exp, but automake completely controls the
+ # creation of that file; there's no way to append to it without messing up
+ # the dependancy chains. So we overrule automake. This rule is exactly
+ # what it would have generated, plus our own additions.
+ site.exp: Makefile
+ @echo 'Making a new site.exp file...'
+ @echo '## these variables are automatically generated by make ##'
>site.tmp
+ @echo '# Do not edit here. If you wish to override these values'
>>site.tmp
+ @echo '# edit the last section' >>site.tmp
+ @echo 'set srcdir $(srcdir)' >>site.tmp
+ @echo "set objdir `pwd`" >>site.tmp
+ @echo 'set build_alias "$(build_alias)"' >>site.tmp
+ @echo 'set build_triplet $(build_triplet)' >>site.tmp
+ @echo 'set host_alias "$(host_alias)"' >>site.tmp
+ @echo 'set host_triplet $(host_triplet)' >>site.tmp
+ @echo 'set target_alias "$(target_alias)"' >>site.tmp
+ @echo 'set target_triplet $(target_triplet)' >>site.tmp
+ @echo 'set target_triplet $(target_triplet)' >>site.tmp
+ @echo 'set libiconv "$(LIBICONV)"' >>site.tmp
+ @echo 'set baseline_file "$(baseline_file)"' >> site.tmp
+ @echo '## All variables above are generated by configure. Do Not Edit
##' >>site.tmp
+ @test ! -f site.exp || \
+ sed '1,/^## All variables above are.*##/ d' site.exp >> site.tmp
+ @-rm -f site.bak
+ @test ! -f site.exp || mv site.exp site.bak
+ @mv site.tmp site.exp
+
baseline_file = ${baseline_dir}/baseline_symbols.txt
extract_symvers = $(glibcxx_srcdir)/scripts/extract_symvers
current_symbols.txt: ${extract_symvers} ../src/.libs/libstdc++.so
-@(${extract_symvers} ../src/.libs/libstdc++.so current_symbols.txt)
*** new-abi-baseline:
*** 103,125
${extract_symvers} ../src/.libs/libstdc++.so $${output})
if GLIBCXX_TEST_ABI
# Use 'new-abi-baseline' to create an initial symbol file. Then run
# 'check-abi' to test for changes against that file.
! check-abi: abi_check baseline_symbols current_symbols.txt
! [EMAIL PROTECTED]/abi_check --check ./current_symbols.txt
${baseline_file} \
! 2>&1 | tee libstdc++-abi.sum
! [EMAIL PROTECTED] libstdc++-abi.sum libstdc++-abi.log
!
! check-abi-verbose: abi_check baseline_symbols current_symbols.txt
! [EMAIL PROTECTED]/abi_check --check-verbose ./current
[Bug c/21536] [3.4/4.0/4.1 Regression] C99 array of variable length use causes segmentation fault
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 18:07 --- Confirmed, I really thought I saw this before. Anyways this is a regression from 2.95.3. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||wrong-code Known to fail||3.0.4 3.2.3 3.2.2 3.3.3 ||3.4.0 4.0.0 Known to work||2.95.3 Last reconfirmed|-00-00 00:00:00 |2005-05-12 18:07:43 date|| Summary|C99 array of variable length|[3.4/4.0/4.1 Regression] C99 |use causes segmentation |array of variable length use |fault |causes segmentation fault Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21536
[Bug target/21535] Empty inline assembly cause the generated code to be wrong?
-- What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21535
[Bug libgcj/21524] Cancelling a TimerTask puts Timer binary heap in inconsistent state
--- Additional Comments From jradel at 2wire dot com 2005-05-12 18:32 --- (From update of attachment 8868) Ignore this first proposed fix... it's buggy. Working on a new version. -- What|Removed |Added Attachment #8868 is|0 |1 obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21524
[Bug rtl-optimization/20211] autoincrement generation is poor
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 18:59 --- The only change is the following: before: bzip2-1.0.2,compress,9408 bzip2-1.0.2,decompress,10604 after: bzip2-1.0.2,compress,9428 bzip2-1.0.2,decompress,10640 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211
[Bug libfortran/21324] #undef GFC_CLEAR_MEMORY causes testsuite failures
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-12 19:11 --- Subject: Bug 21324 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-12 19:10:59 Modified files: libgfortran: ChangeLog libgfortran/io : open.c unit.c unix.c libgfortran/runtime: memory.c Log message: 2005-05-12 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/21324 * runtime/memory.c: Don't define GFC_CLEAR_MEMORY (it's a performance hog). * io/open.c (new_unit): Zero freshly allocated memory for unit structure. * io/unit.c (init_units): Zero freshly allocated memory for STDIN, STDOUT and STDERR. * io/unix.c (open_internal): Zero freshly allocated memory for unix_stream. (fd_to_stream): Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.163.2.28&r2=1.163.2.29 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/open.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.10.10.3&r2=1.10.10.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/unit.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.8&r2=1.8.10.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/unix.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.21.10.3&r2=1.21.10.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/runtime/memory.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.6&r2=1.6.12.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21324
[Bug libfortran/21324] #undef GFC_CLEAR_MEMORY causes testsuite failures
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-05-12 19:12 --- Fixed in mainline and 4.0. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21324
[Bug libstdc++/21523] [3.4/4.0 Regression] 3.4.4 RC1 fails libstdc++ install on powerpc64-linux
--- Additional Comments From janis187 at us dot ibm dot com 2005-05-12 19:25 --- Subject: Re: [3.4/4.0 Regression] 3.4.4 RC1 fails libstdc++ install on powerpc64-linux > Would you please try the attached patch for 3.4? I have a similar patch > for 4.0 which I will attach soon. With GCC 3.4.4 RC1 the following on an 8-proc powerpc64-linux system: $src/configure --enable-languages=c++ ... make -j 8 bootstrap make install failed without the patch, succeeded with the patch. I'm running the same thing again for good measure and then will build all languages (except Ada) and run the testsuites. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21523
[Bug c++/21537] New: A templatized struct's member function can't call another templatized struct's templatized member function
In the following code, one templatized struct's member function calls another
templatized struct's templatized member function. GCC 3.3.3 reports a parse
error in the line labeled "This doesn't work!". I've found that if I change the
instantiation of struct inner to use an 'int' rather than 'T', GCC will
compile. Is this correct behavior, or is it a GCC bug?
= CODE FOLLOWS =
template
struct inner
{
template void test() { }
};
template
struct outer
{
void go()
{
//inner ().test(); // This works!
inner ().test(); // This doesn't work!
}
};
= END OF CODE =
--
Summary: A templatized struct's member function can't call
another templatized struct's templatized member function
Product: gcc
Version: 3.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrstephengross at hotmail dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21537
[Bug rtl-optimization/20211] autoincrement generation is poor
--- Additional Comments From joern dot rennecke at st dot com 2005-05-12 19:30 --- Subject: Re: autoincrement generation is poor pinskia at gcc dot gnu dot org wrote: >--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 >18:59 --- >The only change is the following: >before: >bzip2-1.0.2,compress,9408 >bzip2-1.0.2,decompress,10604 >after: >bzip2-1.0.2,compress,9428 >bzip2-1.0.2,decompress,10640 > > > Well, there were also lots of small changes. As said before, if you add it all up, the net difference is just four bytes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211
[Bug c++/21537] A templatized struct's member function can't call another templatized struct's templatized member function
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 19:32 --- This is correct. You need: inner ().template test(); -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21537
[Bug tree-optimization/21538] New: [4.0/4.1 Regression] g++.dg/opt/temp1.C execution test fails
FAIL: g++.dg/opt/temp1.C execution test has appeared on mainline between 20050511 and 20050512 on multiple targets. In <http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01158.html> Jakub Jelinek notes it appears on 4.0 branch as well and blames > 2005-04-28 Richard Guenther <[EMAIL PROTECTED]> > > * fold-const.c (fold_indirect_ref_1): Avoid removing > NOP_EXPRs with type qualifiers like const. -- Summary: [4.0/4.1 Regression] g++.dg/opt/temp1.C execution test fails Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org,jakub at gcc dot gnu dot org,rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21538
[Bug middle-end/21538] [4.0/4.1 Regression] g++.dg/opt/temp1.C execution test fails
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 19:57 --- CCing Mark as he wrote the code to fix this testcase in the first place. -- What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org Component|tree-optimization |middle-end Keywords||missed-optimization Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21538
[Bug tree-optimization/21539] New: [4.1 Regression] gcc.dg/tree-ssa/ltrans-5.c fails
FAIL: gcc.dg/tree-ssa/ltrans-5.c scan-tree-dump-times Linear expression:
constant: 1 invariants: denominator: 1 1
FAIL: gcc.dg/tree-ssa/ltrans-5.c scan-tree-dump-times transformed loop 1
have appeared on mainline between 20050511 and 20050512 on platforms including
at least i686-pc-linux-gnu and hppa{2.0w,64}-hp-hpux11.{11,23}. gcc-testresults
shows other platforms as well.
--
Summary: [4.1 Regression] gcc.dg/tree-ssa/ltrans-5.c fails
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsm28 at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21539
[Bug java/21540] New: switch stmt problem
Compiling the attached results in: [EMAIL PROTECTED] tmp]$ gcj -C bug.java bug.java: In class 'bug': bug.java: In method 'bug.fn(int)': bug.java:9: error: Constant expression required. case ((int) xxx >>> 32): ^ 1 error -- Summary: switch stmt problem Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: green at redhat dot com CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21540
[Bug java/21540] switch stmt problem
--- Additional Comments From green at redhat dot com 2005-05-12 20:03 --- Created an attachment (id=8880) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8880&action=view) Test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21540
[Bug tree-optimization/21541] New: [4.1 Regression] gcc.c-torture/execute/20031215-1.c compilation fails
FAIL: gcc.c-torture/execute/20031215-1.c compilation, -O2
FAIL: gcc.c-torture/execute/20031215-1.c compilation, -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/20031215-1.c compilation, -O3 -g
FAIL: gcc.c-torture/execute/20031215-1.c compilation, -Os
UNRESOLVED: gcc.c-torture/execute/20031215-1.c execution, -O2
UNRESOLVED: gcc.c-torture/execute/20031215-1.c execution, -O3
-fomit-frame-pointer
UNRESOLVED: gcc.c-torture/execute/20031215-1.c execution, -O3 -g
UNRESOLVED: gcc.c-torture/execute/20031215-1.c execution, -Os
have appeared on mainline between 20050511 and 20050512 on platforms including
at least i686-pc-linux-gnu and hppa{2.0w,64}-hp-hpux11.{11,23}. gcc-testresults
shows other platforms as well.
/home/gcc/nightlies/src-mainline-2005-05-12/gcc-mainline-2005-05-12/gcc/testsuite/gcc.c-torture/execute/20031215-1.c:
In function 'test1':
/home/gcc/nightlies/src-mainline-2005-05-12/gcc-mainline-2005-05-12/gcc/testsuite/gcc.c-torture/execute/20031215-1.c:11:
error: Statement makes a memory store, but has no V_MAY_DEFS nor V_MUST_DEFS
# VUSE ;
ao.ch[2] = 0;
/home/gcc/nightlies/src-mainline-2005-05-12/gcc-mainline-2005-05-12/gcc/testsuite/gcc.c-torture/execute/20031215-1.c:11:
internal compiler error: verify_ssa failed.
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
--
Summary: [4.1 Regression] gcc.c-torture/execute/20031215-1.c
compilation fails
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsm28 at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21541
[Bug debug/20967] g++ generates same DW_AT_ranges info for two different functions
--- Additional Comments From wilson at gcc dot gnu dot org 2005-05-12 20:37 --- Created an attachment (id=8881) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8881&action=view) Emit DW_AT_call_file and DW_AT_call_line for inlined subroutines. -- What|Removed |Added Attachment #8760 is|0 |1 obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20967
[Bug java/21540] switch stmt problem
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12
21:49 ---
Confirmed, here is another example:
public class bug
{
public static final long xxx = 555;
public static final int xxx1 = (int)(xxx >>> 32);
public int fn (int v)
{
switch (v)
{
case (xxx1):
return 1;
}
return 0;
}
}
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Keywords||rejects-valid
Known to fail||3.0.4 3.2.3 3.2.2 3.3.3
||3.4.0 4.0.0 4.1.0
Last reconfirmed|-00-00 00:00:00 |2005-05-12 21:49:59
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21540
[Bug testsuite/21539] [4.1 Regression] gcc.dg/tree-ssa/ltrans-5.c fails
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 21:51 --- The testcase is wrong and should be removed. -- What|Removed |Added Status|UNCONFIRMED |NEW Component|tree-optimization |testsuite Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-12 21:51:19 date|| Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21539
[Bug tree-optimization/21541] [4.1 Regression] gcc.c-torture/execute/20031215-1.c compilation fails
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 21:57 --- This is why I hate the type system of GCC and what is consider compatible and such for the tree optimizers -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2005-05-12 21:57:33 date|| Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21541
[Bug middle-end/21538] [4.0/4.1 Regression] g++.dg/opt/temp1.C execution test fails
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 21:59 --- Confirmed, though I think the testcase is wrong though if we use memcpy before main. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-12 21:59:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21538
[Bug tree-optimization/21520] missing PRE opportunity with operand after operand
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-12 22:13 --- Subject: Bug 21520 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-12 22:13:00 Modified files: gcc: ChangeLog tree-ssa-pre.c Added files: gcc/testsuite/gcc.c-torture/compile: pr21532.c Log message: Fix PR tree-optimization/21520 * tree-ssa-pre.c (phi_translate): Use fully_constant_expression to attempt to fold constants. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8751&r2=2.8752 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-pre.c.diff?cvsroot=gcc&r1=2.85&r2=2.86 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/pr21532.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21520
