--- Comment #33 from Kyle dot D dot Moffett at boeing dot com 2010-06-08
06:48 ---
EGLIBC and PPL are still building; I'm heading to sleep and I'll check on them
later this morning.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
--- Comment #2 from burnus at gcc dot gnu dot org 2010-06-08 06:37 ---
Subject: Bug 6
Author: burnus
Date: Tue Jun 8 06:37:32 2010
New Revision: 160424
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160424
Log:
2010-06-07 Tobias Burnus
PR fortran/6
*
--- Comment #4 from fm3 at os dot inf dot tu-dresden dot de 2010-06-08
06:19 ---
Yes, you are right. This is a duplicate. Thanks.
--
fm3 at os dot inf dot tu-dresden dot de changed:
What|Removed |Added
-
--- Comment #20 from borntraeger at de dot ibm dot com 2010-06-08 05:51
---
both patches look sane. I will test both.
thank you for your work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44297
--- Comment #4 from pinskia at gmail dot com 2010-06-08 05:11 ---
Subject: Re: __cxa_end_cleanup ends up in wrong section i.e. not in .text
Well this code will only be compiled for arm-eabi which is an elf only
target. Please submit your patch to gcc-patc...@.
Sent from my iPhone
O
Well this code will only be compiled for arm-eabi which is an elf only
target. Please submit your patch to gcc-patc...@.
Sent from my iPhone
On Jun 7, 2010, at 9:53 PM, "raj dot khem at gmail dot com" > wrote:
--- Comment #3 from raj dot khem at gmail dot com 2010-06-08
04:53 -
--- Comment #32 from Kyle dot D dot Moffett at boeing dot com 2010-06-08
05:07 ---
The first working patch (VOIDmode||DFmode) just successfully passed full GMP
and MPFR testsuites on the e500 boards. PPL and EGLIBC are currently
rebuilding.
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #3 from raj dot khem at gmail dot com 2010-06-08 04:53 ---
(In reply to comment #2)
> Confirmed, it should do a .text and then a previous. I have closed a bug
> where
> an inline-asm was not doing this too (see PR 35895).
>
another version I had was with pushsection and p
--- Comment #8 from jason at gcc dot gnu dot org 2010-06-08 04:38 ---
Fixed
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44366
--- Comment #8 from jason at gcc dot gnu dot org 2010-06-08 04:37 ---
Or even:
template
void f(T t, int(*)[sizeof(t)])
{
struct A { void g() {
foo;
} };
}
which makes this a regression against 3.2.
--
jason at gcc dot gnu dot org
--- Comment #7 from jason at gcc dot gnu dot org 2010-06-08 04:34 ---
Subject: Bug 44366
Author: jason
Date: Tue Jun 8 04:34:20 2010
New Revision: 160421
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160421
Log:
PR c++/44366
* error.c (dump_simple_decl): Don't
--- Comment #6 from jason at gcc dot gnu dot org 2010-06-08 04:34 ---
Subject: Bug 44366
Author: jason
Date: Tue Jun 8 04:33:50 2010
New Revision: 160420
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160420
Log:
PR c++/44366
* error.c (dump_parameters): Mask ou
--- Comment #31 from Kyle dot D dot Moffett at boeing dot com 2010-06-08
04:24 ---
Alan,
Now that I've corrected all of my compiler issues, your first patch (the one
quoted below) works like a charm. I still need to do the extensive
archive-rebuild and testsuite run to verify that it
--- Comment #9 from pzhao at gcc dot gnu dot org 2010-06-08 04:02 ---
Fixed for trunk.
--
pzhao at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #8 from pzhao at gcc dot gnu dot org 2010-06-08 03:56 ---
Subject: Bug 37724
Author: pzhao
Date: Tue Jun 8 03:56:40 2010
New Revision: 160418
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160418
Log:
gcc/
2010-06-08 Andrew Pinski
Shujing Zhao
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-06-08 03:24 ---
Confirmed, it should do a .text and then a previous. I have closed a bug where
an inline-asm was not doing this too (see PR 35895).
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from raj dot khem at gmail dot com 2010-06-08 03:20 ---
Created an attachment (id=20863)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20863&action=view)
the fix
2010-06-07 Khem Raj
* libsupc++/eh_arm.cc (__cxa_end_cleanup): Switch to
.text secti
__cxa_end_cleanup on arm is inline assembly in libsupc++/eh_arm.cc
in one case when libstdc++ was compiled with -Os this inline assembly
is emitted at the beginning and the section before that is a .debug
section as a result this ends up in .debug section and the symbol
goes missing in libstdc++
--- Comment #2 from janus at gcc dot gnu dot org 2010-06-08 02:32 ---
Ok, this one took me a while to figure out, but in the end it turns out the fix
is actually pretty simple, once you found out where the problem is:
Index: gcc/fortran/resolve.c
===
--- Comment #19 from paolo dot carlini at oracle dot com 2010-06-08 01:49
---
Yes.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status
--- Comment #18 from paolo dot carlini at oracle dot com 2010-06-08 01:49
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Target Milesto
--- Comment #3 from paolo at gcc dot gnu dot org 2010-06-08 01:46 ---
Subject: Bug 9694
Author: paolo
Date: Tue Jun 8 01:46:10 2010
New Revision: 160417
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160417
Log:
2010-06-07 Paolo Carlini
PR libstdc++/44417
*
--- Comment #17 from paolo at gcc dot gnu dot org 2010-06-08 01:46 ---
Subject: Bug 44417
Author: paolo
Date: Tue Jun 8 01:46:10 2010
New Revision: 160417
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160417
Log:
2010-06-07 Paolo Carlini
PR libstdc++/44417
/sw/lib/gcc4.6/x86_64-apple-darwin10.4.0/sys-include -m32 -ffloat-store
-fomit-frame-pointer -fclasspath=
-fbootclasspath=../../../../gcc-4.6-20100607/libjava/classpath/lib
--encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -m32 -c
-fsource-filename=/sw/src/fink.build/gcc46-4.
--- Comment #4 from janus at gcc dot gnu dot org 2010-06-08 01:19 ---
The backtrace for comment #3 is:
#0 gfc_add_component_ref (e=0x1806e80, name=0x77e7ceb8 "doit") at
/home/jweil/gcc46/trunk/gcc/fortran/class.c:77
#1 0x0052b323 in resolve_typebound_subroutine (code=0x180
--- Comment #1 from amylaar at gcc dot gnu dot org 2010-06-08 00:17 ---
Using C linkage for all of gcc-plugin.h is straightforward, and we it also
makes sense to put some popular other symbols there, e.g. warning.
However, there is a limit what we can reasonably put into C linkage withou
--- Comment #5 from jason at gcc dot gnu dot org 2010-06-08 00:07 ---
This actually isn't lambda-specific. The same crash happens with
template
void f(T t, decltype(*t))
{
struct A { void g() { foo; } };
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44366
--- Comment #1 from amylaar at gcc dot gnu dot org 2010-06-07 23:59 ---
(In reply to comment #0)
> I am building a plugin and would like to use some of the macros defined in
> flags.h, but that file is not installed in the plugin/include directory.
>
At least as of revision 160389, fla
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #8 from amodra at gmail dot com 2010-06-07 23:33 ---
Reassigning since Edmar's identical patch predates mine.
--
amodra at gmail dot com changed:
What|Removed |Added
--
--- Comment #8 from bernds at gcc dot gnu dot org 2010-06-07 22:49 ---
Fixed.
--
bernds at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #3 from hubicka at gcc dot gnu dot org 2010-06-07 22:48 ---
Subject: Bug 44454
Author: hubicka
Date: Mon Jun 7 22:48:32 2010
New Revision: 160410
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160410
Log:
PR middle-end/44454
(df_lr_top_dump, df_lr_b
--- Comment #7 from bernds at gcc dot gnu dot org 2010-06-07 22:46 ---
Fixed.
--
bernds at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
There are a number of global variables that are commonly used for plugins.
By switching the GCC build language to C++, we introduce name mangling,
which means that we loose plugin dynamic link compatibility to previous
versions of gcc. Also, the interface becomes subject to change when mangling
ch
--- Comment #2 from hubicka at gcc dot gnu dot org 2010-06-07 22:38 ---
The SMS failures are due to dumping. We seem to be dumping freed obstack
bitmaps from dce executed within SMS. I will fix that, but tomorrow I am
traveling, so only at evening.
Honza
--
http://gcc.gnu.org/bug
--- Comment #19 from changpeng dot fang at amd dot com 2010-06-07 22:30
---
Created an attachment (id=20862)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20862&action=view)
Account prefetch_mod and unroll_factor for the computation of the prefetch
count
Ooops. Attached a wrong "
--- Comment #7 from paolo dot carlini at oracle dot com 2010-06-07 22:29
---
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44401
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2010-06-07 22:25
---
Very likely:
2010-05-25 Steven Bosscher
* gcc-interface/targtyps.c: Do not include tm_p.h
* gcc-interface/Make-lang.in: Update dependencies.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #4 from amylaar at gcc dot gnu dot org 2010-06-07 22:22 ---
(In reply to comment #3)
updated patch for revision 160389:
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00665.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44034
--- Comment #8 from wilson at codesourcery dot com 2010-06-07 22:18 ---
Subject: Re: suboptimal MIPS widening multiply accumulate
On Mon, 2010-06-07 at 21:34 +, bernds at gcc dot gnu dot org wrote:
> Jim, are you still working on this or should I pick it up?
I'm working on it, but
/home/guerby/build-37/./prev-gcc/xgcc -B/home/guerby/build-37/./prev-gcc/
-B/n/37/guerby/install-trunk-37-160037/armv7l-unknown-linux-gnueabi/bin/
-B/n/37/guerby/install-trunk-37-160037/armv7l-unknown-linux-gnueabi/bin/
-B/n/37/guerby/i\
nstall-trunk-37-160037/armv7l-unknown-linux-gnueabi/lib/ -isy
--- Comment #7 from bernds at gcc dot gnu dot org 2010-06-07 21:34 ---
Jim, are you still working on this or should I pick it up?
--
bernds at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jason at gcc dot gnu dot org 2010-06-07 21:28 ---
Subject: Bug 44401
Author: jason
Date: Mon Jun 7 21:28:27 2010
New Revision: 160408
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160408
Log:
PR c++/44401
* parser.c (cp_parser_lookup_name):
F2003, 12.4.1.2, page 271, just before note 12.24:
"If the actual argument is an array section having a vector subscript,
the dummy argument is not definable and shall not have the INTENT
(OUT), INTENT (INOUT), VOLATILE, or ASYNCHRONOUS attributes."
Works for VOLATILE.
* * *
integer :: a(10),
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-07 21:09 ---
FAIL: gcc.dg/sms-3.c (internal compiler error)
FAIL: gcc.dg/sms-3.c (test for excess errors)
FAIL: gcc.dg/sms-4.c (internal compiler error)
FAIL: gcc.dg/sms-4.c (test for excess errors)
FAIL: gcc.dg/sms-6.c (internal
...
mv -f Tlto-wrapper lto-wrapper
(SHLIB_LINK='/n/42/guerby/build/./gcc/xgcc -B/n/42/guerby/build/./gcc/ -O2 -g
-O2 -minterlink-mips16 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem
./include -\
fPIC -g -DHAVE_GTHR_DEFAUL
--- Comment #14 from grosser at gcc dot gnu dot org 2010-06-07 20:59
---
Subject: Bug 40887
Author: grosser
Date: Mon Jun 7 20:59:33 2010
New Revision: 160403
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160403
Log:
Merge some commits missed during a merge from mainline in D
--- Comment #8 from grosser at gcc dot gnu dot org 2010-06-07 20:59 ---
Subject: Bug 42093
Author: grosser
Date: Mon Jun 7 20:59:33 2010
New Revision: 160403
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160403
Log:
Merge some commits missed during a merge from mainline in Dez
--- Comment #7 from grosser at gcc dot gnu dot org 2010-06-07 20:59 ---
Subject: Bug 42454
Author: grosser
Date: Mon Jun 7 20:59:33 2010
New Revision: 160403
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160403
Log:
Merge some commits missed during a merge from mainline in Dez
--- Comment #7 from bergner at gcc dot gnu dot org 2010-06-07 20:55 ---
I'll note that the thread I pointed to in the previous comment mentioned that I
thought we should be handling DDmode the same as DFmode (normally we do), but
Joseph's post here:
http://gcc.gnu.org/ml/gcc-patches/2
--- Comment #6 from bergner at gcc dot gnu dot org 2010-06-07 20:50 ---
I believe Edmar already bootstrapped and regtested the same patch.
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00346.html
--
bergner at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from jason at gcc dot gnu dot org 2010-06-07 20:43 ---
Subject: Bug 44401
Author: jason
Date: Mon Jun 7 20:43:01 2010
New Revision: 160399
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160399
Log:
PR c++/44401
* parser.c (cp_parser_lookup_name):
I have compiled sucessfully GCC 4.5.0 under various systems (solaris, cygwin,
darwin), using gmp-5.0.1, mpfr-2.4.2 and mpc-0.8.2 installed in the source tree
before compilation.
I've tried recently a new MPFR Release Candidate 2 (from
http://www.mpfr.org/mpfr-3.0.0/mpfr-3.0.0-rc2.tar.bz2) as a rep
On Linux/ia32, revision 160384 gave
FAIL: g++.dg/other/static11.C (internal compiler error)
FAIL: g++.dg/other/static11.C (test for excess errors)
FAIL: gcc.c-torture/unsorted/dump-noaddr.c, -O1 -dumpbase
dump1/dump-noaddr.c -DMASK=1 -x c --param ggc-min-heapsize=1 -fdump-ipa-all
-fdump-rtl-all
On Linux/ia32, revision 160380:
http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg00293.html
caused
FAIL: g++.dg/torture/pr32304.C -O3 -g (internal compiler error)
FAIL: g++.dg/torture/pr32304.C -O3 -g (test for excess errors)
--
Summary: [4.6 Regression] Revision 160380 caused
--- Comment #18 from rakdver at kam dot mff dot cuni dot cz 2010-06-07
20:24 ---
Subject: Re: Big spec cpu2006 prefetch regressions
on gcc 4.6 on x86
> --- Comment #14 from changpeng dot fang at amd dot com 2010-06-07 18:27
> ---
> Here is the current status of my in
--- Comment #5 from joseph at codesourcery dot com 2010-06-07 20:17 ---
Subject: Re: gengtype: don't test undefined value after
vasprintf failure
On Mon, 7 Jun 2010, dj at redhat dot com wrote:
> > If the libiberty maintainers won't review the xvasprintf patch,
>
> I did: http://gcc
--- Comment #16 from ro at gcc dot gnu dot org 2010-06-07 20:11 ---
Subject: Bug 32499
Author: ro
Date: Mon Jun 7 20:10:41 2010
New Revision: 160395
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160395
Log:
toplevel:
Backport from mainline:
2010-03-01
--- Comment #23 from jan dot kratochvil at redhat dot com 2010-06-07 20:03
---
(In reply to comment #9)
> In debug info we could use DW_OP_call{2,4} to refer to those
> DIEs' DW_AT_location, but AFAIK gdb doesn't handle those 2 yet.
FYI FSF GDB HEAD supports them now:
http://sourceware
--- Comment #4 from matt at use dot net 2010-06-07 19:46 ---
Let me know when this is implemented on trunk (preferrably by marking this
report as resolved) and I'll test my proprietary test cases here.
Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42371
--- Comment #30 from Kyle dot D dot Moffett at boeing dot com 2010-06-07
18:56 ---
Ok, the cross-compiler built with this patch fails to build a native GCC for
the target with the following ICE:
../../../src/libgcc/../libdecnumber/decLibrary.c: In function 'isinfd128':
../../../src/lib
--- Comment #3 from ro at gcc dot gnu dot org 2010-06-07 18:50 ---
Revised patch available.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
URL|h
--- Comment #17 from changpeng dot fang at amd dot com 2010-06-07 18:37
---
(In reply to comment #15)
> Created an attachment (id=20860)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20860&action=view) [edit]
> Don't consider effect of unrolling in the computation of insn-to-prefe
--- Comment #16 from changpeng dot fang at amd dot com 2010-06-07 18:32
---
Created an attachment (id=20861)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20861&action=view)
Limit non-constant step prefetching only to the innermost loops
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #15 from changpeng dot fang at amd dot com 2010-06-07 18:30
---
Created an attachment (id=20860)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20860&action=view)
Don't consider effect of unrolling in the computation of insn-to-prefetch ratio
--
http://gcc.gnu.org/
--- Comment #29 from Kyle dot D dot Moffett at boeing dot com 2010-06-07
18:28 ---
Awesome!!! Both of our testcases that were failing pass with this patch
applied!
I'm not going to call it a 100% victory yet, I want to rebuild our native
compilers and build-and-run the PostgreSQL, GMP
--- Comment #14 from changpeng dot fang at amd dot com 2010-06-07 18:27
---
Here is the current status of my investigation:
(1) 465.tonto regression (~9%):
The regressions mainly comes from loops which have array references with both
constant (prefetch_mod = 8) and non-constant (prefet
--- Comment #4 from jim at meyering dot net 2010-06-07 18:24 ---
Good! I see that there's already a patch to deal with all of the unchecked
asprintf calls, too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44435
--- Comment #3 from dj at redhat dot com 2010-06-07 18:14 ---
Subject: Re: gengtype: don't test undefined value after vasprintf failure
> If the libiberty maintainers won't review the xvasprintf patch,
I did: http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00589.html
--
http://gcc.
--- Comment #22 from tkoenig at gcc dot gnu dot org 2010-06-07 18:11
---
Adjusting subject, setting severity to "enhancement" and
adding "diagnostic" keyword.(In reply to comment #21)
> (In reply to comment #18)
> > Expected:
> > a) Allow it as extension (-std=gnu or -std=legacy; especi
--- Comment #2 from jakub at gcc dot gnu dot org 2010-06-07 18:05 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #2 from jakub at gcc dot gnu dot org 2010-06-07 18:05 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #6 from manu at gcc dot gnu dot org 2010-06-07 18:04 ---
I think the condition of this warning should be:
warn if a binary operation is performed on a type but the result is then
implicitly converted to a larger type. The workaround for a valid case should
be casting to t
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2010-06-07 17:53
---
Investigating.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Assigne
--- Comment #5 from manu at gcc dot gnu dot org 2010-06-07 17:53 ---
*** Bug 44420 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 2010-06-07 17:53 ---
I think it is a duplicate.
*** This bug has been marked as a duplicate of 42935 ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from manu at gcc dot gnu dot org 2010-06-07 17:52 ---
uint32_t bar;
uint64_t foo;
...
foo = bar << 20;
Is another testcase from PR 44420.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #1 from jakub at gcc dot gnu dot org 2010-06-07 17:50 ---
Subject: Bug 4
Author: jakub
Date: Mon Jun 7 17:50:10 2010
New Revision: 160388
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160388
Log:
PR c++/4
* expr.c (mark_exp_read): Handle IND
--- Comment #1 from jakub at gcc dot gnu dot org 2010-06-07 17:49 ---
Subject: Bug 3
Author: jakub
Date: Mon Jun 7 17:49:06 2010
New Revision: 160387
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160387
Log:
PR c++/3
* decl.c (initialize_local_var): If
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-06-07 17:36 ---
(In reply to comment #1)
> uint64_t = uint32_t OP uint32_t; With an implicit casting to uint64_t?
If that is the case this is a dup of bug 42935.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44420
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-07 17:34 ---
> foo = bar << 20;
Yes this can overflow but so can "bar * 2" and "bar + 1". Maybe I am missing
something here because we don't warn for those cases. Do you want a warning
where the assignment happens to be a wid
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-06-07 17:29 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords|
--- Comment #5 from amodra at gmail dot com 2010-06-07 17:25 ---
Created an attachment (id=20859)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20859&action=view)
fix pr42427 fallout
Would someone with e500 hardware please bootstrap and regression test this
patch? I'm running pow
Investigating the few remaining testsuite failures on Solaris 11/x86, I came
across
FAIL: gcc.target/i386/abi-2.c scan-assembler-times ymm0 1
In the assembler output, ymm0 appears twice:
vmovdqa .LC0, %ymm0
vmovdqa %ymm0, (%eax)
FAIL: gcc.target/i386/pr22076.c scan-assembler-times
--- Comment #2 from redi at gcc dot gnu dot org 2010-06-07 17:10 ---
pr.cc: In function 'int main()':
pr.cc:6:22: error: assigning to an array from an initializer list
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #28 from amodra at gmail dot com 2010-06-07 17:05 ---
Please bootstrap and test this addition to e500.h
/* When setting up caller-save slots (MODE == VOIDmode) ensure we
allocate space for DFmode. Save gprs in the correct mode too. */
#define HARD_REGNO_CALLER_SAVE_MODE
During my investigtion of testsuite differences with and without --enable-tls
(cf. PR middle-end/44450), I noticed another bunch of failures that only happen
with emutls, but only for 32-bit:
+FAIL: libgomp.c/pr33880.c execution test
+FAIL: libgomp.fortran/omp_parse1.f90 -O0 execution test
+FAIL
--- Comment #1 from redi at gcc dot gnu dot org 2010-06-07 17:03 ---
I think this is Bug 44045 and was fixed for 4.6
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
I've recently compared testsuite results on Solaris 11/x86 with --enable-tls
(the default) and --disable-tls before going on to investigate TLS problems on
Solaris 8 and 9, especially given that emutls has been broken on mainline (and
the
4.5 branch) for quite some time.
In doing so, I noticed an
--- Comment #8 from jamborm at gcc dot gnu dot org 2010-06-07 16:56 ---
(In reply to comment #5)
>
> have a look at PR44406... i believe its the same thing.
>
I think it probably is because the patch of mine would lead to code
very similar to what exposed PR 44406. However, PR 44406
I am able to compile this using -std=c++0x (not even -std=gnu++0x):
#include
int main()
{
int test[] = {1,2,3};
std::cout << test[0] << test[1] << test[2];
test = {4,5,6};
std::cout << test[0] << test[1] << test[2] << std::endl;
}
it compiles without warnings (-Wa
--- Comment #26 from jamborm at gcc dot gnu dot org 2010-06-07 16:51
---
*** Bug 44406 has been marked as a duplicate of this bug. ***
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from jamborm at gcc dot gnu dot org 2010-06-07 16:51 ---
Moreover, I cannot reproduce this bug on the 4.5 branch since:
r159866 | rguenth | 2010-05-26 13:46:01 +0200 (Wed, 26 May 2010) | 12 lines
2010-05-26 Richard Guenther
PR rtl-optimization/44164
*
--- Comment #19 from ro at gcc dot gnu dot org 2010-06-07 16:49 ---
Created an attachment (id=20858)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20858&action=view)
assembler output at -O3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946
--- Comment #18 from ro at gcc dot gnu dot org 2010-06-07 16:48 ---
Created an attachment (id=20857)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20857&action=view)
assembler output at -O0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946
The last remaining gfortran testsuite failure on Solaris 10/11 x86 is
FAIL: gfortran.dg/atan2_1.f90 -O0 execution test
(only for 32-bit). The test aborts at l.12:
do i = 1, 10
if(atan(1.0, i/10.0) -atan2(1.0, i/10.)/= 0.0) call abort()
if(atan(1.0d0,i/10.0d0)-atan2(1.0d0,i/10.0d0
--- Comment #17 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-07
16:32 ---
Subject: Re: [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran
failing tests that worked previously
I've now analysed this further: the test only fails at -O3. The failure
is an abort in l
--- Comment #2 from dg dot recrutement31 at gmail dot com 2010-06-07 16:24
---
(From update of attachment 20856)
The program in which this bug occurs have been tested with valgrind that does
not reveal memory leak and other bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7
1 - 100 of 156 matches
Mail list logo
