On Jul 24, 2009, graham_k nab...@keellings.com wrote:
Can someone tell me definitively - if I use a ten line GPLed function, say
quicksort, in 500,000 lines of code which I write myself, do I need to GPL
all of my source code and make the ode free for all?
The FSF offers an e-mail based
The Secure Coding Initiative at CERT has published a new Technical Note
CMU/SEI-2009-TN-023 entitled As-if Infinitely Ranged Integer Model.
Abstract:
Integer overflow and wraparound are major causes of software vulnerabilities in
the C and C++ programming languages. In this paper we present
Hello!
The source of gcc uses both, fputc and putc. I would like to do some
janitorial work and change fputc to putc.
The reason is, that in system.h, both of them get redefined to the
corresponding unlock function:
# ifdef HAVE_PUTC_UNLOCKED
# undef putc
# define putc(C, Stream)
I have seen that when I build, on Cygwin (1.5), configuring as:
--
${gcc_dir}/configure --prefix=${prefix_dir} \
--exec-prefix=${eprefix_dir} \
--sysconfdir=${sysconf_dir} \
--libdir=${lib_dir} \
--libexecdir=${libexec_dir} \
Hi,
I have a question about modelling of condition codes in GCC. The
target I am considering has the following characteristics:
Associated with each register is a set of CC flags that are updated
whenever that register is used as a destination of an operation that
would normally update the CC
Hello,
This patch adds dummy implementation for
gnu/java/security/jce/prng/natVMSecureRandomWin32.cc file for Win32 build.
It throws just an exception for not supporting this method.
ChangeLog
2009-07-24 Kai Tietz kai.ti...@onevision.com
*
Trying to build gcc-4.5-20090723 on Cygwin 1.5, configuring with:
${gcc_dir}/configure --prefix=${prefix_dir} \
--exec-prefix=${eprefix_dir} \
--sysconfdir=${sysconf_dir} \
--libdir=${lib_dir} \
--libexecdir=${libexec_dir} \
--mandir=${man_dir} \
On Fri, 24 Jul 2009, Robert Seacord wrote:
A PDF Download of this paper is available at:
http://www.sei.cmu.edu/publications/documents/09.reports/09tn023.html
This model still seems extremely poorly defined. The only sensible way to
fix this is a careful definition of the AIR abstract
Robert Seacord wrote:
Hi Robert,
Source code for the As GCC 4.4.0 and GCC 4.5.0 (svn) prototypes can be
downloaded form:
http://www.cert.org/secure-coding/integralsecurity.html
Since you've got a version based off SVN, can you possibly post up a diff as
well as a full archive of the
Joseph S. Myers wrote:
If an operation that overflows has been carried out, may the AIR abstract
machine then trap at any future time (if the implementation has moved or
copied the relevant operation to that future time)?
I think that's answered on p.12 isn't it?
AIR Integers do not
As further comments, it's unfortunate that this document has chosen
certain badly thought out basis documents and concepts.
On page 13 you have a short table of critical undefined behavior and an
attempt to define bounded undefined behavior, that ignore all my
previous comments in this area,
Kai Tietz wrote:
* gnu/java/security/jce/prng/natVMSecureRandomWin32.cc: New Win32
specific implementation.
+ (JvNewStringLatin1 (Error function not implemented for Win32
target.));
That's slightly ambiguous; it needs a colon after 'Error', to make clear it
isn't an
On 7/24/09, Uros Bizjak ubiz...@gmail.com wrote:
The source of gcc uses both, fputc and putc. I would like to do some
janitorial work and change fputc to putc.
putc and fputc have different semantics:
fputc is guaranteed to be a function while putc may be a macro.
M
He who has nothing
Hi,
I've written a gimple pass, which counts for the number of assignment
statements in the c code. I've used the lval of the GIMPLE_MODIFY_STMT and
checking for VAR_DECL condition. It is working
But I want to know what are the TREE_CODEs for other remaing constructs
viz declration stmt,
On Fri, Jul 24, 2009 at 05:20:16AM -0700, pms wrote:
But I want to know what are the TREE_CODEs for other remaing constructs
viz declration stmt, conditions, count for constants and how to use them in
the gimple pass. Can anybody help in this regard
The names are defined in tree.def.
On 07/24/2009 02:06 PM, Martin Guy wrote:
The source of gcc uses both, fputc and putc. I would like to do some
janitorial work and change fputc to putc.
putc and fputc have different semantics:
fputc is guaranteed to be a function while putc may be a macro.
True, but does this
On Thu, 2009-07-23 at 15:06 +0200, Danny Backx wrote:
On Thu, 2009-07-23 at 11:52 +0100, Dave Korn wrote:
Danny Backx wrote:
On Thu, 2009-07-23 at 10:07 +0100, Dave Korn wrote:
Kai Ruottu wrote :
Comparing the output from some earlier working GCC with the gcc-4.4.0
output would
This merge brings in unit-at-a-time gimplification, so it needed some
tweaking. Mostly, it helped to find out some GENERIC that was leaking
into the streamer. A pleasant side-effect of the unit-at-a-time
gimplification is that not every function is gimplified, so there is
less gunk to pickle out
On Fri, 2009-07-24 at 14:51 +0200, Danny Backx wrote:
On Thu, 2009-07-23 at 15:06 +0200, Danny Backx wrote:
On Thu, 2009-07-23 at 11:52 +0100, Dave Korn wrote:
Danny Backx wrote:
On Thu, 2009-07-23 at 10:07 +0100, Dave Korn wrote:
Kai Ruottu wrote :
Comparing the output from
This merge brings in unit-at-a-time gimplification, so it needed some
tweaking. Mostly, it helped to find out some GENERIC that was leaking
into the streamer. A pleasant side-effect of the unit-at-a-time
gimplification is that not every function is gimplified, so there is
less gunk to
On Fri, Jul 24, 2009 at 09:43, Jan Hubickahubi...@ucw.cz wrote:
This merge brings in unit-at-a-time gimplification, so it needed some
tweaking. Mostly, it helped to find out some GENERIC that was leaking
into the streamer. A pleasant side-effect of the unit-at-a-time
gimplification is that
On Fri, 2009-07-24 at 15:40 +0200, Danny Backx wrote:
On Fri, 2009-07-24 at 14:51 +0200, Danny Backx wrote:
On Thu, 2009-07-23 at 15:06 +0200, Danny Backx wrote:
On Thu, 2009-07-23 at 11:52 +0100, Dave Korn wrote:
Danny Backx wrote:
On Thu, 2009-07-23 at 10:07 +0100, Dave Korn
Basile STARYNKEVITCH bas...@starynkevitch.net writes:
I would believe that it is the wrong place to install such a file. (In
particular it makes ldconfig unhappy, when /usr/local/lib/lib64 is
scanned).
In what way does it make ldconfig unhappy? My /usr/lib directory has a
number of files
This discussion is offtopic for the gcc@gcc.gnu.org mailing list.
Please send replies directly to me or to gnu-misc-discuss.
Adel Abushaev adel.abush...@gmail.com writes:
GPL is viral, one drop of it will make everything else GPL, especially
when you redistribute the code.
Please try to
Ian Lance Taylor wrote:
Basile STARYNKEVITCH bas...@starynkevitch.net writes:
I would believe that it is the wrong place to install such a file. (In
particular it makes ldconfig unhappy, when /usr/local/lib/lib64 is
scanned).
In what way does it make ldconfig unhappy? My /usr/lib
Angelo Graziosi angelo.grazi...@alice.it writes:
What it the best? DPD or BID?
The question is not appropriate for the gcc@gcc.gnu.org mailing list,
which is for gcc developers. It would be appropriate for
gcc-h...@gcc.gnu.org. Please take any followups to gcc-help. Thanks.
You neglected to
Markus L markusl.s...@gmail.com writes:
I have a question about modelling of condition codes in GCC. The
target I am considering has the following characteristics:
Associated with each register is a set of CC flags that are updated
whenever that register is used as a destination of an
Basile == Basile STARYNKEVITCH bas...@starynkevitch.net writes:
[...]
Basile /usr/local/lib/gcc-trunk/../lib64/libstdc++.so.6.0.12-gdb.py
Basile I would believe that it is the wrong place to install such a file. (In
Basile particular it makes ldconfig unhappy, when /usr/local/lib/lib64 is
Dave Korn wrote:
AIR Integers do not require Ada-style precise traps, which require that an
exception is raised every time there is an integer overflow. In the AIR
integer model, it is acceptable to delay catching an incorrectly represented
value until an observation point is reached just
Ben Elliston wrote:
This thread is off-topic for the GCC mailing list. Please follow up on
gnu.misc.discuss or some other suitable forum.
it is also full of appalling misinformation, so I suggest everyone
delete it! There is good reason for keeping such threads off the list.
Thanks,
Ben
On Fri, 2009-07-24 at 12:03 -0400, Robert Dewar wrote:
Indeed an alternative approach to handling this problem in GCC would
be to adapt the Ada model for C and C++ which would not be too hard
to do I suspect. Then gcc could be improved to handle this model
better and more effectively with
Ian Lance Taylor ha scritto:
Angelo Graziosi angelo.grazi...@alice.it writes:
What it the best? DPD or BID?
You neglected to mention which version of gcc you are building. The
decimal float support is relatively new.
Oops... it is the most updated for 4.3, 4.4 and 4.5
If you are using
Hello
We want to know what are TREE_CODES and TREE_TYPES;we were
trying to do the assignment in gimple pass, we got a code which checks the
number of assignment statements but now we want to check the deceleration
statements we browsed through the tree.def , tree.h and tree.c
On Fri, 24 Jul 2009, Dave Korn wrote:
Joseph S. Myers wrote:
If an operation that overflows has been carried out, may the AIR abstract
machine then trap at any future time (if the implementation has moved or
copied the relevant operation to that future time)?
I think that's
Laurent GUERBY wrote:
On Fri, 2009-07-24 at 12:03 -0400, Robert Dewar wrote:
Indeed an alternative approach to handling this problem in GCC would
be to adapt the Ada model for C and C++ which would not be too hard
to do I suspect. Then gcc could be improved to handle this model
better and more
On Thu, 23 Jul 2009, Ian Lance Taylor wrote:
It seems to me that e-mail to gcc-b...@gcc.gnu.org is basically lost
in the noise. It seems to me that we should not recommend that people
send bug reports there; the chances that anything will happen are much
smaller than the already small chance
Hello there.
I am trying to track down a problem with gcc 4.1 which has to do with inlining
and templates on PowerPC. Is there any documentation I can look related to the
output generated with -fdump? I am getting extraneous lwz (load word and zero
extend) instructions inserted when calling
On Fri, Jul 24, 2009 at 10:34 PM, Tim Crooktcr...@adobe.com wrote:
Hello there.
I am trying to track down a problem with gcc 4.1 which has to do with
inlining and templates on PowerPC. Is there any documentation I can look
related to the output generated with -fdump? I am getting extraneous
--
Caso voc� n�o queira mais receber e-mail desta newsletter, acesse
http://onlyquality.com.br/marketing/?p=unsubscribeuid=2e5ed1f25a5b18da67114f6d1f558338
--
Powered by PHPlist, www.phplist.com --
--
Caso voc� n�o queira mais receber e-mail desta newsletter, acesse
http://onlyquality.com.br/marketing/?p=unsubscribeuid=959f4ec3883353db0d672a826cb4459b
--
Powered by PHPlist, www.phplist.com --
So... It's been a long journey, but I think I'm at a point in which,
even though VTA is not completely finished, it's already enough of an
improvement that it could go in, be useful and get wider testing.
To the best of my knowledge, all of the concerns and objections that
were raised have
DJ Delorie writes:
I didn't reference the web site for the polynomial, just for background.
To be honest, I'm not sure what the polynomial is. As the comments
explain, the algorithm I used is precisely taken from gdb, in remote.c,
and is intended to produce the same result. Does anybody on the
Your code uses the (one and only) CRC-32 polynomial 0x04c11db7, so just
describing it as the CRC-32 function should be sufficient documentation.
It's the same CRC function as used by PKZIP, Ethernet, and chksum.
It's not compatible with the Intel CRC32 instruction which uses the
CRC-32C
On Fri, 2009-07-24 at 15:40 +0200, Danny Backx wrote:
It turns out that different functions are used :
- my 4.4 implementation takes its multiply code from dp-bit.c
- the 4.1 implementation takes it from ieee754-df.S
I've now tweaked gcc/config/arm/t-wince-pe (to use _arm_muldivf3
--- Comment #3 from ubizjak at gmail dot com 2009-07-24 06:25 ---
Please also add the testcase from Comment #1 to gcc testsuite.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40209
--- Comment #4 from steven at gcc dot gnu dot org 2009-07-24 06:27 ---
A hint, please, about why the patch of comment #2 would be the correct fix. As
far as I can tell, loop-iv doesn't need the notes and shouldn't have to clean
up other passes' mess. This patch also introduces a pass
--- Comment #3 from steven at gcc dot gnu dot org 2009-07-24 06:59 ---
Because HAVE_cc0 is only for cc0 targets, and ARM is not one of those?
You should stop jumping to peepholes for every missed optimization you find.
There is a csecc pass (part of cse2) that should handle this. You
--- Comment #4 from carrot at google dot com 2009-07-24 07:37 ---
Just as I've figured out HAVE_cc0 is disabled. And cse_condition_code_reg does
nothing for thumb target.
I also found that the conditional branch instructions is always in the same
insn pattern as the previous compare
--- Comment #7 from jakub at gcc dot gnu dot org 2009-07-24 07:57 ---
Subject: Bug 40643
Author: jakub
Date: Fri Jul 24 07:57:13 2009
New Revision: 150041
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150041
Log:
PR fortran/40643
PR fortran/31067
*
--- Comment #29 from jakub at gcc dot gnu dot org 2009-07-24 07:57 ---
Subject: Bug 31067
Author: jakub
Date: Fri Jul 24 07:57:13 2009
New Revision: 150041
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150041
Log:
PR fortran/40643
PR fortran/31067
*
--- Comment #30 from burnus at gcc dot gnu dot org 2009-07-24 08:19 ---
Regarding the just committed inline version: It would be interesting to know
whether it is vectorizable (with/without -ffinite-math-only [i.e.
-ffast-math]).
Additionally, for size-1 result arrays, the function
--- Comment #29 from burnus at gcc dot gnu dot org 2009-07-24 08:21 ---
Probably fixed by the commit of PR 40643 comment 7
Author: jakub
Date: Fri Jul 24 07:57:13 2009
New Revision: 150041
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150041
Log:
PR fortran/40643
--- Comment #5 from steven at gcc dot gnu dot org 2009-07-24 08:25 ---
The fact that the move sets the condition code is not modelled in the insn.
From .expand dump:
(insn 6 5 7 3 t.c:5 (set (reg/v:SI 133 [ v ])
(reg:SI 0 r0)) -1 (nil))
From -dAP output:
@(insn 6 5 7 t.c:5
--- Comment #31 from jakub at gcc dot gnu dot org 2009-07-24 08:30 ---
Vectorization questions I'll defer to Ira.
For !optimize I even had a change to forcibly use the function call instead of
inline version. But it didn't really work, as there are only array versions of
the library
--- Comment #6 from steven at gcc dot gnu dot org 2009-07-24 08:48 ---
In fact even the compare isn't a separate insn:
@(insn 6 5 7 t.c:5 (set (reg/v:SI 1 r1 [orig:133 v ] [133])
@(reg:SI 0 r0)) 167 {*thumb1_movsi_insn} (nil))
@ 0x0004
mov r1, r0 @ 6
--- Comment #10 from rguenther at suse dot de 2009-07-24 09:02 ---
Subject: Re: [4.5 Regression] Revision 149750 failed
483.xalancbmk in SPEC CPU 2006
On Thu, 23 Jul 2009, hjl dot tools at gmail dot com wrote:
--- Comment #9 from hjl dot tools at gmail dot com 2009-07-23 19:16
--- Comment #5 from paolo dot carlini at oracle dot com 2009-07-24 09:07
---
Implemented here:
2008-05-23 Kaveh R. Ghazi gh...@caip.rutgers.edu
* builtin-types.def (BT_FN_INT_INT_INT_INT_INT_INT_VAR): New.
* builtins.c (fold_builtin_fpclassify): New.
--- Comment #27 from jakub at gcc dot gnu dot org 2009-07-24 09:46 ---
These are small helper programs. The real question is if -Wl,--relax is used
on the gcc line that actually fails with the linker errors.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37739
--- Comment #4 from jwakely dot gcc at gmail dot com 2009-07-24 10:12
---
(In reply to comment #3)
Simple case :
templatetypename C struct A {};
templatetypename C struct B { struct Inner {}; };
templatetypename K
struct Atypename BK::Inner {};
4.1.2/VS2005 compile
--- Comment #6 from davek at gcc dot gnu dot org 2009-07-24 10:12 ---
Subject: Bug 40807
Author: davek
Date: Fri Jul 24 10:12:16 2009
New Revision: 150042
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150042
Log:
PR libffi/40807
* src/x86/ffi.c
--- Comment #7 from davek at gcc dot gnu dot org 2009-07-24 10:22 ---
Fixed at r.150042.
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #36 from rguenth at gcc dot gnu dot org 2009-07-24 10:24
---
With the newest whole-file patch I instead get
#1 0x087a1c89 in tree_check_failed (node=0xb6e9fcb0,
file=0x8b9d398 /home/richard/src/trunk/gcc/fortran/trans-types.c,
line=2010, function=0x8b9da9d
--- Comment #37 from rguenth at gcc dot gnu dot org 2009-07-24 10:27
---
We then get to the next ICE ...
(gdb) up
#1 0x0819bfaa in gfc_create_module_variable (sym=0x22cb3750)
at /home/richard/src/trunk/gcc/fortran/trans-decl.c:3327
3327 gcc_assert (TYPE_CONTEXT (decl) ==
--- Comment #5 from jwakely dot gcc at gmail dot com 2009-07-24 10:29
---
(In reply to comment #4)
I think this is invalid because K is used in a non-deduced context
Which is the same problem as with the original testcase - this is not a bug in
gcc.
According to 14.5.4.1
--- Comment #6 from paolo dot carlini at oracle dot com 2009-07-24 10:42
---
Closing...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #38 from rguenth at gcc dot gnu dot org 2009-07-24 10:56
---
Too large, not reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
--- Comment #5 from janus at gcc dot gnu dot org 2009-07-24 11:00 ---
Subject: Bug 40822
Author: janus
Date: Fri Jul 24 11:00:01 2009
New Revision: 150047
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150047
Log:
2009-07-24 Janus Weil ja...@gcc.gnu.org
PR
--- Comment #39 from jv244 at cam dot ac dot uk 2009-07-24 11:29 ---
(In reply to comment #36)
All of gfortran.h seems to be ignorant of the GC - which means we may
not garbage collect while the FE is still running, so all calls to
cgraph_finalize_function should have true as their
--- Comment #20 from rguenth at gcc dot gnu dot org 2009-07-24 11:56
---
As noticed in PR40011,
All of gfortran.h seems to be ignorant of the GC - which means we may
not garbage collect while the FE is still running, so all calls to
cgraph_finalize_function should have true as their
According to documentation (quote):
-
-malign-double
-mno-align-double
Control whether GCC aligns double, long double, and long long variables on
a two word boundary or a one word boundary. Aligning double variables on a two
word boundary will produce code that runs somewhat faster on a
--- Comment #1 from paolo dot carlini at oracle dot com 2009-07-24 12:05
---
The resolution of the DR is implemented in mainline.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2009-07-24 12:05
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #6 from janus at gcc dot gnu dot org 2009-07-24 12:14 ---
Fixed with r150047. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #24 from rguenth at gcc dot gnu dot org 2009-07-24 12:16
---
GCC does not assume the stack is aligned to 16 bytes if it cannot prove that it
is. That GCC aligns the stack to 16 bytes itself is compliant with the
requirement of 4 byte stack alignment.
So I completely miss
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-07-24 12:21 ---
It works on SLES11 as well.
rguent...@scandium:/tmp g++ -v
Using built-in specs.
Target: ia64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-24 12:26 ---
indeed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from jv244 at cam dot ac dot uk 2009-07-24 12:27 ---
(In reply to comment #20)
As noticed in PR40011,
All of gfortran.h seems to be ignorant of the GC - which means we may
not garbage collect while the FE is still running, so all calls to
cgraph_finalize_function
--- Comment #1 from bugtrack at roumenpetrov dot info 2009-07-24 12:40
---
P.S.: issue is tested on 32-bit x86 platform
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40845
--- Comment #28 from giffordj at la dot twcbc dot com 2009-07-24 13:12
---
Looks like it.
gcc -isystem /usr/include -m32 -g -fkeep-inline-functions -DIN_GCC -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
-Wold-style-definition -Wc++-compat
I downloaded
http://users.physik.fu-berlin.de/~tburnus/gcc-trunk/gcc-trunk-x86_64.tar.gz and
attempted to compile the file listed below. I got the message:
a.f90: In function speak:
a.f90:7:0: internal compiler error: tree check: expected function_decl, have
namespace_decl in gfc_finish_var_decl,
--- Comment #7 from rearnsha at gcc dot gnu dot org 2009-07-24 14:08
---
(In reply to comment #6)
In fact even the compare isn't a separate insn:
There's a reason for that.
If you separate compares from uses of the flags then reload may end up
inserting add or mov instructions in
--- Comment #11 from hjl dot tools at gmail dot com 2009-07-24 14:16
---
(In reply to comment #10)
Subject: Re: [4.5 Regression] Revision 149750 failed
483.xalancbmk in SPEC CPU 2006
On Thu, 23 Jul 2009, hjl dot tools at gmail dot com wrote:
--- Comment #9 from hjl dot
--- Comment #8 from doko at ubuntu dot com 2009-07-24 14:37 ---
same behaviour with the 4.4.1 release
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38292
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-24 15:30 ---
That has the whole-file patch applied appearantly.
582 /* Code with static variables must not be inlined. */
583 if (TREE_STATIC (decl) DECL_CONTEXT (decl))
584 DECL_UNINLINABLE(DECL_CONTEXT
--- Comment #22 from rguenth at gcc dot gnu dot org 2009-07-24 15:32
---
Can you run it in a debugging session and do
(gdb) break ggc_collect
(gdb) break cgraph_finalize_compilation_unit
and see if ggc_collect is reached before cgraph_finalize_compilation_unit?
Thanks.
--
--- Comment #24 from jakub at gcc dot gnu dot org 2009-07-24 15:37 ---
I have a patch.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from nvachhar at google dot com 2009-07-24 15:39 ---
Subject: Re: ICE in iv_analyze_def caused by
stale REG_UNUSED note
loop-iv does need notes, albeit indirectly through the single_set
function. single_set looks at the REG_UNUSED note, and if all but one
set
--- Comment #23 from jv244 at cam dot ac dot uk 2009-07-24 15:43 ---
(In reply to comment #22)
Can you run it in a debugging session and do
(gdb) break ggc_collect
(gdb) break cgraph_finalize_compilation_unit
and see if ggc_collect is reached before
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-24 15:44 ---
long double is 12 bytes, C requires arrays to pack dense, thus a 12 byte
long double has to be aligned to 4 bytes at least in arrays.
GCC 3.3 to 4.5 do
sizeof/offset: o_d=12/08 o_ld=16/04 o_l=08/04 o_ll=12/08
--- Comment #24 from rguenth at gcc dot gnu dot org 2009-07-24 15:46
---
Ok, that confirms this bug is unrelated to the GC issue in the other PR.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
--- Comment #8 from zlynx at acm dot org 2009-07-24 15:47 ---
I will work on trying it with libunwind and then with binutils 2.19. Those seem
to be the differences so far.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40841
--- Comment #25 from rguenth at gcc dot gnu dot org 2009-07-24 15:54
---
Ah, btw I remember that the Fortran FE creates a new type copy for each
array descriptor and links them in the type variant chains (wtf?).
Can you try
Index: gcc/fortran/trans-types.c
--- Comment #26 from jv244 at cam dot ac dot uk 2009-07-24 16:04 ---
(In reply to comment #24)
Ok, that confirms this bug is unrelated to the GC issue in the other PR.
Well, there are two bugs. The first one is gone with your
'cgraph_finalize_function (ftn_main, true)' change
--
--- Comment #27 from jv244 at cam dot ac dot uk 2009-07-24 16:05 ---
(In reply to comment #25)
Ah, btw I remember that the Fortran FE creates a new type copy for each
array descriptor and links them in the type variant chains (wtf?).
Can you try
this fixes the segfault, but I now
--- Comment #28 from rguenth at gcc dot gnu dot org 2009-07-24 16:12
---
Add
TYPE_CANONICAL (fat_type) = base_type;
after the build_distinct_type_copy call.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
--- Comment #29 from jv244 at cam dot ac dot uk 2009-07-24 16:48 ---
(In reply to comment #28)
Add
TYPE_CANONICAL (fat_type) = base_type;
after the build_distinct_type_copy call.
Yep... goes fine now
arghh... further testing on standard sources (-g?) reveals:
--- Comment #30 from rguenth at gcc dot gnu dot org 2009-07-24 16:51
---
Hmm, that looks unrelated ...?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
--- Comment #31 from jv244 at cam dot ac dot uk 2009-07-24 16:56 ---
(In reply to comment #30)
Hmm, that looks unrelated ...?
doesn't seem to happen on a clean trunk ( a few days more recent ). This is a
reduced testcase for this failure:
gfortran -g bug.f90
bug.f90: In function
--- Comment #32 from jv244 at cam dot ac dot uk 2009-07-24 17:00 ---
(In reply to comment #31)
doesn't seem to happen on a clean trunk ( a few days more recent )
it is definitely caused by the current patch (i.e. reverting it fixes the
issue):
Index: trans-types.c
--- Comment #6 from steven at gcc dot gnu dot org 2009-07-24 17:04 ---
Then we should write a new function, something like this in df.h perhaps:
/* Given an INSN, return a SET expression if the insn has only one
SET whose SET_DEST is used. If SET_DEST is memory, then the SET is
1 - 100 of 135 matches
Mail list logo
