[Bug libstdc++/29603] New: Warning in tr1 header with -Wshadow
The TR1 header functional issues the following warning when using -Wshadow: /usr/include/c++/4.1.1/tr1/functional_iterate.h:202: warning: declaration of __pmf shadows a member of 'this' -- Summary: Warning in tr1 header with -Wshadow Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: pcarlini at suse dot de ReportedBy: bernie at develer dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29603
[Bug libstdc++/29224] -Wshadow causing warning in tr1/functional
--- Comment #5 from bernie at develer dot com 2006-10-26 09:30 --- *** Bug 29603 has been marked as a duplicate of this bug. *** -- bernie at develer dot com changed: What|Removed |Added CC||bernie at develer dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29224
[Bug libstdc++/29603] Warning in tr1 header with -Wshadow
--- Comment #1 from bernie at develer dot com 2006-10-26 09:30 --- Sorry, I've just noticed this was a dupe, and it's already fixed on trunk. *** This bug has been marked as a duplicate of 29224 *** -- bernie at develer dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29603
[Bug c++/28659] [4.2 regression] ICE (segfault) while compiling kdelibs 4.0 snapshot
--- Comment #18 from bernie at develer dot com 2006-08-28 06:18 --- (In reply to comment #17) And that is Redhat's branch which has the patch which caused this in the first place on it. Thus, I've filed a bug report in RedHat's bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=204277 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28659
[Bug c++/28659] [4.2 regression] ICE (segfault) while compiling kdelibs 4.0 snapshot
--- Comment #14 from bernie at develer dot com 2006-08-28 00:59 --- Please also backport to 4.1 (see #28863). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28659
[Bug c++/28659] [4.2 regression] ICE (segfault) while compiling kdelibs 4.0 snapshot
--- Comment #16 from bernie at develer dot com 2006-08-28 05:05 --- (In reply to comment #15) This never existed on 4.1. gcc 4.1.1 from FC6 crashes with the testcase of bug 28863. Maybe it's some redhat specific patch, but they follow gcc's 4.0-branch quite closely these days: Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.1 20060825 (Red Hat 4.1.1-19) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28659
[Bug c++/28863] New: ICE on template class with visibility specification
The following testcase:
templateclass T class __attribute__((visibility(default))) Foo
{
FooT bar();
};
templateclass T FooT FooT::bar()
{
}
Produces:
foo.cpp: In member function #8216;FooT FooT::bar()#8217;:
foo.cpp:6: internal compiler error: Segmentation fault
--
Summary: ICE on template class with visibility specification
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bernie at develer dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28863
[Bug c/24976] New: simple hexadecimal number parsed as C99 hex float
This testcase: int a = 0xe+100; Produces a diagnostic message that would surprise most users: foo.c:1:9: error: invalid suffix +100 on integer constant I'm not sure what the standard says about ambiguity between the hex float notation and the regular + operator, but many users are going to think of this behavior as a parser bug. -- Summary: simple hexadecimal number parsed as C99 hex float Product: gcc Version: 4.0.3 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bernie at develer dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24976
[Bug preprocessor/24976] simple hexadecimal number parsed as C99 hex float
--- Comment #3 from bernie at develer dot com 2005-11-21 18:41 --- (In reply to comment #2) 0xe+100 is a single preprocessing number. If the end of http://gcc.gnu.org/onlinedocs/gcc/Incompatibilities.html is unclear, please let us know how we could have improved it so that you would have realised it applies to this situation and so there is no bug. We could handle it like we do for in nested template declarations: split the token and try reparsing the expression with the other meaning. If it works, give the friendly error message (maybe you meant 0xe + 100?). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24976
[Bug target/18421] ICE in reload_cse_simplify_operands, at postreload.c:391
--- Additional Comments From bernie at develer dot com 2005-07-11 21:07 --- A revised patch was posted here: http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00853.html I will attach it here in case someone wants to apply it to an old version of GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18421
[Bug target/18421] ICE in reload_cse_simplify_operands, at postreload.c:391
--- Additional Comments From bernie at develer dot com 2005-07-11 23:23 --- Created an attachment (id=9246) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9246action=view) Updated patch -- What|Removed |Added Attachment #8577 is|0 |1 obsolete|| AssignedTo|unassigned at gcc dot gnu |bernie at develer dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18421
[Bug target/16719] [ColdFire] Illegal move of byte itno address register causes compiler to ICE
--- Additional Comments From bernie at develer dot com 2005-07-11 23:25 --- Patch attached to Bug #18421 (Attachment #9246). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16719
[Bug target/18421] ICE in reload_cse_simplify_operands, at postreload.c:391
--- Additional Comments From bernie at develer dot com 2005-07-11 23:33 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18421
[Bug target/16719] [ColdFire] Illegal move of byte itno address register causes compiler to ICE
--- Additional Comments From bernie at develer dot com 2005-07-11 23:34 --- Fixed on mainline. Pending for 4.0 and 3.4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16719
[Bug target/18421] ICE in reload_cse_simplify_operands, at postreload.c:391
--- Additional Comments From bernie at develer dot com 2005-07-11 23:35 --- Oops... still pending for 4.0 and 3.4. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18421
[Bug c++/21832] New: Linker error when taking reference of static integral data member
Also happens with 3.3.5 and 4.0.0. The test case
is so simple I'm surprised nobody noticed before.
Unless of course I need to take a new C++ course.
---cut---
void bar(const int a) { }
struct Foo
{
static const int X = 10;
};
int main()
{
bar(Foo::X);
return 0;
}
---cut---
/tmp/ccYC57Zg.o(.text+0x23): In function `main':
foo.cpp: undefined reference to `Foo::X'
collect2: ld returned 1 exit status
--
Summary: Linker error when taking reference of static integral
data member
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: critical
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bernie at develer dot com
CC: aleph at develer dot com,gcc-bugs at gcc dot gnu dot
org,giovannibajo at libero dot it
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=21832
[Bug c++/21832] Linker error when taking reference of static integral data member
-- What|Removed |Added Known to fail||4.0.0 3.3.5 3.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21832
[Bug c++/21832] Linker error when taking reference of static integral data member
--- Additional Comments From bernie at develer dot com 2005-05-30 21:56 --- (In reply to comment #1) What a quick response! This is a dup of bug 14404. I thought this was on the bug reporting web page (maybe not), well it should be. It's there, I just didn't see it. This is invalid code, see comment #1 in PR 14404 for how to fix your code. Yeah, I'm quite astonished. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21832
[Bug c++/19317] [4.1 Regression] removing a temporary return value when we cannot
--- Additional Comments From bernie at develer dot com 2005-05-19 09:45 --- (In reply to comment #38) My backtrace looks suspiciously similar to the backtrace reported in comment #14. Yep, yours is probably the same bug as that in comment #14, which I don't think is related to the original bug report. 20949 was opened for that bug, then closed for lack of a testcase. Ah, OK. Then I think this bug should be closed: the patch is already applied and the other testcases (comment #1, comment #2 and comment #4) all work for me. Reducing a testcase isn't trivial, but I'll try. Thanks. If you do come up with one, it probably makes the most sense to attach it to 20949 and reopen it. Will do. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19317
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From bernie at develer dot com 2005-05-19 10:00 --- (In reply to comment #49) Mark, is http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00180.html OK for mainline as well as 4.0? It's OK for mainline. It's not OK for 4.0 unless it's a regression. It's not a regresion, but it causes KDE to miscompile with GCC 4.0.0. Could we apply it for 4.0 anyway? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug c++/19317] [4.1 Regression] removing a temporary return value when we cannot
--- Additional Comments From bernie at develer dot com 2005-05-19 10:42
---
(In reply to comment #39)
(In reply to comment #37)
Reducing a testcase isn't trivial, but I'll try.
try to pass to the ./configure the kde_cv_val_gcc_visibility_bug=yes switch.
rebuild and test artsd. it may help.
I ran the acinclude.m4 test manually, and it
links fine for me (altough the binary crashes
on startup).
$ cat foo.cpp
/* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664 */
#include string
int some_function( void ) __attribute__ ((visibility(default)));
int some_function( void )
{
std::string s(blafasel);
return 0;
}
$ g++ -fPIC -fvisibility-inlines-hidden -O0 -shared foo.cpp -o foo
$ ./foo
Segmentation fault
currently i have a gcc-4.0.1-20050514(+patches:19664,20218,v3)
and artsd works fine without hacks.
I'll try to build with those patches, thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19317
[Bug c++/19317] [4.1 Regression] removing a temporary return value when we cannot
--- Additional Comments From bernie at develer dot com 2005-05-18 20:45 --- (In reply to comment #36) (In reply to comment #35) I'm still seeing the artsd miscompilation with gcc 4.0.0 20050512 (Red Hat 4.0.0-5), which contains everything from gcc-4_0-branch upto 13-05-2005 (circa). A backtrace showing a crash is not a very useful bug report, and probably has nothing to do with this bug report. It might not even be a gcc bug, as the konqueror failure was not. If you can track down the miscompilation, we'd love to hear about it in a new bug report. My backtrace looks suspiciously similar to the backtrace reported in comment #14. My backtrace is from an arts client, not from the artsd server, but they do share lots of common code. I've tried to debug the problem: something weird happens in the destructor of a vectorstring, then GDB seems to get confused by stack/registers corruption. It really looks like a code generation bug to me. Reducing a testcase isn't trivial, but I'll try. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19317
[Bug c++/19317] [4.1 Regression] removing a temporary return value when we cannot
--- Additional Comments From bernie at develer dot com 2005-05-17 05:40 --- I'm still seeing the artsd miscompilation with gcc 4.0.0 20050512 (Red Hat 4.0.0-5), which contains everything from gcc-4_0-branch upto 13-05-2005 (circa). This is from an arts *client*: Starting program: /home/bernie/src/gfactory/src/gfactory Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0x73d000 [Thread debugging using libthread_db enabled] [New Thread -1209042464 (LWP 20182)] unix_connect: can't connect to server (unix:/tmp/mcop-root/beetle_trilan-0cad-4289417b) bernie: here9 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1209042464 (LWP 20182)] 0x006359b7 in __gnu_cxx::__pooltrue::_M_reclaim_block () from /usr/lib/libstdc++.so.6 (gdb) bt #0 0x006359b7 in __gnu_cxx::__pooltrue::_M_reclaim_block () from /usr/lib/libstdc++.so.6 #1 0x00913fef in __gnu_cxx::__mt_allocstd::string, __gnu_cxx::__common_pool_policy__gnu_cxx::__pool, true ::deallocate (this=0xbfc1fd38, __p=0x8509c68, __n=1) at /usr/lib/gcc/i386-redhat-linux/4.0.0/../../../../include/c++/4.0.0/ext/mt_allocator.h:746 #2 0x00914029 in std::_Vector_basestd::string, std::allocatorstd::string ::_M_deallocate (this=0xbfc1fd38, __p=0x8509c68, __n=1) at /usr/lib/gcc/i386-redhat-linux/4.0.0/../../../../include/c++/4.0.0/bits/stl_vector.h:123 #3 0x00914066 in ~_Vector_base (this=0xbfc1fd38) at /usr/lib/gcc/i386-redhat-linux/4.0.0/../../../../include/c++/4.0.0/bits/stl_vector.h:109 #4 0x009140cf in ~vector (this=0xbfc1fd38) at /usr/lib/gcc/i386-redhat-linux/4.0.0/../../../../include/c++/4.0.0/bits/stl_vector.h:273 #5 0x00914102 in ~ObjectReference (this=0xbfc1fd2c) at /usr/local/src/kde/arts/mcop/reference.h:48 #6 0x009069ad in Arts::SoundServer_base::_fromString ([EMAIL PROTECTED]) at soundserver.cc:1452 #7 0x00e1f0aa in arts_backend_init () from /usr/local/kde/lib/libartscbackend.so.0 #8 0xbfc1fd90 in ?? () #9 0x00e258cc in typeinfo name for Sender () from /usr/local/kde/lib/libartscbackend.so.0 #10 0x0017 in ?? () Previous frame inner to this frame (corrupt stack?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19317
[Bug target/19293] avr-gcc crashes when using shifts with negative shift count
--- Additional Comments From bernie at develer dot com 2005-01-26 23:11 --- Please also apply to 3.4-branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19293
[Bug target/19597] [4.0 Regression] avr-gcc 4.0, multiplication by constant, very long code
--- Additional Comments From bernie at develer dot com 2005-01-24 10:28 --- Subject: Re: [4.0 Regression] avr-gcc 4.0, multiplication by constant, very long code marekm at amelek dot gda dot pl wrote: --- Additional Comments From marekm at amelek dot gda dot pl 2005-01-24 09:24 --- Subject: Re: [4.0 Regression] avr-gcc 4.0, multiplication by constant, very long code On Mon, Jan 24, 2005 at 08:56:46AM -, giovannibajo at libero dot it wrote: Marek, can you review this patch please? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19597 Thanks. Reviewing this will take some time - I agree the current rtx costs are not perfect, but changing them can affect generated code in unexpected ways. It would be good to test it a lot on various test cases, to make sure it doesn't introduce new code size regressions... I'm building avr-gcc right now with your two patches and this one applied. I'll let you know shortly. btw, how do you test the AVR backend? Can you execute the dejagnu testsuite on simulavr or something similar? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19597
[Bug target/19597] [4.0 Regression] avr-gcc 4.0, multiplication by constant, very long code
--- Additional Comments From bernie at develer dot com 2005-01-24 13:15 --- Subject: Re: [4.0 Regression] avr-gcc 4.0, multiplication by constant, very long code Bernardo Innocenti wrote: marekm at amelek dot gda dot pl wrote: --- Additional Comments From marekm at amelek dot gda dot pl 2005-01-24 09:24 --- Subject: Re: [4.0 Regression] avr-gcc 4.0, multiplication by constant, very long code On Mon, Jan 24, 2005 at 08:56:46AM -, giovannibajo at libero dot it wrote: Marek, can you review this patch please? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19597 Thanks. Reviewing this will take some time - I agree the current rtx costs are not perfect, but changing them can affect generated code in unexpected ways. It would be good to test it a lot on various test cases, to make sure it doesn't introduce new code size regressions... I'm building avr-gcc right now with your two patches and this one applied. I'll let you know shortly. Not good. With these two patches applied, the size of four big AVR applications increased slightly. These were built with -Os (the second one shows a minor improvement): textdata bss dec hex filename 8008 136 40185452161 images-orig/dspslave.elf 8032 136 40185692179 images-patched/dspslave.elf textdata bss dec hex filename 18448 536 692 196764cdc images-orig/dspmaster.elf 18428 536 692 196564cc8 images-patched/dspmaster.elf These with -O2: textdata bss dec hex filename 6045418321562 63848f968 images-orig/kfront.elf 6048818321562 63882f98a images-patched/kfront.elf textdata bss dec hex filename 36160 9001713 387739775 images-orig/kcntrl.elf 36344 9001713 38957982d images-patched/kcntrl.elf Would you like to see some diffs? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19597
[Bug middle-end/19597] [4.0 Regression] avr-gcc 4.0, multiplication by constant, very long code
--- Additional Comments From bernie at develer dot com 2005-01-24 00:49 --- Confirmed: --- 3.4 output --- ldi r18,lo8(24011) ldi r19,hi8(24011) mul r24,r18 movw r20,r0 mul r24,r19 add r21,r0 mul r25,r18 add r21,r0 clr r1 movw r24,r20 -- --- 4.0 output --- movw r22,r24 movw r18,r24 add r18,r24 adc r19,r25 add r18,r18 adc r19,r19 add r18,r24 adc r19,r25 movw r24,r18 add r24,r18 adc r25,r19 add r24,r24 adc r25,r25 add r24,r24 adc r25,r25 sub r24,r18 sbc r25,r19 movw r18,r24 add r18,r24 adc r19,r25 add r18,r18 adc r19,r19 add r18,r18 adc r19,r19 sub r18,r24 sbc r19,r25 movw r20,r18 add r20,r18 adc r21,r19 add r20,r20 adc r21,r21 add r20,r20 adc r21,r21 sub r20,r18 sbc r21,r19 movw r24,r20 add r24,r20 adc r25,r21 add r24,r24 adc r25,r25 add r24,r24 adc r25,r25 sub r24,r20 sbc r25,r21 add r24,r24 adc r25,r25 add r24,r22 adc r25,r23 -- -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-24 00:49:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19597
[Bug target/19293] avr-gcc crashes when using shifts with negative shift count
--- Additional Comments From bernie at develer dot com 2005-01-20 05:46 --- (In reply to comment #10) Hi, here is the changed patch for avr.c . I hope that it is now compliant to the gcc coding standards. I however did not understand what you have meant with this hunk adds spurious whitespace. There's a change of one line that adds a single whitespace after an opening brace. Also, there's an if-block that has the braces indented by one space instead of two spaces. Sorry for being picky. I'll fix these before committing if the patch gets approved. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19293
[Bug target/19329] [3.4 Regression] Miscompilation with bitfields
--- Additional Comments From bernie at develer dot com 2005-01-19 00:03 --- (In reply to comment #11) By the way at #19293, you will also find a patch suggestion that should be eaysily adapted to all of the present shifting problems. I agree PR19293 is a superset of this bug, so I'll close it and withdraw my (already approved) patch. Could you update your patch with a test for = 0? Please post it in gcc-patches, with me and Marek Michalkiewicz [EMAIL PROTECTED] in Cc. I will take care to install your patch in CVS as soon as it gets approved. *** This bug has been marked as a duplicate of 19293 *** -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19329
[Bug target/19293] avr-gcc crashes when using shifts with negative shift count
--- Additional Comments From bernie at develer dot com 2005-01-19 00:04 --- *** Bug 19329 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||giovannibajo at libero dot ||it http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19293
[Bug middle-end/19329] [3.4 Regression] Miscompilation with bitfields
--- Additional Comments From bernie at develer dot com 2005-01-19 00:06 --- Oops, I forgot this bug should stay open until someone figures out why GCC 3.4 leaks through insns with a 0 shift count. I've reclassified the bug as affecting the middle-end. -- What|Removed |Added Status|RESOLVED|REOPENED Component|target |middle-end Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19329
[Bug target/19293] avr-gcc crashes when using shifts with negative shift count
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bernie at develer dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-01-15 05:53:55 |2005-01-19 00:09:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19293
[Bug middle-end/19329] [3.4 Regression] Bitfield operations cause shifts with 0-count to slip through backends
--- Additional Comments From bernie at develer dot com 2005-01-19 00:11 --- I'm no longer in charge for this bug. -- What|Removed |Added AssignedTo|bernie at develer dot com |unassigned at gcc dot gnu ||dot org Status|REOPENED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19329
[Bug target/19293] avr-gcc crashes when using shifts with negative shift count
--- Additional Comments From bernie at develer dot com 2005-01-19 00:18
---
(In reply to comment #3)
A quick informal review.
if (GET_CODE (operands[2]) == CONST_INT)
{
int k;
if (!len)
len = k;
!
This line contains spurious whitespace.
! if ( (INTVAL(operands[2]) 0) || (INTVAL(operands[2]) 7) )
The coding standard requires a space between INTVAL and the
opening parenthesis.
Also remember to replace with =!
!{ /* illegal shift count */
! *len = 0;
! return ;
!}
The comment should stay on its own line, with
capitalized initial, a full stop (.) at the
end, followed by *two* whitespaces.
This also applies to the other hunks.
const char *
lshrhi3_out (rtx insn, rtx operands[], int *len)
{
if (GET_CODE (operands[2]) == CONST_INT)
! {
int scratch = (GET_CODE (PATTERN (insn)) == PARALLEL);
int ldi_ok = test_hard_reg_class (LD_REGS, operands[0]);
int k;
This hunk adds spurious whitespace after the opening brace.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19293
[Bug target/19329] [3.4 Regression] Miscompilation with bitfields
--- Additional Comments From bernie at develer dot com 2005-01-08 17:57 --- Also fails with this pre-release version: avr-gcc (GCC) 3.4.3 20041019 (prerelease) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Bootstrapping today's mainline right now. -- What|Removed |Added Known to fail|3.4.2 |3.4.2 3.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19329
[Bug target/18592] [3.3/3.4 regression] [m68k] ICE in output_operand: invalid expression as operand
--- Additional Comments From bernie at develer dot com 2004-12-15 22:37 --- Note: PR 18542 also covers avr-* targets. Comment #7 in PR18542 said that separate PR's were going to be filed for avr and h8300. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18592
[Bug rtl-optimization/18612] Loop optimiser generates incorrect code.
--- Additional Comments From bernie at develer dot com 2004-12-13 08:53 --- What happens here is that func2() is inlined inside func(), and j loaded into %a0 before entering the loop, for improved speed. The test for Array[i] 0 is correctly performed *inside* the loop. This PR appears to be invalid to me, but I'll wait for a clarification before closing it. func: link.w %a6,#0 clr.b %d0 lea Array,%a1 moveq #0,%d1 move.l j,%a0 .align 2 .L8: move.b %d0,%d1 tst.b (%a1,%d1.l) jbeq .L5 addq.l #1,%a0 .L5: addq.b #1,%d0 cmp.b #5,%d0 jbls .L8 move.l %a0,j unlk %a6 rts -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18612
[Bug target/18592] [3.3/3.4 regression] [m68k] ICE in output_operand: invalid expression as operand
--- Additional Comments From bernie at develer dot com 2004-12-13 09:14 --- And you also need -m68020 to trigger the bug. Works fine with -m68000, so the bug must hide in one of the TARGET_68020 patterns. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18592
[Bug target/18592] [3.3/3.4 regression] [m68k] ICE in output_operand: invalid expression as operand
--- Additional Comments From bernie at develer dot com 2004-12-13 09:29
---
It happens both on ColdFire and 680x0 (x=2), but not
on 68000.
output_addr_const() gets passed a TRUNCATE (HImode) rtx.
I could find it in the last dump before the ICE:
(insn 87 45 127 3 (set (reg:HI 0 %d0 [35])
(const:HI (truncate:HI (minus:SI (label_ref:SI 11)
(label_ref:SI 54) 28 {*m68k.md:784} (nil)
(insn_list:REG_LABEL 11 (insn_list:REG_LABEL 54 (nil
The pattern definition in m68k.md is:
(define_insn
[(set (match_operand:HI 0 nonimmediate_operand =g)
(match_operand:HI 1 general_src_operand gS))]
!TARGET_COLDFIRE
* return output_move_himode (operands);)
It seems output_move_himode() inappropriately lets the
TRUNCATE pass through, but since the instruction being
generater is a move.l, the only place in output_move_himode()
where this could have happened is:
else if (CONSTANT_P (operands[1]))
return move%.l %1,%0;
I don't know how to fix it, this is all I could do.
The full GDB backtrace is:
#0 output_addr_const (file=0x82b7b50, x=0xb7fa94f0) at
/usr/local/src/uclinux-tools/gcc-3.4.3/gcc/final.c:3276
#1 0x080fa36e in output_addr_const (file=0x82b7b50, x=0xb7fa94f8)
at /usr/local/src/uclinux-tools/gcc-3.4.3/gcc/final.c:3202
#2 0x081d575e in print_operand ()
#3 0x080fa26b in output_operand (x=0xb7fa94f8, code=0) at
/usr/local/src/uclinux-tools/gcc-3.4.3/gcc/final.c:3145
#4 0x080fa03c in output_asm_insn (template=0x8246011 move%.l %1,%0,
operands=0x828ec20)
at /usr/local/src/uclinux-tools/gcc-3.4.3/gcc/final.c:3071
#5 0x080f9105 in final_scan_insn (insn=0xb7ff6820, file=0x82b7b50, optimize=2,
prescan=0, nopeepholes=0,
seen=0xb4fc) at /usr/local/src/uclinux-tools/gcc-3.4.3/gcc/final.c:2449
#6 0x080f7de7 in final (first=0xb7ff32c0, file=0x82b7b50, optimize=2,
prescan=0)
at /usr/local/src/uclinux-tools/gcc-3.4.3/gcc/final.c:1572
#7 0x081b8461 in rest_of_compilation ()
#8 0x081d81a2 in tree_rest_of_compilation ()
#9 0x08059ba2 in c_expand_body_1 ()
#10 0x081d937b in cgraph_expand_function ()
#11 0x081da690 in cgraph_optimize ()
#12 0x0807dd51 in c_objc_common_finish_file ()
#13 0x081b9c44 in toplev_main ()
#14 0x0808da4b in main ()
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18592
[Bug target/18592] [3.3/3.4 regression] [m68k] ICE in output_operand: invalid expression as operand
--- Additional Comments From bernie at develer dot com 2004-12-13 09:44 --- *** Bug 18542 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||corsepiu at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18592
[Bug target/18592] [3.3/3.4 regression] [m68k] ICE in output_operand: invalid expression as operand
--- Additional Comments From bernie at develer dot com 2004-12-13 09:45 --- Please see additional comments attached to PR18542: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18542 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18592
[Bug target/18542] [3.4 regression] ICE: output_operand: invalid expression as operand
--- Additional Comments From bernie at develer dot com 2004-12-13 09:43 --- *** This bug has been marked as a duplicate of 18592 *** -- What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18542
[Bug target/18385] code contains 68040 instructions
--- Additional Comments From bernie at develer dot com 2004-12-13 09:49 --- The top-level multilib directory is compiled for the default target, which is in some cases m68000, and in some cases m68020. m68k-elf defaults to m68000. Perhaps your linker script doesn't look into the m68040 subdirectory to fetch the correct version of crt0.o? Please attach your linker script. -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18385
[Bug target/18385] code contains 68040 instructions
--- Additional Comments From bernie at develer dot com 2004-12-14 01:23 --- Sorry, I've read your report vice-versa, because that's the most likely thing that could have happened (there were so many bogus uClinux reports that I finally decided to remove m68000 libraries from the toolchain distribution). Could you please add -v to your link command line and see what it says? You should see the m68k-elf-ld invocation with its full command-line. Now, I see that invoking gcc without any -m680x0 option would not generate code for 68020 by default: ---cut--- m68020-*-elf* | m68k-*-elf*) tm_file=m68k/m68k.h m68k/m68k-none.h m68k/m68kelf.h dbxelf.h elfos.h m68k/m68kemb.h m68k/m68020-elf.h tm_defines=MOTOROLA USE_GAS tmake_file=m68k/t-m68kelf extra_parts=crtbegin.o crtend.o use_fixproto=yes ;; ---cut--- (don't get fooled by the m68020-elf.h header, it just contains two harmless definitions). -- What|Removed |Added Status|WAITING |SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18385
[Bug middle-end/18887] [4.0 Regression] libgcc2.h Improperly determines required built-in function size requirements.
--- Additional Comments From bernie at develer dot com 2004-12-12 14:11 --- The ICE has been triggered by one of these patches: diff -u -p -r2.6723 -r2.6731 --- gcc/ChangeLog 6 Dec 2004 12:32:21 - 2.6723 +++ gcc/ChangeLog 7 Dec 2004 03:52:13 - 2.6731 @@ -1,3 +1,66 @@ +2004-12-06 Ziemowit Laski [EMAIL PROTECTED] + + * c-tree.h (struct lang_type): Add 'objc_protocols' field. + +2004-12-06 DJ Delorie [EMAIL PROTECTED] + + * reload.c (find_valid_class): Fix logic to test inner mode as well. + (push_reload): Pass inner mode. + +2004-12-06 Eric Christopher [EMAIL PROTECTED] + + * doc/tm.texi (TARGET_VALID_POINTER_MODE): Document. + +2004-12-06 Aldy Hernandez [EMAIL PROTECTED] + + * config/rs6000/sysv4.h: Define RELOCATABLE_NEEDS_FIXUP to 1. + +2004-12-06 Zdenek Dvorak [EMAIL PROTECTED] + Kazu Hirata [EMAIL PROTECTED] + + PR tree-optimization/18601 + * tree-cfg.c (thread_jumps, thread_jumps_from_bb): Removed. + (tree_forwarder_block_p): Do not consider blocks that are its own + successors forwarders. + (cleanup_forwarder_blocks, remove_forwarder_block): New functions. + (cleanup_tree_cfg): Use cleanup_forwarder_blocks instead of + thread_jumps. + * tree-flow.h (bb_ann_d): Remove forwardable. + +2004-12-06 Kazu Hirata [EMAIL PROTECTED] + + * expr.c (expand_expr_real_1): Remove an if whose condition + is always false. + +2004-12-06 Roger Sayle [EMAIL PROTECTED] + + * c-gimplify.c (gimplify_c_loop): Improve initial implementations + for loops whose conditions are known at compile-time. + * gimplify.c (append_to_statement_list_1): Remove side_effects + parameter, this function should never be called if its false. + (append_to_statement_list): Only call append_to_statement_list_1 + if t is non-NULL tree with side-effects. + (append_to_statement_list_force): Likewise, if t is not NULL. + +2004-12-06 Jorn Rennecke [EMAIL PROTECTED] + + * bt-load.c (btr_def_s): New member own_end; + (add_btr_to_live_range): Add second parameter. Changed caller. + (clear_btr_from_live_range): Clear btrs_live_at_end bit + for the register its definition basic block if own_end is set. + (augment_live_range): Also take btrs_live_at_end into account. + (combine_btr_defs): Don't bother with + other_def-other_btr_uses_after_use if it pertains to a different + register. + (move_btr_def): Set def-other_btr_uses_before_def after + calling combine_btr_defs. + + * bt-load.c (augment_live_range): New argument full_range. + Changed all callers. + + * bt-load.c (move_tr_def): Set other_tr_uses_before_def + taking new btr assignment into account. + 2004-12-05 Daniel Berlin [EMAIL PROTECTED] * tree-ssa-alias.c (create_global_var): Use void_type_node, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18887
[Bug target/18941] can't build latest 4.0 avr target (as of 12/11/04 cvs and earlier)
--- Additional Comments From bernie at develer dot com 2004-12-12 13:52 --- *** This bug has been marked as a duplicate of 18887 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18941
[Bug middle-end/18887] [4.0 Regression] libgcc2.h Improperly determines required built-in function size requirements.
--- Additional Comments From bernie at develer dot com 2004-12-12 13:52 --- *** Bug 18941 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18887
[Bug middle-end/18887] [4.0 Regression] libgcc2.h Improperly determines required built-in function size requirements.
--- Additional Comments From bernie at develer dot com 2004-12-12 14:22 --- More precisely, the ICE has been triggered by this patch: +2004-12-06 DJ Delorie [EMAIL PROTECTED] + + * reload.c (find_valid_class): Fix logic to test inner mode as well. + (push_reload): Pass inner mode. The problem is not *in* this patch, but while waiting for a proper fix, I could get GCC to build again for AVR by reversing it locally. -- What|Removed |Added CC||dj at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18887
[Bug target/17735] [4.0 Regression] make stops with initializer for integer value is too complicated while building an avr-cross compiler
--- Additional Comments From bernie at develer dot com 2004-11-18 18:41 --- Works for me, thanks! Patch still waiting for review in gcc-patches. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17735
[Bug target/18551] New: wrong asm output for -ffunction-sections with g++
The backend outputs invalid assembly containing full function signatures when compiling C++ sources with -ffunction-sections: ldi r30,pm_lo8(.L_bool updateEEParam(uint16_t, uint8_t*)_body) I'm not sure this is AVR specific, but it doesn't certainly happen on i386-linux. -- Summary: wrong asm output for -ffunction-sections with g++ Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: target AssignedTo: denisc at overta dot ru ReportedBy: bernie at develer dot com CC: gcc-bugs at gcc dot gnu dot org,marekm at amelek dot gda dot pl GCC target triplet: avr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18551
[Bug target/18552] New: Annoying warning with -ffunction-sections -g
When building with both -ffunction-sections and -g, the compiler outputs an invalid warning for each compiled file: drv/timer.c:1: warning: -ffunction-sections may affect debugging on some targets The code printing this is here: --- gcc/toplev.c --- #ifndef OBJECT_FORMAT_ELF if (flag_function_sections write_symbols != NO_DEBUG) warning (-ffunction-sections may affect debugging on some targets); #endif --- gcc/toplev.c --- A possible fix could be adding elfos.h to the tm_file list for the avr target in config.gcc, which may also lead to simplifications in some parts of config/avr.h. -- Summary: Annoying warning with -ffunction-sections -g Product: gcc Version: 3.4.4 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bernie at develer dot com CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: avr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18552
[Bug target/18553] New: Annoying warning with -ffunction-sections -g
When building with both -ffunction-sections and -g, the compiler outputs an invalid warning for each compiled file: drv/timer.c:1: warning: -ffunction-sections may affect debugging on some targets The code printing this is here: --- gcc/toplev.c --- #ifndef OBJECT_FORMAT_ELF if (flag_function_sections write_symbols != NO_DEBUG) warning (-ffunction-sections may affect debugging on some targets); #endif --- gcc/toplev.c --- A possible fix could be adding elfos.h to the tm_file list for the avr target in config.gcc, which may also lead to simplifications in some parts of config/avr.h. -- Summary: Annoying warning with -ffunction-sections -g Product: gcc Version: 3.4.4 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P2 Component: target AssignedTo: denisc at overta dot ru ReportedBy: bernie at develer dot com CC: gcc-bugs at gcc dot gnu dot org,marekm at amelek dot gda dot pl GCC host triplet: avr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18553
[Bug target/18553] Annoying warning with -ffunction-sections -g
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Known to fail||3.4.3 4.0.0 Last reconfirmed|-00-00 00:00:00 |2004-11-18 19:42:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18553
[Bug target/18551] wrong asm output for -mcall-prologues with g++
--- Additional Comments From bernie at develer dot com 2004-11-18 20:30 --- Oops, this PR should have been about -mcall-prologues, not -ffunction-sections. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-18 20:30:50 date|| Summary|wrong asm output for - |wrong asm output for -mcall- |ffunction-sections with g++ |prologues with g++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18551
[Bug target/17735] [4.0 Regression] make stops with initializer for integer value is too complicated while building an avr-cross compiler
--- Additional Comments From bernie at develer dot com 2004-11-17 00:54 --- Still present on mainline. Prevents bootstrap on avr. -- What|Removed |Added CC||bernie at develer dot com Last reconfirmed|2004-09-30 18:55:05 |2004-11-17 00:54:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17735
[Bug middle-end/14684] [4.0 Regression] -fprofile-use/-fprofile-generate failure because of coverage mismatch
--- Additional Comments From bernie at develer dot com 2004-10-22 19:37 --- I still see this bug on mainline when doing a profiledbootstrap: stage1/xgcc -Bstage1/ -B/usr/local/src/gcc/i386-linux-HEAD-install/i686-pc-linux-gnu/bin/ -c -O2 -g -fomit-frame-pointer -fprofile-use -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Werror -fno-common -DHAVE_CONFIG_H-I. -I. -I../../gcc-HEAD/gcc -I../../gcc-HEAD/gcc/. -I../../gcc-HEAD/gcc/../include -I../../gcc-HEAD/gcc/../libcpp/include ../../gcc-HEAD/gcc/attribs.c -o attribs.o ../../gcc-HEAD/gcc/attribs.c: In function 'decl_attributes': ../../gcc-HEAD/gcc/attribs.c:337: error: coverage mismatch for function 'decl_attributes' while reading counter 'arcs'. ../../gcc-HEAD/gcc/attribs.c:337: error: number of counters is 109 instead of 111 gmake[2]: *** [attribs.o] Error 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14684
[Bug target/17451] [3.4 Regression] ICE at insn-output.c:1495 with -O1
--- Additional Comments From bernie at develer dot com 2004-10-16 00:44 --- I can still see it with a recent snapshot from RawHide: gcc version 3.4.2 20041006 (Red Hat 3.4.2-5) So unless it has been accidentally fixed during the last 10 days, the bug is still in 3.4-branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17451
