Re: GCC 3.3.6 has been released

[Gerald Pfeifer]

On Sun, 29 May 2005, Brian Dessent wrote:
> I noticed that on  it
> states:
> 
> "A port of GCC 2.95.2 and 3.x is included with the Cygwin environment."
> 
> However, the Cygwin project had to remove its 2.95 gcc package due to
> brokenness (and lack of maintainer interest in resolving it) quite some
> time ago, so it's probably misleading to state that it's available.

Thanks for the hint (even if it took us some time to process it).

I just installed the following patch for GCC mainline which will cause
the web page to be updated within 24 hours.

  2005-06-26  Gerald Pfeifer  <[EMAIL PROTECTED]>

* doc/install.texi (Specific): Do not specify the concrete
versions of GCC provided by Cygwin.  Simplify the part on
building on Cygwin.

Once GCC 4.0.1 has been released, I plan to also commit the patch there.

Gerald

Index: doc/install.texi
===
RCS file: /cvs/gcc/gcc/gcc/doc/install.texi,v
retrieving revision 1.356
diff -u -3 -p -r1.356 install.texi
--- doc/install.texi6 Jun 2005 19:31:33 -   1.356
+++ doc/install.texi26 Jun 2005 13:37:32 -
@@ -3882,14 +3882,11 @@ respects, this target is the same as the
 @end html
 @heading @anchor{windows}Microsoft Windows (32-bit)
 
-A port of GCC 2.95.2 and 3.x is included with the
+Ports of GCC are included with the
 @uref{http://www.cygwin.com/,,Cygwin environment}.
 
-Current (as of early 2001) snapshots of GCC will build under Cygwin
-without modification.
-
-GCC does not currently build with Microsoft's C++ compiler and there
-are no plans to make it do so.
+GCC will build under Cygwin without modification; it does not build
+with Microsoft's C++ compiler and there are no plans to make it do so.
 
 @html
 

Confusing code in regrename.c

[Steven Bosscher]

Hi,

You added some code to regrename in revision 1.28 for which I don't
understand the need:

1.26  rth   1595:   /* For each earlyclobber operand, zap the 
value data.  */
1596:   for (i = 0; i < n_ops; i++)
1597:if (recog_op_alt[i][alt].earlyclobber)
1598:  kill_value (recog_data.operand[i], vd);
1599: 
1600:   /* Within asms, a clobber cannot overlap 
inputs or outputs.
1601: I wouldn't think this were true for 
regular insns, but
1602: scan_rtx treats them like that...  */
1603:   note_stores (PATTERN (insn), 
kill_clobbered_value, vd);
1604: 
1605:   /* Kill all auto-incremented values.  */
1606:   /* ??? REG_INC is useless, since stack 
pushes aren't done that way.  */
1607:   for_each_rtx (&PATTERN (insn), 
kill_autoinc_value, vd);
1.28  rth   1608: 
1609:   /* Kill all early-clobbered operands.  */
1610:   for (i = 0; i < n_ops; i++)
1611:if (recog_op_alt[i][alt].earlyclobber)
1612:  kill_value (recog_data.operand[i], vd);

The stuff added in 1.28 (lines 1608-1612) to kill early-clobbered
operands is precisely the same as what is done just a few lines
earlier (lines 1595-1598).  Is this a thinko or is this necessary for
some non-obvious reason??

Gr.
Steven

Re: cpp, CPLUS_INCLUDE_PATH, and g++: bug or feature?

[Gerald Pfeifer]

On Wed, 22 Jun 2005, Joe Buck wrote:
> The reason for this (making the g++ script compile .c files as C++) is
> historical; in the early days Stroustrup used the .c extension for C++ as
> well, apparently because he had ambitions of displacing C with C++, so
> in the early days that's what users expected.

Thanks for this piece of background information, Joe!  What bothered me 
most is the asymmetry between gcc compiling a .cc file as C++ (this I had 
expected) and g++ compiling a .c file as C++ (this I had not).

On Wed, 22 Jun 2005, Gabriel Dos Reis wrote:
> It must be a bug.  If it process them as a C++ files, it must compile
> them as C++.  Similarly, if gcc preprocess files as C files, one would
> expect it to compile it as C programs with appropriate semantics.

It seems I made a mistake in one of my original tests.  With current GCC 
head I'm no longer to reproduce this.

Gerald

Re: makeinfo 4.8 generates non-standard HTML for @[EMAIL PROTECTED]

[Gerald Pfeifer]

Hi Karl,

On Wed, 20 Apr 2005, Karl Berry wrote:
>   You should substitute `i686
>   ' in the above command with the appropriate processor 
>   for your host.
> Thanks for the report, I'll work on fixing that.

have you had a chance to look into this?  It's certainly not a top
priority issue and I don't want to pressure you, just came across
this again today.

Gerald

[Ada] Current patch needed to build Ada as of 20050626

[Laurent GUERBY]

After recent fixes, the only patch left to be
able to build Ada on mainline is for the wrapv problems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21959
(patch by Andreas Schwab). It works at least on x86 and x86_64-linux:

http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg01590.html
http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg01592.html

The Ada PR has a small test case in C showing the problem, by Andrew Pinski:

unsigned char c[0xFF];
void f(void)
{
  unsigned char i;
  c[128] = 128;
  i = 0;
  while (1)
  {
if (((signed char) i) < 0) break;
c[i] = ' ';
i++;
  }
}

If no one is looking at this, may be it's better to just commit the workaround 
patch?

Laurent

Index: misc.c
===
RCS file: /cvs/gcc/gcc/gcc/ada/misc.c,v
retrieving revision 1.103
diff -u -r1.103 misc.c
--- misc.c  16 Jun 2005 09:05:06 -  1.103
+++ misc.c  26 Jun 2005 20:30:01 -
@@ -339,6 +339,8 @@
   /* Uninitialized really means uninitialized in Ada.  */
   flag_zero_initialized_in_bss = 0;

+  flag_wrapv = 1;
+
   return CL_Ada;
 }

attributes and templates

[Nathan Sidwell]

Paulo,

I tried to get attributes and templates to play nice.  Even though conceptually
it's quite straight forward, our data representations and current instantiation
machinery pretty much make it very difficult.  It would be several days (maybe a
week or two) to get working :(

I'm fairly certain implementing __builtin_reflect (...) for the other bits of
type traits would be easier (though I've not tried).

nathan
-- 
Nathan Sidwell::   http://www.codesourcery.com   :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk

Re: attributes and templates

[Andrew Pinski]

On Jun 26, 2005, at 5:54 PM, Nathan Sidwell wrote:


Paulo,

I tried to get attributes and templates to play nice.  Even though 
conceptually
it's quite straight forward, our data representations and current 
instantiation
machinery pretty much make it very difficult.  It would be several 
days (maybe a

week or two) to get working :(


Isn't this PR 19163, PR 17743, and PR 19407?

Thanks,
Andrew Pinski

Re: [Ada] Current patch needed to build Ada as of 20050626

[Andrew Pinski]

On Jun 26, 2005, at 5:00 PM, Laurent GUERBY wrote:


After recent fixes, the only patch left to be
able to build Ada on mainline is for the wrapv problems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21959
(patch by Andreas Schwab). It works at least on x86 and x86_64-linux:

http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg01590.html
http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg01592.html

And powerpc-darwin:
http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg01334.html

-- Pinski

Re: Confusing code in regrename.c

[Richard Henderson]

On Sun, Jun 26, 2005 at 05:27:31PM +0200, Steven Bosscher wrote:
> The stuff added in 1.28 (lines 1608-1612) to kill early-clobbered
> operands is precisely the same as what is done just a few lines
> earlier (lines 1595-1598).  Is this a thinko or is this necessary for
> some non-obvious reason??

The only kink I can find is that kill_autoinc_value does set up a new value.
Which might mean that I should have moved the code block instead of copying
it; presumably I was blind at the time.  And rename kill_autoinc_value, since
it does more than kill.


r~

Do C++ signed types have modulo semantics?

[Michael Veksler]

According to the (very) long discussion on VRP, signed char/short/int/etc
do not have modulo semantic, they have an undefined behavior on overflow.
However in  defines numeric_limits::is_modulo = true.

1. Is that a bug in , a bug in the standard, or is just C++
different
   than C in this respect?
2. Maybe because overflow is undefined then is_modulo maybe
   considered "unspecified". I don't like this option, because it does not
help
   generic programming.
3. Do I understand what is_modulo stands for?
4. What should be done (libstdc++ PR, C++ PR, DR, other)?

I have seen this in gcc-4.0-20050602, and gcc-3.4.3



  Michael