[Bug fortran/34004] Accepts invalid: Ambigiuous interface with subroutine.

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2007-11-08 10:32 ---
> "Two dummy arguments are distinguishable if neither is a subroutine and
> neither is TKR compatible (5.1.1.2) with the other."
> 
> Does this mean, though, that a subroutine is or is not distinguishable from a
> variable?

This indeed means that for (checking) generic interfaces, a subroutine dummy is
not distinguishable from a variable or function dummy. (And for distinguishing
variables/functions dummies only TKR is used.)

See also
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/18873113b18cd5e9/
and there especially the (first) posts of Craig Dedo and Richard Maine.


-- 


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

[Bug fortran/34026] New: Internal compiler error: in gfc_add_modify, at fortran/trans.c:159

[Christian dot Carli at cern dot ch]

Attempt to compile pgplot (graphics library, ) with gfortran results in a
compiler error for one routine grfa.f.
 Computer: Mac Book Pro (intel hardware) (I could not reproduce the error under
Linux and older
   gfortran version)
 Operating system: Mac OS 10.4
 Compiler version: GNU Fortran (GCC) 4.3.0 20070810 (experimental)
   (downloaded from:
http://www.macresearch.org/xcode_gfortran_plugin_update)

 Command used (example - other options resulted in the same error):
gfortran -c -Wall -DSUN -DCVCALC -DBNDRY -pipe -O2  grfa.f
 Error message obtained:
grfa.f: In function 'grfa':
grfa.f:99: internal compiler error: in gfc_add_modify, at
fortran/trans.c:159
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
 Input files:
Since I did not find any way to attach the input files (grfa.f and
grpckg1.inc) to the 
present report, I put them into my /afs public into the folder:
/afs/cern.ch/user/c/carli/public/gfortranTest/
I hope this is convenient and you can access.

   I hope that this bug report is useful for you and contains the information
you need.
 Best regards,
Christian


-- 
   Summary: Internal compiler error: in gfc_add_modify, at
fortran/trans.c:159
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Christian dot Carli at cern dot ch


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

[Bug fortran/34025] New: Warning when compiling with -m64 -ffast-math on Intel Darwin

[dominiq at lps dot ens dot fr]

When compiling any fortran program on Intel Darwin with -m64 -ffast-math, I get
the following warning:

ld64 warning: in
/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin8/4.3.0/x86_64/crtfastmath.o, file is
not of required architecture

This yields the failure of gfortran.dg/pr32533.f90 and gfortran.dg/pr33794.f90.


-- 
   Summary: Warning when compiling with -m64 -ffast-math on Intel
Darwin
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
 GCC build triplet: i686-apple-darwin8
  GCC host triplet: i686-apple-darwin8
GCC target triplet: i686-apple-darwin8


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

[Bug target/32787] [4.2 Regression] Sun Studio 12 Undefined symbol addl

[uros at gcc dot gnu dot org]

--- Comment #11 from uros at gcc dot gnu dot org  2007-11-08 10:07 ---
Subject: Bug 32787

Author: uros
Date: Thu Nov  8 10:07:06 2007
New Revision: 129993

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129993
Log:
PR target/32787
Backport from mainline:

2007-11-06  Rask Ingemann Lambertsen  <[EMAIL PROTECTED]>

* config/i386/driver-i386.c: Test for __GNUC__ instead of
GCC_VERSION which is always defined.


Modified:
branches/gcc-4_2-branch/gcc/ChangeLog
branches/gcc-4_2-branch/gcc/config/i386/driver-i386.c


-- 


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

[Bug c/34024] infinite loop on longjmp with optimization

[schwab at suse dot de]

--- Comment #1 from schwab at suse dot de  2007-11-08 09:38 ---
A variable that is supposed to survive longjmp must be declared volatile.


-- 

schwab at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/32241] [4.1/4.2/4.3 regression] ICE trying to call x.~X(); in a template

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2007-
   ||11/msg00407.html
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-06-08 10:16:34 |2007-11-08 11:49:23
   date||


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

[Bug c++/34015] warning in backward_warning.h is illegible

[manu at gcc dot gnu dot org]

--- Comment #1 from manu at gcc dot gnu dot org  2007-11-08 10:56 ---
We cannot assume that people encountering the warning will have web access.
The warning can certainly be improved. 

"A list of valid replacements is as follows: Use: Instead of:" 
This doesn't actually explain what follows.

", basic_stringbuf , strstreambuf ,
basic_istringstream ,"
The comma makes it look like you should use basic_stringbuf instead of
.
Also, if strstream is replaced by several, it will be convenient to group them
( replaced by strstreambuf, ostrstream)

"To disable this warning use -Wno-deprecated."
There is a period missing before this sentence. I think it should go earlier,
so there is nothing else after the list of replacements.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-11-08 10:56:30
   date||


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

[Bug c++/34015] warning in backward_warning.h is illegible

[pcarlini at suse dot de]

--- Comment #2 from pcarlini at suse dot de  2007-11-08 11:05 ---
Let's add Benjamin in CC...


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 CC||bkoz at redhat dot com


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

Re: [Bug c++/34015] warning in backward_warning.h is illegible

[Gabriel Dos Reis]

"manu at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:

| We cannot assume that people encountering the warning will have web access.

That is true.  But, the majority of for those who do have a web
access, we should provide additional pointers.

Of course, the real solution is to leave these headers as they were
in previous GCC releases.

-- Gaby

[Bug c++/34015] warning in backward_warning.h is illegible

[gdr at cs dot tamu dot edu]

--- Comment #3 from gdr at cs dot tamu dot edu  2007-11-08 11:23 ---
Subject: Re:  warning in backward_warning.h is illegible

"manu at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:

| We cannot assume that people encountering the warning will have web access.

That is true.  But, the majority of for those who do have a web
access, we should provide additional pointers.

Of course, the real solution is to leave these headers as they were
in previous GCC releases.

-- Gaby


-- 


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

[Bug fortran/34025] Warning when compiling with -m64 -ffast-math on Intel Darwin

[fxcoudert at gcc dot gnu dot org]

--- Comment #1 from fxcoudert at gcc dot gnu dot org  2007-11-08 12:36 
---
Can you get the same warning with a C program? And can you please post the
output of running gfortran with -v, so that we know what subprocesses are
invoked and what arguments they get passed?


-- 

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

[Bug target/32787] [4.2 Regression] Sun Studio 12 Undefined symbol addl

[ubizjak at gmail dot com]

--- Comment #12 from ubizjak at gmail dot com  2007-11-08 10:23 ---
(In reply to comment #8)

> Thanks for the suggestion.  I think it should use the assembler when
> compiling with Sun Studio 12.

Please note that this part of gcc driver is only activated when -march=native
is added to compile flags. When sunpro is used as stage1 compiler,
-march=native functionality of the driver will be disabled, but will be
re-enabled in later stages when gcc will compile itself.

I didn't test this, but IMO -march=native functionality will remain disabled
when non-bootstrapped gcc is built with non-gcc compiler.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/33826] [4.1/4.2/4.3 Regression] GCC generates wrong code for infinitely recursive functions

[richard dot guenther at gmail dot com]

--- Comment #12 from richard dot guenther at gmail dot com  2007-11-08 
09:08 ---
Subject: Re:  [4.1/4.2/4.3 Regression] GCC generates wrong code for infinitely
recursive functions

On 11/7/07, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
> This patch keeps recursive functions from being marked as pure or const.
>
> Full testing in progress on x86-64.  But the code seems to work properly.
>
> Ok to commit when the full testing is finished?

Ok.

Thanks,
Richard.

> Kenny
>
> 2007-11-07  Kenneth Zadeck <[EMAIL PROTECTED]>
>
> PR middle-end/33826
> * ipa-pure-const (static_execute): Added code to keep recursive
> functions from being marked as pure or const.
> * ipa-utils (searchc): Fixed comment.
>
> 2007-11-07  Kenneth Zadeck <[EMAIL PROTECTED]>
>
> PR middle-end/33826
> * gcc.dg/pr33826.c: New.
>
>
>
>


-- 


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

[Bug c/34027] New: [4.3 regression] -Os code size nearly doubled

[bunk at stusta dot de]

PR32044 makes it for months impossible to compile the Linux kernel with gcc
4.3, but I'll leave the discussions who's technically at fault (and whether gcc
4.3 will ever be able to compile the Linux kernel) to the people who know more
about such things.

But the fact that the code emitted with -Os used is nearly twice as big that's
a  regression in gcc.

Test case:

$ cat test.c
unsigned long long foobar(unsigned long long ns)
{
  while(ns >= 10L)
ns -= 10L;
  return ns;
}
$ gcc --version
gcc (GCC) 4.2.3 20071014 (prerelease) (Debian 4.2.2-3)
...
$ gcc -Os test.c -c -o old-gcc.o
$ /usr/local/DIR/gcc-svn20071108/bin/gcc -Os test.c -c -o new-gcc.o
$ objdump -D old-gcc.o 

old-gcc.o: file format elf32-i386

Disassembly of section .text:

 :
   0:   55  push   %ebp
   1:   89 e5   mov%esp,%ebp
   3:   8b 45 08mov0x8(%ebp),%eax
   6:   8b 55 0cmov0xc(%ebp),%edx
   9:   eb 08   jmp13 
   b:   05 00 36 65 c4  add$0xc4653600,%eax
  10:   83 d2 ffadc$0x,%edx
  13:   83 fa 00cmp$0x0,%edx
  16:   77 f3   ja b 
  18:   3d ff c9 9a 3b  cmp$0x3b9ac9ff,%eax
  1d:   77 ec   ja b 
  1f:   5d  pop%ebp
  20:   c3  ret
Disassembly of section .comment:
...
$ objdump -D new-gcc.o 

new-gcc.o: file format elf32-i386

Disassembly of section .text:

 :
   0:   55  push   %ebp
   1:   89 e5   mov%esp,%ebp
   3:   57  push   %edi
   4:   56  push   %esi
   5:   53  push   %ebx
   6:   bb 00 36 65 c4  mov$0xc4653600,%ebx
   b:   83 ec 0csub$0xc,%esp
   e:   8b 7d 0cmov0xc(%ebp),%edi
  11:   8b 75 08mov0x8(%ebp),%esi
  14:   6a 00   push   $0x0
  16:   68 00 ca 9a 3b  push   $0x3b9aca00
  1b:   57  push   %edi
  1c:   56  push   %esi
  1d:   e8 fc ff ff ff  call   1e 
  22:   83 c4 10add$0x10,%esp
  25:   69 ca 00 36 65 c4   imul   $0xc4653600,%edx,%ecx
  2b:   29 c1   sub%eax,%ecx
  2d:   f7 e3   mul%ebx
  2f:   01 f0   add%esi,%eax
  31:   8d 14 11lea(%ecx,%edx,1),%edx
  34:   11 fa   adc%edi,%edx
  36:   8d 65 f4lea-0xc(%ebp),%esp
  39:   5b  pop%ebx
  3a:   5e  pop%esi
  3b:   5f  pop%edi
  3c:   5d  pop%ebp
  3d:   c3  ret
Disassembly of section .comment:
...
$


-- 
   Summary: [4.3 regression] -Os code size nearly doubled
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bunk at stusta dot de
 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=34027

[Bug tree-optimization/33434] [4.3 Regression] inlining miscompilation

[hubicka at gcc dot gnu dot org]

--- Comment #15 from hubicka at gcc dot gnu dot org  2007-11-08 12:42 
---
The problem here is that code assumes that variable without DEFAULT_DEF is not
in SSA.  Arguments that are unused also do have DEFAULT_DEF=NULL, this patch
should fix it. I am testing it now.

Honza
Index: tree-inline.c
===
*** tree-inline.c   (revision 129992)
--- tree-inline.c   (working copy)
*** setup_one_parameter (copy_body_data *id,
*** 1420,1425 
--- 1420,1434 
&& !useless_type_conversion_p (TREE_TYPE (p), TREE_TYPE (value)))
  rhs = fold_build1 (NOP_EXPR, TREE_TYPE (p), value);

+   /* If the value of argument is never used, don't care about initializing
it.
+  This is needed for correctness since we otherwise confuse it with
non-SSA
+  variable later and end up renaming otherwise.  */
+   if (gimple_in_ssa_p (cfun) && is_gimple_reg (p) && !def)
+ {
+   gcc_assert (!TREE_SIDE_EFFECTS (value));
+   return;
+ }
+ 
/* If the parameter is never assigned to, has no SSA_NAMEs created,
   we may not need to create a new variable here at all.  Instead, we may
   be able to just use the argument value.  */


-- 


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

[Bug fortran/34026] Internal compiler error: in gfc_add_modify, at fortran/trans.c:159

[fxcoudert at gcc dot gnu dot org]

--- Comment #1 from fxcoudert at gcc dot gnu dot org  2007-11-08 12:45 
---
(In reply to comment #0)
> Since I did not find any way to attach the input files (grfa.f and
> grpckg1.inc) to the present report

Once you write the report, there is a "Create a New Attachment" link on the
bugzilla page for your report.

> /afs/cern.ch/user/c/carli/public/gfortranTest/
> I hope this is convenient and you can access.

I have absolutely no idea how to access that file. Can you either attach it as
described above, or make it available under a widely-used protocol (HTTP, FTP,
...)


-- 


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

[Bug fortran/34020] Bogus codegen for openmp atomics w/ indirects operands on IPF

[fxcoudert at gcc dot gnu dot org]

--- Comment #1 from fxcoudert at gcc dot gnu dot org  2007-11-08 12:49 
---
Does the same thing happen with C?

void foo(float *lhs, float*rhs) {
#pragma omp atomic
  *lhs = *rhs + *lhs;
}


-- 

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

[Bug fortran/34026] Internal compiler error: in gfc_add_modify, at fortran/trans.c:159

[Christian dot Carli at cern dot ch]

--- Comment #2 from Christian dot Carli at cern dot ch  2007-11-08 12:51 
---
Created an attachment (id=14506)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14506&action=view)
Fortran source file


-- 


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

[Bug fortran/34026] Internal compiler error: in gfc_add_modify, at fortran/trans.c:159

[Christian dot Carli at cern dot ch]

--- Comment #3 from Christian dot Carli at cern dot ch  2007-11-08 12:53 
---
Created an attachment (id=14507)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14507&action=view)
Include File


-- 


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

[Bug tree-optimization/32575] [4.2/4.3 regression] With -ftree-vrp miscompiles a single line of code in SQLite

[jakub at gcc dot gnu dot org]

--- Comment #16 from jakub at gcc dot gnu dot org  2007-11-08 12:54 ---
Continuing after the #c11 .. #c15 unrelated PR32540 comments with the original
bug:

I've built -r127926 and -r127927 cc1 and it seems this wasn't fixed just by
a side-effect.
Although p can be either retval of foo or &q, we had in 127926:
  # pD.2027_1 = PHI 
  # qD.2028_18 = VDEF  { qD.2028 }
  pD.2027_1->s1D.2010 = aD.2023_6(D);
while 127927 has:
  # pD.2027_1 = PHI 
  # qD.2028_19 = VDEF 
  # SMT.26D.2082_20 = VDEF  { qD.2028 SMT.26D.2082 }
  pD.2027_1->s1D.2010 = aD.2023_6(D);

-pD.2027_1, name memory tag: NMT.27D.2083, is dereferenced, points-to vars: { q
}
+pD.2027_1, name memory tag: NMT.27D.2083, is dereferenced, points-to vars: { q
SMT.26 }

So guess I'll just submit the testcase for inclusion on the trunk and then we
can close this PR.


-- 


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

[Bug fortran/34026] Internal compiler error: in gfc_add_modify, at fortran/trans.c:159

[Christian dot Carli at cern dot ch]

--- Comment #4 from Christian dot Carli at cern dot ch  2007-11-08 13:05 
---
Subject: Re:  Internal compiler error: in gfc_add_modify, at
fortran/trans.c:159

   Hello,

The two files needed to (re)produce the error message have been  
uploaded
via the bugzilla interface.
I have continued to play a bit with the source code to isolate  
where the error
comes from.  The error disappears, if one comments out the 101st line  
of the
source file grfa.f:
C  DO 40 LINE = NINT(YMIN/DY),NINT(YMAX/DY)
Splitting this command into three lines (and defining INTEGERs  
LINEMIN and
LINEMAX) works and gives the following:
   LINEMIN=NINT(YMIN/DY)
   LINEMAX=NINT(YMAX/DY)
   DO 40 LINE = LINEMIN, LINEMAX

I hope that the files and the additional comment are useful for  
you.  Thanks a
lot for having a look on this problem.
  Best regards,
Christian

On Nov 8, 2007, at 1:45 PM, fxcoudert at gcc dot gnu dot org wrote:

>
>
> --- Comment #1 from fxcoudert at gcc dot gnu dot org   
> 2007-11-08 12:45 ---
> (In reply to comment #0)
>> Since I did not find any way to attach the input files (grfa.f and
>> grpckg1.inc) to the present report
>
> Once you write the report, there is a "Create a New Attachment"  
> link on the
> bugzilla page for your report.
>
>> /afs/cern.ch/user/c/carli/public/gfortranTest/
>> I hope this is convenient and you can access.
>
> I have absolutely no idea how to access that file. Can you either  
> attach it as
> described above, or make it available under a widely-used protocol  
> (HTTP, FTP,
> ...)
>
>
> -- 
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34026
>
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone who is.
> You reported the bug, or are watching the reporter.


-- 


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

[Bug tree-optimization/32575] [4.2/4.3 regression] With -ftree-vrp miscompiles a single line of code in SQLite

[jakub at gcc dot gnu dot org]

--- Comment #17 from jakub at gcc dot gnu dot org  2007-11-08 13:08 ---
Subject: Bug 32575

Author: jakub
Date: Thu Nov  8 13:07:54 2007
New Revision: 129998

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129998
Log:
PR tree-optimization/32575
* gcc.c-torture/execute/20071108-1.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/20071108-1.c
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug tree-optimization/32575] [4.2 regression] With -ftree-vrp miscompiles a single line of code in SQLite

[jakub at gcc dot gnu dot org]

--- Comment #18 from jakub at gcc dot gnu dot org  2007-11-08 13:11 ---
I have also retested with the http://www.sqlite.org/gccbug32575.tar.gz
tarball and on the trunk it passes just fine with -O2.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.2/4.3 regression] With - |[4.2 regression] With -
   |ftree-vrp miscompiles a |ftree-vrp miscompiles a
   |single line of code in  |single line of code in
   |SQLite  |SQLite


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

[Bug c++/34015] warning in backward_warning.h is illegible

[manu at gcc dot gnu dot org]

--- Comment #4 from manu at gcc dot gnu dot org  2007-11-08 13:13 ---
This is my proposal.

"This header is deprecated and may be removed in the future.  Please, consider
using an equivalent, non-deprecated interface for the requested functionality. 
To disable this warning use -Wno-deprecated.  A list of valid replacements is
as follows: 
 is replaced by , ,
, ;   is replaced by
, , , ;   is
replaced by , ;   is replaced
by , , , ;  
is replaced by , ;   is replaced
by , , ;   is replaced by ,
."

I just re-organized the information, not sure if it is actually correct. I
noticed that  is replaced by . So how would you get a
warning there? The same happens with . How can a header be
replaced with the a new header with the same name?


-- 


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

[Bug fortran/34025] Warning when compiling with -m64 -ffast-math on Intel Darwin

[dominiq at lps dot ens dot fr]

--- Comment #2 from dominiq at lps dot ens dot fr  2007-11-08 13:19 ---
> Can you get the same warning with a C program?

Yes

> And can you please post the output of running gfortran with -v

[ibook-dhum] f90/bug% gfc -v -m64 -ffast-math ac.f90
Driving: gfc -mmacosx-version-min=10.4 -v -m64 -ffast-math ac.f90
-lgfortranbegin -lgfortran -shared-libgcc
Using built-in specs.
Target: i686-apple-darwin8
Configured with: ../gcc-4.3-work/configure --prefix=/opt/gcc/gcc4.3w
--mandir=/opt/gcc/gcc4.3w/share/man --infodir=/opt/gcc/gcc4.3w/share/info
--build=i686-apple-darwin8 --enable-languages=c,c++,fortran,objc,obj-c++
--with-gmp=/sw --with-libiconv-prefix=/sw --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
Thread model: posix
gcc version 4.3.0 20071108 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.4' '-v' '-m64' '-ffast-math'
'-shared-libgcc' '-mtune=generic'
 /opt/gcc/gcc4.3w/libexec/gcc/i686-apple-darwin8/4.3.0/f951 ac.f90 -fPIC -quiet
-dumpbase ac.f90 -mmacosx-version-min=10.4 -m64 -mtune=generic -auxbase ac
-version -ffast-math -fintrinsic-modules-path
/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin8/4.3.0/finclude -o
/var/tmp//ccjovyzu.s
GNU F95 (GCC) version 4.3.0 20071108 (experimental) (i686-apple-darwin8)
compiled by GNU C version 4.3.0 20071108 (experimental), GMP version
4.2.1, MPFR version 2.2.1.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.4' '-v' '-m64' '-ffast-math'
'-shared-libgcc' '-mtune=generic'
 as -arch x86_64 -force_cpusubtype_ALL -o /var/tmp//cc5GHKYm.o
/var/tmp//ccjovyzu.s
COMPILER_PATH=/opt/gcc/gcc4.3w/libexec/gcc/i686-apple-darwin8/4.3.0/:/opt/gcc/gcc4.3w/libexec/gcc/i686-apple-darwin8/4.3.0/:/opt/gcc/gcc4.3w/libexec/gcc/i686-apple-darwin8/:/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin8/4.3.0/:/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin8/:/usr/libexec/gcc/i686-apple-darwin8/:/usr/lib/gcc/i686-apple-darwin8/
LIBRARY_PATH=/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin8/4.3.0/x86_64/:/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin8/4.3.0/../../../x86_64/:/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin8/4.3.0/:/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin8/4.3.0/../../../:/usr/lib/
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.4' '-v' '-m64' '-ffast-math'
'-shared-libgcc' '-mtune=generic'
 /opt/gcc/gcc4.3w/libexec/gcc/i686-apple-darwin8/4.3.0/collect2 -dynamic -arch
x86_64 -macosx_version_min 10.4 -multiply_defined suppress
-weak_reference_mismatches non-weak -o a.out -lcrt1.o
/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin8/4.3.0/x86_64/crt3.o
-L/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin8/4.3.0/x86_64
-L/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin8/4.3.0/../../../x86_64
-L/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin8/4.3.0
-L/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin8/4.3.0/../../..
/var/tmp//cc5GHKYm.o -lgfortranbegin -lgfortran -lgcc_s.10.4 -lgcc -lSystem
/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin8/4.3.0/x86_64/crtfastmath.o
ld64 warning: in
/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin8/4.3.0/x86_64/crtfastmath.o, file is
not of required architecture
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.4' '-v' '-m64' '-ffast-math'
'-shared-libgcc' '-mtune=generic'


-- 


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

[Bug fortran/34028] New: Type mismatch with optimization of ISHFT

[fxcoudert at gcc dot gnu dot org]

Happens on x86-linux, with both -m32 and -m64. Spotted by running the testsuite
with -fdefault-integer-8.

$ cat intrinsic_bitops.f90
   implicit none
   integer(kind=4) :: k, o

   o = 0
   k = 12

   if (ishft (k, o+2_8) .ne. 48_8) call abort
end
$ gfortran -O2 intrinsic_bitops.f90
intrinsic_bitops.f90: In function ‘MAIN__’:
intrinsic_bitops.f90:1: error: type mismatch in comparison expression
logical4

int8

int4

if (D.864 <= 31)
  {
if (o >= -2)
  {
D.862 = (int8) o;
D.863 = D.862 + 2;
D.864 = ABS_EXPR ;
D.866 = k << D.864;
iftmp.2 = D.866 != 48;
  }
else
  {
k.3 = () k;
D.862 = (int8) o;
D.863 = D.862 + 2;
D.864 = ABS_EXPR ;
D.868 = k.3 >> D.864;
iftmp.2 = D.868 != 48;
  }
iftmp.1 = iftmp.2;
  }
else
  {
iftmp.1 = 1;
  }
intrinsic_bitops.f90:1: internal compiler error: verify_gimple failed


The tree dump is:
ABS_EXPR <(int8) o + 2> <= 31 ? o >= -2 ? k << ABS_EXPR <(int8) o + 2> != 48 :
() k >> ABS_EXPR <(int8) o + 2> != 48 : 1

The problem arises from the fact that 31 above is int4, while ABS_EXPR <(int8)
o + 2> is int8. The following patch fixes it:

Index: trans-intrinsic.c
===
--- trans-intrinsic.c   (revision 129869)
+++ trans-intrinsic.c   (working copy)
@@ -2533,7 +2533,7 @@ gfc_conv_intrinsic_ishft (gfc_se * se, g
   /* The Fortran standard allows shift widths <= BIT_SIZE(I), whereas
  gcc requires a shift width < BIT_SIZE(I), so we have to catch this
  special case.  */
-  num_bits = build_int_cst (TREE_TYPE (args[0]), TYPE_PRECISION (type));
+  num_bits = build_int_cst (TREE_TYPE (args[1]), TYPE_PRECISION (type));
   cond = fold_build2 (GE_EXPR, boolean_type_node, width, num_bits);


-- 
   Summary: Type mismatch with optimization of ISHFT
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, patch
  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=34028

[Bug fortran/34028] Type mismatch with optimization of ISHFT

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |fxcoudert at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-11-08 13:20:40
   date||
   Target Milestone|--- |4.3.0


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

[Bug target/16350] gcc only understands little endian ARM systems

[nickc at gcc dot gnu dot org]

--- Comment #15 from nickc at gcc dot gnu dot org  2007-11-08 13:44 ---
Subject: Bug 16350

Author: nickc
Date: Thu Nov  8 13:44:09 2007
New Revision: 12

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=12
Log:
  PR target/16350
* config.gcc: For arm*b-* define TARGET_BIG_ENDIAN_DEFAULT.
* config/arm/linux-elf.h (TARGET_ENDIAN_DEFAULT): Define based on
TARGET_BIG_ENDIAN_DEFAULT.
   Use for MULTILIB_DEFAULTS.
   (TARGET_DEFAULT): Set according to TARGET_ENDIAN_DEFAULT.
   (LINUX_TARGET_LINK_SPEC): Pass -mlittle-endian on to the assembler.
* config/arm/linux-eabi.h (TARGET_LINKER_EMULATION): Set according to
TARGET_BIG_ENDIAN_DEFAULT.
   (SUBTARGET_EXTRA_LINK_SPEC): Likewise.
* gcc/config/arm/bpabi.h (TARGET_DEFAULT_MASK): Set according to
TARGET_BIG_ENDIAN_DEFAULT.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config.gcc
trunk/gcc/config/arm/bpabi.h
trunk/gcc/config/arm/linux-eabi.h
trunk/gcc/config/arm/linux-elf.h


-- 


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

[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use

[manu at gcc dot gnu dot org]

--- Comment #19 from manu at gcc dot gnu dot org  2007-11-08 14:22 ---
(In reply to comment #16)
> One possible solution would be to annotate the division by the expected value
> of the result.  Division expanders then may decide whether to expand to 
> machine
> instruction/libcall or to check for small values of the result in if-guards
> first.
> 

Well, that won't achieve at all what the user wants, that is, to not get a call
to __udividi3. 

There are 2 issues here:

1) GCC replaces the loop by division. This may or may not be more efficient. In
this case, it is not. In many other cases, it is.

2) The user does not want a call to __udividi3.

If I understand correctly you need __udividi3 to do the division, am I wrong?
Of course, you could "inline" it or link statically to avoid libgcc. The former
will pessimize the code in most cases and the latter can be done by the user.  

Tricky. Is it possible to fix (2) without fixing (1)?


-- 


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

[Bug libfortran/32770] [Meta-bug] -fdefault-integer-8 issues

[fxcoudert at gcc dot gnu dot org]

--- Comment #30 from fxcoudert at gcc dot gnu dot org  2007-11-08 14:08 
---
(In reply to comment #29)
> gfortran.fortran-torture/execute/intrinsic_bitops.f90

This one is now PR34028, for which I have a patch. The others one aren't ICEs,
but matches my regexp because they have "internal" in the testcase name ;-)


-- 


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

[Bug tree-optimization/34029] internal compiler error: verify_stmts failed

[holger dot hopp at sap dot com]

--- Comment #1 from holger dot hopp at sap dot com  2007-11-08 13:41 ---
Created an attachment (id=14508)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14508&action=view)
reproducer


-- 


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

[Bug tree-optimization/34029] New: internal compiler error: verify_stmts failed

[holger dot hopp at sap dot com]

I discovered following internal compiler error in gcc 4.3.0 (trunk).
The cause is the svn change 125925.

The title sounds to be similar to bug 34018, but the removal of change
125925 does not help for bug 34018. So this bug must be something
different.

gcc version:  gcc 4.3.0 svn revision 125925 and later
at least with gcc 4.3.0 svn revision 129958 (20071107).

$ gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=...my_path... --enable-shared
--with-gmp=...my_path... --with-mpfr=...my_path... --enable-languages=c,c++
Thread model: posix
gcc version 4.3.0 20071107 (experimental) (GCC)

steps to reproduce:

$ gcc -O2 -c testcase.c
testcase.c: In function 'checkVersionLibtestcase':
testcase.c:10: error: invalid array index
20 - () &version_testcase;

testcase.c:10: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Exit 1

Without optimization it compiles fine:
$ gcc -c testcase.c

Commenting out change 125925 also compiles fine (patch attached).


-- 
   Summary: internal compiler error: verify_stmts failed
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: holger dot hopp at sap dot com
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug target/16350] gcc only understands little endian ARM systems

[nickc at redhat dot com]

--- Comment #16 from nickc at redhat dot com  2007-11-08 13:47 ---
Hi Bernhard,

  I have applied your patch.  I made one small change:  I adjusted the new
comments in the header files to:

  /* TARGET_BIG_ENDIAN_DEFAULT is set in
 config.gcc for big endian configurations.  */

This was conformance with the GNU Coding Standards and also for brevity.

Cheers
  Nick


-- 


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

[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use

[manu at gcc dot gnu dot org]

--- Comment #18 from manu at gcc dot gnu dot org  2007-11-08 13:47 ---
(In reply to comment #4)
> > (probably the condition check is too conservative
> > so this isn't fully cooked yet):
> 
> Way too conservative because even if you don't have the opcode, sometimes code
> can be produced without calling the libcall.
> If you change the define to:
> #define NSEC_PER_SEC  0x1000UL
> 
> You will not get an call udividi3, though there is still a divide in unsigned
> long long, the division can be done exactly (via shifting).
> 

Just to understand the issue better. Which pass/function is responsible to
detect that the division can be done exactly and replace it by a shift? Can't
this be checked when the result is computed and moved outside the loop?

By the way, __builtin_expect generates a probability of >90% of exiting the
loop. Shouldn't that be taken into account when moving anything outside the
loop?


-- 


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

[Bug middle-end/34006] [4.2 only] vectorization with 64-bit integers

[fxcoudert at gcc dot gnu dot org]

--- Comment #3 from fxcoudert at gcc dot gnu dot org  2007-11-08 14:04 
---
Testcase that doesn't require -fdefault-integer-8:

$ cat a.f90
program test
  integer(kind=8) nvec(10), ivec(10), nclass
  integer i
  nvec(:)= 1
  ivec(:) = 0
  call zbase(nvec,ivec,10)
  write(*,'(10I3)') ivec
end

subroutine zbase(nvec,ivec,nclass)
  integer(kind=8) nvec(10), ivec(10), iclass
  integer nclass
  do iclass = 2,nclass
ivec(iclass) = ivec(iclass-1)+nvec(iclass-1)
  end do
end
$ gfortran-4.2.2 -O1 a.f90 && ./a.out
  0  1  2  3  4  5  6  7  8  9
$ gfortran-4.2.2 -O1 -ftree-vectorize a.f90 && ./a.out
  0  1  2  1  2  1  2  1  2  1

I can't make a C testcase out of this, but I really think that the code emitted
by the front-end is fine, thus I'm recategorizing this as middle-end.

Also: on my x86_64-linux, it works fine for 4.1.2.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
  Component|fortran |middle-end
 Ever Confirmed|0   |1
   GCC host triplet|Linux_x86-64 CentOS |
 GCC target triplet||x86_64-linux
   Keywords||wrong-code
  Known to fail||4.2.2
  Known to work||4.3.0
   Last reconfirmed|-00-00 00:00:00 |2007-11-08 14:04:26
   date||
Summary|vectorization with 64-bit   |[4.2 only] vectorization
   |integers|with 64-bit integers


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

[Bug target/16350] gcc only understands little endian ARM systems

[buytenh at wantstofly dot org]

--- Comment #17 from buytenh at wantstofly dot org  2007-11-08 14:26 ---
Subject: Re:  gcc only understands little endian ARM systems

When I (not Bernhard) wrote the original patch, Richard Earnshaw
didn't like the approach.  See:

http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02265.html


-- 


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

[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use

[rakdver at kam dot mff dot cuni dot cz]

--- Comment #20 from rakdver at kam dot mff dot cuni dot cz  2007-11-08 
14:46 ---
Subject: Re:  [4.3 regression] udivdi3 counterproductive, unwarranted use

> --- Comment #19 from manu at gcc dot gnu dot org  2007-11-08 14:22 ---
> (In reply to comment #16)
> > One possible solution would be to annotate the division by the expected 
> > value
> > of the result.  Division expanders then may decide whether to expand to 
> > machine
> > instruction/libcall or to check for small values of the result in if-guards
> > first.
> > 
> 
> Well, that won't achieve at all what the user wants, that is, to not get a 
> call
> to __udividi3. 

However, it would avoid calling the division most of the time, i.e.,
for performance this would be a possible solution.

> There are 2 issues here:
> 
> 1) GCC replaces the loop by division. This may or may not be more efficient. 
> In
> this case, it is not. In many other cases, it is.

The code performing the replacement should probably check what is the
expected # of iterations of the loop, and compute which way is more
efficient.  However, it is a bit difficult to get this work correctly.

> 2) The user does not want a call to __udividi3.

There is nothing wrong with calling __udividi3, once the division is
introduced.


-- 


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

[Bug fortran/34028] Type mismatch with optimization of ISHFT

[fxcoudert at gcc dot gnu dot org]

--- Comment #2 from fxcoudert at gcc dot gnu dot org  2007-11-08 15:35 
---
Fixed.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/34015] warning in backward_warning.h is illegible

[benoit dot hudson at gmail dot com]

--- Comment #5 from benoit dot hudson at gmail dot com  2007-11-08 15:35 
---
The fact that the error appears in backward_warning.h is another annoyance,
which is probably why the overly long descriptive message is there.  Better
would be that #include  would only report " is
deprecated; please use  instead."  Then the file listed as generating
the problem is hash_set included from the user's code, and the message
specifically says what's wrong, and the message fits on one line in a standard
terminal.


-- 


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

[Bug fortran/34028] Type mismatch with optimization of ISHFT

[fxcoudert at gcc dot gnu dot org]

--- Comment #1 from fxcoudert at gcc dot gnu dot org  2007-11-08 15:33 
---
Subject: Bug 34028

Author: fxcoudert
Date: Thu Nov  8 15:33:23 2007
New Revision: 130003

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130003
Log:
PR fortran/34028
* trans-intrinsic.c (gfc_conv_intrinsic_ishft): Use correct type.

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


-- 


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

[Bug bootstrap/34003] [4.2/4.3 Regression] gcc 4.3.0 unable to bootstrap itself; Unsatisfied symbols: ggc_free

[rsandifo at gcc dot gnu dot org]

--- Comment #12 from rsandifo at gcc dot gnu dot org  2007-11-08 16:10 
---
Interesting.  Something platform-specific must be going wrong here.
The original build failure shouldn't have happened even without
the attached patch because ggc-none.o should provide a definition
of ggc_free.  The cc1 link shouldn't fail because $(GGC).o should
be linked into libbackend.a.

It's probably easier to track down why the original failure happened,
rather than why the cc1 one happened, so could you try again without
the patch I attached and see why ggc-none.o isn't providing a
definition of ggc_free?

As things stand, I don't think this was caused by my 2006 patch
after all, so I'll unassign myself to avoid confusion.  (I'll keep
myself on cc: because I'm curious what's wrong.)


-- 

rsandifo at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu dot
   ||org
 Status|WAITING |NEW
   Last reconfirmed|2007-11-06 21:38:47 |2007-11-08 16:10:18
   date||


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

[Bug fortran/33917] Rejects valid PROCEDURE declarations

[burnus at gcc dot gnu dot org]

--- Comment #7 from burnus at gcc dot gnu dot org  2007-11-08 15:28 ---
Subject: Bug 33917

Author: burnus
Date: Thu Nov  8 15:28:30 2007
New Revision: 130002

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130002
Log:
2007-11-08  Tobias Burnus  <[EMAIL PROTECTED]>

PR fortran/33917
* interface.c (check_sym_interfaces): Disallow PROCEDURE-declared
procedures for MODULE PROCEDURE.
* decl.c (match_procedure_in_interface): Do not mark as procedure.

2007-11-08  Tobias Burnus  <[EMAIL PROTECTED]>

PR fortran/33917
* gfortran.dg/proc_decl_5.f90: New.
* gfortran.dg/proc_decl_6.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/proc_decl_5.f90
trunk/gcc/testsuite/gfortran.dg/proc_decl_6.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/interface.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/33945] PROCEDURE in module somtimes wrongly rejected

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2007-11-08 15:29 ---
Both problems fixed on the trunk (4.3.0). Other branches are not affected as
PROCEDURE is new.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug fortran/33917] Rejects valid PROCEDURE declarations

[burnus at gcc dot gnu dot org]

--- Comment #8 from burnus at gcc dot gnu dot org  2007-11-08 15:36 ---
Sorry, the check in was for PR 33917.


-- 


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

[Bug fortran/33945] PROCEDURE in module somtimes wrongly rejected

[burnus at gcc dot gnu dot org]

--- Comment #5 from burnus at gcc dot gnu dot org  2007-11-08 15:39 ---
The check-in was the following (note the wrong bug number).

Author: burnus
Date: Thu Nov  8 15:28:30 2007
New Revision: 130002

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130002
Log:
2007-11-08  Tobias Burnus  <[EMAIL PROTECTED]>

PR fortran/33917
* interface.c (check_sym_interfaces): Disallow PROCEDURE-declared
procedures for MODULE PROCEDURE.
* decl.c (match_procedure_in_interface): Do not mark as procedure.

2007-11-08  Tobias Burnus  <[EMAIL PROTECTED]>

PR fortran/33917
* gfortran.dg/proc_decl_5.f90: New.
* gfortran.dg/proc_decl_6.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/proc_decl_5.f90
trunk/gcc/testsuite/gfortran.dg/proc_decl_6.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/interface.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/34001] Incorrect __attribute__ fastcall behavior

[hjl at lucon dot org]

--- Comment #1 from hjl at lucon dot org  2007-11-08 17:12 ---
I verified that it isn't fixed in gcc 4.3.0.


-- 

hjl at lucon dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-11-08 17:12:05
   date||
   Target Milestone|--- |4.3.0
Version|4.0.1   |4.3.0


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

[Bug c/34030] New: ICE in in compare_values_warnv, at tree-vrp.c:701

[christophe dot lyon at st dot com]

When compiling this sample code
int myvar;

int foo(int mynum)
{
if void *)0) ==
 (
  myvar & ((1U<<0) << mynum)
 )
 )
&& (mynum > 0)
)
  {
return 1;
  }
return 0;
}

with GCC-4.1.1, 4.1.2, 4.2.2, I get:
internal compiler error: in compare_values_warnv, at tree-vrp.c:701

It occurs only when compiling at -O2, -O3 or -Os, not at -O1.

If I remove the (void*) cast, compilation is successful.


-- 
   Summary: ICE in in compare_values_warnv, at tree-vrp.c:701
   Product: gcc
   Version: 4.2.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: christophe dot lyon at st 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=34030

[Bug fortran/22552] Would like warning when an undeclared function is called

[fxcoudert at gcc dot gnu dot org]

--- Comment #2 from fxcoudert at gcc dot gnu dot org  2007-11-08 17:59 
---
I'm not sure about the wording, but the following patch does what you want:

Index: interface.c
===
--- interface.c (revision 129869)
+++ interface.c (working copy)
@@ -2216,12 +2216,16 @@ check_intents (gfc_formal_arglist *f, gf
 void
 gfc_procedure_use (gfc_symbol *sym, gfc_actual_arglist **ap, locus *where)
 {
-
-  /* Warn about calls with an implicit interface.  */
+  /* Warn about calls with an implicit interface, or to procedures not
+ explicitly declared.  */
   if (gfc_option.warn_implicit_interface
   && sym->attr.if_source == IFSRC_UNKNOWN)
 gfc_warning ("Procedure '%s' called with an implicit interface at %L",
 sym->name, where);
+  else if (gfc_option.warn_implicit_procedure && sym->attr.proc ==
PROC_UNKNOWN
+  && sym->attr.if_source == IFSRC_UNKNOWN)
+gfc_warning ("Procedure '%s' called at %L is not explicitly declared",
+sym->name, where);

   if (sym->attr.if_source == IFSRC_UNKNOWN
   || !compare_actual_formal (ap, sym->formal, 0,


You also need to add the option in lang.opt and gfortran.h, and handle it in
options.c, of course ;-)


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
   Keywords||patch
   Last reconfirmed|2005-12-30 19:42:48 |2007-11-08 17:59:32
   date||


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

[Bug tree-optimization/33826] [4.1/4.2/4.3 Regression] GCC generates wrong code for infinitely recursive functions

[zadeck at naturalbridge dot com]

--- Comment #15 from zadeck at naturalbridge dot com  2007-11-08 16:49 
---
fixed


-- 

zadeck at naturalbridge dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/33826] [4.1/4.2/4.3 Regression] GCC generates wrong code for infinitely recursive functions

[zadeck at naturalbridge dot com]

--- Comment #14 from zadeck at naturalbridge dot com  2007-11-08 16:48 
---
Subject: Re:  [4.1/4.2/4.3 Regression] GCC generates
 wrong code for infinitely recursive functions

Richard Guenther wrote:
> On 11/7/07, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
>   
>> This patch keeps recursive functions from being marked as pure or const.
>>
>> Full testing in progress on x86-64.  But the code seems to work properly.
>>
>> Ok to commit when the full testing is finished?
>> 
>
> Ok.
>
> Thanks,
> Richard.
>
>   
>> Kenny
>>
>> 2007-11-07  Kenneth Zadeck <[EMAIL PROTECTED]>
>>
>> PR middle-end/33826
>> * ipa-pure-const (static_execute): Added code to keep recursive
>> functions from being marked as pure or const.
>> * ipa-utils (searchc): Fixed comment.
>>
>> 2007-11-07  Kenneth Zadeck <[EMAIL PROTECTED]>
>>
>> PR middle-end/33826
>> * gcc.dg/pr33826.c: New.
>>
>>
>>
>>
>> 
committed as revision 130006.

kenny

Index: testsuite/gcc.dg/pr33826.c
===
--- testsuite/gcc.dg/pr33826.c  (revision 0)
+++ testsuite/gcc.dg/pr33826.c  (revision 0)
@@ -0,0 +1,40 @@
+/* Regression test for PR middle-end/33826 */
+/* Verify that recursive functions cannot be pure or const.  */
+
+/* { dg-do compile } */
+/* { dg-options "-O1 -fdump-ipa-pure-const" } */
+
+int recurese1 (int i)
+{
+  return recurse1 (i+1);
+}
+
+int recurse2a (int i)
+{
+  return recurse2b (i+1);
+}
+
+int recurse2b (int i)
+{
+  return recurse2a (i+1);
+}
+
+int norecurse1a (int i)
+{
+  return norecurse1b (i+1);
+}
+
+int norecurse1b (int i)
+{
+  return i+1;
+}
+
+/* { dg-final { scan-ipa-dump "found to be const: norecurse1a" "pure-const" }
} */
+/* { dg-final { scan-ipa-dump "found to be const: norecurse1b" "pure-const" }
} */
+/* { dg-final { scan-ipa-dump-not "found to be pure: recurse1" "pure-const" }
} */
+/* { dg-final { scan-ipa-dump-not "found to be pure: recurse2a" "pure-const" }
} */
+/* { dg-final { scan-ipa-dump-not "found to be pure: recurse2b" "pure-const" }
} */
+/* { dg-final { scan-ipa-dump-not "found to be const: recurse1" "pure-const" }
} */
+/* { dg-final { scan-ipa-dump-not "found to be const: recurse2a" "pure-const"
} } */
+/* { dg-final { scan-ipa-dump-not "found to be const: recurse2b" "pure-const"
} } */
+/* { dg-final { cleanup-ipa-dump "pure-const" } } */
Index: testsuite/gcc.dg/tree-ssa/20030714-1.c
===
--- testsuite/gcc.dg/tree-ssa/20030714-1.c  (revision 129944)
+++ testsuite/gcc.dg/tree-ssa/20030714-1.c  (working copy)
@@ -34,13 +34,6 @@ find_base_value (src)
 }


-/* There should be four IF conditionals.  */
-/* { dg-final { scan-tree-dump-times "if " 4 "dom3"} } */
-
 /* There should be no casts to short unsigned int.  */
 /* { dg-final { scan-tree-dump-times "\\(short unsigned int\\)" 0 "dom3"} } */

-/* There should be two loads of ->code.  */
-/* { dg-final { scan-tree-dump-times "->code" 2 "dom3"} } */
-
-/* { dg-final { cleanup-tree-dump "dom3" } } */
Index: ipa-pure-const.c
===
--- ipa-pure-const.c(revision 129944)
+++ ipa-pure-const.c(working copy)
@@ -644,6 +644,7 @@ static_execute (void)
   for (i = 0; i < order_pos; i++ )
 {
   enum pure_const_state_e pure_const_state = IPA_CONST;
+  int count = 0;
   node = order[i];

   /* Find the worst state for any node in the cycle.  */
@@ -660,11 +661,40 @@ static_execute (void)
  if (!w_l->state_set_in_source)
{
  struct cgraph_edge *e;
+ count++;
+
+ /* FIXME!!!  Because of pr33826, we cannot have either
+immediate or transitive recursive functions marked as
+pure or const because dce can delete a function that
+is in reality an infinite loop.  A better solution
+than just outlawing them is to add another bit the
+functions to distinguish recursive from non recursive
+pure and const function.  This would allow the
+recursive ones to be cse'd but not dce'd.  In this
+same vein, we could allow functions with loops to
+also be cse'd but not dce'd.
+
+Unfortunately we are late in stage 3, and the fix
+described above is is not appropriate.  */
+ if (count > 1)
+   {
+ pure_const_state = IPA_NEITHER;
+ break;
+   }
+   
  for (e = w->callees; e; e = e->next_callee) 
{
  struct cgraph_node *y = e->callee;
  /* Only look at the master nodes and skip external nodes.  */
  y = cgraph_master_clone (y);
+
+ /* Check for immediate recursive functions.  See the
+FIXME above.  */
+ if 

[Bug middle-end/33713] [4.3 Regression] can't find a register in class 'GENERAL_REGS' while reloading 'asm'

[paolo dot bonzini at lu dot unisi dot ch]

--- Comment #10 from paolo dot bonzini at lu dot unisi dot ch  2007-11-08 
16:32 ---
Subject: Re:  [4.3 Regression] can't find a register
 in class 'GENERAL_REGS' while reloading 'asm'

ubizjak at gmail dot com wrote:
> --- Comment #9 from ubizjak at gmail dot com  2007-11-07 18:56 ---
> (In reply to comment #8)
> 
>> So if we can agree to dump -fforce-addr: yes, please.
> 
> Sometimes -fforce-addr produces faster code, as claimed in
> http://gcc.gnu.org/ml/fortran/2007-10/msg00048.html

My SPEC2000 run has not finished, but the results so far give a 
different overall picture:

+gzip: 156 -> 167 (without -fforce-addr -> with -fforce-addr)
+vpr: 165 -> 168
+gcc: 68 -> 70
  mcf: 167 -> 167
  crafty: 95 -> 95
  parser: 203 -> 204
+perlbmk: 118 -> 124
+gap: 74 -> 77
-vortex: 142 -> 136
+bzip2: 153 -> 156
+twolf: 223 -> 236

  wupwise: 119 -> 120
-swim: 180 -> 175
  mgrid: 249 -> 251
  applu: 193 -> 194
+mesa: 179 -> 182
+galgel: 145 -> 149
  art: 426 -> 427
-equake: 86 -> 79
+facerec: 190 -> 193

Probably it would be better to spend time distilling a simple testcase 
from equake, which is a relatively small (1500 lines) C program, so that 
the benefit is there with regular -O2.


-- 


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

[Bug libstdc++/34031] New: money_get:do_get incorrectly sets eofbit for valid input

[janis at gcc dot gnu dot org]

The C++ Standard, in section 22.2.6.1.1, says that if money_get::do_get
recognizes a valid sequence then it does not modify the ios_base::iostate
variable passed to it.  That variable should be set to eofbit only if do_get
has not recognized a valid sequence and no more characters are available.  This
was reported within IBM.

The testcase below gives the following output with GCC 3.3:

Contents of digits = "11"
Contents of retval = " 22"
mystate is goodbit as expected

and the following with later versions, including current mainline:

Contents of digits = "11"
Contents of retval = " 22"
mystate is eofbit, should not have changed

The testcase:

--
#include 
#include 
#include 
#include 
#include 

// Declare our own version of money_get to get access to do_get.
struct MyMoneyGet : public std::money_get
{
  char *
  my_do_get (char *pa, char *pz, bool intl,
 std::ios_base &myios, std::ios_base::iostate &mystate,
 std::string &digits)
  {
return do_get (pa, pz, intl, myios, mystate, digits);
  }
};

int
main ()
{
  std::string digits;
  MyMoneyGet mg;
  std::ios_base::iostate mystate;
  std::stringstream myios;
  std::locale mylocale (std::locale::classic (), new std::moneypunct);

  myios.imbue (mylocale);
  char s1[] = "11 22";
  char s2[] = "11"; // use this to get the length we want
  char *retval;
  size_t len2 = strlen (s2);

  // Parse the string "11" from the larger string "11 12"; we do that
  // to be able to look at the return value in retval.
  mystate = std::ios_base::goodbit;
  retval = mg.my_do_get (s1, s1 + len2, false, myios, mystate, digits);
  printf ("Contents of digits = \"%s\"\n", digits.c_str ());
  printf ("Contents of retval = \"%s\"\n", retval);
  if (mystate == std::ios_base::goodbit)
printf ("mystate is goodbit as expected\n");
  else
{
  if (mystate == std::ios_base::eofbit)
printf ("mystate is eofbit, should not have changed\n");
  else
printf ("mystate is %d, should not have changed\n", mystate);
  abort ();
}
}
---

The behavior changed with:

http://gcc.gnu.org/viewcvs?view=rev&rev=73011

r73011 | paolo | 2003-10-28 17:09:03 + (Tue, 28 Oct 2003)


-- 
   Summary: money_get:do_get incorrectly sets eofbit for valid input
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org


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

[Bug tree-optimization/33680] [4.3 Regression] ICE when compilling elbg.c from ffmpeg (vectorizer)

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2007-
   ||11/msg00448.html
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-10-06 20:37:00 |2007-11-08 18:18:23
   date||


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

[Bug tree-optimization/34029] [4.3 Regression] internal compiler error: verify_stmts failed

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Keywords||ice-on-valid-code
Summary|internal compiler error:|[4.3 Regression] internal
   |verify_stmts failed |compiler error: verify_stmts
   ||failed
   Target Milestone|--- |4.3.0


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

[Bug tree-optimization/33826] [4.1/4.2/4.3 Regression] GCC generates wrong code for infinitely recursive functions

[zadeck at gcc dot gnu dot org]

--- Comment #13 from zadeck at gcc dot gnu dot org  2007-11-08 16:46 ---
Subject: Bug 33826

Author: zadeck
Date: Thu Nov  8 16:45:53 2007
New Revision: 130006

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130006
Log:
2007-11-07  Kenneth Zadeck <[EMAIL PROTECTED]>

PR middle-end/33826
* ipa-pure-const (static_execute): Added code to keep recursive
functions from being marked as pure or const.
* ipa-utils (searchc): Fixed comment.
2007-11-08  Kenneth Zadeck <[EMAIL PROTECTED]>

PR middle-end/33826
* gcc.dg/pr33826.c: New.
* gcc.dg/tree-ssa/20030714-1.c: Removed two tests that depend on 
recursive functions being marked pure or const. 


Added:
trunk/gcc/testsuite/gcc.dg/pr33826.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-pure-const.c
trunk/gcc/ipa-utils.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/20030714-1.c


-- 


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

[Bug rtl-optimization/34012] [4.3 Regression] Pessimization caused by fwprop

[jakub at gcc dot gnu dot org]

--- Comment #9 from jakub at gcc dot gnu dot org  2007-11-08 17:05 ---
Bootstrapped/regtested on x86_64-linux, ppc64-linux (-m64 default) and
ia64-linux.  No regressions.  Could you please send it to gcc-patches?


-- 


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

[Bug c++/34032] New: -std=c++0x causes undeclared symbols errors on cygwin

[eric dot niebler at gmail dot com]

Building with -std=c++0x causes __STRICT_ANSI__ to be defined. The new C++
headers expect the system C headers (ctype.h, stdio.h, etc.,) to declare
certain functions (isblank(), snprintf(), etc.) that are part of C++0x. The
system C headers that are part of cygwin aren't privy to this. The result is
that simple programs like the following to not compile with -std=c++0x on a
stock cygwin install.

  #include 
  int main() {}

The error is:

In file included from
/usr/local/gcc-4.3-20071030/lib/gcc/i686-pc-cygwin/4.3.0/../../../../include/c
++/4.3.0/cctype:98,
 from
/usr/local/gcc-4.3-20071030/lib/gcc/i686-pc-cygwin/4.3.0/../../../../include/c
++/4.3.0/bits/localefwd.h:49,
 from
/usr/local/gcc-4.3-20071030/lib/gcc/i686-pc-cygwin/4.3.0/../../../../include/c
++/4.3.0/ios:47,
 from
/usr/local/gcc-4.3-20071030/lib/gcc/i686-pc-cygwin/4.3.0/../../../../include/c
++/4.3.0/ostream:45,
 from
/usr/local/gcc-4.3-20071030/lib/gcc/i686-pc-cygwin/4.3.0/../../../../include/c
++/4.3.0/iostream:45,
 from main.cpp:1:
/usr/local/gcc-4.3-20071030/lib/gcc/i686-pc-cygwin/4.3.0/../../../../include/c++/4.3.0/tr1_impl/ccty
pe:43: error: '::isblank' has not been declared



For another example, the following program also does not compile on cygwin with
-std=c++0x:


  #include 

  int main()
  {
char buf[50];
snprintf(buf, 50, "hello");
  }


main.cpp: In function 'int main()':
main.cpp:6: error: 'snprintf' was not declared in this scope


This is with a stock g++ built on cygwin from latest source from svn,
configured with "--prefix=/usr/local/g++-4.3 --enable-languages=c,c++".


-- 
   Summary: -std=c++0x causes undeclared symbols errors on cygwin
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eric dot niebler at gmail dot com
  GCC host triplet: cygwin


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

[Bug target/32886] c4x: error: unrecognizable insn configuring libgcc

[john dot xia at esstech dot com]

--- Comment #1 from john dot xia at esstech dot com  2007-11-08 18:38 
---
Created an attachment (id=14509)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14509&action=view)
preprocessed file 


-- 


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

[Bug target/32886] c4x: error: unrecognizable insn configuring libgcc

[john dot xia at esstech dot com]

--- Comment #2 from john dot xia at esstech dot com  2007-11-08 18:39 
---
../../gcc-4.2.2/gcc/libgcc2.c: In function '__neghi2':
../../gcc-4.2.2/gcc/libgcc2.c:80: error: unrecognizable insn:
(insn 40 39 41 3 ../../gcc-4.2.2/gcc/libgcc2.c:77 (set (reg:QI 57)
(const_int 0 [0x0])) -1 (nil)
(nil))
../../gcc-4.2.2/gcc/libgcc2.c:80: internal compiler error: in extract_insn, at
recog.c:2077
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.


-- 


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

[Bug target/34025] Warning when compiling with -m64 -ffast-math on Intel Darwin

[dominiq at lps dot ens dot fr]

--- Comment #4 from dominiq at lps dot ens dot fr  2007-11-08 18:43 ---
Subject: Re:  Warning when compiling with -m64 -ffast-math
 on Intel Darwin

> Hmmm, this should have been compiled with -m64.  Can you attach your build log
> for building GCC?

The full log or only the part concerning crtfastmath.o?


-- 


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

[Bug objc/34033] New: compiler accepts invalid string concatenation

[tromey at gcc dot gnu dot org]

The code in c-lex.c that handles string concatenation allows weird,
and from what I can tell invalid, ObjC string concatentations.
In particular it allows any number of "@"s, and trailing "@"s.
E.g., it treats these as valid strings:

   "foo" @ "bar"
   @"foo" @


-- 
   Summary: compiler accepts invalid string concatenation
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: objc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tromey at gcc dot gnu dot org


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

[Bug tree-optimization/34034] New: perlbmk hangs with -O2 -fno-tree-dce -fno-tree-dominator-opts

[janis at gcc dot gnu dot org]

Test perlbmk from SPEC CPU2000 hangs on powerpc-linux and i686-linux when
compiled with "-O2 -fno-tree-dce -fno-tree-dominator-opts".  I didn't manage to
get a minimized testcase that fails on both targets, but do have two slightly
different tests.  Both of them hang in the loop that begins "for (t++;", just
as 253.perlbmk does.

A regression hunt on powerpc-linux identified this patch:

http://gcc.gnu.org/viewcvs?view=rev&rev=127993

r127993 | nickc | 2007-08-31 14:28:38 + (Fri, 31 Aug 2007)


-- 
   Summary: perlbmk hangs with -O2 -fno-tree-dce -fno-tree-
dominator-opts
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org


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

[Bug tree-optimization/34034] perlbmk hangs with -O2 -fno-tree-dce -fno-tree-dominator-opts

[janis at gcc dot gnu dot org]

--- Comment #1 from janis at gcc dot gnu dot org  2007-11-08 18:49 ---
Created an attachment (id=14510)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14510&action=view)
test for x86-linux


-- 


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

[Bug tree-optimization/34034] perlbmk hangs with -O2 -fno-tree-dce -fno-tree-dominator-opts

[janis at gcc dot gnu dot org]

--- Comment #2 from janis at gcc dot gnu dot org  2007-11-08 18:49 ---
Created an attachment (id=14511)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14511&action=view)
test for powerpc-linux


-- 


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

[Bug target/34025] Warning when compiling with -m64 -ffast-math on Intel Darwin

[dominiq at lps dot ens dot fr]

--- Comment #5 from dominiq at lps dot ens dot fr  2007-11-08 18:50 ---
Subject: Re:  Warning when compiling with -m64 -ffast-math
 on Intel Darwin

> this should have been compiled with -m64.

Apparently it has not been with -m64:

/opt/gcc/i686-darwin/./gcc/xgcc -B/opt/gcc/i686-darwin/./gcc/
-B/opt/gcc/gcc4.3w/i686-apple-darwin8/bin/
-B/opt/gcc/gcc4.3w/i686-apple-darwin8/lib/ -isystem
/opt/gcc/gcc4.3w/i686-apple-darwin8/include -isystem
/opt/gcc/gcc4.3w/i686-apple-darwin8/sys-include -O2 -g -O2   -DIN_GCC-W
-Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include  -I.
-I/opt/gcc/i686-darwin/i686-apple-darwin8/x86_64/libgcc
-I../../gcc-4.3-work/gcc
-I../../gcc-4.3-work/gcc//opt/gcc/i686-darwin/i686-apple-darwin8/x86_64/libgcc
-I../../gcc-4.3-work/gcc/../include -I../../gcc-4.3-work/gcc/../libcpp/include
-I/sw/include  -I../../gcc-4.3-work/gcc/../libdecnumber
-I../../gcc-4.3-work/gcc/../libdecnumber/dpd -I../libdecnumber -g -O2
-fomit-frame-pointer -m64 \
  -fno-tree-dominator-opts  \
  -c ../../gcc-4.3-work/gcc/config/darwin-crt3.c -o
/opt/gcc/i686-darwin/i686-apple-darwin8/x86_64/libgcc/crt3.o
/opt/gcc/i686-darwin/./gcc/xgcc -B/opt/gcc/i686-darwin/./gcc/
-B/opt/gcc/gcc4.3w/i686-apple-darwin8/bin/
-B/opt/gcc/gcc4.3w/i686-apple-darwin8/lib/ -isystem
/opt/gcc/gcc4.3w/i686-apple-darwin8/include -isystem
/opt/gcc/gcc4.3w/i686-apple-darwin8/sys-include -O2  -O2 -g -O2   -DIN_GCC   
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include  -fPIC -pipe -g -DHAVE_GTHR_DEFAULT
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -msse -minline-all-stringops -c \
../../gcc-4.3-work/gcc/config/i386/crtfastmath.c \
-o /opt/gcc/i686-darwin/i686-apple-darwin8/x86_64/libgcc/crtfastmath.o
/opt/gcc/i686-darwin/./gcc/xgcc -B/opt/gcc/i686-darwin/./gcc/
-B/opt/gcc/gcc4.3w/i686-apple-darwin8/bin/
-B/opt/gcc/gcc4.3w/i686-apple-darwin8/lib/ -isystem
/opt/gcc/gcc4.3w/i686-apple-darwin8/include -isystem
/opt/gcc/gcc4.3w/i686-apple-darwin8/sys-include -O2  -O2 -g -O2   -DIN_GCC   
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include  -fPIC -pipe -g -DHAVE_GTHR_DEFAULT
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -D__PREC=32 -c \
../../gcc-4.3-work/gcc/config/i386/crtprec.c \
-o /opt/gcc/i686-darwin/i686-apple-darwin8/x86_64/libgcc/crtprec32.o
/opt/gcc/i686-darwin/./gcc/xgcc -B/opt/gcc/i686-darwin/./gcc/
-B/opt/gcc/gcc4.3w/i686-apple-darwin8/bin/
-B/opt/gcc/gcc4.3w/i686-apple-darwin8/lib/ -isystem
/opt/gcc/gcc4.3w/i686-apple-darwin8/include -isystem
/opt/gcc/gcc4.3w/i686-apple-darwin8/sys-include -O2  -O2 -g -O2   -DIN_GCC   
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include  -fPIC -pipe -g -DHAVE_GTHR_DEFAULT
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -D__PREC=64 -c \
../../gcc-4.3-work/gcc/config/i386/crtprec.c \
-o /opt/gcc/i686-darwin/i686-apple-darwin8/x86_64/libgcc/crtprec64.o
/opt/gcc/i686-darwin/./gcc/xgcc -B/opt/gcc/i686-darwin/./gcc/
-B/opt/gcc/gcc4.3w/i686-apple-darwin8/bin/
-B/opt/gcc/gcc4.3w/i686-apple-darwin8/lib/ -isystem
/opt/gcc/gcc4.3w/i686-apple-darwin8/include -isystem
/opt/gcc/gcc4.3w/i686-apple-darwin8/sys-include -O2  -O2 -g -O2   -DIN_GCC   
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include  -fPIC -pipe -g -DHAVE_GTHR_DEFAULT
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -D__PREC=80 -c \
../../gcc-4.3-work/gcc/config/i386/crtprec.c \
-o /opt/gcc/i686-darwin/i686-apple-darwin8/x86_64/libgcc/crtprec80.o


-- 


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

[Bug libstdc++/34031] money_get:do_get incorrectly sets eofbit for valid input

[sebor at roguewave dot com]

--- Comment #2 from sebor at roguewave dot com  2007-11-08 18:52 ---
Yes, I can confirm that, Paolo. The Apache C++ Standard Library behaves the
same (i.e., the facet sets eofbit).


-- 


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

[Bug c++/34032] -std=c++0x causes undeclared symbols errors on cygwin

[pcarlini at suse dot de]

--- Comment #1 from pcarlini at suse dot de  2007-11-08 18:56 ---
Note that the library has autoconf tests for those C99 functions, which,
however, are run with the default C++98 compiler. Now I'm confused by this
__STRICT_ANSI__ thing on cygwin, does it mean that with -std=gnu++0x things are
fine? On gnu-linux things work in any case, simply because the glibc headers do
not disable those C99 features when -std=c++0x (or -std=c++98, for that matter)
is passed and thus __STRICT_ANSI__ is defined... I think some help from the
Cygwin people is in order...


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 CC||cgf at gcc dot gnu dot org,
   ||dannysmith at users dot
   ||sourceforge dot net


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

[Bug libstdc++/34031] [DR 585] money_get:do_get incorrectly sets eofbit for valid input

[pcarlini at suse dot de]

--- Comment #3 from pcarlini at suse dot de  2007-11-08 18:59 ---
Thanks Martin. Therefore, let's confirm this bug to suspend it immediately
until our DR get resolved.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-11-08 18:59:04
   date||
Summary|money_get:do_get incorrectly|[DR 585] money_get:do_get
   |sets eofbit for valid input |incorrectly sets eofbit for
   ||valid input


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

[Bug fortran/27997] Fortran 2003: Support type-spec for array constructor

[fxcoudert at gcc dot gnu dot org]

--- Comment #2 from fxcoudert at gcc dot gnu dot org  2007-11-08 18:59 
---
Created an attachment (id=14512)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14512&action=view)
Patch to add this feature

This patch does the job. I'll wait until next stage 1 to submit it.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |fxcoudert at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED


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

[Bug libstdc++/34031] [DR 585] money_get:do_get incorrectly sets eofbit for valid input

[pcarlini at suse dot de]

-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 CC|sebor at roguewave dot com  |
 Status|NEW |SUSPENDED


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

[Bug target/16634] arm-elf-gcc problems when generating code for __attribute__ ((interrupt ("IRQ")))

[ralf dot guetlein at web dot de]

--- Comment #9 from ralf dot guetlein at web dot de  2007-11-08 21:42 
---
(In reply to comment #8)
> also fails on 4.2.1

is this bug still present in 4.2.2?

Acc. to my obervations the error only shows up when not all auto variables can
be mapped to registers, and additional variables are located on stack. As a
work-around, if a more complex interrupt handler is needed, place the code in a
subfunction and call this function from the interrupt handler. In this case no
stack is reserved in the interrupt handler, and the generated code is OK. Care
must be taken, of course, that the optimizer does not inline the code for
IntFunc().

Example:
void IntFunc(void);

__attribute__((interrupt("IRQ")) void IntHandler(void)
{
  IntFunc();
}

__attribute__(noinline)) void IntFunc(void)
{
  // interrupt code here!
}


-- 


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

[Bug tree-optimization/34038] New: 176.gcc segfaults when compiled with -O2 -ftree-vectorize -maltivec

[janis at gcc dot gnu dot org]

Test 176.gcc from SPEC CPU2000 fails at execution time on powerpc-linux when
compiled with "-O2 -ftree-vectorize -maltivec".  The stack frame is corrupted
but the last few entries are several recursive calls of reload which calls
spill_failure which calls asm_noperands.  This is odd, but when _either_
reload.c or reload1.c is compiled without -ftree-vectorize, the test runs to
completion and the output is as expected.

I don't have a minimized testcase.  The failure starts with:

http://gcc.gnu.org/viewcvs?view=rev&rev=112621

r112621 | spop | 2006-04-02 04:27:40 + (Sun, 02 Apr 2006)


-- 
   Summary: 176.gcc segfaults when compiled with -O2 -ftree-
vectorize -maltivec
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org
 GCC build triplet: powerpc-unknown-linux-gnu


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

[Bug fortran/34020] Bogus codegen for openmp atomics w/ indirects operands on IPF

[brian dot e dot bliss at intel dot com]

--- Comment #2 from brian dot e dot bliss at intel dot com  2007-11-09 
00:06 ---
Subject: RE:  Bogus codegen for openmp atomics w/ indirects operands on IPF

The C example looks correct (but you have to use the += operator to get
a legal example, which might have affected things):

% cat foo.c
void foo(float *lhs, float*rhs) {
#pragma omp atomic
  *lhs += *rhs;
}
% gcc -fopenmp -O1 -S foo.c
% cat foo.s
.file   "foo.c"
.pred.safe_across_calls p1-p5,p16-p63
.text
.align 16
.global foo#
.proc foo#
foo:
.prologue
.body
ldfs f6 = [r33]
ld4 r15 = [r32]
;;
mov r16 = r15
.L2:
setf.s f7 = r15
;;
fadd.s f7 = f7, f6
;;
getf.s r15 = f7
addp4 r14 = r16, r0
;;
mov ar.ccv = r14
mf
;;
cmpxchg4.rel r17 = [r32], r15, ar.ccv
;;
mov r15 = r17
cmp4.eq p6, p7 = r17, r16
(p6) br.ret.dpnt.many rp
mov r16 = r17
br .L2
;;
.endp foo#
.ident  "GCC: (GNU) 4.2.0"

-bb

-Original Message-
From: fxcoudert at gcc dot gnu dot org [mailto:[EMAIL PROTECTED]

Sent: Thursday, November 08, 2007 6:50 AM
To: Bliss, Brian E
Subject: [Bug fortran/34020] Bogus codegen for openmp atomics w/
indirects operands on IPF



--- Comment #1 from fxcoudert at gcc dot gnu dot org  2007-11-08
12:49 ---
Does the same thing happen with C?

void foo(float *lhs, float*rhs) {
#pragma omp atomic
  *lhs = *rhs + *lhs;
}


-- 

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

--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.


-- 


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

[Bug fortran/34026] Internal compiler error: in gfc_add_modify, at fortran/trans.c:159

[fxcoudert at gcc dot gnu dot org]

--- Comment #6 from fxcoudert at gcc dot gnu dot org  2007-11-08 23:56 
---
Hi Christian,

I've tried on i686-darwin, and it works fine with GNU Fortran (GCC) 4.3.0
20071017. I will thus close this report as fixed, and I suggest you download
more recent binaries (either from macresearch, or from
http://gcc.gnu.org/wiki/GFortranBinaries).

Please reopen the report if by any chance this problem persists with a compiler
more recent that the date I mentionned above.

Thanks!


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug target/30829] extra register zero extends

[dje at google dot com]

--- Comment #1 from dje at google dot com  2007-11-09 00:57 ---
I looked into what's going on here.

This is a problem in the i386.md lshr+zext combiner patterns (or a problem in
the combine pass, depending on one's point of view).  There are patterns in
i386.md that are supposed to handle this case but they're not being used.

lshrsi3_1_one_bit_zext doesn't handle the lshr(1) case. I don't understand why
the lshr is outside of the zero_extend in its definition.  Looking at the dump
of the combine pass I see it trying to match a zero_extract, and if I code
lshrsi3_1_one_bit_zext to use a zero_extract then I get the expected code (i.e.
the superfluous move is gone).

lshrsi3_1_zext doesn't handle the lshr(n) case.  It intuitively matches but
combine tries to "simplify" this case to (and:DI (subreg:DI (lshr ...) 0)
0x) and there's no pattern that matches this.  If I add a pattern to
match this it still doesn't work because the rtx_cost of the two separate insns
lshr,zext (= 4 + 1) is less than the rtx cost of the combined pattern (= 4 + 3
+ 4) so combine rejects the change because it thinks it's more expensive. 
ix86_rtx_costs has code to treat zero_extend SI->DI as a cheap case but it
doesn't get used here unfortunately because the zero_extend gets converted to
an AND (which isn't to say that's bad for the general case).

There are two other related patterns that I also don't understand:
lshrsi3_cmp_one_bit_zext and lshrsi3_cmp_zext.  It's not clear to me that they
will match anything.

It's unfortunate that the intuitive pattern can't work here.  i.e. for the one
bit shift one needs to use a zero_extract and for the N bit shift one needs to
use AND and hack ix86_rtx_costs.  Maybe if the "simplified" pattern doesn't
work combine could try a "less simplified" pattern, or maybe combine could be
told not to simplify this particular case (either via target dependent means or
by detecting the specific case of SI->DI).  Maybe I'm missing something.


-- 

dje at google dot com changed:

   What|Removed |Added

 CC||dje at google dot com


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

[Bug c++/34023] Wrong using of user-defined conversion operator for converting rvalue to reference on constant.

[sergey dot gcc at comrades dot id dot au]

--- Comment #3 from sergey dot gcc at comrades dot id dot au  2007-11-09 
01:14 ---
// Workaround:
class a
{
public:
template
operator T &() const
throw(typename ::boost::disable_if<
::boost::is_same >::type *)
{
static int f;
return f;
}
};

int main()
{
a const &aa = a(); // line # 27
int &i = aa;
}


-- 


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

[Bug rtl-optimization/34035] [4.3 Regression] ICE in calc_dfs_tree with -O2 -fnon-call-exceptions -ffast-math -fno-gcse

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Keywords||ice-on-valid-code
Summary|ICE in calc_dfs_tree with - |[4.3 Regression] ICE in
   |O2 -fnon-call-exceptions -  |calc_dfs_tree with -O2 -
   |ffast-math -fno-gcse|fnon-call-exceptions -ffast-
   ||math -fno-gcse
   Target Milestone|--- |4.3.0


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

[Bug rtl-optimization/34035] New: ICE in calc_dfs_tree with -O2 -fnon-call-exceptions -ffast-math -fno-gcse

[janis at gcc dot gnu dot org]

Test eon from SPEC CPU2000 fails to build on powerpc64-linux with both -m32 and
-m64 and "-fnon-call-exceptions -ffast-math -fno-gcse " with an ICE in
calc_dfs_tree at dominance.c:393

Minimized test case:

class One {
public:
One () { e[0] = e[1] = 0.0; }
double e[2];
};

template 
class Two {
public:
Two();
private:
T *data;
int arraySize;
};

template 
Two::Two() {
   data = new T[arraySize];
}

class Three {
protected:
  Two data;
};

class Four : public Three {
public:
  Four ();
  void Foo (int n);
};

Four :: Four (){
   Foo (1);
}

The ICE starts with:

http://gcc.gnu.org/viewcvs?view=rev&rev=123084

r123084 | bonzini | 2007-03-20 08:31:13 + (Tue, 20 Mar 2007)


-- 
   Summary: ICE in calc_dfs_tree with -O2 -fnon-call-exceptions -
ffast-math -fno-gcse
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org
GCC target triplet: powerpc*-linux


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

[Bug fortran/31817] Give at least a warning for specification function without explicit interface

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2007-11-08 20:46 ---
> I think we already emit the error you'd like (and probably have done so for
> quite some time):
>
> Error: Function 'fn' at (1) must be PURE

Ok. Seemingly it has been fixed by collateral damage of a pure patch during
4.3.0. (It does not show this message in 4.2.2.)

> Is there anything more than that?
No.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED


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

[Bug target/33774] Cygwin/mingw do not support 16 byte alignment of struct/union fields

[dannysmith at gcc dot gnu dot org]

--- Comment #3 from dannysmith at gcc dot gnu dot org  2007-11-08 20:20 
---
Subject: Bug 33774

Author: dannysmith
Date: Thu Nov  8 20:20:02 2007
New Revision: 130024

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130024
Log:
PR target/33774
* config/i386/cygming.h (BIGGEST_FIELD_ALIGNMENT): Define only if
IN_TARGET_LIBS.



Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/cygming.h


-- 


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

[Bug fortran/33957] gfortran rejects valid initialization expression

[fxcoudert at gcc dot gnu dot org]

--- Comment #5 from fxcoudert at gcc dot gnu dot org  2007-11-09 01:25 
---
The patch below should do it.

Index: expr.c
===
--- expr.c  (revision 129869)
+++ expr.c  (working copy)
@@ -1981,11 +1981,7 @@ check_inquiry (gfc_expr *e, int not_rest
   break;

   if (functions[i] == NULL)
-{
-  gfc_error ("Inquiry function '%s' at %L is not permitted "
-"in an initialization expression", name, &e->where);
-  return MATCH_ERROR;
-}
+return MATCH_ERROR;

   /* At this point we have an inquiry function with a variable argument.  The
  type of the variable might be undefined, but we need it now, because the


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
 AssignedTo|unassigned at gcc dot gnu   |fxcoudert at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Keywords||patch
   Last reconfirmed|2007-10-31 19:20:31 |2007-11-09 01:25:46
   date||


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

[Bug c++/34032] -std=c++0x causes undeclared symbols errors on cygwin

[dannysmith at users dot sourceforge dot net]

--- Comment #3 from dannysmith at users dot sourceforge dot net  2007-11-08 
19:18 ---
The newlib stdio.h puts [v]snprintf declarations within a #ifndef
__STRICT_ANSI__ block. 
Likewise for cygwin's  ctype.h  and isblank


-- 


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

[Bug fortran/31817] Give at least a warning for specification function without explicit interface

[fxcoudert at gcc dot gnu dot org]

--- Comment #1 from fxcoudert at gcc dot gnu dot org  2007-11-08 19:16 
---
I think we already emit the error you'd like (and probably have done so for
quite some time):

$ cat k.f90
  function f2 (fn, i)
integer :: i, fn
character (len = fn (i)) :: f2
  end function f2
$ gfortran -c k.f90
k.f90:3.20:

character (len = fn (i)) :: f2
   1
Error: Function 'fn' at (1) must be PURE


Is there anything more than that?


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |WAITING


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

[Bug target/34025] Warning when compiling with -m64 -ffast-math on Intel Darwin

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2007-11-08 18:40 ---
>/opt/gcc/gcc4.3w/lib/gcc/i686-apple-darwin8/4.3.0/x86_64/crtfastmath.o, file is
not of required architecture

Hmmm, this should have been compiled with -m64.  Can you attach your build log
for building GCC?


-- 


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

[Bug tree-optimization/34030] ICE in in compare_values_warnv, at tree-vrp.c:701

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-11-08 18:37 ---
This might have been already fixed in 4.2.3.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org


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

[Bug libfortran/33863] backspace error on i386-pc-mingw32

[fxcoudert at gcc dot gnu dot org]

--- Comment #8 from fxcoudert at gcc dot gnu dot org  2007-11-08 23:51 
---
(In reply to comment #7)
> However, most run time
> libraries do the simple thing when they see io-redirection - they close the
> stream file and re-open it as a ordinary file. Is there any reason GFORTRAN
> could not do that ?

As a generic answer: I don't think it's advisable as it's against the principle
of least surprise. I can think of at least a standard case where this could
fail: you create a file, run a Fortran program with stdin redirected to that
file, and unlink the file (so that, when the Fortran program exits, the file is
removed without you having to wait and do it later). In that case, trying to
reopen it will fail (it might even give wrong results if a new file of the same
name is created, though it's not likely).

This "unlink" trick is widely used. For example, my shell (zsh) does it to
avoid you creating temporary files: instead of letting you do:

$ ./foo > tmp
$ ./bar < tmp

you can do

$ ./bar =(./foo)

(and yes, you could use a pipe, but it's not the same if tmp is large and you
don't want the two programs to run concurrently).

Well, I really am verbose tonight, but I don't think it's desirable.


-- 

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

[Bug tree-optimization/34036] New: ICE with control flow in the middle of basic block for -fnon-call-exceptions

[janis at gcc dot gnu dot org]

Test eon from SPEC CPU2000 fails to build with "-O2 -fnon-call-exceptions
-ffast-math -fsignaling-nans" due to an ICE for control flow in the middle of a
basic block.  Two minimized tests show different warnings on both powerpc-linux
and i686-linux:

elm3b145% /opt/gcc-nightly/trunk/bin/g++ -O2 -fnon-call-exceptions -ffast-math
-fsignaling-nans -c bug13.cc
bug13.cc: In constructor ‘mrGrid::mrGrid()’:
bug13.cc:22: error: control flow in the middle of basic block 4
bug13.cc:22: internal compiler error: verify_flow_info failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

elm3b145% /opt/gcc-nightly/trunk/bin/g++ -O2 -fnon-call-exceptions -ffast-math
-fsignaling-nans -c bug14.cc
bug14.cc: In function ‘int main()’:
bug14.cc:27: error: BB 11 can not throw but has EH edges
bug14.cc:27: error: BB 12 can not throw but has EH edges
bug14.cc:27: error: control flow in the middle of basic block 13
bug14.cc:27: error: control flow in the middle of basic block 13
bug14.cc:27: internal compiler error: verify_flow_info failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Here's bug13.cc; I'll attach the other which is slightly larger.

template 
class ggStaticArray {
public:
  ~ggStaticArray();
};

template 
class ggGrid {
public:
  ggGrid() : grid() { }
  ggStaticArray grid;
};

class mrGrid {
public:
  mrGrid(void);
protected:
  ggGrid grid;
  double multiplier;
};

mrGrid::mrGrid(void)
{
  double xMeasure, yMeasure, zMeasure;
  double cellDimension;

  cellDimension = multiplier * (xMeasure * yMeasure * zMeasure);
}

Regression hunts for both identified this patch:

http://gcc.gnu.org/viewcvs?view=rev&rev=108425

r108425 | law | 2005-12-12 19:59:16 + (Mon, 12 Dec 2005)


-- 
   Summary: ICE  with control flow in the middle of basic block for
-fnon-call-exceptions
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org


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

[Bug target/33774] Cygwin/mingw do not support 16 byte alignment of struct/union fields

[dannysmith at users dot sourceforge dot net]

--- Comment #4 from dannysmith at users dot sourceforge dot net  2007-11-08 
20:21 ---
Fixed on trunk.
Danny


-- 

dannysmith at users dot sourceforge dot net changed:

   What|Removed |Added

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


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

[Bug libfortran/33863] backspace error on i386-pc-mingw32

[dir at lanl dot gov]

--- Comment #7 from dir at lanl dot gov  2007-11-08 19:56 ---
When I changed it to directly open the file, it was happy. You are right, of
course, backspacing a stream file is not permitted. However, most run time
libraries do the simple thing when they see io-redirection - they close the
stream file and re-open it as a ordinary file. Is there any reason GFORTRAN
could not do that ?


-- 


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

[Bug c++/30297] [4.1/4.2 regression] ICE with extern "C" and inheritance

[tromey at gcc dot gnu dot org]

--- Comment #8 from tromey at gcc dot gnu dot org  2007-11-08 19:51 ---
Fixed on trunk.


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work||4.3.0
Summary|[4.1/4.2/4.3 regression] ICE|[4.1/4.2 regression] ICE
   |with extern "C" and |with extern "C" and
   |inheritance |inheritance


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

[Bug libstdc++/34032] -std=c++0x causes undeclared symbols errors on cygwin

[pcarlini at suse dot de]

--- Comment #4 from pcarlini at suse dot de  2007-11-08 19:33 ---
Ok, at least we have a work around, then. About Cygwin, probably the reason is
that those features are made available as extensions not at C99 facilities (I'm
sure that this was the case at some point for many snprintf implementations,
for example). The safe approach, then, would be always running all the autoconf
tests with the strict C++ compiler (-std=c++98, whereas -std=gnu++98 is the
default). Are there any opinions about that?


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 CC||bkoz at redhat dot com
 Status|UNCONFIRMED |NEW
  Component|c++ |libstdc++
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-11-08 19:33:51
   date||


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

[Bug debug/33739] [4.3 Regression] Failure of gfortran.dg/literal_character_constant_1_*.F with -m64 -g on Darwin

[fxcoudert at gcc dot gnu dot org]

--- Comment #11 from fxcoudert at gcc dot gnu dot org  2007-11-08 19:20 
---
Subject: Bug 33739

Author: fxcoudert
Date: Thu Nov  8 19:19:50 2007
New Revision: 130016

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130016
Log:
PR fortran/33739
* scanner.c (start_source_file, end_source_file,
exit_remaining_files): New functions.
(gfc_advance_line): Use the new functions.

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


-- 


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

[Bug libstdc++/34031] money_get:do_get incorrectly sets eofbit for valid input

[pcarlini at suse dot de]

--- Comment #1 from pcarlini at suse dot de  2007-11-08 18:37 ---
Hi Martin. I think this inconsistency between num_get and money_get is just a
special case of our DR 585:

  http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#585

and that setting eofbit when end of file after successful parsing of a monetary
quantity is consistent with our proposed resolution. Can you confirm? Thanks in
advance.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 CC||sebor at roguewave dot com


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

[Bug c++/34032] -std=c++0x causes undeclared symbols errors on cygwin

[eric dot niebler at gmail dot com]

--- Comment #2 from eric dot niebler at gmail dot com  2007-11-08 19:16 
---
I didn't know about -std=gnu++0x. That seems to work. -std=c++0x doesn't. 

FWIW, the stock gcc that comes with cygwin is 3.4:
$ g++ --version
g++ (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
Copyright (C) 2004 Free Software Foundation, Inc.


-- 


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

[Bug debug/33739] [4.3 Regression] Failure of gfortran.dg/literal_character_constant_1_*.F with -m64 -g on Darwin

[fxcoudert at gcc dot gnu dot org]

--- Comment #12 from fxcoudert at gcc dot gnu dot org  2007-11-08 19:20 
---
Fixed.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/34026] Internal compiler error: in gfc_add_modify, at fortran/trans.c:159

[fxcoudert at gcc dot gnu dot org]

--- Comment #5 from fxcoudert at gcc dot gnu dot org  2007-11-08 19:26 
---
Interestingly, I can't reproduce your problem on x86_64-linux. I'll try tonight
with my own i686-darwin.


-- 


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

[Bug libffi/31937] libffi doesn't support ppc without FPU

[andreast at gcc dot gnu dot org]

--- Comment #4 from andreast at gcc dot gnu dot org  2007-11-08 19:34 
---
The mentioned patch does not work properly, it only handles soft-float when
no-long-double-128 is used.
Working on a better one which should support both, 'double == long double' and
long double == 128.


-- 


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

[Bug c++/30297] [4.1/4.2/4.3 regression] ICE with extern "C" and inheritance

[tromey at gcc dot gnu dot org]

--- Comment #7 from tromey at gcc dot gnu dot org  2007-11-08 19:50 ---
Subject: Bug 30297

Author: tromey
Date: Thu Nov  8 19:50:38 2007
New Revision: 130018

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130018
Log:
gcc/cp
2007-11-08  Andrew Pinski  <[EMAIL PROTECTED]>
PR c++/30297:
* tree.c (decl_linkage): Fields have no linkage.
gcc/testsuite
PR c++/30297:
* g++.dg/inherit/pr30297.C: New file.

Added:
trunk/gcc/testsuite/g++.dg/inherit/pr30297.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/33713] [4.3 Regression] can't find a register in class 'GENERAL_REGS' while reloading 'asm'

[bonzini at gnu dot org]

--- Comment #11 from bonzini at gnu dot org  2007-11-08 19:56 ---
-fforce-addr for SPECfp is neutral, with big improvements in equake (and a
little on swim+lucas, but the latter has huge fluctuations).

SPECint drops from 1156 to 1130, with clear changes for the worse as
highlighted by my previous comment.

I am also in favor of dropping -fforce-addr.


-- 


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

[Bug middle-end/33713] [4.3 Regression] can't find a register in class 'GENERAL_REGS' while reloading 'asm'

[bonzini at gnu dot org]

--- Comment #12 from bonzini at gnu dot org  2007-11-08 19:58 ---
Who prepares the patch? :-)


-- 


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