Matching and testing against smulhsm3

[m]

Hello!

I am trying to implement the following insns for my back end: smulhssi3, 
smulhshi3, smulhsqi3


According to [1], the operation should be equivalent to:

  narrow op0, op1, op2;
  op0 = (narrow) (((wide) op1 * (wide) op2) >> (N / 2 - 1));

...so I tried to write a corresponding matching pattern, like so:

  (define_insn "smulhshi3"
    [(set (match_operand:HI 0 "register_operand" "=r")
  (truncate:HI
    (ashiftrt:SI
  (mult:SI
    (sign_extend:SI (match_operand:HI 1 "register_operand" "r"))
    (sign_extend:SI (match_operand:HI 2 "register_operand" "r")))
  (const_int 15]
  "TARGET_PACKED_OPS"
  "mulq.h\\t%0, %1, %2")

However, I am unable to trigger this code path. I have tried with the 
following C code:


short mulq(short op1, short op2) {
  return (short) (((int) op1 * (int) op2) >> (32 / 2 - 1));
}

But I just get the regular 4-instruction result (2x sign extend, 1x mul, 
1x shift).


Are there any builtins that I need to use, or anything that I need to 
enable for my back end? Or should I use another pattern?


I also have similar problems with avgsi3_floor and friends.

Regards,

 Marcus


[1] https://gcc.gnu.org/onlinedocs/gccint/Standard-Names.html

Re: Matching and testing against smulhsm3

[m]

On 2020-02-07 16:44, Segher Boessenkool wrote:

Hi!

On Fri, Feb 07, 2020 at 03:41:25PM +0100, m wrote:

...so I tried to write a corresponding matching pattern, like so:

   (define_insn "smulhshi3"
     [(set (match_operand:HI 0 "register_operand" "=r")
   (truncate:HI
     (ashiftrt:SI
   (mult:SI
     (sign_extend:SI (match_operand:HI 1
"register_operand" "r"))
     (sign_extend:SI (match_operand:HI 2
"register_operand" "r")))
   (const_int 15]
   "TARGET_PACKED_OPS"
   "mulq.h\\t%0, %1, %2")

However, I am unable to trigger this code path. I have tried with the
following C code:

short mulq(short op1, short op2) {
   return (short) (((int) op1 * (int) op2) >> (32 / 2 - 1));
}

But I just get the regular 4-instruction result (2x sign extend, 1x mul,
1x shift).

What does -fdump-rtl-combine-all show it tried?  *Did* it try anything?


Segher



Cool option. I'm not really sure how to read the output tough. The 
closest it seems to try to match is this:



Failed to match this instruction:
(set (reg:SI 85)
    (ashiftrt:SI (mult:SI (sign_extend:SI (subreg:HI (reg:SI 86) 0))
    (reg:SI 83 [ op2D.1381 ]))
    (const_int 15 [0xf])))


It seems that it has already decided to split the instruction into 
several operations (the truncate operation is not there, and the second 
sign_extend:SI (subreg:HI ...) is also missing).



/Marcus

Adding conditional move (movsicc) to MD

[m]

Hello!

I am trying to get movmodecc (movsicc) going for my MRISC32 machine 
description, but I am unable to get GCC to use my define_expand pattern.


I have tried different variants, but here is one example that I think 
should work:


    (define_expand "movsicc"
  [(set (match_operand:SI 0 "register_operand")
    (if_then_else:SI (match_operator 1 "comparison_operator"
   [(match_operand:SI 2 "register_operand")
    (match_operand:SI 3 "register_operand")])
 (match_operand:SI 4 "register_operand")
 (match_operand:SI 5 "register_operand")))]
  ""
    {
  if (!mrisc32_expand_conditional_move (operands))
    FAIL;
  DONE;
    })

As far as I can see, mrisc32_expand_conditional_move() is never called, 
even for simple code like:


    int cmov_ne(int a, int b, int c, int d) {
  return a != b ? c : d;
    }

Am I missing something? Do I need to explicitly enable conditional moves 
somewhere in the MD?


Regards,

  Marcus

Comparison operations in machine description (-1 vs +1)

[m]

Hello gcc developers!

I am working on a new back end for my MRISC32 ISA [1], and I'm still very
new to gcc internals. I suspect that I will have more questions further
down the road, but let's start with this topic...

The MRISC32 ISA has instructions for setting a register based on the
outcome of a comparison. For instance:

  slt s1, s2, s3

...which is equal to (in C):

  int s1 = s2 < s3 ? -1 : 0;

Now, these compare instructions set the target register value to -1 (all
bits set to 1), rather than +1 (only LSB set to 1), which is not compatible
with the "lt", "eq" etc operators in gcc (from what I can see). This forces
me to add an extra "and" operation to mask out only the LSB of the result
when implementing the compare operations.

For instance:

(define_insn "*slt"
  [(set (match_operand:SI 0 "register_operand" "=r")
    (lt:SI (match_operand:SI 1 "register_operand" "r")
   (match_operand:SI 2 "register_operand" "r")))]
  ""
  "slt\t%0, %1, %2\;and\t%0, %0, #1")

From a functional point of view, it should not be necessary to do that mask
operation until the value "1" or "0" is actually needed for an arithmetic
operation (e.g. as is the case in the default implementation of adddi3).
Logical operations (and, or, xor etc) and conditional branches can use the
-1 just as well as the +1.

Question: Is there any way that I can avoid doing the extra "and" operation
in every instantiation of slt? For instance are there other insn:s that I
can define that gcc will recognize and use instead, or a machine
configuration that I can control to get a different behavior?

Best regards,

  Marcus


[1] 
https://github.com/mbitsnbites/gcc-mrisc32/tree/mbitsnbites/mrisc32/gcc/config/mrisc32

Re: Comparison operations in machine description (-1 vs +1)

[m]

Den 2019-11-12 kl. 19:54, skrev Jeff Law:

On 11/12/19 11:29 AM, m wrote:

Hello gcc developers!

I am working on a new back end for my MRISC32 ISA [1], and I'm still very
new to gcc internals. I suspect that I will have more questions further
down the road, but let's start with this topic...

The MRISC32 ISA has instructions for setting a register based on the
outcome of a comparison. For instance:

   slt s1, s2, s3

...which is equal to (in C):

   int s1 = s2 < s3 ? -1 : 0;

Look at STORE_FLAG_VALUE.  m68k for example works like this.

jeff



Thanks! That did the trick!

/Marcus

[MRISC32] Not getting scaled index addressing in loops

[m]

Hello!

I maintain a fork of GCC which adds support for my custom CPU ISA, 
MRISC32 (the machine description can be found here: 
https://github.com/mrisc32/gcc-mrisc32/tree/mbitsnbites/mrisc32/gcc/config/mrisc32 
).


I recently discovered that scaled index addressing (i.e. MEM[base + 
index * scale]) does not work inside loops, but I have not been able to 
figure out why.


I believe that I have all the plumbing in the MD that's required 
(MAX_REGS_PER_ADDRESS, REGNO_OK_FOR_BASE_P, REGNO_OK_FOR_INDEX_P, etc), 
and I have verified that scaled index addressing is used in trivial 
cases like this:


charcarray[100];
shortsarray[100];
intiarray[100];
voidsingle_element(intidx, intvalue) {
carray[idx] = value; // OK
sarray[idx] = value; // OK
iarray[idx] = value; // OK
}

...which produces the expected machine code similar to this:

stbr2, [r3, r1] // OK
sthr2, [r3, r1*2] // OK
stwr2, [r3, r1*4] // OK

However, when the array assignment happens inside a loop, only the char 
version uses index addressing. The other sizes (short and int) will be 
transformed into code where the addresses are stored in registers that 
are incremented by +2 and +4 respectively.


voidloop(void) {
for(intidx = 0; idx < 100; ++idx) {
carray[idx] = idx; // OK
sarray[idx] = idx; // BAD
iarray[idx] = idx; // BAD
}
} ...which produces:
.L4:
sthr1, [r3] // BAD
stwr1, [r2] // BAD
stbr1, [r5, r1] // OK
addr1, r1, #1
sner4, r1, #100
addr3, r3, #2 // (BAD)
addr2, r2, #4 // (BAD)
bsr4, .L4

I would expect scaled index addressing to be used in loops too, just as 
is done for AArch64 for instance. I have dug around in the machine 
description, but I can't really figure out what's wrong.


For reference, here is the same code in Compiler Explorer, including the 
code generated for AArch64 for comparison: https://godbolt.org/z/drzfjsxf7


Passing -da (dump RTL all) to gcc, I can see that the decision to not 
use index addressing has been made already in *.253r.expand.


Does anyone have any hints about what could be wrong and where I should 
start looking?


Regards,

  Marcus

Re: [MRISC32] Not getting scaled index addressing in loops

[m]

I'm sorry about the messed up code formatting (I blame the WYSIWYG). I 
hope the message gets through anyway (have a look at the Compiler 
Explorer link - https://godbolt.org/z/drzfjsxf7 - it has all the code).


/Marcus

Re: [MRISC32] Not getting scaled index addressing in loops

[m]

On 2022-06-22, Andrew Pinski wrote:

On Fri, May 27, 2022 at 11:52 PM m  wrote:

Hello!

I maintain a fork of GCC which adds support for my custom CPU ISA,
MRISC32 (the machine description can be found here:
https://github.com/mrisc32/gcc-mrisc32/tree/mbitsnbites/mrisc32/gcc/config/mrisc32
).

I recently discovered that scaled index addressing (i.e. MEM[base +
index * scale]) does not work inside loops, but I have not been able to
figure out why.

I believe that I have all the plumbing in the MD that's required
(MAX_REGS_PER_ADDRESS, REGNO_OK_FOR_BASE_P, REGNO_OK_FOR_INDEX_P, etc),
and I have verified that scaled index addressing is used in trivial
cases like this:

charcarray[100];
shortsarray[100];
intiarray[100];
voidsingle_element(intidx, intvalue) {
carray[idx] = value; // OK
sarray[idx] = value; // OK
iarray[idx] = value; // OK
}

...which produces the expected machine code similar to this:

stbr2, [r3, r1] // OK
sthr2, [r3, r1*2] // OK
stwr2, [r3, r1*4] // OK

However, when the array assignment happens inside a loop, only the char
version uses index addressing. The other sizes (short and int) will be
transformed into code where the addresses are stored in registers that
are incremented by +2 and +4 respectively.

voidloop(void) {
for(intidx = 0; idx < 100; ++idx) {
carray[idx] = idx; // OK
sarray[idx] = idx; // BAD
iarray[idx] = idx; // BAD
}
} ...which produces:
.L4:
sthr1, [r3] // BAD
stwr1, [r2] // BAD
stbr1, [r5, r1] // OK
addr1, r1, #1
sner4, r1, #100
addr3, r3, #2 // (BAD)
addr2, r2, #4 // (BAD)
bsr4, .L4

I would expect scaled index addressing to be used in loops too, just as
is done for AArch64 for instance. I have dug around in the machine
description, but I can't really figure out what's wrong.

For reference, here is the same code in Compiler Explorer, including the
code generated for AArch64 for comparison: https://godbolt.org/z/drzfjsxf7

Passing -da (dump RTL all) to gcc, I can see that the decision to not
use index addressing has been made already in *.253r.expand.

The problem is your cost model for the indexing is incorrect; IV-OPTs
uses TARGET_ADDRESS_COST to figure out the cost of each case.
So if you don't have that implemented, then the default one is used
and that will be incorrect in many cases.
You can find IV-OPTs costs and such by using the ivopts dump:
-fdump-tree-ivopts-details .

Thanks,
Andrew Pinski


Thank you Andrew!

I added a TARGET_ADDRESS_COST implementation that just returns zero,
as a test, and sure enough scaled indexed addressing was used.

Now I will just have to figure out a more accurate implementation for
my architecture.

Regards,

  Marcus




Does anyone have any hints about what could be wrong and where I should
start looking?

Regards,

Marcus

Query regarding struct variables in GIMPLE

[Karthikeyan M]

Hi ,

I am trying to convert GIMPLE representation of a program to XML.
GIMPLE does not seem to lower instances of  struct variables

E.g.

struct T{int i, int j}x;

f(){ x.j = 10}

appears as  x.j = 10 inside the GIMPLE dump of the function body . Is
there some place from where I can get it in the following( or any
other simpler ) form


f()
{
   t1 = &x;
t2 = t1+4;
*t2 = 10;
}

I am sorry if this is an already answered question . A search on the
mailing list archives did not give me an answer.

Any help would be greatly appreciated.


--


Karthik


To laugh often and love much; to win the respect of intelligent
persons and the affection of children; to earn the approbation of
honest critics; to appreciate beauty; to give of one's self; to leave
the world a bit better, whether by a healthy child, a garden patch or
a redeemed social condition; to have played and laughed with
enthusiasm and sung with exultation; to know even one life has
breathed easier because you have lived--that is to have succeeded.
--Ralph Waldo Emerson






--

Karthik


To laugh often and love much; to win the respect of intelligent
persons and the affection of children; to earn the approbation of
honest critics; to appreciate beauty; to give of one's self; to leave
the world a bit better, whether by a healthy child, a garden patch or
a redeemed social condition; to have played and laughed with
enthusiasm and sung with exultation; to know even one life has
breathed easier because you have lived--that is to have succeeded.
--Ralph Waldo Emerson


--

Karthik


To laugh often and love much; to win the respect of intelligent
persons and the affection of children; to earn the approbation of
honest critics; to appreciate beauty; to give of one's self; to leave
the world a bit better, whether by a healthy child, a garden patch or
a redeemed social condition; to have played and laughed with
enthusiasm and sung with exultation; to know even one life has
breathed easier because you have lived--that is to have succeeded.
--Ralph Waldo Emerson

Fwd: Query regarding struct variables in GIMPLE

[Karthikeyan M]

Thanks.
Can you point me to documentation / code where I can get more
information about these artificial tags ?


On 3/13/07, Diego Novillo < [EMAIL PROTECTED]> wrote:

Karthikeyan M wrote on 03/13/07 21:32:

> appears as   x.j = 10 inside the GIMPLE dump of the function body . Is
> there some place from where I can get it in the following( or any
> other simpler ) form

No, we don't unnecessarily take addresses of variables.  Structure
references are left intact.  For some aggregates that cannot be
scalarized we try to create artificial tags to represent the fields (to
get field sensitive results in points-to resolution).





--

Karthik


To laugh often and love much; to win the respect of intelligent
persons and the affection of children; to earn the approbation of
honest critics; to appreciate beauty; to give of one's self; to leave
the world a bit better, whether by a healthy child, a garden patch or
a redeemed social condition; to have played and laughed with
enthusiasm and sung with exultation; to know even one life has
breathed easier because you have lived--that is to have succeeded.
--Ralph Waldo Emerson

Building without bootstrapping

[Karthikeyan M]

Hi ,

I am trying to build GCC without bootstrapping

The config options I used were

-- prefix= --disable-bootstrap --disable-libada --enable-languages=c

I then did a

make

After that, I edited some code in c-parser.c , then, as suggested in
http://gcc.gnu.org/ml/gcc/2007-02/msg00025.html , I tried

make stage1-bubble

This does not seem to compile the changed file.

Please let me know what is the correct way to do this , also please
point me to documentation that will help me understand the build
process.

--

Karthik

Re: Building without bootstrapping

[Karthikeyan M]

when you run configure.

If you do use --disable-bootstrap, just run "make all-gcc".


I tried this, it is still using the compiled-compiler in stage2 and beyond

I added some code to c-parser.c and this crashes the built-compiler
when it tries to  compile itself.  I want the build to stop after
stage 1 , so that I can use gdb on cc1 to debug the problem .
Basically, I am looking for a way to get the Makefile to always use
only the system's pre-built gcc .

Any help would be greatly appreciated.

--

Karthik

Re: Building without bootstrapping

[Karthikeyan M]

Thanks for the help.
But my problem is not yet solved

I created a new folder , configured with
--prefix= --disable-bootstrap --enable-languages=c

option and then did a

make

but the newly  built compiler is still used in the build process. i.e
in the generated

Makefile


CC_FOR_TARGET=$(STAGE_CC_WRAPPER)
$$r/$(HOST_SUBDIR)/gcc/xgcc -B$$r/$(HOST_SUBDIR)/gcc/
$(FLAGS_FOR_TARGET)

GCC_FOR_TARGET=$(STAGE_CC_WRAPPER)
$$r/$(HOST_SUBDIR)/gcc/xgcc -B$$r/$(HOST_SUBDIR)/gcc/
$(FLAGS_FOR_TARGET)

if I replace  $$r/$(HOST_SUBDIR)/gcc/xgcc  with gcc , I get the
following error :

gcc -B/home/karthik/test-nisc2/./gcc/
-B/home/karthik/test-nisc/i686-pc-linux-gnu/bin/
-B/home/karthik/test-nisc/i686-pc-linux-gnu/lib/ -isystem
/home/karthik/test-nisc/i686-pc-linux-gnu/include -isystem
/home/karthik/test-nisc/i686-pc-linux-gnu/sys-include -O2 -O2 -g -O2
-DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include  -I.
-I. -I../../src/gcc-4.1.2/gcc -I../../src/gcc-4.1.2/gcc/.
-I../../src/gcc-4.1.2/gcc/../include
-I../../src/gcc-4.1.2/gcc/../libcpp/include   -g0
-finhibit-size-directive -fno-inline-functions -fno-exceptions
-fno-zero-initialized-in-bss -fno-unit-at-a-time
-fno-omit-frame-pointer \
 -c ../../src/gcc-4.1.2/gcc/crtstuff.c -DCRT_BEGIN \
 -o crtbegin.o
../../src/gcc-4.1.2/gcc/crtstuff.c:1: error: bad value (generic) for
-mtune= switch


What am I doing wrong?
How can I get the build scripts to use the precompiled gcc throughout
the build process ?

Regards,

Karthik


On 3/16/07, Mike Stump <[EMAIL PROTECTED]> wrote:

On Mar 16, 2007, at 6:51 PM, Karthikeyan M wrote:
>> when you run configure.
>>
>> If you do use --disable-bootstrap, just run "make all-gcc".
>
> I tried this, it is still using the compiled-compiler in stage2 and
> beyond

There is no stage 2 if you aren't bootstrapping.  I'd recommend rm -
rf  build and start again.

   cd gcc && make

would be the canonical development method.

Re: Building without bootstrapping

[Karthikeyan M]

Thanks for the information.
So, if I want to debug a bug in the cc1 code that causes target
library build to fail -
should I just use the cc1 that is generated in /gcc/  ?

Is there a better way of doing this, without going through a make that
builds some components successfully (cc1) and fails for the others (
target libs ) ?


On 3/18/07, Paul Brook <[EMAIL PROTECTED]> wrote:

> How can I get the build scripts to use the precompiled gcc throughout
> the build process ?

Short answer is you can't. The newly build gcc is always used to build the
target libraries[1].

Paul

[1] Except when building a Canadian cross, in which case you're expected to
have a build->target cross compiler available. Bad Things will probably
happen if this doesn't match the compiler being built.

Listing file-scope variables inside a pass

[Karthikeyan M]

What should I do if I want a list of all file-scope variables inside
my own pass ?

The file_scope variable is local to c-decl.c . Is there a reason why
the scope holding variables are local to c-decl.c ?

-
Karthik

Re: Listing file-scope variables inside a pass

[Karthikeyan M]

Thanks.
Where exactly should I be looking?
Will the cgraph nodes also have global declarations that are never
used inside any
function .

On 3/20/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:

On 3/20/07, Dave Korn <[EMAIL PROTECTED]> wrote:
> On 19 March 2007 22:16, Karthikeyan M wrote:
>
> > What should I do if I want a list of all file-scope variables inside
> > my own pass ?
> >
> > The file_scope variable is local to c-decl.c . Is there a reason why
> > the scope holding variables are local to c-decl.c ?
>
>   Because we want to keep front-, mid- and back- ends of the compiler as
> modular and non-interdependent as possible, perhaps?
>
>   If you need a routine to dump that data, why not write it in c-decl.c and
> just expose the prototype in a suitable header file (c-tree.h)?
>
He already can get the file-scope variables by going through the
cgraph variable nodes.




--

Karthik


To laugh often and love much; to win the respect of intelligent
persons and the affection of children; to earn the approbation of
honest critics; to appreciate beauty; to give of one's self; to leave
the world a bit better, whether by a healthy child, a garden patch or
a redeemed social condition; to have played and laughed with
enthusiasm and sung with exultation; to know even one life has
breathed easier because you have lived--that is to have succeeded.
--Ralph Waldo Emerson

Re: Listing file-scope variables inside a pass

[Karthikeyan M]

Are these macros not a part of 4.1.2 ?
I just picked up the tarball of the 4.1.2-core source.

Which release has this code ?

Thanks a lot.


On 3/20/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:

On 3/20/07, Karthikeyan M <[EMAIL PROTECTED]> wrote:
> Thanks.
> Where exactly should I be looking?
cgraph.c, cgraphunit.c, cgraph.h
see cgraph_varpool_nodes, FOR_EACH_STATIC_VARIABLE (static here means
having scope greater than a single function, it does not mean "all
variables declared static in C")

> Will the cgraph nodes also have global declarations that are never
> used inside any
> function .
If you ask for all of them, it will give you all of them
If you ask for only the needed ones, it will give you all of the
needed ones (see FOR_EACH_STATIC_VARIABLE)
>
> On 3/20/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> > On 3/20/07, Dave Korn <[EMAIL PROTECTED]> wrote:
> > > On 19 March 2007 22:16, Karthikeyan M wrote:
> > >
> > > > What should I do if I want a list of all file-scope variables inside
> > > > my own pass ?
> > > >
> > > > The file_scope variable is local to c-decl.c . Is there a reason why
> > > > the scope holding variables are local to c-decl.c ?
> > >
> > >   Because we want to keep front-, mid- and back- ends of the compiler as
> > > modular and non-interdependent as possible, perhaps?
> > >
> > >   If you need a routine to dump that data, why not write it in c-decl.c 
and
> > > just expose the prototype in a suitable header file (c-tree.h)?
> > >
> > He already can get the file-scope variables by going through the
> > cgraph variable nodes.
> >
>
>
> --
>
> Karthik
>
> 
> To laugh often and love much; to win the respect of intelligent
> persons and the affection of children; to earn the approbation of
> honest critics; to appreciate beauty; to give of one's self; to leave
> the world a bit better, whether by a healthy child, a garden patch or
> a redeemed social condition; to have played and laughed with
> enthusiasm and sung with exultation; to know even one life has
> breathed easier because you have lived--that is to have succeeded.
> --Ralph Waldo Emerson
> 
>




--

Karthik


To laugh often and love much; to win the respect of intelligent
persons and the affection of children; to earn the approbation of
honest critics; to appreciate beauty; to give of one's self; to leave
the world a bit better, whether by a healthy child, a garden patch or
a redeemed social condition; to have played and laughed with
enthusiasm and sung with exultation; to know even one life has
breathed easier because you have lived--that is to have succeeded.
--Ralph Waldo Emerson

Re: Listing file-scope variables inside a pass

[Karthikeyan M]

Oh ! So the releases on  http://gcc.gnu.org/releases.html are for
those who just want to use gcc and not hack it ?

Is the latest release not done from the top of the trunk ?

Is there any tool that I can use visualize the repository ? A tool
that shows a visualization like
http://en.wikipedia.org/wiki/Image:Subversion_project_visualization.png



On 3/21/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:

On 3/20/07, Karthikeyan M <[EMAIL PROTECTED]> wrote:
> Are these macros not a part of 4.1.2 ?
> I just picked up the tarball of the 4.1.2-core source.
>
> Which release has this code ?
4.2 or 4.3

You should never try to be doing real development work on GCC against
anything but the development trunk (or a branch of the development
trunk).
If for no other reason than we only fix regressions on release branches.

>
> Thanks a lot.
>
>
> On 3/20/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> > On 3/20/07, Karthikeyan M <[EMAIL PROTECTED]> wrote:
> > > Thanks.
> > > Where exactly should I be looking?
> > cgraph.c, cgraphunit.c, cgraph.h
> > see cgraph_varpool_nodes, FOR_EACH_STATIC_VARIABLE (static here means
> > having scope greater than a single function, it does not mean "all
> > variables declared static in C")
> >
> > > Will the cgraph nodes also have global declarations that are never
> > > used inside any
> > > function .
> > If you ask for all of them, it will give you all of them
> > If you ask for only the needed ones, it will give you all of the
> > needed ones (see FOR_EACH_STATIC_VARIABLE)
> > >
> > > On 3/20/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> > > > On 3/20/07, Dave Korn <[EMAIL PROTECTED]> wrote:
> > > > > On 19 March 2007 22:16, Karthikeyan M wrote:
> > > > >
> > > > > > What should I do if I want a list of all file-scope variables inside
> > > > > > my own pass ?
> > > > > >
> > > > > > The file_scope variable is local to c-decl.c . Is there a reason why
> > > > > > the scope holding variables are local to c-decl.c ?
> > > > >
> > > > >   Because we want to keep front-, mid- and back- ends of the compiler 
as
> > > > > modular and non-interdependent as possible, perhaps?
> > > > >
> > > > >   If you need a routine to dump that data, why not write it in 
c-decl.c and
> > > > > just expose the prototype in a suitable header file (c-tree.h)?
> > > > >
> > > > He already can get the file-scope variables by going through the
> > > > cgraph variable nodes.
> > > >
> > >
> > >
> > > --
> > >
> > > Karthik
> > >
> > > 

> > > To laugh often and love much; to win the respect of intelligent
> > > persons and the affection of children; to earn the approbation of
> > > honest critics; to appreciate beauty; to give of one's self; to leave
> > > the world a bit better, whether by a healthy child, a garden patch or
> > > a redeemed social condition; to have played and laughed with
> > > enthusiasm and sung with exultation; to know even one life has
> > > breathed easier because you have lived--that is to have succeeded.
> > > --Ralph Waldo Emerson
> > > 

> > >
> >
>
>
> --
>
> Karthik
>
> 
> To laugh often and love much; to win the respect of intelligent
> persons and the affection of children; to earn the approbation of
> honest critics; to appreciate beauty; to give of one's self; to leave
> the world a bit better, whether by a healthy child, a garden patch or
> a redeemed social condition; to have played and laughed with
> enthusiasm and sung with exultation; to know even one life has
> breathed easier because you have lived--that is to have succeeded.
> --Ralph Waldo Emerson
> 
>




--

Karthik


To laugh often and love much; to win the respect of intelligent
persons and the affection of children; to earn the approbation of
honest critics; to appreciate beauty; to give of one's self; to leave
the world a bit better, whether by a healthy child, a garden patch or
a redeemed social condition; to have played and laughed with
enthusiasm and sung with exultation; to know even one life has
breathed easier because you have lived--that is to have succeeded.
--Ralph Waldo Emerson

Schily ueber Deutschland

[M . Rainforth]

Lese selbst:
http://www.heise.de/newsticker/meldung/59427

Re: DWARF64 gcc/clang flag discussion

[m...@klomp.org]

On Fri, Nov 20, 2020 at 08:22:26PM +, Alexander Yermolovich wrote:
> On llvm side of compiler world there has been work done by Igor Kudrin to 
> enable DWARF64.
> I am trying to add a flag to Clang to enable DWARF64 generation. 
> https://reviews.llvm.org/D90507
> In review David Blaikie pointed out that there has been a discussion on what 
> to call this flag:
> https://linuxplumbersconf.org/event/7/contributions/746/attachments/578/1018/DWARF5-64.pdf
> https://linuxplumbersconf.org/event/7/sessions/90/attachments/583/1201/dwarf-bof-notes-aug24-lpc-2020.txt
> https://www.mail-archive.com/gcc@gcc.gnu.org/msg92495.html
> 
> Reading through that it doesn't look like there is a consensus on what it 
> should be.
>
> From discussion there is seems to be mixed opinion if it should be
> -f or -g. Primarily centered around if -g prefix implies
> turning on generation of debug information.
>
> Now that LLVM can actually generate DWARF64 for ELF, can we come to consensus 
> on the name?

I don't believe any firm consensus was reached on naming yet.  But I
would pick -fdwarf32/-fdwarf64.

Cheers,

Mark

About the Idea Presented by GCC for Google Summer of Code

[Chethan M]

Hello Sir/Madam,
  I am a 2nd Year Computer Science student from Bangalore.I am
Interested in an idea presented by the GCC for Google Summer of Code.The
idea is about creating built in functions for folding for constant
arguments and expanding inline,Which would be mentored by  Joseph Myers.
   I found this idea interesting and really possible for me. But
I'm finding difficulty in proposing the the project as i never worked for
Open source soft wares.Would you Please help me with more description for
the idea or with some suggestion?

Thank you.

-- 
Chethan M
Dept of Computer Science
BMS College of Engineering
Bangalore
Phone:+91 7411605509
Mail: mchethan.ac...@gmail.com
 1bm16cs...@bmsce.ac.in

Re: opencl and gcc

[M Wahab]

There's a very basic GCC front-end for LLVM-IR at
http://gcc-llvmir.googlecode.com, which has some support for
using clang to generate the LLVM IR. It might be usable as a starting
point for an OpenCL front-end, assuming that the OpenCL parser made it
into clang.

Matthew

Fwd: On-line petice proti radaru

[luci-m]

...uz jsem podepsala, poslete to taky dal... www.nechciradar.cz
Lucka

- Original Message - 
From: "Jan Dvorak" <[EMAIL PROTECTED]>

Sent: Monday, March 31, 2008 11:04 AM
Subject: Fwd: On-line petice proti radaru




 Původní zpráva 
Od: Eva Vaňková
Komu: Evička Š.; Bára; Hynek; Ing. Iva Kratochvílová; Ing. Jan Zítek;
Jan Dvorak; Lukáš H.; Mgr. Karel Hrubý; Petra Fojtíková; spacekm; Vosík
Datum: 30.3.2008 13:26
Předmět: On-line petice proti radaru


Ahoj,

právě jsem podepsala důležitou online-petici proti americkému radaru
v Česku. Potřebujeme tvou pomoc. Tady je odkaz:

www.nechciradar.cz

Eva Vaňková

Re: gpl version 3 and gcc

[Alfred M. Szmidt]

   Fine.. as I said, what's a reasonable forum to discuss this on?
   gnu.misc.discuss just doesn't cut it..

gnu-misc-discuss@ is the proper place, just ignore Terekhov.

Successful build/install of gcc-4.1.2 on Solaris10

[Stephen M. Kenton]

Successful build/install of gcc-4.1.2 on Solaris10
The previous version of GCC used for the build was 3.4.6
I just built the compiler until I worked around the toolchain
problems: downrev gawk and missing gmp (watch 32 vs 64 bit) and mpfr.
Then a reconfig for everything built and installed in /usr/local.

#!/bin/ksh
#Use ksh to work around broken shell problems on Solaris
CONFIG_SHELL=/bin/ksh
export CONFIG_SHELL
/bin/ksh /hd1/src/gnu-src/gcc-4.1.2/configure
make SHELL=/bin/ksh bootstrap

% gcc -v
Using built-in specs.
Target: sparc-sun-solaris2.10
Configured with: /hd1/src/gnu-src/gcc-4.1.2/configure 
--enable-languages=c :


(reconfigured) /hd1/src/gnu-src/gcc-4.1.2/configure
Thread model: posix
gcc version 4.1.2

% uname -a
SunOS dna7 5.10 Generic_118833-36 sun4u sparc SUNW,Sun-Fire-880

please update the gcj main page

[John M. Gabriele]

Please update http://gcc.gnu.org/java/index.html and mention
how much of the Java 1.5 spec that GCJ currently implements.

When I refer folks to GCJ, the first thing they usually ask is,
"does it support generics?" "autoboxing?" and so on. That info
should be right up on the GCJ front page -- even if GCJ doesn't
support those newer features. *Especially* if GCJ doesn't
support those newer features.

Thanks, :)
---John





Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 

Re: please update the gcj main page

[John M. Gabriele]

--- Ranjit Mathew <[EMAIL PROTECTED]> wrote:

> John M. Gabriele wrote:
> > Please update http://gcc.gnu.org/java/index.html and mention
> > how much of the Java 1.5 spec that GCJ currently implements.
> > 
> > When I refer folks to GCJ, the first thing they usually ask is,
> > "does it support generics?" "autoboxing?" and so on. That info
> > should be right up on the GCJ front page -- even if GCJ doesn't
> > support those newer features. *Especially* if GCJ doesn't
> > support those newer features.
> 
> GCJ doesn't yet support any of the new 1.5 features.

Hi Ranjit. Thanks for the reply. I hope I didn't sound confrontational --
I just realized I forgot to put any smilies into my original message. :)

> Tom Tromey is developing "gcjx", a complete rewrite
> of the GCJ compiler front-end, that would support
> the 1.5 features in addition to being easier to maintain,
> etc. You can check it out for yourself using the "gcjx-branch"
> branch of the GCC CVS repository:
> 
>   http://gcc.gnu.org/cvs.html

Nice. Thanks for the link. It would be great to have that
information right on the gcj front page. How can we go
about adding it?

> As for your suggestion, I believe the correct place would
> be "2.8 What features of the Java language are/aren't supported?"
> in the FAQ:
> 
>   http://gcc.gnu.org/java/faq.html#2_8

Ah. Some expansion of that faq item would be useful (re. 1.4 vs 1.5).
Following the link to the JLS page, I see that they are still pointing users
to what looks to me like the Java 1.4 spec (I browsed the online html version's
index, and there's no mention of generics or autoboxing), though a new
version of that JLS book seems to be coming out last month. :)

Also note that the "table of contents" at the top of the GCJ faq page has
a typo: s/arn't/aren't/.

> in addition to the front-page (if so desired).

Yes. How do we go about it? :)

Thanks,
---John

> Ranjit.
> 
> -- 
> Ranjit Mathew   Email: rmathew AT gmail DOT com
> 
> Bangalore, INDIA. Web: http://ranjitmathew.hostingzero.com/
> 





Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 

Re: please update the gcj main page

[John M. Gabriele]

--- Bryce McKinlay <[EMAIL PROTECTED]> wrote:

> Ranjit Mathew wrote:
> 
> >As for your suggestion, I believe the correct place would
> >be "2.8 What features of the Java language are/aren't supported?"
> >in the FAQ:
> >
> >  http://gcc.gnu.org/java/faq.html#2_8
> >
> >in addition to the front-page (if so desired).
> >  
> >
> 
> The FAQ is badly in need of an update - in fact, it should be moved over 
> to the Wiki (http://gcc.gnu.org/wiki/GCJ) in order to be easier to 
> update and maintain.

The faq looks great. I'm paranoid though -- with wiki's, I always worry
some random troll is going to pop in and make tiny incorrect changes
just to mess with everyone. IMO, if you needed some special access privileges
to make changes (besides just creating a username and password), that
would be ideal.

Also, the GCJ front page could use a link to the GCJ page of the wiki
(right under or in place of the GCJ FAQ link).

Further, in the column on the left (GCJ homepage), everything below the
"About GCC" should probably be under some sort of GCC heading or graphic
or color-scheme (to show that that stuff is not *specifically* GCJ-related, but
rather, general GCC-related). I tend to end up hitting the GCC-in-general
links on that page when I was looking to click GCJ-specific links.

Thanks,
---John





Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 

Re: please update the gcj main page

[John M. Gabriele]

--- Bryce McKinlay <[EMAIL PROTECTED]> wrote:

> John M. Gabriele wrote:
> 
> > >Yes. How do we go about it? :)
> >  
> >
> 
> The web pages can be found in the "wwwdocs" module in GCC cvs. Go here 
> for details: http://gcc.gnu.org/cvs.html
> 
> Fixes and updates should be submitted to [EMAIL PROTECTED] and 
> [EMAIL PROTECTED] We appreciate your help with this!
> 
> Bryce
> 

Thanks for the links Bryce. :) Will have a look at it this weekend.

---J





Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 

Re: please update the gcj main page

[John M. Gabriele]

--- Florian Weimer <[EMAIL PROTECTED]> wrote:

> * Gerald Pfeifer:
> 
> > On Sun, 31 Jul 2005, Daniel Berlin wrote:
> >> For code.
> >> I have never seen such claims made for documentation, since it's much
> >> easier to remove and deal with infringing docs than code.
> >
> > I have seen such statements, by RMS himself.
> 
> The official position might have changed (e.g. copyright assignments
> and documentation).
> 

I had one thing I'd like to add to this thread:

I spend some amount of time updating various GNU/Linux-related
docs on the web. Before wiki's became popular (or, at least, before
I knew about them), updating a project's docs meant figuring out
how to get the site's source via cvs, learning LinuxDoc/DocBook,
and sending patches or getting commit access. I never got involved
with that.

Now that many projects are using wiki's, I can log in, make
corrections/additions, and log out. Not to mention how simple
most wiki formatting rules are. It's a piece of cake. The only
thing that bugs me is that sometimes the wiki police trample
over some nicely crafted bit of work I've done, but that's not
too often.

Devs on these mailing lists have reapeatedly mentioned how receptive
they are to having more newb-friendly docs contributed, but it's
just *so* *darn* *easy* to work with a wiki that I'm spoiled rotten,
and I'm quickly getting too lazy to start doing it the old way.

(It occurs to me to wonder if tldp is beginning to see fewer
updates to their docs because folks are preferring to use wiki's.)

IMO, it's best to keep wiki's editable only by folks/accounts
that've been approved somehow. It shouldn't be too much trouble
for a wiki maintainer to enable/disable users as-needed. (Though
some folks have mentioned that they monitor the wiki continuously
and are emailed notifications every time a change is made, so
maybe it's not necessary to only allow approved contributors.)

Anyhow, that's my opinion FWIW, coming from someone who writes
pretty good newb-friendly docs, on various wiki's, every now and
again. IMO, if there's some issue with licensing/copyright and
wiki's for GNU projects, it should be straightened out so everyone
can easily start contributing to the docs, wiki-style. That seems
to be the future of web docs AFAICT.

---John





Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 

Is -fvisibility patch possible on GCC 3.3.x

[Gary M Mann]

Hi,

The -fvisibility feature in GCC 4.0 is a really useful way of hiding all
non-public symbols in a dynamic shared object.

While I'm aware of a patch which backports this feature to GCC 3.4 (over at
nedprod.com), I was wondering whether there is a similar patch available for
GCC 3.3. I'm aware that GCC 3.3 (and some vintages of 3.2) support the
__attribute__ means of setting a symbol's visibility, but I want to be able
to change the default visibility for all symbols.

The problem is that we're stuck for now with the GCC 3.3 compiler as we need
v5 ABI compatibility for Orbix 6.2 and cannot move to 3.4 until Iona catch
up.

Does anyone know if such a patch exists, or even if it is feasible in the
3.3 framework?

Thanks,

Gary

RE: Is -fvisibility patch possible on GCC 3.3.x

[Gary M Mann]

Gaby,

Are you referring to issues with operator new visibility, and RTTI/exception
handling? I'm not throwing objects across DSO boundaries, so this should be
less of an issue.

Gary

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: 06 November 2005 12:25
To: Gary M Mann
Cc: gcc@gcc.gnu.org
Subject: Re: Is -fvisibility patch possible on GCC 3.3.x

"Gary M Mann" <[EMAIL PROTECTED]> writes:

| Hi,
| 
| The -fvisibility feature in GCC 4.0 is a really useful way of hiding all
| non-public symbols in a dynamic shared object.
| 
| While I'm aware of a patch which backports this feature to GCC 3.4 (over
at
| nedprod.com), I was wondering whether there is a similar patch available
for
| GCC 3.3. I'm aware that GCC 3.3 (and some vintages of 3.2) support the
| __attribute__ means of setting a symbol's visibility, but I want to be
able
| to change the default visibility for all symbols.
| 
| The problem is that we're stuck for now with the GCC 3.3 compiler as we
need
| v5 ABI compatibility for Orbix 6.2 and cannot move to 3.4 until Iona catch
| up.
| 
| Does anyone know if such a patch exists, or even if it is feasible in the
| 3.3 framework?

I'm not aware of any such patch.  However, beware that the visibility
patch comes with its own can of worms.

-- Gaby

Pending bugs for GNU

[Alfred M\. Szmidt]

Could someone check the bugs that depend on #21824?  They have been
pending for several months now with no activity, and it is kinda bad
karma not having GCC working on the GNU system.

Thanks.

Re: Pending bugs for GNU

[Alfred M\. Szmidt]

   The usual process is that you post them to the gcc-patches mailing
   list for review.  And if they are approved, you can commit then or
   you can ask someone to commit them for you.  As far as I can tell,
   you have never posted the patches.  At least, there is no sign of
   that in the PR audit trails.

Thanks, will do so later today.

But this seems very awkward for people who only send a patch ones in a
blue moon; and not much good info on that either, the manual just says
`report bugs to the bugtracker'; more or less.

Re: Pending bugs for GNU

[Alfred M\. Szmidt]

   Please read the web page:
   http://gcc.gnu.org/contribute.html

This assumes a stable access to the 'net so that such information can
be extracted when one is reading the documentation.  Which isn't
always the case for everyone.  URL's shouldn't point to important
information of this type in a info manual.  Is there any way to get it
included directly?

Re: GNU Tools Cauldron 2020

[Alfred M. Szmidt]

   Please feel free to share with other groups as appropriate.

The form requires non-free software and Google malware.  Please do not
recommend that people share such things on GNU project lists.

[r...@gnu.org: What's GNU -- and what's not]

[Alfred M. Szmidt]

<#part type=message/rfc822 disposition=inline raw=t>
X-From-Line: r...@gnu.org Tue Feb  4 23:28:18 2020
Received: from fencepost.gnu.org (fencepost.gnu.org [209.51.188.10])
by localhost (mpop-1.0.28) with POP3
for ; Wed, 05 Feb 2020 00:28:18 +0100
Return-path: 
Envelope-to: a...@gnu.org
Delivery-date: Tue, 04 Feb 2020 18:27:08 -0500
Received: from localhost ([::1]:45244 helo=gnu.org)
by fencepost.gnu.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128)
(Exim 4.82)
(envelope-from )
id 1iz7am-LC-IB; Tue, 04 Feb 2020 18:26:53 -0500
Date: Tue, 4 Feb 2020 18:26:51 -0500
From: "Richard Stallman (Chief GNUisance)" 
To: r...@gnu.org
Subject: What's GNU -- and what's not
Message-ID: <20200204232649.ga...@gnu.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-UIDL: 0D[!!:SV!!lI6!!ABY"!
X-RMAIL-ATTRIBUTES: -D--

The GNU Project is sending this message to each GNU package 
maintainer.

You may have recently received an email asking you to review a
document titled "GNU Social Contract" and then to endorse it or reject
it.  It does not entirely accord with the GNU Project's views.  It was
created by some GNU participants who are trying to push changes
on the GNU Project.

The message also proposed to "define" what it means to be a "member of
GNU", and cited a web page presented as a "wiki for GNU maintainers",
It may have given the impression that they were doing all those things
on behalf of the GNU Project.  That is not the case.  The document, 
the
wiki, and the proposed idea of "members" have no standing in the GNU
Project, which is not considering such steps.  The use of a domain not
affiliated with GNU reflects this fact.

GNU package maintainers have committed to do work to maintain and add
to the GNU system, but not anything beyond that.  We have never
pressed contributors to endorse the GNU Project philosophy, or any
other philosophical views, because people are welcome to contribute to
GNU regardless of their views.

To change that -- to impose such requirements -- would be radical,
gratuitous, and divisive, so the GNU Project is not entertaining the
idea.  Likewise, we will not ask package maintainers to be "members"
instead of volunteers.  If you contribute to GNU, you are already a
member of the GNU community.

The wiki that they set up "for GNU maintainers" represents them, not
the GNU Project.  People are always free to publish what they think
the GNU Project should do, but should not presume it will be accepted
or followed by the GNU Project.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)


<#/part>

RE: Listing a maintainer for libcilkrts, and GCC's Cilk Plus implementation generally?

[Tannenbaum, Barry M]

I apologize. They got caught up in other issues. They've been merged into our 
mainstream and I believe they were just posted to the cilkplus.org website and 
submitted to GCC.

  - Barry

-Original Message-
From: Thomas Schwinge [mailto:tho...@codesourcery.com] 
Sent: Thursday, March 5, 2015 7:42 PM
To: Jeff Law
Cc: Zamyatin, Igor; Iyer, Balaji V; gcc@gcc.gnu.org; Tannenbaum, Barry M; H.J. 
Lu; Jakub Jelinek
Subject: Re: Listing a maintainer for libcilkrts, and GCC's Cilk Plus 
implementation generally?

Hi!

On Thu, 5 Mar 2015 13:39:44 -0700, Jeff Law  wrote:
> On 02/23/15 14:41, H.J. Lu wrote:
> > On Mon, Sep 29, 2014 at 4:00 AM, Jakub Jelinek  wrote:
> >> On Mon, Sep 29, 2014 at 12:56:06PM +0200, Thomas Schwinge wrote:
> >>> On Tue, 23 Sep 2014 11:02:30 +, "Zamyatin, Igor" 
> >>>  wrote:
> >>>> Jeff Law wrote:
> >>>>> The original plan was for Balaji to take on this role; however, 
> >>>>> his assignment within Intel has changed and thus he's not going 
> >>>>> to have time to work on
> >>>>> Cilk+ anymore.
> >>>>>
> >>>>> Igor Zamyatin has been doing a fair amount of Cilk+ 
> >>>>> maintenance/bugfixing and it might make sense for him to own it in the 
> >>>>> long term if he's interested.
> >>>>
> >>>> That's right.
> >>>
> >>> Thanks!
> >>>
> >>>> Can I add 2 records (cilk plus and libcilkrts) to Various Maintainers 
> >>>> section?
> >>>
> >>> I understand Jeff's email as a pre-approval of such a patch.
> >>
> >> I think only SC can appoint maintainers, and while Jeff is in the 
> >> SC, my reading of that mail wasn't that it was the SC that has 
> >> acked that, but rather a question if Igor is willing to take that 
> >> role, which then would need to be acked by SC.
> >
> > Where are we on this?  Do we have a maintainer for Cilk Plus and its 
> > run-time library?
> Not at this time.  There was a bit of blockage on various things with 
> the steering committee (who approves maintainers).  I've got a 
> half-dozen or so proposals queued (including Cilk maintainership).

What's the process then, that I get my Cilk Plus (libcilkrts) portability 
patches committed to GCC?  I was advisd this must be routed through Intel 
(Barry M Tannenbaum CCed), which I have done months ago: I submitted the 
patches to Intel, and -- as I understood it -- Barry and I seemed to agree 
about them (at least I don't remember any requests for changes to be made on my 
side), but I have not seen a merge from Intel to update GCC's libcilkrts.  
Should I now commit to GCC the pending patches, 
<http://news.gmane.org/find-root.php?message_id=%3C8738bae1mp.fsf%40kepler.schwinge.homeip.net%3E>
and following?


Grüße,
 Thomas

exepre 24

[D . L M]

Provenance : Courrier pour Windows 10

GCC 4.6 Successful Build and Install

[Guy M. Allard]

configure.guess:

x86_64-unknown-linux-gnu

gcc -v:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/ad3/gma/go-gcc-build/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /ad3/gma/go-build-work/gcc-4.6.0/configure 
--prefix=/ad3/gma/go-gcc-build --enable-languages=c,c++,go

Thread model: posix
gcc version 4.6.0 (GCC)

Languages:

c,c++,go

/etc/issue:

Ubuntu 10.04.2 LTS \n \l

uname -a:

Linux tjjackson 2.6.32-30-generic #59-Ubuntu SMP Tue Mar 1 21:30:46 UTC 
2011 x86_64 GNU/Linux


dpkg -l libc6:

Desired=Unknown/Install/Remove/Purge/Hold
| 
Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend

|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   VersionDescription
+++-==-==-
ii  libc6  2.11.1-0ubuntu Embedded GNU C Library: Shared libraries

Misc:

I had to install package: libc6-dev-i386 to get a successful build.

Goal: working gccgo

Results:

- Simple go programs compile
- Need to use LD_LIBRARY_PATH to get executables to run

Re: Problem with static linking

[Alfred M. Szmidt]

   However, I really implore you: by all means link statically to
   everything else, but leave libc dynamically linked.  I'm not aware
   of any reason not to link libc dynamically, and not doing so leads
   to a ton of problems.

Problems also arise if one uses functions that use NSS (eg. getXbyY
functions like gethostbyname).  In which case, the GNU C library will
try to do a dlopen on several libraries to find the right one.

Re: Compiling programs licensed under the GPL version 2 with GCC 4.4

[Alfred M. Szmidt]

Please take this up with le...@gnu.org.

Re: Compiling programs licensed under the GPL version 2 with GCC 4.4

[Alfred M. Szmidt]

   > a) discussions of licensing issues are off topic on this mailing list
   >
   > b) you should ignore all such discussions, since they invariablly
   > � include lots of legal-sounding opinions from people who are not
   > � lawyers and don't know, and often have significant misconceptions.
   >
   > c) remember that even lawyers don't know what the exactly implications
   > � of copyright law are, juries often surprise. So even if you go ask
   > � a lawyer, you won't get a definitive opinion.

   These three points could be included in a standard answer to
   licensing questions posted to g...@. Invariably, all such threads
   are a waste of time and bandwidth. Perhaps we can include the
   standard answer in some webpage so we can copy+paste or just point
   to it. A first attempt at: http://gcc.gnu.org/wiki/Licensing

The effort is laudable, but the above text has a negative sounding
tone.  It doesn't point users in the right direction.

How about the following wording,

  The most common questions and answers regarding the GNU GPL and how
  it applies can be found in the GNU GPL FAQ
  , if you cannot find the
  answer there please contact  instead of posting your
  question on one of the GCC mailing-lists.

Re: [Dwarf-Discuss] Does gcc optimization impacts retrieving Dwarf information?

[M. Mohan Kumar]

On 05/29/2009 03:11 PM, Mark Wielaard wrote:

(Resent, now actually subscribed to the list from the correct address)

On Fri, 2009-05-29 at 14:28 +0530, M. Mohan Kumar wrote:

That's all true in the abstract, but modern gcc has been known to
abscond with variable location data even for values that are
live/recomputable.  This is the main reason why the VTA (and
debuglocus and other) gcc projects are under way -- to represent the
maximum possible conceptual data, despite -O2 etc.


Frank, Will VTA/debuglocus have the dwarf compatibility (i.e. it does not
need modification to existing applications using libdwarf APIs)?

When can we expect this features (VTA/debuglocus) integrated into mainline
gcc?


Yes, it will output (hopefully better/more complete) dwarf information.
I don't know the schedule details of when this will land in gcc
mainline. But the ideas behind how to improve the tracking of debug
locations for variables in gcc can be found in this paper from Alexandre
Olivia: http://www.lsd.ic.unicamp.br/~oliva/papers/vta/slides.pdf
And on this GCC wiki page:
http://gcc.gnu.org/wiki/Var_Tracking_Assignments


Hi,

In one of the dwarf mail threads it is mentioned that VTA is ready for 
integration into gcc, but its waiting for the acceptance from the 
maintainers.


Are VTA patches part of mainline gcc now? If not, where could we get the 
VTA patches?


Regards,
M. Mohan Kumar.



DebugLocus is an alternative idea on an implementation to improve
tracking debug information from Andrew MacLeod described here:
http://gcc.gnu.org/wiki/AndrewMacLeod/debuglocus

Cheers,

Mark

___
Dwarf-Discuss mailing list
dwarf-disc...@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] Does gcc optimization impacts retrieving Dwarf information?

[M. Mohan Kumar]

On 11/19/2009 04:30 PM, Mark Wielaard wrote:

On Wed, 2009-11-18 at 18:19 +0530, M. Mohan Kumar wrote:

Are VTA patches part of mainline gcc now? If not, where could we get the
VTA patches?


The VTA implementation is in mainline gcc now. There are also some
backports to gcc 4.4, like the gcc that Fedora 12 ships with.


Hi Mark,

Thank you very much for the info. Is there any option needs to be passed 
to gcc to enable this VTA feature?

Support for VLE code in PowerPC

[Kaushik M Phatak]

Hi,

Based on the following conversations in binutils and gcc mailing
list, we understand that there is no support for VLE code for PowerPC
port.
http://sourceware.org/ml/binutils/2008-05/msg00153.html
http://gcc.gnu.org/ml/gcc-help/2009-04/msg00201.html

We are planning to support the same in binutils, gcc and newlib.
Please let us know if you have any suggestions to implement this support
for easier FSF approval.

Thanks,
Kaushik Phatak

Re: printf enhancement

[Alfred M. Szmidt]

   Since it is possible to use the 0b prefix to specify a binary
   number in GCC/C++, will there be any resistance to add %b format
   specifier to the printf family format strings?

You can do that yourself by using the hook facility for printf, see
(libc) Customizing Printf in the GNU C library manual; this is a GNU
extention and not supported by ISO C.

Re: dragonegg in FSF gcc?

[Alfred M. Szmidt]

If the dragonegg and/or LLVM copyright was assigned to the FSF, which
is a prerequisit for anything included in GCC and not what license the
program is under currently, then I'm quite sure that the GCC
maintainers would be more than happy to include both.

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

   legal reasons. The default disclaimer is nonsense, it is hard to find an 
   employer willing to sign a sensible disclaimer, and even when you have a 
   nice employer it can still take months (years?) to get things through the 
   FSF.

If it takes a long time, please contact r...@gnu.org or ass...@gnu.org.

The disclaimers are legally necessary though, the FSF needs a paper
trail in the case your employer comes back and claims that they have
copyright over a change.

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

   My personal opinion is that this legal reason is a *huge*
   bottleneck against external contributions. In particular, because
   you need to deal with it *before* submitting any patch, which,
   given the complexity (4MLOC) and growth rate (+30% in two years) of
   GCC, means in practice that people won't even start looking
   seriously inside GCC before getting that legal paper.

Simply not true, you can submit patches without the legal leg work
done.  The patch cannot be commited to the tree though.  And the time
it takes to do this is less than it took me to read your message...

   Any even since I did send patches to GCC since several years, I am
   still scared even now when sending one.

   Sorry for spaming the list with such non-technical blabla.

You should be more scared of that then sending patches. :-)

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

   The big reason the copyright assignment.  I never even bothered to
   read it, but as I don't get anything in return there's no point.
   Why should put obligaitons on myself, open myself up to even
   unlikely liabilities, just so my patches can merged into the
   official source distribution?

You are still open to liabilities for your own project, if you
incorporate code that you do not have copyright over, the original
copyright holder can still sue you.

   Another reason is the poor patch submission process.  Why e-mail a
   patch if I know, as a new contributor, there's a good chance it
   won't even be looked at by anyone?  Why would I want to go through
   I a process where I'm expected to keep begging until my patch
   finally gets someone's attention?

We are all humans, patches fall through the cracks.  Would you like to
help keeping an eye out for patches that have fallen through?  Would
anyone else like to do this?

   I also just don't need the abuse.  GCC, while not the most of
   hostile of open source projects out there, it's up there.  Manuel
   L�pez-Ib��ez's unjustified hostility towards Michael Witten in this
   thread is just a small example.

Please refer to GCC as a free software project, it was written by the
GNU project and the free software community.  Manuel might have been
rough, but it wasn't hostile.


It seems that the major complaints fall into these categories:

 - Copyright assignments

 - Complex and big project with high standards

Not much can be done to either of those, the copyright assignments are
necessary to keep GCC legally safe.  If a assignment takes a long
time, please contact either r...@gnu.org or ass...@gnu.org; if nobody
says anything then nobody knows anything.

Compilers are complex programs (specially if you support as many front
ends as GCC does), lowering the quality would be disastrous and nobody
really wants that.  The bigger the project, the longer it takes to
become accustomed to it, and not everyone has enough time to get up to
par.  This is not specific to GCC, it affects all large projects.

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

   I have a script that allows me to do the following in a single step:

   gccfarming cleanup
   gccfarming bootstrap
   gccfarming patch PATCH=mypatch.diff
   gccfarming bootstrap
   compare_tests clean.log mypatch.log

That seems useful, could you post a copy of it somewhere?

ada.h _ECHO

[andrew . m . goth]

Today I happened across something that made me scratch my head. 
Perhaps you can help me understand.  Or maybe it's a bug. 

ada.h contains the following preprocessor juju:

#ifdef __STDC__
#define CAT(A,B) A##B
#else
#define _ECHO(A) A
#define CAT(A,B) ECHO(A)B
#endif

For the non-__STDC__ case, why is the macro called _ECHO on one line and
ECHO on the next? 

See for yourself:

http://gcc.gnu.org/viewcvs/trunk/gcc/ada/gcc-interface/ada.h?view=markup

-- 
Andy Goth
   <[EMAIL PROTECTED]>

Re: GCC and the Visual Basic programmer....

[Richard M Stallman]

However,  a proportion of code written for Visual C++ 
makes use of
propriatery runtimes such as MFC, the runtime EULA of which 'currently' 
prevents the use of MFC
based applications with a 'free' OS like ReactOS or GNU based toolchains...

And even if it were permitted, it would be a bad thing to use it,
since it is non-free (user-subjugating) software.

Should there be an alternate but compatible implementation of MFC?

It would be very useful to implement compatible interfaces
but make it run on GNU and Unix systems.

Should there be a way of using Visual Basic style code without using the 
vendors runtime?

Yes.  It would be good to add to GCC a front end for Visual Basic.

Technically speaking, I've been told VB used a p-code form rather than 
direct compliation
to native code, so ..
 Is there a way to automate the conversion/loading of  this p-code into  
form that would compile with
with a GNU derived toolchain?

Since that would still mean using non-free software, it isn't a
solution.  It's just a different form of the same ethical problem.
A solution means doing it without proprietary software.

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

   IANAL but the copyright assignment is probably necessary for the
   FSF to have the rights to change the license at will (within the
   limitations allowed by the copyright assignment). If there are many
   copyright holders, like for say the linux kernel, a change of
   license requires the approval of at least all major copyright
   holders, IIUC.

This is incorrect, anyone can upgrade the license for GCC (and the
rest of the GNU project), since GCC is licensed under the `GPLv3 or
any later version'.  Linux on the other hand is explicitly licensed
only under GPLv2; i.e. it lacks the `or (at your option) any later
version)' clause.

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

   > Not much can be done to either of those, the copyright assignments are
   > necessary to keep GCC legally safe.

   Given that there are plenty of high-profile projects out there
   which seem to be entirely safe in the absence of copyright
   assignment policies, why, exactly, does GCC need one to be "legally
   safe"?

I do not know what high-profile projects you are refering to, you will
have to ask them why they think they can ignore a paper trail.  Having
one copyright holder solves many issues when enforcing copyright, you
do not need to contact all parties.  There is a short article on why
you should assign copyright to the FSF at:
http://www.gnu.org/licenses/why-assign.html

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

The FSF copyright assignments grant you back ultimate rights to use
it in anyway you please.

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

   > Years ago, I was asked to sign one of these documents for some
   > public domain code I wrote that I never intended to become part
   > of a FSF project.  Someone wanted to turn it a regular GNU
   > project with a GPL license, configure scripts, a cute acronym and
   > all that stuff.  I said no.  It's public domain, take it or leave
   > it.  Why I should I sign some legally binding document for some
   > code I had in effect already donated to the public?

   Because that's the only way to PUT something in the public domain!

Well, not entiterly correct... It is very hard to put something into
the public domain (legally) other than dropping dead, and waiting N
years.  What you do is just give a `free for all' license.

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

   >You are still open to liabilities for your own project, if you
   >incorporate code that you do not have copyright over, the original
   >copyright holder can still sue you

   That's irrlevent.  By signing the FSF's document I'd be doing
   nothing to reduce anyone's ability to sue me, I could only be
   increasing them.  And please don't try to argue that's not true,
   because I have no reason to believe you.

Well, it isn't true, the liabilities are exactly the same against you.

   Years ago, I was asked to sign one of these documents for some
   public domain code I wrote that I never intended to become part of
   a FSF project.  Someone wanted to turn it a regular GNU project
   with a GPL license, configure scripts, a cute acronym and all that
   stuff.

If you wrote it, then it is copyrighted and not public domain.
Putting code into the PD is complex, and depending on the place
impossible.  So unless you are a ghost from say 90 years back, the
code was infact copyrighted by you and not in the PD.  The general
method is to ask either for an assignment, or an explicit `free for
all' license.

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

   > If I have the rights to re-license software, and I re-license the
   > software, why do I not have permission to enforce these rights?

   Because you have the permission to re-DISTRIBUTE (not "re-LICENSE")
   the software and nothing else.

In case of GCC, you have the explicit permission to relicense the work
under a later version of the GPL.  In the case of the GNU Lesser GPL,
you have explicit permission to relicense the work under the GPL.  So
depending on the license, you might have permission to relicense the
work.

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

   Wouldn't contributing a patch to be read by the person who will be
   solving the problem, but without transferring of rights, introduce
   risk or liability for the FSF and GCC?

That risk always exists; some level of trust has to exist somewhere.

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

   It's unclear whether the LLVM-style implicit copyright assignment
   is really enforceable, and this certainly isn't a forum to debate
   it.  In any case, it doesn't really matter, because the only reason
   copyright needs to be assigned (AFAIK) is to change the license.

This is not the only reason (and in the GNU projects case, not a
reason at all), the main reason is to be able to enforce the copyright
of the work without having to call in everyone into court.  If only
parts of GCC where copyrighted by the FSF, then the FSF could only sue
only for those parts.

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

   >Given that there are plenty of high-profile projects out there
   >which seem to be entirely safe in the absence of copyright
   >assignment policies, why, exactly, does GCC need one to be
   >"legally safe"?
   > 
   > I do not know what high-profile projects you are refering to

   Kernel, apache, MeeGo, git, for starters.

If with kernel you mean Linux, then they require you to agree to an
type of assignment (though not in paper form), same for git.  Linux
(and git) started with this right around when SCO started threatening
free software projects.  If such a such an agreement is legally
binding or not is for the court to decide, the assignments from the
FSF are legally binding, though (they are contracts).

Apache requires an assignment as well from the looks, see
http://www.apache.org/licenses/icla.txt

I do not know about MeeGo. 

Regarding BusyBox, it was Erik Anderseen who filed suite (via SFLC),
but he can only file suite for the code he holds the copyright over.
If a company manages to remove the code he holds copyright over, and
nobody of the other copyright holders wish to sue, then the company
can go about violating the license.

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

   > And how are potential contributors supposed to know this?

   They're really not.  The fundamental problem here is that this area of
   the law is not only very complicated, but is really all guesswork
   since there are few, if any, relevant cases.  Moreover, this is an
   area of the law where details matter, often quite a bit.

   My suggestion for this process is develop an online form where a
   person specifies various things about their contribution including
   what program it's for an how long it is.  It should ask whether the
   person anticipates submitting more changes.  Then it needs to ask what
   the person's employment status is and in which country.  It should ask
   about terms relating to IPR in any employment agreements.  And so on.

   Then it should be able to come up with a set of choices that would
   cover this person's unique situation.

That is more or less what a potentional contributor gets via email
when submitting a patch.  I don't see how a web form would make things
different.

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

   > That is more or less what a potentional contributor gets via
   > email when submitting a patch.  I don't see how a web form would
   > make things different.

   True, but I think it would make a significant difference if the web
   form could be filled out online without requiring a piece of paper,
   a pen, and a stamp.

There are two forms to be filled out, the `request' and then the
`assignment'.  I'm guessing you are refering to the assignment here,
since that is the paper form--I was refering to the request form.  I'd
love to see that, and all GNU project maintainers would be happy about
it, but that is a topic for the FSF, its lawyers and Richard.

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

   As for flexible, it seems clear that the current form is not
   sufficiently personalized, which makes it more difficult to get it
   signed by an employer.

If you need something specific, you should contact le...@gnu.org.
They are quite flexible, I do not know where people got the idea that
they are not.

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

People will always find reasons to complain, but most people (and
companies) seem to be happy with how the copyright assignments look
today.

Re: Why not contribute? (to GCC)

[Alfred M. Szmidt]

   1) The back-and-forth is too much for casual contributors. If it is
   more effort to do the legal work than to submit the first patch,
   then they will never submit any patch at all.

Please do not exaggerate, if people have time for threads like these,
then they have time to send a short email with some questions or wait
a few days for a piece of paper to sign.

   2) Potential contributors are lost as to what changes to make. I
   was lucky that someone helped me to draft the document but this is
   probably an exception.

Wether a change is required is up to who is signing the form, if they
are not willing to sign it then respective legal departments should be
contacted.

Please contact le...@gnu.org for further discussions about the topic.

[sysad...@gnu.org: [gnu.org #572859] [gcc-bugs-h...@gcc.gnu.org: ezmlm warning]]

[Alfred M. Szmidt]

Not sure where to send this, who is responsible for the mail server
for gcc.gnu.org?

--- Start of forwarded message ---
Subject: [gnu.org #572859] [gcc-bugs-h...@gcc.gnu.org: ezmlm warning] 
From: "Ward Vandewege via RT" 
To: a...@gnu.org
Date: Mon, 10 May 2010 10:28:41 -0400

> [...@gnu.org - Sun May 09 07:42:17 2010]:
> 
> Not sure if it is useful to report these warnings from gcc.gnu.org,
> but here is another warning I got.
> 
> Hi. This is the qmail-send program at sourceware.org.
> I'm afraid I wasn't able to deliver your message to the following
addresses.
> This is a permanent error; I've given up. Sorry it didn't work out.
> 
> :
> 140.186.70.92 failed after I sent the message.
> Remote host said: 550-8-bit characters not allowed in subject
> 550 (see RFC 2822, sections 3.6.5, 2.2.1)
> --- End of forwarded message ---

This was a message with illegal encoding. This is our rule:

  denysenders   = \N[\x80-\xFF]\N
  message   = 8-bit characters not allowed in envelope sender\n\
  (see RFC 2821, section 4.1.2)


The gcc.gnu.org mailserver should really not be accepting that mail either.

Thanks,
Ward.

- -- 
Ward Vandewege 
Free Software Foundation - Senior System Administrator
--- End of forwarded message ---

Re: GFDL/GPL issues

[Alfred M. Szmidt]

I suggest you raise this with lice...@gnu.org.

Re: GFDL/GPL issues

[Alfred M. Szmidt]

   > Therefore, if I don't have an update "soon" (within a week or two), I'd
   > suggest that we operate under the assumption that it will not be
   > possible to combine GFDL manuals and GPL code in the near future.

I think it should be possible, Emacs does something similar I think.

   However, could you (or some other well informed person) elaborate on
   that incompatibility. What exactly is incompatible? Is it some paragraph
   of GPLv3 versus another paragraph of GFDL1.2 - which ones? Or why is it
   incompatible?

The GFDL contains terms that do not exist in the GPL, which is why it
is not compatible

It should be noted that Debian considers the GFDL a non-free
/software/ license; which it is, but then the GFDL is not a software
license to begin with.  The term `non-free license' is very ambiguous.

call_value problem: var = func() !?

[M. -Eqbal Maraqa]

Hello,

I'm working on a new gcc target and trying to implement call_value.
When compiling (-O0 -S) the following c code :

  int f1(int a, int b)
  {
int tmp = a + b;
  return tmp;
  }

  void main()
  {
int a = 10;
int b = 20;
int c;
   
c = f1(a,b);
  }

I get the following error:

f1.c: In function 'f1':
f1.c:5:1: error: unrecognizable insn:
(insn 12 11 13 3 f1.c:4 
   (set (mem/c/i:SI (reg/f:SI 23 [ D.1964 ]) [0 +0 S4 A32])
 (mem/c/i:SI (plus:SI (reg/f:SI 19 virtual-stack-vars)
  (const_int -4 [0xfffc])) 
   [0 tmp+0 S4 A32])) -1 (nil))


I defined expanders and insns only for moving between registers, set
registers with immediate and moving from mem to register and vice versa.
Moving from mem to mem is not allowed. So shouldn't gcc try to force
one of the two mem addresses in a register? I don't even know if that's
what causing the error.


This is the call_value implementation in .md:

(define_expand "call_value"
  [(parallel [(set  (match_operand 0 "register_operand" "")
(call (match_operand 1 "general_operand" "")
  (match_operand 2 "")))
  (clobber (reg:SI RETURN_ADDR_REGNUM))])]
  ""
 {
   rtx dest = XEXP(operands[1], 0);
   
   if(!call_operand(dest, Pmode))
 dest = force_reg(Pmode, dest);
   
   emit_call_insn(gen_call_value_internal(operands[0], dest, operands[2]));
   DONE;
  })

(define_insn "call_value_internal"
  [(parallel [(set  (match_operand 0 "register_operand" "")
(call (match_operand 1 "general_operand" "")
  (match_operand 2 "")))
  (clobber (reg:SI RETURN_ADDR_REGNUM))])]

  ""
  "bal\t%1")


And this is my function_value:

rtx
function_value(const_tree valtype, const_tree func, enum machine_mode mode)
{
 /* first step is an integer-C compiler */ 
 /*G_RET return value reg num = %r1 .*/
  return gen_rtx_REG(SImode, G_RET);
}

I'd be grateful for any help.
Kind regards.
-- 
if [ $(uname) = "Linux" ];then echo 
"[q]sb[lv0=blv256%Plv256/svlcx]sc911084920508\
6363247337574050075032905184391195412274100697358608023133864165787933915045683\
432087129472907338347329339706073226139582008068077725378669120069632svlcxq"|dc;fi;

Re: call_value problem: var = func() !?

[M. -Eqbal Maraqa]

Hello all, hello Richard and thank you for your help.
  
On Wed, 30.06.2010 08:57, Richard Henderson wrote:
> On 06/30/2010 05:06 AM, M. -Eqbal Maraqa wrote:
> > f1.c:5:1: error: unrecognizable insn:
> > (insn 12 11 13 3 f1.c:4 
> >(set (mem/c/i:SI (reg/f:SI 23 [ D.1964 ]) [0 +0 S4 A32])
> >  (mem/c/i:SI (plus:SI (reg/f:SI 19 virtual-stack-vars)
> >   (const_int -4 [0xfffc])) 
> >[0 tmp+0 S4 A32])) -1 (nil))
> 
> I strongly suspect that your movsi expander is incorrect.

Yep, that was the problem. I wrote a stupid predicate for the move
operands, that would allow mem to mem moves, which is not supported by
the architecture and consequently the define_insn.

> You've missed that the operand to call is always a mem.  Most
> ports look through this mem immediately, e.g.

I corrected that one as well.

Kind regards.
-- 
if [ $(uname) = "Linux" ];then echo 
"[q]sb[lv0=blv256%Plv256/svlcx]sc911084920508\
6363247337574050075032905184391195412274100697358608023133864165787933915045683\
432087129472907338347329339706073226139582008068077725378669120069632svlcxq"|dc;fi;

Re: GFDL/GPL issues

[Alfred M. Szmidt]

Please move such unconstructive arguments elsewhere.

Re: GFDL/GPL issues

[Alfred M. Szmidt]

   > > So one way to move forward is to effectively have two manuals,
   > > one containing traditional user-written text (GFDL), the other
   > > containing generated text (GPL).  If you print it out as a
   > > book, the generated part would just appear as an appendix to
   > > the manual, it's "mere aggregation".
   > 
   > This is not acceptable to me. 
   > 
   > You have just described the status quo, what we are already
   > doing. It is very difficult to link api references to manual
   > references in two separate documents. What I want to do is full
   > integration, and not be forced into these aggregations.
   > 
   > And I am being denied.

   You are being denied by RMS.  He controls the copyright, the SC has
   no legal say, and he's stubborn as hell.

When presented with weak arguments, then yes he will be stubborn but
rightly so.  

I don't see what the problem is with two manuals, from a users
perspective I actually prefer that and doing cross referencing between
manuals in texinfo is easy.

Re: GFDL/GPL issues

[Alfred M. Szmidt]

   You probably haven't read this thread fully, or you wouldn't imply
   that GCC should have an "options manual" separate from the user's
   manual.

I have read the thread in full, and I do not see the problem with
keeping that info in a seperate manual; GCC has so many options for
various architectures and systems that I think it makes technical
sense to have a "Invoking GCC" manual.

Re: GFDL/GPL issues

[Alfred M. Szmidt]

   > I have read the thread in full, and I do not see the problem with
   > keeping that info in a seperate manual; GCC has so many options
   > for various architectures and systems that I think it makes
   > technical sense to have a "Invoking GCC" manual.

   And what about libstdc++ API docs, which are currently quite
   difficult to cross-reference with the libstdc++ manual, and cannot
   be included in it?  The API docs come from C++ sources and the
   manual from docbook sources, so texinfo has nothing to do with it.

For a API reference listing document, it would make more sense to
license the work under the GPL, is that possible?  

There is no rule in the GNU project that all types of documentation
must be licensed under the GFDL.  Sometimes it makes sense, good
examples are the gccint, gcc and the emacs manual, and sometimes it
might not like for API reference listings.

Re: GFDL/GPL issues

[Alfred M. Szmidt]

   >You are being denied by RMS.  He controls the copyright, the SC has
   >no legal say, and he's stubborn as hell.
   > 
   > When presented with weak arguments, then yes he will be stubborn
   > but rightly so.
   > 
   > I don't see what the problem is with two manuals, from a users
   > perspective I actually prefer that and doing cross referencing
   > between manuals in texinfo is easy.

   OK, let's say Don Knuth decides he wants to spend his retirement
   contributing to GNU.  RMS is effectively saying that "literate
   programming" is banned from the GNU project and Knuth can just go
   away if he doesn't like it (and yes, requiring GFDL for
   documentation and GPL for code is equivalent to banning literate
   programming).  This is an anti-software-freedom argument, an
   attempt by one man to impose his personal taste.

The GFDL isn't required for all types of documentation, sometimes it
makes sense to use the GFDL for a manual (for example, the emacs
manual) sometimes it might not.  For literate programs, the comments
are as much part of the program as the code, it would make little
sense to require the GFDL for the documentation part of that program.
Infact, the literate programs that are part of the GNU project are
simply licensed under the GPL.  So Knuth is most free to join.  :-)

For some manuals, like the libstdc++ manual as someone mentioned,
maybe relicensing it under the GPL makes the most sense, since it is
mostly a API reference listing.  For other manuals, that contain
little auto-generated text, like the GCC manual, or the GCC Internals
manual, the GFDL makes more sense.

Painting all documentation under a single brush is a huge mistake,
sometimes the GFDL makes sense, sometimes it doesn't.  And one should
look at each specific case separately and make a decision based on
that.

Different invariants about the contents of static links

[Rodney M. Bates]

ov%ecx,0xfffc(%ebp)
  77:   8b 4d fcmov0xfffc(%ebp),%ecx
  7a:   8b 41 fcmov0xfffc(%ecx),%eax
  7d:   8b 00   mov(%eax),%eax
  7f:   a3 00 00 00 00  mov%eax,0x0
  84:   83 ec 0csub$0xc,%esp
  87:   ff 75 08pushl  0x8(%ebp)
  8a:   8b 45 0cmov0xc(%ebp),%eax
  8d:   ff d0   call   *%eax
  8f:   83 c4 10add$0x10,%esp
  92:   c9  leave
  93:   c3  ret

0094 :
  94:   55  push   %ebp
  95:   89 e5   mov%esp,%ebp
  97:   83 ec 18sub$0x18,%esp
  9a:   8d 45 08lea0x8(%ebp),%eax
  9d:   89 45 f4mov%eax,0xfff4(%ebp)
  a0:   8d 45 e8lea0xffe8(%ebp),%eax
  a3:   83 c0 00add$0x0,%eax
  a6:   80 e4 ffand$0xff,%ah
  a9:   b9 58 00 00 00  mov$0x58,%ecx
  ae:   8d 50 0alea0xa(%eax),%edx
  b1:   29 d1   sub%edx,%ecx
  b3:   89 ca   mov%ecx,%edx
  b5:   c6 00 b9movb   $0xb9,(%eax)
  b8:   8d 4d f8lea0xfff8(%ebp),%ecx
  bb:   89 48 01mov%ecx,0x1(%eax)
  be:   c6 40 05 e9 movb   $0xe9,0x5(%eax)
  c2:   89 50 06mov%edx,0x6(%eax)
  c5:   83 ec 08sub$0x8,%esp
  c8:   8d 45 e8lea0xffe8(%ebp),%eax
  cb:   83 c0 00add$0x0,%eax
  ce:   80 e4 ffand$0xff,%ah
  d1:   50  push   %eax
  d2:   8b 45 08mov0x8(%ebp),%eax
  d5:   83 c0 03add$0x3,%eax
  d8:   50  push   %eax
  d9:   8d 4d f8lea0xfff8(%ebp),%ecx
  dc:   e8 8d ff ff ff  call   6e 
  e1:   83 c4 10add$0x10,%esp
  e4:   c9  leave
  e5:   c3  ret

00e6 :
  e6:   55  push   %ebp
  e7:   89 e5   mov%esp,%ebp
  e9:   83 ec 08sub$0x8,%esp
  ec:   83 e4 f0and$0xfff0,%esp
  ef:   b8 00 00 00 00  mov$0x0,%eax
  f4:   83 c0 0fadd$0xf,%eax
  f7:   83 c0 0fadd$0xf,%eax
  fa:   c1 e8 04shr$0x4,%eax
  fd:   c1 e0 04shl$0x4,%eax
 100:   29 c4   sub%eax,%esp
 102:   6a 21   push   $0x21
 104:   e8 fc ff ff ff  call   105 
 109:   83 c4 04add$0x4,%esp
 10c:   83 ec 0csub$0xc,%esp
 10f:   6a 0d   push   $0xd
 111:   e8 fc ff ff ff  call   112 
 116:   83 c4 10add$0x10,%esp
 119:   c9  leave
 11a:   c3  ret
-
--
Rodney M. Bates

Re: Different invariants about the contents of static links

[Rodney M. Bates]

Ian Lance Taylor wrote:

"Rodney M. Bates" <[EMAIL PROTECTED]> writes:



The following example  C code and disassembly is compiled by gcc 3.4.3,
for i686.  It uses two different invariants for what the value of
a static link is.  Everywhere inside P, static link values are consistently
the same as base pointer (%ebp) register values for the same activation
record.  A static link value is generated at 4c: in P, and used at
22: in PInner2 and c: in PInner1.

Everywhere inside similar function Q, static link values consistently point
8 bytes higher than where the base register points.  A value is generated at
d9: in Q and used at 7a: in Qinner2 and 64: in QInner1.

From the examples I have looked at, it looks like it is correct translation,
and, expect for seeming strangeness, is not a problem for execution.

However, I am working on an extended gdb-derived debugger that works,
in part, with code produced by a gcc-derived code generator for
Modula-3.  So far, I can't find out, in the debugger, which invariant
is in use.  I have the debugger correctly both generating and using
static links when evaluating user-typed expressions, using the first
invariant.  I could easily change it to use the second invariant, but
obviously, that would fix some cases and break others.

Is there a compelling reason for this difference?  If not, I would like to
make it all use invariant one.  Also, does anybody know where in gcc this
difference is happening?  I poked around in the source for a couple of hours,
but didn't see anything obvious.



The static link pointer points to a part of the stack frame which
includes the information required for the nested functions.  The
amount of information required changes depending on the code.
Therefore, the static link pointer will not be a constant offset from
the frame pointer.  I don't believe that it is possible to change this
while still handling calls between doubly nested functions, but maybe
I just haven't thought about it hard enough.


I don't understand this.  A pointer to anywhere in an activation record
(or even outside it, if outside by a fixed offset) allows access to
exactly the same set of things as any other, including the value the base
register holds when the activation record is current.  That set is everything
in the AR, using different but still fixed displacements, and nothing more,
since everything else is not necessarily at a fixed displacement from the
AR.

Signed displacements are already required anyway when using the normal base
pointer, so it must not be to keep them all the same sign.  Anyway, the
observed shift in where SLs point is the wrong way to get all displacements
to the same sign.

As for multiple levels of nested functions, that always requires one static
link for every level in the nesting, each to a different AR.  Either consistent
or varying SL target locations generalizes to multiple levels with equal ease.

I am curious about the local pointer to nonlocally-accessed 
variables/parameters.
In my examples, this always is located in the same AR as the field it points to,
thus is unnecessary, since its target field could be accessed directly, using 
the
right displacement.  Does it ever point across different ARs?  I wonder if this
mechanism interacts with the invariant about where the SL points, but I can't
imagine how it would.




BTW, this is using stabs.  I know that is not very complete, but it would be
a lot more work than I want to do to change it.



Stabs doesn't represent the static link pointer at all, so that is
your problem.  You should switch to DWARF.  If that is impossible as
you suggest, then I think your most profitable approach would be to
enhance stabs somehow.

Ian



--
Rodney M. Bates

Re: Different invariants about the contents of static links

[Rodney M. Bates]

Well, I agree with what you said about your example, but it's not what
I am meaning.  See below.

Ian Lance Taylor wrote:

"Rodney M. Bates" <[EMAIL PROTECTED]> writes:



I don't understand this.  A pointer to anywhere in an activation record
(or even outside it, if outside by a fixed offset) allows access to
exactly the same set of things as any other, including the value the base
register holds when the activation record is current.  That set is everything
in the AR, using different but still fixed displacements, and nothing more,
since everything else is not necessarily at a fixed displacement from the
AR.



OK, let me reset.

It seemed to me that you were suggesting that the static link pointer
should always be a constant offset from the frame pointer.


No, I am not saying this.  If it were so, there would be no need for a
SL at all.  You could just use the FP to access both local and nonlocal
things.



gcc doesn't work that way, though.  Here is a simple counter-example.

int
foo (int x, int y)
{
  int
  s1 ()
  {
if (--y == 0)
  return 0;
return x + s1 ();
  }

  return s1 ();
}

If you compile this code, you will see that the static link pointer is
passed down unchanged through the recursive calls.  The frame pointer
is, of course, different for each call.  You can't compute the static
link pointer from the frame pointer.  It's completely independent.

If this is not a counter-example for what you want, then I think we
need a clearer explanation of what you want.


Consider this slightly different example:

int
foo (int x, int y)
{ int loc;

  int
  s1 ( )
{ if (--y == 0)
return 0;
  return loc  + s1 ();
}

  loc = x;
  return s1 ();
}

I added a local variable loc to s1, and both s1 and foo access loc.

When executing in foo, the frame pointer will point to a fixed spot in the
activation record of foo.  On i386, the FP is %ebx and it points to the
dynamic link field.  From there, loc is at displacement -4.  Code in the
body of foo will reference x at -4(FP).

When we get into any instance of s1, s1's AR will contain a static link that
points to the AR of foo, which is what you said.  The question is where
in s1's AR does the SL point to.  It would make sense for it to be the same
as where the frame pointer points when executing in foo, i.e., the static
link would point to the dynamic link field of foo's AR.  Then x could be
accessed from within sl by loading the SL into some register, say REG, and
referring to -4(REG).  loc is at the same displacement relative to the static
link in s1 as is used in foo relative to the FP.

This is exactly what happens in this example, all of which makes sense to
me.   However, in somewhat more complicated examples, the SL value passed
to s1 is not a copy of foo's FP, but instead the _value_ of the SL is
a copy of foo's FP, minus 8.  (I think I said this backwards in my original
post.)  Then loc would be accessed, from within s1, at a different
displacement (+4) relative to the SL pointer, whereas the same AR field is
accessed at displacement -4 relative to FP when within foo.

This all executes correctly, even if it's a bit strange.  But it has to take
extra trouble for the code generator to keep track of two different reference
addresses for the same AR and adjust SL offsets to be different from FP
offsets for the same AR.  I can't see any benefit.  It doesn't change the
set of fields a SL can access in the AR it points to a bit.  Only the
displacements needed change.

And it wouldn't matter to me, except it's making it a lot more difficult
to give gdb the ability to execute gdb-user-typed calls on nested functions
and pass nested functions as parameters (where gdb has to generate static
link values) and print nonlocal variables (where gdb has to know how to
interpret the contents of a SL).

To get the different invariant about where in an AR the SL points to, the
smallest case I could get has 1) two side-by-side nested functions inside
the outer function, 2) one of the nested functions has a parameter
of pointer-to-function type, and 3) the other nested function is passed
as the argument to said parameter.  This involves building a trampoline
that loads the static ancestor pointer.  In this case, passing a fixed
static link, constructing the static ancestor value in the trampoline,
and using a static link all use the other invariant that static link
values point 8 bytes lower than where a FP to the same AR points. Here
is the example:

int foo ( int x )

  { int loc;

int s1 ( int j )
  { return loc + j;
  }

int s2 ( int k, int ( * func ) ( int ) )
  { return func ( k );
  }

loc = x;
return s2 ( loc , s1 );
  }

When accessing parameters instead of local variables, the waters are muddied
by another mechanism that also seems unnecessary to me, but I think is
unrelated to my question.  This is why I switched to a local variable in the
examples.



Ian



--
Rodney M. Bates

A correction: Different invariants about the contents of static links]

[Rodney M. Bates]

This is repost of my slightly earlier post, with a critical and
confusing misstatement corrected.


Well, I agree with what you said about your example, but it's not what
I am meaning.  See below.

Ian Lance Taylor wrote:

"Rodney M. Bates" <[EMAIL PROTECTED]> writes:



I don't understand this.  A pointer to anywhere in an activation record
(or even outside it, if outside by a fixed offset) allows access to
exactly the same set of things as any other, including the value the base
register holds when the activation record is current.  That set is everything
in the AR, using different but still fixed displacements, and nothing more,
since everything else is not necessarily at a fixed displacement from the
AR.



OK, let me reset.

It seemed to me that you were suggesting that the static link pointer
should always be a constant offset from the frame pointer.


No, I am not saying this.  If it were so, there would be no need for a
SL at all.  You could just use the FP to access both local and nonlocal
things.



gcc doesn't work that way, though.  Here is a simple counter-example.

int
foo (int x, int y)
{
  int
  s1 ()
  {
if (--y == 0)
  return 0;
return x + s1 ();
  }

  return s1 ();
}

If you compile this code, you will see that the static link pointer is
passed down unchanged through the recursive calls.  The frame pointer
is, of course, different for each call.  You can't compute the static
link pointer from the frame pointer.  It's completely independent.

If this is not a counter-example for what you want, then I think we
need a clearer explanation of what you want.


Consider this slightly different example:

int
foo (int x, int y)
{ int loc;

  int
  s1 ( )
{ if (--y == 0)
return 0;
  return loc  + s1 ();
}

  loc = x;
  return s1 ();
}

I added a local variable loc to s1, and both s1 and foo access loc.

When executing in foo, the frame pointer will point to a fixed spot in the
activation record of foo.  On i386, the FP is %ebx and it points to the
dynamic link field.  From there, loc is at displacement -4.  Code in the
body of foo will reference x at -4(FP).

When we get into any instance of s1, s1's AR will contain a static link that
points to the AR of foo, which is what you said.  The question is where
in foo's AR does the SL point to.  It would make sense for it to be the same
as where the frame pointer points when executing in foo, i.e., the static
link would point to the dynamic link field of foo's AR.  Then x could be
accessed from within sl by loading the SL into some register, say REG, and
referring to -4(REG).  loc is at the same displacement relative to the static
link in s1 as is used in foo relative to the FP.

This is exactly what happens in this example, all of which makes sense to
me.   However, in somewhat more complicated examples, the SL value passed
to s1 is not a copy of foo's FP, but instead the _value_ of the SL is
a copy of foo's FP, minus 8.  (I think I said this backwards in my original
post.)  Then loc would be accessed, from within s1, at a different
displacement (+4) relative to the SL pointer, whereas the same AR field is
accessed at displacement -4 relative to FP when within foo.

This all executes correctly, even if it's a bit strange.  But it has to take
extra trouble for the code generator to keep track of two different reference
addresses for the same AR and adjust SL offsets to be different from FP
offsets for the same AR.  I can't see any benefit.  It doesn't change the
set of fields a SL can access in the AR it points to a bit.  Only the
displacements needed change.

And it wouldn't matter to me, except it's making it a lot more difficult
to give gdb the ability to execute gdb-user-typed calls on nested functions
and pass nested functions as parameters (where gdb has to generate static
link values) and print nonlocal variables (where gdb has to know how to
interpret the contents of a SL).

To get the different invariant about where in an AR the SL points to, the
smallest case I could get has 1) two side-by-side nested functions inside
the outer function, 2) one of the nested functions has a parameter
of pointer-to-function type, and 3) the other nested function is passed
as the argument to said parameter.  This involves building a trampoline
that loads the static ancestor pointer.  In this case, passing a fixed
static link, constructing the static ancestor value in the trampoline,
and using a static link all use the other invariant that static link
values point 8 bytes lower than where a FP to the same AR points. Here
is the example:

int foo ( int x )

  { int loc;

int s1 ( int j )
  { return loc + j;
  }

int s2 ( int k, int ( * func ) ( int ) )
  { return func ( k );
  }

loc = x;
return s2 ( loc , s1 );
  }

When accessing parameters instead of local variables, the waters are muddied
by another mec

Re: config/gnu.h, config/i386/gnu.h don't include copyright notices

[Alfred M. Szmidt]

   Is there a reason why both config/gnu.h and config/i386/gnu.h don't
   include copyright notices or even the license they are under.  Does
   that mean they are in the public domain or did someone mess up when
   contributing them?

They are (or were) non-trivial enough not to require a copyright
notice.

Re: config/gnu.h, config/i386/gnu.h don't include copyright notices

[Alfred M. Szmidt]

   They are (or were) non-trivial enough not to require a copyright
  
   notice.

I obviously mean that they were _trivial_ enough not to require a
copyright notice.

Re: A correction: Different invariants about the contents of static links]

[Rodney M. Bates]

OK, Thanks for the information.  Just in case, does anybody already
have it in their head roughly where in gcc code this decision is made?

Ian Lance Taylor wrote:

"Rodney M. Bates" <[EMAIL PROTECTED]> writes:



When executing in foo, the frame pointer will point to a fixed spot in the
activation record of foo.  On i386, the FP is %ebx and it points to the
dynamic link field.  From there, loc is at displacement -4.  Code in the
body of foo will reference x at -4(FP).

When we get into any instance of s1, s1's AR will contain a static link that
points to the AR of foo, which is what you said.  The question is where
in foo's AR does the SL point to.  It would make sense for it to be the same
as where the frame pointer points when executing in foo, i.e., the static
link would point to the dynamic link field of foo's AR.  Then x could be
accessed from within sl by loading the SL into some register, say REG, and
referring to -4(REG).  loc is at the same displacement relative to the static
link in s1 as is used in foo relative to the FP.



Thanks for the explanation.  I think I may now understand what you are
getting at.

Consider this slight adjustment to your example:

extern void bar (int *, int *);
int
foo (int x, int y)
{
  int a;
  int loc;
  int b;

  int
  s1 ()
  {
if (--y == 0)
  return 0;
return loc  + s1 ();
  }

  loc = x;
  bar (&a, &b);
  bar (&a, &b);
  return s1 ();
}

When I compile this, the static chain is 24 bytes off from the frame
pointer.  That example was just to show an aspect of how gcc
implements the activation record.  gcc builds a struct holding all the
information which needs to be referenced.  Then it passes the address
of that struct as the static chain.

If you pass a variable size object (e.g., int a[i]) then gcc will
store a pointer to that object in the activation record.  gcc will
also store a pointer if you try to pass down a struct which is a
parameter in the calling function.  These are examples where it isn't
obvious that we want the static chain pointer to be the same as the
frame pointer.

That said, I think I now agree that since the activation record always
has a constant size, we could make the static chain pointer always be
the same as the frame pointer.  The users would apply a constant
offset to their static chain pointer to get to the activation record.

Issues would arise on processors with limited offset space in
addresses, but those issues are solvable.



This all executes correctly, even if it's a bit strange.  But it has to take
extra trouble for the code generator to keep track of two different reference
addresses for the same AR and adjust SL offsets to be different from FP
offsets for the same AR.  I can't see any benefit.  It doesn't change the
set of fields a SL can access in the AR it points to a bit.  Only the
displacements needed change.



Actually, it is not extra trouble for the code generator, it is less
trouble.  The code generator simply builds an internal struct to serve
as the activation record, puts the struct on the stack, and makes the
static chain always be a pointer to that struct.  The code generator
moves simple values into the struct, and stores pointers for complex
values.  Then all references through the static chain are easy to
implement.

Making the static chain be the same as the frame pointer requires a
bit of extra work because the frame pointer can be eliminated to the
stack pointer (via the -fomit-frame-pointer option, which is the
default for some processors when optimizing).  The static chain
pointer would have to be eliminated just as the frame pointer is.



And it wouldn't matter to me, except it's making it a lot more difficult
to give gdb the ability to execute gdb-user-typed calls on nested functions
and pass nested functions as parameters (where gdb has to generate static
link values) and print nonlocal variables (where gdb has to know how to
interpret the contents of a SL).



To make that work is going to take more than making the static chain
pointer and the frame pointer equivalent.  You are going to have to
know how to build the activation record, which as we have seen can
contain pointers to variables which live in the frame.

So I think you are on the wrong path here.  Instead of trying to
equate the static chain pointer and the frame pointer, I think what
you need to do is find some way for the debugging information to
describe the activation record, and to describe where it lives on the
stack.

Ian



--
Rodney M. Bates

Re: Update to GCC copyright assignment policy

[Bradley M. Kuhn]

As most of you are probably aware, glibc is also discussing whether or not
to remove the copyright assignment mandate to the FSF.  I have posted a
comment there regarding that, now available at:
   https://sourceware.org/pipermail/libc-alpha/2021-June/128303.html
… which is supplemented by a longer essay that I published here:
   https://sfconservancy.org/blog/2021/jun/30/who-should-own-foss-copyrights/

I believe there are many complex issues related to the issue of where
copyrights for Free Software projects like GCC go, and while I've written
quite a lot of detail there, I think some of what I've written may be useful
as GCC considers how to build long-term robust plans to assure that the
copyleft of GCC is upheld for the long-term.
-- 
Bradley M. Kuhn - he/him
Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy

Become a Conservancy Supporter today: https://sfconservancy.org/supporter

Re: sanitizers support for windows??

[Stephen M. Webb]

On 2021-09-17 07:52, unlvsur unlvsur via Libstdc++ wrote:
> I find that clang can build sanitizers correctly but libstdc++ does not work 
> with sanitizers since it does not support related functionalities with 
> sanitizers on windows.
> 
> Can we start to add support for sanitizers for windows?? I honestly do not 
> think that would take a huge amount of time.

Our experience at QNX is that other than ubsan, the santizers require 
considerable interworking with the GNU libc and
are not trivial to port to an OS that uses a different libc. Since these are 
actually third-party software any porting
effort or contribution should probably go through the upstream LLVM project to 
avoid forking.

Don't let that stop you from developing a port though.

-- 
Stephen M. Webb  

Reporitng libstdc++ bug without account to Bugzilla

[Palmu, Miro M]

Hi

I think I found libstdc++ bug and I tried to report to Bugzilla but "user 
account creation has been restricted".

So I'm going to report it here in hope that someone with a account could report 
it to Bugzilla if they seem it fit.

Using gcc 13.2 with -std=c++23 code below (https://godbolt.org/z/Kc36rcMYx) 
does not compile even if all compile time
allocations are freed before returning from compile time context. MSVC is able 
to compile it.

I was suggested elsewhere that it could be some oversight in the SSO 
implementation.
 
```
#include 
#include 
#include 
#include 

using namespace std;
using namespace std::literals;

constexpr auto foo() {
const auto vec = vector{ "a"s, "b"s, "c"s };
return ranges::fold_left(vec, ""s, plus{});
}

constexpr auto bar() {
return foo().size();
}

int main() {
constexpr auto _ = bar(); // This does not compile
}
```

Error message:

```
: In function 'int main()':
:19:27:   in 'constexpr' expansion of 'bar()'
:15:23:   in 'constexpr' expansion of 'foo()()'
:19:28:   in 'constexpr' expansion of 
'std::ranges::__fold_left_fn::operator()(_Range&&, _Tp, _Fp) const [with _Range 
= const std::vector, 
std::allocator > >&; _Tp = 
std::__cxx11::basic_string; _Fp = std::plus](vec, 
std::literals::string_literals::operator""s(const char*, std::size_t)(0), 
(std::plus(), std::plus()))'
:19:28:   in 'constexpr' expansion of 
'std::__cxx11::basic_string((* & 
std::move<__cxx11::basic_string&>(__init)))'
:19:28: error: accessing 'std::__cxx11::basic_string_M_allocated_capacity' member instead of initialized 
'std::__cxx11::basic_string_M_local_buf' member in 
constant expression
   19 | constexpr auto _ = bar();
  |^
```

Miro Palmu

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Alfred M. Szmidt]

 - Have them distributed (automake's default).  This means that
   they will be build in the srcdir, not in the builddir: of
   course, this only affects the maintainer, since for a user that
   builds the package from a tarball those files should *not* be
   rebuilt, hence there is no problem even if the user's srcdir is
   read-only.

This has always been the right way to do things.

 - Don't distribute the generated info files.  [...]  In this
   case, the user will have to to have the 'makeinfo' program
   available to build them.

Please don't do this, it causes all kinds of headaches, like the small
fact that makeinfo will now be required to bootstrap.

XML dump for GCC

[Brian M. Ames]

Hello,

I have substantially completed an extension that would allow dumps to be
emitted as XML.  I would like to contribute it to the FSF for inclusion in
the GCC distribution.  Please let me know if there is interest in this.

Thanks,

Brian M. Ames

Re: -Wparentheses lumps too much together

[Derek M Jones]

All,

Developer knowledge of operator precedence and the issue of what
they intended to write are interesting topics.  Some experimental
work is described in (binary operators only I'm afraid):

www.knosof.co.uk/cbook/accu06a.pdf
www.knosof.co.uk/cbook/accu07a.pdf

The ACCU 2006 experiment provides evidence that developer knowledge
is proportional to the number of occurrences of a construct in
source code, it also shows a stunningly high percentage of incorrect
answers.

The ACCU 2007 experiment provides evidence that the names of the
operands has a significant impact on operator precedence choice.

The data from the ACCU06 experiment might be used to select a cutoff
above (ie, frequency of occurrence or developer performance) which
operator pairs will not be flagged as requiring parenthesis.

If GCC wanted to be even more selective it could look at the operand
names before deciding whether to complain.

ps.
I am always on he look out for opportunities to run experiments
using experienced developers.  Does anybody have any suggestions
for conferences I might approach?

--
Derek M. Jones  tel: +44 (0) 1252 520 667
Knowledge Software Ltd  mailto:[EMAIL PROTECTED]
Applications Standards Conformance Testinghttp://www.knosof.co.uk

Re: RFH: testers for ieee test

[Derek M Jones]

Joern ,

You could try using softfloat:
http://www.jhauser.us/arithmetic/SoftFloat.html

--
Derek M. Jones  tel: +44 (0) 1252 520 667
Knowledge Software Ltd  mailto:[EMAIL PROTECTED]
Applications Standards Conformance Testinghttp://www.knosof.co.uk

Re: Official GCC git repository

[Alfred M. Szmidt]

   >  I think the mistake is to have them (git & hg) hosted on the
   >  same machine as svn. Having them on "hg.gcc.gnu.org" and
   >  "git.gcc.gnu.org" would allow to split the load between machines
   >  (even if "hg.gcc.gnu.org" and "git.gcc.gnu.org" are the same
   >  machines originally).

   This would be a great idea, if only we had more machines :) Sadly,
   machines and dns names are tricky for political reasons around gcc.

Maybe they could be hosted on Savannah?  The CVS repo. used to be
synced there.

Re: Official GCC git repository

[Alfred M. Szmidt]

   >>  I think the mistake is to have them (git & hg) hosted on
   >>  the same machine as svn. Having them on "hg.gcc.gnu.org"
   >>  and "git.gcc.gnu.org" would allow to split the load between
   >>  machines (even if "hg.gcc.gnu.org" and "git.gcc.gnu.org"
   >>  are the same machines originally).
   >
   >This would be a great idea, if only we had more machines :)
   >Sadly, machines and dns names are tricky for political reasons
   >around gcc.
   >
   >  Maybe they could be hosted on Savannah?  The CVS repo. used to
   >  be synced there.

   Used to, and then one day they just stopped doing it without telling
   anyone, and questions went unanswered.

Sorry, that never happend AFAIK.  I used the GCC CVS repo
there, was never out of sync for me.

   So uh, thanks but no thanks :)

Same thing can happen here; nothing extraordinary with that...

Re: GCC 4.2.4 Released

[Paul M. Dubuc]

Joseph S. Myers wrote:

GCC 4.2.4 has been released.

GCC 4.2.4 is a bug-fix release, containing fixes for regressions in GCC 
4.2.3 relative to previous GCC releases.  This release is available from 
the FTP servers listed at:


  http://www.gnu.org/order/ftp.html

Please do not contact me directly regarding questions or comments about 
this release.  Instead, use the resources available from 
http://gcc.gnu.org.


As always, a vast number of people contributed to this GCC release -- far 
too many to thank individually!
  
I have been trying to find a list of bugs that have been fixed in this 
release without any success.  How do I find this information about a 
given release?


Thanks,

--
   Paul M. Dubuc

Re: GCC 4.2.4 Released

[Paul M. Dubuc]

Andrew Haley wrote:

Paul M. Dubuc wrote:
  

Joseph S. Myers wrote:


GCC 4.2.4 has been released.

GCC 4.2.4 is a bug-fix release, containing fixes for regressions in
GCC 4.2.3 relative to previous GCC releases.  This release is
available from the FTP servers listed at:

  http://www.gnu.org/order/ftp.html

Please do not contact me directly regarding questions or comments
about this release.  Instead, use the resources available from
http://gcc.gnu.org.

As always, a vast number of people contributed to this GCC release --
far too many to thank individually!
  
  

I have been trying to find a list of bugs that have been fixed in this
release without any success.  How do I find this information about a
given release?



The ChangeLogs are a good place to start.

Andrew.
  
Thanks.  Where can I find them?  If you mean 
http://gcc.gnu.org/gcc-4.2/changes.html I looked there already and I 
don't see any information about what was fixed specifically in 4.2.4.  I 
also tried querying the bugs database with no luck.


--
   Paul M. Dubuc

Re: GCC 4.2.4 Released

[Paul M. Dubuc]

Andrew Haley wrote:

Paul M. Dubuc wrote:
  

Andrew Haley wrote:


Paul M. Dubuc wrote:
 
  

Joseph S. Myers wrote:
   


GCC 4.2.4 has been released.

GCC 4.2.4 is a bug-fix release, containing fixes for regressions in
GCC 4.2.3 relative to previous GCC releases.  This release is
available from the FTP servers listed at:

  http://www.gnu.org/order/ftp.html

Please do not contact me directly regarding questions or comments
about this release.  Instead, use the resources available from
http://gcc.gnu.org.

As always, a vast number of people contributed to this GCC release --
far too many to thank individually!

  

I have been trying to find a list of bugs that have been fixed in this
release without any success.  How do I find this information about a
given release?



The ChangeLogs are a good place to start.

Andrew.
  
  
Thanks.  Where can I find them? 



In the source code.  The top-level directory has on, as does the gcc directory,
and so on.

Andrew.
  
Thanks!  I found it. I looked there but didn't see the file at first.  
Was expecting it to be an ALL CAPS name, I guess.

Sorry,
PMD

--
   Paul M. Dubuc

libstdc++ is having "out of memory" string

[sanjeev kumar m]

Hi All,

I am getting "out of memory" strings error log of our product. It
seems that error message "out of memory" doesn't have our common error
format.

We suspect that GCC library libstdc++.a is giving this error code.

#strings libstdc++.a | egrep "out of memory"
out of memory

Can you please clarify this?

Regards

Sanjeevi

Re: poor optimisation case

[Alfred M. Szmidt]

   > Any chance of moving to launchpad.net?

   And launchpad.net forces everyone else to remember a new username
   and password.

Launchpad is also non-free software.

Why is building a cross compiler "out-of-the-box" always broken?

[Stephen M. Kenton]

Hello all,

Several years ago in the gcc 3.3 time frame I looked into building cross 
compilers using the current versions of gcc, glibc etc. for a number of 
different systems.  I quickly found that it was a quagmire.  I inquired 
of this list at that time and was told that the glibc hack was 
problematic and that things would not be fixed in gcc 3.4 but might get 
better by gcc 3.5 (which eventually became gcc 4.0).  I worked around my 
need at that time and went on to other things.  Recently out of 
curiosity I dug out the problem and took another look.  Except for the 
fact that the Linux kernel build system now supports headers_install to 
provide a reliable set of sanitized header, not much seems to have 
changed.  I realize that there are various "solutions" for specific 
platforms.  Dan Kegel's excellent crosstool and the cross-lfs website, 
for example, are testaments to the people who have labored to circumvent 
this problem.  However, the question remains, why is the problem still 
there to be circumvented?  Is there some secret opposition to easy use 
of these tools, is there some law of nature that prevents them from 
building, is there some good technical reason that is hard to implement, 
or has it just not been a big enough pain for anyone to beat it into 
submission?  As it stands currently, it looks like gcc needs both the 
kernel (for unwind support) and glibc  (for generic C reasons) headers 
*for the target* to build  a cross compiler for that target, but glibc 
needs a functioning cross compiler for that target before it will even 
configure so you can try to "make install-headers".  Mean while, back at 
the ranch, the inhibit_libc hack does not seem to be implemented 
everywhere needed for a successful build and the gcc configure seems to 
have a curious need for the --with-newlib  flag to really mean we want 
inhibit_libc as well as handling with_sysroot and with_headers rather 
differently. (See the fragment below from gcc 4.2.1) As an aside, I 
suspect that there are subtle assumptions that the build/host glibc 
headers are the same as the target glibc headers in some respects.  Way 
back, I was trying to cross compile on Solaris using a complete self 
hosting gnu tool chain and I saw some very strange failure.  In the 
current experiment I am using a more-or-less up to date Linux system, 
but if/when building a cross compiler works I could resurrect the 
Solaris test environment to check for portability issues of that type.  
For now I'm just looking at current Linux build/host/targets.


So, my open questions to the list are, what is/should be the preferred 
way to bootstrap a cross compiler/glibc environment?
What needed to be done to get there from here?  Does the inhibit_libc 
hack need to be extended, ripped out and replaced, or just better 
documented?  I will follow this discussion on the gcc mailing list 
archive since I'm not subscribed, but I'm willing to test stuff if 
anyone wants me to.  Or, if it really does work currently and I'm just 
an idiot, could some kind soul hit me with a clue-bat and point me to a 
descriptions of the solution.


# inhibit_libc

# If this is using newlib, without having the headers available now,
# then define inhibit_libc in LIBGCC2_CFLAGS.
# This prevents libgcc2 from containing any code which requires libc
# support.
inhibit_libc=false
if { { test x$host != x$target && test "x$with_sysroot" = x ; } ||
  test x$with_newlib = xyes ; } &&
{ test "x$with_headers" = x || test "x$with_headers" = xno ; } ; then
  inhibit_libc=true
fi

Thanks - Steve