[Bug fortran/37597] New: internal procedure fails to access host-associated module procedure
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/150847ad37d33cdb The following is rejected with: Error: Symbol 'other_sub' at (1) has no IMPLICIT type If one moves other_sub up in the module, it works. module foo implicit none contains subroutine main_sub () call internal_sub() contains subroutine internal_sub() call QAG(other_sub) end subroutine internal_sub end subroutine main_sub subroutine other_sub () end subroutine other_sub end module foo -- Summary: internal procedure fails to access host-associated module procedure Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org OtherBugsDependingO 32834 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37597
[Bug fortran/37588] GENERIC type-bound procedure is not resolved
--- Comment #4 from sfilippone at uniroma2 dot it 2008-09-20 06:56 --- (In reply to comment #2) I believe the program is valid [modulo the CLASS/TYPE issue]. (NAG f95 by the way give an odd error message and crashes than with a segfault.) Well, of course; be reassured that I will try a CLASS argument as soon as it's implemented ;-) But it's clearly not the issue at hand... Regards SAlvatore -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37588
[Bug target/37593] -mlong-calls doesn't affect calls to _mcount generated with -pg
--- Comment #2 from daney at gcc dot gnu dot org 2008-09-20 07:25 --- Created an attachment (id=16367) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16367action=view) Proposed patch. This patch seems like it may work. I will bootstrap/test it. -- daney at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |daney at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37593
[Bug fortran/37583] ICE insert_bbt(): Duplicate key for self-calling ENTRY subprogram
--- Comment #4 from dominiq at lps dot ens dot fr 2008-09-20 07:32 --- With the patch in comment #3, I get FAIL: gfortran.dg/entry_1.f90 -O0 (test for excess errors) ... FAIL: gfortran.dg/entry_1.f90 -Os (test for excess errors) The failure is: /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/entry_1.f90:16.18: call indirectb (bar) 1 Error: Reference to ENTRY 'bar' at (1) is recursive, but procedure 'foo' is not declared as RECURSIVE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37583
[Bug fortran/37580] [4.3/4.4 Regression] Accepts pointer(:) = target without lower bound
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37580
[Bug libgomp/37586] OpenMP thinks that I have 1 processor on an 8 processor pc
--- Comment #5 from jakub at gcc dot gnu dot org 2008-09-20 08:22 --- No, I didn't mean to ask you to try to work around it, I asked you to investigate why omp_get_num_procs returns 1 instead of 8. The gcc 4.3 vs. 4.4 difference only affects omp_get_max_threads, not omp_get_num_procs, so even omp_get_num_procs reports 1, the options are 1) the process has affinity set to just one CPU 2) GOMP_CPU_AFFINITY has been used 3) you have omp_get_num_procs defined elsewhere in your program, verify that libgomp function is really used. strace -f -e sched_getaffinity dump of the program could reveal 1), 2) can be determined by looking at the scripts you use to start the program (or by adding getenv call in the program to print that for you), 3) can be seen in the debugger and/or by using LD_DEBUG=all env var. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37586
[Bug ada/37585] [4.4 regression] undefined references at -O for ACATS c650001
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2008-09-20 08:43 --- Subject: Bug 37585 Author: ebotcazou Date: Sat Sep 20 08:41:55 2008 New Revision: 140511 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140511 Log: PR ada/37585 * gcc-interface/utils.c (create_subprog_decl): Disable inlining for inlined external functions if they contain a nested function not declared inline. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/utils.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37585
[Bug ada/37585] [4.4 regression] undefined references at -O for ACATS c650001
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2008-09-20 08:49 --- Thanks for reporting the problem. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37585
[Bug c++/37590] g++ should emit different debug info for variable's type
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-09-20 09:07 --- It is not possible to fix this in GCC today. But we can of course output the debug information for decls and types from the frontends ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37590
[Bug c/37591] suppress signed and unsigned warnings when signed value known to be positive
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-09-20 09:10 --- This is the usual trade-off of doing warnings from the frontends... -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-20 09:10:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37591
[Bug target/37584] -ftree-ch causes stack corruption on mingw32
--- Comment #2 from sherpya at netfarm dot it 2008-09-20 09:43 --- adding -fno-tree-ch avoid crashing in mencoder, so I filled the bug on this, but it can be a side effect of something else -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37584
[Bug fortran/37583] ICE insert_bbt(): Duplicate key for self-calling ENTRY subprogram
--- Comment #5 from dominiq at lps dot ens dot fr 2008-09-20 10:09 --- I just noticed that the patch in http://gcc.gnu.org/ml/fortran/2008-09/msg00342.html has an additional test in gcc/fortran/resolve.c: +sym-ns == gfc_current_ns This may fix the failure I have reported. If the patch is not commited before this evening, I'll do some further testing with the change tonight. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37583
[Bug fortran/37583] ICE insert_bbt(): Duplicate key for self-calling ENTRY subprogram
--- Comment #6 from burnus at gcc dot gnu dot org 2008-09-20 11:32 --- I just noticed that the patch in http://gcc.gnu.org/ml/fortran/2008-09/msg00342.html has an additional test in gcc/fortran/resolve.c: +sym-ns == gfc_current_ns This may fix the failure I have reported. If the patch is not commited before this evening, I'll do some further testing with the change tonight. I think it does (both from looking at that line and from testing entry_1.f90 with the old new patch). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37583
[Bug fortran/35846] ICE on nested character constructors
--- Comment #5 from domob at gcc dot gnu dot org 2008-09-20 11:52 --- After coming back to this bug, I believe the problem is that gfc_conv_expr takes care of finding out string lengths' for things like TRIM(x) which don't have a cl-length, but gfc_conv_expr_descriptor which is called e.g. for the array constructors does not do so and calls gfc_conv_string_length with a cl whose length is NULL. As the problem seems to be specific to array constructors and all array constructor elements must have the same character length, I propose to re-use gfc_conv_expr in gfc_conv_string_length to find out the string length if it is NULL by taking the first element of each array constructor and then calling gfc_conv_expr to get the result's string_length. I'll submit a patch shortly if no further problems occur. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35846
[Bug ada/31108] [4.2 regression] ACATS C35507M fails
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2008-09-20 14:00 --- No feedback. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31108
[Bug ada/37431] SPARC ACATS failures for alignment
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2008-09-20 14:02 --- Is this still present? -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37431
[Bug ada/31174] [4.2 Regression] ACATS C380004 fails
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2008-09-20 14:05 --- This is a corner case anyway. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31174
[Bug c++/36707] ICE in build_modify_expr on rvalue reference function template
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-09-20 14:15 --- This is not a regression as it never worked. -std=c++0x is new in GCC 4.3. Failing since 4.3.0. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.3.0 Last reconfirmed|2008-09-15 21:56:28 |2008-09-20 14:15:18 date|| Summary|[4.3/4.4 regression] ICE in |ICE in build_modify_expr on |build_modify_expr on rvalue |rvalue reference function |reference function template |template Target Milestone|4.3.3 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36707
[Bug tree-optimization/36861] [4.3/4.4 Regression] boost's compressed avl confuses GCC
--- Comment #22 from rguenth at gcc dot gnu dot org 2008-09-20 14:25 --- This PR is still very weird. For the curious here are the numbers, now with numbers from trunk included: 4.3 -O: 0.4s 4.3 -O -fstrict-aliasing: 59s 4.4 -O: 1m3s 4.4 -O -fstrict-aliasing: 0.4s 4.4 -O2: 0.3s 4.4 -O2 -fno-strict-aliasing: 0.2s ?! -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.3.1 |4.3.1 4.4.0 Summary|[4.3 Regression] boost's|[4.3/4.4 Regression] boost's |compressed avl confuses GCC |compressed avl confuses GCC http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36861
[Bug tree-optimization/36861] [4.3/4.4 Regression] boost's compressed avl confuses GCC
--- Comment #23 from rguenth at gcc dot gnu dot org 2008-09-20 14:27 --- Created an attachment (id=16368) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16368action=view) unincluded testcase Unincluded testcase attached. I'll leave this at P3 so some brave soul might eventually pick up the analysis. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36861
[Bug middle-end/37053] [4.3/4.4 regression] ICE in reload_cse_simplify_operands, at postreload.c:395
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-09-20 14:29 --- m68k-linux-gnu is neither primary nor secondary target. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37053
[Bug rtl-optimization/37219] [4.3 Regression] fwprop1 is broken for addresses
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-09-20 14:31 --- This is not really spu specific. The patch is ok to backport to the branch if you can get SPEC results for one primary target (ask HJ or Luis). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|spu-elf | Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37219
[Bug c/37267] [4.2/4.3/4.4 Regression] #pragma inside structure initialization causes error
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-09-20 14:35 --- I agree with Jakub. Joseph - are you ok with closing this as invalid? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jsm28 at gcc dot gnu dot org Status|NEW |WAITING Keywords|rejects-valid | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37267
[Bug c++/37314] [4.2/4.3/4.4 Regression] seg violation
--- Comment #15 from rguenth at gcc dot gnu dot org 2008-09-20 14:41 --- The question remains if this is invalid or valid code. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jason at redhat dot com Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37314
[Bug middle-end/37448] [4.3 Regression] gcc 4.3.1 cannot compile big function
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37448
[Bug c++/37553] [4.3/4.4 Regression] ICE in build_c_cast
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-09-20 14:49 --- ui32 and ui32a are identical (they are identical in middle-end terms), but ui32 * and ui32a * would not be identical. Sounds weird, but the way may_alias is designed make it so. A 32bit target is required to trigger the ICE. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.2.4 Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37553
[Bug c++/37563] [4.3/4.4 regression] Trouble calling qualified member function
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-09-20 14:51 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jason at redhat dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to work||4.2.4 Priority|P3 |P2 Last reconfirmed|-00-00 00:00:00 |2008-09-20 14:51:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37563
[Bug tree-optimization/37579] [4.3/4.4 Regression] Vectorizer is causing code bloat and worse performance than unrolling would for a loop in SPEC 2k's eon
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to work||4.2.4 Priority|P3 |P2 Last reconfirmed|-00-00 00:00:00 |2008-09-20 14:53:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37579
[Bug rtl-optimization/37598] New: [ira-merge] FAIL: gcc.target/i386/asm-3.c execution test
On Linux/ia32 and Linux/x86-64, this patch http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01176.html caused FAIL: gcc.target/i386/asm-3.c execution test on ira-merge branch. -- Summary: [ira-merge] FAIL: gcc.target/i386/asm-3.c execution test Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37598
[Bug target/28481] [4.2/4.3/4.4 Regression] regression from 3.x: 4.1.1 uses memory where it can use registers
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-09-20 15:06 --- Trunk does very unfunny things to this testcase as well. -fno-tree-reassoc recovers the register allocation problems. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||vmakarov at redhat dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization, ra Last reconfirmed|-00-00 00:00:00 |2008-09-20 15:06:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28481
[Bug target/37571] [4.4 regression] Performance regression due to compare/branch fuse optimization
--- Comment #5 from hjl at gcc dot gnu dot org 2008-09-20 15:08 --- Subject: Bug 37571 Author: hjl Date: Sat Sep 20 15:07:46 2008 New Revision: 140514 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140514 Log: 2008-09-20 H.J. Lu [EMAIL PROTECTED] PR target/37571 * config/i386/i386.md (*jcc_fused_1): Removed. (*jcc_fused_2): Likewise. (*jcc_fused_3): Likewise. (*jcc_fused_4): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37571
[Bug tree-optimization/36218] [4.2/4.3 Regression] VRP causes stack overflow while building libgcj
--- Comment #18 from rguenth at gcc dot gnu dot org 2008-09-20 15:09 --- Please open a new report for the SSA update problem. Back to NEW for this PR, fixed on the trunk. *-*-mingw* is not in the list of primary or secondary platforms, so P4. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Known to work|4.0.0 |4.0.0 4.4.0 Priority|P2 |P4 Last reconfirmed|2008-08-23 18:06:02 |2008-09-20 15:09:14 date|| Summary|[4.2/4.3/4.4 regression] VRP|[4.2/4.3 Regression] VRP |causes stack overflow while |causes stack overflow while |building libgcj |building libgcj Target Milestone|4.3.3 |4.2.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36218
[Bug target/37571] [4.4 regression] Performance regression due to compare/branch fuse optimization
--- Comment #6 from hjl dot tools at gmail dot com 2008-09-20 15:10 --- Fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37571
[Bug rtl-optimization/36350] [4.3/4.4 Regression] GCC ICE with -frename-registers
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-09-20 15:12 --- CCing ARM maintainers so they can confirm the bug and look at its relation to PR35964. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||richard dot earnshaw at arm ||dot com, nickc at redhat dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36350
[Bug c++/36406] [4.2/4.3/4.4 regression] ICE with template delete operator
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-09-20 15:14 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||3.3.6 4.3.2 Known to work||2.95.4 Last reconfirmed|-00-00 00:00:00 |2008-09-20 15:14:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36406
[Bug ada/37572] compile Ada program fails (XML/Ada, 64 bit AMD)
--- Comment #5 from jdecs at mssblue dot net 2008-09-20 15:19 --- (In reply to comment #3) Could you try a more recent GCC version I am reasonably convinced that the changes Thomas made were for a known compiler bug, using the GPS installed gnatmake to get around it. I am going to close this, as I believe that the original bug is on the work list somewhere and that my problems derive more from system differences than a specific hole in GCC/Ada. I am migrating my system to SUSE 11.0, which has a newer compiler available and will work with Thomas to get the XML/Ada integrated. Thanks for looking at this. -- jdecs at mssblue dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37572
[Bug c++/36410] [4.2/4.3/4.4 Regression] ICE with transparent union
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-09-20 15:20 --- 4.1 ICEs after the same error 4.2 rejects the code with, 4.3 ICEs again after the error. 4.4 doesn't error but ICEs in build_base_path, at cp/class.c:272. Waiting to have someone confirm the validity of the testcase. For now make it ICE-on-invalid (error-recovery only for 4.4, for 4.4 eventually accepts-invalid) as we never accepted the code before. As usual splitting such bugs if we have different behavior/regressions on different GCC versions would make classification easier ... -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jason at redhat dot com Status|UNCONFIRMED |WAITING Keywords|ice-on-valid-code |error-recovery, ice-on- ||invalid-code Priority|P2 |P4 Summary|[4.2/4.3/4.4 regression] ICE|[4.2/4.3/4.4 Regression] ICE |with transparent union |with transparent union http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36410
[Bug tree-optimization/36905] [4.2/4.3/4.4 Regression] IV-opts needs a little help with a[i+1]
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-09-20 15:23 --- Confirmed anyway. Time for a IVOPTs meta-bug ... -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-20 15:23:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36905
[Bug c++/36959] [4.2/4.3/4.4 Regression] C++ front-end causing a static inline function to be emitted
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-09-20 15:26 --- What happens if you remove this piece of code? I suspect we merely need to keep the function declaration to emit proper debug information. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36959
[Bug fortran/37498] [4.4 Regression] Incorrect array value returned
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2008-09-20 15:29 --- Proposed solution: I will add another component to the st_parameter_dt union and call it q. It will be identical to the existing component p accept with the added IOparms at the top. In the 4.4 library we will reference the q instead of p. 4.4 compiled applications should then see their respective runtime information and 4.3 should be unaffected. I will give it a shot and see, the editing is straight forward. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37498
[Bug rtl-optimization/36758] [4.3/4.4 Regression] address addition moved out of the loop
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-09-20 15:22 --- This might be a cost issue in the ppc backend (and so target, not rtl-optimization). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|middle-end |rtl-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36758
[Bug middle-end/37236] [4.3 Regression] ICE: in mark_operand_necessary, at tree-ssa-dce.c:242
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-09-20 15:41 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37236
[Bug middle-end/37236] [4.3 Regression] ICE: in mark_operand_necessary, at tree-ssa-dce.c:242
--- Comment #14 from rguenth at gcc dot gnu dot org 2008-09-20 15:41 --- Subject: Bug 37236 Author: rguenth Date: Sat Sep 20 15:40:15 2008 New Revision: 140515 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140515 Log: 2008-09-20 Richard Guenther [EMAIL PROTECTED] Backport from mainline: 2008-08-29 Richard Guenther [EMAIL PROTECTED] PR middle-end/37236 * tree-ssa-structalias.c (intra_create_variable_infos): Mark PARAM_NOALIAS tags with is_heapvar. * tree-ssa-operands.c (access_can_touch_variable): Offset based tests do not apply for heapvars. Fix offset test. * gfortran.fortran-torture/compile/pr37236.f: New testcase. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.fortran-torture/compile/pr37236.f Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/tree-ssa-operands.c branches/gcc-4_3-branch/gcc/tree-ssa-structalias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37236
[Bug ada/37599] New: renamed volatile variables are not treated as volatile
with Interfaces; use Interfaces; package A is Var : unsigned_8; for Var'Address use ... pragma Volatile (Var); end A; with Interfaces; use Interfaces; with A; procedure B is renamed : Unsigned_8 renames A.Var; begin renamed := renamed or 16#01#; -- 'renamed' is kept in a register A.Var := A.Var or 16#01#;-- 'A.Var' correctly sets the port bit end B; -- Summary: renamed volatile variables are not treated as volatile Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rolf dot ebert dot gcc at gmx dot de GCC host triplet: any GCC target triplet: avr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37599
[Bug rtl-optimization/37598] [ira-merge] FAIL: gcc.target/i386/asm-3.c execution test
--- Comment #1 from hjl dot tools at gmail dot com 2008-09-20 16:37 --- Revert revision 140504 fixes this regression. -- hjl dot tools at gmail dot com changed: What|Removed |Added Summary|[ira-merge] FAIL: |[ira-merge] FAIL: |gcc.target/i386/asm-3.c |gcc.target/i386/asm-3.c |execution test |execution test http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37598
[Bug middle-end/37535] [4.4 Regression] gcc/libgcc2.c:404: internal compiler error: Floating point exception
--- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca 2008-09-20 17:04 --- Subject: Re: [4.4 Regression] gcc/libgcc2.c:404: internal compiler error: Floating point exception URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140504 Log: 2008-09-19 Vladimir Makarov [EMAIL PROTECTED] PR middle-end/37535 * ira-lives.c (mark_reg_live, mark_reg_dead): New functions. (mark_ref_live, mark_ref_dead): Use them. (def_conflicts_with_inputs_p): Remove. (mark_early_clobbers): New function. (process_bb_node_lives): Call preprocess_constraints and mark_early_clobbers. Modified: branches/ira-merge/gcc/ChangeLog branches/ira-merge/gcc/ira-lives.c I have tested this change on the trunk with hppa-unknown-linux-gnu and it fixes the problem. Thanks, Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37535
[Bug bootstrap/37600] New: Bootstrap Failure with Undefined References
$ uname -a CYGWIN_NT-5.1 MCKELVEY-XP 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin $ g++ -v Using built-in specs. Target: i686-pc-cygwin Configured with: /cygdrive/f/Home/cvsroot/gcc/configure --verbose --enable-threads --disable-nls --disable-win32-registry --enable-languages=c,c++ Thread model: posix gcc version 4.4.0 20080826 (experimental) (GCC) $ alias CONFIGURECVS alias CONFIGURECVS='/cygdrive/f/Home/cvsroot/gcc/configure --verbose --enable-threads --disable-nls --disable-win32-registry --enable-languages=c,c++' [EMAIL PROTECTED] ~/cvsroot/gcc-obj $ alias BUILD alias BUILD='nice make CFLAGS='\'''\'' BOOT_CFLAGS='\'''\'' LIBCFLAGS='\''-g -O'\'' CXXFLAGS='\''-O'\'' LIBCXXFLAGS='\''-g -O'\'' bootstrap' mv tmp-libgcc.map libgcc.map # @multilib_flags@ is still needed because this may use # /cygdrive/f/Home/cvsroot/gcc-obj/./gcc/xgcc -B/cygdrive/f/Home/cvsroot/gcc-obj/./gcc/ -B/usr/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem /usr/local/i686-pc-cygwin/include -isystem /usr/local/i686-pc-cygwin/sys-include and -O2 -I/cygdrive/f/Home/cvsroot/gcc/gcc/../winsup/w32api/include -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -isystem ./include -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED directly. # @multilib_dir@ is not really necessary, but sometimes it has # more uses than just a directory name. /bin/sh /cygdrive/f/Home/cvsroot/gcc/libgcc/../mkinstalldirs . ln -s libgcc.map libgcc.map.def if [ ! -d ./shlib ]; then mkdir ./shlib else true; fi /cygdrive/f/Home/cvsroot/gcc-obj/./gcc/xgcc -B/cygdrive/f/Home/cvsroot/gcc-obj/./gcc/ -B/usr/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem /usr/local/i686-pc-cygwin/include -isystem /usr/local/i686-pc-cygwin/sys-include -O2 -I/cygdrive/f/Home/cvsroot/gcc/gcc/../winsup/w32api/include -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -isystem ./include -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -shared -nodefaultlibs libgcc.map.def -Wl,--out-implib,./shlib/libgcc_s.a.tmp -o ./shlib/libgcc_s_1.dll.tmp -g -O2 -B./ _chkstk_s.o _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o _enable_execute_stack_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixtfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _fixunstfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatditf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _floatunditf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o _udiv_w_sdiv_s.o _udivmoddi4_s.o unwind-dw2_s.o unwind-dw2-fde_s.o unwind-sjlj_s.o gthr-gnat_s.o unwind-c_s.o emutls_s.o -luser32 -lkernel32 -ladvapi32 -lshell32 ar -r ./shlib/libgcc_s.a.tmp _chkstk.o _ctors.o gthr-win32.o if [ -f ./shlib/libgcc_s_1.dll ]; then mv -f ./shlib/libgcc_s_1.dll ./shlib/libgcc_s_1.dll.backup; else true; fi mv ./shlib/libgcc_s_1.dll.tmp ./shlib/libgcc_s_1.dll mv ./shlib/libgcc_s.a.tmp ./shlib/libgcc_s.a Creating library file: ./shlib/libgcc_s.a.tmp /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: warning: cannot find entry symbol [EMAIL PROTECTED]; defaulting to 10001000 _absvsi2_s.o: In function `__absvsi2': /cygdrive/f/Home/cvsroot/gcc/libgcc/../gcc/libgcc2.c:237: undefined reference to `_abort' _absvdi2_s.o: In function `__absvdi2': /cygdrive/f/Home/cvsroot/gcc/libgcc/../gcc/libgcc2.c:276: undefined reference to `_abort' _addvsi3_s.o: In function `__addvsi3': /cygdrive/f/Home/cvsroot/gcc/libgcc/../gcc/libgcc2.c:90: undefined reference to `_abort' _addvdi3_s.o: In function `__addvdi3': /cygdrive/f/Home/cvsroot/gcc/libgcc/../gcc/libgcc2.c:115: undefined reference to `_abort' _subvsi3_s.o: In function `__subvsi3': /cygdrive/f/Home/cvsroot/gcc/libgcc/../gcc/libgcc2.c:128: undefined reference to `_abort' _subvdi3_s.o:/cygdrive/f/Home/cvsroot/gcc/libgcc/../gcc/libgcc2.c:153: more undefined references to `_abort' follow unwind-dw2-fde_s.o: In function `get_cie_encoding': /cygdrive/f/Home/cvsroot/gcc/libgcc/../gcc/unwind-dw2-fde.c:276: undefined reference to `_strlen' unwind-dw2-fde_s.o: In function `start_fde_sort': /cygdrive/f/Home/cvsroot/gcc/libgcc/../gcc/unwind-dw2-fde.c:401: undefined reference to `_malloc' /cygdrive/f/Home/cvsroot/gcc/libgcc/../gcc/unwind-dw2-fde.c:404: undefined reference
[Bug tree-optimization/36218] [4.2/4.3 Regression] VRP causes stack overflow while building libgcj
--- Comment #19 from brian at dessent dot net 2008-09-20 17:32 --- Subject: Re: [4.2/4.3 Regression] VRP causes stack overflow while building libgcj PR, fixed on the trunk. *-*-mingw* is not in the list of primary or secondary platforms, so P4. As of 4.3 both MinGW and Cygwin are secondary targets: http://gcc.gnu.org/gcc-4.3/criteria.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36218
[Bug middle-end/37443] fast 64-bit divide by constant on 32-bit platform
--- Comment #3 from ajrobb at bigfoot dot com 2008-09-20 17:32 --- Created an attachment (id=16369) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16369action=view) proposed 32-bit API calls for 64-bit constant divison I have attached a sample assembler code for a API calls for the 2 types of 64-bit division through multiplication: mul0shift - for multiplier with 64 or fewer significant bits mul1shift - for multiplier with 65 significant bits (implicit high bit) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37443
[Bug bootstrap/37600] Bootstrap Failure with Undefined References
--- Comment #1 from brian at dessent dot net 2008-09-20 17:40 --- Subject: Re: New: Bootstrap Failure with Undefined References This is a dup of pr37528 which has a patch waiting to be applied. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37600
[Bug fortran/37580] [4.3/4.4 Regression] Accepts pointer(:) = target without lower bound
--- Comment #4 from burnus at gcc dot gnu dot org 2008-09-20 17:49 --- I marked this as regression, but it is not a true regression as it was before only rejected because bound-specs where not allowed at all in earlier gfortran versions. Well, as testing shows, it still does not work in 4.4, i.e. wrong code is produced. I have posted a patch. -- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Keywords||wrong-code Last reconfirmed|2008-09-19 10:12:15 |2008-09-20 17:49:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37580
[Bug tree-optimization/36218] [4.2/4.3 Regression] VRP causes stack overflow while building libgcj
--- Comment #20 from rguenth at gcc dot gnu dot org 2008-09-20 17:51 --- Oops. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P4 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36218
[Bug c++/36654] Inlined con/de-structor breaks virtual inheritance dllimport classes
--- Comment #5 from tdragon at tdragon dot net 2008-09-20 17:57 --- Any news or thoughts on this bug? (*Ping*) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36654
Re: [Bug c++/36959] [4.2/4.3/4.4 Regression] C++ front-end causing a static inline function to be emitted
Sent from my iPhone On Sep 20, 2008, at 8:26 AM, rguenth at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #1 from rguenth at gcc dot gnu dot org 2008-09-20 15:26 --- What happens if you remove this piece of code? I suspect we merely need to keep the function declaration to emit proper debug information. I only tested disabling it for the non repo case and it worked and got the correct debugging info. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36959
[Bug c++/36959] [4.2/4.3/4.4 Regression] C++ front-end causing a static inline function to be emitted
--- Comment #2 from pinskia at gmail dot com 2008-09-20 18:36 --- Subject: Re: [4.2/4.3/4.4 Regression] C++ front-end causing a static inline function to be emitted Sent from my iPhone On Sep 20, 2008, at 8:26 AM, rguenth at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #1 from rguenth at gcc dot gnu dot org 2008-09-20 15:26 --- What happens if you remove this piece of code? I suspect we merely need to keep the function declaration to emit proper debug information. I only tested disabling it for the non repo case and it worked and got the correct debugging info. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36959 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36959
[Bug middle-end/37535] [4.4 Regression] gcc/libgcc2.c:404: internal compiler error: Floating point exception
--- Comment #11 from hjl dot tools at gmail dot com 2008-09-20 18:44 --- (In reply to comment #10) Subject: Re: [4.4 Regression] gcc/libgcc2.c:404: internal compiler error: Floating point exception URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140504 Log: 2008-09-19 Vladimir Makarov [EMAIL PROTECTED] PR middle-end/37535 * ira-lives.c (mark_reg_live, mark_reg_dead): New functions. (mark_ref_live, mark_ref_dead): Use them. (def_conflicts_with_inputs_p): Remove. (mark_early_clobbers): New function. (process_bb_node_lives): Call preprocess_constraints and mark_early_clobbers. I have tested this change on the trunk with hppa-unknown-linux-gnu and it fixes the problem. This patch caused PR 37598. -- hjl dot tools at gmail dot com changed: What|Removed |Added OtherBugsDependingO||37598 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37535
[Bug ada/37601] New: gcc-4.4-20080919 ada build failure
$ ../gcc-4.4-20080919/configure --prefix=/usr --enable-threads --enable-shared --enable-languages=c,c++,ada --host=x86_64-unknown-linux-gnu --with-system-zlib --with-x --enable-java-awt=gtk --enable-targets=x86_64-unknown-linux-gnu --with-arch=athlon64 --with-tune=athlon64 --with-cpu=athlon64 --disable-multilib --enable-__cxa_atexit --enable-libada --enable-gtk-cairo --enable-libgcj-multifile --with-long-double-128 --disable-nls $ make profiledbootstrap [...] make[3]: Entering directory `/src/a/gcc/o-4.4/gcc' /src/a/gcc/o-4.4/./prev-gcc/xgcc -B/src/a/gcc/o-4.4/./prev-gcc/ -B/usr/x86_64-unknown-linux-gnu/bin/ -c -g -O2 -fprofile-generate -gnatpg -gnata -nostdinc -I- -I. -Iada -I../../gcc-4.4-20080919/gcc/ada -I../../gcc-4.4-20080919/gcc/ada/gcc-interface ../../gcc-4.4-20080919/gcc/ada/checks.adb -o ada/checks.o raised STORAGE_ERROR : stack overflow (or erroneous memory access) make[3]: *** [ada/checks.o] Error 1 $ ulimit -s 10 -- Summary: gcc-4.4-20080919 ada build failure Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gcc at spatium dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37601
[Bug rtl-optimization/33642] unrecognizable insn for -frtl-abstract-sequences
--- Comment #28 from ebotcazou at gcc dot gnu dot org 2008-09-20 19:16 --- Subject: Bug 33642 Author: ebotcazou Date: Sat Sep 20 19:15:19 2008 New Revision: 140516 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140516 Log: PR rtl-optimization/33642 * gcc.c-torture/compile/pr11832.c: XFAIL on SPARC. * gcc.c-torture/compile/pr33009.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/compile/pr11832.c trunk/gcc/testsuite/gcc.c-torture/compile/pr33009.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33642
[Bug ada/37602] New: Renaming of volatile causes variable access
The following procedure generates an access to A because of its renaming as B, even though no explicit access is made to A or B. I think this violates the second sentence of C.6(20). with Interfaces; use Interfaces; with System.Storage_Elements; use System.Storage_Elements; procedure T is A : Unsigned_8; for A'Address use To_Address (1000); pragma Volatile (A); B : Unsigned_8 renames A; begin null; end T; The generated assembler code (-O3 -fomit-frame-pointer) for this procedure is: _ada_t: subl$12, %esp movzbl 1000, %eax addl$12, %esp ret -- Summary: Renaming of volatile causes variable access Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sam at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37602
[Bug middle-end/37603] New: [4.4 Regression] FAIL: gcc.c-torture/compile/pr36141.c at -O1 and above
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ - O1 -w -c -o pr36141.o /test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr 36141.c(timeout = 300) /test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr36141.c: In function 'ff i_prep_closure_loc': /test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr36141.c:17: internal com piler error: in output_constant_pool_2, at varasm.c:3732 Breakpoint 1, output_constant_pool_2 (mode=BLKmode, x=0x83fffdfba020, align=1) at ../../gcc/gcc/varasm.c:3732 3732 gcc_unreachable (); (gdb) p debug_rtx (x) (symbol_ref/v:DI (@ffi_closure_unix) [flags 0x41] function_decl 83fffdfa0c00 ffi_closure_unix) $1 = void (gdb) bt #0 output_constant_pool_2 (mode=BLKmode, x=0x83fffdfba020, align=1) at ../../gcc/gcc/varasm.c:3732 #1 0x40cf0944 in output_constant_pool_1 (desc=0x83fffdfc6700, align=1) at ../../gcc/gcc/varasm.c:3788 #2 0x40cf10cc in output_constant_pool_contents (pool=Cannot access memory at address 0x0 ) at ../../gcc/gcc/varasm.c:3908 #3 0x40cf115c in output_constant_pool (fnname=Cannot access memory at address 0x0 ) at ../../gcc/gcc/varasm.c:3931 #4 0x40ce4070 in assemble_start_function (decl=0x83fffdfa0d00, fnname=0x83fffdfa8ca0 @ffi_prep_closure_loc) at ../../gcc/gcc/varasm.c:1662 #5 0x404f378c in rest_of_handle_final () at ../../gcc/gcc/final.c:4150 #6 0x407508a8 in execute_one_pass (pass=0x8001000475e0) at ../../gcc/gcc/passes.c:1279 #7 0x40750e24 in execute_pass_list (pass=0x8001000475e0) at ../../gcc/gcc/passes.c:1327 #8 0x40750e68 in execute_pass_list (pass=0x800100047d50) at ../../gcc/gcc/passes.c:1328 #9 0x40750e68 in execute_pass_list (pass=0x800100047d00) at ../../gcc/gcc/passes.c:1328 #10 0x409d12cc in tree_rest_of_compilation (fndecl=0x83fffdfa0d00) at ../../gcc/gcc/tree-optimize.c:418 #11 0x40d39cc8 in cgraph_expand_function (node=0x83fffdfa0e00) at ../../gcc/gcc/cgraphunit.c:1038 #12 0x40d3a004 in cgraph_expand_all_functions () at ../../gcc/gcc/cgraphunit.c:1097 #13 0x40d3ab78 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1302 #14 0x401d93ac in c_write_global_declarations () at ../../gcc/gcc/c-decl.c:8071 #15 0x408fef64 in compile_file () at ../../gcc/gcc/toplev.c:979 #16 0x40902d94 in do_compile () at ../../gcc/gcc/toplev.c:2190 #17 0x40902eb0 in toplev_main (argc=17, argv=0x83fffdff05f0) at ../../gcc/gcc/toplev.c: #18 0x402d2f18 in main (argc=Cannot access memory at address 0x0 ) at ../../gcc/gcc/main.c:35 Didn't fail at revision 140325. -- Summary: [4.4 Regression] FAIL: gcc.c-torture/compile/pr36141.c at -O1 and above Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu 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=37603
[Bug ada/37599] renamed volatile variables are not treated as volatile
--- Comment #1 from sam at gcc dot gnu dot org 2008-09-20 20:08 --- Rolf, could you include the problematic assembler code? On i686-pc-linux-gnu, it looks like it generates the expected code except for the bogus extra access that I submitted as a separate bug in PR ada/37602: _ada_b: movla__var, %edx movzbl (%edx), %eax === extra access movzbl (%edx), %eax=== volatile read through renaming orl $1, %eax movb%al, (%edx) === volatile write through renaming movla__var, %edx === looks like a useless assignment movzbl (%edx), %eax=== volatile read orl $1, %eax movb%al, (%edx) === volatile write ret Adding an extra renamed := renamed or 2; shows that reads and writes are not aggregated, as expected for a volatile variable. I will file a separate report for the missed optimization. -- sam at gcc dot gnu dot org changed: What|Removed |Added CC||sam at gcc dot gnu dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37599
[Bug ada/37604] New: Suboptimal code generation for volatile access
The following code generates suboptimal code on i686-pc-linux-gnu: with Interfaces; use Interfaces; with System.Storage_Elements; package A is Var : unsigned_8; for Var'Address use System.Storage_Elements.To_Address (1000); pragma Volatile (Var); end A; with A; with Interfaces; use Interfaces; procedure U is begin A.Var := A.Var or 1; A.Var := A.Var or 2; end U; With -O3 -fomit-frame-pointer, we get: _ada_u: movla__var, %edx === indirection instead of... movzbl (%edx), %eax === ...direct access here orl $1, %eax movb%al, (%edx) movla__var, %edx === useless reloading of a__var movzbl (%edx), %eax orl $2, %eax movb%al, (%edx) ret If the variable is declared in the same compilation unit, we get: _ada_u: movzbl 1000, %eax orl $1, %eax movb%al, 1000 movzbl 1000, %eax orl $2, %eax movb%al, 1000 ret We should probably get the same code in both cases. -- Summary: Suboptimal code generation for volatile access Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sam at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37604
[Bug ada/37431] SPARC ACATS failures for alignment
--- Comment #4 from joel at gcc dot gnu dot org 2008-09-20 21:24 --- According to http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg01683.html this problem is gone. We are back down to 10 failures. Thanks. Are there any remaining on that report, you want me to give you a back trace on? -- joel at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37431
[Bug ada/37431] SPARC ACATS failures for alignment
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2008-09-20 21:40 --- According to http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg01683.html this problem is gone. We are back down to 10 failures. OK, that's good news. Are there any remaining on that report, you want me to give you a back trace on? You can open a PR for the GNAT BUG DETECTED and post the backtrace there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37431
[Bug c++/36959] [4.2/4.3/4.4 Regression] C++ front-end causing a static inline function to be emitted
--- Comment #3 from mmitchel at gcc dot gnu dot org 2008-09-20 21:59
---
I suspect that things have been improved so that this code is no longer
required. My expectation is that in the past we only emitted the static when
we emitted the function body, so the code made sense. But, now, with the
cgraph infrastructure, the compiler is probably perfect capable of emitting a
variable without its containing function.
Andrew raises a good point about -frepo. The interesting question is what
happens if there is an undefined referenced to the variable, but not the
function; does collect2 arrange that we actually emit the function?
For example:
test.h
--
template typename T void * f(T) {
static int i;
}
a.C
---
#include test.h
int* p = f(3);
int main() {}
With -O2 -frepo, does this link? I'd expect that we end up with an undefined
referenced to fint::i in a.o, but that this variable isn't listed in the set
of things that could be generated by recompiling a.C, so we lose.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36959
[Bug middle-end/37603] [4.3/4.4 Regression] FAIL: gcc.c-torture/compile/pr36141.c at -O1 and above
--- Comment #1 from danglin at gcc dot gnu dot org 2008-09-20 22:26 --- This test started to fail when it was moved in r140340 from gcc.c-torture to gcc.c-torture/compile. It doesn't fail with 4.2.4, but does with 4.3.2. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.4 Regression] FAIL: |[4.3/4.4 Regression] FAIL: |gcc.c- |gcc.c- |torture/compile/pr36141.c at|torture/compile/pr36141.c at |-O1 and above |-O1 and above http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37603
[Bug target/37528] [4.4 Regression] boostrap failure due to configure problems
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||build Summary|boostrap failure due to |[4.4 Regression] boostrap |configure problems |failure due to configure ||problems Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37528
[Bug bootstrap/37600] Bootstrap Failure with Undefined References
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-20 22:48 --- *** This bug has been marked as a duplicate of 37528 *** -- 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=37600
[Bug target/37528] [4.4 Regression] boostrap failure due to configure problems
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-09-20 22:48 --- *** Bug 37600 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37528
[Bug rtl-optimization/36758] [4.3/4.4 Regression] address addition moved out of the loop
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-09-20 22:51 --- Set in insn 6 is invariant (0), cost 0, depends on -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36758
[Bug rtl-optimization/36758] [4.3/4.4 Regression] address addition moved out of the loop
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-09-20 22:54 ---
The original insn:
(insn 6 5 7 3 t.c:6 (set (reg:SI 3 3)
(reg/f:SI 122)) 325 {*movsi_internal1} (expr_list:REG_EQUAL (plus:SI
(reg/f:SI 113 sfp)
(const_int 8 [0x8]))
(nil)))
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36758
[Bug rtl-optimization/36758] [4.3/4.4 Regression] address addition moved out of the loop
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-09-20 23:32 ---
(In reply to comment #4)
This might be a cost issue in the ppc backend (and so target, not
rtl-optimization).
GCSE is pulling out the invariant.
Before GCSE we had:
(insn 20 5 6 3 t.c:6 (set (reg/f:SI 121)
(plus:SI (reg/f:SI 113 sfp)
(const_int 8 [0x8]))) -1 (nil))
(insn 6 20 7 3 t.c:6 (set (reg:SI 3 3)
(reg/f:SI 121)) 325 {*movsi_internal1} (expr_list:REG_EQUAL (plus:SI
(reg/f:SI 113 sfp)
(const_int 8 [0x8]))
(nil)))
(call_insn 7 6 8 3 t.c:6 (parallel [
(set (reg:SI 3 3)
(call (mem:SI (symbol_ref:SI (f0) [flags 0x41] function_decl
0xf7d41e00 f0) [0 S4 A8])
(const_int 0 [0x0])))
(use (const_int 0 [0x0]))
(clobber (reg:SI 65 lr))
]) 450 {*call_value_nonlocal_sysvsi} (nil)
(expr_list:REG_DEP_TRUE (use (reg:SI 3 3))
(nil)))
(insn 8 7 10 3 t.c:6 (set (reg:SI 119 [ D.1255 ])
(reg:SI 3 3)) 325 {*movsi_internal1} (nil))
(insn 10 8 11 3 t.c:6 (set (reg:CC 120)
(compare:CC (reg:SI 119 [ D.1255 ])
(const_int 0 [0x0]))) 471 {*cmpsi_internal1} (nil))
(jump_insn 11 10 19 3 t.c:6 (set (pc)
(if_then_else (ne (reg:CC 120)
(const_int 0 [0x0]))
(label_ref 9)
(pc))) 560 {*rs6000.md:13857} (expr_list:REG_BR_PROB (const_int
8600 [0x2198])
(nil)))
And then it pulled out the set outside of the loop.
Why didn't we combine the set of reg 121 into its one use in the set of 3
before the fact (like in fwprop)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36758
[Bug rtl-optimization/36758] [4.3/4.4 Regression] address addition moved out of the loop
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-09-20 23:35 --- GCSE in 4.1.1 did not move this for some reason ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36758
[Bug rtl-optimization/36758] [4.3/4.4 Regression] address addition moved out of the loop
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-09-21 00:20 --- After changing fwprop.c to do the prop if it was used only once, loop-invariant.c pulls it out again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36758
[Bug middle-end/37603] [4.3/4.4 Regression] FAIL: gcc.c-torture/compile/pr36141.c at -O1 and above
--- Comment #2 from danglin at gcc dot gnu dot org 2008-09-21 00:23 --- 'x' is not a legitimate constant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37603
[Bug rtl-optimization/36758] [4.3/4.4 Regression] address addition moved out of the loop
--- Comment #10 from pinskia at gcc dot gnu dot org 2008-09-21 00:26 --- Now in gain_for_invariant, size_cost is zero, even though we have a hard register so we know it will have an extra move. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36758
[Bug rtl-optimization/37471] Move invariant pulls too many cmps out of a loop
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-21 00:32 --- While looking a different bug dealing with invariant motion, I noticed that estimate_reg_pressure_cost does not take into account the mode of the new register. This seems like a big issue. Also init_set_costs always uses SImode which is not a good representation of the register pressure in general. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37471
[Bug rtl-optimization/36758] [4.3/4.4 Regression] addition moved out of the loop when used with an argument
--- Comment #11 from pinskia at gcc dot gnu dot org 2008-09-21 00:45
---
Here is another testcase which shows the issue:
int f(int b);
float g(int a)
{
while (f(a + 1));
while (f(a));
}
--- CUT ---
This increases the need for another volatile register and in fact increases
register pressure even more.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.3/4.4 Regression] address|[4.3/4.4 Regression]
|addition moved out of the |addition moved out of the
|loop|loop when used with an
||argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36758
[Bug middle-end/37443] fast 64-bit divide by constant on 32-bit platform
--- Comment #4 from ajrobb at bigfoot dot com 2008-09-21 02:39 --- Created an attachment (id=16370) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16370action=view) proposed 32-bit API calls for 64-bit constant divison The original attachment did not handle shift greater than 31. -- ajrobb at bigfoot dot com changed: What|Removed |Added Attachment #16369|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37443
[Bug fortran/37498] [4.4 Regression] Incorrect array value returned - 4.3 ABI Broken
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2008-09-21 04:15 --- Experimental patch submitted to list for comment. http://gcc.gnu.org/ml/fortran/2008-09/msg00353.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37498
