--- Comment #3 from steven at gcc dot gnu dot org 2009-03-17 07:20 ---
Copying a pseudo to the required register before an __asm__ is not so easy,
because at expand time the data flow engine doesn't know anything, it's not
even initialized.
What you could do, I suppose in cfgexpand.c
*
When a template is instantiated and the instantiation requires access to the
instantiated template, the error message is not as helpful as it could/should
be. Consider:
f...@viasko:~/work/test/recursive_instantiation$ cat t.cc
template< typename T >
struct foo
{
typename T::type dummy();
};
tem
--- Comment #5 from d dot frey at gmx dot de 2009-03-17 07:30 ---
(In reply to comment #4)
> Maybe Daniel, but this is a completely separate issue.
That's why I asked if I should open yet another PR for it :) I've done that
now: PR c++/39478
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #3 from jakub at gcc dot gnu dot org 2009-03-17 07:46 ---
Created an attachment (id=17471)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17471&action=view)
gcc44-pr39471.patch
So this patch instead? C++ will never need non-NULL DECL_NAME on
IMPORTED_DECL,
as it doesn'
--- Comment #4 from dodji at gcc dot gnu dot org 2009-03-17 07:54 ---
Subject: Re: DW_TAG_imported_module should be used (not
DW_TAG_imported_declaration)
jakub at gcc dot gnu dot org a écrit :
> --- Comment #1 from jakub at gcc dot gnu dot org 2009-03-16 20:55 ---
> Created
--- Comment #5 from dodji at gcc dot gnu dot org 2009-03-17 07:59 ---
Subject: Re: DW_TAG_imported_module should be used (not
DW_TAG_imported_declaration)
jakub at gcc dot gnu dot org a écrit :
> So this patch instead? C++ will never need non-NULL DECL_NAME on
> IMPORTED_DECL,
> as
--- Comment #6 from dodji at gcc dot gnu dot org 2009-03-17 08:08 ---
Subject: Re: DW_TAG_imported_module should be used (not
DW_TAG_imported_declaration)
dodji at redhat dot com a écrit :
> Hmmh, I think the non null name there is useful for namespace aliases in
> C++
Ah, no. We wo
--- Comment #3 from basile at starynkevitch dot net 2009-03-17 08:18
---
I replaced lrand48_r by lrand48...
Regarding fopencookie, it could be fixed
1. by using next PPL (0.11) version
or
2. by linking some specific PPL file
(ppl/interfaces/C/tests/print_to_buffer.cc)
Regards
--
--- Comment #7 from pault at gcc dot gnu dot org 2009-03-17 08:31 ---
This fixes the PR:
Index: gcc/fortran/trans-stmt.c
===
--- gcc/fortran/trans-stmt.c(revision 144197)
+++ gcc/fortran/trans-stmt.c(working copy)
@
--- Comment #7 from jakub at gcc dot gnu dot org 2009-03-17 08:52 ---
Created an attachment (id=17472)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17472&action=view)
gcc44-local-imported-decl.patch
Incremental patch to emit DW_TAG_imported_declaration DIEs (other than
namespace
--- Comment #1 from ktietz at gcc dot gnu dot org 2009-03-17 09:43 ---
This feature would be fine. But at the moment we are in Stage 4. So it can be
implemented on 4.5 and then after 4.4 is reopened merged back.
Cheers,
Kai
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39472
--- Comment #2 from jakub at gcc dot gnu dot org 2009-03-17 09:36 ---
Created an attachment (id=17474)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17474&action=view)
gcc44-pr39474.patch
I disagree. IMHO there is no reason why we should optimize these out at -O0.
We don't optimi
--- Comment #1 from jakub at gcc dot gnu dot org 2009-03-17 09:45 ---
Just learn C. strlen return type is size_t, unsigned type, so in the third
case you have (assuming size_t is say unsigned long) i <= 0UL - 1, unsigned
long comparison, which is evaluated as (unsigned long) i <= -1UL,
I've found an strange behaviour with stdio.strlen() function.
Please, see following self-explaining code:
/*
$ gcc --version
gcc (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu3)
$ uname -a
Linux alumne-desktop 2.6.24-23-generic #1 SMP Mon Jan 26 00:13:11 UTC 2009 i686
GNU/Linux
*/
#include
#include
#define
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-03-17 09:39 ---
(In reply to comment #1)
> It is
> if (TARGET_64BIT)
> {
> if (ix86_function_type_abi (type) == DEFAULT_ABI)
> return regparm;
> return DEFAULT_ABI != SYSV_ABI ? X86_64_REGPARM_MAX : X64_REGPA
--- Comment #9 from jan dot kratochvil at redhat dot com 2009-03-17 10:05
---
I no longer see any DWARF problem there but Archer C++ still does not work with
g++-4.4. Assuming an Archer bug due to the new DW_TAG_lexical_block block.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
--- Comment #28 from jakub at gcc dot gnu dot org 2009-03-17 10:42 ---
Better just do that with the latest trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355
--- Comment #8 from dodji at gcc dot gnu dot org 2009-03-17 10:02 ---
Subject: Re: DW_TAG_imported_module should be used (not
DW_TAG_imported_declaration)
jakub at gcc dot gnu dot org a écrit :
> --- Comment #7 from jakub at gcc dot gnu dot org 2009-03-17 08:52 ---
> Created
--- Comment #3 from jan dot kratochvil at redhat dot com 2009-03-17 10:03
---
It works for the gdb.python/python-template.exp test, thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39474
--- Comment #2 from jakub at gcc dot gnu dot org 2009-03-17 09:19 ---
Created an attachment (id=17473)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17473&action=view)
gcc44-pr37890.patch
Ah, it actually is emitted in the correct lexical block, but in addition to
that it is emitte
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-17 10:59 ---
calling memcpy with exactly overlapping operands is safe (obviously). Thus
this is a bug in valgrind.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from fpbeekhof at gmail dot com 2009-03-17 11:13 ---
Subject: Re: generated memcpy causes trouble in assignment
rguenth at gcc dot gnu dot org wrote:
> --- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-17 10:59
> ---
> calling memcpy with exactly ove
--- Comment #4 from fpbeekhof at gmail dot com 2009-03-17 11:15 ---
Subject: Re: generated memcpy causes trouble in assignment
paolo dot carlini at oracle dot com wrote:
> --- Comment #2 from paolo dot carlini at oracle dot com 2009-03-17 11:04
> ---
> by the way, I cannot
--- Comment #5 from paolo dot carlini at oracle dot com 2009-03-17 11:28
---
By the way, I don't see what could be possibly wrong in libstdc++: can you
please tell us which specific line of code you are suspecting? Certainly, not
the entire swap implementation, which is definitely the c
--- Comment #5 from rearnsha at gcc dot gnu dot org 2009-03-17 11:41
---
This isn't something that should be fixed in the back-end, but most likely an
enhancement to a pass such as ifcvt. To handle this case we would have to
teach ifcvt about dominated conditions and conditional compar
--- Comment #2 from paolo dot carlini at oracle dot com 2009-03-17 11:04
---
by the way, I cannot reproduce it with valgrind 3.3.1 and either mainline or
current 4_3-branch or 4_2-branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480
--- Comment #17 from rguenth at gcc dot gnu dot org 2009-03-17 11:05
---
Created an attachment (id=17476)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17476&action=view)
the other testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
--- Comment #6 from rearnsha at gcc dot gnu dot org 2009-03-17 11:02
---
Created an attachment (id=17475)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17475&action=view)
Proposed fix -- will commit after trunk reopens
--
rearnsha at gcc dot gnu dot org changed:
Wh
The following code is unsafe, and I think it's not my fault.
$ g++ -Wall -g testIterSwap.cc ; valgrind -q ./a.out
==1674== Source and destination overlap in memcpy(0x7FF000500, 0x7FF000500, 20)
==1674==at 0x4C2508B: memcpy (mc_replace_strmem.c:402)
==1674==by 0x4008D2: void swap_from_glib
--- Comment #7 from rearnsha at gcc dot gnu dot org 2009-03-17 11:19
---
(In reply to comment #6)
> foo:
> mov r3, r0
> cmn r1, r0
> rsbeq r0, r1, r0
> rsbne r0, r3, r1
> bx lr
This appears to be the code generated at -O1 and alt
--- Comment #6 from falk at debian dot org 2009-03-17 12:10 ---
(In reply to comment #1)
> calling memcpy with exactly overlapping operands is safe (obviously).
It's not safe at all. A memcpy implementation might use a "prefetch with write
intent" instruction that allocates a cache line
--- Comment #7 from fpbeekhof at gmail dot com 2009-03-17 12:21 ---
Subject: Re: generated memcpy causes trouble in assignment
paolo dot carlini at oracle dot com wrote:
> --- Comment #5 from paolo dot carlini at oracle dot com 2009-03-17 11:28
> ---
> By the way, I don't s
--- Comment #10 from jan dot kratochvil at redhat dot com 2009-03-17 12:24
---
ICE: Comment 7 patch (applied together with the Comment 3 patch) on:
namespace A
{
class B
{
};
};
extern void g ();
vo
--- Comment #11 from jakub at gcc dot gnu dot org 2009-03-17 12:28 ---
Created an attachment (id=17477)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17477&action=view)
gcc44-local-imported-decl.patch
Yeah, I know, found that out already during my regtest. Here is what I'm
bootst
--- Comment #8 from paolo dot carlini at oracle dot com 2009-03-17 12:33
---
Yes, if there is a bug, certainly it is not in libstdc++. Also, please find
somebody able to reproduce it, I can't.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480
Test program:
*import java.util.StringTokenizer;
public class gcjbug {
public static void main(String[] args) {
StringTokenizer t = new StringTokenizer("#a=1 #b=2");
for (int i = 0; i < 2; i++) {
if (t.hasMoreTokens())
System.out.println(t.nextToken
--- Comment #18 from rguenth at gcc dot gnu dot org 2009-03-17 12:42
---
Vlad, for the second testcase I see
-O0:
expand: 0.78 (19%) usr 0.04 ( 5%) sys 0.83 (16%) wall
44335 kB (49%) ggc
integrated RA : 1.05 (25%) usr 0.03 ( 4%) sys 1.13 (22%) w
--- Comment #1 from receive-spam at yandex dot ru 2009-03-17 12:42 ---
Oops, asterisk before "import" should be removed
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39481
--- Comment #6 from hjl at gcc dot gnu dot org 2009-03-17 12:51 ---
Subject: Bug 39473
Author: hjl
Date: Tue Mar 17 12:50:52 2009
New Revision: 144901
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144901
Log:
2009-03-16 H.J. Lu
PR target/39473
* config/i386/
--- Comment #7 from hjl dot tools at gmail dot com 2009-03-17 12:52 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #4 from paolo dot carlini at oracle dot com 2009-03-17 12:55
---
Jason, are you willing to help triaging this one?
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #5 from hjl at gcc dot gnu dot org 2009-03-17 12:55 ---
Subject: Bug 39476
Author: hjl
Date: Tue Mar 17 12:55:18 2009
New Revision: 144902
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144902
Log:
2009-03-17 H.J. Lu
PR target/39476
* config/i386/
--- Comment #5 from paolo dot carlini at oracle dot com 2009-03-17 12:55
---
Sorry, CC-ed Jakub instead of Jason ;)
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #6 from hjl dot tools at gmail dot com 2009-03-17 12:57 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #19 from rguenth at gcc dot gnu dot org 2009-03-17 12:58
---
For trunk -O1 I see
CPU: AMD64 processors, speed 1000 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask
of 0x00 (No unit mask) count 10
samples %symbol na
--- Comment #2 from hjl dot tools at gmail dot com 2009-03-17 12:59 ---
The patch is at
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00759.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #20 from rguenth at gcc dot gnu dot org 2009-03-17 13:09
---
Btw, it looks like internal IRA data-structures can be shrinked on 64bit
platforms by avoiding padding between pointer and integer members a lot.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
--- Comment #3 from hjl at gcc dot gnu dot org 2009-03-17 13:10 ---
Subject: Bug 39477
Author: hjl
Date: Tue Mar 17 13:10:24 2009
New Revision: 144903
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144903
Log:
2009-03-17 H.J. Lu
PR target/39477
* doc/extend.t
--- Comment #9 from fpbeekhof at gmail dot com 2009-03-17 13:11 ---
Subject: Re: generated memcpy causes trouble in assignment
paolo dot carlini at oracle dot com wrote:
> --- Comment #8 from paolo dot carlini at oracle dot com 2009-03-17 12:33
> ---
> Yes, if there is a bu
--- Comment #4 from hjl at gcc dot gnu dot org 2009-03-17 13:12 ---
Subject: Bug 39477
Author: hjl
Date: Tue Mar 17 13:11:58 2009
New Revision: 144904
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144904
Log:
2009-03-17 H.J. Lu
Backport from mainline:
2009-0
--- Comment #5 from hjl dot tools at gmail dot com 2009-03-17 13:12 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #11 from fpbeekhof at gmail dot com 2009-03-17 13:19 ---
Subject: Re: generated memcpy causes trouble in assignment
paolo dot carlini at oracle dot com wrote:
> --- Comment #10 from paolo dot carlini at oracle dot com 2009-03-17
> 13:15 ---
> The component would
--- Comment #10 from paolo dot carlini at oracle dot com 2009-03-17 13:15
---
The component would be c++, because that is a C++ thing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480
--- Comment #12 from paolo dot carlini at oracle dot com 2009-03-17 13:25
---
Apparently, mainline and 4_3-branch do not call memcpy, expand the operator
inline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480
--- Comment #13 from paolo dot carlini at oracle dot com 2009-03-17 13:26
---
If it affects only 4_2-branch would be zero, because it's no longer maintained
;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480
--- Comment #14 from fpbeekhof at gmail dot com 2009-03-17 13:28 ---
Subject: Re: generated memcpy causes trouble in assignment
paolo dot carlini at oracle dot com wrote:
> --- Comment #13 from paolo dot carlini at oracle dot com 2009-03-17
> 13:26 ---
> If it affects only
--- Comment #15 from paolo dot carlini at oracle dot com 2009-03-17 13:32
---
To be clear, I'm not sure this is invalid, I agree with you that we should
understand the issue in better detail. I'll make sure we do the additional
investigation.
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #3 from irar at il dot ibm dot com 2009-03-17 13:33 ---
(In reply to comment #2)
> Or like the following, which is just a bunch of reductions of two elements
> float data[1024];
> void foo(void)
> {
> int i;
> for (i = 1; i < 1024; ++i)
> data[i] = data[i] + data[i-1]
--- Comment #16 from paolo dot carlini at oracle dot com 2009-03-17 13:34
---
Correction: technically 4_2-branch is still open, but no further releases are
expected and will be definitely closed as soon as the 4_4-branch is created
(very soon)
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #17 from paolo dot carlini at oracle dot com 2009-03-17 13:35
---
Jason, could you maybe double check this one too?
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #4 from rearnsha at gcc dot gnu dot org 2009-03-17 13:46
---
Cold case analysis time. Have you seen this problem in recent releases of GCC?
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from joel at gcc dot gnu dot org 2009-03-17 14:02 ---
Yes.
See http://gcc.gnu.org/ml/gcc-testresults/2009-03/msg00362.html.
We also cross post them to an RTEMS tool list and apparently the run on 12
March
resulted in a log that was too large for gcc-testresults.
htt
--- Comment #7 from js-gcc at webkeks dot org 2009-03-17 14:05 ---
> Since I wasn't able to get a cross tool chain running (and www.mingw.org
> doesn't seem to support that with the current gcc versions)
Please have a look at the Portfiles I gave you a link to, they include all the
stuf
--- Comment #18 from ramana dot r at gmail dot com 2009-03-17 14:27 ---
This commit here
http://gcc.gnu.org/viewcvs?view=rev&revision=143942 which is essentially a
backport of the patch http://gcc.gnu.org/viewcvs?view=rev&revision=137235 . If
this fixes the problem, then the bug can be
--- Comment #3 from sam at gcc dot gnu dot org 2009-03-17 14:28 ---
This is not a bug. The compiler really has no way to distinguish between the
following two interpretations for "Put (Get_Name (7))":
1- Get_Name (7) is a call to Get_Name with argument 7, which returns a String
2- G
--- Comment #2 from ramana dot r at gmail dot com 2009-03-17 14:40 ---
This appears to be fixed on mainline on gcc version 4.4.0 20090317
(experimental) (GCC).
output obtained
42 69 105
42 69 105
--
ramana dot r at gmail dot com changed:
What|Removed
--- Comment #12 from swagiaal at redhat dot com 2009-03-17 15:17 ---
(In reply to comment #9)
> I no longer see any DWARF problem there but Archer C++ still does not work
> with
> g++-4.4. Assuming an Archer bug due to the new DW_TAG_lexical_block block.
>
Yes there are a couple I am
extern double log (double __x);
double foo(unsigned long int m_liOutputBufferLen)
{
return log((double)m_liOutputBufferLen);
}
ICEs with -mno-sse2
./cc1 -quiet t.i -mno-sse2
t.i: In function 'foo':
t.i:5: internal compiler error: in inline_secondary_memory_needed, at
config/i386/i386.c:25478
Pl
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.3.3 4.4.0
Known to work||4.2.4
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-17 15:26 ---
Actually it seems the problem is the combination of int -> float conversion
and a call. Either alone doesn't trigger the bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39482
This is a "blocker" but I only set the "Severity" to "major" since I
used a non-default configure option, _and_ I have the patch included.
Configuring with "--with-gc=zone" fails due to a coding error in ggc-zone.c .
Apply the patch to fix this. If the patch is OK, remove comment lines "/* */".
--- Comment #2 from ubizjak at gmail dot com 2009-03-17 15:43 ---
See the third paragraph of the preceding comment to
inline_secondary_memory_needed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39482
--- Comment #1 from rob1weld at aol dot com 2009-03-17 15:45 ---
Created an attachment (id=17478)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17478&action=view)
Patch ggc-zone.c to support ggc_collect_1()'s call to
ggc_mark_roots_extra_marking()
--
http://gcc.gnu.org/bugzill
--- Comment #3 from ubizjak at gmail dot com 2009-03-17 15:51 ---
(In reply to comment #2)
> See the third paragraph of the preceding comment to
> inline_secondary_memory_needed.
Oh, well. trunc* patterns violate this rule.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39482
--- Comment #2 from basile at starynkevitch dot net 2009-03-17 15:57
---
Thanks. Patch commited as rev 144905 of MELT branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39483
--
ubizjak at gmail dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com
|dot org |
Compiling melt-branch revision 144904 with gcc 4.4.0 (Trunk),
4.3, or 4.1 results in a Segmentation fault in the modded 'cc1'
basilys_extra_marking() function.
Here is the "regular output" of where it fails:
Compiling ../../melt-branch/gcc/warmelt-outobj-0.c with -g
-fkeep-inline-functions -DIN_G
--- Comment #1 from basile at starynkevitch dot net 2009-03-17 16:39
---
Bug confirmed.
The bug seems to appear on x86 (not amd64) when configure-ing with
--prefix=/usr/
A very temporary workaround could be to configure with --prefix=/usr/local/
--
http://gcc.gnu.org/bugzilla/sho
--- Comment #4 from leo at marco dot de 2009-03-17 16:47 ---
Subject: Re: gcc generates incorrect trampoline code in
thumb mode
laurent at guerby dot net wrote:
> --- Comment #3 from laurent at guerby dot net 2009-01-02 12:29 ---
> This needs a testcase
>
>
Testcase:
void
--- Comment #3 from hp at gcc dot gnu dot org 2009-03-17 17:13 ---
(In reply to comment #2)
> Is there anything I can do to help with this?
If you could bisect the behaviour to a svn revision range, that might give a
clue.
See the description of the aforementioned bug (where it's unfort
--- Comment #4 from joel at gcc dot gnu dot org 2009-03-17 17:32 ---
Going back through the old run logs. Is this how it shows up?
FAIL: gcc.c-torture/execute/built-in-setjmp.c execution, -O0
FAIL: gcc.c-torture/execute/built-in-setjmp.c execution, -O1
FAIL: gcc.c-torture/execute/b
--- Comment #2 from hjl dot tools at gmail dot com 2009-03-17 17:35 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00797.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #6 from janis at gcc dot gnu dot org 2009-03-17 17:36 ---
Subject: Bug 38526
Author: janis
Date: Tue Mar 17 17:35:55 2009
New Revision: 144908
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144908
Log:
gcc/
PR testsuite/38526
* Makefile.in (site.exp):
--- Comment #3 from jakub at gcc dot gnu dot org 2009-03-17 17:42 ---
Is it really so hard to change UEFI apps?
The thing is that by adding the -mabi= option you pessimize x86_64 gcc even
more than the attribute patches have done. Now at least DEFAULT_ABI ==
SYSV_ABI
or DEFAULT_ABI != S
--- Comment #6 from jakub at gcc dot gnu dot org 2009-03-17 17:44 ---
Subject: Bug 39412
Author: jakub
Date: Tue Mar 17 17:43:52 2009
New Revision: 144909
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144909
Log:
PR debug/39412
* dwarf2out.c (gen_inlined_enumera
--- Comment #2 from jakub at gcc dot gnu dot org 2009-03-17 17:46 ---
Subject: Bug 39443
Author: jakub
Date: Tue Mar 17 17:46:23 2009
New Revision: 144910
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144910
Log:
PR middle-end/39443
* optabs.c (set_user_assemble
--- Comment #2 from rob1weld at aol dot com 2009-03-17 17:48 ---
Created an attachment (id=17479)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17479&action=view)
A patch to ignore NULL "*mi->iniframp" from VEC_iterate() - shortcuts the issue
I am very unfamiliar with this branch
--- Comment #13 from jakub at gcc dot gnu dot org 2009-03-17 17:49 ---
Subject: Bug 39471
Author: jakub
Date: Tue Mar 17 17:49:28 2009
New Revision: 144911
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144911
Log:
PR debug/39471
* dwarf2out.c (dwarf2out_imported
--- Comment #3 from jakub at gcc dot gnu dot org 2009-03-17 17:52 ---
Subject: Bug 37890
Author: jakub
Date: Tue Mar 17 17:52:08 2009
New Revision: 144913
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144913
Log:
PR debug/37890
* name-lookup.c (do_namespace_alia
--- Comment #4 from jakub at gcc dot gnu dot org 2009-03-17 17:53 ---
Subject: Bug 39474
Author: jakub
Date: Tue Mar 17 17:53:01 2009
New Revision: 144914
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144914
Log:
PR debug/39474
* tree-ssa-live.c (remove_unused_l
--- Comment #7 from jakub at gcc dot gnu dot org 2009-03-17 17:55 ---
Fixed on the trunk so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known t
--- Comment #3 from jakub at gcc dot gnu dot org 2009-03-17 17:55 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #14 from jakub at gcc dot gnu dot org 2009-03-17 17:56 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from jakub at gcc dot gnu dot org 2009-03-17 17:56 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|
--- Comment #5 from jakub at gcc dot gnu dot org 2009-03-17 17:57 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from uros at gcc dot gnu dot org 2009-03-17 18:55 ---
Subject: Bug 39482
Author: uros
Date: Tue Mar 17 18:55:40 2009
New Revision: 144915
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144915
Log:
PR target/39482
* config/i386/i386.md (*truncdfsf_m
--- Comment #5 from ubizjak at gmail dot com 2009-03-17 18:58 ---
Fixed in trunk.
--
ubizjak at gmail dot com changed:
What|Removed |Added
URL|
--- Comment #3 from basile at starynkevitch dot net 2009-03-17 19:07
---
I applied a slightly simplified variant of melt-patch-2.patch above as
rev144917
Thanks Rob. It probably works!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39484
--- Comment #4 from hjl dot tools at gmail dot com 2009-03-17 19:17 ---
(In reply to comment #3)
> Is it really so hard to change UEFI apps?
You can take a look at testcases in gcc.target/x86_64/abi/callabi.
They have to use macros, like
---
static
void CALLABI_CROSS do_cpy (char *s, .
--- Comment #5 from hjl dot tools at gmail dot com 2009-03-17 19:46 ---
The updated patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00815.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
1 - 100 of 125 matches
Mail list logo
