--- Comment #7 from rwild at gcc dot gnu dot org 2010-06-03 06:33 ---
Subject: Bug 42798
Author: rwild
Date: Thu Jun 3 06:32:27 2010
New Revision: 160210
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160210
Log:
Import AC_CHECK_DECL for C++ fixes from git Autoconf.
config/:
--- Comment #8 from rwild at gcc dot gnu dot org 2010-06-03 06:45 ---
Subject: Bug 42798
Author: rwild
Date: Thu Jun 3 06:45:02 2010
New Revision: 160211
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160211
Log:
Fix PR bootstrap/42798.
libiberty/:
PR bootstrap/42798
--- Comment #58 from iains at gcc dot gnu dot org 2010-06-03 07:57 ---
(In reply to comment #57)
(In reply to comment #46)
Other than that, you guys manage to write a lot about this but still not
answer
all questions (both of which makes it unattractive for others to look at a
--- Comment #10 from manu at gcc dot gnu dot org 2010-06-03 08:47 ---
(In reply to comment #9)
I've been experimenting with this patch, which warns if there is a missing
mem-initializer for a scalar.
It gives a false positive for cases were the member is assigned to in the
--- Comment #59 from jakub at gcc dot gnu dot org 2010-06-03 09:10 ---
Why would be volatile needed? pthread_join returning guarantees that the other
thread's thread function finished, and the variable is only written in that
thread, there is no data race on it.
--
--- Comment #11 from jwakely dot gcc at gmail dot com 2010-06-03 09:18
---
(In reply to comment #10)
(In reply to comment #9)
I've been experimenting with this patch, which warns if there is a missing
mem-initializer for a scalar.
It gives a false positive for cases were the
--- Comment #32 from iains at gcc dot gnu dot org 2010-06-03 09:21 ---
(In reply to comment #31)
The latest proposed patch triggers one additional g++ tls failure...
FAIL: g++.dg/tls/init-2.C (test for excess errors)
this test is not enabled for emutls at present;
yes, I know it
--- Comment #12 from jwakely dot gcc at gmail dot com 2010-06-03 09:27
---
Apart from the false positives, another problem is that the check for
layout_pod_type_p is not right. An empty class is a POD but doesn't need
initialising.
--
--- Comment #4 from jamborm at gcc dot gnu dot org 2010-06-03 09:30 ---
Unfortunately the preprocessed source from comment #1 seems to be
damaged, I get loads of errors like error: stray '\336' in program.
Can you please re-upload it? Thanks.
--
--- Comment #13 from paolo dot carlini at oracle dot com 2010-06-03 10:16
---
About -Weffc++, we also have a PR (16166) about splitting it... Not that I
think we should really do that - adding a dozen of -Weffc++-type warnings - but
I believe it would be a good idea to finally resolve
Booting with rev. 160214:
gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-Wold-style-definition -Wc++-compat -fno-common
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44397
--- Comment #60 from rwild at gcc dot gnu dot org 2010-06-03 10:33 ---
(In reply to comment #59)
Why would be volatile needed? pthread_join returning guarantees that the
other
thread's thread function finished, and the variable is only written in that
thread, there is no data race
Probably introduced by the fix for bug 44385, given it happens in the same
place and removing -fuse-linker-plugin fixes it again: With gcc 4.5.1 rev
160157, linking Qt's moc with -flto -fuse-linker-plugin results in
g++ -Wl,-rpath-link,/usr/src/ark/BUILD/qt/lib -m64 -O2 -fomit-frame-pointer
-fweb
--- Comment #1 from bero at arklinux dot org 2010-06-03 10:44 ---
Created an attachment (id=20816)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20816action=view)
ltrace output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44398
--- Comment #61 from jakub at gcc dot gnu dot org 2010-06-03 10:47 ---
Of course pthread_join implies all outstanding memory stores of the dead thread
complete before pthread_join returns. And, pthread_join is a non-inlined
function call, a_in_other_thread is a global variable, so the
--- Comment #62 from iains at gcc dot gnu dot org 2010-06-03 10:59 ---
(In reply to comment #60)
(In reply to comment #59)
Is this bug just a dupe of PR 44132 now?
No, PR44132 applies to all darwin versions.
However, I think it *is* a dup of PR44304 (which relates to the fail of
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-06-03 11:12 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #14 from jwakely dot gcc at gmail dot com 2010-06-03 11:24
---
Created an attachment (id=20817)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20817action=view)
better -Wmeminit patch
This version ignores empty classes and checks for a nontrivial default ctor
instead
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-03 11:28 ---
That isn't very helpful ;) Can you try to reproduce this with current trunk?
What version of gold are you using?
Can you produce a testcase? Try doing an incremental link (-r), and strip
libraries and object
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-03 11:28 ---
ipa-reference.c:(.text+0x28825): undefined reference to
`lto_varpool_encoder_size'
has been fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from bero at arklinux dot org 2010-06-03 11:38 ---
Exact same error with 4.5.1 branch rev. 160157, compiling trunk
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44390
--- Comment #5 from jakub at gcc dot gnu dot org 2010-06-03 12:07 ---
Subject: Bug 44375
Author: jakub
Date: Thu Jun 3 12:07:18 2010
New Revision: 160219
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160219
Log:
PR debug/44375
* tree-cfg.c
I'm trying to write windows console application working with directories, and i
discover that arguments processed not right. For example:
#include iostream
int main ( int argc, char *argv[], char *envp[] ) {
std::cout you have argc arguments;
}
resulting:
a.exe a a
you have 2 arguments
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-03 12:29 ---
This is a problem of your execution environment, not GCC. And AFAICS your
observerd behavior is what is expected.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #13 from lists at eitanadler dot com 2010-06-03 12:38 ---
gcc 4.6.0.20100529 + the patch fixes the problem.
--
lists at eitanadler dot com changed:
What|Removed |Added
--- Comment #63 from iains at gcc dot gnu dot org 2010-06-03 12:50 ---
(In reply to comment #62)
(In reply to comment #60)
(In reply to comment #59)
Is this bug just a dupe of PR 44132 now?
No, PR44132 applies to all darwin versions.
OK, I need to refine that comment.
--- Comment #2 from alexandrfedorov at gmail dot com 2010-06-03 12:50
---
I'm executing my application via cmd.exe from Windows XP. As i know in windows
NOTHING is escaping with backslash. Standard utilities like cacls.exe working
well with such arguments.
Please pay attention to this
--- Comment #64 from howarth at nitro dot med dot uc dot edu 2010-06-03
13:03 ---
I've also had a report for the fink gcc45-4.5.0-1000 package of the boot strap
comparison failure occuring (rarely) on a single processor PowerPC (building
with make -j 1).
--
--- Comment #65 from iains at gcc dot gnu dot org 2010-06-03 13:17 ---
*** Bug 44304 has been marked as a duplicate of this bug. ***
--
iains at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from iains at gcc dot gnu dot org 2010-06-03 13:17 ---
*** This bug has been marked as a duplicate of 43170 ***
--
iains at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-03 13:18 ---
GCC does not have any influence on how arguments are split, it is your
execution environment (including the runtime, which might be cygwin or
mingw).
This is not a GCC bug, please do not reopen it.
--
rguenth
--- Comment #4 from jwakely dot gcc at gmail dot com 2010-06-03 13:24
---
If it's a cygwin executable the behaviour might be caused by cygwin's globber
In any case, it's not gcc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44399
--- Comment #66 from howarth at nitro dot med dot uc dot edu 2010-06-03
13:46 ---
At the risk of confusing the issues here, I would point out...
http://gcc.gnu.org/ml/gcc/2010-04/msg00044.html
where I observed that 20_util/shared_ptr/thread/default_weaktoshared.cc
execution test
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-06-03 13:47
---
The problem seems to have vanished, so eventually the fix can be backported
(together with the typo fix in the configure script obviously).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40702
Sent from my iPhone
On Jun 3, 2010, at 5:15 AM, alexandrfedorov at gmail dot com gcc-bugzi...@gcc.gnu.org
wrote:
I'm trying to write windows console application working with
directories, and i
discover that arguments processed not right. For example:
#include iostream
int main ( int
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-06-03 13:48 ---
Mine. See http://gcc.gnu.org/ml/gcc-patches/2010-05/msg02424.html for an
outline for a possible fix.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gmail dot com 2010-06-03 13:48 ---
Subject: Re: New: Problem with command line arguments in windows
Sent from my iPhone
On Jun 3, 2010, at 5:15 AM, alexandrfedorov at gmail dot com
gcc-bugzi...@gcc.gnu.org
wrote:
I'm trying to write windows
--- Comment #5 from zsojka at seznam dot cz 2010-06-03 14:03 ---
This stopped crashing sometimes between r158969 and r159387 (at x86_64-linux)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43688
--- Comment #17 from rguenth at gcc dot gnu dot org 2010-06-03 14:14
---
We bootstrap it again and it now seems to install fine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-06-03 14:22 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
lto/41584
* gcc.dg/lto/20100603-1_0.c: New testcase.
* gcc.dg/lto/20100603-2_0.c: Likewise.
* gcc.dg/lto/20100603-3_0.c: Likewise.
Added:
trunk/gcc/testsuite/gcc.dg/lto/20100603-1_0.c
trunk/gcc/testsuite/gcc.dg/lto/20100603-2_0.c
trunk/gcc/testsuite/gcc.dg/lto
--- Comment #2 from christine dot mecklenborg at gmail dot com 2010-06-03
14:33 ---
(In reply to comment #1)
gcc/ld is trying to link as i386
Well the option -arch x86_64 does not exist for the FSF GCC; it is -m64. I
think the issue is that your makefile is built for Apple's GCC
--- Comment #33 from dominiq at lps dot ens dot fr 2010-06-03 14:52 ---
On x86_64-apple-darwin10.3.0 the patch in comment #26 applied on top of r160219
cause
=== libjava Summary for unix/-m64 ===
# of expected passes2459
# of unexpected failures62
This code is accepted by GCC and compiles
typedef void F();
struct X { F X; };
Not valid according to 9.2/13bullet2. It seems that GCC thinks that F X; is a
data-member (declaring data-members with the name of the class is valid, as
long as there are no user declared constructors).
--
--- Comment #6 from hjl at gcc dot gnu dot org 2010-06-03 14:53 ---
Subject: Bug 43688
Author: hjl
Date: Thu Jun 3 14:53:06 2010
New Revision: 160224
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160224
Log:
Add a testcasef for PR tree-optimization/43688.
2010-06-03 H.J. Lu
--- Comment #7 from hjl dot tools at gmail dot com 2010-06-03 14:55 ---
Fixed by revision 159343:
http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00395.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
This code is valid, but GCC rejects it:
struct X { int X; };
int X::*p = X::X;
// error: taking address of constructor 'X::X'
GCC apparently seems to think that X::X looks up to the injected class name,
and thus (by 3.4.3.1/1a) would name the constructor. But the name of the
non-static data
--- Comment #34 from iains at gcc dot gnu dot org 2010-06-03 15:03 ---
(In reply to comment #33)
On x86_64-apple-darwin10.3.0 the patch in comment #26 applied on top of
r160219
cause
=== libjava Summary for unix/-m64 ===
# of expected passes2459
#
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-06-03 15:03 ---
This is fixed. I have a testcase + testsuite patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
This code is valid, but rejected by GCC:
struct A { void f(); };
typedef void F();
struct B { friend F A::f; };
// error: type 'A' is not derived from type 'B'
--
Summary: GCC does not accept friend function declarations using a
typedef for function type.
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-06-03 15:07 ---
The assert has been removed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-03 15:08 ---
*** Bug 42675 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-06-03 15:08 ---
Similar to PR41844.
*** This bug has been marked as a duplicate of 41844 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-06-03 15:13 ---
Re-confirmed on trunk.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Last
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-06-03 15:14 ---
Ah, it does not work because we mangle foobar to foobar.1234, not because
we eliminate it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43038
--- Comment #35 from dominiq at lps dot ens dot fr 2010-06-03 15:21 ---
Extracted from x86_64-apple-darwin10.3.0/libjava/testsuite/libjava.log:
...
set_ld_library_path_env_vars:
ld_library_path=.:/opt/gcc/build_w/x86_64-apple-darwin10.3.0/./libjava/.libs
invoke:
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-03 15:24 ---
Re-confirmed on trunk.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-03 15:26 ---
Reconfirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Last
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-03 15:28 ---
Fixed for 4.6.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-03 15:31 ---
Cary - why does lto-plugin get invoked when gold has errors?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-03 15:32 ---
There was a defect report in the C++ standard about X::X; I cannot remember
what happens with a member variable being named the same as the class name
though.
--
For the following function:
void xxx(short* __restrict__ a, short* __restrict__ b)
{
int i;
for (i = 0; i 8; i++)
{
a[i] = b[i];
}
}
the following is generated in the .optimized file:
xxx (short int * restrict a, short int * restrict b)
{
vector(2) short int * vect_p.27;
--- Comment #1 from roy dot 1rosen at gmail dot com 2010-06-03 15:49
---
Created an attachment (id=20818)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20818action=view)
preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44403
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-03 16:03 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
lto/41921
* lib/lto.exp: Always load gcc.exp.
(lto-obj): For C source files invoke gcc_target_compile.
* g++.dg/lto/20100603-1_0.C: New testcase.
* g++.dg/lto/20100603-1_1.c: Likewise.
Added:
trunk/gcc/testsuite/g++.dg/lto/20100603-1_0.C
trunk/gcc/testsuite/g
--- Comment #36 from iains at gcc dot gnu dot org 2010-06-03 16:08 ---
(In reply to comment #35)
Extracted from x86_64-apple-darwin10.3.0/libjava/testsuite/libjava.log:
...
set_ld_library_path_env_vars:
ld_library_path=.:/opt/gcc/build_w/x86_64-apple-darwin10.3.0/./libjava/.libs
lto/41921
* lib/lto.exp: Always load gcc.exp.
(lto-obj): For C source files invoke gcc_target_compile.
* g++.dg/lto/20100603-1_0.C: New testcase.
* g++.dg/lto/20100603-1_1.c: Likewise.
Modified:
trunk/gcc/testsuite/lib/lto.exp
--
http://gcc.gnu.org/bugzilla
--- Comment #67 from iains at gcc dot gnu dot org 2010-06-03 16:12 ---
I am puzzled by this apparent fail when the tests that depend on the variables
being distinct are all passing.
So, I think I've got a hunch;
If the spawned thread finishes before pthread_create () returns, then the
--- Comment #5 from hjl at gcc dot gnu dot org 2010-06-03 16:36 ---
Subject: Bug 44294
Author: hjl
Date: Thu Jun 3 16:36:22 2010
New Revision: 160229
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160229
Log:
Check MAX_FIXED_MODE_SIZE on bit-field in C++.
gcc/ada/
2010-06-03
--- Comment #4 from paolo dot carlini at oracle dot com 2010-06-03 16:40
---
Let's CC Jason...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from schaub-johannes at web dot de 2010-06-03 16:45 ---
The Standard allows this at 9.2/13a (In addition, if class T has a
user-declared constructor (12.1), every nonstatic data member of class T shall
have a name different from T.). In our case we don't have a user
--- Comment #68 from jakub at gcc dot gnu dot org 2010-06-03 16:58 ---
That makes sense, so all we need to do in config/tls.m4 is probably:
1) move a_in_main_thread variable to file scope, and neither a_in_main_thread
nor a_in_other_thread should be static
2) move a_in_main_thread = a;
--- Comment #3 from paolo dot carlini at oracle dot com 2010-06-03 17:00
---
Jason certainly followed these developments, I remember, let's CC him.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Consider:
char buf[128];
extern void bar (int a, const char *p);
extern char *strcpy (char *, const char *);
void
foo (int a)
{
if (a)
bar (0, buf);
strcpy (buf, 0123456789abcdefghijklmnopqrstuvwxyz);
bar (0, buf);
}
Compile this testcase with arm-none-linux-gnueabi-4.4.
strcpy
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-03 17:27 ---
Looks related to PR 20972.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44404
I am trying to build mainline GCC (revision 160215) configured
with -enable-build-with-cxx .
I get the following error during bootstrap:
/user/inria/fsf/bldxx-20100603/./prev-gcc/g++
-B/user/inria/fsf/bldxx-20100603/./prev-gcc/
-B/user/inria/cxx/i686-pc-linux-gnu/bin/ -nostdinc++
-I/user/inria
--- Comment #1 from amylaar at gcc dot gnu dot org 2010-06-03 17:59 ---
I'm currently testing if the patch for PR 44361 helps for this failure too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44405
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-03 18:01 ---
*** Bug 44405 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-06-03 18:01 ---
*** This bug has been marked as a duplicate of 44362 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from kazu at gcc dot gnu dot org 2010-06-03 18:18 ---
Andrew,
auto-inc-dec.c was introduced on Jul 2, 2006, and PR 20972 was filed
on April 12, 2005, so I'd think that PR 20972 is due to something
else. They do both involve the same assembler message though.
--
--- Comment #69 from howarth at nitro dot med dot uc dot edu 2010-06-03
18:20 ---
So the tls tests in the generated configure should be changed as follows?
--- gcc-4.5.0/libgomp/configure.orig2010-06-03 13:05:23.0 -0400
+++ gcc-4.5.0/libgomp/configure 2010-06-03
--- Comment #70 from dominiq at lps dot ens dot fr 2010-06-03 18:23 ---
(In reply to comment #68)
That makes sense, so all we need to do in config/tls.m4 is probably:
1) move a_in_main_thread variable to file scope, and neither a_in_main_thread
nor a_in_other_thread should be static
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-06-03 18:25 ---
(In reply to comment #2)
auto-inc-dec.c was introduced on Jul 2, 2006, and PR 20972 was filed
on April 12, 2005, so I'd think that PR 20972 is due to something
else. They do both involve the same assembler
--- Comment #4 from ccoutant at gcc dot gnu dot org 2010-06-03 18:29
---
Cary - why does lto-plugin get invoked when gold has errors?
Gold doesn't stop on these kinds of errors -- it proceeds to the end of the
link to try to diagnose as many errors as possible. I'm not sure why a
--- Comment #4 from jason at gcc dot gnu dot org 2010-06-03 18:55 ---
The naming the constructor stuff is DR 147, but I agree that this testcase
should be accepted since lookup doesn't find the injected-class-name.
--
jason at gcc dot gnu dot org changed:
What
--- Comment #71 from jakub at gcc dot gnu dot org 2010-06-03 19:02 ---
Yes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43170
attached code crashes, when compiled with -ftree-sra
works fine with 4.4.2
its probably an incarnation of PR44258
--
Summary: wrong code generation with -ftree-sra
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
--- Comment #1 from torbenh at users dot sourceforge dot net 2010-06-03
19:08 ---
Created an attachment (id=20819)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20819action=view)
code that crashes when compiled
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44406
--- Comment #2 from torbenh at users dot sourceforge dot net 2010-06-03
19:10 ---
Created an attachment (id=20820)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20820action=view)
preprocessed signals_test.cc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44406
--- Comment #5 from torbenh at users dot sourceforge dot net 2010-06-03
19:15 ---
(In reply to comment #4)
Unfortunately the preprocessed source from comment #1 seems to be
damaged, I get loads of errors like error: stray '\336' in program.
Can you please re-upload it? Thanks.
--- Comment #3 from Kyle dot D dot Moffett at boeing dot com 2010-06-03
19:26 ---
(In reply to comment #0)
So after looking at the code I saw now the following:
1c24 __floatdidf:
1c6c: 11 23 1a 2c evmergehi r9,r3,r3
This function is touching the complete 64bit
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-03 19:39 ---
Created an attachment (id=20821)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20821action=view)
patch
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #72 from iains at gcc dot gnu dot org 2010-06-03 20:06 ---
Created an attachment (id=20822)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20822action=view)
config patch for test
config/tls.m4 - modified as per Jakub's suggestion
*/configure regenerated as necessary.
--- Comment #4 from Kyle dot D dot Moffett at boeing dot com 2010-06-03
20:09 ---
Ok, I have a trivial 19-line testcase that triggers the bug on my native Debian
GCC 4.4.4-2+powerpcspe1 (with PR44169 fix) with -O0 and -O3. The compiler was
built with: --with-cpu=8548
I have seen the following code produce an unexpected result on two different
gcc compilers. I compile the following code
#include stdio.h
int main()
{
int a, d1, r1, r2;
unsigned int d2;
a = -10;
d1 = 2;
d2 = 3;
r1 = a / d1;
r2 = a / d2;
On Linux/ia32, revision 160229 gave:
FAIL: gcc.dg/lto/20100603-2 c_lto_20100603-2_0.o-c_lto_20100603-2_0.o link, -O0
-fwhopr (internal compiler error)
FAIL: gcc.dg/lto/20100603-2 c_lto_20100603-2_0.o-c_lto_20100603-2_0.o link, -O2
-fwhopr (internal compiler error)
FAIL: gcc.dg/lto/20100603-3
--- Comment #5 from gcc at breakpoint dot cc 2010-06-03 20:17 ---
So clearly the caller's assembly is wrong; it should be saving all 64-bits of
r9 (volatile gpr) first.
Yes, that it what I've been pointing out. There is an optimization in the stack
code which uses 32bit stores/loads if
--- Comment #6 from Kyle dot D dot Moffett at boeing dot com 2010-06-03
20:21 ---
Created an attachment (id=20823)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20823action=view)
Combined trivial testcase (For -O0)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
--- Comment #7 from Kyle dot D dot Moffett at boeing dot com 2010-06-03
20:22 ---
Created an attachment (id=20824)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20824action=view)
Multipart trivial testcase (For -O3)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
1 - 100 of 144 matches
Mail list logo
