[Bug tree-optimization/23821] [4.0/4.1/4.2 Regression] DOM and VRP creating harder to optimize code
--- Comment #8 from sebastian dot pop at cri dot ensmp dot fr 2006-02-13 08:45 --- Subject: Re: [4.0/4.1/4.2 Regression] DOM and VRP creating harder to optimize code This case reminds me the peeled chrec unification that I had to disable on autovect branch (I probably have to run the transformation as a stand alone pass outside the analyzer for not disturbing the user passes). In that case we're looking at a code like loop x = phi (0, a) a = phi (1, a + 1) endloop such that a simple transformation can make x a simple iv. This case is also quite important, as it occurs about 300 times during a bootstrap. Now for the current problem, we could run a pass just after loop_init for cleaning all these constructs. As suggested, we would have to build an equivalence relation either like VRP, or on demand. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23821
[Bug fortran/26246] [4.2 Regression] return string length is being marked as TREE_STATIC and TREE_PUBLIC
--- Comment #7 from jakub at gcc dot gnu dot org 2006-02-13 09:11 --- Looks good to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26246
[Bug tree-optimization/26209] [4.1/4.2 Regression] Specific code causes g++ 4.1.0 dominance ICE when compiled with -O3
--- Comment #9 from walter dot zimmer at dlr dot de 2006-02-13 09:22 --- (In reply to comment #8) Patch posted: Built bootstrap gcc-4.1-20060210+patch successful, and now our code is compiling fine with -O3. Many thanks for the quick help! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26209
[Bug libstdc++/26250] stringbuf::overflow() fails to set egptr() same as epptr()
--- Comment #1 from pcarlini at suse dot de 2006-02-13 10:03 --- Confirmed, thanks! -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-02-13 10:03:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26250
[Bug c++/26151] [3.4/4.0/4.1/4.2 regression] duplicate 'duplicate' diagnostic
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-02-13 10:29 --- Subject: Bug 26151 Author: reichelt Date: Mon Feb 13 10:29:31 2006 New Revision: 110911 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110911 Log: PR c++/26151 * parser.c (cp_parser_decl_specifier_seq): Check for duplicate decl-specifiers. Remove extra check for duplicate 'friend'. * decl.c (grokdeclarator): Remove check for duplicate decl-specifiers. Set longlong together with long_p. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/parser.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26151
[Bug c++/26151] [3.4/4.0/4.1 regression] duplicate 'duplicate' diagnostic
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-02-13 10:33 --- Fixed on mainline. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Summary|[3.4/4.0/4.1/4.2 regression]|[3.4/4.0/4.1 regression] |duplicate 'duplicate' |duplicate 'duplicate' |diagnostic |diagnostic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26151
[Bug libstdc++/26250] stringbuf::overflow() fails to set egptr() same as epptr()
--- Comment #2 from pcarlini at suse dot de 2006-02-13 10:38 --- I'm sorry, now I really understand the issue, I think (too much time since my last changes to this code... ;) I don't think we have a problem, actually, in the sense that we are implementing DR 169 rather literally, including: Of course, the resolution below requires some handling of simultaneous input and output since it is no longer possible to update egptr() whenever epptr() is changed. A possible solution is to handle this in underflow(). This means that we are updating epptr() in underflow, not earlier, not upon overflow. Does this way of implementing DR 169 make sense to you? -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26250
[Bug libstdc++/26250] stringbuf::overflow() fails to set egptr() same as epptr()
--- Comment #3 from pcarlini at suse dot de 2006-02-13 10:59 --- (In reply to comment #2) This means that we are updating epptr() in underflow, not earlier, not upon overflow. Does this way of implementing DR 169 make sense to you? I want to avoid giving the wrong impression that is only matter of when. In fact, our (mine and Nathan's, at least) best interpretation of DR 169 implies keeping get area and put area separate as much as possible (consistently with filebuf, by the way): this implies not only that egptr() is not updated to match epptr() upon overflow, but also that, really, doesn't make much sense talking about it during output. In fact, when input will start, and epptr() will be finally updated to match reality (i.e., the length of the internal string) in underflow, almost certainly will not match epptr() anyway. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26250
[Bug rtl-optimization/26222] [4.2 Regression] build failuring in libjava
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-02-13 11:21 --- Subject: Bug 26222 Author: rakdver Date: Mon Feb 13 11:21:23 2006 New Revision: 110912 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110912 Log: PR rtl-optimization/26222 * function.c (assign_stack_temp_for_type): Do not reuse stack slots after tree-rtl expansion. * loop-invariant.c (move_invariant_reg): Use force_operand on rhs before passing it to emit_move_insn. Modified: trunk/gcc/ChangeLog trunk/gcc/function.c trunk/gcc/loop-invariant.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26222
[Bug rtl-optimization/26254] [4.2 Regression] FAIL: gcc.c-torture/compile/20011109-1.c,-O1
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-02-13 12:26:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26254
[Bug rtl-optimization/26222] [4.2 Regression] build failuring in libjava
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-02-13 12:35 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26222
[Bug c++/26256] ignores using declaration
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-13 12:41 --- This is related to PR 25994. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||25994 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26256
[Bug rtl-optimization/26207] [4.2 Regression] file names in rtl dumps don't match reality
-- 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-02-13 12:46:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26207
Re: G++: Order of static destructors ?
Hi Guys, There appears to be a discrepancy in the way that G++ orders its static destructors. Given this test program: This appears to state that the 3.4.4 compiler got it right. The problem I believe is that the destructor for class A is registered to run using atexit() when the constructor for class B is run, but the destructor for class B is permanently recorded in the .dtors section. Since the exit() function runs the things recorded with atexit() first, before calling _exit() which runs the destructors in the .dtors section, the destructor for A is called before the destructor for B. Can anyone clarify this for me ? Is this a bug with the current G++ implementation ? Your 3.4.x result is correct. But your mainline result is most likely due not using --enable-__cxa_atexit when configuring GCC. This option is required to get the correct behavior of destructors. Now you can ask why --enable-__cxa_atexit is not enabled by default on GNU/Linux machine, I don't have that answer to that question but someone else will. Thanks, Andrew Pinski
[Bug rtl-optimization/26254] [4.2 Regression] FAIL: gcc.c-torture/compile/20011109-1.c,-O1
--- Comment #3 from kkojima at gcc dot gnu dot org 2006-02-13 13:08 --- Created an attachment (id=10834) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10834action=view) patch in testing I'm testing the attached patch which defines a new target hook, though I'm not sure if it is the right way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26254
[Bug rtl-optimization/26254] [4.2 Regression] FAIL: gcc.c-torture/compile/20011109-1.c,-O1
--- Comment #4 from rakdver at gcc dot gnu dot org 2006-02-13 13:59 --- Created an attachment (id=10835) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10835action=view) Other possible patch This might be a safer choice; although it would be nice to get all conditions right early, it might be too difficult to handle all the special cases of all possible targets. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26254
[Bug fortran/26257] New: internal compiler error: Segmentation fault, on function call with implcit length array parameter
The following code lets gfortran crash: module chtest contains function chararray2string(chararray) result(text) character(len=1), dimension(:) :: chararray ! input character(len=size(chararray)) :: text ! output integer :: n, i text(:) = ' ' n = size(chararray) DO i=1,n text(i:i) = chararray(i) END DO end function chararray2string end module chtest program TestStringTools use chtest implicit none character(len=50) :: txt character(len=1), dimension(50) :: chararr ! init and print txt(:) = ' ' chararr(1:3) = (/'A','B','C'/) ! convert to a string and print txt = chararray2string(chararr) print *,trim(txt) = [,trim(txt),] end program TestStringTools when compiled with: gfortran Test.F90 -o chtest I get the following response: Test.F90: In function MAIN__: Test.F90:22: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. Commenting out the following line removes the problem: txt = chararray2string(chararr) I used the following gfortran version: gfortran -v Using built-in specs. Target: i386-linux Configured with: ../gcc/configure --prefix=/tmp/gfortran-20060212/irun --enable-languages=c,fortran --host=i386-linux --with-gmp=/tmp/gfortran-20060212/gfortran_libs Thread model: posix gcc version 4.2.0 20060212 (experimental) best regards, Jos de Kloe -- Summary: internal compiler error: Segmentation fault, on function call with implcit length array parameter Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kloedej at knmi dot nl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26257
[Bug fortran/26246] [4.2 Regression] return string length is being marked as TREE_STATIC and TREE_PUBLIC
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-02-13 01:19:12 |2006-02-13 14:25:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26246
[Bug fortran/26257] internal compiler error: Segmentation fault, on function call with assumed shape array parameter
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-13 14:40 --- Confirmed, reduced testcase: module chtest contains function chararray2string(chararray) result(text) character(len=1), dimension(:) :: chararray ! input character(len=size(chararray)) :: text ! output end function chararray2string end module chtest program TestStringTools use chtest character(len=50) :: txt character(len=1), dimension(50) :: chararr txt = chararray2string(chararr) end program TestStringTools -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2006-02-13 14:40:58 date|| Summary|internal compiler error:|internal compiler error: |Segmentation fault, on |Segmentation fault, on |function call with implcit |function call with assumed |length array parameter |shape array parameter http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26257
[Bug tree-optimization/26258] New: [4.1 Regression] Wrong alias information for SRAed struct copy
Compiling with -O2 the following creates invalid virtual operands after
SRA:
struct Foo { int a; int b; };
Foo foo(Foo p, bool ret_first)
{
Foo first = p;
Foo last = p;
return ret_first ? first : last;
}
# iftmp.0D.1761_1 = PHI firstD.1740(1), lastD.1757(0);
L2:;
# VUSE SFT.6D.1783_24;
# VUSE SFT.8D.1785_26;
SR.26D.1803_27 = iftmp.0D.1761_1-bD.1735;
# VUSE SFT.6D.1783_24;
# VUSE SFT.8D.1785_26;
SR.25D.1802_28 = iftmp.0D.1761_1-aD.1734;
the access to -b should VUSE SFTs 5 and 7.
--
Summary: [4.1 Regression] Wrong alias information for SRAed
struct copy
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: wrong-code, alias
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26258
[Bug tree-optimization/26258] [4.1 Regression] Wrong alias information for SRAed struct copy
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-13 15:24 --- C testcase works correctly. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.1.0 | Known to work|4.2.0 4.0.3 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26258
[Bug tree-optimization/26258] [4.1 Regression] Wrong alias information for SRAed struct copy
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-02-13 15:31 ---
C testcase that fails (the PHI first, last is the important part):
typedef struct { int a; int b; } Foo;
Foo foo(Foo p, _Bool ret_first)
{
Foo first = p;
Foo last = p;
Foo *q;
q = ret_first ? first : last;
return *q;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26258
[Bug tree-optimization/26258] [4.1 Regression] Wrong alias information for struct
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-13 15:32 ---
You can invoke the wrong aliasing before SRA:
typedef struct Foo { int a; int b; }Foo;
Foo foo(Foo first, Foo last, bool ret_first)
{
Foo t;
Foo *t1 = (ret_first ? first : last);
t.a = t1-a;
t.b = t1-b;
return t;
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.1 Regression] Wrong alias|[4.1 Regression] Wrong alias
|information for SRAed struct|information for struct
|copy|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26258
[Bug middle-end/25335] [4.1/4.2 Regression] reload leaves insns from earlier passes around: fatal for postinc
--- Comment #14 from amylaar at gcc dot gnu dot org 2006-02-13 15:33 --- Subject: Bug 25335 Author: amylaar Date: Mon Feb 13 15:32:57 2006 New Revision: 110916 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110916 Log: Add PR marker for: PR middle-end/25335 * reload1.c (gen_reload): Also use find_replacement in UNARY_P case. Modified: trunk/gcc/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25335
[Bug tree-optimization/26258] [4.1/4.2 Regression] Wrong alias information for struct
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-13 15:37 ---
Testcase for the mainline:
typedef struct Foo { int a; int b; }Foo;
Foo foo(Foo first, Foo last, bool ret_first)
{
Foo t;
Foo *t1 = (ret_first ? first : last);
first.a = 2;
last.b = 3;
t.a = t1-a;
t.b = t1-b;
t.a += first.a;
t.b += last.b;
return t;
}
--
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-02-13 15:37:29
date||
Summary|[4.1 Regression] Wrong alias|[4.1/4.2 Regression] Wrong
|information for struct |alias information for struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26258
[Bug tree-optimization/26258] [4.1/4.2 Regression] Wrong alias information for struct
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26258
[Bug tree-optimization/26258] [4.1/4.2 Regression] Wrong alias information for struct
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-13 15:42 ---
For the testcase in comment #4:
Points-to analysis
Constraints:
t1_1 = first
t1_1 = last
Solving graph:
Points-to sets
t1_1 = { first last }
Pointed-to sets for pointers in foo
t1_1, name memory tag: NMT.17, is dereferenced, points-to vars: { SFT.4 SFT.6 }
t1_1 is wrong in Pointed-to sets for pointers in foo. maybe we forget to add
all the SFT's or something.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26258
[Bug tree-optimization/26258] [4.1/4.2 Regression] Wrong alias information for struct
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-02-13 15:44 --- Actually contstraints is wrong. in the first aliasing pass before proping into the addresses into PHI's: iftmp.0_25 = first iftmp.0_25 = first.b iftmp.0_24 = last iftmp.0_24 = last.b -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26258
[Bug tree-optimization/26258] [4.1/4.2 Regression] Wrong alias information for struct addresses in PHIs
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-02-13 16:25 --- I have a patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-02-13 15:37:29 |2006-02-13 16:25:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26258
[Bug tree-optimization/26197] [4.2 regression] ICE in is_old_name, at tree-into-ssa.c:466
--- Comment #6 from dorit at il dot ibm dot com 2006-02-13 16:23 --- (In reply to comment #5) Probably related to http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00446.html Would you expect then that calling mark_new_vars_to_rename, like you did in your patch, will fix this problem? I wasn't able to reproduce this error on powerpc-linux and i686-pc-linux-gnu. I do realize that there's a problem with the setting of virtual operands in the vectorizer. The over conservativeness in the vectorizer with respect to setting aliasing information for vector pointers when accessing struct fields may be responssible for this. I will try to look into this issue. In the meantime, could someone that can reproduce this problem try out the mark_new_vars_to_rename patch that Zdenek suggested in the link? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26197
[Bug bootstrap/26259] New: --enable-languages=c,c++,fortran needs ada
Posted here: http://gcc.gnu.org/ml/gcc/2006-02/msg00150.html However, I have noticed this recenly as well. This is considered a bug, as --enable-languages should actually work. -- Summary: --enable-languages=c,c++,fortran needs ada Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bkoz at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26259
[Bug tree-optimization/26260] New: PTA is slow with large structs (hits clisp)
clisp currently can't be compiled with optimization very well, because PTA
takes ages when presented with source code of the form clisp uses.
The attachment demonstrates this:
% /usr/lib/gcc/powerpc64-suse-linux/4.1.0/cc1 -O1 slow-pta.i
tree PTA : 18.08 (100%) usr 0.03 (75%) sys 18.11 (100%) wall
The code is trivial:
symbol_ *bla;
void slow (void) {
bla = symbol_tab_data.S_nil;
}
The crux is the form of symbol_tab_data containing a large number of members,
each of them being a struct containing seven pointers. Making that latter
struct contain less members hugely decreases compile time.
--
Summary: PTA is slow with large structs (hits clisp)
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at suse dot de
GCC host triplet: ppc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26260
[Bug tree-optimization/26260] PTA is slow with large structs (hits clisp)
--- Comment #1 from matz at suse dot de 2006-02-13 16:53 --- Created an attachment (id=10836) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10836action=view) Testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26260
[Bug bootstrap/26259] --enable-languages=c,c++,fortran needs ada
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-13 17:00 --- I have never seen this in my builds and I don't have Ada installed on my main machine which I bootstrap on. What is most likely happening is someone did svn change in the ada subdirectory and did not also do it in the gnattools directory also. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26259
[Bug c++/26261] New: Rejects template with local static variable used in return type
This may be related to PR25868, but looks simpler. Take this
piece of code that certainly looks valid to me:
--
template int dim class X {};
template class T class Y {
static const unsigned int dim = 1;
Xdim f();
};
template class T
XYT::dim YT::f() { return Xdim(); }
-
We reject the code with 3.3, 3.4, 4.0, 4.1, and mainline. I don't have any
older compilers here to check prior versions. The message is this:
-
g/y ~/tmp/build/gcc/mainline/bin/c++ -c x.cc
x.cc:12: error: prototype for 'XYT::dim YT::f()' does not match any in
class 'YT'
x.cc:8: error: candidate is: X1 YT::f()
x.cc:12: error: template definition of non-template 'XYT::dim YT::f()'
-
Since YT::dim == 1, the function really does match its prototype,
despite the error. So this is a rejects-valid.
W.
--
Summary: Rejects template with local static variable used in
return type
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at dealii dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26261
[Bug c++/26261] Rejects template with local static variable used in return type
-- bangerth at dealii dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26261
[Bug c++/26261] Rejects template with local static variable used in return type
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26261
[Bug c++/25868] [3.4/4.0/4.1/4.2 Regression] Multiple templates and typedefs cause function prototype not to match
--- Comment #4 from bangerth at dealii dot org 2006-02-13 17:13 --- May be related to PR26261. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25868
[Bug tree-optimization/26260] PTA is slow with large structs (hits clisp)
--- Comment #2 from dberlin at gcc dot gnu dot org 2006-02-13 17:18 --- Subject: Patch for bug 26260 This should fix it --- Comment #3 from dberlin at gcc dot gnu dot org 2006-02-13 17:18 --- Created an attachment (id=10837) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10837action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26260
[Bug target/26262] New: Named section support should infer segment name
The cctools assembler used by powerpc-apple-darwin requires section directives
in the form:
.section SEGNAME, SECTION_NAME
And, using a section attribute in gcc passes the name along unmodified. So,
for example:
void foo (void) __attribute__((section(bar)));
void foo (void) {}
produces:
.section bar
...
which generates an assembly-time syntax error. It would be nice if gcc would
infer the segment name from the data type (__TEXT for functions and __DATA for
data), unless a segment name is present (as indicated by a comma in the section
name specification, perhaps?)
There is some discussion of this in the thread starting here:
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00226.html
--
Summary: Named section support should infer segment name
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jconner at apple dot com
GCC target triplet: powerpc-apple-darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26262
[Bug c++/26261] Rejects template with local static variable used in return type
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-13 17:22 --- Confirmed. The interesting part is that for compilers pre 3.4, give an even weirder error message: t.cc:10: error: prototype for `XYT::dim YT::f()' does not match any in class `YT' t.cc:6: error: candidate is: XYT::dim YT::f() t.cc:10: error: template definition of non-template `XYT::dim YT::f()' it is obvious from YT::dim == YT::dim :). So I think we are not comparing template arguments correctly at all. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail|3.2.3 3.3.3 3.4.0 4.0.0 |3.2.3 3.3.3 3.4.0 4.0.0 |4.1.0 4.2.0 |4.1.0 4.2.0 3.0.4 2.95.3 Last reconfirmed|-00-00 00:00:00 |2006-02-13 17:22:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26261
[Bug target/26262] Named section support should infer segment name
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-13 17:22 --- 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-02-13 17:22:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26262
[Bug tree-optimization/26260] PTA is slow with large structs (hits clisp)
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-02-13 17:23 --- confirmed and testing in progress -- rguenth 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-02-13 17:23:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26260
[Bug c++/26263] New: defective locale named fr_CA
The program
#include iostream
#include locale
int main() {
std::cout.imbue(std::locale(fr_CA));
std::cout 1;
}
crashes on a 32-bit laptop as well as on a 64-bit workstation,
for all compiler versions 3.4.3 - 4.0.2 (didn't check others)
with a segmentation fault.
And I believe it shouldn't crash (only perhaps throwing an
exception).
--
Summary: defective locale named fr_CA
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: o dot kullmann at swansea dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26263
[Bug libstdc++/26263] defective locale named fr_CA
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-13 17:27 --- This is a dup of bug 23953 which was fixed in 4.0.3. *** This bug has been marked as a duplicate of 23953 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26263
[Bug libstdc++/23953] using stringstreams causes crashes with some locales
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-02-13 17:27 --- *** Bug 26263 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||o dot kullmann at swansea ||dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23953
[Bug c++/26261] Rejects template with local static variable used in return type
--- Comment #2 from bangerth at dealii dot org 2006-02-13 17:27 --- I should have noted that the problem can be avoided by declaring the member function as XYT::dim f(); instead of Xdim f(); I do find this confusing, however. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26261
[Bug target/25376] section attribute doesn't work on darwin
--- Comment #4 from jconner at gcc dot gnu dot org 2006-02-13 18:12 --- Subject: Bug 25376 Author: jconner Date: Mon Feb 13 18:12:17 2006 New Revision: 110917 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110917 Log: PR target/25376 * varasm.c (function_section): Check for section name before calling select_section on targets that define USE_SELECT_SECTION_FOR_FUNCTIONS. On other targets, use unlikely_text_section instead of hot_function_section if first_function_block_is_cold. * gcc.dg/pr25376.c: New test. * gcc.c-torture/compile/pr23237.c: Only compile test -- don't assemble. * lib/target-supports.exp (check_named_sections_available): Only compile named-sections test -- don't assemble. Added: trunk/gcc/testsuite/gcc.dg/pr25376.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/compile/pr23237.c trunk/gcc/testsuite/lib/target-supports.exp trunk/gcc/varasm.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25376
[Bug libstdc++/26250] stringbuf::overflow() fails to set egptr() same as epptr()
--- Comment #4 from sebor at roguewave dot com 2006-02-13 18:12 --- (In reply to comment #3) [...] keeping get area and put area separate as much as possible (consistently with filebuf, by the way): this implies not only that egptr() is not updated to match epptr() upon overflow, but also that, really, doesn't make much sense talking about it during output. In fact, when input will start, and epptr() will be finally updated to match reality (i.e., the length of the internal string) in underflow, almost certainly will not match epptr() anyway. Yes. But that doesn't conform to the requirement in 27.7.1.3, p8: ...If (mode ios_base::in) != 0, the function alters the read end pointer egptr() to point just past the new write position (as does the write end pointer epptr()). I'm not sure it makes sense yet, but it's there nonetheless. DR 169 doesn't lift the requirement, it just allows overflow() to make more than one write position available. Maybe we need a new issue to permit the behavior implemented by libstdc++. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26250
[Bug libstdc++/26250] stringbuf::overflow() fails to set egptr() same as epptr()
--- Comment #5 from pcarlini at suse dot de 2006-02-13 18:20 --- (In reply to comment #4) Yes. But that doesn't conform to the requirement in 27.7.1.3, p8: ...If (mode ios_base::in) != 0, the function alters the read end pointer egptr() to point just past the new write position (as does the write end pointer epptr()). I'm not sure it makes sense yet, but it's there nonetheless. DR 169 doesn't lift the requirement, it just allows overflow() to make more than one write position available. I see what you mean. The problem is that DR 169 says that: Of course, the resolution below requires some handling of simultaneous input and output since it is no longer possible to update egptr() whenever epptr() is changed. A possible solution is to handle this in underflow(). but then, doesn't change 27.7.1.3, p8, as it should, in my opinion, because the rationale is exactly that. Maybe we need a new issue to permit the behavior implemented by libstdc++. I would like that ;) Seriously, I think it's already *in* DR 169, only should be clearly stated, as a change to 27.7.1.3, p8. I don't know which is the best way to proceed... (by the way, again, Dinkum delivered with ICC also fails the last assert) -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu ||dot org Status|WAITING |NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26250
[Bug libstdc++/26250] stringbuf::overflow() fails to set egptr() same as epptr()
-- pcarlini at suse dot de changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26250
[Bug bootstrap/26259] --enable-languages=c,c++,fortran needs ada
--- Comment #2 from bkoz at gcc dot gnu dot org 2006-02-13 18:21 --- You can reproduce by checking out the gcc tree, and then removing the ada directories, and trying to build with --enable-languages=c,c++. -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26259
[Bug bootstrap/26259] --enable-languages=c,c++,fortran needs ada
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-13 18:23 --- Yes you forgot to remove the library and tools directory for Ada. This bug report is, doctor it hurts when I do this. Doctor: Don't do it then. -- 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=26259
[Bug libstdc++/26250] stringbuf::overflow() fails to set egptr() same as epptr()
--- Comment #6 from pcarlini at suse dot de 2006-02-13 18:30 --- By the way, in my reading of the standard and DR 169, not only the bits about egptr() in 27.7.1.3, p8 should be consistently updated, but also those about epptr(), ... just past the new write position (as does the write end pointer epptr(): if we allow for more than one additional write position, the latter cannot be always true. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26250
[Bug middle-end/24427] missing optimization opportunity with binary operators
--- Comment #3 from sayle at gcc dot gnu dot org 2006-02-13 18:33 --- Subject: Bug 24427 Author: sayle Date: Mon Feb 13 18:33:32 2006 New Revision: 110918 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110918 Log: PR middle-end/24427 * fold-const.c (fold_binary) BIT_IOR_EXPR: Transform (XC1)|C2 into (X,C2) if C1 is a subset of the bits of C2. Transform (XC1)|C2 into X|C2 if C1|C2 == ~0. Canonicalize (XC1)|C2 as (X(C1~C2))|C2. BIT_AND_EXPR: Canonicalize (X|C1)C2 as (XC2)|(C1C2). * gcc.dg/tree-ssa/andor-1.c: New test case. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/andor-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24427
[Bug libstdc++/26250] stringbuf::overflow() fails to set egptr() same as epptr()
--- Comment #7 from sebor at roguewave dot com 2006-02-13 18:36 --- Subject: Re: stringbuf::overflow() fails to set egptr() same as epptr() pcarlini at suse dot de wrote: --- Comment #6 from pcarlini at suse dot de 2006-02-13 18:30 --- By the way, in my reading of the standard and DR 169, not only the bits about egptr() in 27.7.1.3, p8 should be consistently updated, but also those about epptr(), ... just past the new write position (as does the write end pointer epptr(): if we allow for more than one additional write position, the latter cannot be always true. I was afraid of that... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26250
[Bug c++/26195] [4.0 regression] pragma interface no longer handles explicit names
--- Comment #4 from zak at transversal dot com 2006-02-13 18:46 --- Marking as 4.0 regression, filling in versions known to work/fail. Here is a patch, tested against mainline, which seems to fix this: http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01002.html -- zak at transversal dot com changed: What|Removed |Added Keywords||patch Known to fail||4.0.3 4.1.0 4.2.0 Known to work||3.3.6 3.4.5 Summary|pragma interface no longer |[4.0 regression] pragma |handles explicit names |interface no longer handles ||explicit names http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26195
[Bug c++/26195] [4.0/4.1/4.2 regression] pragma interface no longer handles explicit names
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-13 18:48 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||02/msg01002.html Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||link-failure Last reconfirmed|-00-00 00:00:00 |2006-02-13 18:48:40 date|| Summary|[4.0 regression] pragma |[4.0/4.1/4.2 regression] |interface no longer handles |pragma interface no longer |explicit names |handles explicit names Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26195
[Bug tree-optimization/26264] New: Extraneous warning with __builtin_stdarg_start and optimization
The testcase from PR 18828 produces the improper diagnostic
18828.c: In function foo:
18828.c:11: warning: second parameter of va_start not last named argument
with 4.0 and above if the use of __builtin_va_start() is replaced with
__builtin_stdarg_start(). According to the ChangeLog below
__builtin_stdarg_start was renamed to __builtin_va_start, but I could find no
information about __builtin_stdarg_start() being deprecated or removed.
2002-07-15 Zack Weinberg [EMAIL PROTECTED]
* ginclude/varargs.h: Replace with stub which issues #error.
* ginclude/stdarg.h: __builtin_stdarg_start is renamed
__builtin_va_start.
[...]
3.4 does not produce the extraneous warning, so something introduced it after
the renaming of __builtin_stdarg_start to __builtin_va_start.
Testcase:
typedef __builtin_va_list __gnuc_va_list;
typedef __gnuc_va_list va_list;
extern void abort (void);
void foo (int size, ...)
{
va_list ap;
if (size != 21)
abort ();
__builtin_stdarg_start(ap,size);
__builtin_va_end(ap);
}
--
Summary: Extraneous warning with __builtin_stdarg_start and
optimization
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: James dot Juran at baesystems dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26264
[Bug middle-end/25724] Emits call to __cmpdi2 for long long comparison in switches
--- Comment #9 from roger at eyesopen dot com 2006-02-13 18:51 --- This has now been fixed on mainline. -- roger at eyesopen dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25724
[Bug tree-optimization/26264] Extraneous warning with __builtin_stdarg_start and optimization
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-13 18:54 --- __builtin_stdarg_start is depreciated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26264
[Bug tree-optimization/26264] Extraneous warning with __builtin_stdarg_start and optimization
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-13 18:59 ---
This patch will fix the problem:
Index: gimplify.c
===
--- gimplify.c (revision 110916)
+++ gimplify.c (working copy)
@@ -1984,7 +1984,8 @@ gimplify_call_expr (tree *expr_p, tree *
}
if (DECL_BUILT_IN_CLASS (decl) == BUILT_IN_NORMAL
- DECL_FUNCTION_CODE (decl) == BUILT_IN_VA_START)
+ (DECL_FUNCTION_CODE (decl) == BUILT_IN_VA_START
+ || DECL_FUNCTION_CODE (decl) == BUILT_IN_STDARG_START))
{
if (!arglist || !TREE_CHAIN (arglist))
{
But I don't know why GCC still has __builtin_stdarg_start.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26264
[Bug c++/19185] [3.4/4.0/4.1/4.2 Regression] ICE: cp_expr_size, at cp/cp-lang.c:308
--- Comment #7 from amylaar at gcc dot gnu dot org 2006-02-13 19:01 --- (In reply to comment #2) I believe that this error occurs because vax.h defines PCC_STATIC_STRUCT_RETURN. Removing this define allows the complilation of this file to complete. FWIW that means that some m68k targets might be affected too. But according to grep, vax.h and m68k.h are the only files defining this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19185
[Bug libgomp/25936] libgomp needs to link against rt on HPUX
--- Comment #7 from roger at eyesopen dot com 2006-02-13 19:02 --- This has now been fixed on mainline. -- roger at eyesopen dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25936
[Bug tree-optimization/26264] Extraneous warning with __builtin_stdarg_start and optimization
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-13 19:02 --- http://gcc.gnu.org/ml/gcc-patches/2002-07/msg00737.html Looks like the only reason why __builtin_stdarg_start is still there is for compatibility reasons, though it most likely should be removed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26264
[Bug tree-optimization/26264] Extraneous warning with __builtin_stdarg_start and optimization
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-13 19:04 --- http://gcc.gnu.org/ml/gcc-patches/2002-06/msg02203.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26264
[Bug tree-optimization/26264] Extraneous warning with __builtin_stdarg_start and optimization
--- Comment #5 from James dot Juran at baesystems dot com 2006-02-13 19:06 --- Yes, that does seem to be the case based on the ChangeLog I quoted. And of course the easy workaround for a developer is just to use __builtin_va_start instead. But is the deprecation of __builtin_stdarg_start documented anywhere? As I noted in the PR, I looked and couldn't find any mention of its deprecation. Thank you for the very quick patch though. Either applying this patch or getting rid of __builtin_stdarg_start entirely (with appropriate documentation) would seem to be preferable to the current behavior. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26264
Re: [Bug tree-optimization/26264] Extraneous warning with __builtin_stdarg_start and optimization
--- Comment #5 from James dot Juran at baesystems dot com 2006-02-13 19:06 --- Yes, that does seem to be the case based on the ChangeLog I quoted. And of course the easy workaround for a developer is just to use __builtin_va_start instead. But is the deprecation of __builtin_stdarg_start documented anywhere? As I noted in the PR, I looked and couldn't find any mention of its deprecation. Why is the developer using an undocumented builtin in the first place? -- Pinski
[Bug tree-optimization/26264] Extraneous warning with __builtin_stdarg_start and optimization
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-02-13 19:08 --- Subject: Re: Extraneous warning with __builtin_stdarg_start and optimization --- Comment #5 from James dot Juran at baesystems dot com 2006-02-13 19:06 --- Yes, that does seem to be the case based on the ChangeLog I quoted. And of course the easy workaround for a developer is just to use __builtin_va_start instead. But is the deprecation of __builtin_stdarg_start documented anywhere? As I noted in the PR, I looked and couldn't find any mention of its deprecation. Why is the developer using an undocumented builtin in the first place? -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26264
[Bug target/26255] [4.0 regression] internal compiler error: in reload_cse_simplify_operands, at postreload.c:391
--- Comment #3 from danglin at gcc dot gnu dot org 2006-02-13 19:08 --- Regarding comment #2, while it's possible that removing the SECONDARY_MEMORY_NEEDED_RTX define has had an effect, we have never had support in pa.md to load an HImode value into a floating-point register. The other changes in the patches mentioned don't affect HImode. It seems as reload isn't respecting HARD_REGNO_MODE_OK (see VALID_FP_MODE_P in pa32-regs.h). The reason for excluding HImode (and QImode) values from the FP registers is you can't do anything with them, and copying to/from the general registers has to be done thorugh memory. Thus, it's better to use the stack. -- 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=26255
[Bug tree-optimization/26264] Extraneous warning with __builtin_stdarg_start and optimization
--- Comment #7 from James dot Juran at baesystems dot com 2006-02-13 19:15 --- Point granted; I guess __builtin_stdarg_start could just be removed without warning or notice. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26264
[Bug fortran/26265] New: gfortran produces illegal assembler code
ffortran build 2006-02-12, Compiling a small module containing two simple functions gives the following result: bobo gfortran -Wall -c basic.F90 /tmp/ccOmbUEh.s: Assembler messages: /tmp/ccOmbUEh.s:36: Error: symbol `..__result' is already defined -- Summary: gfortran produces illegal assembler code Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bo dot berggren at glocalnet dot net GCC host triplet: i386 Linux GCC target triplet: i386 Linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26265
[Bug fortran/26265] gfortran produces illegal assembler code
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-13 19:20 --- This is a dup of bug 26246. *** This bug has been marked as a duplicate of 26246 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26265
[Bug fortran/26246] [4.2 Regression] return string length is being marked as TREE_STATIC and TREE_PUBLIC
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-02-13 19:20 --- *** Bug 26265 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||bo dot berggren at glocalnet ||dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26246
[Bug fortran/26265] gfortran produces illegal assembler code
--- Comment #2 from bo dot berggren at glocalnet dot net 2006-02-13 19:21 --- Created an attachment (id=10838) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10838action=view) This is the source file that fails to compile. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26265
[Bug fortran/26265] gfortran produces illegal assembler code
--- Comment #3 from bo dot berggren at glocalnet dot net 2006-02-13 19:22 --- Created an attachment (id=10839) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10839action=view) Adding the result keyword to the functions makes them compile cleanly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26265
[Bug c++/19185] [3.4/4.0/4.1/4.2 Regression] ICE: cp_expr_size, at cp/cp-lang.c:308
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2006-02-13 19:23 --- Subject: Re: [3.4/4.0/4.1/4.2 Regression] ICE: cp_expr_size, at cp/cp-lang.c:308 (In reply to comment #2) I believe that this error occurs because vax.h defines PCC_STATIC_STRUCT_RETURN. Removing this define allows the complilation of this file to complete. FWIW that means that some m68k targets might be affected too. But according to grep, vax.h and m68k.h are the only files defining this. Sometime ago I tested removing this define on vax-ultrix and had a successful build. While it's the default, I think it was a bad idea and should be removed. There's still -fpcc-struct-return that can be used when needed. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19185
[Bug fortran/25059] ICE after error message
--- Comment #3 from pault at gcc dot gnu dot org 2006-02-13 19:32 --- Subject: Bug 25059 Author: pault Date: Mon Feb 13 19:32:02 2006 New Revision: 110921 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110921 Log: 2006-02-13 Paul Thomas [EMAIL PROTECTED] PR fortran/26038 * trans-stmt.c (gfc_trans_allocate): Provide assumed character length scalar with missing backend_decl for the hidden dummy charlen. PR fortran/25059 * interface.c (gfc_extend_assign): Remove detection of non-PURE subroutine in assignment interface, with gfc_error, and put it in * resolve.c (resolve_code). PR fortran/25070 * interface.c (gfc_procedure_use): Flag rank checking for non- elemental, contained or interface procedures in call to (compare_actual_formal), where ranks are checked for assumed shape arrays.. 2006-02-13 Paul Thomas [EMAIL PROTECTED] PR fortran/26038 * gfortran.dg/allocate_char_star_scalar_1.f90: New test. PR fortran/25059 * gfortran.dg/impure_assignment_1.f90: New test. PR fortran/25070 * gfortran.dg/assumed_shape_ranks_1.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/allocate_char_star_scalar_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/assumed_shape_ranks_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/impure_assignment_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/interface.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/trans-stmt.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25059
[Bug fortran/25070] rank mismatch in subroutine call
--- Comment #3 from pault at gcc dot gnu dot org 2006-02-13 19:32 --- Subject: Bug 25070 Author: pault Date: Mon Feb 13 19:32:02 2006 New Revision: 110921 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110921 Log: 2006-02-13 Paul Thomas [EMAIL PROTECTED] PR fortran/26038 * trans-stmt.c (gfc_trans_allocate): Provide assumed character length scalar with missing backend_decl for the hidden dummy charlen. PR fortran/25059 * interface.c (gfc_extend_assign): Remove detection of non-PURE subroutine in assignment interface, with gfc_error, and put it in * resolve.c (resolve_code). PR fortran/25070 * interface.c (gfc_procedure_use): Flag rank checking for non- elemental, contained or interface procedures in call to (compare_actual_formal), where ranks are checked for assumed shape arrays.. 2006-02-13 Paul Thomas [EMAIL PROTECTED] PR fortran/26038 * gfortran.dg/allocate_char_star_scalar_1.f90: New test. PR fortran/25059 * gfortran.dg/impure_assignment_1.f90: New test. PR fortran/25070 * gfortran.dg/assumed_shape_ranks_1.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/allocate_char_star_scalar_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/assumed_shape_ranks_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/impure_assignment_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/interface.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/trans-stmt.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25070
[Bug fortran/26038] ICE on allocation of assumed length CHARACTER dummy.
--- Comment #12 from pault at gcc dot gnu dot org 2006-02-13 19:32 --- Subject: Bug 26038 Author: pault Date: Mon Feb 13 19:32:02 2006 New Revision: 110921 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110921 Log: 2006-02-13 Paul Thomas [EMAIL PROTECTED] PR fortran/26038 * trans-stmt.c (gfc_trans_allocate): Provide assumed character length scalar with missing backend_decl for the hidden dummy charlen. PR fortran/25059 * interface.c (gfc_extend_assign): Remove detection of non-PURE subroutine in assignment interface, with gfc_error, and put it in * resolve.c (resolve_code). PR fortran/25070 * interface.c (gfc_procedure_use): Flag rank checking for non- elemental, contained or interface procedures in call to (compare_actual_formal), where ranks are checked for assumed shape arrays.. 2006-02-13 Paul Thomas [EMAIL PROTECTED] PR fortran/26038 * gfortran.dg/allocate_char_star_scalar_1.f90: New test. PR fortran/25059 * gfortran.dg/impure_assignment_1.f90: New test. PR fortran/25070 * gfortran.dg/assumed_shape_ranks_1.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/allocate_char_star_scalar_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/assumed_shape_ranks_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/impure_assignment_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/interface.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/trans-stmt.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26038
[Bug fortran/26038] ICE on allocation of assumed length CHARACTER dummy.
--- Comment #13 from pault at gcc dot gnu dot org 2006-02-13 19:35 --- fixed on trunk and 4.1. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26038
[Bug fortran/25059] ICE after error message
--- Comment #4 from pault at gcc dot gnu dot org 2006-02-13 19:36 --- Fixed on trunk and 4.1. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25059
[Bug fortran/25070] rank mismatch in subroutine call
--- Comment #4 from pault at gcc dot gnu dot org 2006-02-13 19:37 --- Fixed on trunk and 4.1. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25070
[Bug c++/26266] New: ICE
-- Summary: ICE Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: igodard at pacbell dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26266
[Bug c++/26266] ICE
--- Comment #1 from igodard at pacbell dot net 2006-02-13 19:44 --- Created an attachment (id=10840) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10840action=view) compiler output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26266
[Bug c++/26266] ICE
--- Comment #2 from igodard at pacbell dot net 2006-02-13 19:44 --- Created an attachment (id=10841) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10841action=view) source code (compressed) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26266
[Bug rtl-optimization/26254] [4.2 Regression] FAIL: gcc.c-torture/compile/20011109-1.c,-O1
--- Comment #5 from rakdver at gcc dot gnu dot org 2006-02-13 19:53 --- I have submited my patch, as it is useful regardless of whether the new hook will be added or not. I am not sure whether it is reasonable to introduce a new target hook just to handle this special case; if you think so, please submit your patch and we may discuss it in the mailing list. -- rakdver at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||02/msg01009.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26254
[Bug c++/26267] New: template function implicity instatiated
While compiling:
templatetypename T
struct Type2Type {
typedef T Type;
};
templateclass T
inline void foo(Type2TypeT const) {
int x = NOT_HERE;
}
int main(int, char *) {
// std::cout Hello world! std::endl;
}
g++ gives an error about NOT_HERE being declared. Rightly so, but the function
`foo' is never called or explicity instantiated, so `foo' should never be
compiled.
From 14.7.1 Implicit instantiation of the ISO C++ standard:
9. An implementation shall not implicitly instantiate a function template,
a member template, a non-virtual member function, a member class or a
static data member of a class template that does not require instantia-
tion.
--
Summary: template function implicity instatiated
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eduffy at gmail dot com
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26267
[Bug c++/26267] template function implicity instatiated
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-13 20:24 --- This has nothing to do with implicity instatiating the template function. NOT_HERE is not dependent so it is looked up as the template function is parsed and not at instatiation time. This is not a bug and this behavior is required by the standard by the non-dependent namelookup. You were looking into the wrong section (I don't have the standard in front of me but IIRC the section is named template lookup rules). -- 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=26267
[Bug c++/26266] ICE
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-13 20:25 --- I should say this is rejected in 4.1.0: ../include/row.hh: In member function rowT::operator const rowconst T() const [with T = unsigned int]: ../include/powerset.hh:1027: instantiated from rowrangeT powersetE, alloc::ranges(rowR) [with R = unsigned int, E = unsigned int, alloc = standardAllocator] ../include/powerset.hh:479: instantiated from powersetE, alloc::powerset(rowR, const allocrangeT ) [with R = unsigned int, E = unsigned int, alloc = standardAllocator] ../include/display.hh:199: instantiated from basicDisplaych, tr::basicDisplay(std::basic_ostream_CharT, _Traits) [with ch = char, tr = std::char_traitschar] ../src/display.cc:8: instantiated from here ../include/row.hh:210: error: conversion from const rangeconst unsigned int* to non-scalar type const rowconst unsigned int requested ../include/powerset.hh: In member function bool powersetE, alloc::insert(rangeU) [with R = wchar_t, E = wchar_t, alloc = standardAllocator]: ../include/powerset.hh:863: instantiated from std::pairtypename powersetE, alloc::iterator, bool powersetE, alloc::insert(const E) [with E = wchar_t, alloc = standardAllocator] ../include/powerset.hh:533: instantiated from powersetE, alloc powersetE, alloc::operator(const E) [with E = wchar_t, alloc = standardAllocator] ../include/display.hh:200: instantiated from basicDisplaych, tr::basicDisplay(std::basic_ostream_CharT, _Traits) [with ch = wchar_t, tr = std::char_traitswchar_t] ../src/display.cc:17: instantiated from here ../include/powerset.hh:889: error: no matching function for call to newRow(int, rangewchar_t) ../include/row.hh: In member function rowvoid::operator rowT() [with T = unsigned int]: ../include/accum.hh:363: instantiated from rowR accumalloc::frameT::space() [with T = unsigned int, alloc = standardAllocator] ../include/accum.hh:250: instantiated from accumalloc::frameT::frame(accumalloc) [with T = unsigned int, alloc = standardAllocator] ../include/powerset.hh:1026: instantiated from rowrangeT powersetE, alloc::ranges(rowR) [with R = unsigned int, E = unsigned int, alloc = standardAllocator] ../include/powerset.hh:479: instantiated from powersetE, alloc::powerset(rowR, const allocrangeT ) [with R = unsigned int, E = unsigned int, alloc = standardAllocator] ../include/display.hh:199: instantiated from basicDisplaych, tr::basicDisplay(std::basic_ostream_CharT, _Traits) [with ch = char, tr = std::char_traitschar] ../src/display.cc:8: instantiated from here ../include/row.hh:786: error: conversion from const rangesize_t* to non-scalar type rowunsigned int requested ../include/row.hh: In member function rowvoid::operator rowT() [with T = char]: ../include/allocator.hh:484: instantiated from void allocatorMixinvoid, D::deallocate(rowvoid) [with D = standardAllocator] ../include/accum.hh:226: instantiated from void accumalloc::spare(rowvoid) [with alloc = standardAllocator] ../include/accum.hh:262: instantiated from accumalloc::frameT::~frame() [with T = rangeunsigned int, alloc = standardAllocator] ../include/powerset.hh:1014: instantiated from rowrangeT powersetE, alloc::ranges(rowR) [with R = unsigned int, E = unsigned int, alloc = standardAllocator] ../include/powerset.hh:479: instantiated from powersetE, alloc::powerset(rowR, const allocrangeT ) [with R = unsigned int, E = unsigned int, alloc = standardAllocator] ../include/display.hh:199: instantiated from basicDisplaych, tr::basicDisplay(std::basic_ostream_CharT, _Traits) [with ch = char, tr = std::char_traitschar] ../src/display.cc:8: instantiated from here ../include/row.hh:786: error: conversion from const rangechar* to non-scalar type rowchar requested ../include/row.hh: In member function rowT::operator const rowconst T() const [with T = wchar_t]: ../include/display.hh:345: instantiated from void basicDisplaych, tr::textBreak() [with ch = wchar_t, tr = std::char_traitswchar_t] ../include/display.hh:157: instantiated from int basicDisplaych, tr::sync() [with ch = wchar_t, tr = std::char_traitswchar_t] ../include/display.hh:99: instantiated from basicDisplaych, tr::~basicDisplay() [with ch = wchar_t, tr = std::char_traitswchar_t] ../src/display.cc:20: instantiated from here ../include/row.hh:210: error: conversion from const rangeconst wchar_t* to non-scalar type const rowconst wchar_t requested ../include/row.hh: In member function rowT::operator const rowconst T() const [with T = char]: ../include/display.hh:345: instantiated from void basicDisplaych, tr::textBreak() [with ch = char, tr = std::char_traitschar] ../include/display.hh:157: instantiated from int basicDisplaych, tr::sync() [with ch = char, tr = std::char_traitschar] ../include/display.hh:99: instantiated from basicDisplaych, tr::~basicDisplay() [with ch = char, tr = std::char_traitschar] ../src/display.cc:20: instantiated from
[Bug c++/26268] New: template function implicity instatiated
While compiling:
templatetypename T
struct Type2Type {
typedef T Type;
};
templateclass T
inline void foo(Type2TypeT const) {
int x = NOT_HERE;
}
int main(int, char *) {
// std::cout Hello world! std::endl;
}
g++ gives an error about NOT_HERE being declared. Rightly so, but the function
`foo' is never called or explicity instantiated, so `foo' should never be
compiled.
From 14.7.1 Implicit instantiation of the ISO C++ standard:
9. An implementation shall not implicitly instantiate a function template,
a member template, a non-virtual member function, a member class or a
static data member of a class template that does not require instantia-
tion.
--
Summary: template function implicity instatiated
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eduffy at gmail dot com
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26268
[Bug c++/26267] template function implicity instatiated
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-13 20:27 --- *** Bug 26268 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26267
[Bug c++/26268] template function implicity instatiated
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-13 20:27 --- *** This bug has been marked as a duplicate of 26267 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26268
[Bug rtl-optimization/26248] [4.2 regression] sh-elf broken: newlib/libc/misc/dprintf.c int_mode_for_mode ICE loop-invariant
--- Comment #3 from rakdver at gcc dot gnu dot org 2006-02-13 20:27 --- Subject: Bug 26248 Author: rakdver Date: Mon Feb 13 20:27:44 2006 New Revision: 110924 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110924 Log: PR rtl-optimization/26247 PR rtl-optimization/26248 * loop-invariant.c (may_assign_reg_p): Do not allow VOIDmode. Modified: trunk/gcc/ChangeLog trunk/gcc/loop-invariant.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26248
[Bug c++/26266] ICE
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-13 20:29 --- And I should say 4.1.0 is correct to reject this code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26266
[Bug rtl-optimization/26247] [4.2 regression] gcc.dg/tree-ssa/gen-vect-26.c, 28 and 32. int_mode_for_mode ICE strict_low_part loop-invariant
--- Comment #3 from rakdver at gcc dot gnu dot org 2006-02-13 20:27 --- Subject: Bug 26247 Author: rakdver Date: Mon Feb 13 20:27:44 2006 New Revision: 110924 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110924 Log: PR rtl-optimization/26247 PR rtl-optimization/26248 * loop-invariant.c (may_assign_reg_p): Do not allow VOIDmode. Modified: trunk/gcc/ChangeLog trunk/gcc/loop-invariant.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26247
[Bug rtl-optimization/26248] [4.2 regression] sh-elf broken: newlib/libc/misc/dprintf.c int_mode_for_mode ICE loop-invariant
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-13 20:58 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26248
[Bug rtl-optimization/26247] [4.2 regression] gcc.dg/tree-ssa/gen-vect-26.c, 28 and 32. int_mode_for_mode ICE strict_low_part loop-invariant
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-13 20:58 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26247
[Bug fortran/20861] Internal procedure cannot be actual argument
--- Comment #8 from pault at gcc dot gnu dot org 2006-02-13 21:23 --- Subject: Bug 20861 Author: pault Date: Mon Feb 13 21:22:55 2006 New Revision: 110926 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110926 Log: 2006-02-13 Paul Thomas [EMAIL PROTECTED] PR fortran/26074 PR fortran/25103 * resolve.c (resolve_symbol): Extend the requirement that module arrays have constant bounds to those in the main program. At the same time simplify the array bounds, to avoiding trapping parameter array references, and exclude automatic character length from main and modules. Rearrange resolve_symbol and resolve_derived to put as each flavor together, as much as is possible and move all specific code for flavors FL_VARIABLE, FL_PROCEDURE and FL_PARAMETER into new functions. (resolve_fl_var_and_proc, resolve_fl_variable, resolve_fl_procedure): New functions to do work of resolve_symbol. (resolve_index_expr): New function that is called from resolved_symbol and is extracted from resolve_charlen. (resolve_charlen): Call this new function. (resolve_fl_derived): Renamed resolve_derived to be consistent with the naming of the new functions for the other flavours. Change the charlen checking so that the style is consistent with other similar checks. Add the generation of the gfc_dt_list, removed from resolve_ symbol. PR fortran/20861 * resolve.c (resolve_actual_arglist): Prevent internal procedures from being dummy arguments. PR fortran/20871 * resolve.c (resolve_actual_arglist): Prevent pure but non-intrinsic procedures from being dummy arguments. PR fortran/25083 * resolve.c (check_data_variable): Add test that data variable is in COMMON. PR fortran/25088 * resolve.c (resolve_call): Add test that the subroutine does not have a type. 2006-02-13 Paul Thomas [EMAIL PROTECTED] PR fortran/26074 PR fortran/25103 * gfortran.dg/module_parameter_array_refs_1.f90: New test. * gfortran.dg/bad_automatic_objects_1.f90: New test. * gfortran.dg/automatic_module_variable.f90: Change error message. PR fortran/20861 * gfortran.dg/internal_dummy_1.f90: New test. PR fortran/20871 * gfortran.dg/elemental_non_intrinsic_dummy_1.f90: New test. PR fortran/25083 * gfortran.dg/uncommon_block_data_1.f90: New test. * gfortran.dg/equiv_constraint_7.f90: Correct non-compliance of test with standard. PR fortran/25088 * gfortran.dg/typed_subroutine_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/bad_automatic_objects_1.f90 trunk/gcc/testsuite/gfortran.dg/elemental_non_intrinsic_dummy_1.f90 trunk/gcc/testsuite/gfortran.dg/internal_dummy_1.f90 trunk/gcc/testsuite/gfortran.dg/module_parameter_array_refs_1.f90 trunk/gcc/testsuite/gfortran.dg/typed_subroutine_1.f90 trunk/gcc/testsuite/gfortran.dg/uncommon_block_data_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/automatic_module_variable.f90 trunk/gcc/testsuite/gfortran.dg/equiv_constraint_7.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20861
[Bug fortran/26074] Module array cannot be automatic or assumed shape
--- Comment #2 from pault at gcc dot gnu dot org 2006-02-13 21:23 --- Subject: Bug 26074 Author: pault Date: Mon Feb 13 21:22:55 2006 New Revision: 110926 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110926 Log: 2006-02-13 Paul Thomas [EMAIL PROTECTED] PR fortran/26074 PR fortran/25103 * resolve.c (resolve_symbol): Extend the requirement that module arrays have constant bounds to those in the main program. At the same time simplify the array bounds, to avoiding trapping parameter array references, and exclude automatic character length from main and modules. Rearrange resolve_symbol and resolve_derived to put as each flavor together, as much as is possible and move all specific code for flavors FL_VARIABLE, FL_PROCEDURE and FL_PARAMETER into new functions. (resolve_fl_var_and_proc, resolve_fl_variable, resolve_fl_procedure): New functions to do work of resolve_symbol. (resolve_index_expr): New function that is called from resolved_symbol and is extracted from resolve_charlen. (resolve_charlen): Call this new function. (resolve_fl_derived): Renamed resolve_derived to be consistent with the naming of the new functions for the other flavours. Change the charlen checking so that the style is consistent with other similar checks. Add the generation of the gfc_dt_list, removed from resolve_ symbol. PR fortran/20861 * resolve.c (resolve_actual_arglist): Prevent internal procedures from being dummy arguments. PR fortran/20871 * resolve.c (resolve_actual_arglist): Prevent pure but non-intrinsic procedures from being dummy arguments. PR fortran/25083 * resolve.c (check_data_variable): Add test that data variable is in COMMON. PR fortran/25088 * resolve.c (resolve_call): Add test that the subroutine does not have a type. 2006-02-13 Paul Thomas [EMAIL PROTECTED] PR fortran/26074 PR fortran/25103 * gfortran.dg/module_parameter_array_refs_1.f90: New test. * gfortran.dg/bad_automatic_objects_1.f90: New test. * gfortran.dg/automatic_module_variable.f90: Change error message. PR fortran/20861 * gfortran.dg/internal_dummy_1.f90: New test. PR fortran/20871 * gfortran.dg/elemental_non_intrinsic_dummy_1.f90: New test. PR fortran/25083 * gfortran.dg/uncommon_block_data_1.f90: New test. * gfortran.dg/equiv_constraint_7.f90: Correct non-compliance of test with standard. PR fortran/25088 * gfortran.dg/typed_subroutine_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/bad_automatic_objects_1.f90 trunk/gcc/testsuite/gfortran.dg/elemental_non_intrinsic_dummy_1.f90 trunk/gcc/testsuite/gfortran.dg/internal_dummy_1.f90 trunk/gcc/testsuite/gfortran.dg/module_parameter_array_refs_1.f90 trunk/gcc/testsuite/gfortran.dg/typed_subroutine_1.f90 trunk/gcc/testsuite/gfortran.dg/uncommon_block_data_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/automatic_module_variable.f90 trunk/gcc/testsuite/gfortran.dg/equiv_constraint_7.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26074
