[Bug target/47487] New: ICE in rs6000_output_function_epilogue, at config/rs6000/rs6000.c:21782 building 64bit libgo

[doko at ubuntu dot com]

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

   Summary: ICE in rs6000_output_function_epilogue, at
config/rs6000/rs6000.c:21782 building 64bit libgo
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@ubuntu.com


powerpc-linux-gnu, trunk 20110126, configured with --enable-targes=all fails
with:

echo timestamp > s-syscall_arch
rm -f `echo unicode/libunicode.a | sed -e 's|/lib|/|' -e 's/\.a/.gox/'`; test
-d unicode || /bin/mkdir -p unicode; rm -f unicode/libunicode.a; files=`echo
../../../../src/libgo/go/unicode/casetables.go
../../../../src/libgo/go/unicode/digit.go
../../../../src/libgo/go/unicode/letter.go
../../../../src/libgo/go/unicode/tables.go | sed -e 's/[^ ]*\.gox//g'`; if
/bin/bash ./libtool --tag GO --mode=compile
/build/buildd/gcc-snapshot-20110126/build/./gcc/gccgo
-B/build/buildd/gcc-snapshot-20110126/build/./gcc/
-B/usr/lib/gcc-snapshot/powerpc-linux-gnu/bin/
-B/usr/lib/gcc-snapshot/powerpc-linux-gnu/lib/ -isystem
/usr/lib/gcc-snapshot/powerpc-linux-gnu/include -isystem
/usr/lib/gcc-snapshot/powerpc-linux-gnu/sys-include  -O2 -g  -m64 -fPIC
-mstrict-align -I . -c -fgo-prefix="libgo_unicode" -o unicode/libunicode.a.o
$files; then ar rc unicode/libunicode.a unicode/libunicode.a.o; else exit 1; fi
libtool: compile:  /build/buildd/gcc-snapshot-20110126/build/./gcc/gccgo
-B/build/buildd/gcc-snapshot-20110126/build/./gcc/
-B/usr/lib/gcc-snapshot/powerpc-linux-gnu/bin/
-B/usr/lib/gcc-snapshot/powerpc-linux-gnu/lib/ -isystem
/usr/lib/gcc-snapshot/powerpc-linux-gnu/include -isystem
/usr/lib/gcc-snapshot/powerpc-linux-gnu/sys-include -O2 -g -m64 -fPIC
-mstrict-align -I . -c -fgo-prefix=libgo_unicode
../../../../src/libgo/go/unicode/casetables.go
../../../../src/libgo/go/unicode/digit.go
../../../../src/libgo/go/unicode/letter.go
../../../../src/libgo/go/unicode/tables.go 
../../../../src/libgo/go/unicode/letter.go: In function 'unicode.to.isra.0':
../../../../src/libgo/go/unicode/letter.go:176:1: internal compiler error: in
rs6000_output_function_epilogue, at config/rs6000/rs6000.c:21782
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[10]: *** [unicode/libunicode.a] Error 1
make[10]: Leaving directory
`/build/buildd/gcc-snapshot-20110126/build/powerpc-linux-gnu/64/libgo'
make[9]: *** [all-recursive] Error 1
make[9]: Leaving directory
`/build/buildd/gcc-snapshot-20110126/build/powerpc-linux-gnu/64/libgo'
make[8]: *** [all] Error 2

[Bug fortran/47486] gfortran -M exits with fatal error when -o option is used

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org,
   ||dfranke at gcc dot gnu.org

--- Comment #1 from Tobias Burnus  2011-01-27 
08:31:56 UTC ---
In the compiler, the file name is handled in cpp.c via
gfc_cpp_option.output_filename -- but that part looks OK.

It seems to be a driver problem as the driver passes:
.../x86_64-unknown-linux-gnu/4.6.0/f951 ... -o test.d ... -o /tmp/cckDPYJ6.s

Thus, either a rule in lang-specs.h is wrong/missing or the problem is in
gfortranspec.c.

I think something like:   %{!o*:-o %b.s}  is missing and %b.s allways is
implicitly used.

Maybe %(cpp_unique_options) should be used? Currently, lang-specs.h contains
the following:

/* Identical to gcc.c (cpp_options), but omitting %(cpp_unique_options)
   and -fpch-preprocess on -save-temps.  */
#define CPP_ONLY_OPTIONS"%1 %{m*} %{f*} %{g*:%{!g0:%{g*} \
 %{!fno-working-directory:-fworking-directory}}} \
 %{std*&ansi&trigraphs} %{W*&pedantic*} %{w} \
 %{O*} %{undef}"

The %b.s seems to be defined in gcc.c's cc1_options.

[Bug preprocessor/41748] Adjust documentation to reflect new (afrer rev. 152599) cpp behavior

[d.g.gorbachev at gmail dot com]

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

Dmitry Gorbachev  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #3 from Dmitry Gorbachev  
2011-01-27 08:35:26 UTC ---
Documented on 'Frequently Asked Questions' wiki page:
.

[Bug rtl-optimization/44174] [4.4/4.5/4.6 Regression] can't find a register in class 'CLOBBERED_REGS' while reloading 'asm'

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou  2011-01-27 
08:39:39 UTC ---
Author: ebotcazou
Date: Thu Jan 27 08:39:33 2011
New Revision: 169325

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169325
Log:
PR rtl-optimization/44174
* gcc.target/i386/asm-6.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/asm-6.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug fortran/47485] gfortran -M output is incorrect when -MT option is used

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org,
   ||dfranke at gcc dot gnu.org

--- Comment #1 from Tobias Burnus  2011-01-27 
08:42:07 UTC ---
The -MT version is added via:

cpp.c's gfc_cpp_init:
  else if (opt->code == OPT_MT || opt->code == OPT_MQ)
deps_add_target (cpp_get_deps (cpp_in),
 opt->arg, opt->code == OPT_MQ);

which matches C's handle_deferred_opts in c-family/c-opts.c.

[Bug fortran/25071] dummy argument larger than actual argument

[burnus at gcc dot gnu.org]

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

--- Comment #10 from Tobias Burnus  2011-01-27 
09:16:47 UTC ---
(In reply to comment #7)
> Sorry for being 'a bit' late with comments, but IMHO this should be an error
> and not just a warning, because
>
> 2) Other compilers reject it (so we can't argue that we must support this
> common extension)

Well, ifort and pathscale compile w/o warning and g95 with just a warning the
example at:  gfortran.fortran-torture/execute/st_function.f90

Thus, for compare_actual_formal I would make a distinction between:

  /* Special case for character arguments.  For allocatable, pointer
 and assumed-shape dummies, the string length needs to match
 exactly.  */

where I agree that at least for pointer and allocatable an error should be
printed - but probably also for assumed-shape dummies.

And to
  if (actual_size != 0
&& actual_size < formal_size
&& a->expr->ts.type != BT_PROCEDURE)

which can be less problematic and where a warning might be sufficient.

[Bug c++/47488] New: [C++0x] decltype + template + string literals: ICE in write_template_arg_literal, at cp/mangle.c

[flast at flast dot jp]

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

   Summary: [C++0x] decltype + template + string literals: ICE in
write_template_arg_literal, at cp/mangle.c
   Product: gcc
   Version: 4.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: fl...@flast.jp


Created attachment 23139
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23139
test code

compiler output:
$ g++-4.5 -std=c++0x testcase.cpp
testcase.cpp: In instantiation of 'decltype (int f(T(), "")) g(const T&) [with
T = int, decltype (f(T(), "")) = int]':
testcase.cpp:9:11:   instantiated from here
testcase.cpp:5:26: internal compiler error: in write_template_arg_literal, at
cp/mangle.c:2687
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

tested version:
4.4.4-14ubuntu5 - Crash
4.5.1 - Crash
4.5.2 - Crash
4.5.6 20110127 - Crash

[Bug rtl-optimization/43494] [4.4/4.5/4.6 Regression] Overlooked dependency causes wrong scheduling, wrong code

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot
   ||gnu.org
  Known to fail||

--- Comment #30 from Eric Botcazou  2011-01-27 
10:46:35 UTC ---
I'll review Alexandre's patch later today.

[Bug c++/47488] [4.4,4.5,4.6 Regression] (sizeof|decltype) + template + string literals: ICE in write_template_arg_literal, at cp/mangle.c

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.01.27 10:56:51
Summary|[C++0x] decltype + template |[4.4,4.5,4.6 Regression]
   |+ string literals: ICE in   |(sizeof|decltype) +
   |write_template_arg_literal, |template + string literals:
   |at cp/mangle.c  |ICE in
   ||write_template_arg_literal,
   ||at cp/mangle.c
 Ever Confirmed|0   |1

--- Comment #1 from Jonathan Wakely  2011-01-27 
10:56:52 UTC ---
This c++98 variation using sizeof instead of decltype gives an ICE in the same
place:

template < typename T >
int f( const T &, const char * );

template struct N { };

template < typename T >
N g( const T &t );

void h()
{
g( 0 );
}


This is a regression since 4.1 which doesn't ICE:

testcase.cpp: In function 'void h()':
testcase.cpp:11: sorry, unimplemented: call_expr cannot be mangled due to a
defect in the C++ ABI

[Bug libgcj/47484] [4.4/4.5/4.6 regression] share/python/aotcompile.py and share/python/classfile.py pollute common namespace

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.01.27 11:02:45
   Target Milestone|--- |4.4.6
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-01-27 
11:02:45 UTC ---
Confirmed.  I do

rm -f $RPM_BUILD_ROOT%{_datadir}/python/aotcompile.py
rm -f $RPM_BUILD_ROOT%{_datadir}/python/classfile.py

since then in our .spec file to avoid the file conflicts (I suppose
nobody needs these files anyway).

[Bug middle-end/47481] [4.6 Regression] i386-rtems* Ada ICE at reload1.c:2105

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Target||i386-rtems*
   Priority|P3  |P4
   Target Milestone|--- |4.6.0
Summary|i386-rtems* Ada ICE at  |[4.6 Regression]
   |reload1.c:2105  |i386-rtems* Ada ICE at
   ||reload1.c:2105

[Bug c++/47488] [4.4,4.5,4.6 Regression] (sizeof|decltype) + template + string literals: ICE in write_template_arg_literal, at cp/mangle.c

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  2011-01-27 
11:09:50 UTC ---
For this variation where f is not deduced, 4.4 says "sorry, unimplemented"
but doesn't ICE, 4.5 and 4.6 ICE in the same place:

template < typename T >
int f( const char * );

template struct N { };

template < typename T >
N( "" ) )> g( const T &t );

void h()
{
g( 0 );
}

[Bug driver/47480] GCC driver names a resolution file after the last argument to the linker

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Guenther  2011-01-27 
11:11:43 UTC ---
I thought I improved the situation with

2010-11-30  Richard Guenther  

PR lto/44986
* gcc.c (main): Use the first input with a compiler as infile
for link spec processing.

the original intent was to name the resolution file after the linker
output file name (in case of -save-temps, of course), but that is not
readily available.  Nor is it possible to avoid the fancy name
assinging -save-temps does (a tmpfile would be ok as well).  All this
requires adding new spec modifiers - ugh.

Thus,

-plugin-opt=-fresolution=%u.res \

the %u needs to be replaced with something that is a better fit
in the -save-temps case (which does not exist).

Btw, your testcase produces t.res for me, not -s.res, so I can't confirm
this bug (the 4.5 branch is probably still affected by the original bug).
t isn't the linker output (a.out is).

So, please double-check your GCC version and paste -v output.

[Bug c++/47478] [4.4 Regression] internal compiler error

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.4.6

--- Comment #7 from Richard Guenther  2011-01-27 
11:18:17 UTC ---
Looks somewhat familiar:

Program received signal SIGSEGV, Segmentation fault.
0x007648d5 in cancel_loop_tree (loop=0xa5a5a5a5a5a5a5a5)
at /space/rguenther/src/svn/gcc-4_4-branch/gcc/cfgloop.c:1305
1305  while (loop->inner)

#0  0x007648d5 in cancel_loop_tree (loop=0xa5a5a5a5a5a5a5a5)
at /space/rguenther/src/svn/gcc-4_4-branch/gcc/cfgloop.c:1305
#1  0x007648d1 in cancel_loop_tree (loop=0x7fffeeaee7e0)
at /space/rguenther/src/svn/gcc-4_4-branch/gcc/cfgloop.c:1306
#2  0x007677da in remove_path (e=0x7fffee3f2040)
at /space/rguenther/src/svn/gcc-4_4-branch/gcc/cfgloopmanip.c:353
#3  0x009b7afe in peel_loop_completely (loop=0x7fffeeaee480)
at /space/rguenther/src/svn/gcc-4_4-branch/gcc/loop-unroll.c:506
#4  0x009b73bd in peel_loops_completely (flags=2)
at /space/rguenther/src/svn/gcc-4_4-branch/gcc/loop-unroll.c:248
#5  0x009b6aaf in unroll_and_peel_loops (flags=2)
at /space/rguenther/src/svn/gcc-4_4-branch/gcc/loop-unroll.c:157
#6  0x009ac87e in rtl_unroll_and_peel_loops ()

Likely a dup of PR42229, fixed with

2009-12-02  Richard Guenther  

PR middle-end/42229
* cfgloopmanip.c (remove_path): Avoid cancelling loops twice.

[Bug rtl-optimization/47477] [4.6 regression] Sub-optimal mov at end of method

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Target|i686|i?86-*-*

--- Comment #2 from Richard Guenther  2011-01-27 
11:22:39 UTC ---
The specific pattern looks easy to catch in a peephole2 or machine dependent
reorg (for destructive arith archs).

[Bug rtl-optimization/47489] New: ICE in print_pattern, at sched-vis.c:602 (affecting mips, with slim RTL dumps)

[m...@joachim-breitner.de]

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

   Summary: ICE in print_pattern, at sched-vis.c:602 (affecting
mips, with slim RTL dumps)
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@joachim-breitner.de


Hi,

I have hit a ICE and could reduce it to the following minimal example:

$ cat bug-demo.c
int func() {
return 0;
}

$ build-mips/gcc/cc1 -O1 -fdump-rtl-mach-slim  bug-demo.c 
 func
Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data>
   Assembling functions:
 func
bug-demo.c: In function ‘func’:
bug-demo.c:3:1: internal compiler error: in print_pattern, at sched-vis.c:602
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

It does not happen with -fdump-rtl-mach, i.e. without slim.

I could not reproduce it by passing individual "-f..." flags instead of -O2,
even though the output of "--help", which mentions which flags are
enabled/disabled, is identical.

This is gcc-4.6 snapshot 20101225, configured using the command line:
../gcc-4.6-20101225/configure --prefix=$PWD/../install  --disable-bootstrap
--disable-multilib --enable-stage1-languages=c
--disable-lib{gcj,ada,ssp,mudflap,gomp} --enable-languages=c
--target=mips-linux


Thanks,
Joachim

[Bug target/47481] [4.6 Regression] spill failure with -O2 -msoft-float on Ada RTS

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot
   ||gnu.org
  Component|middle-end  |target
Summary|[4.6 Regression]|[4.6 Regression] spill
   |i386-rtems* Ada ICE at  |failure with -O2
   |reload1.c:2105  |-msoft-float on Ada RTS

--- Comment #1 from Eric Botcazou  2011-01-27 
11:25:11 UTC ---
-msoft-float certainly doesn't help.

[Bug java/47456] internal compiler error: Segmentation fault while using jna

[steve.reinke at iws dot fraunhofer.de]

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

--- Comment #4 from steve.reinke at iws dot fraunhofer.de 2011-01-27 11:31:50 
UTC ---
is anybody there who can help me?

[Bug c/46620] 32-bit structures containing bitfields are not copied correctly on -O2 , x86 backend

[mikpe at it dot uu.se]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpe at it dot uu.se

--- Comment #2 from Mikael Pettersson  2011-01-27 
11:51:09 UTC ---
On i686-linux this works with gcc 4.1.2 and 4.2.4, fails with 4.3.5 and 4.4.5,
and works again with 4.5.2 (haven't checked trunk).

For 4.5 this was fixed by r147980:

Author: jamborm
Date: Fri May 29 16:47:31 2009
New Revision: 147980

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147980
Log:
2009-05-29  Martin Jambor  

* tree-sra.c:  New implementation of SRA.

[Bug java/47456] internal compiler error: Segmentation fault while using jna

[mikpe at it dot uu.se]

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

--- Comment #5 from Mikael Pettersson  2011-01-27 
12:05:32 UTC ---
(In reply to comment #4)
> is anybody there who can help me?

You need to supply a test case.  If not the original application then something
similar that triggers the same error.

[Bug libfortran/47434] Wrong field width for NaN with (F0.n) formatting

[jvdelisle at gcc dot gnu.org]

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

--- Comment #3 from Jerry DeLisle  2011-01-27 
12:47:04 UTC ---
I agree to fix the NaN case. I have the patch already.

Regarding the other cases:

The copy of the F2008 standard I have says in 10.7.2.3.2 F editing:

"When w is zero, the processor selects the field width."

I also see this:

"Leading zeros are not permitted except for an optional zero immediately to the
left of the decimal symbol if the magnitude of the value in the output field is
less than one."

Similarly for the '+' sign on Inf.  Until now we have chosen to emit the
optional characters.

[Bug c++/46831] [4.6 Regression][C++0x] Crash when it tries to do an invalid ICS with a conversion function template

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.01.27 13:07:21
 Ever Confirmed|0   |1

--- Comment #5 from H.J. Lu  2011-01-27 13:07:21 
UTC ---
(In reply to comment #0)
> GCC crashes on this
> 
> struct B { }; 
> struct D : B { }; 
> 
> struct A { 
>   // [C++0x] default template argument for function template
>   template 
>   operator D&(); 
> }; 
> 
> void f(B&);
> 
> int main() {
>   f(A());
> }
> 
> This code clearly ill-formed by 13.3.3.1.2[over.ics.user] paragraph 3 . C.f.
> 13.3.3.1.4[ocer.ics.ref] paragraph 1.

This ICE is caused by revision 159335:

http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00387.html

[Bug libfortran/47434] Wrong field width for NaN with (F0.n) formatting

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #4 from Tobias Burnus  2011-01-27 
13:08:22 UTC ---
(In reply to comment #3)
> Regarding the other cases:
> Similarly for the '+' sign on Inf.  Until now we have chosen to emit the
> optional characters.

Comparison with other compilers for the example of comment 3.

a) Crayftn 7.2.4
  Infinity
Inf
  0.00
.00
  0.00
.00

b) ifort 11.1, PathScale 3.2.99, Open64 4.2.2.1, 
Infinity
Inf
0.00
.00
0.00
.00

c) Sun Fortran 95 8.3, pgf90 10.5-0
Inf
Inf
0.00
.00
0.00
.00

d) g95 4.03 (0.93)
+Inf
Inf
.00
.00
.00
.00

e) xlf95/AIX V12.1
INF
INF
0.00
.00
0.00
.00

f) NAG 5.1
<<< Yes, that's an zero-length string
Inf
.00
.00
.00
.00

g) g77: Does not like w = 0 and prints "inf" (small "i"), and ".00" for the
other lines.

[Bug c++/46831] [4.6 Regression][C++0x] Crash when it tries to do an invalid ICS with a conversion function template

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  2011-01-27 13:09:52 
UTC ---
(In reply to comment #1)
> 
> --
> We can make this to crash on valid code, too:
> 
> 
> struct B { }; 
> struct D : B { }; 
> struct A { 
>   template operator D&(); 
>   operator long(); 
> }; 
> 
> void f(long); 
> void f(B&);
> 
> int main() { f(A()); }

This ICE is also caused by revision 159335:

http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00387.html

[Bug fortran/25071] dummy argument larger than actual argument

[Joost.VandeVondele at pci dot uzh.ch]

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

--- Comment #11 from Joost VandeVondele  
2011-01-27 13:22:49 UTC ---
I actually vaguely recall why this should be a warning, and not be checked for
at runtime. This is for legacy codes using real :: a(1) instead of real ::
a(*). Something like

SUBROUTINE S1(a)
  INTEGER :: a(10)
  a(10)=0
END SUBROUTINE

SUBROUTINE S2(a)
  INTEGER :: a(1)
  CALL S1(a)
END SUBROUTINE

INTEGER :: a(10)
CALL S2(a)
END

'works just fine'...

[Bug libfortran/47434] Wrong field width for NaN with (F0.n) formatting

[thenlich at users dot sourceforge.net]

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

--- Comment #5 from Thomas Henlich  
2011-01-27 13:25:15 UTC ---
(In reply to comment #3)
> The copy of the F2008 standard I have says in 10.7.2.3.2 F editing:
> 
> "When w is zero, the processor selects the field width."

My interpretation is this:

Section 10.7.2.1 (General rules) applies to these cases, which demands
specifically:

"... the processor selects the smallest positive actual field width that does
not result in a field filled with asterisks. ..."

The statement from 10.7.2.3.2 "When w is zero, the processor selects the field
width." does only refer to this. IMHO it does not suggest the possibility to
include optional characters (a leading decimal zero or plus sign) which make
the field width larger than required.

In the examples, since w=3 ("F3.2") does not result in a field filled with
asterisks, and is the smallest possible such value, the processor must select a
field width of 3.

Also, it is inconsistent that the following commands should result in a
different output:

print "(F0.2)", 0.0
print "(F0.2)", tiny(0.0)

0.00
.00

[Bug libfortran/47434] Wrong field width for NaN with (F0.n) formatting

[burnus at gcc dot gnu.org]

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

--- Comment #6 from Tobias Burnus  2011-01-27 
13:30:30 UTC ---
(In reply to comment #4)
> (In reply to comment #3)
> > Regarding the other cases:
> > Similarly for the '+' sign on Inf.  Until now we have chosen to emit the
> > optional characters.

There seems to be a bug with regards to S:

  print "(s,F0.2)", inf

still prints "+Inf". ("The edit descriptors SS, SP, and S set the sign mode
corresponding to the SIGN= specifier values SUPPRESS, PLUS, and
PROCESSOR_DEFINED, respectively.")


"(6) On output, with I, B, O, Z, F, and G editing, the specified value of the
field width w may be zero. In such cases, the processor selects the smallest
positive actual field width that does not result in a field filled with
asterisks" (10.7.2.1 General rules)

I have to agree with Thomas here: ".00" and "Inf" are the shorted possible
strings, unless SP (sign="PLUS") is used; then "+.00" and "+Inf" are the
shortest possible strings.

In that sense, none of my 10 compiler gets it right ...

[Bug tree-optimization/47228] [4.6 Regression] wrong code with loop

[jamborm at gcc dot gnu.org]

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

--- Comment #7 from Martin Jambor  2011-01-27 
13:41:54 UTC ---
Author: jamborm
Date: Thu Jan 27 13:41:51 2011
New Revision: 169331

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169331
Log:
2011-01-27  Martin Jambor  

PR tree-optimization/47228
* tree-sra.c (sra_modify_assign): Use build_ref_for_model instead of
build_ref_for_offset.

* testsuite/gcc.dg/torture/pr47228.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/torture/pr47228.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-sra.c

[Bug tree-optimization/47228] [4.6 Regression] wrong code with loop

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #8 from Martin Jambor  2011-01-27 
13:42:22 UTC ---
Fixed.

[Bug middle-end/31490] [4.6 Regression] Compile error section type conflict

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |4.6.0
Summary|Compile error section type  |[4.6 Regression] Compile
   |conflict|error section type conflict
  Known to fail||

--- Comment #21 from Jakub Jelinek  2011-01-27 
14:00:25 UTC ---
This patch is wrong and causes DT_TEXTREL nscd.
The relocation mask should never be ignored, otherwise
static const char *const foo __attribute__((__used__, __section__ ("bar"))) =
"baz";
is incorrectly put into readonly section with -fpie or -fpic, eventhough it
must be writable.

[Bug target/37665] invalid loop generation

[corsepiu at gcc dot gnu.org]

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

Ralf Corsepius  changed:

   What|Removed |Added

 CC||corsepiu at gcc dot gnu.org

--- Comment #2 from Ralf Corsepius  2011-01-27 
14:02:45 UTC ---
Joel, could you check if this bug still is present and if it affects RTEMS?

>From what I can gather from looking at the asm gcc generates, this bug might be
fixed in gcc-4.5.x (rtems-4.11)

[Bug middle-end/31490] [4.6 Regression] Compile error section type conflict

[jakub at gcc dot gnu.org]

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

--- Comment #22 from Jakub Jelinek  2011-01-27 
14:09:17 UTC ---
Created attachment 23140
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23140
gcc46-pr31490.patch

Incomplete patch.  pr31490-2.c testcase works (and thus the original one too),
but what still doesn't work is pr31490-3.c, as we call get_variable_section
only from assemble_variable at which point we immediately switch_to_section and
thus it is too late for the second variable to change section flags.

[Bug libstdc++/47354] [4.3 Regression] bitmap_allocator free_list::_M_get never locks mutex

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #13 from Paolo Carlini  2011-01-27 
14:25:41 UTC ---
I guess we can close this as fixed, at this point nobody really cares about
this rather unused allocator in 4.3.x.

[Bug libstdc++/47052] make: *** [configure-target-libstdc++-v3] Error 1 Cross compile GCC for Alpha Architecture

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||paolo.carlini at oracle dot
   ||com
 Resolution||INVALID

--- Comment #2 from Paolo Carlini  2011-01-27 
14:27:05 UTC ---
Feedback not forthcoming.

[Bug c++/47490] New: __Unwind_SjLj_Unregister clobbers return value with i586-mingw32msvc-g++ 4.4.4 and -fstack-protector

[cyp561 at gmail dot com]

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

   Summary: __Unwind_SjLj_Unregister clobbers return value with
i586-mingw32msvc-g++ 4.4.4 and -fstack-protector
   Product: gcc
   Version: 4.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: cyp...@gmail.com
  Host: Ubuntu, 64-bit
Target: i586-mingw32msvc


Wrong code:
i586-mingw32msvc-g++ (GCC) 4.4.4 (on Ubuntu)
Correct code:
i586-mingw32msvc-g++ (Gentoo 4.5.2 p1.0, pie-0.4.5) 4.5.2

Build with:
i586-mingw32msvc-g++ -O0 -fstack-protector -o wtf.exe wtf.cpp

Apparent problem:
The function theCompilerWorks() returns false due to the return value true in
the al register being clobbered by __Unwind_SjLj_Unregister.

The problem only occurs at -O0 in this test case, but the original program
fails at -O2.

May be related to:
Bug 30047 mentions a return value being clobbered by __Unwind_SjLj_Unregister.

Testcase:
-
extern "C" void abort(void);

void a() {}

void (*volatile doNothing)() = a;

struct TheCompilerWorks
{
TheCompilerWorks() {}
~TheCompilerWorks() {}
char unusedArray[340];
};

bool theCompilerWorks()
{
TheCompilerWorks harmlessObject;
doNothing();
return true;
}

int main()
{
if (!theCompilerWorks())
abort();
}
-

[Bug libstdc++/46914] std::atomic::exchange(...) doesn't store correct value.

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #3 from Paolo Carlini  2011-01-27 
14:30:27 UTC ---
Jon, can you help me trying to reproduce this? I can't, it seems an Ubuntu
issue.

[Bug libstdc++/46914] std::atomic::exchange(...) doesn't store correct value.

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  2011-01-27 
14:43:49 UTC ---
I think I tried to reproduce it on Fedora last month and failed - I'll look
again at the weekend

[Bug fortran/47491] New: [4.6 Regression] libgfortran: getpwuid_r (for GETLOG) breaks bootstrapping

[burnus at gcc dot gnu.org]

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

   Summary: [4.6 Regression] libgfortran: getpwuid_r (for GETLOG)
breaks bootstrapping
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: j...@gcc.gnu.org


Follow up to PR 47375 GETLOG thread safety:

As Rainer Orth reports, the patch breaks bootstrapping on Solaris
http://gcc.gnu.org/ml/fortran/2011-01/msg00245.html

Solaris has two versions of getpwuid_r - one matching a draft and one the final
POSIX version:

#if (_POSIX_C_SOURCE - 0 >= 199506L) || defined(_POSIX_PTHREAD_SEMANTICS)
extern int getpwuid_r(uid_t, struct passwd *, char *, int, struct passwd **);
#else
extern struct passwd *getpwuid_r(uid_t, struct passwd *, char *, int);
#endif

[Bug fortran/47491] [4.6 Regression] libgfortran: getpwuid_r (for GETLOG) breaks bootstrapping

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0

[Bug libfortran/47375] GETLOG not threadsafe, causes warnings/wrong-code with static linking

[burnus at gcc dot gnu.org]

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

--- Comment #7 from Tobias Burnus  2011-01-27 
14:48:27 UTC ---
The patch causes build failures on Solaris, cf. bug 47491

[Bug c/47492] New: problem with memset() inside transaction_safe function

[vasilis.karakostas at bsc dot es]

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

   Summary: problem with memset() inside transaction_safe function
   Product: gcc
   Version: trans-mem
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vasilis.karakos...@bsc.es
CC: al...@redhat.com, javier.ar...@bsc.es,
patrick.marl...@gmail.com


Created attachment 23141
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23141
testcase

When I call memset() function from an __attribute__((transaction_safe))
function, I get compilation error.

testcase.c:10:2: error: unsafe function call 'memset' within 'transaction_safe'
function

According to Intel TM ABI, the memset() function is managed by the compiler and
it should be automatically transformed to be transaction safe.
I have attached an example.

[Bug middle-end/31490] [4.6 Regression] Compile error section type conflict

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #23140|0   |1
is obsolete||
 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |

--- Comment #23 from Jakub Jelinek  2011-01-27 
15:00:27 UTC ---
Created attachment 23142
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23142
gcc46-pr31490.patch

Updated patch.

[Bug libstdc++/46914] std::atomic::exchange(...) doesn't store correct value.

[paolo.carlini at oracle dot com]

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

--- Comment #5 from Paolo Carlini  2011-01-27 
15:02:52 UTC ---
Thanks!

[Bug libstdc++/46914] std::atomic::exchange(...) doesn't store correct value.

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  2011-01-27 
15:06:17 UTC ---
as requested in the bug reporting guidelines, please provide the output of 'gcc
-v' (not just gcc --version) so we can see how your compiler was configured

I know the Debian gcc packages default to -march=i486 but I don't know about
Ubuntu

[Bug c/47492] [trans-mem] Problem with memset() inside transaction_safe function

[patrick.marlier at gmail dot com]

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

--- Comment #1 from Patrick Marlier  
2011-01-27 15:10:18 UTC ---
Created attachment 23143
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23143
draft patch

This patch makes it work but:
(trans-mem.c) 
examine_call_tm(): I don't know if it is require to test for BUILT_IN_TM_MEMSET
because it is never reached.
expand_call_tm(): it is required to mark the transaction having transactional
stores but should it be also done for MEMCPY/MEMMOVE?

[Bug c++/44909] [C++0x] Copy constructors implicitly deleted

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED

--- Comment #9 from Jason Merrill  2011-01-27 
15:13:49 UTC ---
Yes.

[Bug libfortran/47493] New: FAIL: gfortran.fortran-torture/execute/csqrt_1.f90 compilation

[danglin at gcc dot gnu.org]

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

   Summary: FAIL: gfortran.fortran-torture/execute/csqrt_1.f90
compilation
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dang...@gcc.gnu.org
  Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
 Build: hppa-unknown-linux-gnu


Executing on host:
/home/dave/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortr
an -B/home/dave/gnu/gcc/objdir/gcc/testsuite/gfortran/../../
-B/home/dave/gnu/gc
c/objdir/hppa-linux-gnu/./libgfortran/
/home/dave/gnu/gcc/gcc/gcc/testsuite/gfor
tran.fortran-torture/execute/csqrt_1.f90  -w  -O0  
-B/home/dave/gnu/gcc/objdir/
hppa-linux-gnu/./libgfortran/.libs
-L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./
libgfortran/.libs
-L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgfortran/.libs
 -L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libiberty  -lm   -o
/home/dave/gnu
/gcc/objdir/gcc/testsuite/gfortran/csqrt_1.x(timeout = 300)
/tmp/ccY8Zsb4.o: In function `.LC9':
(.rodata+0x68): undefined reference to `_gfortran_specific__sqrt_r8'
collect2: ld returned 1 exit status
compiler exited with status 1
output is:
/tmp/ccY8Zsb4.o: In function `.LC9':
(.rodata+0x68): undefined reference to `_gfortran_specific__sqrt_r8'
collect2: ld returned 1 exit status

FAIL: gfortran.fortran-torture/execute/csqrt_1.f90 compilation,  -O0

dave@mx3210:~/gnu/gcc/objdir/gcc$ ./xgcc -B./ -v
Reading specs from ./specs
COLLECT_GCC=./xgcc
COLLECT_LTO_WRAPPER=./lto-wrapper
Target: hppa-linux-gnu
Configured with: ../gcc/configure --with-gnu-as --with-gnu-ld --enable-shared
--prefix=/home/dave/opt/gnu/gcc/gcc-4.6.0
--with-local-prefix=/home/dave/opt/gnu --enable-threads=posix
--enable-__cxa_atexit --build=hppa-linux-gnu --enable-clocale=gnu
--enable-java-gc=boehm --without-cloog --without-ppl
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
Thread model: posix
gcc version 4.6.0 20110125 (experimental) [trunk revision 169250] (GCC)

[Bug libfortran/47432] ttyname() not thread-safe

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus  2011-01-27 
15:18:23 UTC ---
Janne's patch: http://gcc.gnu.org/ml/fortran/2011-01/msg00225.html

There is an POSIX-version issue (draft and final) on Solaris,
cf. http://gcc.gnu.org/ml/fortran/2011-01/msg00248.html (or related PRs 47491
and 47431).

Rainer Orth wrote:

* full standard:

  extern int ttyname_r(int, char *, size_t);

* draft standard:

  extern char *ttyname_r(int, char *, int);

[Bug libfortran/47431] ctime() not thread-safe

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus  2011-01-27 
15:19:22 UTC ---
Janne's patch: http://gcc.gnu.org/ml/fortran/2011-01/msg00224.html

There is an POSIX-version issue (draft and final) on Solaris,
cf. http://gcc.gnu.org/ml/fortran/2011-01/msg00248.html (or related PRs 47491
and 47432).

Rainer Orth wrote:

* full standard:

  extern char *ctime_r(const time_t *, char *);

* draft standards:

  extern char *ctime_r(const time_t *, char *, int);

[Bug libfortran/47431] ctime() not thread-safe

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  2011-01-27 
15:21:48 UTC ---
(In reply to comment #1)
> (or related PRs 47491 and 47432).
(did not link. Try harder:)

PR 47491 - bootstrap error for GETLOG's getpwuid_r
   Cf. solution ideas at
   http://gcc.gnu.org/ml/fortran/2011-01/msg00245.html

PR 47432 - ttyname_r issue (not committed)

[Bug libstdc++/47354] [4.3 Regression] bitmap_allocator free_list::_M_get never locks mutex

[greed at pobox dot com]

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

--- Comment #14 from Graham Reed  2011-01-27 15:22:36 
UTC ---
I agree; thanks guys.

[Bug libfortran/47432] ttyname() not thread-safe

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  2011-01-27 
15:22:43 UTC ---
(In reply to comment #1)
> (or related PRs 47491 and 47431).
(did not link. Try harder:)

PR 47491 - bootstrap error for GETLOG's getpwuid_r
   Cf. solution ideas at
   http://gcc.gnu.org/ml/fortran/2011-01/msg00245.html

PR 47431 - ctime_r issue (not committed)

[Bug libfortran/47432] ttyname() not thread-safe

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  2011-01-27 
15:23:36 UTC ---
(In reply to comment #2)
> PR 47431 - ctime_r issue (not committed)
  PR 47432 <<< should be

[Bug libstdc++/46914] std::atomic::exchange(...) doesn't store correct value.

[paolo.carlini at oracle dot com]

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

--- Comment #7 from Paolo Carlini  2011-01-27 
15:33:47 UTC ---
Ok. In any case we should not risk miscompiling stuff, better bailing out at
compile time. I see that in atomic_base.h the configure-time macros
_GLIBCXX_ATOMIC_BUILTINS_* are used and I se no uses of the
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_* macros, the only one sensitive to the
command line switches. But apparently the PR is about compiling *without* any
special command line switch affecting the availability of the builtins, thus I
don't see how things could possibly go wrong. Something also to keep in mind is
that [GLIBCXX_ENABLE_ATOMIC_BUILTINS] in acinclude.m4 changed recently: I don't
think we want to go through big efforts fixing this issue affecting only C++0x
facilities in case it shows up only on 4.4.x, say, and it's fixed in mainline.
I'll also try to run further tests in mainline, multilib too.

[Bug fortran/47494] New: .MOD files: Consider removing the time stamp

[burnus at gcc dot gnu.org]

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

   Summary: .MOD files: Consider removing the time stamp
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


At http://gcc.gnu.org/ml/gcc-patches/2011-01/msg02012.html Simon Baldwin wrote:

Strict build environments do binary comparisons of files across gcc builds.
Writing the current timestamp into a Fortran .mod file leads to false
positives from such environments.  Omitting the timestamp removes these
false positives.

That change was in Google's internal GCC - and is now pushed to the Google
branch in SVN.

One should consider to apply the patch also to the trunk

[Bug libstdc++/46914] std::atomic::exchange(...) doesn't store correct value.

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot
   ||com

--- Comment #8 from Paolo Carlini  2011-01-27 
15:45:01 UTC ---
I can confirm my negative results with multilib mainline default configured.

[Bug fortran/47494] .MOD files: Consider removing the time stamp

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  2011-01-27 
15:50:57 UTC ---
Cf. also http://gcc.gnu.org/ml/fortran/2011-01/msg00250.html

[Bug lto/47274] [4.6 regression] ICE in lto_varpool_replace_node, at lto-symtab.c:306

[hubicka at gcc dot gnu.org]

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

--- Comment #17 from Jan Hubicka  2011-01-27 
15:51:54 UTC ---
You uploaded the cgraph files from local compilation.main_test is not called in
abs-1.c

I need to see the dump from merging, too.
They gets name of one of the .o files when -save-temps is used.
I.e.
./xgcc -B ./ -O2 abs-1-lib.c abs-1.c m.c -fdump-ipa-cgraph -save-temps -flto
gets me the dump in abs-1-lib.o.000i.cgraph

Honza

[Bug middle-end/45422] [4.6 Regression] compile time increases 3x.

[jakub at gcc dot gnu.org]

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

--- Comment #37 from Jakub Jelinek  2011-01-27 
15:55:57 UTC ---
/usr/src/gcc/objr/gcc/f951 -quiet -ftime-report -fbounds-check -g -O3
-ffast-math -funroll-loops -ftree-vectorize -march=amdfam10 pr45422.f90 2>&1 |
grep ':[ ]*[1-9]\|TOTAL'
 garbage collection:   1.34 ( 1%) usr   0.00 ( 0%) sys   1.32 ( 1%) wall   
   0 kB ( 0%) ggc
 cfg cleanup   :   2.24 ( 2%) usr   0.01 ( 0%) sys   2.26 ( 2%) wall   
7301 kB ( 0%) ggc
 df reaching defs  :   1.46 ( 1%) usr   0.02 ( 1%) sys   1.34 ( 1%) wall   
   0 kB ( 0%) ggc
 df live regs  :   8.28 ( 6%) usr   0.02 ( 1%) sys   8.49 ( 6%) wall   
   0 kB ( 0%) ggc
 df live&initialized regs:   2.46 ( 2%) usr   0.00 ( 0%) sys   2.98 ( 2%) wall 
 0 kB ( 0%) ggc
 df use-def / def-use chains:   1.31 ( 1%) usr   0.00 ( 0%) sys   1.13 ( 1%)
wall   0 kB ( 0%) ggc
 df reg dead/unused notes:   4.01 ( 3%) usr   0.00 ( 0%) sys   4.03 ( 3%) wall 
  7770 kB ( 0%) ggc
 register information  :   1.48 ( 1%) usr   0.00 ( 0%) sys   1.53 ( 1%) wall   
   0 kB ( 0%) ggc
 alias analysis:   1.86 ( 1%) usr   0.00 ( 0%) sys   1.89 ( 1%) wall  
46655 kB ( 3%) ggc
 tree VRP  :   2.25 ( 2%) usr   0.08 ( 4%) sys   2.27 ( 2%) wall  
74472 kB ( 4%) ggc
 tree SSA incremental  :   1.43 ( 1%) usr   0.25 (11%) sys   1.34 ( 1%) wall   
7187 kB ( 0%) ggc
 complete unrolling:   1.19 ( 1%) usr   0.14 ( 6%) sys   1.24 ( 1%) wall  
91809 kB ( 5%) ggc
 tree prefetching  :   1.31 ( 1%) usr   0.12 ( 5%) sys   1.50 ( 1%) wall  
92179 kB ( 5%) ggc
 tree iv optimization  :  15.43 (11%) usr   0.09 ( 4%) sys  15.62 (11%) wall 
303704 kB (17%) ggc
 expand:   1.11 ( 1%) usr   0.03 ( 1%) sys   1.11 ( 1%) wall  
81489 kB ( 5%) ggc
 forward prop  :   1.17 ( 1%) usr   0.01 ( 0%) sys   1.19 ( 1%) wall  
16030 kB ( 1%) ggc
 CSE   :   1.58 ( 1%) usr   0.01 ( 0%) sys   1.42 ( 1%) wall   
 667 kB ( 0%) ggc
 dead code elimination :   1.24 ( 1%) usr   0.00 ( 0%) sys   1.30 ( 1%) wall   
   0 kB ( 0%) ggc
 dead store elim1  :   1.37 ( 1%) usr   0.00 ( 0%) sys   1.31 ( 1%) wall  
23509 kB ( 1%) ggc
 dead store elim2  :   1.10 ( 1%) usr   0.00 ( 0%) sys   1.08 ( 1%) wall  
22323 kB ( 1%) ggc
 loop unrolling:   3.99 ( 3%) usr   0.03 ( 1%) sys   4.11 ( 3%) wall 
185245 kB (11%) ggc
 CPROP :   2.25 ( 2%) usr   0.01 ( 0%) sys   2.00 ( 1%) wall  
25084 kB ( 1%) ggc
 PRE   :   1.20 ( 1%) usr   0.00 ( 0%) sys   1.13 ( 1%) wall   
1576 kB ( 0%) ggc
 web   :   1.09 ( 1%) usr   0.00 ( 0%) sys   1.09 ( 1%) wall   
8368 kB ( 0%) ggc
 CSE 2 :   2.10 ( 2%) usr   0.01 ( 0%) sys   2.17 ( 2%) wall   
2122 kB ( 0%) ggc
 combiner  :   3.97 ( 3%) usr   0.00 ( 0%) sys   3.96 ( 3%) wall  
60594 kB ( 3%) ggc
 integrated RA :  10.18 ( 7%) usr   0.01 ( 0%) sys  10.27 ( 7%) wall  
44477 kB ( 3%) ggc
 reload:   6.31 ( 5%) usr   0.01 ( 0%) sys   6.24 ( 4%) wall  
10153 kB ( 1%) ggc
 reload CSE regs   :   4.39 ( 3%) usr   0.01 ( 0%) sys   4.17 ( 3%) wall  
37354 kB ( 2%) ggc
 rename registers  :   1.13 ( 1%) usr   0.00 ( 0%) sys   1.18 ( 1%) wall   
2500 kB ( 0%) ggc
 scheduling 2  :   5.84 ( 4%) usr   0.02 ( 1%) sys   5.81 ( 4%) wall   
1160 kB ( 0%) ggc
 final :   4.29 ( 3%) usr   0.04 ( 2%) sys   4.66 ( 3%) wall  
10463 kB ( 1%) ggc
 variable tracking :   2.76 ( 2%) usr   0.01 ( 0%) sys   2.73 ( 2%) wall  
64964 kB ( 4%) ggc
 var-tracking dataflow :   3.86 ( 3%) usr   0.02 ( 1%) sys   3.90 ( 3%) wall   
   0 kB ( 0%) ggc
 var-tracking emit :   3.89 ( 3%) usr   0.01 ( 0%) sys   3.85 ( 3%) wall  
19488 kB ( 1%) ggc
 rest of compilation   :   2.27 ( 2%) usr   0.08 ( 4%) sys   2.28 ( 2%) wall  
21438 kB ( 1%) ggc
 remove unused locals  :   1.02 ( 1%) usr   0.01 ( 0%) sys   0.92 ( 1%) wall   
   0 kB ( 0%) ggc
 unaccounted todo  :   1.21 ( 1%) usr   0.05 ( 2%) sys   1.19 ( 1%) wall   
   8 kB ( 0%) ggc
 TOTAL : 137.09 2.28   139.39   
1741129 kB

/usr/src/gcc-4.5/objr/gcc/f951 -quiet -ftime-report -fbounds-check -g -O3
-ffast-math -funroll-loops -ftree-vectorize -march=amdfam10 pr45422.f90 2>&1 |
grep ':[  ]*[1-9]\|TOTAL'
 df live regs  :   2.05 ( 4%) usr   0.00 ( 0%) sys   1.95 ( 4%) wall   
   0 kB ( 0%) ggc
 tree VRP  :   1.43 ( 3%) usr   0.15 ( 8%) sys   1.47 ( 3%) wall  
56376 kB ( 6%) ggc
 complete unrolling:   1.14 ( 2%) usr   0.18 (10%) sys   1.39 ( 3%) wall  
98554 kB (11%) ggc
 tree iv optimization  :   5.31 (10%) usr   0.05 ( 3%) sys   5.40 (10%) wall  
95356 kB (11%) ggc
 expand:   2.98 ( 6%) usr   0.11 ( 6%) sys   3.29 ( 6%) wall  
69642 kB ( 8%) ggc
 combiner  :   1.49 ( 3%) usr   0.00 ( 0%) sys   1.22 ( 2%) wall  
19980 kB ( 2%) ggc
 integrated RA :   3.60 ( 7%) usr   0.01 ( 1%) sys   3.56 ( 6%) wall  
12746 kB ( 1%) ggc
 reload   

[Bug fortran/47491] [4.6 Regression] libgfortran: getpwuid_r (for GETLOG) breaks bootstrapping

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-01-27 15:57:09 UTC ---
Just FYI: as a quick hack, I've added -D_XOPEN_SOURCE=600 to AM_CPPFLAGS
in Makefile.in.  This allowed me to finish the build.  While this should
also work on Solaris 10 (the initial test was on Solaris 11), I've no
idea what will happen on Solaris 8 and 9: although they have the same
problem, they lack XPG6 support.

Rainer

[Bug libstdc++/46914] std::atomic::exchange(...) doesn't store correct value.

[paolo.carlini at oracle dot com]

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

--- Comment #9 from Paolo Carlini  2011-01-27 
15:58:19 UTC ---
Likewise for 4_5-branch.

[Bug fortran/47495] New: .mod files: File modification time - Makefile build issue

[burnus at gcc dot gnu.org]

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

   Summary: .mod files: File modification time - Makefile build
issue
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


Problem described by Thomas Henlich
at http://gcc.gnu.org/ml/fortran/2011-01/msg00242.html

Currently, gfortran only updates the .mod file (content and file modification
date) if the file changes.

That change has been introduced 2007 with PR 31587
and http://gcc.gnu.org/ml/fortran/2007-04/msg00331.html

The issue is the compilation cascade:

(a) If the source file changes, but the .mod file does not there should be no
recompilation of module USErs required

(b) If the source file changes and a new .o is produced, there is no need to
recompile the source to produce another .mod file with the same
modification
date.

As Thomas' email shows, the current Makefile as written by "gfortran -M" cause
a contiguous recompilation of the source files:

  mymodule.o mymodule.mod: mymodule.f90
gfortran -c mymodule.f90

will always recompile the file as "mymodule.mod" stays older than
"mymodule.f90".


On the other hand, for:
  myprogram.o: myprogram.f90 mymodule.mod
gfortran -c myprogram.f90
the file will only be recompiled if mymodule.mod actually changes, which is
good.


The question is: How can one solve this properly? Possibly without dating back
the creation date of the .f90 file ...

[Bug middle-end/45422] [4.6 Regression] compile time increases 3x.

[jakub at gcc dot gnu.org]

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

--- Comment #38 from Jakub Jelinek  2011-01-27 
16:02:49 UTC ---
*.gimple dump is roughly the same size between 4.5 and 4.6, but resulting
assembly size is 15MB in 4.5 and 23MB (with only < 100KB variation with
-fno-ivopts) in 4.6.  -fno-inline doesn't help neither compile time nor
assembly size though on 4.6.

[Bug fortran/47491] [4.6 Regression] libgfortran: getpwuid_r (for GETLOG) breaks bootstrapping

[jb at gcc dot gnu.org]

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

--- Comment #2 from Janne Blomqvist  2011-01-27 16:10:41 
UTC ---
Some git-grepping showed that at least libjava has in configure.ac

AC_DEFINE(_POSIX_PTHREAD_SEMANTICS, 1, [Required define if using POSIX
threads])

and in case Boehm GC is not used (which libgfortran never uses):

AC_DEFINE(_REENTRANT, 1, [Required define if using POSIX threads])

However, if I understand gcc/config/ correctly, _REENTRANT should be
automatically set for all targets that need it.

Also in gcc/config a few targets set 

-D_POSIX_C_SOURCE=199506L

(not Solaris, though). But apparently we shouldn't go and set this somewhere in
libgfortran? That is, at least no other library does this..

Moreover, in config/extensions.m4 there is the macro

AC_USE_SYSTEM_EXTENSIONS

that seems to define _POSIX_PTHREAD_SEMANTICS on Solaris.

This seems to me the most sensible solution. Would that work?

[Bug fortran/47495] .mod files: File modification time - Makefile build issue

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  2011-01-27 
16:11:18 UTC ---
For the example, the following works - though it it not robust: The order of
the "myprogram" dependencies matters - and for the same reason doing a "make
myprogram.o" will fail.  (Assuming that mymodule.f90 has a change, which is
required by myprogram.)

myprogram: mymodule.o myprogram.o
gfortran -o myprogram myprogram.o mymodule.o
mymodule.mod:
gfortran -c mymodule.f90
mymodule.o: mymodule.f90
gfortran -c mymodule.f90
myprogram.o: myprogram.f90 mymodule.mod
gfortran -c myprogram.f90

[Bug middle-end/46949] [4.6 regression] ICE when weakref is used on a definition (internal compiler error: in function_and_variable_visibility, at ipa.c:904)

[hubicka at gcc dot gnu.org]

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

--- Comment #2 from Jan Hubicka  2011-01-27 
16:16:44 UTC ---
Author: hubicka
Date: Thu Jan 27 16:16:34 2011
New Revision: 169332

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169332
Log:
PR middle-end/46949
* cgraphunit.c (process_common_attributes): Fix use of remove_attribute.
(process_function_and_variable_attributes): Check defined weakrefs.
* gcc.dg/attr-weakref-4.c: New testcase

Added:
trunk/gcc/testsuite/gcc.dg/attr-weakref-4.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraphunit.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/45422] [4.6 Regression] compile time increases 3x.

[rguenth at gcc dot gnu.org]

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

--- Comment #39 from Richard Guenther  2011-01-27 
16:16:48 UTC ---
The size difference is likely from prefetching, it's 1.5MB vs. 1.1MB without
that (-O3 -fbounds-check -ffast-math -funroll-loops).  Prefetching usually
causes another set of (then RTL unrolled) loop copies.  See PR44688.

[Bug middle-end/45422] [4.6 Regression] compile time increases 3x.

[rguenth at gcc dot gnu.org]

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

--- Comment #40 from Richard Guenther  2011-01-27 
16:19:26 UTC ---
Btw, when I remove -fbounds-check the sizes are comparable (without
prefetching),
so I guess we are just better in removing bounds checking for 4.6 and that
triggers size-costly loop opts such as vectorization and unrolling.

[Bug middle-end/46949] [4.6 regression] ICE when weakref is used on a definition (internal compiler error: in function_and_variable_visibility, at ipa.c:904)

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Jan Hubicka  2011-01-27 
16:19:56 UTC ---
Fixed.

[Bug middle-end/45422] [4.6 Regression] compile time increases 3x.

[jakub at gcc dot gnu.org]

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

--- Comment #41 from Jakub Jelinek  2011-01-27 
16:28:49 UTC ---
With additional -fno-prefetch-loop-arrays the TOTAL goes down from that 137s to
92.23, and judging from tree dumps between 4.5 and 4.6 we do significantly more
vectorization too (4.6 *.ifcvt is 4.7MB compared to 5.3MB 4.5 *.ifcvt, while
4.6 *.vect grows to 8.3MB while 4.5 *.vect stays at 5.3MB).

[Bug fortran/47491] [4.6 Regression] libgfortran: getpwuid_r (for GETLOG) breaks bootstrapping

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-01-27 16:28:39 UTC ---
> --- Comment #2 from Janne Blomqvist  2011-01-27 
> 16:10:41 UTC ---
> Some git-grepping showed that at least libjava has in configure.ac
>
> AC_DEFINE(_POSIX_PTHREAD_SEMANTICS, 1, [Required define if using POSIX
> threads])
>
> and in case Boehm GC is not used (which libgfortran never uses):
>
> AC_DEFINE(_REENTRANT, 1, [Required define if using POSIX threads])
>
> However, if I understand gcc/config/ correctly, _REENTRANT should be
> automatically set for all targets that need it.

At least on Solaris (and I think on other targets as well), only with
-pthread.

> Also in gcc/config a few targets set 
>
> -D_POSIX_C_SOURCE=199506L
>
> (not Solaris, though). But apparently we shouldn't go and set this somewhere 
> in
> libgfortran? That is, at least no other library does this..

That may not provide the best guidance.  I'd rather look for autoconf
and/or gnulib here.  On Solaris, this may not be enough: starting with
Solaris 10, there's POSIX.1-2001 support via -D_POSIX_C_SOURCE=200112L.

> Moreover, in config/extensions.m4 there is the macro
>
> AC_USE_SYSTEM_EXTENSIONS
>
> that seems to define _POSIX_PTHREAD_SEMANTICS on Solaris.
>
> This seems to me the most sensible solution. Would that work?

Seems so.  At least I've just found that I need -D__EXTENSIONS__ in
addition to -D_XOPEN_SOURCE=600 to get EIP defined in 
(needed by fpu-target.h).

Rainer

[Bug middle-end/45422] [4.6 Regression] compile time increases 3x.

[rguenth at gcc dot gnu.org]

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

--- Comment #42 from Richard Guenther  2011-01-27 
16:30:52 UTC ---
Comparing -O3 -ffast-math -funroll-loops -fno-inline -fno-partial-inlining
(thus generic arch, without prefetching):

trunk:

 df live regs  :   4.22 ( 6%) usr   0.04 ( 2%) sys   4.11 ( 5%) wall   
   0 kB ( 0%) ggc
 tree iv optimization  :   3.92 ( 5%) usr   0.13 ( 5%) sys   4.29 ( 6%) wall  
91066 kB (11%) ggc
 integrated RA :   5.57 ( 8%) usr   0.10 ( 4%) sys   5.93 ( 8%) wall  
26408 kB ( 3%) ggc
 scheduling 2  :   3.73 ( 5%) usr   0.04 ( 2%) sys   3.85 ( 5%) wall   
 939 kB ( 0%) ggc
 TOTAL :  73.68 2.3776.91
852775 kB

4.5:

 df live regs  :   4.60 ( 7%) usr   0.02 ( 1%) sys   4.62 ( 6%) wall   
   0 kB ( 0%) ggc
 expand:   3.94 ( 6%) usr   0.17 ( 8%) sys   3.94 ( 6%) wall  
62218 kB ( 8%) ggc
 integrated RA :   5.73 ( 8%) usr   0.02 ( 1%) sys   5.76 ( 8%) wall  
22920 kB ( 3%) ggc
 reload:   3.78 ( 5%) usr   0.08 ( 4%) sys   3.86 ( 5%) wall   
9291 kB ( 1%) ggc
 TOTAL :  68.98 2.0171.22
828137 kB

it would be nice to confirm that we are indeed much better with
optimizing bounds-checking code.  The prefetching issue is
tracked as PR44688.  So I'd close this either as a dup or as
wontfix (it's a feature that we optimize loops with bounds-checking).

[Bug libfortran/47434] Wrong field width for NaN with (F0.n) formatting

[jvdelisle at gcc dot gnu.org]

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

--- Comment #7 from Jerry DeLisle  2011-01-27 
16:35:13 UTC ---
I remember the discussion when we first implemented this and we wanted the + on
Inf to be consistent with -Inf. 

Oh well, if folks really feel strongly about this, I can change it all.  Hmm, I
think I will add the optional NaN type field so now the smallest I can fit will
be quite a bit wider then 3.  (Just kidding ;) )

[Bug target/47246] [4.6 Regression] Invalid immediate offset for Thumb VFP store regression

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution||FIXED

--- Comment #5 from Chung-Lin Tang  2011-01-26 
03:01:49 UTC ---
Author: cltang
Date: Wed Jan 26 03:01:44 2011
New Revision: 169271

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169271
Log:
2011-01-26  Chung-Lin Tang  

PR target/47246
* config/arm/arm.c (thumb2_legitimate_index_p): Change the
lower bound of the allowed Thumb-2 coprocessor load/store
index range to -256. Add explaining comment.

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

--- Comment #6 from Jakub Jelinek  2011-01-27 
16:39:41 UTC ---
Assuming this is fixed now.

[Bug middle-end/45422] [4.6 Regression] compile time increases 3x.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX

--- Comment #43 from Jakub Jelinek  2011-01-27 
16:43:17 UTC ---
Yeah, I agree.

[Bug bootstrap/47279] Bootstrap fails in stage1 with GCC 4.6

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||amodra at gmail dot com,
   ||hubicka at gcc dot gnu.org

--- Comment #1 from Jan Hubicka  2011-01-27 
16:50:43 UTC ---
I can not parse the error, but it seems to be introduced by Alan's patch
http://odin3.kernel.org/git-lewiemann/?p=devel/binutils/hjl/x86.git;a=commitdiff_plain;h=cf32326845120a7fd0d4eecbd42bd9374fa0b74d

Alan, any idea what gets wrong and why?

[Bug target/47246] [4.6 Regression] Invalid immediate offset for Thumb VFP store regression

[ibolton at gcc dot gnu.org]

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

--- Comment #7 from Ian Bolton  2011-01-27 16:51:41 
UTC ---
(In reply to comment #6)
> Assuming this is fixed now.

Yes, I can use trunk to run the whole of Spec2K for -O3 -mthumb without errors.

[Bug fortran/47495] .mod files: File modification time - Makefile build issue

[Joost.VandeVondele at pci dot uzh.ch]

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

--- Comment #2 from Joost VandeVondele  
2011-01-27 16:52:07 UTC ---
Not sure if that solves the issue, but CP2K uses these rules:

%.o: %.F
$(FC) -c $(FCFLAGS) $<


%.mod: %.o
@true

with these style dependencies:

ai_coulomb_test.o ai_coulomb_test.mod : ai_coulomb_test.F cp_common_uses.h
cp_error_handling.mod cp_log_handling.mod physcon.mod 

so faking that .mod is made up to date by having an up to date .o.

[Bug target/35926] Pushing / Poping ebx without using it.

[tony.poppleton at gmail dot com]

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

--- Comment #6 from Tony Poppleton  2011-01-27 
16:55:26 UTC ---
For the record, the additional movl noticed above in GCC 4.6.0 has been
factored out into PR47477

[Bug middle-end/47496] New: HAS_DECL_ASSEMBLER_NAME_P and DECL_ASSEMBLER_NAME has some incosistency

[adam.rak at streamnovation dot com]

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

   Summary: HAS_DECL_ASSEMBLER_NAME_P and DECL_ASSEMBLER_NAME has
some incosistency
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: adam@streamnovation.com


The following code would hit gcc_unreachable if DECL_ASSEMBLER_NAME_SET_P(expr)
is NULL, which seems valid if DECL_IGNORED_P is true.

if (HAS_DECL_ASSEMBLER_NAME_P(expr))
return DECL_ASSEMBLER_NAME(expr);

It would be more consistent if DECL_ASSEMBLER_NAME returns NULL in this special
case. So DECL_ASSEMBLER_NAME should check DECL_IGNORED_P too.

The other case is when the assembler name hasn't been set yet and DECL_IGNORE_P
is false. It is unclear which counts as a bogus call to DECL_ASSEMBLER_NAME and
which is not.

[Bug libfortran/47493] FAIL: gfortran.fortran-torture/execute/csqrt_1.f90 compilation

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus  2011-01-27 
17:04:51 UTC ---
> (.rodata+0x68): undefined reference to `_gfortran_specific__sqrt_r8'

Can you run:
 nm libgfortran.a |grep _gfortran_specific__sqrt_
on my system that gives:

 T _gfortran_specific__sqrt_r4
 T _gfortran_specific__sqrt_r8
 T _gfortran_specific__sqrt_r10
 T _gfortran_specific__sqrt_r16
 T _gfortran_specific__sqrt_c4
 T _gfortran_specific__sqrt_c8
 T _gfortran_specific__sqrt_c10
 T _gfortran_specific__sqrt_c16

and I somehow expect that also HPPA has a double-precision sqrt ...

 * * *

The other question is: Why is that wrapper called and not directly
__builtin_sqrt? In C that also works:


#include 
#include 

static void
myproc(double(*f)(double), double x)
{
  printf("%e: %e %e\n", x, f(x),sqrt(x));
}

main()
{
  myproc(__builtin_sqrt, 4.0);
  return 0;
}

Result:
  printf (&"%e: %e %e\n"[0], 4.0e+0, 2.0e+0, 2.0e+0);
  return 0;

While the Fortran equivalent produces:
  myproc (_gfortran_specific__sqrt_r8, &C.1537);
and
  D.1545_3 = f_2(D) (x_1(D));
  D.1547_5 = __builtin_sqrt (D.1546_4);

for

program main
  intrinsic dsqrt
  call myproc(dsqrt, 4.0d0)
contains
  subroutine myproc(f, x)
procedure(dsqrt) f
real(8), value :: x
print *, x, f(x), dsqrt(x)
  end subroutine myproc
end program main

The big other question is: why is "myproc" is not inlined? (For -O3
(-fwhole-program, (-flto)).)

[Bug lto/47274] [4.6 regression] ICE in lto_varpool_replace_node, at lto-symtab.c:306

[dave at hiauly1 dot hia.nrc.ca]

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

--- Comment #18 from dave at hiauly1 dot hia.nrc.ca 2011-01-27 17:07:34 UTC ---
On Thu, 27 Jan 2011, hubicka at gcc dot gnu.org wrote:

> I need to see the dump from merging, too.
> They gets name of one of the .o files when -save-temps is used.
> I.e.
> ./xgcc -B ./ -O2 abs-1-lib.c abs-1.c m.c -fdump-ipa-cgraph -save-temps -flto
> gets me the dump in abs-1-lib.o.000i.cgraph

It seems the ICE occurs before the merge files are generated:

Reading specs from /home2/dave/gcc-4.6/objdir/gcc/specs
COLLECT_GCC=/home2/dave/gcc-4.6/objdir/gcc/xgcc
COLLECT_LTO_WRAPPER=/home2/dave/gcc-4.6/objdir/gcc/lto-wrapper
Target: hppa-linux
Configured with: ../gcc/configure --with-gnu-as --with-gnu-ld --enable-shared
--enable-nls --prefix=/home2/dave/opt/gnu/gcc/gcc-4.6.0
--with-local-prefix=/home2/dave/opt/gnu --enable-threads=posix
--enable-__cxa_atexit --build=hppa-linux --enable-clocale=gnu
--enable-java-gc=boehm --enable-java-awt=xlib
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
Thread model: posix
gcc version 4.6.0 20110126 (experimental) [trunk revision 169296] (GCC) 
COLLECT_GCC_OPTIONS='-B' '/home2/dave/gcc-4.6/objdir/gcc/' '-w' '-O2' '-flto'
'-fno-builtin-abs' '-o' '/home2/dave/gcc-4.6/objdir/gcc/testsuite/gcc/abs-1.x7'
'-fdump-ipa-cgraph' '-save-temps' '-v'
 /home2/dave/gcc-4.6/objdir/gcc/cc1 -E -quiet -v -iprefix
/home2/dave/gcc-4.6/objdir/gcc/../lib/gcc/hppa-linux/4.6.0/ -isystem
/home2/dave/gcc-4.6/objdir/gcc/include -isystem
/home2/dave/gcc-4.6/objdir/gcc/include-fixed
/home2/dave/gcc-4.6/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/abs-1.c -w
-flto -fno-builtin-abs -fdump-ipa-cgraph -O2 -fpch-preprocess -o abs-1.i
ignoring nonexistent directory
"/home2/dave/gcc-4.6/objdir/gcc/../lib/gcc/hppa-linux/4.6.0/include"
ignoring nonexistent directory
"/home2/dave/gcc-4.6/objdir/gcc/../lib/gcc/hppa-linux/4.6.0/include-fixed"
ignoring nonexistent directory
"/home2/dave/gcc-4.6/objdir/gcc/../lib/gcc/hppa-linux/4.6.0/../../../../hppa-linux/include"
ignoring nonexistent directory
"/home2/dave/gcc-4.6/objdir/gcc/../lib/gcc/../../lib/gcc/hppa-linux/4.6.0/include"
ignoring nonexistent directory
"/home2/dave/gcc-4.6/objdir/gcc/../lib/gcc/../../include"
ignoring nonexistent directory
"/home2/dave/gcc-4.6/objdir/gcc/../lib/gcc/../../lib/gcc/hppa-linux/4.6.0/include-fixed"
ignoring nonexistent directory
"/home2/dave/gcc-4.6/objdir/gcc/../lib/gcc/../../lib/gcc/hppa-linux/4.6.0/../../../../hppa-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /home2/dave/gcc-4.6/objdir/gcc/include
 /home2/dave/gcc-4.6/objdir/gcc/include-fixed
 /home2/dave/opt/gnu/include
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-B' '/home2/dave/gcc-4.6/objdir/gcc/' '-w' '-O2' '-flto'
'-fno-builtin-abs' '-o' '/home2/dave/gcc-4.6/objdir/gcc/testsuite/gcc/abs-1.x7'
'-fdump-ipa-cgraph' '-save-temps' '-v'
 /home2/dave/gcc-4.6/objdir/gcc/cc1 -fpreprocessed abs-1.i -quiet -dumpbase
abs-1.c -auxbase abs-1 -O2 -w -version -flto -fno-builtin-abs -fdump-ipa-cgraph
-o abs-1.s
GNU C (GCC) version 4.6.0 20110126 (experimental) [trunk revision 169296]
(hppa-linux)
compiled by GNU C version 4.6.0 20110126 (experimental) [trunk revision
169296], GMP version 4.3.2, MPFR version 3.0.0-p3, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C (GCC) version 4.6.0 20110126 (experimental) [trunk revision 169296]
(hppa-linux)
compiled by GNU C version 4.6.0 20110126 (experimental) [trunk revision
169296], GMP version 4.3.2, MPFR version 3.0.0-p3, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 394c56f917a1cdcda6b767bcbf6fcebb
COLLECT_GCC_OPTIONS='-B' '/home2/dave/gcc-4.6/objdir/gcc/' '-w' '-O2' '-flto'
'-fno-builtin-abs' '-o' '/home2/dave/gcc-4.6/objdir/gcc/testsuite/gcc/abs-1.x7'
'-fdump-ipa-cgraph' '-save-temps' '-v'
 /home2/dave/gcc-4.6/objdir/gcc/as -v -W -o abs-1.o abs-1.s
GNU assembler version 2.21.51 (hppa-unknown-linux-gnu) using BFD version (GNU
Binutils) 2.21.51.20110116
COLLECT_GCC_OPTIONS='-B' '/home2/dave/gcc-4.6/objdir/gcc/' '-w' '-O2' '-flto'
'-fno-builtin-abs' '-o' '/home2/dave/gcc-4.6/objdir/gcc/testsuite/gcc/abs-1.x7'
'-fdump-ipa-cgraph' '-save-temps' '-v'
 /home2/dave/gcc-4.6/objdir/gcc/cc1 -E -quiet -v -iprefix
/home2/dave/gcc-4.6/objdir/gcc/../lib/gcc/hppa-linux/4.6.0/ -isystem
/home2/dave/gcc-4.6/objdir/gcc/include -isystem
/home2/dave/gcc-4.6/objdir/gcc/include-fixed
/home2/dave/gcc-4.6/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/abs-1-lib.c
-w -flto -fno-builtin-abs -fdump-ipa-cgraph -O2 -fpch-preprocess -o abs-1-lib.i
ignoring nonexistent directory
"/home2/dave/gcc-4.6/objdir/gcc/../lib/gcc/hppa-linux/4.6.0/include"
ignoring nonexistent directory
"/home2/dave/gcc-4.6/objdir/gcc/../lib/gcc/hppa-linux/4.6.0/include-fixed"
ignoring nonexistent directory
"/home2/dave/gcc-4.6/objdir/gcc/../lib/gcc/hppa-linux/4.6.0/../../../../hppa-

[Bug fortran/47491] [4.6 Regression] libgfortran: getpwuid_r (for GETLOG) breaks bootstrapping

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-01/msg02026.htm
   ||l

--- Comment #4 from Janne Blomqvist  2011-01-27 17:10:42 
UTC ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2011-01/msg02026.html

(In reply to comment #3)
> > --- Comment #2 from Janne Blomqvist  2011-01-27 
> > 16:10:41 UTC ---
> > Some git-grepping showed that at least libjava has in configure.ac
> >
> > AC_DEFINE(_POSIX_PTHREAD_SEMANTICS, 1, [Required define if using POSIX
> > threads])
> >
> > and in case Boehm GC is not used (which libgfortran never uses):
> >
> > AC_DEFINE(_REENTRANT, 1, [Required define if using POSIX threads])
> >
> > However, if I understand gcc/config/ correctly, _REENTRANT should be
> > automatically set for all targets that need it.
> 
> At least on Solaris (and I think on other targets as well), only with
> -pthread.

I think that's Ok. If we're not building with threads, and lack of _REENTRANT
causes the _r() functions not to be seen, gfortran falls back to the non-_r()
functions, which is no problem on a non-threaded build.

> > Also in gcc/config a few targets set 
> >
> > -D_POSIX_C_SOURCE=199506L
> >
> > (not Solaris, though). But apparently we shouldn't go and set this 
> > somewhere in
> > libgfortran? That is, at least no other library does this..
> 
> That may not provide the best guidance.  I'd rather look for autoconf
> and/or gnulib here.  On Solaris, this may not be enough: starting with
> Solaris 10, there's POSIX.1-2001 support via -D_POSIX_C_SOURCE=200112L.

The comments at

http://blogs.gnome.org/tthurman/2008/11/23/_posix_c_source/

suggests defining POSIX_C_SOURCE might not be such a good idea, so I think it's
best to avoid this.

Also, for GNU platforms

http://www.gnu.org/s/libc/manual/html_node/Feature-Test-Macros.html

seems _GNU_SOURCE is sort of a superset of POSIX_C_SOURCE and the kitchen sink.
Which is what we're using today, hopefully the AC_USE_SYSTEM_EXTENSIONS thing
is enough to make things work on other targets.

Re: [Bug lto/47274] [4.6 regression] ICE in lto_varpool_replace_node, at lto-symtab.c:306

[Jan Hubicka]

> lto1: internal compiler error: in lto_varpool_replace_node, at 
> lto-symtab.c:305

Merging should happen after unmerged files are dumped.  Perhaps they go to some 
funny place,
like /tmp?

Honza

[Bug lto/47274] [4.6 regression] ICE in lto_varpool_replace_node, at lto-symtab.c:306

[hubicka at ucw dot cz]

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

--- Comment #19 from Jan Hubicka  2011-01-27 17:16:31 
UTC ---
> lto1: internal compiler error: in lto_varpool_replace_node, at 
> lto-symtab.c:305

Merging should happen after unmerged files are dumped.  Perhaps they go to some
funny place,
like /tmp?

Honza

[Bug libfortran/47434] Wrong field width for NaN with (F0.n) formatting

[burnus at gcc dot gnu.org]

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

--- Comment #8 from Tobias Burnus  2011-01-27 
17:21:24 UTC ---
(In reply to comment #7)
> I remember the discussion when we first implemented this and we wanted the + 
> on
> Inf to be consistent with -Inf. 

Well, the following is in any case wrong:

  real :: inf
  inf = 0
  inf = 1/inf
  print "(sp,F0.2)", inf  ! SIGN=PLUS
  print "(ss,F0.2)", inf  ! SIGN=SUPPRESS
  print "(s, F0.2)", inf  ! SIGN=PROCESSOR_DEFINED
  end

The same result for "F4.2": Three times "+Inf". (Ditto for g95.)

For SIGN=SUPPRESS it should just print "Inf", whether "Inf" or "+Inf" is
correct for PROCESSOR_DEFINED is another question. For consistency with the
other compilers - and for consistency with 10.7.2.1(6), one should probably
remove the "+".

For "F4.2" also the other compilers do not seem to print a + with
sign='PROCESSOR_DEFINED' though I am not sure that I like
Intel's/pathscale's/open64's "Infi" for S and SS better. NAG and Sunf95 have "
Inf" for S/SS.


Regarding "0.00" vs ".00" with "F0.2": I do not have any real preference;
following 10.7.2.1(6) I am slightly inclined that ".00" is better.

[Bug rtl-optimization/47477] [4.6 regression] Sub-optimal mov at end of method

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2011-01-27 
17:21:04 UTC ---
Not so easily, addsi3_cc is quite specialized pattern and if we add peepholes
to help with reg1 = reg1 op reg2; reg2 = reg1 [reg1 DEAD];
I think we'd add it only for a couple of most common arithmetics ops.

Wonder whether the splitters couldn't be smarter here, when splitting a
doubleword addition see that we only care about a SImode subreg thereof.

Or, if lower-subreg.c could do something about it, optimize
(insn 10 9 11 2 (parallel [
(set (reg:DI 74)
(plus:DI (reg:DI 71)
(reg:DI 73)))
(clobber (reg:CC 17 flags))
]) pr47477.c:4 243 {*adddi3_doubleword}
 (nil))

(insn 11 10 12 2 (set (reg:SI 70)
(subreg:SI (reg:DI 74) 0)) pr47477.c:5 64 {*movsi_internal}
 (nil))
into just SImode addition.

[Bug libfortran/47493] FAIL: gfortran.fortran-torture/execute/csqrt_1.f90 compilation

[dave at hiauly1 dot hia.nrc.ca]

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

--- Comment #2 from dave at hiauly1 dot hia.nrc.ca 2011-01-27 17:27:40 UTC ---
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47493
> 
> Tobias Burnus  changed:
> 
>What|Removed |Added
> 
>  CC||burnus at gcc dot gnu.org
> 
> --- Comment #1 from Tobias Burnus  2011-01-27 
> 17:04:51 UTC ---
> > (.rodata+0x68): undefined reference to `_gfortran_specific__sqrt_r8'
> 
> Can you run:
>  nm libgfortran.a |grep _gfortran_specific__sqrt_
> on my system that gives:

dave@mx3210:~/gnu/gcc/objdir/hppa-linux-gnu/libgfortran/.libs$ nm libgfortran.a
|grep _gfortran_specific__sqrt_
 T _gfortran_specific__sqrt_r4
 T _gfortran_specific__sqrt_c4
 T _gfortran_specific__sqrt_c8

I don't fully trust the kernel on this system.  I see in config.h:

/* libm includes sqrt */
/* #undef HAVE_SQRT */

I think the configure test probably failed due to a cache management problem,
although I didn't see anything the the system log.

Dave

[Bug target/37665] invalid loop generation

[joel at gcc dot gnu.org]

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

Joel Sherrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #3 from Joel Sherrill  2011-01-27 17:28:03 
UTC ---
(In reply to comment #2)
> Joel, could you check if this bug still is present and if it affects RTEMS?
> 
> From what I can gather from looking at the asm gcc generates, this bug might 
> be
> fixed in gcc-4.5.x (rtems-4.11)

The program does run to completion now.  This was hanging m32c during RTEMS
initialization of the priority chains.  So now I should test that side of the
world.

Interesanta iespeja nopelnit naudu

[Maris]

Latus internetaa var uzpelnit sekojot saitei:

http://www.tavaveiksme.lv

Labs izklasts un video!

[Bug middle-end/45422] [4.6 Regression] compile time increases 3x.

[xinliangli at gmail dot com]

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

--- Comment #44 from davidxl  2011-01-27 17:33:42 
UTC ---
Nice triaging..

David

[Bug fortran/47491] [4.6 Regression] libgfortran: getpwuid_r (for GETLOG) breaks bootstrapping

[jb at gcc dot gnu.org]

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

--- Comment #5 from Janne Blomqvist  2011-01-27 17:34:18 
UTC ---
Author: jb
Date: Thu Jan 27 17:34:14 2011
New Revision: 169334

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169334
Log:
PR 47491 getpwuid_r() bootstrap regression on Solaris

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/config.h.in
trunk/libgfortran/configure
trunk/libgfortran/configure.ac

[Bug rtl-optimization/47477] [4.6 regression] Sub-optimal mov at end of method

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||rth at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  2011-01-27 
17:45:33 UTC ---
Alternatively, this narrowing of > word mode operations could as well be done
during tree optimizations.  I think the FE is the only place which performs
them,
as can be seen if you modify your testcase to do:
void *
add (void *a, void *b)
{
  return (void *)(__INTPTR_TYPE__) ((long long)(__INTPTR_TYPE__) a + ((long
long)(__INTPTR_TYPE__) b & ~1L));
}
instead of
void *
add (void *a, void *b)
{
  long long tmp = (long long)(__INTPTR_TYPE__) a + ((long
long)(__INTPTR_TYPE__) b & ~1L);
  return (void *)(__INTPTR_TYPE__) tmp;
}

But unfortunately we have nothing which performs this later on (gimple-fold?).

[Bug libfortran/46607] [4.6 Regression] libgfortran relocated install fails

[joseph at codesourcery dot com]

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

--- Comment #10 from joseph at codesourcery dot com  2011-01-27 17:47:12 UTC ---
On Thu, 27 Jan 2011, aoliva at gcc dot gnu.org wrote:

> This could bring an improvement for a few platforms, but it wouldn't solve the
> problme in general.  On platforms that don't support overriding e.g. DT_RPATH
> with e.g. LD_LIBRARY_PATH, the right thing to do is still to require
> prelinking.  Libtool, in an effort to offer a standard interface, has decided
> to impose the requirement that the install-time libdir must end with the 
> libdir
> specified at build time.  This is not a bug, it's a correct design decision. 

I don't see how prelinking (relinking?) relates to the relation between 
two libdir values.  What platform's shared library peculiarities allow 
installation where one libdir is a prefix of the other but not more 
general relations like those allowed by make_relative_prefix?  As far as I 
can see, it should be a straightforward generalization of any logic 
supporting adding a prefix to libdir to support also removing some initial 
directory segments first.

In fact, if you're relinking I don't see the need to care about the 
configure-time directories at all.  At build time, link only for the 
build-tree paths, if any paths need hardcoding anywhere at all; at install 
time, link only for the paths determined by the makefile variables at 
install time; at both times, disregard the paths passed to configure 
except insofar as they determine the makefile variables at install time.  
Support for removing initial segments when installing would probably be 
more of a straightforward change, however, but in any case it seems to be 
a libtool bug to me.

[Bug libfortran/47434] Wrong field width for NaN with (F0.n) formatting

[thenlich at users dot sourceforge.net]

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

--- Comment #9 from Thomas Henlich  
2011-01-27 17:55:13 UTC ---
Maybe this should be a command option, possibly defaulting to the current
behaviour unless -std=xx is given.

[Bug bootstrap/47279] Bootstrap fails in stage1 with GCC 4.6

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 CC||bergner at gcc dot gnu.org

--- Comment #2 from Peter Bergner  2011-01-27 
17:56:49 UTC ---
I just tried a default64 "make CFLAGS=-O -g" build of sources from Jan 24th
(using 2.21 binutils) and it completed with no errors.  What configure options
and binutils version are you using?

[Bug rtl-optimization/47477] [4.6 regression] Sub-optimal mov at end of method

[tony.poppleton at gmail dot com]

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

--- Comment #5 from Tony Poppleton  2011-01-27 
17:58:12 UTC ---
The modified testcase in comment #4 also fixes the original bug with redundent
push/pop of BX (as described in PR35926), so fixing this during tree
optimizations would be good.

[Bug lto/47274] [4.6 regression] ICE in lto_varpool_replace_node, at lto-symtab.c:306

[dave at hiauly1 dot hia.nrc.ca]

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

--- Comment #20 from dave at hiauly1 dot hia.nrc.ca 2011-01-27 18:06:02 UTC ---
On Thu, 27 Jan 2011, hubicka at ucw dot cz wrote:

> Merging should happen after unmerged files are dumped.  Perhaps they go to 
> some
> funny place,
> like /tmp?

They are not in /tmp.  There is one other cgraph file which I attach.

Dave

[Bug c/46620] 32-bit structures containing bitfields are not copied correctly on -O2 , x86 backend

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.01.27 18:31:06
 CC||aoliva at gcc dot gnu.org
   Target Milestone|--- |4.4.6
 Ever Confirmed|0   |1

--- Comment #3 from H.J. Lu  2011-01-27 18:31:06 
UTC ---
It was caused by revision 128908:

http://gcc.gnu.org/ml/gcc-cvs/2007-10/msg00012.html

[Bug libfortran/47493] FAIL: gfortran.fortran-torture/execute/csqrt_1.f90 compilation

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  2011-01-27 
19:01:07 UTC ---
(In reply to comment #2)
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47493
> I don't fully trust the kernel on this system.  I see in config.h:
> 
> /* libm includes sqrt */
> /* #undef HAVE_SQRT */
> 
> I think the configure test probably failed due to a cache management problem,
> although I didn't see anything the the system log.

Well, I then regard comment 0 as not a bug as I think configure is usually
reliable...

Still, the question is why the _gfortran__sqrt_c8 -> __buildin_sqrt wrapper is
needed at all and why no inlining is happening. (missed-optimization) The
latter is probably a post-4.6 item ...