[Bug libfortran/24909] libmatmul.a breaks darwin build
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2005-11-19 08:38 --- On sparc-solaris I get runtime failures: collect2: ld returned 1 exit status^M compiler exited with status 1 output is: Undefined first referenced^M symbol in file^M _gfortran_matmul_r4 /var/tmp//ccKKiCDj.o^M ld: fatal: Symbol referencing errors. No output written to ./matmul_1.exe^M collect2: ld returned 1 exit status^M this is with both, the original libmatmul and with libmatmul_convenience. (using native, sun, as and ld) Confirmed with all versions of Solaris. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24909
[Bug c++/24939] New: operator in middle of expression is parsed as template
-- Summary: operator in middle of expression is parsed as template Product: gcc Version: 3.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: igodard at pacbell dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24939
[Bug c++/24939] operator in middle of expression is parsed as template
--- Comment #1 from igodard at pacbell dot net 2005-11-19 10:11 --- Created an attachment (id=10290) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10290action=view) compiler output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24939
[Bug c++/24939] operator in middle of expression is parsed as template
--- Comment #2 from igodard at pacbell dot net 2005-11-19 10:12 --- Created an attachment (id=10291) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10291action=view) source code (compressed) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24939
[Bug rtl-optimization/24883] [4.1 Regression] fatal error: internal consistency failure building xorg-x11
--- Comment #8 from rguenth at gcc dot gnu dot org 2005-11-19 10:12 --- Bootstrapped and regtested on s390-linux-gnu for all default languages. We already branched, so I leave it to you comitting the patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24883
[Bug rtl-optimization/24899] loop.c miscompiles libgnomecanvas
--- Comment #12 from rguenth at gcc dot gnu dot org 2005-11-19 10:22 --- I don't know. There seems to be a latent problem in loop.c (no wonders). We are currently trying to get rid of loop.c for 4.1 (by effectively disabling it), so we may not care if this is not fixed. For 4.2 we will get rid of loop.c completely. So, SUSPENDED seems appropriate (unless someone wants to work on it). I also remove the regression marker and note it as a loop.c bug in the summary. May I create a testcase and apply that to the branch(es), so we notice re-surfacing of the problem? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |SUSPENDED Summary|[4.1 Regression] Miscompiles|loop.c miscompiles |libgnomecanvas |libgnomecanvas http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24899
[Bug rtl-optimization/24899] loop.c miscompiles libgnomecanvas
--- Comment #13 from rguenth at gcc dot gnu dot org 2005-11-19 10:36 --- Created an attachment (id=10292) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10292action=view) proposed testsuite entry Btw, did you remember to use -fno-inline? I still seem to be able to reproduce it. Testcase which doesn't require that and any includes attached. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24899
[Bug rtl-optimization/24899] loop.c miscompiles libgnomecanvas
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|SUSPENDED |NEW Last reconfirmed|2005-11-18 18:01:19 |2005-11-19 10:37:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24899
[Bug target/24934] [4.1 Regression] profilebootstrap failure
--- Comment #13 from rguenth at gcc dot gnu dot org 2005-11-19 10:38 --- Changing the summary to reflect reality and remove some of the obscure-ness. Mark, what was the obscureness you are refering to? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org Summary|[4.1 Regression]|[4.1 Regression] |profilebootstrap failure|profilebootstrap failure |with debugging disabled | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24934
[Bug middle-end/23294] fold does not fold a*C+a to a*(C+1) or a*C-a to a*(C-1)
--- Comment #7 from rguenth at gcc dot gnu dot org 2005-11-19 11:29 --- Subject: Bug 23294 Author: rguenth Date: Sat Nov 19 11:29:10 2005 New Revision: 107218 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107218 Log: 2005-11-19 Richard Guenther [EMAIL PROTECTED] PR middle-end/23294 * fold-const.c (fold_plusminus_mult_expr): New function. (fold_binary): Use to canonicalize PLUS_EXPR and MINUS_EXPR cases, remove now unnecessary code. * gcc.dg/tree-ssa/pr23294.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr23294.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23294
[Bug middle-end/23294] fold does not fold a*C+a to a*(C+1) or a*C-a to a*(C-1)
--- Comment #8 from rguenth at gcc dot gnu dot org 2005-11-19 11:31 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23294
[Bug libgcj/24940] New: libjava/configure uses $SED without defining it
libjava/configure uses $SED without defining it. Add a check for it, or eliminate it's use? All other configure files directly use sed. Matthias -- Summary: libjava/configure uses $SED without defining it Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: debian-gcc at lists dot debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24940
[Bug target/21041] [4.0/4.1 Regression] ICE: output_operand: Cannot decompose address
--- Comment #10 from rguenth at gcc dot gnu dot org 2005-11-19 14:42 --- Uli, this still ICEs with current mainline. Any real fix in sight? Any chance of committing the workaround? P5, as not a primary target. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Priority|P2 |P5 Summary|[4.0 Regression] ICE: |[4.0/4.1 Regression] ICE: |output_operand: Cannot |output_operand: Cannot |decompose address |decompose address http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21041
[Bug fortran/24807] Fortran supports real*16, but not complex*32
--- Comment #5 from kargl at gcc dot gnu dot org 2005-11-19 14:51 --- How about Old style type declaration at %L not supported? The 16 in complex*16 really isn't a kind type parameter, so we should avoid calling it a kind. If you decide to go with the above message, consider the patch pre-approved. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24807
[Bug java/24698] [4.1 regression] Apparent problem getting non-.class files out of jars
--- Comment #1 from bero at arklinux dot org 2005-11-19 15:00 --- Created an attachment (id=10293) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10293action=view) Simplified test case (this will become a jar) Compile the attached minimalistic test case into a jar file: tar xzf test.tar.gz gcj -C org/arklinux/test/testcase.java fastjar cf test.jar org/arklinux/test/*.class org/arklinux/test/*.properties -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698
[Bug java/24698] [4.1 regression] Apparent problem getting non-.class files out of jars
--- Comment #2 from bero at arklinux dot org 2005-11-19 15:02 --- Created an attachment (id=10294) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10294action=view) Testcase, part 2 Step 2: Compile something that uses it CLASSPATH=test.jar gcj -C test1.java -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698
[Bug java/24698] [4.1 regression] Apparent problem getting non-.class files out of jars
--- Comment #3 from bero at arklinux dot org 2005-11-19 15:03 --- Step 3: Try running it. CLASSPATH=test.jar gij test1 Prints Microsoft is crap with gcj 4.0.x, produces a segmentation fault with today's SVN. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698
[Bug java/24698] [4.1 regression] Apparent problem getting non-.class files out of jars
--- Comment #4 from bero at arklinux dot org 2005-11-19 15:16 --- Also try: gcj -O2 -fPIC -fjni -shared -o libtestcase.so test.jar gcj -o testcase test1.java --main=test1 -L. -ltestcase LD_LIBRARY_PATH=. ./testcase Works as expected in 4.0.x, current SVN acts up: Generating libtestcase.so doesn't produce an error, but after that things get strange. $ gcj -o testcase test1.java --main=test1 -L. -ltestcase test1.java:1: error: Can't find default package 'org.arklinux.test'. Check the CLASSPATH environment variable and the access to the archives 1 error test1.java:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions Similar error if I tell it where to find the jar: $ CLASSPATH=test.jar gcj -o testcase test1.java --main=test1 -L. -ltestcase test1.java:3: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698
[Bug c++/24849] [gomp] ICE in expand_expr_real_1
--- Comment #6 from dnovillo at gcc dot gnu dot org 2005-11-19 15:18 --- Subject: Bug 24849 Author: dnovillo Date: Sat Nov 19 15:18:08 2005 New Revision: 107220 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107220 Log: PR 24849 * omp-low.c (determine_parallel_type): Do not handle OMP_FOR. testsuite/ PR 24849 * g++.dg/gomp/pr24849.C: New test. * gcc.dg/gomp/for-19.c: XFAIL. * gcc.dg/gomp/for-18.c: XFAIL. Added: branches/gomp-20050608-branch/gcc/testsuite/g++.dg/gomp/pr24849.C Modified: branches/gomp-20050608-branch/gcc/ChangeLog.gomp branches/gomp-20050608-branch/gcc/omp-low.c branches/gomp-20050608-branch/gcc/testsuite/ChangeLog.gomp branches/gomp-20050608-branch/gcc/testsuite/gcc.dg/gomp/for-18.c branches/gomp-20050608-branch/gcc/testsuite/gcc.dg/gomp/for-19.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24849
[Bug c++/24849] [gomp] ICE in expand_expr_real_1
--- Comment #7 from dnovillo at gcc dot gnu dot org 2005-11-19 15:18 --- Workaround applied. The actual solution separates lowering from optimization, once all the OMP directives are lowered to a language-independent form, we can apply the combined parallel+loop optimization without running into these odd corners. I need a few more days to finish implementing this separation. In the meantime, we can live without this optimization. -- dnovillo at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24849
[Bug fortran/24917] Handling of hexadecimal constants in gfortran
-- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org AssignedTo|unassigned at gcc dot gnu |kargl at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-11-17 20:16:39 |2005-11-19 15:29:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24917
[Bug target/24934] [4.1 Regression] profilebootstrap failure
--- Comment #14 from pinskia at gcc dot gnu dot org 2005-11-19 16:22 --- (In reply to comment #13) Changing the summary to reflect reality and remove some of the obscure-ness. Mark, what was the obscureness you are refering to? well both using BOOT_CFLAGS and profiledbootstrap together is less likely than just bootstrap and using BOOT_CFLAGS. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24934
[Bug debug/24943] New: [hppa64] Bad dwarf output using non-preserved base register
Given a program like this:
int foo(int a, int b, int c)
{
return a+b+c;
}
int bar(int a, int b, int c)
{
return foo(a, b, c);
}
int main(int argc, char **argv)
{
return bar(1,2,3);
}
for foo and bar, gcc generates code that stores the arguments a, b, and c on
the stack by using the argument pointer, but it does this indirectly, like so:
foo
.PROC
.CALLINFO FRAME=80,NO_CALLS,SAVE_SP,ENTRY_GR=3
.ENTRY
copy %r3,%r1
copy %r30,%r3
std,ma %r1,80(%r30)
std %r3,-8(%r30)
ldo -64(%r29),%r20
stw %r26,4(%r20)
stw %r25,12(%r20)
stw %r24,20(%r20)
[...]
gcc proceeds to emit debug info for a, b, and c relative to r20:
$ opt/bin/readelf -wi dwarfbug
[...]
27d: Abbrev Number: 3 (DW_TAG_formal_parameter)
DW_AT_name: a
DW_AT_decl_file : 1
DW_AT_decl_line : 1
DW_AT_type: a2
DW_AT_location: 2 byte block: 84 4 (DW_OP_breg20: 4)
289: Abbrev Number: 3 (DW_TAG_formal_parameter)
DW_AT_name: b
DW_AT_decl_file : 1
DW_AT_decl_line : 1
DW_AT_type: a2
DW_AT_location: 2 byte block: 84 c (DW_OP_breg20: 12)
295: Abbrev Number: 3 (DW_TAG_formal_parameter)
DW_AT_name: c
DW_AT_decl_file : 1
DW_AT_decl_line : 1
DW_AT_type: a2
DW_AT_location: 2 byte block: 84 14(DW_OP_breg20: 20)
The problem is that since r20 is not a call preserved register, when you are
doing a stack unwind, you have no way to retrieve those variables in anything
other than the topmost frame.
I've seen it do this with r20 and r28, but I guess it can do it with any
available register.
On 32-bit hppa, the parameters are always described relative to the frame base
(DW_OP_fbreg), which works fine.
I'm testing this on hpux, but this looks like it affects all 64-bit hppa
targets.
--
Summary: [hppa64] Bad dwarf output using non-preserved base
register
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tausq at debian dot org
GCC build triplet: hppa64-hp-hpux11.11
GCC host triplet: hppa64-hp-hpux11.11
GCC target triplet: hppa64-hp-hpux11.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24943
[Bug ada/23717] [Ada] Wrong ICE diagnostic formatting
--- Comment #2 from rguenth at gcc dot gnu dot org 2005-11-19 17:24 --- Subject: Bug 23717 Author: rguenth Date: Sat Nov 19 17:24:33 2005 New Revision: 107223 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107223 Log: 2005-11-19 Richard Guenther [EMAIL PROTECTED] Roger Sayle [EMAIL PROTECTED] PR ada/23717 * misc.c (internal_error_function): Don't use vsprintf to format the error message text, instead use pp_format_text and the new pretty printer APIs. This allows handling of %qs, %w, etc. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/misc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23717
[Bug ada/23717] [Ada] Wrong ICE diagnostic formatting
--- Comment #3 from rguenth at gcc dot gnu dot org 2005-11-19 17:25 --- Subject: Bug 23717 Author: rguenth Date: Sat Nov 19 17:25:41 2005 New Revision: 107224 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107224 Log: 2005-11-19 Richard Guenther [EMAIL PROTECTED] Roger Sayle [EMAIL PROTECTED] PR ada/23717 * misc.c (internal_error_function): Don't use vsprintf to format the error message text, instead use pp_format_text and the new pretty printer APIs. This allows handling of %qs, %w, etc. Modified: branches/gcc-4_1-branch/gcc/ada/ChangeLog branches/gcc-4_1-branch/gcc/ada/misc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23717
[Bug ada/23717] [Ada] Wrong ICE diagnostic formatting
--- Comment #4 from rguenth at gcc dot gnu dot org 2005-11-19 17:26 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.1.0 Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23717
[Bug target/24934] [4.1 Regression] profilebootstrap failure
--- Comment #15 from mark at codesourcery dot com 2005-11-19 17:34 --- Subject: Re: [4.1 Regression] profilebootstrap failure rguenth at gcc dot gnu dot org wrote: --- Comment #13 from rguenth at gcc dot gnu dot org 2005-11-19 10:38 --- Changing the summary to reflect reality and remove some of the obscure-ness. Mark, what was the obscureness you are refering to? Sorry, that was indeed unclear. I don't consider building the compiler with profiledbootstrap to be a fundamental usage model. Most people don't do it, and there's an easy work-around: build with normal bootstrap. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24934
[Bug c/24944] New: Size of type not multiple of its alignment.
This topic was discussed in the following thread, but nothing seems to have
happened. I couldn't find a bug report.
http://gcc.gnu.org/ml/gcc/2003-09/msg01031.html
The test case below demonstrates some problems with arrays of aligned types.
Packing the aligned type in a structure fixes the problems.
Results:
FAIL: sizeof(foo_aligned)!=8 {7!=8}
FAIL: sizeof(foo_aligned_array)!=100*8 {700!=800}
FAIL: p2-p1!=3*8 {18!=24}
It appears that getting the address of x[3] rounds the size down to the
alignment, so this should be fixed by ensuring that the size is a multiple of
the alignment.
#include stdio.h
#include stdlib.h
typedef char foo[7];
typedef foo foo_aligned __attribute__((aligned(2)));
typedef struct { foo_aligned c; } foo_aligned_struct;
typedef foo_aligned foo_aligned_array[100];
typedef foo_aligned_struct foo_aligned_struct_array[100];
int result = 0;
void fail(const char *as, int a, const char *bs, int b)
{
fprintf(stderr, FAIL: %s!=%s {%d!=%d}\n, as, bs, a, b);
result = 1;
}
#define expect(A,B) \
do { if((A)!=(B)) fail(#A, A, #B, B); } while(0)
int main()
{
foo_aligned_array x;
foo_aligned_struct_array y;
char *p1, *p2;
expect(sizeof(foo_aligned), 8);
expect(sizeof(foo_aligned_struct), 8);
expect(sizeof(foo_aligned_array), 100*8);
expect(sizeof(foo_aligned_struct_array), 100*8);
p1 = (char*)(x[0]);
p2 = (char*)(x[3]);
expect(p2-p1, 3*8);
p1 = (char*)(y[0]);
p2 = (char*)(y[3]);
expect(p2-p1, 3*8);
return result;
}
--
Summary: Size of type not multiple of its alignment.
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neilt+bugs at chiark dot greenend dot org dot uk
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24944
[Bug c++/24939] operator in middle of expression is parsed as template
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-19 18:31 --- I think this is a dup of your older bug, PR 20308. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24939
[Bug c++/24939] operator in middle of expression is parsed as template
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-19 18:34 ---
Yep it is a dup:
templatetypename T, templatetypenameclass al
void slistT, al::merge(slistT, al l) {
node_type* cursor = before_begin().iter;
while(cursor-next != nil !l.empty()) {
if (l.head-val cursor-next-val)
*** This bug has been marked as a duplicate of 20308 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||DUPLICATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24939
[Bug c++/20308] parser thinks something is a start of a template-id when it is just less than
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-19 18:34 --- *** Bug 24939 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20308
[Bug libgcj/24940] libjava/configure uses $SED without defining it
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-19 18:39 --- SED comes from shlibpath.m4 which has: # shlibpath.m4 - Define LTDL_SHLIBPATH_VAR. -*-Autoconf-*- So isn't this really just an import from libtool? I think you should be complaining there instead of here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24940
[Bug rtl-optimization/24899] [4.1 Regression] loop.c miscompiles libgnomecanvas
--- Comment #14 from pinskia at gcc dot gnu dot org 2005-11-19 18:42 --- I must had missed -fno-inline. This is still reproducable for me on the mainline and the 4.1 branch. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.1.0 Known to work||4.0.3 Summary|loop.c miscompiles |[4.1 Regression] loop.c |libgnomecanvas |miscompiles libgnomecanvas http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24899
[Bug libfortran/19303] Unformatted record header is 4-bytes on 32-bit targets
--- Comment #15 from milan at cmm dot ki dot si 2005-11-19 19:09 --- I didn 't know how to compile gcc-4.1... so I couldn't reply before. I realised I have to install both mpfr and gmp libraries for gcc to compile. It complains only about gmp :-( Yes, this patch works OK. I had to patch the gcc-4.1-20051112 snapshot myself. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19303
[Bug fortran/24945] New: calling two open statements (same unit) without close fails
I am trying to open the same file twice. This works in g77, but fails in gfortran-4.1-20051112 snapshot This is the program: integer iun,irecl iun=1 irecl=5 open(unit=iun,file='uu',status='unknown',access='direct', $ form='unformatted',recl=8*irecl) C close(unit=iun) open(unit=iun,file='uu',status='unknown',access='direct', $ form='unformatted',recl=8*irecl) end If I use close it works, but as you can guess this is a part of larger program so I don't want to know where to put this close statement! -- Summary: calling two open statements (same unit) without close fails Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: milan at cmm dot ki dot si http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24945
[Bug fortran/24807] Fortran supports real*16, but not complex*32
--- Comment #6 from schnetter at aei dot mpg dot de 2005-11-19 19:38 --- Created an attachment (id=10295) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10295action=view) Patch with better error messach I've change the error message so that it doesn't use the expression kind where it shouldn't. I also changed the other error message that is a few lines further down in the same way. -- schnetter at aei dot mpg dot de changed: What|Removed |Added Attachment #10219|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24807
[Bug libfortran/19303] Unformatted record header is 4-bytes on 32-bit targets
--- Comment #16 from rrr6399 at futuretek dot com 2005-11-19 20:24 --- Created an attachment (id=10296) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10296action=view) Patch to change delimitters to 4 bytes for unformatted records This is nearly the same patch that I posted before except for the head of the subversion repository. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19303
[Bug libfortran/24794] problem with namelist input of character array
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2005-11-19 20:43 --- I have the patch for this working and will be submitting to the list for approval soon. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24794
[Bug target/24850] [4.1 regression] bootstrap failure on m68k-linux
--- Comment #2 from kazu at gcc dot gnu dot org 2005-11-19 20:48 --- I'm pretty sure this is a duplicate of PR 24912, which has got more analysis. *** This bug has been marked as a duplicate of 24912 *** -- kazu at gcc dot gnu dot org changed: What|Removed |Added CC||kazu at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24850
[Bug middle-end/24912] m68k build failure: ICE: in reload_cse_simplify_operands
--- Comment #7 from kazu at gcc dot gnu dot org 2005-11-19 20:48 --- *** Bug 24850 has been marked as a duplicate of this bug. *** -- kazu at gcc dot gnu dot org changed: What|Removed |Added CC||debian-gcc at lists dot ||debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24912
[Bug middle-end/24912] [4.1, 4.2 Regression] m68k build failure: ICE: in reload_cse_simplify_operands
-- kazu at gcc dot gnu dot org changed: What|Removed |Added CC||kazu at gcc dot gnu dot org Summary|m68k build failure: ICE: in |[4.1, 4.2 Regression] m68k |reload_cse_simplify_operands|build failure: ICE: in ||reload_cse_simplify_operands Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24912
[Bug target/21578] ICE in reload_cse_simplify_operands for Coldfire.
--- Comment #4 from kazu at gcc dot gnu dot org 2005-11-19 21:05 --- Is this still reproducible? A quick check with m68k-none-elf did not reproduce the ICE. -- kazu at gcc dot gnu dot org changed: What|Removed |Added CC||kazu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21578
[Bug middle-end/24279] SEGV at reload.c:2400 with -O2
--- Comment #7 from kazu at gcc dot gnu dot org 2005-11-19 21:13 --- Jonathan, The testcase seems to work with GCC 4.1. As far as getting the testcase into the testsuite, you need to post a patch first. The best thing to do at this point is to reduce the testcase so that it will be easier to analyze what's going on. -- kazu at gcc dot gnu dot org changed: What|Removed |Added CC||kazu at gcc dot gnu dot org Known to work||4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24279
[Bug target/23695] [ColdFire] Illegal move of byte intoo address register causes compiler to ICE
--- Comment #2 from kazu at gcc dot gnu dot org 2005-11-19 21:19 --- Confirmed with m68k-none-elf. Probably not specific to RTEMS. -- kazu at gcc dot gnu dot org changed: What|Removed |Added CC||kazu at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.1.0 Last reconfirmed|-00-00 00:00:00 |2005-11-19 21:19:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23695
[Bug target/23695] [ColdFire] Illegal move of byte intoo address register causes compiler to ICE
--- Comment #3 from kazu at gcc dot gnu dot org 2005-11-19 21:26 ---
Slightly reduced to:
extern void bar (unsigned char, unsigned char, unsigned char);
void
foo (unsigned char *key, unsigned int round)
{
unsigned char a = 0, b = 0, c = 0;
while (round-- 0)
{
a ^= *++key;
b += *++key;
c += *++key;
}
bar (a, b, c);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23695
[Bug fortran/24862] [4.1 Regression] Internal Error: Derived type I/O should have been handled via the frontend.
--- Comment #6 from jb at gcc dot gnu dot org 2005-11-19 21:36 --- Subject: Bug 24862 Author: jb Date: Sat Nov 19 21:36:06 2005 New Revision: 107228 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107228 Log: fortran ChangeLog: 2005-11-19 Janne Blomqvist [EMAIL PROTECTED] PR fortran/24862 * trans-io.c (gfc_trans_transfer): Handle arrays of derived type. testsuite ChangeLog: 2005-11-19 Janne Blomqvist [EMAIL PROTECTED] PR fortran/24862 * gfortran.dg/arrayio_derived_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/arrayio_derived_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-io.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24862
[Bug target/19201] [m68k] Inefficient code for array accesses (from old PROBLEMS)
--- Comment #3 from kazu at gcc dot gnu dot org 2005-11-19 21:52 --- FWIW, the mainline gcc with -O2 -fomit-frame-pointer produces f: move.l 4(%sp),%a0 move.l (%a0),%a1 move.l 4(%a0),%a0 clr.b (%a0,%a1.l) rts -- kazu at gcc dot gnu dot org changed: What|Removed |Added CC||kazu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19201
[Bug middle-end/24912] [4.1, 4.2 Regression] m68k build failure: ICE: in reload_cse_simplify_operands
--- Comment #8 from hp at gcc dot gnu dot org 2005-11-19 21:54 --- Subject: Bug 24912 Author: hp Date: Sat Nov 19 21:54:26 2005 New Revision: 107230 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107230 Log: PR middle-end/24912 * gcc.dg/torture/pr24912-1.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr24912-1.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24912
[Bug middle-end/24750] [4.1 regression] global-alloc (reload) trips over own confusion for unexpected addressing modes
--- Comment #14 from hp at gcc dot gnu dot org 2005-11-19 21:56 --- Subject: Bug 24750 Author: hp Date: Sat Nov 19 21:56:17 2005 New Revision: 107231 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107231 Log: PR middle-end/24912 PR middle-end/24750 * reload.c (find_reloads_address_1): Mention dependency on gen_reload. * reload1.c (gen_reload): For IN with an unary operation, try moving inner expression to OUT if trivial SET is not valid. Confirm that the result is valid. Move common code block into... (emit_insn_if_valid_for_reload): New function. Modified: trunk/gcc/ChangeLog trunk/gcc/reload.c trunk/gcc/reload1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24750
[Bug middle-end/24912] [4.1, 4.2 Regression] m68k build failure: ICE: in reload_cse_simplify_operands
--- Comment #9 from hp at gcc dot gnu dot org 2005-11-19 21:56 --- Subject: Bug 24912 Author: hp Date: Sat Nov 19 21:56:17 2005 New Revision: 107231 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107231 Log: PR middle-end/24912 PR middle-end/24750 * reload.c (find_reloads_address_1): Mention dependency on gen_reload. * reload1.c (gen_reload): For IN with an unary operation, try moving inner expression to OUT if trivial SET is not valid. Confirm that the result is valid. Move common code block into... (emit_insn_if_valid_for_reload): New function. Modified: trunk/gcc/ChangeLog trunk/gcc/reload.c trunk/gcc/reload1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24912
[Bug middle-end/24912] [4.1, 4.2 Regression] m68k build failure: ICE: in reload_cse_simplify_operands
--- Comment #10 from hp at gcc dot gnu dot org 2005-11-19 21:58 --- Subject: Bug 24912 Author: hp Date: Sat Nov 19 21:58:23 2005 New Revision: 107232 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107232 Log: PR middle-end/24912 * gcc.dg/torture/pr24912-1.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/torture/pr24912-1.c Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24912
[Bug middle-end/24912] [4.1, 4.2 Regression] m68k build failure: ICE: in reload_cse_simplify_operands
--- Comment #11 from hp at gcc dot gnu dot org 2005-11-19 21:59 --- Subject: Bug 24912 Author: hp Date: Sat Nov 19 21:59:48 2005 New Revision: 107233 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107233 Log: PR middle-end/24912 PR middle-end/24750 * reload.c (find_reloads_address_1): Mention dependency on gen_reload. * reload1.c (gen_reload): For IN with an unary operation, try moving inner expression to OUT if trivial SET is not valid. Confirm that the result is valid. Move common code block into... (emit_insn_if_valid_for_reload): New function. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/reload.c branches/gcc-4_1-branch/gcc/reload1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24912
[Bug middle-end/24750] [4.1 regression] global-alloc (reload) trips over own confusion for unexpected addressing modes
--- Comment #15 from hp at gcc dot gnu dot org 2005-11-19 21:59 --- Subject: Bug 24750 Author: hp Date: Sat Nov 19 21:59:48 2005 New Revision: 107233 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107233 Log: PR middle-end/24912 PR middle-end/24750 * reload.c (find_reloads_address_1): Mention dependency on gen_reload. * reload1.c (gen_reload): For IN with an unary operation, try moving inner expression to OUT if trivial SET is not valid. Confirm that the result is valid. Move common code block into... (emit_insn_if_valid_for_reload): New function. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/reload.c branches/gcc-4_1-branch/gcc/reload1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24750
[Bug fortran/24862] [4.1 Regression] Internal Error: Derived type I/O should have been handled via the frontend.
--- Comment #7 from jb at gcc dot gnu dot org 2005-11-19 22:03 --- Subject: Bug 24862 Author: jb Date: Sat Nov 19 22:03:41 2005 New Revision: 107234 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107234 Log: fortran ChangeLog: 2005-11-20 Janne Blomqvist [EMAIL PROTECTED] PR fortran/24862 * trans-io.c (gfc_trans_transfer): Handle arrays of derived type. testsuite ChangeLog: 2005-11-20 Janne Blomqvist [EMAIL PROTECTED] PR fortran/24862 * gfortran.dg/arrayio_derived_1.f90: New test Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/arrayio_derived_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/trans-io.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24862
[Bug tree-optimization/24665] [4.0/4.1 Regression] internal compiler error: get_indirect_ref_operands
-- rth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-11-04 05:06:42 |2005-11-19 22:05:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24665
[Bug target/24757] [4.1 Regression] __sync_fetch_and_add on ia64
--- Comment #26 from pcarlini at suse dot de 2005-11-19 22:12 --- Created an attachment (id=10297) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10297action=view) Reduced from thread/pthread3 Richard, I'm attaching a really minimal testcase, which fails very quickly for me with mainline or 4_1-branch and doesn't with 4_0-branch. It's just two threads and many constructions and destructions of a trivial class which increases (descreases, respectively) atomically a static counter. Of course the abort should never trigger. Can you debug further with this? Otherwise, just tell me, ok? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24757
[Bug libfortran/24945] calling two open statements (same unit) without close fails
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-11-19 22:32 --- Confirmed (though I don't know why it should work and how it should behave). Intel accepts this too. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org OtherBugsDependingO||19292 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-19 22:32:17 date|| Version|unknown |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24945
[Bug bootstrap/24946] New: make[7]: rc: Command not found
make[8]: Leaving directory `/home/dave/gcc-4.1/objdir/gcc/ada/rts' rm -f rts/libgnat.a rts/libgnarl.a rc rts/libgnat.a \ rts/a-caldel.o rts/a-calend.o rts/a-cdlili.o rts/a-cgaaso.o rts/a-cgarso.o rt ... It seems AR_FOR_TARGET didn't expand to ar. 2005-11-14 Arnaud Charlet [EMAIL PROTECTED] * Makefile.in: Add or update g-soccon LIBGNAT pairs for Linux/PPC and 64-bit Solaris Split the Linux version of g-soccon into separate variants for 32 and 64 bit platforms. (gnatlib): Use $(AR_FOR_TARGET) and $(RANLIB_FOR_TARGET) vice $(AR) and $(RANLIB). Remove use of host variable $(RANLIB_FLAGS). install-gnatlib: Use $(RANLIB_FOR_TARGET) vice $(RANLIB). Remove use of host variable $(RANLIB_FLAGS). -- Summary: make[7]: rc: Command not found Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa-unknown-linux-gnu GCC host triplet: hppa-unknown-linux-gnu GCC target triplet: hppa-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24946
[Bug target/24757] [4.1 Regression] __sync_fetch_and_add on ia64
--- Comment #27 from rguenth at gcc dot gnu dot org 2005-11-19 22:38 --- The only thing in the pthread3_reduced.cc testcase that could make it going wrong is wrong alignment of aw. And I remember seeing a lot of unaligned traps in dmesg during libstdc++ testing on ia64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24757
[Bug target/24757] [4.1 Regression] __sync_fetch_and_add on ia64
--- Comment #28 from pcarlini at suse dot de 2005-11-19 22:45 --- Thanks Richard G. In fact, from time to time I saw warnings on the shell, which really puzzled me, because I was sure that no alignment issues were present anymore in the higher lever library code proper. I'll try to add an alignment attribute to the _Atomic_word typedef, as cris is already doing for instance, and see whether something changes for the better. Interestingly no such issue existed with 4_0-branch... Any idea why? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24757
[Bug target/24757] [4.1 Regression] __sync_fetch_and_add on ia64
--- Comment #29 from pcarlini at suse dot de 2005-11-19 23:02 --- (In reply to comment #28) I'll try to add an alignment attribute to the _Atomic_word typedef, as cris is already doing for instance, and see whether something changes for the better. Nope. Maybe the alignment is for some reason broken to the point that not even an explicit __attribute__ ((aligned (X))) can fix it... I don't know. Anyway, the problem is very easy to reproduce, now. I'm also attaching a further reduced, pure C testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24757
[Bug target/24757] [4.1 Regression] __sync_fetch_and_add on ia64
--- Comment #30 from pcarlini at suse dot de 2005-11-19 23:06 --- Created an attachment (id=10298) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10298action=view) Further reduced, pure C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24757
[Bug target/24757] [4.1 Regression] __sync_fetch_and_add on ia64
--- Comment #31 from schwab at suse dot de 2005-11-20 00:22 --- Testing this patch: Index: ia64.c === --- ia64.c (revision 107220) +++ ia64.c (working copy) @@ -2113,7 +2113,7 @@ emit_insn (GEN_FCN (icode) (cmp_reg, mem, ar_ccv, new_reg)); - emit_cmp_and_jump_insns (cmp_reg, old_reg, EQ, NULL, DImode, true, label); + emit_cmp_and_jump_insns (cmp_reg, old_reg, NE, NULL, DImode, true, label); } /* Begin the assembly file. */ -- schwab at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |schwab at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24757
[Bug target/19201] [m68k] Inefficient code for array accesses (from old PROBLEMS)
--- Comment #4 from kazu at gcc dot gnu dot org 2005-11-20 00:22 --- Created an attachment (id=10299) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10299action=view) Patch With this patch, I get: f: move.l 4(%sp),%a0 move.l (%a0),%a1 add.l 4(%a0),%a1 clr.b (%a1) rts -- kazu at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kazu at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19201
[Bug libfortran/24903] dotprod should use conj?
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-20 00:40 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-20 00:40:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24903
[Bug libstdc++/24882] [meta-bug] Non-refcounted, moveable basic_string
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||meta-bug Last reconfirmed|-00-00 00:00:00 |2005-11-20 00:40:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24882
[Bug c++/24874] ICE: in add_AT_specification, at dwarf2out.c:4903
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-20 00:43 --- Yes this is a dup of bug 24569 which was fixed for 4.0.3. *** This bug has been marked as a duplicate of 24569 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24874
[Bug c++/24569] [4.0/4.1 regression] ICE in add_AT_specification, at dwarf2out.c:4966
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-11-20 00:43 --- *** Bug 24874 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||christof at petig-baender ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24569
[Bug c++/24947] New: -Os should maximize inlining --param values.
When compiling with -Os and -Winline, many warnings like this occur: file.cc:25: warning: inlining failed in call to 'function': --param inline-unit-growth limit reached because the optimizer's inlining code gives up too early. The parameters most commonly exceeded are max-inline-insns-single, inline-unit-growth, and large-function-growth. This happens pretty much all the time in my code from all those deep STL interfaces, and I constantly have to specify some more appropriate (higher) values for the offending parameters. All C++ code I have ever seen is written with lots of inlines. Those inline functions, almost always reduce code size when inlined, and when the optimizer passes them by, it leaves behind function calls to simple accessors that could have been compiled as a single movl. Since -Os is supposed to optimize for size, it would be most logical to set those --param values to their maximum values (I use 1024, which works so far) to ensure all the inline functions are inlined. This works for -Os because -finline-functions is disabled and only those functions that are explicitly declared inline are inlined. With -finline-functions the large inlining parameters would probably generate nothing but bloat, and should remain at present values. -- Summary: -Os should maximize inlining --param values. Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: msharov at hotmail dot com GCC build triplet: athlon-gnu-linux GCC host triplet: athlon-gnu-linux GCC target triplet: athlon-gnu-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24947
[Bug libfortran/24945] calling two open statements (same unit) without close fails
--- Comment #2 from kargl at gcc dot gnu dot org 2005-11-20 01:16 --- See 9.3.4 from the standard. If a unit is connected to a file that exists, execution of an OPEN statement for that unit is permitted. If the FILE= specifier is not included in such an OPEN statement, the file to be connected to the unit is the same as the file to which the unit is already connected. If the file to be connected to the unit does not exist but is the same as the file to which the unit is preconnected, the properties specified by an OPEN statement become a part of the connection. If the file to be connected to the unit is not the same as the file to which the unit is connected, the effect is as if a CLOSE statement without a STATUS= specifier had been executed for the unit immediately prior to th execution of an OPEN statement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24945
[Bug c++/24947] -Os should maximize inlining --param values.
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-20 01:31 --- For 4.1, with -Os, -finline-functions is enabled, and the inlining params have been changed so that it has been tuned for -Os and csibe http://www.csibe.org/. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24947
[Bug libfortran/24794] problem with namelist input of character array
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2005-11-20 02:00 --- Patch submitted for review and approval. Christoph, thankyou for submitting this PR and the example case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24794
[Bug c++/24948] New: lookup chooses the wrong overload
I believe gcc is in error for calling the int* overload in the program below.
Sorry if this is a duplicate -- I went through the many lookup bugs in Bugzilla
but none of them looked quite like this one.
$ cat t.cpp g++ -pedantic -W t.cpp ./a.out
#include assert.h
int foo (void*) { return 0; }
template class T int bar (T *p) { return foo (p); }
int foo (int*) { return 1; }
int main ()
{
assert (0 == bar ((int*)0));
}
Assertion failed: 0 == bar ((int*)0), file t.cpp, line 9
Abort (core dumped)
--
Summary: lookup chooses the wrong overload
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
GCC build triplet: all
GCC host triplet: all
GCC target triplet: all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24948
[Bug c++/24948] lookup chooses the wrong overload
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-20 03:04 --- This was fixed by the same patch which fixed PR 2922. The issue was that GCC was not keeping track of the overloaded set. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||2922 Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24948
[Bug rtl-optimization/24930] [4.0/4.1 Regression] Crash in combine
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-20 03:06 --- I bootstraped and tested this on x86_64-linux-gnu with no regressions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24930
[Bug debug/24943] [hppa64] Bad dwarf output using non-preserved base register
--- Comment #1 from tausq at debian dot org 2005-11-20 03:38 --- I forgot to mention that the above was compiled with gcc -g -o dwarfbug dwarfbug.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24943
[Bug target/24949] New: FAIL: gcc.c-torture/compile/20000403-2.c -O0
With 4.1, gcc.c-torture/compile/2403-2.c fails
Here is a slightly reduced test case.
void
foo (long long tmp)
{
tmp = tmp 32;
}
2403-2.c: In function 'foo':
2403-2.c:5: error: unrecognizable insn:
(insn 8 6 9 1 (set (mem/c/i:DI (reg/f:SI 25 virtual-incoming-args) [0 tmp+0 S8
A32])
(ashiftrt:DI (mem/c/i:DI (reg/f:SI 25 virtual-incoming-args) [0 tmp+0
S8 A32])
(const_int 32 [0x20]))) -1 (nil)
(nil))
2403-2.c:5: internal compiler error: in extract_insn, at recog.c:2084
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
--
Summary: FAIL: gcc.c-torture/compile/2403-2.c -O0
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at gcc dot gnu dot org
GCC target triplet: m68k-none-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24949
[Bug tree-optimization/24665] [4.0/4.1 Regression] internal compiler error: get_indirect_ref_operands
--- Comment #6 from rth at gcc dot gnu dot org 2005-11-20 05:37 --- Subject: Bug 24665 Author: rth Date: Sun Nov 20 05:37:08 2005 New Revision: 107244 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107244 Log: PR tree-opt/24665 * tree-gimple.c (is_gimple_id): Export. * tree-gimple.h (is_gimple_id): Declare. * tree-ssa-ccp.c (ccp_decl_initial_min_invariant): New. (get_default_value): Use it. (maybe_fold_stmt_indirect): Likewise. Added: trunk/gcc/testsuite/g++.dg/opt/pr24665.C Modified: trunk/gcc/ChangeLog trunk/gcc/tree-gimple.c trunk/gcc/tree-gimple.h trunk/gcc/tree-ssa-ccp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24665
[Bug target/21578] ICE in reload_cse_simplify_operands for Coldfire.
--- Comment #5 from corsepiu at gcc dot gnu dot org 2005-11-20 05:38 --- (In reply to comment #4) Is this still reproducible? A quick check with m68k-none-elf did not reproduce the ICE. Confirmed, I can't reproduce it with my latest rtems-toolchain: m68k-rtems4.7-gcc (GCC) 4.0.1 (RTEMS gcc-4.0.1-20050727/newlib-1.13.0-20050912 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21578
[Bug target/24757] [4.1 Regression] __sync_fetch_and_add on ia64
--- Comment #32 from rth at gcc dot gnu dot org 2005-11-20 05:43 --- Oh good grief. I can't see the forest for the trees. Andreas, I expect that patch will work. If it tests ok, please commit it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24757
[Bug target/22082] Can't link 64-bit shared libraries with Xcode 2.1
--- Comment #32 from lucier at math dot purdue dot edu 2005-11-20 07:13 --- Subject: Re: Can't link 64-bit shared libraries with Xcode 2.1 On Nov 19, 2005, at 1:50 AM, lucier at math dot purdue dot edu wrote: Can you explain what Apple's libtool has to do with it? Is it used by gcc to find these libraries at link time? Sorry, dumb question. Brad -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22082
