[Bug c++/36149] New: -O2 optimization generates wrong code
GCC version:
gcc (GCC) 4.1.2 20070925 (Red Hat 4.1.2-27)
It is really hard to reproduce and goes away even with minimal code changes.
Happens in a unit test.
Host is x86_64: model name : Intel(R) Core(TM)2 CPU 6300 @
1.86GHz from /proc/cpuinfo.
The following snippets might be useful to someone perhaps:
C code:
void pRemove(CLASS *d)
{
LC(d)-m_back-m_fwd = LC(d)-m_fwd;
LC(d)-m_fwd-m_back = LC(d)-m_back;
}
void prepend(CLASS *a)
{
pRemove(a);
LC(a)-m_fwd = head.m_fwd;
head.m_fwd-m_back = LC(a);
LC(a)-m_back = head;
head.m_fwd = LC(a);
}
MapList::add():
// ...
m_list.remove(removed);
if (fTop) {
m_list.prepend(item);
} else {
// ...
Disassembly w/ comments:
8053c7f: 80 7d 8f 00 cmpb $0x0,0xff8f(%ebp)###
if (fTop)
8053c83: 89 02 mov%eax,(%edx)
8053c85: 8b 07 mov(%edi),%eax
8053c87: 89 3f mov%edi,(%edi)
8053c89: 89 50 04mov%edx,0x4(%eax)
8053c8c: 89 7f 04mov%edi,0x4(%edi)
The above few lines perform the remove(removed) call and the if test out of
order, which is OK. After that, variables look like this:
14: item.m_back = (Vapi::DoubleLink *) 0x81d4400
13: item.m_fwd = (Vapi::DoubleLink *) 0x81d4400
12: item = (DownloadQueue::DQ_Item *) 0x81d4400
11: this-m_list.head.m_back = (Vapi::DoubleLink *) 0xffc26b3c
10: this-m_list.head.m_fwd = (Vapi::DoubleLink *) 0xffc26b3c
9: this-m_list.head = (Vapi::DoubleLink *) 0xffc26b3c
8: removed.m_back = (Vapi::DoubleLink *) 0x81d43b0
7: removed.m_fwd = (Vapi::DoubleLink *) 0x81d43b0
6: removed = (DownloadQueue::DQ_Item *) 0x81d43b0
The m_list.head is empty, item is on no list, and removed is on no list.
Then the code for prepend(item) is supposed to execute:
8053c8f: 0f 84 bf 01 00 00 je 8053e54
DownloadQueue::DQ_MapList::add(DownloadQueue::DQ_Item*, bool)+0x354
8053c95: 8b 55 0cmov0xc(%ebp),%edx ###
edx = item
8053c98: 8b 42 04mov0x4(%edx),%eax ###
eax = item-m_back (in pRemove)
8053c9b: 89 d3 mov%edx,%ebx###
ebx = item
8053c9d: 8b 12 mov(%edx),%edx ###
edx = item-m_fwd
8053c9f: 89 10 mov%edx,(%eax) ###
item-m_back-m_fwd = edx (item-m_fwd)
8053ca1: 8b 13 mov(%ebx),%edx ###
edx = item-m_fwd
8053ca3: 89 0b mov%ecx,(%ebx) ###
item-m_fwd = %ecx (removed?!)
8053ca5: 89 42 04mov%eax,0x4(%edx) ###
item-m_fwd-m_back = item-m_back
8053ca8: 8b 45 9cmov0xff9c(%ebp),%eax###
eax = head
8053cab: 8b 55 98mov0xff98(%ebp),%edx###
??
8053cae: 89 59 04mov%ebx,0x4(%ecx) ###
removed-m_back = item (?!)
8053cb1: 89 43 04mov%eax,0x4(%ebx) ###
item-m_back = head
8053cb4: 89 5a 04mov%ebx,0x4(%edx) ###
?? head-m_back = item
8053cb7: 8b 5f 20mov0x20(%edi),%ebx
But that doesn't look all that great. The compiler somehow tries to interleave
the pRemove and the rest of prepend, but the result is pretty bad:
14: item.m_back = (Vapi::DoubleLink *) 0xffc26b3c
13: item.m_fwd = (Vapi::DoubleLink *) 0x81d43b0
12: item = (DownloadQueue::DQ_Item *) 0x81d4400
11: this-m_list.head.m_back = (Vapi::DoubleLink *) 0xffc26b3c
10: this-m_list.head.m_fwd = (Vapi::DoubleLink *) 0x81d4400
9: this-m_list.head = (Vapi::DoubleLink *) 0xffc26b3c
8: removed.m_back = (Vapi::DoubleLink *) 0x81d4400
7: removed.m_fwd = (Vapi::DoubleLink *) 0x81d43b0
6: removed = (DownloadQueue::DQ_Item *) 0x81d43b0
Item and removed point to each other, with one of their pointers, m_list.head
points to item but not with both pointers, item points to head with one of its
pointers...
May not be able to provide full source that reproduces the problem (couldn't
generate a short piece of code that reproduces the problem.) But, could perhaps
provide additional info.
--
Summary: -O2 optimization generates wrong code
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dino at concisoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36149
[Bug c++/36149] -O2 optimization generates wrong code
--- Comment #1 from dino at concisoft dot com 2008-05-06 07:19 --- The same code works fine with -O1 and -O3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36149
[Bug tree-optimization/36118] [4.4 Regressions] inline-related regressions
--- Comment #2 from hubicka at gcc dot gnu dot org 2008-05-06 08:00 --- Subject: Bug 36118 Author: hubicka Date: Tue May 6 07:59:54 2008 New Revision: 134975 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134975 Log: PR tree-optimization/36118 * passes.c (pass_init_dump_file): Fix dump header. Modified: trunk/gcc/ChangeLog trunk/gcc/passes.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36118
[Bug c++/36149] -O2 optimization generates wrong code
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-06 08:23 --- How is LC defined? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36149
[Bug middle-end/36106] #pragma omp atomic issues with floating point types
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||05/msg00260.html Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-05-06 09:20:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36106
[Bug middle-end/36129] ICE with -fprofile-use
--- Comment #3 from jv244 at cam dot ac dot uk 2008-05-06 09:29 --- Created an attachment (id=15585) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15585action=view) files (.f .gcda .mod) needed to reproduce the ICE and a README attached the files needed to trigger the verify_histograms ICE, plus a README with the exact command used to do so -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36129
[Bug other/36150] New: colorize output of gcc
It could be useful if gcc colorizes its output. Colors allow easier to distinguish errors and warnings from makefile commands and etc... Currently there exist a separate script like colorgcc which colorizes output of compiler but it does not works with localized bugs.gentoo.org/168709 output so seems that it's better to have colorizing functionality in gcc itself as only gcc knows better what output it issues. -- Summary: colorize output of gcc Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pva at gentoo dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150
[Bug c++/36151] New: gcc fails to find template specializations within namespace
Compiling the following code fails with g++ 4.2.1 (also with 4.1.3 and 4.3.0
but works with 4.0.1 and 4.0.2)
--
templateclass T class A
{
public:
T operator*() { return *m; }
T *m;
};
templateclass T class B
{
public:
T operator*() { return *m; }
T *m;
};
class X
{
public:
void foo() {}
};
namespace N {
templateclass T void bar( T v ) { v.foo(); }
templateclass T void bar( BT x ) { bar( *x ); }
templateclass T void bar( AT x ) { bar( *x ); }
}
int main()
{
B AX m;
N::bar( m );
};
--
Output of g++ -c testfile.cpp:
testfile.cpp: In function 'void N::bar(T) [with T = AX]':
testfile.cpp:23: instantiated from 'void N::bar(BT) [with T = AX]'
testfile.cpp:30: instantiated from here
testfile.cpp:22: error: 'class AX' has no member named 'foo'
--
Somehow the compiler doesn't seem to see the template specialization for AX
and takes the more general template instead - I consider this a bug BECAUSE:
1.) This code compiles with reversed order of template specialization
definition OR template nesting - i.e. the above example will work with A BX
m;
2.) Code compiles with namespace consistently removed (any order of
definitions/nesting).
--
Output of g++ -v:
Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info --mandir
=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=rel
ease --with-gxx-include-dir=/usr/include/c++/4.2.1 --enable-ssp
--disable-libssp --disable-libgcj --with-slibdir=/lib --with-system-
zlib --enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --program-suffix=-4.2 --enable-v
ersion-specific-runtime-libs --without-system-libunwind --with-cpu=generic
--host=i586-suse-linux
Thread model: posix
gcc version 4.2.1 (SUSE Linux)
--
identical behaviour observed with
4.1.3 (i586-suse-linux)
4.3.0 (powerpc-apple-darwin8)
known to work with
4.0.1, 4.0.2 (both platforms mentioned)
--
Summary: gcc fails to find template specializations within
namespace
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: juergen dot wallner at philips dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36151
[Bug middle-end/36143] [4.4 Regression]: FAIL: g++.dg/tree-ssa/pr19637.C
--- Comment #6 from rguenther at suse dot de 2008-05-06 10:22 ---
Subject: Re: [4.4 Regression]: FAIL: g++.dg/tree-ssa/pr19637.C
On Tue, 6 May 2008, pinskia at gcc dot gnu dot org wrote:
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-05-06 04:15
---
Oh we don't handle VCE On the left hand side for many different reasons. One
is because if we set only part of the variable, we could get possible invalid
gimple as we are only setting part of a SSA_NAME. I am un-assigning myself
for
now.
We fold
i.1_7 = (struct Foo *) i;
D.2236_8 = i.1_7-i[0];
to
D.2236_8 = VIEW_CONVERT_EXPRstruct Foo(i).i[0];
which is fine in principle but misses a folding to i[0].
maybe_fold_offset_to_{array,component}_ref in tree-ssa-ccp.c should
be extended to handle this case, invoked via fold_stmt.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36143
[Bug middle-end/36137] gcc can't do math
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Keywords||wrong-code Last reconfirmed|2008-05-05 19:10:16 |2008-05-06 10:50:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36137
[Bug middle-end/36152] New: [4.4 Regression] invalid character '' in mnemonic at revision 134957
The tests gcc.dg/vect/vect-reduc-1short.c and vect-reduc-9.c fail at revision 134957 with: /var/tmp//ccTL0QBh.s:61:invalid character '' in mnemonic /var/tmp//ccTL0QBh.s:65:invalid character '' in mnemonic The assembly file vect-reduc-9.s contains at line 47: psat_plusminus_mnemonicw %xmm2, %xmm1 -- Summary: [4.4 Regression] invalid character '' in mnemonic at revision 134957 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: i686-apple-darwin9 GCC host triplet: i686-apple-darwin9 GCC target triplet: i686-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36152
[Bug fortran/36153] New: ICE on size with kind parameter
Use of an optional kind parameter on a call to the intrinsic size was added in Fortran 2003, and is essential to avoid overflow when dealing with arrays bigger than huge(0). The following example provides test code and demonstrates this. gfortran should warn that this is non-standard fortran 90/95 and fail gracefully, and/or work as per the F2003 spec. Thanks, Jonathan. [EMAIL PROTECTED] ~/bugs/gfortran-4.3/size_kind $ gfortran-4.3 -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../configure --program-suffix=-4.3 Thread model: posix gcc version 4.3.0 (GCC) [EMAIL PROTECTED] ~/bugs/gfortran-4.3/size_kind $ gfortran-4.3 test_64.f90 f951: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. [EMAIL PROTECTED] ~/bugs/gfortran-4.3/size_kind $ cat test_64.f90 program test_64 implicit none integer, parameter :: long = selected_int_kind(18) integer, parameter :: short = kind(0) integer(long), parameter :: big_sz = huge(0_short)+1000_long integer(long), parameter :: max_32 = huge(0_short) integer, dimension(:), allocatable :: array integer(long) :: i print *, 2**31 = , 2_long**31 print *, max_32 = , max_32 print *, big_sz = , big_sz allocate(array(big_sz)) print *, sz = , size(array) print *, sz = , size(array, kind=long) end program -- Summary: ICE on size with kind parameter Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: J dot Hogg at rl dot ac dot uk GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36153
[Bug libfortran/36120] selected_char_kind_1.f90 undefined reference with -m32
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2008-05-06 11:12 --- Is that a clean build? The symbol is new and I think sometimes dependencies don't get updated fine. I saw that one at some point, but a clean build made it disappear. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36120
[Bug libfortran/36120] selected_char_kind_1.f90 undefined reference with -m32
--- Comment #2 from Ralf dot Wildenhues at gmx dot de 2008-05-06 12:00 --- (In reply to comment #1) Is that a clean build? The symbol is new and I think sometimes dependencies don't get updated fine. I saw that one at some point, but a clean build made it disappear. Next time you see such an issue, can you please try to note as many details as possible, open a PR and Cc: me? I can only see that happening with --enable-maintainer-mode and then the rebuild rules not finding appropriate autotools versions. -- Ralf dot Wildenhues at gmx dot de changed: What|Removed |Added CC||Ralf dot Wildenhues at gmx ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36120
[Bug middle-end/36129] [4.4 Regression] ICE with -fprofile-use
--- Comment #4 from jv244 at cam dot ac dot uk 2008-05-06 12:08 --- older gcc versions (tested 4.2.3 and 4.3.0) seem to work fine -- jv244 at cam dot ac dot uk changed: What|Removed |Added Known to work||4.2.3 4.3.0 Summary|ICE with -fprofile-use |[4.4 Regression] ICE with - ||fprofile-use http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36129
[Bug libfortran/36120] selected_char_kind_1.f90 undefined reference with -m32
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2008-05-06 12:08 --- (In reply to comment #2) Next time you see such an issue, can you please try to note as many details as possible, open a PR and Cc: me? I will, sorry. I was really more in a hurry of getting my patch regtesting fine (it happend when I first testing it) so I didn't write it down. I can only see that happening with --enable-maintainer-mode and then the rebuild rules not finding appropriate autotools versions. Hum, that was without --enable-maintainer-mode and manually running automake (but not autoconf or autoheader); maybe doing that is the mistake in itself :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36120
[Bug libfortran/36120] selected_char_kind_1.f90 undefined reference with -m32
--- Comment #4 from Ralf dot Wildenhues at gmx dot de 2008-05-06 12:14 --- Subject: Re: selected_char_kind_1.f90 undefined reference with -m32 * fxcoudert at gcc dot gnu dot org wrote on Tue, May 06, 2008 at 02:08:59PM CEST: I can only see that happening with --enable-maintainer-mode and then the rebuild rules not finding appropriate autotools versions. Hum, that was without --enable-maintainer-mode and manually running automake (but not autoconf or autoheader); maybe doing that is the mistake in itself :) If you're only modifying Makefile.am files, then running automake should be sufficient (except changes to ACLOCAL_AMFLAGS won't be picked up). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36120
[Bug middle-end/36152] [4.4 Regression] invalid character '' in mnemonic at revision 134957
--- Comment #1 from dominiq at lps dot ens dot fr 2008-05-06 12:17 --- It seems to be fixed at (or before) revision 134981. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36152
[Bug c/36154] New: internal compiler error: in get_constraint_for_component_ref, at tree-ssa-structalias.c:2727
I'm encountering an internal compiler error with the gcc 4.3.0 release. I don't think this is a duplicate of any other bugs. Here is the command and subsequent output: powerpc-eabispe-gcc -I../ -I/home/patrick/src/e7/prex -I/home/patrick/src/e7/prex/usr/include -I/home/patrick/src/e7/prex/include -nostdinc -fsingle-precision-constant -mabi=no-spe -gdwarf-2 -Os -ansi -fno-strict-aliasing -Wall -Wundef -Wstrict-prototypes -Wpointer-arith -std=gnu99 -fno-stack-protector -Wno-variadic-macros -D__ppc__ -D__e7__ -D__ARCH__=ppc -D__PLATFORM__=e7 -Uppc -Ue7 -fno-omit-frame-pointer -DDEBUG -g -Wsign-compare -Werror-implicit-function-declaration -I../comms/lwip/include -I../comms/lwip/prex/include -I../comms/lwip/include/ipv4 -v -save-temps -I../include -c -o ../test/test_xcp_eth.o test_xcp_eth.c Using built-in specs. Target: powerpc-eabispe Configured with: /home/patrick/src/e7/toolchain/src/gcc-4.3.0/configure --prefix=/home/patrick/src/e7/toolchain/stage2 --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=powerpc-eabispe --enable-languages=c --disable-nls --disable-multilib --disable-werror --with-newlib --disable-shared --disable-debug --disable-libssp Thread model: single gcc version 4.3.0 (GCC) COLLECT_GCC_OPTIONS='-I../' '-I/home/patrick/src/e7/prex' '-I/home/patrick/src/e7/prex/usr/include' '-I/home/patrick/src/e7/prex/include' '-nostdinc' '-fsingle-precision-constant' '-mabi=no-spe' '-gdwarf-2' '-Os' '-ansi' '-fno-strict-aliasing' '-Wall' '-Wundef' '-Wstrict-prototypes' '-Wpointer-arith' '-std=gnu99' '-fno-stack-protector' '-Wno-variadic-macros' '-D__ppc__' '-D__e7__' '-D__ARCH__=ppc' '-D__PLATFORM__=e7' '-Uppc' '-Ue7' '-fno-omit-frame-pointer' '-DDEBUG' '-g' '-Wsign-compare' '-Werror-implicit-function-declaration' '-I../comms/lwip/include' '-I../comms/lwip/prex/include' '-I../comms/lwip/include/ipv4' '-v' '-save-temps' '-I../include' '-c' '-o' '../test/test_xcp_eth.o' /home/patrick/src/e7/toolchain/stage2/libexec/gcc/powerpc-eabispe/4.3.0/cc1 -E -quiet -nostdinc -v -I../ -I/home/patrick/src/e7/prex -I/home/patrick/src/e7/prex/usr/include -I/home/patrick/src/e7/prex/include -I../comms/lwip/include -I../comms/lwip/prex/include -I../comms/lwip/include/ipv4 -I../include -D__ppc__ -D__e7__ -D__ARCH__=ppc -D__PLATFORM__=e7 -Uppc -Ue7 -DDEBUG test_xcp_eth.c -mabi=no-spe -ansi -std=gnu99 -Wall -Wundef -Wstrict-prototypes -Wpointer-arith -Wno-variadic-macros -Wsign-compare -Werror-implicit-function-declaration -fsingle-precision-constant -fno-strict-aliasing -fno-stack-protector -fno-omit-frame-pointer -fworking-directory -Os -fpch-preprocess -o test_xcp_eth.i #include ... search starts here: #include ... search starts here: ../ /home/patrick/src/e7/prex /home/patrick/src/e7/prex/usr/include /home/patrick/src/e7/prex/include ../comms/lwip/include ../comms/lwip/prex/include ../comms/lwip/include/ipv4 ../include End of search list. COLLECT_GCC_OPTIONS='-I../' '-I/home/patrick/src/e7/prex' '-I/home/patrick/src/e7/prex/usr/include' '-I/home/patrick/src/e7/prex/include' '-nostdinc' '-fsingle-precision-constant' '-mabi=no-spe' '-gdwarf-2' '-Os' '-ansi' '-fno-strict-aliasing' '-Wall' '-Wundef' '-Wstrict-prototypes' '-Wpointer-arith' '-std=gnu99' '-fno-stack-protector' '-Wno-variadic-macros' '-D__ppc__' '-D__e7__' '-D__ARCH__=ppc' '-D__PLATFORM__=e7' '-Uppc' '-Ue7' '-fno-omit-frame-pointer' '-DDEBUG' '-g' '-Wsign-compare' '-Werror-implicit-function-declaration' '-I../comms/lwip/include' '-I../comms/lwip/prex/include' '-I../comms/lwip/include/ipv4' '-v' '-save-temps' '-I../include' '-c' '-o' '../test/test_xcp_eth.o' /home/patrick/src/e7/toolchain/stage2/libexec/gcc/powerpc-eabispe/4.3.0/cc1 -fpreprocessed test_xcp_eth.i -quiet -dumpbase test_xcp_eth.c -mabi=no-spe -ansi -auxbase-strip ../test/test_xcp_eth.o -gdwarf-2 -g -Os -Wall -Wundef -Wstrict-prototypes -Wpointer-arith -Wno-variadic-macros -Wsign-compare -Werror-implicit-function-declaration -ansi -std=gnu99 -version -fsingle-precision-constant -fno-strict-aliasing -fno-stack-protector -fno-omit-frame-pointer -o test_xcp_eth.s GNU C (GCC) version 4.3.0 (powerpc-eabispe) compiled by GNU C version 4.2.3 (Ubuntu 4.2.3-2ubuntu7), GMP version 4.2.2, MPFR version 2.3.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: d72f763bda0b53028b002e23e9bbb24c test_xcp_eth.c: In function 'cmd_unaligned': test_xcp_eth.c:68: internal compiler error: in get_constraint_for_component_ref, at tree-ssa-structalias.c:2727 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: internal compiler error: in get_constraint_for_component_ref, at tree-ssa- structalias.c:2727 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot
[Bug c/36154] internal compiler error: in get_constraint_for_component_ref, at tree-ssa-structalias.c:2727
--- Comment #1 from patrick at motec dot com dot au 2008-05-06 12:46 --- Created an attachment (id=15586) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15586action=view) preprocessed source preprocessed source for the file that causes the bug, as required by bug writing guidelines! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36154
[Bug target/35714] x86 poor code with pmaddwd
--- Comment #3 from ubizjak at gmail dot com 2008-05-06 12:55 ---
This is due to this code snippet from i386.c, ix86_expand_binop_builtin ():
--cut here--
/* ??? Using ix86_fixup_binary_operands is problematic when
we've got mismatched modes. Fake it. */
xops[0] = target;
xops[1] = op0;
xops[2] = op1;
if (tmode == mode0 tmode == mode1)
{
target = ix86_fixup_binary_operands (UNKNOWN, tmode, xops);
op0 = xops[1];
op1 = xops[2];
}
else if (optimize || !ix86_binary_operator_ok (UNKNOWN, tmode, xops))
{
op0 = force_reg (mode0, op0);
op1 = force_reg (mode1, op1);
target = gen_reg_rtx (tmode);
}
--cut here--
Since UNKNOWN is not commutative operator, this code disables many
optimizations that can be performed by treating builtins individually using
ix86_fixup_binary_operands_no_copy ().
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35714
[Bug c++/36149] -O2 optimization generates wrong code
--- Comment #3 from dino at concisoft dot com 2008-05-06 14:18 ---
templateclass Y static LINK* LC(Y* X) {
return static_castLINK*(X);
}
templateclass Y static const LINK* LCC(Y* X) {
return static_castconst LINK*(X);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36149
[Bug middle-end/36013] [4.1/4.3/4.4 Regression] Wrong code involving restricted pointers to non-restricted pointers
--- Comment #5 from ian at airs dot com 2008-05-06 14:23 ---
I introduced DECL_BASED_ON_RESTRICT_P because the conversion to SSA discarded
almost all information about restrict qualifiers. The compiler was tracking
restrict qualifiers on the original variable, but not on the GIMPLE variables.
The main use of restrict qualifiers at the RTL level is in the scheduler, and I
didn't realize that it would be possible to write a machine-independent test
case.
DECL_BASED_ON_RESTRICT_P is meant to indicate that the temporary has the same
restrict qualifiers as the DECL_GET_RESTRICT_BASE. It's not meant to be a
general implementation of based on as defined by the standard. It's only
meant to say this GIMPLE temporary has the same restrict qualifiers as this
user variable.
This patch fixes the problem, although I haven't tested it.
Index: gimplify.c
===
--- gimplify.c (revision 134283)
+++ gimplify.c (working copy)
@@ -391,6 +391,13 @@ find_single_pointer_decl_1 (tree *tp, in
{
tree *pdecl = (tree *) data;
+ /* We are only looking for pointers at the same level as the
+ original tree; we must not look through any indirections.
+ Returning anything other than NULL_TREE will cause the caller to
+ not find a base. */
+ if (REFERENCE_CLASS_P (*tp))
+return *tp;
+
if (DECL_P (*tp) POINTER_TYPE_P (TREE_TYPE (*tp)))
{
if (*pdecl)
@@ -406,8 +413,9 @@ find_single_pointer_decl_1 (tree *tp, in
return NULL_TREE;
}
-/* Find the single DECL of pointer type in the tree T and return it.
- If there are zero or more than one such DECLs, return NULL. */
+/* Find the single DECL of pointer type in the tree T, used directly
+ rather than via an indirection, and return it. If there are zero
+ or more than one such DECLs, return NULL. */
static tree
find_single_pointer_decl (tree t)
@@ -418,7 +426,8 @@ find_single_pointer_decl (tree t)
{
/* find_single_pointer_decl_1 returns a nonzero value, causing
walk_tree to return a nonzero value, to indicate that it
-found more than one pointer DECL. */
+found more than one pointer DECL or that it found an
+indirection. */
return NULL_TREE;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36013
[Bug testsuite/36155] New: UTF tests doesn't work on Linux
This patch
http://gcc.gnu.org/ml/gcc-patches/2008-05/msg00275.html
breaks UTF tests on Linux. Does check_effective_target_4byte_wchar_t
really work? I got
bash-3.2$ cat w.c
#if 0
#include wchar.h
#endif
int
main ()
{
int dummy[sizeof (wchar_t) = 4 ? 1 : -1];
return 0;
}
bash-3.2$ gcc -c w.c
w.c: In function 'main':
w.c:8: error: 'wchar_t' undeclared (first use in this function)
w.c:8: error: (Each undeclared identifier is reported only once
w.c:8: error: for each function it appears in.)
bash-3.2$
Is wchar.h included for your test?
--
Summary: UTF tests doesn't work on Linux
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36155
[Bug fortran/36153] ICE on size with kind parameter
--- Comment #1 from burnus at gcc dot gnu dot org 2008-05-06 14:43 ---
Confirmed. Note: Using -std=f95 the kind= is properly rejected.
==16567== Invalid read of size 4
==16567==at 0x4605FD: gfc_resolve_expr (resolve.c:2310)
==16567==by 0x465625: resolve_code (resolve.c:6195)
==16567==by 0x468D1B: gfc_resolve_blocks (resolve.c:5988)
==16567==by 0x46560C: resolve_code (resolve.c:6187)
==16567==by 0x466F40: resolve_codes (resolve.c:9121)
I think the following comparison does not make sense for KIND= (I have only
glanced at it):
for (arg = expr-value.function.actual; arg; arg = arg-next)
{
if (inquiry arg-next != NULL arg-next-expr)
{
if (arg-next-expr-expr_type != EXPR_CONSTANT)
break;
if ((int)mpz_get_si (arg-next-expr-value.integer)
arg-expr-rank)
break;
I think this function still assumes that one uses only DIM= and not KIND=. The
failing line is the mpz_get_si, although that should work? Allowed options are:
SIZE (ARRAY [, DIM, KIND])
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||ice-on-valid-code
Known to fail||4.3.1 4.4.0
Last reconfirmed|-00-00 00:00:00 |2008-05-06 14:43:06
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36153
[Bug libfortran/36156] New: gfortran.dg/fmt_t_7.f failed
Revision 134973 http://gcc.gnu.org/ml/gcc-cvs/2008-05/msg00133.html breaks gfortran.dg/fmt_t_7.f on Linux/ia32 and Linux/Intel64. -- Summary: gfortran.dg/fmt_t_7.f failed Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36156
[Bug fortran/36157] New: ICE in snapshot of 05/02/08 under FreeBSD i386 with IMPLICIT and function call
The following subroutine produces a segfault when compiled with the 05/02/08 snapshot of gfortran 4.4.0 under FreeBSD i386. I believe it is related to Bugs 36139 and 36140. This test case is just like the first one in Bug 36139 except that the PARAMETER statement is omitted. SUBROUTINE mnbrak IMPLICIT REAL(a-f) f=func() END SUBROUTINE mnbrak -- Summary: ICE in snapshot of 05/02/08 under FreeBSD i386 with IMPLICIT and function call Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michael dot a dot richmond at nasa dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36157
[Bug fortran/36158] New: Transformational function BESSEL_YN(n1,n2,x) and BESSEL_JN missing
Fortran 2008 (PR 33197) supports the BESSEL_* functions. However, for BESSEL_*N there are two versions: A) An elemental function BESSEL_YN(N, X) and BESSEL_JN(N,X) B) An transformational function BESSEL_YN(N1,N2,X) and BESSEL_JN(N1,N2,Y) (B) Is currently not supported: The result of BESSEL_JN (N1, N2, X) is a rank-one array with extent MAX(N2#8722;N1+1,0). Element i of the result value of BESSEL_JN (N1, N2, X) is a processor-dependent approximation to the Bessel function of the first kind and order N1+i #8722; 1 of X. Note that one needs to simplify also the transformational version as one can also use it in initialization expressions. See also PR 36096 and 36117 and http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/e9add97708681397 -- Summary: Transformational function BESSEL_YN(n1,n2,x) and BESSEL_JN missing Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36158
[Bug fortran/36153] ICE on size with kind parameter
--- Comment #2 from kargl at gcc dot gnu dot org 2008-05-06 15:17 --- The problem arises because fortran/trans-intrinsics.c and libgfortran/intrinsics/size.c were not updated to deal with the addition of the KIND keyword. If you change the code to use size(array, dim=1, kind=long), then the kind=long is essentially ignored. In your case, _gfortran_size1 is given dim=long, which is dim=8, which of course segfaults. To get a error message, add -std=f95 to your command line; otherwise, gfortran accepts most Fortran 2003 intrinsic subprograms by default. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36153
[Bug c++/36149] -O2 optimization generates wrong code
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-05-06 15:23 --- This looks like you are violating C/C++ aliasing rules from that definition. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36149
[Bug middle-end/36154] internal compiler error: in get_constraint_for_component_ref, at tree-ssa-structalias.c:2727
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36154
[Bug target/36144] [4.4 Regression] gcc.dg/vect/vect-reduc-1short.c and gcc.dg/vect/vect-reduc-9.c fail
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-05-06 15:26 --- *** Bug 36152 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dominiq at lps dot ens dot ||fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36144
[Bug middle-end/36152] [4.4 Regression] invalid character '' in mnemonic at revision 134957
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-06 15:26 --- *** This bug has been marked as a duplicate of 36144 *** -- 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=36152
[Bug other/36150] colorize output of gcc
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-06 15:28 --- I don't think we should do this. There is already a secondary program that does the coloring too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150
[Bug target/35657] Alignments of DFP types aren't consistent
--- Comment #12 from hjl at gcc dot gnu dot org 2008-05-06 15:41 --- Subject: Bug 35657 Author: hjl Date: Tue May 6 15:41:08 2008 New Revision: 134987 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134987 Log: 2008-05-06 H.J. Lu [EMAIL PROTECTED] PR target/35657 * config/i386/i386.c (contains_128bit_aligned_vector_p): Renamed to ... (contains_aligned_value_p): This. Handle _Decimal128. (ix86_function_arg_boundary): Only align _Decimal128 to its natural boundary and handle it properly. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35657
[Bug c++/36149] -O2 optimization generates wrong code
--- Comment #5 from dino at concisoft dot com 2008-05-06 15:42 ---
Are we missing a const, or would you care to give a bit more specific comment?
I see that:
templateclass Y static const LINK* LCC(Y* X) {
return static_castconst LINK*(X);
}
could be missing a const in the declaration of Y* X, should probably be const
Y* X. Is that what you're referring to?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36149
[Bug c++/36151] gcc fails to find template specializations within namespace
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-06 15:44 ---
This is correct behavior.
templateclass T void bar( T v ) { v.foo(); }
templateclass T void bar( BT x ) { bar( *x ); }
templateclass T void bar( AT x ) { bar( *x ); }
Since AT is not in the namespace N, the second bar only sees itself and the
first bar (in its overloaded set).
If you want working code use the following:
namespace N {
templateclass T void bar( T v );
templateclass T void bar( BT x );
templateclass T void bar( AT x );
templateclass T void bar( T v ) { v.foo(); }
templateclass T void bar( BT x ) { bar( *x ); }
templateclass T void bar( AT x ) { bar( *x ); }
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36151
[Bug c++/36149] -O2 optimization generates wrong code
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-05-06 15:45 --- As I mentioned it looks like you are violating aliasing rules. Basically you are accessing one type as another. But without a full testcase I cann't be sure. Also Does -O2 -fno-strict-aliasing work? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36149
[Bug c++/36159] New: C++ compiler should issue a warning with missing new operator
[EMAIL PROTECTED] tmp]$ cat a.cc
#include stdio.h
#include emmintrin.h
struct A {
public:
__m128i m;
void init() { m = _mm_setzero_si128(); }
};
int main()
{
A * a = new A;
printf(Address of A: %p\n, a);
a-init();
delete a;
return 0;
}
[EMAIL PROTECTED] tmp]$ g++ -m32 -msse3 a.cc
[EMAIL PROTECTED] tmp]$ ./a.out
Address of A: 0x804a008
Segmentation fault
[EMAIL PROTECTED] tmp]$
If we add dynamic allocation with explicit alignment support to C++, we
immediately have to answer the question: does this extension require new
syntax?
If it doesn't -- in other words, if we just change the way code is generated
for a new-expression -- then some existing carefully-written code will be
broken.
If it does, then existing template code won't take advantage of it. So, for
example, if we store our SIMD data in a standard C++ library container, it
(probably) won't work because it won't be properly aligned.
This is the reason why no one has yet come up with a general solution to this
problem, even though it has been a known issue for over ten years. The best
that anyone's been able to do is the class-specific operator new.
For this testcase, g++ should issue an error when the class-specific operator
new is missing.
--
Summary: C++ compiler should issue a warning with missing new
operator
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36159
[Bug tree-optimization/36054] bad code generation with -ftree-vectorize
--- Comment #20 from hjl dot tools at gmail dot com 2008-05-06 16:10 --- It is a bug in testcase. But g++ doesn't diagnose it properly. I opened PR 36159 for it. -- hjl dot tools at gmail dot com changed: What|Removed |Added BugsThisDependsOn||36159 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36054
[Bug c++/36159] C++ compiler should issue a warning with missing new operator
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-06 16:11 --- Actually we (Sony) have come up with a solution but not much as come about with it though. If you read Trevor's proposal, you would have found we did come up with one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36159
[Bug c++/36159] C++ compiler should issue a warning with missing new operator
--- Comment #2 from hjl dot tools at gmail dot com 2008-05-06 16:28 --- Trevor, can you scale down your original proposal just to issue an error when there is no class-specific operator new for a type with an alignment greater than what malloc() guarantees? It will be programmer's responsibility to provide appropriate new operator. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||tsmigiel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36159
[Bug c++/36149] -O2 optimization generates wrong code
--- Comment #7 from dino at concisoft dot com 2008-05-06 16:54 --- -O2 -fno-strict-aliasing does work. I think the LC and LLC functions always cast from a derived class to a base class. That shouldn't cause aliasing problems, but I need to learn more about that. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36149
[Bug fortran/36117] Use MPFR for bessel function (optimization, rejects valid F2008)
--- Comment #3 from burnus at gcc dot gnu dot org 2008-05-06 17:07 --- Subject: Bug 36117 Author: burnus Date: Tue May 6 17:06:54 2008 New Revision: 134988 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134988 Log: 2008-05-06 Tobias Burnus [EMAIL PROTECTED] PR fortran/36117 * intrinsic.c (add_functions): Call gfc_simplify_bessel_*. * intrinsic.h: Add prototypes for gfc_simplify_bessel_*. * simplify.c (gfc_simplify_bessel_j0,gfc_simplify_bessel_j1, gfc_simplify_bessel_jn,gfc_simplify_bessel_y0, gfc_simplify_bessel_y1,gfc_simplify_bessel_yn): New. 2008-05-06 Tobias Burnus [EMAIL PROTECTED] PR fortran/36117 * gfortran.dg/bessel_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/bessel_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36117
[Bug fortran/36117] Use MPFR for bessel function (optimization, rejects valid F2008)
--- Comment #4 from burnus at gcc dot gnu dot org 2008-05-06 17:09 --- FIXED on the trunk (4.4.0). -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36117
[Bug libfortran/36156] gfortran.dg/fmt_t_7.f failed
--- Comment #1 from burnus at gcc dot gnu dot org 2008-05-06 17:11 --- I think this is side effect of reverting the patch of PR 34974 (which caused several regressions) without removing its now failing test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36156
[Bug preprocessor/36088] Unevaluated PP expression rejected
--- Comment #3 from tromey at gcc dot gnu dot org 2008-05-06 17:15 --- Subject: Bug 36088 Author: tromey Date: Tue May 6 17:15:07 2008 New Revision: 134989 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134989 Log: gcc/testsuite PR preprocessor/35313, PR preprocessor/36088: * gcc.dg/cpp/pr35313.c: New file. * gcc.dg/cpp/if-oppr.c: Remove test for ',' in a conditional expression. * gcc.dg/cpp/if-oppr2.c: New file. libcpp PR preprocessor/35313, PR preprocessor/36088: * expr.c (optab) QUERY, COMMA: Set precedence to 4. (reduce) case CPP_QUERY: Special case CPP_COMMA and CPP_COLON. Added: trunk/gcc/testsuite/gcc.dg/cpp/if-oppr2.c trunk/gcc/testsuite/gcc.dg/cpp/pr35313.c Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/cpp/if-oppr.c trunk/libcpp/ChangeLog trunk/libcpp/expr.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36088
[Bug preprocessor/35313] Valid pp-expression rejected in C99 mode
--- Comment #3 from tromey at gcc dot gnu dot org 2008-05-06 17:15 --- Subject: Bug 35313 Author: tromey Date: Tue May 6 17:15:07 2008 New Revision: 134989 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134989 Log: gcc/testsuite PR preprocessor/35313, PR preprocessor/36088: * gcc.dg/cpp/pr35313.c: New file. * gcc.dg/cpp/if-oppr.c: Remove test for ',' in a conditional expression. * gcc.dg/cpp/if-oppr2.c: New file. libcpp PR preprocessor/35313, PR preprocessor/36088: * expr.c (optab) QUERY, COMMA: Set precedence to 4. (reduce) case CPP_QUERY: Special case CPP_COMMA and CPP_COLON. Added: trunk/gcc/testsuite/gcc.dg/cpp/if-oppr2.c trunk/gcc/testsuite/gcc.dg/cpp/pr35313.c Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/cpp/if-oppr.c trunk/libcpp/ChangeLog trunk/libcpp/expr.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35313
[Bug other/36150] colorize output of gcc
--- Comment #2 from esigra at gmail dot com 2008-05-06 17:27 --- I would definitely like GCC to produce colourized output. It can really improve the readability. I miss that feature. It has my vote. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150
[Bug other/36150] colorize output of gcc
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-06 17:35 --- http://schlueters.de/colorgcc.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150
[Bug other/36150] colorize output of gcc
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-05-06 17:37 --- I rather not add too much complexity to gcc diagnostic output. Which means no color. colorgcc could be extended to get the correct coloring for the locazation. See also http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31983 . -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150
[Bug c/31983] Add option to gcc to display specific language manual section reference for error/warning encountered.
--- Comment #4 from esigra at gmail dot com 2008-05-06 18:00 --- (In reply to comment #3) 2) Standards are not freely distributable, thus they are not widely available. You say that as if it was a general fact, but it is certainly not. For example the Ada reference manual is available right here: [http://www.ada-auth.org/arm.html] More correct would be to say that *some* standards are not widely available. Finally, if you still think it is worth it, you could implement it yourself as a wrapper to the output of GCC (similar to how colorgcc [*] works). You must mean similar to how colorgcc *not* works. colorgcc is just an ugly hack that should be scrapped and burned as soon as GCC is fixed to format its own output properly. What colorgcc tries to do is total nonsense. It tries to parse localized output! Of course it fails for 94% of the supported languages (only English sort-of works as far as I know). Even English may fail if there is a version mismatch. And seriously, what is more efficent, adding a colour code sequence to the string constant in GCC that says warning: or having separate scripts for each combination of locale and GCC version, that parse the output of GCC and recreates it with colour codes? What would distributions prefer to maintain? -- esigra at gmail dot com changed: What|Removed |Added CC||esigra at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31983
[Bug other/36150] colorize output of gcc
--- Comment #5 from pva at gentoo dot org 2008-05-06 18:07 --- Andrew, it's very pity to see this bug closed as invalid so fast. Besides being useful, people enjoy colors and people work with compilers... I've already stated that, but I repeat. colorgcc does not work in case you have localized output (see our bug report). Reading source of colorgcc it seems that it uses words like warning or error as a key to parse and colorize output. Thus taking into account the number of human languages gcc is translated to and will be in future, adding complexity of having different encodings leaves colorgcc hardly working without fixing it with rasp-file after translation updates or additions. The complexity of this makes me think that it's natural to have this feature in place where error/warning is thrown - that is in gcc itself... bug 36150 although could help, as it makes possible to parse error based on numbers, works only for languages with stable references where it's hardly possible that numbers changes, as in other case wrong coloring could mislead programmer... Summarizing, I do not see why decision error or warning we have should be decided based on output after gcc and not in first place - in gcc itself - where it's known with high certainty. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150
[Bug preprocessor/35313] Valid pp-expression rejected in C99 mode
--- Comment #4 from tromey at gcc dot gnu dot org 2008-05-06 18:09 --- Fixed on trunk. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.4.0 Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35313
[Bug preprocessor/36088] Unevaluated PP expression rejected
--- Comment #4 from tromey at gcc dot gnu dot org 2008-05-06 18:10 --- Fixed on trunk. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.4.0 Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36088
[Bug testsuite/36155] UTF tests doesn't work on Linux
--- Comment #1 from hjl dot tools at gmail dot com 2008-05-06 18:12 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2008-05/msg00333.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||05/msg00333.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36155
[Bug fortran/36160] New: show_locus doesn't deal well with wide characters
print *, 'Hello World'wrong ! position is OK 1 Error: Syntax error in PRINT statement at (1) print *, 'Hello W\xC3\xB6rld'wrong ! Position is misleading 1 Error: Syntax error in PRINT statement at (1) (see proposition by Tobias at http://gcc.gnu.org/ml/gcc-patches/2008-05/msg00334.html) -- Summary: show_locus doesn't deal well with wide characters Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: diagnostic Severity: enhancement Priority: P3 Component: fortran AssignedTo: fxcoudert at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36160
[Bug fortran/36160] show_locus doesn't deal well with wide characters
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-05-06 18:19:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36160
[Bug c/31983] Add option to gcc to display specific language manual section reference for error/warning encountered.
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-05-06 18:21 --- But seriously colorization should not be done in the compiler. Just like IDE should not be part of the compiler ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31983
[Bug testsuite/36155] UTF tests doesn't work on Linux
--- Comment #2 from hjl at gcc dot gnu dot org 2008-05-06 18:37 --- Subject: Bug 36155 Author: hjl Date: Tue May 6 18:37:03 2008 New Revision: 134994 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134994 Log: 2008-05-06 H.J. Lu [EMAIL PROTECTED] PR testsuite/36155 * gcc.dg/utf32-4.c: Fix a typo. * lib/target-supports.exp (check_effective_target_4byte_wchar_t): Use __WCHAR_TYPE__ instead of wchar_t. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/utf32-4.c trunk/gcc/testsuite/lib/target-supports.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36155
[Bug other/36150] colorize output of gcc
--- Comment #6 from esigra at gmail dot com 2008-05-06 18:40 --- (In reply to comment #4) I rather not add too much complexity to gcc diagnostic output. Which means no color. We did not demand that you do it personally. We just think that it would be a really good idea if someone would do it some time. Just how much complexity would it take? colorgcc could be extended to get the correct coloring for the locazation. Sure it *could* be done, but it would require a version of colorgcc for each (combination of GCC version and) localization. Now we are talking about complexity! Localized output is inherently unsuitable for parsing. The existence of such an ugly hack is certainly no excuse for not allowing a proper implementation in GCC itself, where it belongs. And seriously, what is more efficcent, adding a colour code sequence to the string constans in GCC that says warning:, error: etc or having a bunch of scripts for parsing the output of various GCC versions/localizations, recreating it with colour codes? What would distributions prefer to maintain? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150
[Bug fortran/36063] [win64] Wrong results for RRSPACING, SCALE, SET_EXPONENT and SPACING
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2008-05-06 18:45 --- The mingw-w64 CRT were wrong, but have been fixed since then. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36063
[Bug c/31983] Add option to gcc to display specific language manual section reference for error/warning encountered.
--- Comment #6 from esigra at gmail dot com 2008-05-06 18:47 --- (In reply to comment #5) But seriously colorization should not be done in the compiler. Just like IDE should not be part of the compiler ... Colorization of a message is part of the message. It should obviously be done whereever the message is constructed. (IDE has nothing to do with this.) With your argument, the compiler should not do text messages (or any localization thereof) either, but rather return some code that an external program formats/localizes and presents to the user in a suitable way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31983
[Bug libstdc++/36130] Atomics regression test fail to compile when parallel mode is enabled
--- Comment #2 from bkoz at gcc dot gnu dot org 2008-05-06 18:58 --- Subject: Bug 36130 Author: bkoz Date: Tue May 6 18:57:46 2008 New Revision: 134995 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134995 Log: 2008-05-06 Benjamin Kosnik [EMAIL PROTECTED] PR libstdc++/36130 * include/bits/c++config: Namespace macros and setup only in C++. * testsuite/29_atomics/headers/stdatomic.h/debug_mode.c: New. Added: trunk/libstdc++-v3/testsuite/29_atomics/headers/stdatomic.h/debug_mode.c Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/c++config -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36130
[Bug c++/33979] support for char16_t, char32_t
--- Comment #5 from bkoz at gcc dot gnu dot org 2008-05-06 19:02 --- The compiler parts of this are done, or well along in terms of progress. For the library, I think it makes sense to start with _GLIBCXX_USE_CHAR16_T and _GLIBCXX_USE_CHAR32_T configury and macros, and then ease into support with things like numeric_limits and char_traits. -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33979
[Bug libfortran/36156] gfortran.dg/fmt_t_7.f failed
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-05-06 19:09 --- I xfailed it and forgot to commit it. I will do that tonight. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36156
[Bug target/36028] [IRA] ICE in reload_cse_simplify_operands
--- Comment #3 from vmakarov at redhat dot com 2008-05-06 19:11 --- Thanks for decreasing the test case. The problem was in wrong mode of save/restore stack slot when it was reused for another hard register. It resulted in generation of wrong save/restore insn and after that in a wrong secondary reload insn needed for this insn and the last insn caused a crash in the postreload pass. The patch solving the problem will follow soon. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36028
[Bug target/36028] [IRA] ICE in reload_cse_simplify_operands
--- Comment #4 from vmakarov at gcc dot gnu dot org 2008-05-06 19:22 --- Subject: Bug 36028 Author: vmakarov Date: Tue May 6 19:22:07 2008 New Revision: 134996 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134996 Log: 2008-05-06 Vladimir Makarov [EMAIL PROTECTED] PR rtl-optimization/36028 * caller-save.c (setup_save_areas): Adjust reused stack slot. Modified: branches/ira/gcc/ChangeLog branches/ira/gcc/caller-save.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36028
[Bug fortran/36161] New: gfc_error formats are not marked gcc-internal-format in po file
The first argument of gfc_error seems to be a format string of the form tagged with gcc-internal-format elsewhere in the po file. But it seems gfc_error formats are instead tagged with no-c-format. This is somewhat dangerous, since msgfmt will not discover mistakes in the translation, mistakes that potentially could cause a crash. (Yes, it happened. I had done a few such mistakes in sv.po, which was just pointed out to me in a friendly letter.) -- Summary: gfc_error formats are not marked gcc-internal-format in po file Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: goeran at uddeborg dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36161
[Bug fortran/35990] run-time abort for PACK of run-time zero sized array
--- Comment #10 from tkoenig at gcc dot gnu dot org 2008-05-06 20:47 --- Subject: Bug 35990 Author: tkoenig Date: Tue May 6 20:46:41 2008 New Revision: 134999 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134999 Log: 2008-05-06 Thomas Koenig [EMAIL PROTECTED] PR libfortran/35995 PR libfortran/35990 Backport from trunk. * m4/ifunction_logical.m4: If the extent of array is less than zero, set it to zero. Use an explicit flag for breaking out of the main loop to avoid, because the data pointer for array may be NULL for an empty array. * m4/ifunction.m4: Likewise. * generated/all_l1.c: Regenerated. * generated/all_l16.c: Regenerated. * generated/all_l2.c: Regenerated. * generated/all_l4.c: Regenerated. * generated/all_l8.c: Regenerated. * generated/any_l1.c: Regenerated. * generated/any_l16.c: Regenerated. * generated/any_l2.c: Regenerated. * generated/any_l4.c: Regenerated. * generated/any_l8.c: Regenerated. * generated/count_16_l.c: Regenerated. * generated/count_1_l.c: Regenerated. * generated/count_2_l.c: Regenerated. * generated/count_4_l.c: Regenerated. * generated/count_8_l.c: Regenerated. * generated/maxloc1_16_i1.c: Regenerated. * generated/maxloc1_16_i16.c: Regenerated. * generated/maxloc1_16_i2.c: Regenerated. * generated/maxloc1_16_i4.c: Regenerated. * generated/maxloc1_16_i8.c: Regenerated. * generated/maxloc1_16_r10.c: Regenerated. * generated/maxloc1_16_r16.c: Regenerated. * generated/maxloc1_16_r4.c: Regenerated. * generated/maxloc1_16_r8.c: Regenerated. * generated/maxloc1_4_i1.c: Regenerated. * generated/maxloc1_4_i16.c: Regenerated. * generated/maxloc1_4_i2.c: Regenerated. * generated/maxloc1_4_i4.c: Regenerated. * generated/maxloc1_4_i8.c: Regenerated. * generated/maxloc1_4_r10.c: Regenerated. * generated/maxloc1_4_r16.c: Regenerated. * generated/maxloc1_4_r4.c: Regenerated. * generated/maxloc1_4_r8.c: Regenerated. * generated/maxloc1_8_i1.c: Regenerated. * generated/maxloc1_8_i16.c: Regenerated. * generated/maxloc1_8_i2.c: Regenerated. * generated/maxloc1_8_i4.c: Regenerated. * generated/maxloc1_8_i8.c: Regenerated. * generated/maxloc1_8_r10.c: Regenerated. * generated/maxloc1_8_r16.c: Regenerated. * generated/maxloc1_8_r4.c: Regenerated. * generated/maxloc1_8_r8.c: Regenerated. * generated/maxval_i1.c: Regenerated. * generated/maxval_i16.c: Regenerated. * generated/maxval_i2.c: Regenerated. * generated/maxval_i4.c: Regenerated. * generated/maxval_i8.c: Regenerated. * generated/maxval_r10.c: Regenerated. * generated/maxval_r16.c: Regenerated. * generated/maxval_r4.c: Regenerated. * generated/maxval_r8.c: Regenerated. * generated/minloc1_16_i1.c: Regenerated. * generated/minloc1_16_i16.c: Regenerated. * generated/minloc1_16_i2.c: Regenerated. * generated/minloc1_16_i4.c: Regenerated. * generated/minloc1_16_i8.c: Regenerated. * generated/minloc1_16_r10.c: Regenerated. * generated/minloc1_16_r16.c: Regenerated. * generated/minloc1_16_r4.c: Regenerated. * generated/minloc1_16_r8.c: Regenerated. * generated/minloc1_4_i1.c: Regenerated. * generated/minloc1_4_i16.c: Regenerated. * generated/minloc1_4_i2.c: Regenerated. * generated/minloc1_4_i4.c: Regenerated. * generated/minloc1_4_i8.c: Regenerated. * generated/minloc1_4_r10.c: Regenerated. * generated/minloc1_4_r16.c: Regenerated. * generated/minloc1_4_r4.c: Regenerated. * generated/minloc1_4_r8.c: Regenerated. * generated/minloc1_8_i1.c: Regenerated. * generated/minloc1_8_i16.c: Regenerated. * generated/minloc1_8_i2.c: Regenerated. * generated/minloc1_8_i4.c: Regenerated. * generated/minloc1_8_i8.c: Regenerated. * generated/minloc1_8_r10.c: Regenerated. * generated/minloc1_8_r16.c: Regenerated. * generated/minloc1_8_r4.c: Regenerated. * generated/minloc1_8_r8.c: Regenerated. * generated/minval_i1.c: Regenerated. * generated/minval_i16.c: Regenerated. * generated/minval_i2.c: Regenerated. * generated/minval_i4.c: Regenerated. * generated/minval_i8.c: Regenerated. * generated/minval_r10.c: Regenerated. * generated/minval_r16.c: Regenerated. * generated/minval_r4.c: Regenerated. * generated/minval_r8.c: Regenerated. * generated/product_c10.c: Regenerated. * generated/product_c16.c: Regenerated. * generated/product_c4.c: Regenerated. *
[Bug fortran/35995] ANY, ALL, and COUNT errors for zero sized sections
--- Comment #8 from tkoenig at gcc dot gnu dot org 2008-05-06 20:47 --- Subject: Bug 35995 Author: tkoenig Date: Tue May 6 20:46:41 2008 New Revision: 134999 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134999 Log: 2008-05-06 Thomas Koenig [EMAIL PROTECTED] PR libfortran/35995 PR libfortran/35990 Backport from trunk. * m4/ifunction_logical.m4: If the extent of array is less than zero, set it to zero. Use an explicit flag for breaking out of the main loop to avoid, because the data pointer for array may be NULL for an empty array. * m4/ifunction.m4: Likewise. * generated/all_l1.c: Regenerated. * generated/all_l16.c: Regenerated. * generated/all_l2.c: Regenerated. * generated/all_l4.c: Regenerated. * generated/all_l8.c: Regenerated. * generated/any_l1.c: Regenerated. * generated/any_l16.c: Regenerated. * generated/any_l2.c: Regenerated. * generated/any_l4.c: Regenerated. * generated/any_l8.c: Regenerated. * generated/count_16_l.c: Regenerated. * generated/count_1_l.c: Regenerated. * generated/count_2_l.c: Regenerated. * generated/count_4_l.c: Regenerated. * generated/count_8_l.c: Regenerated. * generated/maxloc1_16_i1.c: Regenerated. * generated/maxloc1_16_i16.c: Regenerated. * generated/maxloc1_16_i2.c: Regenerated. * generated/maxloc1_16_i4.c: Regenerated. * generated/maxloc1_16_i8.c: Regenerated. * generated/maxloc1_16_r10.c: Regenerated. * generated/maxloc1_16_r16.c: Regenerated. * generated/maxloc1_16_r4.c: Regenerated. * generated/maxloc1_16_r8.c: Regenerated. * generated/maxloc1_4_i1.c: Regenerated. * generated/maxloc1_4_i16.c: Regenerated. * generated/maxloc1_4_i2.c: Regenerated. * generated/maxloc1_4_i4.c: Regenerated. * generated/maxloc1_4_i8.c: Regenerated. * generated/maxloc1_4_r10.c: Regenerated. * generated/maxloc1_4_r16.c: Regenerated. * generated/maxloc1_4_r4.c: Regenerated. * generated/maxloc1_4_r8.c: Regenerated. * generated/maxloc1_8_i1.c: Regenerated. * generated/maxloc1_8_i16.c: Regenerated. * generated/maxloc1_8_i2.c: Regenerated. * generated/maxloc1_8_i4.c: Regenerated. * generated/maxloc1_8_i8.c: Regenerated. * generated/maxloc1_8_r10.c: Regenerated. * generated/maxloc1_8_r16.c: Regenerated. * generated/maxloc1_8_r4.c: Regenerated. * generated/maxloc1_8_r8.c: Regenerated. * generated/maxval_i1.c: Regenerated. * generated/maxval_i16.c: Regenerated. * generated/maxval_i2.c: Regenerated. * generated/maxval_i4.c: Regenerated. * generated/maxval_i8.c: Regenerated. * generated/maxval_r10.c: Regenerated. * generated/maxval_r16.c: Regenerated. * generated/maxval_r4.c: Regenerated. * generated/maxval_r8.c: Regenerated. * generated/minloc1_16_i1.c: Regenerated. * generated/minloc1_16_i16.c: Regenerated. * generated/minloc1_16_i2.c: Regenerated. * generated/minloc1_16_i4.c: Regenerated. * generated/minloc1_16_i8.c: Regenerated. * generated/minloc1_16_r10.c: Regenerated. * generated/minloc1_16_r16.c: Regenerated. * generated/minloc1_16_r4.c: Regenerated. * generated/minloc1_16_r8.c: Regenerated. * generated/minloc1_4_i1.c: Regenerated. * generated/minloc1_4_i16.c: Regenerated. * generated/minloc1_4_i2.c: Regenerated. * generated/minloc1_4_i4.c: Regenerated. * generated/minloc1_4_i8.c: Regenerated. * generated/minloc1_4_r10.c: Regenerated. * generated/minloc1_4_r16.c: Regenerated. * generated/minloc1_4_r4.c: Regenerated. * generated/minloc1_4_r8.c: Regenerated. * generated/minloc1_8_i1.c: Regenerated. * generated/minloc1_8_i16.c: Regenerated. * generated/minloc1_8_i2.c: Regenerated. * generated/minloc1_8_i4.c: Regenerated. * generated/minloc1_8_i8.c: Regenerated. * generated/minloc1_8_r10.c: Regenerated. * generated/minloc1_8_r16.c: Regenerated. * generated/minloc1_8_r4.c: Regenerated. * generated/minloc1_8_r8.c: Regenerated. * generated/minval_i1.c: Regenerated. * generated/minval_i16.c: Regenerated. * generated/minval_i2.c: Regenerated. * generated/minval_i4.c: Regenerated. * generated/minval_i8.c: Regenerated. * generated/minval_r10.c: Regenerated. * generated/minval_r16.c: Regenerated. * generated/minval_r4.c: Regenerated. * generated/minval_r8.c: Regenerated. * generated/product_c10.c: Regenerated. * generated/product_c16.c: Regenerated. * generated/product_c4.c: Regenerated. *
[Bug fortran/35995] ANY, ALL, and COUNT errors for zero sized sections
--- Comment #9 from tkoenig at gcc dot gnu dot org 2008-05-06 20:49 --- Fixed on 4.3. Closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.3.1 | Known to work|4.4.0 |4.4.0 4.3.1 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35995
[Bug fortran/35990] run-time abort for PACK of run-time zero sized array
--- Comment #11 from tkoenig at gcc dot gnu dot org 2008-05-06 20:50 --- Fixed on 4.3. Closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.3.1 | Known to work|4.4.0 |4.4.0 4.3.1 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35990
[Bug libfortran/36131] [4.4 Regression] wrong IO
--- Comment #6 from tkoenig at gcc dot gnu dot org 2008-05-06 20:53 --- Hi Jerry, did you commit the test case to make sure we don't regress again? Thomas -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36131
[Bug fortran/35719] pointer to zero sized array not associated
--- Comment #5 from tkoenig at gcc dot gnu dot org 2008-05-06 21:24 --- Created an attachment (id=15587) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15587action=view) Trial patch Here's an attempt at a patch, which should do the right thing at least for this case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35719
[Bug fortran/36162] New: Non-ASCII character in module string gives ICE
We need to escape non-printable characters when we read/write module files. Otherwise, big bad ICE: module m character(*), parameter :: a ='H\0z' end module m use m print *, a ! ICE print *, ichar(a(1:1)), ichar(a(2:2)), ichar(a(3:3)) ! ICE end -- Summary: Non-ASCII character in module string gives ICE Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: fxcoudert at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36162
[Bug fortran/36162] Non-ASCII character in module string gives ICE
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-05-06 21:27:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36162
[Bug other/36150] colorize output of gcc
--- Comment #7 from brian at dessent dot net 2008-05-06 21:28 --- Subject: Re: colorize output of gcc esigra at gmail dot com wrote: And seriously, what is more efficcent, adding a colour code sequence to the string constans in GCC that says warning:, error: etc or having a bunch of scripts for parsing the output of various GCC If you added escape sequences to the string constants in the gcc source then it would only work for the C locale messages. And isn't your whole complaint that colorgcc fails for non-C locales? In other words, this would not do anything in the very case you care about, because in non-C locales the message strings are taken from the po file and not the literal strings in the source code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150
[Bug c++/36163] New: Friend declaration confused by namespace/using
This code:
namespace name {
class foo {
public:
templateclass T
voidbaz(T t) { int i = t.dat; }
};
}
using namespace name;
class bar {
friend class foo;
int dat;
};
int main() {
bar b;
foo f;
f.baz(b);
}
gets you:
~/ootbc/members$ g++ foo.cc
foo.cc: In member function 'void name::foo::baz(T) [with T = bar]':
foo.cc:16: instantiated from here
foo.cc:11: error: 'int bar::dat' is private
foo.cc:5: error: within this context
--
Summary: Friend declaration confused by namespace/using
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36163
[Bug c++/36163] Friend declaration confused by namespace/using
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-06 21:31 --- I don't think this is a bug, the friend class here is really ::foo. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36163
[Bug testsuite/36155] UTF tests doesn't work on Linux
--- Comment #3 from hjl at gcc dot gnu dot org 2008-05-06 21:36 --- Subject: Bug 36155 Author: hjl Date: Tue May 6 21:35:33 2008 New Revision: 135008 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135008 Log: 2008-05-06 H.J. Lu [EMAIL PROTECTED] PR testsuite/36155 * g++.dg/ext/utf32-4.C: Fix a typo. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/ext/utf32-4.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36155
[Bug c++/36163] Friend declaration confused by namespace/using
--- Comment #2 from igodard at pacbell dot net 2008-05-06 21:39 --- Isn't ::foo the using'd class from name? If not, how does one befriend a class that comes from a using? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36163
[Bug other/36150] colorize output of gcc
--- Comment #8 from esigra at gmail dot com 2008-05-06 21:55 --- (In reply to comment #7) If you added escape sequences to the string constants in the gcc source then it would only work for the C locale messages. Adding escape sequences for colours would work as well with localization as any other formatting. Simple example: printf(%s%s%s%s, warning_format_start, _(warning: ), _(the actual message), warning_format_end); Here warning_format_start may be a pointer to orange and warning_format_end a pointer to /orange. If colours are disabled, they both point to . So the result might be warning: the actual message or orangewarning: the actual message/orange. Localization would work fine for both warning: and the actual message. I do not really see the problem that you were thinking of. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150
[Bug other/36150] colorize output of gcc
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-05-06 21:58 --- The other issue here is that people want different colors for each of their warnings so why hardcode it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150
[Bug other/36150] colorize output of gcc
--- Comment #10 from brian at dessent dot net 2008-05-06 22:06 --- Subject: Re: colorize output of gcc esigra at gmail dot com wrote: printf(%s%s%s%s, warning_format_start, _(warning: ), _(the actual message), warning_format_end); But then that is not simply adding a colour code sequence to the string constans in GCC, i.e. you can't just grep for warning: and change it to \033[01;32warning:, it's much more involved. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150
[Bug middle-end/36013] [4.1/4.3/4.4 Regression] Wrong code involving restricted pointers to non-restricted pointers
--- Comment #6 from jakub at gcc dot gnu dot org 2008-05-06 22:56 ---
Created an attachment (id=15588)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15588action=view)
gcc44-pr36013.patch
Patch I've bootstrapped/regtested on x86_64-linux. Will you check this in, or
should I mail it to gcc-patches?
I've played with testcases like:
int
foo (int *__restrict p, int *__restrict q)
{
int *r, *s, t;
*p = 1;
*q = 2;
p[6] = 3;
q[6] = 4;
for (r = p, s = q, t = 0; r p + 64; r++, s++)
{
*r = 7;
*s = 88;
t += *r;
}
return t;
}
and here neither tree nor RTL aliasing is ATM able to optimize the subsequent
read from *r out - while the accesses before the loop use different alias sets
(3 resp. 4), in the loop everything uses alias set 2, but that isn't a
regression introduced with this patch, so probably DECL_BASED_ON_RESTRICT_P
stuff needs more work, but that is unrelated to this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36013
[Bug libstdc++/36164] New: abi breakage, stdio_sync_filebuf routines missing
A few routines seem to have disappeared from 4.0.0 to 4.2.1: mrs2 $ nm /usr/lib/libstdc++.6.0.4.dylib | grep __ZN9__gnu_cxx18stdio_sync_filebuf | c++filt 000252d2 T __gnu_cxx::stdio_sync_filebufchar, std::char_traitschar ::file() 000252fc T __gnu_cxx::stdio_sync_filebufchar, std::char_traitschar ::sync() 000252de T __gnu_cxx::stdio_sync_filebufchar, std::char_traitschar ::uflow() 00025894 T __gnu_cxx::stdio_sync_filebufchar, std::char_traitschar ::seekoff(long long, std::_Ios_Seekdir, std::_Ios_Openmode) 00025a3c T __gnu_cxx::stdio_sync_filebufchar, std::char_traitschar ::seekpos(std::fpos__mbstate_t, std::_Ios_Openmode) 0002554c T __gnu_cxx::stdio_sync_filebufchar, std::char_traitschar ::overflow(int) 00025b02 T __gnu_cxx::stdio_sync_filebufchar, std::char_traitschar ::pbackfail(int) 00025bda T __gnu_cxx::stdio_sync_filebufchar, std::char_traitschar ::underflow() 00025542 T __gnu_cxx::stdio_sync_filebufchar, std::char_traitschar ::stdio_sync_filebuf(__sFILE*) 00025504 T __gnu_cxx::stdio_sync_filebufchar, std::char_traitschar ::stdio_sync_filebuf(__sFILE*) 0002530e T __gnu_cxx::stdio_sync_filebufwchar_t, std::char_traitswchar_t ::file() 0002531a T __gnu_cxx::stdio_sync_filebufwchar_t, std::char_traitswchar_t ::sync() 00025bbc T __gnu_cxx::stdio_sync_filebufwchar_t, std::char_traitswchar_t ::uflow() 00025968 T __gnu_cxx::stdio_sync_filebufwchar_t, std::char_traitswchar_t ::seekoff(long long, std::_Ios_Seekdir, std::_Ios_Openmode) 0002532c T __gnu_cxx::stdio_sync_filebufwchar_t, std::char_traitswchar_t ::seekpos(std::fpos__mbstate_t, std::_Ios_Openmode) 00025ab8 T __gnu_cxx::stdio_sync_filebufwchar_t, std::char_traitswchar_t ::overflow(int) 00025b4a T __gnu_cxx::stdio_sync_filebufwchar_t, std::char_traitswchar_t ::pbackfail(int) 00025b92 T __gnu_cxx::stdio_sync_filebufwchar_t, std::char_traitswchar_t ::underflow() 000254fa T __gnu_cxx::stdio_sync_filebufwchar_t, std::char_traitswchar_t ::stdio_sync_filebuf(__sFILE*) 000254bc T __gnu_cxx::stdio_sync_filebufwchar_t, std::char_traitswchar_t ::stdio_sync_filebuf(__sFILE*) mrs2 $ nm /usr/lib/libstdc++.6.0.9.dylib | grep __ZN9__gnu_cxx18stdio_sync_filebuf | c++filt 0002c57c T __gnu_cxx::stdio_sync_filebufchar, std::char_traitschar ::file() 0002c5dc T __gnu_cxx::stdio_sync_filebufchar, std::char_traitschar ::seekpos(std::fpos__mbstate_t, std::_Ios_Openmode) 0002c588 T __gnu_cxx::stdio_sync_filebufwchar_t, std::char_traitswchar_t ::file() 0002c9ae T __gnu_cxx::stdio_sync_filebufwchar_t, std::char_traitswchar_t ::seekpos(std::fpos__mbstate_t, std::_Ios_Openmode) :-( This breaks Norton Anti Virus v11. Radar 5897367 -- Summary: abi breakage, stdio_sync_filebuf routines missing Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mrs at apple dot com GCC target triplet: powerpc-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36164
[Bug libstdc++/36164] abi breakage, stdio_sync_filebuf routines missing
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-07 00:12 --- Was this ever supposed to be used external from libstdc++? It is in the __gnu_cxx namespace. I don't think they are exported at all under GNU/Linux with elf exports. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36164
[Bug libstdc++/36164] abi breakage, stdio_sync_filebuf routines missing
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-07 00:18 --- # __gnu_cxx::stdio_sync_filebuf _ZTVN9__gnu_cxx18stdio_sync_filebufI[cw]St11char_traitsI[cw]EEE; _ZN9__gnu_cxx18stdio_sync_filebufI[cw]St11char_traitsI[cw]EE4fileEv; _ZN9__gnu_cxx18stdio_sync_filebufI[cw]St11char_traitsI[cw]EE4syncEv; _ZN9__gnu_cxx18stdio_sync_filebufI[cw]St11char_traitsI[cw]EE[5-9CD]*; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36164
[Bug libfortran/34974] null bytes when reverse-tabbing long records (regression vs. g77)
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2008-05-07 02:29 --- Subject: Bug 34974 Author: jvdelisle Date: Wed May 7 02:28:45 2008 New Revision: 135017 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135017 Log: 2008-05-06 Jerry DeLisle [EMAIL PROTECTED] PR libfortran/34974 gfortran.dg/fmt_t_7.f: XFAIL this until we get issue resolved. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/fmt_t_7.f -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34974
[Bug libfortran/36156] gfortran.dg/fmt_t_7.f failed
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-05-07 02:32 --- I committed the XFAILed test case. Sorry for the inconvenience. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36156
[Bug libfortran/36156] gfortran.dg/fmt_t_7.f failed
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-05-07 02:33 --- Closing -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36156
[Bug libstdc++/36164] abi breakage, stdio_sync_filebuf routines missing
--- Comment #3 from mrs at apple dot com 2008-05-07 02:40 --- Adding: +_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEE4syncEv; +_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEE5uflowEv; +_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEE6xsgetnEPci; +_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEE6xsputnEPKci; + _ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEE7seekoffExSt12_Ios_SeekdirSt13_Ios_Openmode; +_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEE8overflowEi; +_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEE9pbackfailEi; +_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEE9underflowEv; +_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEEC1EP7__sFILE; +_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEEC2EP7__sFILE; +_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEED0Ev; +_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEED1Ev; +_ZN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEED2Ev; +_ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEE4syncEv; +_ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEE5uflowEv; +_ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEE6xsgetnEPwi; +_ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEE6xsputnEPKwi; + _ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEE7seekoffExSt12_Ios_SeekdirSt13_Ios_Openmode; +_ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEE8overflowEi; +_ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEE9pbackfailEi; +_ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEE9underflowEv; +_ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEEC1EP7__sFILE; +_ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEEC2EP7__sFILE; +_ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEED0Ev; +_ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEED1Ev; +_ZN9__gnu_cxx18stdio_sync_filebufIwSt11char_traitsIwEED2Ev; back to libstdc++-v3/config/abi/pre/gnu.ver seems to make it better. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36164
[Bug libfortran/36131] [4.4 Regression] wrong IO
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2008-05-07 02:45 --- One of the problems here is how to do a test case for writing to stdout. We would have to create a pipe and write to it and read back from the other side. I don't know how to do that in the testsuite. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36131
[Bug libstdc++/36164] abi breakage, stdio_sync_filebuf routines missing
--- Comment #4 from mrs at apple dot com 2008-05-07 02:58 --- Thinking and supposing are bad substitutes for solid engineering. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36164
[Bug c++/36149] -O2 optimization generates wrong code
--- Comment #8 from bangerth at dealii dot org 2008-05-07 04:17 --- The point is: without the complete source code nothing definitive can be said whether it's the compiler's or the programmer's fault. Your chances that someone will take the time to try to understand what's going on increase exponentially if you manage to produce a small testcase, whereas they are pretty low if all you can show is several thousand lines of code. 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=36149
[Bug c++/36159] C++ compiler should issue a warning with missing new operator
--- Comment #3 from bangerth at dealii dot org 2008-05-07 04:21 --- How is the compiler supposed to know about what alignment malloc can produce? How can it know that ::operator new doesn't increase the alignment automatically? 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=36159
[Bug middle-end/36013] [4.1/4.3/4.4 Regression] Wrong code involving restricted pointers to non-restricted pointers
--- Comment #7 from ian at airs dot com 2008-05-07 04:39 --- I'll approve the patch. I think it's correct. I'll check it in in a day or two, or you can go ahead and do it if you are ready. Thanks for testing it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36013
[Bug testsuite/36165] New: Foreign exceptions for Objective-C and C++ are not tested
Since both C++ and Objective-C support foreign exceptions, they should be tested. I don't know where the best place to put the testcase. I want to say the Objective-C testsuite and add a check to make sure the C++ front-end was built. -- Summary: Foreign exceptions for Objective-C and C++ are not tested Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: testsuite AssignedTo: pinskia at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36165
[Bug testsuite/36165] Foreign exceptions for Objective-C and C++ are not tested
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-07 04:52 --- Mine. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-05-07 04:52:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36165
