[Bug c++/37518] New: preprocessor failure
Platform: Fedora release 8 (Werewolf) Linux chevy.lbl.gov 2.6.23.15-137.fc8 #1 SMP Sun Feb 10 17:03:13 EST 2008 x86_64 x86_64 x86_64 GNU/Linux % g++ -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /net/chevy/raid1/rwgk/gcc_trunk/configure --prefix=/net/cci-filer1/vol1/tmp/rwgk/gcc_trunk_140355_fc8_x86_64 --enable-languages=c,c++,fortran Thread model: posix gcc version 4.4.0 20080914 (experimental) (GCC) % cat boost_mpl_less.cpp #include boost/mpl/less.hpp % g++ -c boost_mpl_less.cpp In file included from /usr/include/boost/mpl/aux_/numeric_op.hpp:22, from /usr/include/boost/mpl/aux_/comparison_op.hpp:27, from /usr/include/boost/mpl/less.hpp:19, from boost_mpl_less.cpp:1: /usr/include/boost/mpl/apply_wrap.hpp:81:31: error: missing binary operator before token ( /usr/include/boost/mpl/apply_wrap.hpp:173:31: error: missing binary operator before token ( In file included from /usr/include/boost/mpl/aux_/numeric_cast_utils.hpp:18, from /usr/include/boost/mpl/aux_/numeric_op.hpp:25, from /usr/include/boost/mpl/aux_/comparison_op.hpp:27, from /usr/include/boost/mpl/less.hpp:19, from boost_mpl_less.cpp:1: /usr/include/boost/mpl/apply_wrap.hpp:81:31: error: missing binary operator before token ( /usr/include/boost/mpl/apply_wrap.hpp:173:31: error: missing binary operator before token ( In file included from /usr/include/boost/mpl/aux_/comparison_op.hpp:27, from /usr/include/boost/mpl/less.hpp:19, from boost_mpl_less.cpp:1: /usr/include/boost/mpl/aux_/numeric_op.hpp:290:31: error: missing binary operator before token ( Observations: g++ -E boost_mpl_less.cpp /dev/null leads to the same error. Many other mpl headers lead to a similar error. Adding -fpermissive doesn't make a difference. Using the boost svn trunk instead of the boost that comes with Fedora 8 leads to the same error. -- Summary: preprocessor failure Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rwgk at yahoo dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37518
Re: [Bug c++/37518] New: preprocessor failure
Sent from my iPhone On Sep 13, 2008, at 11:02 PM, rwgk at yahoo dot com [EMAIL PROTECTED] wrote: Platform: Fedora release 8 (Werewolf) Linux chevy.lbl.gov 2.6.23.15-137.fc8 #1 SMP Sun Feb 10 17:03:13 EST 2008 x86_64 x86_64 x86_64 GNU/Linux % g++ -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /net/chevy/raid1/rwgk/gcc_trunk/configure --prefix=/net/cci-filer1/vol1/tmp/rwgk/gcc_trunk_140355_fc8_x86_64 --enable-languages=c,c++,fortran Thread model: posix gcc version 4.4.0 20080914 (experimental) (GCC) % cat boost_mpl_less.cpp #include boost/mpl/less.hpp % g++ -c boost_mpl_less.cpp In file included from /usr/include/boost/mpl/aux_/numeric_op.hpp:22, from /usr/include/boost/mpl/aux_/comparison_op.hpp:27, from /usr/include/boost/mpl/less.hpp:19, from boost_mpl_less.cpp:1: /usr/include/boost/mpl/apply_wrap.hpp:81:31: error: missing binary operator before token ( What is on that line? I think this is invalid code and there is already a dup of this too. /usr/include/boost/mpl/apply_wrap.hpp:173:31: error: missing binary operator before token ( In file included from /usr/include/boost/mpl/aux_/ numeric_cast_utils.hpp:18, from /usr/include/boost/mpl/aux_/numeric_op.hpp:25, from /usr/include/boost/mpl/aux_/comparison_op.hpp:27, from /usr/include/boost/mpl/less.hpp:19, from boost_mpl_less.cpp:1: /usr/include/boost/mpl/apply_wrap.hpp:81:31: error: missing binary operator before token ( /usr/include/boost/mpl/apply_wrap.hpp:173:31: error: missing binary operator before token ( In file included from /usr/include/boost/mpl/aux_/comparison_op.hpp: 27, from /usr/include/boost/mpl/less.hpp:19, from boost_mpl_less.cpp:1: /usr/include/boost/mpl/aux_/numeric_op.hpp:290:31: error: missing binary operator before token ( Observations: g++ -E boost_mpl_less.cpp /dev/null leads to the same error. Many other mpl headers lead to a similar error. Adding -fpermissive doesn't make a difference. Using the boost svn trunk instead of the boost that comes with Fedora 8 leads to the same error. -- Summary: preprocessor failure Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rwgk at yahoo dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37518
[Bug c++/37518] preprocessor failure
--- Comment #1 from pinskia at gmail dot com 2008-09-14 06:56 --- Subject: Re: New: preprocessor failure Sent from my iPhone On Sep 13, 2008, at 11:02 PM, rwgk at yahoo dot com [EMAIL PROTECTED] wrote: Platform: Fedora release 8 (Werewolf) Linux chevy.lbl.gov 2.6.23.15-137.fc8 #1 SMP Sun Feb 10 17:03:13 EST 2008 x86_64 x86_64 x86_64 GNU/Linux % g++ -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /net/chevy/raid1/rwgk/gcc_trunk/configure --prefix=/net/cci-filer1/vol1/tmp/rwgk/gcc_trunk_140355_fc8_x86_64 --enable-languages=c,c++,fortran Thread model: posix gcc version 4.4.0 20080914 (experimental) (GCC) % cat boost_mpl_less.cpp #include boost/mpl/less.hpp % g++ -c boost_mpl_less.cpp In file included from /usr/include/boost/mpl/aux_/numeric_op.hpp:22, from /usr/include/boost/mpl/aux_/comparison_op.hpp:27, from /usr/include/boost/mpl/less.hpp:19, from boost_mpl_less.cpp:1: /usr/include/boost/mpl/apply_wrap.hpp:81:31: error: missing binary operator before token ( What is on that line? I think this is invalid code and there is already a dup of this too. /usr/include/boost/mpl/apply_wrap.hpp:173:31: error: missing binary operator before token ( In file included from /usr/include/boost/mpl/aux_/ numeric_cast_utils.hpp:18, from /usr/include/boost/mpl/aux_/numeric_op.hpp:25, from /usr/include/boost/mpl/aux_/comparison_op.hpp:27, from /usr/include/boost/mpl/less.hpp:19, from boost_mpl_less.cpp:1: /usr/include/boost/mpl/apply_wrap.hpp:81:31: error: missing binary operator before token ( /usr/include/boost/mpl/apply_wrap.hpp:173:31: error: missing binary operator before token ( In file included from /usr/include/boost/mpl/aux_/comparison_op.hpp: 27, from /usr/include/boost/mpl/less.hpp:19, from boost_mpl_less.cpp:1: /usr/include/boost/mpl/aux_/numeric_op.hpp:290:31: error: missing binary operator before token ( Observations: g++ -E boost_mpl_less.cpp /dev/null leads to the same error. Many other mpl headers lead to a similar error. Adding -fpermissive doesn't make a difference. Using the boost svn trunk instead of the boost that comes with Fedora 8 leads to the same error. -- Summary: preprocessor failure Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rwgk at yahoo dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37518 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37518
[Bug middle-end/37491] [4.4 Regression] Revision 140257 causes vectorizer tests failures
--- Comment #1 from irar at il dot ibm dot com 2008-09-14 07:00 --- I think those loops are not supposed to get vectorized. E.g., in gcc.target/i386/vectorize2.c the store statement b[i_14] = D.1579_6 is not vectorizable because vector long int (the vector type of the statement taken from the type of D.1579_6) does not alias int (the type of b). Since the use of the rhs type seems to be the best solution (for pr 37385) and the alias sets have to be checked (pr 36493), I guess that the tests have to be changed. In gcc.dg/vect/pr36493.c the vectorization check can be simply removed. In the two other tests, changing the type of array b to long will help to vectorize the loops. I think that does not matter for the tests, right? -- irar at il dot ibm dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-14 07:00:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37491
[Bug target/37454] gcc: unrecognized option '-rdynamic'
--- Comment #2 from pluto at agmk dot net 2008-09-14 07:06 --- -rdynamic could be enabled by the --with-gnu-ld configure option. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37454
[Bug c/37506] attribute section is not working with constant strings
--- Comment #6 from nm127 at freemail dot hu 2008-09-14 07:14 --- (In reply to comment #5) This is all expected, if you want a string constant to be in a different section, you need to put there your self by using a variable. So the __attribute__ __section__ modifier is not recursively applied to all child element? If the __attribute__ __section__ is not recursive shouldn't it be possible to specify explicitly this modifier for the child elements something like z and w in comment #4? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37506
[Bug c++/37518] preprocessor failure
--- Comment #2 from rwgk at yahoo dot com 2008-09-14 07:24 --- What is on that line? #elif BOOST_PP_ITERATION_DEPTH() == 1 If you don't have /usr/include/boost, you can get the entire boost tree from here: svn co https://svn.boost.org/svn/boost/trunk boost Then simply compile with -Iboost. I think this is invalid code This boost code is about four years old and compiles with many compilers incl. any other gcc = 3.2 (at least), many EDG versions, and Visual C++ = 6. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37518
[Bug c/37506] attribute section is not working with constant strings
--- Comment #7 from brian at dessent dot net 2008-09-14 07:54 ---
Subject: Re: attribute section is not working with constant strings
If you want a struct containing a pointer to a string in a specified
section, then:
char str[] __attribute__ ((__section__(.xxx_section))) = foo;
struct foo {
char *p
} var = { str };
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37506
[Bug tree-optimization/37482] [4.4 Regression] definition in block 51 follows the use for SSA_NAME with -maltivec
-- irar at il dot ibm dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |irar at il dot ibm dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-09-11 20:30:49 |2008-09-14 07:57:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37482
[Bug preprocessor/36453] PR36320 breaks boost
--- Comment #5 from schwab at suse dot de 2008-09-14 08:08 --- *** Bug 37518 has been marked as a duplicate of this bug. *** -- schwab at suse dot de changed: What|Removed |Added CC||rwgk at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36453
[Bug c++/37518] preprocessor failure
--- Comment #3 from schwab at suse dot de 2008-09-14 08:08 --- *** This bug has been marked as a duplicate of 36453 *** -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37518
[Bug c/37519] New: confusing error message about attribute section name type
When compiling the following (bad) code with gcc 4.4.0 20080912 I get an error
message.
int x __attribute__ ((__section__(1)));
int main() {
return 0;
}
The error message is:
test.c:2: error: section attribute not allowed for 'x'
The problem is really that the __section__ should have string parameter and not
a number (1). I expect an error message like this:
test7.c:2: error: section attribute name must be string for 'x'
--
Summary: confusing error message about attribute section name
type
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nm127 at freemail dot hu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37519
[Bug c++/37057] 7 Internal Compiler Errors when compiling OpenFOAM-1.5
--- Comment #12 from hubicka at ucw dot cz 2008-09-14 09:18 --- Subject: Re: 7 Internal Compiler Errors when compiling OpenFOAM-1.5 Honza, I may not be analyzing this correctly, but it looks like cgraph_remove_unreachable_nodes() may be removing something that is not dead. Is cgraph handling constructors and destructors on non-ELF systems correctly? It ought to be. I.e. as long as I remember, the constructors either appear local but have DECL_STATIC_CONSTRUCTOR on ELF or they are externally visible functions with specially mangled names. Perhaps there is yet another way to handle it? They should be recognized by decide_is_function_needed predicate in cgraphunit.c Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37057
[Bug c++/37057] 7 Internal Compiler Errors when compiling OpenFOAM-1.5
--- Comment #13 from hubicka at ucw dot cz 2008-09-14 09:24 --- Subject: Re: 7 Internal Compiler Errors when compiling OpenFOAM-1.5 Looking at the log, it seems to be another leak where multiple declarations points to single struct function. This is of course quite evil bug with various side effects (surprisingly often the sharing just works, but it is always memory leak and tends to break various targets), we had instance of it already in IPCP versioning and template instantiation. THis is why I added explicit ggc_free in cgraph code now. I am just leaving for US trip, so I am not sure how soon I will be able to look, but debugging is quite easy. You figure out the shared decls (i.e. one is in the backtrace where garbagecollector crashes, other is the one we call ggc_free on the struct function when removing it). Then breakpoint on the end of ggc_page with condition of result being either of those addresses to see who builds them and the second one is the wrong copy. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37057
[Bug middle-end/37491] [4.4 Regression] Revision 140257 causes vectorizer tests failures
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-09-14 09:32 --- I don't follow. For vectorize2.c we have b[i] = lrint (a[i]); where we should be able to vectorize this using lrint vectorization and a scalar long - int conversion (which is a no-op on i686 and should be vectorized on x86_64). There is no aliasing issue involved here. But yes, the testcase should be changed to actually check something more meaningful than one or more cvtpd2dq instructions. Same for vectorize3.c. The loop in pr36493.c should also be vectorizable, there isn't any alias problem there. Oh well, I guess the alias check logic in the vectorizer is still bogus. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37491
[Bug c/37519] confusing error message about attribute section name type
--- Comment #1 from nm127 at freemail dot hu 2008-09-14 09:18 --- Created an attachment (id=16317) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16317action=view) add a new error message for attribute section parameter type check This patch separates the type check of the attribute section. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37519
[Bug fortran/36214] Wrong simplification of BOZ constants
--- Comment #9 from domob at gcc dot gnu dot org 2008-09-14 09:59 --- Subject: Bug 36214 Author: domob Date: Sun Sep 14 09:57:50 2008 New Revision: 140358 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140358 Log: 2008-09-11 Daniel Kraft [EMAIL PROTECTED] PR fortran/36214 * simplify.c (simplify_cmplx): Added linebreak to long line. * target-memory.c (gfc_convert_boz): Fix indentation. (gfc_interpret_float): Set mpfr precision to right value before calling mpfr_init. 2008-09-11 Daniel Kraft [EMAIL PROTECTED] PR fortran/36214 * gfortran.dg/boz_9.f90: Corrected test. * gfortran.dg/boz_11.f90: New test. * gfortran.dg/boz_12.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/boz_11.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/boz_12.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/simplify.c branches/gcc-4_3-branch/gcc/fortran/target-memory.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/boz_9.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36214
[Bug fortran/37498] [4.4 Regression] Incorrect array value returned
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37498
[Bug fortran/36214] Wrong simplification of BOZ constants
--- Comment #10 from domob at gcc dot gnu dot org 2008-09-14 10:02 --- Fixed for trunk (4.4) and 4.3. -- domob at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36214
[Bug rtl-optimization/37514] [4.4 Regression] Wrong code generated for 20021120-1.c with -O3 -fomit-frame-pointer on sh4
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37514
[Bug middle-end/37491] [4.4 Regression] Revision 140257 causes vectorizer tests failures
--- Comment #3 from irar at il dot ibm dot com 2008-09-14 10:04 ---
(In reply to comment #2)
I don't follow. For vectorize2.c we have
b[i] = lrint (a[i]);
where we should be able to vectorize this using lrint vectorization and
a scalar long - int conversion (which is a no-op on i686 and should be
vectorized on x86_64). There is no aliasing issue involved here.
I am working on x86_64 using -m32 (without -m32 I get
../../gcc.target/i386/vectorize2.c:15: note: function is not vectorizable.
../../gcc.target/i386/vectorize2.c:15: note: not vectorized: relevant stmt not
supported: D.1603_6 = lrint (D.1602_5); ).
I don't see any conversion:
foo ()
{
unsigned int ivtmp.65;
int pretmp.55;
double pretmp.54;
int i;
long int D.1579;
double D.1578;
bb 2:
bb 3:
# i_14 = PHI i_7(4), 0(2)
# ivtmp.65_13 = PHI ivtmp.65_12(4), 256(2)
D.1578_5 = a[i_14];
D.1579_6 = lrint (D.1578_5);
b[i_14] = D.1579_6;
i_7 = i_14 + 1;
ivtmp.65_12 = ivtmp.65_13 - 1;
if (ivtmp.65_12 != 0)
goto bb 4;
else
goto bb 5;
bb 4:
goto bb 3;
bb 5:
return;
}
The vectorized version (if the alias check is removed) is:
...
vector long int * ivtmp.120;
vector long int vect_var_.113;
...
vect_var_.111_20 = *ivtmp.110_18;
ivtmp.110_21 = ivtmp.110_18 + 16;
vect_var_.112_22 = *ivtmp.110_21;
vect_var_.113_23 = __builtin_ia32_vec_pack_sfix (vect_var_.111_20,
vect_var_.112_22);
*ivtmp.120_26 = vect_var_.113_23;
The alias check is for the store, checking *ivtmp.120_26 and b.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37491
[Bug c/37519] confusing error message about attribute section name type
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-09-14 10:09 --- Confirmed. -- rguenth 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 |2008-09-14 10:09:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37519
[Bug middle-end/37491] [4.4 Regression] Revision 140257 causes vectorizer tests failures
--- Comment #4 from rguenther at suse dot de 2008-09-14 10:36 ---
Subject: Re: [4.4 Regression] Revision 140257 causes
vectorizer tests failures
On Sun, 14 Sep 2008, irar at il dot ibm dot com wrote:
--- Comment #3 from irar at il dot ibm dot com 2008-09-14 10:04 ---
(In reply to comment #2)
I don't follow. For vectorize2.c we have
b[i] = lrint (a[i]);
where we should be able to vectorize this using lrint vectorization and
a scalar long - int conversion (which is a no-op on i686 and should be
vectorized on x86_64). There is no aliasing issue involved here.
I am working on x86_64 using -m32 (without -m32 I get
../../gcc.target/i386/vectorize2.c:15: note: function is not vectorizable.
../../gcc.target/i386/vectorize2.c:15: note: not vectorized: relevant stmt not
supported: D.1603_6 = lrint (D.1602_5); ).
I don't see any conversion:
Indeed, the conversion is for the 64bit case:
D.1614_6 = lrint (D.1613_5);
D.1615_7 = (int) D.1614_6;
but yes, we cannot vectorize lrint if the result is 64bit long
(which it is on 64bit).
For the 32bit case the problem is really the choice of the vector
type for the store (where is this decided on?). As the type of
b is int it should have chosen vector int instead of vector long.
Note that it is perfectly valid (on 32bit) to assign a vector long
to a vector int. So with a change like
The vectorized version (if the alias check is removed) is:
...
vector long int * ivtmp.120;
vector int * ivtmp.120;
vector long int vect_var_.113;
...
vect_var_.111_20 = *ivtmp.110_18;
ivtmp.110_21 = ivtmp.110_18 + 16;
vect_var_.112_22 = *ivtmp.110_21;
vect_var_.113_23 = __builtin_ia32_vec_pack_sfix (vect_var_.111_20,
vect_var_.112_22);
*ivtmp.120_26 = vect_var_.113_23;
The alias check is for the store, checking *ivtmp.120_26 and b.
the alias check would be fine.
So,
/* The type of the vector store is determined by the rhs. */
vectype = get_vectype_for_scalar_type (TREE_TYPE (op));
the type should be determined by the lhs (after all we try to check
if the new vector lhs aliases the old scalar lhs). But of course
this means the vector lhs type should be chosen to actually match
the scalar type of the lhs.
if (!useless_type_conversion_p (TREE_TYPE (op), TREE_TYPE
(scalar_dest)))
{
if (vect_print_dump_info (REPORT_DETAILS))
fprintf (vect_dump, operands of different types);
return false;
}
This test should then be adjusted to check
if (!useless_type_conversion_p (TREE_TYPE (TREE_TYPE
(vectype)), TREE_TYPE (op)))
first, it was the wrong way around, second we should check if the
conversion from the rhs (op) to the element type of the lhs
vector type (vectype) is useless.
Now the interesting part is of course where we select the type
for the induction variable for the store (I can't find this
atm).
Hope this helps,
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37491
[Bug rtl-optimization/37512] Useless instructions in member call by pointer
--- Comment #2 from 9ugsa9j02 at sneakemail dot com 2008-09-14 11:17 --- Subject: Re: Useless instructions in member call by pointer pinskia at gcc dot gnu dot org gcc-bugzilla-at-gcc.gnu.org |Forums| wrote: --- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-14 02:01 --- Fixed on the trunk by the new register allocator (IRA): __Z6callfnP1AMS_FvvE: LFB0: pushq %rbp LCFI0: testb $1, %sil movq%rsi, %r11 movq%rsp, %rbp LCFI1: movq%rsi, -16(%rbp) --- ? movq%rdx, -8(%rbp)--- ? je L3 movq(%rdi,%rdx), %rax movq-1(%rsi,%rax), %r11 L3: addq%rdx, %rdi leave jmp *%r11 Ok, so that fixes the extra register store. Why is it still creating a stack temporary? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37512
[Bug middle-end/37491] [4.4 Regression] Revision 140257 causes vectorizer tests failures
--- Comment #5 from irar at il dot ibm dot com 2008-09-14 12:05 ---
(In reply to comment #4)
For the 32bit case the problem is really the choice of the vector
type for the store (where is this decided on?). As the type of
b is int it should have chosen vector int instead of vector long.
Now I am completely confused. The decision to base the type of the store on the
rhs was made to fix pr 37385
(http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00674.html). Without it, there
is ICE in set_mem_alias_set...
Vector pointers are created in vect_create_data_ref_ptr. When called from
vectorizable_store, it gets the type of vectorized rhs and creates a vector
pointer of that type (this was the patch for pr 37385).
Note that it is perfectly valid (on 32bit) to assign a vector long
to a vector int. So with a change like
The vectorized version (if the alias check is removed) is:
...
vector long int * ivtmp.120;
vector int * ivtmp.120;
vector long int vect_var_.113;
...
vect_var_.111_20 = *ivtmp.110_18;
ivtmp.110_21 = ivtmp.110_18 + 16;
vect_var_.112_22 = *ivtmp.110_21;
vect_var_.113_23 = __builtin_ia32_vec_pack_sfix (vect_var_.111_20,
vect_var_.112_22);
*ivtmp.120_26 = vect_var_.113_23;
The alias check is for the store, checking *ivtmp.120_26 and b.
the alias check would be fine.
This part I do understand ;)
So,
/* The type of the vector store is determined by the rhs. */
vectype = get_vectype_for_scalar_type (TREE_TYPE (op));
the type should be determined by the lhs
not if we base the vectype on the scalar type of the rhs...
(after all we try to check
if the new vector lhs aliases the old scalar lhs). But of course
this means the vector lhs type should be chosen to actually match
the scalar type of the lhs.
if (!useless_type_conversion_p (TREE_TYPE (op), TREE_TYPE
(scalar_dest)))
{
if (vect_print_dump_info (REPORT_DETAILS))
fprintf (vect_dump, operands of different types);
return false;
}
This test should then be adjusted to check
if (!useless_type_conversion_p (TREE_TYPE (TREE_TYPE
(vectype)), TREE_TYPE (op)))
first, it was the wrong way around, second we should check if the
conversion from the rhs (op) to the element type of the lhs
vector type (vectype) is useless.
Do you mean
if (!useless_type_conversion_p (TREE_TYPE (scalar_dest), TREE_TYPE (op)))?
If vectype is built based on TREE_TYPE (scalar_dest) it should be the same, no?
Now the interesting part is of course where we select the type
for the induction variable for the store (I can't find this
atm).
Isn't it ivtmp.120_26 itself? (The updating of vector pointers is done in
vect_create_data_ref_ptr as well).
Thanks,
Ira
Hope this helps,
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37491
[Bug fortran/37498] [4.4 Regression] Incorrect array value returned
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2008-09-14 12:11 --- See http://gcc.gnu.org/ml/fortran/2008-09/msg00259.html for start of patch and request for comments. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37498
[Bug fortran/36700] [4.3/4.4 Regression] ICE on calling a function
--- Comment #4 from pault at gcc dot gnu dot org 2008-09-14 12:13 --- This is caused by my fix for the regression PR32526 and the fix for PR31494. I completely overlooked the possibility that folk might CALL functions:-) I have a prospective fix in gfc_match_call:2545, which is where the trouble starts; add a !sym-attr.function to the if statement. The confusion between function and subroutine gets patched up in resolution. I'm not in a position to either regtest or commit until Thursday. If anybody feels the need to do either before then, feel free! Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-07-02 18:10:59 |2008-09-14 12:13:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36700
[Bug target/24894] ICE building newlib/libc/misc/init.c
--- Comment #5 from aesok at gcc dot gnu dot org 2008-09-14 12:51 --- Subject: Bug 24894 Author: aesok Date: Sun Sep 14 12:50:10 2008 New Revision: 140360 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140360 Log: PR target/19636 PR target/24894 PR target/31644 PR target/31786 * config/avr/avr.c (legitimate_address_p): Fix problem where subreg is not recognized as a valid register usage. Allow REG_X to be used as a base pointer. * config/avr/avr.h (LEGITIMIZE_RELOAD_ADDRESS): Remove code that forces a reload when using a base register. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24894
[Bug target/31644] [avr] can't find a register in class 'BASE_POINTER_REGS' while reloading 'asm'
--- Comment #9 from aesok at gcc dot gnu dot org 2008-09-14 12:51 --- Subject: Bug 31644 Author: aesok Date: Sun Sep 14 12:50:10 2008 New Revision: 140360 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140360 Log: PR target/19636 PR target/24894 PR target/31644 PR target/31786 * config/avr/avr.c (legitimate_address_p): Fix problem where subreg is not recognized as a valid register usage. Allow REG_X to be used as a base pointer. * config/avr/avr.h (LEGITIMIZE_RELOAD_ADDRESS): Remove code that forces a reload when using a base register. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31644
[Bug target/31786] [4.2/4.3/4.4 Regression][avr] error: unable to find a register to spill in class 'BASE_POINTER_REGS'
--- Comment #17 from aesok at gcc dot gnu dot org 2008-09-14 12:51 --- Subject: Bug 31786 Author: aesok Date: Sun Sep 14 12:50:10 2008 New Revision: 140360 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140360 Log: PR target/19636 PR target/24894 PR target/31644 PR target/31786 * config/avr/avr.c (legitimate_address_p): Fix problem where subreg is not recognized as a valid register usage. Allow REG_X to be used as a base pointer. * config/avr/avr.h (LEGITIMIZE_RELOAD_ADDRESS): Remove code that forces a reload when using a base register. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31786
[Bug target/19636] [4.2 regression] Can't compile large switch statement
--- Comment #23 from aesok at gcc dot gnu dot org 2008-09-14 12:51 --- Subject: Bug 19636 Author: aesok Date: Sun Sep 14 12:50:10 2008 New Revision: 140360 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140360 Log: PR target/19636 PR target/24894 PR target/31644 PR target/31786 * config/avr/avr.c (legitimate_address_p): Fix problem where subreg is not recognized as a valid register usage. Allow REG_X to be used as a base pointer. * config/avr/avr.h (LEGITIMIZE_RELOAD_ADDRESS): Remove code that forces a reload when using a base register. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19636
[Bug middle-end/37491] [4.4 Regression] Revision 140257 causes vectorizer tests failures
--- Comment #6 from rguenther at suse dot de 2008-09-14 12:53 ---
Subject: Re: [4.4 Regression] Revision 140257 causes
vectorizer tests failures
On Sun, 14 Sep 2008, irar at il dot ibm dot com wrote:
--- Comment #5 from irar at il dot ibm dot com 2008-09-14 12:05 ---
(In reply to comment #4)
For the 32bit case the problem is really the choice of the vector
type for the store (where is this decided on?). As the type of
b is int it should have chosen vector int instead of vector long.
Now I am completely confused. The decision to base the type of the store on
the
rhs was made to fix pr 37385
(http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00674.html). Without it, there
is ICE in set_mem_alias_set...
Sorry, I probably didn't look too closely when reviewing this patch.
Vector pointers are created in vect_create_data_ref_ptr. When called from
vectorizable_store, it gets the type of vectorized rhs and creates a vector
pointer of that type (this was the patch for pr 37385).
The sanity checking should forgive any wrong decision we make there,
still basing it on the lhs looks more correct. I will have a look
myself. The important thing is to make both the creation and
the check consistent of course.
I see vect_create_data_ref_ptr is getting the type to use passed
in case of stores and this is TREE_TYPE (vec_oprnd) - is vec_oprnd
the lhs or the rhs? It looks like it is the rhs which may explain
the ICE for PR37385, we should use the vector type according
to the lhs here (maybe passing NULL to vect_create_data_ref_ptr
will do this - dependend on how STMT_VINFO_VECTYPE is set for
stores).
Note that it is perfectly valid (on 32bit) to assign a vector long
to a vector int. So with a change like
The vectorized version (if the alias check is removed) is:
...
vector long int * ivtmp.120;
vector int * ivtmp.120;
vector long int vect_var_.113;
...
vect_var_.111_20 = *ivtmp.110_18;
ivtmp.110_21 = ivtmp.110_18 + 16;
vect_var_.112_22 = *ivtmp.110_21;
vect_var_.113_23 = __builtin_ia32_vec_pack_sfix (vect_var_.111_20,
vect_var_.112_22);
*ivtmp.120_26 = vect_var_.113_23;
The alias check is for the store, checking *ivtmp.120_26 and b.
the alias check would be fine.
This part I do understand ;)
Good ;)
So,
/* The type of the vector store is determined by the rhs. */
vectype = get_vectype_for_scalar_type (TREE_TYPE (op));
the type should be determined by the lhs
not if we base the vectype on the scalar type of the rhs...
(after all we try to check
if the new vector lhs aliases the old scalar lhs). But of course
this means the vector lhs type should be chosen to actually match
the scalar type of the lhs.
if (!useless_type_conversion_p (TREE_TYPE (op), TREE_TYPE
(scalar_dest)))
{
if (vect_print_dump_info (REPORT_DETAILS))
fprintf (vect_dump, operands of different types);
return false;
}
This test should then be adjusted to check
if (!useless_type_conversion_p (TREE_TYPE (TREE_TYPE
(vectype)), TREE_TYPE (op)))
first, it was the wrong way around, second we should check if the
conversion from the rhs (op) to the element type of the lhs
vector type (vectype) is useless.
Do you mean
if (!useless_type_conversion_p (TREE_TYPE (scalar_dest), TREE_TYPE (op)))?
If vectype is built based on TREE_TYPE (scalar_dest) it should be the same,
no?
It should be the same - ideally we'd check the conversion on
both vector types (the lhs and the rhs).
Now the interesting part is of course where we select the type
for the induction variable for the store (I can't find this
atm).
Isn't it ivtmp.120_26 itself? (The updating of vector pointers is done in
vect_create_data_ref_ptr as well).
Yes, looks like vect_create_data_ref_ptr decides if it is not passed
the type (which it is for stores).
I can try to have a look here, but I'm not exactly familiar with
the code (thanks for the pointers ;)), so I'd appreciate if you
try to figure out what it takes to fix vect_create_data_ref_ptr or
its caller.
Thanks,
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37491
[Bug target/31945] missing type vector conversions patterns on spu
--- Comment #1 from ubizjak at gmail dot com 2008-09-14 13:23 --- Confirmed. -- ubizjak at gmail dot com changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-14 13:23:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31945
[Bug target/31945] missing type vector conversions patterns on spu
--- Comment #2 from ubizjak at gmail dot com 2008-09-14 13:29 --- GCC now implements whole lot of vector conversions, including int--float and int--double. See 24659. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31945
[Bug fortran/37507] Print location in (DE)ALLOCATION errors
-- domob at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-09-13 10:09:35 |2008-09-14 13:48:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37507
[Bug fortran/37468] error when combining -i8 with .F files
--- Comment #3 from tkoenig at gcc dot gnu dot org 2008-09-14 14:20 --- I can't find a mention of -i8 in the gfortran documentation. I wonder if it even should work... Confirmed, the current behavior is at least inconsistent. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-14 14:20:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37468
[Bug c++/37057] 7 Internal Compiler Errors when compiling OpenFOAM-1.5
--- Comment #14 from hubicka at gcc dot gnu dot org 2008-09-14 14:31 --- On cross from today tree it seems fine: Starting program: /home/jh/gcc-baseline/build-aix/gcc/cc1plus -O2 *.ii -fpreprocessed -quiet -dumpbase makeChemkinReactions.C -maix32 -auxbase makeChemkinReactions -Wall -Wno-strict-aliasing -Wextra -Wno-unused-parameter -Wold-style-cast -version -ftemplate-depth-40 GNU C++ (GCC) version 4.4.0 20080914 (experimental) (powerpc-ibm-aix5.3.0.0) compiled by GNU C version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21), GMP version 4.2.1, MPFR version 2.2.1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 272438ec7d6ea2c49ce12d5bf798cf01 In file included from lnInclude/TroeFallOffFunction.H:109, from reaction/reactions/makeChemkinReactions.C:37: lnInclude/TroeFallOffFunctionI.H: In member function 'Foam::scalar Foam::TroeFallOffFunction::operator()(Foam::scalar, Foam::scalar) const': lnInclude/TroeFallOffFunctionI.H:75: warning: sorry: semantics of inline function static data 'const Foam::scalar d' are wrong (you'll wind up with multiple copies) lnInclude/TroeFallOffFunctionI.H:75: warning: you can work around this by removing the initializer Perhaps it was fixed by my yesterday commit on DECL_STRUCT_FUNCTION sharing? Or am I doing something wrong? Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37057
[Bug fortran/37468] error when combining -i8 with .F files
--- Comment #4 from dominiq at lps dot ens dot fr 2008-09-14 15:09 --- I am not sure, but I seems to remember a discussion about the fact that -i8 could not be used and -fdefault-integer-8 has been chosen because -i has some meaning after compilation (linker?). Does it ring some bell among the old-timers? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37468
[Bug c++/37057] 7 Internal Compiler Errors when compiling OpenFOAM-1.5
--- Comment #15 from dje at gcc dot gnu dot org 2008-09-14 15:35 --- Honza, I think that your recent pt.c:tsubst_decl() fix coincidentally may have fixed this as well. Tracing the ggc_alloc_stat() calls, struct function only appears to be allocated once, but likely is copied when it should not be. Jørn, Could you try rebuilding GCC 4.3.1 with Honza's patch and report if it fixes your failures? http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00999.html #0 ggc_alloc_stat (size=84) at /farm/dje/src/src/gcc/ggc-page.c:1251 #1 0x100059ac in ggc_alloc_cleared_stat (size=84) at /farm/dje/src/src/gcc/ggc-common.c:132 #2 0x10072b10 in allocate_struct_function (fndecl=0x30119c00, abstract_p=1 '\001') at /farm/dje/src/src/gcc/function.c:3944 #3 0x10562c28 in start_preparsed_function (decl1=0x30119c00, attrs=0x20029648, flags=0) at /farm/dje/src/src/gcc/cp/decl.c:11544 #4 0x10581d78 in start_function (declspecs=0x2006e360, declarator=0x10, attrs=0x0) at /farm/dje/src/src/gcc/cp/decl.c:11727 #5 0x107340e0 in cp_parser_init_declarator (parser=0x304ef230, decl_specifiers=0x2ff21f20, checks=0x0, function_definition_allowed_p=1 '\001', member_p=0 '\0', declares_class_or_enum=806084960, function_definition_p=0x2ff21f18 \001) at /farm/dje/src/src/gcc/cp/parser.c:17371 #6 0x10735bec in cp_parser_single_declaration (parser=0x304ef230, checks=0x0, member_p=0 '\0', explicit_specialization_p=0 '\0', friend_p=0x2ff21fd8 ) at /farm/dje/src/src/gcc/cp/parser.c:17717 #7 0x10735ed4 in cp_parser_template_declaration_after_export ( parser=0x304ef230, member_p=0 '\0') at /farm/dje/src/src/gcc/cp/parser.c:17570 #8 0x1073d484 in cp_parser_declaration (parser=0x304ef230) at /farm/dje/src/src/gcc/cp/parser.c:7885 #9 0x1073da88 in cp_parser_declaration_seq_opt (parser=0x304ef230) at /farm/dje/src/src/gcc/cp/parser.c:7816 #10 0x1073e7d0 in cp_parser_namespace_definition (parser=0x304ef230) at /farm/dje/src/src/gcc/cp/parser.c:12029 #11 0x1073d390 in cp_parser_declaration (parser=0x304ef230) at /farm/dje/src/src/gcc/cp/parser.c:7917 #12 0x1073da88 in cp_parser_declaration_seq_opt (parser=0x304ef230) at /farm/dje/src/src/gcc/cp/parser.c:7816 #13 0x1073e370 in c_parse_file () at /farm/dje/src/src/gcc/cp/parser.c:3031 #14 0x107abf98 in c_common_parse_file (set_yydebug=806760888) at /farm/dje/src/src/gcc/c-opts.c:1239 #15 0x10003800 in toplev_main (argc=537008760, argv=0x109696c0) at /farm/dje/src/src/gcc/toplev.c:968 #16 0x13a0 in main (argc=806760888, argv=0x10) at /farm/dje/src/src/gcc/main.c:35 #17 0x1214 in __start () (gdb) print fndecl $6 = 0x30119c00 (gdb) pt function_decl 30119c00 _M_destroy type method_type 3017ab60 type void_type 300214e0 void type_6 VOID align 8 symtab 0 alias set -1 canonical type 300214e0 pointer_to_this pointer_type 30021548 SI size integer_cst 300073e8 constant 32 unit size integer_cst 300070f0 constant 4 align 32 symtab 0 alias set -1 canonical type 301211a0 method basetype record_type 3011d9c0 _Rep arg-types tree_list 3017b1e0 value pointer_type 30120680 chain tree_list 3017b1a0 value reference_type 3017a958 chain tree_list 30014f60 value void_type 300214e0 void throws tree_list 300b3040 nothrow public static external in_system_header no-static-chain SI file /opt/freeware/lib/gcc/powerpc-ibm-aix5.3.0.0/4.3.1/include/c++/bits/basic_string.tcc line 420 col 42 align 32 context record_type 3011d9c0 _Rep initial error_mark 30014aa0 arguments parm_decl 30171d70 this type pointer_type 301206e8 type record_type 3011d9c0 _Rep readonly unsigned type_0 type_6 SI size integer_cst 300073e8 32 unit size integer_cst 300070f0 4 align 32 symtab 0 alias set -1 canonical type 301206e8 readonly unsigned SI file /opt/freeware/lib/gcc/powerpc-ibm-aix5.3.0.0/4.3.1/include/c++/bits/basic_string.tcc line 420 col 42 size integer_cst 300073e8 32 unit size integer_cst 300070f0 4 align 32 chain parm_decl 30171d20 __a type reference_type 3017a958 unsigned SI file /opt/freeware/lib/gcc/powerpc-ibm-aix5.3.0.0/4.3.1/include/c++/bits/basic_string.tcc line 420 col 30 size integer_cst 300073e8 32 unit size integer_cst 300070f0 4 align 32 result result_decl 30171dc0 D.9306 type void_type 300214e0 void ignored VOID file /opt/freeware/lib/gcc/powerpc-ibm-aix5.3.0.0/4.3.1/include/c++/bits/basic_string.tcc line 420 col 42 align 8 template-info 3017b320 chain function_decl 30119c80 _M_refcopy -- dje at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008-
[Bug bootstrap/37304] [4.4 Regression]: in-tree-binutils gcc configure tests fail because of unexpanded $(objdir)
--- Comment #4 from rwild at gcc dot gnu dot org 2008-09-14 15:37 --- FWIW, this happens inside libtool configure tests, so I guess it is harmless inside gcc/. Do you see this in other directories' configure outputs, too, and if yes, can you post a little more context (esp. the 5 or so lines following what you posted would have been interesting)? -- rwild at gcc dot gnu dot org changed: What|Removed |Added CC||rwild at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37304
[Bug fortran/37468] error when combining -i8 with .F files
--- Comment #5 from dominiq at lps dot ens dot fr 2008-09-14 16:12 --- I have found it: http://gcc.gnu.org/ml/fortran/2005-03/msg00189.html RFC: renaming -i8, -r8, and -d8 From: Steve Kargl sgk at troutmask dot apl dot washington dot edu To: fortran at gcc dot gnu dot org Date: Fri, 11 Mar 2005 11:13:41 -0800 Subject: RFC: renaming -i8, -r8, and -d8 Jim Wilson provided a detail explanation of the GCC options handling scheme in http://gcc.gnu.org/ml/gcc/2005-03/msg00513.html. Because -i*, -r*, and -d* are reserved for preprocessing, linking, and debugging options, respectively, and -f* is specifically reserved for frontend options, I proposal that we rename the -i8, -r8, and -d8 options to -fi8, -fr8, and -fd8. These options can also have long form aliases. I also proposal the following semantics for these options. ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37468
[Bug fortran/35840] ICE for character expression in I/O specifier
--- Comment #4 from mikael dot morin at tele2 dot fr 2008-09-14 16:42 --- Created an attachment (id=16318) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16318action=view) proposed patch The problem here is that the parser matches a general expression and has to check later that it is an initialization expression. I have taken the code in gfc_match_init_expr and put it in its own function (gfc_reduce_init_expr) so that checking can be deferred. Fixing the bug is then trivial. This has just been regression tested. Should I send this to the fortran mailing list ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35840
[Bug fortran/35840] ICE for character expression in I/O specifier
--- Comment #5 from domob at gcc dot gnu dot org 2008-09-14 16:51 --- Yes, that's probably the best to get comments/reviews for your patch; if you think it is already mature, CC [EMAIL PROTECTED], too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35840
[Bug c++/37057] 7 Internal Compiler Errors when compiling OpenFOAM-1.5
--- Comment #16 from jorn dot amundsen at ntnu dot no 2008-09-14 17:11 --- (In reply to comment #15) With 4.3.2, and by uncommenting a superfluous third party package, I am down at 4 ICE's. The makeChemkinReactions ICE is still present with 4.3.2, though. Now, since cp/pt.c are identical in 4.3.1 and 4.3.2 I patched and started a recompile of the official 4.3.2 release sources. I hope this is ok. The build needs 4 hrs to complete. Of course, if there is nothing to gain by patching 4.3.2, I will revert to 4.3.1. --joern Honza, I think that your recent pt.c:tsubst_decl() fix coincidentally may have fixed this as well. Tracing the ggc_alloc_stat() calls, struct function only appears to be allocated once, but likely is copied when it should not be. Jørn, Could you try rebuilding GCC 4.3.1 with Honza's patch and report if it fixes your failures? http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00999.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37057
[Bug fortran/35840] ICE for character expression in I/O specifier
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2008-09-14 17:58 --- I see that I did not use RESOLVE_TAG in gfc_resolve_dt. Doing so resolves the ICE issue. Then if we really want to accept this poorly written code, I think the place to fix it may be in io.c (resolve_tag) @@ -2481,6 +2483,7 @@ gfc_resolve_dt (gfc_dt *dt) RESOLVE_TAG (tag_e_round, dt-round); RESOLVE_TAG (tag_e_blank, dt-blank); RESOLVE_TAG (tag_e_decimal, dt-decimal); + RESOLVE_TAG (tag_e_async, dt-asynchronous); e = dt-io_unit; if (gfc_resolve_expr (e) == SUCCESS -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35840
[Bug fortran/37497] Fortran openMP compiler error: Segmentation fault
-- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37497
[Bug fortran/35840] ICE for character expression in I/O specifier
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2008-09-14 19:01 --- Subject: Bug 35840 Author: jvdelisle Date: Sun Sep 14 19:00:26 2008 New Revision: 140366 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140366 Log: 2008-09-14 Jerry DeLisle [EMAIL PROTECTED] Tobias Burnus [EMAIL PROTECTED] PR fortran/35840 * io.c (match_vtag): Add tag name to error message. (match_out_tag): Cleanup whitespace. (gfc_resolve_dt): Resolve id and async tags. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35840
[Bug fortran/34554] time compiling complicated size initialization expression
--- Comment #3 from dominiq at lps dot ens dot fr 2008-09-14 19:09 ---
On a Core2 2.1Ghz, the original code gives
[ibook-dhum] f90/bug% time gfc pr34554.f90
193.792u 0.273s 3:14.46 99.7% 0+0k 0+27io 0pf+0w
[ibook-dhum] f90/bug% time a.out
152 135210384
0.000u 0.001s 0:00.00 0.0% 0+0k 0+2io 0pf+0w
The following code where the PARAMETERs have been removed
program sum_f95
implicit none
integer i, j
integer n, iv1
n = 152
iv1 = size([([('',i=1,j**3)],j=1,n)])
write(*,*) n, iv1
end program sum_f95
gives
[ibook-dhum] f90/bug% time gfc pr34554_2_db.f90
0.027u 0.022s 0:00.08 50.0% 0+0k 0+15io 0pf+0w
[ibook-dhum] f90/bug% time a.out
152 135210384
0.745u 0.637s 0:01.38 99.2% 0+0k 0+0io 0pf+0w
So using parameters give a runtime speedup at the expense of a very long
compilation time. However is it reasonable that the computation of
size([([('',i=1,j**3)],j=1,n)]) be almost 200 times slower when done by the
compiler?
For the original test, the compile times for different n are
n=52
2.736u 0.024s 0:02.76 99.6% 0+0k 0+26io 0pf+0w
n=102
39.522u 0.079s 0:39.79 99.4%0+0k 0+12io 0pf+0w
n=152
193.792u 0.273s 3:14.46 99.7% 0+0k 0+27io 0pf+0w
So the compilation time is O(n^4).
For the second test, the runtimes are
n=52
0.013u 0.011s 0:00.02 100.0%0+0k 0+0io 0pf+0w
n=102
0.155u 0.139s 0:00.29 96.5% 0+0k 0+0io 0pf+0w
n=152
0.745u 0.637s 0:01.38 99.2% 0+0k 0+0io 0pf+0w
So the execution time is also O(n^4), but the prefactor is two order of
magnitude larger at compile time (it means that you have to run the same code
200 times to have a real benefit on the total compile+execution time).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34554
[Bug c++/37057] 7 Internal Compiler Errors when compiling OpenFOAM-1.5
--- Comment #17 from dje at gcc dot gnu dot org 2008-09-14 19:52 --- Because the problem is due to garbage collection, it is non-deterministic, depending on what data GCC generates. I was able to reproduce the problem in a recent development version of GCC, prior to Honza's patch, but not in my installed version of GCC 4.3.1, which is why I asked you to confirm that the patch fixes the problem for you. GCC 4.3.2 fixes numerous bugs over GCC 4.3.1, although not necessarily ICEs that affect you. I would recommend using a patched version of GCC 4.3.2 over a patched version of GCC 4.3.1, but that is your decision. -- dje at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING Target Milestone|--- |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37057
[Bug target/37520] New: junk `(,%eax,4)' after expression / suffix or operands invalid for `lea' for libstdc++ deque/init-list.cc
Looking at my testsuite runs on i386-unknown-freebsd6.3 I noticed the following testsuite failure. FAIL: 23_containers/deque/init-list.cc (test for excess errors) Excess errors: /var/tmp//ccHEu2Vp.s:5429: Error: junk `(,%eax,4)' after expression /var/tmp//ccHEu2Vp.s:5429: Error: suffix or operands invalid for `lea' I'll attach *.ii and *.s files in a minute. -- Summary: junk `(,%eax,4)' after expression / suffix or operands invalid for `lea' for libstdc++ deque/init-list.cc Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gerald at pfeifer dot com GCC host triplet: i386-unknown-freebsd6.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37520
[Bug target/37520] junk `(,%eax,4)' after expression / suffix or operands invalid for `lea' for libstdc++ deque/init-list.cc
--- Comment #1 from gerald at pfeifer dot com 2008-09-14 20:47 --- Created an attachment (id=16319) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16319action=view) init-list.ii -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37520
[Bug target/37520] junk `(,%eax,4)' after expression / suffix or operands invalid for `lea' for libstdc++ deque/init-list.cc
--- Comment #2 from gerald at pfeifer dot com 2008-09-14 20:47 --- Created an attachment (id=16320) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16320action=view) init-list.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37520
[Bug target/37521] New: Building of GCC fails with internal compiler error for target AVR
Since revision 139590 (including) GCC fails to build successfully. Revision
139589 can be built successfully with the same configuration.
Configuration:
../trunk/configure --prefix=/usr/local/avr --target=avr
--enable-languages=c,c++ --disable-nls --disable-libssp --with-dwarf2
Output when running make:
.
.
.
make[4]: Entering directory `/home/tuomas/avr/gcc/build/avr/avr25/libgcc'
# If this is the top-level multilib, build all the other
# multilibs.
/home/tuomas/avr/gcc/build/./gcc/xgcc -B/home/tuomas/avr/gcc/build/./gcc/
-B/usr/local/avr/avr/bin/ -B/usr/local/avr/avr/lib/ -isystem
/usr/local/avr/avr/include -isystem /usr/local/avr/avr/sys-include -g -O2
-mmcu=avr25 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
-Wold-style-definition -isystem ./include -DDF=SF -Dinhibit_libc
-mcall-prologues -Os -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc
-I. -I. -I../../.././gcc -I../../../../trunk/libgcc
-I../../../../trunk/libgcc/. -I../../../../trunk/libgcc/../gcc
-I../../../../trunk/libgcc/../include -DHAVE_CC_TLS -o _mulsc3.o -MT _mulsc3.o
-MD -MP -MF _mulsc3.dep -DL_mulsc3 -c ../../../../trunk/libgcc/../gcc/libgcc2.c
\
../../../../trunk/libgcc/../gcc/libgcc2.c: In function '__mulsc3':
../../../../trunk/libgcc/../gcc/libgcc2.c:1890: error: unable to find a
register to spill in class 'BASE_POINTER_REGS'
../../../../trunk/libgcc/../gcc/libgcc2.c:1890: error: this is the insn:
(insn 2450 1710 2451 4 ../../../../trunk/libgcc/../gcc/libgcc2.c:1851 (set
(mem/c:QI (plus:HI (reg/f:HI 28 r28)
(const_int 37 [0x25])) [31 S1 A8])
(reg:QI 30 r30)) 4 {*movqi} (nil))
../../../../trunk/libgcc/../gcc/libgcc2.c:1890: internal compiler error: in
spill_failure, at reload1.c:2098
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
make[4]: *** [_mulsc3.o] Error 1
make[4]: Leaving directory `/home/tuomas/avr/gcc/build/avr/avr25/libgcc'
.
.
.
--
Summary: Building of GCC fails with internal compiler error for
target AVR
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tuomas dot pennanen at pp dot inet dot fi
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: avr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37521
[Bug fortran/35840] ICE for character expression in I/O specifier
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2008-09-14 21:29 --- Patch committed in Comment #7 only eliminates the ICE. Reduction of the initialization expression remains. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35840
[Bug c++/37057] 7 Internal Compiler Errors when compiling OpenFOAM-1.5
--- Comment #18 from jorn dot amundsen at ntnu dot no 2008-09-14 22:01 --- (In reply to comment #17) I tried with a patched 4.3.2, and it does unfortunately *not* fix the problem. The compiler line (as read from -###) results in: $ /opt/freeware/libexec/gcc/powerpc-ibm-aix5.3.0.0/4.3.2/cc1plus -fpreprocessed chemkinReader.ii -quiet -dumpbase chemkinReader.ii -auxbase chemkinReader -o chemkinReader.s chemkinReader.ii: In member function 'void Foam::chemkinReader::addReactionType(Foam::chemkinReader::reactionType, Foam::DynamicListFoam::ReactionFoam::sutherlandTransportFoam::specieThermoFoam::janafThermoFoam::perfectGas ::specieCoeffs, 0u, 2u, 1u, Foam::DynamicListFoam::ReactionFoam::sutherlandTransportFoam::specieThermoFoam::janafThermoFoam::perfectGas ::specieCoeffs, 0u, 2u, 1u, const ReactionRateType) [with ReactionRateType = Foam::FallOffReactionRateFoam::ArrheniusReactionRate, Foam::LindemannFallOffFunction]': chemkinReader.ii:91089: 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. I could patch and recompile 4.3.1 if you think this might be useful. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37057
[Bug libstdc++/37522] New: [4.4 regression] Incorrect vswprintf prototype breaks __to_xstring
When attempting a bootstrap including libstdc++-v3, the following error will be encountered. libtool: compile: /mingw/src/gccf/./gcc/xgcc -shared-libgcc -B/mingw/src/gccf/./gcc -nostdinc++ -L/mingw/src/gccf/i386-pc-mingw32/libstdc++-v3/src -L/mingw/src/gccf/i386-pc-mingw32/libstdc++-v3/src/.libs -L/mingw/src/gccf/i386-pc-mingw32/winsup/mingw -L/mingw/src/gccf/i386-pc-mingw32/winsup/w32api/lib -isystem /mingw/src/svn/winsup/mingw/include -isystem /mingw/src/svn/winsup/w32api/include -B/mingw/i386-pc-mingw32/bin/ -B/mingw/i386-pc-mingw32/lib/ -isystem /mingw/i386-pc-mingw32/include -isystem /mingw/i386-pc-mingw32/sys-include -I/mingw/src/gccf/i386-pc-mingw32/libstdc++-v3/include/i386-pc-mingw32 -I/mingw/src/gccf/i386-pc-mingw32/libstdc++-v3/include -I/mingw/src/svn/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -std=gnu++0x -c ../../../../svn/libstdc++-v3/src/functexcept.cc -DDLL_EXPORT -DPIC -o .libs/functexcept.o In file included from /mingw/src/gccf/i386-pc-mingw32/libstdc++-v3/include/string:58, from /mingw/src/gccf/i386-pc-mingw32/libstdc++-v3/include/stdexcept:44, from ../../../../svn/libstdc++-v3/src/functexcept.cc:31: /mingw/src/gccf/i386-pc-mingw32/libstdc++-v3/include/bits/basic_string.h: In function 'std::wstring std::to_wstring(long long int)': /mingw/src/gccf/i386-pc-mingw32/libstdc++-v3/include/bits/basic_string.h:2675: error: no matching function for call to '__to_xstring(int (*)(wchar_t*, const wchar_t*, char*), unsigned int, const wchar_t [5], long long int)' /mingw/src/gccf/i386-pc-mingw32/libstdc++-v3/include/bits/basic_string.h: In function 'std::wstring std::to_wstring(long long unsigned int)': /mingw/src/gccf/i386-pc-mingw32/libstdc++-v3/include/bits/basic_string.h:2681: error: no matching function for call to '__to_xstring(int (*)(wchar_t*, const wchar_t*, char*), unsigned int, const wchar_t [5], long long unsigned int)' /mingw/src/gccf/i386-pc-mingw32/libstdc++-v3/include/bits/basic_string.h: In function 'std::wstring std::to_wstring(long double)': /mingw/src/gccf/i386-pc-mingw32/libstdc++-v3/include/bits/basic_string.h:2689: error: no matching function for call to '__to_xstring(int (*)(wchar_t*, const wchar_t*, char*), const int, const wchar_t [4], long double)' make[4]: *** [functexcept.lo] Error 1 The problem is that MSVCRT's prototype for vswprintf is incorrect, and differs from the standard C version. This may not be easy to fix in mingwrt. However, the _vsnwprintf function has the correct prototype and works with __to_xstring. I guess the solution is to make libstdc++ use _vsnwprintf instead of vswprintf on *-mingw32. -- Summary: [4.4 regression] Incorrect vswprintf prototype breaks __to_xstring Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: build Severity: major Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aaronavay62 at aaronwl dot com GCC target triplet: *-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37522
[Bug target/37521] Building of GCC fails with internal compiler error for target AVR
--- Comment #1 from eric dot weddington at atmel dot com 2008-09-15 03:18 --- Anatoly Sokolov committed a patch as revision 140360 that may (or may not) fix this problem. See his post on the patches list: http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01054.html Please try a more recent version to see if this patch solves this problem. Thanks. -- eric dot weddington at atmel dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37521
[Bug c++/37057] 7 Internal Compiler Errors when compiling OpenFOAM-1.5
--- Comment #19 from dje at gcc dot gnu dot org 2008-09-14 22:42 --- First, you reported seven ICEs. You attached files for makeChemkinReactions.ii. That file failed before Honza's patch and does not appear to fail after his patch. I cannot reproduce the failure using my version of GCC 4.3.1. Saying that the patch does not fix the problem is not accurate. You said that the makeChemkinReactions.ii still was present in GCC 4.3.2, but you report an ICE for chemkinReader.ii. Please stop shifting the goalpost. You have not commented on makeChemkinReactions.ii. No one said that the seven ICEs were do to a single problem. I suspect the makeChemkinReactions.ii ICE *is* fixed. If you attach chemkinReader.ii, we can try to investigate it as well. These likely all are due to garbage collection issues, but not a single bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37057
[Bug rtl-optimization/37451] Extra addition for doloop in some cases
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-15 01:15 --- Hmm, I posted a patch which fixes some of this but we still don't get rid of the extra zero extend because of the way variables are promoted. Boo. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37451
[Bug target/37520] junk `(,%eax,4)' after expression / suffix or operands invalid for `lea' for libstdc++ deque/init-list.cc
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-09-14 22:24 --- leal$_48(,%eax,4), %eax ... subl$$_48, %eax Hmm Looks like someone forgot a $ encoding in some cases. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|junk `(,%eax,4)' after |junk `(,%eax,4)' after |expression / suffix or |expression / suffix or |operands invalid for `lea' |operands invalid for `lea' |for libstdc++ deque/init- |for libstdc++ deque/init- |list.cc |list.cc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37520
[Bug c++/37057] 7 Internal Compiler Errors when compiling OpenFOAM-1.5
--- Comment #20 from jorn dot amundsen at ntnu dot no 2008-09-15 04:42 --- (In reply to comment #19) I am sorry, You are right. I thought it fixed everything, though. I will check 4.3.2 + the cp/pt.c patch against every of the 7 original ICE's and give an updated status on everyone in another update a little later today. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37057
[Bug libstdc++/37522] [4.4 regression] Incorrect vswprintf prototype breaks __to_xstring
-- aaronavay62 at aaronwl dot com changed: What|Removed |Added CC||dannysmith at users dot ||sourceforge dot net OtherBugsDependingO||36216 nThis|| AssignedTo|unassigned at gcc dot gnu |aaronavay62 at aaronwl dot |dot org |com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Known to fail||4.4.0 Known to work||4.3.2 Last reconfirmed|-00-00 00:00:00 |2008-09-14 23:27:34 date|| Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37522
[Bug libstdc++/37522] [4.4 regression] Incorrect vswprintf prototype breaks __to_xstring
--- Comment #1 from dannysmith at users dot sourceforge dot net 2008-09-15 02:57 --- I guess the solution is to make libstdc++ use _vsnwprintf instead of vswprintf on *-mingw32. I think that is the most expedient solution. Would an inline redirection of vswprintf to _vsnwprintf in config/os/mingw32/os_define.h (later, if it gets fixed in mingw runtime that could be made conditional on mingw version) work? Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37522
[Bug tree-optimization/37102] [4.3/4.4 Regression] out-of-SSA is broken
--- Comment #11 from lthode at mail dot unomaha dot edu 2008-09-15 01:03 --- (In reply to comment #9) Thanks for the explanation, for the branch I would recommend an extra DCE pass right before pass_del_ssa. On the trunk we need to make sure to run this at -O0 as well. Note that the simple DCE can leave dead statements around, only control-dependent DCE will make sure to not retain any DCE opportunities. Well, I tried just that (running CD-DCE right before Out-of-SSA independent of optimization level) on the trunk, and 16 Fortran testcases blow up (with an ICE in Out-of-SSA) at -O0 due to it. However, turning optimization on makes them compile again, so running DCE at -O0 isn't such a great idea. On the other hand, this should be easy enough to fix on the branch, as we can just run the pass if optimization is enabled. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37102
[btt] Re: school
Anyone who doesn't hate homework is cr'r'r'r'r'r'r'r'r'r'raz'z'z'zz'z'z'z'z'z'z'z'zy! Nick Cocchiarella Email: [EMAIL PROTECTED], [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] Skype: coolcocch I would encourage you to check out the google group Blind Teen Talk, a group specifically oriented at blind/vi teens. To join, send a blank email to [EMAIL PROTECTED] You can also check out my blog at tubacooch.blogspot.com. - Original Message - From: Jeffrey Shockley, Windows Desktop Edition [EMAIL PROTECTED] To: blind-teen-talk@googlegroups.com Date sent: Sun, 14 Sep 2008 20:10:04 -0400 Subject: [btt] Re: school I can't say I don't particularly like it, but I don't hate it. Jeffrey Shockley E-Mail: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] Google Talk: [EMAIL PROTECTED] AIM: jawswizard Skype: jawswizard Alexis Garcia wrote: do we all hate home work and school? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Blind Teen Talk group. To post to this group, send email to blind-teen-talk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at one of theat = "160x600_as"; google_ad_channel = "8427791634"; google_color_border = "FF"; google_color_bg = "FF"; google_color_link = "006792"; google_color_url = "006792"; google_color_text = "00"; //--> [Bug fortran/37513] New: Wrongly rejects: unprotected_pointer = protected_pointer burnus at gcc dot gnu dot org [Bug fortran/37513] Wrongly rejects: unprotected_pointer = protected_pointer burnus at gcc dot gnu dot org [Bug fortran/37513] Misleading error for (invalid) protected_pointer = unprotected_pointer mikael dot morin at tele2 dot fr Reply via email to [btt] Re: school Nick Cocchiarella Reply via email to [btt] Re: school Nick Cocchiarella Reply via email to [btt] Re: school Nick Cocchiarella Reply via email to [btt] Re: school Nick Cocchiarella Reply via email to [btt] Re: school Nick Cocchiarella Reply via email to [btt] Re: school Nick Cocchiarella Reply via email to