Re: Miscompilation of remainder expressions

[Michael Veksler]

Gabriel Paubert wrote:

On Mon, Jan 15, 2007 at 10:34:23PM +0200, Michael Veksler wrote:
  

Once the kernel sees the FP trap (whatever its i368 name is),
it decodes the machine code and finds:
idivl  (%ecx).
As far as I remember, this will put the result in two registers
one for div_res and one for mod_res.

Since MIN_INT/-1 is undefined, the kernel may put MIN_INT
in div_res, and mod_res=1. Then return to the following instruction.

Should I open a request for the kernel?



No, because the instruction has actually two result values:

- the remainder, which you could safely set to zero (not 1!)

  

My typo, right.

- the quotient, which is affected by the overflow and there may be
  compiler and languages that rely on the exception being generated.

  

Right, there are languages besides C/C++ and compilers other than GCC,
not to speak of assembly code.
Solution: let GCC generate a redundant prefix, such as ecs. If

   ecs eds idivl (%ecx).
   or
   ecs ess idivl(%ecx)
   or
   ecs ecs idivl(%ecx)
   etc.

generates a trap, only then will the kernel set the remainder to 0
and the quotient to MIN_INT. (Starting with i686 decoding redundant
prefixes costs zero cycles, am I right?)

The kernel cannot know whether you are going to use
the quotient or not by simply decoding the instruction.

  
It does not matter if quotient is used because in C/C++ its value is 
undefined.

For -fwrapv -MIN_INT/-1 == -MIN_INT*-1 == -MIN_INT.
For -ftrapv, then yes we want the signal (otherwise more instructions are
required to trap on the overflow).

Actually I believe that a%b and a%(-b) always return the same value
if we follow the C99 specification. So if you are only interested
in the remainder, you can simply use a%abs(b) instead of a%b. The
overhead of abs() is really small.  
  

Compared to the slow idivl, abs could be negligible, right. However, abs
does introduce new data dependence which might add a noticeable cost.
My x86 assembly days have gone twelve years ago, so I can't remember:

   Is there an abs instruction in the i386 instruction set?

If not, then adding a conditional branch for: a=a<0?-a:a is not that
cheap. It uses up branch-prediction resources, and if it misses predictions
then branching can be quite slow (depending on e.g. pipeline depth).
Such a change has to be benchmarked. People are not going to be
happy if this makes their code regress by 5%.


--
Michael Veksler
http:///tx.technion.ac.il/~mveksler

Re: Unsure about a new warning in mainline

[Manuel López-Ibáñez]

So the warning turned out to be useful or still was it too noisy ?
Sorry, I am not perfectly following this discussion.

Cheers,

Manuel

On 15 Jan 2007 19:16:23 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:

Paolo Carlini <[EMAIL PROTECTED]> writes:

> Therefore, I'd like to apply to mainline the below (finishing testing
> on x86-linux), can you check it?
>
> Thanks in advance,
> Paolo.
>
> /
> 2007-01-15  Ian Lance Taylor  <[EMAIL PROTECTED]>
>   Paolo Carlini  <[EMAIL PROTECTED]>
>
>   * include/ext/type_traits.h: Fix __glibcxx_max macro.
>   * include/std/limits: Likewise.

Looks right to me.

Ian

Re: Unsure about a new warning in mainline

[Gabriel Dos Reis]

On Tue, 16 Jan 2007, Manuel López-Ibáñez wrote:

| So the warning turned out to be useful or still was it too noisy ?

It is still noisy.

The limit macro fixes does not magically turn off the signed -> unsigned
noise -- it fixed a warning about overflow.
I'll send a separate message for the signed -> unsigned warning.

-- Gaby

Re: Cheatsheet for building gcc

[Zdenek Dvorak]

Hello,

thanks a lot for the answers!

> >Q4) How to compile all the libraries (libjava, ...) using the stage1
> >compiler?
> 
> A4) Configure with --enable-stage1-languages=all

Is there a way how to do it without reconfiguring gcc?  This question
aims at the following situation: I already have compiled the stage1
compiler with a patch, and I have learned from some external source
that the compiler ICEs during the compilation of libjava.  Since it
is highly unlikely that bootstrapping the compiler would matter,
I would like to be able to just start building libjava using stage1
compiler.  Reconfiguring gcc and building it from scratch takes
some time, so I would like to avoid that.

> >Q6) How to clean up everything except for the stage1 compiler and
> >its runtime (libgcc, libmudflap, libgomp)?
> 
> make restrap (which will also start a bootstrap)

Would it be possible to add a possibility to just clean up the things,
without restarting the bootstrap (i.e., to move everything to the
state I would have after "make stage1-bubble" if I started from the scratch)?

Zdenek

> >And of course, how to do any other useful things that I have forgotten
> >about...
> 
> I would like to ask if, in your opinion, libssp, libmudflap and libgomp 
> should be bootstrapped like libgcc is.  I would think that, for 
> automatic parallelization, you'd need at least libgomp.
> 
> In this case, the answer to Q3 would be simply "make stage1-bubble".
> 
> Paolo

relevant files for target backends

[Markus Franke]

Dear GCC Developers/Users,

I am trying to port a backend from GCC version 2.7.2.3 to version 4.1.1.
As far as I have seen, a lot of new relevant files were introduced to
build a good structure for new backends.

I am wondering where to define the prototypes for functions in
.c Shall the prototypes be defined in -protos.h or in
.h or in .c. As far as I understand the prototypes
should be defined in -protos.h, right? But if I do so several
errors/warnings arise because of undeclared prototypes.

Another question is where target macros should be defined. As far as I
can see .c has something like such a structure:

---snip---
#define 
#define 
#define 
#define 

struct gcc_target targetm = TARGET_INITIALIZER;
---snap---

But there are also a lot of macros defined in .h. What kind of
macros should be defined in .h and which macros should be
defined in .c?

I try to write good and standardised code in order to contribute my
development. I would appreciate any help. By the way, I already had a
look in the GCC Internals manual but I am still a bit confused.


Thanks in advance and regards,
Markus Franke

Re: relevant files for target backends

[pranav bhandarkar]

I am wondering where to define the prototypes for functions in
.c Shall the prototypes be defined in -protos.h or in
.h or in .c. As far as I understand the prototypes
should be defined in -protos.h, right? But if I do so several
errors/warnings arise because of undeclared prototypes.

Another question is where target macros should be defined. As far as I
can see .c has something like such a structure:

---snip---
#define 
#define 
#define 
#define 

struct gcc_target targetm = TARGET_INITIALIZER;

.h is used to define macros that give such information as the
register classes, whether little endian or not, sizes of integral
types etc.
The file .c, like you rightly said defines the targetm
structure that holds pointers to target related functions and data.
Such functions are defined in the .c file. Such target hooks are
#defined in the .c file.
HTH,
Pranav

Re: Cheatsheet for building gcc

[Paolo Bonzini]

Is there a way how to do it without reconfiguring gcc?


No.  Do you think it would be best to have --enable-stage1-languages=all 
in non-release branches?  The time taken to compile the stage1 
(nonoptimized) non-C front-ends is small, and the advantage seems 
significant.



Q6) How to clean up everything except for the stage1 compiler and
   its runtime (libgcc, libmudflap, libgomp)?

make restrap (which will also start a bootstrap)


Would it be possible to add a possibility to just clean up the things,
without restarting the bootstrap (i.e., to move everything to the
state I would have after "make stage1-bubble" if I started from the scratch)?


Actually, I was wrong as "make restrap" will also delete the runtime. 
The closest things to what you want are:
- "make distclean-stage2"; however it will leave there all the target 
libraries if they have already been compiled, not only the runtime.

- "make distclean-stage2 clean-target"; which will remove also the runtime.

Paolo

Re: Miscompilation of remainder expressions

[Paolo Bonzini]

Compared to the slow idivl, abs could be negligible, right. However, abs
does introduce new data dependence which might add a noticeable cost.

   Is there an abs instruction in the i386 instruction set?


No, the closest thing (input in eax, output in edx) is

cltq
addl %edx, %eax
xorl %eax, %edx

But the register allocations constraints are pretty heavy considering 
that idivl already puts strain on the RA.


Paolo

Re: Cheatsheet for building gcc

[Zdenek Dvorak]

Hello,

> >Is there a way how to do it without reconfiguring gcc?
> 
> No.  Do you think it would be best to have --enable-stage1-languages=all 
> in non-release branches?  The time taken to compile the stage1 
> (nonoptimized) non-C front-ends is small, and the advantage seems 
> significant.

if you configure with  --enable-stage1-languages=all,

1) will all the libraries be built three times during bootstrap, or just
   once?
2) is it still possible to just build the stage1 compiler without the
   libraries?

> >>>Q6) How to clean up everything except for the stage1 compiler and
> >>>   its runtime (libgcc, libmudflap, libgomp)?
> >>make restrap (which will also start a bootstrap)
> >
> >Would it be possible to add a possibility to just clean up the things,
> >without restarting the bootstrap (i.e., to move everything to the
> >state I would have after "make stage1-bubble" if I started from the 
> >scratch)?
> 
> Actually, I was wrong as "make restrap" will also delete the runtime. 
> The closest things to what you want are:
> - "make distclean-stage2"; however it will leave there all the target 
> libraries if they have already been compiled, not only the runtime.
> - "make distclean-stage2 clean-target"; which will remove also the runtime.

thanks, the "make distclean-stage2 clean-target" actually is exactly
what I need (although I specified something different :-)

Zdenek

Re: Creating a variable declaration of custom type.

[Ferad Zyulkyarov]

Hi,


Best way to figure this out is to write a simple 5 line testcase that
defines a structure type and also defines a pointer to that type, and
then step through gcc to see what it does.  Try putting breakpoints in
finish_struct and build_pointer_type.


I tried with the advised test case but again I could not find how to
reference to the already declared type "MyType".

As it sould be logically, there should be a way to get a reference to
the declared type i.e.
tree type_decl = lookup_name("MyType");
tree type_ptr = build_pointer_type(type_decl->type_node);
tree var_decl = build(VAR_DECL, get_identifier("t"), type_ptr);

I tried similar codes like the above, but I don't know how to retrieve
the "type" from the type declaration. Any help, ideas are highly
appreciated.

Ferad Zyulkyarov

Re: Miscompilation of remainder expressions

[Lucas (a.k.a T-Bird or bsdfan3)]

Paolo Bonzini wrote:




Compared to the slow idivl, abs could be negligible, right. However, abs
does introduce new data dependence which might add a noticeable cost.

   Is there an abs instruction in the i386 instruction set?



No, the closest thing (input in eax, output in edx) is

cltq
addl %edx, %eax
xorl %eax, %edx

But the register allocations constraints are pretty heavy considering 
that idivl already puts strain on the RA.


Paolo




Paolo, what does the cltq instruction do?  I cannot find it in my x86 
reference manuals...

Re: Cheatsheet for building gcc

[Richard Kenner]

> > Q2) How to bootstrap the compiler, but not build any time consuming
> > libraries (libjava, libstdc++)?
> 
> A2) "make stage{2,3,feedback}-bubble"

Can you say what the differences between these three are?  Which is the
equivalent of the old "cd gcc; make bootstrap"?

> > Q4) How to compile all the libraries (libjava, ...) using the stage1
> > compiler?
> 
> A4) Configure with --enable-stage1-languages=all

... and then do what, "make bootstrap"?

Re: Cheatsheet for building gcc

[Paolo Bonzini]

if you configure with  --enable-stage1-languages=all,

1) will all the libraries be built three times during bootstrap, or just
   once?


Just once.  Things that are built three times are only those that have 
"bootstrap=true" in the Makefile.def file.


Paolo

Re: Miscompilation of remainder expressions

[Paolo Bonzini]

cltq
addl %edx, %eax
xorl %eax, %edx

But the register allocations constraints are pretty heavy considering 
that idivl already puts strain on the RA.


Paolo, what does the cltq instruction do?  I cannot find it in my x86 
reference manuals...


Uhm, I meant cltd and it is the same as "cdq" in the intel syntax.

cltq is an x86-64 instruction and it is the same as "cdqe" in the intel 
syntax.


Paolo

Re: Cheatsheet for building gcc

[Paolo Bonzini]

Richard Kenner wrote:

Q2) How to bootstrap the compiler, but not build any time consuming
libraries (libjava, libstdc++)?

A2) "make stage{2,3,feedback}-bubble"


Can you say what the differences between these three are?  Which is the
equivalent of the old "cd gcc; make bootstrap"?


They will stop respectively at stage2 (equivalent of old "cd gcc; make 
bootstrap2"), stage3 (old "cd gcc; make bootstrap"), stagefeedback 
(equivalent of old "cd gcc; make profiledbootstrap).



Q4) How to compile all the libraries (libjava, ...) using the stage1
compiler?

A4) Configure with --enable-stage1-languages=all


... and then do what, "make bootstrap"?


"make stage1-bubble all-target".

I think I have now enough info to make The Page That Should Have Been 
Created A Year Ago.


Paolo

Re: Cheatsheet for building gcc

[Paolo Bonzini]

with the changes to the build system in the last few months, I am having
problems to do some things I am used to do during development.  I found
more or less satisfactory procedures for most them, however, I would
like to know the "official" way how to achieve those effects (and to put
the created "cheatsheet" to wiki, so that people do not have to reinvent
the wheel).


Now at http://gcc.gnu.org/wiki/Top-Level_Bootstrap.

Paolo

Re: relevant files for target backends

[Markus Franke]

Thank you for your response. I understood everything you said but I am
still confused about the file -protos.h. Which prototypes have
to be defined there?

Thanks in advance,
Markus Franke

pranav bhandarkar wrote:
>> I am wondering where to define the prototypes for functions in
>> .c Shall the prototypes be defined in -protos.h or in
>> .h or in .c. As far as I understand the prototypes
>> should be defined in -protos.h, right? But if I do so several
>> errors/warnings arise because of undeclared prototypes.
>>
>> Another question is where target macros should be defined. As far as I
>> can see .c has something like such a structure:
>>
>> ---snip---
>> #define 
>> #define 
>> #define 
>> #define 
>>
>> struct gcc_target targetm = TARGET_INITIALIZER;
> 
> .h is used to define macros that give such information as the
> register classes, whether little endian or not, sizes of integral
> types etc.
> The file .c, like you rightly said defines the targetm
> structure that holds pointers to target related functions and data.
> Such functions are defined in the .c file. Such target hooks are
> #defined in the .c file.
> HTH,
> Pranav
> 

-- 
Nichts ist so praktisch wie eine gute Theorie!

Re: Miscompilation of remainder expressions

[Andrew Haley]

Michael Veksler writes:
 > Roberto Bagnara wrote:
 > >
 > > Reading the thread "Autoconf manual's coverage of signed integer
 > > overflow & portability" I was horrified to discover about GCC's
 > > miscompilation of the remainder expression that causes INT_MIN % -1
 > > to cause a SIGFPE on CPUs of the i386 family.  Are there plans to
 > > fix this bug (which, to me, looks quite serious)?
 > > All the best,
 > >
 > This problem is quite rare in practice (otherwise there would be
 > much more complaining). As such it may be too expensive,
 > performance-wise, to fix in GCC. It seems as one of those
 > classical things that can be worked-around in the kernel.

I guess, or it can be fixed-up in user space.  We already do this for
the Java language.

Andrew.

Re: Miscompilation of remainder expressions

[Gabriel Dos Reis]

Andrew Haley <[EMAIL PROTECTED]> writes:

| Michael Veksler writes:
|  > Roberto Bagnara wrote:
|  > >
|  > > Reading the thread "Autoconf manual's coverage of signed integer
|  > > overflow & portability" I was horrified to discover about GCC's
|  > > miscompilation of the remainder expression that causes INT_MIN % -1
|  > > to cause a SIGFPE on CPUs of the i386 family.  Are there plans to
|  > > fix this bug (which, to me, looks quite serious)?
|  > > All the best,
|  > >
|  > This problem is quite rare in practice (otherwise there would be
|  > much more complaining). As such it may be too expensive,
|  > performance-wise, to fix in GCC. It seems as one of those
|  > classical things that can be worked-around in the kernel.
| 
| I guess, or it can be fixed-up in user space.  We already do this for
| the Java language.

Andrew pointed me to his implementation.  
I, however, have a question: why do we need to mess with signals at all?
I mean, could not we generate the following for "%":

rem a b :=
  if abs(b) == 1 
 return 0
  return  a b

is there any other corner case that will trigger the trap?


-- Gaby

Re: Miscompilation of remainder expressions

[Andrew Haley]

Gabriel Dos Reis writes:
 > Andrew Haley <[EMAIL PROTECTED]> writes:
 > 
 > | Michael Veksler writes:
 > |  > Roberto Bagnara wrote:
 > |  > >
 > |  > > Reading the thread "Autoconf manual's coverage of signed integer
 > |  > > overflow & portability" I was horrified to discover about GCC's
 > |  > > miscompilation of the remainder expression that causes INT_MIN % -1
 > |  > > to cause a SIGFPE on CPUs of the i386 family.  Are there plans to
 > |  > > fix this bug (which, to me, looks quite serious)?
 > |  > > All the best,
 > |  > >
 > |  > This problem is quite rare in practice (otherwise there would be
 > |  > much more complaining). As such it may be too expensive,
 > |  > performance-wise, to fix in GCC. It seems as one of those
 > |  > classical things that can be worked-around in the kernel.
 > | 
 > | I guess, or it can be fixed-up in user space.  We already do this for
 > | the Java language.
 > 
 > Andrew pointed me to his implementation.  
 > I, however, have a question: why do we need to mess with signals at all?
 > I mean, could not we generate the following for "%":
 > 
 > rem a b :=
 >   if abs(b) == 1 
 >  return 0
 >   return  a b
 > 
 > is there any other corner case that will trigger the trap?

I have tried it, and it is pretty expensive.  It messes up the
pipelines and it hides the % from the optimizer.  IMO we should not do
this by default, since it's such a nitpicky corner case.

Andrew.

Re: Miscompilation of remainder expressions

[Gabriel Dos Reis]

Andrew Haley <[EMAIL PROTECTED]> writes:

| Gabriel Dos Reis writes:
|  > Andrew Haley <[EMAIL PROTECTED]> writes:
|  > 
|  > | Michael Veksler writes:
|  > |  > Roberto Bagnara wrote:
|  > |  > >
|  > |  > > Reading the thread "Autoconf manual's coverage of signed integer
|  > |  > > overflow & portability" I was horrified to discover about GCC's
|  > |  > > miscompilation of the remainder expression that causes INT_MIN % -1
|  > |  > > to cause a SIGFPE on CPUs of the i386 family.  Are there plans to
|  > |  > > fix this bug (which, to me, looks quite serious)?
|  > |  > > All the best,
|  > |  > >
|  > |  > This problem is quite rare in practice (otherwise there would be
|  > |  > much more complaining). As such it may be too expensive,
|  > |  > performance-wise, to fix in GCC. It seems as one of those
|  > |  > classical things that can be worked-around in the kernel.
|  > | 
|  > | I guess, or it can be fixed-up in user space.  We already do this for
|  > | the Java language.
|  > 
|  > Andrew pointed me to his implementation.  
|  > I, however, have a question: why do we need to mess with signals at all?
|  > I mean, could not we generate the following for "%":
|  > 
|  > rem a b :=
|  >   if abs(b) == 1 
|  >  return 0
|  >   return  a b
|  > 
|  > is there any other corner case that will trigger the trap?
| 
| I have tried it, and it is pretty expensive.  It messes up the
| pipelines and it hides the % from the optimizer. 

Aha, thanks.

| IMO we should not do this by default, since it's such a nitpicky
| corner case. 

At this point, without having tried (C/C++) implementations and their
effects on most software, I have no definitive opinion -- except that
we do something about it.

-- Gaby

Re: relevant files for target backends

[pranav bhandarkar]

On 1/16/07, Markus Franke <[EMAIL PROTECTED]> wrote:

Thank you for your response. I understood everything you said but I am
still confused about the file -protos.h. Which prototypes have
to be defined there?

Thanks in advance,
Markus Franke


IMO and from what I have gathered from the documentation, the
prototypes of all the functions in the source file i.e. the
.c file should go into -protos.h
HTH,
Pranav

Re: relevant files for target backends

[Kaveh R. GHAZI]

On Tue, 16 Jan 2007, Markus Franke wrote:

> Thank you for your response. I understood everything you said but I am
> still confused about the file -protos.h. Which prototypes have
> to be defined there?

Any external function you manully define in config/machine/machine.c
probably should have a prototype in config/machine/machine-protos.h.  If
you create external functions in other .c files in config/machine/, then
possibly those need to be in a protos.h file too.

If during compilation of GCC you get missing prototype warnings, then that
.c file needs to include "tm_p.h".

Predicate functions are automatically prototyped in "tm-preds.h".  I
believe that file gets pulled in by "tm_p.h" also.

--Kaveh
--
Kaveh R. Ghazi  [EMAIL PROTECTED]

GCC trunk failed to compile cpu2k6/dealII at x86_64

[Grigory Zagorodnev]

Hi!
GCC 4.3 revision 120799 fails to compile SPEC cpu2006/447.dealII 
benchmark at x86_64-redhat-linux on -O2 optimization level. Last 
revision know to be good is 120775.


data_out_base.cc: In static member function 'static void 
DataOutBase::write_vtk(const std::vectordim>, std::allocator > >&, const 
std::vector,
std::allocator >, std::allocatorstd::char_traits, std::allocator > > >&, const DataO

utBase::VtkFlags&, std::ostream&) [with int dim = 3, int spacedim = 4]':
data_out_base.cc:2949: internal compiler error: tree check: expected 
tree that contains 'decl minimal' structure, have 'reduc_m

ax_expr'  in add_call_clobber_ops, at tree-ssa-operands.c:1780
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
specmake: *** [data_out_base.o] Error 1

- Grigory

Re: GCC trunk failed to compile cpu2k6/dealII at x86_64

[Grigory Zagorodnev]

Grigory Zagorodnev wrote:
GCC 4.3 revision 120799 fails to compile SPEC cpu2006/447.dealII 
benchmark at x86_64-redhat-linux on -O2 optimization level. Last 
revision know to be good is 120775.



It appears that revision 120767 causes the failure
http://gcc.gnu.org/viewcvs?view=rev&revision=120767

Which is "Remove unused variables from REFERENCED_VARS list" patch
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01048.html

- Grigory

Re: Miscompilation of remainder expressions

[Roberto Bagnara]

Andrew Haley wrote:

Roberto Bagnara writes:
 > 
 > Reading the thread "Autoconf manual's coverage of signed integer

 > overflow & portability" I was horrified to discover about GCC's
 > miscompilation of the remainder expression that causes INT_MIN % -1
 > to cause a SIGFPE on CPUs of the i386 family.  Are there plans to
 > fix this bug (which, to me, looks quite serious)?

No, there aren't.  It would make more sense for you to wrap % in some
code that checks for this, rather than for us to slow down every division
for this one special case.


With all due respect, I must say I am shocked.  I always thought
(and taught) that we, Free Software people, value standard conformance
and getting things right.  Now we have a bug that can shut down
airplanes and dealing with it is (in extreme synthesis) assimilated
to nitpicking.  I have not found a mention of this bug in the "Known Bugs"
section of http://gcc.gnu.org: perhaps I missed it, but I think
it definitely should be brought to the attention of the users since,
IMHO, no one really expects a remainder expression to cause a SIGFPE.
I have also looked at the bug database, and I did not find any report
concerning this bug, so I created one:

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30484

A final remark: I think that today the problem is safety, not speed.
I don't think doing the right thing for remainder expression will
have such a high cost with the help of the optimizer and, maybe,
assistance from the kernel.  But even if the cost turns out to be high,
the actual state of things is unacceptable: mentioning the bug prominently
in the documentation, trying to change the standard, ..., whatever;
but not leaving things as they are.
All the best,

   Roberto

--
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:[EMAIL PROTECTED]

Re: Creating a variable declaration of custom type.

[Ferad Zyulkyarov]

I succeeded to do it as follows:

tree type_decl = lookup_name(get_identifier("MyType"));
tree type_ptr = build_pointer_type(TREE_TYPE(type_decl));
tree var_decl = build(VAR_DECL, get_identifier("t"), type_ptr);
pushdecl(var_decl);

It may not be a perfect solution but for now it works.

On 1/16/07, Ferad Zyulkyarov <[EMAIL PROTECTED]> wrote:

Hi,

> Best way to figure this out is to write a simple 5 line testcase that
> defines a structure type and also defines a pointer to that type, and
> then step through gcc to see what it does.  Try putting breakpoints in
> finish_struct and build_pointer_type.

I tried with the advised test case but again I could not find how to
reference to the already declared type "MyType".

As it sould be logically, there should be a way to get a reference to
the declared type i.e.
tree type_decl = lookup_name("MyType");
tree type_ptr = build_pointer_type(type_decl->type_node);
tree var_decl = build(VAR_DECL, get_identifier("t"), type_ptr);

I tried similar codes like the above, but I don't know how to retrieve
the "type" from the type declaration. Any help, ideas are highly
appreciated.

Ferad Zyulkyarov




--
Ferad Zyulkyarov
Barcelona Supercomputing Center

Re: Miscompilation of remainder expressions

[Andrew Haley]

Roberto Bagnara writes:
 > Andrew Haley wrote:
 > > Roberto Bagnara writes:
 > >  > 
 > >  > Reading the thread "Autoconf manual's coverage of signed integer
 > >  > overflow & portability" I was horrified to discover about GCC's
 > >  > miscompilation of the remainder expression that causes INT_MIN % -1
 > >  > to cause a SIGFPE on CPUs of the i386 family.  Are there plans to
 > >  > fix this bug (which, to me, looks quite serious)?
 > > 
 > > No, there aren't.  It would make more sense for you to wrap % in some
 > > code that checks for this, rather than for us to slow down every division
 > > for this one special case.
 > 
 > With all due respect, I must say I am shocked.  I always thought
 > (and taught) that we, Free Software people, value standard conformance
 > and getting things right.

This is a disgreement about interpretation of the langauge in the
standard, which is:

"The result of the / operator is the quotient from the division of the
first operand by the second; the result of the % operator is the
remainder. In both operations, if the value of the second operand is
zero, the behavior is undefined. When integers are divided, the result
of the / operator is the algebraic quotient with any fractional part
discarded.87) If the quotient a/b is representable, the expression
(a/b)*b + a%b shall equal a."

If the quotient a/b is *not* representable, is the behaviour of %
well-defined or not?  It doesn't say.

Andrew.

Re: 27% regression of gcc 4.3 performance on cpu2k6/calculix

[Grigory Zagorodnev]

Toon Moene wrote:
Calculix is a combined C/Fortran program.  Did you try to compile the 
Fortran parts with --param max-aliased-vops=default 50> ?
Right, calculix is a combined program. Gprof says the regression is in 
e_c3d routine which is 1k lines of Fortran code.


Various max-aliased-vops give no difference for calculix:

default (assume --param max-aliased-vops=50)
1780 sec.

--param max-aliased-vops=80
1789 sec.

--param max-aliased-vops=20
1780 sec.

Setting of max-aliased-vops to value greater than 80 gives an ICE:
allocation.f: In function 'allocation':
allocation.f:19: internal compiler error: in ssa_operand_alloc, at 
tree-ssa-oper

ands.c:365

- Grigory

Re: Miscompilation of remainder expressions

[Duncan Sands]

On Tuesday 16 January 2007 16:50, Andrew Haley wrote:
> Roberto Bagnara writes:
>  > Andrew Haley wrote:
>  > > Roberto Bagnara writes:
>  > >  > 
>  > >  > Reading the thread "Autoconf manual's coverage of signed integer
>  > >  > overflow & portability" I was horrified to discover about GCC's
>  > >  > miscompilation of the remainder expression that causes INT_MIN % -1
>  > >  > to cause a SIGFPE on CPUs of the i386 family.  Are there plans to
>  > >  > fix this bug (which, to me, looks quite serious)?
>  > > 
>  > > No, there aren't.  It would make more sense for you to wrap % in some
>  > > code that checks for this, rather than for us to slow down every division
>  > > for this one special case.
>  > 
>  > With all due respect, I must say I am shocked.  I always thought
>  > (and taught) that we, Free Software people, value standard conformance
>  > and getting things right.
> 
> This is a disgreement about interpretation of the langauge in the
> standard, which is:
> 
> "The result of the / operator is the quotient from the division of the
> first operand by the second; the result of the % operator is the
> remainder. In both operations, if the value of the second operand is
> zero, the behavior is undefined. When integers are divided, the result
> of the / operator is the algebraic quotient with any fractional part
> discarded.87) If the quotient a/b is representable, the expression
> (a/b)*b + a%b shall equal a."
> 
> If the quotient a/b is *not* representable, is the behaviour of %
> well-defined or not?  It doesn't say.

In ada/exp_ch4.adb you will find:

 --  Deal with annoying case of largest negative number remainder
 --  minus one. Gigi does not handle this case correctly, because
 --  it generates a divide instruction which may trap in this case.

 --  In fact the check is quite easy, if the right operand is -1,
 --  then the mod value is always 0, and we can just ignore the
 --  left operand completely in this case.

Ada semantics require INT_MIN rem -1 to be zero.

Best wishes,

Duncan.

Re: Miscompilation of remainder expressions

[Roberto Bagnara]

Andrew Haley wrote:

Roberto Bagnara writes:
 > Andrew Haley wrote:
 > > Roberto Bagnara writes:
 > >  > 
 > >  > Reading the thread "Autoconf manual's coverage of signed integer

 > >  > overflow & portability" I was horrified to discover about GCC's
 > >  > miscompilation of the remainder expression that causes INT_MIN % -1
 > >  > to cause a SIGFPE on CPUs of the i386 family.  Are there plans to
 > >  > fix this bug (which, to me, looks quite serious)?
 > > 
 > > No, there aren't.  It would make more sense for you to wrap % in some

 > > code that checks for this, rather than for us to slow down every division
 > > for this one special case.
 > 
 > With all due respect, I must say I am shocked.  I always thought

 > (and taught) that we, Free Software people, value standard conformance
 > and getting things right.

This is a disgreement about interpretation of the langauge in the
standard, which is:

"The result of the / operator is the quotient from the division of the
first operand by the second; the result of the % operator is the
remainder. In both operations, if the value of the second operand is
zero, the behavior is undefined. When integers are divided, the result
of the / operator is the algebraic quotient with any fractional part
discarded.87) If the quotient a/b is representable, the expression
(a/b)*b + a%b shall equal a."

If the quotient a/b is *not* representable, is the behaviour of %
well-defined or not?  It doesn't say.


To the point that, when a/b is not representable, raising SIGFPE
for a%b is standard conformant behavior?

Note however that I am not saying that the standard is not defective.
Who knows how to write and submit C/C++ standard defect reports?
Let us do that, assuming that such a report has not been submitted
already.

--
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:[EMAIL PROTECTED]

Re: Miscompilation of remainder expressions

[Andrew Haley]

Roberto Bagnara writes:
 > Andrew Haley wrote:
 > > 
 > > If the quotient a/b is *not* representable, is the behaviour of %
 > > well-defined or not?  It doesn't say.
 > 
 > To the point that, when a/b is not representable, raising SIGFPE
 > for a%b is standard conformant behavior?

 > Note however that I am not saying that the standard is not defective.
 > Who knows how to write and submit C/C++ standard defect reports?
 > Let us do that, assuming that such a report has not been submitted
 > already.

It's already been done.

Andrew.

Re: Miscompilation of remainder expressions

[Manuel López-Ibáñez]

On 16/01/07, Duncan Sands <[EMAIL PROTECTED]> wrote:

On Tuesday 16 January 2007 16:50, Andrew Haley wrote:
> Roberto Bagnara writes:
>  > Andrew Haley wrote:
>  > > Roberto Bagnara writes:
>  > >  >
>  > >  > Reading the thread "Autoconf manual's coverage of signed integer
>  > >  > overflow & portability" I was horrified to discover about GCC's
>  > >  > miscompilation of the remainder expression that causes INT_MIN % -1
>  > >  > to cause a SIGFPE on CPUs of the i386 family.  Are there plans to
>  > >  > fix this bug (which, to me, looks quite serious)?
>  > >
>  > > No, there aren't.  It would make more sense for you to wrap % in some
>  > > code that checks for this, rather than for us to slow down every division
>  > > for this one special case.
>  >
>  > With all due respect, I must say I am shocked.  I always thought
>  > (and taught) that we, Free Software people, value standard conformance
>  > and getting things right.
>
> This is a disgreement about interpretation of the langauge in the
> standard, which is:
>
> "The result of the / operator is the quotient from the division of the
> first operand by the second; the result of the % operator is the
> remainder. In both operations, if the value of the second operand is
> zero, the behavior is undefined. When integers are divided, the result
> of the / operator is the algebraic quotient with any fractional part
> discarded.87) If the quotient a/b is representable, the expression
> (a/b)*b + a%b shall equal a."
>
> If the quotient a/b is *not* representable, is the behaviour of %
> well-defined or not?  It doesn't say.

In ada/exp_ch4.adb you will find:

 --  Deal with annoying case of largest negative number remainder
 --  minus one. Gigi does not handle this case correctly, because
 --  it generates a divide instruction which may trap in this case.

 --  In fact the check is quite easy, if the right operand is -1,
 --  then the mod value is always 0, and we can just ignore the
 --  left operand completely in this case.

Ada semantics require INT_MIN rem -1 to be zero.


FWIW,

[EMAIL PROTECTED]:~$ gcc --version
gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5)

[EMAIL PROTECTED]:~$ cat test.c
#include 
#include 

int main(void) {
   int z = INT_MIN % -1;
   printf("%d %% %d -> %d\n", INT_MIN, -1, z);
   return 0;
}

[EMAIL PROTECTED]:~$ gcc -Wall -Wextra test.c -o test
[EMAIL PROTECTED]:~$ ./test
-2147483648 % -1 -> 0

[EMAIL PROTECTED]:~$ cat test.c
#include 
#include 

int modulo(int dividend, int divisor)
{
   return dividend % divisor;
}
int main(void) {
   int z = modulo(INT_MIN, -1);
   printf("%d %% %d -> %d\n", INT_MIN, -1, z);
   return 0;
}
[EMAIL PROTECTED]:~$ gcc  -Wall -Wextra test.c -o test
[EMAIL PROTECTED]:~$ ./test
Floating point exception
[EMAIL PROTECTED]:~$ gcc -O2 -Wall -Wextra test.c -o test
[EMAIL PROTECTED]:~$ ./test
Floating point exception
[EMAIL PROTECTED]:~$ gcc -O3 -Wall -Wextra test.c -o test
[EMAIL PROTECTED]:~$ ./test
-2147483648 % -1 -> 0

I don't know whether results are different in mainline.

Cheers,

Manuel.

Re: Miscompilation of remainder expressions

[Robert Dewar]

It's interesting that the same issue arose with GNAT, but
we had no option to ignore the special case, since one of
the official Ada validation test programs tested this case,
and indeed as you see below there is a special test:


function q (a, b : integer) return integer is
begin
   return a rem b;
end;


generates

Source recreated from tree for q (body)
---


function q (a : integer; b : integer) return integer is
begin
   [constraint_error when
 b = 0
 "divide by zero"]
   return integer((if b = -1 then 0 else a rem b));
end q;

And indeed this is a nasty hit in efficiency, though in
practice the wide spread use of integer types with
restricted ranges means that most of the time you
know for example that the divisor cannot be negative.

Re: Miscompilation of remainder expressions

[Robert Dewar]

Roberto Bagnara wrote:

Reading the thread "Autoconf manual's coverage of signed integer
overflow & portability" I was horrified to discover about GCC's
miscompilation of the remainder expression that causes INT_MIN % -1
to cause a SIGFPE on CPUs of the i386 family.  Are there plans to
fix this bug (which, to me, looks quite serious)?
All the best,

Roberto

P.S. I checked whether this bug affects my code and it does.
  Before yesterday I was completely unsuspecting of such
  a fundamental flaw... I wonder how many know about it.


It's truly amazing for real code to be computing remainders
in this domain ... seems a bad idea to me, since very few
people are comfortably aware of what remainder means for
such cases.

Re: Miscompilation of remainder expressions

[Robert Dewar]

Roberto Bagnara wrote:

Reading the thread "Autoconf manual's coverage of signed integer
overflow & portability" I was horrified to discover about GCC's
miscompilation of the remainder expression that causes INT_MIN % -1
to cause a SIGFPE on CPUs of the i386 family.  Are there plans to
fix this bug (which, to me, looks quite serious)?


Seems ultra-non-serious to me, hard to believe this case appears
in real code, despite surprising claim by Roberto.

Re: Miscompilation of remainder expressions

[David Daney]

Robert Dewar wrote:

Roberto Bagnara wrote:


Reading the thread "Autoconf manual's coverage of signed integer
overflow & portability" I was horrified to discover about GCC's
miscompilation of the remainder expression that causes INT_MIN % -1
to cause a SIGFPE on CPUs of the i386 family.  Are there plans to
fix this bug (which, to me, looks quite serious)?



Seems ultra-non-serious to me, hard to believe this case appears
in real code, despite surprising claim by Roberto.



It seems to me that you would know that it is happening.  If it hits 
you, you don't get hard to find wierd program results.  Your program is 
killed by SIGFPE.


David Daney

Re: Miscompilation of remainder expressions

[Robert Dewar]

Roberto Bagnara wrote:

Andrew Haley wrote:

Roberto Bagnara writes:
 > 
 > Reading the thread "Autoconf manual's coverage of signed integer

 > overflow & portability" I was horrified to discover about GCC's
 > miscompilation of the remainder expression that causes INT_MIN % -1
 > to cause a SIGFPE on CPUs of the i386 family.  Are there plans to
 > fix this bug (which, to me, looks quite serious)?

No, there aren't.  It would make more sense for you to wrap % in some
code that checks for this, rather than for us to slow down every division
for this one special case.


With all due respect, I must say I am shocked.  I always thought
(and taught) that we, Free Software people, value standard conformance
and getting things right.  Now we have a bug that can shut down
airplanes 


Please do not indulge in excessive rhetoric, planes do not get
shut down by compiler bugs. If you really think that the integrity
of avionics software depends on bug free compilers you have no
idea what you are talking about (I would guess you are for
example unfamiliar with DO-178B certification).

Yes, it's a bug, is it a serious bug, no? Will real software
be affected? no. Indeed I find any program that actually
does this remainder operation in practice to be highly
suspect.


A final remark: I think that today the problem is safety, not speed.
I don't think doing the right thing for remainder expression will
have such a high cost with the help of the optimizer and, maybe,
assistance from the kernel.  But even if the cost turns out to be high,
the actual state of things is unacceptable: mentioning the bug prominently
in the documentation, trying to change the standard, ..., whatever;
but not leaving things as they are.


Yes, it should probably be fixed, but making a major fuss about
it seems peculiar at best. I think it is perfectly reasonable
for you to propose a patch to fix this if you are specially
concerned, but don't expect the community to rush to fix this
particular bug at high priority in response to this complaint.

There are lots of known bugs far more important than this one.

Re: Miscompilation of remainder expressions

[Robert Dewar]

Roberto Bagnara wrote:


To the point that, when a/b is not representable, raising SIGFPE
for a%b is standard conformant behavior?


possibly so ..


Note however that I am not saying that the standard is not defective.
Who knows how to write and submit C/C++ standard defect reports?
Let us do that, assuming that such a report has not been submitted
already.


not clear that this is a defect, I would find it quite reasonable
for the C standard to recognize this anticipatable case, and decide
that a%b is undefined if a/b is undefined.

Re: Miscompilation of remainder expressions

[Joe Buck]

On Tue, Jan 16, 2007 at 08:22:10AM -0600, Gabriel Dos Reis wrote:
> I mean, could not we generate the following for "%":
> 
> rem a b :=
>   if abs(b) == 1 
>  return 0
>   return  a b

On x86 processors that have conditional moves, why not do the equivalent
of

neg_b = -b;
cmov(last result is negative,neg_b,b)
__machine_rem(a,b)

Then there's no disruption of the pipeline.

Re: Miscompilation of remainder expressions

[Roberto Bagnara]

Robert Dewar wrote:

Roberto Bagnara wrote:

Reading the thread "Autoconf manual's coverage of signed integer
overflow & portability" I was horrified to discover about GCC's
miscompilation of the remainder expression that causes INT_MIN % -1
to cause a SIGFPE on CPUs of the i386 family.  Are there plans to
fix this bug (which, to me, looks quite serious)?
All the best,

Roberto

P.S. I checked whether this bug affects my code and it does.
  Before yesterday I was completely unsuspecting of such
  a fundamental flaw... I wonder how many know about it.


It's truly amazing for real code to be computing remainders
in this domain ... seems a bad idea to me, since very few
people are comfortably aware of what remainder means for
such cases.


Everyone knows that dividing a number by -1 or 1 gives
a 0 remainder.  To the contrary, no one expects a%b to
raise SIFPE when b != 0.

--
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:[EMAIL PROTECTED]

Re: Miscompilation of remainder expressions

[Gabriel Dos Reis]

Andrew Haley <[EMAIL PROTECTED]> writes:

| Roberto Bagnara writes:
|  > Andrew Haley wrote:
|  > > Roberto Bagnara writes:
|  > >  > 
|  > >  > Reading the thread "Autoconf manual's coverage of signed integer
|  > >  > overflow & portability" I was horrified to discover about GCC's
|  > >  > miscompilation of the remainder expression that causes INT_MIN % -1
|  > >  > to cause a SIGFPE on CPUs of the i386 family.  Are there plans to
|  > >  > fix this bug (which, to me, looks quite serious)?
|  > > 
|  > > No, there aren't.  It would make more sense for you to wrap % in some
|  > > code that checks for this, rather than for us to slow down every division
|  > > for this one special case.
|  > 
|  > With all due respect, I must say I am shocked.  I always thought
|  > (and taught) that we, Free Software people, value standard conformance
|  > and getting things right.
| 
| This is a disgreement about interpretation of the langauge in the
| standard, which is:
| 
| "The result of the / operator is the quotient from the division of the
| first operand by the second; the result of the % operator is the
| remainder. In both operations, if the value of the second operand is
| zero, the behavior is undefined. When integers are divided, the result
| of the / operator is the algebraic quotient with any fractional part
| discarded.87) If the quotient a/b is representable, the expression
| (a/b)*b + a%b shall equal a."
| 
| If the quotient a/b is *not* representable, is the behaviour of %
| well-defined or not?  It doesn't say.

Andrew and me exchanged (private) viewpoints of this yesterday.  I would
like to add something I forgot to say.

By definition, the absolute value of "a % b" is always less than the
absolute value of b.  Consequently, "a % b" is always defined.

-- Gaby

Re: Miscompilation of remainder expressions

[Gabriel Dos Reis]

Duncan Sands <[EMAIL PROTECTED]> writes:

[...]

| Ada semantics require INT_MIN rem -1 to be zero.

I cannot see any other value as a result.

-- Gaby

Re: Miscompilation of remainder expressions

[David Daney]

Roberto Bagnara wrote:

Robert Dewar wrote:


Roberto Bagnara wrote:


Reading the thread "Autoconf manual's coverage of signed integer
overflow & portability" I was horrified to discover about GCC's
miscompilation of the remainder expression that causes INT_MIN % -1
to cause a SIGFPE on CPUs of the i386 family.  Are there plans to
fix this bug (which, to me, looks quite serious)?
All the best,

Roberto

P.S. I checked whether this bug affects my code and it does.
  Before yesterday I was completely unsuspecting of such
  a fundamental flaw... I wonder how many know about it.



It's truly amazing for real code to be computing remainders
in this domain ... seems a bad idea to me, since very few
people are comfortably aware of what remainder means for
such cases.



Everyone knows that dividing a number by -1 or 1 gives
a 0 remainder.  To the contrary, no one expects a%b to
raise SIFPE when b != 0.



On the contrary, since the beginning of time SIGFPE has been generated 
on GCC/x86/linux under these conditions.  This is wildly known.


Just because you just found out about it does not mean that 'no one' 
expects it.


David Daney

Re: Miscompilation of remainder expressions

[Roberto Bagnara]

Robert Dewar wrote:

Roberto Bagnara wrote:

Reading the thread "Autoconf manual's coverage of signed integer
overflow & portability" I was horrified to discover about GCC's
miscompilation of the remainder expression that causes INT_MIN % -1
to cause a SIGFPE on CPUs of the i386 family.  Are there plans to
fix this bug (which, to me, looks quite serious)?


Seems ultra-non-serious to me, hard to believe this case appears
in real code, despite surprising claim by Roberto.


How do you test if a number is a multiple of another one?
What about rounding toward zero to a multiple of k?
I guess

x - x%k

looks like unreal code to you.

--
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:[EMAIL PROTECTED]

Re: Miscompilation of remainder expressions

[Robert Dewar]

Gabriel Paubert wrote:
\

No, because the instruction has actually two result values:

- the remainder, which you could safely set to zero (not 1!)

- the quotient, which is affected by the overflow and there may be
  compiler and languages that rely on the exception being generated.


But the division is undefined, programs have no right to
rely on an exception being generated.

Re: Miscompilation of remainder expressions

[Robert Dewar]

David Daney wrote:

Roberto Bagnara wrote:


Everyone knows that dividing a number by -1 or 1 gives
a 0 remainder.  To the contrary, no one expects a%b to
raise SIFPE when b != 0.



On the contrary, since the beginning of time SIGFPE has been generated 
on GCC/x86/linux under these conditions.  This is wildly known.


Just because you just found out about it does not mean that 'no one' 
expects it.


Indeed, I would never write this expression expecting the result to
be reliably zero, since x86 chips have treated this as a divide by
zero since the beginning of time (well 1981 :-)), a SIGFPE is quite
expected! So I guess Roberto's "no one" does not include me :-)


David Daney

RE: Miscompilation of remainder expressions

[Dave Korn]

On 16 January 2007 18:23, Robert Dewar wrote:

> Gabriel Paubert wrote:
> \
>> No, because the instruction has actually two result values:
>> 
>> - the remainder, which you could safely set to zero (not 1!)
>> 
>> - the quotient, which is affected by the overflow and there may be
>>   compiler and languages that rely on the exception being generated.
> 
> But the division is undefined, programs have no right to
> rely on an exception being generated.

  It really depends whether you think of the % operator as being an atomic
mathematical operation, or a compound function involving real division and
multiplication and subtraction.  I think the wording of the standard says only
that the inequality "(a/b)*b + a%b == a" does not hold when (a/b) cannot be
represented, but does not deny the modulo operator the option of just
returning the correct result, which is representable.

cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: Miscompilation of remainder expressions

[Roberto Bagnara]

Robert Dewar wrote:

Roberto Bagnara wrote:

Andrew Haley wrote:

Roberto Bagnara writes:
 >  > Reading the thread "Autoconf manual's coverage of signed integer
 > overflow & portability" I was horrified to discover about GCC's
 > miscompilation of the remainder expression that causes INT_MIN % -1
 > to cause a SIGFPE on CPUs of the i386 family.  Are there plans to
 > fix this bug (which, to me, looks quite serious)?

No, there aren't.  It would make more sense for you to wrap % in some
code that checks for this, rather than for us to slow down every 
division

for this one special case.


With all due respect, I must say I am shocked.  I always thought
(and taught) that we, Free Software people, value standard conformance
and getting things right.  Now we have a bug that can shut down
airplanes 


Please do not indulge in excessive rhetoric, planes do not get
shut down by compiler bugs. If you really think that the integrity
of avionics software depends on bug free compilers you have no
idea what you are talking about (I would guess you are for
example unfamiliar with DO-178B certification).


You are right: I am not familiar with DO-178B certification.


Yes, it's a bug, is it a serious bug, no? Will real software
be affected? no. Indeed I find any program that actually
does this remainder operation in practice to be highly
suspect.


But I am not wrong if I say that a bug is a bug and must be fixed.
I was answering to a message saying (basically) "we won't fix
it since there is a performance penalty to be paid."
I do not feel to be excessively rhetoric if I say that others,
not us, are said to knowingly disregard standards, whether it be
for performance reasons or for other reasons.  Of course, this
is a matter of taste.


A final remark: I think that today the problem is safety, not speed.
I don't think doing the right thing for remainder expression will
have such a high cost with the help of the optimizer and, maybe,
assistance from the kernel.  But even if the cost turns out to be high,
the actual state of things is unacceptable: mentioning the bug 
prominently

in the documentation, trying to change the standard, ..., whatever;
but not leaving things as they are.


Yes, it should probably be fixed, but making a major fuss about
it seems peculiar at best. I think it is perfectly reasonable
for you to propose a patch to fix this if you are specially
concerned, but don't expect the community to rush to fix this
particular bug at high priority in response to this complaint.


I am sorry if I brought you to think that I am asking something
for me.  There is no longer a problem for me personally: I will
simply stop using % in my projects (which, by the way are in C++)
and will use custom functions instead.  I have almost finished
an Autoconf test to check for this bug.  Most importantly, I am
now perfectly aware of the problem.  I have filed a couple
of bug reports, one for GCC and the other for the Intel C/C++
compiler.  I have been told that a C Standard Defect Report
already exists on this subject.  So, it is the end of the
story, as far as I am personally concerned.
Concerning the community (to which I belong, by the way)
I propose that, to start with, the documentation is modified
to mention this problem in a prominent way.  The text can
be borrowed from the new Autoconf's documentation that has
been recently discussed on this list.


There are lots of known bugs far more important than this one.


Wow!  I hope they are all in Bugzilla: the one we are talking
about was apparently not there until a couple of hours ago.

--
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:[EMAIL PROTECTED]

Re: Miscompilation of remainder expressions

[Robert Dewar]

Dave Korn wrote:

On 16 January 2007 18:23, Robert Dewar wrote:


Gabriel Paubert wrote:
\

No, because the instruction has actually two result values:

- the remainder, which you could safely set to zero (not 1!)

- the quotient, which is affected by the overflow and there may be
  compiler and languages that rely on the exception being generated.

But the division is undefined, programs have no right to
rely on an exception being generated.


  It really depends whether you think of the % operator as being an atomic
mathematical operation, or a compound function involving real division and
multiplication and subtraction.  I think the wording of the standard says only
that the inequality "(a/b)*b + a%b == a" does not hold when (a/b) cannot be
represented, but does not deny the modulo operator the option of just
returning the correct result, which is representable.


I think you missed my point

For sure a/b is undefined, so the trap routine does not have to worry
about the case where the trap comes from a/b, it only has to worry
about the case where the remainder is wanted, so setting the remainder
is indeed safe.


cheers,
  DaveK

Re: Miscompilation of remainder expressions

[Robert Dewar]

Roberto Bagnara wrote:


I am sorry if I brought you to think that I am asking something
for me.  There is no longer a problem for me personally: I will
simply stop using % in my projects (which, by the way are in C++)
and will use custom functions instead.  I have almost finished
an Autoconf test to check for this bug.  Most importantly, I am
now perfectly aware of the problem.  I have filed a couple
of bug reports, one for GCC and the other for the Intel C/C++
compiler.  I have been told that a C Standard Defect Report
already exists on this subject.  So, it is the end of the
story, as far as I am personally concerned.
Concerning the community (to which I belong, by the way)
I propose that, to start with, the documentation is modified
to mention this problem in a prominent way.  The text can
be borrowed from the new Autoconf's documentation that has
been recently discussed on this list.


OK, so sounds like this bug definitely is in the status of
being of extremly low priority, since the only user who has
ever cared about it so far doesn't care any more



There are lots of known bugs far more important than this one.


Wow!


Are you *really* surprised by that statement above, if so
it's pretty amazing.


I hope they are all in Bugzilla: the one we are talking
about was apparently not there until a couple of hours ago.


Maybe they are may be not, it's not that critical, since
there are lots of serious bugs that are not known. So you
can never write programs that critically depend on compiler
correctness.

RE: Miscompilation of remainder expressions

[Dave Korn]

On 16 January 2007 18:42, Robert Dewar wrote:

> Dave Korn wrote:
>> On 16 January 2007 18:23, Robert Dewar wrote:
>> 
>>> Gabriel Paubert wrote:
>>> \
 No, because the instruction has actually two result values:
 
 - the remainder, which you could safely set to zero (not 1!)
 
 - the quotient, which is affected by the overflow and there may be
   compiler and languages that rely on the exception being generated.
>>> But the division is undefined, programs have no right to
>>> rely on an exception being generated.
>> 
>>   It really depends whether you think of the % operator as being an atomic
>> mathematical operation, or a compound function involving real division and
>> multiplication and subtraction.  I think the wording of the standard says
>> only that the inequality "(a/b)*b + a%b == a" does not hold when (a/b)
>> cannot be represented, but does not deny the modulo operator the option of
>> just returning the correct result, which is representable.
> 
> I think you missed my point

  Oops, yeh.  I was thinking of Andrew Haley's question about the wording of
the language in the standard.

cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: Miscompilation of remainder expressions

[Joe Buck]

On Tue, Jan 16, 2007 at 12:05:12PM -0600, Gabriel Dos Reis wrote:
> By definition, the absolute value of "a % b" is always less than the
> absolute value of b.  Consequently, "a % b" is always defined.

Nitpick: for nonzero b.

Re: Miscompilation of remainder expressions

[Gabriel Dos Reis]

On Tue, 16 Jan 2007, Joe Buck wrote:

| On Tue, Jan 16, 2007 at 12:05:12PM -0600, Gabriel Dos Reis wrote:
| > By definition, the absolute value of "a % b" is always less than the
| > absolute value of b.  Consequently, "a % b" is always defined.
|
| Nitpick: for nonzero b.

yes, I assumed that -- since the standard says that the result is
undefined when b is zero.  I should have repeated that assumption.

-- Gaby

Re: Miscompilation of remainder expressions

[Roberto Bagnara]

David Daney wrote:

Roberto Bagnara wrote:

Robert Dewar wrote:


Roberto Bagnara wrote:


Reading the thread "Autoconf manual's coverage of signed integer
overflow & portability" I was horrified to discover about GCC's
miscompilation of the remainder expression that causes INT_MIN % -1
to cause a SIGFPE on CPUs of the i386 family.  Are there plans to
fix this bug (which, to me, looks quite serious)?
All the best,

Roberto

P.S. I checked whether this bug affects my code and it does.
  Before yesterday I was completely unsuspecting of such
  a fundamental flaw... I wonder how many know about it.



It's truly amazing for real code to be computing remainders
in this domain ... seems a bad idea to me, since very few
people are comfortably aware of what remainder means for
such cases.



Everyone knows that dividing a number by -1 or 1 gives
a 0 remainder.  To the contrary, no one expects a%b to
raise SIFPE when b != 0.



On the contrary, since the beginning of time SIGFPE has been generated 
on GCC/x86/linux under these conditions.  This is wildly known.


Just because you just found out about it does not mean that 'no one' 
expects it.


OK: so it is my fault.  But even if it is so wildly known, I think
the GCC documentation should still mention it, for the sake of the
few morons like me that are unsuspecting.

From http://en.wikipedia.org/wiki/SIGFPE

  A common oversight is to consider division by zero the only source
  of SIGFPE conditions. On some architectures (IA-32 included), integer
  division of INT_MIN, the smallest representable negative integer value,
  by -1 triggers the signal because the quotient, a positive number,
  is not representable.

Hmmm, it says nothing about the remainder.  Can some Google guru
suggest how to prove or disprove the claim that what we are
talking about is wildly known?

--
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:[EMAIL PROTECTED]

Re: Miscompilation of remainder expressions

[Robert Dewar]

Roberto Bagnara wrote:


You are right: I am not familiar with DO-178B certification.


Fair enough, but it means you should never use avionics code
as an example in such discussions. No life has ever been lost
due to a software bug in the realm of commercial aviation, and
that was not achieved by trusting compilers to be bug free.



Yes, it's a bug, is it a serious bug, no? Will real software
be affected? no. Indeed I find any program that actually
does this remainder operation in practice to be highly
suspect.


But I am not wrong if I say that a bug is a bug and must be fixed.


must be fixed

never means more than "may be fixed if someone either gets
enthusiastic enough to do it themselves, or is paid to fix it."
Of course serious bugs usually fall into one of these categories
in a reasonable time period.

Reduce size of indirect-dispatch executables

[Andrew Haley]

I noticed that we were repeatedly reloading from memory this.class and
this.class.constants.  It makes far more sense to read these values at
the start of a method, and that is what this patch does.  It reduces
the text size of 32-bit indirect-dispatch executables by 1.4% and
64-bit by 1.3%.

We need a more general patch to hoist invariants in gcj -- there are a
lot of these -- but this is a good start.

Andrew.


2007-01-16  Andrew Haley  <[EMAIL PROTECTED]>

* expr.c (expand_byte_code): Call cache_this_class_ref() and
cache_cpool_data_ref().
Set TYPE_CPOOL_DATA_REF.
(cache_cpool_data_ref): New function.
* constants.c (build_ref_from_constant_pool): Remove special-case
code for flag_indirect_classes.
* decl.c (finish_method): Move class initialization from here to
cache_this_class_ref.
* class.c (cache_this_class_ref): New function.
(build_class_ref): Use this_classdollar to get the
current class$.

Index: class.c
===
--- class.c (revision 120621)
+++ class.c (working copy)
@@ -110,6 +110,10 @@
 
 static GTY(()) VEC(tree,gc) *registered_class;
 
+/* A tree that returns the address of the class$ of the class
+   currently being compiled.  */
+static GTY(()) tree this_classdollar;
+
 /* Return the node that most closely represents the class whose name
is IDENT.  Start the search from NODE (followed by its siblings).
Return NULL if an appropriate node does not exist.  */
@@ -1031,6 +1035,35 @@
   return decl;
 }
 
+/* Create a local variable that holds the the current class$.  */
+
+void
+cache_this_class_ref (tree fndecl)
+{
+  tree classdollar_field = build_classdollar_field (output_class);
+  this_classdollar = build_decl (VAR_DECL, NULL_TREE, 
+TREE_TYPE (classdollar_field));
+  
+  java_add_local_var (this_classdollar);
+  java_add_stmt (build2 (MODIFY_EXPR, TREE_TYPE (this_classdollar), 
+this_classdollar, classdollar_field));
+
+  /* Prepend class initialization for static methods reachable from
+ other classes.  */
+  if (METHOD_STATIC (fndecl)
+  && (! METHOD_PRIVATE (fndecl)
+  || INNER_CLASS_P (DECL_CONTEXT (fndecl)))
+  && ! DECL_CLINIT_P (fndecl)
+  && ! CLASS_INTERFACE (TYPE_NAME (DECL_CONTEXT (fndecl
+{
+  tree init = build3 (CALL_EXPR, void_type_node,
+ build_address_of (soft_initclass_node),
+ build_tree_list (NULL_TREE, this_classdollar),
+ NULL_TREE);
+  java_add_stmt (init);
+}
+}
+
 /* Build a reference to the class TYPE.
Also handles primitive types and array types. */
 
@@ -1050,7 +1083,7 @@
return build_indirect_class_ref (type);
 
   if (type == output_class && flag_indirect_classes)
-   return build_classdollar_field (type);
+   return this_classdollar;
   
   if (TREE_CODE (type) == RECORD_TYPE)
return build_static_class_ref (type);
@@ -2537,7 +2570,7 @@
 
   if (TYPE_NVIRTUALS (this_class))
 return;
-
+  
   super_class = CLASSTYPE_SUPER (this_class);
 
   if (super_class)
Index: decl.c
===
--- decl.c  (revision 120621)
+++ decl.c  (working copy)
@@ -2001,22 +2001,6 @@
build2 (TRY_FINALLY_EXPR, void_type_node, *tp, exit));
 }
 
-  /* Prepend class initialization for static methods reachable from
- other classes.  */
-  if (METHOD_STATIC (fndecl)
-  && (! METHOD_PRIVATE (fndecl)
-  || INNER_CLASS_P (DECL_CONTEXT (fndecl)))
-  && ! DECL_CLINIT_P (fndecl)
-  && ! CLASS_INTERFACE (TYPE_NAME (DECL_CONTEXT (fndecl
-{
-  tree clas = DECL_CONTEXT (fndecl);
-  tree init = build3 (CALL_EXPR, void_type_node,
- build_address_of (soft_initclass_node),
- build_tree_list (NULL_TREE, build_class_ref (clas)),
- NULL_TREE);
-  *tp = build2 (COMPOUND_EXPR, TREE_TYPE (*tp), init, *tp);
-}
-
   /* Convert function tree to GENERIC prior to inlining.  */
   java_genericize (fndecl);
 
Index: constants.c
===
--- constants.c (revision 120621)
+++ constants.c (working copy)
@@ -448,7 +448,7 @@
   TREE_STATIC (decl) = 1;
   TYPE_CPOOL_DATA_REF (output_class) = decl;
 }
-
+  
   return decl;
 }
 
@@ -459,25 +459,6 @@
 {
   tree d = build_constant_data_ref ();
   tree i = build_int_cst (NULL_TREE, index);
-  if (flag_indirect_classes)
-{
-  tree decl = build_class_ref (output_class);
-  tree klass = build1 (INDIRECT_REF, TREE_TYPE (TREE_TYPE (decl)),
-  decl);
-  tree constants = build3 (COMPONENT_REF, 
-  TREE_TYPE (constants_field_decl_node), klass,
-   

Re: relevant files for target backends

[Rask Ingemann Lambertsen]

On Tue, Jan 16, 2007 at 11:24:56AM +0100, Markus Franke wrote:

> I am wondering where to define the prototypes for functions in
> .c Shall the prototypes be defined in -protos.h or in
> .h or in .c. As far as I understand the prototypes
> should be defined in -protos.h, right? But if I do so several
> errors/warnings arise because of undeclared prototypes.

   All functions and variables not declared static in .c should
have a prototype in -protos.h. Also, does this patch help?

Index: gcc/var-tracking.c
===
--- gcc/var-tracking.c  (revision 120287)
+++ gcc/var-tracking.c  (working copy)
@@ -106,6 +106,7 @@
 #include "expr.h"
 #include "timevar.h"
 #include "tree-pass.h"
+#include "tm_p.h"
 
 /* Type of micro operation.  */
 enum micro_operation_type

> But there are also a lot of macros defined in .h. What kind of
> macros should be defined in .h and which macros should be
> defined in .c?

   Those listed as macros in the documentation should go into .h
while those listed as target hooks should go into .c.

> I try to write good and standardised code in order to contribute my
> development. I would appreciate any help. By the way, I already had a
> look in the GCC Internals manual but I am still a bit confused.

   I would like to encurage you to submit a patch for the GCC Internals
manual to make it clearer.
   
-- 
Rask Ingemann Lambertsen

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Thorsten Glaser]

Paul Eggert dixit:

>  […] gcc -O2 makes no promises without
>  -fwrapv.

gcc -O1 -fwrapv even doesn't work correctly for gcc3,
and gcc2 and gcc <3.3(?) don't even have -fwrapv:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30477

bye,
//mirabile
-- 
  "Using Lynx is like wearing a really good pair of shades: cuts out
   the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL."
 -- Henry Nelson, March 1999

Re: Miscompilation of remainder expressions

[David Daney]

Roberto Bagnara wrote:


Hmmm, it says nothing about the remainder.  Can some Google guru
suggest how to prove or disprove the claim that what we are
talking about is wildly known?



The point really is not how widely/wildly known the issue is.  Really 
the thing we consider on gcc@ is:  What is the 'best' thing for GCC and 
the GCC developers to do.


I don't claim to speak for others, but until now this issue has not 
seemed all that pressing.  And it still doesn't.


David Daney

Re: Miscompilation of remainder expressions

[Andrew Haley]

Roberto Bagnara writes:
 > Robert Dewar wrote:
 > 
 > > Yes, it's a bug, is it a serious bug, no? Will real software
 > > be affected? no. Indeed I find any program that actually
 > > does this remainder operation in practice to be highly
 > > suspect.
 > 
 > But I am not wrong if I say that a bug is a bug and must be fixed.
 > I was answering to a message saying (basically) "we won't fix
 > it since there is a performance penalty to be paid."

It wasn't saying that.

My opinion at the time was (and still is) that it probably isn't a
bug, and there is a performance penalty to be paid for changing the
behaviour, so we shouldn't fix it.

If I had believed that it surely was a bug, then I wouldn't have made
the performance argument: correctness first, then performance.

Andrew.

Re: Miscompilation of remainder expressions

[Joe Buck]

On Tue, Jan 16, 2007 at 11:05:20AM -0800, David Daney wrote:
> Roberto Bagnara wrote:
> >
> >Hmmm, it says nothing about the remainder.  Can some Google guru
> >suggest how to prove or disprove the claim that what we are
> >talking about is wildly known?
> >
> 
> The point really is not how widely/wildly known the issue is.  Really 
> the thing we consider on gcc@ is:  What is the 'best' thing for GCC and 
> the GCC developers to do.
> 
> I don't claim to speak for others, but until now this issue has not 
> seemed all that pressing.  And it still doesn't.

We can talk about this forever, but how about moving to a resolution?

First off, is there a PR for this bug?  Second, if it were to be fixed,
what is the fix that minimizes the extra overhead?  I suspect that many
users would not want the fix if it slows down integer modulo
significantly, or if they are already coding defensively because they know
about the issue, but that some users *would* want it.

The final solution would be a fix that is enabled by some flag.  We can
then have another argument as to the name of the flag and when it is
enabled.

I suggest that those who think this is a severe problem are the ones who
are highly motivated to work on a solution.  An efficient solution could
be tricky: you don't want to disrupt pipelines, or interfere with
optimizations that rely on recognizing that there is a modulo.

I don't think anyone would object if there were a non-default option to
ensure that anything % -1 is zero and does not trap, especially if the
overhead were small.  So Roberto, how about it?  Would you like to work on
that?  Any other volunteers?  You can't expect those who don't see it as
a serious problem to volunteer, not with so many other open bugs.

Re: Miscompilation of remainder expressions

[Robert Dewar]

Andrew Haley wrote:

Roberto Bagnara writes:
 > Robert Dewar wrote:
 > 
 > > Yes, it's a bug, is it a serious bug, no? Will real software

 > > be affected? no. Indeed I find any program that actually
 > > does this remainder operation in practice to be highly
 > > suspect.
 > 
 > But I am not wrong if I say that a bug is a bug and must be fixed.

 > I was answering to a message saying (basically) "we won't fix
 > it since there is a performance penalty to be paid."

It wasn't saying that.

My opinion at the time was (and still is) that it probably isn't a
bug, and there is a performance penalty to be paid for changing the
behaviour, so we shouldn't fix it.

If I had believed that it surely was a bug, then I wouldn't have made
the performance argument: correctness first, then performance.


Yes, of course, I think we all agree with that. Roberto was just
misreading here


Andrew.

Re: relevant files for target backends

[Markus Franke]

Thank you very much. That was exactly the information I was looking for.
I will think about a contribution to the GCC Internals.

Thanks again,
Markus Franke

Rask Ingemann Lambertsen wrote:
> On Tue, Jan 16, 2007 at 11:24:56AM +0100, Markus Franke wrote:
> 
> 
>>I am wondering where to define the prototypes for functions in
>>.c Shall the prototypes be defined in -protos.h or in
>>.h or in .c. As far as I understand the prototypes
>>should be defined in -protos.h, right? But if I do so several
>>errors/warnings arise because of undeclared prototypes.
> 
> 
>All functions and variables not declared static in .c should
> have a prototype in -protos.h. Also, does this patch help?
> 
> Index: gcc/var-tracking.c
> ===
> --- gcc/var-tracking.c(revision 120287)
> +++ gcc/var-tracking.c(working copy)
> @@ -106,6 +106,7 @@
>  #include "expr.h"
>  #include "timevar.h"
>  #include "tree-pass.h"
> +#include "tm_p.h"
>  
>  /* Type of micro operation.  */
>  enum micro_operation_type
> 
> 
>>But there are also a lot of macros defined in .h. What kind of
>>macros should be defined in .h and which macros should be
>>defined in .c?
> 
> 
>Those listed as macros in the documentation should go into .h
> while those listed as target hooks should go into .c.
> 
> 
>>I try to write good and standardised code in order to contribute my
>>development. I would appreciate any help. By the way, I already had a
>>look in the GCC Internals manual but I am still a bit confused.
> 
> 
>I would like to encurage you to submit a patch for the GCC Internals
> manual to make it clearer.
>

-- 
Nichts ist so praktisch wie eine gute Theorie!

Re: Miscompilation of remainder expressions

[Vincent Lefevre]

On 2007-01-16 12:31:00 -0500, Robert Dewar wrote:
> Roberto Bagnara wrote:
> >Reading the thread "Autoconf manual's coverage of signed integer
> >overflow & portability" I was horrified to discover about GCC's
> >miscompilation of the remainder expression that causes INT_MIN % -1
> >to cause a SIGFPE on CPUs of the i386 family.  Are there plans to
> >fix this bug (which, to me, looks quite serious)?
> 
> Seems ultra-non-serious to me, hard to believe this case appears
> in real code, despite surprising claim by Roberto.

What makes you think so?

One never knows. We (the MPFR developers) found several compiler bugs
concerning particular cases like that, which occurred in MPFR. One of
them (in some gcc version) was 0 + LONG_MIN, which was different from
LONG_MIN. Is 0 + LONG_MIN so different from INT_MIN % -1, for instance?

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: Miscompilation of remainder expressions

[David Daney]

Vincent Lefevre wrote:

On 2007-01-16 12:31:00 -0500, Robert Dewar wrote:


Roberto Bagnara wrote:


Reading the thread "Autoconf manual's coverage of signed integer
overflow & portability" I was horrified to discover about GCC's
miscompilation of the remainder expression that causes INT_MIN % -1
to cause a SIGFPE on CPUs of the i386 family.  Are there plans to
fix this bug (which, to me, looks quite serious)?


Seems ultra-non-serious to me, hard to believe this case appears
in real code, despite surprising claim by Roberto.



What makes you think so?

One never knows. We (the MPFR developers) found several compiler bugs
concerning particular cases like that, which occurred in MPFR. One of
them (in some gcc version) was 0 + LONG_MIN, which was different from
LONG_MIN. Is 0 + LONG_MIN so different from INT_MIN % -1, for instance?



The difference is that your program didn't get killed by SIGFPE, it just 
gave incorrect results.


David Daney

Re: Miscompilation of remainder expressions

[Ian Lance Taylor]

Joe Buck <[EMAIL PROTECTED]> writes:

> I suggest that those who think this is a severe problem are the ones who
> are highly motivated to work on a solution.  An efficient solution could
> be tricky: you don't want to disrupt pipelines, or interfere with
> optimizations that rely on recognizing that there is a modulo.

I suspect that the best fix, in the sense of generating the best code,
would be to do this at the tree level.  That will give loop and VRP
optimizations the best chance to eliminate the test for -1.  Doing it
during gimplification would be easy, if perhaps rather ugly.  If there
are indeed several processors with this oddity, then it would even
make a certain degree of sense as a target-independent option.

If we think it's too ugly to do it in the target independent code,
then it's trivial to do it by changing the divmodsi4 define_expand in
config/i386/i386.md.

Ian

Re: Miscompilation of remainder expressions

[Andrew Haley]

Ian Lance Taylor writes:
 > Joe Buck <[EMAIL PROTECTED]> writes:
 > 
 > > I suggest that those who think this is a severe problem are the
 > > ones who are highly motivated to work on a solution.  An
 > > efficient solution could be tricky: you don't want to disrupt
 > > pipelines, or interfere with optimizations that rely on
 > > recognizing that there is a modulo.
 > 
 > I suspect that the best fix, in the sense of generating the best
 > code, would be to do this at the tree level.  That will give loop
 > and VRP optimizations the best chance to eliminate the test for -1.
 > Doing it during gimplification would be easy, if perhaps rather
 > ugly.  If there are indeed several processors with this oddity,
 > then it would even make a certain degree of sense as a
 > target-independent option.

x86, x86-64, S/390, as far as I'm aware.

Andrew.

Re: Miscompilation of remainder expressions

[Vincent Lefevre]

On 2007-01-16 15:50:09 +, Andrew Haley wrote:
> This is a disgreement about interpretation of the langauge in the
> standard, which is:
> 
> "The result of the / operator is the quotient from the division of the
> first operand by the second; the result of the % operator is the
> remainder. In both operations, if the value of the second operand is
> zero, the behavior is undefined. When integers are divided, the result
> of the / operator is the algebraic quotient with any fractional part
> discarded.87) If the quotient a/b is representable, the expression
> (a/b)*b + a%b shall equal a."
> 
> If the quotient a/b is *not* representable, is the behaviour of %
> well-defined or not?  It doesn't say.

The C standard already says "the result of the % operator is the
remainder". Then, "If the quotient a/b is representable, the expression
(a/b)*b + a%b shall equal a." is just redundant information.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: Miscompilation of remainder expressions

[David Daney]

Andrew Haley wrote:

Ian Lance Taylor writes:
 > Joe Buck <[EMAIL PROTECTED]> writes:
 > 
 > > I suggest that those who think this is a severe problem are the

 > > ones who are highly motivated to work on a solution.  An
 > > efficient solution could be tricky: you don't want to disrupt
 > > pipelines, or interfere with optimizations that rely on
 > > recognizing that there is a modulo.
 > 
 > I suspect that the best fix, in the sense of generating the best

 > code, would be to do this at the tree level.  That will give loop
 > and VRP optimizations the best chance to eliminate the test for -1.
 > Doing it during gimplification would be easy, if perhaps rather
 > ugly.  If there are indeed several processors with this oddity,
 > then it would even make a certain degree of sense as a
 > target-independent option.

x86, x86-64, S/390, as far as I'm aware.



MIPS does *not* seem to suffer from this 'defect', so a target 
independent solution that caused MIPS to generate worse code would be bad.


David Daney

Re: Miscompilation of remainder expressions

[Ian Lance Taylor]

David Daney <[EMAIL PROTECTED]> writes:

> Andrew Haley wrote:
> > Ian Lance Taylor writes:
> >  > Joe Buck <[EMAIL PROTECTED]> writes:
> >  >  > > I suggest that those who think this is a severe problem are
> > the
> >  > > ones who are highly motivated to work on a solution.  An
> >  > > efficient solution could be tricky: you don't want to disrupt
> >  > > pipelines, or interfere with optimizations that rely on
> >  > > recognizing that there is a modulo.
> >  >  > I suspect that the best fix, in the sense of generating the
> > best
> >  > code, would be to do this at the tree level.  That will give loop
> >  > and VRP optimizations the best chance to eliminate the test for -1.
> >  > Doing it during gimplification would be easy, if perhaps rather
> >  > ugly.  If there are indeed several processors with this oddity,
> >  > then it would even make a certain degree of sense as a
> >  > target-independent option.
> > x86, x86-64, S/390, as far as I'm aware.
> >
> 
> MIPS does *not* seem to suffer from this 'defect', so a target
> independent solution that caused MIPS to generate worse code would be
> bad.

To be clear, in my opinion, this should always be selected by an
option, it should never be default behaviour for any target.

Ian

Re: Miscompilation of remainder expressions

[Joe Buck]

On Tue, Jan 16, 2007 at 01:31:06PM -0800, David Daney wrote:
> Andrew Haley wrote:
> >Ian Lance Taylor writes:
> > > I suspect that the best fix, in the sense of generating the best
> > > code, would be to do this at the tree level.  That will give loop
> > > and VRP optimizations the best chance to eliminate the test for -1.
> > > Doing it during gimplification would be easy, if perhaps rather
> > > ugly.  If there are indeed several processors with this oddity,
> > > then it would even make a certain degree of sense as a
> > > target-independent option.
> >
> >x86, x86-64, S/390, as far as I'm aware.
> >
> 
> MIPS does *not* seem to suffer from this 'defect', so a target 
> independent solution that caused MIPS to generate worse code would be bad.

Since at least three targets are affected, it would seem that doing it at
the tree level is the right thing.  The tree level code could
consult a flag saying whether to jump through hoops to avoid faulting for i % 
-1.
This flag would never be set for the MIPS, and would be set for x86,
x86-64, or S/390 only if the user asks for it.  If the flag is present,
the operation would be treat i % j as either (j == -1 ? 0 : i rem j) or
(i % abs(j)) or whatever other expression might yield the best code.

Re: Miscompilation of remainder expressions

[Gabriel Dos Reis]

Joe Buck <[EMAIL PROTECTED]> writes:

| On Tue, Jan 16, 2007 at 11:05:20AM -0800, David Daney wrote:
| > Roberto Bagnara wrote:
| > >
| > >Hmmm, it says nothing about the remainder.  Can some Google guru
| > >suggest how to prove or disprove the claim that what we are
| > >talking about is wildly known?
| > >
| > 
| > The point really is not how widely/wildly known the issue is.  Really 
| > the thing we consider on gcc@ is:  What is the 'best' thing for GCC and 
| > the GCC developers to do.
| > 
| > I don't claim to speak for others, but until now this issue has not 
| > seemed all that pressing.  And it still doesn't.
| 
| We can talk about this forever, but how about moving to a resolution?

seconded.

| First off, is there a PR for this bug?

I believe this is target/30484.

Ian, do you believe something along the line of

 # > I mean, could not we generate the following for "%": 
 # >
 # > rem a b := 
 # >   if abs(b) == 1
 # >  return 0
 # >   return  a b
 #
 # On x86 processors that have conditional moves, why not do the equivalent
 # of
 #
 # neg_b = -b;
 # cmov(last result is negative,neg_b,b)
 # __machine_rem(a,b)
 #
 # Then there's no disruption of the pipeline.

is workable for the affected targets?

-- Gaby

Re: Miscompilation of remainder expressions

[Ian Lance Taylor]

Gabriel Dos Reis <[EMAIL PROTECTED]> writes:

> Ian, do you believe something along the line of
> 
>  # > I mean, could not we generate the following for "%": 
>  # >
>  # > rem a b := 
>  # >   if abs(b) == 1
>  # >  return 0
>  # >   return  a b
>  #
>  # On x86 processors that have conditional moves, why not do the equivalent
>  # of
>  #
>  # neg_b = -b;
>  # cmov(last result is negative,neg_b,b)
>  # __machine_rem(a,b)
>  #
>  # Then there's no disruption of the pipeline.
> 
> is workable for the affected targets?

Sure, I think the only real issue is where the code should be
inserted.

Ian

Re: Miscompilation of remainder expressions

[Vincent Lefevre]

On 2007-01-16 13:08:18 -0800, David Daney wrote:
> The difference is that your program didn't get killed by SIGFPE, it
> just gave incorrect results.

An incorrect result is worse, but being killed by SIGFPE is still very
bad.

But I was mainly answering the claim "hard to believe this case appears
in real code". IMHO, INT_MIN % -1 can appear just as 0 + LONG_MIN can
appear, just as LONG_MIN / 1 can appear.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

meaning of typedef ...and something more

[Laura Tardivo]

Hi, my question is about the meanig of qualifiers in combination with 
typedefs. For example:

typedef int function1();
typedef int function2();
...
typedef function1 transition1;
typedef function2 transition2;
...
int Def_Fun( volatile transition1);
int Def_Fun( volatile transition2 const);

Specífically, between functionX and transitionX, and before functionX we can 
add pointer, volatile and const, but what are the meanings of this 
cualifiers in that places.
Someone can help us?. Thanks!



--
Departamento de Computaciòn
Universidad Nacional de Río Cuarto

Re: Miscompilation of remainder expressions

[Vincent Lefevre]

On 2007-01-16 21:27:42 +, Andrew Haley wrote:
> Ian Lance Taylor writes:
>  > I suspect that the best fix, in the sense of generating the best
>  > code, would be to do this at the tree level.  That will give loop
>  > and VRP optimizations the best chance to eliminate the test for -1.
>  > Doing it during gimplification would be easy, if perhaps rather
>  > ugly.  If there are indeed several processors with this oddity,
>  > then it would even make a certain degree of sense as a
>  > target-independent option.
> 
> x86, x86-64, S/390, as far as I'm aware.

and PowerPC G4 and G5, where I don't get a crash, but an incorrect
result (as said on PR#30484).

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: Miscompilation of remainder expressions

[Vincent Lefevre]

On 2007-01-16 13:41:16 -0800, Ian Lance Taylor wrote:
> To be clear, in my opinion, this should always be selected by an
> option, it should never be default behaviour for any target.

I disagree. One should get correct results by default.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: Miscompilation of remainder expressions

[Gabriel Dos Reis]

Vincent Lefevre <[EMAIL PROTECTED]> writes:

| On 2007-01-16 13:41:16 -0800, Ian Lance Taylor wrote:
| > To be clear, in my opinion, this should always be selected by an
| > option, it should never be default behaviour for any target.
| 
| I disagree. One should get correct results by default.

Once we have an implemented solution, we can quibble over whether it
should be on by default or not.  That debate will be supported by
sample of hard data.  Once we have an implementation.

-- Gaby

Re: Miscompilation of remainder expressions

[Andrew Pinski]

> 
> Vincent Lefevre <[EMAIL PROTECTED]> writes:
> 
> | On 2007-01-16 13:41:16 -0800, Ian Lance Taylor wrote:
> | > To be clear, in my opinion, this should always be selected by an
> | > option, it should never be default behaviour for any target.
> | 
> | I disagree. One should get correct results by default.
> 
> Once we have an implemented solution, we can quibble over whether it
> should be on by default or not.  That debate will be supported by
> sample of hard data.  Once we have an implementation.

I wonder why the call to div/ldiv/lldiv says the behavior is undefined while
% is defined, that seems wrong.

The specific wording from the standard is "If either part of the result
cannot be represented, the behavior is undefined." So why is % different
from those functions?

-- Pinski

Re: meaning of typedef ...and something more

[Joe Buck]

On Tue, Jan 16, 2007 at 10:54:33PM -0300, Laura Tardivo wrote:
> 
> Hi, my question is about the meanig of qualifiers in combination with 
> typedefs. For example:

Laura,

That is a C language question, and is not gcc-specific.  The gcc list is
for the compiler developers to communicate, and even gcc-help is not for
teaching people the C language, though it can be used for help with gcc
usage.

You could try the comp.lang.c.moderated forum.

Re: Miscompilation of remainder expressions

[Gabriel Dos Reis]

Andrew Pinski <[EMAIL PROTECTED]> writes:

| > 
| > Vincent Lefevre <[EMAIL PROTECTED]> writes:
| > 
| > | On 2007-01-16 13:41:16 -0800, Ian Lance Taylor wrote:
| > | > To be clear, in my opinion, this should always be selected by an
| > | > option, it should never be default behaviour for any target.
| > | 
| > | I disagree. One should get correct results by default.
| > 
| > Once we have an implemented solution, we can quibble over whether it
| > should be on by default or not.  That debate will be supported by
| > sample of hard data.  Once we have an implementation.
| 
| I wonder why the call to div/ldiv/lldiv says the behavior is undefined while
| % is defined, that seems wrong.

That is because div also has to compute the division too (which is undefined)
"%" does not.

| The specific wording from the standard is "If either part of the result
| cannot be represented, the behavior is undefined." So why is % different
| from those functions?

because "%" is not "div", syntactically and semantically.

-- Gaby

Re: Miscompilation of remainder expressions

[Joe Buck]

On Tue, Jan 16, 2007 at 06:55:45PM -0500, Andrew Pinski wrote:
> > 
> > Vincent Lefevre <[EMAIL PROTECTED]> writes:
> > 
> > | On 2007-01-16 13:41:16 -0800, Ian Lance Taylor wrote:
> > | > To be clear, in my opinion, this should always be selected by an
> > | > option, it should never be default behaviour for any target.
> > | 
> > | I disagree. One should get correct results by default.
> > 
> > Once we have an implemented solution, we can quibble over whether it
> > should be on by default or not.  That debate will be supported by
> > sample of hard data.  Once we have an implementation.
> 
> I wonder why the call to div/ldiv/lldiv says the behavior is undefined while
> % is defined, that seems wrong.
> 
> The specific wording from the standard is "If either part of the result
> cannot be represented, the behavior is undefined." So why is % different
> from those functions?

Let's keep the two issues separate.  Clearly some users want a solution;
if people are willing to contribute a solution we should accept it.
There appears to be controversy over the language requirement.  If a
solution is contributed, then the default setting of the switch (whether
on or off by default) is a separate matter.  We might even consider doing
a survey: what do the users want?

Benchmark wars might also have an impact.  Does icc generate a SIGFPE?
What's the effect on benchmarks?  Some users might want to pay the price
to be sure the trap is avoided, others might not.

Re: meaning of typedef ...and something more

[Ian Lance Taylor]

"Laura Tardivo" <[EMAIL PROTECTED]> writes:

> Hi, my question is about the meanig of qualifiers in combination with 
> typedefs. For example:
> 
> typedef int function1();
> typedef int function2();
> ...
> typedef function1 transition1;
> typedef function2 transition2;
> ...
> int Def_Fun( volatile transition1);
> int Def_Fun( volatile transition2 const);
> 
> Specífically, between functionX and transitionX, and before functionX we can 
> add pointer, volatile and const, but what are the meanings of this 
> cualifiers in that places.
> Someone can help us?. Thanks!

Please do not post to both the gcc-help and gcc mailing lists.  A
question like this is only appropriate for gcc-help.

Actually, it's not really even appropriate for gcc-help, since the
question is not about gcc.  This is a question about the C language.

I would try to answer your question, but unfortunately I don't
understand it.  Since this only has to do with C, not with gcc, I
recommend comp.lang.c, which you can reach at, e.g.:
http://groups.google.com/group/comp.lang.c/topics

Ian

Preventing warnings

[Richard Stallman]

In Emacs we have a macro that tends to produce the warning

   comparison is always false due to limited range of data type

when compiling for 64-bit machines.  EMACS_INT is 64 bits
in that case.  Here is the macro:

#define FIXNUM_OVERFLOW_P(i) \
  ((EMACS_INT)(i) > MOST_POSITIVE_FIXNUM \
   || (EMACS_INT) (i) < MOST_NEGATIVE_FIXNUM)

When this macro is used on an expression that has type int, it
produces those warnings, and there is no way to change the macro to
prevent the warnings.  We used the workaround of copying the
expression into an EMACS_INT in a previous statement, but that is
cumbersome and ugly.

Is there a way to write the macro so as to suppress this warning?

If not, I think one ought to be implemented.  I have a suggestion for
what it could look like:

#define FIXNUM_OVERFLOW_P(i) \
  ((EMACS_INT)(int)(i) > MOST_POSITIVE_FIXNUM \
   || (EMACS_INT)(int)(i) < MOST_NEGATIVE_FIXNUM)

The casts to int could be interpreted as meaning "yes I know this is
limited to the range of of ints, so don't warn me about the
consequences of that fact."

Please respond.

http://gcc.gnu.org/svnwrite.html points to non-existing source http://gcc.gnu.org/ml/gcc-SVN/

[Tomas Bily]

Hi,

 I found out that page http://gcc.gnu.org/svnwrite.html points to
http://gcc.gnu.org/ml/gcc-SVN/ mailing list but it doesn't exist. It's
in section "Write access policies" above "Free for all" subsection.
It seems that correct list is http://gcc.gnu.org/ml/gcc-cvs/.

 Tomas

Re: http://gcc.gnu.org/svnwrite.html points to non-existing source http://gcc.gnu.org/ml/gcc-SVN/

[Ben Elliston]

>  I found out that page http://gcc.gnu.org/svnwrite.html points to
> http://gcc.gnu.org/ml/gcc-SVN/ mailing list but it doesn't exist. It's
> in section "Write access policies" above "Free for all" subsection.
> It seems that correct list is http://gcc.gnu.org/ml/gcc-cvs/.

Nicely spotted.  I think someone got overzealous with search and
replace.  :-)

Ben

Char array alignment for PowerPc changed

[Michael Eager]

With powerpc-eabi-gcc, I noticed that there's been a small
change between gcc-3.4 and gcc-4.1 in how automatic char arrays
are allocated.

In gcc-3.4, char arrays are aligned on word boundaries.
In gcc-4.1, they are aligned on byte boundaries.

For example:

void foo() {
  char a[31];
  char b[31];
  ...

On gcc-3.4, "b" would be allocated at a+32; in gcc-4.1, it's a+31.

I can't find a bug report which mentions this, nor
do I see anything in the code either in function.c or
in the LOCAL_ALIGNMENT macro in rs6000.h which would
have this effect.

Was this a deliberate change?  If so, where?

The PPC EABI says that arrays are aligned on the boundary
of the type, which suggests that this was a bug fix.  But
unaligned char arrays make strcpy much slower.

--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: Preventing warnings

[Brooks Moses]

Richard Stallman wrote:

If not, I think one ought to be implemented.  I have a suggestion for
what it could look like:

#define FIXNUM_OVERFLOW_P(i) \
  ((EMACS_INT)(int)(i) > MOST_POSITIVE_FIXNUM \
   || (EMACS_INT)(int)(i) < MOST_NEGATIVE_FIXNUM)

The casts to int could be interpreted as meaning "yes I know this is
limited to the range of of ints, so don't warn me about the
consequences of that fact."


It appears to me that this syntax wouldn't work for the primary purpose 
that you're using this for, though.  If this is applied to an expression 
that's of larger-than-int type and is outside the range of ints, won't 
this syntax always convert it to something that is inside the range of 
ints?  And so, if MOST_POSITIVE_FIXNUM and MOST_NEGATIVE_FIXNUM are such 
that the original syntax would always be false when i is an int 
expression, won't this version result in something that's always false 
even for out-of-range larger-than-int expressions?


- Brooks

Re: Char array alignment for PowerPc changed

[Andrew Pinski]

On Tue, 2007-01-16 at 20:04 -0800, Michael Eager wrote:
> But unaligned char arrays make strcpy much slower.

Actually it depends on the processor unless you are messed up by using
-mstrict-align which is a huge hammer for most (if not all) PowerPC
processors even though the few cases which need an unaligned exception
handler is small.

For an example of the Cell, all GP register access is optimal unless it
crosses a 32byte boundary and then it is microcoded into the next
smaller unit.  For double and float, the access only needs word aligned
to be optimal but otherwise it calls an unaligned exception handler.  I
forget how the string instructions are done but I think those are
microcoded also, likewise with the multiple stores/loads.

Most if not all PowerPC are this way, I think even the ISA requires this
(except if instead of going access a 32byte boundary, it is a different
boundary (the page boundary) and that would then call the unaligned
exception handler and that is rarer).

Who really need to start getting the PS3 game OS to do an unaligned
exception handler that works instead of hanging.

Thanks,
Andrew Pinski

Re: Preventing warnings

[Ian Lance Taylor]

Richard Stallman <[EMAIL PROTECTED]> writes:

> In Emacs we have a macro that tends to produce the warning
> 
>comparison is always false due to limited range of data type
> 
> when compiling for 64-bit machines.  EMACS_INT is 64 bits
> in that case.  Here is the macro:
> 
> #define FIXNUM_OVERFLOW_P(i) \
>   ((EMACS_INT)(i) > MOST_POSITIVE_FIXNUM \
>|| (EMACS_INT) (i) < MOST_NEGATIVE_FIXNUM)
> 
> When this macro is used on an expression that has type int, it
> produces those warnings, and there is no way to change the macro to
> prevent the warnings.  We used the workaround of copying the
> expression into an EMACS_INT in a previous statement, but that is
> cumbersome and ugly.

gcc has issued this warning for quite a while.  It has been around at
least since this change:

Sun Apr 17 01:21:35 1988  Richard Stallman  (rms at frosted-flakes.ai.mit.edu)

* typecheck.c (shorten_compare): Warn about constant result only in
cases like (char)x < 0x80, where old C compilers made it -0x80.

I'm not sure whether anything has changed in this area to cause the
warnings to appear more frequently today.


> Is there a way to write the macro so as to suppress this warning?

You can avoid it by using unsigned types.  I think that something like
this will do the trick:

#define FIXNUM_OVERFLOW_P(i)\
  ((unsigned long long)(i) > MOST_POSITIVE_FIXNUM   \
   && (unsigned long long)(i) < MOST_NEGATIVE_FIXNUM)

Ian

Re: Char array alignment for PowerPc changed

[Michael Eager]

Andrew Pinski wrote:

On Tue, 2007-01-16 at 20:04 -0800, Michael Eager wrote:

But unaligned char arrays make strcpy much slower.


Actually it depends on the processor unless you are messed up by using
-mstrict-align which is a huge hammer for most (if not all) PowerPC
processors even though the few cases which need an unaligned exception
handler is small.

For an example of the Cell, all GP register access is optimal unless it
crosses a 32byte boundary and then it is microcoded into the next
smaller unit.  For double and float, the access only needs word aligned
to be optimal but otherwise it calls an unaligned exception handler.  I
forget how the string instructions are done but I think those are
microcoded also, likewise with the multiple stores/loads.

Most if not all PowerPC are this way, I think even the ISA requires this
(except if instead of going access a 32byte boundary, it is a different
boundary (the page boundary) and that would then call the unaligned
exception handler and that is rarer).

Who really need to start getting the PS3 game OS to do an unaligned
exception handler that works instead of hanging.

Thanks,
Andrew Pinski


I have no idea how your reply is related to my question about the
change in alignment of char arrays between gcc-3.4 and gcc-4.1.

Strcpy is optimized to copy arrays which are aligned on word
boundaries by using word load/store.  Unaligned arrays are copied
byte by byte.  Runs slower.

I'm not using PS3 or Cell.  Or doubles or floats.  Unaligned
access exceptions are a non-issue.  There's no OS involved and
nothing hangs.

--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: Char array alignment for PowerPc changed

[Andrew Pinski]

> 
> Andrew Pinski wrote:
> I have no idea how your reply is related to my question about the
> change in alignment of char arrays between gcc-3.4 and gcc-4.1.

It was not really a rely to that part of the question but rather the
assertion in general that unaligned access was slower which is not true
for most PowerPC chips I know of.

> Strcpy is optimized to copy arrays which are aligned on word
> boundaries by using word load/store.  Unaligned arrays are copied
> byte by byte.  Runs slower.

Which strcpy?  Maybe the strcpy is written incorrectly for your
processor?  Can you name which PowerPC you are using?

The 74xx and 75x both are able to access unaligned words in a double
word boundary like an aligned access.  The 603/604 were both able
to handle unaligned word loads fast as aligned ones.

I still am trying to find a PowerPC were unaligned loads would cause
a major penality in general.

-- Pinski