--- 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):
template
inline pair::__type,
typen
--- 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 re
--- 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=gcc&view=rev&rev=163094
Log:
2010-08-11 Paolo Carlini
PR libstdc++/42925
--- 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
Statu
--- 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 objec
--
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.
--
jaku
--- 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
#include
#include
#include
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];
lhs >> rhs.k
=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
--- 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=21451&action=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=21451&action=view) [edit]
> testcase
>
and it is resolved by changing __attribute__ ((dllimport)) to __attr
--- 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
#b1 = phi
...
a2 = a1 + x
b2 = b1 + y
Here we also have:
#a1 = phi
...
a2 = a1 + x
...
a3 = a
--- 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=gcc&view=rev&rev=163096
Log:
2010-08-11 Janus Weil
PR fortran/44595
* intr
--- 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 conditio
--- 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=21452&action=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=21453&action=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
> buffer[2
--- 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 stan
--- 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 from
--- 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, ¶m, 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 b
--- 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=gcc&view=rev&rev=163098
Log:
2010-08-11 Richard Guenther
PR c/44555
--- 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
Status|ASSIGNE
--- 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 ref
--- 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 unwinder
--- 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.
--
http://gcc.gnu.org/bugzill
--- 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. Wel
--- 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"
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=21454&action=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
http://lists.cs.uiuc.edu/pipermail/llvmdev/200
--- 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
#include
void format_indirect(char* dst_buffer, size_t dst_buffer_size_b
--- 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 HAVE_LIBSYSTEM_PTHRE
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"
wrote:
Currently libjava is being improperly linked (PR java/41991) due to
the
presence of -lm and -lpthreads on the share
--- 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 a
--- 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) beca
--- 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 compiler
--- 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=21455&action=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 have
--- 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 readi
--- 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 ->
--- 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 gnu
--- 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, ch
--- 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
>
--- 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
exten
--- 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=21434&action=view) [edit]
> > gdb backtrace
> >
>
> Hmm, GGC st
--- 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=21456&action=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 a
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():
../../../../clam
--- 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=21457&action=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=21458&action=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 compi
--- 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
--- Comment #31 from pinskia at gcc dot gnu dot org 2010-08-11 21:02
---
>Didn't you understand the equivalent code would be:
No, as the variables act the same if they are automatic variables or arguments.
there is no different between the two. That has been my point from the
beginni
--- Comment #32 from rogerio at rilhas dot com 2010-08-11 21:12 ---
(In reply to comment #31)
> >Didn't you understand the equivalent code would be:
> No, as the variables act the same if they are automatic variables or
> arguments.
> there is no different between the two. That has be
--- Comment #33 from pinskia at gcc dot gnu dot org 2010-08-11 21:16
---
Yes GCC implements that ABI and &argument will get you the address of that
argument. But that does not deter from that &argument will produce an array of
size 1 rather than what you want which is the rest of the a
--- Comment #79 from jasmin at revisionfx dot com 2010-08-11 21:26 ---
> I am not exactly sure how to report a bug here
Find the answer here:
https://bugs.launchpad.net/sbcl/+bug/539632
" Compile with -mpreferred-stack-boundary=2. This will force GCC to compile
code that adheres to
--- Comment #34 from redi at gcc dot gnu dot org 2010-08-11 21:27 ---
(In reply to comment #25)
> In other words my code is not portable because GCC is not doing what it
> should.
> GCC causes code not to be portable a lot of times, like in the following case
> (which does not compile b
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-08-11 21:41 ---
Hmm, I don't think this is correct as const volatile is a bit weird. It means
a read must happen but it does not say order compared to other volatile
variables (or at least I think).
--
http://gcc.gnu.org/bugzi
--- Comment #35 from rogerio at rilhas dot com 2010-08-11 22:16 ---
(In reply to comment #33)
> Yes GCC implements that ABI and &argument will get you the address of that
> argument.
If that is so then the format parameter will be placed at some address X, param
1 at address X+4, param
--- Comment #36 from rguenth at gcc dot gnu dot org 2010-08-11 22:27
---
(In reply to comment #35)
> (In reply to comment #33)
> > Yes GCC implements that ABI and &argument will get you the address of that
> > argument.
>
> If that is so then the format parameter will be placed at some
--- Comment #37 from rguenth at gcc dot gnu dot org 2010-08-11 22:30
---
Btw, 6.5.6/7 "For the purposes of these operators, a pointer to an object that
is
not an element of an array behaves the same as a pointer to the first element
of an array of length one with the type of the object
--- Comment #38 from rogerio at rilhas dot com 2010-08-11 22:35 ---
(In reply to comment #34)
> (In reply to comment #25)
> > In other words my code is not portable because GCC is not doing what it
> > should.
> > GCC causes code not to be portable a lot of times, like in the following
--- Comment #39 from rogerio at rilhas dot com 2010-08-11 22:37 ---
(In reply to comment #37)
> Btw, 6.5.6/7 "For the purposes of these operators, a pointer to an object that
> is
> not an element of an array behaves the same as a pointer to the first element
> of an array of length one
--- Comment #40 from rguenth at gcc dot gnu dot org 2010-08-11 22:48
---
(In reply to comment #39)
> (In reply to comment #37)
> > Btw, 6.5.6/7 "For the purposes of these operators, a pointer to an object
> > that
> > is
> > not an element of an array behaves the same as a pointer to t
--- Comment #41 from rogerio at rilhas dot com 2010-08-11 22:50 ---
> It doesn't make it an array in the C sense.
What is an array in the C sense? Isn't it a sequence of entries? Is there any
other concept to go along with it that allows PTR4 to be set to any other value
than X? If so,
When configuration script of avr-libc tries to check if gcc has support for
Attiny2313A it doesn't indicate any failure even if it really doesn't support
it. I found about that trying to build avr toolchain using this version of gcc.
Here is a part of config.log:
configure:5374: checking if avr-g
--- Comment #42 from rogerio at rilhas dot com 2010-08-11 22:51 ---
> It doesn't make it an array in the C sense.
What is an array in the C sense? Isn't it a sequence of entries? Is there any
other concept to go along with it that allows PTR4 to be set to any other value
than X? If so,
--- Comment #43 from rogerio at rilhas dot com 2010-08-11 22:52 ---
> It doesn't make it an array in the C sense.
What is an array in the C sense? Isn't it a sequence of entries? Is there any
other concept to go along with it that allows PTR4 to be set to any other value
than X? If so,
1 - 100 of 140 matches
Mail list logo
