--- Comment #15 from jason at gcc dot gnu dot org 2006-09-08 07:14 ---
The bug is in expand_builtin_setjmp_receiver:
/* Now put in the code to restore the frame pointer, and argument
pointer, if needed. */
[...]
emit_move_insn (virtual_stack_vars_rtx, hard_frame_pointer_rtx);
--- Comment #16 from jason at gcc dot gnu dot org 2006-09-08 07:37 ---
The line in question dates back to when __builtin_setjmp was first added in
1996.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28493
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-09-08 07:40
---
Only fixed on the mainline.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
g++ version: 4.1.1
target platform: linux kernel 2.6.13-15
with option pedantic the following line does not compile outside main:
int array3[(const unsigned short) (20.5 * 3)];
error message from compiler is:
error: array bound is not an integer constant
to me this is wrong because the
If reload decides to create an automodification reload (POST_MODIFY, etc.),
inc_for_reload will not deal correctly with any reloads for the base and
index registers. This problem is related to:
2006-03-29 Paul Brook [EMAIL PROTECTED]
* reload1.c (choose_reload_regs): Check for all
--- Comment #1 from rsandifo at gcc dot gnu dot org 2006-09-08 08:37
---
Created an attachment (id=12211)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12211action=view)
Testcase
This brute-force test fails with -O2 -mfloat-abi=softfp.
--
rsandifo at gcc dot gnu dot org
Well, i want to create a new pass for gcc. i do all passes an introduce my pass
in passes.c
p = pass_tree_loop.sub;
NEXT_PASS (pass_tree_loop_init);
NEXT_PASS (pass_tree_blocking);
I do the tree-blocking.c
static void
main_tree_blocking (void)
{ struct loops loops
--- Comment #6 from pluto at agmk dot net 2006-09-08 12:48 ---
any idea how to fix this? i can test proposals.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28811
--- Comment #13 from tausq at debian dot org 2006-09-08 15:04 ---
Works for me on the original test case (ACE package) and on the reduced test
case in #3. Tested on hppa-linux native.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26957
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-08 15:51 ---
This is the wrong place to report a problem about your own pass if you have not
done any debugging yourself.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-09-08 15:51
---
Then fixed on the mainline, marking as such and changing back to new for the
other branches.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from daknhro at hotmail dot com 2006-09-08 16:28 ---
can i have a debugging?(In reply to comment #1)
This is the wrong place to report a problem about your own pass if you have
not
done any debugging yourself.
how i do a debugginh
--
--- Comment #4 from mkoeppe at gmx dot de 2006-09-08 16:41 ---
(In reply to comment #3)
And the other question is how did you get passed PR 15212?
I now tested make bootstrap on native i586-pc-interix3.
This bug (PR 28968) occurs there, too, when building the stage1. I think it is
--- Comment #15 from jason at gcc dot gnu dot org 2006-09-08 16:52 ---
Subject: Bug 26957
Author: jason
Date: Fri Sep 8 16:52:40 2006
New Revision: 116781
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116781
Log:
PR c++/26957
* method.c (use_thunk): Clear
--- Comment #16 from jason at gcc dot gnu dot org 2006-09-08 16:54 ---
Subject: Bug 26957
Author: jason
Date: Fri Sep 8 16:53:55 2006
New Revision: 116782
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116782
Log:
PR c++/26957
* method.c (use_thunk): Clear
--- Comment #17 from jason at gcc dot gnu dot org 2006-09-08 16:54 ---
Applied to 4.0 and 4.1 as well.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from amylaar at gcc dot gnu dot org 2006-09-08 17:26 ---
I suppose this accepts-invalid problem is related:
struct I
{
int i;
} i = { 0 };
int
f (int i, int j = i.i)
{
return i + j;
}
--
amylaar at gcc dot gnu dot org changed:
What|Removed
The following code violates clause 4 of 3.4.5
class C {};
void
f ()
{
C o;
class C {};
o.C::~C ();
}
--
Summary: class member access using a qualified-id fails to check
for match of classes
Product: gcc
Version: 4.2.0
g++ doesn't diagnose the overflow (clause 5 paragraph 5) in the following
constant expression:
#include limits.h
long l = LONG_MAX+1;
--
Summary: Failure to diagnose overflow in constant expression
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
--- Comment #2 from jsm28 at gcc dot gnu dot org 2006-09-08 18:51 ---
Working on a fix.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
The following code is accepted, contrary to clause 5.2.4:
typedef int C;
typedef double D;
void
f ()
{
C o;
o.D::~C ();
}
--
Summary: g++ does not check first type name in pseudo-destructor-
name
Product: gcc
Version: 4.2.0
--- Comment #7 from janis at gcc dot gnu dot org 2006-09-08 19:11 ---
A regression hunt on powerpc-linux, using the reduced testcase from comment #4
with no options, identified this patch for which that test starts compiling
cleanly:
http://gcc.gnu.org/viewcvs?view=revrev=116450
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-09-08 19:14 ---
So the ICE in tree_low_cst has been fixed in the next releases of GCC 4.1.x and
4.0.x, that is good news but we still have the ICE in
loc_descriptor_from_tree_1 now.
--
pinskia at gcc dot gnu dot org changed:
void
f()
{
bool i = 0;
i++ = 6;
}
--
Summary: post-increment of bool variable accepted as lvalue
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-08 19:33 ---
Confirmed, though in 3.0.4 to 3.4.0 we gave a weird error for this code:
t.cc: In function `void f()':
t.cc:5: error: assignment of read-only location
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #4 from tromey at gcc dot gnu dot org 2006-09-08 19:34 ---
Also see PR 28892
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
The following is accepted despite the requirements of 5.3.4 paragraph 15
of a user-defined constructor:
class B
{
public:
B ();
};
class C : B {};
const C *
f ()
{
const C *p = new const C[1];
return p;
}
--
Summary: const new: Inherited constructor accepted in lieu of
--- Comment #2 from amylaar at gcc dot gnu dot org 2006-09-08 20:30 ---
g++ also fails to check the accessibility of the destructor:
class C
{
private:
void operator delete (void *p) throw ();
};
void
f ()
{
C *p = new C;
}
class D
{
private:
~D ();
};
void
g ()
{
D *p =
--- Comment #3 from steven at gcc dot gnu dot org 2006-09-08 20:32 ---
See http://gcc.gnu.org/wiki/DebuggingGCC
Please stop asking questions here and try to figure out something for yourself,
from the wiki, from the documentation, by experimenting, or when all else
fails, on the
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2006-09-08 20:45
---
The approach looks OK but the fix should use invalidate_any_buried_refs.
Post the revised version to gcc-patches if it works (read the guidelines on
http://gcc.gnu.org/contribute.html) and I'll formally approve
() {};
};
void (*T::handler)() = func;
int main()
{
T t;
return 0;
}
gcc version 4.2.0 20060908 (experimental) emits:
08048416 t global constructors keyed to _ZN1T7handlerE
08049664 B T::handler
4.1.1 and 3.4.6 emit:
0804962c D T::handler
--
Summary: Static constructor emitted
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-08 21:00 ---
Hmm, this worked in 4.2.0 20060821
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28991
--- Comment #2 from adam at os dot inf dot tu-dresden dot de 2006-09-08
21:07 ---
gcc version 4.2.0 20060903 (experimental) also gives:
080483f2 t global constructors keyed to _ZN1T7handlerE
08049650 B T::handler
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28991
--- Comment #17 from jason at gcc dot gnu dot org 2006-09-08 22:37 ---
Hmm, it seems things are a bit more complicated than I thought. Without my
change to expand_builtin_setjmp_receiver, Janis's test passes at -O0 and fails
at -O1; the adjustment of r31 at -O0 is actually correct.
$ cat bad_if.cc
#include stdio.h
int main() {
if (0); { /* Semicolon accidentally added between condition and brace. */
printf(Not intended to be printed\n);
}
return 0;
}
$ .../i686-unknown-linux-gnu-g++ --version
i686-unknown-linux-gnu-g++ (GCC) 4.1.0
$
--- Comment #18 from jason at gcc dot gnu dot org 2006-09-08 22:52 ---
Janis: the most part of the -fstack-protector patch that seems plausible for
causing this problem was the change to expand_function_end to call
sjlj_emit_function_exit_after at a different point. But that section of
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-09-08 22:56
---
Subject: Bug 28858
Author: reichelt
Date: Fri Sep 8 22:56:44 2006
New Revision: 116788
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116788
Log:
PR c++/28858
* parser.c
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-09-08 23:28
---
Fixed on mainline.
Won't backport to 4.1 and 4.0 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-08 23:28 ---
This is a dup of bug 5520 which was fixed in 4.2.0.
*** This bug has been marked as a duplicate of 5520 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-09-08 23:28
---
*** Bug 28992 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
gfortran -v -save-temps -c Diags.f95
Using built-in specs.
Target: powerpc-apple-darwin8.7.0
Configured with: ../gcc-4.0.3/configure --prefix=/usr/local
--enable-languages=c,c++,f95,java --with-gmp=/usr/local/lib
--with-mpfr=/usr/local/lib
Thread model: posix
gcc version 4.0.3
--- Comment #10 from reichelt at gcc dot gnu dot org 2006-09-08 23:33
---
The fix is incomplete. The following testcase still fails:
==
struct A
{
static void foo();
};
void bar()
{
A().foo;
}
==
--
reichelt at gcc dot gnu dot
--- Comment #3 from jsm28 at gcc dot gnu dot org 2006-09-08 23:41 ---
Subject: Bug 28504
Author: jsm28
Date: Fri Sep 8 23:41:21 2006
New Revision: 116789
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116789
Log:
PR c/28504
* c-tree.h (struct c_arg_info): Add
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-09-08 23:45
---
(In reply to comment #10)
The fix is incomplete. The following testcase still fails:
Can you file a new bug report since the orginal testcase here was fixed, even
though your testcase is very closely related it
--- Comment #1 from jsm28 at gcc dot gnu dot org 2006-09-09 00:03 ---
This was fixed by
2005-12-13 Mark Mitchell [EMAIL PROTECTED]
Jakub Jelinek [EMAIL PROTECTED]
* g++.dg/compat/struct-layout-1.exp: Do not link with libiberty.
*
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-09 00:16 ---
Related to PR 20039.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
When configuring and bootstrapping with
#!/bin/tcsh
/bin/rm -rf *; env CC='gcc -mcpu=970 -m64' ../configure
--prefix=/pkgs/gcc-test-64 --enable-languages=c --disable-checking; make -j 16
bootstrap BOOT_CFLAGS='-O2 -g -mcpu=970 -m64' build.log
bootstrap fails with
--- Comment #4 from jsm28 at gcc dot gnu dot org 2006-09-09 01:02 ---
Patch doesn't apply cleanly to 4.1 branch.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from vnasardinov at gmail dot com 2006-09-09 01:05 ---
PR 28892 reminded me that I had forgotten to mention one thing. The
attached program (attachment 12208) runs fine under gij.
To be more precise, it does more or less the same thing it does under
Sun's JDK. Under
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2006-09-09 01:17
---
Please upgarde to at least 4.1 version of gfortran. This compiles fine for me
with latest gfortran 4.2. 100's of bugs have been fixed since 4.0 series.
--
jvdelisle at gcc dot gnu dot org changed:
--- Comment #2 from danp57 at optonline dot net 2006-09-09 01:19 ---
There is a syntax error in the code: the function tqli() declaration is missing
the terminal ')'
Dan
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28993
--- Comment #3 from danp57 at optonline dot net 2006-09-09 01:20 ---
I will upgrade...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28993
Bradley,
I would think it would only make sense to try to build 64-bit only using
the --enable-multilib=no and then some incantation of the configure for
a ppc64 target of darwin (which doesn't exist). This really doesn't make
sense to do since, unlike x86_64, Darwin's default libs on both ppc
--- Comment #4 from dberlin at gcc dot gnu dot org 2006-09-09 02:26 ---
Subject: Re: New: Problem creating a new pass
Then i do make and make install without problems,but when i try to compiler a
c
code..
I'd highly suggest you email gcc@, use the current development
version,
--- Comment #9 from mmitchel at gcc dot gnu dot org 2006-09-09 03:17
---
The case in Comment #8 is now broken on 4.1/4.2.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-09 04:10 ---
Confirmed, a regression from 3.3.3 which gave:
t.cc: In function `void f()':
t.cc:10: error: lookup of `C' in the scope of `class C' (`class C') does not
match lookup in the current scope (`class f()::C')
To me
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-09 04:14 ---
Confirmed, not a regression and only happens with the C++ front-end.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Somewhere between r116775 and r116795, the build of libgfortran has become
broken on Darwin PPC. The build now fails with...
/bin/sh ./libtool --mode=compile
/sw/src/fink.build/gcc4-4.1.999-20060908/darwin_objdir/./gcc/xgcc
-B/sw/src/fink.build/gcc4-4.1.999-20060908/darwin_objdir/./gcc/
-B/sw/lib
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-09 04:16 ---
Confirmed, another regression from 3.3.3:
t.cc: In function `void f()':
t.cc:9: qualified type `double' does not match destructor name `~C'
t.cc:9: type of `o' does not match destructor type `double' (type was `C'
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-09 04:22 ---
This is obviously caused by:
* config/darwin.c (machopic_select_section): Support literal16.
(machopic_select_rtx_section): Ditto.
Is a new cctools needed now?
--
pinskia at gcc dot gnu dot org
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-09 04:28 ---
(In reply to comment #1)
Hmm, this worked in 4.2.0 20060821
But it was broke in 4.2.0 20060831.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.0.4 |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28588
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-09 05:03 ---
This looks like it was caused by PR 28588.
In store_init_value, we have a BASELINK.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-09 05:23 ---
If we have another function in the overloaded set for the BASELINK:
class T
{
static void (* handler)();
static void func();
static void func(int);
};
void (*T::handler)() = func;
We don't get the
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-09-09 05:39 ---
I cannot figure out which function should be stripping the BASELINK expression.
OVERLOADS work because perform_implicit_conversion strips it after going
through the overloaded set to figure out which function is
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-09 05:42 ---
This is also related to PR 20039.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-09 05:48 ---
For x86, 3.4.0 produces:
movl4(%esp), %edx
movsbl a+1(%edx),%eax
movsbl b+1(%edx),%edx
addl%edx, %eax
ret
While 4.0.0 produced:
movl4(%esp), %edx
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-09 05:50 ---
Confirmed, the size of the struct is too small to cause it to be returned by
reference.
See the patch at
http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00051.html
for a fix.
--
pinskia at gcc dot gnu dot org
68 matches
Mail list logo
