--- Comment #1 from burnus at gcc dot gnu dot org 2007-04-12 09:19 ---
Cf. http://gcc.gnu.org/ml/fortran/2007-04/msg00120.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29785
--- Comment #5 from burnus at gcc dot gnu dot org 2007-04-12 09:46 ---
Subject: Bug 31472
Author: burnus
Date: Thu Apr 12 09:46:30 2007
New Revision: 123735
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123735
Log:
2007-04-12 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
--- Comment #6 from burnus at gcc dot gnu dot org 2007-04-12 09:58 ---
Fixed in 4.3. No regression and rejects only valid Fortran 2003 code -> no
backporting to 4.2 -> Fixed.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-04-12 10:16
---
Subject: Bug 24689
Author: rguenth
Date: Thu Apr 12 10:15:53 2007
New Revision: 123736
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123736
Log:
2007-04-12 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-04-12 10:16
---
Subject: Bug 31307
Author: rguenth
Date: Thu Apr 12 10:15:53 2007
New Revision: 123736
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123736
Log:
2007-04-12 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #2 from trog24 at comcast dot net 2007-04-12 10:18 ---
Subject: Re: PPC object code generation
Hello,
Thank you for your response.
I have monitored the temperature and it is not overheating.
The manner in which the register is corrupted from a non fr
--- Comment #50 from rguenth at gcc dot gnu dot org 2007-04-12 10:20
---
Subject: Bug 31169
Author: rguenth
Date: Thu Apr 12 10:20:42 2007
New Revision: 123737
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123737
Log:
2007-04-12 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-04-12 10:27
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-04-12 10:28
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #1 from m dot reszat at kostal dot com 2007-04-12 10:34 ---
SDA relative access renders useless for the vector load/store opcodes, as the
displacement is limited to +0..+248. Hence, the compiler should not try anyway.
With this bug persisting, one has to limit SDA access to
This happens on other gcc versions too. It seems the checks on whether the
necessary return statement is used fail when using an if statement.
I included a little code snippet here. It compiles without warnings or errors
(all optimizations and even with -Wall no warnings are given). When executed i
--- Comment #2 from burnus at gcc dot gnu dot org 2007-04-12 10:52 ---
> > Is this example (PR 20541) really valid?
> Lahey does not complain.
At compile time? Or at run time?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31320
--- Comment #1 from walter at schreppers dot com 2007-04-12 10:55 ---
Created an attachment (id=13355)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13355&action=view)
Compile with any optimization (i used -O2)
A similar type of bug occured to me a lot in the past. When using if'
--- Comment #13 from dgregor at gcc dot gnu dot org 2007-04-12 12:48
---
Subject: Bug 31078
Author: dgregor
Date: Thu Apr 12 12:47:56 2007
New Revision: 123740
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123740
Log:
2007-04-12 Douglas Gregor <[EMAIL PROTECTED]>
PR
--- Comment #4 from dgregor at gcc dot gnu dot org 2007-04-12 12:48 ---
Subject: Bug 31103
Author: dgregor
Date: Thu Apr 12 12:47:56 2007
New Revision: 123740
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123740
Log:
2007-04-12 Douglas Gregor <[EMAIL PROTECTED]>
PR c
--- Comment #14 from dgregor at gcc dot gnu dot org 2007-04-12 12:50
---
Fixed on mainline
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #5 from dgregor at gcc dot gnu dot org 2007-04-12 12:50 ---
Fixed on mainline
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #13 from dgregor at gcc dot gnu dot org 2007-04-12 12:52
---
Same problem/cause as 31103, which is now fixed on mainline.
*** This bug has been marked as a duplicate of 31103 ***
--
dgregor at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from dgregor at gcc dot gnu dot org 2007-04-12 12:52 ---
*** Bug 31505 has been marked as a duplicate of this bug. ***
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from patchapp at dberlin dot org 2007-04-12 12:55 ---
Subject: Bug number PR middle-end/31322
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00611.html
--
http://gcc.gnu.org
add option to build libgfortran and fortran with -combine.
This creates a smaller binary and may also create a faster binary. The former
is the main motivation from my POV.
--
Summary: add --enable-intermodule
Product: gcc
Version: 4.3.0
Status: UNCO
--- Comment #1 from aldot at gcc dot gnu dot org 2007-04-12 15:03 ---
Created an attachment (id=13356)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13356&action=view)
patch to add --enable-intermodule to libgfortran
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31546
Currently, nowhere is documented that gfortran calls for .F, .FPP, .F90, .F95
and .F2003 the C Preprocessor (in the traditional mode, cf. PR 18428).
I don't know whether it fits better to gfortran.texi or invoke.texi.
In addition, we don't document the option to call the preprocessor for files
w
The following Fortran program
program test
complex :: z
real :: r
r = abs(z)**2
print *, r
end program test
produces the following tree:
D.1352 = __builtin_cabsf (z);
D.1353 = D.1352 * D.1352;
r = D.1353;
The complex value is naively calculated as:
sqrt( (_Real_ z)*(_Real_ z) +
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-04-12 15:41 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #2 from ubizjak at gmail dot com 2007-04-12 15:53 ---
(In reply to comment #0)
> The complex value is naively calculated as:
> sqrt( (_Real_ z)*(_Real_ z) + (_Imag_ z)*(_Imag_ z) )
>
> However, since the value is squared afterwards, the square root can be simply
> removed
In invoke.texi, the description for -frtl-abstract-sequences is located between
-frounding-math and -fsignaling-nans. It means that the description is located
in a @table specially dedicated to GCC floating-point compliance, while the
option is not related to floating-point arithmetic at all. It sh
--- Comment #1 from j at uriah dot heep dot sax dot de 2007-04-12 16:32
---
I disagree the "invalid syntax". According to the formal attribute syntax
description:
``Any list of specifiers and qualifiers at the start of a declaration may
contain attribute specifiers, whether or not suc
gfortran-20070412 segfaults on the code below, gfortran-20070316 doesn't.
$> cat segfault.f90
MODULE class_dummy_atom_types
TYPE :: dummy_atom_list
TYPE(dummy_atom), DIMENSION(:), POINTER :: table
INTEGER :: nused
END TYPE
TYPE :: dummy_ato
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-04-12 17:08 ---
Please note, that the USE-ONLY of "dummy_atom_list_merge" is crucial. Without
it, the segfault does not occur.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31550
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org
|dot org
internal compiler error: in fold_convert, at fold-const.c:2330
$> gfortran-svn -v
gcc version 4.3.0 20070412 (experimental)
Backtrace:
#0 fancy_abort (file=0x86fb400 "../../../svn/gcc/gcc/fold-const.c", line=2330,
function=0x86fb326 "fold_convert")
at ../../../svn/g
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-04-12 17:46 ---
Adding FX to CC as requested on the mailing list.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2007-04-12
17:58 ---
Does that mean that the patch for mainline wouldn't work on gcc 4.2 branch or
that the patch just hasn't been applied to gcc 4.2 branch yet?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30700
If gcc runs out of volatile VMX registers, he is going to save the non volatile
registers. This fails if one of them is defined in -fcall-used-vXX (test case
attaced)
--
Summary: -fcall-used-vXX turns into ICE
Product: gcc
Version: 4.1.2
Status: UNCON
--- Comment #1 from gcc at breakpoint dot cc 2007-04-12 18:02 ---
Created an attachment (id=13357)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13357&action=view)
test case for the "internal compiler error: in propagate_one_insn, at
flow.c:1699"
Reults ins:
powerpc64-unknown-linu
--- Comment #2 from gcc at breakpoint dot cc 2007-04-12 18:04 ---
Created an attachment (id=13358)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13358&action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31552
--- Comment #4 from patchapp at dberlin dot org 2007-04-12 18:10 ---
Subject: Bug number PR31471
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00694.html
--
http://gcc.gnu.org/bugzilla/sh
"a" edit descriptor for character output produces repeatable, but incorrect
output in some situations when the width of the field is not explicitly
specified in the edit descriptor, but is inferred from the number of characters
in the write list item.
--
Summary: incorrect processing
--- Comment #2 from patchapp at dberlin dot org 2007-04-12 18:12 ---
Subject: Bug number PR 31250
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00693.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #3 from patchapp at dberlin dot org 2007-04-12 18:13 ---
Subject: Bug number PR31266
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00695.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #2 from tobi at gcc dot gnu dot org 2007-04-12 18:17 ---
This is not fixed with the patch for PR31266. The remaining issue looks
closely related to not using byte-sized strides in array descriptors.
--
tobi at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from brad dot finney at humboldt dot edu 2007-04-12 18:20
---
Created an attachment (id=13359)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13359&action=view)
test program demonstrating bug behavior along with program output
--
http://gcc.gnu.org/bugzilla/show
--- Comment #2 from brad dot finney at humboldt dot edu 2007-04-12 18:22
---
same bug noted on version 4.0.3 (intel linux 64bit) noted.
--
brad dot finney at humboldt dot edu changed:
What|Removed |Added
---
--- Comment #2 from pault at gcc dot gnu dot org 2007-04-12 18:52 ---
(In reply to comment #1)
> Please note, that the USE-ONLY of "dummy_atom_list_merge" is crucial. Without
> it, the segfault does not occur.
>
Confirmed - I have a bad feeling about this one!
Paul
--
pault at gcc
ly added and still a bit buggy gfortran. One should use version 4.1.x,
which is much more stable, or the 4.2.0 or 4.3.0 which contain even fewer
Fortran bugs. Binaries are available from:
http://gcc.gnu.org/wiki/GFortranBinaries
Using
gfortran 4.1.3 20070302 (prerelease)
gfortran 4.2.0
Instantiating stable_partition with an iterator where the difference_type is
something different than ptrdiff_t results in an error like this:
.../bits/stl_algo.h: In function `_ForwardIterator
std::stable_partition(_ForwardIterator, _ForwardIterator, _Predicate) [with
_ForwardIterator = my_iterat
Instantiating stable_partition with an iterator where the difference_type is
something different than ptrdiff_t results in an error like this:
.../bits/stl_algo.h: In function `_ForwardIterator
std::stable_partition(_ForwardIterator, _ForwardIterator, _Predicate) [with
_ForwardIterator = my_iterat
--- Comment #1 from djg at cray dot com 2007-04-12 19:09 ---
*** This bug has been marked as a duplicate of 31554 ***
--
djg at cray dot com changed:
What|Removed |Added
--- Comment #1 from djg at cray dot com 2007-04-12 19:09 ---
*** Bug 31555 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31554
--- Comment #4 from tobi at gcc dot gnu dot org 2007-04-12 19:10 ---
Subject: Bug 31266
Author: tobi
Date: Thu Apr 12 19:10:10 2007
New Revision: 123759
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123759
Log:
PR fortran/31266
fortran/
* primary.c (gfc_variable_attr): Don't co
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-04-12 19:23 ---
Subject: Bug 31234
Author: dfranke
Date: Thu Apr 12 19:23:03 2007
New Revision: 123760
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123760
Log:
2007-04-12 Daniel Franke <[EMAIL PROTECTED]>
PR fo
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-04-12 19:27 ---
Subject: Bug 31234
Author: dfranke
Date: Thu Apr 12 19:27:07 2007
New Revision: 123761
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123761
Log:
2007-04-12 Daniel Franke <[EMAIL PROTECTED]>
PR fo
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-04-12 19:28 ---
Documented in trunk and 4.2 branch. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
Section 25, lib.algorithms, paragraph 7, defines the Predicate parameter in
std::find_if and others as returning a value that need only be usable in the
controlling-expression of an if statement. libstdc++'s find_if incorrectly
relies on the operator! function, which may not be usable.
In a case w
--- Comment #3 from pault at gcc dot gnu dot org 2007-04-12 19:37 ---
What is really odd is that the same code (see below) is produced, with or
without the ONLY... It looks fine in either case and identical to that produced
by 4.2. *sigh*
Is this a problem with the backend?
Paul
dummy
--- Comment #1 from chris at bubblescope dot net 2007-04-12 19:37 ---
There is also a large number of other places which do "!pred" in various
functions
I believe there are other bugs of this type, relating to && and ||. If someone
really cared about this, they could do a complete sweep
--- Comment #3 from tobi at gcc dot gnu dot org 2007-04-12 19:48 ---
Subject: Bug 31250
Author: tobi
Date: Thu Apr 12 19:48:06 2007
New Revision: 123763
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123763
Log:
PR fortran/31250
fortran/
* decl.c (match_char_spec): Move check fo
--- Comment #2 from pcarlini at suse dot de 2007-04-12 19:59 ---
Confirmed. I will look into this as soon as possible, first blush, I'm
wondering whether just calling __stable_partition_adaptive with a last
argument:
..., _DistanceType(__buf.size()))
would be enough to fix the proble
--- Comment #13 from michael dot meissner at amd dot com 2007-04-12 20:18
---
How hard would it be to back port the change to 4.1.3 and 4.2?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31307
--- Comment #2 from pcarlini at suse dot de 2007-04-12 20:26 ---
Thanks Chris. Apparently, we don't have *that* many ! on the return of the
predicates or other logicals, maybe ~10. The task of fixing all of them seems
manageable rather easily. Let's make sure I understand: it would be ju
uch more stable, or the 4.2.0 or 4.3.0 which contain even fewer
> Fortran bugs. Binaries are available from:
> http://gcc.gnu.org/wiki/GFortranBinaries
>
> Using
> gfortran 4.1.3 20070302 (prerelease)
> gfortran 4.2.0 20070412 (prerelease)
> gfortran 4.3.0 20070412 (experimental
--- Comment #3 from pcarlini at suse dot de 2007-04-12 20:34 ---
Forgot ;)
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #4 from chris at bubblescope dot net 2007-04-12 20:36 ---
Thats my understanding yes.
It might possibly at the same time be worth fixing predicates appears in && and
||, which have to be changed into nested ifs I think.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=315
--- Comment #5 from pcarlini at suse dot de 2007-04-12 20:39 ---
(In reply to comment #4)
> Thats my understanding yes.
Ok, thanks.
> It might possibly at the same time be worth fixing predicates appears in &&
> and
> ||, which have to be changed into nested ifs I think.
Luckily, ver
--- Comment #3 from djg at cray dot com 2007-04-12 21:53 ---
(In reply to comment #2)
At a glance, that looks right to me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31554
--
pcarlini at suse dot de changed:
What|Removed |Added
CC|pcarlini at suse dot de |
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
--
pcarlini at suse dot de changed:
What|Removed |Added
CC|pcarlini at suse dot de |
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
Testcase:
unsigned int f(void)
{
return 0x8001UL;
}
This should be able to done in three instructions:
.f:
li 3,1
oris 3,3,0x8000
blr
Right now it is done as:
.L.f:
li 3,0
ori 3,3,32768
sldi 3,3,16
ori 3,3,1
blr
Which is (0x800
--- Comment #14 from pinskia at gcc dot gnu dot org 2007-04-12 22:32
---
(In reply to comment #13)
> How hard would it be to back port the change to 4.1.3 and 4.2?
Why do you want to that, this is not a regression at all. I am tried of people
asking questions like this for missed optim
--- Comment #15 from rguenth at gcc dot gnu dot org 2007-04-12 22:36
---
4.2.0 wouldn't be too difficult (a svn merge of the change to 4.2.0 branch
succeeds without problems), but 4.1.3 has ineffective store copyprop (see
PR26135). Of course this is not a regression, so a backport is n
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-04-12 22:41 ---
The latter.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30700
--- Comment #14 from pedro dot lamarao at mndfck dot org 2007-04-12 23:12
---
This bug is not reproducible with current mainline.
I suspect it was closed years ago and should be closed by now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2204
C++ testcase (compile with -maltivec):
struct SubData
{
inline const Float Clamp(Float f, Float f0, Float f1)
}
inline const void SinCos(Float angle, Float& sine, Float& cosine)
{
C0 = __builtin_vec_splat(_simdCosEstCoefficients, 0);
C1 = __builtin_vec_splat(_simdCos
I'm not going to get into registering to submit a bug in the formal way,
I am trying urgently to get some quick and dirty results.
But the gfortran compiler told me to report a bug, so I am doing so
Command line
[EMAIL PROTECTED] QDPfig]# gfortran -o contour_fun
contour_fun.f90
Error message
--- Comment #17 from paolo at gcc dot gnu dot org 2007-04-13 00:06 ---
Subject: Bug 28277
Author: paolo
Date: Fri Apr 13 00:06:37 2007
New Revision: 123770
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123770
Log:
2007-04-12 Paolo Carlini <[EMAIL PROTECTED]>
PR libst
--- Comment #7 from pedro dot lamarao at mndfck dot org 2007-04-13 01:44
---
Created an attachment (id=13360)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13360&action=view)
First attempt at fixing the bug.
This patch gives a diagnostic compiling the test case.
I just copied som
subroutine a(fun)
implicit none
integer, intent(in) :: fun
real, external :: funget
real v
v = funget(fun)
funget = -99.9
end subroutine a
laptop:kargl[221] gfc4x -c -O g.f90
g.f90: In function 'a':
g.f90:6: internal compiler error: in gfc_conv_variable, at
fortran/trans-expr.c:444
--- Comment #8 from fang at csl dot cornell dot edu 2007-04-13 02:40
---
Note: PR 30734 is a dupe of this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2708
--- Comment #17 from mrs at apple dot com 2007-04-13 03:09 ---
The followup problem has now been fixed in 4.2.
--
mrs at apple dot com changed:
What|Removed |Added
--- Comment #4 from pault at gcc dot gnu dot org 2007-04-13 05:11 ---
(In reply to comment #3)
> Is this a problem with the backend?
Dream on, Mr Thomas! It's my own patch:
2007-03-18 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/30531
PR fortran/31086
* symbo.
--- Comment #2 from pault at gcc dot gnu dot org 2007-04-13 05:13 ---
(In reply to comment #1)
> Adding FX to CC as requested on the mailing list.
>
Daniel,
Does this also disappear, like 31550, with versions earlier than 20070318?
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #44 from hjl at lucon dot org 2007-04-13 05:28 ---
sixtrack in SPEC CPU 2K started to fail on Mar. 19:
http://people.redhat.com/dnovillo/spec2000.em64t/gcc/log/20070319/CFP2000.002.html
and it still fails today. Is it caused by this bug fix?
--
hjl at lucon dot org chan
--- Comment #45 from pinskia at gcc dot gnu dot org 2007-04-13 05:32
---
(In reply to comment #44)
> sixtrack in SPEC CPU 2K started to fail on Mar. 19:
And then start passing and then again started to fail again on/around April
1st. HJL when will you please get your dates correct.
-
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-04-13 07:52
---
I thought I would get around to this some day. Its noy high priority. More of
an oddity.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
-
85 matches
Mail list logo
