--- Comment #18 from mikael at gcc dot gnu dot org 2010-06-26 09:06 ---
(In reply to comment #17)
> The reason for the failures with entry_* is
>
> [macbook] f90/bug% gfc /opt/gcc/_clean/gcc/testsuite/gfortran.dg/entry_10.f90
> f951(52154) malloc: *** error for object 0x1419161b0: point
--- Comment #6 from rguenther at suse dot de 2010-06-26 09:18 ---
Subject: Re: [4.6 Regression]
c-c++-common/torture/complex-sign-add.c
On Fri, 25 Jun 2010, sje at cup dot hp dot com wrote:
> --- Comment #5 from sje at cup dot hp dot com 2010-06-25 22:47 ---
> I verified tha
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-06-26 09:28 ---
Another way would probably be to ensure that f0 always appears as first operand
by adjusting the various patterns in ia64.md to only allow fr_reg_operand
in the 2nd operand slot of addsf3 (and maybe other patterns).
$ gfortran -fdump-parse-tree select_type_1.f03
...
Interner Fehler bei (1):
show_code_node(): Bad statement code
--
Summary: ICE with -fdump-parse-tree and select type
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-06-26 10:05 ---
Testcase which should fail at all optimization levels
(assuming that fadd.s f4, f0 is internally going through the
mac unit as fmac.s f4, f1, f0)
float __attribute__((noinline))
foo (float x)
{
float y = x + 0.0;
building 30_threads/condition_variable_any/cons/1.cc with the 4.4 branch
g++ -fstack-protector -std=c++0x any.cc -o any
and running the binary on a system with the shared libstdc++.so installed from
the 4.5 branch aborts.
#include
#include
int main()
{
bool test __attribute__((unused)) = tr
--- Comment #7 from amylaar at gcc dot gnu dot org 2010-06-26 10:22 ---
The patches have been tested & posted to gcc-patches:
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02492.html
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02452.html
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02495
--- Comment #10 from redi at gcc dot gnu dot org 2010-06-26 10:26 ---
I disagree that it would be useful, it would encourage non-portable code, and
I'd rather be told about the missing definition.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44673
the binary built with 4.4 and run with 4.5's libstdc++ shared library fails:
#include
# include
# define VERIFY(fn) assert(fn)
// Tests the value() function of the regex_traits class.
void test01()
{
bool test __attribute__((unused)) = true;
std::tr1::regex_traits t;
VERIFY( t.value('7',
--- Comment #11 from redi at gcc dot gnu dot org 2010-06-26 10:33 ---
[class.static.data]/3
If a static data member is of const literal type, its declaration in the class
definition can specify a brace-or-equal-initializer ... The member shall
still be defined in a namespace scope if it is
--- Comment #12 from manu at gcc dot gnu dot org 2010-06-26 10:35 ---
(In reply to comment #11)
> [class.static.data]/3
> If a static data member is of const literal type, its declaration in the class
> definition can specify a brace-or-equal-initializer ... The member shall
> still be de
--- Comment #13 from redi at gcc dot gnu dot org 2010-06-26 10:38 ---
(In reply to comment #11)
> definition
Bah, that entity is the "fi" ligature, it should say definition
(In reply to comment #12)
> So is g++ accepting invalid code?
Yes, but it's a violation of the ODR, no diagnosti
--- Comment #14 from manu at gcc dot gnu dot org 2010-06-26 10:53 ---
> (In reply to comment #12)
> > So is g++ accepting invalid code?
>
> Yes, but it's a violation of the ODR, no diagnostic is required (it's not
> possible to tell until link time that there's no definition.)
>
> The
--- Comment #1 from paolo dot carlini at oracle dot com 2010-06-26 11:23
---
Regex was completely broken / unusable, before yesterday's first seriou stab at
it.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
--- Comment #1 from paolo dot carlini at oracle dot com 2010-06-26 11:27
---
Jon, can you have a quick look to this? Thanks in advance
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44676
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44674
--- Comment #1 from hubicka at gcc dot gnu dot org 2010-06-26 11:39 ---
Subject: Bug 44671
Author: hubicka
Date: Sat Jun 26 11:38:57 2010
New Revision: 161428
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161428
Log:
PR middle-end/44671
* cgraphunit.c (cgraph_fu
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-26 11:53 ---
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-26 13:25 ---
Subject: Bug 44674
Author: rguenth
Date: Sat Jun 26 13:24:57 2010
New Revision: 161431
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161431
Log:
2010-06-26 Richard Guenther
PR middle-end/44674
When porting my software from Win32 to Linux, i had to recompile it with gcc
under Mingw and also under Linux. There was a hurdle, because the loop shown
below in b) crashed after a while on both platforms. (I was happy to find the
location of the bug with gdb!) After rearranging the code like c) i
> cat bug.ii
struct Base1 {
virtual ~Base1() {}
};
struct Base2 {
virtual ~Base2() {}
};
struct Foo : Base1, Base2 {};
void f(Foo&);
void g(void* v) {
Base2* base = static_cast(v);
Foo* foo = static_cast(base);
f(*foo);
}
> g++ -Wall -c bug.ii
bug.ii: In function Âvoid g(vo
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-06-26 13:32 ---
Subject: Bug 44674
Author: rguenth
Date: Sat Jun 26 13:32:17 2010
New Revision: 161432
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161432
Log:
2010-06-26 Richard Guenther
PR middle-end/44674
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-06-26 13:33 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #15 from redi at gcc dot gnu dot org 2010-06-26 13:46 ---
(In reply to comment #14)
>
> However, it links in the if-else case.
The variable is not "used" in the [basic.def.odr] sense, because the
lvalue-to-rvalue conversion occurs immediately.
> I understand that ?: may be
--- Comment #2 from redi at gcc dot gnu dot org 2010-06-26 14:01 ---
condition_variable_any was completely broken in 4.4 and its ABi changed when we
implemented it for real. Obviously we can't preserve ABI between a broken,
incomplete implementation and a working one, so I'm not really w
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-06-26 14:25 ---
I now see compile-time on polyhedron sky-rocketed with enabling prefetching at
-O3 by default. See
http://gcc.opensuse.org/c++bench/polyhedron/polyhedron-summary.txt-1-0.html
This isn't acceptable - please work on
--- Comment #3 from redi at gcc dot gnu dot org 2010-06-26 14:51 ---
closing for the reasons given above
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-06-26 15:55 ---
Subject: Bug 44393
Author: rguenth
Date: Sat Jun 26 15:55:05 2010
New Revision: 161434
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161434
Log:
2010-06-26 Richard Guenther
PR tree-optimization/
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-06-26 15:57 ---
Subject: Bug 44393
Author: rguenth
Date: Sat Jun 26 15:57:17 2010
New Revision: 161435
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161435
Log:
2010-06-26 Richard Guenther
PR tree-optimization/
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-06-26 15:58 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from hjl dot tools at gmail dot com 2010-06-26 16:07 ---
On Linux/ia32, I also see:
FAIL: abi_check
FAIL: 23_containers/unordered_map/erase/1.cc execution test
FAIL: 23_containers/unordered_map/erase/24061-map.cc execution test
FAIL: 23_containers/unordered_map/insert/arr
Here's a minimal test-case:
-
int copysign_bug(double x)
{
if (x * 0.5 == x)
return 1;
else if (copysign(1.0, x) < 0.0)
return 2;
else
return 3;
}
int main(void) {
double x;
x = -0.0;
printf("copysign_bug(%.17g) = %d\n", x, copysign_bug(x));
x = 0.0;
printf(
--- Comment #1 from dickinsm at gmail dot com 2010-06-26 17:01 ---
Created an attachment (id=21012)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21012&action=view)
Preprocessed source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44683
--- Comment #2 from dickinsm at gmail dot com 2010-06-26 18:16 ---
I'm also seeing this bug in gcc 4.5.0 on OS X, and it's been independently
confirmed in gcc 4.4.3 on Fedora 12 (see http://bugs.python.org/issue9069).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44683
--- Comment #3 from dickinsm at gmail dot com 2010-06-26 18:26 ---
Apologies; I seem to have messed up the original bug report, by accidentally
pasting a slightly edited version of the original bug file. The minimal
test-case is as follows:
#include
#include
int copysign_bug(doubl
On Linux/x86, revision 161433 gave
FAIL: g++.dg/opt/pmf1.C (internal compiler error)
FAIL: g++.dg/opt/pmf1.C (test for excess errors)
/export/gnu/import/git/gcc-eas/gcc/testsuite/g++.dg/opt/pmf1.C:75:1: internal
compiler error: in refs_may_alias_p_1, at tree-ssa-alias.c:812^M
Please submit a full
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-26 18:44 ---
It may be caused by revision 161431:
http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg01349.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #2 from hjl dot tools at gmail dot com 2010-06-26 18:57 ---
Since the patch is backported to 4.5 branch. This bug
may also impact 4.5.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44684
--- Comment #6 from borntraeger at de dot ibm dot com 2010-06-26 20:30
---
Richard,
can you check if compute_miss_rate is the problem?
does the attached patch helps?
thanks
Christian
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44576
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-26 21:46 ---
Huh, I did test -m32 and didn't see this. 4.5 is affected only with
checking enabled.
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from tkoenig at gcc dot gnu dot org 2010-06-26 22:03 ---
I have a patch.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|
--- Comment #2 from tkoenig at gcc dot gnu dot org 2010-06-26 22:54 ---
Subject: Bug 44678
Author: tkoenig
Date: Sat Jun 26 22:54:39 2010
New Revision: 161444
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161444
Log:
2010-06-27 Thomas Koenig
PR fortran/44678
--- Comment #3 from tkoenig at gcc dot gnu dot org 2010-06-26 22:56 ---
Fixed, closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Status|
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-06-26 22:57 ---
Confirmed. Somewhere during RTL opts we thread a jump the wrong way. Also
happens with SSE math.
int __attribute__((noinline,noclone))
copysign_bug (double x)
{
if (x != 0.0 && (x * 0.5 == x))
return 1;
if
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to work||4.3.4
Summary|Optimization bug with |[4.4/4.5/4.6 Re
--- Comment #4 from hjl dot tools at gmail dot com 2010-06-26 23:28 ---
On Linux/x86-64, revision 161432 failed to compile SPEC CPU 2006
with similar error:
g++ -c -o XercesXPath.o -DSPEC_CPU -DNDEBUG -DAPP_NO_THREADS
-DXALAN_INMEM_MSG_LOADER -I. -Ixercesc -Ixercesc/dom -Ixercesc/dom/i
--
rwild at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|rwild at gcc dot gnu dot org|unassigned at gcc dot gnu
|
--- Comment #5 from hjl dot tools at gmail dot com 2010-06-27 03:04 ---
It is caused by revision 134833:
http://gcc.gnu.org/ml/gcc-cvs/2008-04/msg01062.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
49 matches
Mail list logo
