[Bug target/30519] [4.3 Regression] Configuration mismatch -- extra parts
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-21 08:37 ---
This patch should work but I cannot test it.
Index: config.host
===
--- config.host (revision 120891)
+++ config.host (working copy)
@@ -192,6 +192,7 @@
;;
alpha*-*-linux*)
tmake_file=${tmake_file} alpha/t-crtfm
+extra_parts=$extra_parts crtfastmath.o
;;
alpha*-*-gnu*)
;;
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-01-21 08:37:01
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30519
[Bug c++/30524] New: Template argument is not recognized as a Type inside a template function.
Perfectly valid C++ syntax causes a compiler error when used inside a template
function. Both the Sun compiler and Microsoft compiler have no trouble with the
sample code shown below. Notice that the same code inside the non-template
function succeeds in compiling just fine. The GCC compiler appears to have
trouble figuring out that the expression resolves into a normal data type. The
error I get from GCC is:
test23.cpp: In function `void THIS_FAILS(T)':
test23.cpp:19: error: type/value mismatch at argument 1 in template parameter
list for `templateclass T struct whatever'
test23.cpp:19: error: expected a type, got ` Ssizeof (func(var))::type'
test23.cpp:19: error: invalid type in declaration before ';' token
~
template typename T struct whatever {};
template int struct S;
template struct S1 { typedef char Array[ 1 ]; typedef char type; };
S1::Array func( const char );
void THIS_WORKS( char var )
{
whatever S sizeof( func( var ) ) ::typetemporary;
}
template typename T
void THIS_FAILS( T var )
{
whatever S sizeof( func( var ) ) ::typetemporary;
}
--
Summary: Template argument is not recognized as a Type inside a
template function.
Product: gcc
Version: 3.4.6
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: SSacek at appsecinc dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30524
[Bug c++/30524] Template argument is not recognized as a Type inside a template function.
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-21 08:43 --- You missed the typename keyword which is required to figure out if S sizeof( func( var ) ) ::type is really a type or a variable. Read also http://gcc.gnu.org/gcc-3.4/changes.html . -- 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=30524
[Bug rtl-optimization/30467] [4.3 regression] Bootstrap failure: ICE in ifcvt.c
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-01-21 08:49 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30467
[Bug middle-end/30521] if (i == n) ++i; or i += i == n;?
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-21 08:54 --- I think this has been fixed already, for PPC with 4.0.2, we get: _f: mr r2,r3 addi r3,r3,1 cmpw cr7,r3,r4 bnelr cr7 addi r3,r2,2 blr .align 2 .p2align 4,,15 .globl _f1 _f1: addi r3,r3,1 xor r0,r3,r4 subfic r0,r0,0 addze r0,r3 mr r3,r0 blr While on the trunk we get: _f: addi r3,r3,1 xor r0,r3,r4 subfic r0,r0,0 addze r0,r3 mr r3,r0 blr .align 2 .globl _f1 _f1: addi r3,r3,1 xor r0,r3,r4 subfic r0,r0,0 addze r0,r3 mr r3,r0 blr -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30521
[Bug c/30475] assert(int+100 int) optimized away
--- Comment #30 from pinskia at gcc dot gnu dot org 2007-01-21 08:58
---
GCC is not going to change. There is no reason why you can't either use
-fwrapv or change the security checks to be before the overflow happens. There
are now good reasons why -fwrapv is not on by default, if you look at:
int f(int max, int *t)
{
int i;
for(i = 0;i=max;i++)
{
if (i0) return 1;
t[i]++;
}
return 0;
}
The if (i0) should always be removed as i can never be negative.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||WONTFIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug middle-end/30503] ICE using phase 2 bootstrap output cc1 on tree.c
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Status|UNCONFIRMED |WAITING Keywords||build http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30503
[Bug libstdc++/30449] Missing overloads (specializations) in stl_algobase.h
--- Comment #1 from paolo at gcc dot gnu dot org 2007-01-21 09:57 --- Subject: Bug 30449 Author: paolo Date: Sun Jan 21 09:57:42 2007 New Revision: 121027 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121027 Log: 2007-01-21 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/30449 (fill, fill_n) * include/bits/stl_algobase.h (__fill_aux(wchar_t*, wchar_t*, const wchar_t), __fill_n_aux(wchar_t*, _Size, const wchar_t)): New. (fill(signed char*, signed char*, const signed char), fill(unsigned char*, unsigned char*, const unsigned char), fill(char*, char*, char), fill_n(signed char*, _Size, const signed char), fill_n(unsigned char*, _Size, const unsigned char), fill_n(char*, _Size, char)): Rename to __*_aux. (__fill_normal, __fill_n_normal): New, call the latter. (fill, fill_n): Adjust, call the latter. * testsuite/25_algorithms/fill/4.cc: New. * testsuite/25_algorithms/fill/5.cc: New. Added: trunk/libstdc++-v3/testsuite/25_algorithms/fill/4.cc trunk/libstdc++-v3/testsuite/25_algorithms/fill/5.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_algobase.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30449
[Bug libfortran/30525] New: character comparisons with padding
The results should be consistent. g77 gets this right. $ cat char-comparison.f program main character*2 c2 character*1 c1, c3, c4 C C Comparison between char(255) and space padding C c2 = 'a' // char(255) c1 = 'a' print *, c2 .gt. c1 C C Comparison between char(255) and space C c3 = ' ' c4 = char(255) print *,c4 .gt. c3 end $ gfortran char-comparison.f ./a.out F T $ g77 char-comparison.f ./a.out T T -- Summary: character comparisons with padding Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org OtherBugsDependingO 19292 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30525
[Bug libfortran/30525] character comparisons with padding
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-01-21 11:31 --- A signed issue in compare_string. I'll also have to check front end constant folding for this... -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-21 11:31:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30525
[Bug target/30517] Inefficient address calculation on i386
--- Comment #1 from ubizjak at gmail dot com 2007-01-21 11:38 --- (In reply to comment #0) gcc with -Os -fno-PIC generates: movb$38, (%ebx,%edx)# 45*movqi_1/7 [length = 4] leal(%ebx,%edx), %eax # 122 *lea_1 [length = 3] movb$108, 1(%eax) # 48*movqi_1/7 [length = 4] movb$116, 2(%eax) # 50*movqi_1/7 [length = 4] movb$59, 3(%eax)# 52*movqi_1/7 [length = 4] addl$4, %edx# 54*addsi_1/1 [length = 3] movb$38, (%ebx,%edx)# 61*movqi_1/7 [length = 4] movb$103, 1(%edx,%ebx) # 64*movqi_1/7 [length = 5] movb$116, 2(%edx,%ebx) # 67*movqi_1/7 [length = 5] movb$59, 3(%edx,%ebx) # 70*movqi_1/7 [length = 5] addl$4, %edx# 71*addsi_1/1 [length = 3] I think this is due to address cost calculation, which returns the same cost for different complex addressing modes. Current costs are (taken from ivopts tree dump): Address costs: index costs 2 sym + index costs 1 var + index costs 3 sym + var + index costs 2 cst + index costs 1 sym + cst + index costs 1 var + cst + index costs 2 sym + var + cst + index costs 2 rat * index costs 2 sym + rat * index costs 1 var + rat * index costs 3 sym + var + rat * index costs 2 cst + rat * index costs 1 sym + cst + rat * index costs 1 var + cst + rat * index costs 2 sym + var + cst + rat * index costs 2 Unfortunatelly, changing address costs has tendency to create worse code in other places (for example - offset is moved into a register and reg+reg access is used insted of reg+offset access). The second is the same size as the first at the moment, but should be transformed into the same thing. If they are the same size (and there is no speed impact), there is actually no point to expect that they should compile to the same thing. BTW: similar effect of address cost can be seen in PR/24669. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30517
[Bug target/30518] error from system header file
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-01-21 11:43
---
This is a real MacOS bug. Using the Apple compiler I can reproduce it using the
following (on 10.4). I don't know if it should be kept open in the GCC bugzilla
(for a possible fixinclude patch) or if getting it into the Apple radar
(#4944229) is enough.
$ cat a.c
#include sys/resource.h
int main (void) { return 0; }
$ gcc -isysroot /Developer/SDKs/MacOSX10.3.9.sdk a.c
In file included from a.c:1:
/Developer/SDKs/MacOSX10.3.9.sdk/usr/include/sys/resource.h:81: error: field
ru_utime has incomplete type
/Developer/SDKs/MacOSX10.3.9.sdk/usr/include/sys/resource.h:82: error: field
ru_stime has incomplete type
/Developer/SDKs/MacOSX10.3.9.sdk/usr/include/sys/resource.h:119: error: parse
error before int32_t
/Developer/SDKs/MacOSX10.3.9.sdk/usr/include/sys/resource.h:124: error: parse
error before rlim_t
/Developer/SDKs/MacOSX10.3.9.sdk/usr/include/sys/resource.h:130: error: parse
error before fixpt_t
/Developer/SDKs/MacOSX10.3.9.sdk/usr/include/sys/resource.h:132: error: parse
error before } token
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||shebs at apple dot com, mrs
||at apple dot com, echristo
||at apple dot com, dalej at
||apple dot com
Status|UNCONFIRMED |NEW
Component|libfortran |target
Ever Confirmed|0 |1
Keywords||rejects-valid
Known to fail||4.0.1 4.2.0 4.3.0
Last reconfirmed|-00-00 00:00:00 |2007-01-21 11:43:09
date||
Summary|failed to build libgfortran |error from system header
|in gcc-4.3-20070119 on OSX |file
|10.3.9 |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30518
[Bug c/30475] assert(int+100 int) optimized away
--- Comment #31 from andreas at andreas dot org 2007-01-21 12:23 --- And who will go over the existing millions lines of code, and verify the overflow checks everywhere? Or add -fwrapv to all the Makefiles for unaidited code? Obviously not you. It seems to be easier to pretend you're not responsible for the next security bug in Linux. I'm still amazed that for the gcc maintainers, performance seems to be more important than security of the existing code base. I'm even more amazed that they seem to be unable to do some benchmarks to show that they have a point, apart from some made-up examples. Why is Microsoft willing and able to do such changes to Visual Studio, and you are not? -- andreas at andreas dot org changed: What|Removed |Added CC||andreas at andreas dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug c++/30277] bit-field: wrong overload resolution
--- Comment #2 from joseph at codesourcery dot com 2007-01-21 12:28 --- Subject: Re: bit-field: wrong overload resolution On Sun, 21 Jan 2007, bangerth at dealii dot org wrote: I only have the C99 standard, and there I read in 6.3.1.1 p2 that only those variables are promoted to int that are of smaller size. C and C++ handle bit-fields differently. C99 text about bit-fields is irrelevant and misleading for C++. In C++03, integral promotions for bit-fields are specified in 4.5 [conv.prom] (note these are can be converted, as part of a conversion sequence; the underlying concepts are not those of C), and before any such conversion a C++ bit-field has the declared type as per 9.6 [class.bit] rather than a special type as in C. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30277
[Bug c/30475] assert(int+100 int) optimized away
--- Comment #32 from andreas at andreas dot org 2007-01-21 12:49 --- Oh, and besides, proper range analysis could optimize the above code, even in the presence of correct (and I mean LIA-1) overflow behaviour of signed ints. It seems you still didn't even manage to come up with an example where is optimization matters which is not eliminate bounds checks during array access. And the single reason bounds checks are done is to prevent buffer overflow exploits. So if you optimize that away in a situation where a LIA-1 compliant compiler would not, you're creating a security problem. I don't see why making make_range in fold-const.c behave in compliance with LIA-1 should be a problem, especially not performance-wise. It would really make a lot of people sleep better in the night. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug c/30475] assert(int+100 int) optimized away
--- Comment #33 from felix-gcc at fefe dot de 2007-01-21 13:53 --- so now you give us... a straw man? The range analysis has nothing to do with just assuming integers can't wrap. But more to the point: the Intel compiler does not assume signed integers can't wrap, and IT STILL PRODUCES MUCH FASTER CODE THAN GCC. So all your hand waiving about how this optimization is good for performance is utterly destroyed by the Intel compiler. And please let me express my shock how you tell me to my face that the only example where this optimization has measurable impact (I didn't actually try it, but I will) is when it optimizes away range checks in C++ vectors. Which, you know, exist solely because THERE ARE NO RANGE CHECKS IN C ARRAYS and, uh, C++ is much better and people are told to use C++ vectors instead BECAUSE THEY HAVE RANGE CHECKS and now you tell me that your optimization removes those. Whoa, what an improvement, man. Now you convinced me. Not that the optimization is useful, mind you, but that you are a marauding saboteur sent by the evil minions at Microsoft on a mission to make open source software look bad. -- felix-gcc at fefe dot de changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug c++/30526] New: min/max issues when limits and windows.h headers are included
/usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:290: error: expected ';' before 'throw' /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:292: error: expected `;' before 'static' /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:292: error: expected ';' before 'throw' /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:295: error: expected `;' before 'static' /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:320: error: expected ';' before 'throw' /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:322: error: expected `;' before 'static' /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:322: error: expected ';' before 'throw' /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:325: error: expected `;' before 'static' /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:374: error: expected ';' before 'throw' /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:376: error: expected `;' before 'static' /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:376: error: expected ';' before 'throw' /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:379: error: expected `;' before 'static' /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:425: error: expected ';' before 'throw' /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:427: error: expected `;' before 'static' /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:427: error: expected ';' before 'throw' /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:430: error: expected `;' before 'static' /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:476: error: expected ';' before 'throw' /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:478: error: expected `;' before 'static' /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:478: error: expected ';' before 'throw' /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:481: error: expected `;' before 'static' /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:527: error: expected ';' before 'throw' /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:529: error: expected `;' before 'static' /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:529: error: expected ';' before 'throw' /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:532: error: expected `;' before 'static' /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:578: error: expected ';' before 'throw' /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:580: error: expected `;' before 'static' /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:580: error: expected ';' before 'throw' /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:583: error: expected `;' before 'static' /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:629: error: expected ';' before 'throw' /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:631: error: expected `;' before 'static' /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:631: error: expected ';' before 'throw' /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:634: error: expected `;' before 'static' /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:680: error: expected ';' before 'throw' /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:682: error: expected `;' before 'static' /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:682: error: expected ';' before 'throw' /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:685: error: expected `;' before 'static' /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:731: error: expected ';' before 'throw' /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:733: error: expected `;' before 'static' /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:733: error: expected ';' before 'throw'
[Bug c++/30526] min/max issues when limits and windows.h headers are included
--- Comment #1 from Christoph_vW at reactos dot org 2007-01-21 14:07 --- link to the sourcecode: http://svn.reactos.org/svn/reactos/trunk/reactos/base/applications/network/telnet/ -- Christoph_vW at reactos dot org changed: What|Removed |Added CC||Christoph_vW at reactos dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30526
[Bug c/30527] New: Use of input/output operands in __asm__ templates not fully documented
It seems that I can use %k0 (rather than just %0) in an asm template to force the (register) operand to long size (i.e. a value in %al referenced as %k0 comes out as %eax in the generated assembly). This doesn't seem to be documented anywhere. I presume there may be other such character prefixes which have similar functions. -- Summary: Use of input/output operands in __asm__ templates not fully documented Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: davmac at davmac dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30527
[Bug c/30527] Use of input/output operands in __asm__ templates not fully documented
--- Comment #1 from davmac at davmac dot org 2007-01-21 14:15 --- I should add that I'm prepared to send a patch for the documentation if someone will tell me what the operands are and what they do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30527
[Bug c++/30526] min/max issues when limits and windows.h headers are included
--- Comment #2 from Christoph_vW at reactos dot org 2007-01-21 14:26 --- Created an attachment (id=12926) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12926action=view) keytrans.ii -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30526
[Bug c++/30526] min/max issues when limits and windows.h headers are included
--- Comment #3 from Christoph_vW at reactos dot org 2007-01-21 14:30 --- with -v mingw32-g++ -c base/applications/network/telnet/src/keytrans.cpp -o obj-i386/base/applications/network/telnet/src/tkeydef.o -Ibase/applications/network/telnet -D__USE_W32API -D__REACTOS__ -I. -Iinclude -Iinclude/psdk -Iinclude/crt -Iinclude/ddk -Iinclude/GL -Iinclude/ndk -Iinclude/reactos -Iinclude/reactos/libs -D_M_IX86 -D_X86_ -D__i386__ -D_REACTOS_ -DDBG -Wall -Wpointer-arith -Os -Wno-strict-aliasing -ftracer -momit-leaf-frame-pointer -mpreferred-stack-boundary=2 -g -pipe -fno-optimize-sibling-calls -v -save-temps mingw32-g++: warning: -pipe ignored because -save-temps specified Using built-in specs. Target: mingw32 Configured with: /home/Christoph/Desktop/source/gcc-4.2-20070117//configure -v --prefix=/usr/local/mingw32 --target=mingw32 --with-headers=/usr/local/mingw32/mingw32/include --with-gcc --with-gnu-ld --with-gnu-as --enable-threads --disable-nls --enable-languages=c,c++,objc,java --disable-win32-registry --disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchronization --enable-libstdcxx-debug Thread model: win32 gcc version 4.2.0 20070117 (prerelease) /usr/local/mingw32/libexec/gcc/mingw32/4.2.0/cc1plus -E -quiet -v -Ibase/applications/network/telnet -I. -Iinclude -Iinclude/psdk -Iinclude/crt -Iinclude/ddk -Iinclude/GL -Iinclude/ndk -Iinclude/reactos -Iinclude/reactos/libs -D__USE_W32API -D__REACTOS__ -D_M_IX86 -D_X86_ -D__i386__ -D_REACTOS_ -DDBG base/applications/network/telnet/src/keytrans.cpp -momit-leaf-frame-pointer -mpreferred-stack-boundary=2 -mtune=i386 -Wall -Wpointer-arith -Wno-strict-aliasing -ftracer -fno-optimize-sibling-calls -fworking-directory -Os -fpch-preprocess -o keytrans.ii ignoring nonexistent directory /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/sys-include #include ... search starts here: #include ... search starts here: base/applications/network/telnet . include include/psdk include/crt include/ddk include/GL include/ndk include/reactos include/reactos/libs /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0 /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/mingw32 /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/backward /usr/local/mingw32/lib/gcc/mingw32/4.2.0/include /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include End of search list. In file included from /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/ext/type_traits.h:42, from /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/bits/stl_algobase.h:73, from /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/bits/char_traits.h:46, from /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/string:46, from base/applications/network/telnet/src/tkeymap.h:7, from base/applications/network/telnet/src/keytrans.h:25, from base/applications/network/telnet/src/keytrans.cpp:60: /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:290:22: error: macro min requires 2 arguments, but only 1 given /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:292:22: error: macro max requires 2 arguments, but only 1 given /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:320:23: error: macro min requires 2 arguments, but only 1 given /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:322:23: error: macro max requires 2 arguments, but only 1 given /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:374:23: error: macro min requires 2 arguments, but only 1 given /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:376:23: error: macro max requires 2 arguments, but only 1 given /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:425:30: error: macro min requires 2 arguments, but only 1 given /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:427:30: error: macro max requires 2 arguments, but only 1 given /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:476:32: error: macro min requires 2 arguments, but only 1 given /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:478:32: error: macro max requires 2 arguments, but only 1 given /usr/local/mingw32/lib/gcc/mingw32/4.2.0/../../../../mingw32/include/c++/4.2.0/limits:527:26: error: macro min requires 2 arguments, but only 1 given
[Bug libstdc++/30526] min/max issues when limits and windows.h headers are included
--- Comment #4 from pcarlini at suse dot de 2007-01-21 15:13 --- Already fixed in mainline... let's fix it in 4_2-branch too, then. *** This bug has been marked as a duplicate of 29989 *** -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30526
[Bug libstdc++/29989] missed #undef min/max in limits
--- Comment #7 from pcarlini at suse dot de 2007-01-21 15:13 --- *** Bug 30526 has been marked as a duplicate of this bug. *** -- pcarlini at suse dot de changed: What|Removed |Added CC||Christoph_vW at reactos dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29989
[Bug libstdc++/29989] missed #undef min/max in limits
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-01-21 15:19 --- Can we have this fixed in 4.2.0 as well? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29989
[Bug libstdc++/29989] missed #undef min/max in limits
--- Comment #9 from pcarlini at suse dot de 2007-01-21 15:23 --- (In reply to comment #8) Can we have this fixed in 4.2.0 as well? Just wait 10 mins... ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29989
[Bug libstdc++/29989] missed #undef min/max in limits
--- Comment #10 from paolo at gcc dot gnu dot org 2007-01-21 15:34 --- Subject: Bug 29989 Author: paolo Date: Sun Jan 21 15:34:16 2007 New Revision: 121029 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121029 Log: 2007-01-21 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/29989 * include/bits/c++config: #undef min and max. * include/bits/stl_algobase.h: Remove min and max #undefs. * testsuite/18_support/numeric_limits/29989.cc: New. Modified: branches/gcc-4_2-branch/libstdc++-v3/ChangeLog branches/gcc-4_2-branch/libstdc++-v3/include/bits/c++config branches/gcc-4_2-branch/libstdc++-v3/include/bits/stl_algobase.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29989
[Bug libstdc++/29989] missed #undef min/max in limits
-- pcarlini at suse dot de changed: What|Removed |Added Known to fail|4.1.2 4.2.0 |4.1.2 Target Milestone|4.3.0 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29989
[Bug libstdc++/29989] missed #undef min/max in limits
--- Comment #11 from paolo at gcc dot gnu dot org 2007-01-21 15:36 --- Subject: Bug 29989 Author: paolo Date: Sun Jan 21 15:36:27 2007 New Revision: 121030 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121030 Log: 2007-01-21 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/29989 * include/bits/c++config: #undef min and max. * include/bits/stl_algobase.h: Remove min and max #undefs. * testsuite/18_support/numeric_limits/29989.cc: New. Added: branches/gcc-4_2-branch/libstdc++-v3/testsuite/18_support/numeric_limits/29989.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29989
[Bug other/23572] No warning for assigning a value to a 'float' variable that overflows with option -Wextra
--- Comment #7 from patchapp at dberlin dot org 2007-01-21 16:01 --- Subject: Bug number PR 23572 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01730.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23572
[Bug bootstrap/30511] False array bound check causes gcc failed to boostrap
--- Comment #7 from mueller at gcc dot gnu dot org 2007-01-21 16:12 --- Subject: Bug 30511 Author: mueller Date: Sun Jan 21 16:12:10 2007 New Revision: 121032 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121032 Log: 2007-01-21 Dirk Mueller [EMAIL PROTECTED] PR bootstrap/30511 * tree-vrp.c (check_array_bounds): do not warn about ADDR_EXPR's of ARRAY_REF's which are immediately used in binary expressions. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30511
[Bug libfortran/30015] Intrinsic date_and_time can go back in time
--- Comment #4 from burnus at gcc dot gnu dot org 2007-01-21 16:16 --- Subject: Bug 30015 Author: burnus Date: Sun Jan 21 16:16:10 2007 New Revision: 121033 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121033 Log: 2006-12-09 Tobias Burnus [EMAIL PROTECTED] PR libfortran/30015 * intrinsics/date_and_time.c (date_and_time): Fix case where time can go backwards. * configure.ac: Remove AC_TRY_RUN test for timezone in gettimeofday. * acinclude.m4: Ditto. * configure: Regenerate. * config.h.in: Regenerate. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/acinclude.m4 trunk/libgfortran/config.h.in trunk/libgfortran/configure trunk/libgfortran/configure.ac trunk/libgfortran/intrinsics/date_and_time.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30015
[Bug c/30475] assert(int+100 int) optimized away
--- Comment #34 from pinskia at gcc dot gnu dot org 2007-01-21 16:31 --- The range analysis has nothing to do with just assuming integers can't wrap. Partly wrong, range analysis is helped by the fact assuming integers can't wrap. If range analysis dependent on pointer overflow being undefined, would you complain then, I bet you would. Intel's compiler assumes integer overflow is undefined but if you think it does not, then fine, most if not all commerial compilers assume that. Unlike them, we give you an option to assume otherwise. I don't see why making make_range in fold-const.c It is already if you use -fwrapv. The problem here is that the people who added these security checks in the first place did not know C. So either GCC can be changed or these programs can be fixed by the way comp.lang.c faq recommends or by using -fwrapv. If we change GCC, you punish the people who actually write defined C so that is out of the question. I think the real issue that some of the security folks want to check after the fact that something happened instead of before it happend which is the correct way to do anything. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug inline-asm/30527] Use of input/output operands in __asm__ templates not fully documented
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-21 16:37 --- Every target have slightly different operand modifiers. They are usually documented in config/*/*.md or config/*/*.c, but I think it is incorrect to documented them for real because people will then abuse them. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |inline-asm Keywords||documentation http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30527
[Bug libstdc++/29722] Linking with libsupc++.a creates link time undefined references
--- Comment #7 from pcarlini at suse dot de 2007-01-21 16:39 --- Benjamin, I'm noticing that the hard-coded path on top of the new cxx_runtime_only_linkage.cc test doesn't play well with multilib and fails at link-time, see, e.g., for unix/-m32 on x86_64-linux: http://gcc.gnu.org/ml/gcc-testresults/2007-01/msg00722.html This is the error I'm seeing, can we do something about it? /usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld: skipping incompatible ../libsupc++/.libs/libsupc++.a when searching for -lsupc++ /usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld: cannot find -lsupc++ collect2: ld returned 1 exit status compiler exited with status 1 output is: /usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld: skipping incompatible ../libsupc++/.libs/libsupc++.a when searching for -lsupc++ /usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld: cannot find -lsupc++ collect2: ld returned 1 exit status -- pcarlini at suse dot de changed: What|Removed |Added CC||pcarlini at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29722
[Bug bootstrap/30511] False array bound check causes gcc failed to boostrap
--- Comment #8 from mueller at gcc dot gnu dot org 2007-01-21 16:52 --- Fixed for 4.3. -- mueller at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30511
[Bug c/9049] No support for selective enabling/disabling of warnings
--- Comment #10 from manu at gcc dot gnu dot org 2007-01-21 17:24 --- There is some initial support for this: http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9049
[Bug libgcj/30513] [4.3 Regression] Bootstrap failure with libgcj on sparc-sun-solaris2.10
--- Comment #5 from tromey at gcc dot gnu dot org 2007-01-21 17:18 --- Interesting -- I would not have thought of trying -ansi. I wonder if this approach would really work for us. I wonder sometime in the future -ansi will turn off other GNU extensions that we use. Andreas T. had seen this problem a while back; the approach we had talked about then was adding '#undef sun' somewhere... perhaps posix.h. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30513
[Bug c/30475] assert(int+100 int) optimized away
--- Comment #35 from andreas at andreas dot org 2007-01-21 17:29 --- (In reply to comment #34) The range analysis has nothing to do with just assuming integers can't wrap. Partly wrong, range analysis is helped by the fact assuming integers can't wrap. And in those cases then leads to code that does unexpected things, such as breaking existing security checks. I don't see why making make_range in fold-const.c It is already if you use -fwrapv. No, it is not. What happens is that make_range will generate invalid ranges in any case, and then optimizations depending on those ranges will be skipped when -fwrapv is specified. (Please correct me if I'm reading the code wrong, even though I'm maintaining an open source compiler myself, I don't have much experience reading gcc code.) What this means is that in the example you posted above, even though the compiler *could* compute a correct range and properly fold the if statement even given LIA-1 compliant overflow behaviour, gcc will skip the optimization when passed -fwrapv. After reading the code, I can certainly see why making -fwrapv is something you'd rather avoid: it makes a lot of optimizations go down the drain. But: this wouldn't have to happen if you fixed make_range to do something sensible instead. I wonder why this didn't jump right into the face of the person who implemented -fwrapv, it must have been a real pain to track down all the usages. The problem here is that the people who added these security checks in the first place did not know C. So either GCC can be changed or these programs can be fixed by the way comp.lang.c faq recommends or by using -fwrapv. If we change GCC, you punish the people who actually write defined C so that is out of the question. Well, maybe they didn't. I did a non-representative survey with the C programmers I know: everybody assumed overflow of signed ints would behave as it does for the underlying machine representation. Not a single one was aware of the danger. And we're talking of people with 20+ years of professional experience in the field here. And I think people who do know can be expected to read the gcc manual to figure out that there were a -fnowrapv option to make their code go a wee bit faster. Did I mention that I have yet to see a convincing example of a case where undefinedness of signed overflow actually makes code go faster that isn't per definition a security problem? Especially after having learned from reading the gcc code that -fwrapv turns off a whole lot more optimizations than it has to? I think the real issue that some of the security folks want to check after the fact that something happened instead of before it happend which is the correct way to do anything. No, I would call any security expert who refuses to learn that there is a problem with signed overflow and how to check for that correctly an idiot. The issue here is really how to deal with the existing body of code out there that was written in the implicit assumption of LIA-1 compliant behaviour. This is about risk management for all the Linux systems out there. It is not about whose fault is it. It's about Houston, we have a problem, and need it fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug c/30475] assert(int+100 int) optimized away
--- Comment #36 from felix-gcc at fefe dot de 2007-01-21 17:47 --- I think the actual root issue here is that the gcc argumentation is fundamentally wrong. I am complaining that gcc removes my checks, not that signed integer overflow is undefined. Also, note that it is everything BUT undefined. Adding 5 to INT_MAX will create a negative number. It behaves EXACTLY as expected by basically everyone. And if gcc decided that it is undefined and it creates INT_MAX again, then I would be happy, too. No problem with that whatsoever. All I want is gcc to be consistent. gcc DOES create a negative number. And then it removes an if statement asking whether the number is negative. That can not be explained away with signed int overflow being undefined. Let's write it in separate statements, so even the biggest idiot in the world can understand the issue. int a,b,c; a=INT_MAX; /* statement ONE */ b=a+2; /* statement TWO */ c=(ba); /* statement THREE */ My issue with gcc is that it removes statement THREE. Your argument about undefinedness is about statement TWO. Following your argumentation, gcc is allowed to return 23 in statement TWO. But it still not allowed to generate no code for statement THREE. In my opinion, people who don't understand this most basic of logic should not be let NEAR the code of a compiler, let alone a compiler millions of people are depending on. Now, to summarize. We destroyed your complete argument, including wild assertions you happened to make during its course. We gave evidence that the current behavior is bad for a lot of people. What more do you need to see reason? Do you want a bribe? Some more crack? Hookers, maybe? I don't see what else could be discussed about the matter. I will refrain from wasting time on trying to find new way to explain the obvious to you. From now on, I'll just auto-reopen the bug and say see previous arguments. -- felix-gcc at fefe dot de changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug c++/12242] g++ should warn about out-of-range int-enum conversions
--- Comment #8 from manu at gcc dot gnu dot org 2007-01-21 17:47 --- I was thinking about adding this to Wconversion. But perhaps it is more appropriate for Wundefined. After all, the value may change or not depending on the particular implementation, since it is undefined. Gabriel, should I add it to the list of Wundefined? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12242
[Bug libfortran/30525] character comparisons with padding
--- Comment #2 from tkoenig at gcc dot gnu dot org 2007-01-21 18:02 --- Here's a patch: http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01726.html Constant folding by the front end is OK, BTW. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30525
[Bug c++/30357] Enum typecast warning
--- Comment #2 from manu at gcc dot gnu dot org 2007-01-21 18:08 --- I am not sure this is such a good idea. A casting typically means I want to really do this. GCC normally suppress warnings when casting is added. A warning when you assign when enum type to another and the first enum is not a subset of the second could still be useful, but the casting should prevent the warning. I am not sure what happens for such assignment, is it undefined behaviour? If so, perhaps it should be warned by Wundefined. If not, then perhaps we could add it to Wconversion. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30357
[Bug c/30475] assert(int+100 int) optimized away
--- Comment #37 from pluto at agmk dot net 2007-01-21 18:16 --- (In reply to comment #36) Now, to summarize. you're leading to undefined behaviour - do you understand this simple fact? in such cases compiler can do *anything* with your code. current behavior is bad for a lot of people. it's the highest time to read the standard and use unsigned types or -fwrapv. I'll just auto-reopen the bug and say see previous arguments. you're violating standard, so stop screaming. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug target/30518] error from system header file
--- Comment #7 from mrs at apple dot com 2007-01-21 18:19 --- Yes, this is a bug, a fixincludes should be able to fix it, yes, that should be done. At Apple, we use the fixincludes mechanism to build the SDK bits, so that is eactly the right fix for us as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30518
[Bug target/30518] error from system header file
--- Comment #8 from mrs at apple dot com 2007-01-21 18:21 --- radr://4944229 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30518
[Bug fortran/30528] New: INTEGER(2) overflow
These lines cannot be compiled with gfortran (GNU Fortran 95 (GCC) 4.2.0 20070117 (prerelease)) on a Mac OS X 10.4 (powerpc): INTEGER*2 IWD1 IWD1 = 32768 END It fails with IWD1 = 32768 1 Error: Arithmetic overflow converting INTEGER(4) to INTEGER(2) at (1) This works for g77 (GNU Fortran (GCC) 3.4.3) as well as with gfortran (and g77) on Mac OS X 10.4 on intel (i686-apple-darwin8). All fortran compilers have been compiled within the Fink framework. -- Summary: INTEGER(2) overflow Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: remi dot mommsen at gmx dot net GCC build triplet: powerpc-apple-darwin8 GCC host triplet: powerpc-apple-darwin8 GCC target triplet: powerpc-apple-darwin8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30528
[Bug c++/29018] empty enum accepted
--- Comment #3 from manu at gcc dot gnu dot org 2007-01-21 18:24 --- So, do we want to fix those testcases or do we want to keep ignoring empty enums? -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29018
[Bug target/27067] Compile errors with multiple inheritance where the stdcall attribute is applied to virtual functions.
--- Comment #7 from Christoph_vW at reactos dot org 2007-01-21 18:42 --- Created an attachment (id=12927) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12927action=view) Updated patch against the gcc-4_2-branch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27067
[Bug other/30529] New: Incompatible __dec_byte_swap declaration
bash-3.1$ grep __dec_byte_swap libdecnumber/*.c gcc/config/dfp-bit.c libdecnumber/decLibrary.c:uint32_t __dec_byte_swap (uint32_t); libdecnumber/decLibrary.c:__dec_byte_swap (uint32_t in) gcc/config/dfp-bit.c:extern unsigned long __dec_byte_swap (unsigned long); long can be uint32_t on 64bit targets. -- Summary: Incompatible __dec_byte_swap declaration Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30529
[Bug other/30530] New: dfp.c assumes DPD encoding
dfp.c uses the sig field to store encoded value and only uses access routines in libdecnumber to manipulate it so that dfp.c can be encoding neutral. But there are 659 decimal128 *d128; 660 *r = *op0; 661 d128 = (decimal128 *) r-sig; 662 /* Flip high bit. */ 663 d128-bytes[0] ^= 1 7; 664 /* Keep sign field in sync. */ 665 r-sign ^= 1; 671 decimal128 *d128; 672 *r = *op0; 673 d128 = (decimal128 *) r-sig; 674 /* Clear high bit. */ 675 d128-bytes[0] = 0x7f; 676 /* Keep sign field in sync. */ 677 r-sign = 0; 714 if (sign) 715 r-sig[0] |= 0x8000; They won't work with BID encoding. -- Summary: dfp.c assumes DPD encoding Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30530
[Bug other/30529] Incompatible __dec_byte_swap declaration
--- Comment #1 from hjl at lucon dot org 2007-01-21 19:14 --- I(In reply to comment #0) bash-3.1$ grep __dec_byte_swap libdecnumber/*.c gcc/config/dfp-bit.c libdecnumber/decLibrary.c:uint32_t __dec_byte_swap (uint32_t); libdecnumber/decLibrary.c:__dec_byte_swap (uint32_t in) gcc/config/dfp-bit.c:extern unsigned long __dec_byte_swap (unsigned long); long can be uint32_t on 64bit targets. I meant long can be uint64_t on 64bit targets. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30529
[Bug target/30517] Inefficient address calculation on i386
--- Comment #2 from astrange at ithinksw dot com 2007-01-21 19:25 --- Created an attachment (id=12928) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12928action=view) example source code Had a bit of browser trouble; here's the code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30517
[Bug c/30475] assert(int+100 int) optimized away
--- Comment #38 from rguenth at gcc dot gnu dot org 2007-01-21 19:46 --- (in reply to comment #35) It is true that in the face of -fwrapv gcc does not optimize as good as it does for unsigned numbers (that wrap, too). I am in the progress of fixing that for the value range propagation pass. You are of course welcome to fix it for make_range ;) (or maybe file an enhancement bug report for that, so we don't lose track of that issue) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug fortran/30528] INTEGER(2) overflow
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-01-21 20:11 --- The largest positive integer that can be represented by that kind type is 32767, so gfortran is correctly reporting an error. Use -fno-range-check to bypass this. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30528
[Bug c/30475] assert(int+100 int) optimized away
--- Comment #39 from pinskia at gcc dot gnu dot org 2007-01-21 20:14 --- No reason to keep this open as you are violating the C standard. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug fortran/30528] INTEGER(2) overflow
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-01-21 20:14 --- First, it should be noted that it's not legal code. Indeed, you might (or not) be surprised by the behaviour of the code in question: pito /tmp $ cat a.f INTEGER*2 IWD1 IWD1 = 32768 PRINT *, IWD1 END pito /tmp $ g77 a.f ./a.out -32768 This check is new in gfortran, the behaviour is intentional but can be specificaly disabled using -fno-range-check: $ gfortran -fno-range-check a.f ./a.out -32768 Closing bug report as INVALID. Making note to document this in the release notes. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED GCC build triplet|powerpc-apple-darwin8 | GCC host triplet|powerpc-apple-darwin8 | GCC target triplet|powerpc-apple-darwin8 | Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30528
[Bug fortran/20896] [4.2 and 4.1 only] ambiguous interface not detected
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-01-21 20:41 --- What is the status on this now? After reviewing the standard I think I am in agreement with what this patch does. The standard is not exactly straight forward interpret. Do we have consensus yet on this? If so, I will commit for Paul. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20896
[Bug fortran/30531] New: ICE in fold_convert
The attached file produces the error: [EMAIL PROTECTED] bugtest]$ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.2-20070117/configure --prefix=/usr/local/gcc42 --with-mpfr=/home/travel/GCC/BUILDS/mpfr --with-gmp-lib=/home/travel/GCC/BUILDS/gmp/lib/ --with-gmp=/home/travel/GCC/BUILDS/gmp Thread model: posix gcc version 4.2.0 20070117 (prerelease) [EMAIL PROTECTED] bugtest]$ gfortran -c ice-foldc.f90 ice-foldc.f90: In function 'foo_init': ice-foldc.f90:42: internal compiler error: in fold_convert, at fold-const.c:2109 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: ICE in fold_convert Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sfilippone at uniroma2 dot it GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30531
[Bug libfortran/30525] character comparisons with padding
--- Comment #3 from tkoenig at gcc dot gnu dot org 2007-01-21 20:52 --- Subject: Bug 30525 Author: tkoenig Date: Sun Jan 21 20:51:53 2007 New Revision: 121035 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121035 Log: 2007-01-21 Thomas Koenig [EMAIL PROTECTED] PR libfortran/30525 * intrinsics/string_intrinsics.c(compare_string): Make sure that comparisons are done unsigned. 2007-01-21 Thomas Koenig [EMAIL PROTECTED] PR libfortran/30525 * gfortran.dg/char_comparison_1.f: New test. Added: trunk/gcc/testsuite/gfortran.dg/char_comparison_1.f Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/string_intrinsics.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30525
[Bug other/30530] dfp.c assumes DPD encoding
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30530
[Bug bootstrap/30510] [4.3 Regression] Gcc failed to bootstrap
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||build Summary|Gcc failed to bootstrap |[4.3 Regression] Gcc failed ||to bootstrap Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30510
[Bug middle-end/30506] not sibcalling a function
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-01-21 21:10 --- I was wrong about this being tail called on PPC, though it should. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|target |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30506
[Bug tree-optimization/30493] [4.1 Regression] Unexpected compilation results: -O versus no optimization
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30493
[Bug preprocessor/8270] [4.0/4.1/4.2/4.3 Regression] back-slash white space newline with comments, no warning
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8270
[Bug c++/11987] [4.0/4.1/4.2/4.3 regression] Accepts-invalid with inherited nested type
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11987
[Bug c++/14179] [4.0/4.1/4.2/4.3 Regression] out of memory while parsing array with many initializers
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14179
[Bug target/15184] [4.0/4.1/4.2/4.3 Regression] Direct access to byte inside word not working with -march=pentiumpro
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15184
[Bug other/15082] [4.0/4.1/4.2/4.3 regression] Minor compilation problem for cross to Solaris 8
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15082
[Bug c++/14777] [4.0/4.1/4.2/4.3 Regression] typedef doesn't fully expose base class type
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14777
[Bug target/26560] [4.0/4.1 regression] mips: unable to find a register to spill in class 'FP_REGS'
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26560
[Bug target/29686] [4.1 Regression] ICE when building the kernel on ARM
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29686
[Bug tree-optimization/30175] [4.3 Regression] Runtime regressions with mem-ssa merge in Polyhedron and tramp3d-v4
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|Runtime regressions with|[4.3 Regression] Runtime |mem-ssa merge in Polyhedron |regressions with mem-ssa |and tramp3d-v4 |merge in Polyhedron and ||tramp3d-v4 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30175
[Bug other/29534] [4.1 Regression] ICE in gcc -O -ftrapv with decreasing array index
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29534
[Bug middle-end/29943] [4.2/4.3 Regression] gcc generate incorrect alias symbols for PPC
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29943
[Bug target/30472] [4.1 Regression] -gstabs, ICE in output_operand: invalid expression as operand
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30472
[Bug tree-optimization/16306] [4.0/4.1/4.2/4.3 Regression] restrict and copying pointers problem
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16306
[Bug tree-optimization/16913] [4.0/4.1/4.2/4.3 Regression] restrict does not make a difference
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16913
[Bug c++/17053] [4.0/4.1/4.2/4.3 Regression] Repo functionality partially broken on AIX (collect2.c)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17053
[Bug c++/17763] [4.0/4.1/4.2/4.3 Regression] Wrong context in error message for template parameter
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17763
[Bug libstdc++/17789] [4.0/4.1/4.2/4.3 Regression] Cannot 'make check' inside libstdc++-v3
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17789
[Bug tree-optimization/17863] [4.0/4.1/4.2/4.3 Regression] performance loss (not inlining as much??)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17863
[Bug debug/19192] [4.0/4.1/4.2/4.3 Regression] Current development gcc generates inaccurate line info for example code
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19192
[Bug middle-end/19988] [4.0/4.1/4.2/4.3 Regression] pessimizes fp multiply-add/subtract combo
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19988
[Bug preprocessor/20077] [4.0/4.1/4.2/4.3 Regression] GCC accepts macro definitions that fail a constraint
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20077
[Bug c/30475] assert(int+100 int) optimized away
--- Comment #40 from tromey at gcc dot gnu dot org 2007-01-21 21:52 --- I've read through the comments in this PR. I thought it would be useful to point out that a decision on how GCC will optimize in the absence of -fwrapv will not be decided by this PR. This change has been extensively discussed on the GCC list, and, really, that is the appropriate forum for this. So, even if this PR is constantly reopened, it won't be resolved via this route. If you do intend to bring this up again on the GCC list, please read the previous discussion before posting. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug c++/20209] [4.0 Regression] Missing warnings for aggregate has a partly bracketed initializer
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-01-21 21:52 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20209
[Bug preprocessor/20285] [4.0/4.1/4.2/4.3 Regression] gcc -E - . gives a misleading error message
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20285
[Bug c++/20681] [4.0/4.1/4.2/4.3 Regression] wrong control reaches warning with switches
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20681
[Bug target/21081] [4.0 Regression] internal compiler error: verify_stmts failed.
--- Comment #22 from pinskia at gcc dot gnu dot org 2007-01-21 21:56 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21081
[Bug other/30530] dfp.c assumes DPD encoding
--- Comment #1 from hjl at lucon dot org 2007-01-21 21:56 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01743.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30530
[Bug fortran/30531] ICE in fold_convert
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-01-21 21:56 --- Actually, there is no attachment :-) Could you send it, please? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30531
[Bug target/21169] [4.0 regression] ICE in reload_cse_simplify_operands with -fnon-call-exceptions -fPIC -O2
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-01-21 21:57 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21169
[Bug c++/21312] [4.0/4.1/4.2/4.3 Regression] Access violation diagnostic given twice
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21312
[Bug c/21343] [4.0/4.1/4.2/4.3 Regression] incompatible internal linkage declarations in different scopes not diagnosed
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21343
[Bug c/21659] [4.0/4.1/4.2/4.3 Regression] [unit-at-a-time] weak declaration must precede definition error missing at = O1
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21659
[Bug c/22297] [4.0/4.1/4.2/4.3 Regression] missing uninitialization warning
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22297
[Bug fortran/30407] Elemental functions in WHERE assignments wrongly rejected
--- Comment #4 from patchapp at dberlin dot org 2007-01-21 22:00 --- Subject: Bug number PR30407 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01744.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30407
[Bug c++/30332] [4.1/4.2/4.3 regression] bit-field: optimization BUG?
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30332
[Bug c++/30425] [4.0/4.1 Regression] ICE in type_dependent_expression_p, at cp/pt.c:12739
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30425
