Currently, it is not possible to use SSE 4.1 variable blend instructions in asm
statements. These instructions require the third argument to be in %xmm0, but
gcc fails to allocate correct register even when (new) z constraint is used.
--cut here--
typedef float V4SFmode
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-04 07:22 ---
How can this be a regression if the constraint is new?
Also it seems like you could use register asm(xmm0) to get the correct
register to be used.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #2 from ubizjak at gmail dot com 2007-06-04 07:39 ---
(In reply to comment #1)
How can this be a regression if the constraint is new?
This is the same failure as PR32189, and that one is marked as a regression.
Also it seems like you could use register asm(xmm0) to get
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-04 07:50 ---
Also it seems like you could use register asm(xmm0) to get the correct
register to be used.
But please note that c argument is passed to the function via xmm2.
So this is why GCC has register asm() extension is
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-04 07:58 ---
Note local allocate should be able to figure the z constraint is only one
register and assign it to that pesdu-register.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32201
--- Comment #5 from ubizjak at gmail dot com 2007-06-04 08:06 ---
Created an attachment (id=13655)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13655action=view)
Local alloc RTL dump
RTL dump of .c.163r.lreg
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32201
--- Comment #4 from jbglaw at lug-owl dot de 2007-06-04 08:18 ---
That was already known in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30563 ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30537
--- Comment #4 from rob1weld at aol dot com 2007-06-04 08:30 ---
Results:
Results for 4.3.0 20070602 (libc6_2.3.6.ds1-13) testsuite on i686-pc-linux-gnu
http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg00168.html
Results for 4.3.0 20070602 (libc6_2.6~20070518-2) testsuite on
Please read first portion of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32193
to see the where and how of obtaining and installing new libc6, then come back
here.
After upgrading my library I did a diff of the make -i check test results of
the build before I upgraded and after I upgraded. It was
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-04 08:37 ---
No need because this failure is a random failure anyways.
*** This bug has been marked as a duplicate of 32057 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-06-04 08:37 ---
*** Bug 32202 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32057
--- Comment #2 from dominiq at lps dot ens dot fr 2007-06-04 08:44 ---
Subject: Re: Upgrading GNU/Linux to libc6_2.6~20070518-2
fails gfortran.dg/secnds.f
No need because this failure is a random failure anyways.
Afterall not so random: most of the failures are due to the fact
that
--- Comment #7 from rob1weld at aol dot com 2007-06-04 08:58 ---
[EMAIL PROTECTED]
IEEE 754 does not discuss any of the functions you list above. In fact,
IEEE 754 places requirements on exactly one function in libm, and that is
sqrt(), which must be exact in all rounding modes.
--- Comment #8 from rob1weld at aol dot com 2007-06-04 09:07 ---
[EMAIL PROTECTED]
Can you suggest a download URL?
Mine is from ATT. I didn't save the URL. Your output is certainly a few pages
shorter than mine. There is a Paranoia test included in Ucbtest that has output
similar to
--- Comment #9 from rob1weld at aol dot com 2007-06-04 09:16 ---
There is a wiki here - your contributions are appreciated.
http://en.wikipedia.org/wiki/IEEE_754r
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32180
As requested: http://gcc.gnu.org/ml/fortran/2007-06/msg00013.html
timef() allows one easily to track elapsed time. It is supported by a couple of
vendors such as IBM and Intel, but not by gfortran, g95, g77, sunf95, NAG f95.
--- Comment #1 from dominiq at lps dot ens dot fr 2007-06-04 11:25 ---
As far as I can tell this bug seems to affect only darwin7.
The ICE occurs with RESHAPE and EOSHIFT with character arrays and a third
optional argument:
The following code
character(len=1) :: tempn(1,2)
X-Bugzilla-Reason: CC
First: I apologize if this report is missing something but I did not find
enough information in the guidelines to be more accurate. Furthermore, I have
only gcc 4.1.2 prerelease available (from Suse Linux 10.2), so I will be glad
if somebody tells me the bug has been fixed
--- Comment #8 from ubizjak at gmail dot com 2007-06-04 12:27 ---
A bit of debugging leads to following findings:
build_common_builtin_nodes() defines supported complex mul/div functions
depending on lang_hooks.types.type_for_mode(). This langhook defaults to
c_common_type_for_mode().
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32182
Consider the following code:
% cat unused.cpp
static int GetFoo() { return 17; }
static int foo = GetFoo();
void bar()
{
}
This compiles without warnings:
% g++ -Wall -c unused.cpp
%
However if any error is introduced, like e.g. removing the closing brace of the
bar() function, then we get
--- Comment #12 from mec at google dot com 2007-06-04 13:35 ---
Verified with my two test programs with snapshot gcc-4.3-20070601. Thanks for
the fast fix!
--
mec at google dot com changed:
What|Removed |Added
--- Comment #3 from manu at gcc dot gnu dot org 2007-06-04 13:51 ---
Likely, the code for parsing template arguments is not clever enough to stop as
soon as something goes awry and report it correctly.
--
manu at gcc dot gnu dot org changed:
What|Removed
--- Comment #165 from rguenth at gcc dot gnu dot org 2007-06-04 14:02
---
The lates patch fixes the FreePOOMA testsuite regressions. I'll give it a
performance testing spin on vangelis tonight.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
--- Comment #4 from igodard at pacbell dot net 2007-06-04 14:27 ---
Well, in my ignorance, I'd say that the symptoms are consistent with scanning
forward to the next , regardless of what gets scanned over, such an
unmatched or statement-lists.
--
--- Comment #28 from rguenth at gcc dot gnu dot org 2007-06-04 15:28
---
solution_set_add () looks like the culprit (thx micha). So, the following will
fix it in case we have offsets only from COMPONENT_REFs, not from regular
pointer arithmetic (which is not true):
Index:
--- Comment #29 from rguenth at gcc dot gnu dot org 2007-06-04 15:45
---
We can make it safe if we only really handle + in pointer arithmetic. Like
with
@@ -3258,7 +3255,7 @@ handle_ptr_arith (VEC (ce_s, heap) *lhsc
unsigned int i = 0;
unsigned int j = 0;
VEC (ce_s, heap)
--- Comment #15 from sje at gcc dot gnu dot org 2007-06-04 15:58 ---
Subject: Bug 31733
Author: sje
Date: Mon Jun 4 15:58:12 2007
New Revision: 125312
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125312
Log:
PR target/31733
* cfgrtl.c (rtl_verify_flow_info):
--- Comment #16 from sje at cup dot hp dot com 2007-06-04 16:03 ---
Fixed now. All testcases are working with ToT.
--
sje at cup dot hp dot com changed:
What|Removed |Added
# of unsupported tests 46
/Users/dir/gfortran/ibin/gcc/testsuite/gfortran/../../gfortran version 4.3.0
20070604 (experimental)
--
Summary: gfortran testsuite - unexpected failures
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-04 16:11 ---
Only semi unexpected, the issue hasto do with fp rounding,
*** This bug has been marked as a duplicate of 32057 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-06-04 16:11
---
*** Bug 32206 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
the following testcase express one condition in three different ways.
in fact, gcc produces only two different warnings.
extern void z();
void f() { if ( z ) z(); }
void g() { if ( z != 0 ) z(); }
void h() { if ( z != (void*)0 ) z(); }
t.c: In function 'f':
t.c:2: warning: the address of 'z'
--- Comment #4 from aldot at gcc dot gnu dot org 2007-06-04 17:20 ---
fx, are you still working on this?
yet another reason why -M as an alias for -J should be dropped and instead
proper -M dependency handling should be added is this:
$ echo end foo.f90 gfortran -o main foo.f90 -v
--- Comment #10 from kargl at gcc dot gnu dot org 2007-06-04 17:32 ---
(In reply to comment #7)
[EMAIL PROTECTED]
IEEE 754 does not discuss any of the functions you list above. In fact,
IEEE 754 places requirements on exactly one function in libm, and that is
sqrt(), which must
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-06-04 17:39
---
(In reply to comment #4)
fx, are you still working on this?
Not actively. It's probably not so hard, though: read the file, like we do with
-fsyntax-only mode, and parse #file headers.
yet another reason why
--- Comment #9 from ubizjak at gmail dot com 2007-06-04 17:42 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00188.html
(Please do not open new bugreport for missing _multc3 and _divtc3. These will
be added as a follow-up patch).
--
ubizjak at gmail dot com changed:
--
ubizjak at gmail dot com changed:
What|Removed |Added
CC|ubizjak at gmail dot com|
AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com
--- Comment #11 from theodore dot papadopoulo at sophia dot inria dot fr
2007-06-04 18:12 ---
(In reply to comment #8)
I suspect (unless I'm overlooked something) that this problem cause wrong
statistics when using jointly the -fopenmp and -profile-* flags.
I tried that and seen
[EMAIL PROTECTED]:~/exp-43-redux$ cat vector-fill.cc
// Copyright 2007, Google Inc. All rights reserved.
// Author: [EMAIL PROTECTED] (Michael Chastain)
#include vector
std::vectorint my_vector (117);
===
[EMAIL PROTECTED]:~/exp-43-redux$ /home/mec/gcc-4.3-20070601/install/bin/g++
-Wall
-S
Comparing stages 2 and 3
warning: ./cc1-checksum.o differs
Bootstrap comparison failure!
./cfgloopanal.o differs
./expmed.o differs
./df-problems.o differs
./combine.o differs
./ebitmap.o differs
./emit-rtl.o differs
./reload.o differs
./cgraphunit.o differs
./c-typeck.o differs
./recog.o differs
--- Comment #10 from uros at gcc dot gnu dot org 2007-06-04 20:07 ---
Subject: Bug 32191
Author: uros
Date: Mon Jun 4 20:07:37 2007
New Revision: 125314
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125314
Log:
PR c/32191
* gcc/c-common.c (c_define_builtins):
--- Comment #11 from ubizjak at gmail dot com 2007-06-04 20:08 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from andreast at gcc dot gnu dot org 2007-06-04 20:09
---
can you post the config flags? Did you may use --disable-checking ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32209
In the following testcase:
#include new
#include stdlib.h
#include stdio.h
class c1
{
public:
char m1 : 17;
//char m2;
};
void printbytes(void * p, int size)
{
printf(Printing an object on %i bytes\n,size);
for (int i=0; isize; i++)
printf(Byte %i is %i\n,i, ((char*)p)[i]);
While compiling KDE 3.5.7, this appears:
-
Making all in interfaces
make[5]: Entering directory
`/initrd/mnt/dev_save/VBProjects/passwordlinux/kde/konstruct/kde/kdepim/work/kdepim-3.5.7/kmail/interfaces'
make[5]: Nothing to be done for `all'.
make[5]: Leaving directory
--- Comment #2 from malitzke at metronets dot com 2007-06-04 20:42 ---
Confirmation on different architecture (powerpc-linux-gnu G4) doing an *.nm
comparison as follows: on c-common.o
16c16
00017d5c t add_tlist
---
00017d60 t add_tlist
60c60
00018ca0 T c_add_case_label
---
00018ca4
--- Comment #3 from malitzke at metronets dot com 2007-06-04 20:56 ---
Took the liberty of adding Prof Sikora and the release manager, Could not add
MR
Zedenek Dvorak (refusla by [EMAIL PROTECTED]
This seems to be a case Maintainers no doing the required bootstraps. I am
amazed that
--- Comment #6 from rep dot dot dot nop at gmail dot com 2007-06-04 20:50
---
Subject: Re: gfortran should be able to output Makefile dependencies with -M*
options
On Mon, Jun 04, 2007 at 05:39:48PM -, fxcoudert at gcc dot gnu dot org
wrote:
--- Comment #5 from fxcoudert at
--- Comment #50 from manu at gcc dot gnu dot org 2007-06-04 21:12 ---
Subject: Bug 25241
Author: manu
Date: Mon Jun 4 21:11:51 2007
New Revision: 125317
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125317
Log:
2007-06-04 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR
--- Comment #18 from hjl at lucon dot org 2007-06-04 21:14 ---
(In reply to comment #12)
Maybe someone should timings without the second reassoc.
Jeff mentioned the loop optimizers cause new reassociations:
http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00469.html
And Daniel Berlin
--- Comment #19 from hjl at lucon dot org 2007-06-04 21:39 ---
Can anyone show that the newly added dce_loop anything useful? Can we disable
it or move it after the second reassoc?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32183
--- Comment #4 from malitzke at metronets dot com 2007-06-04 21:56 ---
Here is the build machinery used on the powerpc: There were two changes made to
prior runs that caused no boot failures:
BUILD was incresed from 11 to 12
form enable-languages c++, fortran were removed as being
--- Comment #20 from rakdver at kam dot mff dot cuni dot cz 2007-06-04
22:15 ---
Subject: Re: [4.3 Regression] reassoc2 can more extra calculations into a loop
Can anyone show that the newly added dce_loop anything useful?
Yes, predictive commoning does not work as well if there is
--- Comment #21 from hjl at lucon dot org 2007-06-04 22:19 ---
(In reply to comment #20)
Subject: Re: [4.3 Regression] reassoc2 can more extra calculations into a
loop
Can anyone show that the newly added dce_loop anything useful?
Yes, predictive commoning does not work as
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-04 22:01 ---
So you found a bug that was only exposed with --disable-checking which
usually means two thing, a gcc_assert really has side effects or something is
being micompiled now. Also by the way since the trunk works
--- Comment #22 from rakdver at kam dot mff dot cuni dot cz 2007-06-04
22:39 ---
Subject: Re: [4.3 Regression] reassoc2 can more extra calculations into a loop
Can anyone show that the newly added dce_loop anything useful?
Yes, predictive commoning does not work as well if
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #23 from dberlin at gcc dot gnu dot org 2007-06-04 23:01
---
Subject: Re: [4.3 Regression] reassoc2 can more extra calculations into a loop
On 4 Jun 2007 22:15:46 -, rakdver at kam dot mff dot cuni dot cz
[EMAIL PROTECTED] wrote:
--- Comment #20 from rakdver at
--- Comment #24 from rakdver at kam dot mff dot cuni dot cz 2007-06-04
23:23 ---
Subject: Re: [4.3 Regression] reassoc2 can more extra calculations into a loop
Can anyone show that the newly added dce_loop anything useful?
Yes, predictive commoning does not work as well if
I want to build a gcc 4.3.0 fresh from svn for the fr30-elf target.
Binutils 2.17 are already installed in /usr/local/fr30-elf-new/.
In the gcc source directory I do:
# ./configure --target=fr30-elf --prefix=/usr/local/fr30-elf-new/
[...]
# make
[...]
The build fails with the
--- Comment #26 from rakdver at gcc dot gnu dot org 2007-06-04 23:35
---
Created an attachment (id=13656)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13656action=view)
patch preventing reassociation across loop boundaries
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32183
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-04 23:37 ---
Building in the source directory is one of the least tested features of GCC,
you should try building in a different directory as recommended by
http://gcc.gnu.org/install .
--
pinskia at gcc dot gnu dot org
--- Comment #25 from rakdver at gcc dot gnu dot org 2007-06-04 23:34
---
Reassoc should be fixed, we should not consider workarounds like this.
Either fix or remove reassoc2 works for me :)
One possible fix is attached; it prevents us from reassociating across loop
boundaries.
The web page:
http://gcc.gnu.org/onlinedocs/libiberty/
Indicates that libiberty is LGPL. The directory for libiberty also contain
only a COPYING.LIB, again indicating it should be LGPL to me.
However, at least make-relative-prefix.c indicates that it is part of
libiberty, but is GPL, not LGPL.
--- Comment #2 from tk at maintech dot de 2007-06-05 00:06 ---
Ok, if I build outside the source tree, the problem doesn't appear.
I'm not sure if this is still a bug or not, so I'm leaving the ticket open.
Thanks for the hint!
--
tk at maintech dot de changed:
What
--- Comment #1 from joseph at codesourcery dot com 2007-06-05 00:07 ---
Subject: Re: New: License for libiberty
See http://gcc.gnu.org/ml/gcc/2003-06/msg01286.html; I don't recall
seeing the SC's/FSF's answer to this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32213
--- Comment #27 from dberlin at gcc dot gnu dot org 2007-06-05 00:12
---
Subject: Re: [4.3 Regression] reassoc2 can more extra calculations into a loop
On 4 Jun 2007 23:35:19 -, rakdver at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #26 from rakdver at gcc dot
--- Comment #28 from hjl at lucon dot org 2007-06-05 00:15 ---
(In reply to comment #25)
So probably this restriction should be applied only in reassoc2 (or reassoc2
should be removed, if Daniel believes it is not useful).
My SPEC CPU 2000 resutls in comment #18 shows reassoc2
description test
--
Summary: summary test
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy:
--- Comment #6 from malitzke at metronets dot com 2007-06-05 01:29 ---
Fantastic; My stupidity in copying the disable-checking from one of the dozen
top distributors (which make experimental gcc-4.x.y available, patched them
with gcc-3.x.y stuff and referred users to contact gcc
--- Comment #1 from fang at csl dot cornell dot edu 2007-06-05 01:57
---
g++: Internal error: Killed (program cc1plus)
... suggests that some external force terminated g++. Did you perhaps run out
of memory? (If so, try 'ulimit')
--
fang at csl dot cornell dot edu changed:
--- Comment #7 from andreast at gcc dot gnu dot org 2007-06-05 04:48
---
still broken for disable-checking
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
74 matches
Mail list logo
