[Bug bootstrap/38262] [4.4 regression] GCC components unnecessarily link with shared gmp/mpfr

[spop at gcc dot gnu dot org]

--- Comment #9 from spop at gcc dot gnu dot org  2008-12-05 08:03 ---
Subject: Bug 38262

Author: spop
Date: Fri Dec  5 08:01:58 2008
New Revision: 142464

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142464
Log:
2008-11-07  Sebastian Pop  <[EMAIL PROTECTED]>

PR bootstrap/38262
* java/Make-lang.in (jc1): Add BACKENDLIBS, remove GMPLIBS.
* objc/Make-lang.in (cc1obj-dummy, cc1obj): Same.
* objcp/Make-lang.in (cc1objplus-dummy, cc1objplus): Same.
* cp/Make-lang.in (cc1plus-dummy, cc1plus): Same.
* ada/gcc-interface/Make-lang.in (gnat1): Same.
* fortran/Make-lang.in (f951): Same.
* Makefile.in (LIBS): Remove GMPLIBS, CLOOGLIBS and PPLLIBS.
(BACKENDLIBS): New.
(cc1-dummy, cc1): Add BACKENDLIBS, remove GMPLIBS.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/ada/gcc-interface/Make-lang.in
trunk/gcc/cp/Make-lang.in
trunk/gcc/fortran/Make-lang.in
trunk/gcc/java/Make-lang.in
trunk/gcc/objc/Make-lang.in
trunk/gcc/objcp/Make-lang.in


-- 


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

[Bug bootstrap/38262] [4.4 regression] GCC components unnecessarily link with shared gmp/mpfr

[spop at gcc dot gnu dot org]

--- Comment #8 from spop at gcc dot gnu dot org  2008-12-05 08:02 ---
Fixed.


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/38411] [4.4 Regression] Revision 142439 caused 22_locale/locale/cons/7.cc execution test

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2008-12-05 08:24 
---
Are you using the same glibc on x86_64 and ia64? The two failing testcases
(cons/7.cc and members/char/2.cc, the other are implied) are essentially the
same: something is different on that ia64 machine about the localedata having
to do with numeric decimal point and grouping. I'll try to further debug this
(because 38368 is a real issue and we want a fix) but since I can't reproduce
on my machines, I need to know the value of the various dp1, dp2, etc. in the
failing VERIFY (assert).


-- 


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

[Bug libstdc++/38411] [4.4 Regression] Revision 142439 caused 22_locale/locale/cons/7.cc execution test

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2008-12-05 08:36 ---
The only thing I remember was fr_FR locale changing some stuff and Fedora
backing out that change as it was done upstream too late in the cycle to get
feedback from the French community.


-- 


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

[Bug libstdc++/38411] [4.4 Regression] Revision 142439 caused 22_locale/locale/cons/7.cc execution test

[paolo dot carlini at oracle dot com]

--- Comment #6 from paolo dot carlini at oracle dot com  2008-12-05 08:47 
---
Yes, I'm not sure is the same issue. Anyway, the problem can only be in this
idea:

  _M_data->_M_thousands_sep = *(__nl_langinfo_l(THOUSANDS_SEP, 
__cloc));
  ...

  if (_M_data->_M_thousands_sep == '\0')
{
  _M_data->_M_thousands_sep = ',';

that is, we are trying to standardize on ',' (the same we have for the "C"
locale) in case the localedata is \0 for the thousands separator. Apparently
for some versions of glibc, it causes problems, I'm still trying to disentangle
the logic... Jakub, how does it sound to you?


-- 


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

[Bug libstdc++/38411] [4.4 Regression] Revision 142439 caused 22_locale/locale/cons/7.cc execution test

[paolo dot carlini at oracle dot com]

--- Comment #7 from paolo dot carlini at oracle dot com  2008-12-05 08:50 
---
By the way, yes the fr_FR locale is heavily used in those tests...


-- 


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

[Bug bootstrap/38262] [4.4 regression] GCC components unnecessarily link with shared gmp/mpfr

[jakub at gcc dot gnu dot org]

--- Comment #10 from jakub at gcc dot gnu dot org  2008-12-05 08:52 ---
Subject: Bug 38262

Author: jakub
Date: Fri Dec  5 08:50:47 2008
New Revision: 142466

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142466
Log:
PR bootstrap/38262
Fixup ChangeLog entries.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ada/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/fortran/ChangeLog
trunk/gcc/java/ChangeLog
trunk/gcc/objc/ChangeLog
trunk/gcc/objcp/ChangeLog


-- 


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

[Bug c/38408] compilation error during bootstrap in fold-const.c using TOT!

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2008-12-05 08:52 ---
Subject: Bug 38408

Author: jakub
Date: Fri Dec  5 08:51:36 2008
New Revision: 142468

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142468
Log:
PR c/38408
* fold-const.c (fold_checksum_tree): Change buf type to union
tree_node.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c


-- 


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

[Bug libstdc++/38411] [4.4 Regression] Revision 142439 caused 22_locale/locale/cons/7.cc execution test

[paolo dot carlini at oracle dot com]

--- Comment #8 from paolo dot carlini at oracle dot com  2008-12-05 08:55 
---
I suspect in the localedata of fr_FR, the thousands separator may have changed
in some glibc from ' ' (0x20) to '\0'. Jakub can you confirm that?


-- 


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

[Bug ada/38393] Storage_Error, bug box on record with large array component

[sam at gcc dot gnu dot org]

--- Comment #1 from sam at gcc dot gnu dot org  2008-12-05 09:02 ---
This bug has been fixed already in GCC 4.4.0.


-- 

sam at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||sam at gcc dot gnu dot org
 Status|UNCONFIRMED |RESOLVED
 GCC target triplet||4.4.0
 Resolution||FIXED


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

[Bug tree-optimization/38405] [4.4 Regression] (silent failure) handling bitfield in ternary

[bonzini at gnu dot org]

--- Comment #4 from bonzini at gnu dot org  2008-12-05 09:02 ---
I'll look at it in a couple of days.  In the meanwhile, could you please attach
the dumps of vrp and the pass just before it?


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |bonzini at gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-12-05 09:02:53
   date||


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

[Bug libstdc++/38411] [4.4 Regression] Revision 142439 caused 22_locale/locale/cons/7.cc execution test

[jakub at gcc dot gnu dot org]

--- Comment #9 from jakub at gcc dot gnu dot org  2008-12-05 09:10 ---
Forcing "," thousands separator when none should be used is very weird.  Does
C++ standard mandate that behavior?  "" means thousands shouldn't be separated
by any separator.  In most cases such locales also have grouping 0;0 or -1, but
there
are buggy? locales, e.g. bg_BG, that specify empty thousands_sep, yet have
grouping 3;3.  For empty thousands_sep glibc just forces no grouping:
  if ((wide && thousands_sepwc == L'\0')
  || (! wide && *thousands_sep == '\0'))
grouping = NULL;

BTW, thousands_sep is a multibyte string, it can be multiple bytes (or none, as
discussed here).  Say ru_RU has:
""
which is 3 bytes:
 /xe2/x80/x82 EN SPACE
and a bunch of locales are using "", which is 2 bytes:
 /xc2/xa0 NO-BREAK SPACE
_NL_NUMERIC_THOUSANDS_SEP_WC is always just one wchar_t though.

thousands_sep is one of the things that changed in fr_FR this year, see
sourceware #6040.


-- 


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

[Bug libstdc++/38411] [4.4 Regression] Revision 142439 caused 22_locale/locale/cons/7.cc execution test

[jakub at gcc dot gnu dot org]

--- Comment #10 from jakub at gcc dot gnu dot org  2008-12-05 09:13 ---
To reply to #c8, it changed the other way around, from "" to "" in April
2008.  But as I said, Fedora 9, which shipped glibc 2.9, was backing out these
changes (Fedora 10 has them already).


-- 


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

[Bug ada/38393] Storage_Error, bug box on record with large array component

[steven at gcc dot gnu dot org]

--- Comment #2 from steven at gcc dot gnu dot org  2008-12-05 09:15 ---
Is it possible to back-port the fix to GCC 4.3?


-- 


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

[Bug libstdc++/38411] [4.4 Regression] Revision 142439 caused 22_locale/locale/cons/7.cc execution test

[paolo dot carlini at oracle dot com]

--- Comment #11 from paolo dot carlini at oracle dot com  2008-12-05 09:16 
---
(In reply to comment #9)
> Forcing "," thousands separator when none should be used is very weird.

Is the same "C" locale has. We only want consistency, see 38368.

  Does
> C++ standard mandate that behavior?  "" means thousands shouldn't be separated
> by any separator.  In most cases such locales also have grouping 0;0 or -1, 
> but
> there
> are buggy?

I suppose so, because we have a comment in the code (resulting from feedback me
and / or Benjamin got from glibc people clearly saying that '\0' implies no
grouping. We always worked under this hypothesis.


 locales, e.g. bg_BG, that specify empty thousands_sep, yet have
> grouping 3;3.  For empty thousands_sep glibc just forces no grouping:
>   if ((wide && thousands_sepwc == L'\0')
>   || (! wide && *thousands_sep == '\0'))
> grouping = NULL;

Ok...

> 
> BTW, thousands_sep is a multibyte string, it can be multiple bytes

This is just a C++ standard issue, unfortunately...

Paolo.


-- 


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

[Bug libstdc++/38411] [4.4 Regression] Revision 142439 caused 22_locale/locale/cons/7.cc execution test

[paolo dot carlini at oracle dot com]

--- Comment #12 from paolo dot carlini at oracle dot com  2008-12-05 09:17 
---
(In reply to comment #10)
> To reply to #c8, it changed the other way around, from "" to "" in 
> April
> 2008.  But as I said, Fedora 9, which shipped glibc 2.9, was backing out these
> changes (Fedora 10 has them already).

Crazy. Anyway, that is the problem. I will change the tests to not rely on such
named locales.


-- 


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

[Bug ada/38393] Storage_Error, bug box on record with large array component

[sam at rfc1149 dot net]

--- Comment #3 from sam at rfc1149 dot net  2008-12-05 09:19 ---
Subject: Re:  Storage_Error, bug box on record with large
array component

* steven at gcc dot gnu dot org <[EMAIL PROTECTED]> [2008-12-05 09:15:14
-]

| Is it possible to back-port the fix to GCC 4.3?

It may be possible if you identify the commit that fixed it :/ I only
did a test run and noticed that I could reproduce it with GCC 4.3.2 on
i686-pc-linux-gnu and not with GCC 4.4.0 on the same target, but hadn't
noticed the bug before.

Finding the right commit may be hard, as the problem may have been
fixed by the side-effect of a totally unrelated commit, so good luck
with that.


-- 


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

[Bug libstdc++/38411] [4.4 Regression] Revision 142439 caused 22_locale/locale/cons/7.cc execution test

[jakub at gcc dot gnu dot org]

--- Comment #13 from jakub at gcc dot gnu dot org  2008-12-05 09:38 ---
I see you already disable grouping if it is empty, good.

If _M_thousands_sep must be a single _CharT, then for  I guess you should
transliterate it if the string is longer than one character.
Either by using glibc transliteration (more generic, but slower), or by
hardcoding
the few multibyte strings that are used in glibc locales ATM.
That's just  in current glibc (transliterate to ' ') and in some older
libcs was also that  (also to ' ').  Maybe change everything longer than
one byte to ' ' ;).


-- 


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

[Bug libstdc++/38411] [4.4 Regression] Revision 142439 caused 22_locale/locale/cons/7.cc execution test

[paolo dot carlini at oracle dot com]

--- Comment #14 from paolo dot carlini at oracle dot com  2008-12-05 09:42 
---
(In reply to comment #13)
> If _M_thousands_sep must be a single _CharT, then for  I guess you 
> should
> transliterate it if the string is longer than one character.
> Either by using glibc transliteration (more generic, but slower), or by
> hardcoding
> the few multibyte strings that are used in glibc locales ATM.
> That's just  in current glibc (transliterate to ' ') and in some older
> libcs was also that  (also to ' ').  Maybe change everything longer 
> than
> one byte to ' ' ;).

Ok, thanks. I think we have to think more about this issue, it's as old as v3
;) For 4.5 maybe...



-- 


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

[Bug libstdc++/38411] [4.4 Regression] Revision 142439 caused 22_locale/locale/cons/7.cc execution test

[paolo dot carlini at oracle dot com]

-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |paolo dot carlini at oracle
   |dot org |dot com
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-12-05 09:43:10
   date||


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

[Bug libstdc++/38411] [4.4 Regression] Revision 142439 caused 22_locale/locale/cons/7.cc execution test

[jakub at gcc dot gnu dot org]

--- Comment #15 from jakub at gcc dot gnu dot org  2008-12-05 09:48 ---
Well, if you take first byte from a multibyte sequence, then it is IMNSHO
something that should be solved for 4.4 too.  For say ru_RU.UTF-8 that means
you emit invalid UTF-8 if you separate digits with say '\xc2',
"\x33\xc2\x33\x33\x33" is invalid UTF-8.


-- 


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

[Bug libstdc++/38411] [4.4 Regression] Revision 142439 caused 22_locale/locale/cons/7.cc execution test

[paolo dot carlini at oracle dot com]

--- Comment #16 from paolo dot carlini at oracle dot com  2008-12-05 09:51 
---
(In reply to comment #15)
> Well, if you take first byte from a multibyte sequence, then it is IMNSHO
> something that should be solved for 4.4 too.  For say ru_RU.UTF-8 that means
> you emit invalid UTF-8 if you separate digits with say '\xc2',
> "\x33\xc2\x33\x33\x33" is invalid UTF-8.

Maybe, but, as I should learn from you ;) this is definitely not a regression,
the time is short and the issue is tricky. Therefore, I don't think I will
tackle it directly, unless you are willing to help, of course! 


-- 


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

[Bug libstdc++/38399] money_get<> read decimal point when frac_digits() <= 0

[tsyvarev at ispras dot ru]

--- Comment #3 from tsyvarev at ispras dot ru  2008-12-05 09:53 ---
Thanks for remark. It seemed for me, that iterator returned by get() and
iterator constructed from stream directly are interchangeable. Now I see that
it isn't so.

Then, example should be rewritten:

#include 
#include 
#include 

using namespace std;

class my_moneypunct : public moneypunct
{
protected:
//this should disable fraction part of monetary value
int do_frac_digits()const {return 0;}
};

int  main()
{
locale loc(locale(), new my_moneypunct());
stringstream ss("123.455");
ss.imbue(loc);
string digits;
ios_base::iostate err;
istreambuf_iterator iter = 
use_facet >(loc).get(ss, 0, false, ss, err, digits);

string rest = string(iter, istreambuf_iterator());
cout << "digits is \"" << digits << "\"\n";
cout << "rest of stream is \"" << rest << "\"\n";
return 0;
}
Output doesn't change.


-- 


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

[Bug libstdc++/38411] [4.4 Regression] Revision 142439 caused 22_locale/locale/cons/7.cc execution test

[paolo dot carlini at oracle dot com]

--- Comment #17 from paolo dot carlini at oracle dot com  2008-12-05 09:54 
---
Created an attachment (id=16831)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16831&action=view)
Draft

Draft patch using is_IS instead of fr_FR.


-- 


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

[Bug libstdc++/38411] [4.4 Regression] Revision 142439 caused 22_locale/locale/cons/7.cc execution test

[paolo dot carlini at oracle dot com]

--- Comment #18 from paolo dot carlini at oracle dot com  2008-12-05 09:55 
---
HJ, can you test it and report? Thanks!


-- 


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

[Bug libstdc++/38399] money_get<> read decimal point when frac_digits() <= 0

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2008-12-05 09:59 
---
(In reply to comment #3)
> Thanks for remark.

You are welcome. By the way, since in general you are so kind to report very
accurate and to the point issues, I would appreciate if you could also add
testcases more similar to what we already have in the testsuite (so, for
example, no outputs, no use of iostreams, asserts instead; etc.). That would
greatly speed up the whole process! Thanks again.


-- 


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

[Bug rtl-optimization/38245] [4.4 Regression] stack corruption when a call is removed but not the outgoing argument pushes

[ebotcazou at gcc dot gnu dot org]

--- Comment #9 from ebotcazou at gcc dot gnu dot org  2008-12-05 10:28 
---
> "I guess that option 4 is to investigate why DSE doesn't remove the dead
> stores."
> 1) DCE which removes this is done after DSE2

Bummer.

> 2) DSE doesn't remove sp based stores, except for spill slots (there is a PR
> about it, but isn't going to be fixed any time soon).

Right, I remember now. :-)

I'll try to come up with something.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ebotcazou at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-11-24 09:10:58 |2008-12-05 10:28:01
   date||


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

[Bug rtl-optimization/38245] [4.4 Regression] stack corruption when a call is removed but not the outgoing argument pushes

[jakub at gcc dot gnu dot org]

--- Comment #10 from jakub at gcc dot gnu dot org  2008-12-05 11:07 ---
I guess for !ACCUMULATE_OUTGOING_ARGS DCE of calls having stack arguments
generally shouldn't be an issue (unless they pop the stack themselves, don't
remember if it is easily determinable in generic way), worst case where will be
some pushes and some pops or stack additions left around.
For ACCUMULATE_OUTGOING_ARGS you could use:
(expr_list:REG_DEP_TRUE (use (mem:SI (reg/f:SI 7 sp) [0 S4 A8]))
(expr_list:REG_DEP_TRUE (use (mem:SI (plus:SI (reg/f:SI 7 sp)
(const_int 4 [0x4])) [0 S4 A8]))
(nil
from the CALL_INSN, just see if you can find safely and remove also the stores
to those stack locations, if yes, remove them together with the call, if not,
don't DCE the call either.


-- 


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

[Bug libstdc++/38411] [4.4 Regression] Revision 142439 caused 22_locale/locale/cons/7.cc execution test

[tsyvarev at ispras dot ru]

--- Comment #19 from tsyvarev at ispras dot ru  2008-12-05 11:08 ---
It seems that C++ standard contains contradiction about thousands separator in
"C" locale:

22.2.3.1, p1 says:

The instantiations required in Table 51 (22.1.1.1.1), namely numpunct
and numpunct, provide classic “C” numeric formats, i.e. they contain
information equivalent to that contained in the “C” locale or their wide
character counterparts as if obtained by a call to widen.

also, 22.2.3.1.2 p.2 says:

char_type do_thousands_sep() const;

Returns: A character for use as the digit group separator. The required
instantiations return ’,’ or L’,’.

It appears, that according to C++ standard, thousands separator for "C" locale
is ','.

But according to the ISO standard of "C"("POSIX") locale (Section 7.3, Locale
Definition), thousands separator in this locale should be '\0', which means N/A
or not assigned.

Or is this reasoning wrong?


-- 

tsyvarev at ispras dot ru changed:

   What|Removed |Added

 CC||tsyvarev at ispras dot ru


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

[Bug middle-end/38406] [4.4 Regression] Revision 142437 caused gcc.dg/Wstrict-aliasing-converted-assigned.c

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-12-05 11:10 ---
Uhm, I probably forgot to apply one testsuite update.  I'll check.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-12-05 11:10:59
   date||
   Target Milestone|--- |4.4.0


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

[Bug tree-optimization/38405] [4.4 Regression] (silent failure) handling bitfield in ternary

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-12-05 11:23 ---
The error is likely

Folding statement: D.1241_5 = D.1242_4 != 0;
Folded into: D.1241_5 = (int) D.1242_4;

which is wrong for

   D.1242;

because it sign-extends.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work||4.3.2
   Priority|P3  |P1


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

[Bug testsuite/38406] [4.4 Regression] Revision 142437 caused gcc.dg/Wstrict-aliasing-converted-assigned.c

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-12-05 11:57 ---
Forwprop optimizes that testcase now on 32bit systems.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|middle-end  |testsuite


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

[Bug testsuite/38406] [4.4 Regression] Revision 142437 caused gcc.dg/Wstrict-aliasing-converted-assigned.c

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2008-12-05 12:00 ---
Subject: Bug 38406

Author: rguenth
Date: Fri Dec  5 11:59:21 2008
New Revision: 142471

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142471
Log:
2008-12-05  Richard Guenther  <[EMAIL PROTECTED]>

PR testsuite/38406
* gcc.dg/Wstrict-aliasing-converted-assigned.c: Restrict PTA
alias warning to lp64 targets.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/Wstrict-aliasing-converted-assigned.c


-- 


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

[Bug testsuite/38406] [4.4 Regression] Revision 142437 caused gcc.dg/Wstrict-aliasing-converted-assigned.c

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-12-05 11:59 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug target/38306] [4.4 Regression] 15% slowdown w.r.t. 4.3 of computational kernel on some architectures

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||missed-optimization
   Priority|P3  |P2


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

[Bug c++/38357] [4.2/4.3/4.4 Regression] ICE cc1plus (Segmentation fault)

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug bootstrap/38300] [4.4 Regression] libstdc++ and libgcj contain a reference to _Unwind_GetIPInfo

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

[Bug preprocessor/38161] [4.4 regression] #elif breaks

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-12-05 12:20 ---


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


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug preprocessor/36453] PR36320 breaks boost

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2008-12-05 12:20 ---
*** Bug 38161 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||h dot b dot furuseth at usit
   ||dot uio dot no


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

[Bug middle-end/38360] [4.3 Regression] ICE in gimple_op, at gimple.h:1636

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2
Summary|[4.3 regression] ICE in |[4.3 Regression] ICE in
   |gimple_op, at gimple.h:1636 |gimple_op, at gimple.h:1636


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

[Bug debug/38367] [4.2/4.3/4.4 Regression] Wrong debug information for big endian function parameters

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2
Summary|[4.1/4.2/4.3/4.4 regression]|[4.2/4.3/4.4 Regression]
   |Wrong debug information for |Wrong debug information for
   |big endian function |big endian function
   |parameters  |parameters


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

[Bug middle-end/38074] [4.4 Regression] missed inlining on Core2 Duo due to apparent wrong branch prediction/profile

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2008-12-05 12:21 ---
Honza, can you have a look here?  I suspect the fortran decl issue prevent
proper profile distribution over the callgraph...


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug middle-end/38070] [4.3 Regression] ICE in compare_values_warnv

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug tree-optimization/38359] [4.3 Regression] ICE in set_lattice_value, at tree-ssa-ccp.c:466

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug tree-optimization/38369] [4.3 regression] ICE (SIGSEGV in number_of_iterations_exit)

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug middle-end/38271] [4.4 Regression] Spurious / missing "... used uninitialized in this function" warning

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2008-12-05 12:57 ---
This is sra_build_assignment/sra_build_bf_assignments way of "lowering" a
BIT_FIELD_REF to integer arithmetic.  We hit the !INTEGRAL_TYPE_P (TREE_TYPE
(var)) paths and for

  BIT_FIELD_REF <*p_1(D), 32, 0>

we create VIEW_CONVERT_EXPR  (*p) and extract the lower/upper 32
bits by shifting and masking.  This obviously "uses" possibly uninitialized
parts of *p or s0.  The problem here is that we interestingly split the
initialization of s0 to the upper part

  s0.c ={v} s0$c_7;

and the lower part

  SR.3_8 = VIEW_CONVERT_EXPR(s0);
  SR.4_9 = SR.3_8 & 0x;
  SR.5_10 = (long long unsigned int) s0$B0F32_5;
  SR.6_11 = SR.4_9 | SR.5_10;
  s0 ={v} VIEW_CONVERT_EXPR(SR.6_11);

this is likely because SRA really wants to have two 32bit fields but it
cannot deal with the larger struct with a VIEW_CONVERT_EXPR.

With just disabling all these code-paths we get

:
  s0$B0F32_4 = 0;
  s0$c_5 = p_1(D)->c;
  s0$B0F32_6 = BIT_FIELD_REF <*p_1(D), 32, 0>;
  s0.c ={v} s0$c_5;
  BIT_FIELD_REF  ={v} s0$B0F32_6;
  s ={v} s0;
  s$a_7 = s.a;
  D.1242_2 = s$a_7;

and no warning.  But of course we now have bitfield refs that are not optimized
(not scalarizing in this case would be better).  Of course even with the
current scalarization we finally arrive with

:
  # VUSE 
  s0$c_7 = p_1(D)->c;
  # VUSE 
  D.1249_4 = VIEW_CONVERT_EXPR(*p_1(D));
  s0$B0F32_5 = (unsigned int) D.1249_4;
  # VUSE 
  SR.21_24 = VIEW_CONVERT_EXPR(s0);
  SR.22_25 = SR.21_24 & 0x;
  # s0_28 = VDEF 
  s0 = VIEW_CONVERT_EXPR(SR.22_25);
  # s0_29 = VDEF 
  s0.c = s0$c_7;
  # VUSE 
  SR.3_8 = VIEW_CONVERT_EXPR(s0);
  SR.4_9 = SR.3_8 & 0x;
  SR.5_10 = (long long unsigned int) s0$B0F32_5;
  SR.6_11 = SR.5_10 | SR.4_9;
  s0$B0F32_21 = (unsigned int) SR.6_11;
  s0$c_30 = VIEW_CONVERT_EXPR(SR.6_11).c;
  # VUSE 
  SR.25_31 = VIEW_CONVERT_EXPR(s0);
  SR.26_32 = SR.25_31 & 0x;
  SR.27_33 = (long long unsigned int) s0$B0F32_21;
  SR.28_34 = SR.27_33 | SR.26_32;
  # s0_35 = VDEF 
  s0 = VIEW_CONVERT_EXPR(SR.28_34);
  # s0_36 = VDEF 
  s0.c = s0$c_30;
  # VUSE 
  # s_18 = VDEF 
  s = s0;
  # VUSE 
  s$a_37 = s.a;
  # s_39 = VDEF 
  s.a = s$a_37;
  # VUSE 
  # SMT.16_20 = VDEF 
  bar (s);
  return;

because we seem to scalarize again.  Ugh.


-- 


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

[Bug middle-end/38074] [4.4 Regression] missed inlining on Core2 Duo due to apparent wrong branch prediction/profile

[hubicka at ucw dot cz]

--- Comment #9 from hubicka at ucw dot cz  2008-12-05 12:59 ---
Subject: Re:  [4.4 Regression] missed inlining on Core2 Duo due  to apparent
wrong branch prediction/profile

> Honza, can you have a look here?  I suspect the fortran decl issue prevent
Will do.  We however don't distribute profile over cgraph...  This looks
more like one of misguesses cases

Honza


-- 


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

[Bug middle-end/38271] [4.4 Regression] Spurious / missing "... used uninitialized in this function" warning

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2008-12-05 13:05 ---
The following would make SRA only combine all of the struct or nothing.  That
avoids these messy situations:

Index: tree-sra.c
===
--- tree-sra.c  (revision 142469)
+++ tree-sra.c  (working copy)
@@ -1695,7 +1695,10 @@ try_instantiate_multiple_fields (struct 

   gcc_assert (~alchk < align);

-  /* Create the field group as a single variable.  */
+  /* Create the field group as a single variable if the group covers
+ the whole element.  */
+  if (size != TREE_INT_CST_LOW (TYPE_SIZE (TREE_TYPE (elt->element
+return f;

   /* We used to create a type for the mode above, but size turns
  to be out not of mode-size.  As we need a matching type


-- 


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

[Bug libstdc++/38411] [4.4 Regression] Revision 142439 caused 22_locale/locale/cons/7.cc execution test

[paolo at gcc dot gnu dot org]

--- Comment #20 from paolo at gcc dot gnu dot org  2008-12-05 13:09 ---
Subject: Bug 38411

Author: paolo
Date: Fri Dec  5 13:07:53 2008
New Revision: 142472

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142472
Log:
2008-12-05  Paolo Carlini  <[EMAIL PROTECTED]>

PR libstdc++/38411
* testsuite/22_locale/numpunct/members/char/2.cc: Use is_IS instead
of fr_FR.
* testsuite/22_locale/numpunct/members/wchar_t/2.cc: Likewise.
* testsuite/22_locale/locale/cons/7.cc: Likewise.


Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/testsuite/22_locale/locale/cons/7.cc
trunk/libstdc++-v3/testsuite/22_locale/numpunct/members/char/2.cc
trunk/libstdc++-v3/testsuite/22_locale/numpunct/members/wchar_t/2.cc


-- 


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

[Bug libstdc++/38411] [4.4 Regression] Revision 142439 caused 22_locale/locale/cons/7.cc execution test

[paolo dot carlini at oracle dot com]

--- Comment #21 from paolo dot carlini at oracle dot com  2008-12-05 13:09 
---
Fixed.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

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


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

[Bug debug/37959] g++ does not emit DW_AT_explicit

[dodji at gcc dot gnu dot org]

--- Comment #2 from dodji at gcc dot gnu dot org  2008-12-05 14:29 ---
This patch was posted to gcc-patches, got reworked and approved. See
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00137.html.

I will wait until trunk is open again for feature commit to install it.


-- 


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

[Bug tree-optimization/37716] [4.4 Regression] ice for legal C++ code with -O2 on 20080926

[jakub at gcc dot gnu dot org]

--- Comment #13 from jakub at gcc dot gnu dot org  2008-12-05 14:34 ---
Subject: Bug 37716

Author: jakub
Date: Fri Dec  5 14:33:14 2008
New Revision: 142476

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142476
Log:
PR tree-optimization/37716
* gimplify.c (gimplify_expr): Allow COND_EXPR if
gimplify_ctxp->allow_rhs_cond_expr.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c


-- 


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

[Bug tree-optimization/38405] [4.4 Regression] (silent failure) handling bitfield in ternary

[bonzini at gnu dot org]

--- Comment #6 from bonzini at gnu dot org  2008-12-05 15:42 ---
Subject: Re:  [4.4 Regression] (silent failure)
 handling bitfield in ternary


> Folding statement: D.1241_5 = D.1242_4 != 0;
> Folded into: D.1241_5 = (int) D.1242_4;
> 
> which is wrong for
> 
>D.1242;
> 
> because it sign-extends.

So it's probably in fold-const.c and latent in 4.3 too...

Paolo


-- 


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

[Bug debug/38390] Missing DW_TAG_imported_module

[dodji at gcc dot gnu dot org]

-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dodji at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-12-05 16:17:53
   date||


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

[Bug tree-optimization/25621] Missed optimization when unrolling the loop (splitting up the sum) (only with -ffast-math)

[jv244 at cam dot ac dot uk]

--- Comment #10 from jv244 at cam dot ac dot uk  2008-12-05 16:25 ---
Timings in 4.4 are essentially unchanged

gfortran -O3 -ffast-math -march=native PR25621.f90:

 default loop   1.29208100
 hand optimized loop  0.864053988

fun enough inverse timings with a recent intel compiler:

 default loop  0.4400280
 hand optimized loop   1.260078


-- 


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

[Bug fortran/25096] Non-conforming shapes of DATA object and data

[jv244 at cam dot ac dot uk]

--- Comment #2 from jv244 at cam dot ac dot uk  2008-12-05 16:26 ---
still fails with 4.4


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

   Last reconfirmed|2006-06-04 09:38:57 |2008-12-05 16:26:38
   date||


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

[Bug fortran/22571] Reject derived types for dummy arguments declared in the subroutine unless they are SEQUENCE

[jv244 at cam dot ac dot uk]

--- Comment #9 from jv244 at cam dot ac dot uk  2008-12-05 16:28 ---
updated testcase still fails:

subroutine a(p)
  type t
integer :: t1
  end type
  type(t) :: p
  p%t1 = 42
end subroutine
subroutine b
  type u
integer :: u1
  end type
  type (u) :: q
  call a(q)
  write(6,*) q%u1
end subroutine


-- 


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

[Bug fortran/34663] Specification expression is defined by dummy variables of different entry points

[jv244 at cam dot ac dot uk]

--- Comment #2 from jv244 at cam dot ac dot uk  2008-12-05 16:30 ---
still fails in 4.4


-- 


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

[Bug middle-end/38413] New: [graphite] ICE: in build2_stat, at tree.c:3293

[mitul dot thakkar at amd dot com]

Getting error in tree.c file, while running it with graphite. Following is the
exact description of the error message.

gcc -c -O2 -fgraphite-identity  final_build.c

final_build.c: In function 'specqsort':
final_build.c:3: internal compiler error: in build2_stat, at tree.c:3293
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Reduced test case is attached for the same.

-Mitul Thakkar.


-- 
   Summary: [graphite] ICE: in build2_stat, at tree.c:3293
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mitul dot thakkar at amd dot com
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug middle-end/38413] [graphite] ICE: in build2_stat, at tree.c:3293

[mitul dot thakkar at amd dot com]

--- Comment #1 from mitul dot thakkar at amd dot com  2008-12-05 16:46 
---
Created an attachment (id=16832)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16832&action=view)
Reduced Test Case


-- 


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

[Bug libgcj/38414] New: gcc 4.3-20081204 build broken on OS X 10.4 ppc

[hal at oz dot net]

I ran a build gcc-4.3-20081204 on a powerbook g4 running OS X 10.4 and it
failed quite late in stage 3.  Here's the tail end of the console output:

libtool: compile: 
/Volumes/LaCie/Developer/Sources/gcc-4.3-20081204-build/gcc/gcj
-B/Volumes/LaCie/Developer/Sources/gcc-4.3-20081204-build/powerpc-apple-darwin8.11.0/libjava/
-B/Volumes/LaCie/Developer/Sources/gcc-4.3-20081204-build/gcc/ -fclasspath=
-fbootclasspath=../../../gcc-4.3-20081204/libjava/classpath/lib
--encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c
-fsource-filename=/Volumes/LaCie/Developer/Sources/gcc-4.3-20081204-build/powerpc-apple-darwin8.11.0/libjava/classpath/lib/classes
-MT java/util/logging.lo -MD -MP -MF java/util/logging.deps
@java/util/logging.list -o java/util/logging.o >/dev/null 2>&1
rm: java/util/.libs/logging.o: Invalid argument
make[3]: *** [java/util/logging.lo] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-target-libjava] Error 2
make: *** [all] Error 2


This build used configure with no options (all defaults).  A similar build of
the previous week's drop (gcc-4.3-20081127) ran successfully with no errors.


-- 
   Summary: gcc 4.3-20081204 build broken on OS X 10.4 ppc
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hal at oz dot net


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

[Bug middle-end/38338] [4.4 Regression] __builtin_apply causes an ICE on x86

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2008-12-05 16:53 ---
Subject: Bug 38338

Author: jakub
Date: Fri Dec  5 16:52:16 2008
New Revision: 142480

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142480
Log:
PR middle-end/38338
* builtins.c (expand_builtin_apply_args): Put before parm_birth_insn
only if internal_arg_pointer is a non-virtual pseudo.

* gcc.dg/pr38338.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr38338.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug debug/38367] [4.2/4.3/4.4 Regression] Wrong debug information for big endian function parameters

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2008-12-05 16:55 ---
Subject: Bug 38367

Author: jakub
Date: Fri Dec  5 16:53:39 2008
New Revision: 142481

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142481
Log:
PR debug/38367
* function.c (assign_parm_find_stack_rtl): If promoted_mode
is wider than DECL_MODE, adjust MEM_OFFSET (stack_parm) for
big endian.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/function.c


-- 


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

[Bug middle-end/38338] [4.4 Regression] __builtin_apply causes an ICE on x86

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2008-12-05 16:54 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug debug/38367] [4.2/4.3 Regression] Wrong debug information for big endian function parameters

[jakub at gcc dot gnu dot org]

--- Comment #9 from jakub at gcc dot gnu dot org  2008-12-05 16:55 ---
Fixed on the trunk.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work|4.0.4   |4.0.4 4.4.0
Summary|[4.2/4.3/4.4 Regression]|[4.2/4.3 Regression] Wrong
   |Wrong debug information for |debug information for big
   |big endian function |endian function parameters
   |parameters  |


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

[Bug c++/35336] Broken diagnostic: 'bit_field_ref' not supported by dump_expr

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2008-12-05 17:01 ---
Subject: Bug 35336

Author: jakub
Date: Fri Dec  5 16:59:34 2008
New Revision: 142484

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142484
Log:
PR middle-end/37248
* fold-const.c (make_bit_field_ref): Change bitpos and bitsize
arguments to HOST_WIDE_INT.  If type has different signedness
than unsignedp or different precision from bitsize, create
the right type for BIT_FIELD_REF and cast to type.
(fold_truthop): Change first_bit and end_bit to HOST_WIDE_INT.

Revert:
2008-03-05  Richard Guenther  <[EMAIL PROTECTED]>
PR c++/35336
* fold-const.c (fold_truthop): Remove code generating
BIT_FIELD_REFs of structure bases.
(fold_binary): Likewise.
(make_bit_field_ref): Remove.
(optimize_bit_field_compare): Remove.
(all_ones_mask_p): Remove.

* gcc.target/i386/pr37248-1.c: New test.
* gcc.target/i386/pr37248-2.c: New test.
* gcc.target/i386/pr37248-3.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr37248-1.c
trunk/gcc/testsuite/gcc.target/i386/pr37248-2.c
trunk/gcc/testsuite/gcc.target/i386/pr37248-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/37248] [4.4 Regression] regression transformation bitfield to individual bytes

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2008-12-05 17:01 ---
Subject: Bug 37248

Author: jakub
Date: Fri Dec  5 16:59:34 2008
New Revision: 142484

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142484
Log:
PR middle-end/37248
* fold-const.c (make_bit_field_ref): Change bitpos and bitsize
arguments to HOST_WIDE_INT.  If type has different signedness
than unsignedp or different precision from bitsize, create
the right type for BIT_FIELD_REF and cast to type.
(fold_truthop): Change first_bit and end_bit to HOST_WIDE_INT.

Revert:
2008-03-05  Richard Guenther  <[EMAIL PROTECTED]>
PR c++/35336
* fold-const.c (fold_truthop): Remove code generating
BIT_FIELD_REFs of structure bases.
(fold_binary): Likewise.
(make_bit_field_ref): Remove.
(optimize_bit_field_compare): Remove.
(all_ones_mask_p): Remove.

* gcc.target/i386/pr37248-1.c: New test.
* gcc.target/i386/pr37248-2.c: New test.
* gcc.target/i386/pr37248-3.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr37248-1.c
trunk/gcc/testsuite/gcc.target/i386/pr37248-2.c
trunk/gcc/testsuite/gcc.target/i386/pr37248-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/37248] [4.4 Regression] regression transformation bitfield to individual bytes

[jakub at gcc dot gnu dot org]

--- Comment #9 from jakub at gcc dot gnu dot org  2008-12-05 17:01 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug other/28614] gcc.c-torture/compile/20001226-1.c times out

[sje at gcc dot gnu dot org]

--- Comment #2 from sje at gcc dot gnu dot org  2008-12-05 17:05 ---
Subject: Bug 28614

Author: sje
Date: Fri Dec  5 17:04:27 2008
New Revision: 142485

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142485
Log:
PR other/28614
* gcc.c-torture/compile/20001226-1.c: Add dg-timeout-factor.
* g++.dg/torture/pr31863.C: Ditto.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/torture/pr31863.C
trunk/gcc/testsuite/gcc.c-torture/compile/20001226-1.c


-- 


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

[Bug middle-end/38074] [4.4 Regression] missed inlining on Core2 Duo due to apparent wrong branch prediction/profile

[hubicka at gcc dot gnu dot org]

--- Comment #10 from hubicka at gcc dot gnu dot org  2008-12-05 17:08 
---
compute_call_stmt_bb_frequency test is indeed bit insane, but probably works in
practice.  I will fix this on pretty-ipa branch.
Looking at sw(__MAIN) just after profiling, profile is there and it is sort of
sane.

The reason for low probability of the internal loop being somewhat cold is
block
31 that is predicted via noreturn heuristics.
It looks like the code is leading to exit at error cases and to noreturn call
in common case that is confusing the predictors...

Block 31 starts with:
omega_178 = 6.2831853070010824624041561037302017211914062e+0 /
period.151_177
v0 ={v} 1.555111512312
5782702118158340454e-1
dt_parm.51.common.filename ={v} &"channel.f90"[1]{lb: 1 sz: 1};

Perhaps if all paths through function leads to noreturn, one can disable the
heuristics... I will check if this works.

Honza


-- 


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

[Bug middle-end/38074] [4.4 Regression] missed inlining on Core2 Duo due to apparent wrong branch prediction/profile

[hubicka at ucw dot cz]

--- Comment #11 from hubicka at ucw dot cz  2008-12-05 17:15 ---
Subject: Re:  [4.4 Regression] missed inlining on Core2 Duo due  to apparent
wrong branch prediction/profile

OK,
so the problem is that all the paths are leading to noreturn, so the
conditional deciding on what noreturn path will be taken is predictor by
same heuristic in both dirrections.
Our first math heuristic blindly picks the first one in row predicting
the "invalid command line parameters" path to be very likely and main
body to be very unlikely.

This patch fixes it in both ways: when all paths are leading to
noreturn, we disable the heuristics and when heuristics is taken
into consideration for first match we first check that it was not
confused and did not predict edge in both ways.

I also fixed nonsence in compute_call_stmt_bb_frequency noticed by
Jakub. To make frequencies at least little bit sane, I simply add 1 to
both values so we still get calls with higher frequency than 0 predicted
as more often.

Honza

Jan Hubicka  <[EMAIL PROTECTED]>
Jakub Jelinek <[EMAIL PROTECTED]>
* cgraphbuild.c (compute_call_stmt_bb_frequency): Fix handling of 0
entry frequency.
* predict.c (combine_predictions_for_bb): Ignore predictor predicting
in both dirrection for first match heuristics.
(tree_bb_level_predictions): Disable noreturn heuristic when there
is no returning path.
Index: cgraphbuild.c
===
*** cgraphbuild.c   (revision 141929)
--- cgraphbuild.c   (working copy)
*** int
*** 109,121 
  compute_call_stmt_bb_frequency (basic_block bb)
  {
int entry_freq = ENTRY_BLOCK_PTR->frequency;
!   int freq;

if (!entry_freq)
! entry_freq = 1;

!   freq = (!bb->frequency && !entry_freq ? CGRAPH_FREQ_BASE
! : bb->frequency * CGRAPH_FREQ_BASE / entry_freq);
if (freq > CGRAPH_FREQ_MAX)
  freq = CGRAPH_FREQ_MAX;

--- 109,120 
  compute_call_stmt_bb_frequency (basic_block bb)
  {
int entry_freq = ENTRY_BLOCK_PTR->frequency;
!   int freq = bb->frequency;

if (!entry_freq)
! entry_freq = 1, freq++;

!   freq = freq * CGRAPH_FREQ_BASE / entry_freq;
if (freq > CGRAPH_FREQ_MAX)
  freq = CGRAPH_FREQ_MAX;

Index: predict.c
===
*** predict.c   (revision 141929)
--- predict.c   (working copy)
*** combine_predictions_for_bb (basic_block 
*** 820,827 
probability = REG_BR_PROB_BASE - probability;

  found = true;
  if (best_predictor > predictor)
!   best_probability = probability, best_predictor = predictor;

  d = (combined_probability * probability
   + (REG_BR_PROB_BASE - combined_probability)
--- 820,852 
probability = REG_BR_PROB_BASE - probability;

  found = true;
+ /* First match heuristics would be widly confused if we predicted
+both directions.  */
  if (best_predictor > predictor)
!   {
!   struct edge_prediction *pred2;
! int prob = probability;
! 
!   for (pred2 = (struct edge_prediction *) *preds; pred2; pred2 =
pred2->ep_next)
!  if (pred2 != pred && pred2->ep_predictor == pred->ep_predictor)
!{
!  int probability2 = pred->ep_probability;
! 
!  if (pred2->ep_edge != first)
!probability2 = REG_BR_PROB_BASE - probability2;
! 
!  if ((probability < REG_BR_PROB_BASE / 2) != 
!  (probability2 < REG_BR_PROB_BASE / 2))
!break;
! 
!  /* If the same predictor later gave better result, go for
it! */
!  if ((probability >= REG_BR_PROB_BASE / 2 && (probability2 >
probability))
!  || (probability <= REG_BR_PROB_BASE / 2 && (probability2
< probability)))
!prob = probability2;
!}
! if (!pred2)
!   best_probability = prob, best_predictor = predictor;
!   }

  d = (combined_probability * probability
   + (REG_BR_PROB_BASE - combined_probability)
*** static void
*** 1521,1526 
--- 1546,1561 
  tree_bb_level_predictions (void)
  {
basic_block bb;
+   bool has_return_edges = false;
+   edge e;
+   edge_iterator ei;
+ 
+   FOR_EACH_EDGE (e, ei, EXIT_BLOCK_PTR->preds)
+ if (!(e->flags & (EDGE_ABNORMAL | EDGE_FAKE | EDGE_EH)))
+   {
+ has_return_edges = true;
+   break;
+   }

apply_return_prediction ();

*** tree_bb_level_predictions (void)
*** 1535,1541 

  if (is_gimple_call (stmt))
{
! if (gimple_call_flags (stmt) & ECF_NORETURN)
predict_paths_leading_to (bb, PRED_NORETURN,
  NOT_TAKEN);
 

[Bug other/28614] gcc.c-torture/compile/20001226-1.c times out

[sje at cup dot hp dot com]

--- Comment #3 from sje at cup dot hp dot com  2008-12-05 17:16 ---
Dave, I added a dg-timeout-factor to this test for HPPA so it shouldn't time
out on PA boxes anymore.  I hadn't noticed the x86 timeout part of the report
when I first looked at it.  Do you still have that problem?  If so we can
change the test to increase the timeout there too or, if you don't have that
problem anymore we can just close this bug out since it should be fixed on PA
now.


-- 

sje at cup dot hp dot com changed:

   What|Removed |Added

 CC||sje at cup dot hp dot com


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

[Bug bootstrap/38300] [4.4 Regression] libstdc++ and libgcj contain a reference to _Unwind_GetIPInfo

[howarth at nitro dot med dot uc dot edu]

--- Comment #5 from howarth at nitro dot med dot uc dot edu  2008-12-05 
17:30 ---
Andrew,
This last patch would still be problematic since it will not catch targets
set to *-*-darwin8 rather than *-*-darwin8.5. A better fix would be to use the
approach from...


r142417 | janis | 2008-12-03 18:41:46 -0500 (Wed, 03 Dec 2008) | 2 lines

* g++.old-deja/g++.eh/badalloc1.C: Reinstate XFAIL for Darwin 3-7.

...and use a patch like

Index: unwind_ipinfo.m4
===
--- unwind_ipinfo.m4(revision 142255)
+++ unwind_ipinfo.m4(working copy)
@@ -22,7 +22,11 @@ AC_DEFUN([GCC_CHECK_UNWIND_GETIPINFO], [
   *) have_unwind_getipinfo=yes ;;
 esac
   else
- have_unwind_getipinfo=yes
+# Darwin before version 9 does not have _Unwind_GetIPInfo.
+case ${target} in
+  *-*-darwin[3-8]*) have_unwind_getipinfo=no ;;
+  *) have_unwind_getipinfo=yes ;;
+esac
   fi

   if test x$have_unwind_getipinfo = xyes; then

...which would work until we reach darwin30.


-- 


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

[Bug bootstrap/38300] [4.4 Regression] libstdc++ and libgcj contain a reference to _Unwind_GetIPInfo

[schwab at suse dot de]

--- Comment #6 from schwab at suse dot de  2008-12-05 17:47 ---
You can use multiple patterns:

*-*-darwin[1-8]|*-*-darwin[1-8].*) ...


-- 


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

[Bug fortran/38415] New: procedure pointer assignment to abstract interface

[janus at gcc dot gnu dot org]

The following program is currently accepted, although it is invalid:

 abstract interface
   subroutine bar(a)
 integer :: a
   end subroutine bar
 end interface
 procedure(bar), pointer :: foo
 foo => bar
end

This problem was found by Tobias.


-- 
   Summary: procedure pointer assignment to abstract interface
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janus at gcc dot gnu dot org


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

[Bug libstdc++/38399] money_get<> read decimal point when frac_digits() <= 0

[paolo at gcc dot gnu dot org]

--- Comment #5 from paolo at gcc dot gnu dot org  2008-12-05 18:24 ---
Subject: Bug 38399

Author: paolo
Date: Fri Dec  5 18:23:39 2008
New Revision: 142487

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142487
Log:
2008-12-05  Paolo Carlini  <[EMAIL PROTECTED]>

PR libstdc++/38399
* include/bits/locale_facets_nonio.tcc (money_get<>::
_M_extract(iter_type, iter_type, ios_base&, ios_base::iostate&,
string&)): Fix, reject decimal point when frac_digits <= 0.
* testsuite/22_locale/money_get/get/char/38399.cc: New.
* testsuite/22_locale/money_get/get/wchar_t/38399.cc: Likewise.
* testsuite/22_locale/money_get/get/char/5.cc: Adjust.
* testsuite/22_locale/money_get/get/wchar_t/5.cc: Likewise.

Added:
trunk/libstdc++-v3/testsuite/22_locale/money_get/get/char/38399.cc
trunk/libstdc++-v3/testsuite/22_locale/money_get/get/wchar_t/38399.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/locale_facets_nonio.tcc
trunk/libstdc++-v3/testsuite/22_locale/money_get/get/char/5.cc
trunk/libstdc++-v3/testsuite/22_locale/money_get/get/wchar_t/5.cc


-- 


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

[Bug libstdc++/38399] money_get<> read decimal point when frac_digits() <= 0

[paolo dot carlini at oracle dot com]

--- Comment #6 from paolo dot carlini at oracle dot com  2008-12-05 18:25 
---
Fixed for 4.4.0.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.4.0
Version|unknown |4.3.0


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

[Bug fortran/38415] procedure pointer assignment to abstract interface

[janus at gcc dot gnu dot org]

--- Comment #1 from janus at gcc dot gnu dot org  2008-12-05 18:48 ---
Btw ifort 11 accepts this, while the g95 version I have (from Sep. 5 2008)
gives an ICE.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |janus at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-12-05 18:48:50
   date||


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

[Bug c/38416] New: c-parser.c puts pragma_kind as a 7 bit field, when 8 will generate better code

[gnu at the-meissners dot org]

I was modifying the named address support to add the named address keywords via
the C keyword tables rather than via a target hook, and I noticed the c_token
structure has pragma_kind as a 7 bit field.  All of the previous bit fields are
8 bits in size, and next field is a tree, so we are not saving any space by
declaring the field to be 7 bits instead of 8, which would allow byte
loads/stores to be used to access the field.  Here is the declaration.

typedef struct c_token GTY (())
{
  /* The kind of token.  */
  ENUM_BITFIELD (cpp_ttype) type : 8;
  /* If this token is a CPP_NAME, this value indicates whether also
 declared as some kind of type.  Otherwise, it is C_ID_NONE.  */
  ENUM_BITFIELD (c_id_kind) id_kind : 8;
  /* If this token is a keyword, this value indicates which keyword.
 Otherwise, this value is RID_MAX.  */
  ENUM_BITFIELD (rid) keyword : 8;
  /* If this token is a CPP_PRAGMA, this indicates the pragma that
 was seen.  Otherwise it is PRAGMA_NONE.  */
  ENUM_BITFIELD (pragma_kind) pragma_kind : 7;
  /* The value associated with this token, if any.  */
  tree value;
  /* The location at which this token was found.  */
  location_t location;
} c_token;


-- 
   Summary: c-parser.c puts pragma_kind as a 7 bit field, when 8
will generate better code
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gnu at the-meissners dot org
 GCC build triplet: x86_64-gnu-linux
  GCC host triplet: x86_64-gnu-linux
GCC target triplet: x86_64-gnu-linux


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

[Bug c/38416] c-parser.c puts pragma_kind as a 7 bit field, when 8 will generate better code

[gnu at the-meissners dot org]

--- Comment #1 from gnu at the-meissners dot org  2008-12-05 19:17 ---
Created an attachment (id=16833)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16833&action=view)
Trivial patch to fix the problem.


-- 


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

[Bug ada/38229] FAIL: c954a01

[danglin at gcc dot gnu dot org]

--- Comment #1 from danglin at gcc dot gnu dot org  2008-12-05 19:37 ---
This test only fails when run with the test harness.


-- 


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

[Bug target/36539] IRA+i386 doesn't allocate asm output being returned to eax

[astrange at ithinksw dot com]

--- Comment #8 from astrange at ithinksw dot com  2008-12-05 20:08 ---
With some recent changes IRA makes better decisions now but they don't survive
reload.

Using
> /gcc -O3 -fomit-frame-pointer -fno-pic -fdump-rtl-ira -S cabac-ret.i

I get about the same asm and this in the IRA dump:
 Allocnos coloring:


  Loop 0 (parent -1, header bb0, depth 0)
bbs: 2
all: 0r64 1r58 2r62 3r59 4r60 5r63
modified regnos: 58 59 60 62 63 64
border:
Pressure: GENERAL_REGS=6
Reg 58 of GENERAL_REGS has 2 regs less
Reg 62 of GENERAL_REGS has 2 regs less
Reg 59 of GENERAL_REGS has 2 regs less
Reg 60 of GENERAL_REGS has 2 regs less
Reg 63 of GENERAL_REGS has 2 regs less
  Pushing a0(r64,l0)
  Pushing a3(r59,l0)(potential spill: pri=2857, cost=2)
  Pushing a1(r58,l0)
  Pushing a5(r63,l0)
  Pushing a2(r62,l0)
  Pushing a4(r60,l0)
  Popping a4(r60,l0)  -- assign reg 3
  Popping a2(r62,l0)  -- assign reg 4
  Popping a5(r63,l0)  -- assign reg 0 <- "r"(state)
  Popping a1(r58,l0)  -- assign reg 0 <- "=&r"(bit)
  Popping a3(r59,l0)  -- assign reg 5
  Popping a0(r64,l0)  -- assign reg 0 <- returned bit&1

a1 and a5 should be conflicting, since a1 is an earlyclobber output and can't
share a register with any of the inputs. reload fixes this by moving it to a
worse register. 


-- 


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

[Bug ada/38229] ACATS c954a01

[laurent at guerby dot net]

--- Comment #2 from laurent at guerby dot net  2008-12-05 20:10 ---
This also fails on powerpc-unknown-linux-gnu according to:

http://lists.debian.org/debian-gcc/2008/11/msg00080.html


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 CC||laurent at guerby dot net
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2008-12-05 20:10:08
   date||
Summary|FAIL:   c954a01 |ACATS c954a01


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

[Bug debug/38390] Missing DW_TAG_imported_module

[dodji at gcc dot gnu dot org]

--- Comment #1 from dodji at gcc dot gnu dot org  2008-12-05 20:27 ---
It looks like this is due to the fact that f contains no statement considered
"meaningful" by the front end. So, no BIND_EXPR node is being generated for its
body, so no debug info is being generated for its body either.

For instance, in the example below:

namespace A
  {
int v;
  }

int
f ()
{
  int i = 0;
  using namespace A;
  return v;
}

the DW_AT_imported_module is being generated correctly.


-- 


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

[Bug debug/38390] Missing DW_TAG_imported_module

[dodji at gcc dot gnu dot org]

--- Comment #2 from dodji at gcc dot gnu dot org  2008-12-05 20:29 ---
Created an attachment (id=16834)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16834&action=view)
A candidate patch

This patch seems to fix the problem. I haven't tried to make it pass regtests
yet though.


-- 


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

[Bug other/28614] gcc.c-torture/compile/20001226-1.c times out

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca  2008-12-05 
20:42 ---
Subject: Re:  gcc.c-torture/compile/20001226-1.c times out

> --- Comment #3 from sje at cup dot hp dot com  2008-12-05 17:16 ---
> Dave, I added a dg-timeout-factor to this test for HPPA so it shouldn't time
> out on PA boxes anymore.  I hadn't noticed the x86 timeout part of the report
> when I first looked at it.  Do you still have that problem?  If so we can
> change the test to increase the timeout there too or, if you don't have that
> problem anymore we can just close this bug out since it should be fixed on PA
> now.

I haven't done a GCC build recently on this x86 system but I don't
believe there is a timeout problem with this test on most x86 systems.

Instead of just arbitrarily increasing the timeout values, I tend to think
timeout values should be scaled based on the time for some base compilation.
It also would be nice to keep execution time records for certain benchmark
tests to that it might be possible to detect regressions in compilation
speed.

Dave


-- 


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

[Bug fortran/38389] (DE)ALLOCATE compile time check for same variable

[kargl at gcc dot gnu dot org]

--- Comment #1 from kargl at gcc dot gnu dot org  2008-12-05 21:02 ---
I'll take this as part of the [de]allocate work.  Note, this also causes a
segfault with all versions of gfortran

program a
  implicit none
  integer, allocatable :: i(:)
  allocate(i(4))
  deallocate(i, stat=i(1))
end program a

My current patch does

troutmask:sgk[254] gfc4x -o z b.f90
b.f90:6.22:

  deallocate(i, stat=i(1))
 1
Error: stat-variable at (1) shall not be deallocated within the same DEALLOCATE
statement


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |kargl at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-12-05 21:02:59
   date||


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

[Bug c/38416] c-parser.c puts pragma_kind as a 7 bit field, when 8 will generate better code

[meissner at gcc dot gnu dot org]

--- Comment #2 from meissner at gcc dot gnu dot org  2008-12-05 21:06 
---
Subject: Bug 38416

Author: meissner
Date: Fri Dec  5 21:05:14 2008
New Revision: 142493

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142493
Log:
PR c/38416, make pragma_kind 8 bits

Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-parser.c


-- 


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

[Bug c++/35336] Broken diagnostic: 'bit_field_ref' not supported by dump_expr

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2008-12-05 21:11 ---
Subject: Bug 35336

Author: jakub
Date: Fri Dec  5 21:10:16 2008
New Revision: 142497

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142497
Log:
PR c++/35336
* c-pretty-print.c (pp_c_postfix_expression): Handle BIT_FIELD_REF.
(pp_c_expression): Likewise.

* error.c (dump_expr): Handle BIT_FIELD_REF.

* g++.dg/other/error30.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/other/error30.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-pretty-print.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/error.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/38389] (DE)ALLOCATE compile time check for same variable

[kargl at gcc dot gnu dot org]

--- Comment #2 from kargl at gcc dot gnu dot org  2008-12-05 21:24 ---
I have a patch for the original problem.

deallocate_alloc_opt_1.f90:23.14-17:

  deallocate(i, i)
 1  2
Error: Allocate-object at (1) also appears at (2)


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||sgk at troutmask dot apl dot
   ||washington dot edu


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

[Bug middle-end/38418] New: FAIL: gcc.dg/union-5.c execution test

[danglin at gcc dot gnu dot org]

Executing on host: /mnt/gnu/gcc/objdir/gcc/xgcc -B/mnt/gnu/gcc/objdir/gcc/
/mnt/
gnu/gcc/gcc/gcc/testsuite/gcc.dg/union-5.c   -O -fgcse -fno-split-wide-types
-fn
o-show-column  -lm   -o ./union-5.exe(timeout = 300)
PASS: gcc.dg/union-5.c (test for excess errors)
Setting LD_LIBRARY_PATH to :/mnt/gnu/gcc/objdir/gcc::/mnt/gnu/gcc/objdir/gcc
FAIL: gcc.dg/union-5.c execution test


-- 
   Summary: FAIL: gcc.dg/union-5.c execution test
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa2.0w-hp-hpux11.11
  GCC host triplet: hppa2.0w-hp-hpux11.11
GCC target triplet: hppa2.0w-hp-hpux11.11


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

[Bug c++/38410] g++.dg/eh/crossjump1.C (internal compiler error)

[janis at gcc dot gnu dot org]

--- Comment #1 from janis at gcc dot gnu dot org  2008-12-05 21:36 ---
The failures also happen for powerpc64-unknown-linux-gnu, both -m32 and -m64. 
They start with r142418.


-- 


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

[Bug middle-end/38418] FAIL: gcc.dg/union-5.c execution test

[danglin at gcc dot gnu dot org]

--- Comment #1 from danglin at gcc dot gnu dot org  2008-12-05 21:41 ---
0x2b40 : stw rp,-14(sp)
0x2b44 : cmpib,= 0,r26,0x2b54 
0x2b48 : ldo 40(sp),sp
0x2b4c :b,l 0x2b28 ,rp
0x2b50 :nop
0x2b54 :b,l 0x2b28 ,rp
0x2b58 :nop
0x2b5c :nop


-- 


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

[Bug target/38419] New: [4.3 Regression] ICE (SIGSEGV) with -O

[doko at ubuntu dot com]

seen with 4.3 20081029, not seen with 4.2 and trunk, builds with -O0

$ g++ -Wall -g -O1 -pthread -c DjVuAnno.ii -fPIC
DjVuAnno.cpp: In static member function 'static DJVU::GPList
DJVU::DjVuANT::get_map_areas(DJVU::GLParser&)':
DjVuAnno.cpp:1261: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.


-- 
   Summary: [4.3 Regression] ICE (SIGSEGV) with -O
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: doko at ubuntu dot com
GCC target triplet: arm-linux-gnueabi


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

[Bug target/38419] [4.3 Regression] ICE (SIGSEGV) with -O

[doko at ubuntu dot com]

--- Comment #1 from doko at ubuntu dot com  2008-12-05 21:45 ---
Created an attachment (id=16837)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16837&action=view)
preprocessed source


-- 


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

[Bug rtl-optimization/38272] [4.4 Regression] Revision 142207 caused libgomp.fortran/threadprivate2.f90

[hjl at gcc dot gnu dot org]

--- Comment #10 from hjl at gcc dot gnu dot org  2008-12-05 21:45 ---
Subject: Bug 38272

Author: hjl
Date: Fri Dec  5 21:44:32 2008
New Revision: 142499

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142499
Log:
2008-12-05  Ian Lance Taylor  <[EMAIL PROTECTED]>
H.J. Lu  <[EMAIL PROTECTED]>

PR rtl-optimization/38272
* reload1.c (do_input_reload): Don't use a register spill for
memory.

Modified:
branches/ira-merge/gcc/ChangeLog.ira
branches/ira-merge/gcc/reload1.c


-- 


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

[Bug middle-end/38418] FAIL: gcc.dg/union-5.c execution test

[ebotcazou at gcc dot gnu dot org]

--- Comment #2 from ebotcazou at gcc dot gnu dot org  2008-12-05 21:48 
---
Fixed this morning. :-)


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug testsuite/38420] New: gcc.target/i386/pr37248-2.c doesn't work on ia32

[hjl dot tools at gmail dot com]

I got

+FAIL: gcc.target/i386/pr37248-2.c scan-tree-dump optimized "& 3758096391[^
+FAIL: gcc.target/i386/pr37248-3.c scan-tree-dump optimized "& 3766484487[^

on Fedora 9/ia32. I saw

;; Function foo (foo)

Analyzing Edge Insertions.
foo (struct S x)
{
:
 return (BIT_FIELD_REF  & 0x0e007) == 0x0e007;

}

0x0e007 is the same as 3758096391.


-- 
   Summary: gcc.target/i386/pr37248-2.c doesn't work on ia32
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
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=38420

[Bug libstdc++/38421] New: libstdc++-v3/include/tr1/ell_integral.tcc contains __ea identifier

[gnu at the-meissners dot org]

The SPU port is adding support for named address spaces, and will be adding the
__ea keyword as a type qualifier.  At the moment, the named address support is
for C only, but at some point in the future, it might be desirable to add named
address support to C++ as well.  If C++ support is added, then the
libstdc++-v3/include/tr1/ell_integral.tcc file needs to be changed to not use
the __ea identifier.


-- 
   Summary: libstdc++-v3/include/tr1/ell_integral.tcc contains __ea
identifier
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gnu at the-meissners dot org
 GCC build triplet: x86_64-gnu-linux
  GCC host triplet: x86_64-gnu-linux
GCC target triplet: spu-elf


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

[Bug rtl-optimization/38272] [4.4 Regression] Revision 142207 caused libgomp.fortran/threadprivate2.f90

[hjl at gcc dot gnu dot org]

--- Comment #11 from hjl at gcc dot gnu dot org  2008-12-06 00:56 ---
Subject: Bug 38272

Author: hjl
Date: Sat Dec  6 00:54:47 2008
New Revision: 142513

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142513
Log:
2008-12-05  Bernd Schmidt  <[EMAIL PROTECTED]>

PR rtl-optimization/38272
* reload1.c (choose_reload_regs): Keep reload_spill_index correct
in all cases.

Modified:
branches/ira-merge/gcc/ChangeLog.ira
branches/ira-merge/gcc/reload1.c


-- 


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