--- Comment #6 from jakub at gcc dot gnu dot org 2009-12-30 09:02 ---
IMHO such a wrong-code should be fixed also on 4.4/4.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42099
--- Comment #22 from nospamname at web dot de 2009-12-30 09:39 ---
There is no m68k-amigaos support in
FSF GCC and I don't think there ever has been.
There is support for m68k-amigaos in FSF GCC.
search in gcc source for name amigaos and on changelog.lib you find this
Wed Sep 10
--- Comment #7 from irar at il dot ibm dot com 2009-12-30 10:16 ---
The bug is in SLP load permutation analysis. I am testing a patch.
--
irar at il dot ibm dot com changed:
What|Removed |Added
--- Comment #5 from paolo at gcc dot gnu dot org 2009-12-30 10:53 ---
Subject: Bug 42537
Author: paolo
Date: Wed Dec 30 10:53:31 2009
New Revision: 155518
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155518
Log:
/gcc
2009-12-30 Robert Millan rmh@aybabtu.com
PR
--- Comment #6 from paolo dot carlini at oracle dot com 2009-12-30 10:54
---
Done.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #23 from bonzini at gnu dot org 2009-12-30 10:56 ---
You need a proper patch, not instructions.
However, it's clear from the bugreport and the patches required to fix it, that
it is not important whether the target is m68k-amigaos or another OS.
--
--- Comment #1 from ubizjak at gmail dot com 2009-12-30 10:57 ---
Confirmed, I have a patch.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #37 from bonzini at gnu dot org 2009-12-30 10:59 ---
The bootstrap failure is fixed, please reconfirm and reopen bugs for other
failures or other targets.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #2 from uros at gcc dot gnu dot org 2009-12-30 11:07 ---
Subject: Bug 42549
Author: uros
Date: Wed Dec 30 11:07:12 2009
New Revision: 155519
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155519
Log:
PR target/42549
* config/i386/mmx.md
--- Comment #38 from bonzini at gnu dot org 2009-12-30 11:09 ---
Andreas, for s390-linux I get this jumpless code:
f:
xr %r2,%r3
lpr %r2,%r2
ahi %r2,-1
srl %r2,31
br %r14
for this testcase:
int f(int a, int b)
{
return
--- Comment #29 from debian-gcc at lists dot debian dot org 2009-12-30
11:13 ---
yes, sorry, you are right.
Matthias
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28322
--- Comment #30 from manu at gcc dot gnu dot org 2009-12-30 11:19 ---
No problem. This was implemented in GCC 4.4 and mentioned in the changes.html
page. We haven't received any complaints so far, so closing as FIXED.
--
manu at gcc dot gnu dot org changed:
What
--- Comment #14 from manu at gcc dot gnu dot org 2009-12-30 11:29 ---
*** Bug 42238 has been marked as a duplicate of this bug. ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from manu at gcc dot gnu dot org 2009-12-30 11:29 ---
-Winit-self is broken in C++
*** This bug has been marked as a duplicate of 34772 ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from uros at gcc dot gnu dot org 2009-12-30 11:35 ---
Subject: Bug 42549
Author: uros
Date: Wed Dec 30 11:34:57 2009
New Revision: 155521
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155521
Log:
PR target/42549
* config/i386/mmx.md
--- Comment #4 from uros at gcc dot gnu dot org 2009-12-30 11:47 ---
Subject: Bug 42549
Author: uros
Date: Wed Dec 30 11:47:30 2009
New Revision: 155522
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155522
Log:
PR target/42549
* config/i386/mmx.md
--- Comment #5 from ubizjak at gmail dot com 2009-12-30 11:49 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
URL|
--- Comment #24 from nospamname at web dot de 2009-12-30 12:06 ---
(In reply to comment #23)
You need a proper patch, not instructions.
However, it's clear from the bugreport and the patches required to fix it,
that
it is not important whether the target is m68k-amigaos or
--- Comment #25 from bonzini at gnu dot org 2009-12-30 12:22 ---
Adding target support without at least libgcc makes little sense.
The small part in config.guess/config.sub is not going to be removed, since
those files are just imported in GCC and are handled as a separate project.
forwarding, seen with current branches and trunk
Matthias
#include iostream
int main()
{
std::wcerr LHello, world! std::endl;
std::cerr !dlrow ,olleH std::endl;
}
when compiled, will only output Hello, world!, and the subsequent string will
not be output.
However,
#include
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-30 12:51
---
*** Bug 42552 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from paolo dot carlini at oracle dot com 2009-12-30 12:51
---
If you are looking for a totally unsupported (can go away at any moment)
workaround (it's a bug that it does what you want), see PR11705
*** This bug has been marked as a duplicate of 37557 ***
--
paolo
--- Comment #3 from mironov dot ivan at gmail dot com 2009-12-30 12:52
---
I can also reproduce this problem:
$ g++ -m32 -ftree-loop-distribution -O2 posix_proactor.ii -c
../../../../dep/ACE_wrappers/ace/POSIX_Proactor.cpp: In member function 'int
--- Comment #8 from irar at gcc dot gnu dot org 2009-12-30 12:53 ---
Subject: Bug 41956
Author: irar
Date: Wed Dec 30 12:53:18 2009
New Revision: 155523
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155523
Log:
PR tree-optimization/41956
* tree-vect-slp.c
current trunk/branches on x86_64-linux-gnu. return values with different
compilers and different optimizations:
-O0 -O1 -O2 -O3
gcc-4.1 0222
gcc-4.3 0222
gcc-4.4 2000
gcc-4.5 0100
Matthias
#include stdbool.h
#include stdio.h
Sent from my iPhone
On Dec 30, 2009, at 7:56 AM, debian-gcc at lists dot debian dot org gcc-bugzi...@gcc.gnu.org
wrote:
current trunk/branches on x86_64-linux-gnu. return values with
different
compilers and different optimizations:
-O0 -O1 -O2 -O3
gcc-4.1 0222
--- Comment #1 from pinskia at gmail dot com 2009-12-30 13:14 ---
Subject: Re: New: wrong code with -O1
Sent from my iPhone
On Dec 30, 2009, at 7:56 AM, debian-gcc at lists dot debian dot org
gcc-bugzi...@gcc.gnu.org
wrote:
current trunk/branches on x86_64-linux-gnu. return
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-12-30 14:33 ---
The inline-asm is totally incorrect here is the corrected version of the
function (note res should be set):
static bool atomic_test_and_reset_bit(unsigned long *v,unsigned long bit) {
bool res = 0;
__asm__
--- Comment #7 from gccbugzilla at taggedtype dot net 2009-12-30 15:24
---
Ok, I ran the delta program for a few days and got this message:
Died at /home/s.somani/thirdparty/delta-2006.08.03/delta line 123, line
64641
Doh!
I'll try and see if I can get another test case.
--
--- Comment #8 from gccbugzilla at taggedtype dot net 2009-12-30 15:39
---
Aha, found a small test case:
int main()
{
long double d;
bool b = static_castlong double(0) == d;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42465
--- Comment #9 from gccbugzilla at taggedtype dot net 2009-12-30 15:41
---
I've narrowed it down to this invocation:
g++ -o octonion_test.o -c -mxl-compat ld_break.cpp
So it's caused by some interaction with -mxl-compat
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42465
--- Comment #11 from hjl dot tools at gmail dot com 2009-12-30 15:50
---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg01208.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #9 from hutchinsonandy at gcc dot gnu dot org 2009-12-30 16:14
---
Fixed on 4.5 - or at least significantly better enough to warrant closure.
--
hutchinsonandy at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from manu at gcc dot gnu dot org 2009-12-30 16:26 ---
This seems FIXED per DJ's commit.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from manu at gcc dot gnu dot org 2009-12-30 16:29 ---
Once PR42508 is fixed, this should be reevaluated and probably won't warn
anymore or can be closed as INVALID, since the warning was valid.
--
manu at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from davek at gcc dot gnu dot org 2009-12-30 16:37 ---
Test runs all finished.
Before: http://gcc.gnu.org/ml/gcc-testresults/2009-12/msg02081.html
After: http://gcc.gnu.org/ml/gcc-testresults/2009-12/msg02582.html
No new fails. Sending patch.
--
--- Comment #15 from steven at gcc dot gnu dot org 2009-12-30 16:39 ---
With GCC: (GNU) 4.5.0 20091228 (experimental) [trunk revision 155486] I get
identical code at -O2 with and without -fno-ivopts for i686:
.L3:
movl%ebx, (%ecx,%eax,4)
addl$1, %eax
--- Comment #7 from mikpe at it dot uu dot se 2009-12-30 16:45 ---
FWIW, Ian's fix backports trivially to 4.4 and 4.3 and fixes this test case
there with no test suite regressions (all default languages) on i686-linux.
--
mikpe at it dot uu dot se changed:
What
--- Comment #3 from manu at gcc dot gnu dot org 2009-12-30 16:59 ---
This would need conditional PHIs, so a duplicate of PR20968.
GCC never detects that ret is always initialized, it doesn't warn because at
low optimization levels we do not warn for PHIs or because CCP (PR18501) just
--- Comment #7 from manu at gcc dot gnu dot org 2009-12-30 16:59 ---
*** Bug 42145 has been marked as a duplicate of this bug. ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #1 from ramana at gcc dot gnu dot org 2009-12-30 17:32 ---
The problem here essentially appears to be that GCC can't seem to generate
conditional tail-calls (or conditional calls for that matter in this case) with
-fno-optimize-sibling-calls . I don't read this as a problem
--- Comment #17 from janus at gcc dot gnu dot org 2009-12-30 17:34 ---
Reopening. As reported in http://gcc.gnu.org/ml/fortran/2009-12/msg00215.html,
the patch in comment #15 introduced several regressions on the fortran-dev
branch.
--
janus at gcc dot gnu dot org changed:
--- Comment #6 from urbanjost at comcast dot net 2009-12-30 17:51 ---
Subject: Re: Fortran FORMAT descriptor X generates nulls instead of blanks
for ACCESS='stream files
I could not initially get the Mingw or straight CygWin install to work; but
I was also having problems with
X11
While building gnatlink gnatmake for both i386 and x86_64, get
ld: duplicate symbol _system__secondary_stack__mark_idIP in
../rts/libgnat.a(s-secsta.o) and s-secsta.o
(and, after fixing this, s-exctab.o).
I suppose this is because of a change in Snow Leopard where an object can't be
both
--- Comment #1 from simon at pushface dot org 2009-12-30 18:27 ---
Created an attachment (id=19424)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19424action=view)
Patch to gcc/ada/gcc-interface/Makefile.in
[Some] objects that are in the RTS archive mustn't be explicitly
--- Comment #10 from simon at pushface dot org 2009-12-30 18:29 ---
I've done as Eric suggests in #8 (though it looks to me as though the build
system is very close to supporting just --build= in this case!).
Situation now is that something in gcc/ada/gcc-interface/Makefile is selecting
The following line of code is accepted:
typedef double AlignedDoubleType __attribute__((aligned(16)));
However, if I replace 'double' with a template parameter inside a template
function, then I get the following error message:
error: alignment of array elements is greater than element size
I
--- Comment #1 from bredelin at ucla dot edu 2009-12-30 19:00 ---
Created an attachment (id=19425)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19425action=view)
A testcase.
To reproduce the error, compile the file (test5.C) with this command line:
% g++-4.5 -c test5.C -O3
--
--- Comment #2 from bredelin at ucla dot edu 2009-12-30 19:03 ---
Also, I just noticed that the error occurs only if -ftree-vectorize is turned
on.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42555
This is distilled from PR42500. The same testcase doesn't show a problem if
compiled with a C compiler only.
Why does the gimple for the following testcase contain ?
extern C void foo(int a[4]);
extern C void bar(int a, int b, int c, int d)
{
int v[4] = { a, b, c, d};
foo(v);
--- Comment #4 from ramana at gcc dot gnu dot org 2009-12-30 19:14 ---
Ok (In reply to comment #3)
My complete command line:
/home/carrot/compiler/armobj/gcc/cc1plus -fpreprocessed testH.ii
-quiet
-dumpbase testH.cpp -auxbase-strip obj/./testH.o -Os -o testH.s
Please compile
--- Comment #4 from jason at gcc dot gnu dot org 2009-12-30 19:28 ---
Confirmed, marking as P1 regression.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jason at gcc dot gnu dot org 2009-12-30 19:35 ---
4.5 already says
wa.C:8:11: error: declaration of ~typename BaseT::BaseTypo as member of
BaseT
for this testcase. Closing as fixed, as backporting the fix seems a little
risky for an invalid code bug.
--
--- Comment #16 from jason at gcc dot gnu dot org 2009-12-30 19:36 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from ian at gcc dot gnu dot org 2009-12-30 19:42 ---
Subject: Bug 42099
Author: ian
Date: Wed Dec 30 19:42:03 2009
New Revision: 155524
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155524
Log:
gcc/:
PR middle-end/42099
* expmed.c (expand_divmod):
--- Comment #4 from fierevere at ya dot ru 2009-12-30 19:42 ---
ICE does not happen on x86_64-linux-gnu platform,
so its only 32-bit x86 linux-gnu specific
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40355
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-12-30 19:47 ---
The front-end already changed it into being = {};, a[0] = ...
cleanup_point int v[4] = {};;
cleanup_point Unknown tree: expr_stmt
Unknown tree: expr_stmt
v[0] = a
;
Unknown tree: expr_stmt
v[1] = b
--- Comment #9 from ian at gcc dot gnu dot org 2009-12-30 19:50 ---
Subject: Bug 42099
Author: ian
Date: Wed Dec 30 19:50:24 2009
New Revision: 155525
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155525
Log:
gcc/:
PR middle-end/42099
* expmed.c (expand_divmod):
--- Comment #10 from ian at airs dot com 2009-12-30 19:59 ---
I backported the patch and testsuite to the 4.3 and 4.4 branches.
--
ian at airs dot com changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #11 from howarth at nitro dot med dot uc dot edu 2009-12-30
20:50 ---
Please try an svn pull of current gcc-4_4-branch. Assuming that you have EMT64
capable hardware and want to build the native x86_64 version of the FSF gcc
compilers, the new config.guess should properly
--- Comment #8 from burnus at gcc dot gnu dot org 2009-12-30 20:50 ---
TODO:
- SAVED local variables are (probably) mishandled
- Check whether other things such as allocatable scalar components,
(absent/present) optional dummys etc. work.
- allocatable-scalar returning functions as
I tried to compile gcc (4.4.1 and 4.4.2) for m68k-coff for Linux. I'm
using Ubuntu 9.10 AMD64. However, I get an error stating that gas is not
supported for the version of binutils (2.20) used:
...
Configuring in ./gas
configure: creating cache ./config.cache
checking build system type...
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42442
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
|
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-12-30 20:57 ---
I'll have a look.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
The attached testcase miscompiles as:
gfortran -floop-block-O2 -funroll-loops -ffast-math bug.f90
./a.out
4.
gfortran -O2 -funroll-loops -ffast-math bug.f90
./a.out
1.
gfortran bug.f90 ./a.out
1.
4.4 works fine, 4.5
--- Comment #1 from jv244 at cam dot ac dot uk 2009-12-30 21:08 ---
Created an attachment (id=19426)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19426action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42558
--- Comment #2 from jv244 at cam dot ac dot uk 2009-12-30 21:10 ---
full version details:
gfortran -v -floop-block-O2 -funroll-loops -ffast-math bug.f90
Driving: gfortran -v -floop-block -O2 -funroll-loops -ffast-math bug.f90
-lgfortran -lm -shared-libgcc
Using built-in specs.
--- Comment #5 from jsm28 at gcc dot gnu dot org 2009-12-30 21:28 ---
Subject: Bug 42439
Author: jsm28
Date: Wed Dec 30 21:28:45 2009
New Revision: 155526
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155526
Log:
PR c/42439
* c-decl.c
--- Comment #6 from jsm28 at gcc dot gnu dot org 2009-12-30 21:30 ---
Fixed for 4.5 (allowing this dubious code with a pedwarn-if-pedantic,
since this is done in several similar cases).
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from jakub at gcc dot gnu dot org 2009-12-30 21:32 ---
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42099
--- Comment #3 from hjl dot tools at gmail dot com 2009-12-30 21:34 ---
It is caused by revision 155418:
http://gcc.gnu.org/ml/gcc-cvs/2009-12/msg00562.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42558
I just tried to compile the package libhugetlbfs-2.5 with the GNU
C compiler version 4.5 snapshot 20091224 and the compiler said
n file included from /usr/include/string.h:640:0,
from icache-hygiene.c:37:
/usr/include/bits/string3.h: In function 'jumpfunc':
--- Comment #1 from dcb314 at hotmail dot com 2009-12-30 22:23 ---
Created an attachment (id=19427)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19427action=view)
C source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42559
--- Comment #1 from mikpe at it dot uu dot se 2009-12-30 22:40 ---
(In reply to comment #0)
I tried to compile gcc (4.4.1 and 4.4.2) for m68k-coff for Linux. I'm
using Ubuntu 9.10 AMD64. However, I get an error stating that gas is not
supported for the version of binutils (2.20)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||jamborm at gcc dot gnu dot
|
--- Comment #3 from schwab at gcc dot gnu dot org 2009-12-30 23:03 ---
Subject: Bug 42516
Author: schwab
Date: Wed Dec 30 23:03:46 2009
New Revision: 155527
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155527
Log:
PR target/42516
* config/m68k/m68k.md (rotlsi_16): New insn.
--- Comment #4 from schwab at linux-m68k dot org 2009-12-30 23:04 ---
Fixed.
--
schwab at linux-m68k dot org changed:
What|Removed |Added
Status|NEW
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Component|regression |rtl-optimization
Keywords|
--- Comment #9 from rguenther at suse dot de 2009-12-30 23:16 ---
Subject: Re: -fdump-tree-all for lto does not work as
expected
On Wed, 23 Dec 2009, hjl dot tools at gmail dot com wrote:
--- Comment #8 from hjl dot tools at gmail dot com 2009-12-23 21:01
---
Since LTO
--- Comment #3 from davek at gcc dot gnu dot org 2009-12-30 23:21 ---
Subject: Bug 42531
Author: davek
Date: Wed Dec 30 23:20:55 2009
New Revision: 155528
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155528
Log:
PR lto/42531
* lto-streamer-out.c (produce_asm):
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42494
--- Comment #10 from hjl dot tools at gmail dot com 2009-12-30 23:27
---
(In reply to comment #9)
Subject: Re: -fdump-tree-all for lto does not work as
expected
On Wed, 23 Dec 2009, hjl dot tools at gmail dot com wrote:
--- Comment #8 from hjl dot tools at gmail dot com
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-12-30 23:34 ---
The issue is that we do not do predicated value-numbering so we need multiple
invocations of it. Which all of FRE, DOM and PRE do - but PRE is not run at
-Os in 4.4.
And yes, the optimization done by 4.5 is
--- Comment #11 from rguenther at suse dot de 2009-12-30 23:37 ---
Subject: Re: -fdump-tree-all for lto does not work as
expected
On Wed, 30 Dec 2009, hjl dot tools at gmail dot com wrote:
--- Comment #10 from hjl dot tools at gmail dot com 2009-12-30 23:27
---
(In
--- Comment #2 from hjl dot tools at gmail dot com 2009-12-30 23:38 ---
Here is a small testcase:
[...@gnu-34 rrs]$ cat pr19427.c
void jumpfunc(int copy, void *p)
{
void *l = jumplabel;
if (copy)
__builtin___memcpy_chk (p, l, 128, __builtin_object_size (p, 0));
jumplabel:
return;
--- Comment #1 from ramana at gcc dot gnu dot org 2009-12-30 23:54 ---
Mine.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #2 from mikpe at it dot uu dot se 2009-12-31 00:53 ---
(In reply to comment #0)
When compiling m68k-elf the process went
smoothly and I can install (m68k-elf-as, m68k-elf-ar, etc.). But this
time I can not compile gcc 4.4.1 or 4.4.2 (m68k-elf-gcc) because I
get an error
--- Comment #8 from davek at gcc dot gnu dot org 2009-12-31 01:35 ---
Subject: Bug 41605
Author: davek
Date: Thu Dec 31 01:35:24 2009
New Revision: 155534
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155534
Log:
2009-12-31 Iain Sandoe iain.san...@sandoe-acoustics.co.uk
--- Comment #23 from matt at use dot net 2009-12-31 01:44 ---
I just ran into a bug that this feature would have found for me at
compile-time. Instead, it required exercising the code under valgrind, which
took quite some time. If voting were enabled, I would vote for this bug.
--
in the attached testcase, both GCC 4.5.20091214 and GCC 4.4.1 on Ubuntu 9.10
miss the uninitialized use warnings specified in the comments. it does correct
catch the simple byte variable base, as noted in the comments.
--
Summary: missing uninitialized variable warning on simple
--- Comment #1 from matt at use dot net 2009-12-31 02:15 ---
Created an attachment (id=19428)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19428action=view)
source file
to replicate (-O3 is required, would be nice if it just worked with -O2):
g++ -O3 -Wall -c
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-12-31 02:23 ---
Well with: int32_t actuallyRead = read(v, SIZE_OF_BYTE);
And inlining turned on all the way, this:
if (toRead 1)
...
memcpy(data, _totPtr, toRead);
Becomes just:
*_totPtr = *data;
which
--- Comment #4 from hutchinsonandy at gcc dot gnu dot org 2009-12-31 03:16
---
The same occurs in 4.5
I think the bug is invalid
The expression 1 pin will be promoted. This produces a defined result if
pin7 and 15
The expression can not then be lower to 8 bit shift - since a shift
It would be nice if __attribute__((warning())) (and error) worked anywhere
that __attribute__((deprecated)) is accepted. After all, there are other
reasons to warn other than deprecation, and the warning attribute allows an
explanation string.
However, as of gcc 4.3.4, attribute((warning)) is
--- Comment #2 from ebb9 at byu dot net 2009-12-31 04:41 ---
Conversely, it would be nice for __attribute__((warning)) and
__attribute__((error)) to allow omitting their argument (in other words, it
would be nice to have all three of deprecated, warning, and error act
consistently and
--- Comment #3 from hjl dot tools at gmail dot com 2009-12-31 05:55 ---
*** This bug has been marked as a duplicate of 36892 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #8 from hjl dot tools at gmail dot com 2009-12-31 05:55 ---
*** Bug 30063 has been marked as a duplicate of this bug. ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
1 - 100 of 101 matches
Mail list logo
