--- Comment #9 from howarth at nitro dot med dot uc dot edu 2010-08-12
05:52 ---
The remove_outfile.diff patch has the additional advantage of also eliminating
the gcc.dg/torture/builtin-math-7.c failures.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45258
--- Comment #5 from pj dot pandit at yahoo dot co dot in 2010-08-12 05:30
---
Doesn't the wording - visible outside of its containing compilation unit - ring
any bells?
Secondly, for variables and functions that are not defined in the compilation
unit, it doesn't make sense to mark the
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2010-08-12
04:12 ---
These patches also appear to clean up the linkages on libstdc++.6.dylib and
libgfortran.3.dylib so that now libSystem is properly at the end of the
linkage. It will be interesting to see if these patches he
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2010-08-12
04:02 ---
The combination of the remove_outfile.diff and libjava_lm_lpthread_cleanup.diff
patches eliminates the incorrect linkage position of libSystem in the libjava
shared libraries on darwin. Will regression test
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2010-08-12
04:00 ---
Created an attachment (id=21467)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21467&action=view)
patch to eliminate remaining -lm and -lpthread usage in libjava build
--
http://gcc.gnu.org/bugzi
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2010-08-12
03:42 ---
Created an attachment (id=21466)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21466&action=view)
final patch to add remove-outfile support for darwin.
--
howarth at nitro dot med dot uc dot edu c
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2010-08-12
03:41 ---
Opps. Forgot about -ldl.
--
howarth at nitro dot med dot uc dot edu changed:
What|Removed |Added
-
A bug? maybe...
$ avr-gcc -v
Using built-in specs.
Target: avr
Configured with: ../src/configure -v --enable-languages=c,c++
--prefix=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man
--bindir=/usr/bin --libexecdir=/usr/lib --libdir=/usr/lib
--enable-shared --with-system-zlib --enable-lon
--- Comment #2 from hjl dot tools at gmail dot com 2010-08-12 03:14 ---
It failed for me with gcc 4.2 and 4.3.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
--
gcc at d-silva dot org changed:
What|Removed |Added
Severity|blocker |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45263
--- Comment #55 from rogerio at rilhas dot com 2010-08-12 02:12 ---
Created an attachment (id=21465)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21465&action=view)
Snapshot 4 - Showing incorrect value for PTR4
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
--- Comment #54 from rogerio at rilhas dot com 2010-08-12 02:12 ---
Created an attachment (id=21464)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21464&action=view)
Snapshot 3 - Breakpoint before calling "format_indirect" (showing dump for
$ebp+0x10)
--
http://gcc.gnu.org/bug
--- Comment #53 from rogerio at rilhas dot com 2010-08-12 02:10 ---
Created an attachment (id=21463)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21463&action=view)
Snapshot 2 - Inside "format_direct" to show cdecl ABI parameter packing
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #52 from rogerio at rilhas dot com 2010-08-12 02:09 ---
Created an attachment (id=21462)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21462&action=view)
Snapshot 1 - Breakpoint before calling "format_direct"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
--- Comment #51 from rogerio at rilhas dot com 2010-08-12 02:08 ---
Given all that we have established in our conversation I think I can now
demonstrate the bug easily.
The entry to the "format_direct" call (in the main function, just before
entering the "format_direct" function) disass
--
gcc at d-silva dot org changed:
What|Removed |Added
Severity|normal |blocker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45263
--- Comment #2 from gcc at d-silva dot org 2010-08-12 01:22 ---
Created an attachment (id=21461)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21461&action=view)
Patch to gcc/config/avr/libgcc.S saving r20 onto the stack before calling
constructors
--
http://gcc.gnu.org/bugzil
--- Comment #1 from gcc at d-silva dot org 2010-08-12 01:21 ---
Created an attachment (id=21460)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21460&action=view)
Test case showing that register r20 is clobbered when calling a constructor
--
http://gcc.gnu.org/bugzilla/show_bug
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|blocker |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45263
In gcc/config/avr/libgcc.S, revision 143306, a change to __do_global_ctors &
__do_global_dtors was made which makes use of register r20.
This register can be used to pass parameters to the constructors, but it is not
pushed/popped from the stack, so it will get clobbered if a constructor uses
that
--- Comment #6 from paolo dot carlini at oracle dot com 2010-08-12 01:09
---
Working on this too.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2010-08-12
00:57 ---
Note that while the proposed patch properly parses out -lm and -lpthread from
linkages done with the compiler, this is insufficient to solve the problems
with libjava. The hard coded use of -lm in libjava/M
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2010-08-12
00:54 ---
Created an attachment (id=21459)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21459&action=view)
proposed patch to add and use remove-outfile
The proposed patch implements remove-outfile to parse ou
--- Comment #3 from changpeng dot fang at amd dot com 2010-08-12 00:38
---
(In reply to comment #2)
> It was caused by revision 153878:
>
> http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00094.html
>
I think the same patch was also committed to 4.4 branch.
Maybe some prefetch work(s) in 4.
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-08-12 00:44 ---
Confirmed, works in 4.3.2.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
For the program below, gcc optimization produces wrong result. g++ does the
same for a cpp version of this program.
gcc 1.c -Wall
1
0
1
gcc 1.c -Wall -O
./a.out
1
1
1
The program is as following
#include
int f(unsigned int x)
{
return x>>31||(-x)>>31;
}
int main()
{
printf("%d
--- Comment #2 from hjl dot tools at gmail dot com 2010-08-11 23:58 ---
It was caused by revision 153878:
http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00094.html
and disappeared with revision 159514:
http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00566.html
I am not if it really fixed the bug.
--- Comment #4 from roland at redhat dot com 2010-08-11 23:52 ---
The compiler is being internally inconsistent here. It somtimes decides that
__attribute__((section ("name"))) means a "name" section in a COMDAT group, and
sometimes decides that it means just a plain "name" section. If
--- Comment #50 from rogerio at rilhas dot com 2010-08-11 23:43 ---
(In reply to comment #48)
> >No, cdecl states that &x+1==&y, and that &x+2==&z.
> Maybe the ABI says that but that does not mean you can access "&x + 1" to get
> to &y at least in a "standard" defined way. That is the w
--- Comment #49 from rogerio at rilhas dot com 2010-08-11 23:22 ---
(In reply to comment #40)
> (In reply to comment #39)
> > (In reply to comment #37)
> Why do you think GCC makes it the address of a copy?
Well, the first observation was dumpung the memory around the returned address
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-08-11 23:20 ---
(In reply to comment #2)
> You're right, the fprintf function should be correct. Moreover, no only the
> attiny2313A is indicated as "result: yes" and is not supported.
What I am trying to say that fprintf function
--- Comment #2 from rootolini at gmail dot com 2010-08-11 23:17 ---
(In reply to comment #1)
> fprintf (stderr, "unknown MCU '%s' specified\nKnown MCU names:\n",
>avr_mcu_name);
>
> That should most likely be an error instead of just a fprintf.
>
You're right, th
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-08-11 23:11 ---
(In reply to comment #4)
> I don't see that the const qualifier should be relevant: doesn't it simply
> indicate that the code is not permitted to write through that lvalue?
That's true which is why I think this bug
--- Comment #48 from pinskia at gcc dot gnu dot org 2010-08-11 22:58
---
>No, cdecl states that &x+1==&y, and that &x+2==&z.
Maybe the ABI says that but that does not mean you can access "&x + 1" to get
to &y at least in a "standard" defined way. That is the whole point of it
acting a
--- Comment #47 from rogerio at rilhas dot com 2010-08-11 22:55 ---
(In reply to comment #41)
(please disregard this duplication)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
--- Comment #4 from bigotp at acm dot org 2010-08-11 22:54 ---
I don't see that the const qualifier should be relevant: doesn't it simply
indicate that the code is not permitted to write through that lvalue? (FWIW,
the real code uses a memory mapped address and the const qualifier was p
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-08-11 22:54 ---
fprintf (stderr, "unknown MCU '%s' specified\nKnown MCU names:\n",
avr_mcu_name);
That should most likely be an error instead of just a fprintf.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #46 from rogerio at rilhas dot com 2010-08-11 22:54 ---
(In reply to comment #42)
(please disregard this duplication)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
--- Comment #45 from rogerio at rilhas dot com 2010-08-11 22:54 ---
(In reply to comment #43)
(please disregard this duplication)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
--- Comment #44 from rogerio at rilhas dot com 2010-08-11 22:53 ---
(In reply to comment #36)
> (In reply to comment #35)
> > (In reply to comment #33)
> 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 co
--- 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,
--- 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,
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 #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,
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
--
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 #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
--- 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 #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 #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
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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
--
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 #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
--
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
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
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
--- 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:
--- 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
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 #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:
--- 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 #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
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 #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"
--- 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 #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 #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
1 - 100 of 140 matches
Mail list logo
