Here is the testcase:
template
struct A {
A() {}
};
struct B {
B() {}
Afoo();
};
template
AT::foo() {
return A();
}
template class A;
And the command line:
> g++ -c test.cc -Wall
test.cc:13: internal compiler error: in is_ancestor, at cp/name-lookup.c:2236
Please submit
--- 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
---
--- 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 #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 ta
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 s
--- 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
pin>7 and <15
The expression can not then be lower to 8 bit shift - since a shif
--- 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;
whic
--- 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=19428&action=view)
source file
to replicate (-O3 is required, would be nice if it just worked with -O2):
g++ -O3 -Wall -c gcc-missing-uninit.
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 array
--- 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.
--
h
--- 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=gcc&view=rev&rev=155534
Log:
2009-12-31 Iain Sandoe
PR target/41605
* confi
--- 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 err
--- 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 a
--- 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 #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 re
--- 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 correct
--- 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 do
--
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 #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=gcc&view=rev&rev=155528
Log:
PR lto/42531
* lto-streamer-out.c (produce_asm):
--- 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 LT
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Component|regression |rtl-optimization
Keywords||miss
--- 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
--- 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=gcc&view=rev&rev=155527
Log:
PR target/42516
* config/m68k/m68k.md (rotlsi_16): New insn.
M
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||jamborm at gcc dot gnu dot
|
--- 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) us
--- 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=19427&action=view)
C source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42559
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':
/usr/include/bits/strin
--- 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
--- 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 #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 #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=gcc&view=rev&rev=155526
Log:
PR c/42439
* c-decl.c (check_bitfield_type_and_wi
--- 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.
CO
--- 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=19426&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42558
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 mis
--- 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
AssignedT
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
|
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42442
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... x86_64-u
--- 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
--- 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 de
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- 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
--- 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=gcc&view=rev&rev=155525
Log:
gcc/:
PR middle-end/42099
* expmed.c (expand_divmod):
--- 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] = ...
<>;
<>>
;
<<< Unknown tree: expr_stmt
v[1] = b >>>
;
<<< Unknown tree: expr_stmt
v[2] = c >>>
;
<<< Unknown tree: expr_stmt
v[3] = d >>>
;
--- 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 #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=gcc&view=rev&rev=155524
Log:
gcc/:
PR middle-end/42099
* expmed.c (expand_divmod):
--- 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 #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 Base::BaseTypo as member of
Base
for this testcase. Closing as fixed, as backporting the fix seems a little
risky for an invalid code bug.
--
jason
--- 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 #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" "te
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);
foo
--- 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
--- 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=19425&action=view)
A testcase.
To reproduce the error, compile the file (test5.C) with this command line:
% g++-4.5 -c test5.C -O3
--
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 t
--- 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
--- 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=19424&action=view)
Patch to gcc/ada/gcc-interface/Makefile.in
[Some] objects that are in the RTS archive mustn't be explicitly mentione
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 expli
--- 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
--- 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 #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 w
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--- 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
-
--- 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
in
--- 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|Remove
--- 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
cm
--- 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.
--
http://gcc.gnu.org
--- 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 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 #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 #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 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 #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_cast(0) == d;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42465
--- 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.
--
h
--- 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__ __vol
--- 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"
wrote:
> current trunk/branches on x86_64-linux-gnu. return values with
> different
Sent from my iPhone
On Dec 30, 2009, at 7:56 AM, "debian-gcc at lists dot debian dot 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
gcc-4.3 022
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
#include
static bool atom
--- 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=gcc&view=rev&rev=155523
Log:
PR tree-optimization/41956
* tree-vect-slp.c (vect
--- 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
ACE_POSIX_AIOCB_Proactor::create_resul
--- 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 #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
forwarding, seen with current branches and trunk
Matthias
#include
int main()
{
std::wcerr << L"Hello, 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,
#includ
--- 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.
Peo
--- 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 an
--- 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 #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=gcc&view=rev&rev=155522
Log:
PR target/42549
* config/i386/mmx.md (*mmx_subv2sf3
--- 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=gcc&view=rev&rev=155521
Log:
PR target/42549
* config/i386/mmx.md (*mmx_subv2sf3
--- 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 #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 #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|Remov
--- 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 #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 (a
--- 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=gcc&view=rev&rev=155519
Log:
PR target/42549
* config/i386/mmx.md ("*mmx_subv2sf
--- 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 #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
AssignedTo|u
--- 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.
--
http://gcc.gnu.org/bu
--- 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
Status
--- 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=gcc&view=rev&rev=155518
Log:
/gcc
2009-12-30 Robert Millan
PR other/42537
--- 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 #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 15
1 - 100 of 101 matches
Mail list logo
