<$rstr7-19b>
<$rstr7-19b>
Re: Build Error: Today's CVS; Solaris sparc 2.7
On Mon, 6 May 2002, mckelvey wrote: > setenv CC gcc ; /mnt/home3/utilities/gcc/configure > --prefix=/mnt/home3/utilities --verbose --enable-languages=c++ Thanks. Do you by any chance have GNU binutils installed in this prefix? If so, can you run the configure again and add: --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld If that fixes it, you've encountered a known problem (documented in /install/specific.html IIRC). If not, we'll have to investigate. JEff
[Bug libstdc++/35569] [c++0x] std::bind result functor doesn't accept rvalues
--- Comment #2 from jeff at schwabcenter dot com 2009-01-14 19:20 ---
I'm seeing the same thing with Boost.Bind (boost 1.37, GCC 4.2.1).
#include
#include
using boost::bind;
using std::multiplies;
int main() {
// Fine.
int const lvalue = 5;
bind(multiplies(),4,_1)(lvalue);
// Mistaken for a cast.
bind(multiplies(),4,_1)(5);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35569
[Bug c++/40192] [4.4/4.5 Regression] Unable to use std::vector with typedef'd array types
--- Comment #5 from jeff at schwabcenter dot com 2009-05-19 16:36 --- Whoa whoa whoa... The behavior seemed correct before. vector shouldn't even be legal. Shouldn't the compiler to catch such a mistake? -- jeff at schwabcenter dot com changed: What|Removed |Added CC| |jeff at schwabcenter dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40192
[Bug c++/40192] [4.4/4.5 Regression] Unable to use std::vector with typedef'd array types
--- Comment #7 from jeff at schwabcenter dot com 2009-05-19 17:09 --- I understand the desire for backward compatibility, but are the semantics actually the same? Are the vector values arrays, or do they decay to pointers? Section 23.1 says standard container elements have to be CopyConstructible and assignable, but raw arrays are neither. Is there at least some flag to re-enable the diagnostic? If you're saying this is a necessary evil for reasons of backward compatibility, then I understand, but in my opinion, this is a step backward that will confuse newcomers like Brian and hurt cross-compatibility. Speaking strictly as a GCC user, I don't see any reason to reduce the compiler's ability to deduce an obvious mistake with ill-defined semantics. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40192
[Bug c++/40192] [4.4/4.5 Regression] Unable to use std::vector with typedef'd array types
--- Comment #9 from jeff at schwabcenter dot com 2009-05-19 17:32 --- OK. Thanks for the explanation. Are the semantics documented somewhere? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40192
[Bug c++/40192] [4.4/4.5 Regression] Unable to use std::vector with typedef'd array types
--- Comment #12 from jeff at schwabcenter dot com 2009-05-19 18:07 --- What he said. I'm perusing your patch, and I appreciate that you removed an artificial restriction. The right place to catch this is up front, in a concept check, rather than in _Destroy; since I'm not about to add the check myself, I'm hardly in a position to criticize. The diagnostic did have the nice property of catching a real, semantic error, though, and it seems a shame to let a known error go unreported. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40192
[Bug ada/25573] New: Incorrect result returning constrained subtype (slice) with non-trivial return expression
The library PNG_IO fails during elaboration while performing some sanity checks
on its internal functions.
This was created on i386-redhat-linux-gnu (Centos 4)
I have boiled this down to a pretty simple test case that looks like the issue
happens when a function is returning a constrained subtype of an unconstrained
array and it is doing so when building the return value from an expression.
The following code should print abcd. Instead, it prints several garbage
characters.
with Text_IO;
with Interfaces; use Interfaces;
procedure Slice_Bug is
subtype Slice_Type is String(1 .. 4);
function identity(A : in Character) return Character is
begin
return a;
end identity;
function Get_Slice return Slice_Type is
begin
return identity('a') & identity('b') & identity('c') & identity('d');
end Get_Slice;
begin
Text_IO.Put_Line(Get_Slice);
end Slice_Bug;
Removing the constraint from the subtype makes this code work as expected.
Leaving the constraint in and doing a simple return "abcd" also works.
--
Summary: Incorrect result returning constrained subtype (slice)
with non-trivial return expression
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jeff at thecreems dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25573
[Bug ada/26306] Use of volatile array with bounds determined at run time.
--- Comment #4 from jeff at thecreems dot com 2006-10-20 16:56 --- I just did a fresh Gcc build today this no longer appears to be a problem URL: svn://gcc.gnu.org/svn/gcc/trunk Repository Root: svn://gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 117904 Node Kind: directory Schedule: normal Last Changed Author: fxcoudert Last Changed Rev: 117904 Last Changed Date: 2006-10-20 07:52:56 -0400 (Fri, 20 Oct 2006) Properties Last Updated: 2006-10-20 09:33:34 -0400 (Fri, 20 Oct 2006) [EMAIL PROTECTED] mat_test]$ gcc -c scratch.adb [EMAIL PROTECTED] mat_test]$ gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc/configure --disable-checking --enable-languages=c,fortran,ada --prefix=/home/jcreem/local Thread model: posix gcc version 4.2.0 20061020 (experimental) -- jeff at thecreems dot com changed: What|Removed |Added CC||jeff at thecreems dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26306
[Bug ada/24726] Gigi abort, Code=508
--- Comment #4 from jeff at thecreems dot com 2006-10-20 17:01 --- Seems fixed in trunk Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc/configure --disable-checking --enable-languages=c,fortran,ada --prefix=/home/jcreem/local Thread model: posix gcc version 4.2.0 20061020 (experimental) [EMAIL PROTECTED] bg]$ gcc -c elements-sets.adb [EMAIL PROTECTED] bg]$ -- jeff at thecreems dot com changed: What|Removed |Added CC||jeff at thecreems dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24726
[Bug ada/24079] Ada FE ICE on protected procedure with default argument (invalid?)
--- Comment #2 from jeff at thecreems dot com 2006-10-20 17:03 --- Still there in head gcc -c bug.adb +===GNAT BUG DETECTED==+ | 4.2.0 20061020 (experimental) (i686-pc-linux-gnu) Assert_Failure atree.adb:812 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24079
[Bug ada/29533] New: Ada fails to vectorize even trivial loops
While there might exist a case that can be vectorized, a few of the simple cases that should be easy that I have tried are not able to be vectorized. For example, the following package compare_lang is type the_range is range 0 .. 100; type My_Array is array (the_range) of Float; a, b, c : my_array; procedure do_compare; end compare_lang; package body compare_lang is procedure do_compare is begin for JJJ in the_range loop a(jjj) := b(jjj) * c(jjj); end loop; end do_compare; end compare_lang; gcc -c -O3 -gnatp -march=pentium4 -mfpmath=sse -msse3 -ftree-vectorize -ftree-vectorizer-verbose=5 compare_lang.adb compare_lang.adb:5: note: not vectorized: complicated access pattern. compare_lang.adb:3: note: vectorized 0 loops in function. Obviously similar structures C vectorize fine. -- Summary: Ada fails to vectorize even trivial loops Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jeff at thecreems dot com GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29533
[Bug bootstrap/32272] make exit because build/genmodes.exe doesn't exist
--- Comment #5 from jeff at jeffunit dot com 2007-09-28 01:37 --- I am using gnu make-3.81 I just verified that the problem is still present. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32272
[Bug bootstrap/37061] New: Build fails with REGISTER_TARGET_PRAGMAS redefined
I'm compiling gcc snapshot 20080801 on a Solaris 2.10 (amd64) machine with host tools from binutils 2.18 and gcc 4.3. I've configured with: ../gcc-4.4-20080801/configure --disable-static --enable-shared --prefix=/home/huron/jeffga/sfw/gcc-4.4 --with-gmp=/home/huron/jeffga/sfw/gcc-4.4 --with-mpfr=/home/huron/jeffga/sfw/gcc-4.4 --with-gnu-as --with-gnu-ld But make fails with: [... snipped ..] /home/huron/jeffga/src/obj/./prev-gcc/xgcc -B/home/huron/jeffga/src/obj/./prev-gcc/ -B/home/huron/jeffga/sfw/gcc-4.4/i386-pc-solaris2.10/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc-4.4-20080801/gcc -I../../gcc-4.4-20080801/gcc/build -I../../gcc-4.4-20080801/gcc/../include -I./../intl -I../../gcc-4.4-20080801/gcc/../libcpp/include -I/home/huron/jeffga/sfw/gcc-4.4/include -I/home/huron/jeffga/sfw/gcc-4.4/include -I../../gcc-4.4-20080801/gcc/../libdecnumber -I../../gcc-4.4-20080801/gcc/../libdecnumber/dpd -I../libdecnumber -o build/genconstants.o ../../gcc-4.4-20080801/gcc/genconstants.c In file included from ./tm.h:19, from ../../gcc-4.4-20080801/gcc/genconstants.c:31: ../../gcc-4.4-20080801/gcc/config/sol2.h:237:1: error: "REGISTER_TARGET_PRAGMAS" redefined In file included from ./tm.h:12, from ../../gcc-4.4-20080801/gcc/genconstants.c:31: ../../gcc-4.4-20080801/gcc/config/i386/i386.h:542:1: error: this is the location of the previous definition make[3]: *** [build/genconstants.o] Error 1 make[3]: Leaving directory `/home/huron/jeffga/src/obj/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/home/huron/jeffga/src/obj' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/home/huron/jeffga/src/obj' make: *** [all] Error 2 The same REGISTER_TARGET_PRAGMAS redefined warning also showed up repeatedly in the earlier compilation but as that all happened without -Werror, it continued. Line 237 of gcc/config/sol2.h in the source does have: #define REGISTER_TARGET_PRAGMAS() solaris_register_pragmas () Line 542 of gcc/config/i386/i386.h has: #define REGISTER_TARGET_PRAGMAS() ix86_register_pragmas () The same configure command, with the same tools, will build gcc 4.3.1 without issue. -- Summary: Build fails with REGISTER_TARGET_PRAGMAS redefined Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jeff at jgarrett dot org GCC host triplet: i386-pc-solaris2.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37061
[Bug debug/35502] New: -Wall should include -Wswitch-default
The g++ man page says -Wall is equivalent to "All of the above -W
options combined." The -Wswitch-default option should therefore be included in
-Wall, but currently is not.
The correct solution IMO is to add -Wswitch-default to -Wall in c-opts.c.
Please see the attached patch.
Script started on Fri Mar 7 12:16:38 2008
~$ g++ -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --enable-languages=c++
--prefix=/export/home/jeff/opt/gcc
Thread model: posix
gcc version 4.2.4 20080214 (prerelease)
~$ g++ -Wall -Wswitch-default main.cc
main.cc: In function 'int main(int, char**)':
main.cc:1: warning: switch missing default case
~$ g++ -Wall main.cc -save-temps
~$ cat main.ii
# 1 "main.cc"
# 1 ""
# 1 ""
# 1 "main.cc"
int main(int argc, char** argv) { switch (argc) { } }
Script done on Fri Mar 7 12:17:25 2008
--
Summary: -Wall should include -Wswitch-default
Product: gcc
Version: 4.2.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jeff at schwabcenter dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35502
[Bug debug/35502] -Wall should include -Wswitch-default
--- Comment #1 from jeff at schwabcenter dot com 2008-03-07 23:21 --- Created an attachment (id=15277) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15277&action=view) Preprocessed sample code Compiling the attached file with g++ -Wall should produce "warning: switch missing default case". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35502
[Bug debug/35502] -Wall should include -Wswitch-default
--- Comment #2 from jeff at schwabcenter dot com 2008-03-07 23:24 --- Created an attachment (id=15278) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15278&action=view) Fix for this bug Setting warn_switch_default = value in the OPT_Wall case of c_common_handle_option (in gcc/c-opts.c) fixes the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35502
[Bug debug/35502] -Wall should include -Wswitch-default
--- Comment #5 from jeff at schwabcenter dot com 2008-03-07 23:38 --- Thanks for the quick response and the links. FYI, the latter link seems to be broken: http://archives.free.net.ph/message/20071001.204624.0ca57fae.de.html Is there any particular reason for changing the docs, rather than the code? Include Wswitch-default in Wall is intuitive to me, and avoiding the warning is straight-forward (if not trivial). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35502
[Bug debug/35502] -Wall should include -Wswitch-default
--- Comment #6 from jeff at schwabcenter dot com 2008-03-07 23:42 --- > Is there any particular reason for changing the docs, rather than the code? Kindly disregard that question. I have just been informed by a co-worker that some of our third-party library headers include switch statements without default cases, so adding -Wswitch-default to -Wall would make our lives more difficult, anyway. :( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35502
[Bug debug/35502] -Wall should include -Wswitch-default
--- Comment #7 from jeff at schwabcenter dot com 2008-03-07 23:43 --- http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html does not list -Wswitch-default being enabled by -Wall. -- jeff at schwabcenter dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35502
[Bug debug/87308] New: pretty printer for std::any fails with: Python Exception Unknown manager function in std::any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87308
Bug ID: 87308
Summary: pretty printer for std::any fails with: Python
Exception Unknown
manager function in std::any
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: jeff at jgarrett dot org
Target Milestone: ---
Using g++-8.1 and gdb-8.2 both built from source on a CentOS 7.3 host, pretty
printing a std::any fails with an exception for unknown manager function.
$ gdb ./erased-lambda
GNU gdb (GDB) 8.2
(gdb) run
Starting program: .../erased-lambda
Program received signal SIGILL, Illegal instruction.
main () at erased-lambda.cpp:6
6 __builtin_trap();
(gdb) print a1
$1 = Python Exception Unknown manager
function in std::any:
Python Exception Unknown manager function in
std::any:
{
_M_manager = 0x4007b2
>::_S_manage(std::any::_Op, const std::any *, std::any::_Arg *)>, _M_storage =
{_M_ptr = 0x1, _M_buffer = {__data = "\001\000\000\000\000\000\000",
__align = {
It would appear that the printer attempts to match the manager function name
with the following regex:
rx = r"""({0}::_Manager_\w+<.*>)::_S_manage\({0}::_Op, {0} const\*,
{0}::_Arg\*\)""".format(typename)
Note that the second argument as printed by my gdb is 'const std::any *' versus
the regex 'std::any const*' (east vs west const and space before *) and the
third argument as printed by gdb is 'std::any::_Arg *' versus the regex
'std::any::_Arg*' (space before *). Applying the following patch "fixed" the
regex for my particular set of versions:
--- a/printers.py
+++ b/printers.py
@@ -1040,7 +1040,7 @@ class StdExpAnyPrinter(SingleObjContainerPrinter):
func =
gdb.block_for_pc(int(mgr.cast(gdb.lookup_type('intptr_t'
if not func:
raise ValueError("Invalid function pointer in %s" %
self.typename)
-rx = r"""({0}::_Manager_\w+<.*>)::_S_manage\({0}::_Op, {0}
const\*, {0}::_Arg\*\)""".format(typename)
+rx = r"""({0}::_Manager_\w+<.*>)::_S_manage\({0}::_Op, const
{0} \*, {0}::_Arg \*\)""".format(typename)
m = re.match(rx, func.function.name)
if not m:
raise ValueError("Unknown manager function in %s" %
self.typename)
However, even with that applied, pretty printing a lambda prints the wrong type
due to a bad type lookup:
(gdb) print a1
$1 = std::any containing = {[contained value] = {__j = 1, __k =
0}}
(gdb) print a2
$2 = std::any containing = {[contained value] = {__j = 2, __k =
3}}
Note that both a1 and a2 are interpreted as holding type main::{lambda()#2},
but a1 actually holds main::{lambda()#1}.
GCC version:
$ g++-8.1 -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-8.1.0/bin/g++-8.1
COLLECT_LTO_WRAPPER=/usr/local/gcc-8.1.0/libexec/gcc/x86_64-pc-linux-gnu/8.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-8.1.0/configure --program-suffix=-8.1
--prefix=/usr/local/gcc-8.1.0 --disable-multilib --enable-gold --enable-ld
--enable-lto
Thread model: posix
gcc version 8.1.0 (GCC)
Please let me know if I can provide anything else to help.
== erased-lambda.cpp ==
// g++-8.1 -g -std=c++17 erased-lambda.cpp -o erased-lambda
#include
int main() {
std::any a1 = [i=1] {};
std::any a2 = [j=2,k=3] {};
__builtin_trap();
}
[Bug libstdc++/87308] pretty printer for std::any fails with: Python Exception Unknown manager function in std::any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87308
--- Comment #3 from Jeff Garrett ---
That's such a good point about the local types in general.
Considering that the gdb python API seems to prefer readable names, e.g. for
lookup, and those are not standard nor unique, might it be perhaps preferable
to avoid going through the regex to get the manager type, and from that the
contained type? Something like this?
mgr = self.val['_M_manager']
if mgr != 0:
# cast to uintptr_t doesn't seem to be necessary
func = gdb.block_for_pc(long(mgr))
if not func:
raise ValueError("Invalid function pointer in %s" %
self.typename)
self.contained_type = gdb.lookup_symbol('_Tp', func)[0].type
valptr = None
mgrfuncname = func.function.name
if
mgrfuncname.startswith('{0}::_Manager_internal'.format(self.typename)):
valptr = self.val['_M_storage']['_M_buffer'].address
elif
mgrfuncname.startswith('{0}::_Manager_external'.format(self.typename)):
valptr = self.val['_M_storage']['_M_ptr']
else:
raise ValueError("Unknown manager function in %s" %
self.typename)
contained_value =
valptr.cast(self.contained_type.pointer()).dereference()
We can lookup the symbol for the formal template parameter of the manager by
its name ('_Tp') in the context of the block for the _S_manage function. I'm
not an expert in any of this, so there may be a reason this is not preferable.
It does seem to work with some fundamental types and std::string as well (with
no magic to handle the typedef).
It still fails in the multiple local lambdas case... But that seems like an
easier to solve problem, because I believe the DWARF debugging has enough
information to know which lambda is _Tp in each of the instantiations, and gdb
is just getting confused. I think it should work in principle.
[Bug c/23909] New: Incorrect code generated for SSE2 based xor routine when compiled with -O2 -fomit-frame-pointer
We use some optimized XOR routines for software RAID. Unfortunately, the
compiler generated incorrect code when this was compiled for Redhat 7.3 +
2.4.24 (this is normally kernel code). I later found out that all versions of
gcc that I tested (up to FC4 - 4.0.0 20050519 (Red Hat 4.0.0-8)) had this
issue.
gcc -v on RH 7.3:
build-lin3> gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 2731 (Red Hat Linux 7.3 2.96-110)
build-lin3> uname -a
Linux build-lin3 2.4.21-kdb #2 SMP Tue Apr 6 12:52:57 EDT 2004 i686 unknown
I've also tested on gcc 4.0.0:
rack-lin9$ gcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --
infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-
checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-
exceptions --enable-libgcj-multifile --enable-
languages=c,c++,objc,java,f95,ada --enable-java-awt=gtk --with-java-
home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --host=i386-redhat-linux
Thread model: posix
gcc version 4.0.0 20050519 (Red Hat 4.0.0-8)
rack-lin9$ uname -a
Linux rack-lin9 2.6.11-1.1369_FC4smp #1 SMP Thu Jun 2 23:08:39 EDT 2005 i686
i686 i386 GNU/Linux
Compile command line when test fails:
gcc -o xor_fail -fomit-frame-pointer -O2 xor.c
Compile command line when test PASSES:
gcc -o xor xor.c
I'll attach the test program to the bug.
The generated code runs into problems in the loop:
/* now perform the xor across a stride */
for (offset = stride; offset < maxoffs; offset += 32) {
/* load first strip unit */
__asm__ __volatile__(
"add %1, %0\n"
"movaps 0(%0), %%xmm0\n"
"movaps 16(%0), %%xmm1\n"
: : "r" (bptr[0]), "r" (offset));
/* now xor the next N-1 strip units */
for (j = 1; j < num_of_buffers; j++){
__asm__ __volatile__(
"add%1, %0\n"
"xorps 0(%0), %%xmm0\n"
"xorps 16(%0), %%xmm1\n"
: : "r" (bptr[j]), "r" (offset) );
}
/* now write out the result */
__asm__ __volatile__(
"add %1, %0\n"
"movntps %%xmm0, 0(%0)\n"
"movntps %%xmm1, 16(%0)\n"
: : "r" (dest), "r" (offset) );
}
Specifically, in first loading the data:
__asm__ __volatile__(
"add %1, %0\n"
"movaps 0(%0), %%xmm0\n"
"movaps 16(%0), %%xmm1\n"
: : "r" (bptr[0]), "r" (offset));
We end up referencing memory off the end of the array bptr[0]. This is
because the loop doesn't initialize %ebx and %ebx ends up being too large to
access this array. The loop jumps to .L261, but .L261 is below movl (%ebp), %
ebx.
movl(%ebp), %ebx
.p2align 2
.L261:
.stabn 68,0,168,.LM68-sse_multi_xor_gen
.LM68:
#APP
add %edx, %ebx
movaps 0(%ebx), %xmm0
movaps 16(%ebx), %xmm1
.stabn 68,0,175,.LM69-sse_multi_xor_gen
.LM69:
#NO_APP
movl$1, %ecx
cmpl%edi, %ecx
jge .L273
.p2align 2
.L265:
.stabn 68,0,176,.LM70-sse_multi_xor_gen
.LM70:
movl(%ebp,%ecx,4), %eax
#APP
add%edx, %eax
xorps 0(%eax), %xmm0
xorps 16(%eax), %xmm1
.stabn 68,0,175,.LM71-sse_multi_xor_gen
.LM71:
#NO_APP
incl%ecx
cmpl%edi, %ecx
jl .L265
.L273:
.stabn 68,0,183,.LM72-sse_multi_xor_gen
.LM72:
movl88(%esp), %eax
#APP
add %edx, %eax
movntps %xmm0, 0(%eax)
movntps %xmm1, 16(%eax)
.stabn 68,0,166,.LM73-sse_multi_xor_gen
.LM73:
#NO_APP
addl$32, %edx
cmpl%esi, %edx
jb .L261
The workaround fix is to just remove -fomit-frame-pointer. Though I'm fairly
concerned since the Linux kernel uses -fomit-frame-pointer for the kernel
sources.
--
Summary: Incorrect code generated for SSE2 based xor routine when
compiled with -O2 -fomit-frame-pointer
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jeff at panasas dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23909
[Bug c/23909] Incorrect code generated for SSE2 based xor routine when compiled with -O2 -fomit-frame-pointer
--- Additional Comments From jeff at panasas dot com 2005-09-16 05:44 --- Created an attachment (id=9738) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9738&action=view) Xor test program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23909
[Bug target/23909] Incorrect code generated for SSE2 based xor routine when compiled with -O2 -fomit-frame-pointer
--- Additional Comments From jeff at panasas dot com 2005-09-16 14:50 --- (In reply to comment #3) > This works for me with 4.1.0 but I really think it is just an accident. > /[EMAIL PROTECTED]@*/ int cr0; /* really, it's used, but lclint doesn't > "get" __asm__ */ > This comment does not make sense. > Specificly since GCC also warns about it: > t.c:110: warning: unused variable cr0 > t.c:109: warning: unused variable reg_store > I still think you are making a mistake in your code by using inline-asm. I pulled out some of the code required in the kernel. When using SSE in the kernel you have to save and restore cr0 but you can't do that at userlevel. The comment only refers to lclint, a tool that we use to statically check our code. lclint doesn't parse the inline asm, so we have to annotate the code. reg_store is also another local that is used to save and restore the xmm registers when running in the kernel. you can just ignore this at user-level. I'm not sure why SSE intrinsics will help here? This bug is will "go-away" when even very small changes are made to that loop, so just about any change will mask the bug. The other problem that we have is that this code is compiled with several versions of gcc (2.95.2 -> 3.4) so the inline asm is a good common denominator. I'd be willing to move to intrinisics if it solved the problem rather than masked it. Are there other reasons that the inline asm is a bad idea? I believe the code is completely legal inline asm. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23909
[Bug ada/22601] New: GNAT Command lists many commands as available that are not
Typing the command "gnat" results in the following output (note this is Centos 4.1 but I am pretty sure this is not target specific) : GNAT 3.4.3 20050227 (Red Hat 3.4.3-22.1) Copyright 1996-2004 Free Software Found ation, Inc. List of available commands GNAT BIND gnatbind GNAT CHOP gnatchop GNAT CLEAN gnatclean GNAT COMPILEgnatmake -f -u -c GNAT ELIM gnatelim GNAT FIND gnatfind GNAT KRUNCH gnatkr GNAT LINK gnatlink GNAT LIST gnatls GNAT MAKE gnatmake GNAT NAME gnatname GNAT PREPROCESS gnatprep GNAT PRETTY gnatpp GNAT STUB gnatstub GNAT XREF gnatxref Commands FIND, LIST, PRETTY, STUB and XREF accept project file switches -vPx, -P prj and -Xnam=val Some of the commands that are listed as available commands are not really available: %gnat elim Couldn't locate gnatelim %gnat pretty Couldn't locate gnatpp %gnat stub Couldn't locate gnatstub I think these are only available with the pro distribution of GNAT. Seems to still be the case in HEAD right now too (with possible addition of the sub command metric). Perhaps gnatcmd.adb should be updated so that it looks at some other file that is already branched between the FSF sources and ACT and tailor the output to only include those commands that are actually expected to be present. -- Summary: GNAT Command lists many commands as available that are not Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: minor Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jeff at thecreems dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22601
[Bug ada/34117] Please enable range checks by default (-gnato)
--- Comment #1 from jeff at thecreems dot com 2007-11-16 14:27 --- Seems like a good idea. Since we often say that correctness should come before performance when it comes to optimization, it has always seemed odd to me that performance was the default mode of operation. We can complain all we want that users should read the manual before they start using the compiler but the fact is they don't and probably never will. I do wonder if perhaps a new flag that just disables range checking to get the 'old' behavior would be warranted? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34117
[Bug c++/36860] New: gcc 4.2.3 produces poor code compared to gcc-3.4.3 on xeon prestonia
I have a subroutine that is heavily used by a program I frequently run called UKKA_Dist_With_Max. I had benchmarked it using mandriva linux 2005LE. When I ran it using mandriva 2008.1, it ran much slower. Using the compiler from mandriva linux 2005LE (gcc-3.4.3) and mandriva 2008.1, I was able to reproduce the problem. For example, with gcc-3.4.3 a small run takes 191 seconds, but with gcc-4.2.3 the same run takes 247 seconds. The switches I am using to compile, with both compilers are: -O3 -march=pentium4 -mtune=pentium4 -g -pthread \ -finline-functions -fschedule-insns2 -fbounds-check \ -W -Wall -pedantic -Wshadow -Wpointer-arith -Weffc++ \ -Wcast-qual -Wcast-align -Wwrite-strings -Wunused \ -Wctor-dtor-privacy -Wnon-virtual-dtor -Wreorder \ -Woverloaded-virtual -Wsign-promo -Wunused-parameter \ -Wpointer-arith -Wreturn-type -Wcast-qual -Wswitch \ -Wshadow -Wcast-align \ -Wchar-subscripts -Winline -Wredundant-decls gcc-4.2.3 was prebuilt by mandriva with the following: Using built-in specs. Target: i586-manbo-linux-gnu Configured with: ../configure --prefix=/usr --libexecdir=/usr/lib --with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-checking=release --enable-languages=c,c++,ada,fortran,objc,obj-c++,java --host=i586-manbo-linux-gnu --with-cpu=generic --with-system-zlib --enable-threads=posix --enable-shared --enable-long-long --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --enable-java-awt=gtk --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --enable-gtk-cairo --disable-libjava-multilib --enable-ssp --disable-libssp Thread model: posix gcc version 4.2.3 (4.2.3-6mnb1) gcc-3.4.3 was built by me with the following: Reading specs from /home/jdeifik_2008.1/lib/gcc/i686-pc-linux-gnu/3.4.3/specs Configured with: ../gcc-3.4.3/configure --prefix=/home/jdeifik_2008.1 Thread model: posix gcc version 3.4.3 Here is the subroutine file, run through the preprocessor using gcc-4.2.3: -- Summary: gcc 4.2.3 produces poor code compared to gcc-3.4.3 on xeon prestonia Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jeff at jeffunit dot com GCC build triplet: i586-manbo-linux-gnu GCC host triplet: i586-manbo-linux-gnu GCC target triplet: i586-manbo-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36860
[Bug c++/36860] gcc 4.2.3 produces poor code compared to gcc-3.4.3 on xeon prestonia
--- Comment #1 from jeff at jeffunit dot com 2008-07-17 01:57 --- Created an attachment (id=15919) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15919&action=view) this is the preprocessed subroutine that is poorly optimized -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36860
[Bug c++/36860] gcc 4.2.3 produces poor code compared to gcc-3.4.3 on xeon prestonia
--- Comment #2 from jeff at jeffunit dot com 2008-07-17 01:59 --- In order to run the entire program, you will need a fair amount of code. All needed code can be found at the above URL, along with test data. -- jeff at jeffunit dot com changed: What|Removed |Added URL||www.weasel.com/sim_test.tar. ||gz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36860
[Bug c++/36860] gcc 4.2.3 produces poor code compared to gcc-3.4.3 on xeon prestonia
--- Comment #3 from jeff at jeffunit dot com 2008-07-17 02:07 --- Created an attachment (id=15920) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15920&action=view) Here is the subroutine, run throuh the preprocessor using gcc-3.4.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36860
[Bug c++/19281] New: file format not recognized; treating as linker script
--prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-languages=c,ada,c++,d,f77,java,objc,pascal --enable-nls --without-included-gettext --enable-libgcj --with-system-zlib --enable-interpreter --enable-threads=posix --enable-java-gc=boehm --enable-sjlj-exceptions --disable-version-specific-runtime-libs --disable-win32-registry Thread model: posix gcc version 3.3.3 (cygwin special) /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/collect2.exe -Bdynamic --dll-search-prefix=cyg -o Auth.exe /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/../../../crt0.o /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/crtbegin.o -L/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3 -L/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/../../.. AuthTest.o AuthTestDlg.o stdafx.o -lstdc++ -lgcc -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/crtend.o /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/../../../../i686-pc-cygwin/bin/ld:AuthTest.o: file format not recognized; treating as linker script /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/../../../../i686-pc-cygwin/bin/ld:AuthTest.o:1: syntax error collect2: ld returned 1 exit status make: *** [Auth.exe] Error 1 make: Target `all' not remade because of errors. Build complete for project Auth -- Summary: file format not recognized; treating as linker script Product: gcc Version: 3.3.3 Status: UNCONFIRMED Severity: critical Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jeff at connectrf dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: Windows 2000, I686 GCC host triplet: Windows 2000, I686 GCC target triplet: Windows 2000, I686 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19281
[Bug c++/19281] file format not recognized; treating as linker script
--- Additional Comments From jeff at connectrf dot com 2005-01-06 15:33 --- (In reply to comment #1) > This is not a gcc bug, either this is your bug and the .o file is not an object file or this is a binutils bug. Andrew, then perhaps you can explain why the exact same code compiles, links and runs fine in a Microsoft environment? So the only thing that has changed is I am using GCC Hm.. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19281
[Bug c++/19281] file format not recognized; treating as linker script
--- Additional Comments From jeff at connectrf dot com 2005-01-10 18:45 --- Andrew, A view from the ld folks. They believe that the ld is failing due to the -fpreprocessed switch not producing the .o file.. --- Additional Comments From nickc at redhat dot com 2005-01-10 17:57 --- Subject: Re: file format not recognized; treating as linker script Hi Jeff, >> I tried it with -c same result. Also, when I ran file on it it says ASCII >> text. Hmm, what size is the file ? >> Here are the messages >> >> Full rebuild of configuration Release for project Auth Note - I would strongly suggest that you halt the build process after the creation of the first object file. Things have definitely gone wrong by this point. We are not looking at a linker bug, we are looking at a gcc bug or possibly a gas bug. There appears to be something very odd going on when an object file is built: >> g++ -O3 -Wall -c -fpreprocessed -M -v -oAuthTest.o ../AuthTest.cpp So G++ is invoked on AuthTest.cpp. I assume that the "-fpreprocessed" switch is correct and that this source file has already been pre-processed ? >> Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/specs >> Configured with: /gcc/gcc-3.3.3-3/configure --verbose --prefix=/usr >> --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib >> --mandir=/usr/share/man --infodir=/usr/share/info >> --enable-languages=c,ada,c++,d,f77,java,objc,pascal --enable-nls >> --without-included-gettext --enable-libgcj --with-system-zlib >> --enable-interpreter --enable-threads=posix --enable-java-gc=boehm >> --enable-sjlj-exceptions --disable-version-specific-runtime-libs >> --disable-win32-registry >> Thread model: posix >> gcc version 3.3.3 (cygwin special) >> /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/cc1plus.exe -E -D__GNUG__=3 -quiet -v >> -M >> -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=3 -D__CYGWIN32__ >> -D__CYGWIN__ -Dunix -D__unix__ -D__unix -idirafter >> /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/../../../../include/w32api -idirafter >> /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/../../../../i686-pc-cygwin/lib/../../include/w32api >> ../AuthTest.cpp -oAuthTest.o -Wall -fpreprocessed -O3 So cc1plus.exe is run once... >> ignoring nonexistent directory "/usr/local/include" >> ignoring nonexistent directory "/usr/i686-pc-cygwin/include" >> ignoring duplicate directory "/usr/i686-pc-cygwin/lib/../../include/w32api" >> #include "..." search starts here: >> #include <...> search starts here: >> /usr/include/c++/3.3.3 >> /usr/include/c++/3.3.3/i686-pc-cygwin >> /usr/include/c++/3.3.3/backward >> /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/include >> /usr/include >> /usr/include/w32api >> End of search list. >> Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/specs >> Configured with: /gcc/gcc-3.3.3-3/configure --verbose --prefix=/usr >> --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib >> --mandir=/usr/share/man --infodir=/usr/share/info >> --enable-languages=c,ada,c++,d,f77,java,objc,pascal --enable-nls >> --without-included-gettext --enable-libgcj --with-system-zlib >> --enable-interpreter --enable-threads=posix --enable-java-gc=boehm >> --enable-sjlj-exceptions --disable-version-specific-runtime-libs >> --disable-win32-registry >> Thread model: posix >> gcc version 3.3.3 (cygwin special) >> /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/cc1plus.exe -E -D__GNUG__=3 -quiet -v >> -P >> -M -MM -MG -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=3 >> -D__CYGWIN32__ -D__CYGWIN__ -Dunix -D__unix__ -D__unix -idirafter >> /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/../../../../include/w32api -idirafter >> /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/../../../../i686-pc-cygwin/lib/../../include/w32api >> ../AuthTest.cpp -Wall -w -fpreprocessed -O3 ... and then it is run again with the -o switch missing ? Why ? >> ignoring nonexistent directory "/usr/local/include" >> ignoring nonexistent directory "/usr/i686-pc-cygwin/include" >> ignoring duplicate directory "/usr/i686-pc-cygwin/lib/../../include/w32api" >> #include "..." search starts here: >> #include <...> search starts here: >> /usr/include/c++/3.3.3 >> /usr/include/c++/3.3.3/i686-pc-cygwin >> /usr/include/c++/3.3.3/backward >> /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/include >> /usr/include >> /usr/include/w32api >> End of search list. >> F
[Bug driver/19281] file format not recognized; treating as linker script
--- Additional Comments From jeff at connectrf dot com 2005-01-11 17:44 --- Andrew, What compiler option flag do I need to set for forward Declartions then? _M was taking care of those errors however it is not producing the .o? Is there a Crossrefrence of compiler options between MC VC++ and GCC? -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19281
[Bug driver/19281] file format not recognized; treating as linker script
--- Additional Comments From jeff at connectrf dot com 2005-01-11 19:24
---
Andrew, let me try again. BTW I have looked at the man pages for both gcc and
ld, I must say they are clear as mud, but then most are.
If I take the defaults, in CDT, I receive the errors attached below. If I add
the options -fpreprocessed and -M as miscellaneous options, as I found in the
man pages, the files compile without issue, but gcc does not create the proper
object files for linking.
So what gcc options would be required for forward declarations and standard
#include's?
Here is the makefile...
# Automatically-generated file. Do not edit!
ROOT := ..
-include $(ROOT)/makefile.init
RM := rm -rf
# All of the sources participating in the build are defined here
-include sources.mk
-include $(SUBDIRS:%=%/subdir.mk)
-include objects.mk
-include $(DEPS)
-include $(ROOT)/makefile.defs
all: Auth.exe
Auth.exe: $(OBJS)
@echo 'Building target: $@'
g++ -o $@ $(OBJS) $(USER_OBJS) $(LIBS)
@echo 'Finished building: $@'
clean:
-$(RM) $(OBJS) $(DEPS) Auth.exe
.PHONY: all clean dependents
-include $(ROOT)/makefile.targets
Full rebuild of configuration Release for project Auth
make -k clean all
rm -rf authtest.o authtestdlg.o stdafx.o authtest.d authtestdlg.d
stdafx.d Auth.exe
Building file: ../authtest.cpp
g++ -IC:\Documents and Settings\jeff\Desktop\AuthTest\include -O3 -Wall -c
-fmessage-length=0 -oauthtest.o ../authtest.cpp
In file included from ../authtest.cpp:4:
../AuthTest.h:4:9: warning: #pragma once is obsolete
../AuthTest.h:7:10: #error include 'stdafx.h' before including this file for PCH
In file included from ../authtest.cpp:4:
../AuthTest.h:18: error: parse error before `{' token
../AuthTest.h:29: error: ISO C++ forbids declaration of `DECLARE_MESSAGE_MAP'
with no type
../AuthTest.h: In function `int DECLARE_MESSAGE_MAP()':
../AuthTest.h:29: error: parse error before `}' token
../AuthTest.h:31:28: warning: no newline at end of file
In file included from ../authtest.cpp:5:
../AuthTestDlg.h:9: error: parse error before `{' token
../AuthTestDlg.h:17: error: parse error before `protected'
../AuthTestDlg.h:26: error: syntax error before `(' token
../AuthTestDlg.h:27: error: syntax error before `void'
../AuthTestDlg.h:28: error: syntax error before `void'
../AuthTestDlg.h:29: error: parse error before `(' token
../AuthTestDlg.h:31: error: ISO C++ forbids declaration of `DECLARE_MESSAGE_MAP'
with no type
../AuthTestDlg.h: In function `int DECLARE_MESSAGE_MAP()':
../AuthTestDlg.h:31: error: redefinition of `int DECLARE_MESSAGE_MAP()'
../AuthTest.h:29: error: `int DECLARE_MESSAGE_MAP()' previously defined here
../AuthTestDlg.h:31: error: redefinition of `int DECLARE_MESSAGE_MAP()'
../AuthTest.h:29: error: `int DECLARE_MESSAGE_MAP()' previously defined here
../AuthTestDlg.h:31: error: parse error before `public'
../AuthTestDlg.h:33: error: 'CString' is used as a type, but is not defined as a
type.
../AuthTestDlg.h:35: error: 'CString' is used as a type, but is not defined as a
type.
../AuthTestDlg.h:37: error: 'BOOL' is used as a type, but is not defined as a
type.
../AuthTestDlg.h:41: error: 'BOOL' is used as a type, but is not defined as a
type.
../AuthTestDlg.h:42: error: 'BOOL' is used as a type, but is not defined as a
type.
../AuthTestDlg.h:43: error: syntax error before `void'
../AuthTestDlg.h:44: error: 'CString' is used as a type, but is not defined as a
type.
../AuthTestDlg.h:45: error: parse error before `}' token
../authtest.cpp:14: error: type specifier omitted for parameter `CWinApp'
../authtest.cpp:15: error: ISO C++ forbids declaration of `BEGIN_MESSAGE_MAP'
with no type
../authtest.cpp: In function `int BEGIN_MESSAGE_MAP(CAuthTestApp)':
../authtest.cpp:15: error: `' has incomplete type
../AuthTest.h:17: error: forward declaration of `class CAuthTestApp'
../authtest.cpp:15: error: parse error before `(' token
../authtest.cpp:15: error: `ID_HELP' undeclared (first use this function)
../authtest.cpp:15: error: (Each undeclared identifier is reported only once for
each function it appears in.)
../authtest.cpp:15: error: `CWinApp' undeclared (first use this function)
../authtest.cpp:15: error: parse error before `::' token
../authtest.cpp:16: error: ISO C++ forbids declaration of `ON_COMMAND' with no
type
../authtest.cpp: In function `int ON_COMMAND(...)':
../authtest.cpp:21: error: ISO C++ forbids declaration of `END_MESSAGE_MAP' with
no type
../authtest.cpp: In function `int END_MESSAGE_MAP()':
../authtest.cpp:22: error: invalid
[Bug driver/19281] file format not recognized; treating as linker script
--- Additional Comments From jeff at connectrf dot com 2005-01-11 20:03 --- Andrew, If I take the exact same code, and compile it with VC++ it does not complain! However, gcc the ONLY thing that has changed, will not compile code that works! Why? Old wise one, must one rewrite entrie working applications just so gcc understands?? -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19281
[Bug driver/19281] file format not recognized; treating as linker script
--- Additional Comments From jeff at connectrf dot com 2005-01-11 20:23 --- Andrew, You are sure hard to convince... Where did the error go? Full rebuild of configuration Release for project Auth make -k clean all rm -rf authtest.o authtestdlg.o stdafx.o authtest.d authtestdlg.d stdafx.d Auth.exe Building file: ../authtest.cpp g++ -IC:\Documents and Settings\jeff\Desktop\AuthTest\include -O3 -Wall -c -fmessage-length=0 -fpreprocessed -M -oauthtest.o ../authtest.cpp Finished building: ../authtest.cpp Building file: ../authtestdlg.cpp g++ -IC:\Documents and Settings\jeff\Desktop\AuthTest\include -O3 -Wall -c -fmessage-length=0 -fpreprocessed -M -oauthtestdlg.o ../authtestdlg.cpp Finished building: ../authtestdlg.cpp Building file: ../stdafx.cpp g++ -IC:\Documents and Settings\jeff\Desktop\AuthTest\include -O3 -Wall -c -fmessage-length=0 -fpreprocessed -M -ostdafx.o ../stdafx.cpp Finished building: ../stdafx.cpp Building target: Auth.exe g++ -o Auth.exe authtest.o authtestdlg.o stdafx.o /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/../../../../i686-pc-cygwin/bin/ld:authtest.o: file format not recognized; treating as linker script /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/../../../../i686-pc-cygwin/bin/ld:authtest.o:1: syntax error collect2: ld returned 1 exit status make: *** [Auth.exe] Error 1 make: Target `all' not remade because of errors. Build complete for project Auth -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19281
[Bug driver/19281] file format not recognized; treating as linker script
--- Additional Comments From jeff at connectrf dot com 2005-01-11 21:03 --- Well that makes sense.. Does anyone have an example of the compiler options to port from VC++ to GCC? A nice Crossreference table would be just dandy. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19281
[Bug c++/16321] 64 bit structure passing problem (g++, not gcc)
--- Additional Comments From jeff at rtr dot com 2004-11-16 22:00 --- Subject: Re: 64 bit structure passing problem (g++, not gcc) Hi, I tested it with gcc 3.4.3 today and the bug seems to have been fixed. Regards, Jeff According to pinskia at gcc dot gnu dot org: > > >--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-15 >03:39 --- >Any news? > >-- > > >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16321 > >--- You are receiving this mail because: --- >You reported the bug, or are watching the reporter. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16321
[Bug c/77394] New: internal compiler error with Intel 3825U, cygwin 64 bit compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77394
Bug ID: 77394
Summary: internal compiler error with Intel 3825U, cygwin 64
bit compiler
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jeff at jeffunit dot com
Target Milestone: ---
Created attachment 39502
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39502&action=edit
output of cpuinfo, meminfo and gcc -DM -E
I have isolated the internal compiler error to a small piece of code:
#include/* floor */
extern double Round(double d)
{
return floor(d + 0.5);
}
produces:
bug_f3.c: In function 'Round':
bug_f3.c:5:5: internal compiler error: Illegal instruction
return floor(d + 0.5);
^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
gcc --version reports:
gcc (GCC) 5.4.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
uname -srvmo reports:
CYGWIN_NT-10.0 2.5.2(0.297/5/3) 2016-06-23 14:29 x86_64 Cygwin
The code compiles and runs correctly on other cpu's using the same cygwin 5.4.0
It also compiles and runs on mageia 5 linux with gcc 4.9.2
Included in attachments is the output of
cat /proc/cpuinfo
cat /proc/meminfo
gcc -dM -E
I suspect the internal compiler error is related to the specific processor,
which is found on my newish dell notebook.
[Bug ada/29543] New: Ada produces substantially slower code than FORTRAN for identical inputs - looping over double subscripted arrays
I understand comparing very very small benchmarks like this can be misleading
but I believe I've looked at this enough to have a sense that it is
demonstrating a basic truth and not a narrow performance issue.
The test case that has been attached shows a FORTRAN and Ada program that are
equivalent (within their matrix multiply loop). The Ada one runs about 2x
slower with about 3x the number of machine instructions in the inner loop.
(Note that running with Ada run time checks disabled).
I dumped the optimized trees (as the original tree of the Ada version was
difficult to read because of the node types not being known to the pretty
printer). The Ada tree is certainly a mess compared to the FORTRAN version.
The core of the FORTRAN code looks like
do I = 1,N
do J = 1,N
sum = 0.0
do R = 1,N
sum = sum + A(I,R)*B(R,J)
end do
C(I,J) = sum
end do
end do
With the resulting optimized tree fragment (of the inner most loop) being
:;
sum = MEM[base: (real4 *) ivtmp.97] * MEM[base: (real4 *) pretmp.81, index:
(real4 *) ivtmp.161 + (real4 *) ivtmp.94, step: 4B, offset: 4B] + sum;
ivtmp.94 = ivtmp.94 + 1;
ivtmp.97 = ivtmp.97 + ivtmp.157;
if (ivtmp.94 == () D.1273) goto ; else goto ;
While the core of the Ada code looks like:
for I in A'range(1) loop
for J in A'range(2) loop
Sum := 0.0;
for R in A'range(2) loop
Sum := Sum + A(I,R)*B(R,J);
end loop;
C(I,J) := Sum;
end loop;
end loop;
With the resulting optimized tree fragment of the inner most loop being :
:;
D.2370 = (*D.2277)[pretmp.627]{lb: tst_array__L_3__T16b___L sz: pretmp.709 *
4}[() r]{lb: tst_array__L_4__T17b___L sz: 4};
:
temp.721 = D.2344->LB0;
:
temp.720 = D.2344->UB1;
:
temp.719 = D.2344->LB1;
:
j.73 = () j;
D.2373 = (*D.2298)[() r]{lb: temp.721 sz: MAX_EXPR <(temp.720 +
1 - temp.719) * 4, 0> + 3 & -4}[j.73]{lb: temp.719 sz: 4};
:
D.2374 = D.2370 * D.2373;
:
sum = D.2374 + sum;
:
if (r == tst_array__L_4__T17b___U) goto ; else goto ;
:;
r = r + 1;
goto ();
Now, I'll be the first to admit that I know very little about the innards of
compiler technology but that tree looks like a horrible mess. It is no wonder
the resulting assembly is such a mess.
I am attaching a tar file that has the complete source for the Ada and the
FORTRAN version.
--
Summary: Ada produces substantially slower code than FORTRAN for
identical inputs - looping over double subscripted
arrays
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jeff at thecreems dot com
GCC build triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29543
[Bug ada/29543] Ada produces substantially slower code than FORTRAN for identical inputs - looping over double subscripted arrays
--- Comment #1 from jeff at thecreems dot com 2006-10-22 02:02 --- Created an attachment (id=12473) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12473&action=view) Source code and very simple build script for Ada and FORTRAN code capable of showing poor tree and runtime performance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29543
[Bug tree-optimization/29543] Poor code generated for arrays with variable bounds
--- Comment #8 from jeff at thecreems dot com 2006-10-22 15:50 --- (In reply to comment #7) > > No, but there is an obvious one why the Fortran version trounces the Ada > > version. Let's not compare apples with oranges. > > The adverse effect of the indirection can be alleviated though: > >N : Positive := Positive'Value (Argument (1)); >G : Ada.Numerics.Float_Random.Generator; > >type Real_Matrix is array (1..N, 1..N) of Float; >type Matrix_Access is access Real_Matrix; > >A,B,C : Matrix_Access; >Start, Finish : Ada.Calendar.Time; >Sum : Float := 0.0; > begin >A := new Real_Matrix; >B := new Real_Matrix; >C := new Real_Matrix; > That is a good approach and it significantly narrows the gap though I would argue that a general user would not see the original version as "different" than the FORTRAN version. Both of them are dynamically allocating the size at run time based on an input parameter. The FORTRAN arrays could indeed be passed to other procedures (such as matmul) that take variable sized arrays while this modified version (in its current form) could not. So, from an understanding of the internals of the compiler, I think you have a reasonable argument that the original Ada and FORTRAN were somewhat different but I think this modified version is actually further from the FORTRAN. (Though I must admit I know very little about FORTRAN 95). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29543
[Bug tree-optimization/29543] Poor code generated for arrays with variable bounds
--- Comment #14 from jeff at thecreems dot com 2006-10-23 23:50 --- (In reply to comment #1) > Created an attachment (id=12473) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12473&action=view) [edit] > Source code and very simple build script for Ada and FORTRAN code capable of > showing poor tree and runtime performance. > Note, while it does not fully close the gap, I can confirm that a large portion of this the poor performance is a regression when compared to GCC 4.0.3. The 4.0.3 is about 1/3 faster than the 4.2.0 which also corresponds to a significantly reduced number of generated instructions for the inner loop. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29543
GCC 32bit ARM compiler integer division bugs -O2 or -O3
gcc version for reproducer bug
==
I tried this on the most recent gcc 32bit compiler version at godbolt.org,
and it is reporoducing the same assembly language for this benchmark as the
gcc version I am using, Raspbian 8.3.0-6+rpi1. The optional performance
enhancement I describe at the bottom *definitely* still applies, even if
the bugs I'm reporting in this reproducer are fixed.
output:
=
-970094740 14028998
problem:
==
(1) The bench() function below can only return positive values, so the
first number printed above is wrong.
(2) the second number is supposed to be the first number divided by
lit-const 237. The second number is too big for that to be correct.
REPRODUCER -- REPRODUCER -- REPRODUCER
==
#include
int bench()
{
int sum = 0;
for (int i=10; --i)
sum += i / 237;
return ((sum < 0) ? -sum : sum);
}
int main()
{
int asum = bench();
pritntf("%d %d\n", asum, asum / 237);
return 0;
}
==
END REPRODUCER -- END REPRODUCER -- END REPRODUCER
OTHER non-bug comment
===
The compiler I wrote runs literally twice as fast as 32bit ARM gcc for this
operation. The lit-const division and modulo in gcc 32 bit ARM is crazy
bad. Here is how I did it in my compiler:
// Following function from Hacker's Delight, 2nd Edition
// converts literal-constant integer division into a multiply
struct muldiv {int M; int s;}; // Recip mult and shift amount
void irecip(int d, struct muldiv *mag) {
int p;
int ad, anc, delta, q1, r1, q2, r2, t;
int two31 = 0x8000; // 2**31.
ad = (d < 0) ? -d : d;
t = 0x7fff + ((d < 0) ? (1+d) : -d) + 1;
anc = 0x7fff - t%ad + ((d < 0) ? 1 : 0);
p = 31; // Init. p.
q1 = -(two31/anc); // Init. q1 = 2**p/|nc|.
r1 = two31 - q1*anc;// Init. r1 = rem(2**p, |nc|).
q2 = two31/ad; // Init. q2 = 2**p/|d|.
r2 = -(two31 - q2*ad); // Init. r2 = rem(2**p, |d|).
q2 = -q2;
do {
p = p + 1;
q1 = 2*q1; // Update q1 = 2**p/|nc|.
r1 = 2*r1; // Update r1 = rem(2**p, |nc|).
if (r1 >= anc) { // (Must be an unsigned
q1 = q1 + 1; // comparison here).
r1 = r1 - anc;}
q2 = 2*q2; // Update q2 = 2**p/|d|.
r2 = 2*r2; // Update r2 = rem(2**p, |d|).
if (r2 >= ad) { // (Must be an unsigned
q2 = q2 + 1; // comparison here).
r2 = r2 - ad;}
delta = ad - r2;
} while (q1 < delta || (q1 == delta && r1 == 0));
mag->M = q2 + 1;
if (d < 0) mag->M = -mag->M; // Magic number and
mag->s = p - 32;// shift amount to return.
}
void const_div_AST(int *enode)
{
struct muldiv mag;
int *a, divisor = n[2];
irecip(divisor, &mag);
n[2] = mag.M; *--n = DivCnst;
if (divisor > 0 && mag.M < 0) { *--n = (int) enode; *--n = Add; }
else if (divisor < 0 && mag.M > 0) { *--n = (int) enode; *--n = Sub; }
if (mag.s > 0) {
a = n; *--n = mag.s; *--n = Num; *--n = (int) a; *--n = Shr;
}
}
[Bug c++/88095] class nontype template parameter UDL string literals doesn't accepts deduction placeholder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88095
Jeff Snyder changed:
What|Removed |Added
CC||jeff-gcc at caffeinated dot
me.uk
--- Comment #1 from Jeff Snyder ---
I had a go at fixing this, and the following makes Hana's example work:
---8<---
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -27875,7 +27875,8 @@ cp_parser_template_declaration_after_parameters
(cp_parser* parser,
{
tree parm_list = TREE_VEC_ELT (parameter_list, 0);
tree parm = INNERMOST_TEMPLATE_PARMS (parm_list);
- if (CLASS_TYPE_P (TREE_TYPE (parm)))
+ if (CLASS_TYPE_P (TREE_TYPE (parm))
+ || TREE_CODE (TREE_TYPE (parm)) == TEMPLATE_TYPE_PARM)
/* OK, C++20 string literal operator template. We don't need
to warn in lower dialects here because we will have already
warned about the template parameter. */;
--->8---
[Bug bootstrap/28976] New: ld internal error building libmath in gcc 4.1.1
I was attempting to build gcc 4.1.1 on an I386 system running Linux, RedHat 4ES U3, and got an internal error from ld. I realize that ld is not part of gcc but I could not find anywhere to report bugs on it. Since I was building gcc at the time, I decided to file a report with you. Please let me know where I should file it, if not here. The source directory for the gcc was /tmp/gcc-4.1.1, the target was /tmp/gccbld. I entered the following commands: cd /tmp/gccbld /tmp/gcc-4.1.1/configure make bootstrap Here is a portion of the make output. As you see, it was trying to build libmath: Making all in libmath make[5]: Entering directory `/tmp/gccbld/i686-pc-linux-gnu/libstdc++-v3/libmath'make[5]: Nothing to be done for `all'. make[5]: Leaving directory `/tmp/gccbld/i686-pc-linux-gnu/libstdc++-v3/libmath' Making all in src make[5]: Entering directory `/tmp/gccbld/i686-pc-linux-gnu/libstdc++-v3/src' /bin/sh ../libtool --tag CXX --mode=link /tmp/gccbld/./gcc/xgcc -shared-libgcc -B/tmp/gccbld/./gcc -nostdinc++ -L/tmp/gccbld/i686-pc-linux-gnu/libstdc++-v3/src -L/tmp/gccbld/i686-pc-linux-gnu/libstdc++-v3/src/.libs -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -Wl,-O1 -Wl,-z,relro -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -o libstdc++.la -rpath /usr/local/lib -version-info 6:8:0 -Wl,--version-script=libstdc++-symbol.ver -lm bitmap_allocator.lo pool_allocator.lo mt_allocator.lo codecvt.lo compatibility.lo complex_io.lo ctype.lo debug.lo debug_list.lo functexcept.lo globals_locale.lo globals_io.lo ios.lo ios_failure.lo ios_init.lo ios_locale.lo limits.lo list.lo locale.lo locale_init.lo locale_facets.lo localename.lo stdexcept.lo strstream.lo tree.lo allocator-inst.lo concept-inst.lo fstream-inst.lo ext-inst.lo ios-inst.lo iostream-inst.lo istream-inst.lo istream.lo locale-inst.lo locale-misc-inst.lo misc-inst.lo ostream-inst.lo sstream-inst.lo streambuf-inst.lo streambuf.lo string-inst.lo valarray-inst.lo wlocale-inst.lo wstring-inst.lo atomicity.lo codecvt_members.lo collate_members.lo ctype_members.lo messages_members.lo monetary_members.lo numeric_members.lo time_members.lo basic_file.lo c++locale.lo ../libmath/libmath.la ../libsupc++/libsupc++convenience.la -lm /tmp/gccbld/./gcc/xgcc -shared-libgcc -B/tmp/gccbld/./gcc -nostdinc++ -L/tmp/gccbld/i686-pc-linux-gnu/libstdc++-v3/src -L/tmp/gccbld/i686-pc-linux-gnu/libstdc++-v3/src/.libs -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -shared -nostdlib /usr/lib/crti.o /tmp/gccbld/./gcc/crtbeginS.o .libs/bitmap_allocator.o .libs/pool_allocator.o .libs/mt_allocator.o .libs/codecvt.o .libs/compatibility.o .libs/complex_io.o .libs/ctype.o .libs/debug.o .libs/debug_list.o .libs/functexcept.o .libs/globals_locale.o .libs/globals_io.o .libs/ios.o .libs/ios_failure.o .libs/ios_init.o .libs/ios_locale.o .libs/limits.o .libs/list.o .libs/locale.o .libs/locale_init.o .libs/locale_facets.o .libs/localename.o .libs/stdexcept.o .libs/strstream.o .libs/tree.o .libs/allocator-inst.o .libs/concept-inst.o .libs/fstream-inst.o .libs/ext-inst.o .libs/ios-inst.o .libs/iostream-inst.o .libs/istream-inst.o .libs/istream.o .libs/locale-inst.o .libs/locale-misc-inst.o .libs/misc-inst.o .libs/ostream-inst.o .libs/sstream-inst.o .libs/streambuf-inst.o .libs/streambuf.o .libs/string-inst.o .libs/valarray-inst.o .libs/wlocale-inst.o .libs/wstring-inst.o .libs/atomicity.o .libs/codecvt_members.o .libs/collate_members.o .libs/ctype_members.o .libs/messages_members.o .libs/monetary_members.o .libs/numeric_members.o .libs/time_members.o .libs/basic_file.o .libs/c++locale.o -Wl,--whole-archive ../libmath/.libs/libmath.a ../libsupc++/.libs/libsupc++convenience.a -Wl,--no-whole-archive -L/tmp/gccbld/i686-pc-linux-gnu/libstdc++-v3/src -L/tmp/gccbld/i686-pc-linux-gnu/libstdc++-v3/src/.libs -lm ../libmath/.libs/libmath.a -lm ../libsupc++/.libs/libsupc++convenience.a -lm -L/tmp/gccbld/./gcc -L/usr/local/lib -lgcc_s -lc -lgcc_s -lm -lgcc_s -lc -lgcc_s /tmp/gccbld/./gcc/crtendS.o /usr/lib/crtn.o -Wl,-O1 -Wl,-z -Wl,relro -Wl,--version-script=libstdc++-symbol.ver -Wl,-soname -Wl,libstdc++.so.6 -o .libs/libstdc++.so.6.0.8 /usr/bin/ld: BFD 2.15.92.0.2 20040927 internal error, aborting at ../../bfd/elf32-i386.c line 2262 in elf_i386_relocate_section /usr/bin/ld: Please report this bug. -- Summary: ld internal error building libmath in gcc 4.1.1 Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jeff dot lanam at hp dot com http://gcc.gnu.org/bugz
[Bug bootstrap/28976] ld internal error building libmath in gcc 4.1.1
--- Comment #3 from jeff dot lanam at hp dot com 2006-09-07 18:36 --- Subject: RE: ld internal error building libmath in gcc 4.1.1 Thank you for the quick response. I updated binutils and got past that. I'm a novice at using GNU. -Original Message- From: pinskia at gcc dot gnu dot org [mailto:[EMAIL PROTECTED] Sent: Thursday, September 07, 2006 11:02 AM To: Lanam, Jeff Subject: [Bug bootstrap/28976] ld internal error building libmath in gcc 4.1.1 --- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-07 18:01 --- This is a bug in Redhat's ld and should be reported to them. It has been fixed on the mainline (and in a couple of releases) of binutils already. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28976 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28976
[Bug awt/16729] Component.print() and Component.printAll() does not affect graphics parameter
--- Comment #2 from jeff dot myers at eclipse dot org 2005-10-23 23:50 --- This function must be implemented to support the Swing/AWT development using Eclipse Visual Editor project (http://www.eclipse.org/vep/) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16729
[Bug c/34252] New: DEC32_MIN_EXP, DEC32_MAX_EXP don't match TR 24732
I discovered a few differences in the gcc implemenation of the
macros, as compared with the ISO C Tr24732 paper. It may be more likely that
the gcc implementation is incorrect.
In any case, here's what I see in the decfloat-constants.c test from the gcc
4.3 testsuite:
if (DEC32_MIN_EXP != -95) abort();
if (DEC64_MIN_EXP != -383) abort();
if (DEC128_MIN_EXP != -6143) abort();
if (DEC32_MAX_EXP != 96) abort();
if (DEC64_MAX_EXP != 384) abort();
if (DEC128_MAX_EXP != 6144) abort();
Here's the info from Tr24732:
- minimum exponent
DEC32_MIN_EXP -94
DEC64_MIN_EXP -382
DEC128_MIN_EXP -6142
- maximum exponent
DEC32_MAX_EXP 97
DEC64_MAX_EXP 385
DEC128_MAX_EXP 6145
As you can see, they appear to be off-by-one (gcc is always one less). The
constants are generated by the gcc compiler (at least gcc 4.3.0 20071012, which
I am using), so the decfloat-constants test passes.
Also, gcc sets DEC32_DEN, etc:
if (DEC32_DEN != 0.01E-95DF) abort();
if (DEC64_DEN != 0.001E-383DD) abort();
if (DEC128_DEN != 0.1E-6143DL) abort();
Tr24732 specifies these as DEC32_SUBNORMAL_MIN, etc:
DEC32_SUBNORMAL_MIN 0.01E-95DF
DEC62_SUBNORMAL_MIN 0.001E-383DD
DEC128_SUBNORMAL_MIN
0.1E-6143DL
See http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1241.pdf
It looks like the gcc values came from the implementation and not
TR 24732.
--
Summary: DEC32_MIN_EXP, DEC32_MAX_EXP don't match TR 24732
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jeff dot sullivan at intel dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34252
[Bug c++/36642] New: Problem with non matching template args in tr1_impl/hashtable
I think there may be two issues here demonstrated in the code below. The
example code is distilled from ./include/c++/4.3.0/tr1_imp/hashtable. GCC
compiles this code without a diagnostic, but both the Intel and Microsoft
compilers diagnose an error with too few template args for __detail::_Map_base'
:
% cl -c t.cpp -nologo
t.cpp
t.cpp(10) : error C2976: '__detail::_Map_base' : too few template arguments
t.cpp(4) : see declaration of '__detail::_Map_base'
% cat t.cpp
namespace __detail
{
template struct _Map_base { };
}
struct _Hashtable
{
template
friend struct __detail::_Map_base;
};
So, you may want to fix the template in and/or try to
diagnose this case in the compilation.
--
Summary: Problem with non matching template args in
tr1_impl/hashtable
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jeff dot sullivan at intel dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36642
[Bug tree-optimization/19570] New: cross compiler for power PC -O2 optimization moves code outside of use
The -O2 optimization moves code outside of loop causing function call to be done after the data structure was unlocked. The code was actually moved to after the second usage of the variable assigned the return value of the indirect function call. The problem does not occur when the optimization level is decreased by using -O. I have checked this on the 386 version of the compiler and the code movement does not occur. Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/specs $ gcc -v (i386 compiler) Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) The cross compiler version is: $ ppc4xx-linux-gcc -v Reading specs from /opt/timesys/linux/4.0/toolchains/ppc4xx-linux/lib/gcc-lib/powerpc-linux/3.2/specs Configured with: ../package/configure --build=i686-linux --host=i686-linux --target=powerpc-linux --prefix=/opt/timesys/linux/4.0/toolchains/ppc4xx-linux --enable-threads=posix --program-transform-name='s,^,ppc4xx-linux-,' --enable-languages=c,c++ --enable-shared --with-gnu-as --with-gnu-ld --nfp --with-stabs Thread model: posix gcc version 3.2 The uname information is: Linux gard8000 2.4.20-8 #1 Thu Mar 13 17:54:28 EST 2003 i686 i686 i386 GNU/Linux System Info $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 2.26GHz stepping: 9 cpu MHz : 2261.049 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm bogomips: 4508.87 $ cat /proc/meminfo total:used:free: shared: buffers: cached: Mem: 525639680 510992384 146472960 90320896 367050752 Swap: 1069244416 98328576 970915840 MemTotal: 513320 kB MemFree: 14304 kB MemShared: 0 kB Buffers: 88204 kB Cached: 337652 kB SwapCached: 20796 kB Active: 372652 kB ActiveAnon: 26032 kB ActiveCache:346620 kB Inact_dirty: 0 kB Inact_laundry: 69508 kB Inact_clean: 10852 kB Inact_target:90600 kB HighTotal: 0 kB HighFree:0 kB LowTotal: 513320 kB LowFree: 14304 kB SwapTotal: 1044184 kB SwapFree: 948160 kB $ cat /proc/version Linux version 2.4.20-8 ([EMAIL PROTECTED]) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #1 Thu Mar 13 17:54:28 EST 2003 The compilation lines for the error is in the file COMP_BUG, $ cat COMP_BUG ppc4xx-linux-gcc -save-temps \ -D__KERNEL__ \ -I/opt/timesys/linux/4.0/ep405/src/2.4.18-timesys-4.0/kernel/include \ -Wstrict-prototypes \ -Wno-trigraphs \ -O2 \ -fno-strict-aliasing \ -fno-common \ -finline-limit=5000 \ -fomit-frame-pointer \ -D__powerpc__ \ -fsigned-char \ -msoft-float \ -pipe \ -ffixed-r2 \ -Wno-uninitialized \ -mmultiple \ -mstring \ -I/opt/timesys/linux/4.0/ep405/src/2.4.18-timesys-4.0/kernel/arch/ppc \ -mcpu=405 \ -Wa,-m405 \ -Werror \ -g3 \ -DKBUILD_BASENAME=select \ -c \ -o select.o select.c and the compilation line generating code without the error is the file NOCOMP_BUG. $ cat NOCOMP_BUG ppc4xx-linux-gcc \ -D__KERNEL__ \ -I/opt/timesys/linux/4.0/ep405/src/2.4.18-timesys-4.0/kernel/include \ -Wstrict-prototypes \ -Wno-trigraphs \ -O \ -fno-strict-aliasing \ -fno-common \ -finline-limit=5000 \ -fomit-frame-pointer \ -D__powerpc__ \ -fsigned-char \ -msoft-float \ -pipe \ -ffixed-r2 \ -Wno-uninitialized \ -mmultiple \ -mstring \ -I/opt/timesys/linux/4.0/ep405/src/2.4.18-timesys-4.0/kernel/arch/ppc \ -mcpu=405 \ -Wa,-m405 \ -Werror \ -g3 \ -DKBUILD_BASENAME=select \ -c \ -o select.o select.c The source file is fs/select.c which is from the timesys linux 2.4.18-timesys4.0 kernel. The source file and headers follow. I have included all the header files for successful compilation. My contact information is: Jeff Fellin RFL Electronics 973-334-3100 x327 [EMAIL PROTECTED] = select.c /* * This file contains the
[Bug c++/105774] New: Bogus overflow in constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105774
Bug ID: 105774
Summary: Bogus overflow in constant expression
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jeff at jgarrett dot org
Target Milestone: ---
The following is diagnosed as ill-formed by GCC but not by Clang:
int main() {
constexpr auto _ = [] {
char x = 127;
return ++x;
}();
}
:5:5: error: overflow in constant expression [-fpermissive]
On godbolt https://godbolt.org/z/91oeGsEbh
Originally from
https://stackoverflow.com/questions/72425404/still-unsure-about-signed-integer-overflow-in-c
I believe that this is well-formed. [expr.pre.incr]/1 says x++ is equivalent to
x+=1. [expr.ass]/6 says that x+=1 is equivalent to x=x+1 except that x is only
evaluated once. That expression x=x+1 avoids overflow through integer
promotion.
The same code with x+=1 instead of ++x is allowed by GCC.
[Bug ipa/119006] New: IPA ICF and LTO cause strcmp condition to be omitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119006
Bug ID: 119006
Summary: IPA ICF and LTO cause strcmp condition to be omitted
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: jeff-gcc at caffeinated dot me.uk
Target Milestone: ---
When compiled with -O2 -flto (or more minimally: -O -finline
-fipa-icf-functions -foptimize-strlen -ftree-dse -ftree-vrp -flto), GCC
miscompiles the following code:
template struct FixedString {
FixedString(const char* str_) { *this = str_; }
bool operator==(const char* rhs_) const { return rhs_ and not
__builtin_strcmp(_str, rhs_); }
bool operator!=(const char* rhs_) const { return !(*this == rhs_); }
char _str[N + 1];
};
int fixedStringUser(const FixedString<10>& lhs, const char* rhs) {
return lhs == rhs;
}
void checkString(FixedString<127> reason_) {
if (reason_ != "StrOverTenChars") asm volatile("nop");
}
int main(int argc, char** argv) {
FixedString<127> fs = argv[1];
if (argc > 2) checkString(fs);
}
During LTO WPA, ICF replaces FixedString<127>::operator== with
FixedString<10>::operator==, and then LTRANS reasons that strcmp of a buffer
which can hold a string up to length 10 cannot be equal to a string longer than
10 characters, forgetting that the LHS is actually max length 127. This results
in `checkString` being reduced to the body of the `if` condition, i.e. just the
`asm volatile("nop")`.
Testing on godbolt (https://gcc.godbolt.org/z/bv3YqzTG5) shows that this has
been present since GCC11, and is still present in trunk.
[Bug ipa/119006] IPA ICF and LTO cause strcmp condition to be omitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119006
--- Comment #2 from Jeff Snyder ---
Further simplified:
template struct FixedString {
bool operator==(const char* rhs_) const { return rhs_ and not
__builtin_strcmp(_str, rhs_); }
bool operator!=(const char* rhs_) const { return !(*this == rhs_); }
char _str[N + 1];
};
int fixedString10User(const FixedString<10>& lhs, const char* rhs) {
return lhs == rhs;
}
void checkString(FixedString<127> reason_) {
if (reason_ != "StrOverTenChars") asm volatile("nop");
}
int main() {}
I also had to build with `-rdynamic` to repro without `checkString` being
omitted entirely. Observed on x86-64.
