Hi all,
I'd like to know if there is any way, even using gcc extensions,
to syntactically catch what is the return type (and the list
of formal arguments) of a function in which I am.
Also, in case there is no way, I'd like to know how difficult would
be to introduce a couple of keywords, like
Adam Nemet ane...@caviumnetworks.com writes:
struct s
{
char a:4;
char b:8;
char c:4;
} __attribute__ ((packed))
is 3 bytes long because b gets pushed to the next byte boundary.
Sounds like a bug.
The reason for this behavior is that finish_struct does not propagate packed
to
On Fri, Jan 16, 2009 at 4:19 PM, Ian Lance Taylor i...@google.com wrote:
Adam Nemet ane...@caviumnetworks.com writes:
struct s
{
char a:4;
char b:8;
char c:4;
} __attribute__ ((packed))
is 3 bytes long because b gets pushed to the next byte boundary.
Sounds like a bug.
The
Hi,
I am working on a gcc-4.1.2 and I would like to know how the prologue
length from a function can be calculated.
Indeed I am trying to evaluate what needs to be done to implement SEH and
one requirement is to be able to
fill a structure holding information like function length and prologue
Vincent R. foru...@smartmobili.com writes:
I am working on a gcc-4.1.2 and I would like to know how the prologue
length from a function can be calculated.
The question is not well formed. The instructions which are part of
the prologue (e.g., saving callee-saved registers onto the stack) can
Hi,
I am trying to implement
unsigned long long __rdtsc (void);
for RDTSC as an intrinsic. It is easy to do it with asm statement.
But I am having a hard time to implement it as a gcc builtin.
The main problem is there is no input. It is impossible to write
a proper RTL for it. Any
Sent from my iPhone
On Jan 16, 2009, at 9:23 AM, H.J. Lu hjl.to...@gmail.com wrote:
Hi,
I am trying to implement
unsigned long long __rdtsc (void);
for RDTSC as an intrinsic. It is easy to do it with asm statement.
But I am having a hard time to implement it as a gcc builtin.
The main
On Fri, Jan 16, 2009 at 09:35:33AM -0800, Andrew Thomas Pinski wrote:
On Jan 16, 2009, at 9:23 AM, H.J. Lu hjl.to...@gmail.com wrote:
Hi,
I am trying to implement
unsigned long long __rdtsc (void);
for RDTSC as an intrinsic. It is easy to do it with asm statement.
But I am having a hard
On Fri, Jan 16, 2009 at 11:35 AM, Jack Lloyd ll...@randombit.net wrote:
According to the info docs, the Alpha has __builtin_alpha_rpcc which
doesn't take any inputs either, and should just call rpcc much as an
rdtsc intrinsic would, so it may provide a more direct model.
(define_insn
On Fri, 16 Jan 2009 08:37:20 -0800, Ian Lance Taylor i...@google.com
wrote:
Vincent R. foru...@smartmobili.com writes:
I am working on a gcc-4.1.2 and I would like to know how the prologue
length from a function can be calculated.
The question is not well formed. The instructions which
On Fri, Jan 16, 2009 at 12:47 PM, Andrew Pinski pins...@gmail.com wrote:
On Fri, Jan 16, 2009 at 11:35 AM, Jack Lloyd ll...@randombit.net wrote:
According to the info docs, the Alpha has __builtin_alpha_rpcc which
doesn't take any inputs either, and should just call rpcc much as an
rdtsc
On Fri, Jan 16, 2009 at 1:28 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Fri, Jan 16, 2009 at 12:47 PM, Andrew Pinski pins...@gmail.com wrote:
On Fri, Jan 16, 2009 at 11:35 AM, Jack Lloyd ll...@randombit.net wrote:
According to the info docs, the Alpha has __builtin_alpha_rpcc which
doesn't take
Vincent R. foru...@smartmobili.com writes:
To locate appropriate handlers when an exception occurs in Win32
environments other than x86,
Note that as far as I know, gcc only supports win32 for ARM and x86
(and x86_64, I guess, or maybe that is win64). So I assume you are
talking about ARM.
On Fri, 16 Jan 2009 14:13:58 -0800, Ian Lance Taylor i...@google.com
wrote:
Vincent R. foru...@smartmobili.com writes:
To locate appropriate handlers when an exception occurs in Win32
environments other than x86,
Note that as far as I know, gcc only supports win32 for ARM and x86
(and
Snapshot gcc-4.4-20090116 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090116/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
It's not my turn to send a status report, but as I plan doing a release
candidate for GCC 4.3.3 soon I thought a status report for that would
be in order.
Status
==
The GCC 4.3 branch is now frozen in preparation for a release candidate
for the GCC 4.3.3 release. When the branch is
On Fri, Jan 16, 2009 at 3:03 PM, Richard Guenther rguent...@suse.de wrote:
It's not my turn to send a status report, but as I plan doing a release
candidate for GCC 4.3.3 soon I thought a status report for that would
be in order.
Status
==
The GCC 4.3 branch is now frozen in
On Fri, 16 Jan 2009, H.J. Lu wrote:
On Fri, Jan 16, 2009 at 3:03 PM, Richard Guenther rguent...@suse.de wrote:
It's not my turn to send a status report, but as I plan doing a release
candidate for GCC 4.3.3 soon I thought a status report for that would
be in order.
Status
==
Vincent R. foru...@smartmobili.com writes:
No you are right, prologue definition in my context is :
Typically, a prolog segment contains separate sequences of instructions
that perform the following tasks:
* Allocate a stack frame.
* Save incoming argument registers.
* Set up
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2009-01-16
08:14 ---
Regressing r143152 from current gcc trunk also eliminates the problem
confirming that commit is the origin of the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-16 09:23 ---
I think you should simply do the check for an indirect base only if the folding
of the view-convert-expr ended up in a view-convert-expr. Playing with
alias-sets
here will still cause these nested v-c-es with
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-16 09:27 ---
If you wouldn't generate a V_C_E for *(float*)sv-i it would just work.
IMHO this should be invalid gimple anyway, as you V_C_E a register type but
the V_C_E argument is not a register. Thus valid gimple would be
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-01-16 09:34
---
Do we have a small testcase?
VIEW_CONVERT_EXPRunion u_u64(c64_76).u.lo32.u.lo16.u.lo8 = D.1947_8;
indeed looks funny (it's a partial def of a register).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38745
--- Comment #4 from rguenther at suse dot de 2009-01-16 09:36 ---
Subject: Re: missing FRE with
VIEW_CONVERT_EXPR
On Fri, 16 Jan 2009, pinskia at gcc dot gnu dot org wrote:
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-01-16 02:33
---
Mine. Simple patch which
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-01-16 09:42 ---
I tried to reproduce this on i686-linux without success (-O3 -fPIC -mfpmath=sse
-msse2 -m32).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
--- Comment #5 from janus at gcc dot gnu dot org 2009-01-16 09:42 ---
Further test cases:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/e0d04d755453a2a5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36704
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-01-16 09:57 ---
I think this boils down to the usual POINTER_PLUS fallout.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38856
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-16 10:00 ---
This is at most a documentation problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38864
--- Comment #10 from dominiq at lps dot ens dot fr 2009-01-16 10:00 ---
I don't see any problem on powerpc-apple-darwin9, but I confirm it on
i686-apple-darwin9 on 32 bit mode. The problem disappear with either -m64
and/or -fno-pic.
--
--- Comment #3 from jakub at gcc dot gnu dot org 2009-01-16 11:21 ---
-O2 -fno-tree-pre works. tree_could_trap_p is true for integer division by
non-constant (or 0), but we don't seem to have stmt_could_trap_p. Perhaps it
should be added and PRE should considfer it? In rtl land,
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-01-16 11:41 ---
Optimal would be to check this at insertion time, a quick fix is to adjust
compute_avail to not consider trapping expressions.
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
Sent from my iPhone
On Jan 16, 2009, at 1:57 AM, rguenth at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-01-16
09:57 ---
I think this boils down to the usual POINTER_PLUS fallout.
It failed in 4.1 also so nope
--- Comment #6 from pinskia at gmail dot com 2009-01-16 11:46 ---
Subject: Re: loop iv detection failure
Sent from my iPhone
On Jan 16, 2009, at 1:57 AM, rguenth at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #5 from rguenth at gcc dot gnu dot org
I just tried to compile this file with the GNU C compiler
version 4.4 snapshot 20090109 using valgrind and the flags
-O3 march=native on a amd64 box.
The debug output was
==20395== Invalid read of size 2
==20395==at 0xAFDA6E: T.911 (ira-costs.c:590)
==20395==by 0xAFE0F0: T.910
--- Comment #10 from janus at gcc dot gnu dot org 2009-01-16 12:04 ---
Subject: Bug 38152
Author: janus
Date: Fri Jan 16 12:03:51 2009
New Revision: 143430
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143430
Log:
2009-01-16 Janus Weil ja...@gcc.gnu.org
PR
taking into account the following program
-
class tester {
public:
int i;
void foo() {}
};
int main()
{
tester().foo();
tester().i = 10;
return 0;
}
-
The C++
--- Comment #1 from stefan dot constantin at gmail dot com 2009-01-16
12:07 ---
Sorry for not mentioning this earlier,
the sample program provide compiles without error or warning with
g++ -Wall.
I expected the compiler to error on the line tester().i = 10; because such a
construct
--- Comment #11 from janus at gcc dot gnu dot org 2009-01-16 12:30 ---
This PR can be closed, provided there are no remaining issues on darwin9 (see
comment #4 and #5). I cannot check this myself (since I don't have access to a
darwin system), but maybe Dominique can?
--
janus at
--- Comment #7 from jakub at gcc dot gnu dot org 2009-01-16 12:42 ---
The correct testcase is IMHO:
void
baz (int v)
{
unsigned a = (v == 1) ? 1 : 2;
if (__builtin_constant_p (a))
asm volatile (# constant %0 :: i (a));
else
asm volatile (# register %0 :: r (a));
}
For
--- Comment #8 from jakub at gcc dot gnu dot org 2009-01-16 12:49 ---
Yes, it does. Going to bootstrap/regtest it now.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-01-16 13:20 ---
Now it does. See PR38835.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-01-16 13:35 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-16 13:36 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from dave dot korn dot cygwin at gmail dot com 2009-01-16
13:41 ---
(In reply to comment #5)
If you look at the (static) libgcc.a, when shared libs are enabled, it
contains only symbols that are not exported from the shared dll. Only the
'API-stable' symbols are
--- Comment #6 from dave dot korn dot cygwin at gmail dot com 2009-01-16
13:43 ---
This bug is fixed and should be closed now. A new PR, bug 37660, has been
created for the separate issue in comment 4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37915
While comparing list of gcc 4.3 and 4.4 library exported symbols, I've
discovered that libgfortran.so.3 dropped
__iso_c_binding_c_f_procpointer@@GFORTRAN_1.0
but hasn't changed SONAME. That's an ABI break. Could we get the symbol back
for compatibility with gfortran 4.3?
--
--- Comment #1 from hjl dot tools at gmail dot com 2009-01-16 14:18 ---
Where is the input file?
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
While comparing list of exported symbols, libgcj_bc.so.1 hasn't dropped any
symbols from 4.3 (correct, hasn't changed SONAME), but libgcj.so.10 dropped
_Jv_CreateJavaVM and _Jv_GetStringChars symbols compared to libgcj.so.9.
That wouldn't normally be an issue (they have different SONAME), but in
--- Comment #2 from jakub at gcc dot gnu dot org 2009-01-16 14:27 ---
Also for -march=native you should really post what -fverbose-asm tells you has
been selected for -march and other option (and you should retry with those
options instead of -march=native).
--
--- Comment #3 from jv244 at cam dot ac dot uk 2009-01-16 14:38 ---
(In reply to comment #2)
Also for -march=native you should really post what -fverbose-asm tells you has
been selected for -march and other option (and you should retry with those
options instead of -march=native).
I'm trying to compile boost 1.37.0 on Slackware 12.1 and get an internal
compiler error on trying to compile comp_ellint_1l.cpp. I have Slackware's
stock gcc, which is 4.2.3.
The exact command that triggers the error is:
/usr/bin/g++ -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall
--- Comment #1 from HMWiesinger at gmx dot at 2009-01-16 14:45 ---
Created an attachment (id=17117)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17117action=view)
preprocessed source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38873
--- Comment #4 from hjl dot tools at gmail dot com 2009-01-16 14:59 ---
(In reply to comment #3)
(In reply to comment #2)
Also for -march=native you should really post what -fverbose-asm tells you
has
been selected for -march and other option (and you should retry with those
--- Comment #1 from aph at gcc dot gnu dot org 2009-01-16 14:59 ---
Thanks for looking.
As far as I can see _Jv_GetStringChars has been extern inline forever, so
doesn't matter. Probably should have a matching definition, but will never be
called.
_Jv_CreateJavaVM in libgcj.so.9 is:
--- Comment #23 from r dot emrich at de dot tecosim dot com 2009-01-16
15:01 ---
Created an attachment (id=17118)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17118action=view)
fix file magic regex for hppa*64*
This patch fixes the file magic regex for hppa*64*.
All dependent
--- Comment #9 from jakub at gcc dot gnu dot org 2009-01-16 15:01 ---
Subject: Bug 38789
Author: jakub
Date: Fri Jan 16 15:01:24 2009
New Revision: 143435
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143435
Log:
PR tree-optimization/38789
* tree-ssa-threadedge.c
--- Comment #10 from jakub at gcc dot gnu dot org 2009-01-16 15:02 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #24 from rwild at gcc dot gnu dot org 2009-01-16 15:13 ---
(In reply to comment #23)
This patch fixes the file magic regex for hppa*64*.
All dependent files have to be regenerated.
This modified regex allows to detect PA-RISC shared objects with the native
HP-UX file
--- Comment #25 from dave at hiauly1 dot hia dot nrc dot ca 2009-01-16
15:14 ---
Subject: Re: fails to build cross gcc for target hppa64-hp-hpux11.00 in
libstdc++/libmath
Created an attachment (id=17118)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17118action=view)
--
When trying make check
RUNTESTFLAGS=--target_board='unix/{,-fstack-protector/--param=ssp-buffer-size=4}'
I've noticed all gnat.dg tests fail as gnatmake doesn't pass through --param
options.
I see it already special cases (most of) -m*, -f*, -g* etc. options,
could it do the same for --param?
As
--- Comment #11 from howarth at nitro dot med dot uc dot edu 2009-01-16
15:27 ---
I've not had any luck reproducing this issue on linux. A few other notes. I
don't see this problem with the Macintel gfortran binaries from...
http://gcc.gnu.org/wiki/GFortranBinaries
However those may
--- Comment #1 from laurent at guerby dot net 2009-01-16 15:33 ---
for the --param= case the following should work (untested):
Index: gcc/ada/make.adb
===
--- gcc/ada/make.adb(revision 143273)
+++ gcc/ada/make.adb
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2009-01-16
15:33 ---
Any ideas on how to debug this further locally? If I add,,,
--- testcase.f.org 2009-01-16 10:28:14.0 -0500
+++ testcase.f 2009-01-16 10:28:47.0 -0500
@@ -194,5 +194,6 @@
Hi,
I recently started using the paralleled version of gcc's libstdc++. Now, I have
recognized that there is no parallel version of the fill algorithm (at least at
i486-linux-gnu).
The threshold variable __gnu_parallel::_Settings::fill_minimal_n
suggests that a parallel version of the fill
--- Comment #2 from laurent at guerby dot net 2009-01-16 15:37 ---
Oops == = =
Index: gcc/ada/make.adb
===
--- gcc/ada/make.adb(revision 143273)
+++ gcc/ada/make.adb(working copy)
@@ -8039,6 +8039,7 @@
--- Comment #1 from paolo dot carlini at oracle dot com 2009-01-16 15:46
---
Thanks for your report. Johannes, can you have a look?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38875
--- Comment #2 from singler at gcc dot gnu dot org 2009-01-16 15:51 ---
In some former (non-integrated) version of the code we had problems with fill
because it was so heavily used by other routines of the STL. But this is not a
principal problem. So I will try to integrate it as soon
--- Comment #5 from dcb314 at hotmail dot com 2009-01-16 15:54 ---
(In reply to comment #1)
Where is the input file?
gcc/testsuite/gcc.dg/callabi/func-1.c
My apologies for not getting the cut'n'paste correct.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38869
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ABI
Priority|P3 |P1
Target
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ABI
Priority|P3 |P1
Target
--- Comment #26 from r dot emrich at de dot tecosim dot com 2009-01-16
16:07 ---
(In reply to comment #24)
(In reply to comment #23)
This patch fixes the file magic regex for hppa*64*.
All dependent files have to be regenerated.
This modified regex allows to detect PA-RISC
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-16 16:07 ---
Works for me. Can you specify the output of the g++ command if you append -v
to
the full commandline?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38873
--- Comment #1 from kargl at gcc dot gnu dot org 2009-01-16 16:13 ---
Jakub probably already knows this, but
2008-05-25 Tobias Burnus bur...@net-b.de
PR fortran/32600
* intrinsics/iso_c_binding.c (c_f_procpointer): Remove.
* intrinsics/iso_c_binding.h
--- Comment #27 from dave at hiauly1 dot hia dot nrc dot ca 2009-01-16
16:15 ---
Subject: Re: fails to build cross gcc for target hppa64-hp-hpux11.00 in
libstdc++/libmath
Changes to libtool.m4 should be posted upstream (to the libtool-patches at
gnu.org list) and integrated there
--- Comment #28 from r dot emrich at de dot tecosim dot com 2009-01-16
16:17 ---
Created an attachment (id=17119)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17119action=view)
fix file magic regex for hppa*64*
updated patch
--
r dot emrich at de dot tecosim dot com changed:
--- Comment #2 from jakub at gcc dot gnu dot org 2009-01-16 16:26 ---
Then that patch was wrong. You could have code compiled with gfortran 4.3 that
references this symbol, which won't even start (e.g. with LD_BIND_NOW=1)
against gcc 4.4 libgfortran.
The symbol needs to be IMHO put
--- Comment #29 from r dot emrich at de dot tecosim dot com 2009-01-16
16:45 ---
Created an attachment (id=17120)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17120action=view)
fix file magic regex for HP-UX hosts
updated patch for all HP-UX hosts.
--
r dot emrich at de dot
--- Comment #30 from r dot emrich at de dot tecosim dot com 2009-01-16
16:51 ---
(In reply to comment #21)
I dont't know if the warnings at the end of this message are a result of this
issue or different one. The linker complains about fde encoding in
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-16 17:13 ---
The patch mail says
As c_f_procpointer was never callable, I could remove it from the library.
so it was never used?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38871
--- Comment #31 from dave at hiauly1 dot hia dot nrc dot ca 2009-01-16
17:21 ---
Subject: Re: fails to build cross gcc for target hppa64-hp-hpux11.00 in
libstdc++/libmath
I dont't know if the warnings at the end of this message are a result of
this
issue or different one. The
I have seen bug 21198. My understanding is that refers to an operating system
limit on the number of simultaneous files open. However if we attempt to reuse
the same stream using fclose to close it before fopen is called again
we still hit a limit. Under gentoo gcc runtime fails to open the file
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-16 18:05 ---
close is not fclose. close works on file numbers and not FILE*.
t.c:4: warning: return type defaults to 'int'
t.c: In function 'main':
t.c:13: warning: format '%0x' expects type 'unsigned int', but argument 3 has
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-01-16 18:22 ---
return reinterpret_cast_Tp*(reinterpret_cast_UIntPtrType(this)
+ _M_diff);
(const struct _Fwd_list_node_base *) this p+ (long unsigned int) ((const
struct
--- Comment #3 from rguenther at suse dot de 2009-01-16 18:27 ---
Subject: Re: field-insensitive PTA causes
libstdc++ miscompiles
On Fri, 16 Jan 2009, pinskia at gcc dot gnu dot org wrote:
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-01-16 18:22
---
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-01-16 18:30 ---
void *p;
intptr_t iptr = (intptr_t)p - (intptr_t)iptr;
of course. Then this is just
(void *)((intptr_t)iptr + (intptr_t)p - (intptr_t)iptr)
==
(void *)(intptr_t)p
which is guaranteed by the std
--
--- Comment #32 from r dot emrich at de dot tecosim dot com 2009-01-16
18:33 ---
(In reply to comment #31)
Probably, the warning needs to be suppressed. The warning is correct
in that the encoding currently used contains dynamic relocations
preventing the creation of a
On Fri, Jan 16, 2009 at 10:30 AM, rguenth at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org wrote:
(void *)((intptr_t)iptr + (intptr_t)p - (intptr_t)iptr)
==
(void *)(intptr_t)p
which is guaranteed by the std
No that is not guaranteed because of:
If the result cannot be represented in the
--- Comment #5 from pinskia at gmail dot com 2009-01-16 18:33 ---
Subject: Re: field-insensitive PTA causes libstdc++ miscompiles
On Fri, Jan 16, 2009 at 10:30 AM, rguenth at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org wrote:
(void *)((intptr_t)iptr + (intptr_t)p - (intptr_t)iptr)
--- Comment #7 from jason at gcc dot gnu dot org 2009-01-16 18:35 ---
Subject: Bug 38579
Author: jason
Date: Fri Jan 16 18:35:28 2009
New Revision: 143439
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143439
Log:
PR c++/38579
* search.c (protected_accessible_p):
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-01-16 18:37 ---
Guaranteed by 7.18.1.4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38835
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-01-16 18:41 ---
A regression because POINTER_PLUS_EXPR is new with 4.3.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
On Fri, Jan 16, 2009 at 10:37 AM, rguenth at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org wrote:
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-01-16 18:37
---
Guaranteed by 7.18.1.4.
These types are optional.
:)
--- Comment #8 from pinskia at gmail dot com 2009-01-16 18:44 ---
Subject: Re: field-insensitive PTA causes libstdc++ miscompiles
On Fri, Jan 16, 2009 at 10:37 AM, rguenth at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org wrote:
--- Comment #6 from rguenth at gcc dot gnu dot org
--- Comment #2 from william dot langdon at kcl dot ac dot uk 2009-01-16
18:45 ---
(In reply to comment #1)
Yip, fclose fixes it!
Many thanks!
Bill
Ps: gcc did not give any warnings here, unless I add -Wall
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38876
--- Comment #9 from rguenther at suse dot de 2009-01-16 18:51 ---
Subject: Re: [4.4 Regression] field-insensitive
PTA causes libstdc++ miscompiles
On Fri, 16 Jan 2009, pinskia at gmail dot com wrote:
--- Comment #8 from pinskia at gmail dot com 2009-01-16 18:44 ---
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-01-16 18:53 ---
Here is a testcase where IV can be found but we end up with two copies of the
same register in the loop:
int f(unsigned long s, unsigned long *c)
{
long j;
for(j = 0;j s; j++)
{
c[j]=j;
}
}
Which
--- Comment #8 from jason at gcc dot gnu dot org 2009-01-16 18:55 ---
Fixed for 4.4, not applying to older branches.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-01-16 18:55 ---
If you wouldn't generate a V_C_E for *(float*)sv-i it would just work.
The front-end generates them for the vector testcase which is why I added that
one to show that forwprop does not matter in the end.
--
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-01-16 18:56
---
C testcase, fails with 4.3 and 4.4 with -O2 --param
max-fields-for-field-sensitive=0
#include stdint.h
extern void abort (void);
int main()
{
int i = 1;
int *p = i;
uintptr_t iptr;
iptr = (uintptr_t)p -
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-01-16 18:56
---
C testcase, fails with 4.3 and 4.4 with -O2 --param
max-fields-for-field-sensitive=0
#include stdint.h
extern void abort (void);
int main()
{
int i = 1;
int *p = i;
uintptr_t iptr;
iptr = (uintptr_t)p -
1 - 100 of 210 matches
Mail list logo