[Bug c++/114878] New: GCC fails with an error on armv7: use of built-in trait '__remove_cvref(_InIter1)' in function signature; use library traits instead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114878 Bug ID: 114878 Summary: GCC fails with an error on armv7: use of built-in trait '__remove_cvref(_InIter1)' in function signature; use library traits instead Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: yuri at tsoft dot com Target Milestone: --- 2 projects where the problem occurs: * https://karlsruhemis.github.io/ * https://github.com/Artelnics/opennn The failure occurs on FreeBSD, only on the armv7 architecture. Here is the FreeBSD bug report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278630 Here is a sample failure log: https://pkg-status.freebsd.org/ampere1/data/140releng-armv7-quarterly/1b931669de11/logs/kamis-2.1.log
[Bug c++/114652] New: g++ fails to compile the ceres-solver-2.2.0 project: error: use of built-in trait '__remove_cvref(_Tp)' in function signature; use library traits instead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114652 Bug ID: 114652 Summary: g++ fails to compile the ceres-solver-2.2.0 project: error: use of built-in trait '__remove_cvref(_Tp)' in function signature; use library traits instead Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: yuri at tsoft dot com Target Milestone: --- Command and error: /usr/local/bin/g++13 -DCERES_SUITESPARSE_VERSION=\"7.6.1\" -DEIGEN_MPL2_ONLY -DGFLAGS_IS_A_DLL=0 -DGLOG_USE_GFLAGS -DGLOG_USE_GLOG_EXPORT -Dceres_EXPORTS -I/wrkdirs/usr/ports/math/ceres-solver/work/ceres-solver-2.2.0/include -I/wrkdirs/usr/ports/math/ceres-solver/work/ceres-solver-2.2.0/internal -I/wrkdirs/usr/ports/math/ceres-solver/work/.build/include -I/usr/local/include/suitesparse -I/usr/local/include/eigen3 -O2 -pipe -fstack-protector-strong -Wl,-rpath=/usr/local/lib/gcc13 -stdlib=libc++ -Wl,-rpath=/usr/local/lib/gcc13 -isystem /usr/local/include -Wmissing-declarations -Wno-unknown-pragmas -Wno-sign-compare -Wno-unused-parameter -Wno-missing-field-initializers -O2 -pipe -fstack-protector-strong -Wl,-rpath=/usr/local/lib/gcc13 -stdlib=libc++ -Wl,-rpath=/usr/local/lib/gcc13 -isystem /usr/local/include -DNDEBUG -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -pthread -MD -MT internal/ceres/CMakeFiles/ceres_internal.dir/parameter_block_ordering.cc.o -MF internal/ceres/CMakeFiles/ceres_internal.dir/parameter_block_ordering.cc.o.d -o internal/ceres/CMakeFiles/ceres_internal.dir/parameter_block_ordering.cc.o -c /wrkdirs/usr/ports/math/ceres-solver/work/ceres-solver-2.2.0/internal/ceres/parameter_block_ordering.cc In file included from /usr/include/c++/v1/__algorithm/copy_move_common.h:12, from /usr/include/c++/v1/__algorithm/copy.h:12, from /usr/include/c++/v1/__memory/uninitialized_algorithms.h:13, from /usr/include/c++/v1/__memory/ranges_uninitialized_algorithms.h:22, from /usr/include/c++/v1/memory:896, from /wrkdirs/usr/ports/math/ceres-solver/work/ceres-solver-2.2.0/internal/ceres/parameter_block_ordering.h:34, from /wrkdirs/usr/ports/math/ceres-solver/work/ceres-solver-2.2.0/internal/ceres/parameter_block_ordering.cc:31: /usr/include/c++/v1/__algorithm/iterator_operations.h: In instantiation of 'static constexpr std::__1::__remove_cvref_t<_Tp> std::__1::_IterOps::prev(_Iter&&, typename std::__1::iterator_traits<__remove_cvref(_Tp)>::difference_type) [with _Iter = std::__1::__wrap_iter&]': /usr/include/c++/v1/__algorithm/iterator_operations.h:161:27: error: use of built-in trait '__remove_cvref(_Tp)' in function signature; use library traits instead 161 | __remove_cvref_t<_Iter> prev(_Iter&& __iter, | ^~~~ /usr/include/c++/v1/__algorithm/iterator_operations.h: In instantiation of 'static constexpr std::__1::__remove_cvref_t<_Tp> std::__1::_IterOps::next(_Iter&&, typename std::__1::iterator_traits<__remove_cvref(_Tp)>::difference_type) [with _Iter = std::__1::__wrap_iter&]': /usr/include/c++/v1/__algorithm/iterator_operations.h:153:27: error: use of built-in trait '__remove_cvref(_Tp)' in function signature; use library traits instead 153 | __remove_cvref_t<_Iter> next(_Iter&& __it, | ^~~~ Log: https://pkg-status.freebsd.org/ampere3/data/140releng-armv7-default/26c5fe5d2fe6/logs/ceres-solver-2.2.0_8.log OS: FreeBSD 14.0
[Bug c++/110746] gcc-12 fails: sorry, unimplemented: PCH allocation failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110746 --- Comment #7 from Yuri --- gcc-13 has the same problem.
[Bug c++/110746] gcc-12 fails: sorry, unimplemented: PCH allocation failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110746 --- Comment #6 from Yuri --- FAILED: src/plugins/score-plugin-avnd/CMakeFiles/score_plugin_avnd.dir/__/__/__/midiscaler_avnd.cpp.o /usr/local/libexec/ccache/g++13 -DBOOST_ASIO_DISABLE_CONCEPTS=1 -DBOOST_MATH_DISABLE_FLOAT128=1 -DBOOST_NO_RTTI=1 -DLIBREMIDI_ALSA -DLIBREMIDI_JACK -DQT_CORE_LIB -DQT_DISABLE_DEPRECATED_BEFORE=0x0605ff -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_NO_JAVA_STYLE_ITERATORS -DQT_NO_KEYWORDS -DQT_NO_LINKED_LIST -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_NO_USING_NAMESPACE -DQT_OPENGL_LIB -DQT_QMLINTEGRATION_LIB -DQT_QML_LIB -DQT_SERIALPORT_LIB -DQT_SHADERTOOLS_LIB -DQT_STATEMACHINE_LIB -DQT_STATICPLUGIN -DQT_USE_QSTRINGBUILDER -DQT_WEBSOCKETS_LIB -DQT_WIDGETS_LIB -DRAPIDJSON_HAS_STDSTRING=1 -DSCORE_LIB_BASE -DSCORE_LIB_DEVICE -DSCORE_LIB_INSPECTOR -DSCORE_LIB_LOCALTREE -DSCORE_LIB_PROCESS -DSCORE_LIB_STATE -DSCORE_PLUGIN_AUDIO -DSCORE_PLUGIN_AUTOMATION -DSCORE_PLUGIN_AVND_EXPORTS -DSCORE_PLUGIN_CURVE -DSCORE_PLUGIN_DATAFLOW -DSCORE_PLUGIN_DEVICEEXPLORER -DSCORE_PLUGIN_ENGINE -DSCORE_PLUGIN_GFX -DSCORE_PLUGIN_LIBRARY -DSCORE_PLUGIN_MEDIA -DSCORE_PLUGIN_SCENARIO -DSCORE_PLUGIN_TRANSPORT -DSCORE_STATIC_PLUGINS -DSERVUS_USE_AVAHI_CLIENT -DTINYSPLINE_DOUBLE_PRECISION -I/usr/ports/multimedia/ossia-score/work/.build/src/plugins/score-plugin-avnd -I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/src/plugins/score-plugin-avnd -I/usr/ports/multimedia/ossia-score/work/.build -I/usr/ports/multimedia/ossia-score/work/.build/src/plugins/score-plugin-engine -I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/src/plugins/score-plugin-engine -I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/3rdparty -I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/3rdparty/zipdownloader/src -I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/3rdparty/QProgressIndicator -I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/3rdparty/Qt-Color-Widgets -I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/3rdparty/Qt-Color-Widgets/src -I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/3rdparty/Qt-Color-Widgets/QtColorWidgets -I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/3rdparty/libossia/3rdparty/verdigris/src -I/usr/ports/multimedia/ossia-score/work/.build/src/lib -I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/src/lib -I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/3rdparty/libossia/3rdparty/Flicks -I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/3rdparty/libossia/src -I/usr/ports/multimedia/ossia-score/work/.build/3rdparty/libossia/src -I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/3rdparty/libossia/3rdparty/Servus/servus/.. -I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/3rdparty/QCodeEditor/include -I/usr/ports/multimedia/ossia-score/work/.build/src/plugins/score-lib-device -I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/src/plugins/score-lib-device -I/usr/ports/multimedia/ossia-score/work/.build/src/plugins/score-lib-state -I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/src/plugins/score-lib-state -I/usr/local/include/qt6/QtDBus/6.4.2 -I/usr/local/include/qt6/QtDBus/6.4.2/QtDBus -I/usr/ports/multimedia/ossia-score/work/.build/src/plugins/score-lib-process -I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/src/plugins/score-lib-process -I/usr/ports/multimedia/ossia-score/work/.build/src/plugins/score-lib-inspector -I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/src/plugins/score-lib-inspector -I/usr/ports/multimedia/ossia-score/work/.build/src/plugins/score-lib-localtree -I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/src/plugins/score-lib-localtree -I/usr/ports/multimedia/ossia-score/work/.build/src/plugins/score-plugin-library -I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/src/plugins/score-plugin-library -I/usr/ports/multimedia/ossia-score/work/.build/src/plugins/score-plugin-deviceexplorer -I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/src/plugins/score-plugin-deviceexplorer -I/usr/ports/multimedia/ossia-score/work/.build/src/plugins/score-plugin-transport -I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/src/plugins/score-plugin-transport -I/usr/ports/multimedia/ossia-score/work/.build/src/plugins/score-plugin-scenario -I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/src/plugins/score-plugin-scenario -I/usr/ports/multimedia/ossia-score/work/.build/src/plugins/score-plugin-curve -I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/src/plugins/score-plugin-curve -I/usr/ports/multimedia/ossia-score/work/.build/src/plugins/score-plugin-automation -I/usr/ports/multimedia/ossia-score/work/ossia-score-3.1.11/src/plugins/score-plugin-automation -I/usr/ports/multimedia/ossia-score/work/.build/src/plugins/score-plugin-audio
[Bug c++/110746] gcc-12 fails: sorry, unimplemented: PCH allocation failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110746 --- Comment #4 from Yuri --- This happens during the build of the Ossia Score project: https://github.com/ossia/score
[Bug c++/110746] gcc-12 fails: sorry, unimplemented: PCH allocation failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110746 --- Comment #1 from Yuri --- OS: FreeBSD 13.2
[Bug c++/110746] New: gcc-12 fails: sorry, unimplemented: PCH allocation failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110746 Bug ID: 110746 Summary: gcc-12 fails: sorry, unimplemented: PCH allocation failure Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: yuri at tsoft dot com Target Milestone: --- > : sorry, unimplemented: PCH allocation failure This message is in the GCC source code. What does this mean "PCH allocation failure"? What is wrong?
[Bug other/106328] New: Build doesn't respect -j N flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106328 Bug ID: 106328 Summary: Build doesn't respect -j N flag Product: gcc Version: 11.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: yuri at tsoft dot com Target Milestone: --- -j8 is given to it, but it creates ~130 lto1 processes. See this downstream issues for details: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265254
[Bug fortran/100662] intrinsic::ieee_arithmetic fails on aarch, powerpc architectures on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100662 --- Comment #7 from Yuri --- fpu-387.h is in the gcc10 source tree: > $ find . -name "fpu-*" > ./work/gcc-10.3.0/libgfortran/config/fpu-generic.h > ./work/gcc-10.3.0/libgfortran/config/fpu-sysv.h > ./work/gcc-10.3.0/libgfortran/config/fpu-glibc.h > ./work/gcc-10.3.0/libgfortran/config/fpu-aix.h > ./work/gcc-10.3.0/libgfortran/config/fpu-387.h fpu-aarch64.h isn't in the gcc10 tree, and not among FreeBSD-installed headers. It seems that it is missing in gcc?
[Bug fortran/100662] intrinsic::ieee_arithmetic fails on aarch, powerpc architectures on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100662
--- Comment #5 from Yuri ---
config.log doesn't contain the IEEE string even on amd64.
libgfortran/configure.host seems to only enable IEEE modules on i?86 | x86_64
architectures through this code:
> case "${host_cpu}" in
> i?86 | x86_64)
> if test "x${have_soft_float}" = "xyes"; then
> fpu_host='fpu-generic'
> else
> fpu_host='fpu-387'
> fi
> ieee_support='yes'
> ;;
> esac
What does gcc need from OS for IEEE754?
Shouldn't it just compile with relevant to IEEE754 opcodes?
[Bug fortran/100662] intrinsic::ieee_arithmetic fails on aarch, powerpc architectures on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100662 --- Comment #3 from Yuri --- On amd64 gcc installs the file finclude/ieee_arithmetic.mod and on aarch64 this file isn't installed. What is installed is defined by the gcc build process.
[Bug fortran/100662] intrinsic::ieee_arithmetic fails on aarch, powerpc architectures on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100662 --- Comment #2 from Yuri --- intrinsic::ieee_arithmetic works fine on amd64/i386 architectures on the same OS. What do you think is missing/wrong in the OS that causes it?
[Bug fortran/100662] New: intrinsic::ieee_arithmetic fails on aarch, powerpc architectures on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100662 Bug ID: 100662 Summary: intrinsic::ieee_arithmetic fails on aarch, powerpc architectures on FreeBSD Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: yuri at tsoft dot com Target Milestone: --- Fortran codes using intrinsic::ieee_arithmetic on aarch, powerpc architectures fail to compile. See details in this FreeBSD bug report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255890
[Bug c++/93120] New: gcc-9 complains fails to see that switch handles all enum values, and still complains ' "control reaches end of non-void function" when there is no return after the switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93120 Bug ID: 93120 Summary: gcc-9 complains fails to see that switch handles all enum values, and still complains ' "control reaches end of non-void function" when there is no return after the switch Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: yuri at tsoft dot com Target Milestone: --- Example: https://github.com/yurivict/nn-insight/blob/master/plugins/tf-lite/tf-lite.cpp#L33 gcc-9 complains: > /usr/ports/misc/nn-insight/work/nn-insight-0.1-3-g78a125f/plugins/tf-lite/tf-lite.cpp: > In function 'PluginInterface::PaddingType > Helpers::convertPaddingType(tflite::Padding)': > /usr/ports/misc/nn-insight/work/nn-insight-0.1-3-g78a125f/plugins/tf-lite/tf-lite.cpp:37:2: > warning: control reaches end of non-void function [-Wreturn-type] >37 | } > | ^
[Bug fortran/88549] New: gcc doesn't install iso_c_binding.mod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88549 Bug ID: 88549 Summary: gcc doesn't install iso_c_binding.mod Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: yuri at tsoft dot com Target Milestone: --- gcc doesn't install iso_c_binding.mod, and the pcmsolver project (https://github.com/PCMSolver/pcmsolver) fails: > F90-F-0004-Unable to open MODULE file iso_c_binding.mod > (/wrkdirs/usr/ports/science/pcmsolver/work/pcmsolver-1.2.1/src/metal/metal_sphere.F90: > 26) > F90/x86-64 FreeBSD Flang - 1.5 2017-05-01: compilation aborted Googling iso_c_binding.mod finds some more instances of a similar problem. See log: http://beefy6.nyi.freebsd.org/data/120amd64-default/487722/logs/pcmsolver-1.2.1_2.log FreeBSD 12 amd64
[Bug fortran/86566] The preprocessor cpp6 loses line concatenation on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86566 --- Comment #2 from Yuri --- Replacing cpp with gcc6 -cpp fails: $ gcc6 -cpp -fno-omit-frame-pointer -D__FFTW3 -I/usr/ports/science/quantum-espresso/work/q-e-qe-6.3/include -I/usr/ports/science/quantum-espresso/work/q-e-qe-6.3/FoX/finclude -I/usr/ports/science/quantum-espresso/work/q-e-qe-6.3/S3DE/iotk/include/ iotk_base.f90 -o iotk_base_tmp.f90 /usr/lib/crt1.o: In function `_start': /usr/src/lib/csu/amd64/crt1.c:(.text+0x17b): undefined reference to `main' collect2: error: ld returned 1 exit status It seems like it tries to link the executable?
[Bug fortran/86566] New: The preprocessor cpp6 loses line concatenation on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86566 Bug ID: 86566 Summary: The preprocessor cpp6 loses line concatenation on FreeBSD Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: yuri at tsoft dot com Target Milestone: --- How to repeat: create the file a.f90 with this one line (it is also attached): > call iotk_strcat(string,trim(adjustl(tmpval))//" ",ierr) Run the command: > cpp8 a.f90 -o atmp.f90 The result isn't a valid fortran: > call iotk_strcat(string,trim(adjustl(tmpval)) The problem observed on gcc8 and gcc6. The FreeBSD port bug report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229855
[Bug c++/61652] New: Option --enable-libstdcxx-debug doesn't pass debug options to libstdc++.so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61652 Bug ID: 61652 Summary: Option --enable-libstdcxx-debug doesn't pass debug options to libstdc++.so Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: yuri at tsoft dot com Based on documentation here https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug.html I configured gcc to build a debug version of libstdc++.so: $ ../src/configure --prefix=/opt/gcc/4.8.2/ --enable-libstdcxx-debug --enable-libstdcxx-debug-flags='-g3 -O0' $ gmake It did build another version of libstdc++.so with different size under lib/debug/, but both of them have local variables optimized away. I am interested in ../src/libstdc++-v3/libsupc++/dyncast.cc, touching it and rebuilding shows that -O0 hasn't been passed to the compile command, and it builds with -O2. Building gcc-4.8.2 on FreeBSD-10
[Bug c++/56941] New: Thread conflict is reported by helgrind in _Unwind_IteratePhdrCallback
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56941 Bug #: 56941 Summary: Thread conflict is reported by helgrind in _Unwind_IteratePhdrCallback Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: y...@tsoft.com I get the following error from helgrind on heavily multi-threaded process throwing a lot of exceptions. gcc in use is 4.7.2 on amd64 architecture. Line unwind-dw2-fde-dip.c:212: prev_cache_entry-link = cache_entry-link; It looks like the error is due to an unprotected cache access. This should either be fixed, or there should be a good explanation why this should be considered a non-issue. Data race conditions reported by helgrind usually correspond to real issues. ---helgrind log--- ==83659== Possible data race during write of size 8 at 0x24FECC8 by thread #17 ==83659== Locks held: none ==83659==at 0x22FB1D9: _Unwind_IteratePhdrCallback (unwind-dw2-fde-dip.c:212) ==83659==by 0x14D41: dl_iterate_phdr (in /libexec/ld-elf.so.1) ==83659==by 0x22FB8B1: _Unwind_Find_FDE (unwind-dw2-fde-dip.c:451) ==83659==by 0x22F8D9A: uw_frame_state_for (unwind-dw2.c:1179) ==83659==by 0x22F91F6: uw_init_context_1 (unwind-dw2.c:1500) ==83659==by 0x22F96A6: _Unwind_RaiseException (unwind.inc:88) ==83659==by 0x1E1FAD0: __cxa_throw (eh_throw.cc:78) ==83659==...user stack omitted... ==83659== ==83659== This conflicts with a previous write of size 8 by thread #54 ==83659== Locks held: none ==83659==at 0x22FB1D5: _Unwind_IteratePhdrCallback (unwind-dw2-fde-dip.c:211) ==83659==by 0x14D41: dl_iterate_phdr (in /libexec/ld-elf.so.1) ==83659==by 0x22FB8B1: _Unwind_Find_FDE (unwind-dw2-fde-dip.c:451) ==83659==by 0x22F8D9A: uw_frame_state_for (unwind-dw2.c:1179) ==83659==by 0x22F970A: _Unwind_RaiseException (unwind.inc:99) ==83659==by 0x1E1FAD0: __cxa_throw (eh_throw.cc:78) ==83659==...user stack omitted...
[Bug c/56099] New: Empty static noinline functions aren't called from optimized code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56099
Bug #: 56099
Summary: Empty static noinline functions aren't called from
optimized code
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: y...@tsoft.com
The C testcase below, when compiled with gcc-4.7.1 with flag '-O2', doesn't
contain the noinline function at all. No body and no call.
gcc-4.2.1 did leave the body of such function, but also didn't have the call.
gcc should respect noinline attribute even on the empty functions and should
leave both body and call to it.
PS: I hit this while attempting to add the DTrace probes through adding of the
empty function. However, call to this function was never placed into code so
this technique doesn't work due to this bug.
---testcase---
__attribute__((noinline))
static int func_ni() {
return 1;
}
void func_exp() {
func_ni();
}
[Bug tree-optimization/56099] Empty static noinline functions aren't called from optimized code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56099 --- Comment #2 from Yuri yuri at tsoft dot com 2013-01-24 19:06:12 UTC --- Created attachment 29267 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29267 asm of the testcase showing there is still no noinline function I am trying 'noclone' with gcc-4.7.1 but there is still no func_ni in the resulting output: /opt/gcc/4.7.1/bin/gcc -O2 -S ni.c See ni.s attached
[Bug tree-optimization/56099] Empty static noinline functions aren't called from optimized code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56099 --- Comment #4 from Yuri yuri at tsoft dot com 2013-01-24 19:16:10 UTC --- You are saying I also need to place some __asm__ into this noinline function? Doesn't this look like working around some bugs in gcc? User doesn't need to know how gcc is doing this inside, weather it is cloning something or treats it as pure or not. noinline means do-not-inline, no matter what is inside. I originally asked for a simple basic thing, and so many gcc guts got exposed by this.
[Bug tree-optimization/56099] Empty static noinline functions aren't called from optimized code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56099 --- Comment #6 from Yuri yuri at tsoft dot com 2013-01-24 19:24:43 UTC --- I think 'noinline' flag should be factored into the removal decision.
[Bug c/49685] New: libgcc_s.so not compiled without optimization when requested
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49685 Summary: libgcc_s.so not compiled without optimization when requested Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: y...@tsoft.com I need to have libgcc_s.so without optimization and with debug info. Following documentation on GCC own site http://gcc.gnu.org/onlinedocs/libstdc++/manual/debug.html, I ran make with overriding compilation flags: make CXXFLAGS='-g3 -fno-inline -O0' CFLAGS='-g3 -fno-inline -O0' all But the resulting libgcc_s.so is still optimized. I could see that -O 2 was passed to all compiles. Actually, gcc build process should respect the given to the top-level make CFLAGS and CXXFLAGS and propagate them to all levels.
[Bug bootstrap/49306] New: 4.6.0 fails to build on Solaris 11 (i386)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49306 Summary: 4.6.0 fails to build on Solaris 11 (i386) Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: y...@tsoft.com I have prerequisite gmp,mfrc,mpc and binutils installed under /opt/local. Configure command is: ../src/configure \ --with-gnu-as --with-as=/opt/local/bin/as \ --with-gnu-ld --with-ld=/opt/local/bin/ld \ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local \ --prefix=/usr/local/gcc/4.6.0 followed by gmake -j 2 causes the error: ...skiped... checking for i386-pc-solaris2.11-gcc... /tmp/gcc-build/4.6.0/bld/./gcc/xgcc -B/tmp/gcc-build/4.6.0/bld/./gcc/ -B/usr/local/gcc/4.6.0/i386-pc-solaris2.11/bin/ -B/usr/local/gcc/4.6.0/i386-pc-solaris2.11/lib/ -isystem /usr/local/gcc/4.6.0/i386-pc-solaris2.11/include -isystem /usr/local/gcc/4.6.0/i386-pc-solaris2.11/sys-include checking for suffix of object files... configure: error: in `/tmp/gcc-build/4.6.0/bld/i386-pc-solaris2.11/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. gmake[2]: *** [configure-stage1-target-libgcc] Error 1 gmake[2]: Leaving directory `/tmp/gcc-build/4.6.0/bld' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/tmp/gcc-build/4.6.0/bld' gmake: *** [all] Error 2 File /tmp/gcc-build/4.6.0/bld/i386-pc-solaris2.11/libgcc/config.log has this error in it: configure:3268: /tmp/gcc-build/4.6.0/bld/./gcc/xgcc -B/tmp/gcc-build/4.6.0/bld/./gcc/ -B/usr/local/gcc/4.6.0/i386-pc-solaris2.11/bin/ -B/usr/local/gcc/4.6.0/i386-pc-solaris2.11/lib/ -isystem /usr/local/gcc/4.6.0/i386-pc-solaris2.11/include -isystem /usr/local/gcc/4.6.0/i386-pc-solaris2.11/sys-include-c -g -O2 conftest.c 5 ld.so.1: cc1: fatal: libmpc.so.2: open failed: No such file or directory xgcc: internal compiler error: Killed (program cc1) Please submit a full bug report, with preprocessed source if appropriate. Workaround that I found is to remove all .so files from /opt/local/lib (libmpc.so.2 and others) After this build succeeds. I should note that I use Solaris 11 appliance ready to run in VirtualBox.
[Bug target/47842] gcc forces 16-byte stack alignment on Solaris i386, when SYSV requires word alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47842 --- Comment #3 from Yuri yuri at tsoft dot com 2011-02-22 19:23:45 UTC --- If gcc would only set 16 byte alignment this wouldn't be that bad since, as you mentioned, it is still word aligned. The problem is that gcc assumes that stack is 16 aligned and creates code based on this. For example it places instruction like this 'movdqa %xmm0, 0x10(%esp)' which assumes 16 byte alignment. As a result, gcc compiled procedure crashes when called by ABI compliant code. gcc can't assume 16 byte alignment.
[Bug c/47842] New: gcc forces 16-byte stack alignment on Solaris i386, when SYSV requires word alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47842 Summary: gcc forces 16-byte stack alignment on Solaris i386, when SYSV requires word alignment Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: y...@tsoft.com Linux made a decision to switch to 16-byte alignment, but not others. I know for a fact that Solaris is affected, I am not sure, but FreeBSD i386 might also be affected. Please turn this behavior back to the one prescribed by specification for Solaris (and FreeBSD if affected): http://www.sco.com/developers/devspecs/abi386-4.pdf section 3-10: The stack is word aligned. Although the architecture does not require any alignment of the stack, software convention and the operating system requires that the stack be aligned on a word boundary. Or please refer to the Sun/Oracle decision to change this behavior.
[Bug c++/47536] gcc-4.5.2 fails to build on Solaris 10 i386
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47536 --- Comment #4 from Yuri yuri at tsoft dot com 2011-01-30 11:17:32 UTC --- Passing --with-gnu-as option to configure fixes the problem. But why can't configure detect this by itself? GNU as has --version which clearly says that its GNU assembler. And original Solaris as doesn't have --version option.
[Bug c++/47536] gcc-4.5.2 fails to build on Solaris 10 i386
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47536 --- Comment #5 from Yuri yuri at tsoft dot com 2011-01-30 21:53:47 UTC --- --with-gnu-as lets gcc build to succeed. But resulting g++ has the problem on all c++ modules: g++ -c m.cpp Assembler: m.cpp /var/tmp//ccEysWY5.s, line 7 : Illegal mnemonic Near line: .cfi_startproc /var/tmp//ccEysWY5.s, line 7 : Syntax error Near line: .cfi_startproc /var/tmp//ccEysWY5.s, line 9 : Illegal mnemonic Near line: .cfi_def_cfa_offset 8 /var/tmp//ccEysWY5.s, line 9 : Syntax error Near line: .cfi_def_cfa_offset 8 /var/tmp//ccEysWY5.s, line 11 : Illegal mnemonic Near line: .cfi_offset 5, -8 /var/tmp//ccEysWY5.s, line 11 : Syntax error Near line: .cfi_offset 5, -8 /var/tmp//ccEysWY5.s, line 12 : Illegal mnemonic Near line: .cfi_def_cfa_register 5 /var/tmp//ccEysWY5.s, line 12 : Syntax error Near line: .cfi_def_cfa_register 5 /var/tmp//ccEysWY5.s, line 15 : Illegal mnemonic Near line: .cfi_restore 5 /var/tmp//ccEysWY5.s, line 15 : Syntax error Near line: .cfi_restore 5 /var/tmp//ccEysWY5.s, line 16 : Illegal mnemonic Near line: .cfi_def_cfa 4, 4 /var/tmp//ccEysWY5.s, line 16 : Syntax error Near line: .cfi_def_cfa 4, 4 /var/tmp//ccEysWY5.s, line 18 : Illegal mnemonic Near line: .cfi_endproc /var/tmp//ccEysWY5.s, line 18 : Syntax error Near line: .cfi_endproc ba
[Bug c++/47536] gcc-4.5.2 fails to build on Solaris 10 i386
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47536 --- Comment #7 from Yuri yuri at tsoft dot com 2011-01-30 22:03:50 UTC --- Actually g++ produces the correct assembler file, but still calls original Sun assembler /usr/ccs/bin/as instead of the GNU one from the path, regardless of the option --with-gnu-as passed to gcc configure. Removing /usr/ccs/bin/as fixes the problem. So there are two issues with gcc-4.5.2 on Solaris: 1. Inability to detect GNU assembler in path (unwarranted requirement to pass --with-gnu-as). Broken build when either no GNU assembler in path or no option --with-gnu-as passed. 2. GNU assembler from path isn't used by g++, causing Sun assembler to fail on GNU-formatted assembler file.
[Bug c++/47536] gcc-4.5.2 fails to build on Solaris 10 i386
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47536 --- Comment #8 from Yuri yuri at tsoft dot com 2011-01-30 22:06:50 UTC --- (In reply to comment #6) Which is why it's recommended in the docs: http://gcc.gnu.org/install/specific.html#ix86-x-solaris210 Please try using the suggested configuration There is nothing in these recommendations that configure can't do by itself. Please update configure so that all users don't have to stumble upon the same things over and over.
[Bug c++/47536] gcc-4.5.2 fails to build on Solaris 10 i386
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47536 --- Comment #10 from Yuri yuri at tsoft dot com 2011-01-30 23:27:13 UTC --- (In reply to comment #9) well if you don't want a working compiler feel free to ignore the docs and refuse to try the options that might help I didn't refuse to try anything, I already got the working compiler. I have suggested the improvement of configure to avoid further user confusion.
[Bug c/46713] -fvisibility=hidden generates broken code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46713 --- Comment #6 from Yuri yuri at tsoft dot com 2011-01-29 20:07:34 UTC --- Thanks! You can change the warning message to be a bit more proactive: visibility attribute not supported in this configuration (as during configuration wasn't from binutils?); ignored
[Bug c++/47536] New: gcc-4.5.2 fails to build on Solaris 10 i386
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47536 Summary: gcc-4.5.2 fails to build on Solaris 10 i386 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: y...@tsoft.com I downloaded gcc-core-4.5.2 and gcc-g++-4.5.2, configured with command: ../src/configure --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --prefix=/opt/local/gcc/4.5.2 Current binutils is in path. This is an error I am getting after a while: ...skiped... checking for i386-pc-solaris2.10-gcc... /tmp/gcc-build/4.5.2/bld/./gcc/xgcc -B/tmp/gcc-build/4.5.2/bld/./gcc/ -B/opt/local/gcc/4.5.2/i386-pc-solaris2.10/bin/ -B/opt/local/gcc/4.5.2/i386-pc-solaris2.10/lib/ -isystem /opt/local/gcc/4.5.2/i386-pc-solaris2.10/include -isystem /opt/local/gcc/4.5.2/i386-pc-solaris2.10/sys-include -m64 checking for suffix of object files... configure: error: in `/tmp/gcc-build/4.5.2/bld/i386-pc-solaris2.10/amd64/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. gmake[2]: *** [configure-stage1-target-libgcc] Error 1 gmake[2]: Leaving directory `/tmp/gcc-build/4.5.2/bld' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/tmp/gcc-build/4.5.2/bld' gmake: *** [all] Error 2 Its strange that there is an option -m64 that appears in the command line.
[Bug c++/47536] gcc-4.5.2 fails to build on Solaris 10 i386
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47536 --- Comment #2 from Yuri yuri at tsoft dot com 2011-01-29 22:15:45 UTC --- Created attachment 23165 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23165 Requested config.log
[Bug c++/47536] gcc-4.5.2 fails to build on Solaris 10 i386
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47536 --- Comment #3 from Yuri yuri at tsoft dot com 2011-01-29 22:40:09 UTC --- Assembler complains on -xarch option. /opt/local/bin/as: unrecognized option `-xarch=generic64' But '/opt/local/bin/as --help' doeasn't list -xarch as the valid option. It has -march option.
[Bug c++/47529] New: Visibility attributes not supported on Solaris i386 platform
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47529 Summary: Visibility attributes not supported on Solaris i386 platform Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: y...@tsoft.com I am porting project to Solaris. Same code that builds fine on Linux/BSD produces warnings on Solaris 10: warning: visibility attribute not supported in this configuration; ignored Compilation of modules succeeds with these warnings. But later linking of those object modules into the shared library fails with this message: ld: fatal: relocation error: R_386_GOTOFF: file /path/to/library/libmine.a(module.o): symbol some symbol is here: relocation must bind locally. collect2: ld returned 1 exit status I have built gcc-4.5.2 myself with the same options on both Linux and Solaris. Why wouldn't visibility attributes not be supported in Solaris configuration? Also reading some threads from the past I see that these two messages are somewhat related. Due to the lack of visibility attributes some symbol with R_386_GOTOFF becomes global and can't be linked into the shared library as global. How to solve such problem when c++ code defines some symbols with hidden attributes and Solaris version of gcc fails to support this?
[Bug c++/46109] New: gcc-4.5.0 fails to build on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46109 Summary: gcc-4.5.0 fails to build on Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: y...@tsoft.com I tried to build gcc-4.5.0 exactly the same way that succeeds on LInux and failed on Mac OS X. Darwin MacBook.local 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23 18:28:53 PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386 i386 --- build log --- ...skipped... make DESTDIR= RPATH_ENVVAR=DYLD_LIBRARY_PATH TARGET_SUBDIR=i386-apple-darwin10.4.0 bindir=/usr/local/bin datadir=/usr/local/share exec_prefix=/usr/local includedir=/usr/local/include datarootdir=/usr/local/share docdir=/usr/local/share/doc/ infodir=/usr/local/share/info pdfdir=/usr/local/share/doc/ htmldir=/usr/local/share/doc/ libdir=/usr/local/lib libexecdir=/usr/local/libexec lispdir= localstatedir=/usr/local/var mandir=/usr/local/share/man oldincludedir=/usr/include prefix=/usr/local sbindir=/usr/local/sbin sharedstatedir=/usr/local/com sysconfdir=/usr/local/etc tooldir=/usr/local/i386-apple-darwin10.4.0 build_tooldir=/usr/local/i386-apple-darwin10.4.0 target_alias=i386-apple-darwin10.4.0 AWK=awk BISON=bison CC_FOR_BUILD=gcc CFLAGS_FOR_BUILD=-g -O2 CXX_FOR_BUILD=g++ EXPECT=expect FLEX=flex INSTALL=/usr/bin/install -c INSTALL_DATA=/usr/bin/install -c -m 644 INSTALL_PROGRAM=/usr/bin/install -c INSTALL_SCRIPT=/usr/bin/install -c LDFLAGS_FOR_BUILD= LEX=flex M4=gm4 MAKE=make RUNTEST=runtest RUNTESTFLAGS= SED=/usr/bin/sed SHELL=/bin/sh YACC=bison -y `echo 'ADAFLAGS=' | sed -e s'/[^=][^=]*=$/XFOO=/'` ADA_CFLAGS= AR_FLAGS=rc `echo 'BOOT_ADAFLAGS=-gnatpg -gnata' | sed -e s'/[^=][^=]*=$/XFOO=/'` BOOT_CFLAGS=-g -O2 -fomit-frame-pointer BOOT_LDFLAGS= CFLAGS=-g -O2 CXXFLAGS=-g -O2 LDFLAGS= LIBCFLAGS=-g -O2 LIBCXXFLAGS=-g -O2 -fno-implicit-templates STAGE1_CHECKING=--enable-checking=yes,types STAGE1_LANGUAGES=c GNATBIND=no GNATMAKE=no AR_FOR_TARGET=ar AS_FOR_TARGET=as CC_FOR_TARGET=/tmp/gcc-build/4.5.0/bld/./gcc/xgcc -B/tmp/gcc-build/4.5.0/bld/./gcc/ CFLAGS_FOR_TARGET=-g -O2 CPPFLAGS_FOR_TARGET= CXX_FOR_TARGET=/tmp/gcc-build/4.5.0/bld/./gcc/g++ -B/tmp/gcc-build/4.5.0/bld/./gcc/ -nostdinc++ -L/tmp/gcc-build/4.5.0/bld/i386-apple-darwin10.4.0/libstdc++-v3/src -L/tmp/gcc-build/4.5.0/bld/i386-apple-darwin10.4.0/libstdc++-v3/src/.libs CXXFLAGS_FOR_TARGET=-g -O2 DLLTOOL_FOR_TARGET=dlltool FLAGS_FOR_TARGET=-B/usr/local/i386-apple-darwin10.4.0/bin/ -B/usr/local/i386-apple-darwin10.4.0/lib/ -isystem /usr/local/i386-apple-darwin10.4.0/include -isystem /usr/local/i386-apple-darwin10.4.0/sys-include GCJ_FOR_TARGET= GFORTRAN_FOR_TARGET= LD_FOR_TARGET=/usr/libexec/gcc/i686-apple-darwin10/4.2.1/ld LIPO_FOR_TARGET=lipo LDFLAGS_FOR_TARGET= LIBCFLAGS_FOR_TARGET=-g -O2 LIBCXXFLAGS_FOR_TARGET=-g -O2 -fno-implicit-templates NM_FOR_TARGET=nm OBJDUMP_FOR_TARGET=objdump RANLIB_FOR_TARGET=ranlib STRIP_FOR_TARGET=strip WINDRES_FOR_TARGET=windres WINDMC_FOR_TARGET=windmc BUILD_CONFIG=bootstrap-debug `echo 'LANGUAGES=' | sed -e s'/[^=][^=]*=$/XFOO=/'` LEAN=false STAGE1_CFLAGS=-g -fkeep-inline-functions STAGE1_CXXFLAGS=-g -O2 STAGE1_TFLAGS= STAGE2_CFLAGS=-g -O2 -fomit-frame-pointer -gtoggle STAGE2_CXXFLAGS=-g -O2 STAGE2_TFLAGS= STAGE3_CFLAGS=-g -O2 -fomit-frame-pointer STAGE3_CXXFLAGS=-g -O2 STAGE3_TFLAGS= STAGE4_CFLAGS=-g -O2 -fomit-frame-pointer STAGE4_CXXFLAGS=-g -O2 STAGE4_TFLAGS= STAGEprofile_CFLAGS=-g -O2 -fomit-frame-pointer -gtoggle -fprofile-generate STAGEprofile_CXXFLAGS=-g -O2 STAGEprofile_TFLAGS= STAGEfeedback_CFLAGS=-g -O2 -fomit-frame-pointer -fprofile-use STAGEfeedback_CXXFLAGS=-g -O2 STAGEfeedback_TFLAGS= TFLAGS= CONFIG_SHELL=/bin/sh MAKEINFO=makeinfo --split-size=500 --split-size=500 compare rm -f stage_current Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs warning: gcc/cc1plus-checksum.o differs Bootstrap comparison failure! i386-apple-darwin10.4.0/libgomp/.libs/bar.o differs i386-apple-darwin10.4.0/libgomp/.libs/barrier.o differs i386-apple-darwin10.4.0/libgomp/.libs/env.o differs i386-apple-darwin10.4.0/libgomp/.libs/iter.o differs i386-apple-darwin10.4.0/libgomp/.libs/iter_ull.o differs i386-apple-darwin10.4.0/libgomp/.libs/lock.o differs i386-apple-darwin10.4.0/libgomp/.libs/loop.o differs i386-apple-darwin10.4.0/libgomp/.libs/loop_ull.o differs i386-apple-darwin10.4.0/libgomp/.libs/ordered.o differs i386-apple-darwin10.4.0/libgomp/.libs/parallel.o differs i386-apple-darwin10.4.0/libgomp/.libs/proc.o differs i386-apple-darwin10.4.0/libgomp/.libs/sections.o differs i386-apple-darwin10.4.0/libgomp/.libs/single.o differs i386-apple-darwin10.4.0/libgomp/.libs/task.o differs i386-apple-darwin10.4.0/libgomp/.libs/team.o differs i386-apple-darwin10.4.0/libgomp/.libs/work.o differs i386-apple-darwin10.4.0/libgomp/bar.o differs i386-apple-darwin10.4.0/libgomp/barrier.o differs i386-apple-darwin10.4.0/libgomp/env.o differs
[Bug c++/45917] New: Friend of friend is allowed the access to the private type through the template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45917
Summary: Friend of friend is allowed the access to the private
type through the template
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: y...@tsoft.com
testcase below has struct R as private in class F.
class F declares class Q a friend, allowing it to see it's private members.
But operator is friend in Q, not in F.
Why is it allowed for operator to instantiate listR but not R r? This is a
bug.
--- testcase ---
#include list
#include ostream
using namespace std;
class F {
private:
struct R {
}; // R
friend class Q;
class Q {
listR l;
friend ostream operator(ostream os, const Q q) {
// R r; // this breaks!
for (listR::const_iterator it = q.l.begin(); it != q.l.end(); it++) {
// this doesn't break! Why?
}
return os;
}
}; // Q
}; // F
[Bug c++/45918] New: Lack of warning on meaningless unsigned to zero comparison
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45918
Summary: Lack of warning on meaningless unsigned to zero
comparison
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: y...@tsoft.com
In this case idxNUM-1 is always false.
gcc should issue an error: comparison is always false due to the value range
limitations.
--- testcase ---
typedef unsigned size_t;
templatesize_t NUM
struct G {
void fn();
};
templatesize_t NUM
void GNUM::fn() {
for (size_t idx = 0; idxNUM-1; idx++) {
}
}
template struct G1;
[Bug c++/45918] Lack of warning on meaningless unsigned to zero comparison
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45918 --- Comment #2 from Yuri yuri at tsoft dot com 2010-10-06 23:16:21 UTC --- No warning in 4.2.1 for example.
[Bug c++/44298] New: code addressed only by label with it's address taken is ignored
The testcase below passes the entry point to 'lll' call as an address of the
label ll_def. printf line disappears completely.
Obviously people should only use such code when they really know what they are
doing. But compilation result here is complately wrong and isn't usable in any
way.
--- testcase ---
#include stdio.h
#include stdlib.h
__attribute__ ((noinline)) void lll(void*) {
}
void mainx() {
lll(ll_def);
return;
ll_def:
printf(default\n);
return;
}
--
Summary: code addressed only by label with it's address taken is
ignored
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44298
[Bug c++/44285] New: Need an option that will create symbols for all public c++ methods, not only for those which bodies are outside the class declaration
Consider the example below.
When compiled with flag -O3 methods meth_used and meth_unused aren't present in
the resulting assembly at all.
Now consider the situation when this class is a part of the package compiled
into the shared library and both meth_used and meth_unused are API of this
package.
Without the symbols for meth_used and meth_unused it's pretty much assumed that
the user will have c++ code that will recompile those function into the user
code. It's impossible to bind from other languages only knowing symbols without
c++ coding.
gcc should have an option, either compiler option, or the special keyword on
the method, that would guarantee the method presence in the object.
I looked into __attribute__ visibility. It only allows these values: default,
hidden, protected or internal and doesn't help in this situation.
Maybe public visibility should be added for this case?
-- example header: exp.h --
extern void zzz();
class Abc {
public:
void meth_used() {
zzz();
}
void meth_unused() {
zzz();
}
};
-- example header: exp.C --
#include exp.h
void my_exp() {
(new Abc)-meth_used();
}
--
Summary: Need an option that will create symbols for all public
c++ methods, not only for those which bodies are outside
the class declaration
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44285
[Bug c++/44285] Need an option that will create symbols for all public c++ methods, not only for those which bodies are outside the class declaration
--- Comment #4 from yuri at tsoft dot com 2010-05-26 16:37 --- Why this is useful, as I wrote above, to eliminate the need for c++ coding for binding with other languages. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44285
[Bug c++/44285] Need an option that will create symbols for all public c++ methods, not only for those which bodies are outside the class declaration
--- Comment #5 from yuri at tsoft dot com 2010-05-26 16:43 --- -fkeep-inline-functions leaves them, but it will also leave all inline functions, not only public ones. This will, I guess, blow up the size of the object since there can be a lot of internal inlines that shouldn't appear in the object. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44285
[Bug c++/43960] New: Template redeclaration with different number of parameters is tolerated
This testcase redeclares template H::F with different number of parameters.
This should be illegal, but gcc-4.5.0 passes it.
--- testcase ---
namespace H {
templateclass A,typename T,bool K struct F;
}
;
class Z {
templatetypename T friend struct H::F;
};
--
Summary: Template redeclaration with different number of
parameters is tolerated
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43960
[Bug c++/43884] New: Performance degradation of the simple example (fibonacci) 4.3.3-4.5.0
I ran this simple example with the argument 45 through various versions of gcc
(option -O3):
#include stdlib.h
#include stdio.h
int fib(int AnArg) {
if (AnArg = 2) return (1);
return (fib(AnArg-1)+fib(AnArg-2));
}
int main(int argc, char* argv[]) {
int n = atoi(argv[1]);
printf(fib(%i)=%i\n, n, fib(n));
}
Here are the average runtimes I got:
versiontime
4.3.1 3.930s
4.3.2 3.500s
4.3.3 3.470s
4.4.1 3.930s
4.4.3 3.940s
4.5.0 3.860s
I ran ~10 samples so values are approximate, but it's quite obvious that 4.5.0
has very significant degradation compared to 4.3.3.
Is there a performance suite for gcc that is ran for each release, are results
available online?
This case is pretty simple, basic. I would expect gcc to produce quite optimal
code for it.
--
Summary: Performance degradation of the simple example
(fibonacci) 4.3.3-4.5.0
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43884
[Bug c++/43882] New: 4.5.0 produces missing symbols (std::_List_node_base::_M_hook ...)
I have a c++ project with a lots of STL. It compiles fine with gcc 4.3.1 and 4.4.3, but with the new 4.5.0 I get those two missing symbols in linking: std::_List_node_base::_M_hook(std::_List_node_base*) std::_List_node_base::_M_unhook() libstdc++.so from 4.5.0 has those relevant symbols, and the ones not found are there: 000584c4 T std::_List_node_base::_M_hook(std::_List_node_base*) 000585bc T std::__norm::_List_node_base::_M_hook(std::__norm::_List_node_base*) 000ab3c8 T std::__cxx1998::_List_node_base::_M_hook(std::__cxx1998::_List_node_base*) 000584e0 T std::_List_node_base::_M_unhook() 000585d8 T std::__norm::_List_node_base::_M_unhook() 000ab3e4 T std::__cxx1998::_List_node_base::_M_unhook() -- Summary: 4.5.0 produces missing symbols (std::_List_node_base::_M_hook ...) Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: yuri at tsoft dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43882
[Bug c++/43882] 4.5.0 produces missing symbols (std::_List_node_base::_M_hook ...)
--- Comment #2 from yuri at tsoft dot com 2010-04-25 00:35 --- But linker produces messages like this: x.C:229: undefined reference to `std::_List_node_base::_M_hook(std::_List_node_base*)' New with the switch to 4.5.0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43882
[Bug c++/43882] 4.5.0 produces missing symbols (std::_List_node_base::_M_hook ...)
--- Comment #5 from yuri at tsoft dot com 2010-04-25 01:17 --- Sorry, my bad. It really was picking up the default libstdc++.so from the OS installation. I used -R/path/to/4.5.0/libstdc++.so to fix this library path. But it turns out that -L/path/to/4.5.0/libstdc++.so is also required in addition to this, otherwise the default libstdc++.so is looked up by linker. Maybe this is a bug in linker, don't know. But those new symbols revealed the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43882
[Bug c++/43503] New: field in-place decrement isn't optimized
Decrementing of the field causes 3 instructions for what could be one on i686
target.
--- testcase ---
struct C { int fld; };
extern void a();
extern void b();
void f(C *c) {
if (--c-fld 0) {
a();
} else {
a();
}
}
--- result of assembly with -O5 option ---
_Z1fP1C:
.LFB0:
pushl %ebp
.LCFI0:
movl%esp, %ebp
.LCFI1:
subl$8, %esp
.LCFI2:
movl8(%ebp), %edx
movl(%edx), %eax ; XXX
decl%eax ; XXX these three should be one insn
movl%eax, (%edx) ; XXX
leave
jmp _Z1av
--
Summary: field in-place decrement isn't optimized
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43503
[Bug c++/43503] field in-place decrement isn't optimized
--- Comment #2 from yuri at tsoft dot com 2010-03-24 01:14 --- I would put higher priority here over the other missed optimizations because this is the basic c/c++ construct and it's used very frequently. -- yuri at tsoft dot com changed: What|Removed |Added Component|middle-end |c++ Version|unknown |4.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43503
[Bug c++/41804] New: testsuite breaks with DejaGnu messages
When I try running 'gmake check' after compile I get such log:
skipped
Running target unix
Using /usr/local/share/dejagnu/baseboards/unix.exp as board description file
for target.
Using /usr/local/share/dejagnu/config/unix.exp as generic interface file for
target.
Using /tmp/gcc-build/gcc-4.4.2/libstdc++-v3/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running /tmp/gcc-build/gcc-4.4.2/libstdc++-v3/testsuite/libstdc++-abi/abi.exp
...
ERROR: (DejaGnu) proc set_ld_library_path_env_vars does not exist.
The error code is POSIX EINVAL {invalid argument}
The info on the error is:
could not readlink
/tmp/gcc-build/gcc-4.4.2/libstdc++-v3/testsuite/data/istream_extractor_other-1.txt:
invalid argument
while executing
file readlink $f
skipped
--
Summary: testsuite breaks with DejaGnu messages
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41804
[Bug java/41745] Segmentation fault when ecj.jar is run as a binary compiled by gcj
--- Comment #2 from yuri at tsoft dot com 2009-10-19 09:23 --- No, it doesn't work for me on FreeBSD-8.0: /usr/local/gcc/4.4.1-java/bin/gcj -o ecj --main=org.eclipse.jdt.internal.compiler.batch.Main /usr/local/share/java/ecj.jar LD_LIBRARY_PATH=/usr/local/gcc/4.4.1-java/lib ldd ./ecj ./ecj: libgcc_s.so.1 = /usr/local/gcc/4.4.1-java/lib/libgcc_s.so.1 (0x341ba000) libgcj.so.10 = /usr/local/gcc/4.4.1-java/lib/libgcj.so.10 (0x341c6000) libm.so.5 = /lib/libm.so.5 (0x363d9000) libthr.so.3 = /lib/libthr.so.3 (0x363f3000) librt.so.1 = /usr/lib/librt.so.1 (0x36408000) libc.so.7 = /lib/libc.so.7 (0x3640d000) LD_LIBRARY_PATH=/usr/local/gcc/4.4.1-java/lib ./ecj HelloWorld.java Segmentation fault: 11 backtrace: #0 0x364041c7 in __error () from /lib/libthr.so.3 #1 0x36403da8 in __error () from /lib/libthr.so.3 #2 0x36606820 in ?? () #3 0x0008 in ?? () #4 0x0001 in ?? () #5 0x36606800 in ?? () #6 0x in ?? () #7 0xbf9fedd4 in ?? () #8 0x363fe1a5 in pthread_rwlock_unlock () from /lib/libthr.so.3 #9 0x36401fae in pthread_cond_signal () from /lib/libthr.so.3 #10 0x34d217e8 in _Jv_CondWait (cv=0x3639778c, mu=0x36397780, millis=0, nanos=0) at ../../../gcc-4.4.1/libjava/posix-threads.cc:212 #11 0x8c34d070 in ?? () #12 0x3639778c in _ZL5mutex () from /usr/local/gcc/4.4.1-java/lib/libgcj.so.10 #13 0x36397780 in E () from /usr/local/gcc/4.4.1-java/lib/libgcj.so.10 #14 0x in ?? () #15 0x in ?? () #16 0x in ?? () #17 0x0001 in ?? () #18 0x341795a8 in dladdr () from /libexec/ld-elf.so.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41745
[Bug java/41745] Segmentation fault when ecj.jar is run as a binary compiled by gcj
--- Comment #4 from yuri at tsoft dot com 2009-10-19 17:20 --- I confirm this on FreeBSD-8.0 for gcc-4.5.0.20091001. I notified the maintainer of FreeBSD gcc port. But once the fix will be found it should go into gcj itself, not into port. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41745
[Bug java/41745] Segmentation fault when ecj.jar is run as a binary compiled by gcj
--- Comment #5 from yuri at tsoft dot com 2009-10-19 19:12 --- How to run testsuite for gcj? When I run 'gmake check-gcc' from the build directory it doesn't run gcj tests at all, and gcc/g++ tests summaries are all empty. Not sure what that means. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41745
[Bug java/41745] New: Segmentation fault when ecj.jar is run as a binary compiled by gcj
I use this command line:
gcj -o ecj --main=org.eclipse.jdt.internal.compiler.batch.Main
/usr/local/share/java/ecj.jar
to compile ecj.jar into native binary ecj.
However, when I try running resulting binary on Hello World Java program it
crashes. Original ecj.jar compiles HelloWorld successfully.
public class HelloWorld {
public static void main(String args[]) {
System.out.println(Hello World!);
}
}
--
Summary: Segmentation fault when ecj.jar is run as a binary
compiled by gcj
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41745
[Bug c/41462] New: redundant instructions with long double returned value
When I compile this function:
double f(long double i) {return (i);}
with gcc flags -S -O3, I get the assembly below.
There are two redundant FPU instructions there. double value is already in FPU
after fldt. No need to store it and load it back since difference between
double and long double is only in memory representation, and in FPU registers
they are the same.
asm output (relevant part)
f:
pushl %ebp
movl%esp, %ebp
subl$8, %esp redundant related stack adjustment
fldt8(%ebp)
fstpl -8(%ebp) redundant STORE
fldl-8(%ebp) redundant LOAD
leave
ret
--
Summary: redundant instructions with long double returned value
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41462
[Bug c/41462] redundant instructions with long double returned value
--- Comment #1 from yuri at tsoft dot com 2009-09-24 17:25 --- Forgot to mention: 32-bit mode on i586 CPU. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41462
[Bug java/41372] New: Symbols in shared library compiled from jar/classes should not be local with -findirect-dispatch
When I compile jar into shared library all symbols become local when -findirect-dispatch is specified. Local symbols can't be found by dlsym. -findirect-dispatch options shouldn't change symbols from global to local since external callers may choose to import them regardless of this option. -- Summary: Symbols in shared library compiled from jar/classes should not be local with -findirect-dispatch Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: yuri at tsoft dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41372
[Bug java/41375] New: Compiling native executable without -findirect-dispatch causes random SEGVs
I have a simple Java class that doesn't directly depend on anything except for java.lang.String, java.lang.reflect.Class and java.lang.reflect.Method. It loads other classes (from jars in my case) by name and invoked them through Class.forName()/Method.invoke() mechanism. But it only works when -findirect-dispatch is specified. Without -findirect-dispatch it crashes shortly into the run with the stack below. -findirect-dispatch should only impact the way how currently compiled unit links to other units. In case of the programs like mine (not dependent on anything else directly) -findirect-dispatch should have no impact at all. It should resolve classes and run them the same way, since in this scenario it's clear what should be done to load other classes. --- stack (debug info is not everywhere) --- 0x35ec31a7 in __error () from /lib/libthr.so.3 #1 0x35ec2d88 in __error () from /lib/libthr.so.3 #2 0x36005860 in ?? () #3 0x0008 in ?? () #4 0x0001 in ?? () #5 0x36005840 in ?? () #6 0x in ?? () #7 0x0001 in ?? () #8 0x33c718d4 in ?? () from /libexec/ld-elf.so.1 #9 0x35ec16df in pthread_setcancelstate () from /lib/libthr.so.3 #10 0x35ec0f7d in pthread_cond_signal () from /lib/libthr.so.3 #11 0x347e57e8 in _Jv_CondWait (cv=0x35e5b78c, mu=0x35e5b780, millis=0, nanos=0) at ../../../gcc-4.4.1/libjava/posix-threads.cc:212 #12 0x8c347cb0 in ?? () #13 0x35e5b78c in _ZL5mutex () from /usr/local/gcc/4.4.1-java/lib/libgcj.so.10 #14 0x35e5b780 in E () from /usr/local/gcc/4.4.1-java/lib/libgcj.so.10 #15 0x in ?? () #16 0x in ?? () #17 0x in ?? () #18 0x0001 in ?? () #19 0x33c4e998 in dladdr () from /libexec/ld-elf.so.1 -- Summary: Compiling native executable without -findirect-dispatch causes random SEGVs Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: yuri at tsoft dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41375
[Bug java/41375] Compiling native executable without -findirect-dispatch causes random SEGVs
--- Comment #1 from yuri at tsoft dot com 2009-09-16 12:12 --- I should also add that one of the classes has native methods, and crash occurs shortly after the first such method is invoked. This may or may not be a factor in the issue. Testcase is quite large and I can't submit it here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41375
[Bug java/41375] Compiling native executable without -findirect-dispatch causes random SEGVs
--- Comment #2 from yuri at tsoft dot com 2009-09-16 20:01 --- Created an attachment (id=18599) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18599action=view) Java proxy example that crashes without -findirect-dispatch Try making an executable with -findirect-dispatch and run some large application through it's 'main' method. I get SEGV from inside this application. FreeBSD-72-STABLE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41375
[Bug java/41361] New: segmentation fault when class not found from gcj-built executable with indirect dispatch
I compile an executable: gcj --main=MyApp -findirect-dispatch --classpath=xxx MyApp.class -o my-app When I run my-app and class required by MyClass to run is missing I see Segmentation fault: 11. It should be a meaningful message, not just segv. FreeBSD-72. -- Summary: segmentation fault when class not found from gcj-built executable with indirect dispatch Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: yuri at tsoft dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41361
[Bug c++/41368] New: Erroneous aliasing rules violation messages are issued
When the attached testcase is compiled with gcc-4.4.1 there are two aliasing error messages issued, that appear to be wrong. -- Summary: Erroneous aliasing rules violation messages are issued Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: yuri at tsoft dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41368
[Bug c++/41368] Erroneous aliasing rules violation messages are issued
--- Comment #1 from yuri at tsoft dot com 2009-09-16 05:12 --- Created an attachment (id=18593) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18593action=view) testcase command line: g++ -c -O5 -Wall pr.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41368
[Bug c++/41368] Erroneous aliasing rules violation messages are issued
--- Comment #2 from yuri at tsoft dot com 2009-09-16 05:17 --- gcc-4.3.1 didn't issue such warnings. I wasn't able to minimize the testcase more. Somehow if eee instance of Z is removed and just F::bbb() is called messages disappear. This is strange since code around lines in question is all the same in both cases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41368
[Bug java/41356] New: Circular dependencies between jars cause errors: jars order shouldn't matter
I am trying to compile many jars into one native executable with the following command: /usr/local/gcc/gcc-4.3.1-java/bin/gcj -combine -R /usr/local/gcc/gcc-4.3.1-java/lib --main=com.xxx.MyClass \ /usr/local/share/java/commons-logging-1.1.1.jar \ /usr/local/share/java/avalon-framework-4.2.0.jar \ skipped other jars I am getting this error: org/apache/commons/logging/impl/AvalonLogger.java: In class 'org.apache.commons.logging.impl.AvalonLogger': org/apache/commons/logging/impl/AvalonLogger.java: In constructor '(java.lang.String)': org/apache/commons/logging/impl/AvalonLogger.java:79: error: cannot find file for class org.apache.avalon.framework.logger.Logger If I swap the two first jars I get this error: org/apache/avalon/framework/logger/AbstractLoggable.java: In class 'org.apache.avalon.framework.logger.AbstractLoggable': org/apache/avalon/framework/logger/AbstractLoggable.java: In method 'org.apache.avalon.framework.logger.AbstractLoggable.setupLogger(java.lang.Object,java.lang.String)': org/apache/avalon/framework/logger/AbstractLoggable.java:80: error: cannot find file for class org.apache.log.Logger So either org/apache/avalon/framework can't find org.apache.log or the way around. Even before getting this error I noticed that depending jars should be specified after dependent ones. I believe this is wrong: jars actually can inter-depend on each other and should all be treated equally independent of their order in command line. -- Summary: Circular dependencies between jars cause errors: jars order shouldn't matter Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: yuri at tsoft dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41356
[Bug c++/40560] New: Erroneous aliasing rules message
When I compile the following code with gcc-4.4.0 with -O3 -Wall flags I get
the messages below.
Testcase has 'union' between Z and char types therefore such type conversion
should be allowed by aliasing rules.
--- error message ---
pr.C: In member function Z X::get():
pr.C:12: warning: dereferencing type-punned pointer will break strict-aliasing
rules
--- testcase ---
struct Z {int ii;};
struct X {
union {
Z objs[1];
char bb[20];
};
Z get() {
return (*(Z*)bb[0]); // --- error message here
}
};
--
Summary: Erroneous aliasing rules message
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40560
[Bug c++/40217] New: gcc-4.3.1 fails to produce an error message for out of memory condition
I accidentally ran my FreeBSD-71 system with 3GB RAM without the swap space and
compiled a large module with high degree of optimization.
I was getting this error:
{standard input}: Assembler messages:
{standard input}:68321: Warning: end of file not at end of a line; newline
inserted
{standard input}:69363: Error: undefined symbol `.LLSDACSE3986' in operation
{standard input}:69427: Error: undefined symbol `.LFB398' in operation
g++: Internal error: Killed: 9 (program cc1plus)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html for instructions.
This happened 100% of time, and error message stayed the same.
So gcc was getting memory allocation failure but instead of failing with the
relevant message it was passing wrong assembly to 'as'.
Adding swap cured the situation.
gcc-4.3.3 was failing in a similar way but with a bit different error message.
This should be fixed to make gcc more reliable in the random user environments.
Today by googling the above error messages you can get a lot of references of
similar situations happening to various people.
--
Summary: gcc-4.3.1 fails to produce an error message for out of
memory condition
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40217
[Bug c++/39560] New: Erroneous wanings 'unused variable' in a templetated class method with union
This testcase has warnings:
--- begin testcase ---
struct X { };
class Z {
public:
X* cc(int c);
};
class F {
public:
typedef X* (Z::*MethO)(int);
typedef X* (F::*MethF)(int);
templateMethO m
X* xwrapper(int i) {
union {
Z *z;
F *f;
};
f = this;
return ((z-*m)(i));
}
};
F::MethF meth = F::xwrapperZ::cc;
--- end testcase ---
warnings:
c.C: In member function X* F::xwrapper(int) [with X* (Z::* m)(int) = Z::cc]:
c.C:23: instantiated from here
c.C:17: warning: unused variable z
c.C:17: warning: unused variable f
--
Summary: Erroneous wanings 'unused variable' in a templetated
class method with union
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39560
[Bug c++/39281] New: Error message 'multiple types in one declaration' need to be reworded
Usually this error message is issued when semicolon is missing after the struct/class declaration. Message itself is pretty obscure. It's better to change it: error: multiple types in one declaration, missing semicolon after type declaration? This will give users a clue and will likely eliminate the need to google the error message. -- Summary: Error message 'multiple types in one declaration' need to be reworded Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: yuri at tsoft dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39281
[Bug c++/36483] New: Getting an address of a byte-aligned field declared as a bit-field should be allowed
gcc produces an error for the code below:
bit-field.C:6: error: attempt to take address of bit-field structure member
'S::j'
In this case field j is guaranteed to be byte-aligned.
gcc shouldn't have such a rigid requirement that one can't get an address of
any bit field variable but should allow getting such address when it's actually
possible.
For example I've set bit field attribute (:8) to limit some small enum-typed
field to just 8 bits. And after this I couldn't get it's address as of uint8_t
value.
--- code ---
struct S {
int j:8;
};
char cc(S *s) {
return ((char)s-j);
}
--
Summary: Getting an address of a byte-aligned field declared as a
bit-field should be allowed
Product: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36483
[Bug c++/35876] Exceptions not working on FreeBSD
--- Comment #3 from yuri at tsoft dot com 2008-04-18 23:30 --- Closing it completely -- yuri at tsoft dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35876
[Bug c++/35876] Exceptions not working on FreeBSD
--- Comment #2 from yuri at tsoft dot com 2008-04-18 23:29 --- Problem was because of the mixup of gcc libaries. Executable was built with one compiler and during the run different shared libraries were used. -- yuri at tsoft dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35876
[Bug c++/35876] Exceptions not working on FreeBSD
--- Comment #4 from yuri at tsoft dot com 2008-04-19 01:07 --- Reopening this PR. Same testcase with gcc-4.3.0 on FreeBSD-7.0-STABLE aborts: Abort trap: 6 ldd executable output: libstdc++.so.6 = /usr/local/gcc/4.3.0/lib/libstdc++.so.6 (0x2807d000) libm.so.5 = /lib/libm.so.5 (0x2815a000) libgcc_s.so.1 = /usr/local/gcc/4.3.0/lib/libgcc_s.so.1 (0x2816f000) libc.so.7 = /lib/libc.so.7 (0x2817a000) --- stack trace --- Program received signal SIGABRT, Aborted. 0x28250a67 in kill () from /lib/libc.so.7 (gdb) bt #0 0x28250a67 in kill () from /lib/libc.so.7 #1 0x282509c6 in raise () from /lib/libc.so.7 #2 0x2824f5da in abort () from /lib/libc.so.7 #3 0x281759d6 in uw_init_context_1 (context=0xbfbfe5c4, outer_cfa=0xbfbfe660, outer_ra=0x28127fe8) at ../../../src/libgcc/../gcc/unwind-dw2.c:1249 #4 0x28175f3e in _Unwind_RaiseException (exc=0x81030b0) at ../../../src/libgcc/../gcc/unwind.inc:93 #5 0x28127fe8 in __cxa_throw (obj=0x81030d0, tinfo=0x8048da0, dest=0x80488ac [EMAIL PROTECTED]) at ../../../../src/libstdc++-v3/libsupc++/eh_throw.cc:71 #6 0x08048bcc in main () at exc-2.C:7 (gdb) in ../../../src/libgcc/../gcc/unwind-dw2.c -- yuri at tsoft dot com changed: What|Removed |Added Status|VERIFIED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35876
[Bug c++/35876] Exceptions not working on FreeBSD
--- Comment #5 from yuri at tsoft dot com 2008-04-19 01:09 --- The only broken version is 4.3.0, all 4.2.X throw exceptions ok. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35876
[Bug c++/35949] New: 'const' attribute applied to typedefed type in methods's return is ignored
In the following code 'const VR' in declaration of the return value of 'kk'
works as just 'VR', without constness.
In arguments 'const VR' is applied as const.
code example
typedef int X;
struct S {
typedef X VR; // --- VR is declared as X by-reference
X x;
// uncomment one of these two lines:
const VR kk(VR) const { return (x); } // --- bug: first 'const' is
ignored and function is defined as returning *not* const causing compiler error
message
// const X kk(VR) const { return (x); } // --- ok: function is defined as
returning const by-reference
};
void f() {
typedef S::VR VR;
const X (S::*fn)(VR) const; // ---: ask for the function returning
by-reference
fn = S::kk; // --- error message here
}
--
Summary: 'const' attribute applied to typedefed type in methods's
return is ignored
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35949
[Bug c++/35876] Exceptions not working on FreeBSD
--- Comment #1 from yuri at tsoft dot com 2008-04-09 18:06 --- After further investigation it appears to be some issue with exceptions in FreeBSD-STABLE-7.0 system g++ compiler. Exceptions don't work on FreeBSD with system compiler at all. System compiler is a version of gcc-4.2.1 tweaked by FreeBSD folks in some way so let's leave it alone. But gcc-4.3.0 was freshly compiled by me. And with gcc-4.3.0 exceptions only work when -pthread flag is set (on FreeBSD only). Without -pthread flag gcc-4.3.0 has a problem with exceptions (using it's own gcc-4.3.0 shared libraries). Error is: Abort trap: 6 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35876
[Bug c++/35876] New: Exceptions not working on FreeBSD
Basic exception example:
#include iostream
#include string
using namespace std;
int main() {
try {
throw string(String);
} catch (string s) {
cout Caught an exception \ s \\n;
}
}
Compiled with:
g++ -fexceptions -Wall -o exception exception.cpp
Prints:
terminate called after throwing an instance of 'std::string'
Should print:
Caught an exception String
Exception is never caught.
--
Summary: Exceptions not working on FreeBSD
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35876
[Bug c/35776] New: Simple loop isn't optimized well
I have a C code:
void f();
void i(unsigned n) {
while (n-- 0) {
f();
}
}
Which when compiled with -O3 on i586 produces the assembly:
i:
pushl %ebp
movl%esp, %ebp
pushl %esi
movl8(%ebp), %esi
pushl %ebx
testl %esi, %esi
je .L5
xorl%ebx, %ebx
.p2align 4,,7
.L4:
addl$1, %ebx
callf
cmpl%esi, %ebx
jne .L4
.L5:
popl%ebx
popl%esi
popl%ebp
ret
And obviously shorter assembly with one less instruction in the loop is:
i:
pushl %ebp
movl%esp, %ebp
pushl %esi
movl8(%ebp), %esi
testl %esi, %esi
je .L5
.p2align 4,,7
.L4:
callf
dec %esi
jl .L4
.L5:
popl%esi
popl%ebp
ret
This is a very short and basic loop occurring in programs many times.
That's why this should be optimized very well.
--
Summary: Simple loop isn't optimized well
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35776
[Bug c/35694] New: Error about bad function argument isn't issued on the line of the argument but on the line where function ends
int i(int j, int *k);
void f() {
i(
0,
1 /*--- here the error should be issued*/
); /*--- here the error is issued*/
}
--
Summary: Error about bad function argument isn't issued on the
line of the argument but on the line where function ends
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35694
[Bug c++/35578] New: Error about misplaced 'friend' word is issued on a wrong line
When I compile the code below I get:
x.C:3: error: 'friend' used outside of class
And 'friend' word is on the line #5.
=== code begins ===
int i() {
return (0);
} /*here an error is reported*/
friend void x() {
}
--
Summary: Error about misplaced 'friend' word is issued on a wrong
line
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35578
[Bug c++/35275] New: Operator for embedded class of templetized class isn't found
The following code produces an error on the second line inside of main:
error: no match for 'operator' in 'std::cout Cint::E()'
C++ frontend fails to find the templetized operator.
-- begin code
#include iostream
using namespace std;
templatetypename T
struct C {
struct E {
};
};
templatetypename T
ostream operator(ostream ss, const CT t) {
return (ss);
}
templatetypename T
ostream operator(ostream ss, const typename CT::E t) {
return (ss);
}
main() {
cout Cint(); // this compiles ok
cout Cint::E(); // this fails
}
--
Summary: Operator for embedded class of templetized class isn't
found
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35275
[Bug c++/33805] New: Static member of the class should be able to depend on classes size
I got this error and this made me thinking.
First example produces an error:
m.C:2: error: invalid application of 'sizeof' to incomplete type 'B'
But the second one doesn't.
Why if I take sizeof() of the current class when instantiating the object it's
an error and if I pass the type to the class A as a template parameter this
isn't an error. And class A can do with it's template parameter all it wants
and this is ok.
I think first example should compile w/out errors since static object doesn't
even change the size of B, so it shouldn't matter what it is.
this code produces an error
templateint i struct A { };
struct B { static Asizeof(B) a; };
this code compiles w/out errors
templatetypename O struct A { };
struct B { static AB a; };
--
Summary: Static member of the class should be able to depend on
classes size
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33805
[Bug c++/33475] New warning suggestion: virtual functions called from constructors/destructors
--- Comment #5 from yuri at tsoft dot com 2007-09-19 23:37 --- I would like to note that this isn't a clear-cut suggestion for the following reasons: * It's impossible to enforce such warning in all cases, only in case of virtual functions immediately called from constructor/destructor. * People often use virtual functions from destructors to uninitialize things. And in many cases it's semi-safe. But it's almost always wrong to call virtual functions from constructors. * It probably makes sense to add such warning to Valgrind as well to issue it based on the run-time analysis But still such warning in gcc can prevent many errors waiting to happen from happening. gcc must do as much as possible preventing dangerous coding patterns. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33475
[Bug c++/33475] New: New warning suggestion: virtual functions called from constructors/destructors
I would like to suggest that gcc issues a warning (with -Wall) when any virtual functions are called from constructors and destructors of these objects. During construtors and destructors derived objects aren't complete and almost always virtual functions would be called on undefined derived classes. -- Summary: New warning suggestion: virtual functions called from constructors/destructors Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: yuri at tsoft dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33475
[Bug c++/33476] New: New warning suggestion: virtual functions called from constructors/destructors
I would like to suggest that gcc issues a warning (with -Wall) when any virtual functions are called from constructors and destructors of these objects. During construtors and destructors derived objects aren't complete and almost always virtual functions would be called on undefined derived classes. -- Summary: New warning suggestion: virtual functions called from constructors/destructors Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: yuri at tsoft dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33476
[Bug c++/33477] New: New warning suggestion: virtual functions called from constructors/destructors
I would like to suggest that gcc issues a warning (with -Wall) when any virtual functions are called from constructors and destructors of these objects. During construtors and destructors derived objects aren't complete and almost always virtual functions would be called on undefined derived classes. -- Summary: New warning suggestion: virtual functions called from constructors/destructors Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: yuri at tsoft dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33477
[Bug c++/33478] New: New warning suggestion: virtual functions called from constructors/destructors
I would like to suggest that gcc issues a warning (with -Wall) when any virtual functions are called from constructors and destructors of these objects. During construtors and destructors derived objects aren't complete and almost always virtual functions would be called on undefined derived classes. -- Summary: New warning suggestion: virtual functions called from constructors/destructors Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: yuri at tsoft dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33478
[Bug c++/33481] New: New warning suggestion: virtual functions called from constructors/destructors
I would like to suggest that gcc issues a warning (with -Wall) when any virtual functions are called from constructors and destructors of these objects. During construtors and destructors derived objects aren't complete and almost always virtual functions would be called on undefined derived classes. -- Summary: New warning suggestion: virtual functions called from constructors/destructors Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: yuri at tsoft dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33481
[Bug c++/33480] New: New warning suggestion: virtual functions called from constructors/destructors
I would like to suggest that gcc issues a warning (with -Wall) when any virtual functions are called from constructors and destructors of these objects. During construtors and destructors derived objects aren't complete and almost always virtual functions would be called on undefined derived classes. -- Summary: New warning suggestion: virtual functions called from constructors/destructors Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: yuri at tsoft dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33480
[Bug c++/33483] New: New warning suggestion (for -Wall): sizeof() with non-lvalue has side effects that will not execute at runtime
#include iostream
using namespace std;
Here is a very dangerous situation that compiler can catch illustrated by the
following example: when sizeof has non-lvalue argument.
--- example ---
int f() {
cout I am f endl;
return 5;
}
int main() {
cout sizeof= sizeof(f()) endl; // HERE THE WARNING SHOULD BE
ISSUED
return (0);
}
--
Summary: New warning suggestion (for -Wall): sizeof() with non-
lvalue has side effects that will not execute at runtime
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33483
[Bug c++/33483] New warning suggestion (for -Wall): sizeof() with non-lvalue has side effects that will not execute at runtime
--- Comment #2 from yuri at tsoft dot com 2007-09-18 22:58 --- Warning should be issued in this case as well. Since this isn't an expected behavior to ignore n++. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33483
[Bug c++/31802] New: SSE2 performance is deteriorating when __m128 is placed in union
When I compile the following testcase with '-O3 -msse3' options it runs in
22.562sec, without 'union' clause it runs in 0.280sec. And should be the same
time.
-- begin testcase --
typedef float __v2df __attribute__ ((__vector_size__ (16)));
typedef __v2df __m128;
static __inline __m128 _mm_sub_pd (__m128 __A, __m128 __B) { return
(__m128)__builtin_ia32_subps ((__v2df)__A, (__v2df)__B); }
static __inline __m128 _mm_add_pd (__m128 __A, __m128 __B) { return
(__m128)__builtin_ia32_addps ((__v2df)__A, (__v2df)__B); }
static __inline __m128 _mm_setr_ps (float __Z, float __Y, float __X, float __W)
{ return __extension__ (__m128)(__v2df){ __Z, __Y, __X, __W }; }
struct FF {
union {__m128 d; float f[4];}; // problem
// __m128 d; // no problem
__inline FF() { }
__inline FF(__m128 new_d) : d(new_d) { }
__inline FF(float f) : d(_mm_setr_ps(f, f, f, f)) { }
__inline FF operator+(FF other) { return (FF(_mm_add_pd(d,other.d))); }
__inline FF operator-(FF other) { return (FF(_mm_sub_pd(d,other.d))); }
};
float f[1024*1024];
int main() {
int i;
for (i = 0; i 1024*1024; i++) { f[i] = 1.f/(1024*1024 + 10 - i); }
FF total(0.f);
for (int rpt = 0; rpt 1000; rpt++) {
FF p1(0.f), p2(0.), c;
__m128 *pf = (__m128*)f;
for (i = 0; i 1024*1024/4; i++) {
FF c(*pf++);
total = total + c - p2 + p1;
p1 = p2;
p2 = c;
}
}
}
-- end testcase
This bug has similar testcase as 25500 (that's fixed now). Only 'union' clause
was added.
Yuri
--
Summary: SSE2 performance is deteriorating when __m128 is placed
in union
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31802
[Bug c++/17332] [3.4 Regression] Missed inline opportunity
--- Comment #5 from yuri at tsoft dot com 2006-02-28 09:53 --- So there should be no performance-related bugs reported any more since you only care about correctness? This IS a performance-related problem in gcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17332
[Bug c++/25986] New: return from funcrtion of void value allowed
The following code is meaningless therefore should produce the WARNING.
At least would be useful to have some pedantic warning mode when this should
produce warning.
Yuri
---testcase--
void a() { }
void f() {
return a();
}
--
Summary: return from funcrtion of void value allowed
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25986
[Bug c++/25986] return from funcrtion of void value allowed
--- Comment #2 from yuri at tsoft dot com 2006-01-27 00:02 ---
This functionality was *added* on
purpose to allow generic codes to be written seamlessly
Sure!
Then code void f() { void x; retrun (x); } should work. But it produces:
t.C: In function `void f()':
t.C:2: variable or field `x' declared void
t.C:2: return-statement with a value, in function declared with a void return
type
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25986
[Bug c++/25986] return from funcrtion of void value allowed
--- Comment #4 from yuri at tsoft dot com 2006-01-27 00:44 --- For templates it's sufficient to treat void as type in template specializations. No need to further change language. Especially because generic programming doesn't really scale much beyond it's 'local' use like in STL. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25986
[Bug c++/25986] return from funcrtion of void value allowed
--- Comment #8 from yuri at tsoft dot com 2006-01-27 03:09 --- Let's close this PR as we do not have place for trolls. I am basing my opinion on the very practical experience w/out any intent of trolling. You either provide an example of wide-range successful GP use or take back your words. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25986
