[Bug java/21245] New: gcjh creates invalid/empty header files
While trying to adapt a patch from GNU classpath to libgcj I found that gcjh was failing to build a CNI header from a class file. I accidently deleted my terminal and lost the command output. So I tried again and the bug seemed to have vanished. After some investigation I found the following: gcjh prints this error "gcjh: static field has same name as method" (see attached testcase) and produces a header file which looks okay. This file contains buggy C++ code because it contains a static variable and a static method with the same name. Make then saw the buggy header file and saw its done, do the next step. gcjh should bail out for real and not generate a buggy output file. -- Summary: gcjh creates invalid/empty header files Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: konqueror at gmx dot de CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21245
[Bug libstdc++/21244] Confusion in template instantiation
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27 07:13 --- The first example is invalid is a dup of bug 19404. Now the second example looks to be a bug in libstdc++. -- What|Removed |Added Component|c++ |libstdc++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21244
[Bug java/21245] gcjh creates invalid/empty header files
--- Additional Comments From konqueror at gmx dot de 2005-04-27 07:17 --- Created an attachment (id=8749) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8749&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21245
[Bug c++/21246] New: Compiler fails when using and incrementing a variable i: f(i,++i) equivalent to f(i+1,i+1); ++i
The next code, should show int the screen "a:2 b:3"; but shows "a:3 b:3".
I have tested it into several versions from 3.3 to 4.0. Always the same result.
void foo(int a,int b)
{
std::cout<<"a:"
[Bug c++/21246] Compiler fails when using and incrementing a variable i: f(i,++i) equivalent to f(i+1,i+1); ++i
-- What|Removed |Added Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21246
[Bug libstdc++/21238] conflicting "typedef __numpunct_cache<_CharT> __cache_type;" in std::numpunct makes specialization impossible
-- What|Removed |Added CC||pcarlini at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21238
[Bug libstdc++/21244] Confusion in template instantiation
--- Additional Comments From pcarlini at suse dot de 2005-04-27 08:54
---
The second example seems to me also a duplicate of 19404. This is a reduced
testcase:
class Foo { };
template void operator/(const Foo&, T);
enum { _S_word_bit = 1 };
class vector_bool
{ void _M_allocate() { (_S_word_bit - 1) / _S_word_bit; } };
vector_bool bar;
Andrew, can you confirm?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21244
[Bug middle-end/20794] [4.0/4.1 Regression] Arrays and pointer arithmetic on __attribute ((aligned)) types permitted
--- Additional Comments From dorit at il dot ibm dot com 2005-04-27 08:59 --- (In reply to comment #18) > I submitted a patch, http://gcc.gnu.org/ml/gcc-patches/2005-04/msg02284.html, > but as the mail says it results in a lot of regressions in the compat and > vector tests. I'll see what I can do about the vector tests. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20794
[Bug libstdc++/21244] Confusion in template instantiation
--- Additional Comments From dominik dot strasser at infineon dot com
2005-04-27 09:07 ---
(In reply to comment #4)
> The second example seems to me also a duplicate of 19404. This is a reduced
> testcase:
>
> class Foo { };
> template void operator/(const Foo&, T);
> enum { _S_word_bit = 1 };
> class vector_bool
> { void _M_allocate() { (_S_word_bit - 1) / _S_word_bit; } };
> vector_bool bar;
>
> Andrew, can you confirm?
The following patch cures the problem for me:
--- ./libstdc++-v3/include/bits/stl_bvector.h 2005-01-31 17:21:55.0
+0100
+++ /tmp/stl_bvector.h 2005-04-27 11:05:44.0 +0200
@@ -64,7 +64,7 @@
namespace _GLIBCXX_STD
{
typedef unsigned long _Bit_type;
- enum { _S_word_bit = int(CHAR_BIT * sizeof(_Bit_type)) };
+ static const int _S_word_bit = int(CHAR_BIT * sizeof(_Bit_type));
struct _Bit_reference
{
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21244
[Bug libstdc++/21244] Confusion in template instantiation
--- Additional Comments From dominik dot strasser at infineon dot com 2005-04-27 09:09 --- Created an attachment (id=8750) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8750&action=view) Use const static member instead of enum -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21244
[Bug c++/21244] Confusion in template instantiation
--- Additional Comments From pcarlini at suse dot de 2005-04-27 09:15 --- No, we don't want to change the implementation of the library in case of user error. Really, this is a duplicate of 19404. *** This bug has been marked as a duplicate of 19404 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|libstdc++ |c++ Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21244
[Bug c++/19404] [4.0 Regression] anonymous types and templates and rejecting valid code
--- Additional Comments From pcarlini at suse dot de 2005-04-27 09:15 --- *** Bug 21244 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||dominik dot strasser at ||infineon dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19404
[Bug c++/21244] Confusion in template instantiation
--- Additional Comments From pcarlini at suse dot de 2005-04-27 09:24 --- On second thought, maybe we can safely change the enum to not be anonymous... -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21244
[Bug libstdc++/21244] Confusion in template instantiation
-- What|Removed |Added Component|c++ |libstdc++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21244
[Bug libstdc++/21244] Confusion in template instantiation
--- Additional Comments From dominik dot strasser at infineon dot com 2005-04-27 09:28 --- (In reply to comment #8) > On second thought, maybe we can safely change the enum to not be anonymous... I think so, too as I can't see any user error in the second example. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21244
[Bug libstdc++/21244] Confusion in template instantiation
--- Additional Comments From pcarlini at suse dot de 2005-04-27 09:37 --- Yes, you are right, but I don't want to fiddle too much with that constant, in particular risking to change its size (the standard doesn't guarantee that the underlying type of that anonymous enum is int), seems safer just changing the enum to be named. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21244
[Bug ada/21247] New: Cross-building gnat-4.0.0 requires native gnat-4.0.0
Bootstrapping a gcc-4.0.0/gnat cross-toolchain on FC3 using the native FC3-gcc-3.4.3-22.fc3 toolchain fails with: # ../gcc-4.0.0/configure --target=i386-rtems4.7 --enable-languages=c,ada --disable-multilib --prefix=/opt/rtems-4.7 --with-gnu-as --with-gnu-ld --with-newlib --with-system-zlib --disable-nls --enable-version- specific-runtime-libs --enable-threads=rtems ... make ... gnatmake -I/usr/lib/gcc/i386-redhat-linux/3.4.3/adalib/../adainclude -I/usr/lib/gcc/i386-redhat-linux/3.4.3/adalib/ -I. -I/home/columbo/src/rpms/BUILD/rtems-4.7-i386-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/gcc/ada -u sdefault --GCC="gcc " gcc -c -I/usr/lib/gcc/i386-redhat-linux/3.4.3/adalib/../adainclude -I/usr/lib/gcc/i386-redhat-linux/3.4.3/adalib/ -I. -I/home/columbo/src/rpms/BUILD/rtems-4.7-i386-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/gcc/ada sdefault.adb gnatmake -c -I/usr/lib/gcc/i386-redhat-linux/3.4.3/adalib/../adainclude -I/usr/lib/gcc/i386-redhat-linux/3.4.3/adalib/ -I. -I/home/columbo/src/rpms/BUILD/rtems-4.7-i386-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/gcc/ada gnatmake --GCC="gcc -O2 -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -gnatpg -gnata" gcc -c -I./ -I/usr/lib/gcc/i386-redhat-linux/3.4.3/adalib/../adainclude -I/usr/lib/gcc/i386-redhat-linux/3.4.3/adalib/ -I. -I/home/columbo/src/rpms/BUILD/rtems-4.7-i386-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/gcc/ada -O2 -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -gnatpg -gnata -I- /home/columbo/src/rpms/BUILD/rtems-4.7-i386-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/gcc/ada/gnatmake.adb gcc -c -I./ -I/usr/lib/gcc/i386-redhat-linux/3.4.3/adalib/../adainclude -I/usr/lib/gcc/i386-redhat-linux/3.4.3/adalib/ -I. -I/home/columbo/src/rpms/BUILD/rtems-4.7-i386-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/gcc/ada -O2 -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -gnatpg -gnata -I- /home/columbo/src/rpms/BUILD/rtems-4.7-i386-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/gcc/ada/gnatvsn.adb gcc -c -I./ -I/usr/lib/gcc/i386-redhat-linux/3.4.3/adalib/../adainclude -I/usr/lib/gcc/i386-redhat-linux/3.4.3/adalib/ -I. -I/home/columbo/src/rpms/BUILD/rtems-4.7-i386-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/gcc/ada -O2 -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -gnatpg -gnata -I- /home/columbo/src/rpms/BUILD/rtems-4.7-i386-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/gcc/ada/make.adb ali.ads:187:22: "Restrictions_Info" is undefined (more references follow) gnatmake: "/home/columbo/src/rpms/BUILD/rtems-4.7-i386-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/gcc/ada/make.adb" compilation error make[3]: *** [gnatmake-re] Error 4 Using a native gcc-4.0.0, the same succeeds. -- Summary: Cross-building gnat-4.0.0 requires native gnat-4.0.0 Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: corsepiu at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org,joel at oarcorp dot com,laurent at guerby dot net GCC host triplet: i686-redhat-linux GCC target triplet: !=host http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21247
[Bug libfortran/20436] [4.0 only] using nested reshape functions gives runtime error
-- What|Removed |Added Known to fail||4.0.0 Known to work||4.1.0 Summary|usring nested reshape |[4.0 only] using nested |functions gives runtime |reshape functions gives |error |runtime error Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20436
[Bug libstdc++/21244] [4.0/4.1 Regression] Vector anonymous enum problem
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-27 10:26:35 date|| Summary|Confusion in template |[4.0/4.1 Regression] |instantiation |Vector anonymous enum ||problem http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21244
[Bug c++/21248] New: internal compiler error
Building kdelibs 3.4 with gcc 4.0.0 on i686-pc-linux-gnu. Failed with "internal compiler error" on kimgio/exr.cpp. Command line as follows: /bin/sh ../libtool --silent --mode=compile --tag=CXX g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../dcop -I../kdecore -I../kio/kssl -I../kio -I../dcop -I../libltdl -I../dcop -I../libltdl -I../kdefx -I../kdecore -I../kdecore -I../kdeui -I../kio -I../kio/kio -I../kio/kfile -I.. -I/opt/qt/include -I/usr/X11R6/include -I/opt/kde/include -Drestrict= -I/usr/include/OpenEXR-DQT_THREAD_SUPPORT -D_REENTRANT -Wnon-virtual-dtor -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -DNDEBUG -DNO_DEBUG -O2 -march=i686 -O2 -pipe -Wformat-security -Wmissing-format-attribute -fno-exceptions -fno-check-new -fno-common -fno-exceptions -fno-check-new -fno-common -fvisibility=hidden -fvisibility-inlines-hidden -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -fexceptions -c -o exr.lo exr.cpp -v -save-temps >& gcc4-bug-output.txt -- Summary: internal compiler error Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pete at flooble dot net CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21248
[Bug c++/21248] internal compiler error
--- Additional Comments From pete at flooble dot net 2005-04-27 10:39 --- Created an attachment (id=8751) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8751&action=view) The command line generating the error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21248
[Bug c++/21248] internal compiler error
--- Additional Comments From pete at flooble dot net 2005-04-27 10:39 --- Created an attachment (id=8752) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8752&action=view) Output as generated from command line. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21248
[Bug c++/21248] internal compiler error
--- Additional Comments From pete at flooble dot net 2005-04-27 10:46 --- Created an attachment (id=8753) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8753&action=view) preprocessed file (gzipped due to size - *.ii.gz) as required by bug-submit guidelines Note: gzipped due to uncompressed size > 1 meg. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21248
[Bug tree-optimization/21171] [4.0/4.1 Regression] IV OPTS removes does not create a new VOPs for constant values
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21171
[Bug libstdc++/21238] conflicting "typedef __numpunct_cache<_CharT> __cache_type;" in std::numpunct makes specialization impossible
--- Additional Comments From bduerner at gmx dot de 2005-04-27 11:33
---
This testcase gives the following error:
numpunct_test.cpp:106: instantiated from here
/usr/lib/gcc/i586-ark-linux/3.4.4/../../../../include/c++/3.4.4/bits/locale_facets.tcc:435:
error: no type named `__cache_type' in `class std::numpunct'
-
#include
#include
#include
#include
#include
using namespace std;
struct MyChar {};
namespace std {
template<>
struct char_traits {
typedef MyChar char_type;
typedef int int_type;
typedef streamoff off_type;
typedef off_t pos_type;
typedef mbstate_t state_type;
static void assign(char_type& c1, const char_type& c2) {}
static bool eq(const char_type& c1, const char_type& c2) {}
static bool lt(const char_type& c1, const char_type& c2) {}
static int compare(const char_type* c1, const char_type* c2, size_t n) {}
static size_t length(const char_type* s) {}
static const char_type* find(const char_type* s, size_t n, const char_type&
a) {}
static char_type* move(char_type* s1, const char_type* s2, int_type n) {}
static char_type* copy(char_type* s1, const char_type* s2, size_t n) {}
static char_type* assign(char_type* s, size_t n, char_type a) {}
static char_type to_char_type(const int_type& c) {}
static int_type to_int_type(const char_type& c) {}
static bool eq_int_type(const int_type& c1, const int_type& c2) {}
static int_type eof() {}
static int_type not_eof(const int_type& c) {}
};
template <>
class numpunct : public locale::facet {
public:
typedef MyChar char_type;
typedef basic_string string_type;
// BUG: I would need to include this internally used typedef
// to make it compile successfully.
// typedef __numpunct_cache __cache_type;
public:
static locale::id id;
public:
explicit numpunct(size_t refs = 0) : locale::facet(refs)
{ }
char_type decimal_point() const
{ return this->do_decimal_point(); }
char_type thousands_sep() const
{ return this->do_thousands_sep(); }
string grouping() const
{ return this->do_grouping(); }
string_type truename() const
{ return this->do_truename(); }
string_type falsename() const
{ return this->do_falsename(); }
protected:
~numpunct()
{ }
virtual char_type do_decimal_point() const
{ return MyChar(); }
virtual char_type do_thousands_sep() const
{ return MyChar(); }
virtual string do_grouping() const
{ return ""; }
virtual string_type do_truename() const
{ /* whatever */ }
virtual string_type do_falsename() const
{ /* whatever*/ }
};
std::locale::id std::numpunct::id;
}
class MyStream : public std::basic_iostream {
public:
MyStream() : std::basic_iostream()
{}
};
int main() {
MyStream mystream;
std::locale loc( mystream.getloc(), new std::numpunct() );
mystream.imbue(loc);
int n;
mystream >> n;
return 0;
}
--
What|Removed |Added
CC||bero at arklinux dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21238
[Bug c++/21246] Compiler fails when using and incrementing a variable i: f(i,++i) equivalent to f(i+1,i+1); ++i
--- Additional Comments From giovannibajo at libero dot it 2005-04-27 11:40 --- This is not a bug, the order of evaluation is unspecified. Read about this here: http://gcc.gnu.org/bugs.html section "Increment/decrement operator (++/--) not working as expected" *** This bug has been marked as a duplicate of 11751 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21246
[Bug c/11751] wrong evaluation order of an expression
--- Additional Comments From giovannibajo at libero dot it 2005-04-27 11:40 --- *** Bug 21246 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||jandres at dsic dot upv dot ||es http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11751
[Bug c++/21240] Deadlock (pthread) in signal handler
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27 12:06 --- Do you have a testcase? On second thought pthreads and mutex lockes and signals are out of the scope of a compiler, If this is a bug, this is a glibc bug but I really doubt it. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21240
[Bug ada/21241] ACATS ICE verify_flow_info failed cxg1002 cxg1003 cxg2006 cxg2007 cxg2018 cxg2019 cxg2020
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27 12:09 --- This ICE is caused by more checking. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21241
[Bug libstdc++/21238] conflicting "typedef __numpunct_cache<_CharT> __cache_type;" in std::numpunct makes specialization impossible
--- Additional Comments From pcarlini at suse dot de 2005-04-27 12:12 --- Thanks for the testcase. The issue is subtle and the typedef is only the tip of the iceberg: num_get (involved in >>(int)) uses the caching facilities provided by the primary numpunct, which a specialization simply misses, generally. As our library is currently designed, you cannot specialize numpunct and then use the primary num_get template with it. Maybe we have a slighlty different instance of the problem with istream members that we fixed for 4.0: we should have generic implementations of num_get (and num_put) not exploitng any numpunct-provided caching and efficient specializations for char and wchar_t. Seems doable, at the expense of a non-trivial code-growth, but maybe within the present ABI. Benjamin? -- What|Removed |Added CC||bkoz at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21238
[Bug inline-asm/21249] New: incorrect code generation for rdtsc on x86_64
The following inline assembly is generating correct code on x86 but not on x86_64 (Counter is a uint64_t): asm volatile ( "rdtsc" : "=A" (Counter) ); -- Summary: incorrect code generation for rdtsc on x86_64 Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: inline-asm AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tfautre at pandora dot be CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: x86_64-pc-linux-gnu GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21249
[Bug inline-asm/21249] incorrect code generation for rdtsc on x86_64
--- Additional Comments From tfautre at pandora dot be 2005-04-27 13:08 --- Created an attachment (id=8754) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8754&action=view) Small test program that exibits the problem. The problem becomes more obvious when the program is compiled with -O2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21249
[Bug inline-asm/21249] incorrect code generation for rdtsc on x86_64
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27
13:11 ---
What do you mean, it is generating wrong code?
Actually you are using inline-asm wrong, try the following instead:
#define rdtsc(low,high) \
__asm__ __volatile__("rdtsc" : "=a" (low), "=d" (high))
This comes from the kernel.
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21249
[Bug c++/21248] internal compiler error
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27 13:25 --- I cannot reproduce this on the mainline or "4.0.0 20050410", I will build a 4.0.0 release later today, this might also be already fixed on the 4.0 branch too. -- What|Removed |Added Known to work||4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21248
[Bug preprocessor/21250] New: line number 0 for causes GAS to complain
powerpc64-linux-gcc -c -o any-file.o any-file.S results in any-file.S: Assembler messages: any-file.S:1: Warning: line numbers must be positive; line number 0 rejected as the pre-processed file looks like # 1 "any-file.S" # 0 "" # 1 "" # 1 "any-file.S" ... This regression is caused by http://gcc.gnu.org/ml/gcc-patches/2005-04/msg02132.html -- Summary: line number 0 for causes GAS to complain Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: segher at kernel dot crashing dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc-linux GCC host triplet: powerpc-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21250
[Bug inline-asm/21249] incorrect code generation for rdtsc on x86_64
--- Additional Comments From tfautre at pandora dot be 2005-04-27 13:30 --- Thanks for the code, it's working. The inline rdtsc code was from an IBM article; and after reading the GCC doc on =A, I must admit I was expecting it to work on x86_64 too. "ASpecifies the `a' or `d' registers. This is primarily useful for 64-bit integer values (when in 32-bit mode) intended to be returned with the `d' register holding the most significant bits and the `a' register holding the least significant bits." If =A is for using edx:eax in 32 bits mode, what is it doing exactly in 64 bits then? rdx:rax? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21249
[Bug inline-asm/21249] incorrect code generation for rdtsc on x86_64
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27 13:32 --- (In reply to comment #3) > If =A is for using edx:eax in 32 bits mode, what is it doing exactly in 64 > bits > then? rdx:rax? Just rax. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21249
[Bug preprocessor/21250] line number 0 for causes GAS to complain
-- What|Removed |Added CC||bothner at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21250
[Bug c++/21248] internal compiler error
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-04-27 13:35 --- ICE in gcc/expr.c:3087 emit_move_insn is called with y == NULL. #0 emit_move_insn (x=0x42dbc170, y=0x0) at /net/alwazn/home/rguenth/src/gcc/gcc4.0/gcc/expr.c:3087 #1 0x081d2ddc in convert_modes (mode=QImode, oldmode=SFmode, x=0x42dbc170, unsignedp=0) at /net/alwazn/home/rguenth/src/gcc/gcc4.0/gcc/expr.c:800 #2 0x081d31a5 in convert_to_mode (mode=QImode, x=0xa, unsignedp=10) at /net/alwazn/home/rguenth/src/gcc/gcc4.0/gcc/expr.c:694 #3 0x081d43a2 in store_expr (exp=0x4021b6c0, target=0x42d8f660, call_param_p=0) at /net/alwazn/home/rguenth/src/gcc/gcc4.0/gcc/expr.c:4181 #4 0x081d589e in expand_assignment (to=0x42db2000, from=0x5) at /net/alwazn/home/rguenth/src/gcc/gcc4.0/gcc/expr.c:3990 #5 0x081cc4b3 in expand_expr_real_1 (exp=Variable "exp" is not available. ) at /net/alwazn/home/rguenth/src/gcc/gcc4.0/gcc/expr.c:8136 #6 0x081cfa6e in expand_expr_real (exp=0x42daa9fc, target=0x40144210, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at /net/alwazn/home/rguenth/src/gcc/gcc4.0/gcc/expr.c:6358 #7 0x0832b796 in expand_expr_stmt (exp=0x42daa9fc) at /net/alwazn/home/rguenth/src/gcc/gcc4.0/gcc/expr.h:482 #8 0x0834fb15 in tree_expand_cfg () at /net/alwazn/home/rguenth/src/gcc/gcc4.0/gcc/cfgexpand.c:1133 ... -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-27 13:35:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21248
[Bug target/18402] [3.3 regression] ICE in gen_split_1204 on i686-pc-linux-gnu target
--- Additional Comments From gdr at integrable-solutions dot net 2005-04-27 13:37 --- Subject: Re: [3.3 regression] ICE in in gen_split_1204 on i686-pc-linux-gnu target "rgrosseboerger at dspace dot de" <[EMAIL PROTECTED]> writes: | The proposed patch fixes the reduced testcase and my larger testcase that | crashes GCC 3.3.5 with "-O2 -march=pentium4 -mfpmath=sse -ffast-math" | | I have run the C testsuite with no additional failures. | | If there are no further objections, I would really like to see this bugfix in | GCC 3.3.6. Did you apply the patch? -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18402
[Bug rtl-optimization/20211] autoincrement generation is poor
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-04-27 13:37 --- (In reply to comment #4) > There are both primary and secondary platforms among the AUTO_INC_DEC > targets. > So it is probably good to gain some wider test coverage about the compile- > time/run-time impact of this. E.g. testing CSIBE on ARM, or SPEC on RS6000. I have been trying to install Linux/GNU on an POwer Macintosh G3, but it appears that this is not going to work. Inserting a Yellowdog 3.0.1 install 1 CD-rom into the drive freezes the machine solid. BootX versions later than BootX_1.1.3 won't unpack. BootX 1.1.3 freezes the machine about 60% of the time rather than starting a kernel. rocklinux gets a CRC error on the ramdisk and then can't find init. ubuntu manages to continue after ramdisk unpacking errors, and even goes as far as partitioning if you restrict the partitions to 13 GB or less, but then it say it can't find the CD_ROM it just has read lots of files from. So, since there is no native platform I can test, would you like me to benchmark cross-compiling a suitable package? IIRC powerpc-eabisim is a possible cross target. Would CSIBE cross-compile time measurements fit your requirements? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211
[Bug c++/21166] g++ gives error on reference to packed structure elements
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-27 13:39:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21166
[Bug rtl-optimization/20211] autoincrement generation is poor
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27 13:41 --- (In reply to comment #8) > (In reply to comment #4) > > There are both primary and secondary platforms among the AUTO_INC_DEC > > targets. > > So it is probably good to gain some wider test coverage about the compile- > > time/run-time impact of this. E.g. testing CSIBE on ARM, or SPEC on RS6000. > > I have been trying to install Linux/GNU on an POwer Macintosh G3, but it > appears that this is not going to work. Inserting a Yellowdog 3.0.1 > install 1 CD-rom into the drive freezes the machine solid. BootX versions > later than BootX_1.1.3 won't unpack. BootX 1.1.3 freezes the machine about > 60% of the time rather than starting a kernel. rocklinux gets a CRC error > on the ramdisk and then can't find init. ubuntu manages to continue after > ramdisk unpacking errors, and even goes as far as partitioning if you > restrict the partitions to 13 GB or less, but then it say it can't find the > CD_ROM it just has read lots of files from. Mac OS X and darwin works on the G3, just fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211
[Bug preprocessor/21250] [4.1 Regression] line number 0 for causes GAS to complain
-- What|Removed |Added Summary|line number 0 for |[4.1 Regression] line number |causes GAS to complain |0 for causes GAS ||to complain Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21250
[Bug c++/21251] New: Placement into shared memory
I would like to use placement to instantiate a C++ object into a shared memory segment and access that object from a second process. When I test with an integer, the integer is accessible from the second process. But when I instantiate a C++ class object, it seems a memory pointer, which is local within the first process, is placed in memory. The place object is fully accessible and usable in the first process. I am guessing that the pointer points to the class definition within a table local to that first process. Unfortunately, that table, which does not seem to exist at the same address in the second process, causes the second process to Seg fault when it attempts to access the object instantiated in shared memory. What is the current correct approach to instantiating objects in shared memory so that multiple processes can access the C++ objects? -- Summary: Placement into shared memory Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mronell at alumni dot upenn dot edu CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21251
Re: gcc 4.0.0, doc/gcc.1 not there
Maybe there is something funny about your environment, like an auto-mounted NFS src directory which got auto-unmounted during the build? No, it's all local. However ... it must have been some craziness left over from a previous build, even though I did make distclean in srcdir and removed objdir -- now I can't reproduce it either, it goes through fine. Very sorry to bother. Karl
[Bug target/18402] [3.3 regression] ICE in gen_split_1204 on i686-pc-linux-gnu target
--- Additional Comments From rgrosseboerger at dspace dot de 2005-04-27 14:00 --- Subject: RE: [3.3 regression] ICE in gen_split_1204 on i686-pc-linux-gnu target > -Original Message- > From: gdr at integrable-solutions dot net > > Did you apply the patch? > > -- Gaby No, Roger did. http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01629.html I haven't tested with a recent GCC 3.3.6 snapshot, but the proposed patch and the one that was integrated are identical as far as I can see. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18402
[Bug c++/21251] Placement into shared memory
-- What|Removed |Added GCC build triplet||i686-pc-linux-gnu GCC host triplet||i686-pc-linux-gnu GCC target triplet||i686-pc-linux-gnu Keywords||wrong-code Version|unknown |3.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21251
[Bug c++/21251] Placement into shared memory
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27 14:03 --- Are you talking about the vtable being at two different locations, well there is no way since the struct is a non-POD which means it cannot do many things with. If you want to share data, try with a POD instead. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu | Keywords|wrong-code | Resolution||INVALID Version|3.4.3 |unknown http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21251
[Bug java/21245] gcjh creates invalid/empty header files
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27 14:18 --- Confirmed, I thought I saw something about this before, maybe it was on IRC or on the mailing lists. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-27 14:18:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21245
[Bug tree-optimization/21171] [4.0/4.1 Regression] IV OPTS removes does not create a new VOPs for constant values
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-27 14:28 --- Subject: Bug 21171 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-27 14:28:12 Modified files: gcc: ChangeLog tree-ssa-loop-ivopts.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg/tree-ssa: pr21171.c Log message: PR tree-optimization/21171 * tree-ssa-loop-ivopts.c (find_interesting_uses_address): Do not record address uses if the reference is volatile. * gcc.dg/tree-ssa/pr21171.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8479&r2=2.8480 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-loop-ivopts.c.diff?cvsroot=gcc&r1=2.63&r2=2.64 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5404&r2=1.5405 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr21171.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21171
[Bug c++/21252] New: ICE: (in c_parse_error, at c-common.c:5885)
I got the following ice: /usr/local/bin/g++ -save-temps -DHAVE_CONFIG_H -I. -I. -I../.. -I../../include -Wall -O9 -march=athlon -MT atom_co64.lo -MD -MP -MF .deps/atom_co64.Tpo -c atom_co64.cpp -fPIC -DPIC In file included from mp4common.h:36, from atom_co64.cpp:22: mp4property.h:61: internal compiler error: tree check: expected identifier_node, have integer_cst in c_parse_error, at c-common.c:5885 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. These are the build specs of the gcc being used: Reading specs from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.4/specs Configured with: /home/ltg/software/src/work/gcc-3.4-20050422/configure --enable-threads=posix --enable-libgcj --enable-shared --enable-__cxa_atexit --enable-version-specific-runtime-libs --enable-checking --enable-gather-detailed-mem-stats --disable-nls --enable-languages=c,c++,f77,objc,java,ada --enable-libgcj-multifile --with-x --enable-java-awt=gtk,xlib Thread model: posix gcc version 3.4.4 20050422 (prerelease) The preprocessed file will follow as an attachment. Lothar -- Summary: ICE: (in c_parse_error, at c-common.c:5885) Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ltg at zes dot uni-bremen dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21252
[Bug c++/21252] ICE: (in c_parse_error, at c-common.c:5885)
-- What|Removed |Added Keywords||ice-on-invalid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21252
[Bug c++/21252] ICE: (in c_parse_error, at c-common.c:5885)
--- Additional Comments From ltg at zes dot uni-bremen dot de 2005-04-27 14:35 --- Created an attachment (id=8755) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8755&action=view) This preprocessed file causes an ice. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21252
[Bug c++/21252] ICE: (in c_parse_error, at c-common.c:5885)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27 14:42 --- Can you please re-attach the preprocessed source and not encode the file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21252
[Bug c++/21252] ICE: (in c_parse_error, at c-common.c:5885)
--- Additional Comments From ltg at zes dot uni-bremen dot de 2005-04-27 14:46 --- Created an attachment (id=8756) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8756&action=view) This preprocessed file causes an ice. -- What|Removed |Added Attachment #8755 is|0 |1 obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21252
[Bug c++/21252] ICE: (in c_parse_error, at c-common.c:5885)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27 14:54 --- On the mainline (and I think 4.0 also), we get: mp4property.h:61: error: invalid pure specifier (only `= 0' is allowed) before ';' token mp4property.h:77: error: invalid pure specifier (only `= 0' is allowed) before ';' token mp4property.h:78: error: invalid pure specifier (only `= 0' is allowed) before ';' token mp4property.h:82: error: invalid pure specifier (only `= 0' is allowed) before ';' token mp4property.h:84: error: invalid pure specifier (only `= 0' is allowed) before ';' token mp4property.h:87: error: invalid pure specifier (only `= 0' is allowed) before ';' token rtphint.h:38: error: invalid pure specifier (only `= 0' is allowed) before ';' token rtphint.h:39: error: invalid pure specifier (only `= 0' is allowed) before ';' token This is a dup of bug 17401 which is fixed for 4.0.0. *** This bug has been marked as a duplicate of 17401 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21252
[Bug c++/17401] [3.4/4.0 Regression] ICE with invalid pure specifier
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27 14:54 --- *** Bug 21252 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||ltg at zes dot uni-bremen ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17401
[Bug c++/21251] Placement into shared memory
--- Additional Comments From mronell at alumni dot upenn dot edu 2005-04-27 14:56 --- I believe that the pointer points to a component within the vtable, but I do not want to jump to that conclusion. When the object is instantiated in shared memory, the first element seems to be a pointer to something, probably the vtable, followed by what appears to be object field values. What does 'POD' stand for? I am not great with acronyms. Thank you. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21251
[Bug c++/21251] Placement into shared memory
--- Additional Comments From pcarlini at suse dot de 2005-04-27 15:01
---
(POD ("Plain Old Data") is a technical term, defined in the standard, basically
something you can copy bit by bit, via memcpy)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21251
[Bug fortran/21177] wrong code with NULL()
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-27 15:38 --- Subject: Bug 21177 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-27 15:37:55 Modified files: gcc/fortran: ChangeLog interface.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: pr21177.f90 Log message: PR fortran/21177 * interface.c (compare_parameter): Ignore type for EXPR_NULL only if type is BT_UNKNOWN. * gfortran.dg/pr21177.f90: New test Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.406&r2=1.407 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/interface.c.diff?cvsroot=gcc&r1=1.17&r2=1.18 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5405&r2=1.5406 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/pr21177.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21177
[Bug fortran/21177] wrong code with NULL()
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-27 15:43 --- Subject: Bug 21177 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-04-27 15:42:54 Modified files: gcc/fortran: ChangeLog interface.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: pr21177.f90 Log message: PR fortran/21177 * interface.c (compare_parameter): Ignore type for EXPR_NULL only if type is BT_UNKNOWN. * gfortran.dg/pr21177.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.335.2.39&r2=1.335.2.40 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/interface.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.15&r2=1.15.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.141&r2=1.5084.2.142 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/pr21177.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21177
[Bug fortran/21177] wrong code with NULL()
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-27 15:44 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21177
[Bug libstdc++/21244] [4.0/4.1 Regression] Vector anonymous enum problem
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-27 15:59 --- Subject: Bug 21244 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-27 15:59:09 Modified files: libstdc++-v3 : ChangeLog libstdc++-v3/include/bits: stl_bvector.h Added files: libstdc++-v3/testsuite/23_containers/vector/bool: 21244.cc Log message: 2005-04-27 Dominik Strasser <[EMAIL PROTECTED]> Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/21244 * include/bits/stl_bvector.h: Change the anonymous enum at namespace scope to _S_word_bit_enum. * testsuite/23_containers/vector/bool/21244.cc: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcc&r1=1.2981&r2=1.2982 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/stl_bvector.h.diff?cvsroot=gcc&r1=1.39&r2=1.40 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/23_containers/vector/bool/21244.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21244
[Bug libstdc++/21244] [4.0/4.1 Regression] Vector anonymous enum problem
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-27 16:03 --- Subject: Bug 21244 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-04-27 16:02:28 Modified files: libstdc++-v3 : ChangeLog libstdc++-v3/include/bits: stl_bvector.h Added files: libstdc++-v3/testsuite/23_containers/vector/bool: 21244.cc Log message: 2005-04-27 Dominik Strasser <[EMAIL PROTECTED]> Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/21244 * include/bits/stl_bvector.h: Change the anonymous enum at namespace scope to _S_word_bit_enum. * testsuite/23_containers/vector/bool/21244.cc: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.2917.2.31&r2=1.2917.2.32 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/stl_bvector.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.39&r2=1.39.6.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/23_containers/vector/bool/21244.cc.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 --- Additional Comments From pcarlini at suse dot de 2005-04-27 16:03 --- Fixed for 4.0.1. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21244
[Bug libstdc++/21244] [4.0/4.1 Regression] Vector anonymous enum problem
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-27 16:03 --- Subject: Bug 21244 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-04-27 16:02:28 Modified files: libstdc++-v3 : ChangeLog libstdc++-v3/include/bits: stl_bvector.h Added files: libstdc++-v3/testsuite/23_containers/vector/bool: 21244.cc Log message: 2005-04-27 Dominik Strasser <[EMAIL PROTECTED]> Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/21244 * include/bits/stl_bvector.h: Change the anonymous enum at namespace scope to _S_word_bit_enum. * testsuite/23_containers/vector/bool/21244.cc: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.2917.2.31&r2=1.2917.2.32 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/stl_bvector.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.39&r2=1.39.6.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/23_containers/vector/bool/21244.cc.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21244
[Bug fortran/21104] Segmentation fault on correct code
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-04-27 16:03 --- This is a bug for the following reasons: A] From the standard, we have: 12.3.1.1 Explicit interface A procedure other than a statement function shall have an explicit interface if .. (2) The procedure has .. (c) An array-valued result (functions only), .. (3) The procedure is elemental. .. HOWEVER NOTE 12.3 An interface block cannot be used to describe the interface of an internal procedure, a module procedure, or an intrinsic procedure because the interfaces of such procedures are already explicit.. B] DF f90 says that it is standard conforming. Sorry, the option is /stand:f95 and not /strict. Anyway it goes through. $ f90 /stand:f95 /compile_only /nologo test_intr.f90 test_intr.f90 In conclusion, this is correct code. Inserting an explicit interface in the module fails, correctly, but is allowed, correctly, in the subroutine perdida. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21104
[Bug fortran/21253] New: Bounds Check
Compiled with the bounds checker on and program terminated early with the following message: "Fortran runtime error: Array reference out of bounds" 1. Need a clue of some kind, e.g., line number, array identity, etc. 2. G77 does not indicate an out of bounds. -- Summary: Bounds Check Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: blime at cox dot net CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21253
[Bug tree-optimization/21254] New: Incorrect code with -funroll-loops for multiple targets with same code
The following C++, when compiled with g++-4.0.0, produces incorrect code when
compiled with -O1 -funroll-loops on both sparc-sun-solaris2.8 and i686-pc-linux-
gnu. This is a bare-bones simplification of real code from an application
using
the Boost.Spirit library. If compiled without -funroll-loops, then the
behaviour is as expected (no exception thrown; see below).
$ /opt/gcc-4.0.0-cross/sparc-sun-solaris2.8/bin/sparc-sun-solaris2.8-g++ -v
Using built-in specs.
Target: sparc-sun-solaris2.8
Configured with: ../../gcc-4.0.0/configure --with-dwarf2 --enable-languages=c,
c++ --enable-threads=no --disable-shared --prefix=/opt/gcc-4.0.0-cross/sparc-
sun-solaris2.8 --with-gnu-as --with-gnu-ld --disable-multilib --enable-concept-
checks --enable-clocale=generic --enable-libstdcxx-allocator=mt --build=i686-pc-
linux-gnu --host=i686-pc-linux-gnu --target=sparc-sun-solaris2.8 --with-
sysroot=/opt/sysroot/sparc-sun-solaris2.8/
Thread model: single
gcc version 4.0.0
$ /opt/gcc-4.0.0-cross/i686-pc-linux-gnu/bin/i686-pc-linux-gnu-g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../../gcc-4.0.0/configure --with-dwarf2 --enable-languages=c,
c++ --enable-threads=no --disable-shared --prefix=/opt/gcc-4.0.0-cross/i686-pc-
linux-gnu --with-gnu-as --with-gnu-ld --disable-multilib
--enable-concept-checks
--enable-clocale=generic --enable-libstdcxx-allocator=mt --build=i686-pc-linux-
gnu --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu
Thread model: single
gcc version 4.0.0
The (poor, but simple) C++ program is as follows:
// sparc-sun-solaris2.8-g++ -Wall -O1 -funroll-loops -o opt-sparc
test_optimizer.cc
//
// or
//
// i686-pc-linux-gnu-g++ -Wall -O1 -funroll-loops -o opt-x86 test_optimizer.cc
#include
#include
class basic
{
public:
void set(char from, char to)
{
for (int i = from; i <= to; ++i) {
bset.set(static_cast(i));
}
}
private:
std::bitset<256> bset;
};
// Nevermind that this is not robust code; it's the simplest failure case.
void func(basic * const ptr,
const char *definition)
{
char ch = *definition;
++definition;
while (ch) {
char next = *definition;
++definition;
if (next == '-') {
next = *definition;
++definition;
ptr->set(ch, next);
}
ch = next;
}
}
int
main(const int argc,
const char * const * const argv)
{
basic ptr;
func(&ptr, "A-B");
}
This program should just set a couple of bits in the bitset and exit without
any
output. However, if compiled as described above, it triggers bitset's throw of
std::out_of_range:
$ ./opt-sparc
terminate called after throwing an instance of 'std::out_of_range'
what(): bitset::set
Abort
$ ./opt-x86
terminate called after throwing an instance of 'std::out_of_range'
what(): bitset::set
Aborted
The loop in func() has been "simplified" to remove all untaken branch pathways
while still triggering the bug.
This appears to be a regression since gcc-3.4.3 (for both targets) has no
trouble with this code. Version info from those compilers is shown below.
$ /opt/gcc-3.4.3-cross/sparc-sun-solaris2.8/bin/sparc-sun-solaris2.8-g++ -v
Reading specs from /opt/gcc-3.4.3-cross/sparc-sun-solaris2.8/lib/gcc/sparc-sun-
solaris2.8/3.4.3/specs
Configured with: ../../gcc-3.4.3/configure --with-dwarf2 --enable-languages=c,
c++ --enable-threads=no --disable-shared --prefix=/opt/gcc-3.4.3-cross/sparc-
sun-solaris2.8 --with-gnu-as --with-gnu-ld --disable-multilib --enable-concept-
checks --enable-clocale=generic --enable-libstdcxx-allocator=mt --build=i686-pc-
linux-gnu --host=i686-pc-linux-gnu --target=sparc-sun-solaris2.8 --with-
sysroot=/opt/sysroot/sparc-sun-solaris2.8/
Thread model: single
gcc version 3.4.3
$ /opt/gcc-3.4.3-cross/i686-pc-linux-gnu/bin/i686-pc-linux-gnu-g++ -v
Reading specs from /opt/gcc-3.4.3-cross/i686-pc-linux-gnu/lib/gcc/i686-pc-linux-
gnu/3.4.3/specs
Configured with: ../../gcc-3.4.3/configure --with-dwarf2 --enable-languages=c,
c++ --enable-threads=no --disable-shared --prefix=/opt/gcc-3.4.3-cross/i686-pc-
linux-gnu --with-gnu-as --with-gnu-ld --disable-multilib
--enable-concept-checks
--enable-clocale=generic --enable-libstdcxx-allocator=mt --build=i686-pc-linux-
gnu --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu
Thread model: single
gcc version 3.4.3
--
Summary: Incorrect code with -funroll-loops for multiple targets
with same code
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: spencer at infointeractive dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21254
[Bug c++/21232] [3.4 Regression] g++ segfaults
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-04-27 16:15 --- This works for me (3.4.0, 3.4.1, 3.4.3), too. I even downloaded Mandrake's versions (3.4.1 and 3.4.3). No problem. Can you reproduce the bug with the preprocessed file? Are you sure that this is not a hardware problem? -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21232
[Bug fortran/21253] Bounds Check
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27 17:06 --- For part 2: might be PR 19777, do you have a simple testcase which shows the problem. For part 1, I will file a seperate bug (later today) about the enhancing the error message -- What|Removed |Added OtherBugsDependingO||19777 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21253
[Bug rtl-optimization/21254] Incorrect code with -funroll-loops for multiple targets with same code
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27 17:44 --- The tree level does not change with -funroll-loops. -- What|Removed |Added Component|tree-optimization |rtl-optimization Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21254
[Bug fortran/21253] Bounds Check
--- Additional Comments From blime at cox dot net 2005-04-27 17:58 --- Subject: Re: Bounds Check Sorry, I do not have a simple test case, but might be able to construct one if part 1 is solved. blime pinskia at gcc dot gnu dot org wrote: >--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27 >17:06 --- >For part 2: might be PR 19777, do you have a simple testcase which shows the >problem. > >For part 1, I will file a seperate bug (later today) about the enhancing the >error message > > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21253
[Bug libfortran/20950] [4.0 only] segfault in INQUIRE asking for SEQUENTIAL status
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-27 18:15 --- Subject: Bug 20950 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-04-27 18:15:39 Modified files: gcc/testsuite : ChangeLog libgfortran: ChangeLog libgfortran/io : inquire.c Added files: gcc/testsuite/gfortran.dg: pr20950.f Log message: PR libfortran/20950 * io/inquire.c (inquire_via_unit): Check for the gfc_unit being NULL when setting ioparm.sequential. * gfortran.dg/pr20950.f: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.142&r2=1.5084.2.143 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/pr20950.f.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.4.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.163.2.19&r2=1.163.2.20 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/inquire.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.9.8.1&r2=1.9.8.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20950
[Bug libfortran/20950] [4.0 only] segfault in INQUIRE asking for SEQUENTIAL status
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-27 18:16 --- Patch commited to 4.0. Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20950
[Bug target/21255] New: %R and %S are not safe to use from asms
%R and %S should consider the special endianness of floaitng point registers, and when they find an unexpected argument, they should emit an error rather than abort. -- Summary: %R and %S are not safe to use from asms Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: minor Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: sh*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21255
[Bug fortran/21256] New: Illegal use of assumed-sized array in an array expression
Gfortran is not checking if an assumed sized array is used correctly in an array expression. Gfortran compiles the following without an error or warning subroutine e(a) real, intent(out) :: a(*) a = 1.e0 end subroutine NAG's compiler issues kargl[210] f95 -c e.f90 Error: e.f90, line 3: Invalid appearance of assumed-size array name A [f95 error termination] which is confirmed by Lahey's web based Fortran checker. -- Summary: Illegal use of assumed-sized array in an array expression Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kargl at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21256
[Bug fortran/21257] New: Duplicate use of construct name
Consider the following program: program f integer i loop: do i = 1, 5 print *, i end do loop loop: do i = 1, 5 print *, i end do loop end program f Gfortran compiles the program and it executes both loops. NAG's compiler claims it is illegal. kargl[206] f95 -o f f.f90 Error: f.f90, line 9: Duplicate construct name LOOP detected at @LOOP [f95 terminated - errors found by pass 1] -- Summary: Duplicate use of construct name Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kargl at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21257
[Bug libstdc++/21172] potential integer overflow error in STL heap functions
--- Additional Comments From pete_a90 at yahoo dot com 2005-04-27 19:09 --- I know there are no practical risks to this (heap isn't that popular and it's practically impossible to allocate an array that large) but it won't work if the user made a custom iterator with unsigned char as the size_type and signed char as the distance_type on a machine with small chars. The initialization of __secondChild isn't the problem, it's the updating of it in the loop that will cause it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21172
[Bug libstdc++/21172] potential integer overflow error in STL heap functions
--- Additional Comments From pcarlini at suse dot de 2005-04-27 19:26 --- Please, either provide an analysis that the problem really happens, *given the specific algorithm*, or provide a testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21172
[Bug tree-optimization/21258] New: Teach VRP to pick up a constant from case label.
Consider:
void bar (void);
void
foo (int a)
{
switch (a)
{
case 4:
if (a >= 3
&& a <= 5)
bar ();
}
}
Note that we could remove the "if" statement, VRP does not catch this.
I think Diego already knows about this, but I think it's worth a PR so that
we don't forget.
--
Summary: Teach VRP to pick up a constant from case label.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: dnovillo at redhat dot com,gcc-bugs at gcc dot gnu dot
org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21258
[Bug tree-optimization/21258] Teach VRP to pick up a constant from case label.
--- Additional Comments From dnovillo at redhat dot com 2005-04-27 19:43 --- Subject: Re: New: Teach VRP to pick up a constant from case label. On Wed, Apr 27, 2005 at 07:38:04PM -, kazu at cs dot umass dot edu wrote: > I think Diego already knows about this, but I think it's worth a PR so that > we don't forget. > Yes, there's a FIXME in tree-vrp.c about not handling SWITCH_EXPR. I agree it's worth having a PR for it. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21258
[Bug middle-end/20794] [4.0/4.1 Regression] Arrays and pointer arithmetic on __attribute ((aligned)) types permitted
--- Additional Comments From sje at cup dot hp dot com 2005-04-27 19:44 --- It looks like most of the compat tests have been fixed but I still get two failures. They are tmpdir-gcc.dg-struct-layout-1/t002 and tmpdir-gcc.dg-struct-layout-1/t027. I cut down t002 and wound up with void * __attribute__((aligned (8))) a[2]; I am not sure if this is supposed to apply the alignment to the array as a whole or to the elements. It appears to be applying it to the elements. If it is supposed to apply it to the elements then it is an illegal test, if it is supposed to apply it to the array as a whole then it is a compiler bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20794
g++ compiling code that is wrong.
Hello.
I dont know if I am to write here, but I think I found a bug that I know
is not related to my hardware or my system. Problem is that I don't know
how to report it or if it allready been reported(Kind of hard to search
for a bug when you dont know how to describe it.).
Backstory : I am a bit of a newbie on C++ and was doing a
schoolassigment where I was to make a dynamic array. I didn't do it
right but the code compile(and work on gentoo, didn't work on windowsXP)
anyway.
Instead of using new and delete[] when making the array, I wrote a code
that was something like this :
{
int b;
char a[b];
cout << "bla bla bla";
cin.getline(a,b);
}
The code compile both on gentoo linux(gcc 3.3.5 gcc 3.4.3) and
windowsXP(Minigw 3.2.0-rc3) and on my friends computer under gcc(I
belive Cygwin, dont know which version). I haven't tried it on newer
versions, so I don't know if you already fixed it.
According to the friend(who work as a c++ programer doing apps and stuff
on linuxsystems) and the teacher, this code is shouldn't be able to
compile at all(Which it didn't under MS visual studio).
I was compiling with no options, just g++ but now I saw there was a
-pedantic options and I tried it which return error.
Hope I didn't waste your time with a bug allready reported, but I
thought it would be better to report it just incase.
/Joel
[Bug c++/11285] GCC 3.3 C++ for Sparc Solaris assumes system header files are C.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-27 21:03 --- Subject: Bug 11285 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-27 21:03:00 Modified files: libjava: ChangeLog libjava/gnu/java/net/protocol/file: Connection.java libjava/java/net: URLClassLoader.java Log message: 2005-04-27 Chris Burdess <[EMAIL PROTECTED]> * gnu/java/net/protocol/file/Connection.java: Return correct content length for directory listing. * java/net/URLClassLoader.java: Correction for URLClassLoader, bug #11285: return valid URLs for directories.i Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&r1=1.3568&r2=1.3569 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/gnu/java/net/protocol/file/Connection.java.diff?cvsroot=gcc&r1=1.10&r2=1.11 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/net/URLClassLoader.java.diff?cvsroot=gcc&r1=1.28&r2=1.29 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11285
Re: g++ compiling code that is wrong.
>
> Hello.
>
> I dont know if I am to write here, but I think I found a bug that I know
> is not related to my hardware or my system. Problem is that I don't know
> how to report it or if it allready been reported(Kind of hard to search
> for a bug when you dont know how to describe it.).
>
> Backstory : I am a bit of a newbie on C++ and was doing a
> schoolassigment where I was to make a dynamic array. I didn't do it
> right but the code compile(and work on gentoo, didn't work on windowsXP)
> anyway.
>
> Instead of using new and delete[] when making the array, I wrote a code
> that was something like this :
>
> {
> int b;
> char a[b];
>
>cout << "bla bla bla";
>cin.getline(a,b);
> }
This is a GNU extension which is now the bases for the VLAs in C99.
-- Pinski
[Bug c/21159] [4.0/4.1 Regression] "no effect" warning despite cast to void*
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-27 21:41 --- Subject: Bug 21159 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-27 21:41:15 Modified files: gcc: ChangeLog c-typeck.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: void-cast-1.c Log message: PR c/21159 * c-typeck.c (build_compound_expr): Don't warn for left-hand side being a compound expression whose right-hand side is cast to void. testsuite: * gcc.dg/void-cast-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8501&r2=2.8502 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-typeck.c.diff?cvsroot=gcc&r1=1.436&r2=1.437 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5407&r2=1.5408 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/void-cast-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21159
[Bug c/21159] [4.0/4.1 Regression] "no effect" warning despite cast to void*
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-27 21:47 --- Subject: Bug 21159 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-04-27 21:47:31 Modified files: gcc: ChangeLog c-typeck.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: void-cast-1.c Log message: PR c/21159 * c-typeck.c (build_compound_expr): Don't warn for left-hand side being a compound expression whose right-hand side is cast to void. testsuite: * gcc.dg/void-cast-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.198&r2=2.7592.2.199 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-typeck.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.419.2.2&r2=1.419.2.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.143&r2=1.5084.2.144 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/void-cast-1.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21159
[Bug c/21159] [4.0/4.1 Regression] "no effect" warning despite cast to void*
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27 21:49 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21159
[Bug other/346] gcc install clobbers files that it shouldn't touch
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-27 23:54 --- Can someone comment on the status of this bug? -- What|Removed |Added CC||stevenb at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=346
[Bug rtl-optimization/21138] wrong code in sixtrack for -fmodulo-sched
--- Additional Comments From janis at gcc dot gnu dot org 2005-04-28 00:07
---
There are other SPEC CPU2000 comparison failures on powerpc64-linux
with "-m64 -O2 -fmodulo-sched" that resist attempts to minimize the
testcases. apsi has been failing since:
http://gcc.gnu.org/ml/gcc-cvs/2005-04/msg00893.html from kazu
and lucas has been failing since:
http://gcc.gnu.org/ml/gcc-cvs/2005-04/msg01289.html from radkver.
While trying to minimize the apsi failure I added write statements
that caused apsi to segfault; for example, write the value of I just
inside the loop using it in DCDTZ with:
1327a1328,1329
> write(6,1001) i
> 1001format(' i = ',i3)
I'm adding the information to this PR because I don't have test cases
to submit for the apsi and lucas failures in new PRs, and hope that
the information might be useful to Mostafa or anyone else who looks
into this PR. There were other failures with these options earlier
this month that have since gone away, making it look even more like
latent bugs in the modulo scheduling code.
All of these SPEC CPU2000 failures are with the small "test" input.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21138
[Bug libstdc++/21172] potential integer overflow error in STL heap functions
--- Additional Comments From pcarlini at suse dot de 2005-04-28 00:08 --- Ok, let's reopen the PR as "enhancement": actually, it's easy to produce a testcase that leads to __secondChild growing beyond __len and the latter can be equal to the biggest representable _Distance. -- What|Removed |Added Severity|normal |enhancement Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21172
[Bug libstdc++/21172] potential integer overflow error in STL heap functions
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-28 00:11:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21172
[Bug tree-optimization/21258] Teach VRP to pick up a constant from case label.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-28 00:36 --- Confirmed, in a way PR 20514 is related. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-28 00:36:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21258
[Bug c++/19614] Excessive memory consumption with a class with large (200) virtual (pure?) function and derived classes
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-28 00:52 --- On the mainline, (on x86) we use about 300 megs which is an improvement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19614
[Bug rtl-optimization/21144] [4.0/4.1 regression] Apparent infinite loop in reload
--- Additional Comments From wilson at gcc dot gnu dot org 2005-04-28 01:15 --- Confirmed. The patch is OK for both mainline and the gcc-4.0 branch, assuming it passes the regtest, in case anyone was waiting for approval. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-28 01:15:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21144
[Bug c++/21251] Placement into shared memory
--- Additional Comments From mronell at alumni dot upenn dot edu 2005-04-28 01:32 --- "Plain Old Data" unfortunately is not a good solution in my case. I maintain http://allocator.sourceforge.net which provides an open-source shared memory allocator for the C++ Standard Template Library. This allocator has worked with earlier versions of gcc/g++, but it depends on being able to instantiate objects successfully in shared memory allowing multiple processes to access the same objects. Localized vtable pointers would cause problems. I have a new version of the allocator revised based on Knuth's Dynamic Memory Storage algorithm from his Vol. 1. Its similar to Doug Lea's malloc. However, as before, my approach depends on being able to place and share C++ objects through shared memory. Its that still possible? Am I missing some esoteric compiler flags? Is this a bug or future feature request? Thanks for your suggestions and input. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21251
[Bug libstdc++/21251] Placement into shared memory
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-28 01:44 --- (In reply to comment #4) > However, as before, my approach depends on being able to place and share C++ > objects through shared memory. Its that still possible? > > Am I missing some esoteric compiler flags? Is this a bug or future feature > request? No it is not possible. Now if you convince the standards committe that this is really should be possible, then we will implement their recommendation but as of now, there is no way sorry. > This allocator has worked > with earlier versions of gcc/g++, but it depends on being able to instantiate > objects successfully in shared memory allowing multiple processes to access > the same objects. What versions? I really doubt that it worked at all as vtable implementation has only changed on what is the layout of the vtable. > "Plain Old Data" unfortunately is not a good solution in my case. I maintain > http://allocator.sourceforge.net which provides an open-source shared memory > allocator for the C++ Standard Template Library. Hmm, there allocators have specific requirements in C++. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c++ |libstdc++ Resolution||INVALID Version|unknown |3.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21251
[Bug middle-end/21259] New: ICE on assigning the pointer to a array with __attribute__ aligned
Compiler gets a segfault if the following code is tried on gcc 3.4.3
the same works fine on gcc4.0 and mainline
static void foo ( int arg){
unsigned long long int __attribute__ ((aligned (4))) aligned_array[arg];
unsigned long long int *bak = aligned_array;
}
--
Summary: ICE on assigning the pointer to a array with
__attribute__ aligned
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: raj dot khem at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i386-redhat-linux
GCC host triplet: i386-redhat-linux
GCC target triplet: mips64-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21259
[Bug c++/13051] problem with static member and ?: operator
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-28 02:02 --- reopening to -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13051
