[Bug rtl-optimization/32283] [4.3/4.4 regression] Missed induction variable optimization
--- Comment #23 from rakdver at gcc dot gnu dot org 2008-11-20 08:06 --- Subject: Bug 32283 Author: rakdver Date: Thu Nov 20 08:05:12 2008 New Revision: 142035 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142035 Log: PR rtl-optimization/32283 * tree-ssa-loop-niter.c (scev_probably_wraps_p): Use type of the base of the induction variable to decide whether it may wrap. * tree-ssa-loop-ivopts.c (rewrite_use_compare): Emit the initialization of the bound before the loop. * simplify-rtx.c (simplify_binary_operation_1): Add two simplifications regarding AND. (simplify_plus_minus): Only fail if no simplification is possible. * loop-iv.c (simple_rhs_p): Consider reg + reg and reg cst simple. Modified: trunk/gcc/ChangeLog trunk/gcc/loop-iv.c trunk/gcc/simplify-rtx.c trunk/gcc/tree-ssa-loop-ivopts.c trunk/gcc/tree-ssa-loop-niter.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32283
[Bug tree-optimization/32306] [4.2/4.3/4.4 Regression] redundant || not eliminated
--- Comment #13 from bonzini at gnu dot org 2008-11-20 08:48 --- I agree with Steven that the bug title does not make sense. It is the same as complaining that IRA has a regression because it disables regmove. OTOH, this *is* a regression and the bug should stay open. For example, it could be fixed by doing some of the tree optimizations with not lowered to jumps (just shooting). -- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org Summary|[4.2/4.3/4.4 Regression] DOM|[4.2/4.3/4.4 Regression] |jump threading no longer|redundant || not |iterates|eliminated http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32306
[Bug fortran/38181] calls to SIZE not optimized out of loops
--- Comment #4 from jv244 at cam dot ac dot uk 2008-11-20 08:53 --- so I guess this is up to the front end to generate 'better' code for size -- jv244 at cam dot ac dot uk changed: What|Removed |Added OtherBugsDependingO||36854 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38181
[Bug c/38186] when using gcc compile the code with option -g3, I find the inline assemble code are palced in section .debug_macinfo
--- Comment #1 from schwab at suse dot de 2008-11-20 09:19 --- *** Bug 38187 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38186
[Bug c/38187] when using gcc compile the code with option -g3, I find the inline assemble code are palced in section .debug_macinfo
--- Comment #1 from schwab at suse dot de 2008-11-20 09:19 --- *** This bug has been marked as a duplicate of 38186 *** -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38187
[Bug java/38189] New: Java: set but not used local variable in tight loop
I just had a look at some of the source code of the Java package in the GNU gcc version 4.4.0 snapshot 20081114 gcc-4.4-20081114/libjava/classpath/gnu/xml/aelfred2/XmlParser.java:3205 Avoid unused local variables such as 'ampRead'. I have checked the source code and I agree. Suggest remove set but not used local variable, especially since it is written to for each character read. -- Summary: Java: set but not used local variable in tight loop Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: suse-linux-x86_64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38189
[Bug java/38190] New: ConcurrentHashMap.java: 2 * unused local variables
I just had a look at some of the source code of the Java package in the GNU gcc version 4.4.0 snapshot 20081114 gcc-4.4-20081114/libjava/classpath/external/jsr166/java/util/concurrent/ConcurrentHashMap.java:807 Avoid unused local variables such as 'c'. gcc-4.4-20081114/libjava/classpath/external/jsr166/java/util/concurrent/ConcurrentHashMap.java:815 Avoid unused local variables such as 'c'. I have checked the source code and I agree. Suggest remove these two unused local variables, especially since they are in a for loop. -- Summary: ConcurrentHashMap.java: 2 * unused local variables Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: suse-linux-x86_64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38190
[Bug fortran/38181] calls to SIZE not optimized out of loops
--- Comment #5 from jakub at gcc dot gnu dot org 2008-11-20 09:44 --- Subject: Bug 38181 Author: jakub Date: Thu Nov 20 09:42:35 2008 New Revision: 142037 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142037 Log: PR fortran/38181 * trans-intrinsic.c (gfc_conv_intrinsic_size): Inline 2 argument size if the second argument is not optional and one argument size for rank 1 arrays. * gfortran.dg/array_section_2.f90: Adjust pattern to match the inlined size0 instead of a size0 call. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/array_section_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38181
[Bug java/38191] New: gjdoc/Main.java: dead local variable
I just had a look at some of the source code of the Java package in the GNU gcc version 4.4.0 snapshot 20081114 gcc-4.4-20081114/libjava/classpath/tools/gnu/classpath/tools/gjdoc/Main.java:1056 Avoid unused local variables such as 'customOptions'. The source code is List customOptions = new LinkedList(); Suggest remove unused local variable and reduce memory usage at the same time. -- Summary: gjdoc/Main.java: dead local variable Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: suse-linux-x86_64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38191
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #63 from rguenth at gcc dot gnu dot org 2008-11-20 10:01 --- The patch looks reasonable. I understand that the warning is enabled by default but does not trigger from libstdc++ because that's system headers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug java/38192] New: SwingCallbackHandler.java: remove unused local variable
gcc-4.4-20081114/libjava/classpath/gnu/javax/security/auth/callback/SwingCallbackHandler.java:302
Avoid unused local variables such as'defaultIndex'.
The source code is
int defaultIndex = 0;
for (int i = 0; i locales.length; i++)
{
localeNames[i+1] = locales[i].getDisplayLanguage (locales[i]);
String country = locales[i].getDisplayCountry (locales[i]);
if (country.length () 0)
localeNames[i+1] += ( + country + );
if (locales[i].equals (locale))
defaultIndex = i;
}
Suggest remove unused local variable defaultIndex, since it is in a loop.
--
Summary: SwingCallbackHandler.java: remove unused local variable
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
GCC host triplet: suse-linux-x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38192
[Bug java/38193] New: HashMap.java: unused local variable
I just had a look at some of the source code of the Java package in the GNU gcc version 4.4.0 snapshot 20081114 /home/dcb/gcc/20081114/javaExperiment/gcc-4.4-20081114/libjava/classpath/java/util/HashMap.java:749 Avoid unused local variables such as 'dest'. The source code is HashEntryK, V dest = buckets[idx]; Suggest remove unused local variable dest, since it is in a loop. -- Summary: HashMap.java: unused local variable Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: suse-linux-x86_64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38193
[Bug fortran/38181] calls to SIZE not optimized out of loops
--- Comment #6 from jakub at gcc dot gnu dot org 2008-11-20 10:21 --- With this patch, I got: $ time ./test1 # 4.4 r142036 real0m3.291s user0m3.289s sys 0m0.002s $ time ./test2 # 4.4 r142037 real0m1.327s user0m1.325s sys 0m0.002s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38181
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #64 from paolo dot carlini at oracle dot com 2008-11-20 10:24 --- (assuming I understand correctly Jason' approach - didn't really follow in detail the thread, lately) let me know if you want me to remove the exception_defines.h tricks from the library... -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||paolo at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug libf2c/38194] New: DefaultListSelectionModel.java: remove dead for loop ?
I just had a look at some of the source code of the Java package in the GNU gcc version 4.4.0 snapshot 20081114 gcc-4.4-20081114/libjava/classpath/javax/swing/DefaultListSelectionModel.java:300 Avoid unused local variables such as 'end'. The source code is int beg = sel.nextSetBit(0), end = -1; for(int i=beg; i = 0; i=sel.nextSetBit(i+1)) end = i; Suggest remove unused local variable end, since it is in a for loop. It also looks like the for loop can be removed. -- Summary: DefaultListSelectionModel.java: remove dead for loop ? Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: libf2c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: suse-linux-x86_64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38194
[Bug libstdc++/38196] New: num_put::do_put(bool) performs 'internal' padding incorrectly when boolalpha==true
The description of num_put::do_put(bool) function states (22.2.2.2.2): iter_type do_put(iter_type out, ios_base str, char_type fill, bool val) const; Effects: If (str.flags()ios_base::boolalpha)==0 then do out = do_put(out, str, fill, (int)val) Otherwise do const numpunct np = use_facetnumpunctcharT (loc); string_type s = val ? np.truename() : np.falsename(); and then insert the characters of s into out. It is not specified how exactly the insertion the characters of s into out iterator is performed. It seems that the padding of the string is done the same way as for the other functions from num_put::do_put() family, namely (22.2.2.2.2 p19 Table 61): adjustfield == iosbase::left - pad after adjustfield == iosbase::right - pad before adjustfield == internal and a sign occurs in the representation - pad after the sign adjustfield == internal and representation after stage 1 began with 0x or 0X - pad after x or X otherwise pad before num_put::do_put(bool), however, should output a string that in general is not a string representation of some number. It makes no sense for a string that can be arbitrary to process the sign symbols, 0x or 0X in a different way than its other substrings. That means, the 'internal' flag should be functionally equivalent to 'right' (pad before) in this case. This is exactly the way the operator for inserting sequences of symbols into a stream (operator for const charT*) is implemented. Although the description of padding in this case (27.6.2.5.4, p2) refers to the description of num_put::do_put, in practice the 'internal' flag is functionally equivalent to 'right' in this case, which makes sense. However, the implementation of num_put::do_put(bool) performs 'internal' padding not like operator for sequences of characters but rather the same way as the other functions from num_put::do_put family: it inserts fill symbols between the 'sign' or 0x/0X and the rest of the string. -- Summary: num_put::do_put(bool) performs 'internal' padding incorrectly when boolalpha==true Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tsyvarev at ispras dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38196
[Bug libstdc++/38196] num_put::do_put(bool) performs 'internal' padding incorrectly when boolalpha==true
--- Comment #1 from tsyvarev at ispras dot ru 2008-11-20 10:57 ---
Example:
#include iostream
#include locale
using namespace std;
class my_numpunct : public numpunctchar
{
protected:
string do_falsename() const {return -no-;}
};
int main()
{
locale my_loc = locale(locale::classic(), new my_numpunct());
cout.imbue(my_loc);
cout.width(6);
bool b = false;
cout internal boolalpha b endl;
return 0;
}
output - no- instead of -no-
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38196
[Bug java/38195] New: ClassRmicCompiler.java: remove unused variable
I just had a look at some of the source code of the Java package in the GNU gcc version 4.4.0 snapshot 20081114 gcc-4.4-20081114/libjava/classpath/tools/gnu/classpath/tools/rmic/ClassRmicCompiler.java:922 Avoid unused local variables such as'endReturnTryCatch'. The source code is Label endReturnTryCatch = new Label(); Suggest remove unused local variable endReturnTryCatch. -- Summary: ClassRmicCompiler.java: remove unused variable Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: suse-linux-x86_64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38195
[Bug fortran/38181] calls to SIZE not optimized out of loops
--- Comment #7 from jv244 at cam dot ac dot uk 2008-11-20 11:03 --- (In reply to comment #6) great.. thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38181
[Bug java/38197] New: JobSheetsSupported.java: unused local variable
I just had a look at some of the source code of the Java package in
the GNU gcc version 4.4.0 snapshot 20081114
gcc-4.4-20081114/libjava/classpath/gnu/javax/print/ipp/attribute/supported/JobSheetsSupported.java:138
Avoid unused local variables such as 'j'.
The source code is
int j = 0;
while (it.hasNext())
{
tmp = (JobSheetsSupported) it.next();
Attribute att = tmp.getAssociatedAttribute();
if (att != null)
result.add(att);
j++;
}
Suggest remove unused local variable j.
--
Summary: JobSheetsSupported.java: unused local variable
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
GCC host triplet: suse-linux-x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38197
[Bug java/38198] New: DefaultTableColumnModel.java: redundant call to new
I just had a look at some of the source code of the Java package in the GNU gcc version 4.4.0 snapshot 20081114 gcc-4.4-20081114/libjava/classpath/javax/swing/table/DefaultTableColumnModel.java:401 Avoid unused local variables such as 'ls'. The source code is java.util.ArrayList ls = new java.util.ArrayList(); Suggest remove unused local variable ls. -- Summary: DefaultTableColumnModel.java: redundant call to new Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: suse-linux-x86_64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38198
[Bug fortran/38181] calls to SIZE not optimized out of loops
--- Comment #8 from jakub at gcc dot gnu dot org 2008-11-20 12:07 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38181
[Bug tree-optimization/37868] [4.3 Regression] code that breaks TBAA is misoptimized even with -fno-strict-aliasing
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-11-20 12:13 --- Subject: Bug 37868 Author: rguenth Date: Thu Nov 20 12:12:01 2008 New Revision: 142040 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142040 Log: 2008-11-20 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/37868 * tree-ssa-structalias.c (set_uids_in_ptset): Add SFTs based on pointed to variable and access size. * gcc.dg/torture/pr37868.c: New testcase. * gcc.c-torture/execute/pr38048-1.c: Likewise. * gcc.c-torture/execute/pr38048-2.c: Likewise. Backport from mainline: 2008-07-07 Richard Guenther [EMAIL PROTECTED] * tree-ssa-structalias.c (struct variable_info): Add is_full_var flag. (new_var_info): Set it to false. (solution_set_add): Correctly handle pointers outside a var and inside a field. (type_safe): Treat variables with is_full_var properly. (do_sd_constraint): Likewise. (do_ds_constraint): Likewise. (process_constraint): Remove zeroing offset for !use_field_sensitive. (get_constraint_for_ptr_offset): New function. (get_constraint_for_component_ref): Handle is_full_vars properly. (get_constraint_for): Handle POINTER_PLUS_EXPR. (handle_ptr_arith): Remove. (find_func_aliases): Handle POINTER_PLUS_EXPR through generic get_constraint_for code. (create_function_info_for): For parameter and result varinfos set is_full_var flag. (create_variable_info_for): Set is_full_var flag whenever we just created a single varinfo for a decl. (init_alias_vars): Initialize use_field_sensitive from max-fields-for-field-sensitive parameter. * gcc.dg/torture/pta-ptrarith-1.c: New testcase. * gcc.dg/torture/pta-ptrarith-2.c: Likewise. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/execute/pr38048-1.c branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/execute/pr38048-2.c branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/torture/pr37868.c branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/torture/pta-ptrarith-1.c branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/torture/pta-ptrarith-2.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/tree-ssa-structalias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37868
[Bug tree-optimization/37868] [4.3 Regression] code that breaks TBAA is misoptimized even with -fno-strict-aliasing
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-11-20 12:14 --- 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=37868
[Bug tree-optimization/38169] Wrong string constant optimizing
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-11-20 12:15 --- Fixed. *** This bug has been marked as a duplicate of 38051 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Keywords||alias, wrong-code Resolution||DUPLICATE Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38169
[Bug tree-optimization/38051] [4.4 Regression] Miscompilation of glibc's memcmp
--- Comment #15 from rguenth at gcc dot gnu dot org 2008-11-20 12:15 --- *** Bug 38169 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||holger dot hopp at sap dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38051
[Bug tree-optimization/37868] [4.3 Regression] code that breaks TBAA is misoptimized even with -fno-strict-aliasing
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-11-20 12:26 --- Subject: Bug 37868 Author: rguenth Date: Thu Nov 20 12:25:26 2008 New Revision: 142041 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142041 Log: 2008-11-20 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/37868 * gcc.dg/torture/pr37868.c: New testcase. * gcc.c-torture/execute/pr38048-1.c: Likewise. * gcc.c-torture/execute/pr38048-2.c: Likewise. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr38048-1.c trunk/gcc/testsuite/gcc.c-torture/execute/pr38048-2.c trunk/gcc/testsuite/gcc.dg/torture/pr37868.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37868
[Bug target/38151] structures with _Complex arguments are not passed correctly
--- Comment #15 from howarth at nitro dot med dot uc dot edu 2008-11-20 12:55 --- The patch in comment 13 appears to be sufficient to completely fix the problem on i686-apple-darwin9. The results for current gcc trunk with the patch... http://gcc.gnu.org/ml/gcc-testresults/2008-11/msg01712.html ...compared to those without the patch... http://gcc.gnu.org/ml/gcc-testresults/2008-11/msg01535.html shows that... FAIL: tmpdir-gcc.dg-struct-layout-1/t028 c_compat_x_tst.o-c_compat_y_tst.o execute is eliminated at -m64 without any regressions in other tests. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38151
[Bug driver/21706] MAXPATHLEN usage in [gcc]/gcc/tlink.c
--- Comment #9 from tschwinge at gcc dot gnu dot org 2008-11-20 13:26 --- Fixed on trunk as rev142043. -- tschwinge at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21706
[Bug libstdc++/38196] num_put::do_put(bool) performs 'internal' padding incorrectly when boolalpha==true
--- Comment #2 from paolo dot carlini at oracle dot com 2008-11-20 13:42 --- Ok, let's do this. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-20 13:42:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38196
[Bug fortran/38066] bug6 ambiguous reference
--- Comment #8 from mikael at gcc dot gnu dot org 2008-11-20 13:43 --- Created an attachment (id=16727) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16727action=view) much more manageable testcase I think the testcase is invalid as both PBit4set and PBit8set contain a getNullSet function and are included together in module bug6 without renaming. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38066
[Bug fortran/38199] New: missed optimization, regression: I/O performance
With !234567 character buffer*1000 integer i,j DO j=1,20 write(buffer,'(i2)') j write(*,*) buffer(1:2) read(buffer,*) i write(*,*) i ENDDO end I get the following timings: ifort11 (64bit): 0.306s ifort9 (32bit):0.562s g77 (32bit): 2.786s gfortran4.3 (64bit): 3.906s gfortran4.4 (20081120, 64bit): 4.832s Even worse: !234567 character buffer*10 integer i,j DO j=1, write(buffer,'(i4)') j write(*,*) buffer(1:4) read(buffer,*) i write(*,*) i ENDDO end ifort11 (64bit):0.458s g77 (32bit): 13.283s gfortran4.3 (64bit): 19.362s gfortran4.4 (20081120, 64bit): 23.917s This is a very realistic real-world scenario when reading in a flat-file of unknown width (10 assumed), and then processing the received string buffer, i.e. doing 100 read(10,'(a)',END=999) buffer --- read(buffer,*,END=101,ERR=101) array 101 do something when unexpected content GOTO 100 999 end -- Summary: missed optimization, regression: I/O performance Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: manfred99 at gmx dot ch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199
[Bug fortran/38199] missed optimization, regression: I/O performance
--- Comment #1 from jb at gcc dot gnu dot org 2008-11-20 14:04 --- I'm looking at I/O performance as part of PR 25561 (see also PR 37754, perhaps this is a dup?), but my changes are invasive enough that they are 4.5 material. Thanks for the report. -- jb at gcc dot gnu dot org changed: What|Removed |Added CC||jb at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-20 14:04:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199
[Bug regression/38200] New: internal compiler error: in find_func_aliases, at tree-ssa-structalias.c:3905
I found following internal compiler error in gcc trunk rev. 142038,
maybe a regression of bug 38051 fix.
$ gcc-4.4 -O2 -c tst.c
tst.c: In function bar2:
tst.c:20: internal compiler error: in find_func_aliases, at
tree-ssa-structalias.c:3905
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
Exit 1
int foo ( void **x ) { return 0; }
int (* foo_ptr) ( void **x ) = foo;
typedef int ( CALL)(void);
typedef CALL *ADR;
int foo2 ( ADR * adr );
static int bar ( void )
{
int rc;
void *ptr;
rc = foo2 ( (ADR *)ptr );
*( (void **) foo_ptr ) = ptr;;
return 0;
}
void bar2( void )
{
int rc = bar();
}
--
Summary: internal compiler error: in find_func_aliases, at tree-
ssa-structalias.c:3905
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: holger dot hopp at sap dot com
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=38200
[Bug fortran/38115] unneeded temp
--- Comment #3 from mikael at gcc dot gnu dot org 2008-11-20 14:33 --- duplicate of pr36935? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38115
[Bug target/38201] New: -mfma/-mavx and -msse5/-msse4a don't work together
Both Intel FMA and AMD SSE5 support FMA. For -mfma, which enables
Intel FMA and is a dummy at the moment, or -msse5, we will
generate FMA instructions for
double f;
void
foo (double x, double y, double z)
{
f = x * y + z;
}
What FMA should -mfma -msse5 generate? Also currently, with
-O2 -mavx -msse5, we generate
foo:
fmaddsd %xmm2, %xmm1, %xmm0, %xmm0
vmovsd %xmm0, f(%rip)
ret
which won't run on any machines. For -mfma -msse5 and
-mavx -msse5,
1. Should these combinations be allowed? If allowed,
2. Should the last option turn off the first one?
--
Summary: -mfma/-mavx and -msse5/-msse4a don't work together
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: target
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=38201
[Bug target/38185] -fstrict-aliasing causes wrong register usage
--- Comment #2 from ddenisen at altera dot com 2008-11-20 14:57 --- I searched through all the options in -O2 that are not in -O1 and found that only one triggers the problem: -fstrict-aliasing. To summarize, g++ -m32 -O1 a.ii does not cause the problem but g++ -m32 -O1 -fstrict-aliasing a.ii does. Changing the title of the bug to reflect this information. -- ddenisen at altera dot com changed: What|Removed |Added Summary|Wrong register used to get |-fstrict-aliasing causes |struct information |wrong register usage http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38185
[Bug fortran/38199] missed optimization, regression: I/O performance
--- Comment #2 from manfred99 at gmx dot ch 2008-11-20 14:59 --- The profiling of the second testcase gives % cumulative self self total time seconds secondscalls Ts/call Ts/call name 44.20 8.34 8.34 next_char 24.85 13.03 4.69 mem_read 17.04 16.25 3.22 memcpy 4.98 17.19 0.94 eat_spaces 4.03 17.95 0.76 _gfortrani_empty_internal_buffer 2.44 18.41 0.46 nml_query 2.09 18.80 0.40 strncasecmp_l 0.21 18.84 0.04 memset 0.05 18.85 0.01 __divti3 0.05 18.86 0.01 _gfortrani_write_block 0.05 18.87 0.01 next_char 0.00 18.87 0.001 0.00 0.00 MAIN__ It seems gfortran reads character by character and does not take any opportunities to shortcut the read process. For this case, one could imagine that the read routine would scan for the last non-blank character and would stop reading at this position. Perhaps ifort is doing exactly this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199
[Bug libfortran/37839] st_parameter_dt has unwanted padding, is out of sync with compiler
--- Comment #12 from jakub at gcc dot gnu dot org 2008-11-20 15:08 --- I think the primary question is, is libgfortran in 4.4 supposed to stay at libgfortran.so.3? If yes, then it must be backwards compatible with 4.3. Looking at the 4.3 to 4.4 io.h changes, I see several problems. The st_parameter_open changes look good to me. st_parameter_inquire changes are wrong, io.h has: @@ -299,6 +339,15 @@ typedef struct CHARACTER1 (write); CHARACTER2 (readwrite); CHARACTER1 (convert); + GFC_INTEGER_4 flags2; + CHARACTER1 (asynchronous); + CHARACTER2 (decimal); + CHARACTER1 (encoding); + CHARACTER2 (pending); + CHARACTER1 (round); + CHARACTER2 (sign); + GFC_INTEGER_4 *size; + GFC_INTEGER_4 *id; } st_parameter_inquire; but ioparm.def has: @@ -54,6 +59,17 @@ IOPARM (inquire, read, 1 27, char2) IOPARM (inquire, write,1 28, char1) IOPARM (inquire, readwrite,1 29, char2) IOPARM (inquire, convert, 1 30, char1) +IOPARM (inquire, flags2, 1 31, int4) +IOPARM (inquire, asynchronous, 1 0, char1) +IOPARM (inquire, decimal, 1 1, char2) +IOPARM (inquire, encoding, 1 2, char1) +IOPARM (inquire, pending, 1 3, pint4) +IOPARM (inquire, round,1 4, char1) +IOPARM (inquire, sign, 1 5, char2) +IOPARM (inquire, size, 1 6, pint4) +IOPARM (inquire, id, 1 7, pint4) +IOPARM (wait,common, 0, common) +IOPARM (wait,id, 1 7, pint4) #ifndef IOPARM_dt_list_format #define IOPARM_dt_list_format (1 7) #define IOPARM_dt_namelist_read_mode (1 8) Look at pending, the types don't match. Either it is a char2 (i.e. int length followed by char *), but then it should be char2 in both places, or it is pint4 (i.e. a int *), but then it should be pint4 in both places and everything adjusted, so that there aren't unneeded gaps. st_parameter_dt changes are unfortunately worse. Putting the FE filled new fields into the union is definitely a bad idea, and as gfc_transfer_init clears the whole u.pad, it is ABI incompatible anyway (4.3 compiled programs reserve just 192 (32-bit) resp. 256 (64-bit) bytes for the padding, it will result in writes after end of allocated st_parameter_dt variables in 4.3 running against 4.4 libgfortran. The fix is easy. Either move the newly added fields at the end of the structure and decrease size of pad back to 16 * sizeof (char *) + 32 * sizeof (int), after all, there is plenty of space for new stuff left in there and apparently no new libgfortran internal fields were added to u.p during 4.4. (this is my preferred solution) or, move the newly added FE filled fields before the union and decrease size of the u.pad accordingly, then find out at runtime where to put say the u.p.value field (it could overlap the newly added FE filled fields if none of them are used, or if they are used, could be after the current padding. I'll work on a patch, but would like to hear first 1) whether 4.4 libgfortran is really meant to be backward compatible with 4.3 (I hope so) and 2) what type should pending in INQUIRE have. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37839
[Bug target/38185] -fstrict-aliasing causes wrong register usage
--- Comment #3 from ddenisen at altera dot com 2008-11-20 15:10 --- This could be a duplicate of 35643. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38185
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #65 from jason at redhat dot com 2008-11-20 15:14 --- Subject: Re: exception_defines.h #defines try/catch No, it doesn't make any sense to use try/catch in a program that you're planning to build with -fno-exceptions. It does, however, make sense to use try/catch in a general purpose library that you want to work with exceptions enabled or disabled, such as libstdc++. I believe Lubos is arguing that such libraries ought to use preprocessor tricks to accomplish this, but defining something like __try and __catch instead of try and catch. The difference between this approach and my patch is that it requires the library writer to jump through hoops to make their code work with exceptions enabled and disabled. I guess Lubos thinks this is good, that this is an unusual thing to want to do and so people that want to do it need to be very explicit about it so that people who don't want that but mistakenly build their code with -fno-exceptions get an error rather than a warning. Anyone else have an opinion about this? And yes, -Wexceptions is on by default in my patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug middle-end/38200] [4.4 Regression] internal compiler error: in find_func_aliases, at tree-ssa-structalias.c:3905
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-11-20 15:15 ---
Invalid gimple:
(gdb) call debug_gimple_stmt (origt)
# STORES: { foo_ptr }
foo_ptr ={v} (int (*T4cb) (void * *)) ptr.3_4;
produced by forwprop. Probably caused by Jakubs patch
2008-11-17 Jakub Jelinek [EMAIL PROTECTED]
PR middle-end/38140
* tree-ssa-forwprop.c (forward_propagate_addr_expr_1): If
propagating x = a into *x = b, add a cast if not useless
type conversion or don't optimize if another stmt would be
needed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||jakub at gcc dot gnu dot
||org, rguenth at gcc dot gnu
||dot org
Status|UNCONFIRMED |NEW
Component|regression |middle-end
Ever Confirmed|0 |1
Keywords||ice-on-valid-code
Last reconfirmed|-00-00 00:00:00 |2008-11-20 15:15:11
date||
Summary|internal compiler error: in |[4.4 Regression] internal
|find_func_aliases, at tree- |compiler error: in
|ssa-structalias.c:3905 |find_func_aliases, at tree-
||ssa-structalias.c:3905
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38200
[Bug target/38185] -fstrict-aliasing causes wrong register usage
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-11-20 15:41 --- Nope, this is very likely a dup of PR29286. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38185
[Bug libfortran/25830] [libgfortran] Optionally support multi-process locking
--- Comment #3 from burnus at gcc dot gnu dot org 2008-11-20 15:52 --- Other compilers have the SHARE= specifier for OPEN and INQUIRE, e.g. Intel or HP. I'm not sure it is needed, but one could consider supporting it as well when implementing this option. http://www.intel.com/software/products/compilers/docs/flin/main_for/lref_for/source_files/rflioop.htm I think Fortran 2008 does not allow to such access which makes it a non-issue in terms of the standard, including for coarrays, but still this is a not so rarely requested feature. (But one has to be careful as a user otherwise the program might read/write garbage.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25830
[Bug fortran/38199] [4.4 regression] I/O performance
--- Comment #3 from burnus at gcc dot gnu dot org 2008-11-20 15:56 --- Jerry, regarding the suggestion in comment 2: Do you see that we can do there some optimization, esp. when reading a number or with * a string (for '(a)' one presumably cannot do any optimization and has to read past all blanks). -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu dot ||org Keywords||missed-optimization Priority|P3 |P4 Summary|missed optimization,|[4.4 regression] I/O |regression: I/O performance |performance http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199
[Bug bootstrap/37859] Bootstrap failure on mips64octeon-unknown-linux-gnu
--- Comment #5 from hjl at gcc dot gnu dot org 2008-11-20 15:56 --- Subject: Bug 37859 Author: hjl Date: Thu Nov 20 15:55:30 2008 New Revision: 142047 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142047 Log: 2008-11-20 H.J. Lu [EMAIL PROTECTED] Backport from mainline: 2008-11-19 Vladimir Makarov [EMAIL PROTECTED] PR bootstrap/37859 * ira-int.h (struct ira_loop_tree_node): New member entered_from_non_parent_p. * ira-color.c (print_loop_title): Print loop bbs. * ira-emit.c (entered_from_non_parent_p, setup_entered_from_non_parent_p): New functions. (not_modified_p): Rename to store_can_be_removed_p. Check there is no side entries. (generate_edge_moves): Use store_can_be_removed_p instead of not_modified_p. (ira_emit): Call setup_entered_from_non_parent_p. * ira-build.c (copy_info_to_removed_store_destinations): Accumulate CALL_FREQ, CALL_CROSSED_NUM, and ALLOCNO_EXCESS_PRESSURE_POINTS_NUM. (ira_flattening): Don't CHECK MEM_OPTIMIZED_DEST[_P], always update all accumulated attributes. Modified: branches/ira-merge/gcc/ChangeLog.ira branches/ira-merge/gcc/ira-build.c branches/ira-merge/gcc/ira-color.c branches/ira-merge/gcc/ira-emit.c branches/ira-merge/gcc/ira-int.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37859
[Bug libstdc++/38196] num_put::do_put(bool) performs 'internal' padding incorrectly when boolalpha==true
--- Comment #3 from paolo at gcc dot gnu dot org 2008-11-20 16:01 --- Subject: Bug 38196 Author: paolo Date: Thu Nov 20 16:00:17 2008 New Revision: 142048 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142048 Log: 2008-11-20 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/38196 * include/bits/locale_facets.tcc (num_put::do_put(iter_type, ios_base, char_type, bool)): Fix. * testsuite/22_locale/num_put/put/char/38196.cc: New. * testsuite/22_locale/num_put/put/wchar_t/38196.cc: Likewise. Added: trunk/libstdc++-v3/testsuite/22_locale/num_put/put/char/38196.cc trunk/libstdc++-v3/testsuite/22_locale/num_put/put/wchar_t/38196.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/locale_facets.tcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38196
[Bug libstdc++/38196] num_put::do_put(bool) performs 'internal' padding incorrectly when boolalpha==true
--- Comment #4 from paolo dot carlini at oracle dot com 2008-11-20 16:02 --- Fixed for 4.4.0. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38196
[Bug testsuite/38202] New: [avr] FAIL: gcc.dg/torture/pr37868.c
New test gcc.dg/torture/pr37868.c fails for -O[0123s] with:
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/torture/pr37868.c:8: error:
width of 'a' exceeds its type
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/torture/pr37868.c:9: error:
width of 'b' exceeds its type
The test contains these declarations:
struct X {
unsigned char pad : 4;
unsigned int a : 32;
unsigned int b : 24;
unsigned int c : 6;
} __attribute__((packed));
An int on the AVR is 16-bits, hence the width of 'a' and 'b' exceed their type.
--
Summary: [avr] FAIL: gcc.dg/torture/pr37868.c
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eric dot weddington at atmel dot com
GCC target triplet: avr-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38202
[Bug testsuite/38202] [avr] FAIL: gcc.dg/torture/pr37868.c
--- Comment #1 from eric dot weddington at atmel dot com 2008-11-20 16:14 --- Test was added by: 2008-11-20 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/37868 * gcc.dg/torture/pr37868.c: New testcase. * gcc.c-torture/execute/pr38048-1.c: Likewise. * gcc.c-torture/execute/pr38048-2.c: Likewise. -- eric dot weddington at atmel dot com changed: What|Removed |Added CC||rguenther at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38202
[Bug middle-end/37742] [4.4 Regression] ICE in vectorizer with restrict pointer
--- Comment #20 from rguenth at gcc dot gnu dot org 2008-11-20 16:25
---
Reduced testcase for the libgfortran failure (-O2 -ftree-vectorize):
void matmul_i4 (int * __restrict dest_y,
const int * __restrict abase,
const int * __restrict bbase_y,
int count, int xcount, int ycount, int aystride)
{
int x, y, n;
const int * __restrict abase_n;
int bbase_yn;
for (y = 0; y ycount; y++)
for (n = 0; n count; n++) {
abase_n = abase + n*aystride;
bbase_yn = bbase_y[n];
for (x = 0; x xcount; x++)
dest_y[x] += abase_n[x] * bbase_yn;
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37742
[Bug fortran/38199] [4.4 regression] I/O performance
--- Comment #4 from manfred99 at gmx dot ch 2008-11-20 16:09 --- Consider !234567 program internalread3 implicit none character value*10 integer i,j DO j=1, write(value,'(i4)') j write(*,*) value(1:4) read(value(1:LEN_TRIM(value)),*) i write(*,*) i ENDDO end program internalread3 gfortran4.4 (20081120, 64bit): 1.079s i.e. speedup by factor 23 ... but there are cases where the user can't solve the issue like this. And such basic optimizations are more efficiently done by the compiler. Besides this: This is an internal read, so the compiler has full control over the contents of this string variable. It can e.g. null terminate the string or similar, or it can carry on an index of the last character in string (set on assignment), or ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199
[Bug target/38203] New: attribute `noreturn' isn't effective when -mthumb param is active
A small testcase:
#include stdlib.h
extern unsigned int whatever(unsigned char *);
__attribute__((noreturn)) int main(void)
{
whatever(NULL);
for(;;);
}
If you compile this code without -mthumb, gcc asm output is as such:
.file pqp.c
.text
.align 2
.global main
.type main, %function
main:
@ Volatile: function does not return.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
mov r0, #0
bl whatever
.L2:
b .L2
.size main, .-main
.ident GCC: (GNU) 4.3.2
... Or, in other words, it correctly avoids to preserve the link register.
With -mthumb, it pushes lr to the stack, which is the same behaviour as
removing the noreturn attribute.
The thing becomes relevant when main is a complex function that does not
return: it pushes not only lr, but several otherwise clobbered registers to the
stack which it won't pull back in, thus wasting stack space forever. As you can
imagined, in embedded targets every byte counts. when compiling to arm mode
(not thumb), it avoids preserving these since it has nowhere to return them to.
--
Summary: attribute `noreturn' isn't effective when -mthumb param
is active
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alexandre dot nunes at gmail dot com
GCC target triplet: arm-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38203
[Bug c++/15795] No way to teach operator new anything about alignment requirements
--- Comment #41 from hjl dot tools at gmail dot com 2008-11-20 16:44 --- You may want to take a look at PR 36159. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
[Bug target/38201] -mfma/-mavx and -msse5/-msse4a don't work together
--- Comment #1 from dwarak dot rajagopal at amd dot com 2008-11-20 16:48
---
1) -msse5 includes -mfma switch (because fma is a part of sse5 instructions).
So having -msse5 -mfma is same as having just msse5, though you can just
have -fma (without -msse5).
2) -mavx -msse5 = Yes. This would not make sense since no machine can run
this.
- Dwarak
(In reply to comment #0)
Both Intel FMA and AMD SSE5 support FMA. For -mfma, which enables
Intel FMA and is a dummy at the moment, or -msse5, we will
generate FMA instructions for
double f;
void
foo (double x, double y, double z)
{
f = x * y + z;
}
What FMA should -mfma -msse5 generate? Also currently, with
-O2 -mavx -msse5, we generate
foo:
fmaddsd %xmm2, %xmm1, %xmm0, %xmm0
vmovsd %xmm0, f(%rip)
ret
which won't run on any machines. For -mfma -msse5 and
-mavx -msse5,
1. Should these combinations be allowed? If allowed,
2. Should the last option turn off the first one?
(In reply to comment #0)
Both Intel FMA and AMD SSE5 support FMA. For -mfma, which enables
Intel FMA and is a dummy at the moment, or -msse5, we will
generate FMA instructions for
double f;
void
foo (double x, double y, double z)
{
f = x * y + z;
}
What FMA should -mfma -msse5 generate? Also currently, with
-O2 -mavx -msse5, we generate
foo:
fmaddsd %xmm2, %xmm1, %xmm0, %xmm0
vmovsd %xmm0, f(%rip)
ret
which won't run on any machines. For -mfma -msse5 and
-mavx -msse5,
1. Should these combinations be allowed? If allowed,
2. Should the last option turn off the first one?
--
dwarak dot rajagopal at amd dot com changed:
What|Removed |Added
CC||dwarak dot rajagopal at amd
||dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38201
[Bug target/38203] attribute `noreturn' isn't effective when -mthumb param is active
--- Comment #1 from alexandre dot nunes at gmail dot com 2008-11-20 16:52 --- Created an attachment (id=16728) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16728action=view) A more involved testcase. This testcase shows the preserving behaviour on multiple call-clobbered registers, in spite of noreturn attribute. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38203
[Bug target/38201] -mfma/-mavx and -msse5/-msse4a don't work together
--- Comment #2 from hjl dot tools at gmail dot com 2008-11-20 16:57 --- (In reply to comment #1) 1) -msse5 includes -mfma switch (because fma is a part of sse5 instructions). So having -msse5 -mfma is same as having just msse5, though you can just have -fma (without -msse5). Please look closely. I added -mfma to i386.opt: --- mfma Target Report Mask(ISA_FMA) Var(ix86_isa_flags) VarExists Support MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX and FMA built-in functions and code generation --- It has nothing to with SSE5. SSE5 never implies TARGET_FMA. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38201
[Bug middle-end/38204] New: PRE for post dominating expressions
For this function:
int test (int a, int b, int c, int g)
{
int d, e;
if (a)
d = b * c;
else
d = b - c;
e = b * c + g;
return d + e;
}
the multiply expression is moved to both branches of the if, it would be
better to move it before the if. Intel's compiler does that.
--
Summary: PRE for post dominating expressions
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC host triplet: i386-pc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38204
[Bug bootstrap/33100] [4.3/4.4 regression] on bootstrap getting section .eh_frame: bad cie version 0: offset 0x0
--- Comment #32 from ro at gcc dot gnu dot org 2008-11-20 17:11 --- Subject: Bug 33100 Author: ro Date: Thu Nov 20 17:09:53 2008 New Revision: 142049 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142049 Log: gcc: PR bootstrap/33100 * config.gcc (i[34567]86-*-solaris2*): Don't include i386/t-crtstuff here. Move extra_parts, i386/t-sol2 in tmake_file to libgcc/config.host. * config/i386/t-sol2: Move to libgcc/config/i386. libgcc: PR bootstrap/33100 * configure.ac (i?86-*-solaris2.1[0-9]*): Only include i386/t-crtstuff if linker supports ZERO terminator unwind entries. * configure: Regenerate. * config.host (i[34567]86-*-solaris2*): Move i386/t-sol2 in tmake_file here from gcc/config.gcc. Move extra_parts here from gcc/config.gcc. * config/i386/t-sol2: Move here from gcc/config/i386. Use gcc_srcdir instead of srcdir. Added: branches/gcc-4_3-branch/libgcc/config/i386/t-sol2 - copied, changed from r142012, branches/gcc-4_3-branch/gcc/config/i386/t-sol2 Removed: branches/gcc-4_3-branch/gcc/config/i386/t-sol2 Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config.gcc branches/gcc-4_3-branch/libgcc/ChangeLog branches/gcc-4_3-branch/libgcc/config.host branches/gcc-4_3-branch/libgcc/configure branches/gcc-4_3-branch/libgcc/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33100
[Bug bootstrap/33100] [4.3/4.4 regression] on bootstrap getting section .eh_frame: bad cie version 0: offset 0x0
--- Comment #33 from ro at gcc dot gnu dot org 2008-11-20 17:14 --- Subject: Bug 33100 Author: ro Date: Thu Nov 20 17:13:01 2008 New Revision: 142050 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142050 Log: gcc: PR bootstrap/33100 * config.gcc (i[34567]86-*-solaris2*): Don't include i386/t-crtstuff here. Move extra_parts, i386/t-sol2 in tmake_file to libgcc/config.host. * config/i386/t-sol2: Move to libgcc/config/i386. libgcc: PR bootstrap/33100 * configure.ac (i?86-*-solaris2.1[0-9]*): Only include i386/t-crtstuff if linker supports ZERO terminator unwind entries. * configure: Regenerate. * config.host (i[34567]86-*-solaris2*): Move i386/t-sol2 in tmake_file here from gcc/config.gcc. Move extra_parts here from gcc/config.gcc. * config/i386/t-sol2: Move here from gcc/config/i386. Use gcc_srcdir instead of srcdir. Added: trunk/libgcc/config/i386/t-sol2 - copied, changed from r142008, trunk/gcc/config/i386/t-sol2 Removed: trunk/gcc/config/i386/t-sol2 Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc trunk/libgcc/ChangeLog trunk/libgcc/config.host trunk/libgcc/configure trunk/libgcc/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33100
[Bug bootstrap/33100] [4.3/4.4 regression] on bootstrap getting section .eh_frame: bad cie version 0: offset 0x0
--- Comment #34 from ro at techfak dot uni-bielefeld dot de 2008-11-20 17:14 --- Subject: Re: [4.3/4.4 regression] on bootstrap getting section .eh_frame: bad cie version 0: offset 0x0 Fixed for 4.3.3, 4.4.0: http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00990.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33100
[Bug middle-end/37742] [4.4 Regression] ICE in vectorizer with restrict pointer
--- Comment #21 from rguenth at gcc dot gnu dot org 2008-11-20 17:15
---
The problem with our restrict handling seems to be deeper. We fail to set
the based-on-restrict property properly.
abase_n{4}_13 = abase{-2}_12(D) + D.1614_11;
so here abase_n and abase are not properly connected... unfortunately that
seems to be a very deep rooted problem (and obviously our restrict handling
is broken anyway ...)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37742
[Bug middle-end/37742] [4.4 Regression] ICE in vectorizer with restrict pointer
--- Comment #22 from rguenth at gcc dot gnu dot org 2008-11-20 17:22 --- For 4.4 I will collect the fixes and just disable the assertion... we cannot fix this properly without switching to a completely points-to based restrict implementation (lumping restrict together with TBAA info is fundamentally broken anyway). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37742
[Bug bootstrap/33100] [4.3/4.4 regression] on bootstrap getting section .eh_frame: bad cie version 0: offset 0x0
--- Comment #35 from ro at gcc dot gnu dot org 2008-11-20 17:33 --- Fixed for all active release branches. -- ro at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33100
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #66 from hhinnant at apple dot com 2008-11-20 17:40 ---
(In reply to comment #65)
Subject: Re: exception_defines.h #defines try/catch
No, it doesn't make any sense to use try/catch in a program that you're
planning to build with -fno-exceptions. It does, however, make sense to
use try/catch in a general purpose library that you want to work with
exceptions enabled or disabled, such as libstdc++.
I believe Lubos is arguing that such libraries ought to use preprocessor
tricks to accomplish this, but defining something like __try and __catch
instead of try and catch. The difference between this approach and my
patch is that it requires the library writer to jump through hoops to
make their code work with exceptions enabled and disabled. I guess
Lubos thinks this is good, that this is an unusual thing to want to do
and so people that want to do it need to be very explicit about it so
that people who don't want that but mistakenly build their code with
-fno-exceptions get an error rather than a warning.
Anyone else have an opinion about this?
And yes, -Wexceptions is on by default in my patch.
I've tried really hard to just stay out of this one. :-) I think Jason makes a
good argument. However I just surveyed a bunch of my own code written to work
both with and without exceptions enabled, using macro hoops. In about 95% of
the cases transforming:
try
{
X
}
catch (Y)
{
Z
}
to just:
X
is exactly what I want. In the other 5% of the cases it is not. In these
(relatively rare, but not uncommon) cases, the code under X gets transformed
into code that checks return values for error codes and acts on that error
code:
int er = X
if (er)
return P
This scenario usually pops up when X is doing an allocation which throws when
exceptions are enabled and returns null when exceptions are disabled.
All that being said, is Jason's patch good or bad? shrug I'm still going to
have to manually design 100% of my try/catch clauses for exceptions enabled and
disabled. If I don't, then I'll have a 5% bug rate even with Jason's patch.
Part of me would prefer the error just to ensure that I haven't forgotten to
design for the exceptions-disabled case, even if that design would simply
translate to X. Perhaps the warning will fill that role, I do not know.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug fortran/38188] Inconsistent function results depending on irrelevant write statement
--- Comment #3 from dojo at masterleep dot com 2008-11-20 17:55 --- Oops, sorry for missing that. Thank you for the help. I was led astray because for mysterious reasons it always worked before... -- dojo at masterleep dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38188
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #67 from mmitchel at gcc dot gnu dot org 2008-11-20 17:55 --- I think that the current libstdc++ behavior is undesirable, for the reasons that Howard says. In particular, the fact that including a libstdc++ header can result in definitions of try and catch as macros is bad, even though, of course, that happens only in the -fno-exceptions mode. I find comments about exceptions being a standard part of the language unpersuasive; while that is of course true, G++ is certainly used by people who wan the C++ without exceptions language and not supporting that well would put us at a competitive disadvantage relative to other C++ compilers. I think that changing libstdc++ to use __try, __catch, etc. is reasonable. That's certainly the approach used in other libraries. However, I also think Jason's patch is reasonable, provided of course that the documentation is updated to reflect this new behavior. If I recall correctly, unwinding into a frame with no EH data will cause a runtime abort, so programs will not silently skip catch clauses that have been compiled away. The program may fail, but at least it will not do so silently. Jason, is that correct? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #68 from jason at redhat dot com 2008-11-20 18:10 --- Subject: Re: exception_defines.h #defines try/catch mmitchel at gcc dot gnu dot org wrote: If I recall correctly, unwinding into a frame with no EH data will cause a runtime abort, so programs will not silently skip catch clauses that have been compiled away. The program may fail, but at least it will not do so silently. Jason, is that correct? Yes. If the unwinder runs out of unwind info before it finds a handler, we call terminate(). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug middle-end/37790] limits-fnargs.c takes very long time to compile at -O2
--- Comment #5 from sje at cup dot hp dot com 2008-11-20 18:30 --- The limits-fnargs.c tests pass on my IA64 platforms (HP-UX and Linux). It still failed on hppa64-*-hpux* with a timeout but my PA box is quite slow and I have other tests timing out there as well. I am willing to call it fixed unless Dave wants to keep it open for the hppa64 platform. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37790
[Bug c++/37540] [4.4 regression] ICE on __decltype of method call in function template
--- Comment #8 from jason at gcc dot gnu dot org 2008-11-20 18:42 --- Subject: Bug 37540 Author: jason Date: Thu Nov 20 18:40:52 2008 New Revision: 142054 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142054 Log: PR c++/37540 * call.c (build_over_call): Take the address of the function even in a template. (build_new_method_call): Remember the type of the called function in a template. Added: trunk/gcc/testsuite/g++.dg/cpp0x/decltype14.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37540
[Bug c++/37540] [4.4 regression] ICE on __decltype of method call in function template
--- Comment #9 from jason at gcc dot gnu dot org 2008-11-20 18:42 --- 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=37540
[Bug tree-optimization/27810] inefficient gimplification of function calls
--- Comment #4 from dann at godzilla dot ics dot uci dot edu 2008-11-20
18:43 ---
Still happens with 4.4.0:
qqq (int a)
{
int result.0;
int D.1236;
int result;
result.0 = bar (a);
result = result.0;
D.1236 = result;
return D.1236;
}
--
dann at godzilla dot ics dot uci dot edu changed:
What|Removed |Added
Version|unknown |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27810
[Bug c++/38178] [LTO] devirtualization is missing in lto
--- Comment #1 from dnovillo at gcc dot gnu dot org 2008-11-20 18:47 --- Subject: Bug 38178 Author: dnovillo Date: Thu Nov 20 18:45:58 2008 New Revision: 142055 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142055 Log: 2008-11-20 Rafael Espindola [EMAIL PROTECTED] Diego Novillo [EMAIL PROTECTED] PR 38178 * tree.c (reset_type_lang_specific): Set TYPE_BINFO to NULL. cp/ChangeLog.lto PR 38178 * cp-lang.c (LANG_HOOKS_FOLD_OBJ_TYPE_REF): Undefine. testsuite/ChangeLog.lto: PR 38178 * g++.dg/lto/20081119_0.C: New. * g++.dg/lto/20081119_1.C: New. * g++.dg/opt/devirt1.C: Do not scan for the devirtualized call. Added: branches/lto/gcc/testsuite/g++.dg/lto/20081119_0.C branches/lto/gcc/testsuite/g++.dg/lto/20081119_1.C Modified: branches/lto/gcc/ChangeLog.lto branches/lto/gcc/cp/ChangeLog.lto branches/lto/gcc/cp/cp-lang.c branches/lto/gcc/testsuite/ChangeLog.lto branches/lto/gcc/testsuite/g++.dg/opt/devirt1.C branches/lto/gcc/tree.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38178
[Bug target/38201] -mfma/-mavx and -msse5/-msse4a don't work together
--- Comment #3 from hjl dot tools at gmail dot com 2008-11-20 18:52 ---
Since -mfma implies -mavx, we got
[EMAIL PROTECTED] gcc]$ cat f.c
double f;
void
foo (double x, double y, double z)
{
f = x * y + z;
}
[EMAIL PROTECTED] gcc]$ ./xgcc -B./ -O2 -mfma -msse5 f.c -S
-fno-asynchronous-unwind-tables
[EMAIL PROTECTED] gcc]$ cat f.s
.file f.c
.text
.p2align 4,,15
.globl foo
.type foo, @function
foo:
fmaddsd %xmm2, %xmm1, %xmm0, %xmm0
vmovsd %xmm0, f(%rip)
ret
.size foo, .-foo
.comm f,8,8
.ident GCC: (GNU) 4.4.0 20081120 (experimental) [trunk revision
142045]
.section.note.GNU-stack,,@progbits
[EMAIL PROTECTED] gcc]$
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38201
[Bug fortran/38115] unneeded temp
--- Comment #4 from jv244 at cam dot ac dot uk 2008-11-20 18:54 --- (In reply to comment #3) duplicate of pr36935? similar enough to make this one depend on PR36935. I think the testcases here (certainly comment #1), are more difficult. -- jv244 at cam dot ac dot uk changed: What|Removed |Added BugsThisDependsOn||36935 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38115
[Bug middle-end/37790] limits-fnargs.c takes very long time to compile at -O2
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2008-11-20 18:59 --- Subject: Re: limits-fnargs.c takes very long time to compile at -O2 --- Comment #5 from sje at cup dot hp dot com 2008-11-20 18:30 --- The limits-fnargs.c tests pass on my IA64 platforms (HP-UX and Linux). It still failed on hppa64-*-hpux* with a timeout but my PA box is quite slow and I have other tests timing out there as well. I am willing to call it fixed unless Dave wants to keep it open for the hppa64 platform. It's no longer failing on my box, so I guess we can call it fixed. I'm sure things will get faster with checking off. Still have: WARNING: program timed out. FAIL: gcc.dg/20020425-1.c (test for excess errors) Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37790
[Bug middle-end/37790] limits-fnargs.c takes very long time to compile at -O2
--- Comment #7 from sje at cup dot hp dot com 2008-11-20 19:05 --- gcc.dg/20020425-1.c is a separate issue where the 'remove useless statements' pass is very slow. I will add some comments to that bug report soon if I can't come up with a fix. Resolving this report as fixed. -- sje at cup dot hp dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37790
[Bug c++/28513] [4.2/4.3/4.4 Regression] QOI: Diagnostic missing since 3.3.x when naming rule is violated
-- 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-08-06 14:41:06 |2008-11-20 19:34:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28513
[Bug target/38201] -mfma/-mavx and -msse5/-msse4a don't work together
--- Comment #4 from dwarak dot rajagopal at amd dot com 2008-11-20 19:35 --- Yes, you are right. -mfma -msse5 does not make sense. I mistook -mfma for -mfused-madd and hence the confusion. Hence these combinations (1 and 2) does not make sense. Thanks, Dwarak -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38201
[Bug target/38201] -mfma/-mavx and -msse5/-msse4a don't work together
--- Comment #5 from hjl dot tools at gmail dot com 2008-11-20 19:46 --- (In reply to comment #4) Yes, you are right. -mfma -msse5 does not make sense. I mistook -mfma for -mfused-madd and hence the confusion. Hence these combinations (1 and 2) does not make sense. Should we disallow such combinations? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38201
[Bug target/38151] structures with _Complex arguments are not passed correctly
--- Comment #16 from ubizjak at gmail dot com 2008-11-20 19:50 ---
Problems from Comment #10 and Comment #11 are fixed by the patch from Comment
#13, but following test still fails, even with a patched compiler:
--cut here--
void abort (void);
struct S2848
{
unsigned int a;
_Complex int b;
struct
{
} __attribute__ ((aligned)) c;
};
struct S2848 s2848;
int fails;
void __attribute__((noinline))
check2848va (int z, ...)
{
struct S2848 arg;
__builtin_va_list ap;
__builtin_va_start (ap, z);
arg = __builtin_va_arg (ap, struct S2848);
if (s2848.a != arg.a)
++fails;
if (s2848.b != arg.b)
++fails;
__builtin_va_end (ap);
}
int main (void)
{
s2848.a = 4027477739U;
s2848.b = (723419448 + -218144346 * __extension__ 1i);
check2848va (1, s2848);
if (fails)
abort ();
return 0;
}
--cut here--
gcc -O2 t1.c
./a.out
Aborted
gdb ./a.out
[...]
(gdb) watch fails
Hardware watchpoint 1: fails
(gdb) run
Starting program: /home/uros/test/compat/a.out
Hardware watchpoint 1: fails
Old value = 0
New value = 1
0x0040051d in check2848va (z=1) at t1.c:29
29 ++fails;
Missing separate debuginfos, use: debuginfo-install glibc.x86_64
(gdb) p /x arg.b
$2 = 0x004005802b1e8138
(gdb) p /x s2848.b
$3 = 0xf2ff61a62b1e8138
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38151
[Bug target/38201] -mfma/-mavx and -msse5/-msse4a don't work together
--- Comment #6 from dwarak dot rajagopal at amd dot com 2008-11-20 19:49 --- Should we disallow such combinations? Yes. - Dwarak -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38201
[Bug target/29987] libgomp.c++/ctor-9.C failure
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2008-11-20 20:16 --- Anyway, the following patch fixes this in a cross from x86_64-linux to sparc*-sun-solaris10. Can somebody please bootstrap/regtest it? Bootstrapped/regtested with GNU as for the sake of completeness. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29987
[Bug c++/28513] [4.2/4.3/4.4 Regression] QOI: Diagnostic missing since 3.3.x when naming rule is violated
--- Comment #8 from jason at gcc dot gnu dot org 2008-11-20 20:24 --- Subject: Bug 28513 Author: jason Date: Thu Nov 20 20:23:32 2008 New Revision: 142056 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142056 Log: PR c++/28513 * parser.c (cp_parser_class_name): Call maybe_note_name_used_in_class. Added: trunk/gcc/testsuite/g++.dg/lookup/name-clash7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28513
[Bug c++/28513] [4.2/4.3/4.4 Regression] QOI: Diagnostic missing since 3.3.x when naming rule is violated
--- Comment #9 from jason at gcc dot gnu dot org 2008-11-20 20:27 --- Fixed for 4.4. Reopen if you'd like to see it fixed in 4.3 or 4.2. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work|3.2.3 3.3.3 |3.2.3 3.3.3 4.4.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28513
[Bug c++/28743] [4.2/4.3/4.4 regression] ICE with invalid specialization
-- 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-08-06 14:42:23 |2008-11-20 20:31:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28743
[Bug target/38151] structures with _Complex arguments are not passed correctly
--- Comment #17 from uros at gcc dot gnu dot org 2008-11-20 21:12 --- Subject: Bug 38151 Author: uros Date: Thu Nov 20 21:11:22 2008 New Revision: 142059 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142059 Log: PR target/38151 * config/i386/i386.c (classify_argument) [integer mode size = 64bit]: Handle cases when integer argument crosses argument register boundary. testsuite/ChangeLog: PR target/38151 * gcc.target/i386/pr38151-1.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr38151-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38151
[Bug target/38151] structures with _Complex arguments are not passed correctly
--- Comment #18 from ubizjak at gmail dot com 2008-11-20 21:13 --- va_arg problem from Comment #16 remains unfixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38151
[Bug rtl-optimization/36998] [4.3/4.4 regression] Ada bootstrap broken on i586-*-*
--- Comment #30 from jakub at gcc dot gnu dot org 2008-11-20 21:28 --- Subject: Bug 36998 Author: jakub Date: Thu Nov 20 21:26:52 2008 New Revision: 142060 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142060 Log: PR rtl-optimization/36998 * dwarf2out.c (stack_adjust_offset): Add cur_args_size and cur_offset arguments. Handle sp = reg and (set (foo) (mem (pre_inc (reg sp. (compute_barrier_args_size_1, dwarf2out_frame_debug_expr): Adjust stack_adjust_offset callers. (dwarf2out_stack_adjust): Likewise. Handle insns in annulled branches properly. (compute_barrier_args_size): Handle insns in annulled branches properly. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36998
[Bug target/38201] -mfma/-mavx and -msse5/-msse4a don't work together
--- Comment #7 from hjl dot tools at gmail dot com 2008-11-20 21:29 --- We have the same issue with -m3dnow, -m3dnowa and -msse4a. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38201
[Bug middle-end/29215] [4.2/4.3/4.4 Regression] extra store for memcpy
--- Comment #17 from jakub at gcc dot gnu dot org 2008-11-20 21:36 --- Subject: Bug 29215 Author: jakub Date: Thu Nov 20 21:35:03 2008 New Revision: 142061 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142061 Log: PR middle-end/29215 * builtins.c (SLOW_UNALIGNED_ACCESS): Define if not defined. (fold_builtin_memory_op): Handle even the case where just one of src and dest is an address of a var decl component, using TYPE_REF_CAN_ALIAS_ALL pointers. Remove is_gimple_min_invariant and readonly_data_expr src check. * tree-ssa-sccvn.c (DFS): Use clear_and_done_ssa_iter to shut up warnings. * trans-array.c (trans_array_constructor_value, gfc_build_constant_array_constructor): Fill in TREE_PURPOSE. * gfortran.dg/array_memcpy_3.f90: Adjust pattern to match even memcpy optimized into ref-all store. * gcc.dg/pr29215.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr29215.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/array_memcpy_3.f90 trunk/gcc/tree-ssa-sccvn.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29215
[Bug target/38151] structures with _Complex arguments are not passed correctly
--- Comment #19 from ubizjak at gmail dot com 2008-11-20 21:37 --- Hm, rdx gets corrupted: check2848va: .LFB0: .cfi_startproc movq%rsi, %rcx # tmp73, leaq8(%rsp), %rax #, (+) movq%rdx, -40(%rsp) #, shrq$32, %rcx #, cmpl%esi, s2848(%rip) # tmp73, s2848.a movq-80(%rsp), %rdx #, tmp74 movq%rax, -112(%rsp)#, variable.overflow_arg_area leaq-56(%rsp), %rax #, movq%rsi, -48(%rsp) #, movl$8, -120(%rsp) #, variable.gp_offset movq%rsi, -88(%rsp) # tmp70, movq%rax, -104(%rsp)#, variable.reg_save_area movq%rsi, -72(%rsp) # tmp73, arg movq%rdx, -64(%rsp) # tmp74, arg je .L4 #, addl$1, fails(%rip) #, fails .L4: cmpl%ecx, s2848+4(%rip) # arg$b$real, s2848.b setne %cl #, tmp79 (++)cmpl%edx, s2848+8(%rip) # arg$b$imag, s2848.b setne %al #, tmp82 orb %al, %cl# tmp82, tmp79 je .L6 #, addl$1, fails(%rip) #, fails rdx is saved at the point of (+), corrupted at and this corrupted value is used at (++). The insn at just falls in the insn stream from the sky, it is not present if a is changed to unsigned long in S2848 structure. In case when a is changed to unsigned long, testcase works OK. The testcase also works when insn at is removed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38151
[Bug middle-end/29215] [4.2/4.3 Regression] extra store for memcpy
--- Comment #18 from jakub at gcc dot gnu dot org 2008-11-20 21:39 --- Fixed on the trunk. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.0.0 4.0.4 4.1.0 4.2.0 |4.0.0 4.0.4 4.1.0 4.2.0 ||4.3.2 Known to work|3.4.0 |3.4.0 4.4.0 Summary|[4.2/4.3/4.4 Regression]|[4.2/4.3 Regression] extra |extra store for memcpy |store for memcpy http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29215
[Bug rtl-optimization/36998] [4.3/4.4 regression] Ada bootstrap broken on i586-*-*
--- Comment #31 from jakub at gcc dot gnu dot org 2008-11-20 21:51 --- AFAIK there are 2 bugs in DW_CFA_GNU_args_size handling left. One is that with -fdefer-pop DW_CFA_GNU_args_size will be wrong in some cases (either with -fasynchronous-unwind-tables if noreturn calls with different depth are crossjumped (I think #c13 in this PR is an example), or otherwise when relying on call's second argument. The other problem is that alloca with constant argument (possibly discovered during the optimizations) will be thought as normal stack adjustment and thus accounted for in DW_CFA_GNU_args_size computations, which is wrong. See PR37022. If it would be possible with -fdefer-pop to put into CALL's second argument the actual cumulative stack difference instead of just the size of the arguments, I think the first problem could be solved (as long as crossjumping wouldn't merge CALLs with different second argument). For the second I'm afraid we'll need some way to mark the alloca stack adjustment, so that dwarf2out.c DW_CFA_GNU_args_size computation would ignore it. BTW, unless the asserts are reenabled again (they are currently disabled for these reasons), this isn't a regression, I don't think we ever emitted DW_CFA_GNU_args_size correctly in such cases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36998
[Bug fortran/38205] New: Tranformational function SUM rejected in initialization expressions
The following program fails with: Error: transformational intrinsic 'sum' at (1) is not permitted in an initialization expression I think it is valid Fortran 2003 per 7.1.7 Initialization expression: (5) A reference to a transformational standard intrinsic function other than NULL, where each argument is an initialization expression Note: Fortran 95 7.1.7.1 the program is invalid (only few transformational functions are allowed). Found by James Van Buskirk: http://groups.google.com/group/comp.lang.fortran/msg/2119be02dcf93517 integer, parameter :: a = sum([1,2]) print *, a end -- Summary: Tranformational function SUM rejected in initialization expressions Product: gcc Version: 4.4.0 Status: UNCONFIRMED 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=38205
[Bug fortran/38184] invariant RESHAPE not expanded if SOURCE is empty
--- Comment #2 from burnus at gcc dot gnu dot org 2008-11-20 23:00 --- Another test case is the following program (fixed by your patch): http://groups.google.com/group/comp.lang.fortran/msg/2119be02dcf93517 How about packaging your patch and submitting it? -- burnus at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38184
[Bug c++/38206] New: g++ crashes when compiling trivial code (~10 line test case)
The following code causes g++ to crash:
main.cpp:
==
struct foo {
template class T foo(T);
};
struct bar {
bar();
bar(const foo f);
bar(bar);
};
bar makeBar() {
return bar();
}
==
g++ -v main.cpp
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--enable-targets=all --enable-checking=release --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu3)
/usr/lib/gcc/i486-linux-gnu/4.2.4/cc1plus -quiet -v -D_GNU_SOURCE main.cpp
-quiet -dumpbase main.cpp -mtune=generic -auxbase main -version
-fstack-protector -fstack-protector -o /tmp/ccVkFN1G.s
ignoring nonexistent directory /usr/local/include/i486-linux-gnu
ignoring nonexistent directory
/usr/lib/gcc/i486-linux-gnu/4.2.4/../../../../i486-linux-gnu/include
ignoring nonexistent directory /usr/include/i486-linux-gnu
#include ... search starts here:
#include ... search starts here:
/usr/include/c++/4.2
/usr/include/c++/4.2/i486-linux-gnu
/usr/include/c++/4.2/backward
/usr/local/include
/usr/lib/gcc/i486-linux-gnu/4.2.4/include
/usr/include
End of search list.
GNU C++ version 4.2.4 (Ubuntu 4.2.4-1ubuntu3) (i486-linux-gnu)
compiled by GNU C version 4.2.4 (Ubuntu 4.2.4-1ubuntu3).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: cca9b7b48c023363b938f208576b99cc
g++: Internal error: Segmentation fault (program cc1plus)
Please submit a full bug report.
See URL:http://gcc.gnu.org/bugs.html for instructions.
I've also tested g++ 3.3.3, with similar results. Let me know if I can provide
any further information!
--
Summary: g++ crashes when compiling trivial code (~10 line test
case)
Product: gcc
Version: 4.2.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gredner at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38206
[Bug c++/38206] g++ crashes when compiling trivial code (~10 line test case)
--- Comment #1 from gredner at gmail dot com 2008-11-20 23:20 --- Created an attachment (id=16729) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16729action=view) Self-contained test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38206
[Bug tree-optimization/15484] [tree-ssa] bool and short function arguments promoted to int
--- Comment #6 from dann at godzilla dot ics dot uci dot edu 2008-11-20 23:27 --- Still happens in 4.4. -- dann at godzilla dot ics dot uci dot edu changed: What|Removed |Added Keywords||memory-hog http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15484
[Bug tree-optimization/38207] New: Union in structs are not well optimized
Take:
struct a
{
union
{
int a;
int b;
};
union
{
int c;
int d;
};
};
int f(struct a *c)
{
int d = c-a;
c-c = 1;
return c-a + d;
}
--- CUT ---
There should only be one load from c-a but currently there is two
--
Summary: Union in structs are not well optimized
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38207
