--- Comment #1 from hjl dot tools at gmail dot com 2008-11-12 15:31 ---
Revision 141780 is the case.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
ormal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38094
--- Comment #8 from hjl dot tools at gmail dot com 2008-11-12 21:30 ---
Revision 141798 gave:
FAIL: gfortran.dg/private_type_4.f90 -O (test for errors, line 17)
FAIL: gfortran.dg/private_type_4.f90 -O (test for excess errors)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #9 from hjl dot tools at gmail dot com 2008-11-14 03:45 ---
This patch:
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00593.html
caused:
Running target unix
FAIL: tmpdir-gcc.dg-struct-layout-1/t001 c_compat_main_tst.o compile
FAIL: tmpdir-gcc.dg-struct-layout-1/t001
ortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38138
--- Comment #4 from hjl dot tools at gmail dot com 2008-11-16 00:06 ---
(In reply to comment #3)
> i tried to run the benchmark with -fno-ira, which turned out to be about 20%
> slower than without the flag.
>
Can you try "-O3 -march=core2 -mtune=generic" and "
--- Comment #5 from hjl dot tools at gmail dot com 2008-11-16 00:08 ---
(In reply to comment #3)
> anyway, i found, that the preprocessed source generated by gcc-4.3 cannot be
> compiled with gcc-4.4 ... the specific file can be found here
> http://tim.klingt.org/git?p=nova-ser
--- Comment #4 from hjl dot tools at gmail dot com 2008-11-16 00:17 ---
It is a bug in libstdc++.
*** This bug has been marked as a duplicate of 37144 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #6 from hjl dot tools at gmail dot com 2008-11-16 00:17 ---
*** Bug 38128 has been marked as a duplicate of this bug. ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #8 from hjl dot tools at gmail dot com 2008-11-16 19:21 ---
(In reply to comment #7)
> I am not convinced that PR 38128 is a duplicate of this bug. The test
> doesn't fail if I disable the use of CFI directives on hppa-unknown-linux-gnu.
> In debugging, there
4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38162
--- Comment #4 from hjl dot tools at gmail dot com 2008-11-17 14:31 ---
Revision 141860 caused 30% slowdown on 454.calculix in SPEC CPU 2006
with -O2 -ffast-math on Linux/Intel64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37397
--- Comment #28 from hjl dot tools at gmail dot com 2008-11-18 14:42
---
(In reply to comment #27)
> Isn't this a regression?
>
The warning is new. But the same code won't compile with -Wall while
gcc 4.1 has no problems.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36902
--- Comment #2 from hjl dot tools at gmail dot com 2008-11-18 14:39 ---
It is gone now. It may be a timing issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38162
--- Comment #8 from hjl dot tools at gmail dot com 2008-11-19 18:09 ---
I think we need to break OVERRIDE_OPTIONS into 2 parts:
1. Execute only once for a given input.
2. Execute every time after all optimization options
are processed.
with things like OVERRIDE_OPTIONS_ONCE and
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38201
--- Comment #41 from hjl dot tools at gmail dot com 2008-11-20 16:44
---
You may want to take a look at PR 36159.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2008-11-20 16:57 ---
(In reply to comment #1)
> 1) -msse5 includes -mfma switch (because fma is a part of sse5 instructions).
> So having "-msse5 -mfma" is same as having just "msse5", though you can just
&
--- Comment #3 from hjl dot tools at gmail dot com 2008-11-20 18:52 ---
Since -mfma implies -mavx, we got
[EMAIL PROTECTED] gcc]$ cat f.c
double f;
void
foo (double x, double y, double z)
{
f = x * y + z;
}
[EMAIL PROTECTED] gcc]$ ./xgcc -B./ -O2 -mfma -msse5 f.c -S
-fno
--- Comment #5 from hjl dot tools at gmail dot com 2008-11-20 19:46 ---
(In reply to comment #4)
> Yes, you are right. "-mfma -msse5" does not make sense. I mistook -mfma for
> -mfused-madd and hence the confusion.
>
> Hence these combinations (1 and 2) does not m
--- Comment #7 from hjl dot tools at gmail dot com 2008-11-20 21:29 ---
We have the same issue with -m3dnow, -m3dnowa and -msse4a.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38201
: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38208
--- Comment #1 from hjl dot tools at gmail dot com 2008-11-21 05:22 ---
Revision 142061 is bad.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2008-11-21 05:39 ---
Revision 142061:
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01051.html
is the cause.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #9 from hjl dot tools at gmail dot com 2008-11-21 13:35 ---
(In reply to comment #8)
> In short, set A={-favx, -ffma}, set B={-f3dnow, -f3dnowa, -fsse4a, -fsse5}.
> Any
It is -mXXX, not -fXXX.
> option combination from both sets should be prohibited.
>
Tha
--- Comment #6 from hjl dot tools at gmail dot com 2008-11-21 17:04 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from hjl dot tools at gmail dot com 2008-11-21 17:36 ---
__sync_synchronize isn't specified for IA32/Intel64. You can check
out Intel Memory Ordering White Paper:
www.intel.com/products/processor/manuals/318147.pdf
to see what is the most appropriate.
--
--- Comment #4 from hjl dot tools at gmail dot com 2008-11-21 17:37 ---
The Intel Memory Ordering White Paper is at
http://www.intel.com/products/processor/manuals/318147.pdf
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36793
--- Comment #1 from hjl dot tools at gmail dot com 2008-11-21 23:14 ---
GNU assembler supports both
popcntl %edx, %eax
popcnt %edx, %eax
I guess we can just generate
popcnt %edx, %eax
The same goes for
popcnt %cx,%bx
popcnt %rcx,%rbx
--- Comment #6 from hjl dot tools at gmail dot com 2008-11-21 23:38 ---
I think it is a bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36793
--- Comment #11 from hjl dot tools at gmail dot com 2008-11-22 15:09
---
(In reply to comment #10)
> We should have -mfma to enable a fused multiply-add instruction that is
> available
> when enabling either -msse5 or -mavx. -mfma should not itself enable any
> of the ins
--- Comment #12 from hjl dot tools at gmail dot com 2008-11-22 15:15
---
Richard asked:
Why should it (-mavx -msse5) be disallowed if a user asks for it? Do we
disallow -msse4a -mssse4?
Reply:
-msse4a -mssse4 can generate code which runs if you check the feature
bit in CPUID before
-O3
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
GCC target triplet: i686-pc
--- Comment #1 from hjl dot tools at gmail dot com 2008-11-25 16:37 ---
Can you use ./contrib/gcc_update to update your gcc source tree
so that we can tell which revisions you are using? Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38261
: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38272
--- Comment #12 from hjl dot tools at gmail dot com 2008-11-26 05:38
---
I don't think sibcall work on Darwin. Can you skip them on Darwin?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37843
--- Comment #1 from hjl dot tools at gmail dot com 2008-11-26 15:46 ---
This may be related to PR 37938. You may try similar fix for Linux/ia64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38270
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38280
--- Comment #5 from hjl dot tools at gmail dot com 2008-11-28 08:42 ---
(In reply to comment #4)
> 142250 doesn't fix this regression. 416.gamess and 481.wrf still fail.
>
Revision 142250 is for ira-merge branch. Please try
http://gcc.gnu.org/ml/gcc-patches/2008-11/ms
--- Comment #7 from hjl dot tools at gmail dot com 2008-11-28 15:20 ---
(In reply to comment #6)
> Patch at http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01428.html fixed this
> regression.
>
481.wrf also failed on Intel64. Does this patch fix it?
--
http://gcc.gnu.org
--- Comment #2 from hjl dot tools at gmail dot com 2008-11-28 17:49 ---
Created an attachment (id=16789)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16789&action=view)
A smaller testcase
bash-3.2$ /export/build/gnu/gcc-test/build-x86_64-linux/gcc/xgcc
-B/export/build/
--- Comment #3 from hjl dot tools at gmail dot com 2008-11-28 18:01 ---
Revision 142206 generates:
Reloads for insn # 49
Reload 0: reload_in (SI) = (reg:SI 0 ax)
reload_out (SI) = (reg:SI 1 dx [orig:62 D.2019 ] [62])
GENERAL_REGS, RELOAD_OTHER (opnum = 0
--- Comment #4 from hjl dot tools at gmail dot com 2008-11-28 19:01 ---
With patch for PR 38280:
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01428.html
IRA generates:
Reloads for insn # 151
Reload 0: reload_in (SI) = (mem/u/c:SI (const:SI (unspec:SI
--- Comment #5 from hjl dot tools at gmail dot com 2008-11-28 21:11 ---
do_input_reload has
if (optimize && reload_inherited[j] && rl->in
&& MEM_P (rl->in)
&& MEM_P (rl->in_reg)
&& reload_spill_index[j] &g
--- Comment #7 from hjl dot tools at gmail dot com 2008-11-28 22:28 ---
(In reply to comment #6)
> I think, H.J., that is one more latent bug (i already saw several of them) in
> reload inheritance optimization triggered by IRA which allocates dx for p69
> and
> p87 i
--- Comment #8 from hjl dot tools at gmail dot com 2008-11-28 23:26 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01463.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #18 from hjl dot tools at gmail dot com 2008-11-29 21:10
---
It isn't totally fixed:
FAIL: gcc.target/i386/pr37843-3.c scan-assembler-not call[t ]*foo
FAIL: gcc.target/i386/pr37843-3.c scan-assembler jmp[t ]*foo
I only checked in x86 backend change since n
--- Comment #1 from hjl dot tools at gmail dot com 2008-11-30 00:51 ---
You need -mtune=core to generate "movd %xmm0, %rax". Gcc 4.4 works.
--
hjl dot tools at gmail dot com changed:
What|Removed
--- Comment #1 from hjl dot tools at gmail dot com 2008-11-30 15:00 ---
Can you try -fno-ira to see if it fixes the problem?
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #27 from hjl dot tools at gmail dot com 2008-11-30 20:52
---
(In reply to comment #26)
> Resurrecting regmove is not an option. Time is better spent on figuring out
> what regmove does, that makes a difference, and see if IRA can be taught to do
> the same.
&g
--- Comment #2 from hjl dot tools at gmail dot com 2008-12-01 15:35 ---
It is caused by either revision 142115 or 142116. Revision 142116:
http://gcc.gnu.org/ml/gcc-cvs/2008-11/msg00617.html
is my first guess.
--
hjl dot tools at gmail dot com changed:
What|Removed
--- Comment #3 from hjl dot tools at gmail dot com 2008-12-01 15:37 ---
-fno-ira also failed:
[EMAIL PROTECTED] rrs]$ ./142116/usr/bin/gcc -fPIC -m32 -S y.c -fno-ira
y.c: In function âapply_charâ:
y.c:11: error: unable to find a register to spill in class âQ_REGSâ
y.c:11: error: this
--- Comment #10 from hjl dot tools at gmail dot com 2008-12-02 18:46
---
Fixed as of revision 142345.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #15 from hjl dot tools at gmail dot com 2008-12-03 16:50
---
Simulator is fine. AVX executable can only run on simulator. If
there is a simulator which can run SSE5 and AVX, we will add
a new switch for it.
--
hjl dot tools at gmail dot com changed:
What
--- Comment #8 from hjl dot tools at gmail dot com 2008-12-03 21:28 ---
(In reply to comment #5)
> (In reply to comment #4)
> > 4.3:
> > -O3 -march=native -funroll-loops -ffast-math ==> 4.376
> > -O3 -march=native -funroll-loops -ffast-math -f
arget
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
GCC target triplet: x86-gnu-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38402
0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38406
--- Comment #3 from hjl dot tools at gmail dot com 2008-12-04 20:35 ---
It is caused by revision 140288:
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01925.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
CC||hjl dot tools at gmail dot
test
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http
--- Comment #1 from hjl dot tools at gmail dot com 2008-12-05 03:08 ---
Revision 142439:
http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00264.html
is the possible cause.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2008-12-05 05:25 ---
Revision 142439 is the cause.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from hjl dot tools at gmail dot com 2008-12-05 05:34 ---
Jakub, there was a similar problem with locale on Linux before. Do you
remember it?
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38420
--- Comment #13 from hjl dot tools at gmail dot com 2008-12-06 07:47
---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status
--- Comment #5 from hjl dot tools at gmail dot com 2008-12-07 01:11 ---
See PR 36792.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37853
--- Comment #9 from hjl dot tools at gmail dot com 2008-12-07 01:13 ---
Those 3 still aren't fixed:
FAIL: gcc.dg/vect/vect-67.c scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/no-scevccp-outer-13.c scan-tree-dump-times vect "OUTER LOOP
VECTORI
--- Comment #7 from hjl dot tools at gmail dot com 2008-12-07 16:17 ---
This bug disappeared between revision 142341 and revision 142508.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38405
--- Comment #10 from hjl dot tools at gmail dot com 2008-12-07 17:17
---
It is fixed by revision 142483:
http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00341.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #11 from hjl dot tools at gmail dot com 2008-12-07 17:39
---
Oops. It is revision 142484:
http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00340.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38405
--- Comment #2 from hjl dot tools at gmail dot com 2008-12-09 19:33 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status
--- Comment #16 from hjl dot tools at gmail dot com 2008-12-09 21:58
---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00585.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #21 from hjl dot tools at gmail dot com 2008-12-09 22:34
---
Created an attachment (id=16868)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16868&action=view)
An updated patch
This patch adds some comments to middle-end change. It also
replaces _Decimal1
--- Comment #22 from hjl dot tools at gmail dot com 2008-12-09 22:36
---
(In reply to comment #20)
> HJ --
>
> As Richard says, you should not have checked in the new testcases without
> XFAILs and without having fixed the bug.
>
> Furthermore, your patch to the mid
--- Comment #7 from hjl dot tools at gmail dot com 2008-12-10 00:13 ---
Fixed as of revision 142610.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #13 from hjl dot tools at gmail dot com 2008-12-10 05:02
---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status
--- Comment #9 from hjl dot tools at gmail dot com 2008-12-10 22:44 ---
testsuite/util/regression/rand/assoc/container_rand_regression_test.tcc has
value_type v = test_traits::generate_value(m_g, m_m);
m_alloc.set_throw_prob(m_tp);
const_key_reference r_k
--- Comment #10 from hjl dot tools at gmail dot com 2008-12-10 23:07
---
(gdb) f 0
#0
__gnu_pbds::test::detail::container_rand_regression_test<__gnu_pbds::trie<__gnu_pbds::test::basic_type,
__gnu_pbds::test::basic_type,
__gnu_pbds::string_trie_e_access_traits<__gnu_p
--- Comment #13 from hjl dot tools at gmail dot com 2008-12-10 23:16
---
(In reply to comment #12)
> This one is really old. HJ, do you know if this is still an issue? What
> happened with your patch?
>
I don't know. All my machines have libunwind.so.7.
--
http
--- Comment #2 from hjl dot tools at gmail dot com 2008-12-10 23:20 ---
Fixed as of revision 142637.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #11 from hjl dot tools at gmail dot com 2008-12-11 00:46
---
testsuite/util/regression/trait/assoc/type_trait.hpp has
static const_key_reference
extract_key_imp(pair_type_const_reference r_val)
{ return r_val.first; }
It may create a temporary on
--- Comment #12 from hjl dot tools at gmail dot com 2008-12-11 01:17
---
This program shows the problem:
[EMAIL PROTECTED] 37144]$ cat x.cc
#include
#include
struct T1
{
int i;
T1 () { i = 0; }
T1 (int x) { i = x; }
T1 (const T1 &x) { i = x.i; }
T1&
operator=(
--- Comment #14 from hjl dot tools at gmail dot com 2008-12-11 15:41
---
(In reply to comment #13)
> Hi HJ: I'm not sure to understand, you mean this is actually a C++ / compiler
> bug?!?
>
I can't say if C++ standard requires
const_T1_reference
extract_key_imp(c
--- Comment #18 from hjl dot tools at gmail dot com 2008-12-11 16:46
---
(In reply to comment #17)
> In any case, I don't really understand your snippet: you are comparing &x.i to
> &t1.i, but x comes from p, and p *copies* t1 at construction time, in other
> ter
--- Comment #19 from hjl dot tools at gmail dot com 2008-12-11 16:49
---
1081{
1082 m_alloc.set_throw_prob(0);
1083 value_type v = test_traits::generate_value(m_g, m_m);
1084 m_alloc.set_throw_prob(m_tp);
1085 const_key_reference r_k
--- Comment #7 from hjl dot tools at gmail dot com 2008-12-11 17:20 ---
It is fixed by revision 133519:
http://gcc.gnu.org/ml/gcc-cvs/2008-03/msg00738.html
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01285.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37582
--- Comment #20 from hjl dot tools at gmail dot com 2008-12-11 17:33
---
We created a temporary because
(gdb) bt
#0 pair (
this=0x7fffc6c0, _...@0x7fffc750)
at
/export/build/gnu/gcc-work/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/stl_pair.h
--- Comment #21 from hjl dot tools at gmail dot com 2008-12-11 17:57
---
Here is a new testcase:
[...@gnu-6 37144]$ cat y.cc
#include
#include
struct T1
{
int i;
T1 () { i = 0; }
T1 (int x) { i = x; }
T1 (const T1 &x) { i = x.i; }
T1&
operator=(T1 & __p)
--- Comment #23 from hjl dot tools at gmail dot com 2008-12-11 18:32
---
I am testing this patch:
Index: testsuite/util/regression/trait/assoc/type_trait.hpp
===
--- testsuite/util/regression/trait/assoc/type_trait.hpp
--- Comment #24 from hjl dot tools at gmail dot com 2008-12-11 18:39
---
Created an attachment (id=16886)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16886&action=view)
A patch
John, can you try this patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37144
--- Comment #26 from hjl dot tools at gmail dot com 2008-12-11 18:49
---
(In reply to comment #22)
> Therefore, are you coming to the conclusion that something in the testing
> infrastructure is wrong (mismatched types), *not* in the ext/pb_ds code
> itself?
>
inclu
--- Comment #28 from hjl dot tools at gmail dot com 2008-12-11 18:58
---
(In reply to comment #27)
> Ah, yes, that, I saw it some time ago. Thus, the patch you and John are
> testing
> (which makes sense, first blush) avoids failures in normal mode, but in fact
> ano
--- Comment #2 from hjl dot tools at gmail dot com 2008-12-11 19:17 ---
I can't reproduce it with gcc 4.4 revision 142654 on Linux/x86-64.
--
hjl dot tools at gmail dot com changed:
What|Removed |
--- Comment #2 from hjl dot tools at gmail dot com 2008-12-11 19:59 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status
--- Comment #9 from hjl dot tools at gmail dot com 2008-12-12 01:05 ---
(In reply to comment #8)
>
> This is a link where people mention that fact that gcc is behaving
> non-standardly, so people who want to interoperate with gcc better adopt their
> non-standard behavior.
--- Comment #3 from hjl dot tools at gmail dot com 2008-12-12 14:36 ---
Fixed
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status
--- Comment #1 from hjl dot tools at gmail dot com 2008-12-12 17:11 ---
It is very likely caused by revision 142061:
http://gcc.gnu.org/ml/gcc-cvs/2008-11/msg00562.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2008-12-12 17:20 ---
Revision 142061 is the cause.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from hjl dot tools at gmail dot com 2008-12-12 17:22 ---
It happens on ia32, x86-64 and ia64.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #31 from hjl dot tools at gmail dot com 2008-12-13 02:02
---
Created an attachment (id=16902)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16902&action=view)
A patch to add -D_GLIBCXX_DEBUG to dg-options
I am testing this patch to see if it can trigger
1 - 100 of 3390 matches
Mail list logo
