--- Comment #8 from ebotcazou at gcc dot gnu dot org 2007-11-04 09:57
---
By visual inspection.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2007-11-04 09:58
---
Investigating.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Assigne
--- Comment #2 from raeburn at raeburn dot org 2007-11-04 10:24 ---
Subject: Re: New: error while compiling pthread application
On Nov 3, 2007, at 18:32, bhvijaykumar at gmail dot com wrote:
> srtp_impl.c:8: error: expected expression before ?{? token
> srtp_impl.c:9: error: expected
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-11-04 11:15 ---
As of comment #2
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #14 from fxcoudert at gcc dot gnu dot org 2007-11-04 11:43
---
Yet another comment: this only happens with stabs and -m64 on ppc-darwin8, and
the combination of stabs and -m64 is known as widely broken there (see
http://gcc.gnu.org/ml/gcc-testresults/2007-11/msg00142.html fo
--- Comment #20 from rguenth at gcc dot gnu dot org 2007-11-04 11:45
---
With mainline we now get
.p2align 4,,7
.p2align 3
.L6:
addl$1, %eax
cmpl%eax, %edi
movl%eax, -20(%ebp)
jle .L3
movl%eax, %ecx
mov
--- Comment #4 from lindevel at gmx dot net 2007-11-04 11:47 ---
Created an attachment (id=14482)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14482&action=view)
build.log ICE
Building without setting CFLAGS or CXXFLAGS results in an ICE:
/var/tmp/portage/sys-devel/gcc-4.3.0_pre2
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-11-04 12:47 ---
If you solve the SFT problem, DF needs lot of memory and compile-time in this
testcase on the trunk. The execute() function has lots of basic blocks with
a high number of incoming edges.
So, I have a patch for the
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-11-04 13:34 ---
Some numbers (-O):
4.0.4 needs 596MB peak
4.1.2 needs 2GB peak (and a lot of time)
4.2.2 same as 4.1.2
4.3.0 same as 4.2.2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27004
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-11-04 13:38 ---
Created an attachment (id=14483)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14483&action=view)
patch
Patch to limit the number of SFTs created per function. The limit of 1000 SFTs
brings down memory usage
--- Comment #21 from t dot artem at mailcity dot com 2007-11-04 13:42
---
> I would say let's close this as fixed.
Do you mean that GCC 4.1 and 4.2 will never have this bug fixed and we have to
wait till 4.3 is out?
Besides, have you tested this bug on architectures other that Intel c
--- Comment #31 from hjl at lucon dot org 2007-11-04 14:40 ---
(In reply to comment #30)
> Subject: Re: [4.3 Regression] typeinfo name referenced in ... defined in
> discarded section
>
> On 03/11/2007, at 7:21 AM, hjl at lucon dot org wrote:
>
> > Local symbols should only be referen
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-11-04 14:44
---
Subject: Bug 10220
Author: fxcoudert
Date: Sun Nov 4 14:43:45 2007
New Revision: 129882
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129882
Log:
PR fortran/10220
* dwarf2out.c (add_call
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-11-04 14:46
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #22 from rguenth at gcc dot gnu dot org 2007-11-04 14:53
---
Yes, I looked at i386 and i686 tuned code as well (which gets the addl), the
core2 tuning has this fixed (I didn't measure on AMD CPUs). As both 4.1 and
4.2 are way into maintainance mode and the patch which fixed
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-11-04 15:45
---
FRE doesn't replace a SSA_NAME with another SSA_NAME. So even though VN
figured that e_3 == d_2 == c_1 it doesn't replace them here:
SCCVN says e_3 value numbers to c_1 (VH.5)
SCCVN says d_2 value numbers to c_1
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-04 15:51 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #24 from samuel dot thibault at ens-lyon dot org 2007-11-04
16:42 ---
It's rather the converse: Linux is much like Hurd, since they're both
GNU-based, so quite logically they should share most of the configuration
stuff.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-11-04 19:05 ---
Subject: Bug 32931
Author: pinskia
Date: Sun Nov 4 19:04:49 2007
New Revision: 129886
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129886
Log:
2007-11-04 Andrew Pinski <[EMAIL PROTECTED]>
PR mi
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-11-04 19:05 ---
All fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIG
--- Comment #11 from dberlin at gcc dot gnu dot org 2007-11-04 19:24
---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] Not elimintating the PHIs which have
the same arguments
On 4 Nov 2007 15:45:59 -, rguenth at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #10
--- Comment #18 from tkoenig at gcc dot gnu dot org 2007-11-04 19:51
---
> Looking at Pugh's paper, he shows coefficients for n = 10 and
> r = 10.900511. This is the same as you are using for the double
> case. However, you seem to be missing coefficient d10.
Good catch, thanks!
Th
--- Comment #1 from pcarlini at suse dot de 2007-11-04 20:41 ---
Gosh, this bug is horrible, the -basic- forwarding situation doesn't work with
variadic templates:
void foo(int&&);
void foo(const int&) { }
template
struct identity
{
typedef _Tp type;
};
template
inline _Tp
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-11-04 21:25
---
OK, I have taken some time to investigate this. The problem is not MSYS
specific and also occurs with Cygwin.
I do not think we can fix this. Its not a gfortran bug.
The code is attempting to backspace a standa
--- Comment #19 from dave at hiauly1 dot hia dot nrc dot ca 2007-11-04
21:30 ---
Subject: Re: FAIL: gfortran.dg/gamma_5.f90
> The main problem with the Lanczos approximation are alternating-sign
> terms with nearly cancel each other, which leads to massive precision
> loss.
>
> For z
--- Comment #4 from jakub at gcc dot gnu dot org 2007-11-04 21:35 ---
I'll be testing the following patch. It is quite simplistic, in that it will
give up on bb boundaries, still it should IMHO trigger in quite a lot of cases.
Each optimized out pair of __builtin_stack_save/__builtin_st
With trunk from 20070916 and 20071030 on sparc:
[EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -c -O2 -ftree-vectorize
hdf5-hyperslab.c
hdf5-hyperslab.c: In function 'init_full':
hdf5-hyperslab.c:4: error: invalid reference prefix
{4, 4, 4, 4}
hdf5-hyperslab.c:4: internal compiler error: veri
--- Comment #1 from tbm at cyrius dot com 2007-11-04 22:03 ---
/* Testcase by Martin Michlmayr <[EMAIL PROTECTED]> */
void init_full (char *array, int ny)
{
int j;
char acc = 128;
for (j = 0; j < ny; j++)
*array++ = acc++;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- Comment #2 from tbm at cyrius dot com 2007-11-04 22:05 ---
Created an attachment (id=14484)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14484&action=view)
vectorizer's dump
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33993
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-11-04 22:23 ---
I think this is just a bug in the checking system:
if (!CONSTANT_CLASS_P (t) && !is_gimple_lvalue (t))
{
error ("invalid reference prefix");
return t;
}
CONSTANT_CLASS_P is
The given program can be translated and run and it then produces
incorrect results (details below). Indeed, some circuits from the
GNAT front end seem to indicate an error (use debugging
switch -gnatdF to see this). Also, using -fstack-check adds
a warning that a frame is too large.
The assembly l
-v too_big.adb
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/opt/GCC/43
--enable-languages=c,ada,fortran
Thread model: posix
gcc version 4.3.0 20071104 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-c' '-save-temps' '-gnata
--- Comment #2 from bauhaus at futureapps dot de 2007-11-04 23:02 ---
Side note: With a special command line, this program
triggers a bug box with gcc 4.1.3 (Ubuntu 7.10 i686).
$ gnatmake -W -S -march=x86-64 -m64 -Os too_big.adb
gcc-4.1 -c -W -S -march=x86-64 -m64 -Os too_big.adb
+=
--- Comment #7 from eweddington at cso dot atmel dot com 2007-11-04 23:28
---
With Mike's description in comment #6, confirmed on 4.1.2 and 4.2.2. AVR GCC
4.2.2 is worse than 4.1.2, in that even if sub2 is called with (x+1), the
variable is still 16 bits.
--
eweddington at cso dot a
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last r
--- Comment #1 from sutambe at yahoo dot com 2007-11-05 00:04 ---
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-z
--- Comment #1 from sutambe at yahoo dot com 2007-11-05 00:05 ---
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-z
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-11-05 00:08 ---
Subject: Bug 33272
Author: pinskia
Date: Mon Nov 5 00:08:04 2007
New Revision: 129888
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129888
Log:
Index: ChangeLog
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-11-05 00:08 ---
Subject: Bug 29237
Author: pinskia
Date: Mon Nov 5 00:08:04 2007
New Revision: 129888
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129888
Log:
Index: ChangeLog
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-11-05 00:08 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #32 from geoffk at geoffk dot org 2007-11-05 00:14 ---
Subject: Re: [4.3 Regression] typeinfo name referenced in ... defined in
discarded section
On 04/11/2007, at 6:40 AM, hjl at lucon dot org wrote:
> --- Comment #31 from hjl at lucon dot org 2007-11-04 14:40
> -
--- Comment #33 from hjl at lucon dot org 2007-11-05 00:22 ---
(In reply to comment #32)
>
> What if you want to reference this string from somewhere that should
> never be discarded, like a global variable?
>
Since the string is local, that global variable is defined in
the same fi
--- Comment #34 from hjl at lucon dot org 2007-11-05 00:32 ---
(In reply to comment #33)
> (In reply to comment #32)
> >
> > What if you want to reference this string from somewhere that should
> > never be discarded, like a global variable?
> >
>
> Since the string is local, that g
Consider following trivial C program:
inline int func (int x) { return x + 3 ; }
int main (void) { return func (2) ; }
Compiling with:
gcc -std=c99 file.c -o prog
or
gcc -std=gnu99 file.c -o prog
results in the warning message:
warning: C99 inline functions are not supported
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-05 01:05 ---
No, what it is trying to say 4.2.x does not support fully C99 inline and that
the inline keyword will change in the future to be correct with -std=c99. This
has already been fixed in 4.3.0 where extern inline and in
More crazy issues here, blocking meaningful work :(
Consider the below: it doesn't compile, tries to use the move constructor. If I
define bar in class then things work. Seems kind of broken optimization.
struct type
{
type() { }
type(const type&) { }
private:
type(type&&);
};
template
s
--- Comment #1 from pcarlini at suse dot de 2007-11-05 01:28 ---
Forgot, I said "more" because maybe related to PR33235
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33996
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33604
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33737
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33822
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33837
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33838
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33977
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33993
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33680
--- Comment #35 from geoffk at geoffk dot org 2007-11-05 02:47 ---
Subject: Re: [4.3 Regression] typeinfo name referenced in ... defined in
discarded section
On 04/11/2007, at 4:22 PM, hjl at lucon dot org wrote:
> --- Comment #33 from hjl at lucon dot org 2007-11-05 00:22
> -
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33713
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33763
--- Comment #36 from hjl at lucon dot org 2007-11-05 02:50 ---
The rules for the comdat group are
1. There should be no outside references to local symbols inside of the comdat
group.
2. All comdat groups with the same signature should have the identical set of
defined global symbols.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33826
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
--- Comment #37 from hjl at lucon dot org 2007-11-05 03:01 ---
(In reply to comment #35)
>
>
> - What if the global variable references two or more strings?
All local strings referenced by the global variable should be
in the same comdat group.
> - Won't this cause the global variable
--- Comment #38 from hjl at lucon dot org 2007-11-05 03:03 ---
(In reply to comment #37)
> (In reply to comment #35)
> >
> >
> > - What if the global variable references two or more strings?
>
> All local strings referenced by the global variable should be
> in the same comdat group.
>
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-05 03:09 ---
So if I have emit_move_insn not to produce:
(insn 10 9 11 3 t1.c:10 (set (subreg:SF (reg/v:SI 119 [ c ]) 0)
(reg:SF 123)) -1 (nil))
but instead:
(insn 10 9 11 3 t1.c:10 (set (reg/v:SI 119 [ c ])
(subr
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33922
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33931
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33953
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33984
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33870
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33732
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33923
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33739
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33836
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33856
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33894
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33969
--- Comment #39 from geoffk at geoffk dot org 2007-11-05 03:33 ---
Subject: Re: [4.3 Regression] typeinfo name referenced in ... defined in
discarded section
On 04/11/2007, at 7:01 PM, hjl at lucon dot org wrote:
>> - Won't this cause the global variable to be discarded if anyone
>>
--- Comment #41 from amodra at bigpond dot net dot au 2007-11-05 04:45
---
In reply to #27, I'm reasonably happy with the idea of ld treating a zero
offset into a discarded section as special. I'd also happily approve a patch
that allowed relocations with addends against any local symb
--- Comment #12 from sebpop at gmail dot com 2007-11-05 06:13 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] Not elimintating the PHIs which have
the same arguments
> Replacing ssa names with other ssa names willy-nilly is not always a
> win. We eventually ended up with heuristics to n
81 matches
Mail list logo
