Dear GCC Team :
This is just a friendly letter. There probably will not be another GCC
update from the Sunfreeware site ( which is still showing 3.4.6 ) for a
long time now that Oracle has pulled finances. The same sad state of
affairs affects the OpenSolaris project as a whole.
I do expect
On Tue, Aug 10, 2010 at 6:48 PM, Ian Bolton ian.bol...@arm.com wrote:
I am in the process of fixing PR44328
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328)
The problem is that gen_inbound_check in tree-switch-conversion.c subtracts
info.range_min from info.index_expr, which can cause the
On Wed, Aug 11, 2010 at 9:32 AM, Dennis Clarke dcla...@blastwave.org wrote:
Dear GCC Team :
This is just a friendly letter. There probably will not be another GCC
update from the Sunfreeware site ( which is still showing 3.4.6 ) for a
long time now that Oracle has pulled finances. The same
Hello,
In the example accompanying the patch below we consider that the
types
forward_as_lreftypenameseq::seq_type
at line marked with //#0 and
forward_as_lreftypename remove_referenceSeq::type::seq_type
at the line marked with //#1 should compare equal. And I believe that
is
Hi Sebastian,
I currently encountered an issue when testing
gcc.dg/graphite/interchange-9.c on a ARM bare-metal board which has only
4MB memory.
Apparently, with
#define N
#define M
int A[N*M] in main is too large to fit in stack.
There are several ways to solve this issue:
1.
On Wed, Aug 11, 2010 at 10:29, Jie Zhang j...@codesourcery.com wrote:
Hi Sebastian,
I currently encountered an issue when testing
gcc.dg/graphite/interchange-9.c on a ARM bare-metal board which has only 4MB
memory.
Apparently, with
#define N
#define M
int A[N*M] in main is
On 08/11/2010 11:47 PM, Sebastian Pop wrote:
On Wed, Aug 11, 2010 at 10:29, Jie Zhangj...@codesourcery.com wrote:
Hi Sebastian,
I currently encountered an issue when testing
gcc.dg/graphite/interchange-9.c on a ARM bare-metal board which has only 4MB
memory.
Apparently, with
#define N
Hi Tim,
Do you mean you are adding an additional level of functions and hoping
for efficient in-lining?
Note that my questions arise in the context of automatic code generation:
http://cci.lbl.gov/fable
Please compare e.g. the original LAPACK code with the generated C++ code
to see why the
On 08/11/2010 10:59 AM, Ralf W. Grosse-Kunstleve wrote:
My original posting shows that gfortran and g++ don't do as good
a job as ifort in generating efficient machine code. Note that the
loss going from gfortran to g++ isn't as bad as going from ifort to
gfortran. This gives me hope that the
On 08/10/2010 09:51 PM, Ralf W. Grosse-Kunstleve wrote:
I wrote a Fortran to C++ conversion program that I used to convert selected
LAPACK sources. Comparing runtimes with different compilers I get:
absolute relative
ifort 11.1.0721.790s1.00
gfortran
Hi Richard,
How about using an automatic converter to arrange for C++ code to
call into the generated Fortran code instead? Create nice classes
and wrappers and such, but in the end arrange for the Fortran code
to be called to do the real work.
I found it very labor intensive to maintain a
This is the beta release of binutils 2.20.51.0.11 for Linux, which is
based on binutils 2010 0810 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have
Sending this to gcc since I got no help from sending it to gcc-help
--- On Sun, 8/8/10, Jeff Saremi jeffsar...@yahoo.com wrote:
From: Jeff Saremi jeffsar...@yahoo.com
Subject: Debugging plugins with gdb
To: gcc-h...@gcc.gnu.org
Date: Sunday, August 8, 2010, 9:52 AM
I'd like to step into my
On Wed, Aug 11, 2010 at 3:52 PM, Jeff Saremi jeffsar...@yahoo.com wrote:
Sending this to gcc since I got no help from sending it to gcc-help
Are you trying to debug gcc or cc1/cc1plus? If the former try running
with -v and seeing that cc1/cc1plus is involved and then debug
cc1/cc1plus instead.
On Wed, Aug 11, 2010 at 03:52:17PM -0700, Jeff Saremi wrote:
Trying to use break execute_x command in
add-symbol-file myplugin.so but neither of them work. The
first one complains that function not defined
Did it ask you if you want to make the breakpoint pending? If it did,
say yes.
Daniel/Andrew
thanks so much. I was using gdb version 7.1. So it understood deferred
breakpoints but as long as I started gdb with something like ~/bin/gcc it never
stopped in my function.
As soon as I switched to running gdb on cc1, it worked!
Now i can work on debugging the seg-fault i'm
--- Comment #1 from paolo dot carlini at oracle dot com 2010-08-11 07:06
---
Indeed, the library side of this is rather straightforward, we are already
implementing the FCD correctly (I also checked there no DRs or NBCs open):
templateclass _T1, class _T2
inline pairtypename
--- Comment #43 from paolo dot carlini at oracle dot com 2010-08-11 07:08
---
Ok, even more obscure ;) Can you further investigate? Possibly pinging somebody
knowledgeable about the specs? Before applying to the library the -nostdinc++
bits I'd like to make sure we fully understand the
--- Comment #7 from paolo dot carlini at oracle dot com 2010-08-11 07:26
---
Thanks for your feedback Ian. Now, I'm not sure which target maintainer to
suggest for powerpc-linux... David Edelsohn?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45053
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #15 from paolo at gcc dot gnu dot org 2010-08-11 08:50 ---
Subject: Bug 42925
Author: paolo
Date: Wed Aug 11 08:49:47 2010
New Revision: 163094
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163094
Log:
2010-08-11 Paolo Carlini paolo.carl...@oracle.com
PR
--- Comment #16 from paolo dot carlini at oracle dot com 2010-08-11 08:51
---
Done.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #8 from iains at gcc dot gnu dot org 2010-08-11 09:11 ---
(In reply to comment #7)
(In reply to comment #5)
-(hopefully) Andrew's analysis is correct (but, I guess I'd like to know
why it
fixed them ... )..
IIRC the issue with section anchors and the objective-c
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45251
--- Comment #2 from jakub at gcc dot gnu dot org 2010-08-11 09:27 ---
I don't see why any change is needed. If a function (or variable) isn't
defined in the current translation unit, then it necessarily has to be
accessible from outside of the translation unit containing it.
--
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-08-11 09:28 ---
I think that SLP doesn't handle reduction.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
$cat main.cc g++ -v g++ -o m main.cc
#include iostream
#include algorithm
#include fstream
#include iterator
using namespace std;
struct record
{
int date;
int key[5];
};
std::istream
operator ( std::istream lhs, record rhs )
{
lhs rhs.date;
lhs rhs.key[0];
=unicode
--enable-tls --disable-bootstrap --target=i686-pc-mingw32 --enable-shared
--enable-interpreter --disable-sjlj-exceptions
Thread model: win32
gcc version 4.6.0 20100811 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-fwhopr' '-v' '-mtune=generic' '-march=pentiumpro'
/usr/libexec/gcc/i686-pc-mingw32
--- Comment #1 from jojelino at gmail dot com 2010-08-11 09:57 ---
Created an attachment (id=21451)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21451action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45255
--- Comment #2 from jojelino at gmail dot com 2010-08-11 09:59 ---
(In reply to comment #1)
Created an attachment (id=21451)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21451action=view) [edit]
testcase
and it is resolved by changing __attribute__ ((dllimport)) to
--- Comment #1 from paolo dot carlini at oracle dot com 2010-08-11 10:03
---
This is plain invalid: you are constructing a temporary ofstream and then
hoping to pass it to a constructor taking a ref, not a const ref, cannot work.
--
paolo dot carlini at oracle dot com changed:
--- Comment #3 from steven at gcc dot gnu dot org 2010-08-11 10:17 ---
WHOPR involved, MEM_REF involved... Richi?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from iains at gcc dot gnu dot org 2010-08-11 10:21 ---
also on i686-darwin9, closing as fixed.
--
iains at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from iains at gcc dot gnu dot org 2010-08-11 10:22 ---
AFAICT from testing on cris-elf Xd from i686-darwin9 this is fixed.
--
iains at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from iains at gcc dot gnu dot org 2010-08-11 10:23 ---
AFAICT, from testing on cris-elf Xf from i686-darwin9 this is fixed.
--
iains at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from irar at il dot ibm dot com 2010-08-11 10:24 ---
(In reply to comment #6)
I think that SLP doesn't handle reduction.
Not all kinds of reduction. We handle
#a1 = phi a0, a2
#b1 = phi b0, b2
...
a2 = a1 + x
b2 = b1 + y
Here we also have:
#a1 = phi a0, a9
...
a2 =
--- Comment #4 from janus at gcc dot gnu dot org 2010-08-11 10:50 ---
Subject: Bug 44595
Author: janus
Date: Wed Aug 11 10:49:56 2010
New Revision: 163096
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163096
Log:
2010-08-11 Janus Weil ja...@gcc.gnu.org
PR
--- Comment #8 from dv at vollmann dot ch 2010-08-11 10:56 ---
Subject: Re: libgcc_s link command misses crtsavgpr_s
and crtresgpr_s for powerpc
@Ian:
I'm surprised that it doesn't work, as libgcc/config/rs6000/t-ppccomm includes
crtsavgpr.S and crtresgpr.S in LIB2ADD_ST. I would
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-08-11 10:59 ---
Well. I do not have access to i686-pc-mingw32-gcc and this seems related to
/* Return whether OP is a DECL whose address is function-invariant. */
bool
decl_address_invariant_p (const_tree op)
{
/* The
--- Comment #5 from janus at gcc dot gnu dot org 2010-08-11 11:01 ---
Fixed with r163096. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from rogerio at rilhas dot com 2010-08-11 11:20 ---
Created an attachment (id=21452)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21452action=view)
Preprocessed file (with example 2)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
--- Comment #13 from rogerio at rilhas dot com 2010-08-11 11:21 ---
Created an attachment (id=21453)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21453action=view)
Source file (example 2)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
--- Comment #14 from rogerio at rilhas dot com 2010-08-11 11:22 ---
No, you are not correct. The equivalent code to what I'm doing would be
something like:
int buffer[4]; // 16 bytes on stack
buffer[0]=(int)format
buffer[1]=(int)10
buffer[2]=(int)another_string
buffer[3]=(int)20
call
--- Comment #15 from rguenth at gcc dot gnu dot org 2010-08-11 11:37
---
(In reply to comment #14)
No, you are not correct. The equivalent code to what I'm doing would be
something like:
int buffer[4]; // 16 bytes on stack
buffer[0]=(int)format
buffer[1]=(int)10
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-08-11 11:41
---
Btw, just use vsnprintf.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
--- Comment #17 from redi at gcc dot gnu dot org 2010-08-11 11:55 ---
As already stated, what you are doing is not valid C or C++, the standards do
not guarantee the behaviour you are expecting w.r.t stack layout, and an
optimising C or C++ compiler follows the rules of the language
--- Comment #3 from pj dot pandit at yahoo dot co dot in 2010-08-11 12:15
---
DW_AT_external is meant to indicate whether a variable/function, that is
defined in the compilation unit, is accessible/visible from the outside of it
or not.
It's a subtle difference between `accessible
--- Comment #44 from iains at gcc dot gnu dot org 2010-08-11 12:32 ---
I do not think the current solution is complete/correct.
For 4.5.x and current trunk we still have a significant problem. (4.4.x
apparently still works, as of 4.4.5/r163091, at least for trivial cases)
[apollo is
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-08-11 12:33
---
We can also expand
__builtin_memcpy (local, param, 9);
to multiple copies based on src/dest alignment and size (similar to
store_by_pieces)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13954
--- Comment #4 from jakub at gcc dot gnu dot org 2010-08-11 12:46 ---
I don't see the standard saying that anywhere.
A DW_AT_external attribute, which is a flag, if the name of a variable is
visible outside of its enclosing compilation unit.
If the name of the subroutine described by
--- Comment #2 from wanng dot fenng at gmail dot com 2010-08-11 12:49
---
Subject: Re: data declaration parse error
On 08/11/2010 06:03 PM, paolo dot carlini at oracle dot com wrote:
--- Comment #1 from paolo dot carlini at oracle dot com 2010-08-11 10:03
---
This is
--- Comment #45 from andreast at gcc dot gnu dot org 2010-08-11 12:50
---
I no longer have time to work on this.
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-08-11 13:00
---
Subject: Bug 44555
Author: rguenth
Date: Wed Aug 11 12:59:47 2010
New Revision: 163098
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163098
Log:
2010-08-11 Richard Guenther rguent...@suse.de
PR
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-08-11 13:00
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jason at gcc dot gnu dot org 2010-08-11 13:06 ---
This result, while unfortunate, is not a bug; template argument deduction only
uses the type and lvalueness of the function argument (unsigned, lvalue) and
therefore deduces the type of __x to be unsigned. But an
--- Comment #18 from rogerio at rilhas dot com 2010-08-11 13:11 ---
Of course vsnprintf was my first choice, as you can see from the WIN32 part of
the code I sent you. In WIN32 I can use vsnprint in a very natural and
predictable way in format_indirect. In LINUX this cannot be used in
--- Comment #46 from howarth at nitro dot med dot uc dot edu 2010-08-11
13:14 ---
(In reply to comment #44)
I do not think the current solution is complete/correct.
Don't confuse the darwin9 and darwin10 unwinder issues. They are
different incompatiibilities with the darwin
--- Comment #14 from dave at hiauly1 dot hia dot nrc dot ca 2010-08-11
13:15 ---
Subject: Re: [4.6 Regression]: gcc.dg/tls/alias-1.c
AFAICT, from testing on cris-elf Xf from i686-darwin9 this is fixed.
It also appears fixed on hppa64-hp-hpux11.11.
--
--- Comment #47 from howarth at nitro dot med dot uc dot edu 2010-08-11
13:42 ---
Also from a the darwin unwinder maintainer...
I took a look at the bug report you made. Right off, I can tell that
the problem is that _Unwind_FindEnclosingFunction() is not
implemented. Well,
--- Comment #19 from redi at gcc dot gnu dot org 2010-08-11 14:10 ---
(In reply to comment #18)
Of course vsnprintf was my first choice, as you can see from the WIN32 part of
the code I sent you. In WIN32 I can use vsnprint in a very natural and
predictable way in format_indirect. In
I'll attach a testcase, which shows a missed simplification at tree level:
D.2276_42 = i_53 + 1;
D.2277_43 = D.2276_42 * 32;
iftmp.3_55 = __fswab32 (xb_54);
__asm__(clz %0, %1 : =r ret_56 : r iftmp.3_55 : cc);
ret_58 = 32 - ret_56;
ret_59 = D.2277_43 - ret_58;
In effect, the
--- Comment #1 from bernds at gcc dot gnu dot org 2010-08-11 15:19 ---
Created an attachment (id=21454)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21454action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45256
--- Comment #48 from howarth at nitro dot med dot uc dot edu 2010-08-11
15:23 ---
These messages from the Apple developers also are useful in explaining the
situation...
http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025894.html
--- Comment #6 from steven at gcc dot gnu dot org 2010-08-11 15:27 ---
I don't see how the compiler can know that this input causes an infinite loop.
This is just the halting problem. Not a bug in the sense that there is anything
to fix.
--
steven at gcc dot gnu dot org changed:
The reduced code below used to successfully compile on previous releases of
GCC. I can get this code to compile with GCC 4.1.2, but when I try it with GCC
4.3.4, I get the following error message:
a.c: In function 'main':
a.c:4: error: storage size of 'test' isn't known
Clearly, this is happening
--- Comment #20 from matz at gcc dot gnu dot org 2010-08-11 16:10 ---
A conforming variant of what you probably are trying to code is:
#include stdio.h
#include stdarg.h
void format_indirect(char* dst_buffer, size_t
--- Comment #1 from jakub at gcc dot gnu dot org 2010-08-11 16:11 ---
This has nothing to do with GCC, netinet/in.h is a glibc header, not GCC
header. And the guarding of that type with __USE_GNU is intentional AFAIK.
Just use -D_GNU_SOURCE.
--
jakub at gcc dot gnu dot org changed:
Currently libjava is being improperly linked (PR java/41991) due to the
presence of -lm and -lpthreads on the shared library linkages. This causes
libSystem.dylib to be pushed to the front of the linkage and breaks the logic
used by libgcc_ext. We should add and set defines for
What about removing those in the driver? This way it works correctly
for other makefiles too?
On Aug 11, 2010, at 9:30 AM, howarth at nitro dot med dot uc dot edu
gcc-bugzi...@gcc.gnu.org wrote:
Currently libjava is being improperly linked (PR java/41991) due to
the
presence of -lm and
--- Comment #1 from pinskia at gmail dot com 2010-08-11 17:03 ---
Subject: Re: New: linkage on -lm and -lpthread should be purged from darwin
build
What about removing those in the driver? This way it works correctly
for other makefiles too?
On Aug 11, 2010, at 9:30 AM, howarth
--- Comment #21 from rogerio at rilhas dot com 2010-08-11 17:04 ---
Subject: Re: Indirect variable parameters sometimes cause
segmentation fault
Yes, I was using that solution up to 2003, but then I stopped
using it in favour of the more confortable format (the one I
showed you)
--- Comment #22 from rogerio at rilhas dot com 2010-08-11 17:15 ---
(In reply to comment #19)
(In reply to comment #18)
Of course vsnprintf was my first choice, as you can see from the WIN32 part
of
the code I sent you. In WIN32 I can use vsnprint in a very natural and
--- Comment #12 from sje at cup dot hp dot com 2010-08-11 17:20 ---
I have a slightly smaller test case for this, but it still needs to bootstrap
to fail. If I bootstrap just the C part of the compiler I get a successful
build (with partial inlining enabled) but when I use that
--- Comment #7 from paolo dot carlini at oracle dot com 2010-08-11 17:22
---
The solution involves clearing eofbit first, see US 137 / US 139. Maybe we
should prototype it before Batavia.
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #13 from sje at cup dot hp dot com 2010-08-11 17:23 ---
Created an attachment (id=21455)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21455action=view)
compressed builtins.c.041t.fnsplit dump file
I believe that the splitting and inlining of gimple_call_num_args into
--- Comment #1 from paolo dot carlini at oracle dot com 2010-08-11 17:25
---
Andreas, can you have a look to this? I'm recategorizing it as target, I have
never seen anything similar on Linux (or anywhere else for that matter)
--
paolo dot carlini at oracle dot com changed:
--- Comment #2 from schwab at linux-m68k dot org 2010-08-11 17:30 ---
Obviously the compiler is not working. That needs config.log to tell anything.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45084
--- Comment #3 from paolo dot carlini at oracle dot com 2010-08-11 17:32
---
Ok, thanks. Let's ask for feedback then.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #23 from pinskia at gcc dot gnu dot org 2010-08-11 17:49
---
First off I already mentioned what is undefined in this example in comment #11.
The part of the standard that mentions about arrays. And how the address of a
scalar is considered an array of size 1. I don't
--- Comment #24 from redi at gcc dot gnu dot org 2010-08-11 17:57 ---
(In reply to comment #22)
If GCC supports cdecl on a x86 plaform then it must support the packing of
parameters as defined for x86 (it is not standardize that I know of, but it is
well defined). I sugest reading
--- Comment #9 from jakub at gcc dot gnu dot org 2010-08-11 18:44 ---
Apparently some KVM versions claim to be GenuineIntel family 6 model 6 with lm,
but not ssse3, see
https://bugzilla.redhat.com/show_bug.cgi?id=620562
Perhaps the has_longmode - core2 test should be restored...
--
--- Comment #10 from hjl dot tools at gmail dot com 2010-08-11 19:12
---
(In reply to comment #9)
Apparently some KVM versions claim to be GenuineIntel family 6 model 6 with
lm,
but not ssse3, see
https://bugzilla.redhat.com/show_bug.cgi?id=620562
Perhaps the has_longmode - core2
--- Comment #8 from janus at gcc dot gnu dot org 2010-08-11 19:30 ---
Both comment #0 and comment #6 work for me without ICE on 4.6 trunk r163095.
Closing as fixed.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--
Summary: [4.5/4.6 Regression
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot
--- Comment #1 from jakub at gcc dot gnu dot org 2010-08-11 19:42 ---
/* PR debug/45259 */
/* { dg-do compile } */
/* { dg-options -g -O2 -fpic -w { target fpic } } */
struct S { void (*bar) (long); };
struct T { struct S *t; };
int w;
extern int baz (int);
void
foo (int x, int u,
--- Comment #25 from rogerio at rilhas dot com 2010-08-11 19:51 ---
(In reply to comment #24)
(In reply to comment #22)
If GCC supports cdecl on a x86 plaform then it must support the packing of
parameters as defined for x86 (it is not standardize that I know of, but it
is
--- Comment #14 from rguenth at gcc dot gnu dot org 2010-08-11 19:51
---
I will have a look tomorrow.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #26 from pinskia at gcc dot gnu dot org 2010-08-11 19:54
---
This code does not compile in GCC, and so is not portable.
No it is not portable because that code is just plain invalid; though MS
accepts it as it is implementing something called move constructor as an
--- Comment #8 from mr dot chr dot schmidt at online dot de 2010-08-11
20:00 ---
(In reply to comment #7)
(In reply to comment #6)
Created an attachment (id=21434)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21434action=view) [edit]
gdb backtrace
Hmm, GGC strikes
--- Comment #9 from mr dot chr dot schmidt at online dot de 2010-08-11
20:01 ---
Created an attachment (id=21456)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21456action=view)
another testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45201
--- Comment #2 from lennox at cs dot columbia dot edu 2010-08-11 20:01
---
This problem still exists in GCC 4.5.1.
--
lennox at cs dot columbia dot edu changed:
What|Removed |Added
--- Comment #27 from rogerio at rilhas dot com 2010-08-11 20:04 ---
(In reply to comment #26)
This code does not compile in GCC, and so is not portable.
No it is not portable because that code is just plain invalid; though MS
accepts it as it is implementing something called move
--- Comment #28 from rogerio at rilhas dot com 2010-08-11 20:07 ---
(In reply to comment #23)
First off I already mentioned what is undefined in this example in comment
#11.
The part of the standard that mentions about arrays. And how the address of
a
scalar is considered an
See https://wwws.clamav.net/bugzilla/show_bug.cgi?id=2190
$ g++-4.5 -fprefetch-loop-arrays TargetLowering.ii -c -O2
../../../../clamav-devel/libclamav/c++/llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp:
In member function void llvm::TargetLowering::computeRegisterProperties():
--- Comment #1 from edwintorok at gmail dot com 2010-08-11 20:27 ---
Created an attachment (id=21457)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21457action=view)
TargetLowering.ii
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45260
--- Comment #2 from jakub at gcc dot gnu dot org 2010-08-11 20:30 ---
Created an attachment (id=21458)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21458action=view)
gcc46-pr45259.patch
Untested fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45259
--- Comment #11 from hjl dot tools at gmail dot com 2010-08-11 20:31
---
Maybe we can improve the unknown processor support:
1. For 32bit, use i686 + -mSSEx.
2. For 64bit, use x86_64 + -mSSEx.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44046
--- Comment #29 from rguenth at gcc dot gnu dot org 2010-08-11 20:33
---
(In reply to comment #28)
(In reply to comment #23)
First off I already mentioned what is undefined in this example in comment
#11.
The part of the standard that mentions about arrays. And how the
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|g++4.5: -prefetch-loop- |[4.5/4.6 Regression] g++4.5:
|arrays internal
--- Comment #30 from rogerio at rilhas dot com 2010-08-11 20:58 ---
Really? Your comment #11 has so many mistakes in it that maybe you are the one
who should learn a little bit more on C.
The ABI is not of concern here really. The issue comes down to you have:
char *a;
char **b = a;
1 - 100 of 156 matches
Mail list logo
