[Bug bootstrap/25672] [4.1/4.2/4.3 regression] cross build's libgcc picks up CFLAGS

[bonzini at gnu dot org]

--- Comment #21 from bonzini at gnu dot org  2008-02-21 08:13 ---
fixed in 4.4.0


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

  Known to work|4.0.2   |4.0.2 4.4.0
Summary|[4.1/4.2/4.3/4.4 regression]|[4.1/4.2/4.3 regression]
   |cross build's libgcc picks  |cross build's libgcc picks
   |up CFLAGS   |up CFLAGS


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

[Bug c/28319] sentinel attribute should support non-NULL sentinels

[ludo at gnu dot org]

--- Comment #2 from ludo at gnu dot org  2008-02-21 09:00 ---
(In reply to comment #1)
> The only time I can think this comes up is that the sentinel is -1.

As another example, GNU Guile has a number of variadic functions (e.g.,
`scm_list_n ()') whose sentinel is `SCM_UNDEFINED' (which happens to be 2^8 +
4).  It would be great to be able to specify that value as a second (optional)
argument to the `sentinel' attribute.

Ludovic.


-- 

ludo at gnu dot org changed:

   What|Removed |Added

 CC||ludo at gnu dot org


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

[Bug bootstrap/35273] [4.3 Regression] Bootstrap of mingw32 using non-MSYS shell broken

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||build
   Priority|P3  |P1
   Last reconfirmed|-00-00 00:00:00 |2008-02-21 09:24:07
   date||
Summary|[4.3.0  regression] |[4.3 Regression] Bootstrap
   |Bootstrap of mingw32 using  |of mingw32 using  non-MSYS
   |non-MSYS shell broken   |shell broken
   Target Milestone|--- |4.3.0


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

[Bug fortran/35276] New: Doc should described how to compile mixed-language programs

[fxcoudert at gcc dot gnu dot org]

I think "Part I: Invoking GNU Fortran" of the gfortran documentation should
have a section on "Compiling (and linking) mixed-language programs". Whether
this should be a section or a subsection I don't know, but it's really a
commonly asked question and we ought to have explanations and examples of that
in the doc.


-- 
   Summary: Doc should described how to compile mixed-language
programs
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: documentation
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org


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

[Bug fortran/35276] Doc should described how to compile mixed-language programs

[fxcoudert at gcc dot gnu dot org]

--- Comment #1 from fxcoudert at gcc dot gnu dot org  2008-02-21 10:07 
---
I've posted explanations and examples on comp.lang.fortran that might be used
as a starting point:
http://groups.google.com/group/comp.lang.fortran/msg/a62f1aa0c1592838

Linking to C++ and other languages might also be interesting. Also, when
documentation about our calling conventions is written, we can link these two
parts.

PS: Maybe we should also add information on how to create shared libraries of
gfortran-compiled Fortran code? Or is that too generic to be in our doc?


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-02-21 10:07:41
   date||


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

[Bug fortran/34685] Honour parentheses in expressions

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-02-21 09:53 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   Keywords||patch, wrong-code
 Resolution||FIXED
Summary|[patch] Honour parentheses  |Honour parentheses in
   |in expressions  |expressions
   Target Milestone|--- |4.4.0


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

[Bug c++/35275] New: Operator<< for embedded class of templetized class isn't found

[yuri at tsoft dot com]

The following code produces an error on the second line inside of main:
error: no match for 'operator<<' in 'std::cout << C::E()'
C++ frontend fails to find the templetized operator<<.

-- begin code 

#include 
using namespace std;

template
struct C {
  struct E {
  };
};

template
ostream& operator<<(ostream &ss, const C &t) {
  return (ss);
}

template
ostream& operator<<(ostream &ss, const typename C::E &t) {
  return (ss);
}

main() {
  cout << C(); // this compiles ok
  cout << C::E();  // this fails
}


-- 
   Summary: Operator<< for embedded class of templetized class isn't
found
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com


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

[Bug fortran/35259] -fassociative-math not enabled by default; No option to associate with PAREN_EXPRs

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-02-21 09:56 ---
Summary slightly changed.  There are two issues now:

 - We still do not allow re-association by default, even if we would honor
   PAREN_EXPR

 - There is no way to allow re-association in the face of PAREN_EXPR


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
Summary|PAREN_EXPR: Option to allow |-fassociative-math not
   |for reassociation   |enabled by default;  No
   ||option to associate with
   ||PAREN_EXPRs
Version|4.3.0   |4.4.0


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

[Bug fortran/35276] Doc should described how to compile mixed-language programs

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement


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

[Bug target/35264] [4.3/4.4 regression] ntfs-3g miscompiled

[cnstar9988 at gmail dot com]

--- Comment #3 from cnstar9988 at gmail dot com  2008-02-21 10:26 ---
confirmed.

Checked out revision 132515
gcc version 4.3.0 20080221 (prerelease) (GCC)
gcc -O1 -m32 test.c

aborted.


-- 


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

[Bug target/35264] [4.3/4.4 regression] ntfs-3g miscompiled

[matz at gcc dot gnu dot org]

--- Comment #5 from matz at gcc dot gnu dot org  2008-02-21 12:39 ---
Subject: Bug 35264

Author: matz
Date: Thu Feb 21 12:38:35 2008
New Revision: 132521

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132521
Log:
PR target/35264
* config/i386/i386.c (ix86_expand_branch): Add missing breaks.

* gcc.dg/pr35264.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/pr35264.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/35264] [4.3/4.4 regression] ntfs-3g miscompiled

[matz at gcc dot gnu dot org]

--- Comment #6 from matz at gcc dot gnu dot org  2008-02-21 12:41 ---
Fixed in 4.3 and trunk.


-- 

matz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug target/35264] [4.3/4.4 regression] ntfs-3g miscompiled

[matz at gcc dot gnu dot org]

--- Comment #4 from matz at gcc dot gnu dot org  2008-02-21 12:30 ---
Subject: Bug 35264

Author: matz
Date: Thu Feb 21 12:30:00 2008
New Revision: 132520

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132520
Log:
PR target/35264
* config/i386/i386.c (ix86_expand_branch): Add missing breaks.

* gcc.dg/pr35264.c: New testcase.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/pr35264.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/config/i386/i386.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

[tege-gcc at swox dot com]

--- Comment #2 from tege-gcc at swox dot com  2008-02-21 13:49 ---
Created an attachment (id=15196)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15196&action=view)
Alignment test

This is not a strictly correct test case, it may fail even if
the compiler aligns the stack properly, and it may pass even
if the compiler does not correctly align the stack.  One needs
to read the assembly output to verify that a failure is due to
bad stack alignment.

The idea is to check that two subsequent invocations of foo
places a local variable at the same alignment mod 16.  If the
stack is aligned at 8 mod 16 as it should directly after the
call instruction, any local variable should get the same mod
16 alignment every time.

gcc 4.2.2 as well as gcc 4.2.3 fails this test on both Darwin
and FreeBSD.  The reason is that foo allocates 16 bytes on the
stack, plus the 8 bytes implicitly allocated by call.  This
means the ABI required stack alignment of 16 is not maintained.

$ gcc -O -m64 foo.c  && ./a.out
Abort trap: 6 (core dumped)


-- 


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

[Bug c/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

[tege-gcc at swox dot com]

--- Comment #4 from tege-gcc at swox dot com  2008-02-21 13:57 ---
(From update of attachment 15196)
#include 

long align;

foo (int flag)
{
  int variable;
  if (flag == 0)
return (((long)&variable ^ align) & 0xf);
  align = (long)&variable;
  foo (flag - 1);
}

main ()
{
  if (foo (1) != 0)
abort ();
  exit (0);
}


-- 


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

[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate

[fxcoudert at gcc dot gnu dot org]

--- Comment #13 from fxcoudert at gcc dot gnu dot org  2008-02-21 14:12 
---
Still there with on trunk (4.4) and MacOS 10.5.2:

$ cat s.c
int main (void)
{
  long double x;
  double y;

  x = -0.24; y = x;
  __builtin_printf ("%g %g %g\n", (float) __builtin_asinl(x),
(float) __builtin_asin(y),
(float) (__builtin_asinl(x) - __builtin_asin(y)));
}

$ ./bin/gcc s.c && ./a.out
-0.242366 -0.242366 0.5

asin() and asinl() values are very close, but their difference is output as
0.5. Adding a simple #include  on top of this makes it pass:

$ cat s2.c
#include 
int main (void)
{
  long double x;
  double y;

  x = -0.24; y = x;
  __builtin_printf ("%g %g %g\n", (float) __builtin_asinl(x),
(float) __builtin_asin(y),
(float) (__builtin_asinl(x) - __builtin_asin(y)));
}
$ ./bin/gcc s2.c && ./a.out
-0.242366 -0.242366 -8.82009e-18


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.2.0 4.3.0 4.4.0
   Last reconfirmed|2007-01-14 22:24:04 |2008-02-21 14:12:02
   date||
Version|4.2.0   |4.4.0


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

[Bug libfortran/32841] [4.3/4.4 regression] HUGE(1.0_16) output as +Infinity on ppc-darwin8 (gfortran.dg/large_real_kind_2.F90)

[fxcoudert at gcc dot gnu dot org]

--- Comment #28 from fxcoudert at gcc dot gnu dot org  2008-02-21 13:50 
---
That 27-headed (and counting!) monster PR is really hard to deal with. Here is
some more information:

  -- On powerpc-apple-darwin-9.2.0 (MacOS 10.5.2), the testcases in comments #0
(original report) and #10 gives correct results.

  -- On powerpc-apple-darwin-9.2.0, however, the following C testcase:

#include 
#include 
#include 

int main ()
{
  if (!isfinite(LDBL_MAX))
puts("LDBL_MAX should be finite!");
}

gives wrong results (printing out "LDBL_MAX should be finite!") with gcc-4.4
and the system gcc 4.0.1 (Apple Inc. build 5465). It works with the system gcc
3.3 20030304 (Apple Computer, Inc. build 1823). I've submitted it to Apple as
#5757007.

  -- On powerpc-apple-darwin-9.2.0, HAVE_BROKEN_ISFINITE is not set, while
clearly it should! Digging out, it is because the testcase is run without
including math.h, and that makes it work (ie, if in the C testcase above, you
remove the line including , the testcase passes!). Why HAVE_MATH_H is
not defined is beyond my understanding, but since it's the only place in
libgfortran where we actually worry about it, I suggest we simply remove it.

  -- Working around the isfinite() bug above is possible by using
__builtin_isfinite(), which works fine. I think, however, we can't do that
unconditionally as, IIRC, not all targets are able to expand
__builtin_isfinite().


-- 


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

[Bug c/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

[tege-gcc at swox dot com]

--- Comment #5 from tege-gcc at swox dot com  2008-02-21 14:01 ---
The attachment is not the right file.
I tried to "edit" it but I cannot find out how to do it.
The proper test case is in the comment before this one.
Sorry, I am bugzilla challenged.


-- 


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

[Bug c/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

[tege-gcc at swox dot com]

--- Comment #3 from tege-gcc at swox dot com  2008-02-21 13:53 ---
  Testcase?  Because we do align it for both x86_64-* and i386-darwin.

Well, not as mandated in the 64-bit ABI.

  Now the SVSV i386 ABI says it should be aligned at 4 (word)
  bytes boundary.

This is hardly relevant, since that is a 32-bit ABI.

A test case is difficult to produce, since it is seems hard
to write anything portable.  I made an attempt though, please
see comment attached to it.


-- 


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

[Bug other/35277] New: x86_64 configure option combo yields broken compiler

[joel at gcc dot gnu dot org]

This might be a dumb user error but since it works on 32-bit Fedora's, I
thought it best to file a PR and let you folks decide.

On Fedora 7 or 8, when you configure like this, the libgcc_s.o files do not
end up in an install directory that gcc can find afterwards.  So you end up
getting a link error on the simplest programs.

  ../../gcc-${gcc}/configure --with-gnu-as --disable-multilib \
--with-gnu-ld --verbose --with-system-zlib --disable-nls \
--enable-version-specific-runtime-libs \
--enable-languages=c,ada --prefix=${install_dir} 

I haven't tried every set of options but reducing it to the
following produced a working compiler.

 ../../gcc-${gcc}/configure \
--enable-languages=c,ada --prefix=${install_dir}


-- 
   Summary: x86_64 configure option combo yields broken compiler
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
  GCC host triplet: x86_64-unknown-linux-gnu


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

[Bug other/35277] x86_64 configure option combo yields broken compiler

[rwild at gcc dot gnu dot org]

--- Comment #1 from rwild at gcc dot gnu dot org  2008-02-21 15:32 ---


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


-- 

rwild at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c/32415] libgcc_s not found in library search path with --enable-version-specific-runtime-libs

[rwild at gcc dot gnu dot org]

--- Comment #6 from rwild at gcc dot gnu dot org  2008-02-21 15:32 ---
*** Bug 35277 has been marked as a duplicate of this bug. ***


-- 

rwild at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||joel at gcc dot gnu dot org


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

[Bug rtl-optimization/34522] inefficient code for long long multiply when only low bits are needed

[ubizjak at gmail dot com]

--- Comment #4 from ubizjak at gmail dot com  2008-02-21 15:41 ---
(In reply to comment #1)
> Prototype untested patch.  Produces

Paolo, do you plan to test your patch and submit it to gcc-patches@ ?


-- 


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

[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate

[rguenth at gcc dot gnu dot org]

--- Comment #14 from rguenth at gcc dot gnu dot org  2008-02-21 15:48 
---
How does the header manage to fix this?


-- 


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

[Bug rtl-optimization/33009] -frtl-abstract-sequences causes an infinite loop

[loki at gcc dot gnu dot org]

--- Comment #3 from loki at gcc dot gnu dot org  2008-02-21 15:48 ---
I can confirm the infinite loop too (r132521).
I am going to look into it.


-- 

loki at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||loki at gcc dot gnu dot org
 AssignedTo|unassigned at gcc dot gnu   |loki at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-02-21 15:48:53
   date||


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

[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate

[pinskia at gcc dot gnu dot org]

--- Comment #15 from pinskia at gcc dot gnu dot org  2008-02-21 15:50 
---
(In reply to comment #14)
> How does the header manage to fix this?

The normal functions have the asm extension on them which causes the builtins
to change also.

-- Pinski


-- 


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

[Bug rtl-optimization/34522] inefficient code for long long multiply when only low bits are needed

[bonzini at gnu dot org]

--- Comment #5 from bonzini at gnu dot org  2008-02-21 15:52 ---
I want to clear 17236 first (and Jakub's tweaks are needed anyway).

Feel free to beat me to it.


-- 


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

[Bug c/32415] libgcc_s not found in library search path with --enable-version-specific-runtime-libs

[rwild at gcc dot gnu dot org]

-- 

rwild at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail||4.2.3 4.3.0 4.4.0
   Last reconfirmed|-00-00 00:00:00 |2008-02-21 15:35:27
   date||


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

[Bug c/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2008-02-21 15:53 ---
>  int variable;

This variable does not have be aligned 16byte.

>  long long ebi, windowsize, last_windowsize;

Or even these.

The first one is word aligned.  The second one just has to be 8 byte aligned.


-- 


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

[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate

[bonzini at gnu dot org]

--- Comment #16 from bonzini at gnu dot org  2008-02-21 16:32 ---
So this line of add_builtin_function

  tree libname = get_identifier (library_name);

should instead invoke a target hook (defaulting to get_identifier)?


-- 


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

[Bug rtl-optimization/33009] -frtl-abstract-sequences causes an infinite loop

[aldot at gcc dot gnu dot org]

--- Comment #4 from aldot at gcc dot gnu dot org  2008-02-21 16:44 ---
-frtl-abstract-sequences should IMHO be turned on per default for at least -Os
in 4.4

Otherwise literally nobody will notice if it's broken.
thanks,


-- 


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

[Bug libstdc++/34797] [parallel mode] Settings are separated for each compilation unit

[pcarlini at suse dot de]

--- Comment #7 from pcarlini at suse dot de  2008-02-21 17:06 ---
I understand this is fixed now. Otherwise, please reopen (and sorry ;)


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.3.0


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

[Bug c++/35278] New: extern declaration causes uninitialized reference to go unnoticed

[appfault at hotmail dot com]

The following program correctly generates an error:
---
int& g_foo;
---
$ ~/gcc/bin/g++ -c -Wall test.cpp
test.cpp:1: error: 'g_foo' declared as reference but not initialized

The following program fails to generate an error (which seemingly is a
violation of the C++ standard) but also doesn't even generate a warning, even
with -Wall.
---
extern int& g_foo;
int& g_foo;
---
$ ~/gcc/bin/g++ -c -Wall test.cpp
$

At this point g_foo is a null reference, without having ever dereferenced a
null pointer, which also seemingly is a violation of the C++ standard.

This is the case with some older gcc versions I tried - seemingly not a
regression, at least not a recent one.


-- 
   Summary: extern declaration causes uninitialized reference to go
unnoticed
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: appfault at hotmail dot com


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

[Bug libstdc++/35256] Bad link on http://gcc.gnu.org/onlinedocs/libstdc++/parallel_mode.html

[bkoz at gcc dot gnu dot org]

--- Comment #2 from bkoz at gcc dot gnu dot org  2008-02-21 16:52 ---

Mine. I need to redo this page anyway.


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |bkoz at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-02-20 21:14:52 |2008-02-21 16:52:28
   date||


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

[Bug target/29660] get 'internal compiler error' when building numerical recipes

[fxcoudert at gcc dot gnu dot org]

--- Comment #6 from fxcoudert at gcc dot gnu dot org  2008-02-21 18:44 
---
gfortran-4.0.1 is really old, this code works fine for 4.3.0 so I suggest we
close it as WONTFIX. Please reopen if you can reproduce this with a more recent
compiler.

Thanks for the bug report.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX
   Target Milestone|--- |4.3.0


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

[Bug target/10901] non-local goto's don't work on powerpc-darwin

[fxcoudert at gcc dot gnu dot org]

--- Comment #17 from fxcoudert at gcc dot gnu dot org  2008-02-21 18:47 
---
(In reply to comment #16)
> Our positron branch has the fix for this in it.  We should dig it out and
> submit it.

Mike, any news on that? You can still make it in time for the 5th anniversary
of this PR! :)


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org


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

[Bug bootstrap/35273] [4.3 Regression] Bootstrap of mingw32 using non-MSYS shell broken

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2008-02-21 19:34 ---
> Yes, it was approved by Jakub.

To be precise, approved by Paolo in
http://gcc.gnu.org/ml/gcc/2008-02/msg00410.html
and acked for 4.3 by me.

Anyway, AFAIK the http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00877.html patch
was approved by Paolo too, can one of you please commit that to the trunk/4.3?
branch?


-- 


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

[Bug target/10901] non-local goto's don't work on powerpc-darwin

[mrs at apple dot com]

--- Comment #18 from mrs at apple dot com  2008-02-21 19:48 ---
Nope.


-- 


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

[Bug c/35279] New: incorrect "array subscript is above array bounds" warning in loop at -O3

[rjpeters at klab dot caltech dot edu]

With -O3, I get an apparently incorrect "array subscript is above array bounds"
warning when a multidimensional array is passed to a function and accessed in a
loop:

$ /home/tmp/u/rjpeters/gcc-svn-install/bin/gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /home/tmp/u/rjpeters/gcc-svn/configure
--enable-languages=c,c++ --enable-checking=yes --enable-__cxa_atexit
--with-mpfr=/home/tmp/u/rjpeters/mpfr-2.2.1-install
--with-gmp=/home/tmp/u/rjpeters/gmp-4.2.1-install
--prefix=/home/tmp/u/rjpeters/gcc-svn-install
Thread model: posix
gcc version 4.4.0 20080220 (experimental) [trunk revision 129827] (GCC)

$ cat bug2.c
#include 

static void test1(char f[][64], const int n)
{
  int i;
  for (i = 0; i < n; ++i)
printf("%s", f[i]); /* warning here */
  printf("\n");
}

static void test2(char f[][64])
{
  int i;
  for (i = 0; i < 4; ++i)
printf("%s", f[i]); /* warning here */
  printf("\n");
}

static void test3(char f[][64])
{
  printf("%s", f[0]);
  printf("%s", f[1]);
  printf("%s", f[2]);
  printf("%s", f[3]); /* NOTE: no warning here */
  printf("\n");
}

int main()
{
  char f[4][64] = { "a", "b", "c", "d" };

  test1(f, 4);
  test2(f);
  test3(f);

  return 0;
}

$ /home/tmp/u/rjpeters/gcc-svn-install/bin/gcc -Wall -O3 bug2.c
bug2.c: In function ‘main’:
bug2.c:7: warning: array subscript is above array bounds
bug2.c:7: warning: array subscript is above array bounds
bug2.c:15: warning: array subscript is above array bounds
bug2.c:15: warning: array subscript is above array bounds

$ ./a.out
abcd
abcd
abcd

The fact that there are two warnings each at lines 7 and 14 suggests that
somehow the last two iterations of the unrolled loop are considered as
out-of-bounds; however, the generated code is apparently correct, at least
judging by the runtime output of the program.

I don't see these warnings with "gcc version 4.1.1 20060724 (prerelease)
(4.1.1-3mdk)".

Thanks,
Rob


-- 
   Summary: incorrect "array subscript is above array bounds"
warning in loop at -O3
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rjpeters at klab dot caltech dot edu
 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=35279

[Bug c/35279] incorrect "array subscript is above array bounds" warning in loop at -O3

[rjpeters at klab dot caltech dot edu]

--- Comment #1 from rjpeters at klab dot caltech dot edu  2008-02-21 19:47 
---
Created an attachment (id=15197)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15197&action=view)
test case; compile with "-Wall -O3"


-- 


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

[Bug bootstrap/35273] [4.3 Regression] Bootstrap of mingw32 using non-MSYS shell broken

[rwild at gcc dot gnu dot org]

--- Comment #5 from rwild at gcc dot gnu dot org  2008-02-21 19:57 ---
Subject: Bug 35273

Author: rwild
Date: Thu Feb 21 19:56:23 2008
New Revision: 132529

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132529
Log:
PR bootstrap/35273
* config.build (build_file_translate): Set to `CMD //c' only if
it works.
* Makefile.in (build_file_translate): Improve comment.

Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/Makefile.in
branches/gcc-4_3-branch/gcc/config.build


-- 


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

[Bug fortran/35280] New: ICE on invalid print statement

[keenanpepper at gmail dot com]

If you leave out the format of a print statement, as in

  program test

integer, parameter :: n = 2

print n

  end program test

...you get an ICE instead of an error message. I can't run the latest version
of gfortran now, so please close if this is already fixed.


-- 
   Summary: ICE on invalid print statement
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: keenanpepper at gmail dot com
 GCC build triplet: i386-redhat-linux
  GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux


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

[Bug bootstrap/35273] [4.3 Regression] Bootstrap of mingw32 using non-MSYS shell broken

[rwild at gcc dot gnu dot org]

--- Comment #6 from rwild at gcc dot gnu dot org  2008-02-21 20:05 ---
Subject: Bug 35273

Author: rwild
Date: Thu Feb 21 20:05:11 2008
New Revision: 132530

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132530
Log:
PR bootstrap/35273
* config.build (build_file_translate): Set to `CMD //c' only if
it works.
* Makefile.in (build_file_translate): Improve comment.

Modified:
branches/gcc-4_2-branch/gcc/ChangeLog
branches/gcc-4_2-branch/gcc/Makefile.in
branches/gcc-4_2-branch/gcc/config.build


-- 


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

[Bug bootstrap/35273] [4.3 Regression] Bootstrap of mingw32 using non-MSYS shell broken

[rwild at gcc dot gnu dot org]

--- Comment #7 from rwild at gcc dot gnu dot org  2008-02-21 20:07 ---
(In reply to comment #3)
> > Yes, it was approved by Jakub.
> 
> To be precise, approved by Paolo in
> http://gcc.gnu.org/ml/gcc/2008-02/msg00410.html
> and acked for 4.3 by me.

Yes, sorry for being imprecise.

> Anyway, AFAIK the http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00877.html 
> patch
> was approved by Paolo too, can one of you please commit that to the trunk/4.3?
> branch?

Yes, done now.  Also to 4.2 branch because it had the same problem
(I understand for that branch I don't need RM ack, and the patch was approved
for this branch).

I also improved the comment in Makefile.in as suggested by Danny.


-- 

rwild at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/35273] [4.3 Regression] Bootstrap of mingw32 using non-MSYS shell broken

[rwild at gcc dot gnu dot org]

--- Comment #4 from rwild at gcc dot gnu dot org  2008-02-21 19:56 ---
Subject: Bug 35273

Author: rwild
Date: Thu Feb 21 19:55:39 2008
New Revision: 132528

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132528
Log:
PR bootstrap/35273
* config.build (build_file_translate): Set to `CMD //c' only if
it works.
* Makefile.in (build_file_translate): Improve comment.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/config.build


-- 


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

[Bug rtl-optimization/35281] New: [4.3 regression] multiply with 0 generated for 64*32->64

[astrange at ithinksw dot com]

> /usr/local/gcc43/bin/gcc -v   
Using built-in specs.
Target: i386-apple-darwin9.2.0
Configured with: ../gcc/configure --prefix=/usr/local/gcc43
--enable-threads=posix --with-arch=core2 --with-tune=core2 --with-gmp=/sw
--with-mpfr=/sw --disable-nls --disable-bootstrap --enable-checking=yes,rtl
CFLAGS=-g LDFLAGS=/usr/lib/libiconv.dylib --enable-languages=c,c++,objc,obj-c++
Thread model: posix
gcc version 4.4.0 20080219 (experimental) (GCC) 
> /usr/local/gcc43/bin/gcc -Os -fno-PIC -S u64mul.c -fomit-frame-pointer

gcc generates:
_mul32:
pushl   %ebx
xorl%edx, %edx
subl$8, %esp
movl_b, %eax
movl_a, %ecx
movl_a+4, %ebx
imull   %edx, %ecx
imull   %eax, %ebx
mull_a
addl%ebx, %ecx
leal(%ecx,%edx), %edx
popl%ecx
popl%ebx
popl%ebx
ret

and somehow leaves all the stuff with edx in.
4.1.3 generates:
mul32:
movl_b, %eax
movl_a+4, %ecx
imull   %eax, %ecx
mull_a
addl%edx, %ecx
movl%ecx, %edx
ret

They both generate bad code for mul16.


-- 
   Summary: [4.3 regression] multiply with 0 generated for 64*32->64
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: astrange at ithinksw dot com
 GCC build triplet: i386-apple-darwin9.2.0
  GCC host triplet: i386-apple-darwin9.2.0
GCC target triplet: i386-apple-darwin9.2.0


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

[Bug c++/34824] [4.1/4.2 Regression] ICE with explicit copy constructor

[reichelt at gcc dot gnu dot org]

--- Comment #11 from reichelt at gcc dot gnu dot org  2008-02-21 21:07 
---
Adjust target milestone.


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

  GCC build triplet|4.1.2   |
   GCC host triplet|4.1.2   |
 GCC target triplet|4.1.2   |
   Target Milestone|4.1.3   |4.3.0


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

[Bug c++/35282] New: [4.3/4.4 regression] Template specialization rejected

[reichelt at gcc dot gnu dot org]

The following valid testcase is rejected on mainline and 4.3 branch:

=
template struct A
{
template void foo();
};

template<> template void A<0>::foo() {}
=

The regression was introduced between 2008-02-12 and 2008-02-15.

Paolo, this is probably fallout from your patch 

PR c++/28743
* pt.c (determine_specialization): In case of function templates,
when the type of DECL does not match FN there is no match.

The problem is related to PR14494.


-- 
   Summary: [4.3/4.4 regression] Template specialization rejected
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: rejects-valid, monitored
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
OtherBugsDependingO 14494
 nThis:


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

[Bug c++/35282] [4.3/4.4 regression] Template specialization rejected

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.3.0


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

[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate

[ubizjak at gmail dot com]

--- Comment #17 from ubizjak at gmail dot com  2008-02-21 21:28 ---
(In reply to comment #16)
> So this line of add_builtin_function
> 
>   tree libname = get_identifier (library_name);
> 
> should instead invoke a target hook (defaulting to get_identifier)?

And IMO http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25850#c6 should be wired
into this hook.


-- 


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

[Bug rtl-optimization/35281] [4.3 regression] multiply with 0 generated for 64*32->64

[ubizjak at gmail dot com]

--- Comment #1 from ubizjak at gmail dot com  2008-02-21 21:35 ---
I know that the test sources are probably trivial, but can you post them here
for reference?


-- 


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

[Bug tree-optimization/26069] [4.0/4.1/4.2/4.3/4.4 Regression] Runtime endian-ness check is no longer optimized out.

[ubizjak at gmail dot com]

--- Comment #21 from ubizjak at gmail dot com  2008-02-21 21:54 ---
(In reply to comment #20)

> Here are 2 alternatives I've been playing with:

Any news on this patch?


-- 


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

[Bug fortran/35280] ICE on invalid print statement

[dfranke at gcc dot gnu dot org]

--- Comment #1 from dfranke at gcc dot gnu dot org  2008-02-21 21:58 ---
Confirmed ICE with 4.1.2 and 4.2.4. However, 4.3 (20080210) gives:
pr35280.f90:3.7:

  print n
  1
Error: Constant expression in FORMAT tag at (1) must be of type default
CHARACTER

Closing.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  GCC build triplet|i386-redhat-linux   |
   GCC host triplet|i386-redhat-linux   |
 GCC target triplet|i386-redhat-linux   |
   Keywords||ice-on-invalid-code
  Known to fail||4.1.2 4.2.4
  Known to work||4.3.0
 Resolution||INVALID


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

[Bug rtl-optimization/35281] [4.3 regression] multiply with 0 generated for 64*32->64

[astrange at ithinksw dot com]

--- Comment #2 from astrange at ithinksw dot com  2008-02-21 21:58 ---
Created an attachment (id=15199)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15199&action=view)
source

Oh, I forgot.


-- 


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

[Bug c/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

[tege-gcc at swox dot com]

--- Comment #7 from tege-gcc at swox dot com  2008-02-21 22:01 ---
Sorry, but you ought to read and understand what I write before
you comment, otherwise it becomes rather pointless.


-- 


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

[Bug ada/35284] New: Branch to 0x0 from Ada run-time

[joel at gcc dot gnu dot org]

As reported in http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00747.html, I
am seeing a few hundred failures for ACATS on i386-rtems4.9.  The failure set
appears to be about the same for 5.3.4, 4.3-branch, and SVN trunk.  I am trying
to debug
this on the SVN trunk.  I have finally captured the failure and hope someone
can 
help me run down what is broken. This report focuses on a99006a.

I am running on qemu and by turning on its debugging I have  managed find that
the Ada run-time does an indirect jump to 0x0.  I will attach a symbol table
along with the compressed qemu.log.

The last few instructions before the jump to 0x0 involve a call to
system__soft_links__set_jmpbuf_address_soft so I set a breakpoint there.
On the 8th time it hits it, the address passed in is 0x0 and the backtrace
is this:

 Breakpoint 1, system.soft_links.set_jmpbuf_address_soft (addr=(system.address)
0x0) at s-soflin.adb:270
270procedure Set_Jmpbuf_Address_Soft (Addr : Address) is
(gdb) bt
#0  system.soft_links.set_jmpbuf_address_soft (addr=(system.address) 0x0) at
s-soflin.adb:270
#1  0x00117c52 in system.file_io.chain_file (file=0x14ffa0) at s-fileio.adb:166
#2  0x001119d8 in  () at a-textio.adb:2272
#3  0x001002ea in adainit () at
../../../../../../../../../423/rtems/c/src/lib/libbsp/i386/pc386/start/start.S:192
#4  0x0010036d in gnat_main () at
../../../../../../../../../423/rtems/c/src/lib/libbsp/i386/pc386/start/start.S:192
#5  0x0010039c in start_gnat_main ()
at
../../../../../../../../../423/rtems/c/src/lib/libbsp/i386/pc386/start/start.S:192
#6  0x00137107 in _Thread_Handler ()
at
../../../../../../../423/rtems/c/src/../../cpukit/score/src/threadhandler.c:151

It runs and does some more calls to that same routine but eventually we 
end up doing the indirect call to 0x0 from the middle of 
system__tasking__stages__task_wrapper

I have checked and memory is initialized to zero on this BSP in case this was
an issue and none of the tasks in this test are blowing their stacks.

Advice definitely appreciated on this one.


-- 
   Summary: Branch to 0x0 from Ada run-time
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
GCC target triplet: i386-rtems4.9


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

[Bug ada/35284] Branch to 0x0 from Ada run-time

[joel at gcc dot gnu dot org]

--- Comment #1 from joel at gcc dot gnu dot org  2008-02-21 22:10 ---
Created an attachment (id=15200)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15200&action=view)
QEMU trace up to branch to 0x0

Search for "^0x" and then scroll backwards to see the indirect call in
question.


-- 


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

[Bug ada/35284] Branch to 0x0 from Ada run-time

[joel at gcc dot gnu dot org]

--- Comment #2 from joel at gcc dot gnu dot org  2008-02-21 22:11 ---
Created an attachment (id=15201)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15201&action=view)
numerically sorted symbol table matching qemu.log

This is the numerically sorted symbol table matching the attached log.


-- 


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

[Bug ada/35284] Branch to 0x0 from Ada run-time

[laurent at guerby dot net]

--- Comment #3 from laurent at guerby dot net  2008-02-21 22:32 ---
The great majority of FAIL are tests with an Ada task so my guess is that
tasking is broken.

I'm not a specialist but GNAT soft links are pointers to function which are set
by the elaboration code to point to tasking or non-tasking version of several
runtime primitives, these are in s-soflin.ads. 

May be what you see is that elaboration for s-soflin.ads is not done at the
right time during elaboration so all pointers end up null hence the jump to
null. Might be a binder problem.

Could you try the following small tasking program:

-- begin t.adb
with GNAT.IO; use GNAT.IO;
procedure T is
   task A;
   task body A is
   begin
  Put_Line ("A");
   end A;
begin
   Put_Line ("T");
end T;
-- end t.adb

When I compile it on i386 native with gnatmake -g t.adb I see in the binder
generated b~t.adb :

 System.Restrictions'Elab_Spec;
  System.Restrictions'Elab_Body;
  E076 := True;
  Ada.Exceptions'Elab_Spec;
  System.Soft_Links'Elab_Body;
  E011 := True;
  System.Secondary_Stack'Elab_Body;
  E013 := True;
  System.Exception_Table'Elab_Body;
  E022 := True;
  Ada.Io_Exceptions'Elab_Spec;
  E082 := True;
  Ada.Tags'Elab_Spec;
  Ada.Tags'Elab_Body;
  E074 := True;
  Ada.Streams'Elab_Spec;
  E077 := True;
  Interfaces.C'Elab_Spec;
  E041 := True;
  System.Finalization_Root'Elab_Spec;
  E079 := True;
  System.Tasking.Initialization'Elab_Body;
  E084 := True;
  System.Tasking.Protected_Objects'Elab_Body;
  E090 := True;
  E018 := True;
  System.Finalization_Implementation'Elab_Spec;
  System.Finalization_Implementation'Elab_Body;
  E072 := True;
  Ada.Finalization'Elab_Spec;
  E096 := True;
  Ada.Finalization.List_Controller'Elab_Spec;
  E098 := True;
  System.Tasking.Protected_Objects.Entries'Elab_Spec;
  E094 := True;
  System.Tasking.Queuing'Elab_Body;
  E088 := True;
  System.Tasking.Stages'Elab_Body;
  E068 := True;


-- 


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

[Bug ada/35284] Branch to 0x0 from Ada run-time

[joel at gcc dot gnu dot org]

--- Comment #4 from joel at gcc dot gnu dot org  2008-02-21 22:52 ---
Runs OK on powerpc/psim and sparc/sis built from the same source tree for GCC
and RTEMS.

Fails like a99006a on i386. 

Are there only ~300 tests which rely on tasking?  I posted this URL:
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00747.html
to point out what was failing and passing in case there was a common
thread.ju

I am attaching the b~t.adb.  I don't know enough to comfortably judge whether
it is right or not.


-- 


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

[Bug ada/35284] Branch to 0x0 from Ada run-time

[joel at gcc dot gnu dot org]

--- Comment #5 from joel at gcc dot gnu dot org  2008-02-21 22:53 ---
Created an attachment (id=15202)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15202&action=view)
generated from Laurent's t.adb


-- 


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

[Bug c++/35282] [4.3/4.4 regression] Template specialization rejected

[pcarlini at suse dot de]

--- Comment #1 from pcarlini at suse dot de  2008-02-21 22:25 ---
Please double check, but I don't think it's my patch: I tried quickly reverting
it and interestingly nothing changes: 28743 doesn't ICE and this one is
rejected. It seems something new is going on in this area... Maybe Janis can
help with a regression hunt.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 CC||janis at gcc dot gnu dot org


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

[Bug c++/35282] [4.3/4.4 regression] Template specialization rejected

[pcarlini at suse dot de]

--- Comment #2 from pcarlini at suse dot de  2008-02-21 23:13 ---
Never mind, I did something wrong in my quick check. I can confirm it's my
patch. I'll try to look a bit into it, but beyond reverting it, I cannot
promise to be able to fix the present issue without regressing on 28743...


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 CC|janis at gcc dot gnu dot org|
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-02-21 23:13:46
   date||


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

[Bug fortran/35285] New: Failures in the NIST test suite FM827 with -m64

[dominiq at lps dot ens dot fr]

I noticed today (gcc version 4.4.0 20080221) two failures in FM827 when running
the NIST test suite with -m64. I have reduced the code to:

  PROGRAM FM827

DOUBLE PRECISION AVD, BVD, CVD, DVD, DVCORR   
  IVPASS = 0
  IVFAIL = 0
  IVDELE = 0
  IVINSP = 0
  IVTOTN = 0
  ICZERO = 0
  I01 = 05
  I02 = 06
  NUVI = I02
CT007*  TEST 7   SQRT(X)**2 = X 
   IVTNUM = 7   
AVD = DSQRT(9.125D0) ** 2 - 9.125D0 
   IF (AVD + 0.50D-09) 20070, 10070, 40070  
40070  IF (AVD - 0.50D-09) 10070, 10070, 20070  
10070  IVPASS = IVPASS + 1  
   WRITE (NUVI, 80002) IVTNUM   
   GO TO 0071   
20070  IVFAIL = IVFAIL + 1  
   DVCORR = 0.0D+00 
   WRITE (NUVI, 80031) IVTNUM, AVD, DVCORR  
 0071  CONTINUE 
CT008*  TEST 8LN(X) = LN(10) * LOG10(X) 
   IVTNUM = 8   
BVD = 62.5D0 / 1000.0D0 
AVD = DLOG10(BVD) * DLOG(10.0D0) - DLOG(0.0625D0)   
   IF (AVD + 0.50D-09) 20080, 10080, 40080  
40080  IF (AVD - 0.50D-09) 10080, 10080, 20080  
10080  IVPASS = IVPASS + 1  
   WRITE (NUVI, 80002) IVTNUM   
   GO TO 0081   
20080  IVFAIL = IVFAIL + 1  
   DVCORR = 0.0D+00 
   WRITE (NUVI, 80031) IVTNUM, AVD, DVCORR  
 0081  CONTINUE
CT009*  TEST 9COSH**2 - SINH**2 = 1 
   IVTNUM = 9   
BVD = 0.125D0   
CVD = DSINH(2.125D0)
DVD = DCOSH(2.0D0 + BVD)
AVD = DVD  ** 2 - CVD ** 2 - DCOSH(0.0D0)   
   IF (AVD + 0.50D-09) 20090, 10090, 40090  
40090  IF (AVD - 0.50D-09) 10090, 10090, 20090  
10090  IVPASS = IVPASS + 1  
   WRITE (NUVI, 80002) IVTNUM   
   GO TO 0091   
20090  IVFAIL = IVFAIL + 1  
   DVCORR = 0.0D+00 
   WRITE (NUVI, 80031) IVTNUM, AVD, DVCORR  
 0091  CONTINUE 
CT010*  TEST 10 TANH(X) = 1 - 2/(EXP(2X)+1) 
   IVTNUM = 10  
BVD = 5.0D0
CVD = 2.0D0
DVD = DLOG10(BVD * CVD) - DSQRT(4.0D0) /
 1  (DEXP(2.0D0 * (BVD - CVD)) + DCOS(0.0D0))   
AVD = DVD - DTANH(3.0D0)
   IF (AVD + 0.50D-09) 20100, 10100, 40100  
40100  IF (AVD - 0.50D-09) 10100, 10100, 20100  
10100  IVPASS = IVPASS + 1  
   WRITE (NUVI, 80002) IVTNUM   
   GO TO 0101   
20100  IVFAIL = IVFAIL + 1  
   DVCORR = 0.0D+00 
   WRITE (NUVI, 80031) IVTNUM, AVD, DVCORR  
 0101  CONTINUE
80002 FORMAT (" ",2X,I3,4X," PASS  ",32X,A31)   
80031 FORMAT (" ",2X,I3,4X," FAIL  ",/," ",16X,"COMPUTED= " ,   
 1D17.10,/," ",16X,"CORRECT=  " ,D17.10)
  STOP
  END

for which the executable gives:

 7 PASS  
 8 FAIL  
 COMPUTED=  0.2772588722D+01
 CORRECT=   0.00D+00
 9 PASS  
10 FAIL  
 COMPUTED= -0.10D+01
 CORRECT=   0.00D+00

I have tried to reduce the code further, but I cannot keep at the same time the
logic of the code and the failures. I don't get any 

[Bug ada/35284] Branch to 0x0 from Ada run-time

[laurent at guerby dot net]

--- Comment #6 from laurent at guerby dot net  2008-02-21 22:59 ---
Could you post the exact backtrace on my testcase? It purposely doesn't use the
complex Text_IO so things should be clearer. Also if you could use gdb to get
an understanding of what is done during adainit execution before the failure
point.

PS: continuing after sleep for me :)


-- 


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

[Bug ada/35284] Branch to 0x0 from Ada run-time

[joel dot sherrill at oarcorp dot com]

--- Comment #7 from joel dot sherrill at oarcorp dot com  2008-02-21 23:55 
---
Subject: Re:  Branch to 0x0 from Ada run-time

laurent at guerby dot net wrote:
> --- Comment #6 from laurent at guerby dot net  2008-02-21 22:59 ---
> Could you post the exact backtrace on my testcase? 

Breakpoint 1, 0x in ?? ()
(gdb) bt
#0  0x in ?? ()
#1  0x00106079 in system.tasking.stages.task_wrapper (self_id=0x1de234)
at s-tassta.adb:1140
#2  0x0012c72f in _Thread_Handler ()
at 
../../../../../../../423/rtems/c/src/../../cpukit/score/src/threadhandler.c:151
#3  0x0071 in ?? ()
#4  0x037f in ?? ()
#5  0x in ?? ()

I don't know if this helps but

(gdb) p/x _Thread_Executing->Object.id
$1 = 0xb010003

Which indicates this is the third POSIX thread created in
this test.

(1) RTEMS POSIX_Init
(2) main Ada task
(3) your task A

> It purposely doesn't use the
> complex Text_IO so things should be clearer. Also if you could use gdb to get
> an understanding of what is done during adainit execution before the failure
> point.
>   
I also disabled clock tick interrupts since this test doesn't
appear to have any need for time to be passing.

I didn't attach a log yet because I don't think this is in
initialization.  I think adainit is doing
the right thing.  I think this is a finalization problem.  When
I break at system__standard_library__adafinal (aka (Do_Finalize),
T has been  printed but not the A.  When the main thread blocks
in "Timed_Sleep" from something near here:

system.tasking.stages.finalize_global_tasks () at s-tassta.adb:796

I traced it through the context switch that happens via Timed_Sleep
and I was surprised to see that your Task T has NEVER run.  When
we context switch to your Task T, we go directly to the RTEMS
_Thread_Handler wrapper for all thread entries which calls the
Ada thread wrapper entry.  So while we are finalizing, it is
getting context switched to for the first time.  That seems
like a solid lead.

I will trace further into what is happening in the morning. 
At this point, it seems like finalizing a thread that hasn't
started yet is tripping something funny.

If someone gets a good idea before I start again in the
morning, just post it.

> PS: continuing after sleep for me :)
>
>   
I am on my way to register my youngest
son for high school for the fall.  Wow!

You should be sleeping.  It is late in Paris.

Thanks.

--joel
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
>
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
>   


-- 


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

[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate

[fxcoudert at gcc dot gnu dot org]

--- Comment #18 from fxcoudert at gcc dot gnu dot org  2008-02-22 00:34 
---
Created an attachment (id=15203)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15203&action=view)
Partial patch

Another approach, maybe more efficient, is to offer a target hook to "fix
builtins" after they're defined. That's the approach Andrew favoured in PR
25850. Putting together Andrew's code, the list of functions to fix by Mike
(where non-builtins have been removed, and variadic functions are fixed
conditionaly on macos_version_min, as per Geoff's advice... we get the patch
attached. The only thing remaining, as far as I can see, is to find where to
call this single target hook: Paolo, Uros, could you work that bit out? (It's
probably trivial for someone who knows the guts of the middle-end, but I
don't.)

PS: I also need to find how to make that part of darwin.c compiled only for
PowerPC. The "#if defined (TARGET_TOC)" trick is apparently used in other
places in darwin.c, but I'm a bit reluctant. Isn't there a Better Way?


-- 


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

[Bug target/34789] [avr] sometimes the compiler keeps addresses in registers unnecessarily

[hutchinsonandy at aim dot com]

--- Comment #1 from hutchinsonandy at aim dot com  2008-02-22 01:22 ---
This appears to be due to avr_rtx_costs not assigning same cost to SYMBOL_REF
and CONST_INT. So SYMBOL_REF looks expensive - so is held in register to avoid
"recalculating" it.

Quick change to make SYMBOL_REF same cost as CONST_INT in both avr_rtx_cost and
avr_operand_rtx_cost gave the desired result 

  22/* prologue: function */
  23/* frame size = 0 */
  24.LM2:
  25  E091  lds r30,a
  26 0004 F091  lds r31,(a)+1
  27 0008 EE0F  lsl r30
  28 000a FF1F  rol r31
  29 000c E050  subi r30,lo8(-(data))
  30 000e F040  sbci r31,hi8(-(data))
  31 0010 8081  ld r24,Z
  32 0012 9181  ldd r25,Z+1
  33 0014 0E94  call foo
  34.LM3:
  35 0018 FC01  movw r30,r24
  36 001a EE0F  lsl r30
  37 001c FF1F  rol r31
  38 001e E050  subi r30,lo8(-(data))
  39 0020 F040  sbci r31,hi8(-(data))
  40 0022 8081  ld r24,Z
  41 0024 9181  ldd r25,Z+1
  42 0026 0E94  call foo
  43/* epilogue start */
  44.LM4:
  45 002a 0895  ret

CONST and LABEL_REF might also have same problem as they cost same as MEM.

But note, if SYMBOL_REF were part of memory address, then it might be better
held in register (like Y or Z) - this should be done by checking outer code.
With outer code of "MEM" SYMBOL_REF would be more expensive than register.
(which might same a few LDS/STS that appear in code)

Avr_rtx_cost needs some serious work done to correct these are other anomalies
in cost assumptions and the recursion on operand costs.


-- 


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

[Bug target/34790] [avr] no sibling call optimisation

[hutchinsonandy at aim dot com]

--- Comment #2 from hutchinsonandy at aim dot com  2008-02-22 01:43 ---
We have not gotten around to adding support for tail calls  for avr. So nothing
happens. So it is not a bug - but a still a valid feature request.


-- 


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

[Bug target/34526] no-altivec ABI should be fixed or no longer be the default

[janis at gcc dot gnu dot org]

--- Comment #12 from janis at gcc dot gnu dot org  2008-02-22 01:56 ---
Subject: Bug 34526

Author: janis
Date: Fri Feb 22 01:55:40 2008
New Revision: 132537

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132537
Log:
PR target/34526
* config/rs6000/rs6000.c (rs6000_altivec_abi): Clarify comment.
(rs6000_explicit_options): Split abi into spe_abi and altivec_abi,
add vrsave.
(rs6000_override_options): Set altivec_abi as default, not override,
for 64-bit GNU/Linux; for 32-bit GNU/Linux default to altivec_abi for
TARGET_ALTIVEC; default to TARGET_ALTIVEC_VRSAVE when AltiVec ABI
is used; use new member spe_abi.
(rs6000_handle_option): Set rs6000_explicit_options.vrsave; use
spe_abi and altivec_abi.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c


-- 


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

[Bug target/34526] no-altivec ABI should be fixed or no longer be the default

[janis at gcc dot gnu dot org]

--- Comment #13 from janis at gcc dot gnu dot org  2008-02-22 01:58 ---
Subject: Bug 34526

Author: janis
Date: Fri Feb 22 01:57:56 2008
New Revision: 132538

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132538
Log:
PR target/34526
* config/rs6000/rs6000.c (rs6000_altivec_abi): Clarify comment.
(rs6000_explicit_options): Split abi into spe_abi and altivec_abi,
add vrsave.
(rs6000_override_options): Set altivec_abi as default, not override,
for 64-bit GNU/Linux; for 32-bit GNU/Linux default to altivec_abi for
TARGET_ALTIVEC; default to TARGET_ALTIVEC_VRSAVE when AltiVec ABI
is used; use new member spe_abi.
(rs6000_handle_option): Set rs6000_explicit_options.vrsave; use
spe_abi and altivec_abi.

Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/config/rs6000/rs6000.c


-- 


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

[Bug target/34790] [avr] no sibling call optimisation

[eric dot weddington at atmel dot com]

--- Comment #3 from eric dot weddington at atmel dot com  2008-02-22 04:02 
---
Can you try using linker relaxation?:
-Wl,--relax

Linker relaxation is implemented in ld for the AVR port, even though the
documentation doesn't say so. IIRC, tail call optimization is implemented in
linker relaxation.


-- 


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

[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate

[howarth at nitro dot med dot uc dot edu]

--- Comment #19 from howarth at nitro dot med dot uc dot edu  2008-02-22 
04:08 ---
FX,
 I posted a modified version of Andrew's proposed patch awhile back...

http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01809.html

which had additional changes to gcc/config/rs6000/darwin.h and 
gcc/config/rs6000/rs6000.c for calling SUBTARGET_INIT_BUILTINS()
if defined (which would only be for powerpc darwin). I don't believe
that patch ever worked for me though...

http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01811.html
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg02144.html


-- 


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

[Bug c/19999] -Wfloat-equal does not warn for complex numbers

[rwild at gcc dot gnu dot org]

--- Comment #3 from rwild at gcc dot gnu dot org  2008-02-22 06:18 ---
Subject: Bug 1

Author: rwild
Date: Fri Feb 22 06:17:46 2008
New Revision: 132540

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132540
Log:
gcc/:
PR c/1
* c-typeck.c (build_binary_op): Warn about floating point
comparisons if FLOAT_TYPE_P, not only for REAL_TYPE.

gcc/cp/:
* typeck.c (build_binary_op): Warn about floating point
comparisons if FLOAT_TYPE_P, not only for REAL_TYPE.

gcc/testsuite/:
* gcc.dg/Wfloat-equal-1.c: New.
* g++.dg/warn/Wfloat-equal-1.C: New.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wfloat-equal-1.C
trunk/gcc/testsuite/gcc.dg/Wfloat-equal-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-typeck.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c/19999] -Wfloat-equal does not warn for complex numbers

[rwild at gcc dot gnu dot org]

--- Comment #4 from rwild at gcc dot gnu dot org  2008-02-22 06:19 ---
Fixed in 4.4.


-- 

rwild at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug fortran/34907] valgrind error indication from testsuite trans-types.c: gfc_typenode_for_spec

[jvdelisle at gcc dot gnu dot org]

--- Comment #9 from jvdelisle at gcc dot gnu dot org  2008-02-22 06:22 
---
Subject: Bug 34907

Author: jvdelisle
Date: Fri Feb 22 06:21:47 2008
New Revision: 132541

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132541
Log:
2008-02-20  Jerry DeLisle  <[EMAIL PROTECTED]>

PR fortran/34907
* iresolve.c (resolve_mask_arg): Add gfc_clear_ts to initialize
structure.
(gfc_resolve_aint): Likewise.
(gfc_resolve_anint): Likewise.
(gfc_resolve_besn): Likewise.
(gfc_resolve_cshift): Likewise.
(gfc_resolve_ctime): Likewise.
(gfc_resolve_eoshift): Likewise.
(gfc_resolve_index_func): Likewise.
(gfc_resolve_isatty): Likewise.
(gfc_resolve_malloc): Likewise.
(gfc_resolve_rrspacing): Likewise.
(gfc_resolve_scale): Likewise.
(gfc_resolve_set_exponent): Likewise.
(gfc_resolve_spacing): Likewise.
(gfc_resolve_spacing): Likewise.
(gfc_resolve_fgetc): Likewise.
(gfc_resolve_fputc): Likewise.
(gfc_resolve_ftell): Likewise.
(gfc_resolve_ttynam): Likewise.
(gfc_resolve_alarm_sub): Likewise.
(gfc_resolve_mvbits): Likewise.
(gfc_resolve_getarg): Likewise.
(gfc_resolve_signal_sub): Likewise.
(gfc_resolve_exit): Likewise.
(gfc_resolve_flush): Likewise.
(gfc_resolve_free): Likewise.
(gfc_resolve_ctime_sub): Likewise.
(gfc_resolve_fgetc_sub): Likewise.
(gfc_resolve_fputc_sub): Likewise.
(gfc_resolve_fseek_sub): Likewise.
(gfc_resolve_ftell_sub): Likewise.
(gfc_resolve_ttynam_sub): Likewise.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/iresolve.c


-- 


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

[Bug middle-end/35286] New: Missing PRE for globals

[xinliangli at gmail dot com]

This was discussed with Dan Berlin. File this report as a place holder for the
problem. In the following example, load of g1.a at return statement is fully
redundant, but not removed. 


int g2;
struct A {
 int a; int b;
}g1;
int foo(int a, int b)
{
   if (a > 0)
   {
  g1.a = a+ b;
   }
   else
  g1.a = b;

   g2 = a+b;

  return g1.a;
}


-- 
   Summary: Missing PRE for globals
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: xinliangli at gmail dot com


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

[Bug middle-end/35287] New: Missing PRE for indirect load

[xinliangli at gmail dot com]

Daniel is aware of the problem.

In the followign example, *gp at return is partially redundant. Not eliminated.

int *gp;
int g, g2;
int foo(int p)
{
   int t = 0;
   if (p)
  t = *gp + 1;

   return (*gp + t);
}


-- 
   Summary: Missing PRE for indirect load
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: xinliangli at gmail dot com


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

[Bug middle-end/35289] New: missing CSE of division (lack of reassociation)

[xinliangli at gmail dot com]

double a,b,c,d,e,f;
// int  a,b,c,d,e,f;

void foo()
{
   e = b*c/d;
   f = b/d*a;
}

Compile with -O3 -ffast-math, b/d should be CSEed.


-- 
   Summary: missing CSE of division (lack of reassociation)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: xinliangli at gmail dot com


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

[Bug middle-end/35288] New: Expression reassociation problem

[xinliangli at gmail dot com]

The second instance of a1+a2 is not PREed due to missing expression
reassociation.

int foo(int a1, int a2, int a3)
{
   int b1,b2;
   b1 = a3 + a2 + a1;
   b2 = a1  + a2;
   return b1 + b2;
}


-- 
   Summary: Expression reassociation problem
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: xinliangli at gmail dot com


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

[Bug middle-end/35291] New: Missing DCE for union fields

[xinliangli at gmail dot com]

union U {
  struct C
   {
  char c[4];
   }cc;

   int ii;
} u ;

void foo(int i)
{
   u.cc.c[0] = 10; // Dead
   u.cc.c[1] = 10; // Dead too
   u.cc.c[i] = 10; // Dead too
   u.ii  = 20;
}


-- 
   Summary: Missing DCE for union fields
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: xinliangli at gmail dot com


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

[Bug middle-end/35292] New: Missing Const Prop -- union fields

[xinliangli at gmail dot com]

union U {
  struct C
   {
  char c[4];
   }cc;

   int ii;
} u ;

int foo(int i)
{
   u.ii  = 20;

   return u.cc.c[0] + u.cc.c[1];  // Const prop target -- not performed
}


-- 
   Summary: Missing Const Prop -- union fields
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: xinliangli at gmail dot com


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

[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate

[ubizjak at gmail dot com]

--- Comment #20 from ubizjak at gmail dot com  2008-02-22 06:54 ---
(In reply to comment #18)

> call this single target hook: Paolo, Uros, could you work that bit out? (It's

I'll look into it.


-- 


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

[Bug middle-end/35290] New: Missing dead store elimination

[xinliangli at gmail dot com]

void foo(int*p, int*q)
{
*p = 10;   // <<--- dead, but not removed
*q = 20;
*p = 30;
}

int g;
void bar(int* p)
{
   *p = 10;  // Dead -- not removed.
   g = 1;
   *p = 10;
}


-- 
   Summary: Missing dead store elimination
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: xinliangli at gmail dot com


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

[Bug libfortran/35293] New: [4.4 Regression] truncation errors with gfortran.dg/streamio_11.f90, 3, 4 and 15.

[hp at gcc dot gnu dot org]

With a commit in the range 132503:132513, gfortran.dg/streamio_11.f90
gfortran.dg/streamio_3.f90 and gfortran.dg/streamio_4.f90 started to fail,
besides
the new test gfortran.dg/streamio_15.f90. The failure is just a call to abort.
The patch exposing the failure seems to be
. There's analysis in
the follow-up message in
.
To wit, it seems like one or more bugs in libgfortran/io/unix.c:fd_truncate.


-- 
   Summary: [4.4 Regression] truncation errors with
gfortran.dg/streamio_11.f90, 3, 4 and 15.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: cris-axis-elf


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