--- 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
--- 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
--- 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 output:
libstdc++.so.6 => /usr/local/gcc/4.3.0/lib/libstdc++.so.6 (0x2807d000)
libm.so.5 => /lib/lib
--- 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
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
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
--- 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()'
--- 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
'lo
--- 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 b
--- Comment #10 from yuri at tsoft dot com 2006-01-27 03:19 ---
I never advocated C. I only noted that language was unreasonably changed to
simplify few GP tricks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25986
--- 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
temlated class
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
CC: gcc-bugs at gcc dot g
4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.c
s'es method is ignored
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
CC: gcc-bugs at
--- Additional Comments From yuri at tsoft dot com 2005-05-17 17:38 ---
(In reply to comment #1)
> Hmm, I think we get an error mark node but no error.
Why is this the wrong code? It's easy to execute it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21614
When some object having empty destructor is declared as static in the local
context of some function g++ still inserts call with the empty handler
like <__tcf_0> below.
It may seem like minor issue but redundant instructions increase chances for
I-cache misses and worthen processor pipeline.
Yur
--- Additional Comments From yuri at tsoft dot com 2005-01-28 01:26 ---
(In reply to comment #1)
> Confirmed, although I consider this to be a rather minor point since
> the code is actually run only once. Here's a small test:
I agree, but it bloats the code, therefo
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19662
--- Additional Comments From yuri at tsoft dot com 2005-01-28 20:54 ---
> If your objects are simple and do not need destruction, just don't
> define destructors.
>
> -- Gaby
Disagree, it may only be determined after the optimization that destructor is
actuall empty.
ranch comparison code produced
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot co
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
CC: gcc-bugs at gcc dot gnu dot org
http:
--- Additional Comments From yuri at tsoft dot com 2005-01-31 06:16 ---
Ooops, sorry, should be 2 instructions instead of 7 (3.5X inefficiency)
should be
pushl %ebp
movl%esp, %ebp
>movl8(%ebp), %eax
>andl12(%ebp), %eax
.p
gnu dot org
ReportedBy: yuri at tsoft dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19726
--- Additional Comments From yuri at tsoft dot com 2005-01-31 22:02 ---
actually I want to generalize it:
any situation in C++/C/Ada when many enough close (in memory) variables are
assigned the same value should use bulk "stos(b/w/l)". This should be applied as
part of op
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19748
--- Additional Comments From yuri at tsoft dot com 2005-02-02 02:07 ---
(In reply to comment #2)
> Also note sometimes when a function is pure/const it can be removed which is
why it might act as
> inlining.
>
> Do you have a simple example?
> ...
> Also note sometim
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19943
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19947
: 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
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?
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.
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)
>
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.
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
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&q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110746
--- Comment #1 from Yuri ---
OS: FreeBSD 13.2
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
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=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110746
--- Comment #7 from Yuri ---
gcc-13 has the same problem.
ts 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:
oduct: 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 occur
101 - 141 of 141 matches
Mail list logo
