--- Comment #7 from patrick dot pastoor at onespin-solutions dot com
2008-02-26 07:43 ---
See comment #6!
--
patrick dot pastoor at onespin-solutions dot com changed:
What|Removed |Added
--- Comment #1 from dgregor at gcc dot gnu dot org 2008-02-26 07:16 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2008-02/msg01272.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35315
--
bergner at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.3.0 4.4.0
Priority|P3 |P2
http
--
bergner at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last re
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #11 from manu at gcc dot gnu dot org 2008-02-26 00:59 ---
The main request of this bug (ignore unknown -Wno-* options) has been committed
to 4.4. Is there anything else left to do?
As for
5. The changes to implement (1) and (2) should be backported to
earlier GCCs and ea
--- Comment #10 from manu at gcc dot gnu dot org 2008-02-25 23:42 ---
Subject: Bug 28322
Author: manu
Date: Mon Feb 25 23:41:43 2008
New Revision: 132648
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132648
Log:
2008-02-26 Manuel Lopez-Ibanez <[EMAIL PROTECTED]>
PR 2
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |sam at gcc dot gnu dot org
|dot org
--- Comment #7 from hjl dot tools at gmail dot com 2008-02-25 22:16 ---
It is a compiler bug after all. From:
http://groups.google.com/group/generic-abi/browse_thread/thread/4364eb484397ebe0
A hidden symbol must be defined in the same component, *if it is
defined at all*. That last p
--- Comment #4 from uweigand at gcc dot gnu dot org 2008-02-25 22:15
---
(In reply to comment #3)
> This problem has already been fixed for GCC 4.3 (#34641). The testcase from
> that PR didn't fail for GCC 4.2 so I didn't apply the patch on 4.2 as well.
> But
> now the patch should be
--- Comment #2 from xinliangli at gmail dot com 2008-02-25 21:36 ---
(In reply to comment #1)
> (In reply to comment #0)
> > It is beneficial to unroll reduction loop (and split the reduction target)
> > to
> > reduce dependence height due to recurrence, but GCC does not perform such
>
--- Comment #1 from pcarlini at suse dot de 2008-02-25 21:28 ---
Seems easy.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc
--- Comment #4 from tromey at gcc dot gnu dot org 2008-02-25 21:10 ---
Sorry for the delay on this.
I never remember our rules about when to emit pedantic warnings
and the like. I think libcpp should follow the overall gcc approach
here, whatever that is.
I agree that warning about tr
--- Comment #40 from jb at gcc dot gnu dot org 2008-02-25 20:47 ---
Updated version of the patch in #35 here:
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg01222.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35063
--- Comment #19 from joel at gcc dot gnu dot org 2008-02-25 20:45 ---
How early can I look at the task priority? Is it stored in some data structure
that I can see with objdump before the program is run?
I have yet to see anything in the debugger except 0 getting passed to task
creat
--- Comment #1 from bergner at gcc dot gnu dot org 2008-02-25 20:50 ---
Created an attachment (id=15231)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15231&action=view)
Patch to GCSE to copy REG_POINTER attribute over to new pseudos.
The culprit here is GCSE. When GCSE creates a
We fail to correctly order the operands for the indexed store within the loop
below. This seems to be caused by a missing REG_POINTER attribute, so the code
added for PR28690 doesn't have a chance of getting the ordering correct. An
interesting thing is that if we replace the global array with an "
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-02-25 19:49 ---
GCC is correct, f is a not a dependent name so it has to be looked up at
parsing time and not at instaintation time.
>or, if this is in fact not legal, perhaps a more specific diagnostic message
This is the best
--- Comment #5 from jb at gcc dot gnu dot org 2008-02-25 19:49 ---
Fixed on trunk; closing.
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
Status|U
--- Comment #1 from pcarlini at suse dot de 2008-02-25 19:47 ---
Yes it is. This change dates back to the 3.4 series:
http://gcc.gnu.org/gcc-3.4/changes.html
--
pcarlini at suse dot de changed:
What|Removed |Added
---
Please forgive me if in fact this is standards-compliant behavior.
Code:
template class B
{
protected:
int f;
};
template class D : public B
{
public:
void a() { this->f = 0; } // OK
void b() { f = 0; } // `f' was not declared in this scope
}
--- Comment #13 from jb at gcc dot gnu dot org 2008-02-25 19:28 ---
Subject: Bug 29549
Author: jb
Date: Mon Feb 25 19:27:28 2008
New Revision: 132638
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132638
Log:
2008-02-25 Janne Blomqvist <[EMAIL PROTECTED]>
PR fortran/2
--- Comment #6 from haubi at gentoo dot org 2008-02-25 19:24 ---
Created an attachment (id=15230)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15230&action=view)
valgrind output for cc1plus
This coverage_checksum_string() indeed has slightly changed from gcc-4.0-branch
to gcc-4.1
--- Comment #12 from jb at gcc dot gnu dot org 2008-02-25 19:21 ---
Subject: Bug 29549
Author: jb
Date: Mon Feb 25 19:20:48 2008
New Revision: 132636
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132636
Log:
2008-02-25 Janne Blomqvist <[EMAIL PROTECTED]>
PR fortran/2
--- Comment #5 from haubi at gentoo dot org 2008-02-25 19:17 ---
Similar problem here, with gcc-4.1.1:
This issue does not always end up in an ICE, but when using valgrind, some
"Invalid read of size 1" are consistently reported for cc1plus caused by
coverage_checksum_string():
$ cat g
--- Comment #4 from jb at gcc dot gnu dot org 2008-02-25 19:17 ---
Subject: Bug 35162
Author: jb
Date: Mon Feb 25 19:16:37 2008
New Revision: 132635
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132635
Log:
2008-02-25 Janne Blomqvist <[EMAIL PROTECTED]>
PR c/35162
--- Comment #22 from pinskia at gcc dot gnu dot org 2008-02-25 19:16
---
This is true even for -fPIC case. So in this case, the linker and the compiler
are saying two different things even though I do know for PPC darwin this is
always the case.
So maybe in the end this is a bug in th
--- Comment #21 from pinskia at gcc dot gnu dot org 2008-02-25 19:15
---
The real issue is that darwin's back-end says functions that are defined in the
TU are always binds local so they can be called directly.
So I guess a patch to darwin.c is needed.
--
pinskia at gcc dot gnu dot
--- Comment #3 from paolo at gcc dot gnu dot org 2008-02-25 19:05 ---
Subject: Bug 35338
Author: paolo
Date: Mon Feb 25 19:04:50 2008
New Revision: 132634
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132634
Log:
/cp
2008-02-25 Paolo Carlini <[EMAIL PROTECTED]>
PR c+
--- Comment #3 from paolo at gcc dot gnu dot org 2008-02-25 19:05 ---
Subject: Bug 35333
Author: paolo
Date: Mon Feb 25 19:04:50 2008
New Revision: 132634
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132634
Log:
/cp
2008-02-25 Paolo Carlini <[EMAIL PROTECTED]>
PR c+
--- Comment #6 from bugzilla-gcc at thewrittenword dot com 2008-02-25
18:55 ---
(In reply to comment #5)
> Patch looks ok to me (but I cannot approve it), can you please post it to
> gcc-patches for review?
>
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg01193.html
Thanks.
--
htt
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-02-25 18:54 ---
The IL after MEM_REF lowering looks like
bar ()
{
int D.1193;
unsigned int D.1192;
unsigned int D.1191;
unsigned int D.1190;
int D.1189;
D.1189 = MEM ;
D.1190 = (unsigned int) D.1189;
D.1191 = D.119
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-02-25 18:51 ---
With MEM_REF I get on i686
foo:
movla, %eax
pushl %ebp
movl%esp, %ebp
popl%ebp
andl$-33554240, %eax
orl $2074, %eax
movl%eax, a
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-02-25 18:49 ---
So, the same code should be generated for
union {
struct {
int b1: 3;
int b2: 3;
int b3: 2;
int b4: 17;
}a;
int b;
} a;
void foo()
{
a.a.b1 = 2;
a.a.b2 = 3;
a.a.b4 = 8;
}
void bar()
{
a.b = (a.b
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-02-25 18:44 ---
I would expect the equivalent of
int tmp = a;
tmp &= 0x0030; // fix the mask to be correct, all bits of b3
tmp |= 2 | 3 | 8; // constant folded and properly shifted
a = tmp;
I still see three ORs for ppc64
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-02-25 18:38 ---
This works correctly for PowerPC*.
PPC64 (with GCC 4.0.1):
lwz r0,0(r11)
rlwinm r0,r0,0,3,31
oris r0,r0,0x4000
and r0,r0,r9
oris r0,r0,0xc00
and r0,r0,r2
ori r0
--
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
Hello !
AS intructed by g++ itself, I'm sending you a bug report.
I tried to reduce the source file to the smallest file which triggers the bug.
Maybe one can make shorter but at least this file contains no '#include'
directive.
Session transcript:
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-02-25 18:21 ---
Related to PR 13761 also.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35358
--- Comment #3 from steigers at phys dot ethz dot ch 2008-02-25 18:20
---
(In reply to comment #2)
> What is the ICE?
>
Segmentation fault.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 84cf8bc685ded1e544606791a260313c
ice.h: In
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-02-25 18:16 ---
What is the ICE?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component
--
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 #3 from pcarlini at suse dot de 2008-02-25 18:10 ---
Eh! I think we should only double check that tests creating / writing files use
unique names...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33612
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-02-25 18:03 ---
*** Bug 35359 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-02-25 18:03 ---
*** This bug has been marked as a duplicate of 23086 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from baraclese at googlemail dot com 2008-02-25 17:35
---
I'm changing the resolution to invalid, but maybe you want to up the
requirements on the mpfr version number and bail out if it's too low.
--
baraclese at googlemail dot com changed:
What|Remove
--- Comment #2 from bkoz at gcc dot gnu dot org 2008-02-25 17:28 ---
Jason has suggested a good idea to fix this without messing about with test
harness issues.
We can just split
make check
up into
make check1
make check2
make check3
make check4
make check5
make check6
...
where
--- Comment #2 from xinliangli at gmail dot com 2008-02-25 17:24 ---
(In reply to comment #1)
> We think q may now point to local as that escapes through bar.
>
And that is why it is conservative.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35359
--- Comment #2 from pcarlini at suse dot de 2008-02-25 17:18 ---
Also simple.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc
--- Comment #56 from howarth at nitro dot med dot uc dot edu 2008-02-25
17:09 ---
My bad...
newname = ACONCAT ("_", IDENTIFIER_POINTER (sym), "$LDBL128", NULL);
needs to be...
newname = ACONCAT (("_", IDENTIFIER_POINTER (sym), "$LDBL128", NULL));
...otherwise you get the followi
--- Comment #2 from pcarlini at suse dot de 2008-02-25 17:03 ---
Seems simple.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gc
--- Comment #4 from matz at gcc dot gnu dot org 2008-02-25 16:18 ---
For me it works with gcc42-4.2.1_20070724-17.1 (i686). With 4.3 it breaks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35368
--- Comment #11 from benny at ammitzboell-consult dot dk 2008-02-25 16:02
---
(In reply to comment #10)
> At first this looks like a target issue. Can you check if a still maintained
> GCC version is still affected? That would be 4.2.3 for example.
>
Since print-rtl.c in 4.2.3 still
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-02-25 15:54 ---
Doens't work for me with 4.1.3 20080114, 4.2.3 or 4.3.0 20080219. Works with
4.0.4 20060904.
The bogus reference is here:
.LEFDE5:
.hidden DW.ref.__gxx_personality_v0
.weak DW.ref.__gxx_personali
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-02-25 15:43
---
At first this looks like a target issue. Can you check if a still maintained
GCC version is still affected? That would be 4.2.3 for example.
--
rguenth at gcc dot gnu dot org changed:
What|Rem
--- Comment #2 from benjamin at smedbergs dot us 2008-02-25 15:33 ---
Coworker reports the testcase works correctly on gcc4.2.1 also.
--
benjamin at smedbergs dot us changed:
What|Removed |Added
-
--- Comment #55 from dominiq at lps dot ens dot fr 2008-02-25 15:25 ---
In reply to comment #54:
>does the patch work OK on ppc-darwin?
I don't have the time to do the test right now. I'll try tonight.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
--- Comment #1 from benjamin at smedbergs dot us 2008-02-25 15:17 ---
Created an attachment (id=15229)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15229&action=view)
Minimized testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35368
Testcase attached: when a class is declared with #pragma visibility hidden on,
references to `vtable for __cxxabiv1::__class_type_info' are emitted with
relocations that assume hidden visibility. This is incorrect, and is a
regression against 4.1 and I think 4.2.
To reproduce, compile the testcase
--- Comment #54 from ubizjak at gmail dot com 2008-02-25 15:10 ---
(In reply to comment #51)
> In the patch from comment #50
>
> s/+#esle/+#else/
Ops.
So, with this fixlet, does the patch work OK on ppc-darwin, so I can post it to
gcc-patches@ (Yes, I'll write a ChangeLog ;) ?
--
--- Comment #6 from krebbel at gcc dot gnu dot org 2008-02-25 15:08 ---
Subject: Bug 35258
Author: krebbel
Date: Mon Feb 25 15:07:17 2008
New Revision: 132628
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132628
Log:
2008-02-25 Andreas Krebbel <[EMAIL PROTECTED]>
PR
--- Comment #9 from benny at ammitzboell-consult dot dk 2008-02-25 14:31
---
(In reply to comment #2)
> As when you say bigger do you mean the assembly is different sizes? Or do you
> mean the actually text/data sections are bigger in the object file?
>
The assembly is bigger on the
--- Comment #8 from benny at ammitzboell-consult dot dk 2008-02-25 14:27
---
Added test program and RTL output from 32-bit host and 64-bit host. Note the
difference in the const_int lines:
[EMAIL PROTECTED]:~/src/kuss$ diff /home/bla/Desktop/main.c.01.rtl
/home/bla/Desktop/main.c.01.rt
--- Comment #7 from benny at ammitzboell-consult dot dk 2008-02-25 14:22
---
Created an attachment (id=15228)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15228&action=view)
Output from arm-gcc -c -dM main.c (64-bit host)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35295
--- Comment #6 from benny at ammitzboell-consult dot dk 2008-02-25 14:21
---
Created an attachment (id=15227)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15227&action=view)
Output from arm-gcc -c -dr main.c (64-bit host)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35295
--- Comment #11 from pcarlini at suse dot de 2008-02-25 14:18 ---
About my last reply: I checked, and within the current implementation of the
underlying I/O the last issue (per libstdc++/9662) doesn't exist anymore, in
other terms, when sync_with_stdio(false), C++ I/O on wcin/wcout does
--- Comment #5 from benny at ammitzboell-consult dot dk 2008-02-25 14:14
---
Created an attachment (id=15226)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15226&action=view)
Output from arm-gcc -c -dM main.c (32-bit host)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35295
--- Comment #4 from benny at ammitzboell-consult dot dk 2008-02-25 14:13
---
Created an attachment (id=15225)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15225&action=view)
Output from arm-gcc -c -dr main.c (32-bit host)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35295
--- Comment #16 from dir at lanl dot gov 2008-02-25 14:12 ---
It does not crash any more with my latest version -
[dranta:~/fe/dyna3d96/source] dir% gfortran --v
Using built-in specs.
Target: powerpc-apple-darwin9.1.0
Configured with: ../gcc/configure --disable-bootstrap --enable-mul
--- Comment #3 from benny at ammitzboell-consult dot dk 2008-02-25 14:09
---
Created an attachment (id=15224)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15224&action=view)
Test program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35295
configured by ../../../src/gcc/configure, generated by GNU Autoconf 2.59,
with options " '-v' '--prefix=/opt/experimental' '--enable-shared'
'--with-system-zlib' '--enable-threads=posix' '--enable-nls'
'--enable-clocale=gnu' '--enable-libstdcxx-debug' '--enable-libffi'
'--enable-objc-gc' '--enabl
--- Comment #31 from dominiq at lps dot ens dot fr 2008-02-25 13:46 ---
Subject: Re: [4.3/4.4 regression] HUGE(1.0_16) output
as +Infinity on ppc-darwin8 (gfortran.dg/large_real_kind_2.F90)
Answer to comment #30:
> a compiler configured on powerpc-apple-darwin9 but
> run on powerpc-a
The test case fortran.dg/equiv_7.f90 fails with -m64 -Os on
powerpc-apple-darwin9. I have reduced the code to:
call derived_types ! Thanks to Tobias Burnus for this:)
print *, d1mach (1), transfer ((/0_4, 1048576_4/), 1d0)
if (d1mach (1) .ne. transfer ((/0_4, 1048576_4/), 1d0)) call
--- Comment #10 from pcarlini at suse dot de 2008-02-25 13:11 ---
Note, anyway, that there is a serious blocker to any enhancement in this area
(and of course it explains the current behavior): if wcin & co are converting,
they deal with the underlying stream as a narrow-character orient
--- Comment #53 from fxcoudert at gcc dot gnu dot org 2008-02-25 13:03
---
(In reply to comment #52)
> The test case gfortran.dg/large_real_kind_3.F90 fails on powerpc-apple-darwin9
> because it is xfailed for freebsd and not for darwin
Oops, sorry, fixed by rev. 132621.
--
http:/
--- Comment #52 from dominiq at lps dot ens dot fr 2008-02-25 12:57 ---
The test case gfortran.dg/large_real_kind_3.F90 fails on powerpc-apple-darwin9
because it is xfailed for freebsd and not for darwin:
! { dg-xfail-if "" { "*-*-freebsd*" } { "*" } { "" } }
--
http://gcc.gnu.org
--- Comment #51 from dominiq at lps dot ens dot fr 2008-02-25 12:45 ---
In the patch from comment #50
s/+#esle/+#else/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|NEW |SUSPENDED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35353
--- Comment #9 from pcarlini at suse dot de 2008-02-25 12:44 ---
Maybe we can improve the behavior when the stdio is synced, that is we can
transcode each wchar_t and sync after each transcoding. Very likely, you can
also simulate that behavior right now by using sync_with_stdio(false) +
--- Comment #1 from tim dot vanholder at anubex dot com 2008-02-25 12:37
---
Created an attachment (id=15223)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15223&action=view)
Trivial Patch
Encountered this same problem today on the 4.3 branch (rev 132620).
This is a trivial patc
--- Comment #2 from bje at gcc dot gnu dot org 2008-02-25 12:16 ---
Fixed.
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from ivranos at freemail dot gr 2008-02-25 12:12 ---
Summary of the case:
What doesn't work:
#include
#include
#include
int main()
{
using namespace std;
wcin.imbue(locale("greek"));
wcout.imbue(locale("greek"));
wstring ws;
wcin>> ws;
--- Comment #3 from ubizjak at gmail dot com 2008-02-25 12:10 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2008-02-25 12:08
---
(In reply to comment #3)
> Now, with all three patches, we can compile the testcase and run it fine.
The three patches, together, regtest fine on x86_64-linux (both -m32 and -m64).
--
http://gcc.gnu.org/bugz
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-
|
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-
|
--- Comment #7 from ivranos at freemail dot gr 2008-02-25 12:02 ---
I am sorry for insisting on this, but I think there is an issue, and I want the
best for GCC. So please have a look at the messages of this link:
http://tinyurl.com/384u3n and use Unicode (UTF-8) character encoding in y
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rakdver at gcc dot gnu dot
|
--- Comment #1 from bje at gcc dot gnu dot org 2008-02-25 11:51 ---
Subject: Bug 32948
Author: bje
Date: Mon Feb 25 11:50:17 2008
New Revision: 132618
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132618
Log:
fixincludes/
PR other/32948
* fixincl.c (fix_applies)
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-25 11:48 ---
What is the expected optimization and what is its benefit?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-25 11:47 ---
Similar to the missing base/offset bug, PR35360.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-25 11:44 ---
Confirmed. MEM_REF might help here as we'd get
off_1 = IDX <0 + i * 8>
MEM_REF
and
off_2 = IDX <4 + j * 8>
MEM_REF
where the alias-oracle should be able to see that the accesses cannot overlap.
--
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-25 11:41 ---
We think q may now point to local as that escapes through bar.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from uros at gcc dot gnu dot org 2008-02-25 11:40 ---
Subject: Bug 19984
Author: uros
Date: Mon Feb 25 11:39:15 2008
New Revision: 132617
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132617
Log:
PR middle-end/19984
* builtins.def (BUILT_IN_NAN):
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-25 11:39 ---
It looks like this needs IPA DCE/DSE.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-25 11:37 ---
I bet there is a duplicate report for this. Also see various GCC summit papers
on switch expansion.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-25 11:36 ---
(please make our work easier and make the initial reports Severity enhancement
and add missed-optimization as a Keyword and make the report against a
gcc version, preferably 4.3.0 or 4.4.0; testcases ready for inclu
--- Comment #50 from ubizjak at gmail dot com 2008-02-25 11:29 ---
Created an attachment (id=15222)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15222&action=view)
Addendum to the ldouble patch
Can someone regression test this patch on PPC darwin?
There are following changes:
-
I build the DBD::mysql Perl module under HP-UX 11.11 on an RP3440 machine with
GCC 4.2.1. The link looked like this:
LD_RUN_PATH="/usr/local/mysql/lib" /opt/perl_64/bin/perl myld gcc -shared
-static-libgcc -fPIC -L/lib/pa20_64 dbdimp.o mysql.o -o
blib/arch/auto/DBD/mysql/mysql.sl -L/usr/local/mysq
--- Comment #1 from steigers at phys dot ethz dot ch 2008-02-25 10:35
---
Created an attachment (id=15221)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15221&action=view)
Preprocessed file (.ii)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35364
1 - 100 of 106 matches
Mail list logo
