--- Comment #3 from burnus at gcc dot gnu dot org 2010-04-14 06:33 ---
Some underflow module for Fortran:
http://gcc.gnu.org/ml/fortran/2010-04/msg00144.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29383
--- Comment #20 from burnus at gcc dot gnu dot org 2010-04-14 05:43 ---
Subject: Bug 18918
Author: burnus
Date: Wed Apr 14 05:43:30 2010
New Revision: 158292
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158292
Log:
2010-04-14 Tobias Burnus
PR fortran/18918
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2010-04-14 05:27
---
Subject: Bug 43747
Author: jvdelisle
Date: Wed Apr 14 05:27:29 2010
New Revision: 158291
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158291
Log:
2010-04-14 Jerry DeLisle
PR fortran/43747
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2010-04-14 05:17
---
Subject: Bug 43747
Author: jvdelisle
Date: Wed Apr 14 05:16:59 2010
New Revision: 158290
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158290
Log:
2010-04-14 Jerry DeLisle
PR fortran/43747
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2010-04-14 05:08
---
Easier then I thought. Patch submitted for approval.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43747
--- Comment #5 from kkojima at gcc dot gnu dot org 2010-04-14 04:52 ---
It looks that simply removing the problematic constraint from
doloop_end_split restores build with no performance regressions.
* config/sh/sh.md (doloop_end_split): Remove "+r" constraint
in an input
--- Comment #14 from jason at gcc dot gnu dot org 2010-04-14 01:41 ---
That sounds like another case where trying to recover from an error by changing
a problematic type to 'int' doesn't actually improve matters.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9335
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2010-04-14 01:32
---
OK, I see it now. This is a little different from our previous encounters with
overly big constructors. In fact, the code we had in place is still there, so
we have whacked something. The test case does not fail
--- Comment #4 from kkojima at gcc dot gnu dot org 2010-04-14 00:55 ---
(In reply to comment #3)
> This seems to be due to a pattern that uses a "+" constraint in an input-only
> operand. The attached patch seems to fix it for me; please confirm.
[I'd like to add Christian to the cc li
--- Comment #13 from manu at gcc dot gnu dot org 2010-04-13 23:48 ---
I have a patch that prints this:
/home/manuel/src/pr9335.C:2:36: error: template instantiation depth exceeds
maximum of 1024 (use -ftemplate-depth= to increase the maximum) instantiating
struct X<-0x00018
--- Comment #2 from gcc at cohi dot at 2010-04-13 21:26 ---
(In reply to comment #1)
> Most likely related to PR 43277. I want to say Darwin10's unwinder is broken
> ...
Can this be confirmed?
The information in PR 43277, and the ones linked from there, seemed
inconclusive...
(I can
--- Comment #5 from steven at gcc dot gnu dot org 2010-04-13 21:23 ---
Matz, can you at least attach the patch to this PR, so that someone else can
polish it if you're not going to do it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42963
--- Comment #2 from burnus at gcc dot gnu dot org 2010-04-13 20:56 ---
(In reply to comment #1)
> I don't see the failure on linux-x86-64. I am building on Cygwin to see whta
> shows up there. I seem to recall a patch that changed a fatal error to a
> non-fatal somewhere. I will have a
--- Comment #15 from dominiq at lps dot ens dot fr 2010-04-13 20:45 ---
(In reply to comment #13)
> Here we have index `i1' calculated from fp values and then casted to int.
> Segmentation fault occurs in `y1 = y(i1)' with i1 equal to
> 0x800c.
> This is in function S00061
When building a compiler with --prefix=/some/dir and
--exec-prefix=/some/dir/subdir, the installed gnat cannot find the installed
libraries in /some/dir/subdir/lib/gcc/...
I believe that sdefault.adb should be generated with
S0 : constant String := \"$(exec_prefix)/\";"
not
S0 : constant String
--- Comment #14 from mkuvyrkov at gcc dot gnu dot org 2010-04-13 20:01
---
(In reply to comment #10)
> - D.1850_209 = -alt_90;
> - D.2093_151 = -alb_86;
> - D.1849_208 = D.1848_207 - alb_86;
> + D.2093_151 = -alt_90;
> + D.1849_208 = D.1848_207 - alt_90;
>D.1851_210 = D.1849_20
--- Comment #5 from ubizjak at gmail dot com 2010-04-13 19:46 ---
(In reply to comment #1)
> Created an attachment (id=20331)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20331&action=view) [edit]
> gcc46-pr43681.patch
>
> Untested patch.
How about:
Index: expr.c
==
--- Comment #13 from mkuvyrkov at gcc dot gnu dot org 2010-04-13 19:32
---
The SIGSEGV is due to -funsafe-math-optimizations being used with code like:
==
Re = eps*debm*DIAhy/(vis*sec)
reo = Re
IF ( Re.LT.1000. ) THEN
i1 = INT(Re/200.) + 1
ELSEIF ( Re.LT
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2010-04-13 19:03
---
I don't see the failure on linux-x86-64. I am building on Cygwin to see whta
shows up there. I seem to recall a patch that changed a fatal error to a
non-fatal somewhere. I will have a look tonight.
--
http
--- Comment #38 from aph at gcc dot gnu dot org 2010-04-13 17:25 ---
I think I can fairly easily add an option to the linker to suppress table
merging when linking Java libraries, and that will completely solve the
problem, at least from my point of view. To that end, it would not be at
--- Comment #37 from aph at redhat dot com 2010-04-13 17:02 ---
Subject: Re: [4.4/4.5/4.6 regression] regressions in libjava
testsuite on arm-linux
On 04/13/2010 05:52 PM, mikpe at it dot uu dot se wrote:
>> Is it maybe the case that "Compact model 1" unwinder data isn't yet being
>>
--- Comment #49 from howarth at nitro dot med dot uc dot edu 2010-04-13
16:59 ---
(In reply to comment #48)
> (d) temporarily patches darwin10.h to include the static lib first and
> therefore work around this bug until the radar is done.
>From what I was told (Comment 47), the radar b
The current build machinery in FSF gcc doesn't appear to provide a mechanism to
install target specific .def files when install-plugin installs the header
files. In particular, after applying...
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00610.html
...and building gcc trunk or gcc-4_5-branch on
--- Comment #48 from iains at gcc dot gnu dot org 2010-04-13 16:52 ---
give me a day or two guys...
and I'll post a composite patch that
(a) cleans up some of the nits in config{,/*}/darwin*.h
(b) gets rid of -lgcc [well, moves it to the only places it's still needed]
(c) sorts out dsy
--- Comment #36 from mikpe at it dot uu dot se 2010-04-13 16:51 ---
(In reply to comment #35)
> I've been trying this on gcc trunk, and it doesn't have the problem.
> It seems that merging is not done.
>
> I get
>
> ...
> 0x8684 : @0x8808
> Compact model 1
> 0xb1 0x08 pop {r3}
>
--- Comment #47 from howarth at nitro dot med dot uc dot edu 2010-04-13
16:48 ---
Not good news...according to another Apple programmer...
--
Mike Stump filed the radar:
___divdc3 slightly wrong
Since fixing it did not appear to positively impact our customers I recommended
--- Comment #35 from aph at gcc dot gnu dot org 2010-04-13 16:36 ---
I've been trying this on gcc trunk, and it doesn't have the problem.
It seems that merging is not done.
I get
...
0x8684 : @0x8808
Compact model 1
0xb1 0x08 pop {r3}
0x84 0x00 pop {r14}
0xb0 finish
0xb0
--- Comment #46 from dominiq at lps dot ens dot fr 2010-04-13 16:29 ---
> Did anyone ever file a radar bug report on the inaccurate complex math from
> http://compiler-rt.llvm.org/?
I did not see anything along this line in their bugzilla. However there is
comment #25
> I've filed radr
--- Comment #45 from howarth at nitro dot med dot uc dot edu 2010-04-13
16:06 ---
Did anyone ever file a radar bug report on the inaccurate complex math from
http://compiler-rt.llvm.org/?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
--- Comment #44 from howarth at nitro dot med dot uc dot edu 2010-04-13
16:01 ---
>From a discussion with the clang programmers, I have this response...
> > The FIXME comment in the clang sources caught my eye because,
> > at first glance, it appears to be hinting that this usage
> > o
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2010-04-13 15:48
---
Subject: Bug 32628
Author: ebotcazou
Date: Tue Apr 13 15:47:38 2010
New Revision: 158274
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158274
Log:
PR middle-end/32628
* c-common.c (point
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-04-13 14:30
---
So, my fault.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|
--- Comment #10 from jakub at gcc dot gnu dot org 2010-04-13 14:18 ---
Yes, we sometimes install linker scripts, sometimes symbolic links.
E.g. on powerpc64-linux, 32-bit libgcc_s.so is a linker script, while 64-bit
libgcc_s.so is a symlink.
If you after install overwrite it with a symli
After the merge from fortran-exp to trunk the following tests
[macbook] f90/bug% cat pr19925_1.f90
INTEGER, PARAMETER :: N=10
INTEGER, PARAMETER :: I(N)=(/(MOD(K,2),K=1,N)/)
INTEGER, PARAMETER :: M(N)=I(N:1:-1)
END
[macbook] f90/bug% cat pr19925_1_db.f90
INTEGER, PARAMETER :: N=10
INTEGER
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-04-13 14:10 ---
(In reply to comment #7)
> Is the libgcc_s.so the link finds a linker script?
> You can use -Wl,-M,--verbose to see what is going on.
No, it doesn't seem to.
START GROUP
LOAD /lib/libc.so.6
LOAD /usr/lib/libc_nonsh
--- Comment #12 from dominiq at lps dot ens dot fr 2010-04-13 14:09 ---
A few additional notes:
(1) with revision 158105 reverted, the test gcc.dg/tree-ssa/reassoc-19.c fails
with -m32, but passes with -m64.
(2) revision 158265 with/without revision 158105 reverted (after some surgery
--- Comment #8 from marcus at jet dot franken dot de 2010-04-13 14:08
---
$ file /usr/lib/gcc/powerpc64-suse-linux/4.5/libgcc_s.so
/usr/lib/gcc/powerpc64-suse-linux/4.5/libgcc_s.so: symbolic link to
`/lib/libgcc_s.so.1'
$ file /lib/libgcc_s.so.1
/lib/libgcc_s.so.1: ELF 32-bit MSB shared
--- Comment #7 from matz at gcc dot gnu dot org 2010-04-13 13:54 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from matz at gcc dot gnu dot org 2010-04-13 13:47 ---
Subject: Bug 43730
Author: matz
Date: Tue Apr 13 13:47:11 2010
New Revision: 158270
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158270
Log:
PR middle-end/43730
* builtins.c (expand_builtin_in
--- Comment #5 from matz at gcc dot gnu dot org 2010-04-13 13:35 ---
Subject: Bug 43730
Author: matz
Date: Tue Apr 13 13:35:30 2010
New Revision: 158268
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158268
Log:
PR middle-end/43730
* builtins.c (expand_builtin_in
--- Comment #7 from jakub at gcc dot gnu dot org 2010-04-13 12:43 ---
Is the libgcc_s.so the link finds a linker script?
You can use -Wl,-M,--verbose to see what is going on.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43727
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-04-13 12:34 ---
I can reproduce it.
/tmp> g++ -Os -shared -o libhello.so -Wl,-z,defs -fPIC hello.c -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/powerpc64-suse-linux/4.5/lto-wrapper
Target: powerpc64-sus
--- Comment #21 from redi at gcc dot gnu dot org 2010-04-13 12:26 ---
more accurate summary
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
Summary
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-04-13 12:24 ---
really
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-04-13 12:23 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|---
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-13 12:23 ---
Subject: Bug 43737
Author: rguenth
Date: Tue Apr 13 12:23:17 2010
New Revision: 158264
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158264
Log:
2010-04-13 Richard Guenther
PR bootstrap/43737
--- Comment #4 from matz at gcc dot gnu dot org 2010-04-13 11:59 ---
No, we shouldn't unconditionally create REGs if the target isn't one, but
rather only if it doesn't match the predicate. Like so, which I'm testing
right now:
Index: builtins.c
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-04-13 11:51 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-13 11:51 ---
Subject: Bug 43735
Author: rguenth
Date: Tue Apr 13 11:50:54 2010
New Revision: 158263
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158263
Log:
2010-04-13 Richard Guenther
PR testsuite/43735
--- Comment #19 from iains at gcc dot gnu dot org 2010-04-13 11:37 ---
Subject: Bug 31400
Author: iains
Date: Tue Apr 13 11:37:34 2010
New Revision: 158262
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158262
Log:
gcc/fortran:
2010-04-13 Iain Sandoe
PR bootstrap/314
--- Comment #2 from jamborm at gcc dot gnu dot org 2010-04-13 11:31 ---
(In reply to comment #1)
> Confirmed.
>
> I think the testcase is broken. We now force always-inline functions to
> be inlined during early inlining (which you can't turn off completely
> now, similar to IPA inlini
--- Comment #20 from redi at gcc dot gnu dot org 2010-04-13 11:21 ---
oops - I didn't mean to set the component back to libfortran, that must have
happened when I refreshed the page and my browser "helpfully" kept that
selected. I've reverted it to bootstrap
I don't think it should be c
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-04-13 11:20 ---
Well. There is
pretmp.2458_440 = c[2]{lb: 0 sz: 8};
...
c[2] = D.84046_29;
in a possibly dead code region dominated by
if (pretmp.2460_55 > 16)
goto ;
else
goto ;
where pretmp.2460_55 is (unsigne
--- Comment #6 from aflyhorse at foxmail dot com 2010-04-13 10:58 ---
(In reply to comment #5)
> I don't get why you closed this bug. Anyways if you have a patch, post it to
> gcc-patc...@.
Sorry, I see nobody concerns this, and I'm more anxious about how to port the
libgcj (especially
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||ro at gcc dot gnu dot org
Summary|FAIL: gcc.dg/pr43643.c (
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-13 10:37 ---
Can you bisect the few commits that happened inbetween? Like reverting
the fixes for PRs 43679 and/or 43661, 43642?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Ad
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43742
--- Comment #37 from rguenth at gcc dot gnu dot org 2010-04-13 10:29
---
*** Bug 43744 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-04-13 10:29 ---
*** This bug has been marked as a duplicate of 42841 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #19 from burnus at gcc dot gnu dot org 2010-04-13 10:12 ---
> This looks like a bug in binutils 2.15
Can we thus close the bug? Or remains there something to do in libgfortran?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43733
--- Comment #18 from redi at gcc dot gnu dot org 2010-04-13 09:21 ---
Instead I've decided to use --with-arch=nocona --with-tune=core2, since that
avoids having to deploy a new binutils to every server where I want to deploy
gcc
--
redi at gcc dot gnu dot org changed:
Wha
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-13 09:11 ---
Confirmed.
I think the testcase is broken. We now force always-inline functions to
be inlined during early inlining (which you can't turn off completely
now, similar to IPA inlining before the patch). So we hit
/
--- Comment #3 from bernds at codesourcery dot com 2010-04-13 09:09 ---
Created an attachment (id=20377)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20377&action=view)
A patch to fix the problem
This seems to be due to a pattern that uses a "+" constraint in an input-only
operan
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-13 09:02 ---
Micha - compared to 4.4 we arrive with
(gdb) call debug_rtx (target)
(mem/c/i:SI (plus:DI (reg/f:DI 54 virtual-stack-vars)
(const_int -4 [0xfffc])) [0 result+0 S4 A32])
instead of
(gdb) call de
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org
--- Comment #1 from j at uriah dot heep dot sax dot de 2010-04-13 08:31
---
I think this is essentially a duplicate of bug #21018.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43746
-fmerge-all-constants and –fmerge-constants don’t work at AVR
target.
Example:
const char text1[] PROGMEM=”Test”;
const char text2[] PROGMEM=”Test”;
will still produce duplicated “Test” string in generated code.
--
Summary: -fmerge-constants and -fmerge-all-constants don't work
On AVR target g++ generates code which copies object’s VTABLES from FLASH
to SRAM wasting the memory. Due to the Harvard architecture of AVR processors
the solution is not trivial. This behavior can be observed in any c++ program
which has object with virtual method, e.g:
Class test
{
virtu
--- Comment #4 from iwamatsu at nigauri dot org 2010-04-13 08:09 ---
Hi,
(In reply to comment #3)
> Looks that Christian's patch pic-cp.patch
>
> http://gcc.gnu.org/bugzilla/attachment.cgi?id=19794
>
> in PR target/42841 can fix the problem. Could you
> please try it?
>
I confirmed t
--- Comment #7 from liranuna at gmail dot com 2010-04-13 07:43 ---
Mikael's patch seems to do that trick as well as producing very nice assembly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43722
70 matches
Mail list logo