Re: Bug in Instruction Combination procedure and RTL generation.
J.J. Garcia wrote: Hi all, I'm trying to debug a code optimization in gcc for an specific arch, to be more explicit it's for gcc 2.95.3 for Metaware ARC target architecture, i know the old release of compiler and i know there will not be lot of support about it, anyway im keep on trying..., The "bug" is still there in the most recent version of GCC, but AFAIK (I speak RTL, but I don't speak ARC assembly) the optimization is ok. The change is from: (set (reg:CC 61 cc) (compare:CC (reg/v:SI 69 [ n ]) (const_int 9 [0x9]))) (set (reg/v:SI 67 [ test_value ]) (if_then_else:SI (ltu (reg:CC 61 cc) (const_int 0 [0x0])) (const_int 69 [0x45]) (reg:SI 71))) to (set (reg:CC 61 cc) (compare:CC (reg/v:SI 69 [ n ]) (const_int 8 [0x9]))) (set (reg/v:SI 67 [ test_value ]) (if_then_else:SI (leu (reg:CC 61 cc) (const_int 0 [0x0])) (const_int 69 [0x45]) (reg:SI 71))) Testing < 9 is the same as testing <= 8. The assembly seems also ok, since ".ls" is the translation of the "leu" RTL code. By comparison, "ltu" would become "c". While unexpected, this change is done by GCC as part of "canonicalizing" expressions so that, for example, it could detect that "<= 8" and "< 9" are really testing the same condition. All this said, remember that the correct place to report a bug is the GCC bugzilla at http://gcc.gnu.org/bugzilla Paolo
Re: Bootstrap broken
Andrew Pinski wrote: Looks like __used is used by FreeBSD's headers (and not by glibc/Linux's headers). Sorry, should be fixed now. Paolo.
Re: Bug in Instruction Combination procedure and RTL generation.
El lun, 04-09-2006 a las 09:20 +0200, Paolo Bonzini escribió:
> J.J. Garcia wrote:
> > Hi all,
> >
> > I'm trying to debug a code optimization in gcc for an specific arch, to
> > be more explicit it's for gcc 2.95.3 for Metaware ARC target
> > architecture, i know the old release of compiler and i know there will
> > not be lot of support about it, anyway im keep on trying...,
>
> The "bug" is still there in the most recent version of GCC, but AFAIK (I
> speak RTL, but I don't speak ARC assembly) the optimization is ok.
First of all thx for fast reply and hints,
Sorry, what do you mean with "is still there"? which release/arc/bug-
entry at bugzilla is pointing the same? 'Couse if i compile on x86 as:
[EMAIL PROTECTED] solvebug1]# gcc -o test bug1-prb04503-1-new.c
[EMAIL PROTECTED] solvebug1]# ./test
[EMAIL PROTECTED] solvebug1]# echo $?
0
[EMAIL PROTECTED] solvebug1]# gcc -v
Leyendo especificaciones de /usr/lib/gcc/i386-redhat-linux/3.4.5/specs
Configurado con: ../configure --prefix=/usr --mandir=/usr/share/man --
infodir=/usr/share/info --enable-shared --enable-threads=posix --
disable-checking --with-system-zlib --enable-__cxa_atexit --disable-
libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux
Modelo de hilos: posix
gcc versión 3.4.5 20051201 (Red Hat 3.4.5-2)
Initial condition is [ Test (9 >= 10)] and as expected in x86 the cmp is
being done correctly AFAIK with -O2:
08048368 :
8048368: 55 push %ebp
8048369: 89 e5 mov%esp,%ebp
804836b: 83 7d 08 0a cmpl $0xa,0x8(%ebp)
804836f: 19 c0 sbb%eax,%eax
8048371: 83 e0 31and$0x31,%eax
8048374: 83 c0 14add$0x14,%eax
8048377: c9 leave
8048378: c3 ret
8048379: 8d 76 00lea0x0(%esi),%esi
0804837c :
804837c: 55 push %ebp
804837d: 89 e5 mov%esp,%ebp
804837f: 83 ec 08sub$0x8,%esp
8048382: 83 e4 f0and$0xfff0,%esp
8048385: 83 ec 10sub$0x10,%esp
8048388: 6a 09 push $0x9
804838a: e8 d9 ff ff ff call 8048368
<...>
Sorry, prior to continue i forgot to include last line in ARC assembler
code for main function when calling to test-function (presetting 'r0'
value b4 fork to function, slight detail...):
010c :
10c: 04 3e 0e 10 100e3e04 st blink,[sp,4]
110: 00 36 0e 10 100e3600 st fp,[sp]
114: 00 38 6e 63 636e3800 movfp,sp
118: 10 7e 8e 53 538e7e10 subsp,sp,16
11c: a0 f9 ff 2f 29a0 bl.d ec
---> 120: 09 fe 1f 60 601ffe09 movr0,9
>
> The change is from:
>
> (set (reg:CC 61 cc)
> (compare:CC (reg/v:SI 69 [ n ])
> (const_int 9 [0x9])))
> (set (reg/v:SI 67 [ test_value ])
> (if_then_else:SI (ltu (reg:CC 61 cc) (const_int 0 [0x0]))
> (const_int 69 [0x45])
> (reg:SI 71)))
>
>
> to
>
> (set (reg:CC 61 cc)
> (compare:CC (reg/v:SI 69 [ n ])
> (const_int 8 [0x9])))
> (set (reg/v:SI 67 [ test_value ])
> (if_then_else:SI (leu (reg:CC 61 cc) (const_int 0 [0x0]))
> (const_int 69 [0x45])
> (reg:SI 71)))
>
> Testing < 9 is the same as testing <= 8.
>
> The assembly seems also ok, since ".ls" is the translation of the "leu"
> RTL code. By comparison, "ltu" would become "c".
I think 'mov.ls' is correct, what is failing is to test against 8 in ARC
asm statement 'sub.f 0,r0,8' (update flags from 'r0 - 8' aritmetic
operation) it should be against 9:
00ec :
ec: 00 36 0e 10 100e3600 st fp,[sp]
f0: 00 38 6e 63 636e3800 movfp,sp
f4: 08 7a e0 57 57e07a08 sub.f 0,r0,8
f8: 14 fe 1f 60 601ffe14 movr0,20
fc: 0e 7c 1f 60 601f7c0e mov.ls r0,69
See comparison in function:
unsigned int
uifprb04503_A (unsigned int n)
{
unsigned int test_value = 69;
if ( n >= SINGULARP )
{
test_value = 20;
}
return test_value;
}
What is expected is:
if n >= 10 ---> return 20
n < 10 ---> return 69
or
n <= 9 (adapted to be used with .ls)
What is obtained from objdump is:
if n <= 8 <--- (mov.ls) --> 69
n > 8 > return 20
or
n >= 9 (deduced, bad then against original)
And if i understand correctly from RTL:
(const_int 9 + ltu) is optimized to (const_int 8 + leu)
Which as you say is correct, but:
should not it be 10 instead 9?
Attached the full .rtl (i think it's the initial approach output from
gcc), the .flow and .combine files
TIA
Jose.
>
> While unexpected, this change is done by GCC as
Re: Bug in Instruction Combination procedure and RTL generation.
First of all thx for fast reply and hints, Sorry, what do you mean with "is still there"? which release/arc/bug- entry at bugzilla is pointing the same? 'Couse if i compile on x86 as: I'm speaking about a mainline compiler, configured for arc-none-elf. What I mean is that the change in combine is ok, I don't know if the problem sparks earlier. Please try building an ARC compiler from a recent snapshot, and file a bugzilla bug. Paolo
gcc 4.2.0-20060902 - i386-pc-mingw32 - successful build and install
Follows the build info: config.guess: i386-pc-mingw32 $ gcc -v Using built-in specs. Target: mingw32 Configured with: ../../source/gcc-4.2-20060902/configure --prefix=/mingw --host=mingw32 --target=mingw32 --program-prefix="" --with-as=/mingw/bin/as.exe --with-ld=/mingw/bin/ld.exe --with-gcc --with-gnu-ld --with-gnu-as --enable-threads --disable-nls --enable-languages=c,c++ --disable-win32-registry --disable-shared --without-x --enable-interpreter --enable-hash-synchronization --enable-libstdcxx-debug Thread model: win32 gcc version 4.2.0 20060902 (experimental) $ uname -a MINGW32_NT-5.1 THERGOTHON 1.0.10(0.46/3/2) 2004-03-15 07:17 i686 unknown host system: msys @ WinXP Pro SP2 i686 /me: Marcelo A B Slomp - Brazil -- __ Now you can search for products and services http://search.mail.com Powered by Outblaze
[v3] pch vs. anonymous namespaces
Welp. It looks like the reason for c++/28871 is that anonymous
namespace usage in libstdc++ headers was making PCH files unusable.
This, despite -Winvalid-pch not telling me this...
This, despite -H showing the pch used...
UGH!
I only found this by using --disable-libstdcxx-pch and noticing that my
test times improved by 20 minutes. With this patch in, test times for
libstdc++ are now back to late july levels. (ie, 23 minutes vs. 57
minutes to 64 minutes on my laptop.)
I thought there was a bugzilla about this issue (which impacts boost,
or used to), but I cannot find it at the moment.
:(
-benjamin
2006-09-04 Benjamin Kosnik <[EMAIL PROTECTED]>
PR c++/28871
* include/ext/bitmap_allocator.h: Add comment for end of anonymous
namespace.
* include/ext/rope: Same.
* include/bits/cpp_type_traits.h: Same.
* include/tr1/tuple: Same.
* include/tr1/functional_iterate.h: Same.
* include/bits/cpp_type_traits.h: Revert anonymous namespace
change, use nested detail instead.
* testsuite/lib/libstdc++.exp (libstdc++_init): PCHFLAGS revert to
stdc++.h.
Index: include/ext/bitmap_allocator.h
===
--- include/ext/bitmap_allocator.h (revision 116678)
+++ include/ext/bitmap_allocator.h (working copy)
@@ -82,7 +82,7 @@
* else do no use any synchronization primitives.
*/
bool const __threads_enabled = __gthread_active_p();
- }
+ } // anonymous namespace
#endif
#if defined __GTHREADS
Index: include/ext/rope
===
--- include/ext/rope(revision 116678)
+++ include/ext/rope(working copy)
@@ -71,7 +71,7 @@
{
enum { _S_max_rope_depth = 45 };
enum _Tag {_S_leaf, _S_concat, _S_substringfn, _S_function};
-}
+} // anonymous namespace
_GLIBCXX_BEGIN_NAMESPACE(__gnu_cxx)
Index: include/bits/cpp_type_traits.h
===
--- include/bits/cpp_type_traits.h (revision 116678)
+++ include/bits/cpp_type_traits.h (working copy)
@@ -83,6 +83,19 @@
_GLIBCXX_BEGIN_NAMESPACE(std)
+namespace detail
+{
+ // NB: g++ can not compile these if declared within the class
+ // __is_pod itself.
+ typedef char __one;
+ typedef char __two[2];
+
+ template
+ __one __test_type(int _Tp::*);
+ template
+ __two& __test_type(...);
+} // namespace detail
+
template
struct __truth_type
{ typedef __false_type __type; };
@@ -339,27 +352,14 @@
: public __traitor<__is_arithmetic<_Tp>, __is_pointer<_Tp> >
{ };
- // NB: g++ can not compile these if declared within the class
- // __is_pod itself.
- namespace
- {
-typedef char __one;
-typedef char __two[2];
-
-template
-__one __test_type(int _Tp::*);
-
-template
-__two& __test_type(...);
- }
-
// For the immediate use, the following is a good approximation.
template
struct __is_pod
{
enum
{
- __value = (sizeof(__test_type<_Tp>(0)) != sizeof(__one))
+ __value = (sizeof(detail::__test_type<_Tp>(0))
+!= sizeof(detail::__one))
};
};
Index: include/tr1/tuple
===
--- include/tr1/tuple (revision 116678)
+++ include/tr1/tuple (working copy)
@@ -258,7 +258,7 @@
namespace
{
swallow_assign ignore;
- };
+ }; // anonymous namespace
#define _GLIBCXX_CAT(x,y) _GLIBCXX_CAT2(x,y)
#define _GLIBCXX_CAT2(x,y) x##y
Index: include/tr1/functional_iterate.h
===
--- include/tr1/functional_iterate.h(revision 116678)
+++ include/tr1/functional_iterate.h(working copy)
@@ -396,8 +396,8 @@
namespace
{
_Placeholder<_GLIBCXX_NUM_ARGS> _GLIBCXX_JOIN(_,_GLIBCXX_NUM_ARGS);
+} // anonymous namespace
}
-}
#endif
template
Index: testsuite/lib/libstdc++.exp
===
--- testsuite/lib/libstdc++.exp (revision 116678)
+++ testsuite/lib/libstdc++.exp (working copy)
@@ -214,8 +214,8 @@
"additional_flags=-include additional_flags=bits/stdtr1c++.h"]
if {$lines == "" } {
# set PCH_CXXFLAGS "-include bits/extc++.h"
- set PCH_CXXFLAGS "-include bits/stdtr1c++.h"
-# set PCH_CXXFLAGS "-include bits/stdc++.h"
+# set PCH_CXXFLAGS "-include bits/stdtr1c++.h"
+ set PCH_CXXFLAGS "-include bits/stdc++.h"
} else {
set PCH_CXXFLAGS ""
}
Re: Bootstrap broken
On Mon, 4 Sep 2006, Paolo Carlini wrote: > Sorry, should be fixed now. I'm happy to confirm this. Thanks for the quick response! Gerald
Re: regress changes?
On Aug 31, 2006, at 1:15 PM, Jack Howarth wrote: What happened to regress to allow it to suddenly do make checks at every svn revision? Does it seem noticeably different to you? I don't see much difference, only that it is slower now... 2005-11-19T20:41:33Z 2005-11-20T03:40:58Z regress-5 native 107226 2005-11-20T07:20:13Z 2005-11-20T14:24:50Z regress-5 native 107244 2005-11-20T14:26:29Z 2005-11-20T21:30:09Z regress-5 native 107251 2005-11-20T21:31:42Z 2005-11-21T04:35:29Z regress-5 native 107262 2005-11-21T05:01:36Z 2005-11-21T12:09:35Z regress-5 native 107278 2005-11-21T12:11:11Z 2005-11-21T19:15:48Z regress-5 native 107303 2005-11-21T19:57:21Z 2005-11-22T03:02:19Z regress-3 native 107319 2006-08-25T06:38:35Z 2006-08-25T21:59:45Z regress-1 native 116392 2006-08-25T22:01:47Z 2006-08-26T13:29:25Z regress-1 native 116438 2006-08-26T13:31:14Z 2006-08-27T04:54:38Z regress-3 native 116467 2006-08-27T04:56:33Z 2006-08-27T20:27:54Z regress-2 native 116486 2006-08-27T20:29:48Z 2006-08-28T12:01:02Z regress-1 native 116492 2006-08-28T12:02:58Z 2006-08-29T03:32:46Z regress-1 native 116503 2006-08-29T21:16:28Z 2006-08-30T12:49:23Z regress-1 native 116570 2006-08-30T12:51:20Z 2006-08-31T04:27:29Z regress-1 native 116584
