--- Comment #7 from ramana at gcc dot gnu dot org 2009-05-12 09:36 ---
Confirmed with r147377
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
St
This for loop
for(unsigned i=object::min(_digits, (int)NATIVE_DIGITS);ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=40111
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40107
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-12 09:51 ---
We need a testcase that is reproducible.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from face dot mitev at gmail dot com 2009-05-12 09:54
---
Not a gcc bug, sorry for the confusion.
--
face dot mitev at gmail dot com changed:
What|Removed |Added
--
--- Comment #1 from ramana at gcc dot gnu dot org 2009-05-12 10:05 ---
init_expr_once is now renamed to init_expr_target, though I see that the
comments / code you refer to in the bug report still exist . Can you give any
examples of optimizations that might be enabled if we went ahead a
data incorrectly placed into .data or .rodata instead of .progmem. This makes
impossible using avr-libc predefined types (avr/pgmspace.h).
test.cpp:
char __attribute__((__progmem__)) Test1[] = "test1";
char const __attribute__((__progmem__)) Test2[] = "test2";
typedef char __attribute__((__progme
all data placed to single .progmem.data section.
test.cpp:
char __attribute__((__progmem__)) Test1[] = "test1";
char const __attribute__((__progmem__)) Test2[] = "test2";
void const * array[] =
{
Test1, Test2
};
cmd line:
avr-gcc -mmcu=atmega8 -fdata-sections -Wall -Os -Wa,-ahlmsd=test.lst
Using built-in specs.
Target: mingw32
Configured with: ../gcc-4.3.3/configure --prefix=/mingw --build=mingw32
--enable-languages=c,ada,c++,fortran,objc,obj-c++
--with-bugurl=http://www.tdragon.net/recentgcc/bugs.php --disable-nls
--disable-win32-registry --enable-libgomp --disable-werror --enable-t
The following program:
"
cat -n main.c
1 #include
2
3
4 int main()
5{
6__label__ lab3;
7__label__ lab4;
8
9int i = 0;
10
11i++;
12lab1: fprintf(stderr, "i=%d\n", i);
13
14i++;
15lab2: fprintf(std
--- Comment #2 from drow at gcc dot gnu dot org 2009-05-12 11:36 ---
Sorry, I don't know.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35296
--- Comment #6 from uros at gcc dot gnu dot org 2009-05-12 11:43 ---
Subject: Bug 37197
Author: uros
Date: Tue May 12 11:42:53 2009
New Revision: 147429
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147429
Log:
PR target/37197
* config/i386/driver-i386.c (proces
--- Comment #1 from hubicka at gcc dot gnu dot org 2009-05-12 11:52 ---
Hmm, the inlined functions has loop depth of 4, that makes it predicted to
iterate quite few times. My guess would be that inlining increases loop depth
that in turn makes GCC to conclude that one of loops that are i
--- Comment #1 from bonzini at gnu dot org 2009-05-12 12:04 ---
If you work between r147424 and r147425, there should be no other spurious
changes to the code besides those described in the bug reports.
--
bonzini at gnu dot org changed:
What|Removed
--
bonzini at gnu dot org changed:
What|Removed |Added
Summary|[cond-optab] extra sign |[4.5 Regression][cond-optab]
|extensions on Thumb |
--
bonzini at gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
Summary|[cond-optab] CSE does not |[4.5 Regression][cond-opta
--
bonzini at gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39716
--
bonzini at gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
Summary|[cond-optab] crash on crx in|[4.5 Regression][cond-opta
--
bonzini at gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
Summary|[cond-optab] uses libcall |[4.5 Regression][cond-opta
--
bonzini at gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
Summary|[cond-optab] combine does |[4.5 Regression][cond-opta
--
bonzini at gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
Summary|[cond-optab] worse register |[4.5 Regression][cond-opta
--- Comment #7 from ubizjak at gmail dot com 2009-05-12 12:07 ---
Oops, wrong PR number.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37197
--
bonzini at gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
Summary|[cond-optab] worse code with|[4.5 Regression][cond-opta
--
bonzini at gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
Summary|[cond-optab] worse code with|[4.5 Regression][cond-opta
--
bonzini at gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
Summary|[cond-optab]|[4.5 Regression][cond-opta
--
bonzini at gnu dot org changed:
What|Removed |Added
Summary|[cond-optab] MIPS |[4.5 Regression][cond-optab]
|pessimizations on floating- |
--- Comment #14 from ubizjak at gmail dot com 2009-05-12 12:08 ---
Author: uros
Date: Tue May 12 11:42:53 2009
New Revision: 147429
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147429
Log:
PR target/37197
* config/i386/driver-i386.c (processor_signatures): New e
--
bonzini at gnu dot org changed:
What|Removed |Added
Summary|[cond-optab] ColdFire |[4.5 Regression][cond-optab]
|pessimizations on |
Did some research, I see a bug for this, but it is closed as fixed in 4.2, I
have updated to 4.2.4 (Ubuntu Hardy Updates), but still have the problem. If
you need any other info, let me know and I'll be happy to provide it. The
source code listing (gcc said to cat about 2 lines of our code)
--- Comment #1 from charlet at gcc dot gnu dot org 2009-05-12 12:32 ---
Well, there's nothing we can do without a stand alone (if possible simplified)
reproducer.
Arno
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
permail/j3/attachments/20090512/817b9628/attachment.txt,
which is the following paper:
http://j3-fortran.org/doc/year/09/09-208r2.txt
Disclaimer: Fortran 2008 is not yet a formal standard, the route to it is
listed here: ftp://ftp.nag.co.uk/sc22wg5/N1751-N1800/N1781.txt
--
Summary: F
The powerpc bootstrap fails due to an inner block that has:
rtx op1 = XVECEXP (op1, 0, 0);
and this triggers the error:
error: op1 may be used uninitialized in this function
--
Summary: cond-optab breaks powerpc bootstrap
Product: gcc
Version: 4.5.0
--- Comment #1 from meissner at gcc dot gnu dot org 2009-05-12 12:52
---
Subject: Bug 40118
Author: meissner
Date: Tue May 12 12:52:45 2009
New Revision: 147434
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147434
Log:
Fix PR bootstrap/40118
Modified:
trunk/gcc/ChangeLog
--- Comment #2 from meissner at linux dot vnet dot ibm dot com 2009-05-12
12:54 ---
Created an attachment (id=17854)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17854&action=view)
Patch to fix bootstrap error message.
Patch applied to the tree as obvious.
--
http://gcc.gnu
--- Comment #11 from luisgpm at linux dot vnet dot ibm dot com 2009-05-12
12:55 ---
Any updates?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
--- Comment #11 from danglin at gcc dot gnu dot org 2009-05-12 13:06
---
Build no longer ICEs. I believe this PR was fixed by the
following change:
2009-05-10 Michael Matz
PR target/40031
* config/arm/arm.c (require_pic_register): Emit on entry edge,
not at
--
Summary: ICE with --param hot-bb-frequency-fraction=0
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
Re
--- Comment #1 from dominiq at lps dot ens dot fr 2009-05-12 13:11 ---
Since the manual only gives:
hot-bb-frequency-fraction
Select fraction of the maximal frequency of executions of basic block in
function given basic block needs to have to be considered hot
for --param hot-bb-frequ
--- Comment #11 from jakub at gcc dot gnu dot org 2009-05-12 13:19 ---
Partial fix:
http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00637.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39865
--- Comment #2 from dominiq at lps dot ens dot fr 2009-05-12 13:23 ---
> decreasing --param hot-bb-frequency-fraction might help in this case.
I have tried --param hot-bb-frequency-fraction=1 (which seems the smallest
possible value, see pr40119), but it did not changed anything.
What
emmintrin.h says
/* The Intel API is flexible enough that we must allow aliasing with other
vector types, and their scalar components. */
typedef long long __m128i __attribute__ ((__vector_size__ (16),
__may_alias__));
but the following testcase fails:
#include
#include
int main()
{
co
--- Comment #12 from matz at gcc dot gnu dot org 2009-05-12 13:37 ---
The problem is that for PHI node expansion something has to be inserted on
the backedge of a single BB loop, splitting it into two BBs (where one just
contains one instruction). Something in the RTL passes then moves
Revision 147418:
http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00393.html
caused:
FAIL: gcc.target/i386/ssefp-1.c scan-assembler maxsd
FAIL: gcc.target/i386/ssefp-2.c scan-assembler minsd
on Linux/ia32 and Linux/x86-64.
--
Summary: [4.5 Regression] Revision 147418 failed
The following testcase
#include
typedef union {
__m128i v;
int m[4];
} VectorUnion;
VectorUnion one()
{
VectorUnion r = { _mm_set1_epi32(1) };
return r;
}
int main()
{
VectorUnion x = one();
if (0x == _mm_movemask_epi8(_mm_cmpeq_epi32(x.v, x.v))) {
return 0;
--- Comment #1 from bonzini at gnu dot org 2009-05-12 13:52 ---
The commit was temporary to more easily pinpoint changes due to the cond-optab
branch, and has already been reverted. The two testcases do not fail anymore
with current trunk.
Thanks!
--
bonzini at gnu dot org changed:
--- Comment #3 from rguenther at suse dot de 2009-05-12 14:47 ---
Subject: Re: Time increase with inlining for the
Polyhedron test air.f90
On Tue, 12 May 2009, dominiq at lps dot ens dot fr wrote:
> --- Comment #2 from dominiq at lps dot ens dot fr 2009-05-12 13:23
> ---
>
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-12 14:49 ---
*** This bug has been marked as a duplicate of 4210 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #20 from pinskia at gcc dot gnu dot org 2009-05-12 14:49
---
*** Bug 40114 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-05-12 14:51 ---
*** Bug 40113 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-12 14:51 ---
*** This bug has been marked as a duplicate of 39456 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-12 14:55 ---
No labels are not designed that way. They are designed only for jumping and
when they are taken the address of, there should only be used for jumping and
nothing else.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #22 from singler at gcc dot gnu dot org 2009-05-12 14:57
---
Subject: Bug 39546
Author: singler
Date: Tue May 12 14:57:35 2009
New Revision: 147439
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147439
Log:
2009-05-12 Johannes Singler
PR libstdc++/39546
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-12 15:00 ---
The union copy confuses GCC:
r.v = VIEW_CONVERT_EXPR({1, 1, 1, 1});
D.6990 = r;
x = D.6990;
D.6997 = VIEW_CONVERT_EXPR(x.v);
D.6994 = __builtin_ia32_pcmpeqd128 (D.6997, D.6997);
D.7000 = __builtin_ia32_p
On Linux/x86-64, with checking enabled, revision 147395
http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00369.html
caused
FAIL: 26_numerics/random/independent_bits_engine/operators/equal.cc execution
test
FAIL: 26_numerics/random/independent_bits_engine/operators/serialize.cc
execution test
with -m32.
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-12 15:01 ---
The aliasing is directional - you may access ints via a pointer to __m128i but
not the other way around.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-12 15:02 ---
GCC 4.2 is no longer maintained, please reproduce with at least GCC 4.3.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40116
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40123
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-05-12 15:24 ---
This is a dup of bug 36327.
*** This bug has been marked as a duplicate of 36327 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-05-12 15:24 ---
*** Bug 40122 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #23 from paolo dot carlini at oracle dot com 2009-05-12 15:27
---
Fixed for 4.4.1.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #13 from pinskia at gcc dot gnu dot org 2009-05-12 15:29
---
(In reply to comment #12)
> I'm working on a fix. Earlier compilers contained a hack for this (because
> swing modulo scheduling can only deal with single BB loops),
It was not just SMS which only can deal with
--- Comment #2 from sergstesh at yahoo dot com 2009-05-12 15:43 ---
No, the documentation explicitly says
( http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc.pdf , page 247 .. 248):
"
5.3 Labels as Values
...
To use these values, you need to be able to jump to one. This is done with
the c
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-05-12 15:58 ---
The intention of address of labels is only for use of flow control and nothing
else. So taking the address of a label and using it to find the current PC is
not a valid use of this extension. This extension was not
Right now gcc does not officially support local control flow of any kind. The
user is free to jump around within an asm block using local labels but this is
cumbersome and bug-prone. Jumping out of an asm block in any way is
(un?)officially verboten.
This RFE is for support of jumping from an asm
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-12 16:05 ---
GCC can already produce good code for overflow catching on x86. I think it is
better if you don't use inline-asm for this case at all and just write the
overflow detection in C90/C99 (which means don't cause an over
--- Comment #2 from scovich at gmail dot com 2009-05-12 16:13 ---
Overflow and adc were only examples. Other instructions that set cc, or other
conditions (e.g. parity) would not have that optimization.
Another use is the ability to jump out of an inline asm to handle an uncommon
case (
--- Comment #4 from dominiq at lps dot ens dot fr 2009-05-12 16:18 ---
Assembly code for the inlined inner loop:
L123:
movsd (%rdx), %xmm15
movsd 8(%rdx), %xmm6
mulsd (%rax), %xmm15
mulsd 1200(%rax), %xmm6
movsd 16(%rdx), %xmm4
m
--- Comment #7 from jakub at gcc dot gnu dot org 2009-05-12 16:19 ---
Subject: Bug 39666
Author: jakub
Date: Tue May 12 16:19:29 2009
New Revision: 147440
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147440
Log:
PR middle-end/39666
* gimplify.c (gimplify_switch
--- Comment #3 from hjl dot tools at gmail dot com 2009-05-12 16:23 ---
We are investigating if we need to add non-SSE intrinsics into gcc.
If you can show me an example where gcc can't generate similar
code automatically vs inline asm statement, I will look into if
we should add some ap
--- Comment #8 from jakub at gcc dot gnu dot org 2009-05-12 16:24 ---
Fixed for 4.4/4.5 so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Su
--- Comment #15 from hjl at gcc dot gnu dot org 2009-05-12 16:33 ---
Subject: Bug 37179
Author: hjl
Date: Tue May 12 16:33:14 2009
New Revision: 147441
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147441
Log:
PR target/37179:
* Correct PR number for revision 14
--- Comment #4 from scovich at gmail dot com 2009-05-12 16:36 ---
I'm actually running sparcv9-sun-solaris2.10 (the examples used x86 because
more people know it and its asm is easier to read).
My use case is the following: I'm implementing high-performance synchronization
primitives an
.L7
cmpl$5, %edi
je .L7
rep
ret
.p2align 4,,10
.p2align 3
.L7:
xorl%eax, %eax
jmp F
.cfi_endproc
.LFE0:
.size f, .-f
.ident "GCC: (GNU) 4.5.0 20090512 (experimental)"
.section.
--- Comment #5 from hjl dot tools at gmail dot com 2009-05-12 16:42 ---
(In reply to comment #4)
> I'm actually running sparcv9-sun-solaris2.10 (the examples used x86 because
> more people know it and its asm is easier to read).
>
> My use case is the following: I'm implementing high-pe
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-05-12 16:48 ---
Sounds like you want to use __builtin_expect.
Also GCC uses heuristics to figure out:
if(pred)
is taken most of the time because it is comparing a pointer to NULL.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #7 from scovich at gmail dot com 2009-05-12 17:01 ---
Isn't __builtin_expect a way to send branch prediction hints? I'm not having
trouble with that AFAIK.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40124
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-05-12 17:08 ---
(In reply to comment #7)
> Isn't __builtin_expect a way to send branch prediction hints?
Not just prediction hints, it helps other optimizations of not moving code
around inter block which seems like what you need.
--- Comment #2 from armin76 at gentoo dot org 2009-05-12 17:27 ---
(In reply to comment #1)
> Your compilers are the gentoo special versions, aren't they?
Nope, there's no patch applied in this case. If you meant that we don't 'make
bootstrap-lean && make install', yes.
> If so, you sho
--- Comment #13 from jakub at gcc dot gnu dot org 2009-05-12 18:56 ---
In 4.4.0/x86_64-linux at -O2 at least the problem seems to be that in:
_ZNK5boost9xpressive6detail17xpression_adaptorINS1_16static_xpressionINS1_17alternate_matcherINS1_15alternates_listINS3_INS1_13regex_matcherIN9__g
--- Comment #14 from jakub at gcc dot gnu dot org 2009-05-12 19:06 ---
In *.pre it still looks correct:
adaptor.D.166953._vptr.matchable =
&_ZTVN5boost9xpressive6detail17xpression_adaptorINS_17reference_wrapperIKNS1_17stacked_xpressionINS1
_16static_xpressionINS1_11end_matcherENS1_7no_
--- Comment #4 from burnus at gcc dot gnu dot org 2009-05-12 19:27 ---
Subject: Bug 40061
Author: burnus
Date: Tue May 12 19:26:46 2009
New Revision: 147445
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147445
Log:
2009-05-12 Tobias Burnus
PR bootstrap/40061
--- Comment #15 from jakub at gcc dot gnu dot org 2009-05-12 19:34 ---
Ah, there are two different adaptor variables after inlining, so this might as
well be a dup of PR39604.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39509
--- Comment #5 from burnus at gcc dot gnu dot org 2009-05-12 19:42 ---
FIXED on the 4.3 branch. Thanks for reporting the problem and sorry for the
breakage.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
-
GCC 4.4 or later configured with --enable-shared for i686-mingw32
installs a libgcc DLL (e.g. libgcc_s_dw2-1.dll) in $(bindir). As
this is a binary for the target not the host, this is an inappropriate
location in a cross toolchain; some target-specific directory (e.g.
i686-mingw32/bin or i686-min
When building tools/widl/typelib.c from Wine with -O2 -g, we started
getting the following some three days ago:
/var/tmp//cc43jwq2.s: Assembler messages:
/var/tmp//cc43jwq2.s:2059: Error: can't resolve `.LFE95' {*UND* section} -
`.Ltext0' {.text section}
This is on i386-unknown-freebsd7.1 with GN
--- Comment #1 from gerald at pfeifer dot com 2009-05-12 20:40 ---
Created an attachment (id=17855)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17855&action=view)
Preprocessed source file; test with $GCC -g -O2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40126
--- Comment #3 from burnus at gcc dot gnu dot org 2009-05-12 21:10 ---
I have a patch for this. Note, however, that the compiler - even with default
options - (too) aggressively optimizes your program, i.e. the assignment is
optimized away even with -O0 and thus for your program the valu
This code:
template
voidfoo(int i, void(*f)(T*) = 0, T* a = 0) {}
int main() {
foo(5);
return 0;
}
gets you:
foo.cc: In function int main():
foo.cc:5: error: no matching function for call to foo(int)
So I figured that binding required an actual type, so I tried
--- Comment #12 from burnus at gcc dot gnu dot org 2009-05-12 22:05 ---
Some more data:
==16952== Conditional jump or move depends on uninitialised value(s)
==16952==at 0x4470FC: write_atom (module.c:1339)
==16952==by 0x4472DD: mio_integer (module.c:1450)
==16952==by 0x447DA
--- Comment #3 from bje at gcc dot gnu dot org 2009-05-12 22:19 ---
Fixed.
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #11 from bje at gcc dot gnu dot org 2009-05-12 22:21 ---
Fixed.
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #3 from kkojima at gcc dot gnu dot org 2009-05-12 22:37 ---
Ah, now I understand the issue and find that what we need
in the bug report http://gcc.gnu.org/bugs.html#need is in
http://bugs.gentoo.org/show_bug.cgi?id=267247. Next time,
please give the minimal information to re
--- Comment #35 from bkoz at gcc dot gnu dot org 2009-05-12 22:43 ---
Closing.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-12 22:43 ---
Subject: Bug 40110
Author: burnus
Date: Tue May 12 22:42:45 2009
New Revision: 147452
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147452
Log:
2009-05-12 Tobias Burnus
PR fortran/40110
*
--- Comment #2 from burnus at gcc dot gnu dot org 2009-05-12 22:44 ---
FIXED on the trunk (4.5).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from kkojima at gcc dot gnu dot org 2009-05-12 22:47 ---
Subject: Bug 39561
Author: kkojima
Date: Tue May 12 22:47:03 2009
New Revision: 147453
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147453
Log:
PR target/39561
* config/sh/sh.h (OPTIMIZATIO
--- Comment #10 from bkoz at gcc dot gnu dot org 2009-05-12 23:01 ---
Sorry for the delay Paolo, this fix looks fine.
I see tanhl missing too in that log, yet the gnu.ver exports have it and so
does src/math_compatibility_long_double.cc, although depending on
_GLIBCXX_HAVE_TANHL. What
--- Comment #3 from bkoz at gcc dot gnu dot org 2009-05-12 23:06 ---
Closing as resolved, duplicate of 36801 pending feedback from submitter. If you
feel this is incorrect please re-open and respond to comment #2.
--
bkoz at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from kkojima at gcc dot gnu dot org 2009-05-12 23:08 ---
Fixed.
FYI, I've confirmed that -mno-expand-cbranchdi is still broken
after r146539 fix of cbranchdi4 and the cond-optab merge.
--
kkojima at gcc dot gnu dot org changed:
What|Removed
1 - 100 of 101 matches
Mail list logo
