[Bug fortran/36592] F2003: Procedure pointer in COMMON
--- Comment #4 from janus at gcc dot gnu dot org 2008-09-29 09:40 --- Updated patch: http://gcc.gnu.org/ml/fortran/2008-09/msg00447.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36592
[Bug fortran/37445] Host-associated proc not found if same-name generic is use-associated
--- Comment #12 from burnus at gcc dot gnu dot org 2008-09-29 10:25 --- Somehow the patch is not enough to compile program (see tar.gz / attachment 16266): gfortran -c syskindsM.f90 formatbankM.f90 charutilM.f90 tinyisetM.f90 timestampmodM.f90 errelmntM.f90 errstackM.f90 debugmodM.f90 parlistM.f90 winkindsM.f90 ewinhandM.f90 guiclrsM.f90 iso_varying_stringM.f90 windataM.f90 sysdepM.f90 winnowsM.f90 asciichrM.f90 winidenM.f90 BBModI.f90 hardmodM.f90 WinModI.f90 errormodM.f90 errormodM.f90:1083.32: Error: Type mismatch in argument 'arrayindex' at (1); passed TYPE(terrorelement) to INTEGER(4) errormodM.f90:668.114: Error: SUBROUTINE 'getbasicdata' at (1) cannot call itself, as it is not RECURSIVE The files compile without problems with NAG f95, ifort and g95. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37445
[Bug c++/37671] can't use iostream library
--- Comment #2 from paolo dot carlini at oracle dot com 2008-09-29 10:44 --- Indeed. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37671
[Bug c++/37673] New: Programs fail to execute with a runtime error when locale is set
Programs fail to execute with a runtime error when locale is set.
The following codes fail both for english and greek (haven't checked with other
locales) with the run-time error:
terminate called after throwing an instance of 'std::runtime_error'
what(): locale::facet::_S_create_c_locale name not valid
Aborted.
The codes that fail:
1.
#include iostream
#include locale
#include string
int main()
{
using namespace std;
locale::global(locale(en_US));
wcin.imbue(locale(greek));
wcout.imbue(locale(greek));
wstring ws;
wcin ws;
wcout ws endl;
}
2.
#include iostream
#include locale
#include string
int main()
{
using namespace std;
ios_base::sync_with_stdio(false);
wcin.imbue(locale(greek));
wcout.imbue(locale(greek));
wstring ws;
wcin ws;
wcout ws endl;
}
3.
#include iostream
#include locale
#include string
int main()
{
using namespace std;
wcin.imbue(locale(greek));
wcout.imbue(locale(greek));
wstring ws;
wcin ws;
wcout ws endl;
}
It fails for files too:
4.
#include locale
#include string
#include fstream
int main()
{
using namespace std;
wstring ws= LTest;
wofstream file(filename.txt);
file.imbue(locale(greek));
if(file.is_open())
file ws;
}
The bug is serious, I can't save unicode texts in my programs!
--
Summary: Programs fail to execute with a runtime error when
locale is set
Product: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ivranos at freemail dot gr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37673
[Bug c++/37673] Programs fail to execute with a runtime error when locale is set
--- Comment #1 from ivranos at freemail dot gr 2008-09-29 11:37 --- Created an attachment (id=16424) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16424action=view) The produced .ii file from code (2.) The produced .ii file from code (2.) compiled with the options: g++ -ansi -pedantic-errors -Wall -save-temps temp.cpp -o temp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37673
[Bug c++/37673] Programs fail to execute with a runtime error when locale is set
--- Comment #2 from paolo dot carlini at oracle dot com 2008-09-29 11:46 --- Target? Named locales are supported *only* on GNU/Linux systems. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37673
[Bug libstdc++/32254] std::runtime_error thrown by locale()
--- Comment #6 from paolo dot carlini at oracle dot com 2008-09-29 12:48 --- *** Bug 37673 has been marked as a duplicate of this bug. *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||ivranos at freemail dot gr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32254
[Bug libstdc++/37673] Programs fail to execute with a runtime error when locale is set
--- Comment #3 from paolo dot carlini at oracle dot com 2008-09-29 12:48 --- *** This bug has been marked as a duplicate of 32254 *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED Component|c++ |libstdc++ Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37673
[Bug middle-end/37674] New: Bootstrap failure due to miscompilation of genattrtab
With the patch for PR37535 applied to mainline GCC the bootstrap still fails due to a miscompilation. The problem is that r52 is assigned to r6 what collides with an INSN loading r6 with a parameter for a CALL. I think the problem is created in ira_flattening. Allocno a3 is a parent of a87. For a87 the conflict with r6 is properly recorded. Afterwards ira_flatting merges a87 into a3 without propagating the conflict_hard_regs set. So the conflict with r6 is lost and ira_reassign_pseudos later on assigns r52 to hard reg r6. There is already code in ira_flattening which propagates the conflict sets. But the code is only enabled if propagate_p is true. This in turn seems only to get set if the loop once merged allocnos with different regnos?! I unfortunately don't understand this enough to come up with a patch. So I better leave that to you :) Please contact me if you need more information. I wasn't able to reduce the testcase (genattrtab) since it is quite difficult to see from the code if the miscompile occurred or not. ;; a3(r52,l0) conflicts: a1(r87,l0) .. ;; total conflict hard regs: 0-6 14 ;; conflict hard regs: 0-5 14 ;; a87(r52,l2) conflicts: a86(r48,l2) . ;; total conflict hard regs: 0-6 14 ;; conflict hard regs: 0-6 14 ... Moving ranges of a87r52 to a3r52: [245..248] [234..243] [229..232] [218..227] [173..189] [126..169] ... Try assign 52(a3), cost=268: reassign to 6 -- Summary: Bootstrap failure due to miscompilation of genattrtab Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: krebbel at gcc dot gnu dot org GCC build triplet: s390x-ibm-linux GCC host triplet: s390x-ibm-linux GCC target triplet: s390x-ibm-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37674
[Bug middle-end/37372] [graphite] SCoP detection splits bbs / Define SCoPs with single entry and exit edge
--- Comment #7 from grosser at gcc dot gnu dot org 2008-09-29 13:14 --- Committed SVN 140746. -- grosser at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37372
[Bug middle-end/37485] [graphite] Disconnecting exit edge in process of code generation
--- Comment #8 from grosser at gcc dot gnu dot org 2008-09-29 13:21 --- Commit 140746 should have fixed Bug 3. Can you confirm this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37485
[Bug middle-end/37669] [4.4 Regression] ice for legal code with -O2
--- Comment #4 from jakub at gcc dot gnu dot org 2008-09-29 13:23 --- Can't reproduce with current SVN, neither the reduced nor original testcase, on x86_64, i?86, ppc and ppc64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37669
[Bug libstdc++/37673] Programs fail to execute with a runtime error when locale is set
--- Comment #4 from ivranos at freemail dot gr 2008-09-29 13:27 ---
(In reply to comment #2)
Target? Named locales are supported *only* on GNU/Linux systems.
Ubuntu 8.04 x86.
I am learning the QT package, and for example its QString provides a
toStdString() function that returns a std::string and a toStdWString() function
that returns a std::wstring.
The specific member function I have the problem:
void MainWindow::saveFile()
{
using namespace std;
QString fileName= QFileDialog::getSaveFileName(this, tr(Save file),
tr(), tr(Text files (*.txt)));
if(!fileName.isEmpty())
{
string cFileName= fileName.toStdString();
wofstream cFile(cFileName.c_str());
if(cFile.is_open())
{
QString text= textEdit-toPlainText();
wstring writtenText= text.toStdWString();
cFile writtenText;
}
else
QMessageBox::critical(this, Unable to save file!, The file could
not be created!, QMessageBox::Close);
}
}
My system *is* GNU/Linux. Apart from that, why named locales are supported
only on GNU/Linux systems?
MINGW doesn't accept them for example?
In any case, my problem is in a GNU/Linux system.
--
ivranos at freemail dot gr changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
GCC target triplet||Ubuntu 8.04 x86
Resolution|DUPLICATE |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37673
[Bug tree-optimization/37664] [4.4 Regression] ice in remove_range_assertions, at tree-vrp.c:5116
--- Comment #3 from jakub at gcc dot gnu dot org 2008-09-29 13:28 --- The testcase is invalid, signed integer overflow is undefined behavior. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Keywords|ice-on-valid-code |ice-on-invalid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37664
[Bug libstdc++/32254] std::runtime_error thrown by locale()
--- Comment #7 from paolo dot carlini at oracle dot com 2008-09-29 13:37 --- *** Bug 37673 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32254
[Bug libstdc++/37673] Programs fail to execute with a runtime error when locale is set
--- Comment #5 from paolo dot carlini at oracle dot com 2008-09-29 13:37 --- Given the problem you are reporting, the issue is definitely that either the GNU locale model has not been selected at build time, or the localedata is not available, please refer to 32254, for example, or many similar PRs of this type. Otherwise, the type of snippet which you are reporting about is daily tested multiple times by all the developers, many variants in the testsuite. As regards the generic locale model, we would not be able to guarantee multithread safety, but improvements are in principle welcome, just send over patches. Thanks. *** This bug has been marked as a duplicate of 32254 *** *** This bug has been marked as a duplicate of 32254 *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED GCC build triplet|gcc version 4.2.3 (Ubuntu | |4.2.3-2ubuntu7) | GCC host triplet|Ubuntu 8.04 x86 | Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37673
[Bug fortran/37644] compiler Segmentation fault
--- Comment #2 from rlnaff at usgs dot gov 2008-09-29 13:54 --- Subject: Re: compiler Segmentation fault This was an experiment on the combined usage of Open MP and MPI, and may not be feasible. However, that the compiler would simply fail... R. Naff pinskia at gcc dot gnu dot org wrote: --- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-28 19:57 --- We need the source to figure out what is going wrong here. module common_parameters implicit none ! OMPI? include '/usr/include/mpif.h' ! include 'mpif.h' ! ... kv: precision of variables used in assembly integer, parameter :: kv=selected_real_kind(p=10) ! ... common numbers real(kind=kv), parameter :: n0=0.0_kv, n1=1.0_kv, n2=2.0_kv, n3=3.0_kv, n4=4.0_kv, n5=5.0_kv, n6=6.0_kv, n7=7.0_kv, n8=8.0_kv, n9=9.0_kv, n10=10.0_kv, n100=100.0_kv ! ... common fractions real(kind=kv), parameter :: f2=0.5_kv, f3=n1/n3, f4=0.25_kv, f5=0.2_kv, f6=n1/n6, f7=n1/n7, f8=0.125_kv, f9=n1/n9, f10=0.1_kv ! ... machine smallest number real(kind=kv), parameter :: machine_epsilon=epsilon(n0) real(kind=kv), parameter :: small=n100*machine_epsilon real(kind=kv), save :: MZ=tiny(n0) ! ... interim print character(len=32) :: file_name integer :: interim_print, data_print end module common_parameters ! ... File shared_common_parent.f90 ! ... ! ... Version last modified: R.L. Naff, 07/06 ! ... Purpose: Allow for the transfer of information between modules ! ... and subroutines of parent type. ! ... ! ... Utilization: use module name ! ... ! ... Modules herein: ! ... common_input_types_parent ! ... common_partition_types_parent ! ... common_MPI_types_parent ! ... module common_input_types_parent use common_parameters implicit none integer :: n_x, n_y, n_z end module common_input_types_parent module common_partition_types_parent use common_parameters implicit none integer, save :: max_part, npx, npy, npz integer, save :: ind_rot_rn, dim, no_rows integer, save :: tot_variables integer, save :: no_partitions, red_count, max_C integer, save :: red_part_count, red_node_count, black_node_count integer, save :: max_nodes_A, max_nx, max_ny, max_nz ! ... arrays integer, dimension(:), allocatable :: perm_p, inv_perm_p integer, dimension(:), allocatable :: part_end integer, dimension(:), allocatable :: perm end module common_partition_types_parent module common_reorder_types_parent use common_parameters implicit none integer, dimension(:), allocatable, target :: ii_1, ii_2, ii_3 real(kind=kv), dimension(:), allocatable, target :: C1, C2, C3, CC_1, CC_2, CC_3, coef end module common_reorder_types_parent module common_MPI_types_parent integer :: pc_intracomm, pc_intra_root end module common_MPI_types_parent module reorder_parent ! ... Version last modified: R.L. Naff, 02/07 ! ... Purpose: reorder stiffness coefficients into partitions and ! ... send coefficients to children (slaves). ! ... ! ... Subroutines herein: ! ... subroutine AC_reorder ! ... Called from subroutine MS_PCG_solve, module MS_PCG_parent ! ... Sends or BCasts to Child: coef, C1, C2, C3, ! ... CC_1, CC_2, CC_3 (surrogates for hcoef, C_x, C_y, C_z ! ... and part_con arrays). ! ... ! ... use omp_lib use common_parameters use common_input_types_parent ! ... n_x, n_y, n_z use common_partition_types_parent use common_reorder_types_parent use common_MPI_types_parent !tmp use utilities_parent !tmp use error_handler ! ... pointer arrays holding incoming coefficients real, save, pointer, dimension(:) :: Cii, Cjj, Ckk, hcoef ! ... Arrays pointed in MS_PCG_solve ! ... contains subroutine AC_reorder(i_bound, ib0_count) ! ... Based on domain partitioning, rearrange coefficients and ! ... assign to a process. ! ... ! ... Argument list ! ... integer, intent(out) :: ib0_count integer, dimension(:), intent(in) :: i_bound ! ... ! ... local variables ! ... integer :: p, i, j, k, ii, jj, kk, i_org, xyz_loc integer :: i_1, i_2, i_3, np1, np2, np3 integer :: d_1s, d_2s, d_3s, i_range=range(n1) integer :: n_1, n_2, n_3, d_1, d_2, d_3 integer :: node, row_ct, level_ct, A_nodes integer :: pn_count, ls1, ls2, ls3, e_1, e_2, e_3 integer :: ierr, error, tag_out, a_size integer :: i11, i22, i33, int_real_type integer, dimension(1:3) :: C_count integer, pointer, dimension(:) :: I_point real(kind=kv) :: C11, C22, C33, t_num real :: one=1.0, neg_one=-1.0 real(kind=kv), pointer, dimension(:) :: R_point character(len=64) :: err_loc_message ! ! ... allocate work space error=0; t_num=n10**(-i_range/2) nullify (R_point) ! ... call rot_rn(1, n_x, n_x*n_y, e_1, e_2, e_3) ! ... call rot_rn(n_x, n_y, n_z, n_1, n_2, n_3) call
[Bug libstdc++/37673] Programs fail to execute with a runtime error when locale is set
--- Comment #6 from ivranos at freemail dot gr 2008-09-29 13:55 --- The bug reports you are mentioning combined with 35353 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35353), means that the locales implementation of GCC is a mess. I think the proper solution is to fix the locale problem, not trying to ignore it. -- ivranos at freemail dot gr changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37673
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #13 from nickc at redhat dot com 2008-09-29 14:13 --- Created an attachment (id=16425) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16425action=view) Revised patch with correct section switching -- nickc at redhat dot com changed: What|Removed |Added Attachment #16303|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #14 from nickc at redhat dot com 2008-09-29 14:16 --- Hi Guys, I am not able to reproduce the build problems that were reported with the first version of my patch, but then again I do not have a native cygwin build system or a system in which I can bootstrap mingw32. I think that Brian may well be right however in that the patch is behaving badly when it manually switches into the .bss section. I have uploaded a revised version of the patch which uses the correct gcc function to perform the section switch, so please can anyone who is interested give this new patch a run. Cheers Nick -- nickc at redhat dot com changed: What|Removed |Added CC||nickc at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug libstdc++/37673] Programs fail to execute with a runtime error when locale is set
--- Comment #7 from paolo dot carlini at oracle dot com 2008-09-29 14:17 --- Thanks for your nice, encouraging words. We don't need duplicate reports, thanks. *** This bug has been marked as a duplicate of 32254 *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37673
[Bug libstdc++/32254] std::runtime_error thrown by locale()
--- Comment #8 from paolo dot carlini at oracle dot com 2008-09-29 14:17 --- *** Bug 37673 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32254
[Bug c/37648] Incorrect warning flag ignored with precision in printf
--- Comment #2 from ciobi at inbox dot com 2008-09-29 14:30 --- Sorry. The reason I said that the '0' flag was not actually ignored was that I was sure that without it the padding would be done with spaces rather than '0'. I guess some time ago I was using a compiler where the only way to get 0-padding was with %0.4d ; %.4d produced space-padding and I'm not sure what %04d did, but I'm pretty sure that it wasn't what I wanted. So that's how I remembered that it must be done. When reporting the bug I just assumed that %.4d would use space padding, and I figured that the fact that I was getting 0-padding from %0.4d was due to the use of 0, which now I see that is not true. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37648
[Bug libstdc++/30085] switch debug mode hash containers from ext to tr1
--- Comment #9 from paolo dot carlini at oracle dot com 2008-09-29 14:36 --- Benjamin, are you actively taking care of this issue? Otherwise, I can have a look, really we should have the unordered containers working fine in debug-mode too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30085
[Bug c++/37671] can't use iostream library
--- Comment #3 from hadmanysons at gmail dot com 2008-09-29 14:36 --- That worked all right. Am i just stupid or was there some change to the gcc package I was unaware of, because gcc used to compile c++ code just fine (at least in the older version of Fedora and as old as RedHat 6.2), that i was aware of. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37671
Re: [Bug middle-end/37372] [graphite] SCoP detection splits bbs / Define SCoPs with single entry and exit edge
--- Comment #7 from grosser at gcc dot gnu dot org 2008-09-29 13:14 --- Committed SVN 140746. I see that in http://gcc.gnu.org/viewcvs?view=revrevision=140746 you forgot to include in the changelog a line like this: PR tree-optimization/37372 that would have automatically included the commit message in the bugzilla bug.
[Bug middle-end/37372] [graphite] SCoP detection splits bbs / Define SCoPs with single entry and exit edge
--- Comment #8 from sebpop at gmail dot com 2008-09-29 14:46 --- Subject: Re: [graphite] SCoP detection splits bbs / Define SCoPs with single entry and exit edge --- Comment #7 from grosser at gcc dot gnu dot org 2008-09-29 13:14 --- Committed SVN 140746. I see that in http://gcc.gnu.org/viewcvs?view=revrevision=140746 you forgot to include in the changelog a line like this: PR tree-optimization/37372 that would have automatically included the commit message in the bugzilla bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37372
[Bug middle-end/37485] [graphite] Disconnecting exit edge in process of code generation
--- Comment #9 from spop at gcc dot gnu dot org 2008-09-29 14:50 --- Subject: Re: [graphite] Disconnecting exit edge in process of code generation Commit 140746 should have fixed Bug 3. Can you confirm this? This is a side effect of your patch. This bug is not yet fixed, and the patch is not yet committed, as it triggered another bug in IVOPTS, and then another bug in VRP. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37485
[Bug rtl-optimization/37451] Extra addition for doloop in some cases
--- Comment #5 from schwab at suse dot de 2008-09-29 14:52 --- This is causing miscompilation of the stage2 ada compiler. fatal error: system.ads is incorrectly formatted unrecognized or incorrect restrictions pragma: No_Implicit_Dynamic_Code compilation abandoned make[3]: *** [ada/ada.o] Error 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37451
[Bug tree-optimization/37675] New: gcc.dg/torture/pr36891.c doesn't work on Linux/ia32
On Linux/ia32, I got FAIL: gcc.dg/torture/pr36891.c -O0 (test for excess errors) FAIL: gcc.dg/torture/pr36891.c -O1 (test for excess errors) FAIL: gcc.dg/torture/pr36891.c -O2 (test for excess errors) FAIL: gcc.dg/torture/pr36891.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.dg/torture/pr36891.c -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gcc.dg/torture/pr36891.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gcc.dg/torture/pr36891.c -O3 -g (test for excess errors) FAIL: gcc.dg/torture/pr36891.c -Os (test for excess errors) -- Summary: gcc.dg/torture/pr36891.c doesn't work on Linux/ia32 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-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=37675
[Bug bootstrap/37426] [4.4 regression] IRA merge breaks Tru64 UNIX bootstrap
--- Comment #2 from ro at gcc dot gnu dot org 2008-09-29 15:14 --- Both patches have been checked in, so closing as fixed. (We're back at PR bootstrap/36851 now, though.) -- ro at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37426
[Bug middle-end/19988] [4.2/4.3/4.4 Regression] pessimizes fp multiply-add/subtract combo
-- dje at gcc dot gnu dot org changed: What|Removed |Added CC||bergner at gcc dot gnu dot ||org Severity|minor |major Priority|P4 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19988
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #15 from sherpya at netfarm dot it 2008-09-29 15:39 --- I also got the error on the first patch, gcc 4.4 from svn, binutils 2.18.91.20080917 I still have problems with 2.19 binutils snapshots (unable to correctly create and link dll) unfortunately the current gcc svn does not compile for mingw because of: build/i686-pc-mingw32/libstdc++-v3/include/bits/basic_string.h:2689: error: no matching function for call to '__to_xstring(int (*)(wchar_t*, const wchar_t*, char*), const int, const wchar_t [4], long double)' I may need to fill another bug There is no such code applicable to 4.2 branch :( Please take a look at the attached patch, I've picked it from a mailing list, it makes possible align with local variables (static) I don't known if your patches makes it unneeded -- sherpya at netfarm dot it changed: What|Removed |Added CC||sherpya at netfarm dot it http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #16 from sherpya at netfarm dot it 2008-09-29 15:40 --- Created an attachment (id=16426) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16426action=view) lcomm + alignment -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #17 from sherpya at netfarm dot it 2008-09-29 16:30 ---
with both patches I can achieve align 16
align 16 on globals still fails
Local Aligned 16: 0
Local Aligned 32: 0
Global Aligned 16: 0
Global Aligned 32: 16
the program is:
#include stdio.h
#include stdlib.h
#include inttypes.h
static int local_16[8] __attribute__ ((aligned (16)));
static int local_32[8] __attribute__ ((aligned (32)));
int global_16[8] __attribute__ ((aligned (16)));
int global_32[8] __attribute__ ((aligned (32)));
int main(void)
{
printf(Local Aligned 16: %d\n, (intptr_t) local_16 % 16);
printf(Local Aligned 32: %d\n, (intptr_t) local_32 % 32);
printf(Global Aligned 16: %d\n, (intptr_t) global_16 % 16);
printf(Global Aligned 32: %d\n, (intptr_t) global_32 % 32);
return 0;
}
did I miss something?
(perhaps 16 byte alignment it's enough for sse)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug libstdc++/30085] switch debug mode hash containers from ext to tr1
--- Comment #10 from bkoz at redhat dot com 2008-09-29 17:17 --- Sorry P, I have not paid attention to this. I am not likely to work on it this week, so if you want to work on it feel free. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30085
[Bug libstdc++/30085] switch debug mode hash containers from ext to tr1
--- Comment #11 from paolo dot carlini at oracle dot com 2008-09-29 17:24 --- Ok, no problem, thanks for your quick feedback. I'll see what I can do... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30085
[Bug c++/37631] non-volatile asm passes volatile asm (-O3)
--- Comment #2 from pardo at google dot com 2008-09-29 17:48 --- How can I prevent relative motion? I tried adding a memory constraint to all asms, but they are still moved past each other. I expected any common constraint would keep them from crossing. (Adding volatile to all asms does prevent relative motion but inhibits other optimizations so is undesirable.) -- pardo at google dot com changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37631
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #18 from brian at dessent dot net 2008-09-29 17:58 --- Subject: Re: [cygming] Invalid alignment for SSE store to .comm data generated with -O3 The __to_xstring error is PR37522. You should still be able to bootstrap with --enable-languages=c for the purposes of testing this patch, though. Your testcase that uses printf with addr % 16 might not be showing you what you think it is because the compiler is smart enough to optimize away that computation at compile time since it knows the variable was declared with the given alignment, even though the actual address assigned by the linker mightn't be aligned properly. In my testing I had to use volatile to prevent that compile-time optimization. I also forgot to mention that I don't have sse2 capable hardware so I have no way of testing any of this other than by hand inspection. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug libstdc++/30085] switch debug mode hash containers from ext to tr1
-- paolo dot carlini at oracle dot com changed: What|Removed |Added CC|paolo at gcc dot gnu dot org| AssignedTo|bkoz at gcc dot gnu dot org |paolo dot carlini at oracle ||dot com Status|REOPENED|ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30085
[Bug java/37676] New: Ability to bootstrap a fully working gcj without needing to download a separate binary ecj
As it stands one cannot build a working gcj unless one first gets ecj.jar which is prebuilt with some other javac. It would be great if there was a way to build a fully working gcj with ecj without needing this extra step. -- Summary: Ability to bootstrap a fully working gcj without needing to download a separate binary ecj Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ruskie-gcc at codemages dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37676
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #19 from dannysmith at users dot sourceforge dot net 2008-09-29 18:43 --- Created an attachment (id=16427) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16427action=view) Nick's aligned common testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug inline-asm/37195] different variables get the same overlapping memory address in inline assembly
--- Comment #5 from jdemeyer at cage dot ugent dot be 2008-09-29 19:22 --- Created an attachment (id=16428) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16428action=view) Unified testcase This testcase exhibits the problem on i386, x86_64, powerpc and powerpc64 using preprocessor macros. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37195
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #20 from sherpya at netfarm dot it 2008-09-29 19:33 ---
align testcase looks ok, but anyway I'm mainly interested to have code aligned
to 16. volatile around variables is not enough in my test program.
Nick's testcase is ok even on (local-only align) patched gcc 4.2
I've solved to_xstring problem by using vsnwprintf instead, but current trunk
produces buggy ffmpeg executable so many tests are crashing
aligned data looks ok, at least the variables that were unaligned when it was
crashing
I'm still not so sure about the optimization and the alignment, this code:
#include stdio.h
#include stdlib.h
#include inttypes.h
static volatile int local_16[8] __attribute__ ((aligned (16)));
static volatile int local_32[8] __attribute__ ((aligned (32)));
int volatile global_16[8] __attribute__ ((aligned (16)));
int volatile global_32[8] __attribute__ ((aligned (32)));
int main(void)
{
volatile double diff16, diff32;
printf(Local Aligned 16: %d\n, (intptr_t) local_16 % 16);
printf(Local Aligned 32: %d\n, (intptr_t) local_32 % 32);
printf(Global Aligned 16: %d\n, (intptr_t) global_16 % 16);
printf(Global Aligned 32: %d\n, (intptr_t) global_32 % 32);
diff16 = (intptr_t) global_16 / 16.0f;
diff32 = (intptr_t) global_32 / 32.0f;
printf(16 - %f - 32 - %f\n, diff16, diff32);
return 0;
}
still outputs:
Local Aligned 16: 0
Local Aligned 32: 0
Global Aligned 16: 0
Global Aligned 32: 16
16 - 263177.00 - 32 - 131587.50
regardless of the optimizations options
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #21 from brian at dessent dot net 2008-09-29 20:06 ---
Subject: Re: [cygming] Invalid alignment for SSE store to
.comm data generated with -O3
This is an example of what I'm talking about: the bar() function is
optimized away to simply return 0 because the compiler assumes the
alignment is correct without having to actually emit the code to check
it:
$ echo 'char foo[1] __attribute__((aligned(16))); int bar() {
if((int)foo % 16) return 1; else return 0; }' | i686-pc-mingw32-gcc -x c
- -S -o - -fomit-frame-pointer
.file
.text
.globl _bar
.def_bar; .scl2; .type 32; .endef
_bar:
movl$0, %eax
ret
.comm _foo, 16 # 1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug fortran/35680] [4.3/4.4 regression] ICE on invalid transfer in variable declaration
--- Comment #9 from dominiq at lps dot ens dot fr 2008-09-29 20:25 --- Although I am not familiar with the gfortran code, gfc_array_size (mold, tmp)I think the reason why gfortran.dg/transfer_array_intrinsic_4.f90 fails with the patch in comment #6, is because gfc_array_size (mold, tmp) looks at the size of mold, while the relevant part of the TRANSFER definition is: If SIZE is absent but MOLD is an array (of any size or shape), the result is a one-dimensional array of the minimum length needed to contain the entirety of the bitwise representation of SOURCE. So I think tmp should contain (number_of_bytes_in_SOURCE+size_in_bytes_of_a_MOLD_element-1)/size_in_bytes_of_a_MOLD_element. Note that it would be interesting to test the code for [1_1], [1_2], [1_8], and -fdefault-integer-8 to rule out side effects. BTW I think the code in comment #0 is valid for both statement order: if 'real x' is before TRANSFER, it value is not defined, but not necessary to get the size; if 'real x' is after TRANSFER, x is implicitely defined as real and I think it is legal to confirm it by the 'real x' statement. At least the following code real :: y=epsilon(x) real :: x print *, y end is accepted by gfortran, ifort, and g95. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35680
[Bug middle-end/37669] [4.4 Regression] ice for legal code with -O2
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-09-29 21:10 --- Hmm, maybe this was one of the miscompiling that is happening with IRA ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37669
[Bug middle-end/37669] [4.4 Regression] ice for legal code with -O2
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-09-29 21:12 --- It fails with GNU C (GCC) version 4.4.0 20080926 (experimental) [trunk revision 140710] (i386-apple-darwin8.11.1) But not with a stage1 compiler so ... I am going to add this testcase so we don't get the wrong code regression again. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||ra, wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37669
[Bug tree-optimization/37664] [4.4 Regression] ice in remove_range_assertions, at tree-vrp.c:5116
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-09-29 21:14 --- (In reply to comment #3) The testcase is invalid, signed integer overflow is undefined behavior. The code is semantically valid but just runtime undefined ... -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords|ice-on-invalid-code |ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37664
[Bug middle-end/37669] [4.4 Regression] ice for legal code with -O2
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-09-29 21:24 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED GCC target triplet||i?86-*-* x86_64-*-* Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37669
[Bug middle-end/37669] [4.4 Regression] ice for legal code with -O2
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-09-29 21:25 --- Subject: Bug 37669 Author: pinskia Date: Mon Sep 29 21:23:52 2008 New Revision: 140765 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140765 Log: 2008-09-29 Andrew Pinski [EMAIL PROTECTED] PR middle-end/37669 * gcc.c-torture/compile/pr37669.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr37669.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37669
[Bug middle-end/37154] static inline function problem
--- Comment #6 from sparky at pld-linux dot org 2008-09-29 21:36 --- I was trying to isolate the code which triggers this bug, but seems like the code must be very complex to do so. Nevertheless I found exactly how the resulting assembler code is broken. Note: files gsignal.s and gsignal.s-non-inline are switched. In file .s file with inlining, at line 15045 there's the conditional jump corresponding to `if (!accumulator)' from original code, but the actual comparison of the value and zero is nowhere near to be found. 15041 mr 7,31 15042 bl [EMAIL PROTECTED] 15043 .LBB1531: 15044 .LBB1532: 15045 .loc 1 2282 0 15046 beq- 3,.L1255 --- missing: cmpwi 3,9,0 15047 .LVL1697: 15048 .LBE1532: 15049 .loc 1 2285 0 15050 lwz 9,116(1) It looks like gcc thinks the comparison at line 14364 is enough. The code does not do anything with cr3 along the path, but several external functions are called, which AFAIR are allowed to change the value of cr3. 14360 .loc 1 2333 0 14361 lwz 9,28(22) 14362 .LVL1636: 14363 .loc 1 2334 0 14364 cmpwi 3,9,0 14365 .loc 1 2333 0 14366 stw 9,116(1) 14367 .LVL1637: 14368 .loc 1 2334 0 14369 beq- 3,.L1414 I was playing with newer glib2, so I'm not really sure about this file, but in my case adding appropriate cmpwi 3,reg,0 instruction was enough to fix the code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37154
[Bug fortran/37445] Host-associated proc not found if same-name generic is use-associated
--- Comment #13 from burnus at gcc dot gnu dot org 2008-09-29 21:39 --- Somehow the patch is not enough to compile program Actually the situation is worse -- the failure occurs now much earlier: w/ patch: Failure in errormodM.f90 (43th compiled file) w/o patch: Failure in cmndtypeM.f90 (80th compiled file) Thus I withdraw the OK for the patch http://gcc.gnu.org/ml/fortran/2008-09/msg00407.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37445
[Bug middle-end/37154] static inline function problem
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-09-29 21:40 --- IIRC cr3 is a volatile conditional register. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37154
[Bug middle-end/37154] static inline function problem
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-09-29 21:44 --- CR3 is a caller save register just like R31. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37154
[Bug middle-end/37154] static inline function problem
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-09-29 21:45 --- So maybe someone is violating the PPC ABI. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37154
[Bug fortran/37445] Host-associated proc not found if same-name generic is use-associated
--- Comment #14 from burnus at gcc dot gnu dot org 2008-09-29 22:06 --- Created an attachment (id=16429) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16429action=view) Reduced test case which is failing with the patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37445
[Bug tree-optimization/37574] [4.4 Regression] ICE with the vectorizer and GC
--- Comment #5 from jakub at gcc dot gnu dot org 2008-09-29 22:46 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37574
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #22 from sherpya at netfarm dot it 2008-09-29 23:17 ---
still no success while compiling ffmpeg :(
Program received signal SIGSEGV, Segmentation fault.
0x0074fe94 in ff_fft_calc_3dn ()
(gdb) bt
#0 0x0074fe94 in ff_fft_calc_3dn ()
#1 0x007506f5 in ff_fft_calc_3dn ()
#2 0x00750755 in ff_fft_calc_3dn ()
#3 0x00750a55 in ff_fft_dispatch_sse ()
#4 0x0400 in ?? ()
#5 0x0074f718 in ff_fft_calc_sse (s=0x5b14600, z=0x5b0c5f0) at
libavcodec/i386/fft_sse.c:35
#6 0x00748080 in ff_mdct_calc (s=0x5b145f0, out=0x5b0c5f0, input=0x5b105f0) at
libavcodec/dsputil.h:673
#7 0x0064731d in encode_superframe (avctx=0x5ac4010, buf=0x5ba0030 ,
buf_size=524288, data=0x5b5cca0) at libavcodec/wmaenc.c:92
#8 0x00495b16 in avcodec_encode_audio (avctx=0x5ac4010, buf=0x5ba0030 ,
buf_size=524288, samples=0x750a50) at libavcodec/utils.c:865
#9 0x00406236 in output_packet (ist=0x5ac4390, ist_index=0,
ost_table=0x3fbfb0, nb_ostreams=1, pkt=0x22fed8) at ffmpeg.c:672
#10 0x004095d1 in av_encode (output_files=0xb6c000, nb_output_files=1,
input_files=0xb6b280, nb_input_files=1, stream_maps=0xb6c060, nb_stream_maps=0)
at ffmpeg.c:2129
#11 0x00409878 in main (argc=Cannot access memory at address 0xa
) at ffmpeg.c:3897
(gdb) p ff_cos_16
$1 = {1, 0.923879504, 0.707106769, 0.382683426, 6.12303177e-017, 0.382683426,
0.707106769, 0.923879504}
(gdb) p ff_cos_16
$2 = (FFTSample (*)[8]) 0xe55c94
asm code:
.lcomm _ff_cos_16,32,16
lcomm?
nm output:
$ nm ffmpeg_g.exe |grep ff_cos_16
00e55c94 B _ff_cos_16
00e185d4 B _ff_cos_16384
not aligned :(
gcc version 4.3.3 20080929 (prerelease) (Sherpya)
GNU assembler version 2.18.91 (i686-pc-mingw32) using BFD version (GNUBinutils)
2.18.91.20080917
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #23 from sherpya at netfarm dot it 2008-09-29 23:22 --- a printf in the code for ff_cos_16 causes the compiler to align the var, but at this point it crashes in another place using sse code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug c++/37677] New: GCC produces mangled names which can't be demangled
The following code produces a bad mangled name (or at least a mangled name that
c++filt cannot handle):
template typename F class C { public: C(); };
class D
{
public:
template typename F
operator CF() { return CF(); }
};
Cbool foo(D* p) { return *p; }
The final line produces the symbol ZN1Dcv1CIT_EIbEEv. c++filt cannot demangle
it.
Below is
--
Summary: GCC produces mangled names which can't be demangled
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: meheff at gcc dot gnu dot org
GCC build triplet: i686-unknown-linux
GCC host triplet: i686-unknown-linux
GCC target triplet: i686-unknown-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37677
[Bug c++/37677] GCC produces mangled names which can't be demangled
--- Comment #1 from meheff at gcc dot gnu dot org 2008-09-30 00:10 ---
(In reply to comment #0)
The following code produces a bad mangled name (or at least a mangled name
that
c++filt cannot handle):
template typename F class C { public: C(); };
class D
{
public:
template typename F
operator CF() { return CF(); }
};
Cbool foo(D* p) { return *p; }
The final line produces the symbol ZN1Dcv1CIT_EIbEEv. c++filt cannot demangle
it.
Below is
Grrr... sent too soon. Below is a side channel email from [EMAIL PROTECTED]
about the problem:
This produces the symbol _ZN1Dcv1CIT_EIbEEv which is not demangled.
Building the demangler code with -DSTANDALONE_DEMANGLER
-DCP_DEMANGLE_DEBUG gives me this:
./foo _ZN1Dcv1CIT_EIbEEv
typed name
template
qualified name
name 'D'
cast
template
name 'C'
template argument list
template parameter 0
template argument list
builtin type bool
function type
Failed: _ZN1Dcv1CIT_EIbEEv
This works out to something like
(D::operator Cbool)bool()
It's weird because there seems to be an extra templatization in
there. The symbol is really
D::operator Cbool()
which has one template. So why does the mangled name have two?
Clearly the T_ is expected to map to b. If I do that mapping
myself (_ZN1Dcv1CIbEIbEEv) it demangles to
D::operator Cboolbool()
which is weird.
I'm inclined to think that the correct mangling for this should be
_ZN1Dcv1CIbEEv, which demangles to simply
D::operator Cbool()
I don't understand the extra level of template wrapping.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37677
[Bug c++/37677] GCC produces mangled names which can't be demangled
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-30 00:16 --- Why isD::operator Cboolbool() weird? The operator is still a template so is the type CT. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37677
[Bug middle-end/37535] [4.4 Regression] gcc/libgcc2.c:404: internal compiler error: Floating point exception
--- Comment #15 from hjl at gcc dot gnu dot org 2008-09-30 00:38 --- Subject: Bug 37535 Author: hjl Date: Tue Sep 30 00:36:48 2008 New Revision: 140775 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140775 Log: 2008-09-29 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. Process inputs again if necessary. * doc/rtl.texi (clobber): Change how RA deals with clobbers. Modified: branches/ira-merge/gcc/ChangeLog.ira branches/ira-merge/gcc/doc/rtl.texi branches/ira-merge/gcc/ira-lives.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37535
[Bug middle-end/37678] New: Failure to generate post-increment addressing
This is an ia64 performance and code size regression. Consider the following
function:
void sump(int *a, int *b, int *c, int len){
int i;
for(i = 0; i len; i++){
*a++ = *b++ + *c++;
}
}
GCC 3.4.6 generated the following code. Note that the memory accesses use the
post-increment addressing mode.
sump:
.prologue
.mii
nop 0
.save ar.lc, r2
mov r2 = ar.lc
.body
sxt4 r14 = r35
.mfb
cmp4.ge p6, p7 = 0, r35
nop 0
(p6) br.cond.dpnt .L16
;;
.mmi
adds r14 = -1, r14
;;
nop 0
mov ar.lc = r14
.L17:
.mmb
ld4 r14 = [r33], 4
ld4 r15 = [r34], 4
nop 0
;;
.mii
nop 0
add r14 = r14, r15
;;
nop 0
.mfb
st4 [r32] = r14, 4
nop 0
br.cloop.sptk.few .L17
;;
.L16:
.mib
nop 0
mov ar.lc = r2
br.ret.sptk.many b0
Mainline (revision 140763) generated the following code. Instead of using
post-increment addressing, the original pointers are kept in r34, r33, and r32,
while an offset, held in r14, is incremented by four each iteration. The
offset is added to each of the three bases each iteration. This pattern of
code is ideal for machines that have a base-plus-index addressing mode and not
a post-increment addressing mode, such as x86. However, ia64 has a
post-increment addressing mode and not a base-plus-index addressing mode.
sump:
.prologue
.body
.mmi
adds r18 = -1, r35
nop 0
mov r14 = r0
.mmb
cmp4.ge p6, p7 = 0, r35
nop 0
(p6) br.ret.dpnt.many rp
;;
.mmi
nop 0
addp4 r18 = r18, r0
nop 0
;;
.mii
adds r18 = 1, r18
nop 0
;;
shladd r18 = r18, 2, r0
.L10:
.mmi
add r17 = r34, r14
add r16 = r33, r14
add r15 = r32, r14
.mmi
adds r14 = 4, r14
;;
ld4 r17 = [r17]
nop 0
.mii
ld4 r16 = [r16]
cmp.ne p6, p7 = r18, r14
;;
add r16 = r17, r16
;;
.mib
st4 [r15] = r16
nop 0
(p6) br.cond.dptk .L10
.mib
nop 0
nop 0
br.ret.sptk.many rp
Here is the intermediate representation just before the ivopts pass (just after
the cunroll pass). Let's call this IR1. Note that the three pointers are
incremented each iteration. This pattern, were it preserved, would later be
transformed into post-increment addressing by the auto-inc-dec pass.
;; Function sump (sump)
sump (int * a, int * b, int * c, int len)
{
int i;
int D.1279;
int D.1278;
int D.1277;
bb 2:
if (len_9(D) 0)
goto bb 3;
else
goto bb 6;
bb 3:
bb 4:
# i_25 = PHI i_16(5), 0(3)
# a_26 = PHI a_13(5), a_6(D)(3)
# b_27 = PHI b_14(5), b_7(D)(3)
# c_28 = PHI c_15(5), c_8(D)(3)
D.1277_10 = *b_27;
D.1278_11 = *c_28;
D.1279_12 = D.1278_11 + D.1277_10;
*a_26 = D.1279_12;
a_13 = a_26 + 4;
b_14 = b_27 + 4;
c_15 = c_28 + 4;
i_16 = i_25 + 1;
if (len_9(D) i_16)
goto bb 5;
else
goto bb 6;
bb 5:
goto bb 4;
bb 6:
return;
}
Here is the intermediate representation after the ivopts pass. Let's call this
IR2. The code has been transformed into the pattern we see in the final
assembly.
;; Function sump (sump)
sump (int * a, int * b, int * c, int len)
{
unsigned int D.1361;
unsigned int D.1362;
long unsigned int D.1363;
long unsigned int D.1364;
long unsigned int D.1365;
int * D.1366;
int * D.1360;
long unsigned int D.1359;
int * D.1358;
long unsigned int D.1357;
int * D.1356;
long unsigned int D.1355;
int * ivtmp?59;
int i;
int D.1279;
int D.1278;
int D.1277;
bb 2:
if (len_9(D) 0)
goto bb 3;
else
goto bb 6;
bb 3:
bb 4:
# ivtmp?59_1 = PHI ivtmp?59_24(5), 0B(3)
D.1355_20 = (long unsigned int) ivtmp?59_1;
D.1356_22 = b_7(D) + D.1355_20;
D.1277_10 = MEM[base: D.1356_22];
D.1357_23 = (long unsigned int) ivtmp?59_1;
D.1358_21 = c_8(D) + D.1357_23;
D.1278_11 = MEM[base: D.1358_21];
D.1279_12 = D.1278_11 + D.1277_10;
D.1359_30 = (long unsigned int) ivtmp?59_1;
D.1360_31 = a_6(D) + D.1359_30;
MEM[base: D.1360_31] = D.1279_12;
ivtmp?59_24 = ivtmp?59_1 + 4;
D.1361_32 = (unsigned int) len_9(D);
D.1362_33 = D.1361_32 + 4294967295;
D.1363_34 = (long unsigned int) D.1362_33;
D.1364_35 = D.1363_34 + 1;
D.1365_36 = D.1364_35 * 4;
D.1366_37 = (int *) D.1365_36;
if (ivtmp?59_24 != D.1366_37)
goto bb 5;
else
goto bb 6;
bb 5:
goto bb 4;
bb 6:
return;
}
Here is the RTL representation (with extraneous information removed) going into
the auto-inc-dec pass (coming out of the regclass pass). auto-inc-dec does not
recognize that this code can be transformed to use post-increment addressing.
The only thing auto-inc-dec
[Bug middle-end/37669] [4.4 Regression] ice for legal code with -O2
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-09-30 01:41 --- Actually my reduced testcase still fails for me on the trunk as of Mon Sep 29 21:29:02 UTC 2008 (revision 140765) Stage1's gcc is still fine. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37669
[Bug tree-optimization/37664] [4.4 Regression] ice in remove_range_assertions, at tree-vrp.c:5116
--- Comment #5 from regehr at cs dot utah dot edu 2008-09-30 03:04 --- (In reply to comment #3) The testcase is invalid, signed integer overflow is undefined behavior. It still crashes when -fwrapv or -ftrapv is added to the command line. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37664
[Bug c++/37679] New: -fstrict-aliasing causes omission of double-to-float conversion
The program which will be attached demonstrates a case where, when the -fstrict-aliasing optimization is turned on, the result of the final one of 6 double-to-float conversions does not get written to memory as it should. According to valgrind (memory debugging tool), the target memory gets left uninitialized. The expected output and actual output are described in the program's comments. I don't think I have done any illegal pointer aliasing in this program, and the -Wstrict-aliasing=2 option doesn't warn of any such errors. The problem occurs in g++ 4.1.2. It does not occur in older versions I tried (4.0.2, 3.3.5) nor at lower optimization levels. The compiler version info, as shown by g++ -v, is: Using built-in specs. Target: x86_64-suse-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --libdir=/usr/lib64 --libexecdir=/usr/lib64 --with-gxx-include-dir=/usr/include/c++/4.1.2 --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --without-system-libunwind --enable-spp --disable-libssp --enable-version-specific-runtime-libs --host=x86_64-suse-linux Thread model: posix gcc version 4.1.2 -- Summary: -fstrict-aliasing causes omission of double-to-float conversion Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dhatch at ilm dot com GCC build triplet: x86_64-suse-linux GCC host triplet: x86_64-suse-linux GCC target triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37679
[Bug c++/37679] -fstrict-aliasing causes omission of double-to-float conversion
--- Comment #1 from dhatch at ilm dot com 2008-09-30 03:15 --- Created an attachment (id=16430) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16430action=view) BUG.cpp: test program to reproduce bug 37679 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37679
[Bug c++/37679] -fstrict-aliasing causes omission of double-to-float conversion
--- Comment #2 from brian at dessent dot net 2008-09-30 04:41 --- Subject: Re: -fstrict-aliasing causes omission of double-to-float conversion I can confirm that the failure with 4.1.2, however 4.2.4, 4.3.1, and 4.4 all work fine. 4.1 with -fno-tree-salias also works. Unfortunately this means there's not much that can be done about this as the 4.1 branch is closed and no longer maintained. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37679
