--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-17 07:59 ---
(In reply to comment #2)
Two things, we just don't jump thread.
The testcase mentioned in comment #2 is fixed but we still don't make an
infinite loop for the orginal case:
L9:;
switch (i_lsm.25)
{
case
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Last reconfirmed|2006-02-22 09:55:47
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-17 08:25 ---
I was thinking about this one recently, I might implement this because we could
do it also for:
int f(_Bool a)
{
if (!a)
return 1000;
return 1001;
}
Where we really only need to swap the two arms and such.
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-09-17 08:44 ---
Just to clarify what testcase is still broken, here it is:
void baz (void)
{
if (12ers + 1 == 0)
bar ();
}
--
The reason why strchr testcase is fixed is because we turn the strchr call into
12ers[1].
--
--- Comment #7 from jason dot morgan at vpnsolutions dot uk dot com
2006-09-17 08:47 ---
Subject: RE: compiler generates incorrect ARM instructions when using long
bitfields
Why not? What are the criteria? It is obviously wrong and would be so
simple to fix, even optionally with a
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-09-17 08:51 ---
(In reply to comment #7)
Subject: RE: compiler generates incorrect ARM instructions when using long
bitfields
Why not? What are the criteria? It is obviously wrong and would be so
simple to fix, even
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-17 09:08 ---
Reduced testcase:
struct Observer
{
template typename T void observeComponent ();
};
template typename T
struct TagFilter : Observer
{
TagFilter ()
{
observeComponent int ();
}
};
--
This
--- Comment #8 from irar at gcc dot gnu dot org 2006-09-17 09:18 ---
Subject: Bug 21591
Author: irar
Date: Sun Sep 17 09:17:51 2006
New Revision: 117003
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117003
Log:
PR tree-opt/21591
* tree-data-ref.c
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-17 09:18 ---
Fixed on the mainline:
t1.cc:4: error: int foo::mf() is private
t1.cc:10: error: within this context
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from steven at gcc dot gnu dot org 2006-09-17 09:54 ---
Created an attachment (id=12286)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12286action=view)
patch implementing what Ian suggested
See http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00271.html
--
steven
[EMAIL PROTECTED] pr29098]# cat ../prs/homer.f90
type :: homer
integer, pointer :: bart(:)
end type homer
type(homer) :: marge
integer :: duff_beer
marge = homer (duff_beer)
end
[EMAIL PROTECTED] pr29098]# /svn-4.2/bin/gfortran ../prs/homer.f90f90
../prs/homer.f90: In function
--- Comment #4 from patchapp at dberlin dot org 2006-09-17 11:30 ---
Subject: Bug number PR29098
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00671.html
--
--- Comment #4 from patchapp at dberlin dot org 2006-09-17 11:40 ---
Subject: Bug number PR29060
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00672.html
--
--- Comment #3 from patchapp at dberlin dot org 2006-09-17 12:45 ---
Subject: Bug number PR28817
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00674.html
--
--- Comment #4 from steven at gcc dot gnu dot org 2006-09-17 13:15 ---
Subject: Bug 25993
Author: steven
Date: Sun Sep 17 13:14:53 2006
New Revision: 117005
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117005
Log:
gcc/
PR c/25993
* c-opts.c
--- Comment #5 from steven at gcc dot gnu dot org 2006-09-17 13:17 ---
Fixed on the trunk.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Known to
--- Comment #4 from bdavis at gcc dot gnu dot org 2006-09-17 13:54 ---
before the patch:
$ time /usr/local/bin/gfortran -c data.f90
real3m1.263s
user3m0.519s
sys 0m0.120s
after:
$ time /usr/local/bin/gfortran -c data.f90
real0m3.215s
user0m3.052s
sys 0m0.092s
--- Comment #2 from steven at gcc dot gnu dot org 2006-09-17 13:57 ---
Probably a problem with all 64 bit hosts.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from steven at gcc dot gnu dot org 2006-09-17 13:59 ---
This is an initial RTL generation problem. The ICE happens in
instantiate-virtual-regs but the offending insn already exists right after
expand:
;; Generating RTL for tree basic block 2
;; a = 25214903917
(insn 7
--- Comment #4 from steven at gcc dot gnu dot org 2006-09-17 14:07 ---
Are you _really_ sure this worked with GCC 3.4.5?
$ ./cc1 --version
GNU C version 3.4.6 (hppa2.0-linux-gnu)
compiled by GNU C version 4.0.2 20050901 (prerelease) (SUSE Linux).
GGC heuristics: --param
--- Comment #5 from steven at gcc dot gnu dot org 2006-09-17 14:18 ---
$ ./cc1 --version
GNU C version 3.3.6-hammer 20050117 (prerelease) (hppa2.0-linux-gnu)
compiled by GNU C version 4.0.2 20050901 (prerelease) (SUSE Linux).
GGC heuristics: --param ggc-min-expand=98 --param
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Known to fail|4.1.1 4.2.0 |3.3.6 3.4.6 4.1.1
int n = 0, p[n * 0 + 1];
For C90 and C99, as of June SVN at least, and going back at least as far as
3.3.3.
Almost certainly because of overly early CF.
--
Summary: Failure to diagnose violation of constraint 6.7.5.2p2
Product: gcc
Version: 4.2.0
--- Comment #9 from jason dot morgan at vpnsolutions dot uk dot com
2006-09-17 15:14 ---
Subject: RE: compiler generates incorrect ARM instructions when using long
bitfields
Surely that's the definition of a bug?
I've heard of If it ain't broke, don't fix it.. but never If it's
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-09-17 15:21
---
(In reply to comment #9)
Subject: RE: compiler generates incorrect ARM instructions when using long
bitfields
Surely that's the definition of a bug?
I've heard of If it ain't broke, don't fix it.. but
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-09-17 15:23 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-17 15:26 ---
Confirmed, not a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-17 15:32 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-17 15:39 ---
So what is the problem here? This works for me when I am building a cross
compiler with a sysroot.
What configure options are you using?
--
pinskia at gcc dot gnu dot org changed:
What|Removed
/*
Hi,
in the following program the copy constructor of class C is called with
the constructor argument having the same address as the to be constructed
object.
Best regards,
Oliver Schmidt
$ for i in g++-3.3 g++-3.4 g++-4.0; do echo ; $i --version;
$i -Wall t3.cpp; a.out ;
=== libstdc++ tests ===
Running target unix
WARNING: program timed out.
FAIL: 19_diagnostics/23591_thread-1.c execution test
...
WARNING: program timed out.
FAIL: ext/mt_allocator/22309_thread.cc execution test
WARNING: program timed out.
FAIL: thread/18185.cc execution test
WARNING: program
--- Comment #4 from patchapp at dberlin dot org 2006-09-17 17:40 ---
Subject: Bug number PR20779
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00680.html
--
--- Comment #7 from kristian dot hermansen at gmail dot com 2006-09-17
18:37 ---
Will gcc/g++ integrate the Wcoercion project's solution? It seems to have been
sponsored by Google's Summer of Code 2006. Maybe it will be tested/included
soon? Here is the developer: [EMAIL PROTECTED]
--- Comment #8 from kristian dot hermansen at gmail dot com 2006-09-17
18:39 ---
Sorry, I didn't notice at first that this was you!!! Will you integrate
Wcoercion into gcc/g++ soon or will it always remain a side project? It would
be nice to see such a warning come from using -Wall.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-17 18:51 ---
Well d2, we call the default operator= with lhs and rhs as the same.
So which version do you think have a bug?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29117
--- Comment #6 from vapier at gentoo dot org 2006-09-17 19:13 ---
i had a report from someone that it worked with 3.4.5; i only verified that
4.1.1 was ICEing
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29114
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-17 19:27 ---
Confirmed, still broken as of today 4.1.2 20060917.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-09-17 19:31
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|template constructor in |[4.0/4.1/4.2 Regression]
|template class derived
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.1.2 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9715
==+
| 4.2.0 20060917 (experimental) (i686-pc-linux-gnu) Assert_Failure
atree.adb:812|
| Error detected at subjects.ads:17:3 |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-09-17 19:49 ---
Fixed by:
2005-11-12 Eric Botcazou [EMAIL PROTECTED]
* function.c (assign_stack_local_1): Restrict sanity check
on frame size overflow to 32-bit and above platforms.
--
pinskia at gcc dot gnu
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-09-17 19:57
---
Fixed so closing as such.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-09-17 19:57 ---
Fixed so closing as such.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from danglin at gcc dot gnu dot org 2006-09-17 20:05 ---
There's a question in my mind as to whether we should always be
emitting a library call:
/* When not optimizing, generate calls to library functions for a certain
set of builtins. */
if (!optimize
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2006-09-17 20:14
---
Problem is not in library side.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from danglin at gcc dot gnu dot org 2006-09-17 20:21 ---
Hmmm, seems this is a known issue that never got fixed. See this thread:
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01558.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29111
--- Comment #9 from tbm at cyrius dot com 2006-09-17 20:31 ---
It's aiming for inclusion in GCC 4.3, see
http://gcc.gnu.org/wiki/GCC_4.3_Release_Planning
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26167
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-09-17 21:02 ---
Well, you are right. This bug is a dup of the bug requesting -Wcoercion (if we
have such).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26298
Hi,
I got an internal compiler error while compiling a source file.
I was not able to reproduce the bug on a smaller source file.
I only notice that the error occurs when I add an
__asm__ volatile (movl %0,%%eax::m(get_segment_base_address(*entry)));
but not at the line of this addition.
On gcc
--- Comment #1 from remy dot saissy at gmail dot com 2006-09-17 21:25
---
Created an attachment (id=12287)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12287action=view)
The .i file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29119
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-17 21:57 ---
Reduced testcase:
void ldt_add_entry(void)
{
__asm__ ( :: m(({unsigned __v; __v;})));
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-17 22:01 ---
We must had forgot to mark the variable as ADDRESSABLE.
Also this used to work with the C++ front-end in 4.1.x but now does not in
4.2.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29119
--- Comment #6 from rakdver at gcc dot gnu dot org 2006-09-17 22:48 ---
(In reply to comment #4)
Actually this is just a problem of IV selection, what is happening is the IV
selection chooses the 1024+(const char *)base[quad] as the IV instead of just
base[quad] which causes the
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-09-18 00:18 ---
We should never warn on multiply because it is just too crazy to. This is what
debugging is about, debug your program for mistakes like this.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-18 00:48 ---
Confirmed, a regression from 3.3.3 which gave:
t.cc:4: error: address of non-extern `foo' cannot be used as template argument
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-18 01:15 ---
Can you try a 4.0.2 or a 4.1.1 version of GCC?
Also can you give the part of the log of where the command failed?
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21544
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-09-18 01:24
---
So the only bug here is that -Os produces an extra move. That comes from the
register allocator/reload:
Reloads for insn # 13
Reload 0: reload_in (SI) = (reg:SI 1 dx [65])
GENERAL_REGS, RELOAD_FOR_INPUT
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-18 01:38 ---
This code still involes undefined runtime behavior. So the warning is valid.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from pinskia at gcc dot gnu dot org 2006-09-18 01:45
---
(In reply to comment #13)
Notice in the tektester.386.s testcase, you have an xor instruction on ebx,
when all what's needed to clear out al/ax/eax is a
mov $0, al/ax/eax
xor is both faster and has a smaller
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-18 01:49 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from sayle at gcc dot gnu dot org 2006-09-18 01:54 ---
Subject: Bug 28887
Author: sayle
Date: Mon Sep 18 01:54:33 2006
New Revision: 117012
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117012
Log:
2006-09-17 Zdenek Dvorak [EMAIL PROTECTED]
PR
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-09-18 02:04 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-09-18 03:13
---
The problem here is the x86 back-end pushes constant vectors to the constant
pool.
Note my patch will not work any more because it has been outdated to take into
account the new CONSTRUCTOR layout.
--
pinskia
--- Comment #17 from bryce at mckinlay dot net dot nz 2006-09-18 03:49
---
(In reply to comment #15)
Yes, I think the #ifdef is a reasonable solution. Stack traces will be
inaccurate when GetIPInfo is unavailable, but I don't see any easy way around
that.
--
--- Comment #7 from steven at gcc dot gnu dot org 2006-09-18 04:15 ---
To cut down the estimate for the loop size, you need to treat CALL_EXPRs to
machine specific builtins specially (and probably some of the normal builtins
too). See estimate_num_insns_1, the case for CALL_EXPR. You
--- Comment #18 from howarth at nitro dot med dot uc dot edu 2006-09-18
04:34 ---
Created an attachment (id=12288)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12288action=view)
Patch to revert to _Unwind_GetIP when HAVE_GETIPINFO undefined
--
--- Comment #19 from howarth at nitro dot med dot uc dot edu 2006-09-18
04:40 ---
Tested the patch on Darwin 8 with no regressions. Verified that the
_Unwind_GetIPInfo
symbols are absent for libgcj with HAVE_GETIPINFO undefined. While the patch is
over
10 lines, I would argue that I
--- Comment #20 from howarth at nitro dot med dot uc dot edu 2006-09-18
04:58 ---
Created an attachment (id=12289)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12289action=view)
clean up whitespace in Changelog for patch to revert to _Unwind_GetIP when
HAVE_GETIPINFO undefined
--- Comment #10 from alexey at hyperroll dot com 2006-09-18 05:48 ---
(In reply to comment #9)
We should never warn on multiply because it is just too crazy to. This is
what
debugging is about, debug your program for mistakes like this.
The citation may be used to eliminate every
--- Comment #8 from tbptbp at gmail dot com 2006-09-18 05:52 ---
Subject: Re: IV selection is messed up
On 17 Sep 2006 22:48:12 -, rakdver at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
Regarding the -fprefetch-loop-arrays's heuristic is way off the mark part,
gcc badly
73 matches
Mail list logo
