[Bug target/35073] illegal opcode movw for mcu avr3

[eric dot weddington at atmel dot com]

--- Comment #8 from eric dot weddington at atmel dot com  2008-03-09 05:43 
---
*** Bug 35506 has been marked as a duplicate of this bug. ***


-- 

eric dot weddington at atmel dot com changed:

   What|Removed |Added

 CC||dmixm at marine dot febras
   ||dot ru


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

[Bug target/35506] [avr] 4.3.0 buid error: illegal opcode movw for mcu avr3

[eric dot weddington at atmel dot com]

--- Comment #2 from eric dot weddington at atmel dot com  2008-03-09 05:43 
---


*** This bug has been marked as a duplicate of 35073 ***


-- 

eric dot weddington at atmel dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug testsuite/35350] FAIL: gcc.target/i386/isa-10.c execution test

[hjl dot tools at gmail dot com]

--- Comment #9 from hjl dot tools at gmail dot com  2008-03-09 04:59 ---
Fixed.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Component|c++ |testsuite
  GCC build triplet|gcc version 4.4.0 20080224  |
   |(experimental) (GCC |
 Resolution||FIXED


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

[Bug testsuite/35512] [4.4 Regression]: gcc.target/ia64/visibility-1.c

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-03-09 04:58 ---
>FAIL: gcc.target/ia64/visibility-1.c scan-assembler gprel.*variable_i

If you look at the testcase, you will notice that variable_i is only read from
and never written to so the variable becomes a readonly variable via
ipa-reference and then Store CCP inlines the value so it is no longer
referenced and we don't need to emit it.

So the testcase was never written correctly :).


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|target  |testsuite
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-03-09 04:58:04
   date||


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

[Bug target/35512] New: [4.4 Regression]: gcc.target/ia64/visibility-1.c

[hjl dot tools at gmail dot com]

Revision 133014 gives

FAIL: gcc.target/ia64/visibility-1.c scan-assembler gprel.*variable_i

Revision 132852 is OK.


-- 
   Summary: [4.4 Regression]: gcc.target/ia64/visibility-1.c
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug target/35507] [avr] 4.3.0: size of small funcion increases from 2 to 29 words

[hutchinsonandy at aim dot com]

--- Comment #1 from hutchinsonandy at aim dot com  2008-03-09 04:35 ---
I can confirms this regression.

There appears to be something strange in commutation of operands before RTL is
created which may well explain why it used to work.

BThe  default expander are creating calls to commutative functions that have
the opposite argument order from normal function parameters. Functionally this
does not matter, but it twists up the data flow.

The argument order presented by the RTL is backwards from the ideal. This
happens with both target AVR expander and the default expander (the original PR
was using a default expander). Clearly this is avoidable.

It is not a function of the original code - gcc is purposely ordering the
operands. Regardless of operand ordering (x*y or y*x), the RTL is always
backwards. 


The other factor is the lack of forward propagation in the RTL stages. If this
was effective, RTL ordering would not matter. The limited propagation that is
present avoids hard registers - so never connects the arguments with the
library function. Also combine can't exploit the commutation of the operands.


-- 


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

[Bug c++/35350] FAIL: gcc.target/i386/isa-10.c execution test

[hjl at gcc dot gnu dot org]

--- Comment #8 from hjl at gcc dot gnu dot org  2008-03-08 22:37 ---
Subject: Bug 35350

Author: hjl
Date: Sat Mar  8 22:37:07 2008
New Revision: 133045

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133045
Log:
2008-03-08  H.J. Lu  <[EMAIL PROTECTED]>

PR target/35350
* gcc.target/i386/isa-1.c: Add -march=x86-64.
* gcc.target/i386/isa-2.c: Likewise.
* gcc.target/i386/isa-3.c: Likewise.
* gcc.target/i386/isa-10.c: Likewise.
* gcc.target/i386/isa-11.c: Likewise.
* gcc.target/i386/isa-12.c: Likewise.
* gcc.target/i386/isa-13.c: Likewise.
* gcc.target/i386/isa-14.c: Likewise.

Modified:
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/isa-1.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/isa-10.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/isa-11.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/isa-12.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/isa-13.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/isa-14.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/isa-2.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/isa-3.c


-- 


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

[Bug c++/35350] FAIL: gcc.target/i386/isa-10.c execution test

[hjl at gcc dot gnu dot org]

--- Comment #7 from hjl at gcc dot gnu dot org  2008-03-08 22:34 ---
Subject: Bug 35350

Author: hjl
Date: Sat Mar  8 22:33:54 2008
New Revision: 133044

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133044
Log:
2008-03-08  H.J. Lu  <[EMAIL PROTECTED]>

PR target/35350
* gcc.target/i386/isa-1.c: Add -march=x86-64.
* gcc.target/i386/isa-2.c: Likewise.
* gcc.target/i386/isa-3.c: Likewise.
* gcc.target/i386/isa-10.c: Likewise.
* gcc.target/i386/isa-11.c: Likewise.
* gcc.target/i386/isa-12.c: Likewise.
* gcc.target/i386/isa-13.c: Likewise.
* gcc.target/i386/isa-14.c: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/isa-1.c
trunk/gcc/testsuite/gcc.target/i386/isa-10.c
trunk/gcc/testsuite/gcc.target/i386/isa-11.c
trunk/gcc/testsuite/gcc.target/i386/isa-12.c
trunk/gcc/testsuite/gcc.target/i386/isa-13.c
trunk/gcc/testsuite/gcc.target/i386/isa-14.c
trunk/gcc/testsuite/gcc.target/i386/isa-2.c
trunk/gcc/testsuite/gcc.target/i386/isa-3.c


-- 


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

[Bug target/35496] [4.4 Regression] test failures between revs. 132950 and 132974

[dominiq at lps dot ens dot fr]

--- Comment #7 from dominiq at lps dot ens dot fr  2008-03-08 22:31 ---
Subject: Re:  [4.4 Regression] test failures between revs.
 132950 and 132974

> Can you try this patch?

For the record, the right patch works on intel-apple-darwin9


-- 


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

[Bug c++/35469] [4.3/4.4 Regression] Rejects JArray

[rguenther at suse dot de]

--- Comment #4 from rguenther at suse dot de  2008-03-08 21:17 ---
Subject: Re:  [4.3/4.4 Regression] Rejects JArray

On Sat, 8 Mar 2008, jakub at gcc dot gnu dot org wrote:

> --- Comment #3 from jakub at gcc dot gnu dot org  2008-03-08 20:55 ---
> jboolean is lost in convert_template_argument:
>   /* We only form one instance of each template specialization.
>  Therefore, if we use a non-canonical variant (i.e., a
>  typedef), any future messages referring to the type will use
>  the typedef, which is confusing if those future uses do not
>  themselves also use the typedef.  */
>   if (TYPE_P (val))
> val = canonical_type_variant (val);
> As jboolean is now everywhere but on ppc-darwin a variant of bool, and only 
> the
> former has TYPE_FOR_JAVA set, we have this error.
> Caused by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131840
> I guess the easiest fix is just make jboolean make_unsigned_type (1) on all
> targets, not just on ppc-darwin.

This will cause wrong code generation for

  jboolean i = 1;
  i += 2;

Richard.


-- 


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

[Bug rtl-optimization/33642] unrecognizable insn for -frtl-abstract-sequences

[dje at gcc dot gnu dot org]

--- Comment #8 from dje at gcc dot gnu dot org  2008-03-08 21:03 ---
Sorry, the range is r132891 to r132965.  So this is likely due to Loko's patch.


-- 

dje at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|zadeck at naturalbridge dot |loki at gcc dot gnu dot org
   |com |


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

[Bug c++/35469] [4.3/4.4 Regression] Rejects JArray

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2008-03-08 20:55 ---
jboolean is lost in convert_template_argument:
  /* We only form one instance of each template specialization.
 Therefore, if we use a non-canonical variant (i.e., a
 typedef), any future messages referring to the type will use
 the typedef, which is confusing if those future uses do not
 themselves also use the typedef.  */
  if (TYPE_P (val))
val = canonical_type_variant (val);
As jboolean is now everywhere but on ppc-darwin a variant of bool, and only the
former has TYPE_FOR_JAVA set, we have this error.
Caused by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131840
I guess the easiest fix is just make jboolean make_unsigned_type (1) on all
targets, not just on ppc-darwin.


-- 


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

[Bug tree-optimization/35493] [4.4 Regression] Assert_Failure uintp.adb:1593

[laurent at guerby dot net]

--- Comment #7 from laurent at guerby dot net  2008-03-08 20:45 ---
For reference H. J. Lu proposed patch (for C++):

http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00466.html


-- 


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

[Bug fortran/35474] [4.3/4.4 regression] Reading module file with COMMON and EQUIVALENCE

[pault at gcc dot gnu dot org]

--- Comment #4 from pault at gcc dot gnu dot org  2008-03-08 20:34 ---
(In reply to comment #3)
> (In reply to comment #2)

> Oddly, reverting my patch for 32103 by hand does not get rid of the fault:) I
> am beginning to think that we need fixups for the common block references to
> the symbols... Anyway, I'll make a start on it.
> 

That turns out to be spot on.  The patch below is going on to regtest in just a
moment.

Paul

Index: gcc/fortran/module.c
===
*** gcc/fortran/module.c(revision 132798)
--- gcc/fortran/module.c(working copy)
*** mio_symtree_ref (gfc_symtree **stp)
*** 2310,2315 
--- 2310,2321 
  p->u.rsym.symtree->n.sym = p->u.rsym.sym;
  p->u.rsym.symtree->n.sym->refs++;
  p->u.rsym.referenced = 1;
+
+ /* If the symbol is PRIVATE and in COMMON, load_commons will
+generate a fixup symbol, which must be associated.  */
+ if (p->fixup)
+   resolve_fixups (p->fixup, p->u.rsym.sym);
+ p->fixup = NULL;
}

if (p->type == P_UNKNOWN)


-- 


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

[Bug fortran/34199] segfault for TRANSFER integer to TYPE(C_PTR)

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||03/msg00546.html
   Target Milestone|--- |4.4.0


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

[Bug target/35496] [4.4 Regression] test failures between revs. 132950 and 132974

[ubizjak at gmail dot com]

--- Comment #6 from ubizjak at gmail dot com  2008-03-08 18:31 ---
Segfault is here due to unaligned access:

...
movdqa  .LC1, %xmm0
movdqa  .LC2, %xmm2
...


.align 8
.LC1:
.long   2147483647
.long   0
.long   -2147483647
.long   0
.align 8
.LC2:
.long   4
.long   0
.long   4
.long   0


-- 


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

[Bug fortran/34956] -fbounds-check: bounds_check_9.f90: Use of uninitialized memory

[fxcoudert at gcc dot gnu dot org]

--- Comment #4 from fxcoudert at gcc dot gnu dot org  2008-03-08 18:24 
---
Fixed on mainline.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.4.0


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

[Bug fortran/34956] -fbounds-check: bounds_check_9.f90: Use of uninitialized memory

[fxcoudert at gcc dot gnu dot org]

--- Comment #3 from fxcoudert at gcc dot gnu dot org  2008-03-08 18:23 
---
Subject: Bug 34956

Author: fxcoudert
Date: Sat Mar  8 18:22:31 2008
New Revision: 133037

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133037
Log:
PR fortran/34956
* trans-array.c (gfc_conv_ss_startstride): Fix the logic to avoid
checking bounds of absent optional arguments.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c


-- 


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

[Bug target/35496] [4.4 Regression] test failures between revs. 132950 and 132974

[ubizjak at gmail dot com]

--- Comment #5 from ubizjak at gmail dot com  2008-03-08 18:18 ---
(In reply to comment #3)
> Created an attachment (id=15283)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15283&action=view) [edit]
> A real patch
> 
> Correct patch.

> -ADJUST_ALIGNMENT (DI, (TARGET_64BIT || TARGET_ALIGN_DOUBLE) ? 8 : 4);
> +ADJUST_ALIGNMENT (DI, (TARGET_64BIT
> +|| TARGET_MACHO
> +|| TARGET_ALIGN_DOUBLE) ? 8 : 4);

This failure is not darwin specific, so the fix is wrong. Please see Comment
#4.


-- 


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

[Bug target/35496] [4.4 Regression] test failures between revs. 132950 and 132974

[ubizjak at gmail dot com]

--- Comment #4 from ubizjak at gmail dot com  2008-03-08 18:16 ---
(In reply to comment #0)

> FAIL: gfortran.dg/array_constructor_12.f90  -O3 -fomit-frame-pointer  
> execution
> test
> FAIL: gfortran.dg/array_constructor_12.f90  -O3 -fomit-frame-pointer
> -funroll-loops  execution test
> FAIL: gfortran.dg/array_constructor_12.f90  -O3 -fomit-frame-pointer
> -funroll-all-loops -finline-functions  execution test
> FAIL: gfortran.dg/array_constructor_12.f90  -O3 -g  execution test
> 
> The failures of gfortran.dg/array_constructor_12.f90 result from a 
> segmentation
> fault. All failures disappear with -m64. Between the two builds I have 
> replaced
> the first patch (comment #3) for PR33642 by the second one (comment #4).

This is vectorizer in action. Note that -msse2 is the default for
i686-apple-darwin, and the testcase indeed fails with -O2 -msse2
-ftree-vectorize on linux too.

It looks like wrong assumption for DImode alignment in the vectorizer to me.

Confirmed on linux using "-O2 -msse2 -ftree-vectorize".


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-03-08 18:16:11
   date||


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

[Bug target/35496] [4.4 Regression] test failures between revs. 132950 and 132974

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2008-03-08 17:41 ---
Created an attachment (id=15283)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15283&action=view)
A real patch

Correct patch.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

  Attachment #15282|0   |1
is obsolete||


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

[Bug target/35496] [4.4 Regression] test failures between revs. 132950 and 132974

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2008-03-08 17:39 ---
Created an attachment (id=15282)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15282&action=view)
A patch

Can you try this patch?


-- 


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

[Bug rtl-optimization/33642] unrecognizable insn for -frtl-abstract-sequences

[dje at gcc dot gnu dot org]

--- Comment #7 from dje at gcc dot gnu dot org  2008-03-08 17:14 ---
The failure was introduced between r132949 and r132965.  The two mainline
patches during that time were Richi's alias change and Kenny's dataflow change.
 Given the RTL failure, it more likely is caused by the dataflow patch.


-- 

dje at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dje at gcc dot gnu dot org


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

[Bug target/35496] [4.4 Regression] test failures between revs. 132950 and 132974

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2008-03-08 17:10 ---
The failures disappear if I revert revision 132966:

2008-03-05  H.J. Lu  <[EMAIL PROTECTED]>

* config/i386/i386-modes.def: Use 4 byte alignment on DI for
32bit host.


-- 


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

[Bug middle-end/35509] [4.3/4.4 Regression] builtin isinf() mismatch to compile-time substitution

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2008-03-08 15:55 ---
I don't think this is even a QOI bug.  The values are defined by the C99
standard.  If the person used -std=c89, then he would get what the target's
libc defines them.  The inconstaint value is ok at different optimization level
too because only non-zero and zero are defined as return values.


-- 


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

[Bug target/35373] [4.4 Regression] bootstraping on powerpc with 128bit long double fails with revision 132578

[pinskia at gcc dot gnu dot org]

--- Comment #14 from pinskia at gcc dot gnu dot org  2008-03-08 15:51 
---
*** Bug 35510 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||schwab at suse dot de


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

[Bug target/35510] [4.4 regression] ICE in memory_address

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-03-08 15:51 ---


*** This bug has been marked as a duplicate of 35373 ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug middle-end/35509] [4.3/4.4 Regression] builtin isinf() mismatch to compile-time substitution

[ubizjak at gmail dot com]

--- Comment #4 from ubizjak at gmail dot com  2008-03-08 15:51 ---
(In reply to comment #2)

> (Only i386 and s390 have target dependent expansions for isinf - what is
> their behavior here?)
> 
> Kaveh, you introduced the generic fallback, Andreas, what does s390 return
> here, Uros, how is the situation on i386?

When compiled on 32bit target with -std=c99, testcase aborts. For !c99, library
call is emitted and the test passes OK.


-- 


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

[Bug middle-end/35509] [4.3/4.4 Regression] builtin isinf() mismatch to compile-time substitution

[ghazi at gcc dot gnu dot org]

--- Comment #3 from ghazi at gcc dot gnu dot org  2008-03-08 15:45 ---
(In reply to comment #2)
> Note that one might argue that the testcase is invalid as as you say, C99 only
> says isinf returns non-zero.  So strictly speaking comparing the return value
> of two invocations is not a way to check if both values are an infinity.
> Of course this is at least an QOI issue.  The question is what behavior to
> retain?  The glibc manpage documents returning -1 for -Inf and +1 for +Inf,
> which we could preserve on glibc targets then not expanding via
> isgreater(fabs(x),DBL_MAX).

When I wrote this, I was relying on the minimal C99 requirements, and Rth's
blessing here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30652#c2

One of my goals in writing these builtins was that GCC could always rely on the
inline expansion, perhaps allowing libc implementors to just define isinf into
the builtin.  I'd like to keep that as much as possible.

So on glibc systems, instead of bypassing the expansion, perhaps we could
instead enhance it to return the sign dependent value using builtin signbit to
determine the sign and paste it (bitop it) into the result.

Another option would be to inline a variant of the ieee glibc isinf function
code which seems to be very small.  I don't know how generic it is.


-- 


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

[Bug libstdc++/33628] unary_function and pointer_to_unary_function issues with void template arguments

[jwakely dot gcc at gmail dot com]

--- Comment #2 from jwakely dot gcc at gmail dot com  2008-03-08 15:25 
---
(In reply to comment #0)
> // 1
> #include 
> 
> typedef int value_type;
> 
> // void argument type
> template class std::unary_function;

eurgh, even more of an abomination than int f(void)  :-)

> template class std::pointer_to_unary_function;

This fails, correctly I think.  It's analogous to this illegal declaration:
  typedef void T;
  int f(T);

> // void return type
> template class std::unary_function;
> template class std::pointer_to_unary_function;

These are OK, aren't they?

> And more specific things:
> 
> // 2
> #include 
> void foo() { };
> 
> // pointer_to_unary_function
> void test01()
> {
>   typedef std::pointer_to_unary_function pfunc;
>   pfunc p(&foo);

this is invalid, foo is not a unary function so the number of parameters
doesn't match.  The declaration void f(void) is valid for C compatibility, but
that doesn't make it a unary function.
14.8.2para2 says type deduction can fail due to "Attempting to create a
function type in which a parameter has a type of void."  That's discussing a
different situation, but the principle is the same. I couldn't find anything
more specific.

> // 3
> #include 
> // unary_function
> struct void_unary : public std::unary_function
> { 
>   typedef std::unary_function base_type;
>   typedef base_type::Arg argument_type;
>   typedef base_type::Result result_type;
> };

Hmm, I suppose this is legal, although ill-advised.

> Is this usage standards-conforming?

I think the declarations and typedefs are legal, but using them isn't
necessarily possible. So you can't assign &foo to a unary_function, and you
couldn't define this member:
  Result void_unary::f(Arg);

Thankfully the void f(void) syntax is not valid in templates, because there's
no need for C compatibility in template code.

I don't think this is a bug.


-- 

jwakely dot gcc at gmail dot com changed:

   What|Removed |Added

 CC||jwakely dot gcc at gmail dot
   ||com


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

[Bug fortran/35474] [4.3/4.4 regression] Reading module file with COMMON and EQUIVALENCE

[pault at gcc dot gnu dot org]

--- Comment #3 from pault at gcc dot gnu dot org  2008-03-08 15:11 ---
(In reply to comment #2)
> Paul, do you have an idea?
> 
> The ICE happens when reading the .mod for p->u.wsym.sym->name == "i" in
> free_pi_tree:
>   if (p->fixup != NULL)
> gfc_internal_error ("free_pi_tree(): Unresolved fixup");
> 
> I got somehow lost in module.c when trying to track 'fixup'. See comment 1 for
> your patch which caused the regression. Still, I cannot see anything which is
> obviously wrong.
> 
> Just for fun, I set p->fixup = NULL in mio_symtree_ref (see your patch), then
> one gets the error that COMMON 'c' does not exist.
> 

I have started work on this, as a bit of light relief. Doing the latter,
prevents any members from being added to the COMMON and so it fails to come
into existence.

Oddly, reverting my patch for 32103 by hand does not get rid of the fault:) I
am beginning to think that we need fixups for the common block references to
the symbols... Anyway, I'll make a start on it.

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-03-05 15:08:55 |2008-03-08 15:11:14
   date||


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

[Bug target/35506] [avr] 4.3.0 buid error: illegal opcode movw for mcu avr3

[brian at dessent dot net]

--- Comment #1 from brian at dessent dot net  2008-03-08 14:27 ---
Subject:   New: [avr] 4.3.0 buid error: illegal opcode movw for 
 mcu avr3


> The building for AVR target is aborted at compilation libgcc stage with
> error: Illegal opcode movw for mcu avr3.  The lastest official release

You just need a more recent version of binutils.  See
 for details.


-- 


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

[Bug libstdc++/23888] should debug mode throw instead of assert?

[jwakely dot gcc at gmail dot com]

--- Comment #4 from jwakely dot gcc at gmail dot com  2008-03-08 13:41 
---
(In reply to comment #2)
> Finding this spot, 
> however, is the sole purpose of offering the debug mode libstdc++. 

I agree with every word of Wolfgang's, but this is the key point.
User code would never want to catch and handle debug mode exceptions, what
would the program do, log it and carry on? "We have encountered this bug 4798
times today." :)

Stack unwinding due to an exception could destroy all the evidence of the
failed precondition, making it much harder to track down the problem.  A
coredump is perfect.

The only advantage I see is for the testsuite, but the inconvenience to users
is major.


-- 

jwakely dot gcc at gmail dot com changed:

   What|Removed |Added

 CC||jwakely dot gcc at gmail dot
   ||com


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

[Bug target/22152] Poor loop optimization when using mmx builtins

[ubizjak at gmail dot com]

--- Comment #10 from ubizjak at gmail dot com  2008-03-08 12:51 ---
BTW: The larger testcase from the Comment 0 should add two numbers together,
but the carry propagation logic in the loop is fatally flawed. The testcase
that was added to the testsuite [1] fixes this problem.

[1]
http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gcc.target/i386/sse2-mmx.c?revision=133034&view=markup&pathrev=133034


-- 


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

[Bug c++/35317] [4.1/4.2/4.3/4.4 regression] ICE with operator delete[] and ellipsis

[simartin at gcc dot gnu dot org]

--- Comment #1 from simartin at gcc dot gnu dot org  2008-03-08 12:45 
---
Patch submitted here:
  http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00527.html


-- 

simartin at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |simartin at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-03-03 16:23:27 |2008-03-08 12:45:20
   date||


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

[Bug target/22152] Poor loop optimization when using mmx builtins

[uros at gcc dot gnu dot org]

--- Comment #9 from uros at gcc dot gnu dot org  2008-03-08 12:44 ---
Subject: Bug 22152

Author: uros
Date: Sat Mar  8 12:43:13 2008
New Revision: 133034

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133034
Log:
PR target/22152
* gcc.target/i386/pr22152.c: New test.
* gcc.target/i386/sse2-mmx.c: Ditto.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr22152.c
trunk/gcc/testsuite/gcc.target/i386/sse2-mmx.c
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug other/35511] New: release scripts added release note to zlib/ChangeLog, not zlib/ChangeLog.gcj

[debian-gcc at lists dot debian dot org]

the release scripts added the release note for 4.3.0 to zlib/ChangeLog
(upstream), not zlib/ChangeLog.gcj


-- 
   Summary: release scripts added release note to zlib/ChangeLog,
not zlib/ChangeLog.gcj
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org


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

[Bug target/35504] incorrect code generated on i386 for C++ multiple inheritance, large return structures and regparm or fastcall calling conventions

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-03-08 10:58 ---
Interesting ;)

Please send patches to [EMAIL PROTECTED] indicating how you tested it.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||ABI, wrong-code


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

[Bug middle-end/35509] [4.3/4.4 Regression] builtin isinf() mismatch to compile-time substitution

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-03-08 10:52 ---
Note that one might argue that the testcase is invalid as as you say, C99 only
says isinf returns non-zero.  So strictly speaking comparing the return value
of two invocations is not a way to check if both values are an infinity.

Of course this is at least an QOI issue.  The question is what behavior to
retain?  The glibc manpage documents returning -1 for -Inf and +1 for +Inf,
which we could preserve on glibc targets then not expanding via
isgreater(fabs(x),DBL_MAX).

(Only i386 and s390 have target dependent expansions for isinf - what is
their behavior here?)

Kaveh, you introduced the generic fallback, Andreas, what does s390 return
here, Uros, how is the situation on i386?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ghazi at gcc dot gnu dot
   ||org, uros at gcc dot gnu dot
   ||org, rguenth at gcc dot gnu
   ||dot org, krebbel at gcc dot
   ||gnu dot org


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

[Bug middle-end/35509] [4.3/4.4 Regression] builtin isinf() mismatch to compile-time substitution

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-03-08 10:40 ---
We run into the machine-independent inline expansion that replaces
isinf(x) with isgreater(fabs(x),DBL_MAX).  This is indeed inconsistend with
the constant folding we do.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|target  |middle-end
 Ever Confirmed|0   |1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2008-03-08 10:40:32
   date||
Summary|[avr] 4.3.0: builtin isinf()|[4.3/4.4 Regression] builtin
   |mismatch to compile-time|isinf() mismatch to compile-
   |substitution|time substitution
   Target Milestone|--- |4.3.1


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

[Bug target/35510] [4.4 regression] ICE in memory_address

[schwab at suse dot de]

--- Comment #1 from schwab at suse dot de  2008-03-08 10:05 ---
Created an attachment (id=15281)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15281&action=view)
Preprocessed source


-- 


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

[Bug target/35510] New: [4.4 regression] ICE in memory_address

[schwab at suse dot de]

The compiler ICEs while compiling libgfortran for powerpc:

$ ../../gcc/xgcc -B ../../gcc/ -c -std=gnu99 -O maxloc1_4_r16.i 
../../../libgfortran/generated/maxloc1_4_r16.c: In function
‘mmaxloc1_4_r16’:
../../../libgfortran/generated/maxloc1_4_r16.c:220: internal compiler error: in
memory_address, at explow.c:492

This was introduced by this change:

* explow.c (memory_address): Assert that the generated address is
valid.

memory_address is called with
(plus:SI (reg:SI 119)
(symbol_ref:SI ("") [flags 0x2]))
and transforms that to
(plus:SI (reg:SI 119)
(reg/f:SI 170))


-- 
   Summary: [4.4 regression] ICE in memory_address
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, build
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schwab at suse dot de
GCC target triplet: powerpc-linux


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

[Bug target/35509] New: [avr] 4.3.0: builtin isinf() mismatch to compile-time substitution

[dmixm at marine dot febras dot ru]

The next program is aborted in execution (avr-gcc 4.3.0, -Os):

  int isinf (double);
  void abort (void);
  volatile double x = -1.0/0.0;
  int main ()
  {
if (isinf (x) != isinf (-__builtin_inf ()))
abort ();
return 0;
  }

The second comparison argument is evaluated at compile time: -1 value
is substituted. This is traditional result for isinf(-Inf). The first
call of isinf() is replaced to inline code, which evaluates the -Inf
to +1 value.

The early avr-gcc versions are fine: the extern isinf() function was called.


-- 
   Summary: [avr] 4.3.0: builtin isinf() mismatch to compile-time
substitution
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dmixm at marine dot febras dot ru


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

[Bug target/35508] New: [avr] 4.3.0: undefined reference to `__ffshi2'

[dmixm at marine dot febras dot ru]

The next program is not linked (-Os option):

  int ffs (int);
  int main (int argc, char *argv[])
  {
(void)argv;
return ffs (argc);
  }

with undefined link to '__ffshi2'.

The used libc library (Avr-libc project) contains the ffs() funcion.


-- 
   Summary: [avr] 4.3.0: undefined reference to `__ffshi2'
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dmixm at marine dot febras dot ru


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

[Bug target/35507] New: [avr] 4.3.0: size of small funcion increases from 2 to 29 words

[dmixm at marine dot febras dot ru]

For funcion:

  long mult (long x, long y)
  {
return x * y;
  }

the avr-gcc 4.3.0 produces 29 words of code (-Os option):

  mult:
push r14
push r15
push r16
push r17
  /* prologue: function */
  /* frame size = 0 */
mov r14,r18
mov r15,r19
mov r16,r20
mov r17,r21
mov r18,r22
mov r19,r23
mov r20,r24
mov r21,r25
mov r25,r17
mov r24,r16
mov r23,r15
mov r22,r14
rcall __mulsi3
mov r18,r22
mov r19,r23
mov r20,r24
mov r21,r25
mov r23,r19
mov r24,r20
mov r25,r21
  /* epilogue start */
pop r17
pop r16
pop r15
pop r14
ret

The result of avr-gcc 4.1.2 is 2 words:

  mult:
  /* prologue: frame size=0 */
  /* prologue end (size=0) */
rcall __mulsi3
  /* epilogue: frame size=0 */
ret


-- 
   Summary: [avr] 4.3.0: size of small funcion increases from 2 to
29 words
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dmixm at marine dot febras dot ru


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

[Bug target/35506] New: [avr] 4.3.0 buid error: illegal opcode movw for mcu avr3

[dmixm at marine dot febras dot ru]

The building for AVR target is aborted at compilation libgcc stage with
error: Illegal opcode movw for mcu avr3.  The lastest official release
of binutils is used: 2.18.  The reason of error is an attempt to assemble
MOVW command for avr3 architecture which permits only classic instruction
set historically.

The workaround is to add '-mall-opcodes' avr-as option for this case.
Replace into 'config/avr/avr.h' the string:
#define ASM_SPEC "%{mmcu=avr25:-mmcu=avr2;
mmcu=avr35:-mmcu=avr3;
mmcu=avr31:-mmcu=avr3;mmcu=avr51:-mmcu=avr5;mmcu=*:-mmcu=%*}"
to:
#define ASM_SPEC "%{mmcu=avr25:-mmcu=avr2;
mmcu=avr35:-mmcu=avr3 -mall-opcodes;
mmcu=avr31:-mmcu=avr3;mmcu=avr51:-mmcu=avr5;mmcu=*:-mmcu=%*}"

After this edition the build and installation are fine.


-- 
   Summary: [avr] 4.3.0 buid error: illegal opcode movw for mcu avr3
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dmixm at marine dot febras dot ru


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