--- Comment #15 from burnus at gcc dot gnu dot org 2010-01-04 07:45 ---
I believe the patch at
http://gcc.gnu.org/ml/fortran/2010-01/msg00023.html
should be sufficient.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36161
--- Comment #3 from burnus at gcc dot gnu dot org 2010-01-04 07:44 ---
Should be FIXED now. I did what was proposed in comment 0: Adding the version
via %s.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #10 from burnus at gcc dot gnu dot org 2010-01-04 07:43 ---
Still TO DO:
- SAVED local variables are (probably) mishandled
- Check whether other things such as allocatable scalar components,
(absent/present) optional dummys etc. work.
- allocatable-scalar returning functio
--- Comment #4 from burnus at gcc dot gnu dot org 2010-01-04 07:31 ---
Subject: Bug 42517
Author: burnus
Date: Mon Jan 4 07:30:49 2010
New Revision: 155606
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155606
Log:
2009-01-04 Tobias Burnus
PR fortran/41872
*
--- Comment #9 from burnus at gcc dot gnu dot org 2010-01-04 07:31 ---
Subject: Bug 41872
Author: burnus
Date: Mon Jan 4 07:30:49 2010
New Revision: 155606
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155606
Log:
2009-01-04 Tobias Burnus
PR fortran/41872
*
--- Comment #2 from burnus at gcc dot gnu dot org 2010-01-04 07:31 ---
Subject: Bug 40849
Author: burnus
Date: Mon Jan 4 07:30:49 2010
New Revision: 155606
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155606
Log:
2009-01-04 Tobias Burnus
PR fortran/41872
*
file: test.cpp
template
T make();
struct p {};
struct c : decltype(make()) {};
compilation command:
g++ -c -std=c++0x test.cpp
output:
test.cpp:5: error: expected class-name before 'decltype'
test.cpp:5: error: expected '{' before 'decltype'
test.cpp:5: error: expected unqualified-id before '{
libgomp.fortran/recursion1.f90 aborted at random on Linux/Core i7.
There are
---
implicit none
integer :: i,s
s=0
!$omp parallel do private(i) shared(s)
do i=1,10
call sub(i)
end do
!$omp end parallel do
if (s/=55) call abort()
contains
subroutine sub (n)
integer :: n
s = s + n
--- Comment #8 from hjl dot tools at gmail dot com 2010-01-04 04:28 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2010-01-04 03:52
---
Fixed the script on Cygwin:
$ ./bug1.sh
ar: creating libex.a
COMPILER gfortran-4
BAD LOAD ix2(4)=
ar: creating libex.a
COMPILER gfc
BAD LOAD ix2(4)=
ar: creating libex.a
COMPILER g77
GOOD LOAD ix2(4)=abcdefgh
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2010-01-04 03:40
---
With Linux:
$ ./bug1.sh
ar: creating libex.a
COMPILER g77
GOOD LOAD ix2(4)=abcdefghijklmnopqrst
ar: creating libex.a
COMPILER g95
GOOD LOAD ix2(4)=abcdefghijklmnopqrst
ar: creating libex.a
COMPILER gfortran
G
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2010-01-04 03:25
---
OK, I could not get the script to run for some reason.
However, I manually performed the steps in the script:
gfortran-4 -c juinit2.f
ar -r libex.a juinit2.o
gfortran-4 bug.f -L. -lex -o bug
./bug
--- Comment #1 from paolo dot carlini at oracle dot com 2010-01-04 02:21
---
This behavior changed as response to libstdc++/37958, I spent way to much time
on it, Daniel, believe me ;) Anyway, as an additional data point, SunStudio
also agrees with current libstdc++.
--
paolo dot ca
Compile following code with options -mthumb -fpic -Os,
int foo(int j)
{
static int i;
int t = i;
i = j;
return t;
}
GCC generates:
foo:
ldr r3, .L2 // A
ldr r2, .L2+4 // B
.LPIC0:
add r3, pc// C
add r3, r3, r2// D
--- Comment #7 from jlpoole at pon dot net 2010-01-04 01:51 ---
Thank you.
I've updated trunk to Revision: 155601. Wiped out build and am running make
(it will take a few days). I'll update with my results.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42409
--- 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
--- 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
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 #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
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
---
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 #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
--- 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 #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 #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 #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 #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 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 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 #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 #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 #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 #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 #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 #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 #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
/*
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
--
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
--
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
--- 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
--- 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 #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
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--- 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
--- 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 #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 #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 #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
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 #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
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
1 - 100 of 115 matches
Mail list logo
