[Bug c++/29522] New: [4.0 Regression] rejects valid template argument
Testcase:
template< int C > int assertion_failed( int);
template< class >
struct N
{
static int const okay = 1;
static int const
t = sizeof( assertion_failed( 0))
;
};
int main()
{
N n;
return n.t;
}
--
Summary: [4.0 Regression] rejects valid template argument
Product: gcc
Version: 4.0.4
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29522
[Bug c++/29522] [4.0 Regression] rejects valid template argument
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-20 07:24 --- Note I could not find this bug filed so I filed it. Also note I found it while looking at PR 29518. Oh and the error message is: [EMAIL PROTECTED] ~]$ ~/gcc-4.0/bin/gcc t.cc t.cc: In instantiation of const int N::t: t.cc:13: instantiated from here t.cc:7: error: N::okay is not a valid template argument for type int because it is a non-constant expression t.cc:7: error: no matching function for call to assertion_failed(int) -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.0.4 Known to work||3.2.3 4.1.2 4.2.0 Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29522
[Bug c++/29518] [4.0/4.1/4.2 Regression] rejects valid template argument, enums vs templates
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-10-20 07:25 --- Note I found a related regression in 4.0.4 only and I filed that as PR 29522. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.0.2 4.1.0 4.2.0 |4.0.2 4.1.0 4.2.0 4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29518
[Bug c++/29486] call of friend template is ambiguous
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-10-20 07:33 --- Yes this is a dup of bug 29236. *** This bug has been marked as a duplicate of 29236 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Keywords||rejects-valid Known to work||2.95.3 Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29486
[Bug c++/29236] [4.0/4.1/4.2 Regression] Bogus ambiguity with templates + friend
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-10-20 07:33 --- *** Bug 29486 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29236
[Bug c++/29438] [4.0/4.1/4.2 Regression] Friendship problem
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-20 07:34 --- Yes this is a dup of bug 29236 which has a similar testcase and more discussion on the actually problem. *** This bug has been marked as a duplicate of 29236 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29438
[Bug c++/29236] [4.0/4.1/4.2 Regression] Bogus ambiguity with templates + friend
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-10-20 07:34 --- *** Bug 29438 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pcarlini at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29236
[Bug c++/29417] [4.2 Regression] link fails with debug and anonymous namespace
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-10-20 07:42 --- (In reply to comment #5) > A regression hunt on powerpc-linux identified the following patch: This just confirms the problem here is the same as listed in PR 27657 as that patch cause anonymous namespace to be local linkage. Closing as a dup of PR 27657. *** This bug has been marked as a duplicate of 27657 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29417
[Bug middle-end/27657] [4.2 regression] bogus undefined reference error to static var with -g and -O
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-10-20 07:42 --- *** Bug 29417 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||peter at chocky dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27657
[Bug c++/29517] Exception handling not thread-safe on AIX5.x with Gnu compilers
--- Comment #4 from Ulrich dot Beingesser at t-systems dot com 2006-10-20 07:53 --- Created an attachment (id=12466) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12466&action=view) gdb backtrace info Shows complete sequence how program is build, run, crashes and gdb backtrace on AIX5.2. On AIX5.3 the same conditions occur, but there we have no gdb available yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29517
[Bug c++/29517] Exception handling not thread-safe on AIX5.x with Gnu compilers
--- Comment #5 from Ulrich dot Beingesser at t-systems dot com 2006-10-20 08:08 --- Created an attachment (id=12467) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12467&action=view) backtrace info case 2 Shows backtrace info for scenario when program crashes due to signal 11 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29517
[Bug c++/29517] Exception handling not thread-safe on AIX5.x with Gnu compilers
--- Comment #6 from Ulrich dot Beingesser at t-systems dot com 2006-10-20 08:10 --- Created an attachment (id=12468) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12468&action=view) backtrace info 3 Shows backtrace info for scenario when program crashes due to signal 4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29517
[Bug tree-optimization/28778] [4.0/4.1 Regression] alias bug with cast and call clobbered
--- Comment #45 from rguenth at gcc dot gnu dot org 2006-10-20 08:24 --- Still not fixed on the branches. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Known to fail|4.0.0 4.1.0 4.2.0 |4.0.0 4.1.0 Known to work|3.4.0 |3.4.0 4.2.0 Resolution|FIXED | Summary|[4.0/4.1/4.2 Regression]|[4.0/4.1 Regression] alias |alias bug with cast and call|bug with cast and call |clobbered |clobbered http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28778
[Bug c/29521] Confusing warning for return with expression in function returning void
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-10-20 09:09 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-20 09:09:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29521
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #16 from pault at gcc dot gnu dot org 2006-10-20 09:20 ---
The problem is specific to old-style initializers, as
program FOO
real :: x = 2.0 q
real z /2.0/ q
end program FOO
shows (comment out each declaration in turn!).
Grepping on the first error message leads us to decl.c(gfc_match_data_decl).
Proceeding to the Doxygen documentation, we find right away that there is
nothing in the loop over variables that would distinguish old-style data, so
this must happen in variable_decl.
eh voila!
01186 return match_old_style_init (name);
In this function, we find that the gfc_data, it produces, contains an
expression that points to the symtree for the variable. In ALL OTHER error
routes, this gfc_data is freed so that the hanging pointer to the symtree and
to the soon to be non-existent symbol is removed.
match_old_style_init returns SUCCESS and so has hung the gfc_data entry onto
gfc_current_ns->data where it remains until the compiler splutters its last on
trying to swallow it.
Once we figure that, we know right away that this fixes the problem:
Index: gcc/fortran/decl.c
===
*** gcc/fortran/decl.c (révision 117879)
--- gcc/fortran/decl.c (copie de travail)
*** ok:
*** 2368,2373
--- 2368,2384
gfc_error ("Syntax error in data declaration at %C");
m = MATCH_ERROR;
+ /* Check if there are any old fashioned data statements around.
+ If there are, they risk leaving dangling symtree references
+ and do nothing for us since an error has occurred. */
+ for (;gfc_current_ns->data;)
+ {
+ gfc_data *d;
+ d = gfc_current_ns->data->next;
+ gfc_free (gfc_current_ns->data);
+ gfc_current_ns->data =d;
+ }
+
cleanup:
gfc_free_array_spec (current_as);
current_as = NULL;
This is not checked for breakages or regtested but I believe that it is the
right solution.
It does not fix PR18923 but I think that something similar is at play and could
be investigated in the same way.
(Jerry, I am preparing to depart on a trip; I would be happy if you would
finish off the development of this patch because I cannot return to it for at
least a week.)
Regards
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug libstdc++/10534] wcout can only print ASCII,can't print other language,eg. chinese.
--- Comment #3 from bkoz at gcc dot gnu dot org 2006-10-20 09:28 ---
Ie:
#include
int
main()
{
using namespace std;
const wchar_t w1 = { 0x4e2d };// U+20013 == 0x4E2D
const wchar_t w2 = { 0x56fd };// U+22269 == 0x56FD
const wchar_t w3(20013);
const wchar_t w4(22269);
locale loc("zh_CN.utf8");
locale::global(loc);
wcout << w1 << endl;
wcout << w2 << endl;
wcout << w3 << endl;
wcout << w4 << endl;
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10534
[Bug fortran/29523] New: ICE with some non up-to date .mod files
Hi, I got the following error message when I do just âmakeâ on my program. Running âmake clean && makeâ solves the problem, but gcc should give some useful error message: gfortran -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\" -I. -I../../src-I ../../includes -I potentials -I tools -I lattices -I Verfahren -I filter -O3 -funsafe-loop-optimizations -Wunsafe-loop-optimizations -ftree-loop-linear -ftree-loop-im -ftree-vectorize -funroll-loops -fprefetch-loop-arrays -fvariable-expansion-in-unroller -freorder-blocks-and-partition -ffast-math -ffinite-math-only -fno-trapping-math -funswitch-loops -finline-limit=6000 -c -o diffussion.o ../../src/diffussion.F90 ../../src/diffussion.F90: In Funktion »main_program«: ../../src/diffussion.F90:161: interner Compiler-Fehler: in gfc_get_derived_type, bei fortran/trans-types.c:1450 Bitte senden Sie einen vollständigen Fehlerbericht auf Englisch ein; bearbeiten Sie die Quellen zunächst mit einem Präprozessor, wenn es dienlich ist. Fehler in der deutschen Ãbersetzung sind an [EMAIL PROTECTED] zu melden. Gehen Sie gemäà den Hinweisen in http://gcc.gnu.org/bugs.html> vor. For Debian GNU/Linux specific bug reporting instructions, see . -- Sorry, I don't know, how to reproduce it. But maybe it will be useful anyway. Tobias -- Summary: ICE with some non up-to date .mod files Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: keinstein_junior at gmx dot net GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29523
[Bug c/29524] New: Too much RAM used: __clz_tab[] linked
I noticed that the amount of RAM used, compared to the code generated by gcc 4.1.1, is increased by 256 bytes and found that this it's due to the __clz_tab array linked in at RAM start. -- Summary: Too much RAM used: __clz_tab[] linked Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: batt at develer dot com GCC build triplet: 20061014 GCC host triplet: i686-pc-linux-gnu GCC target triplet: avr-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29524
[Bug c++/29525] New: boost 1.34.0 (testing release) mpl multiset test fails to compile
Attached is a preprocessed file that generates the following error (just the
first one of a group shown):
% g++ -ftemplate-depth-128 -O0 -fno-inline -Wall -g -fPIC -D_GLIBCXX_DEBUG=1
-DBOOST_ALL_NO_LIB=1 -I. -c -o multiset.o libs/mpl/test/multiset.cpp
libs/mpl/test/multiset.cpp: In function 'void count_test() [with T =
test_data >]':
libs/mpl/test/multiset.cpp:75: instantiated from here
libs/mpl/test/multiset.cpp:61: error:
'(((int)boost::mpl::count_impl::apply,
int>::value) == 0)' is not a valid template argument for type 'bool' because it
is a non-constant expression
libs/mpl/test/multiset.cpp:61: error: no matching function for call to
'assertion_failed(mpl_::failed mpl_::assert_relation::)'
...etc...
The (non-processed) line that causes this is:
{
MPL_ASSERT_RELATION( ( count::value ), ==, 0
);
//...
}
This problem also appears to exist on 4.0.3 and 4.1.0. (See, for example, the
reports on
http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/mpl_release.html)
What is interesting(?) is that if the following line is inserted before the
MPL_ASSERT_RELATION line, then the error goes away:
enum { v1 = count::value };
--
Summary: boost 1.34.0 (testing release) mpl multiset test fails
to compile
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at derived-software dot ltd dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29525
[Bug c++/29525] boost 1.34.0 (testing release) mpl multiset test fails to compile
--- Comment #1 from gcc at derived-software dot ltd dot uk 2006-10-20 14:15 --- Created an attachment (id=12469) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12469&action=view) gzip'd preprocessed output of libs/mpl/test/multiset.cpp from boost 1.34 branch Generated with: g++ -ftemplate-depth-128 -O0 -fno-inline -Wall -g -fPIC -D_GLIBCXX_DEBUG=1 -DBOOST_ALL_NO_LIB=1 -I. libs/mpl/test/multiset.cpp -E >~/multiset.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29525
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #17 from jvdelisle at gcc dot gnu dot org 2006-10-20 14:27 --- This does not fix it, but I think the idea is in the right direction. There are multiple error return paths like this that are not cleaning up enough. This explains why making variations on the test case gives several different errors and results. I will pursue to completion. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #18 from jvdelisle at gcc dot gnu dot org 2006-10-20 14:33 --- Correction: The patch in #16 fixes the case in #11. However I have several other variations on this that are taking a different error path. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug c++/29518] [4.0/4.1/4.2 Regression] rejects valid template argument, enums vs templates
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-10-20 14:34 --- *** Bug 29525 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||news at derived-software dot ||ltd dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29518
[Bug c++/29525] boost 1.34.0 (testing release) mpl multiset test fails to compile
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-10-20 14:34 --- *** This bug has been marked as a duplicate of 29518 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29525
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #19 from pault at gcc dot gnu dot org 2006-10-20 14:35 --- Thank goodne for that - I thought that I was going batty! Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug middle-end/29524] Too much RAM used: __clz_tab[] linked
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-10-20 14:39 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||nickc at redhat dot com Status|UNCONFIRMED |NEW Component|c |middle-end Ever Confirmed|0 |1 GCC build triplet|20061014| GCC host triplet|i686-pc-linux-gnu | Last reconfirmed|-00-00 00:00:00 |2006-10-20 14:39:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29524
[Bug fortran/29523] ICE with some non up-to date .mod files
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-10-20 14:43 --- Can you provide some details on the out of date .mod files? Were they compiled with a different compiler version or on a different architecture? Or are they just not up-to-date with the source? In the latter case you should adjust your makefile to honour dependencies and rebuild the .mod files appropriately. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29523
[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
--- Comment #12 from ghazi at gcc dot gnu dot org 2006-10-20 15:53 --- Third patch revision posted here: http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01039.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- |http://gcc.gnu.org/ml/gcc- |patches/2006- |patches/2006- |10/msg00757.html|10/msg01039.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335
[Bug other/29524] Too much RAM used: __clz_tab[] linked
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-20 15:58 --- First off this should not matter as it should not be linked in as it is not used at all. Do you have a testcase which it links it in? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Component|middle-end |other http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29524
[Bug other/29524] Too much RAM used: __clz_tab[] linked
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-20 16:19 --- In fact this works correctly on the SPU target so I think avr is broken or you are really using __builtin_clz. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29524
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2006-10-20 16:25 --- To make you feel better. I have found the other spots. Those are fixed as well and regression tested AOK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug ada/26306] Use of volatile array with bounds determined at run time.
--- Comment #4 from jeff at thecreems dot com 2006-10-20 16:56 --- I just did a fresh Gcc build today this no longer appears to be a problem URL: svn://gcc.gnu.org/svn/gcc/trunk Repository Root: svn://gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 117904 Node Kind: directory Schedule: normal Last Changed Author: fxcoudert Last Changed Rev: 117904 Last Changed Date: 2006-10-20 07:52:56 -0400 (Fri, 20 Oct 2006) Properties Last Updated: 2006-10-20 09:33:34 -0400 (Fri, 20 Oct 2006) [EMAIL PROTECTED] mat_test]$ gcc -c scratch.adb [EMAIL PROTECTED] mat_test]$ gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc/configure --disable-checking --enable-languages=c,fortran,ada --prefix=/home/jcreem/local Thread model: posix gcc version 4.2.0 20061020 (experimental) -- jeff at thecreems dot com changed: What|Removed |Added CC||jeff at thecreems dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26306
[Bug ada/24726] Gigi abort, Code=508
--- Comment #4 from jeff at thecreems dot com 2006-10-20 17:01 --- Seems fixed in trunk Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc/configure --disable-checking --enable-languages=c,fortran,ada --prefix=/home/jcreem/local Thread model: posix gcc version 4.2.0 20061020 (experimental) [EMAIL PROTECTED] bg]$ gcc -c elements-sets.adb [EMAIL PROTECTED] bg]$ -- jeff at thecreems dot com changed: What|Removed |Added CC||jeff at thecreems dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24726
[Bug ada/24079] Ada FE ICE on protected procedure with default argument (invalid?)
--- Comment #2 from jeff at thecreems dot com 2006-10-20 17:03 --- Still there in head gcc -c bug.adb +===GNAT BUG DETECTED==+ | 4.2.0 20061020 (experimental) (i686-pc-linux-gnu) Assert_Failure atree.adb:812 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24079
[Bug testsuite/29527] New: make clean in libiberty/testsuite does nothing under cygwin
The current rule for make clean on libiberty/testsuite doesn't append EXEEXT, so make clean doesn't perform as expected under cygwin. The following patch resolves this; please test/commit Phil Lello Index: libiberty/testsuite/Makefile.in === --- libiberty/testsuite/Makefile.in (revision 117909) +++ libiberty/testsuite/Makefile.in (working copy) @@ -77,9 +77,9 @@ # The standard clean rules. mostlyclean: - rm -f test-demangle - rm -f test-pexecute - rm -f test-expandargv + rm -f [EMAIL PROTECTED]@ + rm -f [EMAIL PROTECTED]@ + rm -f [EMAIL PROTECTED]@ clean: mostlyclean distclean: clean rm -f Makefile -- Summary: make clean in libiberty/testsuite does nothing under cygwin Product: gcc Version: unknown Status: UNCONFIRMED Severity: minor Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: phil dot lello at homecall dot co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29527
[Bug c++/28053] [4.2 regression] ICE deriving from class with invalid bitfield
--- Comment #4 from lmillward at gcc dot gnu dot org 2006-10-20 20:13 --- Subject: Bug 28053 Author: lmillward Date: Fri Oct 20 20:13:42 2006 New Revision: 117910 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117910 Log: PR c++/28053 * decl2.c (grokbitfield): Detect invalid non-integral types earlier when possible. * g++.dg/parse/bitfield1.C: Adjust error markers. * g++.dg/parse/bitfield2.C: New test. Added: trunk/gcc/testsuite/g++.dg/parse/bitfield2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/parse/bitfield1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28053
[Bug c++/28053] [4.2 regression] ICE deriving from class with invalid bitfield
--- Comment #5 from lmillward at gcc dot gnu dot org 2006-10-20 20:14 --- Fixed in 4.2. -- lmillward at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28053
[Bug java/29528] New: [ecj] update gcjh documentation
gcjh has been removed from the gcj-eclipse branch, but the documentation remains. Once we've imported a new Classpath (and with it, the new gcjh), we must update the documentation to reflect the changes. Probably this documentation should be pushed upstream to Classpath. -- Summary: [ecj] update gcjh documentation Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tromey at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29528
[Bug c++/29529] New: purify with iostream reports 128 uninitialized memory reads
When I compile this code:
#include
int main(void)
{
}
with g++, instrumented with the "purify" utility, purify reports
the following:
UMR: Uninitialized memory read (128 times)
This is occurring while in:
__gconv_get_alias_db [libc.so.6]
wctob [libc.so.6]
std::ctype< wchar_t>::_M_initialize_ctype( void) [libstdc++.so.6]
std::ctype< wchar_t>::ctype( unsigned) [libstdc++.so.6]
std::locale::_Impl::_Impl( unsigned) [libstdc++.so.6]
std::locale::_Impl::_Impl( unsigned) [libstdc++.so.6]
Reading 4 bytes from 0xbfa77a24 on the stack.
Address 0xbfa77a24 is 84 bytes below frame pointer in function wctob
Dunno if this is a g++ problem, purify problem, OS problem, system
library problem, not really an error, or whatever, but it would be
nice to make it go away.
System/compiler info:
uname -a
Linux banat 2.6.15-26-686 #1 SMP PREEMPT Mon Jul 17 20:14:14 UTC 2006
i686 GNU/Linux
g++ --version
g++ (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5)
Without , no problem.
--
Summary: purify with iostream reports 128 uninitialized memory
reads
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mstaley at lanl dot gov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29529
[Bug libstdc++/29529] purify with iostream reports 128 uninitialized memory reads
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-20 21:34 --- This is most likely a purify problem. Have you tried using valgrind instead? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |libstdc++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29529
[Bug bootstrap/29531] New: REG: --disable-bootstrap && make bootstrap doesn't work
If one configures with --disable-boostrap --enable-languages=c and then builds with make bootstrap but doesn't have ada installed, the build fails. The problem is that gcc/configure unconditionally adds ada to the stage 1 languages BOOT_LANGUAGES, even though --enable-languages=c is used. In non--disable-boostrap builds I think this was fixed by the patch in: http://gcc.gnu.org/PR24252 (that was incorrectly attached to the wrong PR, but the patch is the one that seems to cause it to work). This is a regression -- Summary: REG: --disable-bootstrap && make bootstrap doesn't work Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mrs at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29531
[Bug bootstrap/29531] REG: --disable-bootstrap && make bootstrap doesn't work
--- Comment #1 from mrs at apple dot com 2006-10-20 22:09 --- I think something like: Doing diffs in configure.ac.~1~: --- configure.ac.~1~2006-10-16 12:38:48.0 -0700 +++ configure.ac2006-10-20 15:00:44.0 -0700 @@ -3419,6 +3419,16 @@ changequote([,])dnl done ;; esac + if test "$language" = ada + then + case ",$enable_languages," in + *,ada,*) ;; + *,all,*) ;; + *) + ok=false + ;; + esac + fi $ok || continue all_lang_makefrags="$all_lang_makefrags \$(srcdir)/$subdir/Make-lang.in" -- fixes this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29531
[Bug ada/28682] [4.2 Regression] --enable-languages=c,c++ for cross compiler builds Ada compiler
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-20 22:11 --- Reopening. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | Summary|--enable-languages=c,c++ for|[4.2 Regression] --enable- |cross compiler builds Ada |languages=c,c++ for cross |compiler|compiler builds Ada compiler Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28682
[Bug bootstrap/29531] REG: --disable-bootstrap && make bootstrap doesn't work
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-20 22:12 --- This is the same issue as PR 28682. Though --disable-bootstrap should not be used unless you really know what you are doing as soon (for 4.3), make bootstrap with --disable-bootstrap will always break for libgcc being at the toplevel. *** This bug has been marked as a duplicate of 28682 *** *** This bug has been marked as a duplicate of 28682 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29531
[Bug ada/28682] [4.2 Regression] --enable-languages=c,c++ for cross compiler builds Ada compiler
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-20 22:12 --- *** Bug 29531 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||mrs at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28682
[Bug ada/28682] [4.2 Regression] --enable-languages=c,c++ for cross compiler builds Ada compiler
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-20 22:13 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-20 22:13:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28682
[Bug bootstrap/29531] REG: --disable-bootstrap && make bootstrap doesn't work
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-20 22:14 --- Actually why are you trying to do a make bootstrap with --disable-bootstrap anyways? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29531
[Bug bootstrap/29531] REG: --disable-bootstrap && make bootstrap doesn't work
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-20 22:15 --- Oh and the problem is not a bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29531
[Bug bootstrap/29531] REG: --disable-bootstrap && make bootstrap doesn't work
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-20 22:15 --- It is not a bug because bootstrap should be broken with --disable-bootstrap even more than it is currently is, it really should be removed at that point. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29531
[Bug ada/28682] [4.2 Regression] --enable-languages=c,c++ for cross compiler builds Ada compiler
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-20 22:16 --- As mentioned this was invalid because HJL used the wrong make target. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28682
[Bug bootstrap/29531] REG: --disable-bootstrap && make bootstrap doesn't work
--- Comment #6 from mrs at apple dot com 2006-10-20 22:29 --- If the decision is to rip out mass amounts of code for bootstrapping in stage3, well, that can be done, but unless that it is done, this is a bug. If it is to be done, that it is a bug that it isn't done. As for WONTFIX, well, I already did fix it, so that isn't quite true. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29531
[Bug bootstrap/29531] REG: --disable-bootstrap && make bootstrap doesn't work
--- Comment #7 from mrs at apple dot com 2006-10-20 22:33 --- I'd like my patch to be considered for 4.2, seems safee enough. -- mrs at apple dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29531
[Bug bootstrap/29531] REG: --disable-bootstrap && make bootstrap doesn't work
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-10-20 22:56 --- I saw we forget about --disable-bootstrap and work on other regressions. Like the P1s on ppc-darwin that has been there for a while now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29531
[Bug bootstrap/29531] REG: --disable-bootstrap && make bootstrap doesn't work
--- Comment #9 from mrs at apple dot com 2006-10-20 23:24 --- I spent a minute upgrading my build system to handle the new world order that's coming down the pike in 4.3... The problem I thought I might hit didn't happen, so, I'm fine with this being WONTFIX. I now do a bootstrap by not using the --disable-bootstrap configure option. -- mrs at apple dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29531
[Bug fortran/17741] ICE in gfc_free_namespace, at fortran/symbol.c:2208
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-10-21 00:16 --- I will see what I can figure out here now. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-09-03 21:39:48 |2006-10-21 00:16:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17741
[Bug fortran/29532] New: [4.1 regression] test suite failures
comparing the 20061007 and the 20061020 build on amd64-linux-gnu I see the following regressions (Debian amd64 unstable): +FAIL: gfortran.dg/io_constraints_1.f90 -O (test for errors, line 73) +FAIL: gfortran.dg/io_constraints_1.f90 -O (test for excess errors) Matthias -- Summary: [4.1 regression] test suite failures Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: debian-gcc at lists dot debian dot org GCC target triplet: amd64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29532
[Bug ada/29533] New: Ada fails to vectorize even trivial loops
While there might exist a case that can be vectorized, a few of the simple cases that should be easy that I have tried are not able to be vectorized. For example, the following package compare_lang is type the_range is range 0 .. 100; type My_Array is array (the_range) of Float; a, b, c : my_array; procedure do_compare; end compare_lang; package body compare_lang is procedure do_compare is begin for JJJ in the_range loop a(jjj) := b(jjj) * c(jjj); end loop; end do_compare; end compare_lang; gcc -c -O3 -gnatp -march=pentium4 -mfpmath=sse -msse3 -ftree-vectorize -ftree-vectorizer-verbose=5 compare_lang.adb compare_lang.adb:5: note: not vectorized: complicated access pattern. compare_lang.adb:3: note: vectorized 0 loops in function. Obviously similar structures C vectorize fine. -- Summary: Ada fails to vectorize even trivial loops Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jeff at thecreems dot com GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29533
[Bug middle-end/29533] Ada fails to vectorize even trivial loops
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-21 03:42 --- This is related to subtypes. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|ada |middle-end Version|unknown |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29533
[Bug c++/28088] [4.1 Regression] Internal compiler error on boost mpl test/apply.cpp
--- Comment #9 from bangerth at dealii dot org 2006-10-21 04:28 --- Mark, is there any way for a backport of your patch to the 4.1 branch? This appears to be a regression involving boost, and I got word from people whose codes break with 4.1.x because of this... Thanks W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28088
