Re: M32C vs PR tree-optimization/39233

[Richard Guenther]

On Wed, 15 Apr 2009, DJ Delorie wrote:

> > yes; however, maybe it would be easier to wait till Richard finishes the
> > work on not representing the overflow semantics in types (assuming that's
> > going to happen say in a few weeks?), which should make the fix
> > unnecessary,
> 
> Another thought - is this bug in the 4.4 branch?  If so, a 4.4 fix may
> be needed too.

Note that the issue is with our representation of POINTER_PLUS_EXPR
which insists on using sizetype for the pointer offset argument
(where I don't remember if m32c uses a bigger or smaller mode for
sizetype than for pointers).  Whenever the sizes of the modes for
pointers and sizetype do not match we have a problem.

Note that while this particular issue may likely be fixed with
the no-undefined-overflow branch work the above much general issue
is _not_ fixed by it.

Richard.

Re: M32C vs PR tree-optimization/39233

[Paolo Bonzini]

> Note that the issue is with our representation of POINTER_PLUS_EXPR
> which insists on using sizetype for the pointer offset argument
> (where I don't remember if m32c uses a bigger or smaller mode for
> sizetype than for pointers).  Whenever the sizes of the modes for
> pointers and sizetype do not match we have a problem.
> 
> Note that while this particular issue may likely be fixed with
> the no-undefined-overflow branch work the above much general issue
> is _not_ fixed by it.

What about forbidding pointer induction variables completely if the
modes for sizetype and pointers do not match?

Paolo

Re: M32C vs PR tree-optimization/39233

[Richard Guenther]

On Wed, 15 Apr 2009, DJ Delorie wrote:

> 
> As of this fix (yes, I know it was some time ago - I've been busy),
> the m32c-elf build fails building the target libiberty:
> 
> ./cc1 -fpreprocessed regex.i -quiet -dumpbase regex.c -mcpu=m32cm \
> -auxbase-strip regex.o -g -O2 -W -Wall -Wwrite-strings -Wc++-compat \
> -Wstrict-prototypes -pedantic -version -o regex.s
> 
> 
> In file included from ../../../../gcc/libiberty/regex.c:639:
> ../../../../gcc/libiberty/regex.c: In function 'byte_re_match_2_internal':
> ../../../../gcc/libiberty/regex.c:7481: internal compiler error: in 
> gen_add2_insn, at optabs.c:4733
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> cc1.r144405.20090224-060515 - failed
> 
> The problem is, you *can't* treat pointers and integers the same on
> m32c, as there is no integral type (16-bit? 32?) the same size as a
> pointer (24 bits).  Pointer math and pointer compatisons need to be
> done with pointer types.
> 
> [ gdb ] where
> #0  fancy_abort (file=0x87e22a8 "../../gcc/gcc/optabs.c", line=4746, 
> function=0x87e28c9 "gen_add2_insn") at ../../gcc/gcc/diagnostic.c:724
> #1  0x0837ddc5 in gen_add2_insn (x=0xb7993bb0, y=0xb7993b80) at 
> ../../gcc/gcc/optabs.c:4745
> #2  0x083f9df7 in gen_reload (out=0xb7993bb0, in=0xb7d086a8, opnum=0, 
> type=RELOAD_FOR_INPUT)
> at ../../gcc/gcc/reload1.c:8248
> #3  0x083fa959 in emit_input_reload_insns () at ../../gcc/gcc/reload1.c:7217
> #4  do_input_reload (chain=, rl=0x8896fcc, j=1)
> at ../../gcc/gcc/reload1.c:7511
> #5  0x083ff278 in emit_reload_insns () at ../../gcc/gcc/reload1.c:7702
> #6  reload_as_needed (live_known=1) at ../../gcc/gcc/reload1.c:4217
> #7  0x084040f9 in reload (first=0xb7c8cd80, global=1) at 
> ../../gcc/gcc/reload1.c:1169
> #8  0x0832f799 in ira (f=) at ../../gcc/gcc/ira.c:3239
> #9  0x08331b50 in rest_of_handle_ira () at ../../gcc/gcc/ira.c:3309
> #10 0x08396aed in execute_one_pass (pass=0x884a200) at 
> ../../gcc/gcc/passes.c:1290
> #11 0x08396d5c in execute_pass_list (pass=0x884a200) at 
> ../../gcc/gcc/passes.c:1339
> #12 0x08396d6f in execute_pass_list (pass=0x886bce0) at 
> ../../gcc/gcc/passes.c:1340
> #13 0x084aca80 in tree_rest_of_compilation (fndecl=0xb7fb5400) at 
> ../../gcc/gcc/tree-optimize.c:437
> #14 0x0860d3e2 in cgraph_expand_function (node=0xb7e84680) at 
> ../../gcc/gcc/cgraphunit.c:1048
> #15 0x0860f23f in cgraph_expand_all_functions () at 
> ../../gcc/gcc/cgraphunit.c:1107
> #16 cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1312
> #17 0x080a5c0b in c_write_global_declarations () at 
> ../../gcc/gcc/c-decl.c:8174
> #18 0x0845817b in compile_file () at ../../gcc/gcc/toplev.c:989
> #19 do_compile () at ../../gcc/gcc/toplev.c:2243
> #20 toplev_main (argc=20, argv=0xb974) at ../../gcc/gcc/toplev.c:2278
> #21 0x081266e2 in main (argc=Cannot access memory at address 0x23
> ) at ../../gcc/gcc/main.c:35
> 
> [ gdb ] call debug_reload(rl)
> Reload 0: reload_in (HI) = (reg:HI 377 [ D.9641 ])
> A_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 0)
> reload_in_reg: (reg:HI 377 [ D.9641 ])
> reload_reg_rtx: (reg:HI 4 a0)
> Reload 1: reload_in (PSI) = (plus:PSI (reg:HI 377 [ D.9641 ])
> (const_int 4 [0x4]))
> A_REGS, RELOAD_FOR_INPUT (opnum = 0), inc by 4
> reload_in_reg: (plus:PSI (reg:HI 377 [ D.9641 ])
> (const_int 4 [0x4]))
> reload_reg_rtx: (reg:PSI 4 a0)
> Reload 2: reload_in (PSI) = (mem/f:PSI (reg/f:PSI 5 a1 [995]) [7 S4 A8])
> A_HI_MEM_REGS, RELOAD_FOR_INPUT (opnum = 1), optional
> reload_in_reg: (mem/f:PSI (reg/f:PSI 5 a1 [995]) [7 S4 A8])
> 
> 
> Note "(plus:PSI (reg:HI) (const_int))" - the mode conflict between PSI
> and HI causes problems.
> 
> Can we somehow make this fix contingent on ports that have suitable
> integral modes?

I'm not sure if this is the same problem, but didn't I suggest in
the past to fix this up during expansion?  That is, if we end up
with a POINTER_PLUS_EXPR with different mode size pointer and offset
promote (or demote) the offset argument to pointer size properly?

What happened to these patch snippets I sent you?  Would they fix
this issue?

Thanks,
Richard.

Snapshots of PPL 0.10.2 available for testing

[Roberto Bagnara]

All the problems of PPL 0.10.1 we are aware of have been
fixed in the snapshot of PPL 0.10.2 available at

ftp://ftp.cs.unipr.it/pub/ppl/snapshots/

In particular here is what has changed:

- Correctly detect GMP 4.3.0.

- Fixed the C interface library version information.

- Test program tests/Polyhedron/memory1 disabled on the zSeries s390x
  platform.

- Makefiles fixed so as to avoid failure of `make -n check'.

If no further issues are reported, that snapshot will be
relabeled PPL 0.10.2 and released on Saturday, April 18, 2009.
Thanks to all who provided feedback.
All the best,

Roberto

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

Re: Snapshots of PPL 0.10.2 available for testing

[Richard Guenther]

On Thu, Apr 16, 2009 at 2:08 PM, Roberto Bagnara  wrote:
>
> All the problems of PPL 0.10.1 we are aware of have been
> fixed in the snapshot of PPL 0.10.2 available at
>
>    ftp://ftp.cs.unipr.it/pub/ppl/snapshots/
>
> In particular here is what has changed:
>
> - Correctly detect GMP 4.3.0.
>
> - Fixed the C interface library version information.
>
> - Test program tests/Polyhedron/memory1 disabled on the zSeries s390x
>  platform.

Huh.  It looks like the test only randomly fails.  Thus I didn't notice
that the preprocessor define is __s390x__ instead of __s390x.

Otherwise it works all fine now.

Thanks,
Richard.

Re: M32C vs PR tree-optimization/39233

[DJ Delorie]

> I'm not sure if this is the same problem, but didn't I suggest in
> the past to fix this up during expansion?  That is, if we end up
> with a POINTER_PLUS_EXPR with different mode size pointer and offset
> promote (or demote) the offset argument to pointer size properly?
> 
> What happened to these patch snippets I sent you?  Would they fix
> this issue?

I don't remember every patch you sent, but I"ve been careful to test
everything you've offered and reported it's effects.  If you can
recall which patch it was, I'll test it again.

I suspect that promoting a short to a pointer won't work right anyway,
as it means that pointers will always have the upper 8 bits masked
off.  The root of the problem is using HImode integers to store
PSImode pointers.

Diagnostic Messaging Suggestion

[Arthur Schwarz]

Suggested Messaging: Messaging seems redundant in indicating that function has 
been redifined twice. One of the messages should be removed. More to the point, 
I think the messaging may be erroneous - code fragment follows.


g++-4 Diagnostic Messaging

In file included from partition.cpp:66:
irange.h: In function 'std::ostream& operator<<(std::ostream&, 
ciRange_2::sRange_2&)':
irange.h:102: error: redefinition of 'std::ostream& operator<<(std::ostream&, 
ciRange_2::sRange_2&)'
irange.h:102: error: 'std::ostream& operator<<(std::ostream&, 
ciRange_2::sRange_2&)' previously defined here


 Code Fragment 
class ciRange_2 : public iRange_List {   // 
public:
struct sRange_2 { double RLo;// Low  range value
  double RHi; }; // High range value

friend istream& operator>>(istream& stream, ciRange_2::sRange_2& Range);
friend ostream& operator<<(ostream& stream, ciRange_2::sRange_2& Range);
}; // class ciRange_2

istream& operator>>(istream& stream, ciRange_2::sRange_2& Range);

ostream& operator<<(ostream& stream, ciRange_2::sRange_2& Range) {
   stream << setw(9) << Range.RLo << " " << setw(9) << Range.RHi;
}

Re: Diagnostic Messaging Suggestion

[James Dennett]

On Thu, Apr 16, 2009 at 12:06 PM, Arthur Schwarz
 wrote:
>
>
>
> Suggested Messaging: Messaging seems redundant in indicating that function 
> has been redifined twice. One of the messages should be removed. More to the 
> point, I think the messaging may be erroneous - code fragment follows.
>
>
> g++-4 Diagnostic Messaging
>
> In file included from partition.cpp:66:
> irange.h: In function 'std::ostream& operator<<(std::ostream&, 
> ciRange_2::sRange_2&)':
> irange.h:102: error: redefinition of 'std::ostream& operator<<(std::ostream&, 
> ciRange_2::sRange_2&)'
> irange.h:102: error: 'std::ostream& operator<<(std::ostream&, 
> ciRange_2::sRange_2&)' previously defined here
>
>
>  Code Fragment 
> class ciRange_2 : public iRange_List {           // 
> public:
>    struct sRange_2 { double RLo;                // Low  range value
>                      double RHi; };             // High range value
>
>    friend istream& operator>>(istream& stream, ciRange_2::sRange_2& Range);
>    friend ostream& operator<<(ostream& stream, ciRange_2::sRange_2& Range);
> }; // class ciRange_2
>
> istream& operator>>(istream& stream, ciRange_2::sRange_2& Range);
>
> ostream& operator<<(ostream& stream, ciRange_2::sRange_2& Range) {
>   stream << setw(9) << Range.RLo << " " << setw(9) << Range.RHi;
> }

Can you show code that reproduces the issue?  My best guess is that a
header file is included twice, and lacks guards, hence the message is
correct: the function is being defined twice, from the same source
location.

-- James

Re: Diagnostic Messaging Suggestion

[Arthur Schwarz]

> 
> Can you show code that reproduces the issue?  My best
> guess is that a
> header file is included twice, and lacks guards, hence the
> message is
> correct: the function is being defined twice, from the same
> source
> location.
> 
> -- James
> 

 Code (unadulterated and full of original lacerations) -

/* 
 * File:   irange.h
 * Author: Arthur Schwarz
 *
 * Created on April 13, 2009, 1:23 PM
 */

#ifndef _IRANGE_H
#define _IRANGE_H
# include 
# include 
# include 
# include 
# include 
# include 
# include "common.h"

class iRange_List : public cDebug{   // input ranges
private:
// Processing of range buffer: 
//  Ranges[Ndx] : Ndx<0..BufferSize-1>
//  if (Ndx == BufferSize) TempStream.write(Ranges[Ndx]; Size += 
BufferSize; Ndx = 0;
fstream TempStream;  // Temporary Stream
static
long const  BufferSize;  // Input buffer size
longNdx; // Index in Ranges buffer
longSize;// Total number ranges used
cRange  ErrorRange;
protected:
cRange* Ranges;  // All input ranges
longErrorCount;  // Number of errors found
protected:
//double Atod(string& Range, long id);
virtual
void DData () { string str(80, ' ');
ostringstream stream(str);
stream << "iRange_List<"
   << setw(9) << Ndx  << ", "
   << setw(9) << Size << ", "
   << setw(9) << ErrorCount << ">" << endl;
cDebug::DData(str);
};
long Next() { if ( ++Ndx < BufferSize) return Ndx;
  TempStream.write((char*)Ranges, sizeof(Ranges));
  Size += BufferSize;
  return (Ndx = 0);
};
void Flush();
public:
iRange_List();
iRange_List(const iRange_List& orig);
virtual ~iRange_List();

long GetSize()  { return Size; }
void PrintRange() { for(long i = 0; i < Ndx; i++) Stdout << setw(9) << i << 
": "
  << Ranges[i]
  << endl;
}; // PrintRange()
virtual
bool Read() = 0;
cRange& operator[](long Ndx) { return ((Ndx >=0 ) && (Ndx < Size))? 
Ranges[Ndx]: ErrorRange; }
}; // class iRange_List

class ciRange_2 : public iRange_List {   // 
public:
struct sRange_2 { double RLo;// Low  range value
  double RHi; }; // High range value

ciRange_2() : iRange_List() { }
virtual
bool Read();
friend istream& operator>>(istream& stream, ciRange_2::sRange_2& Range);
friend ostream& operator<<(ostream& stream, ciRange_2::sRange_2& Range);
}; // class ciRange_2

class ciRange_3 : public iRange_List {   // 
public:
struct sRange_3 { double  RLo;   // Low  range value
  double  RHi;   // High range value
  longDatum; };  // User supplied datum
ciRange_3() : iRange_List() { }
virtual
bool Read();
friend istream& operator>>(istream& stream, sRange_3& Range);
friend ostream& operator<<(ostream& stream, ciRange_3::sRange_3& Range);
}; // class ciRange_3

#endif  /* _IRANGE_H */


//
//Debug Streams
//

istream& operator>>(istream& stream, ciRange_2::sRange_2& Range);
istream& operator>>(istream& stream, ciRange_3::sRange_3& Range);

ostream& operator<<(ostream& stream, ciRange_2::sRange_2& Range) {
   stream << setw(9) << Range.RLo << " " << setw(9) << Range.RHi;
}

ostream& operator<<(ostream& stream, ciRange_3::sRange_3& Range) {
   stream << setw(9) << Range.RLo << " " << setw(9) << Range.RHi << " " << 
setw(9) << Range.Datum;
}

Re: Diagnostic Messaging Suggestion

[Arthur Schwarz]

I forgot to say 'thanks James', thanks.

Well, spurred on by the whimsy that I need a solution to the problem (however 
dolorous), I experimented. I've commented most everything at least once and the 
net effect is that only the 'operator<<' gets a nasty message. I've checked the 
include files that I've written and they all seem clean of heresies. The 
'operator>>' files are unaffected, and with them gone, I still get an error on 
the 'operator<<' function.

The only thing that I can think of, and I think it remote, is that the 
functions refer to a public structure internal to a class. The 'operator>>' 
functions refer to their respective classes. Again, I've removed all of my 
friends but one 'operator<<' and this gets the error.

Now I think I know C++ (although, to be honest, I have strong, personal, 
doubts) and I can't think what I missed.

However, the initial statement still holds, the second diagnostic messages adds 
no clarity and seems redundant. Further, if there was a cause of conflict with 
a redefinition, it would be useful to include the original conflicting 
declaration. Perhaps something like:

<>: error: redefinition of function at <> illegal.
 note: istream& operator>> (bool& val );
   istream& operator>> (short& val );
o o o

the note: stuff is from cplusplus.com @ 
 http://cplusplus.com/reference/iostream/istream/operator%3E%3E/

So, a concrete suggestion at to messaging and an individual first, a puzzler. I 
really need help on the puzzler.

thanks
art

Re: Diagnostic Messaging Suggestion

[Arthur Schwarz]

Thanks to everyone. 

The rock has dropped. The answer is quoted below:

"My best guess is that a header file is included twice, and lacks guards, hence 
the message is correct: the function is being defined twice, from the same 
source location."

I had put my friends following my 'include guard'. As we all know, when your 
guard is down you can get sucker-punched.

Although you should never try to teach an old dog new tricks, with luck and a 
good tail wind this will never happen again.

thanks
art

PS: You are now all my best friend. Sorry.

gcc-4.5-20090416 is now available

[gccadmin]

Snapshot gcc-4.5-20090416 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20090416/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 146216

You'll find:

gcc-4.5-20090416.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.5-20090416.tar.bz2 C front end and core compiler

gcc-ada-4.5-20090416.tar.bz2  Ada front end and runtime

gcc-fortran-4.5-20090416.tar.bz2  Fortran front end and runtime

gcc-g++-4.5-20090416.tar.bz2  C++ front end and runtime

gcc-java-4.5-20090416.tar.bz2 Java front end and runtime

gcc-objc-4.5-20090416.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.5-20090416.tar.bz2The GCC testsuite

Diffs from 4.5-20090409 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.5
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: Diagnostic Messaging Suggestion

[Joe Buck]

On Thu, Apr 16, 2009 at 03:40:47PM -0700, Arthur Schwarz wrote:
> The rock has dropped. The answer is quoted below:
> 
> "My best guess is that a header file is included twice, and lacks guards, 
> hence the message is correct: the function is being defined twice, from the 
> same source location."

Yes, I've had to diagnose this one before; it doesn't happen with my
own code because I use include guards, but I've had to help others.

It would be cool if there were a way of distinguishing the case where
the same header is being processed twice.

We might see

foo.h:11 error: redefinition of `a'
foo.h:11 error: `a' previously defined here

but the first "foo.h:11" might represent the 2300'th line read by the
compiler, while the second "foo.h:11" might represent the 2194'th line.
If, for definitions, the compiler keeps track of this detail, it
would be possible to reliably print

foo.h:11 error: redefinition of `a' (file was included more than once)

if the printable line number is the same but the internal line number
is different.

Advantage of switch-case

[Shameem Ahamed]

Hi All,

Is there any advantage of using switch-case over if-else. I mean any internal 
optimizations, gcc can do on a Linux i386 machine?.

Is it saving any machine instructions for us ?.


Regards,
Shameem
_
So many new options, so little time. Windows Live Messenger.
http://www.microsoft.com/india/windows/windowslive/messenger.aspx

Re: The gcc-in-cxx branch now completes bootstrap

[Mark Mitchell]

Ian Lance Taylor wrote:

> My plan going forward is as follows (when we are back in stage 1):

FWIW, I think this is a great plan.

Thanks,

-- 
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713

Re: Advantage of switch-case

[Joe Buck]

On Thu, Apr 16, 2009 at 09:07:58PM -0700, Shameem Ahamed wrote:

> Is there any advantage of using switch-case over if-else. I mean any internal 
> optimizations, gcc can do on a Linux i386 machine?.

The optimizations in question are architecture-independent, though there
would undoubtedly be processor-specific weights.

Given a switch statement, gcc will generate either a balanced binary
tree or a jump table, depending on the number of branches and their
density.  It has some freedom to optimize this structure that it might
not have for an if-then-else structure.  But I think that the difference
is only going to be significant for a large switch (with many branches);
if there are few branches, the jump table won't be a win (so won't be
chosen), and the balanced tree would be about the same as what you would
write.

I would say that if a switch statement is a natural way to code something,
it would be wise to prefer it to if-then-else if there are four or more
branches (I admit I have no hard justification for the "four" here);
for fewer I'd make the decision based on clarity and maintainability.

Switch statements also give compilers more freedom to rearrange based on
profile-directed optimization.  There was a GCC Summit paper on improving
GCC's code generation for switch statements, see

http://ols.fedoraproject.org/GCC/Reprints-2006/wienskoski-reprint.pdf

I don't know how much of that work got into the compiler, probably
it isn't in the 4.2.x version we're using now.

Re: Advantage of switch-case

[Joe Buck]

On Thu, Apr 16, 2009 at 10:12:10PM -0700, Joe Buck wrote:
> I don't know how much of that work got into the compiler, probably
> it isn't in the 4.2.x version we're using now.

I should clarify that remark.  In production work right now I'm
not using the current gcc, and am not using profile-directed
optimization, so I can't say how well it works with respect to
switch statements.