--- Comment #9 from rguenth at gcc dot gnu dot org 2008-02-04 22:35 ---
Subject: Bug 33631
Author: rguenth
Date: Mon Feb 4 22:34:21 2008
New Revision: 132101
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132101
Log:
2008-02-04 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-02-04 22:34 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from dgregor at gcc dot gnu dot org 2008-02-04 23:31 ---
Looking into this a little bit, the new save_template_attributes is modifying
the type node directly (adding new attributes), but that type node can then get
out of sync with other type nodes if it was the TYPE_MAIN_
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2008-02-04 23:40
---
(In reply to comment #2)
> I have confirmed this under cygwin. Taking the READ statement out so the
> program can run unabated, leads to a system failure trying to allocate
> memory.
> This is platform specific,
--- Comment #6 from alexlh at funk dot org 2008-02-05 00:14 ---
I have the same problem: line 2: exec: -m: invalid option
Trying to build 4.2, the directory specified in --prefix *is* writable by the
user running the build.
--
alexlh at funk dot org changed:
What|Rem
--- Comment #33 from rguenth at gcc dot gnu dot org 2008-02-04 21:13
---
Approved by Ian on IRC, committed, fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #34 from rguenth at gcc dot gnu dot org 2008-02-04 21:13
---
Subject: Bug 35035
Author: rguenth
Date: Mon Feb 4 21:12:49 2008
New Revision: 132095
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132095
Log:
2008-02-04 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-02-04 22:46 ---
Not inlining always_inline is wrong-code. It's not clear which testcase is
a regression - how is the status for 4.2.3?
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2008-02-04 22:51
---
(In reply to comment #4)
> I did not test your patch, but without the common line, the dump contains
> "gfhzjf" until you remove the volatile. This saves you from reading assembler.
Thanks! This allowed me to rea
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-02-04 22:55 ---
(In reply to comment #8)
> Not inlining always_inline is wrong-code. It's not clear which testcase is
> a regression - how is the status for 4.2.3?
>
Only the testcase in comment #1 is a regression. 4.2.3 does no
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2008-02-05 00:42
---
(In reply to comment #5)
> We don't, however, handle the case where we mark volatile the other variable
> involved in the equivalence:
OK, Richard Maine and Steve Lionel confirmed that equivalence shouldn't
inter
The first one is:
Executing on host: /mnt/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran
-B/
mnt/gnu/gcc/objdir/gcc/testsuite/gfortran/../../
/mnt/gnu/gcc/gcc/gcc/testsuite/
gfortran.dg/actual_array_constructor_2.f90 -O0 -pedantic-errors
-L/mnt/gnu/
gcc/objdir/hppa2.0w-hp-hpux11.11/./li
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|c |middle-end
Summary|[Regression 4.2] 841|[4.2 Regre
--- Comment #7 from w6ws at earthlink dot net 2008-02-05 01:25 ---
Subject: Re: VOLATILE attribute not being honored with
common block variable
Gosh - one learns something everyday. The bit with EQUIVALENCE is an
interesting twist!
It seems that F2003 would allow maximum flexibility
--- Comment #6 from janis at gcc dot gnu dot org 2008-02-05 02:23 ---
There's another mess hiding under the ABI change, which is that synthetic
vectors of the same size as AltiVec vectors are passed differently for
-mabi=altivec than for -mabi=no-altivec. There are warnings for syntheti
--- Comment #66 from dave at hiauly1 dot hia dot nrc dot ca 2008-02-05
02:42 ---
Subject: Re: wo_prof_two_strs.c:56: internal compiler error: in
find_new_var_of_type, at ipa-struct-reorg.c:605
> If so, there is still question why the tests do not fail without struct-reorg.
> Or they f
--- Comment #7 from drow at gcc dot gnu dot org 2008-02-05 03:19 ---
Subject: Re: no-altivec ABI should be fixed or no longer
be the default
On Tue, Feb 05, 2008 at 02:23:20AM -, janis at gcc dot gnu dot org wrote:
> There's another mess hiding under the ABI change, which i
--- Comment #16 from aoliva at gcc dot gnu dot org 2008-02-05 03:35 ---
Jakub, build_identity_conv is correct, at least in this case. In C++, the
bitfieldness :-) of a variable is not to be taken into account for purposes of
overload resolution. So, when tfrom != from, this means it is
--- Comment #3 from dnovillo at gcc dot gnu dot org 2008-02-05 04:18
---
Subject: Bug 33738
Author: dnovillo
Date: Tue Feb 5 04:17:58 2008
New Revision: 132111
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132111
Log:
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg0011
--- Comment #4 from dnovillo at gcc dot gnu dot org 2008-02-05 04:29
---
Fixed. http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00110.html.
--
dnovillo at gcc dot gnu dot org changed:
What|Removed |Added
Building gcc-trunk rev 132111 (2008-02-05) for i386-rtems* (elf w/ newlib)
fails with:
...
make[7]: Entering directory
`/users/rtems/src/toolchains/BUILD/i386-rtems4.9/i386-rtems4.9/soft-float/newlib/libm'
Making all in math
make[8]: Entering directory
`/users/rtems/src/toolchains/BUILD/i386-rtems4
--- Comment #1 from corsepiu at gcc dot gnu dot org 2008-02-05 05:11
---
Created an attachment (id=15097)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15097&action=view)
preprocessed source of file producing ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35083
--- Comment #5 from ghazi at gcc dot gnu dot org 2008-02-05 05:23 ---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00112.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35070
--- Comment #17 from mmitchel at gcc dot gnu dot org 2008-02-05 05:22
---
I would suggest inserting the conversion right before the call to
build_target_expr_with_type in convert_like_real:
if ((lvalue & clk_packed)
&& CLASS_TYPE_P (type)
&&
[EMAIL PROTECTED] stack-2]$ cat x.i
float essef(float) __attribute__((sseregparm));
extern float f;
void test(void)
{
f = essef(f);
}
[EMAIL PROTECTED] stack-2]$ /usr/gcc-4.3/bin/gcc -m32 -mno-sse -S x.i
x.i: In function 'test':
x.i:5: error: Calling 'float(float)' with attribute sseregparm withou
--- Comment #1 from hjl dot tools at gmail dot com 2008-02-05 05:52 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00114.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #2 from hjl dot tools at gmail dot com 2008-02-05 05:53 ---
With the patch, I got
lake:pts/2[10]> ./xgcc -B./ -m32 -mno-sse -S x.i
x.i: In function âtestâ:
x.i:5: error: Calling âessefâ with attribute sseregparm without SSE/SSE2
enabled
--
http://gcc.gnu.org/bug
--- Comment #18 from aoliva at gcc dot gnu dot org 2008-02-05 06:20 ---
Ugh. I've just posted a patch that uses fold_convert at that very spot, and
then I saw your suggestion. I'll re-test with that instead.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35056
--- Comment #2 from aoliva at gcc dot gnu dot org 2008-02-05 05:58 ---
I don't see that preserving the information can be accomplished in a simpler
way than what's being implemented in the VTA branch :-( Any other attempt to
retain an expression that is not used anywhere, is such that
The below code snippet compiles on gcc 3.4.6
gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-8)
but fails on gcc 4.1.1
gcc-4.1.1 (GCC) 4.1.1 20060724 (prerelease) (4.1.1-4pclos2007)
with erros such as
namespace_operator_new.cpp:8: error: void* my_alloc::operator new(size_t,
char*, int) may not be declar
FAIL: gcc.dg/vect/vect-iv-9.c scan-tree-dump-times vect "vectorized 1 loops" 2
Not much detail in logs,
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/usr --bindir=/usr/bin --libdir=/usr/lib
--libexecdir=/usr/lib --includedir=/usr/include --mandir=/usr/sha
--- Comment #2 from ubizjak at gmail dot com 2008-02-05 07:33 ---
Confirmed.
The testcase:
float test(unsigned int x)
{
return (float)x;
}
gcc -O2 -mno-80387
t.c: In function âtestâ:
t.c:4: error: unrecognizable insn:
(insn 20 19 21 5 t.c:2 (set (reg:SF 60)
(plus:SF (reg:SF
101 - 132 of 132 matches
Mail list logo
