Hi Jonas,
Thanks for this confirmation. To accelerate my processing of these
papers, would it be possible to already have an electronic version of
them by e-mail? Even a generic version would be ok. This way, I can sign
and return you the paper copy as soon as I get it.
Cheers,
Nic.
On Thu,
http://gcc.gnu.org/mirrors.html lists a number of mirrors that are no
longer reachable, doesn't mention that certain mirrors don't have
snapshots, etc. Can you please investigate.
I found problems with the following mirrors:
ftp://ftp.funet.fi/pub/mirrors/ - no longer has a GCC mirror
On Sat, 8 Apr 2006, Martin Michlmayr wrote:
http://gcc.gnu.org/mirrors.html lists a number of mirrors that are no
longer reachable, doesn't mention that certain mirrors don't have
snapshots, etc. Can you please investigate.
I found problems with the following mirrors:
[...]
On Sat, 8 Apr 2006, Martin Michlmayr wrote:
http://gcc.gnu.org/mirrors.html lists a number of mirrors that are no
longer reachable, doesn't mention that certain mirrors don't have
snapshots, etc. Can you please investigate.
I found problems with the following mirrors:
[...]
On Sat, 8 Apr 2006, Martin Michlmayr wrote:
I found problems with the following mirrors:
ftp://ftp.funet.fi/pub/mirrors/ - no longer has a GCC mirror
Thanks for the hint; I just removed this server from our mirrors list.
ftp://ftp.uvsq.fr/pub/gcc/ - unreachable
* Gerald Pfeifer [EMAIL PROTECTED] [2006-04-08 16:15]:
ftp://core.ring.gr.jp/pub/GNU/gcc/ - has no snapshots (and has weird
structure)
ftp://ftp.ring.gr.jp/pub/GNU/gcc/ - has no snapshots (and has weird
structure)
(When you refer to weird structure, is this about gcc3.3 residing in
On Sat, Apr 08, 2006 at 05:02:28PM +0200, Martin Michlmayr wrote:
* Gerald Pfeifer [EMAIL PROTECTED] [2006-04-08 16:15]:
ftp://core.ring.gr.jp/pub/GNU/gcc/ - has no snapshots (and has weird
structure)
ftp://ftp.ring.gr.jp/pub/GNU/gcc/ - has no snapshots (and has weird
structure)
* Daniel Jacobowitz [EMAIL PROTECTED] [2006-04-08 11:07]:
weird structure have a sub-dir for every release, and are missing
some of the other dirs (e.g. infrastructure).
That means they mirror from ftp.gnu.org, rather than gcc.gnu.org.
Right, but should they all be in the same listing?
--
Le vendredi 07 avril 2006 à 02:54 -0500, Aaron W. LaFramboise a écrit :
I have also recently become interested in a GCC port for the 18F.
Can someone summarize who--if anyone--is working on this, how much
progress he has made so far (Is his work based on mainline?), and any
expected future
Snapshot gcc-4.2-20060408 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20060408/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
Mark, can you please update http://gcc.gnu.org/develop.html#timeline
and add more dates for GCC 4.2 and include 4.3.
Thanks.
--
Martin Michlmayr
http://www.cyrius.com/
Hi all,
This may be a silly question but I am a little bit
stuck on it.
I want to use the 512 byte structure which saves the
floating point register state and convert it into a
simulator that uses long double to represent each
st(i) register. Each st register is represented as a
16 bytes with 6
--- Comment #2 from falk at debian dot org 2006-04-08 08:06 ---
I cannot reproduce this anymore with 4.2.0 20060407, so closing.
--
falk at debian dot org changed:
What|Removed |Added
--- Comment #4 from falk at debian dot org 2006-04-08 08:25 ---
I don't see this problem anymore in 4.2.0 20060407, so closing.
--
falk at debian dot org changed:
What|Removed |Added
% cat bug.c
struct Virtual {
virtual ~Virtual() { }
} __attribute__ ((visibility (hidden)));
const void* get_vptr() {
return new Virtual();
}
const void* p = get_vptr();
% g++ -c bug.c
bug.c: In constructor 'Virtual::Virtual()':
bug.c:1: internal compiler error: Segmentation fault
Please
--- Comment #1 from falk at debian dot org 2006-04-08 10:20 ---
Here is a backtrace.
[EMAIL PROTECTED]:/src/gcc-2006.04.07/build/gcc% gdb cc1plus
GNU gdb 6.4-debian
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
[EMAIL PROTECTED]:/tmp% cat test.c
#ifdef __cplusplus
extern C
#endif
void abort(void);
__attribute__((noinline))
unsigned long f(const unsigned long x) {
struct { unsigned long x : 1; } s;
s.x = x;
return s.x;
}
int main() {
if (f(3) != 1)
abort();
}
[EMAIL
Consider
struct Data {
int get() const { return value; }
int value;
};
struct Object {
int operator[](int i) const { return data_m-get(); }
Data *data_m;
};
int foo(Objecto)
{
return o[0];
}
here we have after forwprop
int foo(Object) (o)
{
struct Object * const this;
struct
--- Comment #6 from tkoenig at gcc dot gnu dot org 2006-04-08 17:05 ---
Subject: Bug 25031
Author: tkoenig
Date: Sat Apr 8 17:05:52 2006
New Revision: 112783
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112783
Log:
2006-04-08 Thomas Koenig [EMAIL PROTECTED]
PR
--- Comment #7 from tkoenig at gcc dot gnu dot org 2006-04-08 17:06 ---
Fixed on 4.1. Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-08 17:09 ---
Created an attachment (id=11227)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11227action=view)
prototype patch
I have a prototype patch for forwprop that handles this, but somehow messes up
virtual operands.
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-08 17:21 ---
Hm, we have from DCE to forwprop
struct cpp_token * D.6254;
struct cpp_token * D.6253;
# temp_1334 = V_MAY_DEF temp_330;
# unsignedp_1335 = V_MAY_DEF unsignedp_333;
# op_1336 = V_MAY_DEF op_351;
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-08 18:31 ---
Of course this is from tramp3d, and I hope fixing it would enable the hoisting
of more invariant loads out of the inner loops.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
[ forwarded from http://bugs.debian.org/361441 ]
% cat ice.c
typedef struct {
int array_inputs;
} TNLcontext;
void f(void *);
void _tnl_upgrade_client_data (void *swtnl_context) {
f(((TNLcontext *) swtnl_context)-array_inputs);
int is_writeable = 0;
int *inputs = ((TNLcontext
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-08 18:56 ---
This is a dup of bug 26534.
*** This bug has been marked as a duplicate of 26534 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-08 18:56 ---
*** Bug 27083 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-04-08 18:58 ---
hmhm, merge_alias_info seems to fix it
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27084
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-08 19:04 ---
Looking at the backtrace, this looks like a target specific issue.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||dberlin at gcc dot gnu dot
|
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-08 19:09 ---
forwrop when propragating better be using merge_ssa_info anyways, just like
copy prop and such.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27084
Basically, we have
before PRE:
bb 3:
# c_92 = PHI c_88(19), c_6(23);
L1:;
# VUSE SMT.18086_30;
D.571515_36 = fieldEngineBase_5-stride_m;
D.571516_37 = m_104 * D.571515_36;
D.571517_38 = c_92 + D.571516_37;
# VUSE SMT.18086_30;
D.571521_46 =
--- 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 #10 from stevenb dot gcc at gmail dot com 2006-04-08 21:13
---
Subject: Re: IVs with the same evolution not eliminated
The new SCC value numberer for PRE i'm working on gets this case right (and
this is in fact, one of the advantages of SCC based value numbering).
Is
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-08 21:46 ---
This really has nothing to do with PRE except for PRE adding a new variable
which contains no aliasing info attached to it so we lose information because
our aliasing system sucks.
--
--- Comment #2 from tkoenig at gcc dot gnu dot org 2006-04-08 21:47 ---
Checking wether size is negative won't work as
a complete fix for this.
Consider the following example:
$ cat a4.f90
program main
real, allocatable:: a(:,:)
allocate (a(1:-1,1:-1))
print *,size(a)
end
--- 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
[ forwarded from http://bugs.debian.org/361501 ]
% cat ice2.c
extern int ptbl[16];
extern int ctbl[16];
void doViews(void) {
int *p = ptbl, *c = ctbl;
while (1) {
c++;
p++;
if (*p (p != c || *c))
return;
}
}
% gcc-4.0 -c -O2 ice2.c
%
[EMAIL PROTECTED]:/tmp% cat min4.c
inline unsigned length() {
return 0;
}
unsigned add_new_phrase() {
return 16 / (1 (length() - 1));
}
[EMAIL PROTECTED]:/tmp% gcc -c min4.c
[EMAIL PROTECTED]:/tmp% gcc -c -O min4.c
min4.c: In function 'add_new_phrase':
min4.c:5: internal
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-04-08 23:11 ---
Here is the patch which fixes this issue for me:
Index: cp-objcp-common.c
===
--- cp-objcp-common.c (revision 112789)
+++ cp-objcp-common.c
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-08 23:13 ---
Confirmed, the ICE is in fold-const.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-08 23:14 ---
in fact when folding 16 / 0 But the 0 has overflowed bit marked so ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27088
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-08 23:16 ---
Confirmed, the ICE is during DOM.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from stevenb dot gcc at gmail dot com 2006-04-08 21:13
---
Subject: Re: IVs with the same evolution not eliminated
The new SCC value numberer for PRE i'm working on gets this case right (and
this is in fact, one of the advantages of SCC based value numbering).
--- Comment #11 from dberlin at gcc dot gnu dot org 2006-04-08 23:20
---
Subject: Re: IVs with the same evolution not
eliminated
--- Comment #10 from stevenb dot gcc at gmail dot com 2006-04-08 21:13
---
Subject: Re: IVs with the same evolution not eliminated
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-08 23:28 ---
I am testing the C++ patch right now. It is always a better idea to fix a pass
to do what it should be doing instead of hacking another one to do the same.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27084
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-09 00:58 ---
Here is a testcase making sure that fold does not get in the way:
extern int ptbl[4];
extern int ctbl[4];
void doViews(void) {
int *c = ctbl, *p = ptbl;
while (1)
{
p++;
c++;
if
This fault occurs in the compilation of tonto-2.2. A fix will be posted to the
list in a few minutes. There is still another problem with tonto that I am
still investigating. I will post that just as soon as I isolate it.
Paul
module test
publicn_elements_uncommon_with_
interface
--- Comment #1 from pault at gcc dot gnu dot org 2006-04-09 04:55 ---
Duuuh! I forgot a little something...
In file test.f90:19
integer(4), dimension(n_elements_uncommon_with_(x)) :: res
1
Error: Expression at (1) must be of INTEGER type
In file
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot
|dot org
49 matches
Mail list logo
