--- Comment #4 from irar at il dot ibm dot com 2007-10-24 07:48 ---
In this testcase we perform vectorization of strided accesses in a loop with
multiple types. In vectorizable_store() we gather all the scalar operands of
the stores in the strided accesses group and later call
It would be really convenient if the C preprocessor exposed the number of
variable arguments supplied to a variadic macro as an integer. I tried to come
up with ways of working around this missing feature, but I can't figure out how
to do it without evaluating the macro arguments twice or causing
The following stripped down code shows pure virtual method definitions for both
a normal base class and a templated base class. To my surprise, the templated
class' body is not generated, leading to a pure virtual method called
termination in my actual threaded code. Leaving out the = 0 in the
--- Comment #9 from irar at gcc dot gnu dot org 2007-10-24 09:35 ---
Subject: Bug 33804
Author: irar
Date: Wed Oct 24 09:35:00 2007
New Revision: 129599
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129599
Log:
PR tree-optimization/33804
* tree-vect-transform.c
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-10-24 09:40
---
No plan to work on this one, see
http://gcc.gnu.org/ml/fortran/2007-10/msg00263.html.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-10-24 09:42
---
(In reply to comment #6)
FX, you confirmed this enhancement: is do-as-the-others-do really good enough
a
reason to implement this?
No (see http://gcc.gnu.org/ml/fortran/2007-10/msg00263.html). The SIGNAL
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-10-24 09:44
---
We should document the current situation and close this
(http://gcc.gnu.org/ml/fortran/2007-10/msg00263.html).
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
--- Comment #12 from pault at gcc dot gnu dot org 2007-10-24 10:00 ---
I have prototype fix for this which works OK and does not break anything. It
copies 'p' to a temporary before the FORALL and uses the temporary for the
references. This method will also cure the problem with
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-10-24 10:00
---
(In reply to comment #0)
+{.ftn, @f77, 0, 0, 0},
+{.FTN, @f77, 0, 0, 0},
Question is: do both case variants actually exist, and does the uppercase one
requires preprocessing?
--
fxcoudert at gcc dot gnu
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-10-24 10:09
---
Hi Peter,
The following:
f951 strauss.f90 -fPIC -quiet -dumpbase strauss.f90 -mmacosx-version-min=10.4
-mtune=generic -auxbase strauss -version -ffixed-form -ffixed-line-length-132
-fbounds-check
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-10-24 10:13
---
One working patch/workaround:
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01377.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33870
--- Comment #13 from wvangulik at xs4all dot nl 2007-10-24 11:16 ---
(In reply to comment #10)
Something like this is smaller, faster and works for all registers (no need for
LD_regs). And could easily be writtin in to a insn:
; rOut: output register
; rIn: input register
; rIn, Z, N
--- Comment #5 from dominiq at lps dot ens dot fr 2007-10-24 11:36 ---
With the patch in comment #4, the code in #2 yields the same results as other
compilers without regression.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33759
While trying to update to revision 129600, I got the following error:
gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I.
-Ibuild
--- Comment #13 from rguenth at gcc dot gnu dot org 2007-10-24 11:56
---
And another one:
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01398.html
unassigning - I neither feel responsible nor competent enough to fix this
design
issue.
--
rguenth at gcc dot gnu dot org changed:
--- Comment #15 from rguenth at gcc dot gnu dot org 2007-10-24 12:01
---
Btw, I can no longer reproduce the problem. var-tracking is not fast, but
even a cc1 compiled with checking and -O0 does not take multiple hours to
compile this (but just a minute):
variable tracking :
--- Comment #16 from zadeck at naturalbridge dot com 2007-10-24 12:14
---
Subject: Re: inf loop/long compile time, time spent in var-tracking.c
rguenth at gcc dot gnu dot org wrote:
--- Comment #15 from rguenth at gcc dot gnu dot org 2007-10-24 12:01
---
Btw, I can no
This is with both 4.2 and 4.3 on x86_64/Linux.
gfortran-4.3 -fopenmp a.f90
a.f90: In function 'MAIN__':
a.f90:3: internal compiler error: in extract_omp_for_data, at omp-low.c:162
Test case (by Xavier Andrade):
--
program testbug
integer :: ii
!$omp parallel do
do
--- Comment #1 from andreasmeier80 at gmx dot de 2007-10-24 12:28 ---
The last commit of Olga was not complete. The two new files weren't commited
--
andreasmeier80 at gmx dot de changed:
What|Removed |Added
--- Comment #4 from matz at gcc dot gnu dot org 2007-10-24 12:54 ---
Subject: Bug 33868
Author: matz
Date: Wed Oct 24 12:54:24 2007
New Revision: 129602
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129602
Log:
PR debug/33868
* var-tracking.c (variable_union):
--- Comment #2 from dominiq at lps dot ens dot fr 2007-10-24 13:20 ---
I am now at stage2 with revision 129601. So this PR seems fixed.
Thanks
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33879
--- Comment #3 from ubizjak at gmail dot com 2007-10-24 13:46 ---
Closed as fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
With this program I get a runtime error message
Fortran runtime error: Attempt to allocate a negative amount of memory.
The error occurs at line 33. I suspect the allocation is the constant array
actual argument (/name/).
This program is a little longer than I like my bug reports to be, but any
--- Comment #32 from rguenth at gcc dot gnu dot org 2007-10-24 15:02
---
I have a patch to fix the heuristics, but it doesn't have effect as nobody
hoists PHI nodes that have become invariant apperantly. After PRE I see
bb 100:
# HEAP.202_828 = PHI HEAP.202_747(150),
--- Comment #2 from burnus at gcc dot gnu dot org 2007-10-24 15:33 ---
Fortran runtime error: Attempt to allocate a negative amount of memory.
This error usually means that you allocate that much memory that an integer(4)
variable overflows. I cannot reproduce the error here with -m32
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-10-24 15:37 ---
*** This bug has been marked as a duplicate of 33680 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #3 from william dot mitchell at nist dot gov 2007-10-24 15:48
---
(In reply to comment #2)
Sorry I forgot to give the computer information. This is a 32 bit CentOS 5
Linux distribution on an Intel Core 2 Duo T7700
[EMAIL PROTECTED] gfortran -v
Using built-in specs.
--- Comment #5 from janis at gcc dot gnu dot org 2007-10-24 17:23 ---
Rob, thanks for investigating this and finding new values. No one seems to
have paid any attention here, so please send this as a patch to
[EMAIL PROTECTED] (let me know privately if you have questions about
that)
--- Comment #15 from rsandifo at gcc dot gnu dot org 2007-10-24 17:52
---
Subject: Bug 33755
Author: rsandifo
Date: Wed Oct 24 17:52:16 2007
New Revision: 129606
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129606
Log:
gcc/
PR target/33755
* config/mips/mips.c
--- Comment #16 from rsandifo at gcc dot gnu dot org 2007-10-24 17:54
---
Subject: Bug 33755
Author: rsandifo
Date: Wed Oct 24 17:54:40 2007
New Revision: 129607
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129607
Log:
gcc/
PR target/33755
* config/mips/mips.c
--- Comment #17 from rsandifo at gcc dot gnu dot org 2007-10-24 17:55
---
Patches applied to mainline and 4.2.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ubizjak at gmail dot com 2007-10-24 17:58 ---
I'm reopening this bug, because now we fail on x86_64:
cc1: warnings being treated as errors
../../gcc-svn/trunk/gcc/ipa-struct-reorg.c: In function create_new_field_acc:
../../gcc-svn/trunk/gcc/ipa-struct-reorg.c:960:
--
ubizjak at gmail dot com changed:
What|Removed |Added
CC||ubizjak at gmail dot com
Status|UNCONFIRMED
--
olga at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |olga at gcc dot gnu dot org
|dot org
$ cat data.f
subroutine foo
real a
data a /1.3/
end
$ gfortran -c -Wall -O3 data.f
$ g77 -c -Wall -O3 data.f
data.f: In subroutine `foo':
In file included from data.f:0:
data.f:2: warning: unused variable 'a'
I'd expect a warning, like g77.
--
Summary:
--- Comment #6 from tkoenig at gcc dot gnu dot org 2007-10-24 19:30 ---
I'll do this together with PR 33698.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #35 from jason at gcc dot gnu dot org 2007-10-24 19:48 ---
Created an attachment (id=14407)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14407action=view)
updated patch
Here's a cleaned up version of Liu Guanwei's patch that passes regression
testing with current 4.3
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
class A{
//
};
class B{
public:
explicit B(const A a)
: i_a(a)
{
}
~B()
{
}
private:
const A i_a;
};
A returnA( const char* arg )
{
return A(/*arg*/);
}
foo()
{
const A aRef = returnA(FirstObject); // . (1)
{
const B b(returnA(SecondObject));//
--- Comment #1 from gzljg at hotmail dot com 2007-10-24 20:15 ---
Created an attachment (id=14408)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14408action=view)
a compilable C source
compile and run it to see the actual outcome.
--
--- Comment #5 from olga at gcc dot gnu dot org 2007-10-24 22:06 ---
Two patches were provided by Samuel Tardieu:
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01427.html
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01426.html
Slightly modified:
--
olga at gcc dot gnu dot org changed:
What|Removed |Added
CC||sam at rfc1149 dot net
Status|ASSIGNED
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-10-24 22:57
---
Try reversing the order here:
./configure --enable-languages=fortran --with-gmp=/home/local/gmp-4.2.2
--with-mpfr=/home/local/mpfr-2.3.0
to:
./configure --enable-languages=fortran
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-10-24 23:15
---
Also, you must enable c as well: This is biggest problem
--enable-languages=c,fortran
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33883
--- Comment #35 from pthaugen at gcc dot gnu dot org 2007-10-24 23:15
---
I reran leslie3d on PowerPC with --param max-aliased-vops=1. The result was
a 90% improvement over my prior revision 129550 run (218% improvement over the
original mainline run).
--
While compiling OpenOffice.org with gcc 4.3 at -O2 or higher (-O1 and -O0 are
ok):
/usr/src/ark/BUILD/ooo-build/build/oog680-m7/i18npool/source/nativenumber/nativenumbersupplier.cxx:85:
internal compiler error: canonical types differ for identical types sal_Unicode
[31] and sal_uInt16 [31]
Please
--- Comment #1 from bero at arklinux dot org 2007-10-24 23:25 ---
Created an attachment (id=14409)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14409action=view)
bzip2-ed preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33886
This C++ test case passes a bitfield value to a function which expects a const
reference. When optimizing, the function gets the wrong value: it gets the
value 0x100, which is an acceptable value for a 24-bit bitfield, but is the
wrong value for extending the bitfield out to a 32-bit integer.
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-10-24 23:51 ---
As far as I know this code is invlaid as you should not able take the address
of the bitfield.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33887
The following causes an ICE:
$ cat ftn95bug.f90
program ftn95bug
implicit none
character(8) :: indata(4) = (/
'12344321', '98766789', 'abcdefgh', 'ABCDEFGH'
/)
call process (myfunc (indata)) ! - This causes a gfortran ICE !
contains
elemental function myfunc (s)
--- Comment #37 from danglin at gcc dot gnu dot org 2007-10-25 02:31
---
Test is failing on hppa-unknown-linux-gnu:
Executing on host:
/home/dave/gnu/gcc-4.3/objdir/gcc/testsuite/gfortran/../../gf
ortran -B/home/dave/gnu/gcc-4.3/objdir/gcc/testsuite/gfortran/../../
/home/dave/
--- Comment #38 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-25
02:39 ---
Subject: Re: wrong types in character array/scalar binop
Tree dump attached.
Dave
--- Comment #39 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-25
02:39 ---
Created an attachment
For this simple code
package P is
type T is limited interface;
function F return not null access T'Class;
end P;
package body P is
function X return not null access T'Class;
pragma Import (C, X);
function F return not null access T'Class is
begin
return Result : not null
,treelang --program-suffix=-129614
Thread model: posix
gcc version 4.3.0 20071024 (experimental) (GCC)
I append the preprocessed source code.
--
Summary: internal compiler error: in tsubst_copy
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
--- Comment #1 from schnetter at aei dot mpg dot de 2007-10-25 04:31
---
Created an attachment (id=14411)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14411action=view)
Failing preprocessed source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33890
[forwarded from http://bugs.debian.org/445930]
this is regression against the classpath generices backport for 4.1/4.2 as used
by some distributions, found in 4.3, fixed in the classpath-0.96.1 merge.
import javax.swing.*;
import java.awt.*;
public class Exo1 extends JFrame{
public Exo1 (){
--- Comment #2 from ian at airs dot com 2007-10-25 05:07 ---
Nothing is taking the address of a bitfield. It's a const reference, which
should get initialized with the value. If the reference is not const, then the
compiler gives an error.
In any case, this code fails the same way,
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-10-25 05:21 ---
int f2 = sv.f2;
That should sign extend as far as I know.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33887
59 matches
Mail list logo
