>From http://embed.cs.utah.edu/embarrassing/dec_09/harvest/gcc-head_icc-11.1/
typedef unsigned int size_t;
typedef __builtin_va_list __gnuc_va_list;
typedef __gnuc_va_list va_list;
typedef size_t STRLEN;
struct sv;
typedef struct sv SV;
typedef int I32;
typedef unsigned int U32;
struct sv
{
void
--- Comment #17 from andi-gcc at firstfloor dot org 2010-01-03 08:12
---
Nope, the examples all disable frame pointer
(the first version of the tester had this problem, but that was fixed)
It's all not frame pointer set up anyways, but sub $...,%esp ... ; add
$...,%esp
with no use of t
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-03 10:58 ---
Confirmed.
The bswap detection does not work on memory at all but only detects it
on registers.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from rguenth at gcc dot gnu dot org 2010-01-03 11:11
---
Confirmed. This is indeed showing two cases of SRA behaving oddly. First
early SRA produces
:
_T2 = *sptr_1(D);
_ans = _T2;
_ans$curr_12 = _T2.curr;
D.1965_6 = _ans$curr_12;
D.1966_7 = D.1965_6 + -1;
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-03 11:15 ---
*** This bug has been marked as a duplicate of 42424 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-03 11:15 ---
*** Bug 42584 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-01-03 11:16 ---
I think we want to make this work for 4.5 again, it works for 4.4 - of course
w/o mpc which causes the problems here.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |A
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-03 11:27 ---
Confirmed. Well, GCC produces exactly the same code as ICC when using
-O2 -mno-accumulate-outgoing-args -fno-optimize-sibling-calls
-fomit-frame-pointer
Thus the sibcall comes in the way as obviously does -maccumul
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-03 11:34 ---
Because with 32bit we do not have a 64bit bswap instruction and tmp is 64bit.
What would you expect here?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from jakub at gcc dot gnu dot org 2010-01-03 11:38 ---
The testcase is indeed invalid, if the second argument to realpath is not NULL,
it must be a buffer at least PATH_MAX bytes long.
--
jakub at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-03 11:45 ---
With
Index: tree-ssa-math-opts.c
===
--- tree-ssa-math-opts.c(revision 155576)
+++ tree-ssa-math-opts.c(working copy)
@@ -,8 +,
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-01-03 12:06 ---
Subject: Bug 42438
Author: rguenth
Date: Sun Jan 3 12:06:02 2010
New Revision: 155584
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155584
Log:
2010-01-03 Richard Guenther
PR tree-optimization/
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-01-03 12:10 ---
Fixed for 4.5 as good as we can.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2010-01-03 12:19 ---
Shouldn't that be || (bswap32_p && word_mode == SImode) ? expand_unop
will only call expand_doubleword_bswap in that case...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42589
--- Comment #4 from rguenther at suse dot de 2010-01-03 12:28 ---
Subject: Re: bswap optimization does not work
for 32bit (but for 64bit) on 64bit registers
On Sun, 3 Jan 2010, jakub at gcc dot gnu dot org wrote:
> --- Comment #3 from jakub at gcc dot gnu dot org 2010-01-03 12:1
The following code compiles fine with GCC 4.3.3 and 4.4.2, but fails to compile
with 4.5 (snapshot from 2009-12-31):
#include
void f( int ) {}
int main() { std::function< void( int ) > pf = std::bind( &f,
std::placeholders::_1 ); }
with the following error:
In file included from t.cc:1:0:
/home
--- Comment #1 from paolo dot carlini at oracle dot com 2010-01-03 12:47
---
Thanks Daniel. Jon, can you have a look? I verified that the tr1 code we were
using in 4.4.x and before is fine, thus should be either the std::function
changes vs rvalue references or, less likely I believe, t
Extracted from
http://embed.cs.utah.edu/embarrassing/dec_09/harvest/gcc-head_llvm-gcc-head/
I've seen this in multiple examples both compared to llvm and icc.
The other compilers merge adjacent stores to structures in memory,
gcc doesn't.
Simple toy example:
struct foo {
short a;
--- Comment #6 from gerald at pfeifer dot com 2010-01-03 13:10 ---
Would you mind trying again with the latest snapshot/SVN version of GCC
(or the current version of lang/gcc45, if you prefer)?
There have been some improvements recently to libffi which may make a
difference. (It does l
--- Comment #5 from andi-gcc at firstfloor dot org 2010-01-03 13:11 ---
I would expect two bswaps yes, like llvm generates
I also can't see how this should be a bad idea for any target with a bswap
like operation (unless it's 64bit)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42
--- Comment #19 from andi-gcc at firstfloor dot org 2010-01-03 13:18
---
Here's another example with the bogus stack frame problem with a tail call
(the embarassing website has quite a lot of similar cases, normally
near the tail of the tables with 16 vs 22 bytes e.g. against sun cc
wh
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-03 13:20 ---
Old problem - there's a duplicate report even somewhere with a patch from
Jakub.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42594
--- Comment #2 from steven at gcc dot gnu dot org 2010-01-03 13:22 ---
Not sure, but looks like a dup of bug 22141.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42594
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-03 13:30 ---
It is.
*** This bug has been marked as a duplicate of 22141 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from rguenth at gcc dot gnu dot org 2010-01-03 13:30
---
*** Bug 42594 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #13 from nospamname at web dot de 2010-01-03 13:57 ---
Can this report reopen please and target change to m68k-* ?
Bug happen also in m68k-elf.See here the two fjlt .L319 to diffrent labels.I
remove lots compiler options
to make it more simple.But ffmpeg error is same.
I try
--
Summary: Integer/Floating point casts between vector types
generate
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc d
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |redi at gcc dot gnu dot org
|dot org
/*
GCC does not permit a vector of a union type.
To dynamically store both integer and float data in an XMM register define an
integer vector and cast to a float vector whenever a floating point operation
is required upon the data (or use a union to perform the type conversion).
Instead
--- Comment #2 from paolo dot carlini at oracle dot com 2010-01-03 14:26
---
Thanks.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-03 14:33 ---
This is because va_list_type_node is char * on some targets and so
pointer-to char types get globbed into it. But va_list_type_node is
re-constructed as char * at IL read time and thus we read back
unsigned char * a
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-03 14:46 ---
*** This bug has been marked as a duplicate of 42596 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-03 14:46 ---
*** Bug 42595 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42596
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-03 14:50 ---
Likely because you are using hardregs. Re-do the testcase with intrinsics
please.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42596
--- Comment #3 from redi at gcc dot gnu dot org 2010-01-03 15:07 ---
>From a quick look, I think the problem is that std::function now uses perfect
forwarding, but std::bind doesn't yet.
So invoking the function passes an rvalue to _Bind::operator() which fails to
bind to _Args&
Previous
--- Comment #4 from paolo dot carlini at oracle dot com 2010-01-03 15:10
---
Ok, Jon, thanks. At some point, however, *soon* I'm afraid given the gcc4.5
schedule, we'll have to make a tough choice: if updating only std::function
leads to bad regressions in common usages of std::bind, an
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-01-03 15:23 ---
Subject: Bug 42589
Author: rguenth
Date: Sun Jan 3 15:23:29 2010
New Revision: 155588
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155588
Log:
2010-01-03 Richard Guenther
PR tree-optimization/
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-01-03 15:24 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from ghazi at gcc dot gnu dot org 2010-01-03 15:31 ---
(In reply to comment #3)
> OK, I can reproduce the issue.
> The problem is that mpc isn't told where to find the gmp and mpfr libraries.
> [...]
> Except that on some targets, ".libs" is actually called "_libs". I don
--- Comment #2 from andi-gcc at firstfloor dot org 2010-01-03 15:40 ---
An obvious improvement would be to use the non callee clobbered registers
as temporal storage, instead of putting into registers that just get spilled
again. I think one of the other compilers in the comparison
did t
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-03 16:01 ---
SRA here again does somthing stupid:
from
:
acpi_ut_track_stack_ptr ();
in.value = value_1(D);
D.1966_2 = in.bytes[3];
out.bytes[0] = D.1966_2;
D.1967_3 = in.bytes[2];
out.bytes[1] = D.1967_3;
D.1968_
--- Comment #5 from paolo dot carlini at oracle dot com 2010-01-03 16:03
---
Jon, I'm raising Priority and Severity not because the isssue per se is that
deadly serious (after all the whole C++0x is experimental, nothing should be
really critical about it), but because we want to make s
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-03 16:26 ---
Similar example not handled by bswap recognition:
typedef unsigned char u8;
typedef unsigned int u32;
union __anonunion
{
u32 value;
u8 bytes[4];
};
u32
acpi_ut_dword_byte_swap (u32 value)
{
union __anonunion
--- Comment #6 from redi at gcc dot gnu dot org 2010-01-03 16:28 ---
ok, understood - I'm looking at finishing the bind changes at the moment
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from paolo dot carlini at oracle dot com 2010-01-03 16:34
---
Let's keep a P1 for now, we really don't want to forget.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
-
--- Comment #2 from galtgendo at o2 dot pl 2010-01-03 16:46 ---
Created an attachment (id=19452)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19452&action=view)
preprocessed sources
Finally I've got a response in the Gentoo bug.
Info:
Using built-in specs.
Target: powerpc-unknown
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-01-03 16:52 ---
Maybe Zdenek has an idea why RTL LIM is so slow.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-01-03 17:03 ---
Well, obviously it is because
template
gmic& gmic::parse(...)
{
...
while (positionhttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=42175
--- Comment #19 from hjl at gcc dot gnu dot org 2010-01-03 17:03 ---
Subject: Bug 41564
Author: hjl
Date: Sun Jan 3 17:03:38 2010
New Revision: 155591
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155591
Log:
Pass -dumpbase and -dumpdir to gcc for LTO
gcc/
2010-01-03 H.J. L
--- Comment #12 from steven at gcc dot gnu dot org 2010-01-03 17:15 ---
Re. comment #11: If I configure with "--without-build-config" on
ia64-unknown-linux-gnu, with -fgcse-sm enabled, then the bootstrap completes
successfully (all languages except ada). If I configure without the extra
--- Comment #13 from steven at gcc dot gnu dot org 2010-01-03 17:22 ---
For traceability: http://gcc.gnu.org/ml/gcc-patches/2009-12/msg01114.html
I somehow forgot to add the PR number to the commit.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41862
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-03 17:31 ---
The same problem exists for builtin functions that return or take arguments
of type char *. They change signature according to -f[un]signed-char which
causes for example
FAIL: gcc.c-torture/execute/builtins/strcpy-
--- Comment #20 from hjl dot tools at gmail dot com 2010-01-03 17:37
---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|NEW
The attached code (which seems fine to me) produces an internal
compiler error.
gfortran -c pp.f90 -o pp.o
f951: internal compiler error: in gfc_build_null_descriptor, at
fortran/trans-array.c:372
gfortran --version
GNU Fortran (GCC) 4.5.0 20091229 (experimental)
module mod_a
implicit none
pu
--- Comment #8 from redi at gcc dot gnu dot org 2010-01-03 17:57 ---
Created an attachment (id=19453)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19453&action=view)
preliminary patch
I'm testing this, which is not ready for checkin, but updates std::bind to
handle rvalues and fi
--- Comment #9 from paolo dot carlini at oracle dot com 2010-01-03 18:05
---
Great. Let's go ahead this way, then!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42593
--- Comment #10 from redi at gcc dot gnu dot org 2010-01-03 18:07 ---
OK
P.S.
(In reply to comment #8)
>
> (the ability to use this workaround was the main reason I fixed
> std::bind
> recently)
I think I've mentioned to Paolo in private mail that we could use bind
(specifically, bi
--- Comment #8 from jb at gcc dot gnu dot org 2010-01-03 18:09 ---
Subject: Bug 42420
Author: jb
Date: Sun Jan 3 18:09:37 2010
New Revision: 155593
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155593
Log:
PR libfortran/42420 Large file capable stat for MingW
Modified:
tr
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-03 18:12 ---
Which seems to be because of CCP which folds
D.2023_3 = __builtin___strcpy_chk (&p[1], &"vwxyz"[0], 31);
with unsigned LHS to
D.2023_3 = ( *) __builtin_memcpy (&p[1], &"vwxyz"[0], 6);
which requires a temporary a
--- Comment #4 from hjl dot tools at gmail dot com 2010-01-03 18:14 ---
Really fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UN
--- Comment #2 from jlpoole at pon dot net 2010-01-03 18:21 ---
Created an attachment (id=19454)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19454&action=view)
output under normal circumstances
In this output, the compiler incorrectly looks for the ecj.jar under
/usr/share/java
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-01-03 18:21 ---
Created an attachment (id=19455)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19455&action=view)
patch
Patch I am going to test. Further testing appreciated.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #3 from jlpoole at pon dot net 2010-01-03 18:23 ---
Created an attachment (id=19456)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19456&action=view)
work-around output
To overcome the misdirected path, I created a "java" directory under /usr/share
and copied the /usr/
--- Comment #14 from rguenth at gcc dot gnu dot org 2010-01-03 18:25
---
It means that gcse-sm generates different code with -g vs. -g0 which likely
means that it is confused by the extra DEBUG_INSNs that appear with -g or
that its generated code depends on things like insn uids.
--
--- Comment #4 from jlpoole at pon dot net 2010-01-03 18:30 ---
I think I found the problem:
the compiler is using an incorrect path, e.g. "/usr/share/java", to find the
ecj.jar file and the other jar files, libgcj-4.5.0.jar
libgcj-tools-4.5.0.jar, when it should have used
"/usr/loc
--- Comment #5 from jlpoole at pon dot net 2010-01-03 18:43 ---
Here's my configuration log:
plug build # pwd
/mnt/seagate2/download/gnu/build
plug build # head config.log
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes
--- Comment #6 from jakub at gcc dot gnu dot org 2010-01-03 18:55 ---
That's just a misunderstanding what DESTDIR is. DESTDIR just says a directory
where the / dir of installed files starts. It is used when you e.g. want to
install everything into a temporary directory to package it up
--- Comment #2 from hjl dot tools at gmail dot com 2010-01-03 19:16 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00116.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #8 from rakdver at kam dot mff dot cuni dot cz 2010-01-03
19:37 ---
Subject: Re: Slow compile and much memory use
at -O1
> --- Comment #7 from rguenth at gcc dot gnu dot org 2010-01-03 17:03
> ---
> Well, obviously it is because
>
> template
> gmic& gmi
--- Comment #7 from andreast at gcc dot gnu dot org 2010-01-03 19:38
---
[tc:~] andreast% /usr/local/bin/gcj45 -o ecj
--main=org.eclipse.jdt.internal.compiler.batch.Main ecj.jar
[tc:~] andreast% vi HelloWorld.java
public class HelloWorld {
public static void main(String args[]) {
--- Comment #8 from matt at use dot net 2010-01-03 19:57 ---
can this be backported to 4.4 as well so I can integrate it into our 4.4-based
toolchain?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42577
--- Comment #15 from steven at gcc dot gnu dot org 2010-01-03 20:02 ---
Created an attachment (id=19457)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19457&action=view)
Ignore all DEBUG_INSNs in store-motion.c
With this patch I can complete a bootstrap on ia64-unknown-linux-gnu w
--- Comment #14 from matt at use dot net 2010-01-03 20:30 ---
Still happening on 4.5.0 20091228 (and gcc 4.4.1) on Ubuntu 9.10/amd64). I
found that it goes away in 3 separate instances when turning on
-finline-functions. The last 2 instances of memory corruption I am running into
are fun
--- Comment #11 from paolo dot carlini at oracle dot com 2010-01-03 20:57
---
By the way, Jon, I don't think we should delay committing this work only
because of DR 817, after all isn't even Ready...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42593
--- Comment #12 from paolo dot carlini at oracle dot com 2010-01-03 21:02
---
... if we have something rather satisfactory wrt all the other isses /
testcases we are aware of in this area the sooner we commit the code, the
better: I'm sure that Daniel can help testing it further on his
Plugin never passes -v -mtune=xxx to lto-wrapper.
--
Summary: -v/-m* don't work with plugin
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc
--- Comment #1 from hjl dot tools at gmail dot com 2010-01-03 21:50 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00119.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #13 from redi at gcc dot gnu dot org 2010-01-03 22:10 ---
Created an attachment (id=19458)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19458&action=view)
updated patch
this fixes the formatting in the previous patch, includes the call_once
workaround, and updates the
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-03 22:29 ---
*** This bug has been marked as a duplicate of 42520 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-01-03 22:29 ---
*** Bug 42598 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #15 from rguenth at gcc dot gnu dot org 2010-01-03 22:32
---
The issue is in a very twisted piece of GCC where the chances to break sth are
bigger that to fix sth ;)
And it isn't a regression, so it's not on too many peoples radar (nor does
it seem to happen in practice and
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-01-03 22:33
---
If it also passes testing it is ok for trunk (it does make sense to me).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41862
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-01-03 22:33 ---
The patch should apply more-or-less literally to the 4.4 branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42577
--- Comment #17 from steven at gcc dot gnu dot org 2010-01-03 22:41 ---
Subject: Bug 41862
Author: steven
Date: Sun Jan 3 22:41:22 2010
New Revision: 155596
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155596
Log:
PR rtl-optimization/41862
* store-motion.c (st
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-01-03 22:45 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-01-03 22:45 ---
Subject: Bug 42583
Author: rguenth
Date: Sun Jan 3 22:44:56 2010
New Revision: 155597
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155597
Log:
2010-01-03 Richard Guenther
PR testsuite/42583
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-01-03 22:45
---
Is this bug now fixed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41605
--- Comment #18 from steven at gcc dot gnu dot org 2010-01-03 22:46 ---
Works for me now.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #30 from steven at gcc dot gnu dot org 2010-01-03 22:57 ---
With the following compiler:
$ ./xgcc --version
xgcc (GCC) 4.5.0 20091228 (experimental) [trunk revision 155486]
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying con
--- Comment #1 from steven at gcc dot gnu dot org 2010-01-03 23:06 ---
This bug needs TLC from a MIPS person. At least a confirmation would be nice.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #16 from steven at gcc dot gnu dot org 2010-01-03 23:08 ---
Can we close this bug as WONTFIX, and remove IMA for GCC 4.5?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39959
--- Comment #31 from rguenth at gcc dot gnu dot org 2010-01-03 23:14
---
Heh. I wonder how we can reliably add testcases for code size issues ...
can we either dump size estimates or extract object .text section sizes?
Ian may know arm people who I suspect would be interested in contri
--- Comment #10 from mikpe at it dot uu dot se 2010-01-03 23:15 ---
(In reply to comment #9)
> Fascinating indeed. If someone can bisect where during 4.4 development we
> fixed this again or where during 4.3 development we broke it that would be
> nice.
This test case was fixed for 4.4
--- Comment #3 from adam at consulting dot net dot nz 2010-01-03 23:20
---
This is a demo of poor code generation with XMM global register variables
("hardregs") and the vector extensions. Intrinsics are too low level. The
vector extensions can continue to work on a platform without x86
Host System: OS/X 10.6.2
Target System: arm7tdmi
Compiler Configuration Options:
jconradw:~ conr2286$ arm-elf-gcc --v
Using built-in specs.
Target: arm-elf
Configured with: ../gcc-4.4.2/configure --target=arm-elf
--prefix=/Users/mfischer/Projekte/development/yagarto/install --disable-nls
--disa
--- Comment #1 from conr2286 at vandals dot uidaho dot edu 2010-01-04
00:26 ---
Created an attachment (id=19459)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19459&action=view)
Preprocessed rtcISR.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42599
The following code prints "true" with 4.3.3, but "false" with 4.4.2 and
4.5-20091231. I think printing "true" is correct or am I missing something?
#include
#include
#include
int main()
{
bool result;
std::istringstream is( "true" );
is >> std::boolalpha >> result;
std::cout << std::bo
--- Comment #7 from hjl at gcc dot gnu dot org 2010-01-04 00:53 ---
Subject: Bug 42520
Author: hjl
Date: Mon Jan 4 00:52:50 2010
New Revision: 155601
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155601
Log:
Pass -m* and -v to -plugin-opt
gcc/
2010-01-03 H.J. Lu
--- Comment #10 from matt at use dot net 2010-01-04 01:04 ---
what I mean to ask is: can this fix be committed to the 4.4 branch? I'd prefer
to minimize the number of local patches we apply to our custom build.
Thanks for the quick fix, by the way! :)
--
http://gcc.gnu.org/bugzilla
1 - 100 of 115 matches
Mail list logo
