In varasm.c default_function_rodata_section():
section *
default_function_rodata_section (tree decl)
{
if (decl != NULL_TREE && DECL_SECTION_NAME (decl))
{
const char *name = TREE_STRING_POINTER (DECL_SECTION_NAME (decl));
if (DECL_ONE_ONLY (decl) && HAVE_COMDAT_GROUP)
Snapshot gcc-4.3-20090305 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20090305/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
File libgomp/config/posix95/lock.c
It implemnts recursive mutexes with the intuitive idea (in the header)
typedef struct
{
pthread_mutex_t lock;
pthread_t owner;
int count;
} omp_nest_lock_t;
However when this is implemented in config/posix95/lock.c
void
omp_unset_nest_lock (omp_nest_loc
On Thu, 5 Mar 2009, Ralf Wildenhues wrote:
> If you are rerunning things manually, in libgomp you need to use
> aclocal -I .. -I ../config
> autoconf
> automake
Well i dont run aclocal and automake as I have not mods that are related
to those tools. I guess thats causing my issue.
> and
Hello Takis,
* Takis Psarogiannakopoulos wrote on Thu, Mar 05, 2009 at 07:28:53PM CET:
> Seems that libgomp is part of GCC and not a separate project right?
> So i am posting this here.
> I have a new target for this library that I want to add. Hence I am
> modifying configure.tgt, source files et
Hi Yanjie,
Glad that you would like to extend GCC ICI/MILEPOST. We should sync with Diego
and Sebastian about that project since they are interested as well ...
In the mean time, me and Zbigniew are preparing the final release of the ICI2
for GCC 4.4 with the collaborative Wiki to continue develop
Thank you for the info, Liang!
We can sync off-line about potential project submissions ...
Cheers,
Grigori
> -Original Message-
> From: lpeng [mailto:pengli...@ict.ac.cn]
> Sent: Thursday, March 05, 2009 7:29 AM
> To: Grigori Fursin
> Cc: gcc; cwu; fangshuangde; huangyuanjie
> Subject: Re
Hi,
Seems that libgomp is part of GCC and not a separate project right?
So i am posting this here.
I have a new target for this library that I want to add. Hence I am
modifying configure.tgt, source files etc and also adding some new
threads stuff on the configure.ac However when I recreate the c
thank you for your answer
If I change affich() code (I put as an example an incrementation of an other
variable named a),
the compiler consider c as a constant (he optimize well and remove all switch
cases in inc function).
So the problem comes from the <<() calls in affich.
Is the compiler lo
On Tue, 2009-02-24 at 20:40 +0100, Laurent GUERBY wrote:
> On Tue, 2009-02-24 at 19:36 +, Dave Korn wrote:
> > Laurent GUERBY wrote:
> > > On Tue, 2009-02-24 at 18:59 +, Dave Korn wrote:
> > >> Laurent GUERBY wrote:
> > >>
> > >>> I'm not sure 3.4 will work for trunk
> > >> I was just en
Hi Richard,
Great to see that you're addressing this issue. If I understand
correctly,
for RTL all operations are always wrapping, right?
I have been considering adding "V" variants for operations that trap on
overflow. The main reason I have not (yet) pursued this, is the daunting
task of te
On Thu, Mar 05, 2009 at 11:39:45AM +, charfi asma wrote:
> intc;
> int main()
>
> {
>
> Calcul ca;
>
> c=3;
>
> ca.affich();
>
> ca.inc(c);
>
> cout << "the value of c is" << c << endl;
>
> return 0;
>
> }
[...]
> int main()
>
> {
>
> Calcul ca;
>
> ca.affich();
>
> c=3;
>
> ca.in
Jan Hubicka wrote:
Hi,
this patch resulted from attempt to solve regression we have in
gdb.opt/inline-locals.exp gdb testsuite and also problems with fact that when
clonning function by ipa-cp we lose any information on function argument.
(and yes, it solves it)
<...>
I know that this is one of
On Thu, Mar 5, 2009 at 3:09 PM, Seema Ravandale wrote:
> Hello Sir,
>
> On Wed, Mar 4, 2009 at 7:44 PM, Manuel López-Ibáñez
> wrote:
>> I am no expert in this area, so please consider that I may be
>> misunderstanding something.
>>
>> This seems a data flow analyzer for GIMPLE. So the analysis re
On Thu, Mar 5, 2009 at 5:47 AM, Joseph S. Myers wrote:
> On Thu, 5 Mar 2009, Richard Guenther wrote:
>
>> On Thu, Mar 5, 2009 at 2:35 AM, Joseph S. Myers
>> wrote:
>> > On Wed, 4 Mar 2009, H.J. Lu wrote:
>> >
>> >> Do we really need a new snapshot when only DATESTAMP is updated? I
>> >> think it
2009/3/5 Jack Howarth :
>
> Manuel,
> It seems that the simplier testcase must be optimizing away the loop
> at all optimization levels. Are there any options that would suppress that
> optimization if one was just looking for array bounds errors with
> -Warray-bounds?
>
Hello Sir,
On Wed, Mar 4, 2009 at 7:44 PM, Manuel López-Ibáñez
wrote:
> I am no expert in this area, so please consider that I may be
> misunderstanding something.
>
> This seems a data flow analyzer for GIMPLE. So the analysis results
> can be used by the FE, am I wrong?
>
( I am assuming by F
On Thu, Mar 05, 2009 at 10:05:15AM +0100, Manuel López-Ibáñez wrote:
> 2009/3/5 Dave Korn :
> >
> > of an array that only has size[4] is going one past the end. So the bug is
> > the missing warning for the simplified testcase, not that the warning is
> > somehow incorrect in the more complex one.
On Thu, Mar 5, 2009 at 2:47 PM, Joseph S. Myers wrote:
> - Show quoted text -
> On Thu, 5 Mar 2009, Richard Guenther wrote:
>
>> On Thu, Mar 5, 2009 at 2:35 AM, Joseph S. Myers
>> wrote:
>> > On Wed, 4 Mar 2009, H.J. Lu wrote:
>> >
>> >> Do we really need a new snapshot when only DATESTAMP is up
On Thu, 5 Mar 2009, Richard Guenther wrote:
> On Thu, Mar 5, 2009 at 2:35 AM, Joseph S. Myers
> wrote:
> > On Wed, 4 Mar 2009, H.J. Lu wrote:
> >
> >> Do we really need a new snapshot when only DATESTAMP is updated? I
> >> think it is a waste
> >> of resources.
>
> It is.
>
> > When 4.4 has br
Hi.
Sorry for inconvenience.
The link should work now. If it wont, then please have patience for few days.
The work of server upgradation is going on, which might have coused problem.
We are talking to system administrator for the same. The problem will
be fixed within a couple of days.
- Seema
Hello Jan,
* Jan Hubicka wrote on Thu, Mar 05, 2009 at 11:54:31AM CET:
> *** dwarf2out.c (revision 144621)
> --- dwarf2out.c (working copy)
> *** along with GCC; see the file COPYING3.
> *** 89,94
> --- 89,95
> #include "hashtab.h"
> #include "cgraph.h"
>
> On Thu, 5 Mar 2009, Jan Hubicka wrote:
>
> > Hi,
> > this patch resulted from attempt to solve regression we have in
> > gdb.opt/inline-locals.exp gdb testsuite and also problems with fact that
> > when
> > clonning function by ipa-cp we lose any information on function argument.
> > (and yes,
Hi every one,
I have a question about gcc optimization, I hope I am writing to the right list
I compiled a simple c++ program using gcc 4.0.1
#include
using namespace std;
intc;
calss Calcul
{
public: void affich()
{
cout << "hello world" << endl;
}
public void inc (int& c)
{
switch
On Thu, 5 Mar 2009, Richard Guenther wrote:
> On Thu, 5 Mar 2009, Jan Hubicka wrote:
>
> > Hi,
> > this patch resulted from attempt to solve regression we have in
> > gdb.opt/inline-locals.exp gdb testsuite and also problems with fact that
> > when
> > clonning function by ipa-cp we lose any inf
On Thu, 5 Mar 2009, Jan Hubicka wrote:
> Hi,
> this patch resulted from attempt to solve regression we have in
> gdb.opt/inline-locals.exp gdb testsuite and also problems with fact that when
> clonning function by ipa-cp we lose any information on function argument.
> (and yes, it solves it)
>
>
Hi Grigori,
I'm a graduate student at the Institute Of Computing Technology
Chinese Academy Of Sciences, and I'm interested in the Summer of Code
projects you list in the gcc wiki, especially the one to extend the
ICI/MILEPOST framework to enable fine-grain tunning. As compiler is my
research area
On Thu, Mar 5, 2009 at 2:35 AM, Joseph S. Myers wrote:
> On Wed, 4 Mar 2009, H.J. Lu wrote:
>
>> Do we really need a new snapshot when only DATESTAMP is updated? I
>> think it is a waste
>> of resources.
It is.
> When 4.4 has branched I plan to close 4.2 branch.
Maybe we can remove DATESTAMP an
2009/3/5 Dave Korn :
>
> of an array that only has size[4] is going one past the end. So the bug is
> the missing warning for the simplified testcase, not that the warning is
> somehow incorrect in the more complex one.
No. The array is unused so it gets removed quite early. If you *do*
return th
29 matches
Mail list logo
