--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-19 07:49 ---
Reduced testcase:
with Implementing_Interface;
procedure Bugs_Test is
begin
declare
use Implementing_Interface;
begin
Serialized_Code (Gary_Left);
end;
end Bugs_Test;
with Abstract_Interface;
p
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-19 07:18 ---
Reduced testcase:
package body sets is
function complement (s : set) return set is begin
return (not s);
end complement;
end sets;
package sets is
type set is private;
function complement (s :
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2006-03-19 06:38
---
Very old problem. I've a patch in the works.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-19 06:00 ---
The expression which is causing the ICE is a PLACEHOLDER expression:
(gdb) p debug_generic_expr (*expr_p)
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-03-19 05:55
---
PR 15305 is another testcase which should go in which now passes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18692
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-19 05:54 ---
Fixed in 4.2.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-19 05:41 ---
Backtrace:
#0 0x004056bc in is_attribute_with_length_p (attr=0xc66e94 "altivec",
attr_len=7, ident=0x0) at /Users/pinskia/src/gcc/local/gcc/gcc/tree.c:3369
#1 0x004059dc in is_attribute_p (attr=0xc66e94 "altivec",
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-19 05:20 ---
Also the error does not make sense.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24130
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-03-19 05:19 ---
The testcase has been waiting on for almost 6 months now so closing as invalid.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-19 05:18 ---
This is not a bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-03-19 05:17 ---
Note PPC-darwin's Ada is broken when testing so I have been able to test this
yet.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18818
--- Comment #17 from pinskia at gcc dot gnu dot org 2006-03-19 05:11
---
NVR in the C++ front-end is causing this violation to be produced.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-19 05:04 ---
No feedback in over 3 months.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-19 05:01 ---
No feedback in 3 months.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-19 00:06 ---
You cannot #undefine typedefs because the processing happens at two different
times at compiling.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
While compiling DirectFB, i get the following errors:
In file included from ../../lib/direct/util.h:34,
from ../../lib/direct/debug.h:41,
from clock.c:34:
/usr/include/pthread.h:285: error: conflicting types for 'pthread_t'
/usr/include/bits/pthreadtypes.h:50: err
--- Comment #4 from sabre at nondot dot org 2006-03-18 23:43 ---
Huh? Why can't it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16660
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-18 19:32 ---
You forgot about agrument dependent lookup which also finds ::A so this is not
a bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
The following code snippet:
struct B {};
void A(B) {};
namespace N {
void A(B) {}
void f(B b) {A(b);}
}
gives this error (tested with 3.3.6 and 4.0.3):
namespaceconf.cpp: In function 'void N::f()':
namespaceconf.cpp:6: error: call of overloaded 'A(B&)' is ambiguous
namespaceconf.cpp:5: note: ca
--- Comment #2 from drow at gcc dot gnu dot org 2006-03-18 19:20 ---
See Joseph's comments:
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01155.html
I don't think there's a GCC bug here either. If anything, it sounds like a GDB
bug (and I remember Mark Kettenis fixing a similar GDB bu
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2006-03-18
17:57 ---
Subject: Re: [hppa64] Bad dwarf output using non-preserved base register
> --- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-18 17:31
> ---
> I thought this was fixed for 4.1.0.
I don't
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-18 17:43 ---
Actually this is just a missed diagnostic. The compiler cannot align the stack
variables where the alignment is greater than stack alignment that the compiler
can give for the stack.
--
pinskia at gcc dot gnu do
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-18 17:31 ---
I thought this was fixed for 4.1.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-03-18 16:39 ---
I found some other ones which had been added after this bug report was open :(.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
switch (default_kind)
{
case OMP_CLAUSE_DEFAULT_NONE:
error ("%qs not specified in enclosing parallel",
IDENTIFIER_POINTER (DECL_NAME (decl)));
error ("%Henclosing parallel", &ctx->location);
..
n = splay_tree_lookup (ctx->variables, (spla
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-18 16:36 ---
Likewise for:
tret = gimplify_expr (&TREE_VALUE (link), pre_p, post_p,
is_gimple_lvalue, fb_lvalue | fb_mayfail);
if (tret == GS_ERROR)
{
tret = gimplify_expr (&TREE_VALUE (link), pre_p, post_p,
is_inout ? is_gimple_min_lval : is_gimple_lvalue,
fb_lvalue | fb_mayfail);
if (tret == GS_ERROR)
{
error ("invalid lvalue in asm output %d", i);
ret = t
too few arguments to function va_start is caught in the gimplifier which is
wrong.
if (!arglist || !TREE_CHAIN (arglist))
{
error ("too few arguments to function %");
*expr_p = build_empty_stmt ();
return GS_OK;
}
I only
I don't have a testcase but gimplify_expr_stmt produces warnings:
warning (OPT_Wextra, "statement with no effect");
...
else if (warn_unused_value)
warn_if_unused_value (stmt, input_location);
--
Summary: gimplify_expr_stmt in cp-gimplifer.c does warnings
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-18 16:29 ---
This is only for the C++ front-end, the C front-end was fixed a while back.
Continue is the same issue
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
Testcase:
void f(void)
{
break;
}
--
Summary: break is not dectected until the gimplifier
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-03-18 16:26 ---
I am going to seperate this into a couple of different bugs.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from falk at debian dot org 2006-03-18 15:45 ---
I cannot reproduce this anymore with Debian 1:3.3.6-12. I guess we can just
close it.
--
falk at debian dot org changed:
What|Removed |Added
---
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-03-18 15:18
---
*** Bug 26742 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-18 15:18 ---
This is how C99 is designed.
This is a dup of an older invalid bug, PR 7508.
*** This bug has been marked as a duplicate of 7508 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-18 15:06 ---
Looks related to PR 11254.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
BugsThi
--- Comment #5 from aph at gcc dot gnu dot org 2006-03-18 14:58 ---
This DECL_ARTIFICIAL for the label -- should it be in the gcj front-end?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21591
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-18 14:48 ---
*** This bug has been marked as a duplicate of 21591 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-18 14:48 ---
*** Bug 26745 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-18 14:46 ---
libffi does not support variable arguments at all.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
The gcc40 was able to vetorize the simple program given below, gcc41 and gcc42
are failing to vectorize with the message:
novect.cpp:21: note: not vectorized: can't determine dependence between
A_4->X[f_9] and C_8->X[f_9]
novect.cpp:21: note: vectorized 0 loops in function.
Michael Cieslinski
In MacOSX 10.4.5, ffi_call can't pass floating-point values to a function which
has variable argument list.
=== Reproduce steps:
(1) compile the test program
% cat vaarg.c
#include
#include
int main()
{
ffi_cif cif;
ffi_type *args[2];
void *values[1];
double v =
--- Comment #1 from tausq at debian dot org 2006-03-18 10:14 ---
Created an attachment (id=11066)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11066&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26743
gcc -O2 -c hamlibperl_wrap.i gives:
/tmp/ccxskRBB.s: Assembler messages:
/tmp/ccxskRBB.s:232018: Error: Field out of range [-262144..262143] (319532).
/tmp/ccxskRBB.s:312290: Error: Field out of range [-262144..262143] (-320952).
The problem happens with gcc-3.3.6, gcc-3.4.5, gcc-4.0.3 and gcc-4.1
44 matches
Mail list logo
