[Bug c++/26698] [4.0/4.1/4.2/4.3 Regression] g++ accepts const-incorrect code due to conversion function
--- Comment #14 from simartin at gcc dot gnu dot org 2007-10-13 06:05 --- Subject: Bug 26698 Author: simartin Date: Sat Oct 13 06:04:57 2007 New Revision: 129282 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129282 Log: gcc/cp/ 2007-10-13 Simon Martin [EMAIL PROTECTED] PR c++/26698 * call.c (build_user_type_conversion_1): Do not consider conversion functions to convert a (possibly cv-qualified) object to the (possibly cv-qualified) same object type (or a reference to it), to a (possibly cv-qualified) base class of that type (or a reference to it). gcc/testsuite/ 2007-10-13 Simon Martin [EMAIL PROTECTED] PR c++/26698 * g++.dg/conversion/op4.C: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/conversion/op4.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/call.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26698
[Bug c++/26698] [4.0/4.1/4.2/4.3 Regression] g++ accepts const-incorrect code due to conversion function
--- Comment #15 from simartin at gcc dot gnu dot org 2007-10-13 06:17 --- Fixed on all the active branches. -- simartin at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26698
[Bug c++/33754] Default argument of type list pair A, B compiles only when typedef is used
--- Comment #2 from photon at seznam dot cz 2007-10-13 08:24 --- (In reply to comment #1) *** This bug has been marked as a duplicate of 57 *** I should note this bug is suspended. This is because the standard is unclear at what is the correct behavior. See DR 325 for all the details. I vote for this to be fixed in GCC, especially since the standard is unclear. The compiler has the knowledge 'pair' is a template class. MS C++ accepts the syntax and does not violate any standards by doing so. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33754
[Bug c++/33754] Default argument of type list pair A, B compiles only when typedef is used
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-10-13 08:54 --- (In reply to comment #2) I vote for this to be fixed in GCC, especially since the standard is unclear. The compiler has the knowledge 'pair' is a template class. MS C++ accepts the syntax and does not violate any standards by doing so. Actually the standard says this is invalid, just it was not the intention of committee that is to be invalid which is why there is defect report against the C++ standard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33754
[Bug target/33755] Gcc 4.2.2 broken for mips linux kernel builds
--- Comment #9 from rsandifo at gcc dot gnu dot org 2007-10-13 10:47 --- The problem comes from dbr_schedule, although it's not really a bug there. We have: bne $5,$0,L1# A ...stuff... L1: bne $5,$0,L2# B ...printk call... L2: and nothing before dbr_schedule has managed to thread A to L2. dbr_schedule first fills B's delay slot with an lui from the printk block, then steal_delay_list_from_target realises that A can steal B's delay slot and branch directly to L2. There is no other path to L1, so the rest of the printk call is now dead. For most targets, this is at worst a missed optimisation; we should have threaded A to L2 much earlier than dbr_schedule, and deleted the whole printk block as dead. I don't think the MIPS port can rely on that happening for correctness. So (alas!) I think the upshot is simply that we need to add some special code to mips_reorg to delete high-part relocations that have no matching lows. I'll have a poke. -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rsandifo at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-10-13 10:47:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33755
[Bug fortran/33760] New: Bind(C): Using C_PTR as structure constructor gives an ICE
gfortran crashes if one uses cptr = C_PTR(p+1) Here, C_PTR is a structure constructor; this usage is invalid Fortran 2003 (as type(C_PTR) has PRIVATE components according to the Fortran 2003 standard); NAG f95 therefore diagnoses: Error: Components of structure constructor 'c_ptr' at (1) are PRIVATE gfortran allows currently to access the private components to allow to print the pointer address as in print *, cptr (For -std=f2003, this gives the expected error because of the private components. However, for C_PTR(..) -std=f2003 does not help.) Valgrind: ==15961== Invalid read of size 8 ==15961==at 0x49F466: gfc_conv_expr (trans-expr.c:3316) ==15961==by 0x49FB9C: gfc_trans_assignment_1 (trans-expr.c:4075) ==15961==by 0x49FDAC: gfc_trans_assignment (trans-expr.c:4222) ==15961==by 0x482E67: gfc_trans_code (trans.c:993) ==15961==by 0x498669: gfc_generate_function_code (trans-decl.c:3307) ==15961==by 0x45462B: gfc_parse_file (parse.c:3384) Test program, found at http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/0ea1d42c43b6d54a/ program main use ISO_C_BINDING implicit none integer(C_INTPTR_T) p type(C_PTR) cptr p = 0 cptr = C_PTR(p+1) end program main -- Summary: Bind(C): Using C_PTR as structure constructor gives an ICE Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33760
[Bug target/33761] New: non-optimal inlining heuristics pessimizes gzip SPEC score at -O3
The measurements were actually done on gzip-1.2.4 sources on core2-d with: a) gcc -mtune=generic -m32 -O2 b) gcc -mtune=generic -m32 -O3 The testfile was created as the tar archive of current SVN trunk repository, which currently accounts for 865M uncompressed. profile of a) % cumulative self self total time seconds secondscalls s/call s/call name 54.63 14.7614.76 102254750 0.00 0.00 longest_match 18.47 19.75 4.991 4.9927.02 deflate 10.25 22.52 2.7727389 0.00 0.00 fill_window 6.81 24.36 1.8427390 0.00 0.00 updcrc 3.15 25.21 0.85 5901 0.00 0.00 compress_block 2.85 25.98 0.77 203123663 0.00 0.00 send_bits 2.66 26.70 0.72 89123566 0.00 0.00 ct_tally 0.67 26.88 0.18 3378994 0.00 0.00 pqdownheap 0.22 26.94 0.0617709 0.00 0.00 build_tree 0.15 26.98 0.0411802 0.00 0.00 send_tree 0.07 27.00 0.02 1367732 0.00 0.00 bi_reverse 0.07 27.02 0.0217710 0.00 0.00 gen_codes 0.00 27.02 0.0027390 0.00 0.00 file_read profile of b) % cumulative self self total time seconds secondscalls s/call s/call name 86.86 29.3529.35129.3533.79 deflate 5.27 31.13 1.7827390 0.00 0.00 updcrc 2.69 32.04 0.91 5901 0.00 0.00 compress_block 2.55 32.90 0.86 89123566 0.00 0.00 ct_tally 2.04 33.59 0.69 203123663 0.00 0.00 send_bits 0.44 33.74 0.1517709 0.00 0.00 build_tree 0.06 33.76 0.02 1367732 0.00 0.00 bi_reverse 0.06 33.78 0.02 5903 0.00 0.00 flush_block 0.03 33.79 0.0111802 0.00 0.00 send_tree 0.00 33.79 0.0027390 0.00 0.00 file_read 0.00 33.79 0.00 9237 0.00 0.00 flush_outbuf 0.00 33.79 0.002 0.00 0.00 basename 0.00 33.79 0.002 0.00 0.00 copy_block 0.00 33.79 0.001 0.00 0.00 add_envopt As can be seen from profiles, longest_match was inlined into deflate. Adding __attribute__((noinline)) to longest_match prototype, we obtain: % cumulative self self total time seconds secondscalls s/call s/call name 55.80 13.8613.86 102254750 0.00 0.00 longest_match 27.62 20.72 6.861 6.8624.84 deflate 7.09 22.48 1.7627390 0.00 0.00 updcrc 3.74 23.41 0.93 5901 0.00 0.00 compress_block 2.62 24.06 0.65 89123566 0.00 0.00 ct_tally 2.42 24.66 0.60 203123663 0.00 0.00 send_bits 0.56 24.80 0.1417709 0.00 0.00 build_tree 0.08 24.82 0.02 1367732 0.00 0.00 bi_reverse 0.08 24.84 0.0211802 0.00 0.00 send_tree 0.00 24.84 0.0027390 0.00 0.00 file_read 0.00 24.84 0.00 9237 0.00 0.00 flush_outbuf 0.00 24.84 0.00 5903 0.00 0.00 flush_block 0.00 24.84 0.002 0.00 0.00 basename 0.00 24.84 0.002 0.00 0.00 copy_block or ~26.5% improvement. I speculate that inlining increases register pressure on SMALL_REGISTER_CLASS target, as this problem is not that noticeable on x86_64. The results of 32bit run are at [1] (valid from 13. oct) and results of 64bit run at [2]. [1] http://vmakarov.fedorapeople.org/spec/spec2000.toolbox_32/gcc/individual-run-ratio.html [2] http://vmakarov.fedorapeople.org/spec/spec2000.toolbox/gcc/individual-run-ratio.html -- Summary: non-optimal inlining heuristics pessimizes gzip SPEC score at -O3 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ubizjak at gmail dot com GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33761
[Bug target/33761] non-optimal inlining heuristics pessimizes gzip SPEC score at -O3
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-10-13 12:31 --- I suppose that alias partitioning makes the difference instead. This is not really a fault of the inliner but our dumb memory optimizers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33761
[Bug fortran/33745] -fbounds-check: Bogus out-of-bounds run-time error for assumed-size array
--- Comment #3 from burnus at gcc dot gnu dot org 2007-10-13 14:34 --- (In reply to comment #2) The wrong-code bug is fixed by the followed patch. Actually, it is not. The problem is - both in the compile time and at the run time bound checking - the combination of element vs. array range. Results using current gfortran (w/o wrong patch): - jp(1:3,2:3): OK - compile-time warning and the run-time error - jp(2,3): OK - no error/warning - jp(3,1:2): No compile-time diagnostics of dimension 1 plus the following: - jp(2,1:2): Bogus run-time error for the upper bound The problem for the last two examples is: - loop-dimen = 1(one array range 1:2) - info-ref-u.ar.dimen = 2 (total no. available dimensions 2) - n = 0, ..., loop-dimen - 1 Thus the check n == info-ref-u.ar.dimen - 1 is never true although n == 0 is the last dimension of an assumed-sized array. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33745
[Bug boehm-gc/33442] 1938 unexpected fails in libjava testsuite
--- Comment #10 from danglin at gcc dot gnu dot org 2007-10-13 15:01 --- Subject: Bug 33442 Author: danglin Date: Sat Oct 13 15:01:29 2007 New Revision: 129283 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129283 Log: PR boehm-gc/33442 * pthread_support.c (GC_PTR GC_get_thread_stack_base): If stack grows up, return stack_addr instead of stack_addr - stack_size. Modified: branches/gcc-4_2-branch/boehm-gc/ChangeLog branches/gcc-4_2-branch/boehm-gc/pthread_support.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33442
[Bug boehm-gc/33442] 1938 unexpected fails in libjava testsuite
--- Comment #11 from danglin at gcc dot gnu dot org 2007-10-13 15:04 --- Fixed on trunk and 4.2. I believe that this problem isn't present in 4.1. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33442
[Bug tree-optimization/33735] [4.3 Regression] verify_stmts failed: missing PHI def
--- Comment #4 from aoliva at gcc dot gnu dot org 2007-10-13 18:37 --- Proposed patch at http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00802.html -- aoliva at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33735
[Bug c++/33762] New: partial template specialization question
Probably this is not a bug, but just I want to make clear to myself...
I have a 'general' template class, and can specialize it for one class(say
base), can I then assume all other classes that derived from 'base' class are
using the specialized version template function(same as the base one)?
Example code:
#include iostream
using namespace std;
class Dummy{};
class Base {} ;
class Derive : virtual public Base{};
template class T class Stub : virtual public T
{
public:
Stub()
{
std::cout template class T class Stub : virtual public T
std::endl;
}
};
template class StubBase
{
public:
Stub()
{
std::cout template class StubBase
std::endl;
}
};
/*
I have to enable this to make it work as expected, but this is definitely not I
wants, since this mean I had to specialize _all_ the dervied classes like this,
which may be too much
template class StubDerive
{
public:
Stub()
{
std::cout template class StubDerive
std::endl;
}
};
*/
class A : public StubDummy
{
};
class B : public StubBase
{
};
class C : public StubDerive
{
};
int main()
{
A a; // expected, use the most general template.
B b; // expected, use the specialized template since T=Base
C c; // ?? I expected it will use the specialized template as well, since
T=Derive, which Derive is derived from Base.Am I wrong here??
return 0;
}
program output:
template class T class Stub : virtual public T
template class StubBase
template class T class Stub : virtual public T // I expected should be
template class StubBase as above here.
--
Summary: partial template specialization question
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gzljg at hotmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33762
[Bug c++/33762] partial template specialization question
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-10-13 19:05 --- specializations are direct matches and don't look at the class's bases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33762
[Bug ada/29283] Bug box in expand_expr_addr_expr_1, at expr.c:6393 on alpha
--- Comment #3 from ludovic at ludovic-brenta dot org 2007-10-13 19:09 --- Here is a second, shorter test case that triggers the bug on i386, x86_64 and powerpc. Thanks to Prakash Countcham at imag.fr and Xavier Grave for confirming on i386 and powerpc. This bug is not in GCC 4.2. procedure Test_Param is type Int_1 is range 0 .. 600; for Int_1'Size use 10; type Int_2 is range 0 .. 8_191; for Int_2'Size use 13; type T_A_B is record A : Int_1; B : Int_2 range 0 .. 6_350; end record; for T_A_B'Size use 23; pragma Pack(T_A_B); type T_C is array (1..7) of T_A_B; for T_C'Size use 7 * 23; pragma Pack(T_C); X : T_C; begin if X(1).B'Valid then null; end if; end Test_Param; $ gnatmake test_param.adb gcc-4.1 -c test_param.adb +===GNAT BUG DETECTED==+ | 4.1.2 20061115 (prerelease) (Debian 4.1.1-22) (x86_64-pc-linux-gnu) GCC error:| | in expand_expr_addr_expr_1, at expr.c:6393 | | Error detected at test_param.adb:24:5| -- ludovic at ludovic-brenta dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Known to fail||4.1.1 Known to work||4.2.2 Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29283
[Bug tree-optimization/33763] New: [4.1/4.2/4.3 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining
/* { dg-do compile } */
/* { dg-options -O2 } */
typedef struct
{
void *a;
void *b;
} T;
extern void *foo (const char *, const char *);
extern void *bar (void *, const char *, T);
extern int baz (const char *, int);
extern inline __attribute__ ((always_inline, gnu_inline)) int
baz (const char *x, int y)
{
return 2;
}
int
baz (const char *x, int y)
{
return 1;
}
int xa, xb;
static void *
inl (const char *x, const char *y)
{
T t = { xa, xb };
int *f = (int *) __builtin_malloc (sizeof (int));
const char *z;
int o = 0;
void *r = 0;
for (z = y; *z; z++)
{
if (*z == 'r')
o |= 1;
if (*z == 'w')
o |= 2;
}
if (o == 1)
*f = baz (x, 0);
if (o == 2)
*f = baz (x, 1);
if (o == 3)
*f = baz (x, 2);
if (o *f 0)
r = bar (f, w, t);
return r;
}
void *
foo (const char *x, const char *y)
{
return inl (x, y);
}
issues bogus sorry diagnostics, while simpler testcases are handled just fine:
extern int foo (const char *, int);
extern int baz (const char *, int);
extern inline __attribute__ ((always_inline, gnu_inline)) int
baz (const char *x, int y)
{
return 2;
}
int
baz (const char *x, int y)
{
return 1;
}
int xa, xb;
static int
inl (const char *x, int y)
{
return baz (x, y);
}
int
foo (const char *x, int y)
{
return inl (x, y);
}
When a gnu_inline (or extern inline gnu89) function has a real is redefined, we
don't want any inlining for that function even if it is always_inline, at least
GCC always behaved that way and even on the simpler testcase behaves that way.
Even the original testcase works just fine with GCC 3.2.x, so this is a
regression. On the trunk it is enough to e.g. remove one of the 3 baz calls in
inl and it compiles just fine (none of the baz calls is inlined as expected),
but
e.g. on 4.1 branch the compilation still fails.
arts hits this problem when building against recent glibcs.
--
Summary: [4.1/4.2/4.3 Regression] Bogus inlining failed in call
to `xxx': redefined extern inline functions are not
considered for inlining
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33763
[Bug tree-optimization/33140] [4.3 Regression] ICE in build2_stat, at tree.c:3115
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-10-13 19:35 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33140
[Bug java/33764] New: [4.3 regression] gij is built as 32-bit binary when building multilib gcc
When building gcc on x86_64 with multilib support, gij is built as 32-bit executable with some strange -rpaths. The other parts of gcj are ok. [EMAIL PROTECTED] ~]$ ldd /usr/bin/gcj libmpfr.so.1 = /usr/lib64/libmpfr.so.1 (0x2b0221bea000) libgmp.so.3 = /usr/lib64/libgmp.so.3 (0x2b0221e2) libc.so.6 = /lib64/libc.so.6 (0x2b022205e000) /lib64/ld-linux-x86-64.so.2 (0x2b02219ce000) [EMAIL PROTECTED] ~]$ ldd /usr/bin/gij (0xe000) libgij.so.9 = /usr/lib64/../lib/libgij.so.9 (0xf7f03000) libgcj.so.9 = /usr/lib64/../lib/libgcj.so.9 (0xf5fea000) libpthread.so.0 = /lib/libpthread.so.0 (0xf5fd2000) librt.so.1 = /lib/librt.so.1 (0xf5fca000) libdl.so.2 = /lib/libdl.so.2 (0xf5fc6000) libz.so.1 = /usr/lib64/../lib/libz.so.1 (0xf5fb3000) libgcc_s.so.1 = /usr/lib64/../lib/libgcc_s.so.1 (0xf5fa6000) libm.so.6 = /lib/libm.so.6 (0xf5f7f000) libc.so.6 = /lib/libc.so.6 (0x4200) /lib/ld-linux.so.2 (0xf7f07000) -- Summary: [4.3 regression] gij is built as 32-bit binary when building multilib gcc Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bero at arklinux dot org GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33764
[Bug c++/30303] [4.2/4.3 regression] ICE with invalid constructor definition
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-10-13 19:44 --- Testing this patch again to make sure it still works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30303
[Bug java/33765] New: [4.3 regression] gcj internal compiler error when reading an empty file
Feeding gcj an empty input file results in [EMAIL PROTECTED] ~]$ rm -f crap.java ; touch crap.java ; gcj crap.java /tmp/cck13U8f.jar:0: internal compiler error: in java_parse_file, at java/jcf-parse.c:1951 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: [4.3 regression] gcj internal compiler error when reading an empty file Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bero at arklinux dot org GCC build triplet: i586-pc-linux-gnu GCC host triplet: i586-pc-linux-gnu GCC target triplet: i586-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33765
[Bug c/33766] New: [4.1/4.2/4.3 Regression] ICE in bsi_for_stmt at tree-cfg.c when using -O1 -ftree-loop-linear
building xorg-server with -O1 -ftree-loop-linear on x86 fails with: texcompress_fxt1.c: In function 'fxt1_encode': texcompress_fxt1.c:1376: internal compiler error: in bsi_for_stmt, at tree-cfg.c:2827 Please submit a full bug report, with preprocessed source if appropriate. tested with 4.0.4, 4.1.2, 4.2.2, and a semi-recent snapshot (20070916) -- Summary: [4.1/4.2/4.3 Regression] ICE in bsi_for_stmt at tree- cfg.c when using -O1 -ftree-loop-linear Product: gcc Version: 4.1.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vapier at gentoo dot org GCC target triplet: i686-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33766
[Bug c/33766] [4.1/4.2/4.3 Regression] ICE in bsi_for_stmt at tree-cfg.c when using -O1 -ftree-loop-linear
--- Comment #1 from vapier at gentoo dot org 2007-10-13 19:52 ---
bugzilla seems to be droppin a brick when i try to attach files, so here's the
reduced test case i've been testing with:
fxt1_quantize_ALPHA1()
{
int j1;
int i;
float *tv;
for (j1 = 1; j1; j1++) {
float e;
for (i = 1; i; i++)
e = tv[i];
if (e)
i = j1;
}
return tv[i];
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33766
[Bug regression/32582] Bootstrap with vectorization enabled fails with ICE on PPC
--- Comment #34 from rakdver at gcc dot gnu dot org 2007-10-13 20:40 --- Does this still reproduce for you? After workarounding the crtstuff.c misscompilation as described in http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00743.html, bootstrap with BOOT_CFLAGS=-O2 -ftree-vectorize -maltivec passes for me on ppc64-linux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32582
[Bug fortran/33745] -fbounds-check: Bogus out-of-bounds run-time error for assumed-size array
--- Comment #4 from burnus at gcc dot gnu dot org 2007-10-13 20:53 --- Mine. Patch for both problems, see http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00796.html -- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2007-10-13 20:53:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33745
[Bug target/33767] New: GLOBAL_ASM_OP needs to be documented in tm.texi
There's just one mention in all of the internals docs:
The default implementation relies on a proper definition of
@code{GLOBAL_ASM_OP}.
varasm.c has this:
/* Default function to output code that will globalize a label. A
target must define GLOBAL_ASM_OP or provide its own function to
globalize a label. */
#ifdef GLOBAL_ASM_OP
void
default_globalize_label (FILE * stream, const char *name)
{
fputs (GLOBAL_ASM_OP, stream);
assemble_name (stream, name);
putc ('\n', stream);
}
#endif /* GLOBAL_ASM_OP */
Clearly, this should be documented as a target macro, and explained what a
proper definition actually *is*. Also, maybe there ought to be a default in
either defaults.h or elfos.h.
(revision 127595)
--
Summary: GLOBAL_ASM_OP needs to be documented in tm.texi
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kai-gcc-bugs at khms dot westfalen dot de
GCC build triplet: any
GCC host triplet: any
GCC target triplet: any
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33767
[Bug other/33768] New: splay-tree.c typo
in the functions rotate_left and rotate_right in splay-tree.c in the libiberty package, the comments preceding the functions should have an apostrophe in the word grandparents (common to both comments) changing the meaning from plural to possessive. a small point to sure but it confounded my understanding of how these simple functions worked for quite a bit. -- Summary: splay-tree.c typo Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: minor Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: george at houseofellery dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33768
[Bug ada/29283] Bug box in expand_expr_addr_expr_1, at expr.c:6393 on alpha
--- Comment #4 from charlet at gcc dot gnu dot org 2007-10-13 21:39 --- 4.1 is pretty much closed at this point, so closing. -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29283
[Bug middle-end/32878] FAIL: 23_containers/bitset/cons/16020.cc execution test
--- Comment #22 from danglin at gcc dot gnu dot org 2007-10-13 21:40 --- This test stopped failing at revision 127720. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32878
[Bug fortran/33727] Segfault with ugly string array constructor
--- Comment #6 from tobi at gcc dot gnu dot org 2007-10-13 21:44 --- Subject: Bug 33727 Author: tobi Date: Sat Oct 13 21:43:49 2007 New Revision: 129286 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129286 Log: 2007-10-13 Tobias Schlueter [EMAIL PROTECTED] Paul Thomas [EMAIL PROTECTED] PR fortran/33254 PR fortran/33727 fortran/ * trans-array.c (get_array_ctor_var_strlen): Check upper bound for constness instead of lower bound. (get_array_ctor_strlen): Add bounds-checking code. testsuite/ * bounds_check_10.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/bounds_check_10.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33727
[Bug fortran/33254] Diagnose different string lengths in array constructors at run time
--- Comment #12 from tobi at gcc dot gnu dot org 2007-10-13 21:44 --- Subject: Bug 33254 Author: tobi Date: Sat Oct 13 21:43:49 2007 New Revision: 129286 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129286 Log: 2007-10-13 Tobias Schlueter [EMAIL PROTECTED] Paul Thomas [EMAIL PROTECTED] PR fortran/33254 PR fortran/33727 fortran/ * trans-array.c (get_array_ctor_var_strlen): Check upper bound for constness instead of lower bound. (get_array_ctor_strlen): Add bounds-checking code. testsuite/ * bounds_check_10.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/bounds_check_10.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33254
[Bug fortran/33727] Segfault with ugly string array constructor
--- Comment #7 from tobi at gcc dot gnu dot org 2007-10-13 21:45 --- Fixed. -- tobi at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33727
[Bug fortran/33254] Diagnose different string lengths in array constructors at run time
--- Comment #13 from tobi at gcc dot gnu dot org 2007-10-13 21:47 --- Fixed. -- tobi at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33254
[Bug debug/33739] [Regression 4.3] Failure of gfortran.dg/literal_character_constant_1_*.F with -m64 -g on Darwin
--- Comment #5 from dominiq at lps dot ens dot fr 2007-10-13 21:52 --- I have forgotten to say that it is a regression, the tests pass with version 4.3.0 20071004 (revision 129004) and fail at after version 4.3.0 20071005 )revision 129038). -- dominiq at lps dot ens dot fr changed: What|Removed |Added Summary|Failure of |[Regression 4.3] Failure of |gfortran.dg/literal_characte|gfortran.dg/literal_characte |r_constant_1_*.F with -m64 -|r_constant_1_*.F with -m64 - |g on Darwin |g on Darwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33739
[Bug fortran/33727] Segfault with ugly string array constructor
--- Comment #8 from tobi at gcc dot gnu dot org 2007-10-13 22:28 --- Dominique, I forgot to say: your testcase is also fixed by Paul's patch, and it's really the same problem, so the testcase I added is enough. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33727
Erinnerung - Empfehlung persoenlich fuer gcc-bugs@gcc.gnu.org - Bereits der 2. Hinweis
Hallo gcc-bugs@gcc.gnu.org, dieses ist nun schon unsere 2. Mail an Sie, da wir nicht moechten, dass Ihnen die für Sie reservierten 2400,00 EUR verloren gehen. Ja tatsaechlich, dieser Betrag ist für Sie als Inhaber der Email gcc- [EMAIL PROTECTED] reserviert Greifen sie jetzt zu und holen sie sich jetzt 2400,00 EUR in Cash ab Alles mehrsprachig und einfach erklaert, starten Sie jetzt Für jeden erhaeltlich, ganz einfach: Anklicken, Registrieren, abholen WO ERHALTEN SIE SONST 2400 Euro in 12 Monaten aufgeteilt ? http://www.2400euro.de Exklusiv für Deutschland, Oesterreich Schweiz Anja Richard hat hiermit in den letzten Tagen 8255 Euro verdient.
[Bug target/33755] Gcc 4.2.2 broken for mips linux kernel builds
--- Comment #10 from ddaney at avtrex dot com 2007-10-14 02:02 --- Subject: Re: Gcc 4.2.2 broken for mips linux kernel builds rsandifo at gcc dot gnu dot org wrote: --- Comment #9 from rsandifo at gcc dot gnu dot org 2007-10-13 10:47 --- The problem comes from dbr_schedule, although it's not really a bug there. We have: bne $5,$0,L1# A ...stuff... L1: bne $5,$0,L2# B ...printk call... L2: and nothing before dbr_schedule has managed to thread A to L2. dbr_schedule first fills B's delay slot with an lui from the printk block, then steal_delay_list_from_target realises that A can steal B's delay slot and branch directly to L2. There is no other path to L1, so the rest of the printk call is now dead. For most targets, this is at worst a missed optimisation; we should have threaded A to L2 much earlier than dbr_schedule, and deleted the whole printk block as dead. I don't think the MIPS port can rely on that happening for correctness. So (alas!) I think the upshot is simply that we need to add some special code to mips_reorg to delete high-part relocations that have no matching lows. I'll have a poke. That makes sense, however it is a bit strange because... IIRC when I compiled the .i file with a fairly recent 4.3 build, the printk in question was not optimized away. So if 4.2.2 can validly optimize away the printk, then we have an optimization regression in 4.3 David Daney -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33755
