[Bug fortran/34325] Wrong error message for syntax error
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-12-19 05:59 --- Fixed on trunk -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34325
[Bug fortran/34325] Wrong error message for syntax error
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-12-19 05:59 --- Subject: Bug 34325 Author: jvdelisle Date: Wed Dec 19 05:58:53 2007 New Revision: 131053 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131053 Log: 2007-12-19 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/34325 * gfortran.dg/missing_parens_1.f90: New. * gfortran.dg/missing_parens_1.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/missing_parens_1.f90 trunk/gcc/testsuite/gfortran.dg/missing_parens_2.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34325
[Bug fortran/34325] Wrong error message for syntax error
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-12-19 05:55
---
Subject: Bug 34325
Author: jvdelisle
Date: Wed Dec 19 05:55:17 2007
New Revision: 131052
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131052
Log:
2007-12-19 Jerry DeLisle <[EMAIL PROTECTED]>
PR fortran/34325
* match.h: New function declaration.
* match.c (gfc_match_parens): New function to look for mismatched
parenthesis. (gfc_match_if): Use new function to catch missing '('.
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/match.c
trunk/gcc/fortran/match.h
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34325
[Bug target/30572] [4.3 Regression] target libraries links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib
--- Comment #21 from howarth at nitro dot med dot uc dot edu 2007-12-19 04:38 --- The counter proposal doesn't work. It produces... [Macintosh:darwin_objdir/i686-apple-darwin9/libgcc] howarth% otool -L libgcc_s.1.dylib libgcc_s.1.dylib: @slibdir@/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30572
[Bug target/29472] [4.0/4.1/4.2 Regression] in reload, at reload1.c:1081 on m68k with -O2 -fPIC
--- Comment #6 from tbm at cyrius dot com 2007-12-19 02:34 --- (In reply to comment #4) > Breakpoint 1, fancy_abort (file=0x803da8 "gcc/reload1.c", line=1086, > function=0x803be1 "reload") at gcc/diagnostic.c:640 This was with 4.2 (from SVN). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29472
[Bug target/29474] [4.1/4.2 Regression] reload_cse_simplify_operands, at postreload.c:393 on m68k with -O -fPIC
--- Comment #7 from tbm at cyrius dot com 2007-12-19 02:34 --- Works with 4.3.0 20071219. -- tbm at cyrius dot com changed: What|Removed |Added Summary|[4.1/4.2/4.3 Regression]|[4.1/4.2 Regression] |reload_cse_simplify_operands|reload_cse_simplify_operands |, at postreload.c:393 on|, at postreload.c:393 on |m68k with -O -fPIC |m68k with -O -fPIC http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29474
[Bug target/29472] [4.0/4.1/4.2 Regression] in reload, at reload1.c:1081 on m68k with -O2 -fPIC
--- Comment #5 from tbm at cyrius dot com 2007-12-19 02:33 --- works with 4.3.0 20071219. -- tbm at cyrius dot com changed: What|Removed |Added Summary|[4.0/4.1/4.2/4.3 Regression]|[4.0/4.1/4.2 Regression] in |in reload, at reload1.c:1081|reload, at reload1.c:1081 on |on m68k with -O2 -fPIC |m68k with -O2 -fPIC http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29472
[Bug target/34393] ICE: in extract_insn, at recog.c:1990
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-12-19 02:14 --- Also fails on powerpc-linux-gnu. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|powerpc-apple-darwin9 | GCC host triplet|powerpc-apple-darwin9 | GCC target triplet|powerpc-apple-darwin9 |powerpc-apple-darwin9, ||powerpc-linux-gnu Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2007-12-19 02:14:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34393
[Bug fortran/34482] FAIL: gfortran.dg/nan_4.f90 -O tests for errors
--- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca 2007-12-19 02:14 --- Subject: Re: FAIL: gfortran.dg/nan_4.f90 -O tests for errors > Patch: http://gcc.gnu.org/ml/fortran/2007-12/msg00214.html Tested second version posted and it fixes the fail on hppa-unknown-linux-gnu. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34482
[Bug target/29474] [4.1/4.2/4.3 Regression] reload_cse_simplify_operands, at postreload.c:393 on m68k with -O -fPIC
--- Comment #6 from tbm at cyrius dot com 2007-12-19 02:07 ---
(gdb) run -O -fPIC -quiet ~/vtk-vtkImageMaskBits.ii
Starting program: /home/tbm/tmp/gcc/gcc-4.2-m68k-20071218-r131051/gcc/cc1plus
-O -fPIC -quiet ~/vtk-vt
kImageMaskBits.ii
/home/tbm/vtk-vtkImageMaskBits.ii: In function âvoid
vtkImageMaskBitsExecute(vtkImageMaskBits*, vtkIma
geData*, vtkImageData*, int*, int, T*) [with T = short unsigned int]â:
/home/tbm/vtk-vtkImageMaskBits.ii:33352: error: insn does not satisfy its
constraints:
(insn 207 446 208 26 (set (reg:HI 0 %d0 [88])
(and:HI (mem:HI (reg:SI 11 %a3) [0 S2 A16])
(reg:HI 0 %d0 [orig:87+2 ] [87]))) 238 {andhi3}
(insn_list:REG_DEP_TRUE 206 (nil))
(nil))
Breakpoint 1, fancy_abort (file=0x81fc58 "gcc/postreload.c", line=392,
function=0x820120 "reload_cse_simplify_operands")
at gcc/diagnostic.c:640
640 {
(gdb) where
#0 fancy_abort (file=0x81fc58 "gcc/postreload.c", line=392,
function=0x820120 "reload_cse_simplify_operands")
at gcc/diagnostic.c:640
#1 0x0066dd82 in _fatal_insn (msgid=,
insn=0x2b7589b46820,
file=0x81fc58 "gcc/postreload.c", line=392,
function=0x820120 "reload_cse_simplify_operands")
at gcc/rtl-error.c:119
#2 0x0066ddc7 in _fatal_insn_not_found (insn=0x188,
file=0x820120 "reload_cse_simplify_operands", line=10,
function=0x )
at gcc/rtl-error.c:129
#3 0x0072c7a7 in reload_cse_simplify_operands (insn=0x2b7589b46820,
testreg=0x2b7589b5f360)
at gcc/postreload.c:392
#4 0x0072c932 in reload_cse_regs_1 (first=0x)
at gcc/postreload.c:171
#5 0x0072c9a8 in reload_cse_regs (first=0x81fc58)
at gcc/postreload.c:67
#6 0x0072d7b1 in rest_of_handle_postreload ()
at gcc/postreload.c:1578
#7 0x006a0408 in execute_one_pass (pass=0x98c3e0)
at gcc/passes.c:881
#8 0x006a056c in execute_pass_list (pass=0x98c3e0)
at gcc/passes.c:932
#9 0x006a057e in execute_pass_list (pass=0x98aa60)
at gcc/passes.c:933
---Type to continue, or q to quit---
#10 0x006a057e in execute_pass_list (pass=0x98aa00)
at gcc/passes.c:933
#11 0x004d0a1e in tree_rest_of_compilation (fndecl=0x2b758948ee00)
at gcc/tree-optimize.c:462
#12 0x00473949 in expand_body (fn=0x2b758948ee00)
at gcc/cp/semantics.c:3095
#13 0x006cb374 in cgraph_expand_function (node=0x2b7589596f00)
at gcc/cgraphunit.c:1243
#14 0x006cbcb5 in cgraph_optimize () at gcc/cgraphunit.c:1308
#15 0x004414af in cp_finish_file () at gcc/cp/decl2.c:3355
#16 0x004b64ba in c_common_parse_file (set_yydebug=)
at gcc/c-opts.c:1182
#17 0x00682628 in toplev_main (argc=, argv=)
at gcc/toplev.c:1032
#18 0x2b758670a4ca in __libc_start_main () from /lib/libc.so.6
#19 0x0040273a in _start () at ../sysdeps/x86_64/elf/start.S:113
(gdb)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29474
[Bug target/29472] [4.0/4.1/4.2/4.3 Regression] in reload, at reload1.c:1081 on m68k with -O2 -fPIC
--- Comment #4 from tbm at cyrius dot com 2007-12-19 02:04 ---
Breakpoint 1, fancy_abort (file=0x803da8 "gcc/reload1.c", line=1086,
function=0x803be1 "reload") at gcc/diagnostic.c:640
640 {
(gdb) where
#0 fancy_abort (file=0x803da8 "gcc/reload1.c", line=1086,
function=0x803be1 "reload") at gcc/diagnostic.c:640
#1 0x00668070 in reload (first=0x2ae9c3a13ac0, global=1)
at gcc/reload1.c:1086
#2 0x007253a7 in rest_of_handle_global_alloc ()
at gcc/global.c:626
#3 0x006a0408 in execute_one_pass (pass=0x98c1a0)
at gcc/passes.c:881
#4 0x006a056c in execute_pass_list (pass=0x98c1a0)
at gcc/passes.c:932
#5 0x006a057e in execute_pass_list (pass=0x98aa00)
at gcc/passes.c:933
#6 0x004d0a1e in tree_rest_of_compilation (fndecl=0x2ae9c39d9e00)
at gcc/tree-optimize.c:462
#7 0x00473949 in expand_body (fn=0x2ae9c39d9e00)
at gcc/cp/semantics.c:3095
#8 0x006cb374 in cgraph_expand_function (node=0x2ae9c39ea240)
at gcc/cgraphunit.c:1243
#9 0x006cbcb5 in cgraph_optimize () at gcc/cgraphunit.c:1308
#10 0x004414af in cp_finish_file () at gcc/cp/decl2.c:3355
#11 0x004b64ba in c_common_parse_file (set_yydebug=)
at gcc/c-opts.c:1182
#12 0x00682628 in toplev_main (argc=, argv=)
at gcc/toplev.c:1032
#13 0x2ae9c351b4ca in __libc_start_main () from /lib/libc.so.6
#14 0x0040273a in _start () at ../sysdeps/x86_64/elf/start.S:113
(gdb)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29472
[Bug tree-optimization/30194] [4.3 Regression] gcc.dg/pr19633-1.c fails on the mainline
--- Comment #15 from danglin at gcc dot gnu dot org 2007-12-19 01:52 --- This went away in mid July on hppa. -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC|danglin at gcc dot gnu dot | |org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30194
[Bug rtl-optimization/34529] [4.1/4.2/4.3 Regression] Wrong code with altivec stores and offsets
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-12-19 01:28 --- 4.0.2 works: ld 9,[EMAIL PROTECTED](2) li 11,-29264 stvx 2,9,11 In 32bit mode for 4.0.3: lis 9,[EMAIL PROTECTED] la 9,[EMAIL PROTECTED](9) li 11,-29264 stvx 0,9,11 32bits, 4.1.0: lis 9,0x8 ori 9,9,36272 add 9,9,9 stvx 2,0,9 -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |critical GCC target triplet|powerpc64-linux-gnu |powerpc*-linux-gnu Known to fail||4.1.1 4.2.0 4.3.0 Known to work||4.0.3 Summary|Wrong code with altivec |[4.1/4.2/4.3 Regression] |stores and offsets |Wrong code with altivec ||stores and offsets Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34529
[Bug fortran/24978] ICE in gfc_assign_data_value_range
--- Comment #11 from dfranke at gcc dot gnu dot org 2007-12-19 00:53 --- Having a look ... -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Known to fail|4.0.2 4.1.0 |4.0.2 4.1.2 4.3.0 Last reconfirmed|2006-10-29 16:47:07 |2007-12-19 00:53:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24978
[Bug rtl-optimization/34529] Wrong code with altivec stores and offsets
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-12-19 00:35 ---
Note here is a better testcase which clobbers all the usable registers:
static vector float b[560560];
void f(void);
vector float Mult(vector float a)
{
b[560560/16] = a;
asm
("":::"memory","0","3","4","5","6","7","8","9","10","11","12","14","15","16","17","18","19","20","21","22","23","24","25","26","27","28","29",
"lr", "30", "31", "ctr");
b[560560/16] = a;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34529
[Bug rtl-optimization/34529] Wrong code with altivec stores and offsets
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-12-19 00:25 ---
After reload we have:
(insn 35 10 37 2 t.c:9 (set (reg:SI 9 9)
(reg/f:SI 65 lr [122])) 325 {*movsi_internal1} (nil))
(insn 37 35 38 2 t.c:9 (set (reg:SI 9 9)
(const_int 560560 [0x88db0])) 325 {*movsi_internal1} (nil))
(insn 38 37 13 2 t.c:9 (set (reg:SI 9 9)
(plus:SI (reg:SI 9 9)
(reg:SI 9 9))) 79 {*addsi3_internal1} (expr_list:REG_EQUIV (plus:SI
(reg:SI 9 9)
(const_int 560560 [0x88db0]))
(nil)))
(insn:HI 13 38 16 2 t.c:9 (set (mem/s:V4SF (reg:SI 9 9) [3 b+560560 S16 A128])
(reg/v:V4SF 77 0 [orig:121 a ] [121])) 655 {altivec_stvx_v4sf} (nil))
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34529
[Bug rtl-optimization/34529] Wrong code with altivec and offsets
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-19 00:23 --- I forgot to say compile this code with -maltivec -include altivec.h -O2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34529
[Bug rtl-optimization/34529] New: Wrong code with altivec and offsets
Testcase:
vector float b[560560];
vector float c[560560];
void f(void);
vector float Mult(vector float a)
{
b[560560/16] = a;
asm
("":::"memory","0","3","4","5","6","7","8","9","10","11","12","14","15","16","17","18","19","20","21","22","23","24","25","26","27","28","29");
b[560560/16] = a;
}
CUT
We get:
lis 9,0x8
ori 9,9,36272
add 9,9,9
stvx 0,0,9
Which is obviously wrong.
--
Summary: Wrong code with altivec and offsets
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: powerpc64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34529
[Bug fortran/34528] New: Document internal structure of arrays
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/80093a381db184c6/ This interface is needed if one wants pass an array descriptor to C; other vendors have such a documentation as well. It should come with a note that the interface may change between versions. Other compilers have this as well, e.g, http://www.intel.com/software/products/compilers/docs/flin/main_for/mergedProjects/bldaps_for/common/bldaps_hndl_arrdesc.htm If not for the gfortran documentation, one could add it to gfortran-internal. -- Summary: Document internal structure of arrays Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: documentation Severity: enhancement 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=34528
[Bug fortran/34527] New: Declaring a variable twice with different characteristics
The following is invalid and rejected using -std=f2003, but I wonder whether one should not also reject it otherwise? What is the string length? function a(n,m) integer :: n,m character(n) a character(m) a end ifort and g95 reject it always. * * * If one wants to add only a check whether the variables are the same, one could use the same check for: function a(n,m) integer :: n,m character(n) a character(m) b entry b(n,m) end NAG f95 and ifort reject this with: - Incompatible character length for ENTRY B of function A - The characteristics of the function named on the ENTRY statement are different from the characteristics of the result of the function named on the FUNCTION statement. gfortran currently (PR34421) accepts this for non-constant expressions. -- Summary: Declaring a variable twice with different characteristics Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: accepts-invalid 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=34527
[Bug c++/34094] [4.2/4.3 Regression] Undefined static data member in anonymous namespace can acquire a definition anyway
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-12-18 23:52 --- (In reply to comment #12) > Note that the simple class is correct, but the template instance is not. Well it was reverted :). See PR 34238 for the reasons why. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||34238 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34094
[Bug c++/34094] [4.2/4.3 Regression] Undefined static data member in anonymous namespace can acquire a definition anyway
--- Comment #12 from crowl at google dot com 2007-12-18 23:46 ---
I think the last fix is incomplete:
namespace {
struct simple { static const int size = 4; };
template< typename T >
struct generic { static const int size = 4; };
}
struct instantiate {
simple simple_var;
generic< int > generic_var;
};
member.cc:4: error: static data member '::generic::size' used,
but not defined
Note that the simple class is correct, but the template instance is not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34094
[Bug fortran/34495] [4.3 Regression] accepts invalid initialization expressions withTRANSFER
-- dfranke at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/fortra ||n/2007-12/msg00236.html Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34495
[Bug fortran/34495] [4.3 Regression] accepts invalid initialization expressions withTRANSFER
--- Comment #10 from dfranke at gcc dot gnu dot org 2007-12-18 23:41 --- Fixed in trunk. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34495
[Bug fortran/34495] [4.3 Regression] accepts invalid initialization expressions withTRANSFER
--- Comment #9 from dfranke at gcc dot gnu dot org 2007-12-18 23:40 --- Subject: Bug 34495 Author: dfranke Date: Tue Dec 18 23:39:56 2007 New Revision: 131047 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131047 Log: gcc/fortran: 2007-12-19 Daniel Franke <[EMAIL PROTECTED]> PR fortran/34495 * expr.c (check_init_expr): Check whether variables with flavor FL_PARAMETER do have a value assigned. Added error messages where appropriate. * simplify.c (gfc_simplify_transfer): Added check if the MOLD argument is a constant if working with initialization expressions. gcc/testsuite: 2007-12-19 Daniel Franke <[EMAIL PROTECTED]> PR fortran/34495 * gfortran.dg/transfer_simplify_2.f90: Fixed invalid initialization expressions. * gfortran.dg/transfer_simplify_7.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/transfer_simplify_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/transfer_simplify_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34495
[Bug target/18346] [4.0/4.1/4.2/4.3 regression] mmix-knuth-mmixware testsuite failure: gcc.dg/trampoline-1.c
--- Comment #8 from hp at gcc dot gnu dot org 2007-12-18 23:33 --- Fails the same way with 130591. No closing, thankyouverymuch. -- hp at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2005-10-24 02:55:13 |2007-12-18 23:33:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18346
[Bug tree-optimization/31081] [4.3 Regression] Inliner messes up SSA for abnormals
--- Comment #14 from jakub at gcc dot gnu dot org 2007-12-18 23:31 --- Zero initialization would work, sure. I was just worried if it wouldn't result in code pessimization. The var in the testcase is only unitialized if exception is thrown, and exceptions should be exceptional. But the zero initialization will be executed even when no exceptions are thrown. Couldn't we e.g. zero initialize it only on the EH edges from bbs where it was uninitialized? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31081
[Bug middle-end/29609] [4.1/4.2/4.3 Regression] Even with -O0 -g gcc optimizes a goto away and I cannot debug
--- Comment #5 from steven at gcc dot gnu dot org 2007-12-18 23:31 --- xf. http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01789.html I was wrong to object to this patch -- there really doesn't seem to be any other way. It's funny, on the one hand we complain about the code quality of -O0, but on the other we have to do quite silly things such as adding jumps to jumps to keep rather important debug information around... Olivier, any chance someone at AdaCore can pick this up and re-submit it to gcc-patches? -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||hainque at gcc dot gnu dot ||org Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29609
[Bug target/18335] [4.0/4.1/4.2/4.3 regression] mmix-knuth-mmixware testsuite failure: gcc.dg/debug/debug-1.c and debug-2 xyzzy
--- Comment #7 from hp at gcc dot gnu dot org 2007-12-18 23:29 --- This bug was in NEW, not WAITING. It's meant as a note, not a request for someone else to fix it. thankyou. Fails the same way with r130591, FWIW. -- hp at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18335
[Bug rtl-optimization/18485] [4.0/4.1/4.2/4.3 regression] mmix-knuth-mmixware testsuite failure: g++.dg/lookup/forscope1.C g++.old-deja/g++.niklas/t132.C g++.old-deja/g++.other/singleton.C
--- Comment #10 from hp at gcc dot gnu dot org 2007-12-18 23:20 --- These tests do not fail and no gcc or g++ test fail with the same error with r130591, so best to close this one. FWIW, instructions are at simtest-howto.html (I've given personal instructions at least once). -- hp at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18485
[Bug tree-optimization/30194] [4.3 Regression] gcc.dg/pr19633-1.c fails on the mainline
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30194
[Bug tree-optimization/30194] [4.3 Regression] gcc.dg/pr19633-1.c fails on the mainline
--- Comment #14 from steven at gcc dot gnu dot org 2007-12-18 23:17 --- Dave, Does the test case pass again if you increase the VOPS threshold once more? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30194
[Bug libgomp/34519] pr26943-2.c is regressed on mainline
--- Comment #5 from ismail at pardus dot org dot tr 2007-12-18 23:11 --- Re-tested with no problems now, but machine was under %300 load when this test failed. Interestingly rest of the regtests passed fine. Anyway this is invalid. Thanks for the attention. -- ismail at pardus dot org dot tr changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34519
[Bug c++/34111] [4.3 Regression] new overload resolution error
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-11-15 23:17:52 |2007-12-18 22:45:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34111
[Bug c++/34206] [4.3 Regression] ICE in retrieve_local_specialization
--- Comment #6 from jason at gcc dot gnu dot org 2007-12-18 22:44 --- fixed -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34206
[Bug fortran/34203] Treat \ as normal character (at least on Windows); diagnose unrecognized escape characters
--- Comment #11 from tkoenig at gcc dot gnu dot org 2007-12-18 22:27 --- This is fixed on trunk, isn't it? Closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34203
[Bug c++/34206] [4.3 Regression] ICE in retrieve_local_specialization
--- Comment #5 from jason at gcc dot gnu dot org 2007-12-18 22:25 --- Subject: Bug 34206 Author: jason Date: Tue Dec 18 22:25:20 2007 New Revision: 131044 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131044 Log: PR c++/34206 * pt.c (tsubst_aggr_type): Do nothing if the type already doesn't use template parms. (dependent_type_p_r): Handle the domain of an array. Added: trunk/gcc/testsuite/g++.dg/template/typedef8.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34206
[Bug c++/33965] internal compiler error: tree check: expected class 'type', have 'constant' (integer_cst) in cp_type_quals, at cp/typeck.c:6955 (vararg templates)
--- Comment #3 from dgregor at gcc dot gnu dot org 2007-12-18 22:16 --- Fixed on the trunk -- dgregor at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33965
[Bug c++/33943] [4.3 Regression] ICE with partial specialization on vararg template template parameter
--- Comment #9 from dgregor at gcc dot gnu dot org 2007-12-18 22:15 --- Fixed on the trunk -- dgregor at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33943
[Bug c++/32565] [4.3 regression] ICE with specialization of variadic template
--- Comment #4 from dgregor at gcc dot gnu dot org 2007-12-18 22:15 --- Fixed on the trunk -- dgregor at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32565
[Bug target/34526] New: no-altivec ABI should be fixed or no longer be the default
This PR is meant to be a central place to record information about this issue. The default ABI for 32-bit PowerPC GNU/Linux does not pass vectors in AltiVec registers and does not save and restore AltiVec registers in functions that use those registers. With -mabi=altivec, vectors are passed in AltiVec registers and AltiVec registers used within a function are saved and restored. This has always been a problem if multiple functions in a call chain use AltiVec registers without the AltiVec ABI, but it's become a more visible issue with -ftree-vectorize included in -O3, particularly when the user specifies a CPU that supports AltiVec and might not realize that those two options imply that AltiVec registers will likely be used in multiple functions in a call stack without saving and restoring them. Two recent PRs that are due to this problem are 34038 and 34437. A somewhat-rel ated PR is 33899. There were some recent discussions of this issue: http://gcc.gnu.org/ml/gcc-patches/2007-07/msg02159.html http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00438.html This ought to be fixed either by using the AltiVec ABI by default or by changing the non-AltiVec ABI to save and restore AltiVec registers in functions that use them. -- Summary: no-altivec ABI should be fixed or no longer be the default Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janis at gcc dot gnu dot org GCC target triplet: powerpc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34526
[Bug c++/33943] [4.3 Regression] ICE with partial specialization on vararg template template parameter
--- Comment #8 from dgregor at gcc dot gnu dot org 2007-12-18 21:19 --- Subject: Bug 33943 Author: dgregor Date: Tue Dec 18 21:19:41 2007 New Revision: 131041 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131041 Log: 2007-12-18 Douglas Gregor <[EMAIL PROTECTED]> Jakub Jelinek <[EMAIL PROTECTED]> PR c++/32565 PR c++/33943 PR c++/33965 * pt.c (template_template_parm_bindings_ok_p): New; verifies bindings of template template parameters after all template arguments have been deduced. (coerce_template_parms): Don't complain when COMPLAIN doesn't include tf_error. (fn_type_unification): Use template_template_parm_bindings_ok_p. (unify): Deal with variadic, bound template template parameters. (get_class_bindings): Use template_template_parm_bindings_ok_p. 2007-12-18 Douglas Gregor <[EMAIL PROTECTED]> Jakub Jelinek <[EMAIL PROTECTED]> PR c++/32565 PR c++/33943 PR c++/33965 * g++.dg/cpp0x/variadic86.C: New. * g++.dg/cpp0x/variadic87.C: New. * g++.dg/cpp0x/variadic84.C: New. * g++.dg/cpp0x/variadic85.C: New. * g++.dg/template/ttp25.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/variadic84.C trunk/gcc/testsuite/g++.dg/cpp0x/variadic85.C trunk/gcc/testsuite/g++.dg/cpp0x/variadic86.C trunk/gcc/testsuite/g++.dg/cpp0x/variadic87.C trunk/gcc/testsuite/g++.dg/template/ttp25.C Modified: trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33943
[Bug c++/33965] internal compiler error: tree check: expected class 'type', have 'constant' (integer_cst) in cp_type_quals, at cp/typeck.c:6955 (vararg templates)
--- Comment #2 from dgregor at gcc dot gnu dot org 2007-12-18 21:19 --- Subject: Bug 33965 Author: dgregor Date: Tue Dec 18 21:19:41 2007 New Revision: 131041 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131041 Log: 2007-12-18 Douglas Gregor <[EMAIL PROTECTED]> Jakub Jelinek <[EMAIL PROTECTED]> PR c++/32565 PR c++/33943 PR c++/33965 * pt.c (template_template_parm_bindings_ok_p): New; verifies bindings of template template parameters after all template arguments have been deduced. (coerce_template_parms): Don't complain when COMPLAIN doesn't include tf_error. (fn_type_unification): Use template_template_parm_bindings_ok_p. (unify): Deal with variadic, bound template template parameters. (get_class_bindings): Use template_template_parm_bindings_ok_p. 2007-12-18 Douglas Gregor <[EMAIL PROTECTED]> Jakub Jelinek <[EMAIL PROTECTED]> PR c++/32565 PR c++/33943 PR c++/33965 * g++.dg/cpp0x/variadic86.C: New. * g++.dg/cpp0x/variadic87.C: New. * g++.dg/cpp0x/variadic84.C: New. * g++.dg/cpp0x/variadic85.C: New. * g++.dg/template/ttp25.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/variadic84.C trunk/gcc/testsuite/g++.dg/cpp0x/variadic85.C trunk/gcc/testsuite/g++.dg/cpp0x/variadic86.C trunk/gcc/testsuite/g++.dg/cpp0x/variadic87.C trunk/gcc/testsuite/g++.dg/template/ttp25.C Modified: trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33965
[Bug c++/32565] [4.3 regression] ICE with specialization of variadic template
--- Comment #3 from dgregor at gcc dot gnu dot org 2007-12-18 21:19 --- Subject: Bug 32565 Author: dgregor Date: Tue Dec 18 21:19:41 2007 New Revision: 131041 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131041 Log: 2007-12-18 Douglas Gregor <[EMAIL PROTECTED]> Jakub Jelinek <[EMAIL PROTECTED]> PR c++/32565 PR c++/33943 PR c++/33965 * pt.c (template_template_parm_bindings_ok_p): New; verifies bindings of template template parameters after all template arguments have been deduced. (coerce_template_parms): Don't complain when COMPLAIN doesn't include tf_error. (fn_type_unification): Use template_template_parm_bindings_ok_p. (unify): Deal with variadic, bound template template parameters. (get_class_bindings): Use template_template_parm_bindings_ok_p. 2007-12-18 Douglas Gregor <[EMAIL PROTECTED]> Jakub Jelinek <[EMAIL PROTECTED]> PR c++/32565 PR c++/33943 PR c++/33965 * g++.dg/cpp0x/variadic86.C: New. * g++.dg/cpp0x/variadic87.C: New. * g++.dg/cpp0x/variadic84.C: New. * g++.dg/cpp0x/variadic85.C: New. * g++.dg/template/ttp25.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/variadic84.C trunk/gcc/testsuite/g++.dg/cpp0x/variadic85.C trunk/gcc/testsuite/g++.dg/cpp0x/variadic86.C trunk/gcc/testsuite/g++.dg/cpp0x/variadic87.C trunk/gcc/testsuite/g++.dg/template/ttp25.C Modified: trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32565
[Bug rtl-optimization/18485] [4.0/4.1/4.2/4.3 regression] mmix-knuth-mmixware testsuite failure: g++.dg/lookup/forscope1.C g++.old-deja/g++.niklas/t132.C g++.old-deja/g++.other/singleton.C
--- Comment #9 from steven at gcc dot gnu dot org 2007-12-18 20:35 --- Control flow graph handling has changed significantly in GCC 4.3. Could someone try this with a recent snapshot from the trunk? If the bug still exists, please assign it to me and provide me with some instructions on how to reproduce it with a cross-compiler. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18485
[Bug target/29474] [4.1/4.2/4.3 Regression] reload_cse_simplify_operands, at postreload.c:393 on m68k with -O -fPIC
--- Comment #5 from steven at gcc dot gnu dot org 2007-12-18 20:34 --- Martin, is this a bug you can still reproduce with the current SVN trunk? If so, could you provide a backtrace from gdb? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29474
[Bug target/29472] [4.0/4.1/4.2/4.3 Regression] in reload, at reload1.c:1081 on m68k with -O2 -fPIC
--- Comment #3 from steven at gcc dot gnu dot org 2007-12-18 20:33 --- Martin, is this a bug you can still reproduce with the current SVN trunk? If so, could you provide a backtrace from gdb? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29472
[Bug target/26015] [4.1/4.2/4.3 Regression] ICE during bootstrap for vax architecture
--- Comment #9 from steven at gcc dot gnu dot org 2007-12-18 20:31 --- Based on comment #8, the patch of comment #6 should probably be committed. Jim, do you have plans to take care of this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26015
[Bug target/25343] [4.0/4.1/4.2/4.3 regression] [m68k] testsuite failures
--- Comment #4 from steven at gcc dot gnu dot org 2007-12-18 20:29 --- See http://gcc.gnu.org/ml/gcc-testresults/2007-10/msg01406.html for recent test suite results. The first three failures are gone, as observed by Andreas too. The largefile.c failures still exist. But as Andrew pointed out, the reason could be that PCH is not fully implemented for m68k. Might I suggest WONTFIX to resolve this bug? -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-12-18 20:29:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25343
[Bug target/24334] [4.0/4.1/4.2/4.3 regression] IRIX 6.5 bootstrap failure with SGI 7.4.3m ld: GOT overflow
--- Comment #9 from steven at gcc dot gnu dot org 2007-12-18 20:23 --- Not sure what to do with this one. Rainer, can you live with WONTFIX? :-) -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-12-18 20:23:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24334
[Bug c++/21312] [4.0/4.1/4.2/4.3 Regression] Access violation diagnostic given twice
--- Comment #9 from steven at gcc dot gnu dot org 2007-12-18 20:20 --- Outline/plan for a fix here: http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00354.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21312
[Bug target/18335] [4.0/4.1/4.2/4.3 regression] mmix-knuth-mmixware testsuite failure: gcc.dg/debug/debug-1.c and debug-2 xyzzy
--- Comment #6 from steven at gcc dot gnu dot org 2007-12-18 20:18 --- Last seen to work: 3.5 years ago. Progress on getting this fixed since: 0% Should anyone feel this bug ought to be fixed, I encourage the respected victim to work on a fix instead of waiting for it :-) -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18335
[Bug c++/17053] [4.0/4.1/4.2/4.3 Regression] Repo functionality partially broken on AIX (collect2.c)
--- Comment #17 from steven at gcc dot gnu dot org 2007-12-18 20:16 --- After three years of deafening silence, I'm sure closing this as WONTFIX will perhaps ignite protests from anyone on the CC: list who still cares about this one. Should that happen, I encourage the respected victim to get some motion in the process to resolve this bug :-) -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17053
[Bug libstdc++/34524] Use of invalidated std::string iterators not caught in debug mode
--- Comment #2 from gcc-bugzilla at contacts dot eelis dot net 2007-12-18 20:16 --- My apologies. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34524
[Bug other/15082] [4.0/4.1/4.2/4.3 regression] Minor compilation problem for cross to Solaris 8
--- Comment #21 from steven at gcc dot gnu dot org 2007-12-18 20:15 --- After three years of deafening silence, I'm sure closing this as WONTFIX will perhaps ignite protests from anyone on the CC: list who still cares about this one. Should that happen, I encourage the respected victim to get some motion in the process to resolve this bug :-) -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15082
[Bug target/34525] [4.3 Regression] ICE in extract_insn, at recog.c:1990 on hppa
--- Comment #1 from tbm at cyrius dot com 2007-12-18 20:15 --- Created an attachment (id=14791) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14791&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34525
[Bug target/34525] New: [4.3 Regression] ICE in extract_insn, at recog.c:1990 on hppa
With 4.3.0 20071212 on hppa:
[EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -O1 -fPIC
ffcall-trampoline.i
./trampoline.c: In function 'is_trampoline_r':
./trampoline.c:1176: error: unrecognizable insn:
(insn 10 9 11 4 ./trampoline.c:1168 (set (reg:SI 100)
(plus:SI (reg:SI 19 %r19)
(high:SI (symbol_ref/v:SI ("@tramp_r") [flags 0x41] -1 (nil))
./trampoline.c:1176: internal compiler error: in extract_insn, at recog.c:1990
Please submit a full bug report,
--
Summary: [4.3 Regression] ICE in extract_insn, at recog.c:1990 on
hppa
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com
GCC target triplet: hppa-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34525
[Bug tree-optimization/23835] [4.1/4.2/4.3 Regression] case where gcc 4.1/4.2/4.3.0 -O3 compile takes two times longer earlier versions
--- Comment #26 from steven at gcc dot gnu dot org 2007-12-18 20:09 --- Bring back on the radar for the release manager. New timings would be much appreciated. Anyone? -- steven at gcc dot gnu dot org changed: What|Removed |Added Priority|P4 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23835
[Bug c/23104] [4.1/4.2/4.3 Regression] C does not reject the same function in two different TUs with -combine
--- Comment #10 from steven at gcc dot gnu dot org 2007-12-18 20:06 --- As of today this is an ICE at least on Cygwin. cc1 segfaults during inlining. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23104
[Bug tree-optimization/17863] [4.0/4.1/4.2/4.3 Regression] performance loss (not inlining as much??)
--- Comment #33 from steven at gcc dot gnu dot org 2007-12-18 20:02 --- Honza, since you re-opened this, perhaps you can give new timings? -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |hubicka at gcc dot gnu dot |dot org |org Status|REOPENED|ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17863
[Bug libstdc++/34524] Use of invalidated std::string iterators not caught in debug mode
--- Comment #1 from pcarlini at suse dot de 2007-12-18 20:00 --- Did you read the documentation? http://gcc.gnu.org/onlinedocs/libstdc++/ext/debug_mode.html in a nutshell, our design doesn't provide safe iterators for basic_string. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34524
[Bug target/18346] [4.0/4.1/4.2/4.3 regression] mmix-knuth-mmixware testsuite failure: gcc.dg/trampoline-1.c
--- Comment #7 from steven at gcc dot gnu dot org 2007-12-18 19:59 --- 3.5 years with no progress whatsoever. Should probably closed as WONTFIX? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18346
[Bug middle-end/21953] [4.1/4.2/4.3 Regression] Many tmpdir-gcc.dg-struct-layout-1 tests fail on Tru64 UNIX V5.1B
--- Comment #9 from steven at gcc dot gnu dot org 2007-12-18 19:58 --- Nothing happened for almost two years. Perhaps we should close this kind of bug-goes-nowhere bug as WONTFIX? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21953
[Bug rtl-optimization/28011] [4.1/4.2 Regression] [SH] g++ generates wrong code, if '-fno-exceptions' and '-O' options are specified
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28011
[Bug objc/23709] [4.1/4.2/4.3 Regression] error recovery is not smart enough
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-12-18 19:52 --- (In reply to comment #4) > Patch was pre-OKed. Andrew, what happened next, did you commit it and is this > bug fixed already? Hmm, I had not got already to creating a new patch. This weekend should be a good weekend to do that :). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Last reconfirmed|2006-09-03 21:50:46 |2007-12-18 19:52:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23709
[Bug objc/23709] [4.1/4.2/4.3 Regression] error recovery is not smart enough
--- Comment #4 from steven at gcc dot gnu dot org 2007-12-18 19:44 --- Patch was pre-OKed. Andrew, what happened next, did you commit it and is this bug fixed already? -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23709
[Bug libstdc++/34524] New: Use of invalidated std::string iterators not caught in debug mode
In the following code, libstdc++'s debug mode does not catch the use of a
potentially invalidated std::string iterator.
#define _GLIBCXX_DEBUG
#define _GLIBCXX_DEBUG_PEDANTIC
#include
#include
#include
int main()
{
typedef std::string S;
S s (3, 'x');
S::iterator i = s.begin(); ++i;
s.push_back('y');
std::cout << *i << std::endl; // just outputs 'x'
}
Since the push_back may invalidate i (per 21.3 para 5, 4th item), libstdc++'s
debug mode should emit an error and abort.
If I change the typedef to std::vector, then the indicated line /does/
cause libstdc++ to emit an error ("attempt to dereference a singular iterator")
and abort.
--
Summary: Use of invalidated std::string iterators not caught in
debug mode
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34524
[Bug tree-optimization/34123] [4.3 Regression] verify_ssa failed with -ftree-loop-linear
--- Comment #8 from spop at gcc dot gnu dot org 2007-12-18 19:42 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34123
[Bug tree-optimization/34123] [4.3 Regression] verify_ssa failed with -ftree-loop-linear
--- Comment #7 from spop at gcc dot gnu dot org 2007-12-18 19:40 --- Subject: Bug 34123 Author: spop Date: Tue Dec 18 19:40:35 2007 New Revision: 131040 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131040 Log: 2007-12-18 Sebastian Pop <[EMAIL PROTECTED]> PR tree-optimization/34123 * lambda-code.c (can_duplicate_iv): New. (cannot_convert_modify_to_perfect_nest): New. (cannot_convert_bb_to_perfect_nest): New. (can_convert_to_perfect_nest): Split up. * gcc.dg/tree-ssa/pr34123.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr34123.c Modified: trunk/gcc/ChangeLog trunk/gcc/lambda-code.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34123
[Bug other/34520] fixincludes adjusts assert.h in such a way that it stays omnipotent
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Component|bootstrap |other GCC host triplet|alphaev67-dec-osf5.1b | GCC target triplet||alphaev67-dec-osf5.1b http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34520
[Bug libffi/29152] 64-bit darwin ppc port needed for libffi
--- Comment #5 from andreast at gcc dot gnu dot org 2007-12-18 19:07 --- Jack, you can try, but I think it is a bit wasted time. Well, depends on how long the process takes to get the patches from apple. [wolfram:gcc/head/objdir] andreast% file /usr/lib/libffi.dylib /usr/lib/libffi.dylib: Mach-O universal binary with 4 architectures /usr/lib/libffi.dylib (for architecture ppc7400): Mach-O dynamically linked shared library ppc /usr/lib/libffi.dylib (for architecture ppc64): Mach-O 64-bit dynamically linked shared library ppc64 /usr/lib/libffi.dylib (for architecture i386): Mach-O dynamically linked shared library i386 /usr/lib/libffi.dylib (for architecture x86_64):Mach-O 64-bit dynamically linked shared library x86_64 I will not spend any time on this issue except help out merging and testing. But as I do not have an own ppc64 I will only have limited interest atm. Maybe you understand... -- andreast at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-12-18 19:07:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29152
[Bug tree-optimization/31081] [4.3 Regression] Inliner messes up SSA for abnormals
--- Comment #13 from hubicka at gcc dot gnu dot org 2007-12-18 18:54 --- Sorry, my last comment was about different inliner issue that seems to be gone now. I guess easiest way around would be to initialize to 0 at the beggining of inlined function body? This happens only for uninitialized SSA registers (otherwise we can do renaming) that should not be at all that common and might result in better code than attempting to preserve the uninitialized values round functions. I will give it a try. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31081
[Bug tree-optimization/34355] ICE: invariant not recomputed when ADDR_EXPR changed with -ftree-parallelize-loops
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-12-06 10:37:11 |2007-12-18 18:51:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34355
[Bug tree-optimization/34330] -ftree-parallelize-loops=4 ICE with the vectorizer also
--- Comment #2 from rakdver at gcc dot gnu dot org 2007-12-18 18:51 --- I do not see a way how to fix this in 4.3, other than disabling vectorizer when parallelization is enabled, or vice versa. -- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|rakdver at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34330
[Bug rtl-optimization/17236] inefficient code for long long multiply on x86
--- Comment #16 from ubizjak at gmail dot com 2007-12-18 18:33 ---
(In reply to comment #15)
> Note two moves [(insn 36) and (insn 37)] around (insn 12).
Bah. This is the correct sequence, around (insn 10) that seems to be the root
of all problems:
(insn:HI 9 8 36 2 m.c:2 (parallel [
(set (reg:SI 2 cx [62])
(plus:SI (reg:SI 2 cx [62])
(reg:SI 0 ax [63])))
(clobber (reg:CC 17 flags))
]) 249 {*addsi_1} (nil))
(insn 36 9 10 2 m.c:2 (set (reg:SI 0 ax)
(reg:SI 4 si [orig:66 b ] [66])) 47 {*movsi_1} (nil))
(insn:HI 10 36 37 2 m.c:2 (parallel [
(set (reg:DI 0 ax)
(mult:DI (zero_extend:DI (reg:SI 0 ax))
(zero_extend:DI (reg:SI 3 bx [orig:64 a ] [64]
(clobber (reg:CC 17 flags))
]) 304 {*umulsidi3_insn} (nil))
(insn 37 10 11 2 m.c:2 (set (reg:DI 3 bx [61])
(reg:DI 0 ax)) 88 {*movdi_2} (nil))
DImode AX as found in (insn 10) could simply be propagated up and down RTL
stream as SImode destination of (insn 8) and SImode source of (insn 12). For
some reason, RA is afraid to allocate registers in mixed modes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17236
[Bug rtl-optimization/17236] inefficient code for long long multiply on x86
--- Comment #15 from ubizjak at gmail dot com 2007-12-18 18:20 ---
(In reply to comment #7)
> mull%ebx
> leal(%ecx,%edx), %esi ; what the heck, a simple addl could do!
> movl%esi, %edx
Something disturbs RA to emit two DImode moves:
(insn:HI 10 36 37 2 m.c:2 (parallel [
(set (reg:DI 0 ax)
(mult:DI (zero_extend:DI (reg:SI 0 ax))
(zero_extend:DI (reg:SI 3 bx [orig:64 a ] [64]
(clobber (reg:CC 17 flags))
]) 304 {*umulsidi3_insn} (nil))
(insn 37 10 11 2 m.c:2 (set (reg:DI 3 bx [61])
(reg:DI 0 ax)) 88 {*movdi_2} (nil))
(note:HI 11 37 12 2 NOTE_INSN_DELETED)
(insn:HI 12 11 18 2 m.c:2 (parallel [
(set (reg:SI 4 si [+4 ])
(plus:SI (reg:SI 2 cx [62])
(reg:SI 4 si [+4 ])))
(clobber (reg:CC 17 flags))
]) 249 {*addsi_1} (nil))
(insn:HI 18 12 24 2 m.c:4 (set (reg/i:DI 0 ax [ ])
(reg:DI 3 bx [61])) 88 {*movdi_2} (nil))
(insn 24 18 33 2 m.c:4 (use (reg/i:DI 0 ax [ ])) -1 (nil))
Note two moves [(insn 36) and (insn 37)] around (insn 12).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17236
[Bug libgcj/34521] SSLEngine - Clone not supported (Null pointer) exception
--- Comment #2 from csm at gnu dot org 2007-12-18 18:08 --- Created an attachment (id=14790) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14790&action=view) Test case Can you try running this test program in your setup? We should confirm first that this isn't a regression in GCJ -- based on your description, it looks like a 'clone()' call is failing on a String array, which should not happen. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34521
[Bug bootstrap/34523] New: configure does not recognize --with-cpu=arm926ejs but --with-cpu=arm926ej-s
checking whether sigaltstack is declared... yes checking for struct tms... yes checking for clock_t... yes checking for .preinit_array/.init_array/.fini_array support... no checking if mkdir takes one argument... no Unknown CPU used in --with-cpu=arm926ejs make[2]: *** [configure-stage1-gcc] Error 1 make[2]: Leaving directory `/scratch/gcc-4.2.2/objdir' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/scratch/gcc-4.2.2/objdir' make: *** [bootstrap] Error 2 Configure seems to mis-require a dash in the cpu. Please note the valid cpu allowed by the compiler is 'arm926ejs' while not 'arm926ej-s'. So, either configure is happy and the subsequent build process fails after stage1 is finished or vice versa. It seems it was possible to use --with-cpu=arm926ejs with 3.4.5 (bug #26378) so I believe this is a regression. -- Summary: configure does not recognize --with-cpu=arm926ejs but -- with-cpu=arm926ej-s Product: gcc Version: 4.2.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mmokrejs at ribosome dot natur dot cuni dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34523
[Bug libgcj/34521] SSLEngine - Clone not supported (Null pointer) exception
--- Comment #1 from csm at gnu dot org 2007-12-18 17:45 --- A CloneNotSupportedException is not a null pointer exception. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34521
[Bug libffi/29152] 64-bit darwin ppc port needed for libffi
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2007-12-18 17:14 --- Andreas, Can't we duplicate the existing code in darwin.S, darwin_closure.S, ffi_darwin.c and sysv.S and wrapper it with a test for __powerpc64__ as a starting point. I think if we at least get discussion going about what needs changed we might slowly progress this PR. Looking at... http://developer.apple.com/documentation/DeveloperTools/Conceptual/LowLevelABI/Articles/32bitPowerPC.html#//apple_ref/doc/uid/TP40002438 http://developer.apple.com/documentation/DeveloperTools/Conceptual/LowLevelABI/Articles/64bitPowerPC.html#//apple_ref/doc/uid/TP40002471 I see that in the Size and natural alignment of the scalar data types table the main differences between 32-bit and 64-bit are... 32-bit64-bit Bool 4 1 unsigned long4 8 signed long 4 8 pointer 4 8 Parameter area to general-purpose register mapping 32-bit64-bit GPR3 SP+24 SP+48 GPR4 SP+28 SP+56 GPR5 SP+32 SP+64 GPR6 SP+36 SP+72 GRP7 SP+40 SP+80 GPR8 SP+44 SP+88 GPR9 SP+48 SP+96 GPR10SP+52 SP+104 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29152
[Bug rtl-optimization/34522] inefficient code for long long multiply when only low bits are needed
--- Comment #1 from bonzini at gnu dot org 2007-12-18 16:58 --- Prototype untested patch. Produces movl12(%esp), %eax imull 4(%esp), %eax ret on the testcase. Index: expr.c === --- expr.c (revision 130928) +++ expr.c (working copy) @@ -8642,7 +8642,8 @@ expand_expr_real_1 (tree exp, rtx target } expand_operands (TREE_OPERAND (exp, 0), TREE_OPERAND (exp, 1), subtarget, &op0, &op1, 0); - return REDUCE_BIT_FIELD (expand_mult (mode, op0, op1, target, unsignedp)); + return REDUCE_BIT_FIELD (expand_mult (tmode != VOIDmode ? tmode : mode, +op0, op1, target, unsignedp)); case TRUNC_DIV_EXPR: case FLOOR_DIV_EXPR: -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34522
[Bug rtl-optimization/17236] inefficient code for long long multiply on x86
--- Comment #14 from bonzini at gnu dot org 2007-12-18 16:50 --- The bug with 64*64->32 multiplication is now PR34522. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17236
[Bug rtl-optimization/34522] bad code for long long multiply when only low bits are needed
-- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-12-18 16:49:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34522
[Bug rtl-optimization/34522] New: bad code for long long multiply when only low bits are needed
For
int test(long long a, long long b)
{
return a * b;
}
GCC generates a widening multiply, and cannot remove the DImode operations
until after register allocation. This causes unnecessary splits.
This could be fixed on the tree level by folding to (int)a * (int)b, or
alternatively in expand.
expand_expr is called with
arg 0 >
arg 1 >>
and tmode SImode, still enough info to choose a better multiply. However,
tmode is not passed on to expand_mult.
--
Summary: bad code for long long multiply when only low bits are
needed
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34522
[Bug rtl-optimization/17236] inefficient code for long long multiply on x86
--- Comment #13 from jakub at gcc dot gnu dot org 2007-12-18 16:39 --- I think tree level does the right thing, TER fixes this up and expand_expr is called with return (int) (b * a) Later on expand_expr is called with unit size align 64 symtab 0 alias set 2 canonical type 0x2e937840 precision 64 min max > arg 0 used DI file pr17236.c line 2 col 30 size unit size align 64 context initial (reg/v:DI 60 [ b ]) arg-type incoming-rtl (mem/c/i:DI (plus:SI (reg/f:SI 53 virtual-incoming-args) (const_int 8 [0x8])) [2 b+0 S8 A32])> arg 1 used DI file pr17236.c line 2 col 17 size unit size align 64 context initial (reg/v:DI 59 [ a ]) arg-type incoming-rtl (mem/c/i:DI (reg/f:SI 53 virtual-incoming-args) [2 a+0 S8 A32]) chain >> and tmode SImode, still enough info to choose a better multiply. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17236
[Bug rtl-optimization/17236] inefficient code for long long multiply on x86
--- Comment #12 from bonzini at gnu dot org 2007-12-18 16:01 --- The problem in comment #11 is that GCC generates a widening multiply, and cannot remove the DImode operations until after register allocation (!). While the root cause is a deficiency in RTL-level DCE, I suggest filing a separate bug, because it could also be fixed on the tree-level. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17236
[Bug target/33474] bfin: ICE: RTL check: expected code 'set' or 'clobber', have 'parallel' in bfin_adjust_cost, at config/bfin/bfin.c:3120
--- Comment #5 from rask at gcc dot gnu dot org 2007-12-18 15:58 --- Fixed with revision 131037. -- rask at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.3.0 | Known to work||4.3.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33474
[Bug java/34521] New: SSLEngine - Clone not supported (Null pointer) exception
I am using GCC (4.3 - 20071130 snapshot) and getting the null pointer exception. Exception in thread "[EMAIL PROTECTED]" java.lang.CloneNotSupportedExcept ion at java.lang.Object.clone at gnu.javax.net.ssl.provider.SSLEngineImpl.setEnabledProtocols -- Summary: SSLEngine - Clone not supported (Null pointer) exception Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jarygrove at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34521
[Bug target/33474] bfin: ICE: RTL check: expected code 'set' or 'clobber', have 'parallel' in bfin_adjust_cost, at config/bfin/bfin.c:3120
--- Comment #4 from rask at gcc dot gnu dot org 2007-12-18 15:31 --- Subject: Bug 33474 Author: rask Date: Tue Dec 18 15:30:57 2007 New Revision: 131037 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131037 Log: PR target/33474 * config/bfin/bfin.c (bfin_adjust_cost): Dig into PARALLELs to find the SET. Modified: trunk/gcc/ChangeLog trunk/gcc/config/bfin/bfin.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33474
[Bug tree-optimization/34413] gfortran.dg/ltrans-7.f90 doesn't work
--- Comment #7 from dominiq at lps dot ens dot fr 2007-12-18 15:11 --- The patch in comment #6 fix the problem without regression on PPC/Intel Darwin9. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34413
[Bug libgomp/34519] pr26943-2.c is regressed on mainline
--- Comment #4 from ismail at pardus dot org dot tr 2007-12-18 14:39 --- [~]> gcc -fopenmp -march=i486 pr26943-2.c -lgomp [~]> ./a.out [~]> works fine like this, I don't know why it fails in the tests. Hmm wonder if --with-cpu=generic could affect this? This is a 4 CPU Xeon machine btw. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34519
[Bug libgomp/34519] pr26943-2.c is regressed on mainline
--- Comment #3 from jakub at gcc dot gnu dot org 2007-12-18 14:30 --- On i386 you need also -march=i486 or higher, i386 doesn't have instructions for atomic stuff. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34519
[Bug bootstrap/34520] New: fixincludes adjusts assert.h in such a way that it stays omnipotent
Default assert.h on Tru64 5.1 has an include guard around the whole include in format of: #ifndef __ASSERT_H_ #define __ASSERT_H_ ... rest of the code ... #endif /* __ASSERT_H_ */ This leads to a behavior different from the one described in the standard, where assert.h is claimed to be the only not omnipotent header file, preventing multiple inclusions and therefore techniques like: #undef NDEBUG #include assert(something); -- Summary: fixincludes adjusts assert.h in such a way that it stays omnipotent Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: critical Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vladimir dot lazarenko at humaninference dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34520
[Bug libgomp/34519] pr26943-2.c is regressed on mainline
--- Comment #2 from ismail at pardus dot org dot tr 2007-12-18 14:17 --- I was testing outside of the testsuite to see why it failed. I see this in log : PASS: libgomp.c/pr26943-2.c (test for excess errors) Setting LD_LIBRARY_PATH to .:/var/pisi/gcc-4.3_pre20071218-31/work/gcc-4.3-20071218/build-default-i686-pc-linux-gnu/i686-pc-linux-gnu/./libgomp/.libs:/var/pisi/gcc-4.3_pre20071218-31/work/gcc-4.3-20071218/build-default-i686-pc-linux-gnu/gcc:.:/var/pisi/gcc-4.3_pre20071218-31/work/gcc-4.3-20071218/build-default-i686-pc-linux-gnu/i686-pc-linux-gnu/./libgomp/.libs:/var/pisi/gcc-4.3_pre20071218-31/work/gcc-4.3-20071218/build-default-i686-pc-linux-gnu/gcc:/var/pisi/gcc-4.3_pre20071218-31/work/gcc-4.3-20071218/build-default-i686-pc-linux-gnu/i686-pc-linux-gnu/libstdc++-v3/.libs:/var/pisi/gcc-4.3_pre20071218-31/work/gcc-4.3-20071218/build-default-i686-pc-linux-gnu/i686-pc-linux-gnu/libgomp/.libs:/var/pisi/gcc-4.3_pre20071218-31/work/gcc-4.3-20071218/build-default-i686-pc-linux-gnu/./gcc:/var/pisi/gcc-4.3_pre20071218-31/work/gcc-4.3-20071218/build-default-i686-pc-linux-gnu/./prev-gcc FAIL: libgomp.c/pr26943-2.c execution test I can't seem to compile the testcase by hand with -fopenmp : [~]> gcc -fopenmp pr26943-2.c -lgomp /tmp/ccaOHasa.o: In function `main.omp_fn.0': pr26943-2.c:(.text+0x179): undefined reference to `__sync_fetch_and_add_4' pr26943-2.c:(.text+0x2c7): undefined reference to `__sync_fetch_and_add_4' collect2: ld returned 1 exit status -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34519
[Bug java/27643] ICE in java_mark_cni_decl_local compiling bytecode->native
--- Comment #6 from aph at gcc dot gnu dot org 2007-12-18 14:06 --- Subject: Bug 27643 Author: aph Date: Tue Dec 18 14:06:15 2007 New Revision: 131036 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131036 Log: 2007-12-18 Andrew Haley <[EMAIL PROTECTED]> PR java/27643 * jcf-parse.c (java_parse_file): Remove call to java_mark_class_local. (parse_class_file): Reinstate call to java_mark_class_local here. * decl.c (java_mark_cni_decl_local): If the ASSEMBLER_NAME is already set, call java_mangle_decl() and make_decl_rtl() to rewrite its name as a hidden alias. Modified: trunk/gcc/java/ChangeLog trunk/gcc/java/decl.c trunk/gcc/java/jcf-parse.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27643
[Bug rtl-optimization/17236] inefficient code for long long multiply on x86
--- Comment #11 from ubizjak at gmail dot com 2007-12-18 13:47 ---
Generated code for a similar example is just plain stupid:
--cut here--
int test(long long a, long long b)
{
return a * b;
}
--cut here--
gcc -O3:
test:
pushl %ebp
movl%esp, %ebp
subl$8, %esp
movl%esi, 4(%esp)
movl16(%ebp), %esi
movl%ebx, (%esp)
movl8(%ebp), %ebx
movl%esi, %eax
movl4(%esp), %esi
mull%ebx
movl(%esp), %ebx
movl%ebp, %esp
popl%ebp
ret
gcc-4.0 is a little less creative and creates:
test:
pushl %ebp
movl%esp, %ebp
pushl %edi
pushl %esi
pushl %ebx
movl8(%ebp), %eax
mull16(%ebp)
popl%ebx
popl%esi
popl%edi
leave
ret
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17236
[Bug tree-optimization/19097] [4.1/4.2/4.3 regression] Quadratic behavior with many sets for the same register in VRP
--- Comment #47 from steven at gcc dot gnu dot org 2007-12-18 13:46 --- (From update of attachment 10017) Patch is obsolete because it was commited. -- steven at gcc dot gnu dot org changed: What|Removed |Added Attachment #10017|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097
[Bug ada/34508] Legal program rejected, RM 3.7(26)
--- Comment #1 from ludovic at ludovic-brenta dot org 2007-12-18 12:10 --- Actually, the declaration of x2 is illegal; GNAT is correct in rejecting it. The declaration of T3 is legal and incorrectly rejected. The error messages are: gnatmake -gnat05 pak1-pak3.ads gcc-4.1 -c -gnat05 pak1-pak3.ads pak1-pak3.ads:3:15: invalid constraint: type has no discriminant pak1-pak3.ads:4:14: no value supplied for discriminant "D" (see also PR ada/34507). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34508
[Bug tree-optimization/31081] [4.3 Regression] Inliner messes up SSA for abnormals
--- Comment #12 from hubicka at gcc dot gnu dot org 2007-12-18 11:41 --- > But I wonder what would be the best way to add the PHI nodes. We really > shouldn't do mark_sym_for_renaming on underlying decl, perhaps create a dummy > decl, let intossa create PHIs etc. for it, then change the SSA_NAME_VARs for > it? Or anything easier? Any ideas? What I hope for is to simply add all possible EH edges (ie edges to all possible receivers not just first one) before inlining, so we never get into busyness of constructing new PHIs because we redirected some EH. Then we always can use the easy route of copying existing PHI argument from the call site. I was travelling last weeks, but I will do look into it before Christmas now. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31081
[Bug c++/34517] INCOROUT: C++ OpenMP lastprivate
--- Comment #2 from jakub at gcc dot gnu dot org 2007-12-18 11:39 --- IMHO it can validly print 7, 14, 21 or 28. See OpenMP 2.5, section 2.5.2: "The method of scheduling the structured blocks among threads in the team is implementation defined." Also, data sharing clause is sections construct clause rather than section directive clause, so no matter how many section directives you have, the constructor/destructor will be called as many times as there are threads in the team. GCC schedules the first not yet processed #pragma omp section block to the first available thread, doesn't do assign different blocks to different threads no matter whether they are available or not. So, if e.g. one (typically master) thread is available some time before all other threads and there isn't really any significant work to do in the block, so it finishes almost instantly, it might very well win the next section block as well, because other threads are still being set up. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34517
