[Bug lto/60530] openssh-6.5p1 can't be built with lto - revision 208516
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60530 David Kredba nheghathivhistha at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from David Kredba nheghathivhistha at gmail dot com --- -fpie in LDFLAGS fixed it, thank you! (Going to open a Gentoo report.)
[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678 --- Comment #38 from David Kredba nheghathivhistha at gmail dot com --- Created attachment 32363 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32363action=edit Unreduced test case from calligra
[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678 --- Comment #39 from David Kredba nheghathivhistha at gmail dot com --- Hello Markus, Thank you. Without LTO the reference is different, maybe qHash would be the next one error. MakeFiles/kritametadataeditor.dir/kis_meta_data_editor.cc.o: In function `KisMetaDataEditor::KisMetaDataEditor(QWidget*, KisMetaData::Store*)': /var/tmp/portage/app-office/calligra-2.8.0/work/calligra-2.8.0/krita/plugins/extensions/metadataeditor/kis_meta_data_editor.cc:79: undefined reference to `QUiLoader::QUiLoader(QObject*)' /var/tmp/portage/app-office/calligra-2.8.0/work/calligra-2.8.0/krita/plugins/extensions/metadataeditor/kis_meta_data_editor.cc:82: undefined reference to `QUiLoader::load(QIODevice*, QWidget*)' /var/tmp/portage/app-office/calligra-2.8.0/work/calligra-2.8.0/krita/plugins/extensions/metadataeditor/kis_meta_data_editor.cc:85: undefined reference to `QUiLoader::~QUiLoader()' /var/tmp/portage/app-office/calligra-2.8.0/work/calligra-2.8.0/krita/plugins/extensions/metadataeditor/kis_meta_data_editor.cc:79: undefined reference to `QUiLoader::~QUiLoader()' collect2: error: ld returned 1 exit status krita/plugins/extensions/metadataeditor/CMakeFiles/kritametadataeditor.dir/build.make:229: recipe for target 'lib/kritametadataeditor.so' failed It wanted to link this way: /usr/bin/x86_64-pc-linux-gnu-g++ -fPIC -flto=4 -fuse-linker-plugin -O2 -ggdb -pipe -march=native -mtune=native -mno-3dnow -mno-sse4.2 -mno-avx -fno-lto -fno-use-linker-plugin -Wnon-virtual-dtor -Wno-long-long -Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -Wformat-security -fno-exceptions -DQT_NO_EXCEPTIONS -fno-check-new -fno-common -Woverloaded-virtual -fno-threadsafe-statics -fvisibility=hidden -fvisibility-inlines-hidden -march=core2 -msse2 -msse3 -mssse3 -msse4.1 -mno-sse4.2 -mno-sse4a -mno-avx -mno-xop -mno-fma4 -Wabi -fabi-version=0 -ffp-contract=fast -fexceptions -UQT_NO_EXCEPTIONS -Wl,--enable-new-dtags -Wl,--no-undefined -lc -flto=4 -fuse-linker-plugin -Wl,--as-needed -Wl,-O2 -Wl,-flto -O2 -ggdb -pipe -march=native -mtune=native -mno-3dnow -mno-sse4.2 -mno-avx -fno-lto -fno-use-linker-plugin -shared -Wl,-soname,kritametadataeditor.so -o ../../../../lib/kritametadataeditor.so CMakeFiles/kritametadataeditor.dir/kritametadataeditor_automoc.cpp.o CMakeFiles/kritametadataeditor.dir/metadataeditor.cc.o CMakeFiles/kritametadataeditor.dir/kis_entry_editor.cc.o CMakeFiles/kritametadataeditor.dir/kis_meta_data_editor.cc.o CMakeFiles/kritametadataeditor.dir/kis_meta_data_model.cpp.o -L/var/tmp/portage/app-office/calligra-2.8.0/work/calligra-2.8.0_build/lib -L/usr/lib64/qt4 ../../../../lib/libkritaui.so.13.0.0 /usr/lib64/qt4/libQtUiTools.a ../../../../lib/libkritaimage.so.13.0.0 ../../../../lib/libkomain.so.13.0.0 /usr/lib64/libkactivities.so.6.2.0 -lGLU -lGL -lSM -lICE -lSM -lICE -lX11 -lXext -lXft -lXau -lXdmcp -lXpm /usr/lib64/qt4/libQtOpenGL.so ../../../../lib/libkowidgets.so.13.0.0 ../../../../lib/libkotext.so.13.0.0 ../../../../lib/libflake.so.13.0.0 ../../../../lib/libpigmentcms.so.13.0.0 ../../../../lib/libkoplugin.so.13.0.0 -lImath -lIlmImf -lIex -lHalf -lIlmThread -Wl,-Bstatic -lVc -Wl,-Bdynamic ../../../../lib/libkundo2.so.13.0.0 ../../../../lib/libkowidgetutils.so.13.0.0 ../../../../lib/libkoodf.so.13.0.0 /usr/lib64/libkio.so.5.12.3 /usr/lib64/qt4/libQtXml.so /usr/lib64/qt4/libQtNetwork.so /usr/lib64/libkdeui.so.5.12.3 /usr/lib64/qt4/libQtGui.so /usr/lib64/qt4/libQtSvg.so /usr/lib64/libkdecore.so.5.12.3 /usr/lib64/qt4/libQtDBus.so /usr/lib64/qt4/libQtCore.so -lpthread -Wl,-rpath,/var/tmp/portage/app-office/calligra-2.8.0/work/calligra-2.8.0_build/lib:/usr/lib64/qt4: -Wl,-rpath-link,/var/tmp/portage/app-office/calligra-2.8.0/work/calligra-2.8.0_build/lib
[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678 --- Comment #40 from Markus Trippelsdorf trippels at gcc dot gnu.org --- David, the Calligra link error from comment 36 and comment 31 are caused by ConditionCommand.cpp.o. With -flto it contains: U _ZN8Calligra6Sheets5qHashERKNS0_10ConditionsE Without -flto the undefined symbol is gone. I'm currently reducing this issue.
[Bug ada/39172] libada parsing of multilib options
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39172 --- Comment #11 from Andreas Schwab schwab at gcc dot gnu.org --- Author: schwab Date: Sun Mar 16 08:32:23 2014 New Revision: 208605 URL: http://gcc.gnu.org/viewcvs?rev=208605root=gccview=rev Log: PR ada/39172 * gcc/ada/gcc-interface/Makefile.in (target_cpu_default): Revert 2013-10-11 change. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/Makefile.in
[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678 --- Comment #41 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Created attachment 32364 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32364action=edit reduced calligra testcase markus@x4 tmp % g++ -flto -c -O2 test.ii nm test.o | grep _ZN8Calligra6Sheets5qHashERKNS0_10ConditionsE U _ZN8Calligra6Sheets5qHashERKNS0_10ConditionsE markus@x4 tmp % g++ -c -O2 test.ii nm test.o | grep _ZN8Calligra6Sheets5qHashERKNS0_10ConditionsE markus@x4 tmp % clang++ -flto -c -O2 test.ii nm test.o | grep _ZN8Calligra6Sheets5qHashERKNS0_10ConditionsE markus@x4 tmp %
[Bug ada/60504] [4.9 regression] many Ada testsuite regressions with gcc-4.9-20140309 on armv5tel-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60504 --- Comment #6 from Bernd Edlinger bernd.edlinger at hotmail dot de --- (In reply to Mikael Pettersson from comment #5) I'm going to try a revert of the unwind changes next, as soon as I can identify the corresponding svn revision numbers. that would be r208419 and r208150
[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|--- |FIXED
--- Comment #42 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
This looks like an application issue, when I move:
bool operator(const Conditions conditions) const {
return qHash(*this) qHash(conditions);
}
from sheets/Condition.h to sheets/Condition.cpp (where it belongs)
Calligra compiles just fine with -flto.
[Bug fortran/60542] [4.9 Regression] realloc_on_assign_5.f03 aborts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60542 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Thomas Koenig tkoenig at gcc dot gnu.org --- OK, looks like it is the same bug after all. After I removed MALLOC_CHECK_ and MALLOC_PERTURB_, things worked. I thought it was a different bug because I got an abort, not a segfault. Marking as duplicate. *** This bug has been marked as a duplicate of bug 47674 ***
[Bug fortran/47674] gfortran.dg/realloc_on_assign_5.f03: Segfault at run time for deferred (allocatable) string length
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47674 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #7 from Thomas Koenig tkoenig at gcc dot gnu.org --- *** Bug 60542 has been marked as a duplicate of this bug. ***
[Bug libfortran/46800] Handle CTRL-D correctly with STDIN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46800 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Thomas Koenig tkoenig at gcc dot gnu.org --- This works now. The following test program (with ^D pressed after invoking a.out) yields ig25@linux-fd1f:/tmp cat a.f90 ios = 123456 read (*,*,iostat=ios) a print *,ios,is_iostat_end(ios) end ig25@linux-fd1f:/tmp gfortran a.f90 ig25@linux-fd1f:/tmp ./a.out -1 T Not really possible to check in the test suite. Closing.
[Bug c++/59071] sse2 intrinsics and constant expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59071 Mark Abraham mark.j.abraham at gmail dot com changed: What|Removed |Added CC||mark.j.abraham at gmail dot com --- Comment #2 from Mark Abraham mark.j.abraham at gmail dot com --- The same error message with 4.8.2 is provoked by _mm_srli_si128((x), sizeof(int) * (i)) and is fixed by _mm_srli_si128((x), 4 * (i))
[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678 --- Comment #43 from David Kredba nheghathivhistha at gmail dot com --- Hello Jason, Thank you. Could you please check uploaded not reduced i file related to my comment #39? As per Markus finding qHash issue is Calligra issue. This is not allowing to build Calligra even without LTO. Thank you in advance.
[Bug fortran/60543] New: Random number problems with REAL64 precision at different optimization levels
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60543 Bug ID: 60543 Summary: Random number problems with REAL64 precision at different optimization levels Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: sarantis.pantazis at gmail dot com Created attachment 32365 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32365action=edit code and compiled files The attached code is meant to generate particle velocities with different magnitudes but uniform angle distribution. In this process, I have checked the sign of the three velocity components and have found the following: (1) In DEBUG mode (-O0, please see the included makefile for the exact flags) no problem appears. (2) In OPT1 mode (-O1) the number of positive components in the y- and z- direction seem to be always the same. (3) In OPT1 mode the code gets stuck if I deactivate the WRITE statements of lines 31 and 34 in bugMain.f. No error/warning messages given by the compiler. I have attached a compiled version of (1)-(3) with the -save-temps flag. The output of lsb_release -a: LSB Version: core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch Distributor ID:Ubuntu Description:Ubuntu 13.10 Release:13.10 Codename:saucy The output of gfortran -v: Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.8.1-10ubuntu9' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu9)
[Bug fortran/58880] [4.9 Regression] [OOP] ICE on valid with FINAL function and type extension
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58880 --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org --- Draft patch. Janus: As you have a better idea when vtables are generated: Have you an idea why the finalization wrapper__final_gn_Nde is not produced? And how to fix that? --- a/gcc/fortran/trans-expr.c +++ b/gcc/fortran/trans-expr.c @@ -71,2 +71,5 @@ gfc_conv_scalar_to_descriptor (gfc_se *se, tree scalar, DECL_ARTIFICIAL (desc) = 1; + + if (!POINTER_TYPE_P (TREE_TYPE (scalar))) +scalar = gfc_build_addr_expr (NULL_TREE, scalar); gfc_add_modify (se-pre, gfc_conv_descriptor_dtype (desc), @@ -77,4 +80,3 @@ gfc_conv_scalar_to_descriptor (gfc_se *se, tree scalar, if the actual argument is a pointer and not, e.g., NULL(). */ - if ((attr.pointer || attr.allocatable) -attr.intent != INTENT_IN POINTER_TYPE_P (TREE_TYPE (scalar))) + if ((attr.pointer || attr.allocatable) attr.intent != INTENT_IN) gfc_add_modify (se-post, scalar,
[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678 --- Comment #44 from David Kredba nheghathivhistha at gmail dot com --- Hello Markus, I moved it (deleted a three lines) from .h file and placed them to asource file a) beginning of source file after a namespace definition and it failed with: /usr/include/qt4/QtCore/qmap.h:107:17: error: no match for 'operator' (operand types are 'const Calligra::Sheets::Conditions' and 'const Calligra::Sheets::Conditions') /usr/include/qt4/QtCore/qmap.h:107:17: error: no match for 'operator' (operand types are 'const Calligra::Sheets::Conditions' and 'const Calligra::Sheets::Conditions') b) before the first occurence of qHash and it failed with: /usr/include/qt4/QtCore/qmap.h:107:17: error: no match for 'operator' (operand types are 'const Calligra::Sheets::Conditions' and 'const Calligra::Sheets::Conditions') /usr/include/qt4/QtCore/qmap.h:107:17: error: no match for 'operator' (operand types are 'const Calligra::Sheets::Conditions' and 'const Calligra::Sheets::Conditions') /usr/include/qt4/QtCore/qmap.h:107:17: error: no match for 'operator' (operand types are 'const Calligra::Sheets::Conditions' and 'const Calligra::Sheets::Conditions') Could you please write me to what line to place it? Thank you in advance.
[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678
--- Comment #45 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
(In reply to David Kredba from comment #44)
Hello Markus,
I moved it (deleted a three lines) from .h file and placed them to asource
file
a) beginning of source file after a namespace definition and it failed
with:
/usr/include/qt4/QtCore/qmap.h:107:17: error: no match for 'operator'
(operand types are 'const Calligra::Sheets::Conditions' and 'const
Calligra::Sheets::Conditions')
/usr/include/qt4/QtCore/qmap.h:107:17: error: no match for 'operator'
(operand types are 'const Calligra::Sheets::Conditions' and 'const
Calligra::Sheets::Conditions')
b) before the first occurence of qHash and it failed with:
/usr/include/qt4/QtCore/qmap.h:107:17: error: no match for 'operator'
(operand types are 'const Calligra::Sheets::Conditions' and 'const
Calligra::Sheets::Conditions')
/usr/include/qt4/QtCore/qmap.h:107:17: error: no match for 'operator'
(operand types are 'const Calligra::Sheets::Conditions' and 'const
Calligra::Sheets::Conditions')
/usr/include/qt4/QtCore/qmap.h:107:17: error: no match for 'operator'
(operand types are 'const Calligra::Sheets::Conditions' and 'const
Calligra::Sheets::Conditions')
Could you please write me to what line to place it?
Thank you in advance.
You need to keep the declaration in Condition.h:
bool operator(const Conditions conditions) const;
and append the following to Condition.cpp:
bool Conditions::operator(const Conditions conditions) const
{
return qHash(*this) qHash(conditions);
}
But this is getting way off-topic.
[Bug libgcc/60494] A better strtol
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60494 --- Comment #2 from Olaf van der Spek olafvdspek at gmail dot com --- (In reply to Andrew Pinski from comment #1) strtol is part of glibc and not part of GCC. Ah, thx. OT: What is assert part of? You can code your own strtol2 and not have to be part of a library really. Of course I can, but I'm not a fan of code duplication and writing a (correct) floating point number parser isn't trivial.
[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #46 from Jakub Jelinek jakub at gcc dot gnu.org --- BTW, kdepim that failed to compile (no -flto) compiles just fine with r208586.
[Bug fortran/58880] [4.9 Regression] [OOP] ICE on valid with FINAL function and type extension
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58880 --- Comment #8 from janus at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #7) Draft patch. Does fix the ICE apparently, but then gives: /tmp/cc6WAMPO.o: In function `__gn_MOD_ndm': c0.f90:(.text+0x676): undefined reference to `__final_gn_Nde.2455' Janus: As you have a better idea when vtables are generated: Have you an idea why the finalization wrapper__final_gn_Nde is not produced? Not sure, but I'll try to find out. Btw, the following variant gives a different ICE also with the patch: module gn implicit none type sl integer, allocatable, dimension(:) :: lv contains final :: sld end type contains subroutine sld(s) type(sl) :: s end subroutine end module use gn type :: nde type(sl) :: r end type contains subroutine ndm type(nde) :: s,i i=s end subroutine end
[Bug tree-optimization/60533] [4.8/4.9 regression] Error introduced by cunrolli pass at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60533
Bill Schmidt wschmidt at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #11 from Bill Schmidt wschmidt at gcc dot gnu.org ---
(In reply to pins...@gmail.com from comment #10)
What is the type of bc? That access to bc in bb 46 looks like to be the
cause.
What is the original code look like, do we have an out of bounds access here
or just a miscombining to create one?
Hm, yeah. This is user error. We have
static Direction bc[43][3];
so the complete unrolling 3 times is justified. The loop iterates over the
last bound and terminates only if a flag value Neighborhood3D::Error is found
in the array. So if there's bad data in the array such that this is never
present we will run into the barrier.
The input data appears to be loaded from:
template int DUMMY
Direction NeighborCode3D::StaticDataDUMMY::bc[43][3] = {
{ InFront, North, West},
{ InFront, North, West},
{ InFront, North, West},
{ InFront, North, West},
{ InFront, North, Error},
{ Error, Error, Error},
{ InFront, West, Error},
{ InFront, West, Error},
{ InFront, Error,Error},
{ Error, Error, Error},
{ InFront, North, West},
{ InFront, North, West},
{ InFront, North, Error},
{ Error, Error, Error},
{ Error, Error, Error},
{ Error, Error, Error},
{ Error, Error, Error},
{ Error, Error, Error},
{ North, West, Error},
{ North, West, Error},
{ North, Error, Error},
{ Error, Error, Error},
{ West, Error, Error},
{ West, Error, Error},
{ Error, Error, Error},
{ Error, Error, Error},
{ North, West, Error},
{ North, West, Error},
{ North, Error, Error},
{ Error, Error, Error},
{ Error, Error, Error},
{ Error, Error, Error},
{ Error, Error, Error},
{ Error, Error, Error},
{ Error, Error, Error},
{ Error, Error, Error},
{ InFront, North, West},
{ InFront, North, West},
{ InFront, North, Error},
{ Error, Error, Error},
{ InFront, West, Error},
{ InFront, West, Error},
{ InFront, Error, Error},
{ Error, Error, Error},
{ InFront, North, West},
{ InFront, North, West},
{ InFront, North, Error}
};
Many of the entries don't contain an Error node, leading to the problem.
Thanks, Eric and Andrew, for helping me work through this one. Closing as
invalid.
[Bug tree-optimization/25621] Missed optimization when unrolling the loop (splitting up the sum) (only with -ffast-math)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25621 --- Comment #13 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Joost VandeVondele from comment #12) Both compilers fail to notice that S32 is basically the same code hand-unrolled. with gcc 4.9 ./a.out default loop 0.542918001 hand optimized loop 0.542917009 so, some progress, both versions of the loop give the same performance. Still not quite as good as ifort, however.
[Bug fortran/60543] [4.8/4.9 Regression] Function with side effect removed by the optimizer.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60543 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-16 Summary|Random number problems with |[4.8/4.9 Regression] |REAL64 precision at |Function with side effect |different optimization |removed by the optimizer. |levels | Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed, although this has nothing to do with REAL64 precision nor with random number. The problem comes from the fact that one call to random() is optimized away. On trunk (4.9) the code is optimized as with following changes: @@ -45,7 +45,7 @@ USE globalParameters USE generalFunctions IMPLICIT NONE -REAL(DP):: magnitude +REAL(DP):: magnitude, tmp REAL(DP):: mass REAL(DP):: angle1, angle2 REAL(DP):: upsilon0_local, gasConstant, T @@ -71,11 +71,12 @@ DO i=1,2000 DO magnitude = 5e0_DP*random() !WRITE(*,*) magnitude, EXP(-magnitude**2) -IF ( random() = EXP(-magnitude**2) ) EXIT +tmp = random() +IF ( tmp = EXP(-magnitude**2) ) EXIT END DO !WRITE(*,*) -angle1=random()*twopi +angle1=tmp*twopi angle2=ACOS(2e0_DP*random()-1e0_DP) ; angle2=angle2-pi/2e0_DP upsilon0_local=SQRT(2e0_DP * gasConstant * T) For the moment I don't really understand what is happening with 4.8, i.e., infinite loop. AFAIU the dumps it looks optimized as @@ -69,9 +69,10 @@ T=293.15e0_DP DO i=1,2000 DO -magnitude = 5e0_DP*random() +tmp = random() +magnitude = 5e0_DP*tmp !WRITE(*,*) magnitude, EXP(-magnitude**2) -IF ( random() = EXP(-magnitude**2) ) EXIT +IF ( tmp = EXP(-magnitude**2) ) EXIT END DO !WRITE(*,*) But the executable does not hang when compiled with 4.7.4 or trunk.
[Bug target/60544] New: libcmain.c:39: undefined reference to `WinMain'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60544 Bug ID: 60544 Summary: libcmain.c:39: undefined reference to `WinMain' Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zosrothko at orange dot fr Hi On a cygwin/win7/x86-64 platform, linking a c++ program with g++ -Wl,-trace-symbol=main -o CobolParser.exe ./src/CharStream.o ./src/CobolParser.o ./src/CobolParserTokenManager.o ./src/ParseException.o ./src/Token.o ./src/TokenMgrError.o produces this error /usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../../../lib/crt0.o: reference to main /usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../../../lib/libcygwin.a(libcmain.o): definition of main /usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../../../lib/libcygwin.a(libcmain.o): In function `main': /usr/src/debug/cygwin-1.7.28-2/winsup/cygwin/lib/libcmain.c:39: undefined reference to `WinMain' /usr/src/debug/cygwin-1.7.28-2/winsup/cygwin/lib/libcmain.c:39:(.text.startup+0x7e): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `WinMain' collect2: error: ld returned 1 exit status makefile:45: recipe for target 'CobolParser.exe' failed make: *** [CobolParser.exe] Error 1 In fact, while the CobolParser.o *has* a main entry point, it seems that the linker is looking for the main reference in the libcygwin.a before CobolParser.o which leads to this error. Or did I miss something? here the detail configuration: $ g++ -v -Wl,-trace-symbol=main -o CobolParser.exe ./src/CharStream.o ./src/CobolParser.o ./src/CobolParserTokenManager.o ./src/ParseException.o ./src/Token.o ./src/TokenMgrError.o Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/lto-wrapper.exe Target: x86_64-pc-cygwin Configured with: /cygdrive/i/szsz/tmpp/cygwin64/gcc/gcc-4.8.2-3/src/gcc-4.8.2/configure --srcdir=/cygdrive/i/szsz/tmpp/cygwin64/gcc/gcc-4.8.2-3/src/gcc-4.8.2 --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/libexec --datadir=/usr/share --localstatedir=/var --sysconfdir=/etc --libdir=/usr/lib --datarootdir=/usr/share --docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C --build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin --without-libiconv-prefix --without-libintl-prefix --enable-shared --enable-shared-libgcc --enable-static --enable-version-specific-runtime-libs --enable-bootstrap --disable-__cxa_atexit --with-dwarf2 --with-tune=generic --enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-graphite --enable-threads=posix --enable-libatomic --enable-libgomp --disable-libitm --enable-libquadmath --enable-libquadmath-support --enable-libssp --enable-libada --enable-libgcj-sublibs --disable-java-awt --disable-symvers --with-ecj-jar=/usr/share/java/ecj.jar --with-gnu-ld --with-gnu-as --with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix --without-libintl-prefix --with-system-zlib --libexecdir=/usr/lib Thread model: posix gcc version 4.8.2 (GCC) COMPILER_PATH=/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/:/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/:/usr/lib/gcc/x86_64-pc-cygwin/:/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/:/usr/lib/gcc/x86_64-pc-cygwin/:/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../../../x86_64-pc-cygwin/bin/ LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/:/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../../../x86_64-pc-cygwin/lib/../lib/:/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../../../x86_64-pc-cygwin/lib/:/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-o' 'CobolParser.exe' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-pc-cygwin/4.8.2/collect2.exe -m i386pep --wrap _Znwm --wrap _Znam --wrap _ZdlPv --wrap _ZdaPv --wrap _ZnwmRKSt9nothrow_t --wrap _ZnamRKSt9nothrow_t --wrap _ZdlPvRKSt9nothrow_t --wrap _ZdaPvRKSt9nothrow_t -Bdynamic --dll-search-prefix=cyg --tsaware -o CobolParser.exe /usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../../../lib/crt0.o /usr/lib/gcc/x86_64-pc-cygwin/4.8.2/crtbegin.o -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2 -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../../../x86_64-pc-cygwin/lib/../lib -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../../../x86_64-pc-cygwin/lib -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../.. -trace-symbol=main ./src/CharStream.o ./src/CobolParser.o ./src/CobolParserTokenManager.o ./src/ParseException.o ./src/Token.o ./src/TokenMgrError.o -lstdc++ -lgcc_s -lgcc -lcygwin -ladvapi32 -lshell32 -luser32 -lkernel32 -lgcc_s -lgcc /usr/lib/gcc/x86_64-pc-cygwin/4.8.2/crtend.o /usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../../../lib/crt0.o: reference to main
[Bug fortran/60543] [4.8/4.9 Regression] Function with side effect removed by the optimizer.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60543 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code CC||burnus at gcc dot gnu.org Target Milestone|--- |4.8.3 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org --- Confirmed. The problem is that function random is regarded as (implicit) pure. However, gfortran's subroutine random_number is properly declared as impure. Reduced example: module m contains REAL(8) FUNCTION random() CALL RANDOM_NUMBER(random) END FUNCTION random end module m $ zgrep -i pure m.mod 0 0 FUNCTION IMPLICIT_PURE) () (REAL 8 0 0 0 REAL ()) 0 0 () () 3 () () Draft patch: --- a/gcc/fortran/intrinsic.c +++ b/gcc/fortran/intrinsic.c @@ -4407 +4407 @@ gfc_intrinsic_sub_interface (gfc_code *c, int error_flag) - if (gfc_pure (NULL) !isym-pure) + if (!isym-pure gfc_pure (NULL)) @@ -4413,0 +4414,3 @@ gfc_intrinsic_sub_interface (gfc_code *c, int error_flag) + if (!isym-pure gfc_implicit_pure (NULL)) +gfc_current_ns-proc_name-attr.implicit_pure = 0; +
[Bug target/60544] libcmain.c:39: undefined reference to `WinMain'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60544 zosrothko at orange dot fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from zosrothko at orange dot fr --- Hi This is a mistake from my side, I have 2 compiles unit name CobolParser, one with a main, the other which is generated automatically without... I just discovered this error using nm to dump the symbols defined in CobolParser. Sorry for the noise
[Bug libfortran/46800] Handle CTRL-D correctly with STDIN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46800 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|ASSIGNED Resolution|FIXED |--- Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org --- Comment #3 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Not fixed. With the original test case. If one gives one or more empty keyboard enters in response to the read from stdin, it then takes two Ctrl-D to get a out of the read loop. It should only take a single Ctrl-D
[Bug c++/60498] error: 'snprintf' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60498 Csaba Ráduly csaba_22 at yahoo dot co.uk changed: What|Removed |Added CC||csaba_22 at yahoo dot co.uk --- Comment #11 from Csaba Ráduly csaba_22 at yahoo dot co.uk --- That is not going to work. $ gcc -dumpversion 4.8.2 $ gcc -E -dM -x c /dev/null | egrep -i 'ansi|std' #define _stdcall __attribute__((__stdcall__)) #define __STDC_HOSTED__ 1 #define __stdcall __attribute__((__stdcall__)) #define __STDC__ 1 $ g++ -dumpversion 4.8.2 $ g++ -E -dM -x c++ /dev/null | egrep -i 'ansi|std' #define _stdcall __attribute__((__stdcall__)) #define __STDC_HOSTED__ 1 #define __stdcall __attribute__((__stdcall__)) #define __STDC__ 1
[Bug c++/60498] error: 'snprintf' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60498 --- Comment #12 from Csaba Ráduly csaba_22 at yahoo dot co.uk --- Doh. Disregard me. $ g++ -std=c++11 -E -dM -x c++ /dev/null | egrep -i 'ansi|std|plus' #define __STDC_HOSTED__ 1 #define __STRICT_ANSI__ 1 #define __cplusplus 201103L #define __stdcall __attribute__((__stdcall__)) #define __GNUC_STDC_INLINE__ 1 #define __STDC__ 1
[Bug c++/60516] cc1plus crashes compiling a method with a huge struct as argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60516 Mikael Pettersson mikpelinux at gmail dot com changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #1 from Mikael Pettersson mikpelinux at gmail dot com --- I can reproduce with gcc-4.8.2 crosses targeting x86_64-w64-mingw32 -m32, both on x86_64-linux and on i686-pc-cygwin. On the Linux host the crash looks like: pr60516.cc: In member function 'void Bar::foo(huge)': pr60516.cc:8:5: internal compiler error: Segmentation fault } ^ 0x7d5e8f crash_signal /tmp/gcc-4.8.2/gcc/toplev.c:332 0x78e831 copy_rtx(rtx_def*) /tmp/gcc-4.8.2/gcc/rtl.c:235 0x98963e ix86_expand_epilogue(int) /tmp/gcc-4.8.2/gcc/config/i386/i386.c:11168 0xa1723f gen_epilogue() /tmp/gcc-4.8.2/gcc/config/i386/i386.md:11858 0x674012 thread_prologue_and_epilogue_insns /tmp/gcc-4.8.2/gcc/function.c:6458 0x674012 rest_of_handle_thread_prologue_and_epilogue /tmp/gcc-4.8.2/gcc/function.c:6973 Without -m32 it doesn't crash. gcc-4.7.3 also crashes, but gcc-4.6.1 and 4.5.3 do not.
[Bug c++/59071] sse2 intrinsics and constant expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59071 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- You would need constexpr int n = sizeof(__i128i) - N; to guarantee it is folded into a constant, otherwise there is no guarantee it will be, it is normal expression and it is purely an optimization issue (which you've requested not to be performed through -O0) whether it is evaluated as constant or not.
[Bug c++/60516] [4.9/4.8 regression]: cc1plus crashes compiling a method with a huge struct as argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60516 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug c++/60516] [4.9/4.8 regression]: cc1plus crashes compiling a method with a huge struct as argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60516 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-16 CC||ktietz at gcc dot gnu.org Summary|cc1plus crashes compiling a |[4.9/4.8 regression]: |method with a huge struct |cc1plus crashes compiling a |as argument |method with a huge struct ||as argument Ever confirmed|0 |1 --- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org --- Confirmed.
[Bug target/53513] SH Target: Add support for fschg and fpchg insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-03-16
Ever confirmed|0 |1
--- Comment #4 from Oleg Endo olegendo at gcc dot gnu.org ---
As mentioned in PR 60138, this issue also prevents a working implementation of
fenv.h friends on SH.
The idea would be to get rid of the __fpscr_values first and set the FPSCR.PR
bit with insn sequences such like..
set pr = 1:
sts fpscr,r2
mov.l #(1 19),r1
or r1,r2
lds r2,fpscr
set pr = 0:
sts fpscr,r2
mov.l #~(1 19),r1
and r1,r2
lds r2,fpscr
This would obviously result in a performance regression but would work with all
SH FPUs.
On SH4A this can then be improved by adding support for fpchg. Although this
would require changes/extensions to the mode switching machinery, as mentioned
in PR 29349. The problem is that the mode switching pass emits only mode
changes to a particular mode, not from mode 'x' to mode 'y'. In PR 29349 an
extension of the pre_edge_lcm function is suggested which would make the
necessary information available.
Here are a few more 'requirements' for SH specific mode change issues:
1)
The following function:
double test (const float* a, const float* b, const double* c, float x)
{
float aa = a[0] * b[0];
double cc = c[0] + c[1];
aa += b[1] * b[2];
cc += c[2] + c[3];
aa += b[3] * b[4];
cc += c[4] + c[5];
aa += b[5] * b[6];
return aa / cc;
}
compiled with -m4 -O2 (default PR mode = double) results in 4 mode switches.
Rewriting it as:
double test (const float* a, const float* b, const double* c, float x)
{
float aa = a[0] * b[0] + b[1] * b[2] + b[3] * b[4] + b[5] * b[6];
double cc = c[0] + c[1];
cc += c[2] + c[3];
cc += c[4] + c[5];
return aa / cc;
}
results only in 2 mode switches (as expected). FP operations which are
independent should be reordered in order to minimize mode switches.
This could go as far as ...
2)
... doing loop distribution, for cases such as:
double test (const float* x, const double* y, unsigned int c)
{
float r0 = 0;
double r1 = 0;
while (c--)
{
float xx = x[0] * x[1] + x[2] + 123.0f;
x += 3;
double yy = y[0] + y[1];
y += 2;
r0 += xx;
r1 += yy;
}
return r0 + r1;
}
which currently produces a loop with 4 mode switches in it. Reordering the FP
operations would bring this down to 2 mode switches in the loop. Since r0 and
r1 are calculated independently, 2 loops can be used, having the mode switches
outside the loops.
3)
FPSCR.SZ mode changes might interfere with FPSCR.PR mode changes. For example,
using fschg to flip FPSCR.SZ might require changing FPSCR.PR first (and
potentially changing it back). If fpchg is not available (SH4A only), it's
better to set both bits directly. In order to minimize mode switches it might
be necessary to reorder instructions and doing loop distribution while looking
at PR and SZ bits simultaneously.
4)
rounding mode settings also mean FPSCR mode changes.
http://gcc.gnu.org/ml/gcc-patches/2014-02/msg01378.html
5)
in some cases preserving FPSCR bits across mode changes is not required (if I'm
not mistaken):
double func (float a, float b, double c, double d)
{
#pragma STDC FENV_ACCESS ON
// function entry, PR = double
// mode switch PR = single
float ab = a + b;
// mode switch PR = double
double x = ab + c + d;
// read back FP status bits and do something with it
return x;
// function exit, PR = double
}
In this case the mode switch double - float - double can be done more
efficiently by pushing the PR = double FPSCR state onto the stack, switch to PR
= single and then switch back to PR = double by popping FPSCR from the stack.
However, this must not happen if other FPSCR settings are changed after the
first switch to PR = single, such as invoking a fenv modifying standard
function or changing the FPSCR.FR bit on SH4.
[Bug c++/59571] [C++11] ICE when casting inside static member constexpr brace initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59571 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-03-16 Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Mine,
[Bug c++/60516] [4.9/4.8 regression]: cc1plus crashes compiling a method with a huge struct as argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60516 --- Comment #3 from Kai Tietz ktietz at gcc dot gnu.org --- Issue is that copy_rtx gets feed with invalid insn. As (gdb) fr 1 #1 0x007ce0bf in ix86_expand_epilogue (style=style@entry=1) at ../../gcc/gcc/config/i386/i386.c:11712 11712 copy_rtx (XVECEXP (PATTERN (insn), 0, 1))); (gdb) call debug_rtx(insn) (insn 15 14 0 (set (reg:SI 2 cx) (mem:SI (post_inc:SI (reg/f:SI 7 sp)) [0 S4 A8])) -1 (nil)) (gdb) print (insn-u.fld[4]).rt_rtx $2 = (rtx) 0xffe25630 (gdb) call debug_rtx((insn-u.fld[4]).rt_rtx) (set (reg:SI 2 cx) (mem:SI (post_inc:SI (reg/f:SI 7 sp)) [0 S4 A8])) (gdb) print ((insn-u.fld[4]).rt_rtx-u.fld[0]).rt_rtvec-elem[1] $3 = (rtx_def *) 0x2
[Bug c++/60516] [4.9/4.8 regression]: cc1plus crashes compiling a method with a huge struct as argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60516 --- Comment #4 from Mikael Pettersson mikpelinux at gmail dot com --- Started with r171890.
[Bug target/53513] SH Target: Add support for fschg and fpchg insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513
--- Comment #5 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #4)
5)
in some cases preserving FPSCR bits across mode changes is not required (if
I'm not mistaken):
double func (float a, float b, double c, double d)
{
#pragma STDC FENV_ACCESS ON
// function entry, PR = double
// mode switch PR = single
float ab = a + b;
// mode switch PR = double
double x = ab + c + d;
// read back FP status bits and do something with it
return x;
// function exit, PR = double
}
In this case the mode switch double - float - double can be done more
efficiently by pushing the PR = double FPSCR state onto the stack, switch to
PR = single and then switch back to PR = double by popping FPSCR from the
stack.
However, this must not happen if other FPSCR settings are changed after the
first switch to PR = single, such as invoking a fenv modifying standard
function or changing the FPSCR.FR bit on SH4.
If it's OK for a temporary mode switch to clobber other FPSCR bits (such as in
the PR = single mode above), it should also be OK to load the FPSCR value from
a thread local variable inside the thread-control-block:
mov.l @(disp, gbr),r0 // r0 = address to fpscr value for a
// particular mode setting
lds.l @r0+,fpscr // mode switch
This would require that any FPSCR setting change is also propagated to the TLS
variables. E.g. setting the rounding mode would have to update FPSCR mode
values in all such TLS variables.
I guess that it would be useful to be able to select an FPSCR value for at
least all combinations of FR and SZ bit settings, in other words having a TLS
__fpscr_values array with 4 entries. However, it would make things such as
toggling FPSCR.FR via frchg inefficient due to the required updates of the TLS
variables. Other setting changes such as denorm or rounding mode are probably
not so critical.
[Bug target/53513] SH Target: Add support for fschg and fpchg insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513 --- Comment #6 from Rich Felker bugdal at aerifal dot cx --- On Sun, Mar 16, 2014 at 11:32:21PM +, olegendo at gcc dot gnu.org wrote: If it's OK for a temporary mode switch to clobber other FPSCR bits (such as in the PR = single mode above), it should also be OK to load the FPSCR value from a thread local variable inside the thread-control-block: mov.l @(disp, gbr),r0 // r0 = address to fpscr value for a // particular mode setting lds.l @r0+,fpscr // mode switch IMO this is an ugly hack that shouldn't be taken. It has lots of complex interactions with other things: signal handlers, the ucontext.h functions, fenv, pthread, etc. that could probably be achieved correctly if somebody wanted to spend the effort on it, but it would be ugly and SH-specific and honestly we already have a shortage of people willing to spend time fixing SH problems without introducing even more work. This would require that any FPSCR setting change is also propagated to the TLS variables. E.g. setting the rounding mode would have to update FPSCR mode values in all such TLS variables. I guess that it would be useful to be able to select an FPSCR value for at least all combinations of FR and SZ bit settings, in other words having a TLS __fpscr_values array with 4 entries. However, it would make things such as toggling FPSCR.FR via frchg inefficient due to the required updates of the TLS variables. Other setting changes such as denorm or rounding mode are probably not so critical. If I'm not mistaken, the toggle approach will be efficient without this TLS hack once it's implemented, right? I don't think it makes sense to introduce a hack for just a short-term mitigation of the performance regression. If you think the short-term fix for this issue is too costly, the proper solution is probably to add a -m option to turn it back off (using the old __fpscr_values approach).
[Bug fortran/44489] Transfer with boz constant can confuse - add documentation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44489 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #7 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- No need to do anything here.
[Bug c/60545] New: Please support the 64-bit Windows/EFI calling convention on x86-64 Linux/ELF
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60545 Bug ID: 60545 Summary: Please support the 64-bit Windows/EFI calling convention on x86-64 Linux/ELF Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: josh at joshtriplett dot org For code interoperating with Windows-compatible assembly routines, or for system code calling into EFI firmware, it would help if GCC natively understood the Windows four-register no-red-zone reserve-16-bytes calling convention on non-Windows x86-64 platforms, such as Linux or generic ELF. bug 16332 requested the same thing, and a comment there suggested that the necessary support went into GCC 4.3, but I haven't seen any signs of it in 4.3 or any other GCC version.
[Bug target/60545] Please support the 64-bit Windows/EFI calling convention on x86-64 Linux/ELF
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60545 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- The attribute is ms_abi. It is documented in 4.4.0 and above. From GCC 4.5.0 docuemtnation: http://gcc.gnu.org/onlinedocs/gcc-4.45.0/gcc/Function-Attributes.html#Function-Attributes ms_abi/sysv_abi On 64-bit x86_64-*-* targets, you can use an ABI attribute to indicate which calling convention should be used for a function. The ms_abi attribute tells the compiler to use the Microsoft ABI, while the sysv_abi attribute tells the compiler to use the ABI used on GNU/Linux and other systems. The default is to use the Microsoft ABI when targeting Windows. On all other systems, the default is the AMD ABI. Note, the ms_abi attribute for Windows targets currently requires the -maccumulate-outgoing-args option.
[Bug sanitizer/60536] Backtrace corrupted on Firefox build with -fsanitize=address and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60536 --- Comment #2 from Kostya Serebryany kcc at gcc dot gnu.org --- Please symbolize the output. Also, does this happen with the clang version of AddressSanitizer?
[Bug middle-end/60546] New: [4.8 and 4.9] O2 asan enable generates wrong insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60546 Bug ID: 60546 Summary: [4.8 and 4.9] O2 asan enable generates wrong insns Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: manjian2006 at gmail dot com Created attachment 32366 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32366action=edit source that causes bug My attachment gives a testcase to this bug. To compile,modify the first argument of 1.sh to the path of your GCC (= 4.8.1). Then run 1.sh to compile. As you can see the differences between line #1 and #2 is just -O2 or -Os. And ./1 reports an error,but ./2 don't. So I am sure currently asan with -O2 will generates wrong insn in middle end.I have not located where goes wrong, please help.
