[Bug fortran/16580] gfortran ICE on test g77.f-torture/execute/intrinsic77.f
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-02 07:10 --- Patch submitted here: http://gcc.gnu.org/ml/fortran/2006-10/msg00022.html -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org URL||http://gcc.gnu.org/ml/fortra ||n/2006-10/msg00022.html Status|NEW |ASSIGNED GCC host triplet|i686-pc-cygwin | Keywords||patch Known to fail||4.2.0 4.1.2 Last reconfirmed|2006-07-09 10:14:53 |2006-10-02 07:10:19 date|| Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16580
[Bug fortran/29288] All intrinsics are allowed as actual arguments
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-10-02 07:11 --- Patch submitted here: http://gcc.gnu.org/ml/fortran/2006-10/msg00022.html -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/fortra ||n/2006-10/msg00022.html Keywords||patch Known to fail||4.2.0 4.1.2 Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29288
[Bug fortran/20541] TR 15581: ALLOCATABLE components
--- Comment #31 from sfilippone at uniroma2 dot it 2006-10-02 07:21 --- For the record: my test application runs to completion with good results snapshot 20060930 + alloc_comps0929.diff. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541
[Bug c++/29226] [4.0/4.1/4.2 regression] ICE in make_decl_rtl, at varasm.c:886
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-10-02 07:31 --- Hmm, the sizeof expression causes use to create the expression: (cast)NON_LVALUE_EXPR> -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29226
[Bug fortran/29210] Name parameter in complex constant not allowed in F95
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-10-02 07:34 --- I'll do it. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Known to fail||4.2.0 4.1.2 Last reconfirmed|-00-00 00:00:00 |2006-10-02 07:34:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29210
[Bug fortran/27900] ICE using intrinsics as arguments
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-10-02 07:39
---
Further reduced testcase (no need for a module):
implicit none
integer i
i = len("123")
call sub(len)
end
When the len in "call sub(len)" is resolved, it is never given its correct
return type, which leads to the ICE. I still don't understand why the implicit
none is doing this on us... Paul, any idea?
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
GCC build triplet|i686-pc-linux-gnu |
GCC host triplet|i686-pc-linux-gnu |
GCC target triplet|i686-pc-linux-gnu |
Keywords||ice-on-valid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27900
[Bug fortran/29315] error passing an array derived from type element
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-10-02 08:09 --- (In reply to comment #2) > Confirmed, we don't set the stride correctly as far as I can tell. This comes about because of the admitted kludge in the mechanism for passing components of derived type arrays. At line 1588 in trans-exp.c, you will find the comment: /* Returns a reference to a temporary array into which a component of an actual argument derived type array is copied and then returned after the function call. TODO Get rid of this kludge, when array descriptors are capable of handling aliased arrays. */ Maybe the time has come for byte size strides, although it will be a horrific job to implement. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29315
[Bug fortran/29210] Name parameter in complex constant not allowed in F95
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-10-02 08:11
---
Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c (revision 116798)
+++ gcc/fortran/primary.c (working copy)
@@ -1084,6 +1084,10 @@
return MATCH_ERROR;
}
+ if (gfc_notify_std (GFC_STD_F2003, "Fortran 2003: PARAMETER symbol in "
+ "complex constant at %C") == FAILURE)
+return MATCH_ERROR;
+
switch (sym->value->ts.type)
{
case BT_REAL:
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29210
[Bug fortran/29210] Name parameter in complex constant not allowed in F95
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-10-02 09:21 --- Subject: Bug 29210 Author: fxcoudert Date: Mon Oct 2 09:21:45 2006 New Revision: 117368 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117368 Log: PR fortran/29210 * primary.c (match_sym_complex_part): Named constants as real or imaginary part of complex a named constant are only allowed in Fortran 2003. * gfortran.dg/complex_parameter_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/complex_parameter_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/primary.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29210
[Bug fortran/29210] [4.1 only] Name parameter in complex constant not allowed in F95
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.2.0 4.1.2 |4.1.2 Known to work||4.2.0 Summary|Name parameter in complex |[4.1 only] Name parameter in |constant not allowed in F95 |complex constant not allowed ||in F95 Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29210
[Bug libstdc++/29286] [4.0/4.1/4.2 Regression] placement new does not change the dynamic type as it should
--- Comment #16 from mrs at apple dot com 2006-10-02 09:32 ---
The dynamic type of the object at &i is indeed float and has the value 7.0 (iff
align and sizes work out). We permitted this so that can can do:
class C { ... };
char buf[1024];
new (&buf[n]) C
and have the dynamic type of the storage be C. You can know the dynamic type
is C, by doing a virtual dispatch, or by asking for the name of the type with
rtti.
Likewise, you can do:
new (&i) float(7.0)
with the same effects. The dynamic type is float, and the value is 7.0, and
this is in all ways the same as:
*(float*)&i = 7.0
Thinking about this some more, it would appear that it is unsafe to reorder
writes of otherwise non-conflicting types past each other as type based
analysis alone isn't enough to ensure they don't conflict. It might be
reasonable to add the C rules that the dynamic type _must_ match the static
(declared) type, if there is one for types other than pointer or pointer to
member the the language standard and to clarify the dynamic type of an object
when a bitwise copy of the object is made to better match the C rules.
Reads should be fine as they are required to be the same type as the write (or
character). In practice, if the optimizer can't see the placement new, it
can't reorder things so this is safe; if it can see it, then it should do value
based analysis in addition to type analysis and conclude they conflict (or can
conflict) and still avoid doing the wrong thing.
I do agree, that for now, this isn't a bug in the library. It could be made a
bug in the library by requring a placement new operator as the only way in
which storage can be reused as a different dynamic type.
--
mrs at apple dot com changed:
What|Removed |Added
CC||mrs at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug fortran/29317] New: gfortran.dg/exponent_1.f90 failure
gfortran.dg/exponent_1.f90 is failing at all optimization levels on x86_64-linux (see http://gcc.gnu.org/ml/gcc-testresults/2006-10/msg00081.html). Here is the problem: $ cat exponent_1.f90 real, parameter :: one = 1.0 print *, exponent(one) if (exponent(one) /= 1.0) call abort end $ gfortran -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../trunk/configure --prefix=/utmp/coudert/gfortran/irun --enable-languages=c,fortran : (reconfigured) ../trunk/configure --prefix=/utmp/coudert/gfortran/irun --enable-languages=c,fortran --enable-maintainer-mode : (reconfigured) ../trunk/configure --prefix=/utmp/coudert/gfortran/irun --enable-languages=c,fortran --enable-maintainer-mode Thread model: posix gcc version 4.2.0 20061001 (experimental) $ gfortran -static exponent_1.f90 && ./a.out 0 zsh: abort ./a.out -- Summary: gfortran.dg/exponent_1.f90 failure Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org GCC build triplet: x86_64-unkown-linux-gnu GCC host triplet: x86_64-unkown-linux-gnu GCC target triplet: x86_64-unkown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29317
[Bug libfortran/18791] [4.1 only] CABS specifics declared of wrong type
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-10-02 09:37 --- Subject: Bug 18791 Author: fxcoudert Date: Mon Oct 2 09:37:09 2006 New Revision: 117369 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117369 Log: PR fortran/18791 * gfortran.dg/specifics_1.f90: New test. * gfortran.fortran-torture/execute/specifics.f90: Add tests for complex specifics. * m4/specific.m4: Special-case cabs so that its return type is real. Special-case conjg so that their suffices are _4, _8, _10 and _16 instead of _c4, _c8, _c10 and _c16. * intrinsics/f2c_specifics.F90: Special-case conjg functions so that their suffices are _4 and _8 instead of _c4 and _c8. * generated/_conjg_c4.F90: Regenerate. * generated/_conjg_c8.F90: Regenerate. * generated/_conjg_c10.F90: Regenerate. * generated/_conjg_c16.F90: Regenerate. * generated/_abs_c4.F90: Regenerate. * generated/_abs_c8.F90: Regenerate. * generated/_abs_c10.F90: Regenerate. * generated/_abs_c16.F90: Regenerate. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/specifics_1.f90 - copied unchanged from r117317, trunk/gcc/testsuite/gfortran.dg/specifics_1.f90 Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gfortran.fortran-torture/execute/specifics.f90 branches/gcc-4_1-branch/libgfortran/ChangeLog branches/gcc-4_1-branch/libgfortran/generated/_abs_c10.F90 branches/gcc-4_1-branch/libgfortran/generated/_abs_c16.F90 branches/gcc-4_1-branch/libgfortran/generated/_abs_c4.F90 branches/gcc-4_1-branch/libgfortran/generated/_abs_c8.F90 branches/gcc-4_1-branch/libgfortran/generated/_conjg_c10.F90 branches/gcc-4_1-branch/libgfortran/generated/_conjg_c16.F90 branches/gcc-4_1-branch/libgfortran/generated/_conjg_c4.F90 branches/gcc-4_1-branch/libgfortran/generated/_conjg_c8.F90 branches/gcc-4_1-branch/libgfortran/intrinsics/f2c_specifics.F90 branches/gcc-4_1-branch/libgfortran/m4/specific.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18791
[Bug libfortran/18791] CABS specifics declared of wrong type
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-02 09:38 --- Fixed on both 4.2 and 4.1 -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.1.1 | Known to work|4.2.0 |4.2.0 4.1.1 Resolution||FIXED Summary|[4.1 only] CABS specifics |CABS specifics declared of |declared of wrong type |wrong type Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18791
[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran
--- Comment #28 from fxcoudert at gcc dot gnu dot org 2006-10-02 09:41 --- The only g77 intrinsic now missing to gfortran is FSEEK (and this is PR 22359). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2006-07-26 12:07:43 |2006-10-02 09:41:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292
[Bug c++/29298] rejects valid specialization of member template classes
--- Comment #3 from bkoz at gcc dot gnu dot org 2006-10-02 10:05 --- Thanks Andrew. I agree, this is not permitted by the standard as the enclosing class is not specialized. What a bummer. I suppose I can work around this by making a more convoluted inheritance chain. This would have been a more elegant solution though, as the "real" case involves multiple template parameters, and the enclosing class only really needs to dependant types from these. Ugh! Ugh! Ugh! -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29298
[Bug c++/29298] rejects valid specialization of member template classes
--- Comment #4 from bkoz at gcc dot gnu dot org 2006-10-02 10:06 --- s/to/two -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29298
[Bug c++/29318] New: ICE: type_info of pointer to variable array
The following invalid code causes an ICE.
$ cat foo.cpp
#include
int main()
{
int i = 5;
int va[i];
const std::type_info& info(typeid(&va));
return 0;
}
$ g++ foo.cpp
foo.cpp: In function 'int main()':
foo.cpp:7: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
--
Summary: ICE: type_info of pointer to variable array
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: s__nakayama at infoseek dot jp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29318
[Bug fortran/18026] boz initialization of REALs fails
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2006-10-02 11:09 --- If it's a regression wrt g77, then it's not an enhancement, it's a bug. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Severity|enhancement |normal GCC host triplet|i686-pc-linux-gnu | Keywords||rejects-valid Last reconfirmed|2006-03-05 03:41:04 |2006-10-02 11:09:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18026
[Bug fortran/25003] [4.1 only] Non-standard-conforming behaviour on pointer association special case
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-10-02 11:22 --- This is now working on mainline but still failing on 4.1 branch. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu | Keywords||wrong-code Known to fail||4.1.2 Known to work||4.2.0 Last reconfirmed|2006-02-26 18:46:50 |2006-10-02 11:22:59 date|| Summary|Non-standard-conforming |[4.1 only] Non-standard- |behaviour on pointer|conforming behaviour on |association special case. |pointer association special ||case Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25003
[Bug target/29319] New: ICE unrecognizable insn: offset too large for larl (breaks glibc)
This happens on the 4.1 branch, not on 4.2/trunk, but it's also latent there:
% cat large-ofs.c
static char l_info[100];
void bug1 (unsigned long tag)
{
char *info = l_info;
info[tag - 0x1 + 1] = 1;
}
void bug2 (unsigned long tag)
{
char *info = l_info;
info[tag - 0x7 + 2] = 2;
}
extern void abort();
int main()
{
unsigned i;
for (i = 0; i < sizeof(l_info); i++)
l_info[i] = 0;
bug1(0x1);
bug2(0x7);
if (l_info[2] != 2 || l_info[1] != 1)
abort();
return 0;
}
% gcc -O2 -fPIC -march=z9-109 large-ofs.c
large-ofs.c: In function ‘bug2’:
large-ofs.c:13: error: unrecognizable insn:
(insn 9 7 10 1 (set (reg:DI 45)
(const:DI (plus:DI (symbol_ref:DI ("l_info") [flags 0x2] )
(const_int -30064771038 [0xfff90022] -1 (nil)
(nil))
large-ofs.c:13: internal compiler error: in extract_insn, at recog.c:2084
This demonstrates two problems: 1) with such large offset to static (or
hidden) objects gcc is confused (bug2), and 2) when one inspects the asm
output for bug1 (comment out bug2 for that) we see:
bug1:
.LFB2:
larl%r1,l_info+34
lhi %r3,1
stc %r3,1(%r2,%r1)
br %r14
Note how the subtraction of 0x7 is missing. Both are a problem in
legitimize_pic_address. In this case we are asked to legitimize
(const:DI (plus:DI (symbol_ref:DI ("l_info") [flags 0x42]
)
(const_int -15032385264 [0xfffc8110])))
It detects that this is a local symbols plus an int offset, and hence tries
to use larl (this is z/arch after all). But it checks only op0 (the
symbol_ref) for larl_operand(), not the offset. But larl can only
accept numbers which fit in 33 bit, which indeed is also tested
by larl_operand. But it never is called with the whole plus operand.
That is because it would also reject odd integer offsets which this very code
tries to handle.
So we need to handle that on our own. If we do that then we'll see the second
bug, resulting in a segfault when the program is run. It is the use of 'int'
to store an INTVAL when fixing up the case for odd offsets.
Note that this situation arises in glibc, ld.so. The index into an array
is the DT_TAG (an arbitrary large 32bit number) minus the base for the
tag in question (a large constant like 0x700), and because the indexed
array contains pointers the overall offset if larger than 33 bit.
That attached patch fixes this testcase.
--
Summary: ICE unrecognizable insn: offset too large for larl
(breaks glibc)
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at gcc dot gnu dot org
GCC host triplet: s390x-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29319
[Bug fortran/25708] Module loading is not good at all
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-10-02 11:23 --- Confirmed and marked as an enhancement. After all, it's working :) -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-02 11:23:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25708
[Bug target/29319] ICE unrecognizable insn: offset too large for larl (breaks glibc)
--- Comment #1 from matz at gcc dot gnu dot org 2006-10-02 11:24 --- Created an attachment (id=12369) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12369&action=view) proposed patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29319
[Bug fortran/27478] getting ": error: invalid operand to binary operator"
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-10-02 11:35
---
That one is annoying. Reduced testcase is:
FUNCTION X()
ENTRY X1
IF (X .GT. 0) CALL FOO(X)
END
The error message is:
a.f: In function master.0.x:
a.f:3: error: invalid operand to binary operator
__result_master.0.xD.914
a.f:3: internal compiler error: verify_stmts failed
And the original tree dump is:
x ()
{
return master.0.x (0);
x1 ()
{
return master.0.x (1);
master.0.x (__entry)
{
real4 __result_master.0.x;
real4 x.0 [value-expr: __result_master.0.x];
switch (__entry)
{
case 0:;
goto L.2;
case 1:;
goto L.4;
}
L.2:;
L.4:;
if (x.0 > 0.0)
{
foo (&x.0);
}
else
{
(void) 0;
}
return __result_master.0.x;
}
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Last reconfirmed|2006-06-04 15:16:36 |2006-10-02 11:35:36
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27478
[Bug target/29319] ICE unrecognizable insn: offset too large for larl (breaks glibc)
--- Comment #2 from matz at gcc dot gnu dot org 2006-10-02 11:35 ---
Note that with this patch solves the bug for this testcase, but it still
doesn't help with the general case. With this slightly changed testcase:
% cat large-ofs2.c
static char l_info[100];
void bug1 (unsigned long tag)
{
char *info = l_info;
info[tag - 0x1 + 1] = 1;
}
void bug2 (unsigned long tag)
{
char *info = l_info;
info[tag - 0x1 + 1] = 2;
}
extern void abort();
int main()
{
unsigned i;
for (i = 0; i < sizeof(l_info); i++)
l_info[i] = 0;
bug1(0x1);
bug2(0x1);
if (l_info[2] != 2 || l_info[1] != 1)
abort();
return 0;
}
% gcc -S -O2 -fPIC -march=z9-109 large-ofs2.c
% gcc large-ofs2.s
large-ofs2.s: Assembler messages:
large-ofs2.s:19: Error: value of -4294967312 too large for field of 4 bytes at
18
Note how the bodies of both functions is exactly the same, but still it
only fails in the second function. For reference here the asm of both
functions:
6 bug1:
7 .LFB2:
8 larl%r1,l_info-4294967296
9 lhi %r3,1
10 stc %r3,1(%r2,%r1)
11 br %r14
12 .LFE2:
13 .size bug1, .-bug1
14 .align 4
15 .globl bug2
16 .type bug2, @function
17 bug2:
18 .LFB3:
19 larl%r1,l_info-4294967296
20 lhi %r3,2
21 stc %r3,1(%r2,%r1)
22 br %r14
I assume the reason is, that the assembler somehow calculates this pc
relative. In that case it could also break later during linking if the
linker doesn't have special means to fix up too large offsets.
So, I think s390x is in the same situation as x86-64. We can't allow
large constant offsets on objects, even though instructions might accept
them, because the object might become placed just a bit too far away,
so that it's base is still in reach, while the offset added to it is not
anymore. On x86-64 we solve that by artificially constraining the range
of offsets. That should perhaps be done here too. E.g. by using
DISP_IN_RANGE instead of the = test I copied from larl_operand.
Up to the maintainers.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29319
[Bug fortran/27703] Linking example programs for PLplot causes error messages about multiple definition of __gfortran_transfer_character
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-02 11:37 --- Closing this. We'd need a more precise definition to be able to do anything about that, although I don't see a reason why shared libraries wouldn't work on cygwin. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27703
[Bug fortran/28849] Missed array shape violation with RESHAPE despite -fbounds-check
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-02 11:54:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28849
[Bug fortran/29232] No warning/error for duplicate construct name
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2006-10-02 11:57:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29232
[Bug fortran/29240] optional argument for signal intrinsic not supported
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-02 11:59 --- Confirmed, as Intel, Portland and other compilers accept this. Marked as an enhancement, though, as g77 didn't support that anyway. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Severity|minor |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|x86_64-suse-linux | GCC host triplet|x86_64-suse-linux | GCC target triplet|x86_64-suse-linux | Last reconfirmed|-00-00 00:00:00 |2006-10-02 11:59:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29240
[Bug ada/29320] New: Segfault and strange behaviour related to "use" clauses
GCC seems to have more problems with "use" clauses (see also bug #26529). gcc: Internal error: Segmentation fault (program gnat1) The compiler has been compiled from source by: > configure --prefix=/opt/gcc-4.1.1 --enable-languages=ada,c > make bootstrap > make install The problem can be reproduced by compiling the source file below, using the following command line: gcc -c command.ads The solution of the problem in this case is to use the correct range 0..6 for INFO_T.COMMAND_NAME, but gcc should have printed an error message instead of crashing, shouldn't it? The compiler does not crash when size 8 is used for COMMAND_KIND_T, but how are the enum values represented in COMMAND_NAME in this case? command.ads === package COMMAND is type COMMAND_KIND_T is (START, STOP); for COMMAND_KIND_T use (START => 80, STOP => 81); -- for COMMAND_KIND_T'size use 8; -- not crashing for COMMAND_KIND_T'size use 16; -- crashing type SUB_COMMAND_KIND_T is new COMMAND_KIND_T range START..STOP; for SUB_COMMAND_KIND_T'size use 7; type INFO_T (COMMAND_NAME : SUB_COMMAND_KIND_T := START) is record case COMMAND_NAME is when others => null; end case; end record; for INFO_T use record COMMAND_NAME at 0 range 0..4; end record; end COMMAND; === -- Summary: Segfault and strange behaviour related to "use" clauses Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: markus dot heichel at comsoft dot de GCC build triplet: i686-pc-linux GCC host triplet: i686-pc-linux GCC target triplet: i686-pc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29320
[Bug fortran/29321] New: optional arguments+derived types = segmentation fault
Compilation of functions/subroutines with optional derived type arguments gives segmentation fault. a.F90: In function 'func': a.F90:11: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. If I remove one of the optional arguments (C in SUB) in the sample code below it appears to work Environment: System: Linux olavs 2.6.8-2-686 #1 Thu May 19 17:53:30 JST 2005 i686 GNU/Linux Architecture: i686 host: i386-pc-linux-gnu build: i386-pc-linux-gnu target: i386-pc-linux-gnu configured with: ../gcc/configure --prefix=/cosmic/coudert/tmp/gfortran-20060906/irun --enable-languages=c,fortran --host=i386-linux --with-gmp=/cosmic/coudert/tmp/gfortran-20060906/gfortran_libs How-To-Repeat: MODULE MYINT TYPE NUM INTEGER :: R = 0 END TYPE NUM CONTAINS FUNCTION FUNC(A,B) RESULT(E) IMPLICIT NONE TYPE(NUM) A,B,E INTENT(IN) :: A,B OPTIONAL B E%R=A%R CALL SUB(A,E) END FUNCTION FUNC SUBROUTINE SUB(A,E,B,C) IMPLICIT NONE TYPE(NUM) A,E,B,C INTENT(IN) A,B INTENT(OUT) E,C OPTIONAL B,C E%R=A%R END SUBROUTINE SUB END MODULE MYINT -- Summary: optional arguments+derived types = segmentation fault Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: critical Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vahtras at pdc dot kth dot se GCC build triplet: i386-pc-linux-gnu GCC host triplet: i386-pc-linux-gnu GCC target triplet: i386-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29321
[Bug middle-end/27986] [4.0/4.1/4.2 Regression] jump to middle of loop on entry with using old version of an variable
--- Comment #4 from amacleod at redhat dot com 2006-10-02 13:56 ---
This is not something out of ssa can resolve on its own.
given this sequence:
# s_2 = PHI ;
# d_1 = PHI ;
:;
D.1287_8 = MEM[base: d_1];
s_9 = s_2 + D.1287_8; <<<--- s_2 and s_9 have different values
d_10 = d_1 + 4B;
if (s_9 < g_11) goto ; else goto ;
# s_7 = PHI ; <<<--- original value of s_2 used here
:;
*v_3 = s_7;
When s_9 is assigned s_2 + D.1287_8 , they have different values, so when s_2
is used in the PHI assigned to s_7, there is a stretch over which s_9 and s_2
are both live, and contain different values.
out of ssa cannot assign them to the same variable.
you are going to have a copy in the loop no matter what you do...
right now we get:
:
s = *(v + 4B);
:;
s.31 = s + MEM[base: d]{*d};
d = d + 4B;
if (s.31 < g) goto ; else goto ;
:;
s = s.31;
goto ();
:;
*v = s;
return;
the other alternative would be:
:;
s.31 = s
s = s + MEM[base: d]{*d};
d = d + 4B;
if (s < g) goto ; else goto ;
:;
goto ();
:;
*v = s.31;
Is that any better? It looks pretty much the same to me. It might help on a 2
address machine where you need r1 = r1 + exp, but that about it.
so Im not sure I understand what you want out of ssa to do with the code here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27986
[Bug middle-end/27986] [4.0/4.1/4.2 Regression] jump to middle of loop on entry with using old version of an variable
--- Comment #5 from amacleod at redhat dot com 2006-10-02 14:01 --- I guess you can flatten the goto slightly. this is still something that is not really in the scope of out of ssa. part of the root of this problem is that the PHI is really just a copy, but the fact that it remains a PHI prevents anyone from moving it. Its possible that we might be able to do something about it with some of the RABLET work. it doesnt really reduce any register pressure, but we might be able to recoginze that it flatten the cfg a bit... I'm not crazy about putting it there tho. Of course, any optimization could do the same thing. A quick pass to look for these cases and transform those PHIs into copies at the appropriate place would accomplish the same thing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27986
[Bug c++/29266] Rule that binding rvalue to a refernce need a copy ctor don't work
--- Comment #6 from yuanfei8077 at gmail dot com 2006-10-02 14:19 --- Subject: Re: Rule that binding rvalue to a refernce need a copy ctor don't work Thank you Andrew, appreciate your help on this topic. -Kelvin On 1 Oct 2006 20:33:33 -, pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > > > --- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-01 20:33 > --- > (In reply to comment #3) > > Plesae seee Comment #2 From Kelvin 2006-09-28 23:25 [reply]. > > > > In addition 2 questions I raised in the Commet2. I also have one more > > question > > about the rule "bind an rvalue to a reference, > > we need to let copy ctor of the class be accessible.", I found that this > > rule > > only effective when the reference is delcared as "const &", but if we remove > > keyword "const", then "no matching" happen again. > > Because it will not be a copy constructor that can bind a rvalue to a > reference > at that point so this is still not a bug. > > > -- > > pinskia at gcc dot gnu dot org changed: > > What|Removed |Added > > Status|UNCONFIRMED |RESOLVED > Resolution||INVALID > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29266 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29266
[Bug fortran/29317] gfortran.dg/exponent_1.f90 failure
--- Comment #1 from sgk at troutmask dot apl dot washington dot edu 2006-10-02 14:22 --- Subject: Re: New: gfortran.dg/exponent_1.f90 failure On Mon, Oct 02, 2006 at 09:32:55AM -, fxcoudert at gcc dot gnu dot org wrote: > gfortran.dg/exponent_1.f90 is failing at all optimization levels on > x86_64-linux (see > http://gcc.gnu.org/ml/gcc-testresults/2006-10/msg00081.html). > Here is the problem: > > $ cat exponent_1.f90 > real, parameter :: one = 1.0 > print *, exponent(one) > if (exponent(one) /= 1.0) call abort > end What version of mpfr do you have? This test will fail if the version is not 2.2.0 or newer. If you have a good mpfr, then the problem may be similar to the one with nearest_1.f90 where the extra precision in the registers is bad (ie., add -ffloat-store to the test). One other possibility is the problem with subnormal numbers is also affecting this test. I hope to look into the subnormal issue later today. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29317
[Bug fortran/29317] gfortran.dg/exponent_1.f90 failure
--- Comment #2 from Francois-Xavier dot Coudert at ens dot fr 2006-10-02 14:27 --- Subject: Re: gfortran.dg/exponent_1.f90 failure > If you have a good mpfr, then the problem may be similar to the one > with nearest_1.f90 where the extra precision in the registers is bad > (ie., add -ffloat-store to the test). I do have mpfr-2.2.0, and adding -ffloat-store doesn't change the test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29317
[Bug fortran/27701] Two routines with the same name cause an interna; error in gfortran
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-10-02
14:32 ---
(In reply to comment #1)
> The problem occurs on i386-*-freebsd
Noting that adding a dummy to the first of the subroutine declarations allows
the compiler to detect that there are two subroutines of the same name, we are
led by the error mesage to decl.c:636. The condition for detection of a
previously defined procedure is sym->formal [!= NULL]. Thus the case above
escapes. Patching this with:
Index: gcc/fortran/decl.c
===
*** gcc/fortran/decl.c (révision 117367)
--- gcc/fortran/decl.c (copie de travail)
*** get_proc_name (const char *name, gfc_sym
*** 635,641
accessible names. */
if (sym->attr.flavor != 0
&& sym->attr.proc != 0
! && sym->formal)
gfc_error_now ("Procedure '%s' at %C is already defined at %L",
name, &sym->declared_at);
--- 635,642
accessible names. */
if (sym->attr.flavor != 0
&& sym->attr.proc != 0
! && (sym->attr.subroutine || sym->attr.function)
! && sym->attr.if_source != IFSRC_UNKNOWN)
gfc_error_now ("Procedure '%s' at %C is already defined at %L",
name, &sym->declared_at);
seems to do the right thing. The attributes subroutine and function are not of
themselves enough, as I discovered when I had to correct the original patch.
This condition was replaced with that on sym->formal and tested with
internal_references_2.f90. Adding the check that the symbol has an interface
source to the subroutine/function test accomplishes the same thing and scoops
up procedures without dummies.
It regtests OK on Cygwin_NT/PIV.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27701
[Bug fortran/29317] gfortran.dg/exponent_1.f90 failure
--- Comment #3 from sgk at troutmask dot apl dot washington dot edu 2006-10-02 15:00 --- Subject: Re: gfortran.dg/exponent_1.f90 failure On Mon, Oct 02, 2006 at 02:27:47PM -, Francois-Xavier dot Coudert at ens dot fr wrote: > > > --- Comment #2 from Francois-Xavier dot Coudert at ens dot fr 2006-10-02 > 14:27 --- > Subject: Re: gfortran.dg/exponent_1.f90 failure > > > If you have a good mpfr, then the problem may be similar to the one > > with nearest_1.f90 where the extra precision in the registers is bad > > (ie., add -ffloat-store to the test). > > I do have mpfr-2.2.0, and adding -ffloat-store doesn't change the test. > > Can you send me the -fdump-tree-original file? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29317
[Bug fortran/27588] -fbounds-check should catch substring out of range accesses
--- Comment #3 from tobias dot burnus at physik dot fu-berlin dot de 2006-10-02 15:15 --- > From Francois-Xavier Coudert 2006-06-08 I'm writing a patch to add substring bounds checking. I hope to post it in the next few days. What is the status? If you have something, I'd save my time of looking at trans-expr.c's gfc_conv_substring and trying to understand how to add it there. Looking at http://www.polyhedron.com/pb05/linux/diagnose.html, this seems to be the last area where gfortran is worse than all others. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27588
[Bug fortran/29322] New: ICE with character optional arg
$ cat u.f90
if (isscan () /= 0) call abort
contains
integer function isscan (substr)
character(*), optional :: substr
if (.not.present(substr)) isscan = myscan ("foo", "over")
end function isscan
end
$ gfortran u.f90
u.f90: In function MAIN__:
u.f90:5: internal compiler error: Segmentation fault
--
Summary: ICE with character optional arg
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29322
[Bug fortran/28722] Fortran front-end produces mismatch trees
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-10-02 15:24
---
Here's a detailed analysis of the current testsuite failures with Andrew's
patches from PR22368 (all patches applied) on i686-linux.
First testcase (from actual_array_constructor_1.f90):
subroutine bar(a)
character(len=*) :: a
call foo((/ a, 'g' /))
end
The error message issued is
actual_array_constructor_1.f90: In function bar:
actual_array_constructor_1.f90:3: error: statement types mismatch
(*D.941)[S.9D.942]{lb: 0 sz: _a.8D.939} = D.946;
charD.14[1:_aD.902]
charD.14[1:1]
actual_array_constructor_1.f90:3: internal compiler error: verify_stmts failed
Second testcase:
interface
pure function double (string)
character (len = *), intent (in) :: string
character (len = len (string)) :: double
end function double
end interface
print *, f5("foo")
contains
function f5 (string)
character (len = *) :: string
character (len = len (double (string))) :: f5
f5 = ''
end function f5
end
returns (at -O1):
char_result_1.f90: In function MAIN__:
char_result_1.f90:1: error: statement types mismatch
D.949_16 = stringD.939_11;
charD.14[1:3] &
charD.14[1:_stringD.907] &
char_result_1.f90:1: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
Third testcase:
real c
if (loc(c) == 0) call abort
end
produces:
loc_2.f90: In function MAIN__:
loc_2.f90:2: error: types mismatch in comparsion
int4D.2
D.903 == 0;
loc_2.f90:2: internal compiler error: verify_stmts failed
Fourth testcase:
call foo("g")
contains
subroutine foo (s)
character(*), optional :: s
if (present(s)) call abort
end subroutine
end
produces
missing_optional_dummy_1.f90: In function MAIN__:
missing_optional_dummy_1.f90:1: error: types mismatch in comparsion
charD.14[1:_sD.904] *
charD.14[1:1] *
sD.913_1 != 0B;
missing_optional_dummy_1.f90:1: internal compiler error: verify_stmts failed
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-10-02 15:24:35
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28722
[Bug fortran/27588] -fbounds-check should catch substring out of range accesses
--- Comment #4 from Francois-Xavier dot Coudert at ens dot fr 2006-10-02 15:32 --- Subject: Re: -fbounds-check should catch substring out of range accesses > I'm writing a patch to add substring bounds checking. I hope to post it in the > next few days. Great! > What is the status? If you have something, I'd save my time of looking > at trans-expr.c's gfc_conv_substring and trying to understand how to > add it there. The status is: "I had the beginning of a patch, but it didn't work fully, and I think it didn't survive summer cleaning of my account". But, I'll be happy to answer any question you have, and review your patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27588
[Bug tree-optimization/29323] New: set_nothrow_function_flags does invalid analysis on weak functions
If a function definition is present, except.c:set_nothrow_function_flags marks functions as nothrow depending on analysis of the function definition. This is incorrect when the function does not bind locally (compare with other function analysis in PR tree-optimization/27781). -- Summary: set_nothrow_function_flags does invalid analysis on weak functions Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: wrong-code, EH Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29323
[Bug tree-optimization/29323] set_nothrow_function_flags does invalid analysis on weak functions
--- Comment #1 from amylaar at gcc dot gnu dot org 2006-10-02 16:09 --- Created an attachment (id=12370) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12370&action=view) test case - main file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29323
[Bug tree-optimization/29323] set_nothrow_function_flags does invalid analysis on weak functions
--- Comment #2 from amylaar at gcc dot gnu dot org 2006-10-02 16:10 --- Created an attachment (id=12371) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12371&action=view) test case - actual definition of function foo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29323
[Bug target/25376] section attribute doesn't work on darwin
--- Comment #7 from jconner at apple dot com 2006-10-02 16:44 --- (In reply to comment #6) > Shouldn't this bug be marked as closed now? Perhaps - however, it's not been fixed on the 4.0 or 4.1 branches... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25376
[Bug fortran/18026] boz initialization of REALs fails
--- Comment #8 from kargl at gcc dot gnu dot org 2006-10-02 16:47 --- Remove reject-valid keyword, again! Return this to enhancement. This is NOT a bug. g77 compatibility and the Fortran 95 standard have a conflict, and so IMNSHO the Fortran 95 standard wins. See comment #3. The Fortran 95 standard has quite explicit language concerning how a BOZ is handled in a DATA statement, and that is what gfortran implements. A BOZ is handled consistently so that the gfortran extension of allowing a BOZ in an assignment gives the same result as the DATA statement. troutmask:kargl[204] cat a.f90 PROGRAM GFCBUG19 DOUBLE PRECISION y, x DATA x / Z'7FF0' / ! Conforms to Fortran 95 standard y = Z'7FF0' ! gfortran extension print *, x, y END troutmask:kargl[205] gfc -o z a.f90 troutmask:kargl[206] ./z 9.218868437227405E+018 9.218868437227405E+018 If someone wants to create a patch to implement a -fbroken-boz-behavior option, then that's fine. OTOH, the user can use the bit manipulation functions and TRANSFER to create whatever bit pattern the user wants. Or, the user can use the -fno-range-check option and simply compute inf = 1./0. and nan = 0. / .0. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org Severity|normal |enhancement Keywords|rejects-valid | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18026
[Bug c++/29318] [4.0/4.1/4.2 Regression] ICE: type_info of pointer to VLA
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-02 16:47 --- Confirmed. 3.0.4 and above ICE so this is a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-02 16:47:37 date|| Summary|ICE: type_info of pointer to|[4.0/4.1/4.2 Regression] |variable array |ICE: type_info of pointer to ||VLA Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29318
[Bug target/25376] section attribute doesn't work on darwin
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-10-02 16:51 --- (In reply to comment #7) > Perhaps - however, it's not been fixed on the 4.0 or 4.1 branches... But this is not a regression so closing as fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25376
[Bug fortran/29321] optional arguments+derived types = segmentation fault
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29321
[Bug fortran/29321] [4.1/4.2 Regression] optional arguments+derived types = segmentation fault
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-02 17:04 --- Confirmed, a regression. Looks related to PR 29284. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||29284 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i386-pc-linux-gnu | GCC host triplet|i386-pc-linux-gnu | GCC target triplet|i386-pc-linux-gnu | Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2006-10-02 17:04:39 date|| Summary|optional arguments+derived |[4.1/4.2 Regression] |types = segmentation fault |optional arguments+derived ||types = segmentation fault Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29321
[Bug rtl-optimization/29323] set_nothrow_function_flags does invalid analysis on weak functions
--- Comment #3 from amylaar at gcc dot gnu dot org 2006-10-02 17:07 --- While except.c:set_nothrow_function_flags analyzes rtl, the DECL_NOTHROW flag it computes is a tree bit. via calls.c:flags_from_decl_or_type -> calls.c:call_expr_flags -> tree-eh.c:tree_could_throw_p makes this information is made available to the tree optimizers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29323
[Bug tree-optimization/29212] ICE with -fipa-pta
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-10-02 17:28 ---
Confirmed, further reduced testcase:
struct StructB
{
bool val_;
};
struct ClassF
{
virtual void MetG(StructB value) = 0;
};
ClassF* MetJ ();
void MetN (StructB const & x)
{
ClassF *VarI = MetJ();
VarI->MetG ( x);
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-10-02 17:28:08
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29212
[Bug driver/29270] "--" does not end option parsing
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-02 17:46 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-02 17:46:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29270
[Bug c++/29291] [4.2 regression] ICE on invalid use of new
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-02 17:47 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-02 17:47:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29291
[Bug libstdc++/29286] [4.0/4.1/4.2 Regression] placement new does not change the dynamic type as it should
--- Comment #17 from mmitchel at gcc dot gnu dot org 2006-10-02 17:48
---
I disagree with Mike's analysis. I certainly understand the goals of placement
new, but I don't think that anyone intended this code:
int i;
*(float *)&i = 7.0;
to be valid. I don't even think people intended this variant:
int i;
new (&i) float(7.0);
to be valid. Note that a consequence of allowing this is that:
int f() {
int i = 3;
new (&i) float(7.0);
return i;
}
is undefined -- not because of the overwriting of i, but because the return
statement reads memory of the wrong type. Mike's position is that accessing a
variable using its static type is not always safe; I find this bizarre.
My personal opinion is that the authors of the standard just didn't think of
all the possible interactions of the various aspects. I believe placement new
was intended to handle only arrays of characters, consistent with the special
dispensation given to character pointers.
However, I don't think my differences with Mike can be resolved without going
directly to the standards committee. Fortunately, from the compiler point of
view, I'm saying "punt" and Mike is saying "punt harder". So, it's probably
just a question of in how many cases we decide to disable type-based alias
analysis.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug fortran/29322] [4.1/4.2 Regression] ICE with character optional arg
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-02 17:50 --- Confirmed, I think this is a dup of bug 29284, well it is at least related. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||29284 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-02 17:50:29 date|| Summary|ICE with character optional |[4.1/4.2 Regression] ICE |arg |with character optional arg Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29322
[Bug libgcj/29205] lib/pkgconfig/libgcj.pc needs to become version dependent
--- Comment #1 from tromey at gcc dot gnu dot org 2006-10-02 17:51 --- I suspect we should put the version number, or at least major.minor, into the name. So, libgcj-4.1.pc, libgcj-4.2.pc, etc. What do you think of this? -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-02 17:51:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29205
[Bug libgcj/29324] New: add wait handling hook
Currently libgcj assumes it can waitpid(-1,...). This interacts poorly with other libraries which may want to interact with subprocesses; for instance glib has an API for spawning and waiting for children, and frysk has to work around this problem (by disallowing the use of Process). libgcj ought to have a way to hook into the low-level process code so that it can interact gracefully with other libraries. I think it is ok if this is CNI only. -- Summary: add wait handling hook Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tromey at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29324
[Bug libgcj/29324] add wait handling hook
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-02 18:35 --- Hmnm, is this really a bug, waitpid is used only in the reaper thread. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29324
[Bug libgcj/29324] add wait handling hook
--- Comment #2 from tromey at gcc dot gnu dot org 2006-10-02 18:39 --- Yes, it really is a bug. libgcj can reap a child process started by some other library. This means it is hard to use libgcj in conjunction with other libraries which may want to do their own subprocess bookkeeping. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-02 18:39:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29324
[Bug fortran/29317] gfortran.dg/exponent_1.f90 failure
--- Comment #4 from sgk at troutmask dot apl dot washington dot edu 2006-10-02 19:08 --- Subject: Re: New: gfortran.dg/exponent_1.f90 failure On Mon, Oct 02, 2006 at 09:32:55AM -, fxcoudert at gcc dot gnu dot org wrote: > gfortran.dg/exponent_1.f90 is failing at all optimization levels on > x86_64-linux (see > http://gcc.gnu.org/ml/gcc-testresults/2006-10/msg00081.html). > Here is the problem: > > $ cat exponent_1.f90 > real, parameter :: one = 1.0 > print *, exponent(one) > if (exponent(one) /= 1.0) call abort > end I can't reproduce this. :( troutmask:sgk[243] gfc4x -o z f.f90 troutmask:sgk[244] ./z 1 troutmask:sgk[245] gfc4x -o z -O f.f90 troutmask:sgk[246] ./z 1 troutmask:sgk[247] gfc4x -o z -O2 f.f90 troutmask:sgk[248] ./z 1 troutmask:sgk[249] gfc4x -o z -O3 f.f90 troutmask:sgk[250] ./z 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29317
[Bug rtl-optimization/29294] 4.1, 4.2 (possibly 4.0?) not finding postmodify address mode on ARM
--- Comment #4 from eplondke at gmail dot com 2006-10-02 19:16 --- (In reply to comment #3) > Actually this case should not be using post modify at all except how many bits > does ARM have to use for an offset? I thought 16bits which means you don't > need > that at all and GCC should generate it without an increment. Oh and this is a > RTL opt issue. > ARM normal arithmetic operands support an 8-bit integer rotated right by an even number of bits (0-30). If you rotate at all some microarchitectures may cause stalls (Xscale maybe?)... Load and Store word (and unsigned byte) have a +/- 12-bit offset. Load and store other single values has a +/- 8-bit offset. Load and store multiple may have no offset. That's for ARM. For THUMB, you get + 5 bits. Both ARM and THUMB mode have postincrement modes. ARM gets a decent postmodify. For THUMB you use the Load Multiple Increment After instruction with a single regster specified. Looks like CSE1 is the first time that (set (reg) (mem (reg))) gets converted to (set (reg) (mem (plus (reg) (4 I have noticed a propensity for postmodify to not be used in several targets comparing GCC 4.X to GCC 3.X. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29294
[Bug c++/29298] rejects valid specialization of member template classes
--- Comment #5 from sebor at roguewave dot com 2006-10-02 19:19 --- Interesting. The vanilla EDG front end rejects it as expected. I wonder why Intel accepts it when neither EDG nor gcc does. Maybe we should open a bug with them to find out ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29298
[Bug middle-end/18071] [4.0/4.1/4.2 Regression] -Winline does not respect -fno-default-inline
--- Comment #24 from wilson at gcc dot gnu dot org 2006-10-02 19:23 --- Created an attachment (id=12372) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12372&action=view) improved patch for inline warning Works for simple testcases. Needs full bootstrap regression test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18071
[Bug middle-end/18071] [4.0/4.1/4.2 Regression] -Winline does not respect -fno-default-inline
--- Comment #25 from wilson at tuliptree dot org 2006-10-02 19:25 --- Subject: Re: [4.0/4.1/4.2 Regression] -Winline does not respect -fno-default-inline On Sat, 2006-09-30 at 12:36 +, lopezibanez at gmail dot com wrote: > I think I found out what is going on, although I cannot decide myself what is > the correct action. If you look at Comment #19, you will see that I have already provided a solution. However, I see that I failed to add the patch I wrote to the bug report. I will do that now. My work on this patch was interrupted by health problems, and I haven't gotten back to it yet. It is still part of my large backlog. Jim -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18071
[Bug libstdc++/29286] [4.0/4.1/4.2 Regression] placement new does not change the dynamic type as it should
--- Comment #18 from mrs at apple dot com 2006-10-02 19:28 ---
What is your position based upon? Mine is based upon having been in the room
when we decided what the C rules probably were, what the C++ rules could be and
the up side and down side of each choice and where we decided what our intent
was going to be and lots of word smithing sessions as well. You can see some
of the depth with which we discussed it in our formulation of the wording in
the standard:
6 Similarly, before the lifetime of an object has started but after the
storage which the object will occupy has been allocated or, after the
lifetime of an object has ended and before the storage which the
object occupied is reused or released, any lvalue which refers to the
original object may be used but only in limited ways. Such an lvalue
refers to allocated storage (_basic.stc.dynamic.deallocation_), and
using the properties of the lvalue which do not depend on its value is
well-defined. If an lvalue-to-rvalue conversion (_conv.lval_) is
applied to such an lvalue, the program has undefined behavior; if the
original object will be or was of a non-POD class type, the program
has undefined behavior if:
--the lvalue is used to access a non-static data member or call a non-
static member function of the object, or
--the lvalue is implicitly converted (_conv.ptr_) to a reference to a
base class type, or
--the lvalue is used as the operand of a static_cast
(_expr.static.cast_) (except when the conversion is ultimately to
char& or unsigned char&), or
--the lvalue is used as the operand of a dynamic_cast
(_expr.dynamic.cast_) or as the operand of typeid.
7 If, after the lifetime of an object has ended and before the storage
which the object occupied is reused or released, a new object is cre-
ated at the storage location which the original object occupied, a
pointer that pointed to the original object, a reference that referred
to the original object, or the name of the original object will auto-
matically refer to the new object and, once the lifetime of the new
object has started, can be used to manipulate the new object, if:
--the storage for the new object exactly overlays the storage location
which the original object occupied, and
--the new object is of the same type as the original object (ignoring
the top-level cv-qualifiers), and
--the original object was a most derived object (_intro.object_) of
type T and the new object is a most derived object of type T (that
is, they are not base class subobjects). [Example:
struct C {
int i;
void f();
const C& operator=( const C& );
};
const C& C::operator=( const C& other)
{
if ( this != &other )
{
this->~C(); // lifetime of *this ends
new (this) C(other);// new object of type C created
f();// well-defined
}
return *this;
}
C c1;
C c2;
c1 = c2;// well-defined
c1.f(); // well-defined; c1 refers to a new
object of type C
--end example]
8 If a program ends the lifetime of an object of type T with static
(_basic.stc.static_) or automatic (_basic.stc.auto_) storage duration
and if T has a non-trivial destructor,35) the program must ensure that
an object of the original type occupies that same storage location
when the implicit destructor call takes place; otherwise the behavior
of the program is undefined. This is true even if the block is exited
with an exception.
We explcitly did consider overlaying one type with a completely different type
and did so intend for the standard to allow that. Further, our intent of
saying that automatics and objects with static duration could be so changed
provided certain conditions were met was meant no only to state that this could
be done, but to state the exact sitations in which it was defined to do so.
> Mike's position is that accessing a variable using its static type is not
> always safe; I find this bizarre.
Welcome to C++, let me quote the standard:
8 If a program ends the lifetime of an object of type T with static
(_basic.stc.static_) or automatic (_basic.stc.auto_) storage duration
and if T has a non-trivial destructor,35) the program must ensure that
an object of the original type occupies that same storage location
when the implicit destructor call takes place; otherwise the behavior
of the program is undefined.
If we didn't mean exactly what we wrote, why on earth would we write it? Hint,
in this, we meant exactlty what was written. I was there, in every single
meeting where we talked about it. I know what our intent was,
[Bug middle-end/27478] entry and addressable and value-expr: and the gimplifier
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-10-02 19:39 --- The gimplifier is going wrong. It first uses the value-expr and then forgets that can be addressable or maybe even worse we don't mark the result as addressable. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|fortran |middle-end Summary|getting ": error: invalid |entry and addressable and |operand to binary operator" |value-expr: and the ||gimplifier http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27478
[Bug middle-end/27478] entry and addressable and value-expr: and the gimplifier
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2006-10-02 20:13 --- I think the following can workaround the middle-end problem: Index: trans-decl.c === --- trans-decl.c(revision 117368) +++ trans-decl.c(working copy) @@ -1866,6 +1866,7 @@ TREE_PUBLIC (decl) = 0; TREE_USED (decl) = 1; GFC_DECL_RESULT (decl) = 1; + TREE_ADDRESSABLE (decl) = 1; layout_decl (decl, 0); -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||19292 nThis|| Component|fortran |middle-end Known to fail||4.2.0 Known to work||4.1.2 Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27478
[Bug c++/16625] Discarded Linkonce sections in .rodata
--- Comment #32 from hacksaw at hacksaw dot org 2006-10-02 20:15 --- Is the 3.3.x tree closed? If that is the case, should someone mark this bug WONTFIX, and those who care can move on patching their gcc or moving to a higher one? Has anyone reproduced this bug with a higher compiler version? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16625
[Bug c++/29298] rejects valid specialization of member template classes
--- Comment #6 from pcarlini at suse dot de 2006-10-02 20:51 --- (In reply to comment #5) > Interesting. The vanilla EDG front end rejects it as expected. I wonder why > Intel accepts it when neither EDG nor gcc does. Sorry about the trivial question: Intel in *strict* mode? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29298
[Bug target/29292] configure produces strange gmp, mpfr lib directories.
--- Comment #3 from danp57 at optonline dot net 2006-10-02 21:02 --- Subject: Re: configure produces strange gmp, mpfr lib directories. There are multiple logs -- 1) I switched to static libraries, but tried both static and shared (the static libs are more standard, and less likely to choke libtool -- if its having problems). 2) I built gmp and mpfr separately (I've had successful builds on both Cygwin and OS X in that config), and I've used the mpfr that comes with the gmp distribution. When I hack the Makefile to correct the complaint I'm writing about below, I still have problems resolving symbols. HOWEVER: the issue I'm looking at here is something I have been able to isolate, and it looks like a good place to start. [EMAIL PROTECTED]:/geno4/watplatt/gcc/gcc-4.1.1.build $ ../gcc-4.1.1/configure --without-nls --enable-languages=c,c++,fortran,objc,obj-c++ --with-gmp=/usr/local/ --with-mpfr=/usr/local/ loading cache ./config.cache checking host system type... powerpc-ibm-aix5.3.0.0 checking target system type... powerpc-ibm-aix5.3.0.0 checking build system type... powerpc-ibm-aix5.3.0.0 checking for a BSD compatible install... ../gcc-4.1.1/install-sh -c checking whether ln works... yes checking whether ln -s works... yes checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking for gnatbind... no checking whether compiler driver understands Ada... no checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f2 checking for correct version of gmp.h... yes checking for MPFR... no configure: error: GMP with MPFR support is required to build fortran [EMAIL PROTECTED]:/geno4/watplatt/gcc/gcc-4.1.1.build $ When I switch the -with-gmp... to /usr/local/lib, the script builds, but the Makefile contains # Where to find GMP HOST_GMPLIBS = -L/usr/local/lib/lib -L/usr/local/lib/lib -lmpfr -lgmp HOST_GMPINC = -I/usr/local/lib/include -I/usr/local/lib/include It should say /usr/local/include, and /usr/local/lib. The libs are there: ls -CF /usr/local/lib/*gmp* /usr/local/lib/libgmp.a/usr/local/lib/libgmp.la* [EMAIL PROTECTED]:/geno4/watplatt/gcc/gcc-4.1.1.build $ ls -CF /usr/local/lib/*mpfr* /usr/local/lib/libmpfr.a/usr/local/lib/libmpfr.la* [EMAIL PROTECTED]:/geno4/watplatt/gcc/gcc-4.1.1.build $ Without correcting the /usr/local/lib/lib reference in the make file, I get: gcc -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute-DHAVE_CONFIG_H -o f951 \ fortran/arith.o fortran/array.o fortran/bbt.o fortran/check.o fortran/data.o fortran/decl.o fortran/dump-parse-tree.o fortran/error.o fortran/expr.o fortran/interface.o fortran/intrinsic.o fortran/io.o fortran/iresolve.o fort ran/match.o fortran/matchexp.o fortran/misc.o fortran/module.o fortran/options.o fortran/parse.o fortran/primary.o fortran/resolve.o fortran/scanner.o fortran/simplify.o fortran/st.o fortran/symbol.o fortran/convert.o fortran/depende ncy.o fortran/f95-lang.o fortran/trans.o fortran/trans-array.o fortran/trans-common.o fortran/trans-const.o fortran/trans-decl.o fortran/trans-expr.o fortran/trans-intrinsic.o fortran/trans-io.o fortran/trans-stmt.o fortran/trans-typ es.o main.o libbackend.a ../libcpp/libcpp.a -L/usr/local/lib/lib -L/usr/local/lib/lib -lmpfr -lgmp ../libcpp/libcpp.a -lintl -liconv ../libiberty/libiberty.a ld: 0711-317 ERROR: Undefined symbol: .__gmpfr_out_str ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status make[2]: *** [f951] Error 1 make[2]: Leaving directory `/geno4/watplatt/gcc/gcc-4.1.1.build/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/geno4/watplatt/gcc/gcc-4.1.1.build' make: *** [all] Error 2 [EMAIL PROTECTED]:/geno4/watplatt/gcc/gcc-4.1.1.build $ If I try to fix the /usr/local/lib/lib reference, there are yet more undefined symbols: ld: 0711-317 ERROR: Undefined symbol: .mpfr_add ld: 0711-317 ERROR: Undefined symbol: .mpfr_sqrt ld: 0711-317 ERROR: Undefined symbol: .mpfr_log10 ld: 0711-317 ERROR: Undefined symbol: .__gmpz_tdiv_r ld: 0711-317 ERROR: Undefined symbol: .__gmpz_fdiv_r ld: 0711-317 ERROR: Undefined symbol: .mpfr_nextabove ld: 0711-317 ERROR: Undefined symbol: .mpfr_nextbelow ld: 0711-317 ERROR: Undefined symbol: .mpfr_ui_div ld: 0711-317 ERROR: Undefined symbol: .mpfr_mul_2ui ld: 0711-317 ERROR: Undefined symbol: .mpfr_set_ui ld: 0711-317 ERROR: Undefined symbol: .mpfr_pow_ui ld: 0711-317 ERROR: Undefined symbol: .__gmpz_get_d ld: 0711-317 ERROR: Undefined symbol: .mpfr_get_d ld: 0711-317 ERROR: Undefined symbol: .mpfr_mul_2si ld: 0711-317 ERROR: Undefined symbol: .mpfr_div_ui ld: 0711-317 ERROR: Undefined symbol: .mpfr_mul_ui ld: 071
[Bug middle-end/18071] [4.0/4.1/4.2 Regression] -Winline does not respect -fno-default-inline
--- Comment #26 from lopezibanez at gmail dot com 2006-10-02 21:03 --- (In reply to comment #25) > If you look at Comment #19, you will see that I have already provided a > solution. However, I see that I failed to add the patch I wrote to the > bug report. I will do that now. My work on this patch was interrupted > by health problems, and I haven't gotten back to it yet. It is still > part of my large backlog. And if you look at comment #18, you will see that Mark Mitchell has already stated the Winline is suppossed to warn "about functions *declared* inline, but not actually inlined. [...] DECL_INLINE is an internal note to the compiler that it might make sense to inline that function." Your patch will break Winline output for any function that is declared inline ( DECL_DECLARED_INLINE_P (fndecl) = 1;) but it is marked as not making sense to be inlined by the compiler (DECL_INLINE (fndecl) = 0;). From a quick grep, there seems to be a few places where this may occur. Of course, you know more about gcc than me. I was just trying to point out this potential issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18071
[Bug fortran/18026] boz initialization of REALs fails
--- Comment #9 from anlauf at gmx dot de 2006-10-02 21:35 --- (In reply to comment #8) > This is NOT a bug. g77 compatibility and the Fortran 95 standard > have a conflict, and so IMNSHO the Fortran 95 standard wins. Gfortran unfortunately does not have a switch to compile legacy code in a way that is sufficiently compatible with g77. The (multiple) libraries that I use do use code similar to the example in quite a few places. I am not the author of these libraries, I just use them. Fortunately I can still use g77 on my platforms to compile the relevant set of files. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18026
[Bug middle-end/27986] [4.0/4.1/4.2 Regression] jump to middle of loop on entry with using old version of an variable
--- Comment #6 from steven at gcc dot gnu dot org 2006-10-02 21:46 --- Re comment #5: "A quick pass to look for these cases and transform those PHIs into copies at the appropriate place would accomplish the same thing." That is exactly what I'd expect the out-of-ssa pass to take care of. Much like the insert_backedge_copies() stuff in the current out-of-ssa pass. Maybe I'm expecting too much, tho... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27986
[Bug fortran/20541] TR 15581: ALLOCATABLE components
--- Comment #32 from pault at gcc dot gnu dot org 2006-10-02 21:54 --- Created an attachment (id=12373) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12373&action=view) A patch that fixes test_ab9.f90 You will see the modification in trans-types.c. This is the first bit of the patch that is not specific to allocatable components, although I am hard pressed to find a case that doesn't involve them. If you feel uncomfortable with breaking the hermetic seal, I could make it specific. That said, this does regtest OK, including all , the other derived type association tests. I will write a test case tomorrow sometime and so have included my reduced version of test_ab9.f90 from Slavatore Filippone to ensure that the audit trail makes sense. The problem arises because of the assignment that is used to initialize the INTENT(OUT) derived type in gfc_conv_function_call. This exercises an association that, I think, would not otherwise be possible. It is fixed by usin the current namespace to start the search for like types, from any namespace where there is no parent. The case where the derived type found is the same as 'self' is eliminated from the search by a continue statement. Paul module modA type dt integer, allocatable :: i(:) end type dt end module modA Module modB interface subroutine foo(x) use modA type(dt), intent(out) :: x end subroutine foo end interface end module modB subroutine test_ab9() use modB ! putting this after USE modA clears the problem use modA type(dt) :: a call foo(a) return end subroutine test_ab9 -- pault at gcc dot gnu dot org changed: What|Removed |Added Attachment #12350|0 |1 is obsolete|| Attachment #12354|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541
[Bug middle-end/27986] [4.0/4.1/4.2 Regression] jump to middle of loop on entry with using old version of an variable
--- Comment #7 from amacleod at redhat dot com 2006-10-02 22:13 --- Its not that you are expecting too much, just in the wrong place from my point of view :-) Changing the out of ssa algorithm or implementation isnt going to change this code. It requires changing the code out of ssa sees. insert_backedge_copies() ought to be its own pass as well, as far as Im concerned. Its the very first thing called, and is not related to the rest of what out of ssa does at all. It should be moved out, and we can have an optimization pass just before out-of-ssa which looks for this kind of thing. That can happen when I start adding the pre-passes for register pressure work if no one does it earlier. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27986
[Bug middle-end/27478] entry and addressable and value-expr: and the gimplifier
--- Comment #9 from patchapp at dberlin dot org 2006-10-02 22:15 --- Subject: Bug number PR 27478 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/2006-10/msg00098.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27478
[Bug c++/29226] [4.0/4.1/4.2 regression] ICE in make_decl_rtl, at varasm.c:886
--- Comment #7 from mmitchel at gcc dot gnu dot org 2006-10-02 22:21 --- Subject: Bug 29226 Author: mmitchel Date: Mon Oct 2 22:21:02 2006 New Revision: 117375 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117375 Log: PR c++/29226 * typeck.c (cxx_sizeof_or_alignof_type): Tidy. In templates, do not try to actually evaluate sizeof for a VLA type. PR c++/29226 * g++.dg/template/vla1.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/vla1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29226
[Bug c/29326] New: __builtin_trap is not documented
__builtin_trap is mentioned on http://gcc.gnu.org/onlinedocs/gcc/Standards.html But it is not documented on: http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html -- Summary: __builtin_trap is not documented Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29326
[Bug c/29326] __builtin_trap is not documented
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-02 23:27 --- If I get a chance I will post a patch sometime this week or next. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29326
[Bug c++/29226] [4.0/4.1 regression] ICE in make_decl_rtl, at varasm.c:886
--- Comment #8 from mmitchel at gcc dot gnu dot org 2006-10-02 23:42 --- Subject: Bug 29226 Author: mmitchel Date: Mon Oct 2 23:41:59 2006 New Revision: 117377 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117377 Log: PR c++/29226 * typeck.c (cxx_sizeof_or_alignof_type): Tidy. In templates, do not try to actually evaluate sizeof for a VLA type. PR c++/29226 * g++.dg/template/vla1.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/vla1.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/typeck.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29226
[Bug testsuite/29307] libiberty/testsuite/test-demangle : parsing errors after unknown demangling style
--- Comment #2 from ian at airs dot com 2006-10-02 23:52 --- I believe this is happening because if the format is unrecognized, the test-demangle program does not go on to see that the --no-params option was used. When --no-params is used, it needs to skip an additional line. I see no advantage to making the test-demangle program robust when given an erroneous input file. If you feel like doing so, please go ahead. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29307
[Bug c++/29138] [4.0/4.1/4.2 Regression] access declarations don't work for classes
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29138
[Bug fortran/29327] New: FAIL: gfortran.dg/specifics_1.f90
Executing on host: /home/dave/gnu/gcc-4.2/objdir/gcc/testsuite/gfortran/../../gf ortran -B/home/dave/gnu/gcc-4.2/objdir/gcc/testsuite/gfortran/../../ /home/dave/ gnu/gcc-4.2/gcc/gcc/testsuite/gfortran.dg/specifics_1.f90 -O0 -ff2c -L/home/ dave/gnu/gcc-4.2/objdir/hppa-linux/./libgfortran/.libs -L/home/dave/gnu/gcc-4.2/ objdir/hppa-linux/./libgfortran/.libs -L/home/dave/gnu/gcc-4.2/objdir/hppa-linux /./libiberty -lm -o ./specifics_1.exe(timeout = 300) /tmp/ccQbN46K.o: In function `.LC82': (.rodata+0x274): undefined reference to `f2c_specific__conjg_4' /tmp/ccQbN46K.o: In function `.LC95': (.rodata+0x28c): undefined reference to `f2c_specific__conjg_8' collect2: ld returned 1 exit status compiler exited with status 1 output is: /tmp/ccQbN46K.o: In function `.LC82': (.rodata+0x274): undefined reference to `f2c_specific__conjg_4' /tmp/ccQbN46K.o: In function `.LC95': (.rodata+0x28c): undefined reference to `f2c_specific__conjg_8' collect2: ld returned 1 exit status FAIL: gfortran.dg/specifics_1.f90 -O0 (test for excess errors) Excess errors: (.rodata+0x274): undefined reference to `f2c_specific__conjg_4' (.rodata+0x28c): undefined reference to `f2c_specific__conjg_8' Fails at all optimizations. The references come in the following plabels: .align 4 .LC82: .word P%f2c_specific__conjg_4 .align 4 .LC95: .word P%f2c_specific__conjg_8 -- Summary: FAIL: gfortran.dg/specifics_1.f90 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa-unknown-linux-gnu GCC host triplet: hppa-unknown-linux-gnu GCC target triplet: hppa-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29327
[Bug fortran/18026] boz initialization of REALs fails
--- Comment #10 from sgk at troutmask dot apl dot washington dot edu 2006-10-03 01:48 --- Subject: Re: boz initialization of REALs fails On Mon, Oct 02, 2006 at 09:35:11PM -, anlauf at gmx dot de wrote: > > > This is NOT a bug. g77 compatibility and the Fortran 95 standard > > have a conflict, and so IMNSHO the Fortran 95 standard wins. > > Gfortran unfortunately does not have a switch to compile legacy code > in a way that is sufficiently compatible with g77. Actually, gfortran does have -std=legacy. It, unfortunately, does not have code inside the appropriate IF statements to do what you want. > The (multiple) libraries that I use do use code similar to the > example in quite a few places. I am not the author of these > libraries, I just use them. Have you submitted bug reports to the authors of these libraries? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18026
[Bug libgcj/28579] [ecj] classpath build must use gcj
--- Comment #2 from tromey at gcc dot gnu dot org 2006-10-03 02:12 --- I can't reproduce this. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28579
[Bug fortran/29317] gfortran.dg/exponent_1.f90 failure
--- Comment #5 from danglin at gcc dot gnu dot org 2006-10-03 02:12 --- The gfortran.dg/exponent_1.f90 and gfortran.dg/nearest_1.f90 are falling on hppa2.0w-hp-hpux11.11. I updated to mpfr 2.2.0 and the tests are still failing. Possibly, I need a complete rebuild. -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29317
[Bug fortran/29317] gfortran.dg/exponent_1.f90 failure
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-10-03 02:17 --- Yes, make sure you do a complete clean rebuild. You may also need this for the PR29327. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29317
[Bug fortran/29317] gfortran.dg/exponent_1.f90 failure
--- Comment #7 from sgk at troutmask dot apl dot washington dot edu 2006-10-03 02:27 --- Subject: Re: gfortran.dg/exponent_1.f90 failure On Tue, Oct 03, 2006 at 02:12:55AM -, danglin at gcc dot gnu dot org wrote: > > The gfortran.dg/exponent_1.f90 and gfortran.dg/nearest_1.f90 are falling > on hppa2.0w-hp-hpux11.11. I updated to mpfr 2.2.0 and the tests are still > failing. Possibly, I need a complete rebuild. > nearest_1.f90 may be broken due to a bug with the handling of a subnormal number. I have no idea why exponent_1.f90 is failing. It works for me. If these are still failing in a few days, I'll either add a the dejagnu bits to run only on *-*-freebsd or I'll remove the test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29317
[Bug fortran/29327] FAIL: gfortran.dg/specifics_1.f90
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-03 02:41 --- http://gcc.gnu.org/ml/fortran/2006-09/msg00468.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29327
[Bug middle-end/28690] [4.2 Regression] Performace problem with indexed load/stores on powerpc
--- Comment #17 from bergner at vnet dot ibm dot com 2006-10-03 03:30 --- Created an attachment (id=12375) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12375&action=view) Patch to swap_commutative_operands_p and gen_addr_rtx to force base pointers into rA position of indexed load/store instructions. We propagated the MEM_POINTER/REG_POINTER flags fine. The problem is that the memory reference we're handed is a REG + REG which looks legitimate to us, so we never call LEGITIMIZE_ADDRESS, so we never have a chance to swap the operands. Since we cannot fixup the latest test case in LEGITIMIZE_ADDRESS, I've decided to attempt another swap_commutative_operands_p() / commutative_operand_precedence() change. However, I'm a little more selective on when we change swap_commutative_operands_p()'s return value. With this patch, I'm able to transform each of the test cases so that the base address if the first operand of the indexed load. * rtlanal.c (swap_commutative_operands_p): Preference a REG_POINTER over a non REG_POINTER. * tree-ssa-address.c (gen_addr_rtx): Force a REG_POINTER to be the first operand of a PLUS. -- bergner at vnet dot ibm dot com changed: What|Removed |Added Attachment #12305|0 |1 is obsolete|| Attachment #12306|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
[Bug fortran/19260] & not required when splitting a token in continuation
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-10-03 03:58 --- Subject: Bug 19260 Author: jvdelisle Date: Tue Oct 3 03:58:20 2006 New Revision: 117384 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117384 Log: 2006-10-02 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/19262 * gfortran.h (gfc_option_t): Add max_continue_fixed and max_continue_free. * options.c (gfc_init_options): Initialize fixed form and free form consecutive continuation line limits. * scanner.c (gfc_scanner_init_1): Initialize continue_line and continue_count. (gfc_next_char_literal): Count the number of continuation lines in the current statement and warn if limit is exceeded. 2006-10-02 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/19260 * scanner.c (gfc_next_char_literal): Add check for missing '&' and warn if in_string, otherwise return ' '. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/options.c trunk/gcc/fortran/scanner.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19260
[Bug fortran/19262] more than thirty-nine continuation lines should issue a std-warn
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-10-03 03:58 --- Subject: Bug 19262 Author: jvdelisle Date: Tue Oct 3 03:58:20 2006 New Revision: 117384 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117384 Log: 2006-10-02 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/19262 * gfortran.h (gfc_option_t): Add max_continue_fixed and max_continue_free. * options.c (gfc_init_options): Initialize fixed form and free form consecutive continuation line limits. * scanner.c (gfc_scanner_init_1): Initialize continue_line and continue_count. (gfc_next_char_literal): Count the number of continuation lines in the current statement and warn if limit is exceeded. 2006-10-02 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/19260 * scanner.c (gfc_next_char_literal): Add check for missing '&' and warn if in_string, otherwise return ' '. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/options.c trunk/gcc/fortran/scanner.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19262
[Bug fortran/19260] & not required when splitting a token in continuation
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2006-10-03 04:10 --- Subject: Bug 19260 Author: jvdelisle Date: Tue Oct 3 04:09:49 2006 New Revision: 117385 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117385 Log: 2006-10-02 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/19260 * gfortran.dg/continuation.f90: Rename to continuation_1.f90. * gfortran.dg/continuation_2.f90: New test. PR fortran/19262 * gfortran.dg/continuation_3.f90: New test. * gfortran.dg/continuation_4.f90: New test. * gfortran.dg/continuation_5.f: New test. * gfortran.dg/continuation_6.f: New test. Added: trunk/gcc/testsuite/gfortran.dg/continuation_1.f90 - copied unchanged from r117065, trunk/gcc/testsuite/gfortran.dg/continuation.f90 trunk/gcc/testsuite/gfortran.dg/continuation_2.f90 trunk/gcc/testsuite/gfortran.dg/continuation_3.f90 trunk/gcc/testsuite/gfortran.dg/continuation_4.f90 trunk/gcc/testsuite/gfortran.dg/continuation_5.f trunk/gcc/testsuite/gfortran.dg/continuation_6.f Removed: trunk/gcc/testsuite/gfortran.dg/continuation.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19260
[Bug fortran/19262] more than thirty-nine continuation lines should issue a std-warn
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2006-10-03 04:10 --- Subject: Bug 19262 Author: jvdelisle Date: Tue Oct 3 04:09:49 2006 New Revision: 117385 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117385 Log: 2006-10-02 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/19260 * gfortran.dg/continuation.f90: Rename to continuation_1.f90. * gfortran.dg/continuation_2.f90: New test. PR fortran/19262 * gfortran.dg/continuation_3.f90: New test. * gfortran.dg/continuation_4.f90: New test. * gfortran.dg/continuation_5.f: New test. * gfortran.dg/continuation_6.f: New test. Added: trunk/gcc/testsuite/gfortran.dg/continuation_1.f90 - copied unchanged from r117065, trunk/gcc/testsuite/gfortran.dg/continuation.f90 trunk/gcc/testsuite/gfortran.dg/continuation_2.f90 trunk/gcc/testsuite/gfortran.dg/continuation_3.f90 trunk/gcc/testsuite/gfortran.dg/continuation_4.f90 trunk/gcc/testsuite/gfortran.dg/continuation_5.f trunk/gcc/testsuite/gfortran.dg/continuation_6.f Removed: trunk/gcc/testsuite/gfortran.dg/continuation.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19262
[Bug fortran/19260] & not required when splitting a token in continuation
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2006-10-03 04:11 --- Fixed on 4.2 -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19260
[Bug fortran/19262] more than thirty-nine continuation lines should issue a std-warn
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2006-10-03 04:12 --- Fixed on 4.2 -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19262
[Bug fortran/29321] [4.1/4.2 Regression] optional arguments+derived types = segmentation fault
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29321
[Bug middle-end/28690] [4.2 Regression] Performace problem with indexed load/stores on powerpc
--- Comment #18 from paolo dot bonzini at lu dot unisi dot ch 2006-10-03 05:20 --- Subject: Re: [4.2 Regression] Performace problem with indexed load/stores on powerpc > * rtlanal.c (swap_commutative_operands_p): Preference a REG_POINTER > over a non REG_POINTER. > * tree-ssa-address.c (gen_addr_rtx): Force a REG_POINTER to be > the first operand of a PLUS. This is more gentle indeed. Be careful however as functions calling commutative_operand_precedence directly may have a problem with that. Can you try making an address illegitimate if it is non-REG_POINTER + REG_POINTER? Or set up splitters to do the transformation just before reload? Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
