[Bug c/41795] New: Incorrect warning while compiling string constant with "??)"
Consider the following example
begin of test.c
int main(int argc, char *argv[])
{
char *sz = "(Is this a correct warning???)";
return main(1, &sz);
}
end of test.c
If compiled, it displays a warning
# gcc -o test test.c
test.c:3:42: warning: trigraph ??) ignored, use -trigraphs to enable
#
--
Summary: Incorrect warning while compiling string constant with
"??)"
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oder at eleks dot lviv dot ua
GCC build triplet: x86
GCC host triplet: x86
GCC target triplet: x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41795
[Bug target/35836] Wrong instruction generated for comparison with zero on PPC 64 bit
--- Comment #11 from oder at eleks dot lviv dot ua 2008-05-21 16:27 --- (In reply to comment #10) > OSAtomicIncrement32Barrier will return a 32bit signed extended value to a > 64bit > so using a 64bit compare is fine and ok according to the ABI. Yes, but it returns value in 64-bit register with lower 32 bit being correct and higher 32 bit being nonzero (the garbage) and using 64bit comparison for equality with zero yields incorrect result. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35836
[Bug c++/35836] Wrong instruction generated for comparison with zero on PPC 64 bit
-- oder at eleks dot lviv dot ua changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35836
[Bug c++/35836] Wrong instruction generated for comparison with zero on PPC 64 bit
--- Comment #9 from oder at eleks dot lviv dot ua 2008-05-21 15:39 --- Created an attachment (id=15666) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15666&action=view) Sources without Mac headers So, I had some free time an enthusiasm to modify the example and remove Apple headers from it. Now it is OS independent. Please remember that the bug seems to be ppc64-specific (or at least *64-specific) at first glance though. Note: It is OK that function returns int64 while its caller expects int32. It should not affect the result of the test but helps to demonstrate the bug. -- oder at eleks dot lviv dot ua changed: What|Removed |Added Attachment #15438|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35836
[Bug c++/35836] Wrong instruction generated for comparison with zero on PPC 64 bit
--- Comment #8 from oder at eleks dot lviv dot ua 2008-04-07 08:58 --- Created an attachment (id=15438) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15438&action=view) Preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35836
[Bug c++/35836] Wrong instruction generated for comparison with zero on PPC 64 bit
--- Comment #5 from oder at eleks dot lviv dot ua 2008-04-06 20:14 --- (In reply to comment #4) > Both Fink and Macports have > gcc 4.1, 4.2, and 4.3 packages, and Macports even has a 4.4 snapshot. Could you please provide a link to gcc archive? On gcc.gnu.org there is no MacOS in Download->Binaries Fink webpage offers binary installer for download. But I don't like it, since, as I already mentioned, I don't have root access and would not like to install anything outside my home folder on a computer I've been let in just to have a try if my sources could be compiled on MacOS. As for Macports, I can't browse that site with IE7. It attempts to download some XML file all the time instead of browsing the pages. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35836
[Bug c++/35836] Wrong instruction generated for comparison with zero on PPC 64 bit
--- Comment #2 from oder at eleks dot lviv dot ua 2008-04-06 13:21 --- (In reply to comment #1) > You need to report this with apple or at least try a still maintained gcc > version and provide a testcase without Mac specific headers. Well, it's not so easy. ./configure for GCC 4.3.0 fails with "Building GCC requires GMP 4.1+ and MPFR 2.3.0+". I don't know what these are and I'm not too eager spending time to search for all the necessary stuff needed to build a new version and find out that there is some problem with building I can't resolve after all. If there are no prebuilt binaries publicly available that means there must be some reason for it. I have already tried to build latest GCC once for QNX. Well, after few days and lots of corrections to headers I succeeded. But then I found that there are some system related settings I don't know how to specify for new compiler and startup stubs in objs, I don't have sources for. So, even though compiler worked I did not take a risk to use it for production binaries compilation. As for getting rid of system-specific headers, I tried replacing OSAtomicIncrement32Barrier(paoDestination) with increment for volatile int64_t, but the problem can't be reproduced that way. This seems to be PowerPC architecture related problem and I don't have other operating systems/machines based on PowerPC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35836
[Bug c++/35835] Compiler fails to recognize match of local "extern" declarations
--- Comment #2 from oder at eleks dot lviv dot ua 2008-04-05 20:02 --- (In reply to comment #1) > First, this bug should be filed with Apple as you are using Apple's modified > compiler. Second 4.0.x is no longer being maintained, so please try 4.1.x. I don't have root access to the build machine and I can only use the version of compiler which is installed there. Also, I don't think the problem is related to target platform. It should be reproduceable on all the platforms. If you can't try it yourself, I can run the test on SunOS or Linux tomorrow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35835
[Bug c++/35836] New: Wrong instruction generated for comparison with zero on PPC 64 bit
r7,0x1279c <_Z20TestAtomic_Incrementv+188> 0x00012794 <_Z20TestAtomic_Incrementv+180>: li r0,1 0x00012798 <_Z20TestAtomic_Incrementv+184>: stb r0,112(r30) 0x0001279c <_Z20TestAtomic_Incrementv+188>: lbz r0,112(r30) 0x000127a0 <_Z20TestAtomic_Incrementv+192>: clrldi r0,r0,56 0x000127a4 <_Z20TestAtomic_Incrementv+196>: mr r3,r0 0x000127a8 <_Z20TestAtomic_Incrementv+200>: ld r1,0(r1) 0x000127ac <_Z20TestAtomic_Incrementv+204>: ld r0,16(r1) 0x000127b0 <_Z20TestAtomic_Incrementv+208>: mtlrr0 0x000127b4 <_Z20TestAtomic_Incrementv+212>: ld r30,-16(r1) 0x000127b8 <_Z20TestAtomic_Incrementv+216>: blr For comparison of first AtomicIncrement() invocation result with zero "cmpdi cr7,r0,0" instruction has been generated at 0x00012714, which is incorrect. For comparison of second AtomicIncrement() invocation result with one "cmpwi cr7,r0,1" instruction has been generated at 0x0001275c, which is correct. On exit from first call to AtomicIncrement() cr3 equals to 0x1 (naturally, 0x0 + 1) and 8 byte comparison with zero yields incorrect result. osx-leopard:build oder$ g++ -m64 -o test test.cpp osx-leopard:build oder$ ./test 0 -- Summary: Wrong instruction generated for comparison with zero on PPC 64 bit Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: oder at eleks dot lviv dot ua GCC build triplet: ppc GCC host triplet: ppc GCC target triplet: ppc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35836
[Bug c++/35835] New: Compiler fails to recognize match of local "extern" declarations
Consider following program
=== begin of test.cpp
#include
static inline void SetValue(int i)
{
extern int g_iValue;
g_iValue = i;
}
static inline int GetValue()
{
extern int g_iValue;
return g_iValue;
}
int g_iValue = 0;
int main()
{
int iValueSave = GetValue();
SetValue(1);
printf("%d\n", GetValue());
SetValue(iValueSave);
return 0;
}
=== end of test.cpp
I use this apptoach to only publish get/set global variable accessors in header
while keeping variable itself hidden in cpp.
If compiled with optimizations turned on, compiler fails identify two local
"extern" declarations as a single memory object and uses initial value
retrieved for iValueSafe in call to printf as well (as if SetValue() was
unrelated to g_iValue).
If compiled and run, program outputs 0 instead of 1.
osx-leopard:build oder$ g++ -O3 -o test test.cpp
osx-leopard:build oder$ ./test
0
Output of "g++ -v" is:
Using built-in specs.
Target: powerpc-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5478~1/src/configure --disable-checking
-enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
--with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib
--build=powerpc-apple-darwin9 --host=powerpc-apple-darwin9
--target=powerpc-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5478)
--
Summary: Compiler fails to recognize match of local "extern"
declarations
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oder at eleks dot lviv dot ua
GCC build triplet: ppc
GCC host triplet: ppc
GCC target triplet: ppc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35835
[Bug c++/33914] New: False warning: allocating zero-element array
Compile
begin of test.cpp
int main()
{
const unsigned nElementCount = 0;
int *piArray = nElementCount ? new int[nElementCount] : 0;
return 0;
}
end of test.cpp
Compiler displays a warning even though new operator is never executed:
test.cpp: In function 'int main()':
test.cpp:4: warning: allocating zero-element array
It does not depend on optimization.
--
Summary: False warning: allocating zero-element array
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oder at eleks dot lviv dot ua
GCC build triplet: x86
GCC host triplet: x86
GCC target triplet: x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33914
[Bug inline-asm/30117] New: fdivp assembler instruction compiles to fdivrp
== begin of div.c ==
int main()
{
asm(
"fdivp;"
);
}
== end of div.c ==
if compiled
===
$ gcc div.c
$ gdb a.out
GNU gdb 6.4
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-pc-nto-qnx6.3.0"...(no debugging symbols
found)
(gdb) disas main
Dump of assembler code for function main:
0x080483ac :push %ebp
0x080483ad :mov%esp,%ebp
0x080483af :sub$0x8,%esp
0x080483b2 :and$0xfff0,%esp
0x080483b5 :mov$0x0,%eax
0x080483ba : sub%eax,%esp
0x080483bc : fdivp %st,%st(1)
0x080483be : leave
0x080483bf : ret
End of assembler dump.
(gdb) x/2b 0x080483bc
0x80483bc :0xde0xf1
(gdb)
===
it generates 0xde 0xf1 opcode sequence.
Accordingly to 25366614.pdf (IA-32 Intel® Architecture Software Developer’s
Manual Volume 2A) distrubuted at Intel website this opcode sequence stands for
fdivrp assembler instruction
begin of 25366614.pdf, page 3-237 ===
DE F1 FDIVRP Divide ST(0) by ST(1), store result in ST(1), and pop the
register stack
end of 25366614.pdf, page 3-237 ===
which produces ST(0)/ST(1) result, while fdivp is expected to have opcode
sequence of 0xde 0xf9 and to produce ST(1)/ST(0).
begin of 25366614.pdf, page 3-234 ===
DE F9 FDIVP Divide ST(1) by ST(0), store result in ST(1), and pop the
register stack.
end of 25366614.pdf, page 3-234 ===
--
Summary: fdivp assembler instruction compiles to fdivrp
Product: gcc
Version: 3.3.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oder at eleks dot lviv dot ua
GCC build triplet: x86
GCC host triplet: x86
GCC target triplet: x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30117
[Bug c++/29582] Parameter pushed to stack too soon
-- oder at eleks dot lviv dot ua changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29582
[Bug c++/29582] Parameter pushed to stack too soon
--- Comment #4 from oder at eleks dot lviv dot ua 2006-10-30 08:33 --- Created an attachment (id=12509) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12509&action=view) Compilable testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29582
[Bug c++/29582] Parameter pushed to stack too soon
--- Comment #2 from oder at eleks dot lviv dot ua 2006-10-24 16:09 --- (In reply to comment #1) > The evaluation order of function arguments is not specified. If you depend on > side effects to be carried out at a specific point you must make sure there is > a sequence point at the appropriate place. These are not the arguments of a single function. Given example is the sequence of method invocations for a class instance. Modification of lvalue occurs in 2nd method invocation and it is supposed to be passed to 4th method invocation. -- oder at eleks dot lviv dot ua changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29582
[Bug c++/29582] New: Parameter pushed to stack too soon
Given class COtherClass having methods
class COtherClass
{
...
inline COtherClass(unsigned int uiParam1, const char *pszParam2, const
char *pszParam3, unsigned long ulParam4, const char *pszParam5)
{...}
~COtherClass();
COtherClass &Method1();
COtherClass &Method2(unsigned long long &ullParam);
COtherClass &operator ()(const char *pszParam1, const void *pvParam2);
COtherClass &operator ()(const char *pszParam1, unsigned long long
ullParam2) { ... }
};
For code
struct CHostClass
{
public:
unsigned long long m_ullProblemField;
const void *m_pvPointerField;
const char *m_szSzField;
~CHostClass()
{
COtherClass(5, m_szSzField, NULL, 0,
"ImmString1").Method1().Method2(m_ullProblemField)("ImmString2",
m_pvPointerField)("ImmString3", m_ullProblemField);
}
};
GCC generated the following assembler text (debug build)
mov0x8(%ebp),%eax // CHostClass::this
pushl 0x4(%eax) // HI(CHostClass::m_ullProblemField)
pushl (%eax) // LO(CHostClass::m_ullProblemField)
push $0x81f10f9 // "ImmString3"
sub$0x8,%esp
mov0x8(%ebp),%eax // CHostClass::this
pushl 0x8(%eax) // CHostClass::m_pvPointerField
push $0x81f0e3a // "ImmString2"
sub$0xc,%esp
pushl 0x8(%ebp) // CHostClass::this <=> offset CHostClass::m_ullProblemField
sub$0xc,%esp
push $0x81f1104 // "ImmString1"
push $0x0 // 0
push $0x0 // NULL
mov0x8(%ebp),%eax // CHostClass::this
pushl 0xc(%eax) // CHostClass::m_szSzField
push $0x5 // 5
lea0xf4e8(%ebp),%eax // storage for COtherClass instance
push %eax
call 0x804e61c // COtherClass::COtherClass constructor
add$0x24,%esp // 6*4 params + 12 reserve made with "sub $0xc,%esp"
lea0xf4e8(%ebp),%eax // instance of COtherClass
push %eax
call 0x818e68e // COtherClass::Method1
add$0x4,%esp // 1 param
push %eax // instance of COtherClass
call 0x8190384 // COtherClass::Method2
add$0x14,%esp // 2*4 params + 12 reserve made with "sub $0xc,%esp"
push %eax // instance of COtherClass
call 0x818e85c // COtherClass::operator()(const char *, const void *)
add$0x14,%esp // 3*4 params + 8 reserve made with "sub $0x8,%esp"
push %eax // instance of COtherClass
call 0x804f322 // COtherClass::operator()(const char *, unsigned long long)
add$0x10,%esp // 2*4 + 1*8 params
sub$0xc,%esp
lea0xf4e8(%ebp),%eax // instance of COtherClass
push %eax
call 0x818e610 // COtherClass::~COtherClass
add$0x10,%esp // 1*4 params + 12 reserve made with "sub $0xc,%esp"
The problem is that the value of m_ullProblemField is pushed to stack at the
very beginning of code while it is modified later during invocation of
COtherClass::Method2. COtherClass::operator (const char *, unsigned long long)
should receive modified value of field but it receives initial one.
--
Summary: Parameter pushed to stack too soon
Product: gcc
Version: 3.3.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oder at eleks dot lviv dot ua
GCC build triplet: x86
GCC host triplet: x86
GCC target triplet: x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29582
[Bug c++/27838] New: Wrong code generated for for()-loop with enumerated type as index
I have enumerated type defined as follows
enum EQUEUEDWRITERFILEERROR
{
QWFE__MIN,
QWFE_REOPEN = QWFE__MIN,
QWFE_WRITE,
QWFE_OVERFLOW,
QWFE__MAX,
};
For it I have prefix increment operator defined with macro
#define DEFINE_ENUM_INC_DEC(EnumType) \
static inline EnumType &operator ++(EnumType &Value) { return (EnumType
&)(++((int &)Value)); }
For following for-loop operator
for (EQUEUEDWRITERFILEERROR qwfeError = QWFE__MIN; qwfeError !=
QWFE__MAX; ++qwfeError)
compiler generated wrong code for condition check
0x8090981 mov0xffd7(%ebp),%edx
0x8090984 mov0xffd7(%ebp),%al
0x8090987 inc%edx
0x8090988 cmp$0x3,%al
0x809098a mov%edx,0xffd7(%ebp)
0x809098d jne0x8090940
That is, variable is incremented in parallel with loop condition check and
result of increment has effect to loop condition only on the next pass. This
causes the loop to execute one time more than required.
Compilation options used
-malign-double -fshort-enums -freg-struct-return -fno-exceptions -g -O3
-march=pentium -fno-rtti -fconserve-space
--
Summary: Wrong code generated for for()-loop with enumerated type
as index
Product: gcc
Version: 3.3.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oder at eleks dot lviv dot ua
GCC build triplet: x86
GCC host triplet: x86
GCC target triplet: x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27838
