--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-08 20:58 ---
SMT.18091 is only ever mentioned in RVUSE_IN/OUT, not for any value handle,
D.571521_46 also doesn't have a value handle.
Created value VH.4677 for fieldEngineBase_5
Created value VH.4679 for *VH.4677 vuses:
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-08 21:54 ---
add... may_alias... after... PRE!
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
ywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
OtherBugsDependingO 22501
nThis:
http://gcc.gnu.org/bugzilla/s
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-09 08:41 ---
And of course I again have hacked forwprop to do the transformation for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27090
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-09 09:03 ---
A quick look at VN doesn't tell me an obvious place where to fix this. We have
Created value VH.0 for f_1
Created value VH.1 for (struct Bar *) VH.0
Created value VH.2 for (struct Foo *) VH.1
where (struc
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-10 09:00 ---
We go via expand_builtin_memset which expands strlen at
len_rtx = expand_normal (len);
but then, expand via setmem fails, so we bail out
else if (!set_storage_via_setmem(dest_mem, len_rtx, val_rtx
--- Comment #19 from rguenth at gcc dot gnu dot org 2006-04-10 11:56
---
So it is indeed chicken and egg ;) load-PRE does not PRE the loads if the loop
is not in do-while form, and we won't hoist the loop header copies until the
loads are PREd. As to comment #13, if we are ab
--- Comment #13 from rguenth at gcc dot gnu dot org 2006-04-10 15:31
---
I wonder if it helps placing this between cunroll and ivopts...
void foo(int n, int m, int stridex, int stridey, int stridex2, int stridey2,
double *x, double *y)
{
for (int k=0; khttp://gcc.gnu.org/bugzilla
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-11 08:28 ---
Confirmed. The following aborts with -O2 and works with -O, optimized tree
dumps are identical.
extern "C" void abort(void);
struct Test { char *p; };
inline void align(char* &p)
{
((long &)p
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-04-11 10:33 ---
Oh, right. I was confused about 'char' and didn't see the alias violating.
*** This bug has been marked as a duplicate of 21920 ***
--
rguenth at gcc dot gnu dot org changed:
W
--- Comment #91 from rguenth at gcc dot gnu dot org 2006-04-11 10:33
---
*** Bug 27114 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-11 10:46 ---
Overflow flag set problem:
n = -2;
n.10 = n;
D.2132 = -08000 / n.10;
-fwrapv "fixes" the problem. This is a dup of ...
--
rguenth at gcc dot gnu dot org changed:
What
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-04-11 15:25 ---
I mean the middle-end probably does some "interesting" foldings of -2147483647L
- 1L as the result -08000 has the overflow flag set. It doesn't do it with
-fwrapv though.
--
http://gcc.g
element
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-12 10:14 ---
Use %lld, the L length modifier is for floating point formats to enable
long double.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-12 10:17 ---
Confirmed. But this is unlikely to be fixed as it would require moving the
diagnostic to the middle-end where this information is available. And
diagosticts from the middle-end are notoriously frowned upon
mization
Severity: enhancement
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27132
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-12 12:53 ---
Testcase:
/* { dg-do compile } */
/* { dg-options "-fdump-tree-gimple" } */
int foo(int i)
{
return i - -1;
}
/* { dg-final { scan-tree-dump "i \\+ 1" "gimple" } } */
/* { dg-fin
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-04-12 13:35 ---
PASS: g++.old-deja/g++.mike/dyncast7.C (test for excess errors)
FAIL: g++.old-deja/g++.mike/dyncast7.C execution test
const Foo* and Foo* are really not compatible. We can just exchange Foo* for
const Foo* for
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-04-12 13:37
---
Created an attachment (id=11250)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11250&action=view)
updated patch
Patch I will clean and test instead. Also fixes 27090.
--
rguenth at gcc dot gnu
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-04-12 18:10 ---
Didn't we have the canonicalization to put the constant in operand2 if
possible? A lot of transformations rely on that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23295
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-04-17 09:51 ---
Confirmed. Number of iteration analysis concludes the loop
ush_4 = label.23_3 + 510B;
if (label.23_3 <= ush_4) goto ; else goto ;
:;
# ush_16 = PHI ;
# csum_14 = PHI ;
:;
# VUSE ;
D.286
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-04-17 10:10 ---
This is a dup of PR26763, which is fixed for 4.1.1.
*** This bug has been marked as a duplicate of 26763 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from rguenth at gcc dot gnu dot org 2006-04-17 10:10
---
*** Bug 27176 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-04-17 10:16 ---
This may be fixed by Zdeneks optimization of phi argument rewrite and dominator
updating. Though I bet these are not appropriate for 4.1.1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27140
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-17 10:34 ---
#5 0x081a8738 in get_val_for (x=0xb7dedea0, base=0xb7d70480)
at /space/rguenther/src/svn/gcc-4_1-branch/gcc/tree-ssa-loop-niter.c:1254
1254 val = fold (TREE_OPERAND (stmt, 1));
(gdb) call
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-17 10:51 ---
Hmm, looks more like a tree sharing problem
Breakpoint 5, fold_ternary (code=CALL_EXPR, type=0xb7d5fa6c, op0=0xb7d55540,
op1=0xb7dd9048, op2=0x0)
at /space/rguenther/src/svn/gcc-4_1-branch/gcc/fold-const.c
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-04-17 11:12 ---
1329aval[j] = get_val_for (op[j], val[j]);
(gdb) call debug_generic_expr(val[0])
__builtin_pow (xD.1278_4, 2.0e+0)
(gdb) call debug_generic_expr(op[0])
xD.1278_3
Program received signal SIGSEGV
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-04-17 11:18 ---
Now, the comment before get_val_for is confusing, as it says
* if BASE is NULL_TREE, X must be a constant and we return X.
but we do
if (!x)
return base;
now, I believe a
gcc_assert
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27181
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-17 12:31 ---
The tree-combiner requiring function depends on 27084. Also this happens in
tramp3d again. Also related to 27090. Still fold needs to catch it first.
--
rguenth at gcc dot gnu dot org changed
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-04-17 13:53 ---
Subject: Bug 26826
Author: rguenth
Date: Mon Apr 17 13:53:19 2006
New Revision: 113007
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113007
Log:
2006-04-17 Richard Guenther <[EMAI
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-04-17 13:54
---
Fixed on the mainline.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #23 from rguenth at gcc dot gnu dot org 2006-04-17 16:54
---
It also helps for propagating loop versioning guard information like
int foo(int i, int j)
{
int res = 0;
if (i==1 && j==2)
for (;i>0;--i)
res += j;
else
for (;i>0;--i)
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-17 19:55 ---
Just to add some information from the conversation on this topic:
> > Shouldn't the aliasing set for the type atype be the same as atype1?
>
> Im not entirely sure, but the C99 standard
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-17 20:07 ---
And this only fails for array types without their size specified. Confirmed.
Btw. inside NumShift the two array types are
unit size
align 32 symtab 0 alias set -1 precision 32 min max
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-18 08:21 ---
6.10.1/3
The resulting tokens
compose the controlling constant expression which is evaluated according to the
rules of
6.6, except that all signed integer types and all unsigned integer types act as
if they have
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-18 08:34 ---
Support for this was ripped out of gcc in 3.4 I think. It won't come back.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-04-18 09:02 ---
Fixed on the mainline. Btw, this is really wrong-code. Can you apply to the
4.1 branch, too, please?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-04-18 14:46 ---
I'll bootstrap & test the obvious patch then.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-19 08:25 ---
Confirmed.
#0 internal_error (
gmsgid=0x8a04870 "tree check: did not expect class %qs, have %qs (%s) in
%s, at %s:%d") at /space/rguenther/src/svn/gcc/gcc/diagnostic.c:586
#1 0x0
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-04-19 08:39 ---
I have a patch (and found this bug "too late").
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-04-19 09:02
---
Now, we have
/* Initial scalar cleanups. */
NEXT_PASS (pass_ccp);
NEXT_PASS (pass_fre);
NEXT_PASS (pass_dce);
NEXT_PASS (pass_forwprop);
NEXT_PASS (pass_copy_prop);
NEXT_PASS (pass_merge_phi
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
OtherBugsDependingO 27039
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27214
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-19 12:46 ---
Confirmed. Testcase:
extern "C" void abort(void);
bool ok = false;
struct C
{
~C() { if (!ok) abort(); }
};
void g()
{
static const C &c = C();
}
int main()
{
g();
ok = true;
retu
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-19 15:13 ---
"-CST" in this case is unsigned 4294967292, it just happens to be printed as
-4B.
So the addition wraps, as it is done using unsigned arithmetic. Writing
char *foo(char *p)
{
return p + 4294967292;
}
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-04-19 15:31 ---
How's that "the same"? Either you say that pointers follow unsigned integer
types in overflow behavior (quote me the standard for that) or explain why
p + -4 is treated as p + (char *)-4
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-04-20 08:44 ---
(gdb) call debug_generic_expr(stmt)
*(struct VectorD.1984 *) D.2012 = dD.1989
that's not gimple. We trip over that in into-ssa.
(gdb) call debug_bb_n(2)
;; basic block 2, loop depth 0, count 0
;; prev bl
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-20 09:54 ---
This is more likely a problem with your kernel/libc than with libstdc++ or gcc.
Also on linux i386 signal 19 is SIGSTOP, for which sigset returns SIG_HOLD.
--
rguenth at gcc dot gnu dot org changed
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-04-20 10:49 ---
I would suggest using SIGUSR1 for testing, malloc and free are not affected by
signal interruption. So if they are, this is internal to the Solaris libc or
the kernel. At a first guess I would suggest updating the
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-20 12:04 ---
It's called -Wsequence-point, but it's not perfect. See also PR18050.
int *v;
int i;
void f(int, int);
void foo(void)
{
v[i] = i++;
f(v[i], i++);
}
/space/rguenther/install/gcc-3.4.4/bin/gcc -Wsequ
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-20 12:05 ---
Oh, you used C++ but filed against C. Reopen bug...
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-20 12:06 ---
... to close as fixed in 4.0.0.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-04-20 13:52 ---
I have a patch to teach GVN tree-combining.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27090
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-04-20 13:54 ---
Which, for the testcase in comment #4 gives us
;; Function f (f)
Created value VH.0 for a_1
Created value VH.1 for *VH.0 vuses: (SMT.4_8)
Created value VH.2 for (unsigned int *) VH.0
Created value VH.3 for (int
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-04-20 14:57
---
We now generate
return (int) ((unsigned int) (long long int) b + (unsigned int) (long long
int) a);
which is harder to optimize. But with -fwrapv and GVN tree-combiner we get
aa_2 = (long long int) a_1
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-20 16:05 ---
You might want to dive into builtins.c:get_pointer_alignment.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27226
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-04-20 20:47 ---
I suggest you test on an architecture that traps on unaligned accesses, so as
ia64 with the correct prctrl setup. In particular you seem to miss that
ARRAY_REF can have a custom index range that doesn't start
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-04-20 21:23 ---
Ah, I see. I only looked at the mainline patch. I was refering to the patch
for PR26565 which is still pending for 4.1 and will bring the 4.1 version
in-line with the mainline version. I guess sh is also affected
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-04-21 12:34
---
Exchanging FRE with DCE produces on x86_64 (-O2 vs. -O2 with patch):
Estimated Estimated
Base Base Base Peak Peak
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-21 12:50 ---
>From ipa-pure-const we get
Function found to be pure: foo_read
Function found to be pure: foo
which is of course bogus for volatile pointer arguments. It's a regression,
because ipa-pure-cons
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-04-21 14:46 ---
Hm, fold_unary does not fold
(struct FooD.1993 *)(struct BarD.1994 *) f
where f is of type (struct FooD.1993 &). Oh well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27090
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
GCC target triplet: powerpc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27260
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-22 11:04 ---
Testcase:
typedef unsigned int size_t;
typedef void *ClientData;
typedef struct Tcl_Interp { } Tcl_Interp;
extern char *addRE;
extern char *rmRE;
extern char *aproposRE;
typedef struct _mod_trace { char **re_ptr
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-22 11:15 ---
More reduced testcase:
void cmdModuleTrace(int i)
{
char *cmd_table;
cmd_table = (char *) __builtin_malloc( 3);
__builtin_memset (cmd_table, !i, 3);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-22 13:08 ---
The problem is we expand the value in QI mode because of
val = builtin_save_expr (val);
len = builtin_save_expr (len);
len_rtx = expand_expr (len, NULL_RTX, VOIDmode, 0);
dest_mem
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-04-22 13:19 ---
Testcase also fails on mainline x86_64 with -Os.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-04-22 20:05 ---
Bootstrapped and tested on x86_64-unknown-linux-gnu.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27218
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-04-22 20:35 ---
So you want __attribute__((incoming_stack_frame_read_only)).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-04-22 21:37 ---
Bootstrapped and tested on x86_64-unknown-linux-gnu.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27236
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-23 11:51 ---
Please read the bug-reporting instructions and provide a preprocessed testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27267
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-23 15:47 ---
Confirmed. We hit
#1 0x080b0ffc in digest_init (type=, init=0xb7da6ed0)
at /space/rguenther/src/svn/gcc/gcc/cp/typeck2.c:788
788 gcc_assert (VEC_length (constructor_elt, v) <= len);
Also happens
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-04-24 07:58 ---
Subject: Bug 22525
Author: rguenth
Date: Mon Apr 24 07:58:53 2006
New Revision: 113216
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113216
Log:
2006-04-24 Richard Guenther <[EMAI
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-04-24 08:17
---
Subject: Bug 27218
Author: rguenth
Date: Mon Apr 24 08:17:42 2006
New Revision: 113218
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113218
Log:
2006-04-24 Andrew Pinski <[EMAI
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-04-24 08:21
---
Subject: Bug 26869
Author: rguenth
Date: Mon Apr 24 08:21:41 2006
New Revision: 113219
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113219
Log:
2006-04-24 Richard Guenther <[EMAI
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-04-24 08:32 ---
Note that I just figured out that your patch doesn't fix the problem.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-04-24 08:36 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-04-24 09:07 ---
Uh, it did. Sorry. Fixed on the mainline.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-04-24 09:06 ---
Subject: Bug 27236
Author: rguenth
Date: Mon Apr 24 09:06:51 2006
New Revision: 113221
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113221
Log:
2006-04-24 Andrew Pinski <[EMAI
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27302
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-25 11:36 ---
First, gcc 3.4.3 is no longer in active maintainance, the oldest still
maintained version is 4.0.3. Second, please read the bugreporting guidelines
and provide a testcase for the problem. Third, this may be as
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-25 11:49 ---
Confirmed. We generate
0x08048475 : movdqu (%edx),%xmm0
0x08048479 : movdqa %xmm0,(%eax)
but both %edx and %eax are unaligned:
eax0x804a021134520865
ecx0x0 0
edx
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-25 11:55 ---
mainline doesn't do vectorization here:
/tmp/t.c:12: note: === vect_analyze_dependences ===
/tmp/t.c:12: note: not vectorized: can't determine dependence between *src.1_24
and *dest.0_23
/tmp/t.c:12: note
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-25 12:07 ---
Look at the assembly output of gcc (-S) and see if there is an appropriate
alignment directive before the entry for AMLogging in the bss section. If
there
is, the assembler/linker are at fault. Otherwise please
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-25 12:11 ---
Considering it. What happens?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-25 12:15 ---
This is not a valid testcase, or even expression. I guess it's invalid anyway
because of operator precedence.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-25 12:20 ---
Oh, this is just an aliasing issue. Reopening...
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-04-25 12:21 ---
.. to close as dup of PR21920.
*** This bug has been marked as a duplicate of 21920 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #93 from rguenth at gcc dot gnu dot org 2006-04-25 12:21
---
*** Bug 27306 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-25 12:38 ---
*** Bug 27305 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27308
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-25 12:38 ---
*** This bug has been marked as a duplicate of 27308 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-25 12:49 ---
This is probably a problem with the inline asm constraints. Try removing the
__asm__("r0") from the __res variable. Also try simplifying the testcase by
storing the result of BIOS_ContainerUsage(1)
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-04-25 13:23 ---
template
class set
{
...
// _GLIBCXX_RESOLVE_LIB_DEFECTS
// DR 103. set::iterator is required to be modifiable,
// but this allows modification of keys.
typedef typename _Rep_type
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-04-25 14:27 ---
Yes, but the problem appears with -O1 which has -fno-strict-aliasing. Now
whether -fno-strict-aliasing makes the testcase valid is another question ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27299
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-04-25 14:29 ---
Changing the function to take both arguments as uint8_t* fixes the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27299
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-04-25 15:45 ---
__res should be allocated to the same register as __r0 due to the '0'
constraint which tells gcc to use the same register as for "=r" (__res).
Whoops - I obviously meant to remove the __asm__
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-25 15:48 ---
The empty class has a size of 1. And yes, the ABI requires to preserve stack
alignment.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #26 from rguenth at gcc dot gnu dot org 2006-04-25 15:55
---
Created an attachment (id=11333)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11333&action=view)
updated patch
This is a cleanup of the patch by Jeff, bootstrapped and regtested on
x86_64-unknown-li
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-04-26 07:58 ---
Ok, that makes sense. Still the failure mode is weird and hints at the
vectorizer not following those semantics but something else.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27299
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-04-26 07:59 ---
Sorry, I fixed that in a followup. -1 is now unsigned and so appears as n +
fff.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22525
1 - 100 of 15085 matches
Mail list logo
