g0 was added in PR 36420 following the Fortran 2008 candidate draft; based on
the public comments, J3 agreed on supporting also g0. besides only g0.
See: http://j3-fortran.org/doc/year/08/08-251r3.txt
and http://www.j3-fortran.org/doc/year/08/08-272.html
Note: The ISO member ballot comments arri
--- Comment #6 from jv244 at cam dot ac dot uk 2008-08-25 06:10 ---
today's trunk gets this right.
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #3 from eric dot weddington at atmel dot com 2008-08-25 05:22
---
These tests have also failed on AVR recently. Known fail on revision 139139.
And no, this is not a duplicate of 37170, as the patch for that bug fixes those
test cases, but does not fix these.
--
eric do
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-08-25 04:32 ---
I have it tested on i386-darwin, spu-elf both without any regressions. The
PowerPC64-linux-gnu run is still working on so far no regressions. I will
submit this tomorrow.
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #1 from hjl dot tools at gmail dot com 2008-08-25 03:47 ---
*** This bug has been marked as a duplicate of 37227 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
--- Comment #1 from hjl dot tools at gmail dot com 2008-08-25 03:47 ---
*** Bug 37226 has been marked as a duplicate of this bug. ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #37 from hp at gcc dot gnu dot org 2008-08-25 02:09 ---
Created an attachment (id=16141)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16141&action=view)
Patch, take 4.
Fourth time's a charm.
The difference is just strengthening the early-return in assemble_external s
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-08-25 02:05 ---
We are gimplifying the copy constructor while gimplifying something else ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37189
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-08-25 02:03 ---
Reduced testcase:
struct optional_base {
optional_base() {}
optional_base ( optional_base const& rhs ) {}
};
struct Point_container { optional_base m_b ; };
int create_internal_node(Point_container& c)
{
Poin
--- Comment #36 from hp at gcc dot gnu dot org 2008-08-25 01:48 ---
Created an attachment (id=16140)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16140&action=view)
Weak testing weak: testing weak stronger.
I was missing tests that referenced a weak address, but offset, and the a
On Linux/ia32, Revision 139545 gave
FAIL: gcc.dg/ipa/ipa-1.c scan-ipa-dump-times cp "versioned function" 2
FAIL: gcc.dg/ipa/ipa-1.c scan-ipa-dump-times cp "replacing param with const" 2
FAIL: gcc.dg/ipa/ipa-2.c scan-ipa-dump-times cp "versioned function" 2
FAIL: gcc.dg/ipa/ipa-2.c scan-ipa-dump-ti
--- Comment #35 from hp at gcc dot gnu dot org 2008-08-25 01:26 ---
Created an attachment (id=16139)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16139&action=view)
Testcase exposing the (on darwin) breaking aspect of prims.ii
See comments in the test-case. The test-case breaks
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37226
Test regressions on AVR target, known for trunk revision 139546:
FAIL: gcc.dg/ipa/ipa-1.c scan-ipa-dump-times cp "versioned function" 2
FAIL: gcc.dg/ipa/ipa-1.c scan-ipa-dump-times cp "replacing param with const" 2
FAIL: gcc.dg/ipa/ipa-2.c scan-ipa-dump-times cp "versioned function" 2
FAIL: gcc.dg
--- Comment #5 from eric dot weddington at atmel dot com 2008-08-25 00:09
---
(In reply to comment #4)
> (In reply to comment #3)
> > Patch in bug #37185, comment #3, does not fix this bug.
>
> Meh. Bad patching job by me. Retesting patch...
>
Confirmed: patch in bug #37185 does not
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-24 23:32 ---
I think this is a dup of bug 16635.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
CC||jason at gcc dot gnu dot org
Status|UNCONFIRMED
The program snippet below shows that GCC/g++ uses an incorrect
instantiation context leading to program miscompilation.
In particular, there is only one instantiation context for g(),
and in that instantiation context, the second f() is inexistant
therefore should not be considered.
#include
na
--- Comment #12 from gnu_andrew at member dot fsf dot org 2008-08-24 23:28
---
Futureproofing:
CVSROOT:/sources/classpath
Module name:classpath
Changes by: Andrew John Hughes 08/08/21 20:46:20
Modified files:
. : ChangeLog
m4 : a
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|ICE when gcc 4.4.0-20080730 |[4.4 Regression] ICE when
|compile lapack
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-24 22:55 ---
Confirmed also on PowerPC 64 GNU/Linux.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-08-24 22:53 ---
Reducing ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37189
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37157
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Summary|vectorizer issue|vectorize
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37153
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-08-24 22:46 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #2 from akyrtzi at gmail dot com 2008-08-24 22:42 ---
I forgot to mention that both MSVC and Comeau compilers interpret
FuncType(a)(x,y)->z = 0;
as expression and compile the test program without errors.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37213
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-24 22:40 ---
Confirmed. One issue is that VRP does not look again at some % statements when
it knows it can be a constant so we produce:
D.1962_10 = 0;
D.1963_11 = (int) D.1962_10;
Here is a more reduced testcase:
func_18 (
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-24 22:28 ---
I think GCC is correct here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37213
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-08-24 22:27 ---
Confirmed, reduced testcase:
int __convert_from_v( ) {
char* __old;
if (__builtin_strcmp(__old, "C")) {}
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-08-24 22:20 ---
Reducing, -Wconversion causes the ICE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37217
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-24 22:12 ---
Confirmed, I don't know if this is a regression or not.
Program received signal SIGSEGV, Segmentation fault.
0x1006f204 in preprocess_file (pfile=0x10a03728) at
/home/apinski/src/local/gcc/gcc/c-ppoutput.c:88
88
--- Comment #2 from tom dot browder at gmail dot com 2008-08-24 22:07
---
Andrew, you're right--it's not prohibited, but my argument is that it should be
prohibited as the default build (but have a specific configure variable to
allow it), at least until it is tested. Over the years I'
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-24 22:04 ---
There are a couple of issues here I think. The first being that the loop:
for (j = 0; j < 4; j++)
arr[j] = mat2[i][j];
is not being unrolled.
If I specify -fpeel-loops, it is unrolled but th
--- Comment #10 from manu at gcc dot gnu dot org 2008-08-24 21:31 ---
I think we should mark as SUSPENDED those enhancement requests where there is
no consensus that we actually want the feature, even if a patch were available.
It would be a waste of time to implement this just to have i
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-24 21:29 ---
Well it is not prohibited, it is supported to do the build in the src
directory, just not recommended as it is not tested really and can (I think
4.3.x has a bug dealing with fixed includes) be broken even for releas
--- Comment #7 from brian at dessent dot net 2008-08-24 21:15 ---
Subject: Re: [cygming] Invalid alignment for SSE store to
.comm data generated with -O3
> Another route would be to set the .bss minimum back to 2**4 again.
Actually that's not really great either because it doesn't d
--- Comment #6 from brian at dessent dot net 2008-08-24 20:59 ---
Subject: Re: [cygming] Invalid alignment for SSE store to
.comm data generated with -O3
It seems to me the issue is that prior to 2007-11-05[1], the PE
assembler could not set section alignment flags correctly so .bss
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-08-24 20:34 ---
I think this was fixed by reverting the patch which turned on IPA-CP by
default. Also I think this was really fixed by
http://gcc.gnu.org/ml/gcc-cvs/2008-08/msg01104.html.
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #7 from burnus at gcc dot gnu dot org 2008-08-24 20:32 ---
Subject: Bug 37201
Author: burnus
Date: Sun Aug 24 20:31:09 2008
New Revision: 139545
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139545
Log:
2008-08-24 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
--- Comment #6 from burnus at gcc dot gnu dot org 2008-08-24 20:31 ---
FIXED on the trunk (4.4).
Thanks for reporting the bug.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from burnus at gcc dot gnu dot org 2008-08-24 20:26 ---
> FYI: I also suggested that they look into gfortran's work on implementing new
> character kinds such as UTF-8.
That part is defined in the Fortran 2003 standard (optional) and the
almost-ISO-approved Fortran 2008 (
--- Comment #5 from ubizjak at gmail dot com 2008-08-24 20:12 ---
Confirmed and added maintainer CC.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #4 from jv244 at cam dot ac dot uk 2008-08-24 20:00 ---
Created an attachment (id=16138)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16138&action=view)
Fortran only testcase
compile as:
gfortran -c -O3 -ffast-math -funroll-loops -ftree-vectorize -march=native
-ffree
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-08-24 19:45
---
gfortran does have -fbackslash that enables c-style interpretation of backslash
characters in strings.
With the Intel approach, the code will not compile without error by a standard
conforming compiler. I would
--- Comment #5 from razya at gcc dot gnu dot org 2008-08-24 19:40 ---
Subject: Bug 37185
Author: razya
Date: Sun Aug 24 19:39:04 2008
New Revision: 139539
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139539
Log:
2008-08-24 Razya Ladelsky <[EMAIL PROTECTED]>
PR tree-
--- Comment #3 from jv244 at cam dot ac dot uk 2008-08-24 19:13 ---
(In reply to comment #2)
> (In reply to comment #1)
> > Created an attachment (id=16137)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16137&action=view) [edit]
> > testcase
> >
> > untar and compile with
> >
>
Intel Fortran has a notation to specify C string literals by appending the
letter C at the end of the string. See here for an example:
http://www.intel.com/software/products/compilers/docs/flin/main_for/mergedProjects/lref_for/source_files/pgcchcs.htm
It would be nice to have this, or something si
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-08-24 18:46 ---
Works for 4.2; original test case:
$ gfortran xpar.f90
$ ./a.out
FFFTTTFTFFTFFTF
FFF
$ gfortran-4.2 xpar.f90
$ ./a.out
FFFT
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-08-24 18:42 ---
(In reply to comment #1)
> Created an attachment (id=16137)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16137&action=view) [edit]
> testcase
>
> untar and compile with
>
> gfortran -c -O3 -ffast-math -funr
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-08-24 18:34 ---
Confirmed.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #4 from eric dot weddington at atmel dot com 2008-08-24 18:31
---
(In reply to comment #3)
> Patch in bug #37185, comment #3, does not fix this bug.
Meh. Bad patching job by me. Retesting patch...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37165
--- Comment #3 from eric dot weddington at atmel dot com 2008-08-24 18:21
---
Patch in bug #37185, comment #3, does not fix this bug. Bug #37185 has to do
with transpose-3.c and is an ICE. This bug has to with a failure of matrix-1.c
and is not an ICE.
--
eric dot weddington at atme
--- Comment #1 from jv244 at cam dot ac dot uk 2008-08-24 18:05 ---
Created an attachment (id=16137)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16137&action=view)
testcase
untar and compile with
gfortran -c -O3 -ffast-math -funroll-loops -ftree-vectorize -march=native
-ffree
This nights trunk fails (gcc of Aug 19th was still fine) with:
gfortran -c -O3 -ffast-math -funroll-loops -ftree-vectorize -march=native
-ffree-form -D__GFORTRAN -D__FFTSG -g -v pw_spline_utils.F
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /data/vondele/gcc_bench/gcc_tr
--- Comment #5 from burnus at gcc dot gnu dot org 2008-08-24 17:18 ---
Subject: Bug 37201
Author: burnus
Date: Sun Aug 24 17:16:46 2008
New Revision: 139537
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139537
Log:
2008-08-24 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
In 4.5.6.2 of the draft F2003 standard ("Type-bound procedure overriding") a
list of conditions is given that an overriding type-bound procedure must
satisfy; the checks that function result characteristics and characteristics of
corresponding dummy arguments are the same are incomplete in the curr
--- Comment #34 from dominiq at lps dot ens dot fr 2008-08-24 16:50 ---
[ibook-dhum] f90/bug% gfc -m64 -S -fno-common
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/weak/weak-2.c
[ibook-dhum] f90/bug% grep ffoo1a weak-2.s
movq[EMAIL PROTECTED](%rip), %rax
--
http://gcc.gnu.org
--- Comment #33 from dominiq at lps dot ens dot fr 2008-08-24 16:46 ---
> All the results for 32-bit mode only, but I am pretty confident that they will
> hold with -m64.
This is wrong: the tests pass in 32-bit mode, but fail with -m64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #4 from dominiq at lps dot ens dot fr 2008-08-24 14:13 ---
After applying the patch in comment #3, the ICE disappeared. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37185
--- Comment #7 from rda at lemma-one dot com 2008-08-24 14:02 ---
The gcc 4.4 semantics as described by Manuel do not conform to the standard in
either case. B2 is the integer -1 which is less than 0, so B2 < 0 should be 1
not 0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30260
I have the following testcase:
#include
#define N 256
#define M 256
double mat1[N][3];
int mat2[M][4];
double point = 0;
int tmp;
double
foo ()
{
int i, j, k, l, ntimes;
int arr[4];
for (ntimes = 0; ntimes < 5000; ntimes++)
{
for (i = 0; i < M; i++)
{
for
--- Comment #1 from mkl at pengutronix dot de 2008-08-24 12:49 ---
Created an attachment (id=16136)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16136&action=view)
minimal test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37220
Hi,
during cross compilation on amd64 host to arm target I get the followng ICE:
arm-v4t-linux-gnueabi-gcc -c -D_GNU_SOURCE -I proc -isystem
/home/mkl/pengutronix/phytec/OSELAS.BSP-phyCORE-trunk/platform-phyCORE-i.MX27-glibc-2.8/sysroot-target/include
-isystem
/home/mkl/pengutronix/phytec/OSELAS.
--- Comment #4 from brian at dessent dot net 2008-08-24 12:47 ---
Subject: Re: [cygwin] Invalid alignment for SSE store to .comm
data generated with -O3
Also, this is not Cygwin-specific as far as I can tell, more like
PE-specific since it affects MinGW as well.
--
http://gcc.gn
--- Comment #3 from razya at il dot ibm dot com 2008-08-24 12:28 ---
(In reply to comment #2)
> *** Bug 37165 has been marked as a duplicate of this bug. ***
Submitted:
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01789.html
I now see no failures in matrix reorg suite.
--
http://gc
--- Comment #3 from brian at dessent dot net 2008-08-24 11:48 ---
Subject: Re: [cygwin] Invalid alignment for SSE store to .comm
data generated with -O3
The the 3 argument version of .comm is only supported by the ELF
assembler so it would be rejected by the PE assembler if gcc were
--- Comment #3 from jh at suse dot cz 2008-08-24 11:37 ---
Subject: Re: [4.4 Regression] Revision 139525 caused many SLP regressions
>
> or should I open another PR?
I've reverted the accidental commit as well as fixed this problem, so I
hope it is all OK.
Honza
--
http://gcc.g
--- Comment #2 from simon dot sasburg at gmail dot com 2008-08-24 11:35
---
with -S added:
.globl _iint
.bss
.align 4
_iint:
.space 4
.comm _iarr, 256 # 256
.section .rdata,"dr"
.align 16
with -S -fno-common added:
.globl _iint
--- Comment #1 from ubizjak at gmail dot com 2008-08-24 11:26 ---
Please look at the asm dump (add -S to compile flags) for following lines:
.globl iint
.bss
.align 4
.type iint, @object
.size iint, 4
iint:
.zero 4
.comm iarr,256,3
--- Comment #4 from burnus at gcc dot gnu dot org 2008-08-24 10:38 ---
One could work around the bug: As such conversions are not valid, one just
needs to reject them with -pedantic (cf. PR 37173) ;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36534
--- Comment #2 from burnus at gcc dot gnu dot org 2008-08-24 10:02 ---
As PR 37201 shows, testing "result = funct()" is not enough, one should also
test "otherfunc(func())" and "print *, func()". (Though the problems will
probably be solved by the fix for PR 37201.)
--
http://gcc.gn
--- Comment #2 from dominiq at lps dot ens dot fr 2008-08-24 09:17 ---
> Well, it seems that revision included enabling ipa-cp by default at -O2 ;)
May this explain the following failures (i686-apple-darwin9):
[ibook-dhum] f90/bug% gfc -O2
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/
--- Comment #3 from etienne_lorrain at yahoo dot fr 2008-08-24 09:13
---
Moreover, if in the first test.c program, you declare variable "conf"
volatile,
the assembly generated contains 8 writes to "conf", and that memory location
is *read* 7 times. If "conf" does not point to memory bu
--- Comment #2 from bonzini at gnu dot org 2008-08-24 08:53 ---
yes, definitely a regression. it would be good to test on a few architectures
though (ppc, spu, x86?).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37219
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37218
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-08-24 08:39 ---
Well, it seems that revision included enabling ipa-cp by default at -O2 ;)
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139525
Log:
* ipa-cp.c (constant_val_insert): Remove.
(ipcp_propagate
77 matches
Mail list logo
