[Bug c++/31663] New: [4.3 Regression] Segfault in constrain_class_visibility with anonymous namespace
I get the following segfault with current gcc 4.3. This was introduced
between 20070330-r123378 (works) and 20070417-r123941 (segfault). This
is related to the use of anonymous namespace.
I believe it was caused by:
2007-04-16 Seongbae Park <[EMAIL PROTECTED]>
PR c++/29365
* cp/decl2.c (constrain_class_visibility):
Do not warn about the use of anonymous namespace in the main input
file.
(sid)19349:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c
kdevelop-mainwindowshare.cc
kdevelop-mainwindowshare.cc:6: internal compiler error: Segmentation fault
Please submit a full bug report,
Testcase:
namespace
{
class ToolbarListView;
}
class KEditToolbarWidget
{
ToolbarListView *m_inactiveList;
};
Backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x00497f92 in constrain_class_visibility (type=0x2aae86bd2540)
at /home/tbm/scratch/gcc/gcc/cp/decl2.c:1865
1865DECL_SOURCE_FILE (TYPE_MAIN_DECL (ftype
(gdb) where
#0 0x00497f92 in constrain_class_visibility (type=0x2aae86bd2540)
at /home/tbm/scratch/gcc/gcc/cp/decl2.c:1865
#1 0x004915ff in finish_struct_1 (t=0x2aae86bd2540)
at /home/tbm/scratch/gcc/gcc/cp/class.c:5103
#2 0x00492560 in finish_struct (t=0x2aae868df960, attributes=0x0)
at /home/tbm/scratch/gcc/gcc/cp/class.c:5221
#3 0x004b9146 in cp_parser_type_specifier (parser=0x2aae86a3f550,
flags=, decl_specs=0x7fff247a2f30, is_declaration=1
'\001',
declares_class_or_enum=0x7fff247a2ee0, is_cv_qualifier=)
at /home/tbm/scratch/gcc/gcc/cp/parser.c:13821
#4 0x004be14a in cp_parser_decl_specifier_seq (parser=0x2aae86a3f550,
flags=CP_PARSER_FLAGS_OPTIONAL, decl_specs=0x7fff247a2f30,
declares_class_or_enum=0x7fff247a2f88)
at /home/tbm/scratch/gcc/gcc/cp/parser.c:8023
#5 0x004c34d5 in cp_parser_simple_declaration (parser=0x2aae86a3f550,
function_definition_allowed_p=1 '\001') at
/home/tbm/scratch/gcc/gcc/cp/parser.c:7725
#6 0x004c56e7 in cp_parser_block_declaration (parser=0x2aae86a3f550,
statement_p=0 '\0')
at /home/tbm/scratch/gcc/gcc/cp/parser.c:7686
#7 0x004c805e in cp_parser_declaration (parser=0x2aae86a3f550)
at /home/tbm/scratch/gcc/gcc/cp/parser.c:7594
#8 0x004c7976 in cp_parser_declaration_seq_opt (parser=0x2aae86a3f550)
at /home/tbm/scratch/gcc/gcc/cp/parser.c:7489
#9 0x004c7c91 in c_parse_file () at
/home/tbm/scratch/gcc/gcc/cp/parser.c:2941
#10 0x005771ea in c_common_parse_file (set_yydebug=)
at /home/tbm/scratch/gcc/gcc/c-opts.c:1268
#11 0x00786f04 in toplev_main (argc=, argv=)
at /home/tbm/scratch/gcc/gcc/toplev.c:1050
#12 0x2aae866b2314 in __libc_start_main () from /lib/libc.so.6
--
Summary: [4.3 Regression] Segfault in constrain_class_visibility
with anonymous namespace
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31663
[Bug fortran/31616] testsuite failures in gfortran.dg/open_errors.f90
--- Comment #6 from ghazi at gcc dot gnu dot org 2007-04-23 08:52 --- Subject: Bug 31616 Author: ghazi Date: Mon Apr 23 08:52:24 2007 New Revision: 124059 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124059 Log: PR fortran/31616 * gfortran.dg/open_errors.f90: Allow a different error message. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/open_errors.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31616
[Bug target/31403] wrong branch instructions generated with -m2a on sh-elf
--- Comment #4 from kkojima at gcc dot gnu dot org 2007-04-23 09:53 --- > The same problem seems to transpire from the movsf_ie pattern for the sh2a-fpu > that also have 32 bit memory instructions. So your fix also applies there. Ah, thanks! I'll add movsf_ie part when I return to this problem. > Shouldn't the new 4 bytes instructions be described latter with a new memory > constraint ? Maybe, though I'm not sure if it's worth to effort. Of course, it'd be interesting to collect some numbers with such a change. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31403
[Bug bootstrap/31523] bootstrap xgcc internal compiler error (using -O3)
--- Comment #9 from anirkko at insel dot ch 2007-04-23 11:35 --- (In reply to comment #8) > > The bootstrap works fine with all flags equal to '-O2' > > Great, thanks for the confirmation. > > > Still worrysome, because somewhere in the installation instructions, it is > > recommended to bootstrap the compiler with the flags one intends to later > > use it with. > > Please point me to this and I'll immediately propose to delete it. 99% of > the testing of the compiler is done with the default bootstrap settings. > > > Does it mean the offending flag is broken and should never be used at all? > > -mcpu=supersparc is totally untested these days so bugs can be expected, yes. > > Please point me to this... It is in the main directory, file FAQ, section "Optimizing the compiler itself": If you want to test a particular optimization option, it's useful to try bootstrapping the compiler with that option turned on. But please don't let this be removed, because 1) I find the suggestion useful, and it seems to somewhat parallel the reason why you want the compiler bootstrap itself through all stages in the first place: to make sure it can compile itself. Likewise, if it can compile itself reproducibly through the bootstrap using different options, you have made sure these options are pretty well tested for real code by the time you have the compiler finished 2) You closed this bug on the premises that -mcpu=supersparc is the culprit. Well, it isn't: I now bootstrapped with '-O2 -mcpu=supersparc' and everything went fine! Therefore, I still think there is a bug in -O3. (alternatively, in the combination of the two). Would you consider reopening this bug if it was -O3? (In this case, I might re-run the bootstrap with only '-O3', next weekend). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31523
[Bug bootstrap/31523] bootstrap xgcc internal compiler error (using -O3)
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2007-04-23 11:55 --- > It is in the main directory, file FAQ, section "Optimizing the compiler > itself": >If you want to test a particular optimization option, it's useful to >try bootstrapping the compiler with that option turned on. OK, but note that it's quite different from what you said. First, it's not "recommended", it's "useful to try". Second, it's only for *testing* the option, not for production use. > 1) I find the suggestion useful, and it seems to somewhat parallel the reason > why you want the compiler bootstrap itself through all stages in the first > place: to make sure it can compile itself. Likewise, if it can compile > itself reproducibly through the bootstrap using different options, you have > made sure these options are pretty well tested for real code by the time you > have the compiler finished OK, that makes sense. > Therefore, I still think there is a bug in -O3. (alternatively, in the > combination of the two). Would you consider reopening this bug if it was -O3? > (In this case, I might re-run the bootstrap with only '-O3', next weekend). Yes, I'm going to reopen it, but I'm not sure someone will tackle it. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31523
[Bug fortran/29523] ICE with some non up-to date .mod files
--- Comment #6 from keinstein_junior at gmx dot net 2007-04-23 12:08 --- I tried to add a new testcase which shows the error with my gfortran-4.2. But got an error. It's located at http://rcswww.urz.tu-dresden.de/~s7935097/src-differror2.tgz now. FYI alloys.mod depends on the other two, is outdated and should be rebuild. But ICE is not a real solution. I'd expect some error about inconsistent .mod fieles (probably noting, which one should be rebuilt). [EMAIL PROTECTED]:~/bugs/src-differror2$ ./start-gfc diffussion.F90: In function ‘MAIN__’: diffussion.F90:9: internal compiler error: in gfc_get_derived_type, at fortran/trans-types.c:1452 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. [EMAIL PROTECTED]:~/bugs/src-differror2$ vi start-gfc [EMAIL PROTECTED]:~/bugs/src-differror2$ ./start-gfc Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /projects/tob/gcc-4_2-branch/configure --enable-languages=c,fortran --prefix=/projects/tob/gcc-4.2 Thread model: posix gcc version 4.2.0 20070215 (prerelease) /usr/local/gcc-4.2/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.2.0/cc1 -E -lang-fortran -traditional-cpp -D_LANGUAGE_FORTRAN -quiet -v -I. -I../../src -I ../../includes -I potentials -I tools -I lattices -I Verfahren -I filter -iprefix /usr/local/gcc-4.2/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.2.0/ -DPACKAGE_NAME="matprop" -DPACKAGE_TARNAME="matprop" -DPACKAGE_VERSION="0.1.0" -DPACKAGE_STRING="matprop 0.1.0" -DPACKAGE_BUGREPORT="[EMAIL PROTECTED]" -DPACKAGE="matprop" -DVERSION="0.1.0" -DDEBUG diffussion.F90 -mtune=generic -Wall -Wsurprising -fbounds-check -ftree-vectorize -fworking-directory -O3 -o /tmp/ccDZMQzD.f95 ignoring nonexistent directory "/usr/local/gcc-4.2/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.2.0/../../../../x86_64-unknown-linux-gnu/include" ignoring nonexistent directory "/projects/tob/gcc-4.2/include" ignoring nonexistent directory "/projects/tob/gcc-4.2/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/include" ignoring nonexistent directory "/projects/tob/gcc-4.2/x86_64-unknown-linux-gnu/include" ignoring nonexistent directory "../../src" ignoring nonexistent directory "../../includes" ignoring nonexistent directory "potentials" ignoring nonexistent directory "tools" ignoring nonexistent directory "lattices" ignoring nonexistent directory "Verfahren" ignoring nonexistent directory "filter" #include "..." search starts here: #include <...> search starts here: . /usr/local/gcc-4.2/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.2.0/include /usr/local/include /usr/include End of search list. /usr/local/gcc-4.2/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.2.0/f951 /tmp/ccDZMQzD.f95 -ffree-form -quiet -dumpbase diffussion.F90 -mtune=generic -auxbase-strip diffussion.o -g -O3 -Wall -Wsurprising -version -p -fbounds-check -ftree-vectorize -I. -I../../src -I ../../includes -I potentials -I tools -I lattices -I Verfahren -I filter -fpreprocessed -I /usr/local/gcc-4.2/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.2.0/finclude -o /tmp/ccsyx4u7.s GNU F95 version 4.2.0 20070215 (prerelease) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.2.0 20070215 (prerelease). GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128471 diffussion.F90: In function ‘MAIN__’: diffussion.F90:9: internal compiler error: in gfc_get_derived_type, at fortran/trans-types.c:1452 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- keinstein_junior at gmx dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29523
[Bug target/31641] [4.1/4.2/4.3 Regression] ICE in s390_expand_setmem, at config/s390/s390.c:3618
--- Comment #2 from krebbel at gcc dot gnu dot org 2007-04-23 12:21 --- In your example the memset function is called with -1 as length argument. When GCC tries to expand this as a builtin function an assertion in the s390 back end function s390_expand_setmem is triggered. Although an ICE is the wrong thing to respond I would consider it a code bug as well. I've proposed a patch to issue a proper error message and call the library function in that situation. The library function probably would write one byte below the target address causing a segfault for a -1 length which is most likely not what the programmer intended but thats what would happen in the -O0 as well. -- krebbel at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-23 12:21:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31641
[Bug tree-optimization/15353] [tree-ssa] Merge two "if"s if one subsumes the other.
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-04-23 12:47 --- Mine. -- 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-10-24 12:39:16 |2007-04-23 12:47:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15353
[Bug libstdc++/31638] [4.0/4.1/4.2 Regression] string usage leads to warning with -Wcast-align
--- Comment #6 from pcarlini at suse dot de 2007-04-23 13:35 --- (In reply to comment #5) > It is OK with me. Ok, excellent. For 4_2-branch we have a nuisance, in that the original testcase involves -Wconversion which in that branch does nothing in C++. Thus I tested on ia64-linux the attached, which adds a new test. If requested I can add it to mainline too, otherwise I will simply commit to the branch and close this PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31638
[Bug libstdc++/31638] [4.0/4.1/4.2 Regression] string usage leads to warning with -Wcast-align
--- Comment #7 from pcarlini at suse dot de 2007-04-23 13:36 --- Created an attachment (id=13430) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13430&action=view) Patch for 4_2-branch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31638
[Bug target/31641] [4.1/4.2/4.3 Regression] ICE in s390_expand_setmem, at config/s390/s390.c:3618
--- Comment #3 from uweigand at gcc dot gnu dot org 2007-04-23 14:51 --- I don't think the patch is correct; according to the C standard, the third argument of memset is of type size_t, which must be an *unsigned* type, so it cannot in fact be negative. What apparently happens is that the argument (after conversion to size_t) is so big that it appears to be negative in its representation as CONST_INT, so the assert in s390.c triggers. A proper fix would probably be to remove the assert in s390_expand_setmem and at the same time make sure those big sizes are handled correctly. (In any case, the testcase certainly is broken anyway.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31641
[Bug c++/31665] New: %s substituted with "built-in"/"library" can't be properly translated
In cp/decl.c there is this code warning (OPT_Wshadow, "shadowing %s function %q#D", DECL_BUILT_IN (olddecl) ? "built-in" : "library", olddecl); The strings substituted for the first %s are not available for translation, so this can not be properly translated. Even if they were, composing a sentence like this is not in general possible to do for an arbitrary language. -- Summary: %s substituted with "built-in"/"library" can't be properly translated Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: goeran at uddeborg dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31665
[Bug c++/31663] [4.3 Regression] Segfault in constrain_class_visibility with anonymous namespace
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-23 15:07 --- http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01191.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31663
[Bug c++/31666] New: [4.3 regression]: g++.old-deja/g++.other/vbase5.C execution test
In http://gcc.gnu.org/ml/gcc-testresults/2007-04/msg01156.html there is FAIL: g++.old-deja/g++.other/vbase5.C execution test -- Summary: [4.3 regression]: g++.old-deja/g++.other/vbase5.C execution test Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31666
[Bug c++/31666] [4.3 regression]: g++.old-deja/g++.other/vbase5.C execution test
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-04-23 15:26 --- Confirmed, I also see this. -- 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 |2007-04-23 15:26:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31666
[Bug preprocessor/30468] [4.0/4.1/4.2 Regression] -M not fully chops dirname
--- Comment #7 from tromey at gcc dot gnu dot org 2007-04-23 15:26 --- Subject: Bug 30468 Author: tromey Date: Mon Apr 23 15:26:21 2007 New Revision: 124067 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124067 Log: PR preprocessor/30468: * mkdeps.c (apply_vpath): Strip successive '/'s if we stripped './'. Modified: branches/gcc-4_1-branch/libcpp/ChangeLog branches/gcc-4_1-branch/libcpp/mkdeps.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30468
[Bug preprocessor/30468] [4.0/4.1/4.2 Regression] -M not fully chops dirname
--- Comment #8 from tromey at gcc dot gnu dot org 2007-04-23 15:27 --- Subject: Bug 30468 Author: tromey Date: Mon Apr 23 15:26:51 2007 New Revision: 124068 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124068 Log: PR preprocessor/30468: * mkdeps.c (apply_vpath): Strip successive '/'s if we stripped './'. Modified: branches/gcc-4_2-branch/libcpp/ChangeLog branches/gcc-4_2-branch/libcpp/mkdeps.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30468
[Bug tree-optimization/31667] New: Integer externsions aren't vectorized
SSE4.1 has pmovzx and pmovsx. For code like:
[EMAIL PROTECTED] vect]$ cat pmovzxbw.c
typedef unsigned char vec_t;
typedef unsigned short vecx_t;
extern __attribute__((aligned(16))) vec_t x [64];
extern __attribute__((aligned(16))) vecx_t y [64];
void
foo ()
{
int i;
for (i = 0; i < 64; i++)
y [i] = x [i];
}
Icc generates
pmovzxbw x(%rip), %xmm0#13.14
pmovzxbw 8+x(%rip), %xmm1 #13.14
pmovzxbw 16+x(%rip), %xmm2 #13.14
pmovzxbw 24+x(%rip), %xmm3 #13.14
pmovzxbw 32+x(%rip), %xmm4 #13.14
pmovzxbw 40+x(%rip), %xmm5 #13.14
pmovzxbw 48+x(%rip), %xmm6 #13.14
pmovzxbw 56+x(%rip), %xmm7 #13.14
movdqa%xmm0, y(%rip)#13.5
movdqa%xmm1, 16+y(%rip) #13.5
movdqa%xmm2, 32+y(%rip) #13.5
movdqa%xmm3, 48+y(%rip) #13.5
movdqa%xmm4, 64+y(%rip) #13.5
movdqa%xmm5, 80+y(%rip) #13.5
movdqa%xmm6, 96+y(%rip) #13.5
movdqa%xmm7, 112+y(%rip)#13.5
ret #14.1
--
Summary: Integer externsions aren't vectorized
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31667
[Bug preprocessor/30468] [4.0/4.1/4.2 Regression] -M not fully chops dirname
--- Comment #9 from tromey at gcc dot gnu dot org 2007-04-23 15:27 --- Fixed on 4.1 and 4.2 branches. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30468
[Bug java/31570] ports/gcc43 fails on FreeBSD 6.2 with signal 9
--- Comment #2 from vaclav dot kocian at wo dot cz 2007-04-23 15:33 --- My RAM is 512MB. Well, the newer version of gcc says : You need to increase the datasize limit to at least 70 (and set kern.maxdsiz="734003200" in /boot/loader.conf) to build with Java support. I do not understand it fully, but it seems quite differently. For now, I'm satisfied with gcc42. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31570
[Bug fortran/31620] [4.3 regression] Zeroing one component of array of derived types zeros the whole structure.
--- Comment #8 from pault at gcc dot gnu dot org 2007-04-23 16:14 --- Subject: Bug 31620 Author: pault Date: Mon Apr 23 16:13:48 2007 New Revision: 124069 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124069 Log: 2007-04-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/31630 * resolve.c (resolve_symbol): Allow resolution of formal namespaces nested within formal namespaces coming from modules. PR fortran/31620 * trans-expr.c (gfc_trans_assignment): Make the call to gfc_trans_zero_assign conditional on the lhs array ref being the only reference. 2007-04-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/31630 * gfortran.dg/used_types_17.f90: New test. PR fortran/31620 * gfortran.dg/zero_array_components_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/used_types_17.f90 trunk/gcc/testsuite/gfortran.dg/zero_array_components_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31620
[Bug fortran/31630] [4.3 regression] ICE on nasty derived types code
--- Comment #3 from pault at gcc dot gnu dot org 2007-04-23 16:14 --- Subject: Bug 31630 Author: pault Date: Mon Apr 23 16:13:48 2007 New Revision: 124069 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124069 Log: 2007-04-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/31630 * resolve.c (resolve_symbol): Allow resolution of formal namespaces nested within formal namespaces coming from modules. PR fortran/31620 * trans-expr.c (gfc_trans_assignment): Make the call to gfc_trans_zero_assign conditional on the lhs array ref being the only reference. 2007-04-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/31630 * gfortran.dg/used_types_17.f90: New test. PR fortran/31620 * gfortran.dg/zero_array_components_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/used_types_17.f90 trunk/gcc/testsuite/gfortran.dg/zero_array_components_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31630
[Bug c++/31598] g++ does not accept some OpenMP code
--- Comment #2 from theodore dot papadopoulo at sophia dot inria dot fr 2007-04-23 16:46 --- (From update of attachment 13378) Slightly simplified the testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31598
[Bug c++/31663] [4.3 Regression] Segfault in constrain_class_visibility with anonymous namespace
--- Comment #2 from spark at gcc dot gnu dot org 2007-04-23 16:53 --- My patch (which is still waiting for a review) should fix this. -- spark at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |spark at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-23 16:53:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31663
[Bug c++/31598] g++ does not accept some OpenMP code
--- Comment #3 from theodore dot papadopoulo at sophia dot inria dot fr 2007-04-23 17:01 --- Sorry to have added you without asking Jakub, but it looks like you are one of the person that deals with OpenMP and this bug seems to have been unnoticed up to now... It seems that this problem is related to the template instanciation mecanism (as far as I can tell). The trouble is that finish_omp_clauses ensures that the variable b is complete by calling require_complete_type but since we are in template instanciation mode, this function returns immediately without doing anything. Further in finish_omp_clauses (semantics.c:3655), assuming that the type is complete the code tries to build a call to a (copy?) constructor, build_call calls complete_type_or_else which calls complete_type which calls instantiate_class_template which returns immediately because TYPE_BEING_DEFINED is true so complete_type_or_else complains. Is there a way to defer the completeness check to after the type has been instantiated ?? -- theodore dot papadopoulo at sophia dot inria dot fr changed: What|Removed |Added CC||jakub at redhat dot com Summary|g++ does not accept some|g++ does not accept some |OpenMP code |OpenMP code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31598
[Bug c++/31419] [4.1/4.2/4.3 regression] template user defined conversion operator instantiated for conversion to self
--- Comment #5 from janis at gcc dot gnu dot org 2007-04-23 17:02 --- A regression hunt on powerc-linux using the submitter's testcase identified the following patch: http://gcc.gnu.org/viewcvs?view=rev&rev=64815 r64815 | nathan | 2003-03-24 19:47:17 + (Mon, 24 Mar 2003) -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||nathan at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31419
[Bug c++/31338] [4.1/4.2/4.3 regression] Cannot apply "!" to complex constants
--- Comment #3 from janis at gcc dot gnu dot org 2007-04-23 17:06 --- A regression hunt on powerpc-linux identified the following patch: http://gcc.gnu.org/viewcvs?view=rev&rev=69715 r69715 | mmitchel | 2003-07-23 18:44:43 + (Wed, 23 Jul 2003) -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31338
[Bug c++/31337] [4.2/4.3 regression] ICE with statement expression
--- Comment #3 from janis at gcc dot gnu dot org 2007-04-23 17:19 --- A regression hunt on powerpc-linux identified the following patch: http://gcc.gnu.org/viewcvs?view=rev&rev=116311 r116311 | jason | 2006-08-21 13:54:57 -0700 (Mon, 21 Aug 2006) -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31337
[Bug java/31622] Segment violation in the “toString” method on a mathematical expression
--- Comment #6 from tromey at gcc dot gnu dot org 2007-04-23 17:24 --- Ok. You are running a version of gcj 4.3 from *before* the gcj-eclipse merge. So, this is correctly marked as a duplicate. If you update and rebuild, and follow the new instructions vis a vis ecj1, you will get a working gcj. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31622
[Bug c++/31584] ICE on probably invalid code
--- Comment #4 from numerical dot simulation at web dot de 2007-04-23 17:24 --- Sorry, the link was wrong, must be http://groups.google.de/group/comp.lang.c++.moderated/browse_thread/thread/8c3b8a84ed78b003/4d9603171894a75d?hl=de#4d9603171894a75d -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31584
[Bug c++/31411] [4.1/4.2/4.3 Regression] ICE in gimplify_expr with throw/special copy constructor with initializer with a deconstructor
--- Comment #7 from janis at gcc dot gnu dot org 2007-04-23 17:27 --- A regression hunt identified the tree-ssa merge to mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31411
[Bug fortran/31620] [4.3 regression] Zeroing one component of array of derived types zeros the whole structure.
--- Comment #9 from pault at gcc dot gnu dot org 2007-04-23 17:52 --- Fixed on trunk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31620
[Bug fortran/31630] [4.3 regression] ICE on nasty derived types code
--- Comment #4 from pault at gcc dot gnu dot org 2007-04-23 17:52 --- Fixed on trunk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31630
[Bug fortran/31668] New: %VAL rejected for PROC_MODULE and PROC_INTERNAL procedures
Reported by Arjan van Dijk, http://gcc.gnu.org/ml/fortran/2007-04/msg00367.html gfortran rejects the following code with the error: "By-value argument at (1) is not allowed in this context" This is because the following check is matched: resolve.c, resolve_actual_arglist(): /* Intrinsics are still PROC_UNKNOWN here. However, since same file external procedures are not resolvable in gfortran, it is a good deal easier to leave them to intrinsic.c. */ if (ptype != PROC_UNKNOWN && ptype != PROC_DUMMY && ptype != PROC_EXTERNAL) However, in this case: ptype == PROC_MODULE. The following values are possible: PROC_UNKNOWN, PROC_MODULE, PROC_INTERNAL, PROC_DUMMY, PROC_INTRINSIC, PROC_ST_FUNCTION, PROC_EXTERNAL I have to think about which cases make sense and which don't. What speaks against allowing PROC_INTRINSIC, PROC_INTERNAL, PROC_ST_FUNCTION? Is there one which needs always be rejected? If yes, a test case would be nice. For PROC_INTERNAL I would argue it should be allowed: SUBROUTINE Grid2BMP(NX) INTEGER, INTENT(IN) :: NX call bmp_write(%val(nx)) contains subroutine bmp_write(nx) integer, intent(in) :: nx end subroutine bmp_write END SUBROUTINE Grid2BMP end For statement functions, I agree it should be invalid (for %VAL, %REF, %DESCR): SUBROUTINE Grid2BMP(NX) INTEGER, INTENT(IN) :: NX integer :: i,f f(i)=i**2 ! statement function i = f(%VAL(i)) END SUBROUTINE Grid2BMP This agrees with ifort which also rejects it. And for PROC_INTRINSIC: ifort rejects sin(%VAL(x)) as above (%VAL/%REF/%DESCR invalid in this context), gfortran has the error: "Argument list function at (1) is not allowed in this context". (I prefer Intel's error message.) At the moment, I don't see any intrinsic which would work with %VAL, but maybe I miss something. Is there an example for PROC_INTRINSIC or PROC_UNKNOWN which needs to be supported? Example: a) Longer example, see follow up email (URL above) b) short example (works if one moves the interface into the procedure body): module x interface subroutine bmp_write(nx) integer, intent(in) :: nx end subroutine bmp_write end interface contains SUBROUTINE Grid2BMP(NX) INTEGER, INTENT(IN) :: NX call bmp_write(%val(nx)) END SUBROUTINE Grid2BMP END module end -- Summary: %VAL rejected for PROC_MODULE and PROC_INTERNAL procedures Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31668
[Bug fortran/31668] %VAL rejected for PROC_MODULE and PROC_INTERNAL procedures
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-23 18:05:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31668
[Bug ada/31669] New: GNAT blows up during compilation
Ada compiler, GNAT, blows up during compilation of the code segment below with an unhandled exception error message "raised RTSIFND.RE_NOT_AVAILABLE : rts.find.adb:210" package Abstract_Base is pragma Pure; type Base_Type is abstract tagged limited private; procedure Update (This : access Base_Type; Data : in Integer) is abstract; private type Base_Type is abstract tagged limited null record; end Abstract_Base; with Abstract_Base; package Re_Not_Available is pragma Remote_Call_Interface; type Base_Access is access all Abstract_Base.Base_Type'Class; type Subscription is private; Null_Sub : constant Subscription; procedure Subscribe (This : in out Subscription; Callback : in Base_Access); procedure Unsubscribe (This : in out Subscription); type Publication is Private; Null_Pub : constant Publication; procedure Register (This : in out Publication); function Register return Publication; procedure Unregister (This : in out Publication); procedure Publish (This : Publication; Data : Integer); private Max_Subscribers : constant := 20; type Subscriber_Id is range 0 .. Max_Subscribers; type Subscription is new Subscriber_Id; type Publication is new Boolean; Null_Sub : constant Subscription := 0; Null_Pub : constant Publication := False; end Re_Not_Available; -- Summary: GNAT blows up during compilation Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anhvofrcaus at gmail dot com GCC build triplet: gcc-4.3-20070420 GCC host triplet: RedHat 10.0 on X86 GCC target triplet: RedHat 10.0 on X86 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31669
[Bug ada/31669] GNAT blows up during compilation
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|blocker |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31669
[Bug c/31670] New: Error calculating size of structs
#include
typedef struct{
char data[261];
int n;
} packet;
int main(int argc, char *argv[]){
packet p;
//It should print packet=265... it prints packet=268
printf("packet = %d\n", sizeof(packet));
//It should print p=265... it prints p=268
printf("p = %d\n", sizeof(p));
//It should print p.n=4... OK
printf("p.n = %d\n", sizeof(p.n));
//It should print p.data=261... OK
printf("p.data = %d\n", sizeof(p.data));
return 0;
}
--
Summary: Error calculating size of structs
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: padrinator at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31670
[Bug c/31670] Error calculating size of structs
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-23 19:32 --- Learn about alignment when doing struct layout. Basically you want to use the attribute packed to get the sizes you want. -- 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=31670
[Bug rtl-optimization/28812] RTL aliasing vs may_alias and structs
--- Comment #6 from amylaar at gcc dot gnu dot org 2007-04-23 19:37 ---
(In reply to comment #5)
> Fixed.
>
I also see mayalias-2 failing with gcc 4.2 on arc at
-O3 -fomit-frame-pointer.
Life analysis finds a 'clever' way to initialize the pointer p
by copying the frame pointer and then using pre-decrement addressing.
The following rtl dump is from mayalias-2.c.134r.life2 ; note that
insn 13 is the store of 1, and insn 15 is the dependent load.
Because the address in insn 13 does not show the frame pointer explicitly,
fixed_scalar_and_varying_struct_p decides that 'p' is varying, and hence
the two memory accesses don't alias.
(insn:HI 42 7 8 2 (set (reg/v/f:SI 149 [ p ])
(reg/f:SI 27 fp)) 12 {*movsi_insn} (nil)
(nil))
(insn:HI 8 42 10 2 (set (mem/c/i:SI (pre_dec:SI (reg/v/f:SI 149 [ p ])) [3 a+0
S4 A32])
(reg:SI 151)) 12 {*movsi_insn} (insn_list:REG_DEP_TRUE 7
(insn_list:REG_DEP_TRUE 42 (nil)))
(expr_list:REG_DEAD (reg:SI 151)
(expr_list:REG_INC (reg/v/f:SI 149 [ p ])
(expr_list:REG_EQUAL (const_int 10 [0xa])
(nil)
(note:HI 10 8 12 2 NOTE_INSN_DELETED)
(insn:HI 12 10 13 2 (set (reg:HI 152)
(const_int 1 [0x1])) 7 {*movhi_insn} (nil)
(nil))
(insn:HI 13 12 15 2 (set (mem/s/j:HI (reg/v/f:SI 149 [ p ]) [0 .x+0
S2 A16])
(reg:HI 152)) 7 {*movhi_insn} (insn_list:REG_DEP_TRUE 10
(insn_list:REG_DEP_TRUE 12 (nil)))
(expr_list:REG_DEAD (reg:HI 152)
(expr_list:REG_DEAD (reg/v/f:SI 149 [ p ])
(expr_list:REG_EQUAL (const_int 1 [0x1])
(nil)
(insn:HI 15 13 16 2 (set (reg:SI 153 [ a ])
(mem/c/i:SI (plus:SI (reg/f:SI 27 fp)
(const_int -4 [0xfffc])) [3 a+0 S4 A32])) 12 {*movsi_insn}
(nil)
(nil))
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28812
[Bug c++/31671] New: Non-type template of type const ref accepted as a non-const ref
The following code compiles in all the gcc versions I tested (4.0.1, 4.1.1,
4.1.2):
template void doit() {
i = 0;
}
template class X {
public:
void foo() {
doit();
}
};
int i;
X x;
int main(int argc, char **argv) {
x.foo();
}
Note that if "i" is declared const then the code will not compile.
--
Summary: Non-type template of type const ref accepted as a non-
const ref
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chgros at coverity dot com
GCC build triplet: i486-linux-gnu
GCC host triplet: i686-linux-gnu
GCC target triplet: i686-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31671
[Bug c++/31671] Non-type template of type const ref accepted as a non-const ref
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-23 20:14 --- Confirmed, not a regression as far as I can tell. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i486-linux-gnu | GCC host triplet|i686-linux-gnu | GCC target triplet|i686-linux-gnu | Keywords||accepts-invalid Known to fail||3.3.3 4.3.0 4.2.0 Last reconfirmed|-00-00 00:00:00 |2007-04-23 20:14:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31671
[Bug c++/31337] [4.2/4.3 regression] ICE with statement expression
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-03-25 07:46:59 |2007-04-23 20:19:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31337
[Bug fortran/31672] New: Not Implemented: Initialization of overlapping variables
This feature is used "classic" Fortran 77 libraries such as Starpac, as mentioned in comp.lang.fortran on 23-Apr-2007 . c:\fortran> type d1mach.f90 function d1mach(i) implicit none double precision d1mach,dmach(5) integer i,large(4),small(4) equivalence ( dmach(1), small(1) ) equivalence ( dmach(2), large(1) ) data small(1),small(2) / 0, 1048576/ data large(1),large(2) /-1,2146435071/ d1mach = 0.0d0 end function d1mach c:\fortran> gfortran -c -v d1mach.f90 Using built-in specs. Target: i386-pc-mingw32 Configured with: ../trunk/configure --prefix=/mingw --enable-languages=c,fortran,c++,objc,obj-c++ --with-gmp=/home/coudert/local --disable-nls --with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror --enable-bootstrap --enable-threads --build=i386-pc-mingw32 --disable-shared --enable-libgomp Thread model: win32 gcc version 4.3.0 20070406 (experimental) c:/programs/gfortran/bin/../libexec/gcc/i386-pc-mingw32/4.3.0/f951.exe d1mach.f90 -quiet -dumpbase d1mach.f90 -mtune=i386 -auxbase d1mach -version -fintrinsic-modules-path c:/programs/gfortran/bin/../lib/gcc/i386-pc-mingw32/4.3.0/finclude -o C:\DOCUME~1\vrao\LOCALS~1\Temp/cchM3Bia.s GNU F95 version 4.3.0 20070406 (experimental) (i386-pc-mingw32) compiled by GNU C version 4.3.0 20070406 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 d1mach.f90: In function 'd1mach': d1mach.f90:1: fatal error: gfc_todo: Not Implemented: Initialization of overlapping variables compilation terminated. -- Summary: Not Implemented: Initialization of overlapping variables Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: beliavsky at aol dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31672
[Bug fortran/31618] backspace intrinsic is not working on an unformatted file
--- Comment #8 from tkoenig at gcc dot gnu dot org 2007-04-23 20:44 --- Subject: Bug 31618 Author: tkoenig Date: Mon Apr 23 20:43:54 2007 New Revision: 124079 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124079 Log: 2007-04-23 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/31618 * io/transfer.c (read_block_direct): Instead of calling us_read, set dtp->u.p.current_unit->current_record = 0 so that pre_position will read the record marker. (data_transfer_init): For different error conditions, call generate_error, then return. 2007-04-23 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/31618 * gfortran.dg/backspace_8.f: New test case. Added: trunk/gcc/testsuite/gfortran.dg/backspace_8.f Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31618
[Bug fortran/31618] [4.2, 4.1 only] backspace intrinsic is not working on an unformatted file
--- Comment #9 from tkoenig at gcc dot gnu dot org 2007-04-23 20:46 --- Fixed on trunk. Maybe we should backport this once 4.2.1 is open. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.2.0 4.1.2 Known to work||4.3.0 Summary|backspace intrinsic is not |[4.2, 4.1 only] backspace |working on an unformatted |intrinsic is not working on |file|an unformatted file http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31618
[Bug fortran/29786] [4.1/4.2/4.3 Regression] rejects equivalence
--- Comment #8 from brooks at gcc dot gnu dot org 2007-04-23 20:48 --- *** Bug 31672 has been marked as a duplicate of this bug. *** -- brooks at gcc dot gnu dot org changed: What|Removed |Added CC||beliavsky at aol dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29786
[Bug fortran/31672] Not Implemented: Initialization of overlapping variables
--- Comment #1 from brooks at gcc dot gnu dot org 2007-04-23 20:48 --- Thanks for reporting this -- this is a rather nicer testcase than the one we had for this already. I've also changed the title of PR #29786 to make it easier to find. *** This bug has been marked as a duplicate of 29786 *** -- brooks at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31672
[Bug fortran/29786] [4.1/4.2/4.3 Regression] Initialization of overlapping variables: Not implemented
--- Comment #9 from brooks at gcc dot gnu dot org 2007-04-23 20:49 --- I'm changing the name of this bug to make it a lot easier to find, now that we know what the actual problem is. Also, PR #31672 contains an excellent testcase for this, which I'll quote here: -- function d1mach(i) implicit none double precision d1mach,dmach(5) integer i,large(4),small(4) equivalence ( dmach(1), small(1) ) equivalence ( dmach(2), large(1) ) data small(1),small(2) / 0, 1048576/ data large(1),large(2) /-1,2146435071/ d1mach = 0.0d0 end function d1mach -- -- brooks at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1/4.2/4.3 Regression]|[4.1/4.2/4.3 Regression] |rejects equivalence |Initialization of ||overlapping variables: Not ||implemented http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29786
[Bug target/29826] __attribute__ dllimport makes optimization crash on cygwin
--- Comment #17 from arcangelpip at hotmail dot com 2007-04-23 20:51 --- Yup, that did it. Building the cross compiler with that patch fixed the test case ICE and the one I kept getting from gettext. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29826
[Bug fortran/29786] [4.1/4.2/4.3 Regression] Initialization of overlapping variables: Not implemented
-- brooks at gcc dot gnu dot org changed: What|Removed |Added Priority|P5 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29786
[Bug fortran/31620] [4.3 regression] Zeroing one component of array of derived types zeros the whole structure.
--- Comment #10 from roger at eyesopen dot com 2007-04-23 20:54 --- Many thanks to Paul for fixing this, and my apologies for being overloaded at work and not being available to investigate it fully myself. I believe that Paul's fix of explicitly checking expr1->ref->next is the correct way to determine whether a reference is too complex. My confusion is that this test should already be being checked/verified in the call to gfc_full_array_ref_p on the line immediately following his change. So on line 1124 of dependency.c in gfc_f_a_r_p is the clause if (ref->next) return false; which should be doing exactly the same thing. The reason I mention this is perhaps GCC is miscompiling itself, and this gfortran failure is the visible manifestation. Alternatively, perhaps ref->next isn't getting set properly, or is getting clobbered somehow. Paul does your new testcase fail without your fix? My apologies again if I'm missing something obvious. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31620
[Bug fortran/31620] [4.3 regression] Zeroing one component of array of derived types zeros the whole structure.
--- Comment #11 from roger at eyesopen dot com 2007-04-23 21:05 --- Duh! I am missing something obvious! The ref->u.ar.type == AR_FULL test on line 1120 returns true. The test for ref->next needs to be moved earlier. Sorry again for the inconvenience. Clearly, my brain isn't working properly at the moment :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31620
[Bug c/31673] New: "`for' loop initial declaration used outside C99 mode" is confusing
The error message `for' loop initial declaration used outside C99 mode is just confusing to the average user. The default -std level is "gnu89" which forbids for loop initial declarations, but as the user might not have even heard about C99 let alone mentioned that somewhere on purpose, this message causes an unusual high amount of support traffic. I suggest replacing it by `foo' loop initial declarations are only allowed in C99 mode -- Summary: "`for' loop initial declaration used outside C99 mode" is confusing Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: j at uriah dot heep dot sax dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31673
[Bug c/31673] "`for' loop initial declaration used outside C99 mode" is confusing
--- Comment #1 from j at uriah dot heep dot sax dot de 2007-04-23 21:34 --- Created an attachment (id=13431) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13431&action=view) Suggested patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31673
[Bug target/31674] New: [4.3 Regression] internal consistency failure on ia64 with -O
I get an internal consistency failure on ia64 with current gcc 4.3. This was introduced between 20070326 and 20070422. It doesn't happen on x86_64. [EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/g++ -c kdeedu-libextdate_la.all_cpp.cc [EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/g++ -c -O kdeedu-libextdate_la.all_cpp.cc kdeedu-libextdate_la.all_cpp.cc: In member function 'void ExtDateTimeEditor::paintEvent(QPaintEvent*)': kdeedu-libextdate_la.all_cpp.cc:104: internal compiler error: internal consistency failure Please submit a full bug report, -- Summary: [4.3 Regression] internal consistency failure on ia64 with -O Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com GCC target triplet: ia64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31674
[Bug c/31673] "`for' loop initial declaration used outside C99 mode" is confusing
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-04-23 21:39 --- > this message causes an unusual high amount of support traffic. Does it? This is the first time I have seen a request for a change. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31673
[Bug target/31674] [4.3 Regression] internal consistency failure on ia64 with -O
--- Comment #1 from tbm at cyrius dot com 2007-04-23 21:40 --- Created an attachment (id=13432) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13432&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31674
[Bug c/31673] "`for' loop initial declaration used outside C99 mode" is confusing
--- Comment #3 from j at uriah dot heep dot sax dot de 2007-04-23 21:49 --- (In reply to comment #2) > > this message causes an unusual high amount of support traffic. > > Does it? This is the first time I have seen a request for a change. When I first saw it, it took quite a while until I realized what it's going to tell me. See here for the example that triggered this enhancement request: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=49112#311973 (Just reading that single article is enough, alas the rest of that thread is getting *way* off.) I'm sure though I've been explaining that a number of times before. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31673
[Bug fortran/29786] [4.1/4.2/4.3 Regression] Initialization of overlapping variables: Not implemented
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-04-23 21:50 --- > [EMAIL PROTECTED] 2007-04-23 20:51:45 PriorityP5 P2 The release manager is the only one who is able to change the priority. Changing the Priority back to P5 based on this is a fortran bug so not blocking the release. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29786
[Bug c/31673] "`for' loop initial declaration used outside C99 mode" is confusing
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-04-23 21:57 --- > (Just reading that single article is enough, alas the rest of that > thread is getting *way* off.) Sounds like this is a case of not reading the documentation again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31673
[Bug c/31673] "`for' loop initial declaration used outside C99 mode" is confusing
--- Comment #5 from j at uriah dot heep dot sax dot de 2007-04-23 22:05 --- (In reply to comment #4) > Sounds like this is a case of not reading the documentation again. Well, unlike many others, he even *knew* something about C99, yet he did not grok the error message's content. And he's even an English native speaker, so what do you guess might a non-native speaker run into when trying to parse that sentence? And no, don't expect the translations to become better than the original. ;-) Negated hints (``outside C99 mode'') are almost never easy to understand. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31673
[Bug fortran/31675] New: Fortran front-end and libgfortran should have a common header file
We should have a header file that's used for stuff shared by the front-end and library, such as magic constants used in library functions arguments. It would avoid code duplication between gcc/fortran/gfortran.h and libgfortran.h, with all the benefits of maintainance and readability you can imagine. -- Summary: Fortran front-end and libgfortran should have a common header file Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31675
[Bug c++/30818] [4.1/4.2/4.3 Regression] templates and typedefs cause function prototype not to match
--- Comment #3 from janis at gcc dot gnu dot org 2007-04-23 22:26 --- A regression hunt on powerpc-linux identified this mainline patch: http://gcc.gnu.org/viewcvs?view=rev&rev=116409 r116409 | nathan | 2006-08-25 09:56:07 -0700 (Fri, 25 Aug 2006) This patch was backported to the 4.1 branch on 2006-10-18. -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org, nathan at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30818
[Bug c++/27787] Qualified lookup fails to find inherited class template
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work|2.95.3 3.2.3|2.95.3 3.2.3 4.1.2 Target Milestone|4.2.0 |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27787
[Bug c++/30818] [4.1/4.2/4.3 Regression] templates and typedefs cause function prototype not to match
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org BugsThisDependsOn||27787 Severity|normal |critical Known to work|3.4.6 |3.4.6 4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30818
[Bug fortran/31675] Fortran front-end and libgfortran should have a common header file
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-23 22:40:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31675
[Bug c++/31338] [4.1/4.2/4.3 regression] Cannot apply "!" to complex constants
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31338
[Bug target/31674] [4.3 Regression] internal consistency failure on ia64 with -O
--- Comment #2 from tbm at cyrius dot com 2007-04-23 22:54 ---
Slightly more reduced:
class QString
{
public:QString ();
QString & operator+= (const QString & str);
};
class Qt
{
};
template < class T > class QValueListIterator
{
};
template < class T > class QValueList
{
public:typedef QValueListIterator < T > iterator;
const T & operator[] (long unsigned int i) const
{
}
};
class QNumberSection
{
public: QNumberSection (bool separat):
sep (separat)
{
}
bool separator ()
{
return sep;
}
private:
int act:7;
bool sep:1;
};
class ExtDateTimeEditorPrivate
{
public:
QString separator ()
{
}
QNumberSection section (int idx)
{
return sections[idx];
}
private:
QValueList < QNumberSection > sections;
};
void
ExtDateTimeEditor()
{
ExtDateTimeEditorPrivate *d;
QString txt;
for (unsigned int i = 0; i < 10; ++i)
{
if (d->section (i).separator ())
txt += d->separator ();
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31674
[Bug c++/31498] [4.1 Regression] ICE with vector initializer in template
--- Comment #3 from janis at gcc dot gnu dot org 2007-04-23 23:28 --- A regression hunt on powerpc-linux for mainline shows that it was fixed by this patch: http://gcc.gnu.org/viewcvs?view=rev&rev=122829 r122829 | mmitchel | 2007-03-12 00:26:39 + (Mon, 12 Mar 2007) That patch was added to the 4.2 branch at the same time, and the test now passes on that branch. The failure still occurs on the 4.1 branch as of 2007-04-19. -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31498
[Bug target/31403] wrong branch instructions generated with -m2a on sh-elf
--- Comment #5 from kkojima at gcc dot gnu dot org 2007-04-23 23:43 --- Created an attachment (id=13433) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13433&action=view) proposed patch I'm testing this now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31403
[Bug rtl-optimization/31676] New: test built-in-setjmp.c fails execution with -O1
Test gcc.c-torture/execute/built-in-setjmp.c has failed execution on powerpc*-unknown-linux-gnu with -O1 for both -m32 and -m64 since this mainline patch was added: http://gcc.gnu.org/viewcvs?view=rev&rev=123919 r123919 | rakdver | 2007-04-17 16:42:29 + (Tue, 17 Apr 2007) It started failing in the same way on powerpc-apple-darwin8.5.0 about the same time. Before that it had failed to compile, for all torture options, on Darwin. -- Summary: test built-in-setjmp.c fails execution with -O1 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janis at gcc dot gnu dot org GCC target triplet: powerpc*-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31676
[Bug rtl-optimization/31676] [4.3 Regression] test built-in-setjmp.c fails execution with -O1
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org OtherBugsDependingO||31360 nThis|| Severity|normal |blocker Summary|test built-in-setjmp.c fails|[4.3 Regression] test built- |execution with -O1 |in-setjmp.c fails execution ||with -O1 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31676
[Bug rtl-optimization/31676] [4.3 Regression] test built-in-setjmp.c fails execution with -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 |2007-04-24 00:00:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31676
[Bug tree-optimization/31677] New: gcc.dg/memcpy-1.c tree dump scan fails on several targets
Test gcc.dg/memcpy-1.c, added on 2006-11-28, has always failed the "optimized"
tree dump scan on powerpc64-unknown-linux-gnu. The contents of the scanned
file
are:
;; Function test (test)
Analyzing Edge Insertions.
test (a)
{
int nasty_local$a;
struct a nasty_local;
:
nasty_local.a = nasty_local$a;
nasty_local = a;
return nasty_local.a;
}
The dump from a compiler from before this test (and associated fix) were added
includes a call to __builtin_memcpy. Should the test check for that string
instead of looking for "nasty_local", or is there a real problem that needs to
be fixed?
The same failure also shows up in archived test results for these targets:
arm-non-eabi
mipsel-unknown-linux-gnu
powerpc-apple-darwin8.5.0
powerpc-ibm-aix5.2.0.0
s390-ibm-linux-gnu
sh4-unknown-linux-gnu
--
Summary: gcc.dg/memcpy-1.c tree dump scan fails on several
targets
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31677
[Bug tree-optimization/31677] gcc.dg/memcpy-1.c tree dump scan fails on several targets
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-24 00:30 --- A couple of issues here: nasty_local.a = nasty_local$a; is a SRA issue and that should not be needed. The rest is just SRA not doing element copy for the struct (it is not a big issue) and the testcase should just include "--param sra-max-structure-size=32" because what it is testing is that SRA can do the element copy with the removal of memcpy. -- 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 |2007-04-24 00:30:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31677
[Bug rtl-optimization/31676] [4.3 Regression] test built-in-setjmp.c fails execution with -O1
--- Comment #1 from rakdver at gcc dot gnu dot org 2007-04-24 00:32 --- ppc64-linux does not build just now, I will fix the problem once it does again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31676
[Bug c/31678] New: invalid C99 code accepted with warning
int test(int* A, int B) { return A < B; }
$ gcc t.c -fsyntax-only -pedantic -ansi -std=c99
t.c: In function 'test':
t.c:3: warning: comparison between pointer and integer
According to C99 6.5.8p2, this should be rejected.
-Chris
--
Summary: invalid C99 code accepted with warning
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sabre at nondot dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31678
[Bug c/31678] invalid C99 code accepted with warning
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-24 00:46 --- You have to use -pedantic-errors to get the error. -- 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=31678
[Bug c/31678] invalid C99 code accepted with warning
--- Comment #2 from sabre at nondot dot org 2007-04-24 01:14 --- Doh, right, thanks! :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31678
