[Bug c/35456] New: Different results for inlined vs. non-inlined function

[ubizjak at gmail dot com]

The testcase:

--cut here--
#include 

double
__attribute__ ((noinline))
test (double x)
{
  return x >= 0.0 ? x : -x;
}

double
__attribute__ ((always_inline))
test_inlined (double x)
{
  return x >= 0.0 ? x : -x;
}


int main()
{
  double x = -0.0;

  printf ("%f %f %f\n", x, test(x), test_inlined(x));
  return 0;
}
--cut here--

gcc -O2 abs.c
./a.out
-0.00 0.00 -0.00


-- 
   Summary: Different results for inlined vs. non-inlined function
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ubizjak at gmail dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug c/35456] Different results for inlined vs. non-inlined function

[ubizjak at gmail dot com]

--- Comment #1 from ubizjak at gmail dot com  2008-03-04 08:40 ---
Hm, -0.0 >= 0.0 is folded to TRUE, as confirmed by:

printf ("%i\n", -0.0 >= 0.0);

This produces 1.


-- 


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

Re: [Bug c/35456] Different results for inlined vs. non-inlined function

[Andrew Pinski]

Sent from my iPhone

On Mar 4, 2008, at 0:40, "ubizjak at gmail dot com" <[EMAIL PROTECTED] 
> wrote:





--- Comment #1 from ubizjak at gmail dot com  2008-03-04 08:40  
---

Hm, -0.0 >= 0.0 is folded to TRUE, as confirmed by:

printf ("%i\n", -0.0 >= 0.0);

This produces 1.



That is correct. The noinline case is wrong. It should not be  
converted to be abs.


-- Pinski



--


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

[Bug c/35456] Different results for inlined vs. non-inlined function

[pinskia at gmail dot com]

--- Comment #2 from pinskia at gmail dot com  2008-03-04 08:49 ---
Subject: Re:  Different results for inlined vs. non-inlined function



Sent from my iPhone

On Mar 4, 2008, at 0:40, "ubizjak at gmail dot com" <[EMAIL PROTECTED] 
 > wrote:

>
>
> --- Comment #1 from ubizjak at gmail dot com  2008-03-04 08:40  
> ---
> Hm, -0.0 >= 0.0 is folded to TRUE, as confirmed by:
>
> printf ("%i\n", -0.0 >= 0.0);
>
> This produces 1.
>

That is correct. The noinline case is wrong. It should not be  
converted to be abs.

-- Pinski

>
> -- 
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35456
>


-- 


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

[Bug middle-end/35249] miscompilation of Emacs at -O

[ebotcazou at gcc dot gnu dot org]

--- Comment #11 from ebotcazou at gcc dot gnu dot org  2008-03-04 09:14 
---
> The original motivation for this report was that I was trying to reproduce the
> occasional problem of error being called (a "this should never happen" sanity
> check) at this place in the code.  I thought I had managed to do that with the
> bugzilla reported simple sequence of events immediately after starting emacs. 
> Does your finding suggest that my supposed reproduction of the error call was
> an illusion?  (And that there is no miscompilation either.)

You really need to put the breakpoint on 'error' to be sure.  Source location
information is seriously shaken by optimization in the 4.x series of compilers
so I wouldn't rely on it to put breakpoints in optimized code.


-- 


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

[Bug c/35449] extended asm documentation wrong

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-03-04 09:31 ---
Patch welcome.


-- 


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

[Bug other/35454] [4.3/4.4 Regression] m68k: internal compiler error: in find_reloads, at reload.c:3744

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.3.0


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

[Bug target/35455] [4.1/4.2/4.3/4.4 Regression] h8300: internal compiler error: in compute_frame_pointer_to_fb_displacement, at dwarf2out.c:10984

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|other   |target
   Target Milestone|--- |4.2.4


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

[Bug c/35456] Different results for inlined vs. non-inlined function

[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||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2008-03-04 09:36:51
   date||


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

[Bug c/35456] Different results for inlined vs. non-inlined function

[ubizjak at gmail dot com]

--- Comment #3 from ubizjak at gmail dot com  2008-03-04 10:01 ---
Working on a fix.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ubizjak at gmail dot com
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-03-04 09:36:51 |2008-03-04 10:01:30
   date||


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

[Bug other/35457] New: Error building GCC trunk on CELL SPU

[eres at il dot ibm dot com]

I get the following error message trying to build trunk r132854 on CELL
SPU:

-O2 ' 'CPPFLAGS=' 'LDFLAGS=' 'build_alias=powerpc64-unknown-linux-gnu'
'host_alias=spu' 'target_alias=spu' --cache-file=.././config.cache
--srcdir=../../../../gcc/newlib/libc
configure: loading cache .././config.cache
configure: error: `CFLAGS' has changed since the previous run:
configure:   former value:  -g -O2
configure:   current value: -g -O2
configure: error: changes in the environment can compromise the build
configure: error: run `make distclean' and/or `rm .././config.cache' and
start over
configure: error: /bin/sh '../../../../gcc/newlib/libc/configure' failed
for libc
make[1]: *** [configure-target-newlib] Error 1
make[1]: Leaving directory `/home/tehila/nfs/mainline_new/build_org'
make: *** [all] Error 2

It might be introduced by a recent change to the calculation of
CFLAGS_FOR_TARGET.
Deleting config.cache file does not seem to help.


-- 
   Summary: Error building GCC trunk on CELL SPU
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eres at il dot ibm dot com


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

[Bug c++/35262] [4.4 Regression]: FAIL: abi_check

[pcarlini at suse dot de]

--- Comment #17 from pcarlini at suse dot de  2008-03-04 11:04 ---
(In reply to comment #16)
> Sorry, I had two versions of patch and managed to commit the wrong copy.
> Sent correct one to ML.  It should be fixed now.

Indeed, it's fixed! Many, many thanks!

> The point I wanted to make is that inliner when knowing to be inlining a
> cold call (because it was hinted so by __builtin_expect) is correctly a
> lot more sellective.  Basically anything that expands to function call
> and some extra code around is a loss for code size inlining.

I see now. I was missing the cold call (__builtin_expect) specifics. Thanks for
the explanation.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/35456] Different results for inlined vs. non-inlined function

[ubizjak at gmail dot com]

--- Comment #4 from ubizjak at gmail dot com  2008-03-04 12:41 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00207.html.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||03/msg00207.html
  Component|c   |middle-end


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

[Bug tree-optimization/35428] [4.3/4.4 regression] ICE with "-ftrapv"

[irar at il dot ibm dot com]

--- Comment #3 from irar at il dot ibm dot com  2008-03-04 13:30 ---
It fails in initialize_matrix_A() when called with chrec {0, +, {0, +, 4}_1}_2:
int_cst_value (CHREC_RIGHT (chrec)) ICEs, since CHREC_RIGHT (chrec) here is {0,
+, 4}_1.

Ira


-- 

irar at il dot ibm dot com changed:

   What|Removed |Added

 CC||sebpop at gmail dot com
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-03-04 13:30:42
   date||


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

[Bug preprocessor/35458] New: Dependency generation (-M) does not quote '#' in filenames

[markus dot milleder at generali dot at]

Dependency generation (-M) does not quote '#' in filenames.


-- 
   Summary: Dependency generation (-M) does not quote '#' in
filenames
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: markus dot milleder at generali dot at


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

[Bug preprocessor/35458] Dependency generation (-M) does not quote '#' in filenames

[markus dot milleder at generali dot at]

--- Comment #1 from markus dot milleder at generali dot at  2008-03-04 
13:37 ---
Created an attachment (id=15259)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15259&action=view)
Patch for mkdeps.c + testcase

This trivial patch cures the problem. I do not have a copyright assignment, but
the patch should be small and simple enough.


-- 


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

[Bug preprocessor/35458] Dependency generation (-M) does not quote '#' in filenames

[rwild at gcc dot gnu dot org]

--- Comment #2 from rwild at gcc dot gnu dot org  2008-03-04 13:53 ---
Please note that quoting # in makefiles is not portable, but only supported
by some make implementations.  For example, with
   foo: a\#b
   bar: c#d

AIX make will assume 'foo' depends on 'a\', and 'bar' on 'c'.
Likewise HP-UX make.  Consequently, both of these make's will error out on
either line of:
  a#b:
  a\#b:


-- 

rwild at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||Ralf dot Wildenhues at gmx
   ||dot de


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

[Bug middle-end/35456] Different results for inlined vs. non-inlined function

[uros at gcc dot gnu dot org]

--- Comment #5 from uros at gcc dot gnu dot org  2008-03-04 13:58 ---
Subject: Bug 35456

Author: uros
Date: Tue Mar  4 13:57:27 2008
New Revision: 132863

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132863
Log:
PR middle-end/35456
* fold-const.c (fold_cond_expr_with_comparison): Prevent
transformations for modes that have signed zeros.
* ifcvt.c (noce_try_abs): Ditto.

testsuite/ChangeLog:

PR middle-end/35456
* gcc.c-torture/execute/pr35456.c: New test.


Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr35456.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/ifcvt.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug preprocessor/35458] Dependency generation (-M) does not quote '#' in filenames

[markus dot milleder at generali dot at]

--- Comment #3 from markus dot milleder at generali dot at  2008-03-04 
14:10 ---
(In reply to comment #2)
> Please note that quoting # in makefiles is not portable, but only supported
> by some make implementations.  For example, with
>foo: a\#b
>bar: c#d
> 
> AIX make will assume 'foo' depends on 'a\', and 'bar' on 'c'.
> Likewise HP-UX make.  Consequently, both of these make's will error out on
> either line of:
>   a#b:
>   a\#b:
> 
So it seems to me the patch is an improvement for make versions that understand
quoting and does not worsen the situation for those that do not, i.e. files
containing # are broken on e.g. AIX without the patch and with it.


-- 


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

[Bug fortran/33197] Fortran 2008: math functions and other small changes

[fxcoudert at gcc dot gnu dot org]

--- Comment #10 from fxcoudert at gcc dot gnu dot org  2008-03-04 14:21 
---
A bit of experimentation reveals that we can use the asymptotic expression at
http://en.wikipedia.org/wiki/Error_function#Asymptotic_expansion for arguments
larger than 7, and it does converge with less than 100 terms (for x86 long
double, arg = 7.0 requires 30 terms, arg = 8.0 requires 22, arg = 10.0 requires
16 and arg = 18.0 requires 10 terms; allow a bit more for ppc long doubles).
So, I rank this as costly but doable, and we frankly don't care too much about
the cost at the moment (people relying on heavy simplification of ERFC_SCALED
intrinsic, well... I don't see that coming too soon). For smaller arguments,
using mpfr_erfc and mpfr_exp should be fine. Does that sound like a plan?


-- 


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

[Bug fortran/33197] Fortran 2008: math functions and other small changes

[fxcoudert at gcc dot gnu dot org]

--- Comment #11 from fxcoudert at gcc dot gnu dot org  2008-03-04 14:26 
---
On ppc longdouble, convergence requires argument >= 8.6 and, again, less than
100 terms. Why does convergence radius depend on the format of the
floating-point type, I wonder... For the record, here's the small C program I
use for testing:

#include 
#include 
#include 

#define PI 3.1415926535897932384626433832795029L

extern long double asympt (long double);

long double asympt (long double x)
{
  long double res, f, y, z;
  int n;

  y = 1 / (2 * x * x);
  z = 1;
  res = 1;
  f = 1;
  for (n = 1; n < 100; n++)
  {
f *= 2 * n - 1;
z *= y;
res += (n % 2 ? -1 : 1) * f * z;
if (f*z <= DBL_MIN)
  break;
if (f*z <= (nextafterl (res, __builtin_infl()) - res))
  break;
  }
  if (n >= 100)
  {
printf (" failed\n");
return -1;
  }

  printf (" %d %Lg\n", n, f*z);
  return res / (x * sqrtl (PI));
}

int main(void)
{
  int i;

  for (i = 20; i < 1; i++)
printf ("%Lg %Lg\n", i * 0.1L, asympt(i * 0.1L));
  return 0;
}


-- 


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

[Bug rtl-optimization/34999] Fallthru crossing edges in partition_hot_cold_basic_blocks are not been fixed when the section ends with call insn

[uweigand at gcc dot gnu dot org]

--- Comment #16 from uweigand at gcc dot gnu dot org  2008-03-04 14:51 
---
Hi Jakub,

we need the same changes in both .eh_frame and .dwarf_frame;
does the gas .cfi_ support both sections?

I'm wondering how "save & restore" should work across two
different FDEs -- in the new FDE, we'd have to emit the full
set of CFA instructions to get to the "base-line" state ...


-- 

uweigand at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||uweigand at de dot ibm dot
   ||com


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

[Bug rtl-optimization/34999] Fallthru crossing edges in partition_hot_cold_basic_blocks are not been fixed when the section ends with call insn

[jakub at gcc dot gnu dot org]

--- Comment #17 from jakub at gcc dot gnu dot org  2008-03-04 15:10 ---
.cfi_* doesn't create .dwarf_frame, but perhaps it could be taught to do that
optionally (some flag on .cfi_startproc that would switch on additional
creation of .dwarf_frame).
The plan with save/restore was that you could do say
.text
.cfi_startproc
.cfi_personality 3, __gxx_personality_v0
.cfi_lsda 3, .LLSDA2
some code plus .cfi_* instructions for it
jmp 1f
.cfi_save .L0123
.section .text.unlikely
.cfi_startproc
.cfi_personality 3, __gxx_personality_v0
.cfi_lsda .LLSDA2
.cfi_restore .L0123
1:
some code plus .cfi_* instructions for it
.cfi_endproc
.previous
.cfi_endproc

where that .cfi_save would add a list of .cfi_* instructions from
.cfi_startproc
till that .cfi_save into .L0123 queue, then .cfi_restore would just add those
queued .cfi directives all at the same location (with some optimizations, e.g.
.cfi_* instructions that clearly cancel themselves would be optimized out, any
location advances of course taken out, etc.).
You can of course do that in dwarf2out.c, but we eventually want to use inline
.cfi_* instructions for other reasons - e.g. so that inline asm code can add
its  unwind info.


-- 


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

[Bug fortran/35459] New: ICE segmentaion fault when compiling valid code, using gfortran.

[s dot binnie at ucl dot ac dot uk]

ICE segmentaion fault when compiling. Apologies for the source included but I
had to reduce it down from proprietary code...

Command used:  gfortran -v -save-temps -c ice_bug.f90

Output:

Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --with-gxx-include-dir=/usr/include/c++/3.4.3
--enable-libgcj-multifile --enable-languages=c,c++,java,f95
--enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic
--host=i386-redhat-linux
Thread model: posix
gcc version 4.1.2 20070626 (Red Hat 4.1.2-14)
 /usr/libexec/gcc/i386-redhat-linux/4.1.2/f951 ice_bug.f90 -quiet -dumpbase
ice_bug.f90 -mtune=generic -auxbase ice_bug -version -I
/usr/lib/gcc/i386-redhat-linux/4.1.2/finclude -o ice_bug.s
GNU F95 version 4.1.2 20070626 (Red Hat 4.1.2-14) (i386-redhat-linux)
compiled by GNU C version 4.1.2 20070626 (Red Hat 4.1.2-14).
GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129265
ice_bug.f90:14: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.


-- 
   Summary: ICE segmentaion fault when compiling valid code, using
gfortran.
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: s dot binnie at ucl dot ac dot uk
 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=35459

[Bug fortran/35459] ICE segmentaion fault when compiling valid code, using gfortran.

[s dot binnie at ucl dot ac dot uk]

--- Comment #1 from s dot binnie at ucl dot ac dot uk  2008-03-04 15:15 
---
Created an attachment (id=15260)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15260&action=view)
testcase for above bug


-- 


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

[Bug tree-optimization/35428] [4.3/4.4 regression] ICE with "-ftrapv"

[irar at il dot ibm dot com]

--- Comment #4 from irar at il dot ibm dot com  2008-03-04 15:44 ---
Isn't the same problem as in pr34635?

Ira


-- 


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

[Bug tree-optimization/35406] gfortran.dg/ldist-1.f90 and gcc.dg/tree-ssa/ldist-4.c don't work

[ismail at namtrac dot org]

--- Comment #1 from ismail at namtrac dot org  2008-03-04 17:14 ---
Confirming on i686-apple-darwin9 with m64.


-- 

ismail at namtrac dot org changed:

   What|Removed |Added

 CC||ismail at namtrac dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-03-04 17:14:36
   date||


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

[Bug fortran/35459] ICE segmentaion fault when compiling valid code, using gfortran.

[kargl at gcc dot gnu dot org]

--- Comment #2 from kargl at gcc dot gnu dot org  2008-03-04 17:15 ---
This compiles with 4.2.3 and 4.3.0 (aka trunk).  In that you are using
4.1.2, I doubt anyone with fix this bug in that branch.  I'll suggest
that an upgrade to a newer version of gfortran is in order.

This bug should probably be closed.


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work||4.2.3 4.3.0


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

[Bug target/27880] [4.2/4.3/4.4 regression] undefined reference to `_Unwind_GetIPInfo'

[wilson at tuliptree dot org]

--- Comment #23 from wilson at tuliptree dot org  2008-03-04 17:56 ---
Subject: Re:  [4.2/4.3/4.4 regression] undefined reference
 to `_Unwind_GetIPInfo'

ubizjak at gmail dot com wrote:
> --- Comment #22 from ubizjak at gmail dot com  2008-02-20 18:39 ---
> Critical P2 bug and the patch gets unreviewed for so long?!
> Is this bug still relevant for ia64-*-linux?

I didn't realize this PR was still open.  I perhaps lost track of it 
because some misleading info added to it implied that it was already 
fixed.  I'll take a look now.

Jim


-- 


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

[Bug c/35460] New: undefined reference to `__builtin_stdarg_start' when compiling 2/29 snapshot on OpenBSD

[michael dot a dot richmond at nasa dot gov]

When I attempt to compile the snapshot of 2/29/08 on OpenBSD 4.2 I get the
following message:

libcpp.a(errors.o)(.text+0x258): In function `cpp_error':
/home/mrichmon/gcc-4.4-20080229/libcpp/errors.c:141: undefined reference to
`__builtin_stdarg_start'
libcpp.a(errors.o)(.text+0x3a0): In function `cpp_error_with_line':
/home/mrichmon/gcc-4.4-20080229/libcpp/errors.c:174: undefined reference to
`__builtin_stdarg_start'


-- 
   Summary: undefined reference to `__builtin_stdarg_start' when
compiling 2/29 snapshot on OpenBSD
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michael dot a dot richmond at nasa dot gov


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

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

[hp at gcc dot gnu dot org]

--- Comment #11 from hp at gcc dot gnu dot org  2008-03-04 18:12 ---
Patches at  and
.


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||patch


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

[Bug c/35460] undefined reference to `__builtin_stdarg_start' when compiling 2/29 snapshot on OpenBSD

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-03-04 18:22 ---
Support for __builtin_stdarg has been removed.  I guess this is still
referenced
in OpenBSD headers?


-- 


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

[Bug target/35453] nmmintrin.h defines macros SIDD_XXX

[hjl at gcc dot gnu dot org]

--- Comment #1 from hjl at gcc dot gnu dot org  2008-03-04 19:18 ---
Subject: Bug 35453

Author: hjl
Date: Tue Mar  4 19:17:35 2008
New Revision: 132867

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132867
Log:
gcc/

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

PR target/35453
* config/i386/smmintrin.h (SIDD_XXX): Renamed to ...
(_SIDD_XXX): This.

gcc/testsuite/

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

PR target/35453
* gcc.target/i386/sse4_2-pcmpestri-1.c: Replace SIDD_XXX with
_SIDD_XXX.
* gcc.target/i386/sse4_2-pcmpestri-2.c: Likewise.
* gcc.target/i386/sse4_2-pcmpestrm-1.c: Likewise.
* gcc.target/i386/sse4_2-pcmpestrm-2.c: Likewise.
* gcc.target/i386/sse4_2-pcmpistri-1.c: Likewise.
* gcc.target/i386/sse4_2-pcmpistri-2.c: Likewise.
* gcc.target/i386/sse4_2-pcmpistrm-1.c: Likewise.
* gcc.target/i386/sse4_2-pcmpistrm-2.c: Likewise.
* gcc.target/i386/sse4_2-pcmpstr.h: Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/smmintrin.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/sse4_2-pcmpestri-1.c
trunk/gcc/testsuite/gcc.target/i386/sse4_2-pcmpestri-2.c
trunk/gcc/testsuite/gcc.target/i386/sse4_2-pcmpestrm-1.c
trunk/gcc/testsuite/gcc.target/i386/sse4_2-pcmpestrm-2.c
trunk/gcc/testsuite/gcc.target/i386/sse4_2-pcmpistri-1.c
trunk/gcc/testsuite/gcc.target/i386/sse4_2-pcmpistri-2.c
trunk/gcc/testsuite/gcc.target/i386/sse4_2-pcmpistrm-1.c
trunk/gcc/testsuite/gcc.target/i386/sse4_2-pcmpistrm-2.c
trunk/gcc/testsuite/gcc.target/i386/sse4_2-pcmpstr.h


-- 


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

[Bug target/35453] nmmintrin.h defines macros SIDD_XXX

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2008-03-04 19:24 ---
Fixed for both gcc 4.3/4.4.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug target/35453] nmmintrin.h defines macros SIDD_XXX

[hjl at gcc dot gnu dot org]

--- Comment #2 from hjl at gcc dot gnu dot org  2008-03-04 19:24 ---
Subject: Bug 35453

Author: hjl
Date: Tue Mar  4 19:23:22 2008
New Revision: 132868

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132868
Log:
gcc/

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

Backport from mainline:
2008-03-04  H.J. Lu  <[EMAIL PROTECTED]>

PR target/35453
* config/i386/smmintrin.h (SIDD_XXX): Renamed to ...
(_SIDD_XXX): This.

gcc/testsuite/

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

Backport from mainline:
2008-03-04  H.J. Lu  <[EMAIL PROTECTED]>

PR target/35453
* gcc.target/i386/sse4_2-pcmpestri-1.c: Replace SIDD_XXX with
_SIDD_XXX.
* gcc.target/i386/sse4_2-pcmpestri-2.c: Likewise.
* gcc.target/i386/sse4_2-pcmpestrm-1.c: Likewise.
* gcc.target/i386/sse4_2-pcmpestrm-2.c: Likewise.
* gcc.target/i386/sse4_2-pcmpistri-1.c: Likewise.
* gcc.target/i386/sse4_2-pcmpistri-2.c: Likewise.
* gcc.target/i386/sse4_2-pcmpistrm-1.c: Likewise.
* gcc.target/i386/sse4_2-pcmpistrm-2.c: Likewise.
* gcc.target/i386/sse4_2-pcmpstr.h: Likewise.

Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/config/i386/smmintrin.h
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/sse4_2-pcmpestri-1.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/sse4_2-pcmpestri-2.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/sse4_2-pcmpestrm-1.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/sse4_2-pcmpestrm-2.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/sse4_2-pcmpistri-1.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/sse4_2-pcmpistri-2.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/sse4_2-pcmpistrm-1.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/sse4_2-pcmpistrm-2.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/sse4_2-pcmpstr.h


-- 


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

[Bug fortran/35461] New: continuation line leads to OMP confusion

[jv244 at cam dot ac dot uk]

the following is accepted by at least xlf, pgf and ifort, but not by 
gcc version 4.3.0 20080213 (experimental) [trunk revision 132283] (GCC)

!$OMP PARALLEL DO DEFAULT(PRIVATE) SHARED(I,&
!$J)
DO K=1,10
   IF (I-J-K==0) I=K
ENDDO
END

gfortran -fopenmp test.f90
test.f90:1.48:

!$OMP PARALLEL DO DEFAULT(PRIVATE) SHARED(I,&
   1
Error: Syntax error in OpenMP variable list at (1)


-- 
   Summary: continuation line leads to OMP confusion
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk


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

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

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-03-04 19:59 ---
I happen to have a "fix".


-- 

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-03-04 19:59:53
   date||


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

[Bug debug/35462] New: anonymous struct in c++ has wrong name in -gdwarf-2

[mrs at apple dot com]

typedef struct {
  int x;
} mystruct;
mystruct m;

should either have no name or a name of mystruct in C++.  I see:

.ascii "\0"   ; DW_AT_name

and

.ascii "$_0\0"  ; external name

This works as expected in C.

Still fails in 20080308.  I think this is target independent.


-- 
   Summary: anonymous struct in c++ has wrong name in -gdwarf-2
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com
GCC target triplet: powerpc-apple-darwin9


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

[Bug debug/35463] New: typedef missing in debug information with -gdwarf-2 for c++

[mrs at apple dot com]

typedef struct {
  int x;
} mystruct;
mystruct m;

is missing any debug information for mystruct.  If one compiles as C, mystruct
is present.

Still broken in 20080308 compiler.  Should be target independent.


-- 
   Summary: typedef missing in debug information with -gdwarf-2 for
c++
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com
GCC target triplet: powerpc-apple-darwin9


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

[Bug debug/35462] anonymous struct in c++ has wrong name in -gdwarf-2

[mrs at apple dot com]

--- Comment #1 from mrs at apple dot com  2008-03-04 20:14 ---
radr://5070293


-- 


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

[Bug debug/35463] typedef missing in debug information with -gdwarf-2 for c++

[mrs at apple dot com]

--- Comment #1 from mrs at apple dot com  2008-03-04 20:15 ---
radr://5070293


-- 


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

[Bug fortran/35461] continuation line leads to OMP confusion

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2008-03-04 20:26 ---
I think this is invalid if I read "2.1.2 Free Source Form Directives" in
http://www.openmp.org/mp-documents/spec25.pdf correctly.

I think it should be:
!$OMP PARALLEL DO DEFAULT(PRIVATE) SHARED(I,&
!$OMPJ)
instead of
!$OMP PARALLEL DO DEFAULT(PRIVATE) SHARED(I,&
!$J)

As "OMP PARALLEL" is a directive. For conditional compilation "!$" (2.2.1) can
be used, but I think it does not apply here.

Jakub, am I right or do I miss something?


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jakub at redhat dot com
   Keywords||openmp


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

[Bug other/28322] GCC new warnings and compatibility

[manu at gcc dot gnu dot org]

--- Comment #17 from manu at gcc dot gnu dot org  2008-03-04 20:29 ---
Subject: Bug 28322

Author: manu
Date: Tue Mar  4 20:28:52 2008
New Revision: 132870

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132870
Log:
2008-03-04  Manuel Lopez-Ibanez  <[EMAIL PROTECTED]>

PR 28322
* opts.c (handle_option): Postpone 'unknown option' errors only for
warning options.
testsuite/
* gcc.dg/pr28322-3.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/pr28322-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/opts.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/35461] continuation line leads to OMP confusion

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2008-03-04 20:41 ---
Yeah, you're right.  In free form ror !$omp directives the continuation lines
must start with !$omp (and previous line must end with &).


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug tree-optimization/27799] adding unused char field inhibits optimization

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-03-04 21:00 ---
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00243.html


-- 

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|NEW |ASSIGNED
   Last reconfirmed|2006-05-29 18:50:17 |2008-03-04 21:00:03
   date||


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

[Bug tree-optimization/27799] adding unused char field inhibits optimization

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-03-04 20:35 ---
Actually alias_sets_conflict_p is the cuplrit, as we have in the alias subset
of struct YY alias set zero (entered for the char member, accesses conflict
with accesses through char *):

  /* See if the first alias set is a subset of the second.  */
  ase = get_alias_set_entry (set1);
  if (ase != 0
  && (ase->has_zero_child
  || splay_tree_lookup (ase->children,
(splay_tree_key) set2)))
return 1;

which IMHO should do

  if (ase != 0
  && ((ase->has_zero_child && set2 == 0)
  || splay_tree_lookup (ase->children, (splay_tree_key) set2))
return 1;

where then both cases are optimized?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dnovillo at gcc dot gnu dot
   ||org


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

[Bug ada/35464] New: "warning: condition is always False" not issued inside generics

[ludovic at ludovic-brenta dot org]

With -gnatwa, GNAT emits very useful warnings; one of them is "condition is
always False".  However, GNAT does not emit this warning when it applies inside
a generic, or a generic instantiation.  The following test case demonstrates
the problem.

procedure Condition_Is_Always_False is

   type T is range 3 .. 4;

   function F return T is
   begin
  return T'First;
   end F;

   procedure OK is
  C : constant T := F;
   begin
  if C = 1 then -- warning: condition is always False
 null;
  end if;
   end OK;

   generic
   procedure NOK_G;

   procedure NOK_G is
  C : constant T := F; -- T'First instead of F gives the warning
   begin
  if C = 1 then -- no warning
 null;
  end if;
   end NOK_G;

   procedure NOK is new NOK_G;

begin -- Condition_Is_Always_False
   OK;
   NOK;
end  Condition_Is_Always_False;

gcc-4.1 -c -gnatwa condition_is_always_false.adb
condition_is_always_false.adb:13:12: warning: condition is always False
gnatbind -x condition_is_always_false.ali
gnatlink condition_is_always_false.ali

If, however, C is initialized directly with T'First (a static value) instead of
the result of F (a static function), GNAT gives the warning even inside the
generic.


-- 
   Summary: "warning: condition is always False" not issued inside
generics
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ludovic at ludovic-brenta dot org


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

[Bug tree-optimization/27799] adding unused char field inhibits optimization

[dann at godzilla dot ics dot uci dot edu]

--- Comment #5 from dann at godzilla dot ics dot uci dot edu  2008-03-04 
21:19 ---
(In reply to comment #4)
> http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00243.html

Thanks for working on this!
Have you looked at the impact?
Probably the generated code won't too different because the RTL alias analysis
probably catches this.
But it would be interesting to see what is the difference for the tree dumps
before and after this patch.


-- 


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

[Bug tree-optimization/27799] adding unused char field inhibits optimization

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2008-03-04 21:22 ---
Actually RTL alias is just using the same routines. The IL difference is

  # SMT.4_6 = VDEF 
  # SMT.5_7 = VDEF 
  x_1(D)->x = 0;
  # SMT.5_8 = VDEF 
  y_2(D)->y = 1;

vs.

  # SMT.18_5 = VDEF 
  x_1(D)->x = 0;
  # SMT.19_7 = VDEF 
  y_2(D)->y = 1;


-- 


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

[Bug tree-optimization/27799] adding unused char field inhibits optimization

[dann at godzilla dot ics dot uci dot edu]

--- Comment #7 from dann at godzilla dot ics dot uci dot edu  2008-03-04 
21:32 ---
(In reply to comment #6)
> Actually RTL alias is just using the same routines.
Might be, but the RTL level code that optimizes away the abort() in both
testcases (if I remember well nonoverlapping_component_refs_p). 

> 
>   # SMT.4_6 = VDEF 
>   # SMT.5_7 = VDEF 
>   x_1(D)->x = 0;
>   # SMT.5_8 = VDEF 
>   y_2(D)->y = 1;
> 
> vs.
> 
>   # SMT.18_5 = VDEF 
>   x_1(D)->x = 0;
>   # SMT.19_7 = VDEF 
>   y_2(D)->y = 1;

That is for this testcase, but what about the impact on .final_cleanup for
something big like combine.c? 


-- 


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

[Bug tree-optimization/27799] adding unused char field inhibits optimization

[rguenther at suse dot de]

--- Comment #8 from rguenther at suse dot de  2008-03-04 21:35 ---
Subject: Re:  adding unused char field inhibits
 optimization

On Tue, 4 Mar 2008, dann at godzilla dot ics dot uci dot edu wrote:

> --- Comment #7 from dann at godzilla dot ics dot uci dot edu  2008-03-04 
> 21:32 ---
> (In reply to comment #6)
> > Actually RTL alias is just using the same routines.
> Might be, but the RTL level code that optimizes away the abort() in both
> testcases (if I remember well nonoverlapping_component_refs_p). 

I still have the abort () with -O2.

> > 
> >   # SMT.4_6 = VDEF 
> >   # SMT.5_7 = VDEF 
> >   x_1(D)->x = 0;
> >   # SMT.5_8 = VDEF 
> >   y_2(D)->y = 1;
> > 
> > vs.
> > 
> >   # SMT.18_5 = VDEF 
> >   x_1(D)->x = 0;
> >   # SMT.19_7 = VDEF 
> >   y_2(D)->y = 1;
> 
> That is for this testcase, but what about the impact on .final_cleanup for
> something big like combine.c? 

No idea, but feel free to check.

Richard.


-- 


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

[Bug tree-optimization/27799] adding unused char field inhibits optimization

[dann at godzilla dot ics dot uci dot edu]

--- Comment #9 from dann at godzilla dot ics dot uci dot edu  2008-03-04 
21:43 ---
(In reply to comment #8)
> Subject: Re:  adding unused char field inhibits
>  optimization
> 
> On Tue, 4 Mar 2008, dann at godzilla dot ics dot uci dot edu wrote:
> 
> > --- Comment #7 from dann at godzilla dot ics dot uci dot edu  
> > 2008-03-04 21:32 ---
> > (In reply to comment #6)
> > > Actually RTL alias is just using the same routines.
> > Might be, but the RTL level code that optimizes away the abort() in both
> > testcases (if I remember well nonoverlapping_component_refs_p). 
> 
> I still have the abort () with -O2.

Argghh, sorry, my bad: typo in the "grep abort file.s" command ...


> > That is for this testcase, but what about the impact on .final_cleanup for
> > something big like combine.c? 
> 
> No idea, but feel free to check.

I don't have a recent build... 


-- 


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

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

[dominiq at lps dot ens dot fr]

--- Comment #7 from dominiq at lps dot ens dot fr  2008-03-04 21:45 ---
I have done some additional tests: compiled under 10.4.11, passed, then
executed under 10.5.2 failed.
Compiled on 10.5.2 with -S, then did the assembly and link under 10.4.11 (using
gfortran) then the executable passed the test. So this seems to be a bug in (or
exposed by) 10.5.2.

It would be nice to have a C test (if possible using gcc 4.0 from apple).


-- 


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

[Bug fortran/35459] ICE segmentaion fault when compiling valid code, using gfortran.

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2008-03-04 21:48 ---
First of all, I would like to thank your for the bug report.

While the bug is present in 4.1, it has been fixed meanwhile and 4.2.3, 4.3.0
and 4.4.0 work. The GCC policy is essentially only to backport fixes to older
version if it is a regression thus I think this will not be fixed in 4.1.x.
(Also due to lack of resources. Besides, I think Red Hat will not provide a
newer GCC 4.1.x.)

I would therefore suggest that you update to a newer GCC. The latest released
GCC is 4.2.3 but GCC 4.3.0 can be expected soon. (Currently: 4.3.0 release
candidate 2.) To my knowledge Red Hat plans to use GCC/gfortran 4.3.0 for their
upcoming Enterprise product and the next Fedora version; I would not be
surprised if they already provide Fedora RPMs.

Otherwise, you can compile gfortran yourself or use the binaries available
from:
http://gcc.gnu.org/wiki/GFortranBinaries


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.1.2 4.1.3


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

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

[fxcoudert at gcc dot gnu dot org]

--- Comment #8 from fxcoudert at gcc dot gnu dot org  2008-03-04 21:58 
---
(In reply to comment #7)
> It would be nice to have a C test (if possible using gcc 4.0 from apple).

It'll be rather easy if you can do what I suggested in comment #6: trim it down
a bit by printing the various quantities involved.


-- 

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-03-04 21:58:33
   date||


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

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

[dominiq at lps dot ens dot fr]

--- Comment #9 from dominiq at lps dot ens dot fr  2008-03-04 22:20 ---
(In reply to comment #8)

Sorry, for not replying to your comments. I have been out of town for four days
(remote place without connction to the net) and I am trying to clean up the
backlog.

To answer the question, when the test fail dlog10 returns 0, but to get that
you need some intermediate steps. The problem has the usual signature of
something reading/writing where it should not.


-- 


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

[Bug fortran/34112] Add $!DEC ATTRIBUTE support for 32bit Windows' STDCALL

[burnus at gcc dot gnu dot org]

--- Comment #7 from burnus at gcc dot gnu dot org  2008-03-04 22:20 ---
Intel documentation in PDF format:
http://softwarecommunity.intel.com/isn/downloads/softwareproducts/pdfs/347685.pdf
Directives (!DEC$) start at page 335


-- 


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

[Bug target/35222] [4.3/4.4 Regression] EH output contains procedure label without P' selector

[danglin at gcc dot gnu dot org]

--- Comment #6 from danglin at gcc dot gnu dot org  2008-03-04 23:31 ---
Subject: Bug 35222

Author: danglin
Date: Tue Mar  4 23:30:47 2008
New Revision: 132876

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132876
Log:
PR target/35222
* configure.ac (CONFIG_SJLJ_EXCEPTIONS): Force SJLJ exceptions
on hpux10.
* configure: Rebuilt.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/configure
trunk/gcc/configure.ac


-- 


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

[Bug target/35222] [4.3/4.4 Regression] EH output contains procedure label without P' selector

[danglin at gcc dot gnu dot org]

--- Comment #7 from danglin at gcc dot gnu dot org  2008-03-04 23:39 ---
Subject: Bug 35222

Author: danglin
Date: Tue Mar  4 23:39:11 2008
New Revision: 132877

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132877
Log:
PR target/35222
* configure.ac (CONFIG_SJLJ_EXCEPTIONS): Force SJLJ exceptions
on hpux10.
* configure: Rebuilt.


Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/configure
branches/gcc-4_3-branch/gcc/configure.ac


-- 


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

[Bug fortran/33759] ICE in transfer_simplify_4.f90 at any level of optimization

[fxcoudert at gcc dot gnu dot org]

--- Comment #13 from fxcoudert at gcc dot gnu dot org  2008-03-04 23:47 
---
It will probably be useless to others, who have already dug into this PR, but I
did have to research a bit to understand it, so I paste here the results of my
research... in case it can help.

-
For the following reduced code:

  integer :: i
  i = 42
  print *, transfer(i, .true.)
  print *, transfer (transfer(i, .true.), 0)
  end

a.f90.013t.cfg has the (still valid):

  i.6 = i;
  transfer.4 = (logical(kind=4)) i.6;
  transfer.8 = transfer.4;
  D.876 = transfer.8;
  D.882 = D.876;
  transfer.5 = (integer(kind=4)) D.882;
  transfer.9 = transfer.5;
  D.878 = transfer.9;

a.f90.014t.cplxlower0 has made it into a pair of memcpy, but
a.f90.015t.veclower has them back in the form of two casts. a.f90.036t.dce1 has
them simplified into:

  transfer.4_9 = (logical(kind=4)) i_7;
  transfer.5_11 = (integer(kind=4)) transfer.4_9; 
  D.878 ={v} transfer.5_11;

a.f90.055t.copyrename2 still has that same form:

  transfer.4_9 = (logical(kind=4)) i_7;
  transfer.5_11 = (integer(kind=4)) transfer.4_9;
  D.878 = transfer.5_11;

but a.f90.056t.ccp2 definitely looses it:

  transfer.4_9 = 0;
  transfer.5_11 = 0;
  D.878 = 0;


So, the question is, is cpp2 right to change:

  i_7 = 42;
  transfer.4_9 = (logical(kind=4)) i_7;
  transfer.5_11 = (integer(kind=4)) transfer.4_9;
  D.878 = transfer.5_11;

into

  transfer.4_9 = 0;
  transfer.5_11 = 0;
  D.878 = 0;

I'm not sure what the semantics are for the logical kinds in the middle-end,
but it may be that only the least significant bit is used (if you change 42
into 43, you don't get the failure).

According to the related thread at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/b29957a2f57fec25/27c2b4eca91c511f?lnk=gst&q=transfer+logical#27c2b4eca91c511f
correctly (comp.lang.fortran thread named "Transfer and variables that don't
use all their storage space.", started by... Tobias Burnus),
TRANSFER(TRANSFER(A,B),A) is legal and it's result should always be A (there
are some restrictions, but they are fulfilled in this precise case).
-

Paul, to comment on your patch, it's not only integer and logical that are
concerned. You can do the same thing with logical and any other type, I'm
sure... and I'm even sure you could manage to do the same thing with a
real(kind=10), which has "unused bits" like a real type. (Or maybe, by playing
with NaN canonicalization, you could do it with any other floating-point type;
ie, choose an integer value that will TRANSFER into a given NaN, and the
middle-end might canonicalize this NaN or optimize it in sort weird way.) Also,
maybe the optimizer can sometimes be clever enough to see through your added
indirection level, can't it?

The only one way I see to do that would be to not create intermediate
variables. This is, after all, the meaning of the Fortran standard, that
although assignment can normalize (and array transfers are excluded from the
TRANSFER(TRANSFER(A,B),A) == A rule), scalar TRANSFERs without assignment don't
normalize. 


-- 

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=33759

[Bug bootstrap/35465] New: [4.4 Regression] Bootstrap failure at rev. 132875

[dominiq at lps dot ens dot fr]

Bootstrap fails at rev. 132875 with:

/opt/gcc/darwin_buildw/./prev-gcc/xgcc -B/opt/gcc/darwin_buildw/./prev-gcc/
-B/opt/gcc/gcc4.4w/powerpc-apple-darwin9/bin/ -c   -g -O2 -mdynamic-no-pic
-DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros  -Wno-overlength-strings
-Werror -fno-common   -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.4-work/gcc
-I../../gcc-4.4-work/gcc/. -I../../gcc-4.4-work/gcc/../include
-I../../gcc-4.4-work/gcc/../libcpp/include -I/sw/include 
-I../../gcc-4.4-work/gcc/../libdecnumber
-I../../gcc-4.4-work/gcc/../libdecnumber/dpd -I../libdecnumber   
../../gcc-4.4-work/gcc/fold-const.c -o fold-const.o
cc1: warnings being treated as errors
../../gcc-4.4-work/gcc/fold-const.c: In function
'tree_single_nonnegative_warnv_p':
../../gcc-4.4-work/gcc/fold-const.c:14241: error: ISO C90 forbids mixed
declarations and code
../../gcc-4.4-work/gcc/fold-const.c: In function
'tree_invalid_nonnegative_warnv_p':
../../gcc-4.4-work/gcc/fold-const.c:14282: error: ISO C90 forbids mixed
declarations and code
make[3]: *** [fold-const.o] Error 1
make[2]: *** [all-stage2-gcc] Error 2
make[1]: *** [stage2-bubble] Error 2
make: *** [all] Error 2


-- 
   Summary: [4.4 Regression] Bootstrap failure at rev. 132875
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr


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

[Bug target/35222] [4.3/4.4 Regression] EH output contains procedure label without P' selector

[danglin at gcc dot gnu dot org]

--- Comment #8 from danglin at gcc dot gnu dot org  2008-03-05 01:11 ---
Patch to force use of sjlj applied to trunk and 4.3.


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

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

[hp at gcc dot gnu dot org]

--- Comment #12 from hp at gcc dot gnu dot org  2008-03-05 01:51 ---
Subject: Bug 35293

Author: hp
Date: Wed Mar  5 01:50:33 2008
New Revision: 132888

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132888
Log:
PR libfortran/35293
* io/unix.c (fd_truncate): Fold s->special_file case into
success case of ftruncate/chsize call instead of the failure case.
Make failure case actually return failure.  Properly update stream
pointers on failure.  Call runtime_error for targets without
neither ftruncate nor chsize where such a call would be needed.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/unix.c


-- 


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

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

[hp at gcc dot gnu dot org]

--- Comment #13 from hp at gcc dot gnu dot org  2008-03-05 01:56 ---
Subject: Bug 35293

Author: hp
Date: Wed Mar  5 01:55:27 2008
New Revision: 132889

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132889
Log:
PR libfortran/35293
* lib/lib/target-supports.exp (check_effective_target_fd_truncate):
New.
* gfortran.fortran-torture/execute/list_read_1.x,
...
gfortran.dg/write_back.f: Gate test on effective_target
fd_truncate.
(missing PR ChangeLog decoration)

Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

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

[hp at gcc dot gnu dot org]

--- Comment #14 from hp at gcc dot gnu dot org  2008-03-05 01:58 ---
Patches committed, case closed.


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/35421] ICE on Valid Code

[mckelvey at maskull dot com]

--- Comment #6 from mckelvey at maskull dot com  2008-03-05 02:50 ---
(In reply to comment #5)
> (In reply to comment #4)
> 
> > >>
> > >> A 65,000 line testcase?  Seriously?
> > >>
> > >
> > > I'll try to make a smaller one. But it most likely won't be small.
> > > I think the bug is caused by a VERY large expression used with a  
> > > constructor
> > > within a try-catch.
> > >
> > 
> > 
> > Most likely this is just a stack overflow so really not an interesting  
> > testcase.
> > 
> 
> Your testcase works for me if I make gcc with 
> LDFLAGS="-Wl,--stack=0x200"
> 
> > Thanks,
> > Andrew Pinski
> > 
> > >
> > 
> 


OK, I will try that. Thanks!

Although that solves my immediate problem, the compiler should not ICE on a
stack overflow, right? It should give a stack overflow error or something
similar.


-- 


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

[Bug c++/35394] Aggressive template instantiation?

[bangerth at dealii dot org]

--- Comment #2 from bangerth at dealii dot org  2008-03-05 02:55 ---

This is called two-stage name lookup: when parsing a template all occurrences
of "things" that do not depend on the template parameter are bound to their
global definitions. Thus, here...

> template 
>class not_compilable
>{
>   enum { dummy_value = sizeof (static_assert) };
>};

...even though we're in a template the compiler sees that static_assert
is a classname that does not depend on the (currently) unknown template
parameter 'Reason' and so is supposed to be replaced for sizeof. This fails,
a behavior mandated by the C++ standard.

On the other hand, here...

> template 
>class not_compilable
>{
>   static static_assert dummy_fct ();
>   enum { dummy_value = sizeof (dummy_fct ()) };
>};

...you ask the compiler to evaluate sizeof
(not_compilable::dummy_fct())
which depends on the template parameter 'Reason' and so its evaluation is
deferred till we know the template type 'Reason', i.e. till instantiation
time. If you never instantiate it, there's no error.

W.


-- 

bangerth at dealii dot org changed:

   What|Removed |Added

 CC||bangerth at dealii dot org
 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug target/35460] undefined reference to `__builtin_stdarg_start' when compiling 2/29 snapshot on OpenBSD

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-03-05 03:18 ---
This is a bug in the openbsd headers.  We most likely should fixincludes them
to use __builtin_va_start instead.

See PR 26264 and http://gcc.gnu.org/ml/gcc-patches/2002-07/msg00737.html for
more information on why this was removed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|c   |target
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-03-05 03:18:21
   date||


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

[Bug target/35466] New: Different assembly codes on 32bit and 64bit hosts

[hjl dot tools at gmail dot com]

Gcc generates different 32bit assembly codes in 32bit and 64bit hosts:

1. On 64bit host,

[EMAIL PROTECTED] stage1-gcc]$ cat x.i
_Decimal128 test (void)
{
  return 1234123412341234.123412341234dl;
}
[EMAIL PROTECTED] stage1-gcc]$ ./xgcc -B./ -msse -S -m32  -march=i386 
-mtune=generic
x.i
[EMAIL PROTECTED] stage1-gcc]$ cat x.s
.file   "x.i"
.text
.globl test
.type   test, @function
test:
pushl   %ebp
movl%esp, %ebp
movl8(%ebp), %eax
movaps  .LC0, %xmm0
movaps  %xmm0, (%eax)
popl%ebp
ret $4
.size   test, .-test
.section.rodata
.align 16
.LC0:
.long   84673010
.long   1025550150
.long   66901964
.long   807927808
.ident  "GCC: (GNU) 4.4.0 20080304 (experimental) [trunk revision
132852]"
.section.note.GNU-stack,"",@progbits
[EMAIL PROTECTED] stage1-gcc]$

2. On 32bit host,

[EMAIL PROTECTED] stage1-gcc]$ cat x.i
_Decimal128 test (void)
{
  return 1234123412341234.123412341234dl;
}
[EMAIL PROTECTED] stage1-gcc]$ ./xgcc -B./ -msse -S -m32 -march=i386 
-mtune=generic
x.i
[EMAIL PROTECTED] stage1-gcc]$ cat x.s
.file   "x.i"
.text
.globl test
.type   test, @function
test:
pushl   %ebp
movl%esp, %ebp
subl$24, %esp
movl8(%ebp), %eax
movaps  .LC0, %xmm0
movaps  %xmm0, -24(%ebp)
movaps  -24(%ebp), %xmm0
movaps  %xmm0, (%eax)
leave
ret $4
.size   test, .-test
.section.rodata
.align 16
.LC0:
.long   84673010
.long   1025550150
.long   66901964
.long   807927808
    .ident  "GCC: (GNU) 4.4.0 20080304 (experimental) [trunk revision
132852]"
.section.note.GNU-stack,"",@progbits
[EMAIL PROTECTED] stage1-gcc]$

Where does "subl$24, %esp" on 32bit host come from?


-- 
   Summary: Different assembly codes on 32bit and 64bit hosts
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug target/35466] Different assembly codes on 32bit and 64bit hosts

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2008-03-05 04:27 ---
The difference comes from tree_expand_cfg pass:

[EMAIL PROTECTED] stage1-gcc]$ diff -up 32/x.i.132r.expand 64
--- 32/x.i.132r.expand  2008-03-04 20:25:21.0 -0800
+++ 64/x.i.132r.expand  2008-03-04 20:25:12.0 -0800
@@ -5,20 +5,18 @@
 ;; Generating RTL for tree basic block 2

 ;;  = 1234123412341234.123412341234
-(insn 6 5 7 x.i:3 (set (subreg:TI (reg:TD 59) 0)
-(mem/u/c:TI (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0 S16 A128])) -1
(nil))
-
-(insn 7 6 8 x.i:3 (set (reg:TI 60)
-(subreg:TI (reg:TD 59) 0)) -1 (nil))
+(insn 6 5 7 x.i:3 (set (reg:TI 59)
+(mem/u/c/i:TI (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0 S16 A128]))
-1 (expr_list:REG_EQUAL (const_double 4404704354742567410 [0x3d20a746050c01f2]
3470023512955869132 [0x302803fcd7cc] 0 [0x0] 0 [0x0])
+(nil)))

-(insn 8 7 0 x.i:3 (set (mem/c/i:TI (reg/f:SI 58 [ D.1355 ]) [0 +0 S16
A128])
-(reg:TI 60)) -1 (nil))
+(insn 7 6 0 x.i:3 (set (mem/c/i:TI (reg/f:SI 58 [ D.1370 ]) [0 +0 S16
A128])
+(reg:TI 59)) -1 (nil))

 ;; return 


-- 


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

[Bug tree-optimization/35452] erasing uncessary warning for basic block frequency computation

[zhouyi04 at ios dot cn]

--- Comment #1 from zhouyi04 at ios dot cn  2008-03-05 07:03 ---
(In reply to comment #0)
Sorry there are some problem with 1st patch because the edge e
maybe removed after redirection.
 24
 | \ /
 \  5
  \ |
6
In function redirect_edge_succ_nodup, the edge from 5 to 6 will
be removed because there exists one from 2 to 6.

following is correct patch:
--- gcc/gcc/tree-cfgcleanup.c~  Wed Mar  5 14:13:00 2008
+++ gcc/gcc/tree-cfgcleanup.c   Wed Mar  5 14:13:52 2008
@@ -418,6 +418,10 @@
 {
   bitmap_set_bit (cfgcleanup_altered_bbs, e->src->index);

+
+  bb->frequency -= EDGE_FREQUENCY(e);
+  bb->count -= e->count;
+
   if (e->flags & EDGE_ABNORMAL)
{
  /* If there is an abnormal edge, redirect it anyway, and

#
By the way, the frequency and count of forwarder block's succor will not be
affected because he is the only child of the forwarder block.

Anyone help me regression test it please


-- 


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

[Bug target/35466] Different assembly codes on 32bit and 64bit hosts

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-03-05 07:49 ---
This is a HWI issue.  I don't know how many times I tell people that x86 should
default to 64bit HWI if it uses TImode.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 GCC target triplet|x86_64-unknown-linux-gnu|i?86-*-* x86_64-*-*


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

[Bug tree-optimization/35467] New: Missed optimization in dependency analysis for arrays allocated by new()

[victork at gcc dot gnu dot org]

The code below demonstrates a missed optimization opportunity that
can have an impact on code. 
If arrays are allocated by new(), the static alias analysis is unable to
prove independency:
#include 
int
foo (void)
{
int *a = new int [1000];
int *b = new int [1000];
int x;

a[10] = 5;
b[10] = 6;
x = a[10];
return x;
}

=cut
While if the arrays are allocated by malloc(), the independency has been
proved:

#include 
int
foo (void)
{
int *a = (int*) malloc (sizeof(int) * 1000);
int *b = (int*) malloc (sizeof(int) * 1000);
int x;

a[10] = 5;
b[10] = 6;
x = a[10];
free (a);
free (b);
return x;
}

=cut

;; Function int foo() (_Z3foov)

Analyzing Edge Insertions.
int foo() ()
{
  int * b;
  int * a;
  void * D.2486;
  void * D.2485;

:
  D.2485 = malloc (4000);
  a = (int *) D.2485;
  D.2486 = malloc (4000);
  b = (int *) D.2486;
  *(a + 40) = 5;
  *(b + 40) = 6;
  free (a);
  free (b);
  return 5;

}

The ability to prove dependency in this kind of c++ source code can enable
vectorization for many loops.


-- 
   Summary: Missed optimization in dependency analysis for arrays
allocated by new()
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: victork at gcc dot gnu dot org


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

[Bug c++/23383] builtin array operator new is not marked with malloc attribute

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-03-05 07:48 ---
*** Bug 35467 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||victork at gcc dot gnu dot
   ||org


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

[Bug tree-optimization/35467] Missed optimization in dependency analysis for arrays allocated by new()

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-03-05 07:48 ---
I guess I have almost all the missed optimization bugs already filed or
something.  Anyways this is an exact duplicate of bug 23383 (which I filed :)
).

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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/35466] Different assembly codes on 32bit and 64bit hosts

[steven at gcc dot gnu dot org]

-- 

steven 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-03-05 07:39:17
   date||


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