[Bug c/44476] New: tclStrToD.c takes very long to compile (forever?)

[jay dot krell at cornell dot edu]

I'll probably have to debug this myself..but compiling Tcl 8.5.8's tclStrToD.c
on alphaev67-dec-osf5.1 takes an inordinately long time. I've left it running
for many minutes. Everything else in Tcl compiled fairly rapidly, just this one
file is going and going. I tried without optimizing too.


gcc -c -O  -mieee  -Wall -fPIC -I"." -I/home/jayk/src/tcl8.5.8/unix/../unix
-I/home/jayk/src/tcl8.5.8/unix/../generic
-I/home/jayk/src/tcl8.5.8/unix/../libtommath -DPACKAGE_NAME=\"tcl\"
-DPACKAGE_TARNAME=\"tcl\" -DPACKAGE_VERSION=\"8.5\" -DPACKAGE_STRING=\"tcl\
8.5\" -DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1
-DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
-DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DTCL_CFGVAL_ENCODING=\"iso8859-1\"
-DTCL_SHLIB_EXT=\".so\" -DTCL_CFG_OPTIMIZED=1 -DTCL_CFG_DEBUG=1 -DTCL_TOMMATH=1
-DMP_PREC=4 -DTCL_WIDE_INT_IS_LONG=1 -DHAVE_GETCWD=1 -DHAVE_OPENDIR=1
-DHAVE_STRTOL=1 -DHAVE_WAITPID=1 -DUSE_TERMIOS=1 -DHAVE_SYS_TIME_H=1
-DTIME_WITH_SYS_TIME=1 -DHAVE_STRUCT_TM_TM_ZONE=1 -DHAVE_TM_ZONE=1
-DHAVE_GMTIME_R=1 -DHAVE_LOCALTIME_R=1 -DHAVE_MKTIME=1 -DHAVE_TM_GMTOFF=1
-DHAVE_TIMEZONE_VAR=1 -DHAVE_STRUCT_STAT_ST_BLKSIZE=1 -DHAVE_ST_BLKSIZE=1
-Dsocklen_t=int -DHAVE_INTPTR_T=1 -DHAVE_UINTPTR_T=1 -DNO_UNION_WAIT=1
-DHAVE_SIGNED_CHAR=1 -DHAVE_LANGINFO=1 -DHAVE_CHFLAGS=1 -DHAVE_SYS_IOCTL_H=1
-DUSE_FIONBIO=1 -DTCL_UNLOAD_DLLS=1  
/home/jayk/src/tcl8.5.8/unix/../generic/tclStrToD.c


bash-4.1$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/jayk/libexec/gcc/alphaev67-dec-osf5.1/4.5.0/lto-wrapper
Target: alphaev67-dec-osf5.1
Configured with: /home/jayk/src/gcc-4.5.0/configure -disable-nls
-disable-bootstrap -with-gmp=/home/jayk -prefix=/home/jayk
Thread model: posix
gcc version 4.5.0 (GCC)


-- 
   Summary: tclStrToD.c takes very long to compile (forever?)
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jay dot krell at cornell dot edu
  GCC host triplet: alphaev67-dec-osf5.1


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

[Bug c/44476] tclStrToD.c takes very long to compile (forever?)

[jay dot krell at cornell dot edu]

--- Comment #1 from jay dot krell at cornell dot edu  2010-06-09 07:28 
---
It is hung here:
#0  0x0001206feb24 in __gmpn_invert_limb ()
#1  0x0001206fd9b0 in __gmpn_divrem_2 ()
#2  0x0001206f1f84 in __gmpn_divrem ()
#3  0x0001206d0e20 in mpfr_div ()
#4  0x0001206d27c4 in mpfr_const_pi_internal ()


I'm going to try rebuilding with gmp/mpfr/mpc in-tree (ie: with current gcc and
without assembly).
  Which doesn't work with gmp 4.3.2 for a reason I didn't debug..I'll try
5.0.1..
  I don't remember how I'd built gmp/mpfr/mpc, very possibly with native cc,
possibly with the optimized assembly.


-- 


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

[Bug bootstrap/44470] [4.6 Regression] Failed to bootstrap with - -with-arch=atom

[ubizjak at gmail dot com]

--- Comment #5 from ubizjak at gmail dot com  2010-06-09 07:46 ---
Looking into it.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ubizjak at gmail dot com
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-06-09 07:46:05
   date||


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

[Bug target/44364] Wrong code with e500 double floating point

[gcc at breakpoint dot cc]

--- Comment #37 from gcc at breakpoint dot cc  2010-06-09 07:50 ---
Created an attachment (id=20873)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20873&action=view)
this fails to compile in -O2 with the fix


-- 


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

[Bug target/44364] Wrong code with e500 double floating point

[gcc at breakpoint dot cc]

--- Comment #38 from gcc at breakpoint dot cc  2010-06-09 07:54 ---
(In reply to comment #28)
> Please bootstrap and test this addition to e500.h
> 
> /* When setting up caller-save slots (MODE == VOIDmode) ensure we
>allocate space for DFmode.  Save gprs in the correct mode too.  */
> #define HARD_REGNO_CALLER_SAVE_MODE(REGNO, NREGS, MODE) \
>   (TARGET_E500_DOUBLE && ((MODE) == VOIDmode || (MODE) == DFmode)   \
>? DFmode \
>: choose_hard_reg_mode ((REGNO), (NREGS), false))
> 

Okay. Now I found something: 

inst/bin/powerpc-linux-gnuspe-gcc extract_chmLib.i -o extract_chmLib.S -S -O2
extract_chmLib.c: In function '_extract_callback':
extract_chmLib.c:29: internal compiler error: in change_address_1, at
emit-rtl.c:1954
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

extract_chmLib.i is attached. Adding -mfloat-gprs=single which avoids using
64bit gprs for double makes this go away.


-- 


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

[Bug fortran/44477] New: Sequential I/O with END FILE: File position should be at EoF

[burnus at gcc dot gnu dot org]

Based on
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/cfb5f9dca46d5114#

After ENDFILE for non-streams, the current file position should be at the
endfile record. Thus, running the program below with NAG gives:
  READ/WRITE attempted after ENDFILE on unit 10
  Program terminated by I/O error on unit 10 (File="XXX",Formatted,Sequential)

And with Pathf95:
  A WRITE operation is invalid if the file is positioned after the end-of-file.

While with gfortran it simply runs. (Ditto for g95 and ifort.) [One could
continue to do so as extension, but one should do so knowingly.]


F2008: "9.8.3 ENDFILE statement"

"Execution of an ENDFILE statement for a file connected for sequential access
writes an endfile record as the next record of the file. The file is then
positioned after the end file record, which becomes the last record of the 
file. If the file also may be connected for direct access, only those records
before the endfile record are considered to have been written. Thus, only those
records may be read during subsequent direct access connections to the file.
   After execution of an ENDFILE statement for a file connected for sequential
access, a BACKSPACE or REWIND statement shall be used to reposition the file
prior to execution of any data transfer input/output statement or ENDFILE
statement.
   Execution of an ENDFILE statement for a file connected for stream access
causes the terminal point of the file to become equal to the current file
position. Only file storage units before the current position are considered to
have been written; thus only those file storage units may be subsequently
read. Subsequent stream output statements may be used to write further data to
the file.
   Execution of an ENDFILE statement for a file that is connected but does not
exist creates the file; if the file is connected for sequential access, it is
created prior to writing the endfile record."


!---
   OPEN(10, FILE='XXX', FORM='FORMATTED', &
 ACTION='WRITE', POSITION='REWIND')
ENDFILE(10)
  write(10,*) 'aa'
end


-- 
   Summary: Sequential I/O with END FILE: File position should be at
EoF
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug c++/44473] iterators already defined for std::vector when using std::decimal

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2010-06-09 08:27 
---
Janis, this doesn't make sense to me, and for sure happens only with decimal.
Can you have a look?


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||janis187 at us dot ibm dot
   ||com


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

[Bug libstdc++/44475] bunch of warnings of "second definition" on osf

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2010-06-09 08:32 
---
Rainer, can you help me on this? I don't even know how to categorize it, if
it's purely an ar issue or what else, I think you know this target...


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||ro at CeBiTec dot Uni-
   ||Bielefeld dot DE


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

[Bug c/44476] tclStrToD.c takes very long to compile (forever?)

[jay dot krell at cornell dot edu]

--- Comment #2 from jay dot krell at cornell dot edu  2010-06-09 08:42 
---
Two line repro, no repro with 4.3.5, hangs with 4.5.0.
I'll rebuild the compiler though.
Seem like a gmp bug.

bash-4.1$ alphaev67-dec-osf5.1-gcc-4.3.5 -c 1.c
bash-4.1$ alphaev67-dec-osf5.1-gcc-4.5.0 -c 1.c

bash-4.1$ cat 1.c
double log (double );
int xTclDoubleDigits(void) { return log(10.0); }


-- 


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

[Bug libstdc++/43838] [4.4/4.5/4.6 Regression] Incorrect output from abi::__cxa_demangle

[paolo dot carlini at oracle dot com]

--- Comment #7 from paolo dot carlini at oracle dot com  2010-06-09 08:54 
---
Non pre-processed testcase. Apparently some buffer is overflowed.

#include 

namespace abcdefgxyzzzabb
{
  class Aaa { };

  namespace klmn
  {
class Baaa { };
  }
}

namespace boost
{
  namespace tuples
  {

class null_type;

template
  struct tuple { };
  }
}

int main()
{
  int status = 0;

  const char* mangled_name
= typeid(boost::tuples::tuple).name();

  __builtin_printf("Mangled name:\n%s\n\n", mangled_name);

  const char* dem_name = abi::__cxa_demangle(mangled_name, 0, 0, &status);

  if (0 == status)
__builtin_printf("Demangled name:\n\n%s\n\n", dem_name);

  return 0;
}


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

Summary|Incorrect output from   |[4.4/4.5/4.6 Regression]
   |abi::__cxa_demangle |Incorrect output from
   ||abi::__cxa_demangle


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

[Bug target/44364] Wrong code with e500 double floating point

[harry dot he at freescale dot com]

--- Comment #39 from harry dot he at freescale dot com  2010-06-09 08:59 
---
Hi,  Kyle Moffett,
in testall.c, r9 is used by a register variable, however, in E500ABI guide,
r9 should be used for parameter passing, this test case seems not reasonable.

Harry He


-- 


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

[Bug tree-optimization/44423] [4.5/4.6 Regression] Massive performance regression in SSE code due to SRA

[jamborm at gcc dot gnu dot org]

--- Comment #11 from jamborm at gcc dot gnu dot org  2010-06-09 09:02 
---
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #8)
> > > I don't think you need flow-sensitivity.
> > > 
> > > Basically when you have only aggregate uses (as in this case)
> > 
> > Vectors are considered scalars in GCC.  That is why the solutions
> > described above work.
> > 
> > > then you only want to scalarize if the destination of the use is
> > > scalarized as well (to be able to copyprop out the aggregate copy).
> > 
> > Well, that is what I thought until someone filed PR 43846.
> 
> Hm, yes.  But there you know that
> 
>   D.2464.m[0] = D.2473_20;
>   D.2464.m[1] = D.2472_19;
>   D.2464.m[2] = D.2471_18;
>   *b_1(D) = D.2464;
> 
> D.2464 will be dead after scalarization.

If D.2464 was larger than just m, that would not necessarily be the
case and we would still want to avoid the extra copies.

However, I it is true that it would make sense to take
grp_assignment_read into account only if the whole access subtree
would end up with grp_unscalarized_data set to zero but that would
require quite a rewrite of analyze_access_subtree and would not help
in this case because grp_unscalarized_data is zero, the union is
covered by scalar replacements.

The real issue is that

>  In the particular case of the
> current bug the aggregate remains live because of the load from va.v
> which we cannot scalarize(*).

we determine this very late, in sra_modify_assign (right after the big
comment) and in the most general form this can be determined only when
we already have the whole access tree (so if we wanted to do this
during analysis, we would have to scan the function body twice).
Nevertheless, for scalar accesses that have scalar sub-accesses this
is always true and it can be easily detected and so we can simply
disallow them, like I wrote in comment #7.  And disallow them always,
since otherwise it would be easy to _add_ stuff to the function that
is causing trouble now so that any heuristics is confused and decides
to produce replacements.

I'll submit a patch in a while.

> 
> (*) we can scalarize this particular case if you manage to build a
> proper constructor from the elements - but that's probably a bit
> involved.
> 

Well, I don't think I want to implement that... but I am curious,
would that actually lead to better (or even different) code if I
placed something like that into the loop?  And I also thought that in
gimple, constructors only could have invariants in them.


-- 


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

[Bug tree-optimization/44423] [4.5/4.6 Regression] Massive performance regression in SSE code due to SRA

[jamborm at gcc dot gnu dot org]

--- Comment #12 from jamborm at gcc dot gnu dot org  2010-06-09 09:05 
---
(In reply to comment #11)
> >   D.2464.m[0] = D.2473_20;
> >   D.2464.m[1] = D.2472_19;
> >   D.2464.m[2] = D.2471_18;
> >   *b_1(D) = D.2464;
> > 
> > D.2464 will be dead after scalarization.
> 
> If D.2464 was larger than just m, that would not necessarily be the
> case and we would still want to avoid the extra copies.
> 

Of course this would be true only if the last assignment was 

*b_1(D) = D.2464.m;

but the argument is the same.


-- 


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

[Bug tree-optimization/44462] Redundant looping pure functions whose return value is dead are not optimized out

[rguenther at suse dot de]

--- Comment #3 from rguenther at suse dot de  2010-06-09 09:10 ---
Subject: Re:  Redundant looping pure functions
 whose return value is dead are not optimized out

On Tue, 8 Jun 2010, pinskia at gcc dot gnu dot org wrote:

> --- Comment #2 from pinskia at gcc dot gnu dot org  2010-06-08 20:10 
> ---
> >Why do we remove register LHS in DCE again? 
> 
> Because it reduces the amount of garbage produced by expand :).

Which means the expander could drop it ...

Richard.


-- 


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

[Bug target/34734] attribute((progmem)) not handled properly in C++ for AVRs

[mschulze at ivs dot cs dot ovgu dot de]

--- Comment #4 from mschulze at ivs dot cs dot ovgu dot de  2010-06-09 
09:16 ---
I found a way to place data in program memory for C++ without producing the
annoying warnings. The trick is omiting __attribute__((__progmem__)) and
instead always use __attribute__((section(".progmem.something"))) for placing
your data into a special section beginning with ".progmem.". I tested this with
different avr-g++ compiler versions (3.4.4, 4.1.1, 4.2.1, 4.3.3, 4.4.0, and
4.4.3), and it always results in the desired behavior.

Example:
[mschu...@teeth tst]$ cat progmem.cpp 
static char __attribute((section(".progmem.something"))) str[]="program memory
data";

const char* test() {
return str;
}
[mschu...@teeth tst]$ /usr/bin/avr-g++ -Wall -mmcu=atmega1281 -c progmem.cpp 
[mschu...@teeth tst]$ /usr/bin/avr-g++ --version
avr-g++ (GCC) 4.3.3
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[mschu...@teeth tst]$ 

Regards,
Michael


-- 

mschulze at ivs dot cs dot ovgu dot de changed:

   What|Removed |Added

 CC||mschulze at ivs dot cs dot
   ||ovgu dot de


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

[Bug libstdc++/44413] inefficient code for std::string::compare on x86-64

[paolo at gcc dot gnu dot org]

--- Comment #6 from paolo at gcc dot gnu dot org  2010-06-09 09:16 ---
Subject: Bug 44413

Author: paolo
Date: Wed Jun  9 09:15:51 2010
New Revision: 160456

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160456
Log:
2010-06-09  Paolo Carlini  

PR libstdc++/44413
* include/ext/vstring_util.h (__vstring_utility<>::_S_compare):
Simplify, just return -1, 0, 1.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/ext/vstring_util.h


-- 


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

[Bug target/44364] Wrong code with e500 double floating point

[harry dot he at freescale dot com]

--- Comment #40 from harry dot he at freescale dot com  2010-06-09 09:23 
---
with my toolchain (From CodeSourcery, 4.4-78), o1test gives correct behavior
with built-in flags(-te500v2), but wrong behaviors with "-fcaller-saves -O
-fno-omit-frame-pointer -fno-dce -fno-split-wide-types". Results are same even
after I rebuilt the toolchain with the patch to e500.h.

is there any tricks here? 


-- 


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

[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6

[iains at gcc dot gnu dot org]

--- Comment #75 from iains at gcc dot gnu dot org  2010-06-09 09:27 ---
Subject: Bug 43170

Author: iains
Date: Wed Jun  9 09:27:04 2010
New Revision: 160457

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

config:
PR bootstrap/43170
* tls.m4 (GCC_CHECK_TLS): Add volatile qualifier to the test 
references.  Move the main () test reference ahead of 
pthread_create().  Add a comment to explain the requirements
of the test.
libgomp:
PR bootstrap/43170
* configure: Regenerate.
libjava:
PR bootstrap/43170
* configure: Regenerate.
libmudflap:
PR bootstrap/43170
* configure: Regenerate.
libstdc++-v3:
PR bootstrap/43170
* configure: Regenerate.


Modified:
trunk/config/ChangeLog
trunk/config/tls.m4
trunk/libgomp/ChangeLog
trunk/libgomp/configure
trunk/libjava/ChangeLog
trunk/libjava/configure
trunk/libmudflap/ChangeLog
trunk/libmudflap/configure
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/configure


-- 


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

[Bug c/44476] tclStrToD.c takes very long to compile (forever?)

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-06-09 09:29 ---
Please report it to mpfr developers.


-- 


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

[Bug target/44474] GCC inserts redundant "test" instruction due to incorrect clobber

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
  Component|c   |target
 GCC target triplet||i?86-*-* x86_64-*-*


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

[Bug bootstrap/44470] [4.6 Regression] Failed to bootstrap with - -with-arch=atom

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0


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

[Bug other/43838] [4.4/4.5/4.6 Regression] Incorrect output from abi::__cxa_demangle

[paolo dot carlini at oracle dot com]

--- Comment #8 from paolo dot carlini at oracle dot com  2010-06-09 09:37 
---
Recategorizing as other (like 42230)... and maybe HJ is interested in playing a
bit with this one too.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||hjl dot tools at gmail dot
   ||com
  Component|libstdc++   |other


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

[Bug fastjar/28359] fastjar directory traversal problem

[jakub at gcc dot gnu dot org]

--- Comment #19 from jakub at gcc dot gnu dot org  2010-06-09 09:39 ---
Created an attachment (id=20874)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20874&action=view)
CVE-2010-0831.patch

Just for the record, the patch that went in leaves fastjar still vulnerable.
The main issue is that tmp_buff isn't the current directory component, but
current directory component with all previous directory component, so the
.. and . tests will match only for the first component.

https://launchpad.net/bugs/540575
has some patch, but it is very ugly and inefficient.


-- 


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

[Bug c/44478] New: -Wunused- but-set-variable is incredible noisy in kernel builds

[andi-gcc at firstfloor dot org]

When building a Linux kernel the new default of having
-Wunused-but-set-variable is incredibly noisy in kernel build. I get hundreds
of new warnings from that.

I looked at some of the circumstances and it's typically

int var = VALUE;

#ifdef SYMBOL
if (do something)
  var = other value
#endif

with SYMBOL being undefined in this build.

I don't think it's feasible to avoid the warning short of turning it off.
I suspect other code bases will have the same problem.
Can the warning be removed from -Wall please?


-- 
   Summary: -Wunused- but-set-variable is incredible noisy in kernel
builds
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andi-gcc at firstfloor dot org
  GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux


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

[Bug c/44478] -Wunused- but-set-variable is incredible noisy in kernel builds

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2010-06-09 09:49 
---
I'm sure you are right, but I don't understand your explanation: even when
SYMBOL
is undefined, why no code actually uses (roughly speaking, reads) var? That's
the point of the warning and your example doesn't seem to shed any special
light on that.


-- 


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

[Bug c/44478] -Wunused- but-set-variable is incredible noisy in kernel builds

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-06-09 09:53 ---
The warning is useful and can find (and already found) several real bugs e.g.
in gcc itself.  Icc has similar warning.
If kernel has lots of useless code like that and doesn't wish to use this
warning, it can add -Wno-unused-but-set-{variable,parameter} to CFLAGS it uses.

Note that in the snippet you mentioned -Wunused would warn always, no matter
whether SYMBOL is defined or not.  When it is not defined, var is unused (also
warned with 4.5 and earlier), when it is defined, var is only set but never
used.

I guess what you really mean is that kernel has lots of snippets that set some
variable to some value and then only conditionally (in #ifdef guarded code)
uses it.


-- 


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

[Bug c/44478] -Wunused- but-set-variable is incredible noisy in kernel builds

[andi-gcc at firstfloor dot org]

--- Comment #3 from andi-gcc at firstfloor dot org  2010-06-09 10:13 ---
Sorry my example was not very good.

Anyways this typically happens with #ifdefs, so the some ifdef path
is actually using the variable, it's just not enabled in the current build.
In theory the ifdefs could be put around the variables too, but
it would increase the ifdef frequency a lot.

Another case i've also seen is to use it as a dummy output variable of inline
assembler, where the assembler is in a macro and it's sometimes used
and sometimes not.


-- 


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

[Bug rtl-optimization/43332] valgrind warns about using uninitialized variable with -fsched-pressure -fschedule-insns

[zsojka at seznam dot cz]

--- Comment #7 from zsojka at seznam dot cz  2010-06-09 10:14 ---
I have just finished bootstrap of r160198 with valgrind checking, the problem
is no longer reproducible there. I am sorry for the delay, make check with
valgrind checking takes about a month there (1.3GHz), bootstrap about a week...


-- 


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

[Bug fortran/43040] Wrong decl for mathbuiltins -> wrong code with LTO

[fxcoudert at gcc dot gnu dot org]

--- Comment #7 from fxcoudert at gcc dot gnu dot org  2010-06-09 10:18 
---
Subject: Bug 43040

Author: fxcoudert
Date: Wed Jun  9 10:17:56 2010
New Revision: 160459

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160459
Log:
PR fortran/43040
* f95-lang.c (gfc_init_builtin_functions): Remove comment.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/f95-lang.c


-- 


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

[Bug fortran/43040] Wrong decl for mathbuiltins -> wrong code with LTO

[fxcoudert at gcc dot gnu dot org]

--- Comment #8 from fxcoudert at gcc dot gnu dot org  2010-06-09 10:20 
---
Checked that it is not an issue.


-- 

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

[Bug c++/44473] iterators already defined for std::vector when using std::decimal

[redi at gcc dot gnu dot org]

--- Comment #4 from redi at gcc dot gnu dot org  2010-06-09 10:22 ---
(From update of attachment 20871)
attachment's mimetype changed to text/plain


-- 

redi at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #20871|application/octet-stream|text/plain
  mime type||


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

[Bug tree-optimization/44462] Redundant looping pure functions whose return value is dead are not optimized out

[hubicka at ucw dot cz]

--- Comment #4 from hubicka at ucw dot cz  2010-06-09 10:29 ---
Subject: Re:  Redundant looping pure functions
whose return value is dead are not optimized out

> > >Why do we remove register LHS in DCE again? 
> > 
> > Because it reduces the amount of garbage produced by expand :).
> 
> Which means the expander could drop it ...

This won't save us from not optimizing out functions returning void.  They can
be looping pure too (most of sanity checks are)

Honza


-- 


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

[Bug bootstrap/44432] [boot with C++] configure does not check presence of host C++ compiler

[amylaar at gcc dot gnu dot org]

--- Comment #2 from amylaar at gcc dot gnu dot org  2010-06-09 10:32 ---
Subject: Bug 44432

Author: amylaar
Date: Wed Jun  9 10:32:23 2010
New Revision: 160460

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160460
Log:
PR bootstrap/44432
* configure.ac: Before using ZW_PROG_COMPILER_DEPENDENCIES for C++,
check that C++ compiler works.
* configure: Regenerate.

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


-- 


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

[Bug testsuite/42843] --enable-build-with-cxx plugin tests fail

[amylaar at gcc dot gnu dot org]

--- Comment #4 from amylaar at gcc dot gnu dot org  2010-06-09 10:40 ---
Subject: Bug 42843

Author: amylaar
Date: Wed Jun  9 10:40:28 2010
New Revision: 160461

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160461
Log:
gcc:
PR testsuite/42843
* gcc-plugin.h (int plugin_is_GPL_compatible): Declare as extern "C".
* doc/plugins.texi (Plugin license check): Update information
on type of plugin_is_GPL_compatible.
* Makefile.in (PLUGINCC): Define as $(COMPILER).
(PLUGINCFLAGS): Define as $(COMPILER_FLAGS).
gcc/testsuite:
PR testsuite/42843
* gcc.dg/plugin/selfassign.c (pass_warn_self_assign): Use enumerator
TV_NONE to initialize tv_id field.
* g++.dg/plugin/selfassign.c (pass_warn_self_assign): Likewise.
* gcc.dg/plugin/one_time_plugin.c (one_pass): Likewise.
* g++.dg/plugin/dumb_plugin.c (pass_dumb_plugin_example): Likewise.
Include toplev.h .
* gcc.dg/plugin/finish_unit_plugin.c: Include cgraph.h.
* g++.dg/plugin/attribute_plugin.c: Include toplev.h and plugin.h .
* g++.dg/plugin/pragma_plugin.c: Include toplev.h .

Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/doc/plugins.texi
trunk/gcc/gcc-plugin.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/plugin/attribute_plugin.c
trunk/gcc/testsuite/g++.dg/plugin/dumb_plugin.c
trunk/gcc/testsuite/g++.dg/plugin/pragma_plugin.c
trunk/gcc/testsuite/g++.dg/plugin/selfassign.c
trunk/gcc/testsuite/gcc.dg/plugin/finish_unit_plugin.c
trunk/gcc/testsuite/gcc.dg/plugin/one_time_plugin.c
trunk/gcc/testsuite/gcc.dg/plugin/selfassign.c


-- 


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

[Bug bootstrap/44432] [boot with C++] configure does not check presence of host C++ compiler

[amylaar at gcc dot gnu dot org]

--- Comment #3 from amylaar at gcc dot gnu dot org  2010-06-09 10:47 ---
Fixed in trunk by revision 160460.


-- 

amylaar at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||4.6.0
 Resolution||FIXED


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

[Bug testsuite/42843] --enable-build-with-cxx plugin tests fail

[amylaar at gcc dot gnu dot org]

--- Comment #5 from amylaar at gcc dot gnu dot org  2010-06-09 10:49 ---
Fixed in trunk by revision 160461.


-- 

amylaar at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to fail|4.5.0 4.6.0 |4.5.0
  Known to work||4.6.0
 Resolution||FIXED


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

[Bug c/44478] -Wunused- but-set-variable is incredible noisy in kernel builds

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-06-09 10:52 ---
We don't warn on
void foo (void)
{
  int dummy;
  asm ("" : "=r" (dummy));
}
- the use in the asm is considered as a use, not just set.


-- 


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

[Bug lto/44464] ICE during linux kernel whopr build

[andi-gcc at firstfloor dot org]

--- Comment #4 from andi-gcc at firstfloor dot org  2010-06-09 10:55 ---
I was told that the whopr link step would inherit the optimization
flags from the build step. Is that not true?

Here's a reduced test case with only a single input file (reduced too)

gcc46 -O2 -fwhopr -c igmp.mini.i
gcc46 -r -fwhopr igmp.mini.o


-- 


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

[Bug lto/44464] ICE during linux kernel whopr build

[andi-gcc at firstfloor dot org]

--- Comment #5 from andi-gcc at firstfloor dot org  2010-06-09 10:56 ---
Created an attachment (id=20875)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20875&action=view)
reduced input file


-- 


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

[Bug tree-optimization/44393] [4.5/4.6 Regression] ICE: verify_ssa failed: no immediate_use list with -Os -ftree-loop-distribution

[zsojka at seznam dot cz]

--- Comment #5 from zsojka at seznam dot cz  2010-06-09 11:02 ---
The testcase also fails when it is changed to:

...
{
  extern void *bar(void) __attribute__((malloc));
  int **pp = bar(), *p = bar();
...

so there isn't any access through NULL pointer.


-- 


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

[Bug c/44478] -Wunused- but-set-variable is incredible noisy in kernel builds

[andi-gcc at firstfloor dot org]

--- Comment #5 from andi-gcc at firstfloor dot org  2010-06-09 11:08 ---
Hmm yes there was another temporary and a inline inbetween

unsigned inlinefunc(void)
{
   unsigned var;
   asm(" ... " : "=r" (var));
   return var;
}

#define macro(x,y)
{ 
unsigned var = inlinefunc();
x = var;
y = var >> 16;
};

caller macro(x,y)  y is just a dummy


-- 


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

[Bug tree-optimization/16427] dead 0 memset not optimized away

[andi-gcc at firstfloor dot org]

--- Comment #3 from andi-gcc at firstfloor dot org  2010-06-09 11:09 ---
Jakub, for this example: how would you suggest to work around this warning?


-- 


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

[Bug fastjar/28359] fastjar directory traversal problem

[marcus at jet dot franken dot de]

--- Comment #20 from marcus at jet dot franken dot de  2010-06-09 11:20 
---
Jakubs patch looks good to me.


-- 


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

[Bug tree-optimization/44423] [4.5/4.6 Regression] Massive performance regression in SSE code due to SRA

[jamborm at gcc dot gnu dot org]

--- Comment #13 from jamborm at gcc dot gnu dot org  2010-06-09 11:20 
---
Subject: Bug 44423

Author: jamborm
Date: Wed Jun  9 11:20:03 2010
New Revision: 160462

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160462
Log:
2010-06-09  Martin Jambor  

PR tree-optimization/44423
* tree-sra.c (dump_access): Dump also grp_assignment_read.
(analyze_access_subtree): Pass negative allow_replacements to children
if the current type is scalar.

* testsuite/gcc.dg/tree-ssa/pr44423.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr44423.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-sra.c


-- 


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

[Bug regression/40886] [4.3/4.4 Regression] No loop counter reversal for simple loops anymore

[andi-gcc at firstfloor dot org]

--- Comment #16 from andi-gcc at firstfloor dot org  2010-06-09 11:21 
---
I don't need a backport to 4.4 and I double checked it works as expected
in gcc 4.5. Closing.


-- 

andi-gcc at firstfloor dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug lto/44464] ICE during linux kernel whopr build

[andi-gcc at firstfloor dot org]

-- 

andi-gcc at firstfloor dot org changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED


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

[Bug rtl-optimization/44479] New: false dependencies are computed after vectorization

[roy dot 1rosen at gmail dot com]

When compiling function:
void xxx(short* __restrict__ a, short* __restrict__ b)
{
   int i;
   for (i = 0; i < 8; i++)
   {
   a[i] = b[i];
   }
}

before sched2 we have:
(note 13 12 14 3 [bb 3] NOTE_INSN_BASIC_BLOCK)

(insn 14 13 15 3 ./a.c:6 (set (reg:SI 2 cx [orig:106 *vect_p.14_18 ] [106])
(mem:SI (reg/v/f:SI 1 dx [orig:103 b ] [103]) [2 *vect_p.14_18+0 S4
A32])) 44 {*movsi_1} (expr_list:REG_EQUIV (mem:SI (reg/v/f:SI 1 dx [orig:103 b
] [103]) [2 *vect_p.14_18+0 S4 A32])
(nil)))

(insn 15 14 18 3 ./a.c:6 (set (mem:SI (reg/v/f:SI 0 ax [orig:102 a ] [102]) [2
*vect_p.18_24+0 S4 A32])
(reg:SI 2 cx [orig:106 *vect_p.14_18 ] [106])) 44 {*movsi_1}
(expr_list:REG_DEAD (reg:SI 2 cx [orig:106 *vect_p.14_18 ] [106])
(nil)))

(insn 18 15 19 3 ./a.c:6 (set (reg:SI 2 cx [orig:107 *vect_p.22_11 ] [107])
(mem:SI (plus:SI (reg/v/f:SI 1 dx [orig:103 b ] [103])
(const_int 4 [0x4])) [2 *vect_p.22_11+0 S4 A32])) 44 {*movsi_1}
(expr_list:REG_EQUIV (mem:SI (plus:SI (reg/v/f:SI 1 dx [orig:103 b ] [103])
(const_int 4 [0x4])) [2 *vect_p.22_11+0 S4 A32])
(nil)))

(insn 19 18 20 3 ./a.c:6 (set (mem:SI (plus:SI (reg/v/f:SI 0 ax [orig:102 a ]
[102])
(const_int 4 [0x4])) [2 *vect_p.27_12+0 S4 A32])
(reg:SI 2 cx [orig:107 *vect_p.22_11 ] [107])) 44 {*movsi_1}
(expr_list:REG_DEAD (reg:SI 2 cx [orig:107 *vect_p.22_11 ] [107])
(nil)))

insn 15 is a store and 18 is a load from a different location (two different
restrict pointers). These insns should not have a dependency between them but
we can see in sched2 that they do have:
;;   ==
;;   -- basic block 3 from 14 to 62 -- after reload
;;   ==

;;   --- forward dependences: 

;;   --- Region Dependences --- b 3 bb 0
;;  insn  codebb   dep  prio  cost   reservation
;;    --   ---       ---
;;   1444 3 018 4   decodern,p2 : 62 25 24 23 19 18 15
;;   1544 3 114 1   decoder0,(p4+p3): 62 61 24 22
18
;;   1844 3 214 4   decodern,p2 : 62 24 22 19
;;   1944 3 210 1   decoder0,(p4+p3): 62 61 22
;;   2244 3 310 4   decodern,p2 : 62 24 23
;;   2344 3 2 6 1   decoder0,(p4+p3): 62 61
;;   2444 3 410 4   decodern,p2 : 62 25
;;   2544 3 2 6 1   decoder0,(p4+p3): 62 61
;;   6141 3 4 6 3   decoder0,(p2+(p0|p1))   : 62
;;   62   477 3 9 6 6   decoder0:

Using built-in specs.
COLLECT_GCC=./xgcc
Target: i386-elf-linux
Configured with: ../gcc-4.6-20100605/configure --target=i386-elf-linux
--enable-languages=c
Thread model: posix
gcc version 4.6.0 20100605 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-O3' '-fsched-verbose=10' '-fno-ivopts' '-fdump-rtl-all'
'-v' '-save-temps' '-mtune=i386' '-march=i386'
 cc1 -E -quiet -v -iprefix ./../lib/gcc/i386-elf-linux/4.6.0/ ./a.c -mtune=i386
-march=i386 -fsched-verbose=10 -fno-ivopts -fdump-rtl-all -O3 -fpch-preprocess
-o a.i
ignoring nonexistent directory "./../lib/gcc/i386-elf-linux/4.6.0/include"
ignoring nonexistent directory
"./../lib/gcc/i386-elf-linux/4.6.0/include-fixed"
ignoring nonexistent directory
"./../lib/gcc/i386-elf-linux/4.6.0/../../../../i386-elf-linux/sys-include"
ignoring nonexistent directory
"./../lib/gcc/i386-elf-linux/4.6.0/../../../../i386-elf-linux/include"
ignoring nonexistent directory
"./../lib/gcc/../../lib/gcc/i386-elf-linux/4.6.0/include"
ignoring nonexistent directory
"./../lib/gcc/../../lib/gcc/i386-elf-linux/4.6.0/include-fixed"
ignoring nonexistent directory
"./../lib/gcc/../../lib/gcc/i386-elf-linux/4.6.0/../../../../i386-elf-linux/sys-include"
ignoring nonexistent directory
"./../lib/gcc/../../lib/gcc/i386-elf-linux/4.6.0/../../../../i386-elf-linux/include"
#include "..." search starts here:
#include <...> search starts here:
End of search list.
COLLECT_GCC_OPTIONS='-O3' '-fsched-verbose=10' '-fno-ivopts' '-fdump-rtl-all'
'-v' '-save-temps' '-mtune=i386' '-march=i386'
 cc1 -fpreprocessed a.i -quiet -dumpbase a.c -mtune=i386 -march=i386 -auxbase a
-O3 -version -fsched-verbose=10 -fno-ivopts -fdump-rtl-all -o a.s
GNU C (GCC) version 4.6.0 20100605 (experimental) (i386-elf-linux)
compiled by GNU C version 4.1.2 20080704 (Red Hat 4.1.2-44), GMP
version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C (GCC) version 4.6.0 20100605 (experimental) (i386-elf-linux)
compiled by GNU C version 4.1.2 20080704 (Red Hat 4.1.2-44), GMP
version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 70c36ceb949c29da0fad8309ce635380
COLLECT_

[Bug rtl-optimization/44479] false dependencies are computed after vectorization

[roy dot 1rosen at gmail dot com]

--- Comment #1 from roy dot 1rosen at gmail dot com  2010-06-09 11:28 
---
Created an attachment (id=20876)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20876&action=view)
preprocessed file


-- 


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

[Bug c/44478] -Wunused- but-set-variable is incredible noisy in kernel builds

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2010-06-09 11:36 ---
Then it has nothing to do with the asm.
If the macro is widely used and very often sets a var that isn't used, all
you can do is add (void) cast to shut the warning up.
(void) (y = var >> 16);
in this case.


-- 


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

[Bug bootstrap/44299] Bootstrap broken for cygwin and mingw targets

[ktietz at gcc dot gnu dot org]

--- Comment #5 from ktietz at gcc dot gnu dot org  2010-06-09 11:53 ---
Fixed by patch at revision 159965.


-- 

ktietz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug rtl-optimization/44479] false dependencies are computed after vectorization

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-06-09 11:56 ---
I will have a look at some point.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-06-09 11:56:12
   date||


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

[Bug regression/40886] [4.3/4.4 Regression] No loop counter reversal for simple loops anymore

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail|4.0.0   |4.0.0 4.3.5 4.4.3
   Target Milestone|4.3.6   |4.5.0


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

[Bug tree-optimization/16427] dead memset not optimized away

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2010-06-09 11:59 ---
It's now optimized by RTL DSE but we keep the stack allocated.

Re-confirmed on the tree-level.  Should be easy to extend DSE to handle this.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-10-22 22:17:10 |2010-06-09 11:59:50
   date||
Summary|dead 0 memset not optimized |dead memset not optimized
   |away|away


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

[Bug fortran/43685] libgfortran: Consider using __int128

[fxcoudert at gcc dot gnu dot org]

--- Comment #1 from fxcoudert at gcc dot gnu dot org  2010-06-09 12:01 
---
I don't understand what you mean by that: currently, we have the following
typedefs on platforms which support a 128-bit int type:

  typedef __int128_t GFC_INTEGER_16;
  typedef __uint128_t GFC_UINTEGER_16;

I don't think it changes anything to put __int128 instead of __int128_t. This
is a special case anyway, because other kinds use the stdint.h name: int8_t,
int16_t, int32_t and int64_t.


-- 

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

[Bug tree-optimization/44423] [4.5/4.6 Regression] Massive performance regression in SSE code due to SRA

[martin at mpa-garching dot mpg dot de]

--- Comment #14 from martin at mpa-garching dot mpg dot de  2010-06-09 
12:06 ---
SSE performance is fine again, thanks a lot!

One more question, if that's OK...
Depending on ARRSZ the testcase uses wildly varying amounts of CPU time; it's
about half a second for ARRSZ=1024, but almost 10 seconds for ARRSZ=20 on my
machine, which is extremely strange because the operation count is the same in
both cases. I suspect that something weird is happening with respect to the
cache and prefetching. Should I open another PR for this?


-- 


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

[Bug fortran/43710] suspicious string comparisons

[fxcoudert at gcc dot gnu dot org]

--- Comment #3 from fxcoudert at gcc dot gnu dot org  2010-06-09 12:07 
---
Hey, I actually have the answer to this one: yes, it is intended as is, and
not, it is a bit more complicated that Jerry says.

We maintain a hash table of identifiers, so that when we have multiple times
the same string, it's always allocated only once. See how gfc_get_string works,
especially the comment at the top:

/* Given printf-like arguments, return a stable version of the result string. 

   We already have a working, optimized string hashing table in the form of
   the identifier table.  Reusing this table is likely not to be wasted, 
   since if the function name makes it to the gimple output of the frontend,
   we'll have to create the identifier anyway.  */


The other, extra-nice benefits of these are 1. we do not have to compare
strings, but simply pointers; 2. we don't have to worry about releasing memory
on a per-case basis.

As such, I'm closing this PR. If you think the analysis is incorrect, please
reopen.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug lto/44464] ICE during linux kernel whopr build

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2010-06-09 12:08 ---
(In reply to comment #4)
> I was told that the whopr link step would inherit the optimization
> flags from the build step. Is that not true?

That's not true.

> Here's a reduced test case with only a single input file (reduced too)
> 
> gcc46 -O2 -fwhopr -c igmp.mini.i
> gcc46 -r -fwhopr igmp.mini.o

Thanks.

Confirmed (also with -flto).

Program received signal SIGSEGV, Segmentation fault.
0x00a196e8 in var_map_base_init (map=0x16479c0)
at /space/rguenther/src/svn/trunk/gcc/tree-ssa-live.c:87
87if (!ann->base_var_processed)
(gdb) p ann
$1 = (var_ann_t) 0x0

probably not too hard to track down.  The decl is a PARM_DECL and not
registered with referenced vars.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-06-09 12:08:51
   date||


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

[Bug lto/44464] ICE during linux kernel whopr build

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2010-06-09 12:15 ---
Actually - we seem to get IPA SRA parm repacements done but the original
parameter SSA names are not released.

(gdb) call debug_function (cfun->decl, 0)
igmp_mc_get_next ( * ISRA.14, struct ip_mc_list * ISRA.15)
{
  struct ip_mc_list * im;

(gdb) call debug_generic_expr ($5)
im_1

Martin - can you have a look?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug bootstrap/44470] [4.6 Regression] Failed to bootstrap with - -with-arch=atom

[ubizjak at gmail dot com]

--- Comment #6 from ubizjak at gmail dot com  2010-06-09 12:15 ---
Following patch is also needed to fix conditional splitting (it does not fix
original uncovered problem where BLOCK_FOR_INSN returns null):

Index: i386.md
===
--- i386.md (revision 160445)
+++ i386.md (working copy)
@@ -6087,8 +6087,15 @@
   switch (get_attr_type (insn))
 {
 case TYPE_LEA:
-  return "#";
+  if (reload_completed && ix86_lea_for_add_ok (PLUS, insn, operands))
+return "#";

+  gcc_assert (rtx_equal_p (operands[0], operands[2]));
+  if (x86_maybe_negate_const_int (&operands[1], mode))
+return "sub{}\t{%1, %0|%0, %1}";
+
+  return "add{}\t{%1, %0|%0, %1}";
+
 case TYPE_INCDEC:
   gcc_assert (rtx_equal_p (operands[0], operands[1]));
   if (operands[2] == const1_rtx)
@@ -6138,8 +6145,14 @@
   switch (get_attr_type (insn))
 {
 case TYPE_LEA:
-  return "#";
+  if (reload_completed && ix86_lea_for_add_ok (PLUS, insn, operands))
+return "#";

+  if (x86_maybe_negate_const_int (&operands[1], SImode))
+return "sub{l}\t{%1, %k0|%k0, %1}";
+
+  return "add{l}\t{%1, %k0|%k0, %1}";
+
 case TYPE_INCDEC:
   if (operands[2] == const1_rtx)
 return "inc{l}\t%k0";
@@ -6222,8 +6235,15 @@
   switch (get_attr_type (insn))
 {
 case TYPE_LEA:
-  return "#";
+  if (reload_completed && ix86_lea_for_add_ok (PLUS, insn, operands))
+return "#";

+  gcc_assert (rtx_equal_p (operands[0], operands[2]));
+  if (x86_maybe_negate_const_int (&operands[1], HImode))
+return "sub{w}\t{%1, %0|%0, %1}";
+
+  return "add{w}\t{%1, %0|%0, %1}";
+
 case TYPE_INCDEC:
   gcc_assert (rtx_equal_p (operands[0], operands[1]));
   if (operands[2] == const1_rtx)
@@ -6313,8 +6333,22 @@
   switch (get_attr_type (insn))
 {
 case TYPE_LEA:
-  return "#";
+  if (reload_completed && ix86_lea_for_add_ok (PLUS, insn, operands))
+return "#";

+  gcc_assert (rtx_equal_p (operands[0], operands[2]));
+  if (x86_maybe_negate_const_int (&operands[1], QImode))
+   {
+ if (widen)
+   return "sub{l}\t{%1, %k0|%k0, %1}";
+ else
+   return "sub{b}\t{%1, %0|%0, %1}";
+   }
+  if (widen)
+return "add{l}\t{%k1, %k0|%k0, %k1}";
+  else
+return "add{b}\t{%1, %0|%0, %1}";
+
 case TYPE_INCDEC:
   gcc_assert (rtx_equal_p (operands[0], operands[1]));
   if (operands[2] == const1_rtx)


-- 


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

[Bug lto/44464] ICE during linux kernel whopr build

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2010-06-09 12:16 ---
CC'ing martin even.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu dot
   ||org


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

[Bug lto/44464] ICE during linux kernel whopr build

[andi-gcc at firstfloor dot org]

--- Comment #9 from andi-gcc at firstfloor dot org  2010-06-09 12:16 ---
Unfortunate.  Fixing that in the makefiles would be major effort for all the -f
and -m  flags, which sometimes vary by target.

I thought LTO was designed to minimize makefile changes? 


-- 


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

[Bug lto/44464] ICE during linux kernel whopr build

[andi-gcc at firstfloor dot org]

--- Comment #10 from andi-gcc at firstfloor dot org  2010-06-09 12:18 
---
The tree input that leads to the NULL annotation is a "error_mark"


-- 


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

[Bug fortran/43685] libgfortran: Consider using __int128

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2010-06-09 12:41 ---
Close as WONTFIX.

The int128 changes still do not offer to enter the integer directly (instead of
using 123L with "<<" shifts)

And one issue was fixed as part of
  http://gcc.gnu.org/viewcvs?view=revision&revision=157407
(in libgfortran.h).


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug bootstrap/44469] [4.5/4.6 Regression] internal compiler error: in fixup_reorder_chain, at cfglayout.c:797

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-06-09 12:51 ---
I guess for empty bbs with no successor where the predecessor ends in an
conditional jump without side-effects try_optimize_cfg can't do just
delete_basic_block, but needs to call some function to actually adjust the
conditional jump into unconditional.  Perhaps try_redirect_by_replacing_jump or
something similar.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu dot
   ||org


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

[Bug lto/44464] ICE during linux kernel whopr build

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2010-06-09 13:01 
---
(In reply to comment #10)
> The tree input that leads to the NULL annotation is a "error_mark"

Not for me.


-- 


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

[Bug lto/44464] ICE during linux kernel whopr build

[rguenth at gcc dot gnu dot org]

--- Comment #12 from rguenth at gcc dot gnu dot org  2010-06-09 13:03 
---
(In reply to comment #9)
> Unfortunate.  Fixing that in the makefiles would be major effort for all the 
> -f
> and -m  flags, which sometimes vary by target.
> 
> I thought LTO was designed to minimize makefile changes? 

Yes.

But you want to be able to have different optimizations at compile/link time.

Also we would need to start on how to automagically merge different settings
at compile-time ...

Well - option handling is still an awkward area.


-- 


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

[Bug target/44364] Wrong code with e500 double floating point

[amodra at gmail dot com]

--- Comment #41 from amodra at gmail dot com  2010-06-09 13:26 ---
Created an attachment (id=20877)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20877&action=view)
e500.h and caller-save.c patch

The ICE in #38 is due to a bug in caller-save.c


-- 


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

[Bug lto/44464] ICE during linux kernel whopr build

[andi-gcc at firstfloor dot org]

--- Comment #13 from andi-gcc at firstfloor dot org  2010-06-09 13:35 
---
What happens then when some files need different options that other files? 
This sounds more and more like a showstopper if you're right.
I was not prepared to redesign the Makefiles


-- 


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

[Bug libstdc++/44480] New: Linear performance of begin() in unordered associative containers

[joaquin at tid dot es]

The current implementation of begin() for unordered associative containers is
linear (a search for the first non-empty bucket is executed each time begin()
is called), yet the C++0x drafts specifiy that this should be constant (23.3.1,
table 93). Boost.Unordered, for instance, caches the first non-empty bucket on
insertion/deletion to meet the O(1) begin() requirement.


-- 
   Summary: Linear performance of begin() in unordered associative
containers
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joaquin at tid dot es


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

[Bug middle-end/44453] [4.6 Regression] Revision 160380 caused g++.dg/torture/pr32304.C

[hubicka at gcc dot gnu dot org]

--- Comment #2 from hubicka at gcc dot gnu dot org  2010-06-09 13:39 ---
The following patch http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00692.html
should fix the problem.  


-- 


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

[Bug lto/44464] ICE during linux kernel whopr build

[andi-gcc at firstfloor dot org]

--- Comment #14 from andi-gcc at firstfloor dot org  2010-06-09 13:42 
---
I found this code in lto.c which seems to disagree:

/* Read the options saved from each file in the command line.  Called
   from lang_hooks.post_options which is called by process_options
   right before all the options are used to initialize the compiler.
   This assumes that decode_options has already run, so the
   num_in_fnames and in_fnames are properly set.

   Note that this assumes that all the files had been compiled with
   the same options, which is not a good assumption.  In general,
   options ought to be read from all the files in the set and merged.
   However, it is still unclear what the merge rules should be.  */

void
lto_read_all_file_options (void)

Still remains to be seen if it DTRT though (e.g. for -pg vs no -pg)


-- 


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

[Bug rtl-optimization/44460] [4.6 Regression] r160380 breaks libjava bootstrap on *-apple-darwin*

[hubicka at gcc dot gnu dot org]

--- Comment #5 from hubicka at gcc dot gnu dot org  2010-06-09 13:43 ---
The following http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00692.html
It definitly avoids the ICE, but it would be nice to know if libstdc++
testsuite passes.

Honza


-- 


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

[Bug rtl-optimization/44460] [4.6 Regression] r160380 breaks libjava bootstrap on *-apple-darwin*

[dominiq at lps dot ens dot fr]

--- Comment #6 from dominiq at lps dot ens dot fr  2010-06-09 13:50 ---
> The following http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00692.html
> It definitly avoids the ICE, but it would be nice to know if libstdc++
> testsuite passes.

It does fix the bootstrap failure. I am currently regtesting (at gfortran -m32)
and should have the results for libstdc++ in a couple of hours.


-- 


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

[Bug target/44364] Wrong code with e500 double floating point

[gcc at breakpoint dot cc]

--- Comment #42 from gcc at breakpoint dot cc  2010-06-09 13:52 ---
(In reply to comment #41)
> The ICE in #38 is due to a bug in caller-save.c

Thank you for the very quick fix.


-- 


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

[Bug lto/44464] ICE during linux kernel whopr build

[andi-gcc at firstfloor dot org]

--- Comment #15 from andi-gcc at firstfloor dot org  2010-06-09 13:55 
---
Ok seems it does not do what I want:

   FIXME lto.  Currently the scheme is limited in that only the
   options saved on the first object file (f1.o) are read back during
   the link step.  This means that the options used to compile f1.o
   will be applied to ALL the object files in the final link step.
   More work needs to be done to implement a merging and validation
   mechanism, as this will not be enough for all cases.  */

Anyways OT for this bug, maybe needs a new one?


-- 


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

[Bug bootstrap/44469] [4.5/4.6 Regression] internal compiler error: in fixup_reorder_chain, at cfglayout.c:797

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-06-09 13:55 ---
There are more issues:
1) cleanup_barriers seems to do weird things with these empty bbs from
__builtin_unreachable (), I guess it shouldn't reorder anything if prev is a
LABEL_P
2) the reason why this compiles fine on x86_64 seems to be in different bb
reordering.  On arm the empty bb is reordered after the condjump, which means
its label is deleted by /* Remove code labels no longer used.  */ in
try_optimize_cfg and then the block is trivially empty.  On x86_64 we don't
ICE, but generate useless code:
movl(%rdi), %eax
testl   %eax, %eax
je  .L2
cmpl$1, %eax
jne .L3
movq%rdi, %rsi
.L2:
xorl%eax, %eax
cmpb$0, (%rsi)
sete%al
ret
.L3:
.cfi_endproc

I'd say we shouldn't try to delete just trivially_empty_bb_p's, but also ones
that before the bb note also have labels and after it nothing or only
DEBUG_INSNs, but we should delete only if we actually succeed adjusting the
jump insn at the end of the earlier block.


-- 


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

[Bug rtl-optimization/44481] New: __builtin_parity() causes ICE in trunc_int_for_mode()

[rainy6144 at gmail dot com]

When compiling the following program with -O2, gcc gives an ICE "internal
compiler error: in trunc_int_for_mode, at explow.c:56".

Versions affected:
gcc (GCC) 4.4.3 20100127 (Red Hat 4.4.3-4)
gcc (GCC) 4.5.1 20100521 (prerelease)


static inline unsigned parity(unsigned x)
{
  return (unsigned) __builtin_parity(x);
}

unsigned f(unsigned rpoly)
{
  return parity(rpoly & 1) ^ parity(rpoly & 6);
}



-- 
   Summary: __builtin_parity() causes ICE in trunc_int_for_mode()
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rainy6144 at gmail 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=44481

[Bug libstdc++/44413] inefficient code for std::string::compare on x86-64

[paolo at gcc dot gnu dot org]

--- Comment #7 from paolo at gcc dot gnu dot org  2010-06-09 14:02 ---
Subject: Bug 44413

Author: paolo
Date: Wed Jun  9 14:02:03 2010
New Revision: 160476

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160476
Log:
2010-06-09  Paolo Carlini  

Revert:
2010-06-09  Paolo Carlini  

PR libstdc++/44413
* include/ext/vstring_util.h (__vstring_utility<>::_S_compare):
Simplify, just return -1, 0, 1.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/ext/vstring_util.h


-- 


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

[Bug target/44364] Wrong code with e500 double floating point

[mark dot workman at acm dot org]

--- Comment #43 from mark dot workman at acm dot org  2010-06-09 14:07 
---
(In reply to comment #39)
> Hi,  Kyle Moffett,
> in testall.c, r9 is used by a register variable, however, in E500ABI 
> guide,
> r9 should be used for parameter passing, this test case seems not reasonable.
> 
> Harry He

Please note that this testcase was removed by Kyle (see comment #12) and that
neither the original testcase (tc-lossings-float.c) nor the trimmed testcase
(tc-lossings-float-3.c) make such explicit use of particular registers.  Thus,
it does appear that it is the compiler that is making the register assignments
in question.

Cheers,
  Mark

> 


-- 

mark dot workman at acm dot org changed:

   What|Removed |Added

 CC||mark dot workman at acm dot
   ||org


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

[Bug bootstrap/44470] [4.6 Regression] Failed to bootstrap with - -with-arch=atom

[hjl dot tools at gmail dot com]

--- Comment #7 from hjl dot tools at gmail dot com  2010-06-09 14:13 ---
(In reply to comment #4)
> (In reply to comment #1)
> > It may be broken by revision 160394:
> > 
> > http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg00307.html
> 
> The add->lea transformation doesn't even trigger in this testcase... You still
> have normal add instruction with a flags clobber up to and including sched2
> pass.
> 
> Later, compilation breaks in machine reorg pass with:
> 
> Program received signal SIGSEGV, Segmentation fault.
> distance_non_agu_define (code=, insn=0x718c2750, 
> operands=0x1298aa0) at ../../gcc-svn/trunk/gcc/config/i386/i386.c:13826
> 13826 if (insn != BB_HEAD (bb))
> 
> (gdb) l
> 13821 basic_block bb = BLOCK_FOR_INSN (insn);
> 13822 int distance = 0;
> 13823 df_ref *def_rec;
> 13824 enum attr_type insn_type;
> 13825   
> 13826 if (insn != BB_HEAD (bb))
> 13827   {
> 13828 rtx prev = PREV_INSN (insn);
> 13829 while (prev && distance < LEA_SEARCH_THRESHOLD)
> 13830   {
> 
> It looks to me that bb is NULL, which isn't a good sign anyway.

ix86_lea_for_add_ok shouldn't be call during final scan when
we have already looked all add patterns and converted them
to lea if necessary.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

   Target Milestone|4.6.0   |---


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

[Bug fortran/44211] [OOP] ICE with TBP of pointer component of derived type array

[janus at gcc dot gnu dot org]

--- Comment #4 from janus at gcc dot gnu dot org  2010-06-09 14:15 ---
Subject: Bug 44211

Author: janus
Date: Wed Jun  9 14:14:08 2010
New Revision: 160478

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160478
Log:
2010-06-09  Janus Weil  

PR fortran/44211
* resolve.c (resolve_typebound_function,resolve_typebound_subroutine):
Resolve references.


2010-06-09  Janus Weil  

PR fortran/44211
* gfortran.dg/typebound_call_14.f03: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/typebound_call_14.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/44067] internal compiler error: in rs6000_split_multireg_move, at config/rs6000/rs6000.c:16713

[bergner at gcc dot gnu dot org]

--- Comment #12 from bergner at gcc dot gnu dot org  2010-06-09 14:15 
---
Subject: Bug 44067

Author: bergner
Date: Wed Jun  9 14:15:11 2010
New Revision: 160479

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160479
Log:
Backport from mainline:

2010-06-09  Edmar Wienskoski  

PR target/44067
* config/rs6000/rs6000.md (DIFD): Do not split dpfp values for
e500v2 target.

Modified:
branches/ibm/gcc-4_4-branch/gcc/ChangeLog.ibm
branches/ibm/gcc-4_4-branch/gcc/config/rs6000/rs6000.md


-- 


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

[Bug fortran/44211] [OOP] ICE with TBP of pointer component of derived type array

[janus at gcc dot gnu dot org]

--- Comment #5 from janus at gcc dot gnu dot org  2010-06-09 14:16 ---
Fixed with r160478. Closing.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/44470] [4.6 Regression] Failed to bootstrap with - -with-arch=atom

[hjl dot tools at gmail dot com]

--- Comment #8 from hjl dot tools at gmail dot com  2010-06-09 14:16 ---
Whatever we do, we need to preserve Atom add->lea optimization.


-- 


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

Re: [Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants

[Dodji Seketeli]

"manu at gcc dot gnu dot org"  writes:

> I find this output a bit confusing. I find clang's output clearer
> http://clang.llvm.org/diagnostics.html.

I guess you are talking about the "automatic macro expansion" section of
that link?

>
> In fact, clang's output actually follows more closely what GCC already does
> with templates/inline functions.

Well, this is obviously a first step in that direction. I'd be more
interested in knowing what I can do at *this* step :-)

But yes, once I can bootstrap all the FEs with the macro location
tracking infrastructure in place with no regression, I guess I'll focus
more on the user visible output.

[Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants

[dodji at redhat dot com]

--- Comment #27 from dodji at gcc dot gnu dot org  2010-06-09 14:23 ---
Subject: Re:  __extension__ keyword doesn't suppress warning on LL or ULL
constants

"manu at gcc dot gnu dot org"  writes:

> I find this output a bit confusing. I find clang's output clearer
> http://clang.llvm.org/diagnostics.html.

I guess you are talking about the "automatic macro expansion" section of
that link?

>
> In fact, clang's output actually follows more closely what GCC already does
> with templates/inline functions.

Well, this is obviously a first step in that direction. I'd be more
interested in knowing what I can do at *this* step :-)

But yes, once I can bootstrap all the FEs with the macro location
tracking infrastructure in place with no regression, I guess I'll focus
more on the user visible output.


-- 


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

Re: [Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants

[Dodji Seketeli]

"manu at gcc dot gnu dot org"  writes:

>> 
>> $ ./cc1 -quiet test.c
>> While expanding macro OPERATE at test.c:2:8
>> While expanding macro SHIFTL at test.c:5:14
>> While expanding macro MULT2 at test.c:8:3
>> test.c: In function 'g':
>> test.c:13:3: error: invalid operands to binary << (have 'double' and 'int')


> Also, what are the column numbers pointing to? They don't make sense
> to me.

About this line:
>> While expanding macro OPERATE at test.c:2:8

which is about:
#define OPERATE(OPRD1, OPRT, OPRD2) \
 OPRD1 OPRT OPRD2;

Column 8 is the starting column of the OPRT token.

About this line:
>> While expanding macro SHIFTL at test.c:5:14

which is about:
#define SHIFTL(A,B) \
  OPERATE (A,<<,B)

Column 14 is the starting column of the '<<' token.

About this line:
>> While expanding macro MULT2 at test.c:8:3

which is about:
#define MULT2(A) \
  SHIFTL (A,1)

Column 3 is the starting column of the 'SHIFT' token.

> In any case, this is a huge step forward! Thanks for working on this. It would
> be an important marketing point if you manage to complete it for GCC
> 4.6.

No problem ;) Not sure it'll get into 4.6, but I'll try.

[Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants

[dodji at redhat dot com]

--- Comment #28 from dodji at gcc dot gnu dot org  2010-06-09 14:32 ---
Subject: Re:  __extension__ keyword doesn't suppress warning on LL or ULL
constants

"manu at gcc dot gnu dot org"  writes:

>> 
>> $ ./cc1 -quiet test.c
>> While expanding macro OPERATE at test.c:2:8
>> While expanding macro SHIFTL at test.c:5:14
>> While expanding macro MULT2 at test.c:8:3
>> test.c: In function 'g':
>> test.c:13:3: error: invalid operands to binary << (have 'double' and 'int')


> Also, what are the column numbers pointing to? They don't make sense
> to me.

About this line:
>> While expanding macro OPERATE at test.c:2:8

which is about:
#define OPERATE(OPRD1, OPRT, OPRD2) \
 OPRD1 OPRT OPRD2;

Column 8 is the starting column of the OPRT token.

About this line:
>> While expanding macro SHIFTL at test.c:5:14

which is about:
#define SHIFTL(A,B) \
  OPERATE (A,<<,B)

Column 14 is the starting column of the '<<' token.

About this line:
>> While expanding macro MULT2 at test.c:8:3

which is about:
#define MULT2(A) \
  SHIFTL (A,1)

Column 3 is the starting column of the 'SHIFT' token.

> In any case, this is a huge step forward! Thanks for working on this. It would
> be an important marketing point if you manage to complete it for GCC
> 4.6.

No problem ;) Not sure it'll get into 4.6, but I'll try.


-- 


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

[Bug tree-optimization/44258] [4.5/4.6 Regression] possible SRA wrong-code generation.

[jamborm at gcc dot gnu dot org]

--- Comment #11 from jamborm at gcc dot gnu dot org  2010-06-09 14:43 
---
OK, I have found the bug and I admit it is rather embarrassing.  I'll
submit a patch soon.


-- 

jamborm at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jamborm at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-05-30 17:04:29 |2010-06-09 14:43:08
   date||


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

[Bug fortran/44465] [OOP] ICE with polymorphic object oriented example

[burnus at gcc dot gnu dot org]

--- Comment #5 from burnus at gcc dot gnu dot org  2010-06-09 15:07 ---
With the patch for PR 44211 (just committed to the 4.6 trunk), the program
compiles and the output is:

  shape
  In generic_shape_assign
  x =   10
  y =   20
  circle
  In generic_shape_assign
  x =  100
  y =  200
  radius =  300
  rectangle
  In generic_shape_assign
  x = 1000
  y = 2000
  width = 3000
  height = 4000

Thanks again for the bug report!


-- 


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

[Bug c++/44366] [C++0x] g++ crashes when declaring a lambda expression using a typedef'd decltype.

[jason at gcc dot gnu dot org]

--- Comment #9 from jason at gcc dot gnu dot org  2010-06-09 15:12 ---
Subject: Bug 44366

Author: jason
Date: Wed Jun  9 15:11:42 2010
New Revision: 160483

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160483
Log:
PR c++/44366
* g++.dg/cpp0x/decltype23.C: Move to...
* g++.dg/diagnostic/parm1.C: ...here, and remove decltype.

Added:
trunk/gcc/testsuite/g++.dg/diagnostic/
trunk/gcc/testsuite/g++.dg/diagnostic/parm1.C
  - copied, changed from r160478,
trunk/gcc/testsuite/g++.dg/cpp0x/decltype23.C
Removed:
trunk/gcc/testsuite/g++.dg/cpp0x/decltype23.C
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug libstdc++/44413] inefficient code for std::string::compare on x86-64

[paolo dot carlini at oracle dot com]

--- Comment #8 from paolo dot carlini at oracle dot com  2010-06-09 15:13 
---
I gave this more thought, and to be honest, focusing on 64-bit targets - I
think that for 32-bit targets what we have is already good enough - I have no
idea how to substantively improve the code, given that the length of a string
is a 64-bit unsigned and the return type must be an int. Jon?


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

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


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

[Bug fortran/44465] [OOP] ICE with polymorphic object oriented example

[ian at rhymneyconsulting dot co dot uk]

--- Comment #6 from ian at rhymneyconsulting dot co dot uk  2010-06-09 
15:20 ---
Subject: RE:  [OOP] ICE with polymorphic object oriented example

Thanks very much for fixing it.

Cheers

Ian

> -Original Message-
> From: burnus at gcc dot gnu dot org [mailto:gcc-bugzi...@gcc.gnu.org]
> Sent: 09 June 2010 16:07
> To: i...@rhymneyconsulting.co.uk
> Subject: [Bug fortran/44465] [OOP] ICE with polymorphic object oriented
> example
> 
> 
> 
> --- Comment #5 from burnus at gcc dot gnu dot org  2010-06-09 15:07
> ---
> With the patch for PR 44211 (just committed to the 4.6 trunk), the
> program
> compiles and the output is:
> 
>   shape
>   In generic_shape_assign
>   x =   10
>   y =   20
>   circle
>   In generic_shape_assign
>   x =  100
>   y =  200
>   radius =  300
>   rectangle
>   In generic_shape_assign
>   x = 1000
>   y = 2000
>   width = 3000
>   height = 4000
> 
> Thanks again for the bug report!
> 
> 
> --
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44465
> 
> --- 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=44465

[Bug objc++/27249] FAIL: obj-c++.dg/encode-8.mm execution test

[mrs at gcc dot gnu dot org]

-- 

mrs at gcc dot gnu dot org changed:

   What|Removed |Added

 CC|mikestump at comcast dot net|
   Target Milestone|--- |4.6.0


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

[Bug libstdc++/44461] __cxa_end_cleanup ends up in wrong section i.e. not in .text

[paolo at gcc dot gnu dot org]

--- Comment #5 from paolo at gcc dot gnu dot org  2010-06-09 15:35 ---
Subject: Bug 44461

Author: paolo
Date: Wed Jun  9 15:34:45 2010
New Revision: 160488

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160488
Log:
2010-06-09  Khem Raj  

PR libstdc++/44461
* libsupc++/eh_arm.cc (__cxa_end_cleanup): Use .pushsection/.popsection
to emit inline assembly into .text section.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/libsupc++/eh_arm.cc


-- 


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

[Bug libstdc++/44461] __cxa_end_cleanup ends up in wrong section i.e. not in .text

[paolo dot carlini at oracle dot com]

--- Comment #6 from paolo dot carlini at oracle dot com  2010-06-09 15:36 
---
Fixed.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

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


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

[Bug libstdc++/44480] [C++0x] Linear performance of begin() in unordered associative containers

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2010-06-09 15:46 
---
I see. Looks like Matt essentially followed in the reference implementation the
legacy HP / SGI, linear, way of computing begin().  I'm asking his opinion on
this, whether we are also going to use caching or something else maybe...
Thanks.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-06-09 15:46:53
   date||


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

[Bug libstdc++/44461] __cxa_end_cleanup ends up in wrong section i.e. not in .text

[raj dot khem at gmail dot com]

--- Comment #7 from raj dot khem at gmail dot com  2010-06-09 15:48 ---
thanks Paolo, we would need this patch on 4.5 branch as well.


-- 


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

[Bug libstdc++/44461] __cxa_end_cleanup ends up in wrong section i.e. not in .text

[paolo dot carlini at oracle dot com]

--- Comment #8 from paolo dot carlini at oracle dot com  2010-06-09 15:52 
---
In general, only if it's a regression. And nobody said that explicitly so far.
If you want to argue for having it anyway in 4_5-branch, please speak on the
mailing list and ask permission to the release managers.


-- 


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

[Bug c/44482] New: some warnings in libgcc amd64-darwin 4.5.0

[jay dot krell at cornell dot edu]

note this is later bootstrap stages so shouldn't matter what the bootstrap
compiler was (assuming it compiled the compiler reasonably correctly)

For the missing prototypes, I suggest you just put them right there:

void Foo(void);
void Foo(void)
{
  ...
}


for the uninitialized I suggest just initializing them and not worrying about
it.


For the cast I already posted a patch adding const.


The shifts are buried in macros and I didn't look so not sure.
Personally if I want (a << 32) I'd just do ((a << 31) << 1)..or, uh, just 0,
but that may or may not be relevant here.


_darwin10_Unwind_FindEnclosingFunction I didn't look at.


I'll maybe come back to this myself, hopefully that's not an abuse of gcc
bugzilla (esp. given that this is not using -disable-bootstrap so not a
terrible bug report).


I'm surprised -Werror isn't used here.
I suggest -Wmissing-prototypes only apply to callers not implementers? I
realize it is a tradeoff, because you want to make sure there is a prototype
somewhere for callers (though not really for libgcc math helpers...) and
forcing the implementor to pull that in is a reasonable way to make that so.


/home/jayk/src/gcc-4.5.0/libgcc/../gcc/unwind-dw2.c: In function
'uw_init_context_1':
/home/jayk/src/gcc-4.5.0/libgcc/../gcc/unwind-dw2.c:1452:5: warning: missing
initializer
/home/jayk/src/gcc-4.5.0/libgcc/../gcc/unwind-dw2.c:1452:5: warning: (near
initialization for 'once_regsizes.__reserved')



/Users/jay/src/gcc-4.5.0/libgcc/../gcc/unwind-dw2-fde-darwin.c: At top level:
/Users/jay/src/gcc-4.5.0/libgcc/../gcc/unwind-dw2-fde-darwin.c:279:1: warning:
no previous prototype for '_darwin10_Unwind_FindEnclosingFunction'


/Users/jay/obj/gcc/./gcc/xgcc -B/Users/jay/obj/gcc/./gcc/
-B/Users/jay/amd64-darwin/bin/ -B/Users/jay/amd64-darwin/lib/ -isystem
/Users/jay/amd64-darwin/include -isystem /Users/jay/amd64-darwin/sys-include   
-g -O2 -m32 -O2  -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include  -fPIC -pipe -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED   -I. -I. -I../../.././gcc
-I/Users/jay/src/gcc-4.5.0/libgcc -I/Users/jay/src/gcc-4.5.0/libgcc/.
-I/Users/jay/src/gcc-4.5.0/libgcc/../gcc
-I/Users/jay/src/gcc-4.5.0/libgcc/../include  -DHAVE_CC_TLS -DUSE_EMUTLS
-Wno-missing-prototypes -Wno-type-limits -o fixunstfsi_s.o -MT fixunstfsi_s.o
-MD -MP -MF fixunstfsi_s.dep -DSHARED -fexceptions -c
/Users/jay/src/gcc-4.5.0/libgcc/../gcc/config/soft-fp/fixunstfsi.c
/Users/jay/src/gcc-4.5.0/libgcc/../gcc/config/soft-fp/fixunstfsi.c: In function
'__fixunstfsi':
/Users/jay/src/gcc-4.5.0/libgcc/../gcc/config/soft-fp/fixunstfsi.c:42:3:
warning: left shift count >= width of type



/Users/jay/obj/gcc/./gcc/xgcc -B/Users/jay/obj/gcc/./gcc/
-B/Users/jay/amd64-darwin/bin/ -B/Users/jay/amd64-darwin/lib/ -isystem
/Users/jay/amd64-darwin/include -isystem /Users/jay/amd64-darwin/sys-include   
-g -O2 -m32 -O2  -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include  -fPIC -pipe -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED   -I. -I. -I../../.././gcc
-I/Users/jay/src/gcc-4.5.0/libgcc -I/Users/jay/src/gcc-4.5.0/libgcc/.
-I/Users/jay/src/gcc-4.5.0/libgcc/../gcc
-I/Users/jay/src/gcc-4.5.0/libgcc/../include  -DHAVE_CC_TLS -DUSE_EMUTLS
-Wno-missing-prototypes -Wno-type-limits -o multf3_s.o -MT multf3_s.o -MD -MP
-MF multf3_s.dep -DSHARED -fexceptions -c
/Users/jay/src/gcc-4.5.0/libgcc/../gcc/config/soft-fp/multf3.c
/Users/jay/src/gcc-4.5.0/libgcc/../gcc/config/soft-fp/multf3.c: In function
'__multf3':
/Users/jay/src/gcc-4.5.0/libgcc/../gcc/config/soft-fp/multf3.c:38:1: warning:
'R_e' may be used uninitialized in this function



/Users/jay/obj/gcc/./gcc/xgcc -B/Users/jay/obj/gcc/./gcc/
-B/Users/jay/amd64-darwin/bin/ -B/Users/jay/amd64-darwin/lib/ -isystem
/Users/jay/amd64-darwin/include -isystem /Users/jay/amd64-darwin/sys-include   
-g -O2 -O2  -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include  -fPIC -pipe -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED   -I. -I. -I../.././gcc
-I/Users/jay/src/gcc-4.5.0/libgcc -I/Users/jay/src/gcc-4.5.0/libgcc/.
-I/Users/jay/src/gcc-4.5.0/libgcc/../gcc
-I/Users/jay/src/gcc-4.5.0/libgcc/../include  -DHAVE_CC_TLS -DUSE_EMUTLS -o
darwin-64_s.o -MT darwin-64_s.o -MD -MP -MF darwin-64_s.dep -DSHARED
-fexceptions -c /Users/jay/src/gcc-4.5.0/libgcc/../gcc/config/darwin-64.c
/Users/jay/obj/gcc/./gcc/xgcc -B/Users/jay/obj/gcc/./gcc/
-B/Users/jay/amd64-darwin/bin/ -B/Users/jay/amd64-darwin/lib/ -isystem
/Users/jay/amd64-darwin/include -isystem /Users/jay/amd64-darwin/sys-include   
-g -O2 -O2  -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include  -fPIC -pipe -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
-D__GCC_FL