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

[iains at gcc dot gnu dot org]

--- Comment #58 from iains at gcc dot gnu dot org  2010-06-03 07:57 ---
(In reply to comment #57)
> (In reply to comment #46)

> Other than that, you guys manage to write a lot about this but still not 
> answer
> all questions (both of which makes it unattractive for others to look at a 
> PR).
>  What about missing volatile for comment #39, as in
> 
>   static int * volatile a_in_other_thread;

sorry, I missed that.
That correction does _not_ make the tests behave deterministically on darwin10.
The tests behave deterministically with/without it on darwin9 (pass at O0, fail
> O0).


-- 


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

[Bug c++/2972] -Wuninitialized could warn about uninitialized member variable usage in constructors

[manu at gcc dot gnu dot org]

--- Comment #10 from manu at gcc dot gnu dot org  2010-06-03 08:47 ---
(In reply to comment #9)
> I've been experimenting with this patch, which warns if there is a missing
> mem-initializer for a scalar.
> 
> It gives a false positive for cases were the member is assigned to in the
> constructor body, or otherwise initialized before use, but it's a start, and
> has already helped me find some missing mem-initializers in real code.

Nice but I am afraid there may be too many false positives. And what is
different between this and the -Weffc++ warning given just below it?


> 
> +case OPT_Wmeminit:
> +  warn_meminit = value;
> +  break;
> +

You do not need this. This is handled automatically when you defined Var in the
opt files.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

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

[jakub at gcc dot gnu dot org]

--- Comment #59 from jakub at gcc dot gnu dot org  2010-06-03 09:10 ---
Why would be volatile needed?  pthread_join returning guarantees that the other
thread's thread function finished, and the variable is only written in that
thread, there is no data race on it.


-- 


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

[Bug c++/2972] -Wuninitialized could warn about uninitialized member variable usage in constructors

[jwakely dot gcc at gmail dot com]

--- Comment #11 from jwakely dot gcc at gmail dot com  2010-06-03 09:18 
---
(In reply to comment #10)
> (In reply to comment #9)
> > I've been experimenting with this patch, which warns if there is a missing
> > mem-initializer for a scalar.
> > 
> > It gives a false positive for cases were the member is assigned to in the
> > constructor body, or otherwise initialized before use, but it's a start, and
> > has already helped me find some missing mem-initializers in real code.
> 
> Nice but I am afraid there may be too many false positives.

Yes, I'm not proposing it in that state. It's just an experiment but has been
useful for me already.

> And what is
> different between this and the -Weffc++ warning given just below it?

-Weffc++ also enables dozens of other warnings, most of which I don't find
useful.  It is about good style, not dangerous code, and I don't like the
compiler to enforce style.

In this specific case, the Weffc++ warning complains if *any* member has no
mem-initializer. I only care about POD members which will be uninitialized, I
don't want to add a mem-initializer for e.g. a std::string member which has a
default constructor.

> > +case OPT_Wmeminit:
> > +  warn_meminit = value;
> > +  break;
> > +
> 
> You do not need this. This is handled automatically when you defined Var in 
> the
> opt files.

Ah OK, thanks!


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[iains at gcc dot gnu dot org]

--- Comment #32 from iains at gcc dot gnu dot org  2010-06-03 09:21 ---
(In reply to comment #31)
> The latest proposed patch triggers one additional g++ tls failure...
> 
> FAIL: g++.dg/tls/init-2.C (test for excess errors)

this test is not enabled for emutls at present;
yes, I know it fails - but - if you look at the error output from g++, you will
see that there are two confusing and contradictory error messages - so I
suspect that the FE is trying to build a constructor for something that has
been declared an error...

Still, this should be on the TODO ;-)


-- 


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

[Bug c++/2972] -Wuninitialized could warn about uninitialized member variable usage in constructors

[jwakely dot gcc at gmail dot com]

--- Comment #12 from jwakely dot gcc at gmail dot com  2010-06-03 09:27 
---
Apart from the false positives, another problem is that the check for
layout_pod_type_p is not right.  An empty class is a POD but doesn't need
initialising.


-- 


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

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

[jamborm at gcc dot gnu dot org]

--- Comment #4 from jamborm at gcc dot gnu dot org  2010-06-03 09:30 ---
Unfortunately the preprocessed source from comment #1 seems to be
damaged, I get loads of errors like "error: stray '\336' in program."
Can you please re-upload it?  Thanks.


-- 


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

[Bug c++/2972] -Wuninitialized could warn about uninitialized member variable usage in constructors

[paolo dot carlini at oracle dot com]

--- Comment #13 from paolo dot carlini at oracle dot com  2010-06-03 10:16 
---
About -Weffc++, we also have a PR (16166) about splitting it... Not that I
think we should really do that - adding a dozen of -Weffc++-type warnings - but
I believe it would be a good idea to finally resolve one way or the other all
those long standing -Weffc++ PRs (we have 5 or 6)... If you ask my opinion, we
should probably *not* split the option, and instead reduce *a lot* the false
positives for the various warnings, even if that means adding false negatives.


-- 


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

[Bug bootstrap/44397] New: [4.6 Regression] mangled line number section in bootstrap

[tkoenig at gcc dot gnu dot org]

Booting with rev. 160214:

gcc   -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-Wold-style-definition -Wc++-compat -fno-common  -DHAVE_CONFIG_H  -o cc1-dummy
c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o
c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o
c-semantics.o c-ppoutput.o c-cppbuiltin.o c-objc-common.o c-dump.o c-pch.o
c-parser.o i386-c.o c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o
c-ada-spec.o \
  dummy-checksum.o main.o tree-browser.o libbackend.a
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a  
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a  -lcloog  -lppl_c -lppl
-lgmpxx -L/usr/local//lib -lmpc -lmpfr -lgmp -rdynamic -ldl  -L../zlib -lz
-lelf
/usr/bin/ld: Dwarf Error: mangled line number section.
libbackend.a(ipa-reference.o): In function
`ipa_reference_write_optimization_summary':
ipa-reference.c:(.text+0x28825): undefined reference to
`lto_varpool_encoder_size'
collect2: ld gab 1 als Ende-Status zurück
make[3]: *** [cc1-dummy] Fehler 1
rm gfdl.pod cpp.pod gcc.pod gcov.pod fsf-funding.pod
make[3]: Leaving directory `/home/ig25/Gcc/trunk-bin/gcc'
make[2]: *** [all-stage1-gcc] Fehler 2
make[2]: Leaving directory `/home/ig25/Gcc/trunk-bin'
make[1]: *** [stage1-bubble] Fehler 2
make[1]: Leaving directory `/home/ig25/Gcc/trunk-bin'
make: *** [all] Fehler 2

This is on x86_64-unknown-linux-gnu, the building compiler is

g...@linux-fd1f:~/Gcc/trunk> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/ig25/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../trunk/configure --prefix=/home/ig25
--enable-languages=c,fortran --with-mpc=/usr/local/
Thread model: posix
gcc version 4.6.0 20100528 (experimental) (GCC)

This is on OpenSuse 11.2.


-- 
   Summary: [4.6 Regression] mangled line number section in
bootstrap
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
  GCC host triplet: x86_64-unknown-linux-gnu


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

[Bug bootstrap/44397] [4.6 Regression] mangled line number section in bootstrap

[tkoenig at gcc dot gnu dot org]

-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0


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

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

[rwild at gcc dot gnu dot org]

--- Comment #60 from rwild at gcc dot gnu dot org  2010-06-03 10:33 ---
(In reply to comment #59)
> Why would be volatile needed?  pthread_join returning guarantees that the 
> other
> thread's thread function finished, and the variable is only written in that
> thread, there is no data race on it.

Does pthread_join imply a memory barrier?  IOW, why can the read of
a_in_other_thread not be reordered before that?
If I'm missing something obvious here, thanks for clarifying.

Is this bug just a dupe of PR 44132 now?


-- 


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

[Bug lto/44398] New: lto1: internal compiler error: Segmentation fault

[bero at arklinux dot org]

Probably introduced by the fix for bug 44385, given it happens in the same
place and removing -fuse-linker-plugin "fixes" it again: With gcc 4.5.1 rev
160157, linking Qt's moc with -flto -fuse-linker-plugin results in

g++ -Wl,-rpath-link,/usr/src/ark/BUILD/qt/lib -m64 -O2 -fomit-frame-pointer
-fweb -frename-registers
-Wl,-O2,-z,combreloc,-z,relro,--enable-new-dtags,--hash-style=gnu -g -flto
-fuse-linker-plugin -Wl,-rpath,/usr/lib64/qt4-embedded/lib
-Wl,-rpath,/usr/lib64/qt4-embedded/lib -flto -fuse-linker-plugin
-fwhole-program -o ../../../bin/moc release-static/moc.o
release-static/preprocessor.o release-static/generator.o
release-static/parser.o release-static/token.o release-static/main.o   
-L/usr/src/ark/BUILD/qt/src/tools/bootstrap -lbootstrap -lz 
lto1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: g++ returned 1 exit status
/usr/bin/ld: fatal error: lto-wrapper failed
collect2: ld returned 1 exit status


I couldn't get gdb to produce relevant output for this, so I'm attaching what
ltrace -f has to say just before the crash.


-- 
   Summary: lto1: internal compiler error: Segmentation fault
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bero at arklinux dot org
 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=44398

[Bug lto/44398] lto1: internal compiler error: Segmentation fault

[bero at arklinux dot org]

--- Comment #1 from bero at arklinux dot org  2010-06-03 10:44 ---
Created an attachment (id=20816)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20816&action=view)
ltrace output


-- 


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

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

[jakub at gcc dot gnu dot org]

--- Comment #61 from jakub at gcc dot gnu dot org  2010-06-03 10:47 ---
Of course pthread_join implies all outstanding memory stores of the dead thread
complete before pthread_join returns.  And, pthread_join is a non-inlined
function call, a_in_other_thread is a global variable, so the compiler has to
assume the pthread_join call can modify it.


-- 


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

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

[iains at gcc dot gnu dot org]

--- Comment #62 from iains at gcc dot gnu dot org  2010-06-03 10:59 ---
(In reply to comment #60)
> (In reply to comment #59)

> Is this bug just a dupe of PR 44132 now?

No, PR44132 applies to all darwin versions.

However, I think it *is* a dup of PR44304 (which relates to the fail of
bootstrap on 4.5.0/Darwin10)


-- 


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

[Bug bootstrap/42798] --enable-build-with-cxx bootstrap fails on i686-pc-linux-gnu (Fedora12)

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2010-06-03 11:12 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c++/2972] -Wuninitialized could warn about uninitialized member variable usage in constructors

[jwakely dot gcc at gmail dot com]

--- Comment #14 from jwakely dot gcc at gmail dot com  2010-06-03 11:24 
---
Created an attachment (id=20817)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20817&action=view)
better -Wmeminit patch

This version ignores empty classes and checks for a nontrivial default ctor
instead of layout_pod_type.

This patch doesn't enable the warning unless explicity requested. I realise
that this warning is about enforcing style ("members should be initialised in
the mem-initializer-list not in the ctor body") but that's ok because it's my
preferred style, I just don't want the compiler to enforce other people's
preferred style ;)


-- 


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

[Bug lto/44398] lto1: internal compiler error: Segmentation fault

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-06-03 11:28 ---
That isn't very helpful ;)  Can you try to reproduce this with current trunk?
What version of gold are you using?

Can you produce a testcase?  Try doing an incremental link (-r), and strip
libraries and object files as much as possible while the issue still
reproduces.  Then attach preprocessed source of the remaining bits.  You
probably need to remove -fwhole-program for this to work (where the issue
then hopefully still reproduces).


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug bootstrap/44397] [4.6 Regression] mangled line number section in bootstrap

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-06-03 11:28 ---
ipa-reference.c:(.text+0x28825): undefined reference to
`lto_varpool_encoder_size'

has been fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug lto/44390] LTO strips out symbols that are actually needed

[bero at arklinux dot org]

--- Comment #7 from bero at arklinux dot org  2010-06-03 11:38 ---
Exact same error with 4.5.1 branch rev. 160157, compiling trunk


-- 


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

[Bug debug/44375] goto_locus lost at -O0 during cfg cleanup

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2010-06-03 12:07 ---
Subject: Bug 44375

Author: jakub
Date: Thu Jun  3 12:07:18 2010
New Revision: 160219

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160219
Log:
PR debug/44375
* tree-cfg.c (gimple_can_merge_blocks_p): For -O0
return false if merging the bbs would lead to goto_locus
location being lost from the IL.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-cfg.c


-- 


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

[Bug c++/44399] New: Problem with command line arguments in windows

[alexandrfedorov at gmail dot com]

I'm trying to write windows console application working with directories, and i
discover that arguments processed not right. For example:

#include 
int main ( int argc, char *argv[], char *envp[] ) {
std::cout << "you have " << argc << " arguments";
}

resulting:

>a.exe "a a"
you have 2 arguments
>a.exe "a a" a
you have 3 arguments
>a.exe "a a\" a
you have 2 arguments

As i understand, backslash is escaping double quote and we have [a a" a]
argument instead of [a a\],[a].
It's very sad, because i must operate with directories or UNC paths like:
"\\serv\share\some dir with spaces\" where double quotes is required and
backslash can be present.

Quoting long file paths with double quotes and backslashes in paths is a common
thing in windows console programs.


-- 
   Summary: Problem with command line arguments in windows
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alexandrfedorov at gmail dot com


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

[Bug c++/44399] Problem with command line arguments in windows

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-06-03 12:29 ---
This is a problem of your execution environment, not GCC.  And AFAICS your
observerd behavior is what is expected.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug tree-optimization/44363] [4.6 Regression] gcc fails with ICE when compiling ffmpeg

[lists at eitanadler dot com]

--- Comment #13 from lists at eitanadler dot com  2010-06-03 12:38 ---
gcc 4.6.0.20100529 + the patch fixes the problem.


-- 

lists at eitanadler dot com changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED


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

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

[iains at gcc dot gnu dot org]

--- Comment #63 from iains at gcc dot gnu dot org  2010-06-03 12:50 ---
(In reply to comment #62)
> (In reply to comment #60)
> > (In reply to comment #59)
> 
> > Is this bug just a dupe of PR 44132 now?
> 
> No, PR44132 applies to all darwin versions.

OK, I need to refine that comment.  
Further testing this morning reveals that the code at comment #42 (modified to
put in the DYLD_LIB)  does also fail on darwin9 (albeit much less frequently).  

However, PR44132 is a non-random problem that applies to all emutls targets and
has a distinct solution.

==

It is not clear (yet) whether this (43170)  bug is in emutls or the platform. 

So, probably better to keep the bugs separate.


-- 


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

[Bug c++/44399] Problem with command line arguments in windows

[alexandrfedorov at gmail dot com]

--- Comment #2 from alexandrfedorov at gmail dot com  2010-06-03 12:50 
---
I'm executing my application via cmd.exe from Windows XP. As i know in windows
NOTHING is escaping with backslash. Standard utilities like cacls.exe working
well with such arguments.

Please pay attention to this problem.


-- 

alexandrfedorov at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

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

[howarth at nitro dot med dot uc dot edu]

--- Comment #64 from howarth at nitro dot med dot uc dot edu  2010-06-03 
13:03 ---
I've also had a report for the fink gcc45-4.5.0-1000 package of the boot strap
comparison failure occuring (rarely) on a single processor PowerPC (building
with make -j 1).


-- 


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

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

[iains at gcc dot gnu dot org]

--- Comment #65 from iains at gcc dot gnu dot org  2010-06-03 13:17 ---
*** Bug 44304 has been marked as a duplicate of this bug. ***


-- 

iains at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||doc0 dot delphin at voila
   ||dot fr


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

[Bug bootstrap/44304] Building gcc 4.5.0 under Snow Leopard : stages 2 & 3 differ

[iains at gcc dot gnu dot org]

--- Comment #11 from iains at gcc dot gnu dot org  2010-06-03 13:17 ---


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


-- 

iains at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/44399] Problem with command line arguments in windows

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-06-03 13:18 ---
GCC does not have any influence on how arguments are split, it is your
execution environment (including the runtime, which might be cygwin or
mingw).

This is not a GCC bug, please do not reopen it.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/44399] Problem with command line arguments in windows

[jwakely dot gcc at gmail dot com]

--- Comment #4 from jwakely dot gcc at gmail dot com  2010-06-03 13:24 
---
If it's a cygwin executable the behaviour might be caused by cygwin's "globber"

In any case, it's not gcc


-- 


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

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

[howarth at nitro dot med dot uc dot edu]

--- Comment #66 from howarth at nitro dot med dot uc dot edu  2010-06-03 
13:46 ---
At the risk of confusing the issues here, I would point out...

http://gcc.gnu.org/ml/gcc/2010-04/msg00044.html

where I observed that 20_util/shared_ptr/thread/default_weaktoshared.cc
execution test rarely times out on darwin10. A standalone testcase which
reproduces this bug (if executed enough times) is in
http://gcc.gnu.org/ml/gcc/2010-04/msg00035.html.


-- 


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

[Bug lto/40702] lto-elf.c fails to compile on Solaris

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2010-06-03 13:47 
---
The problem seems to have vanished, so eventually the fix can be backported
(together with the typo fix in the configure script obviously).


-- 


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

Re: [Bug c++/44399] New: Problem with command line arguments in windows

[Andrew Pinski]

Sent from my iPhone

On Jun 3, 2010, at 5:15 AM, "alexandrfedorov at gmail dot com" > wrote:


I'm trying to write windows console application working with  
directories, and i

discover that arguments processed not right. For example:

#include 
int main ( int argc, char *argv[], char *envp[] ) {
std::cout << "you have " << argc << " arguments";
}

resulting:


a.exe "a a"

you have 2 arguments


This is correct because the first argument is a.exe.



a.exe "a a" a

you have 3 arguments

a.exe "a a\" a

you have 2 arguments

As i understand, backslash is escaping double quote and we have [a  
a" a]

argument instead of [a a\],[a].
It's very sad, because i must operate with directories or UNC paths  
like:
"\\serv\share\some dir with spaces\" where double quotes is required  
and

backslash can be present.

Quoting long file paths with double quotes and backslashes in paths  
is a common

thing in windows console programs.


--
  Summary: Problem with command line arguments in windows
  Product: gcc
  Version: 4.4.3
   Status: UNCONFIRMED
 Severity: normal
 Priority: P3
Component: c++
   AssignedTo: unassigned at gcc dot gnu dot org
   ReportedBy: alexandrfedorov at gmail dot com


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

[Bug fortran/41227] COMMON block, BIND(C) and LTO interoperability issues

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2010-06-03 13:48 ---
Mine.  See http://gcc.gnu.org/ml/gcc-patches/2010-05/msg02424.html for an
outline for a possible fix.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-06-03 13:48:44
   date||


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

[Bug c++/44399] Problem with command line arguments in windows

[pinskia at gmail dot com]

--- Comment #5 from pinskia at gmail dot com  2010-06-03 13:48 ---
Subject: Re:   New: Problem with command line arguments in windows



Sent from my iPhone

On Jun 3, 2010, at 5:15 AM, "alexandrfedorov at gmail dot com"
 wrote:

> I'm trying to write windows console application working with  
> directories, and i
> discover that arguments processed not right. For example:
>
> #include 
> int main ( int argc, char *argv[], char *envp[] ) {
> std::cout << "you have " << argc << " arguments";
> }
>
> resulting:
>
>> a.exe "a a"
> you have 2 arguments

This is correct because the first argument is a.exe.


>> a.exe "a a" a
> you have 3 arguments
>> a.exe "a a\" a
> you have 2 arguments
>
> As i understand, backslash is escaping double quote and we have [a  
> a" a]
> argument instead of [a a\],[a].
> It's very sad, because i must operate with directories or UNC paths  
> like:
> "\\serv\share\some dir with spaces\" where double quotes is required  
> and
> backslash can be present.
>
> Quoting long file paths with double quotes and backslashes in paths  
> is a common
> thing in windows console programs.
>
>
> -- 
>   Summary: Problem with command line arguments in windows
>   Product: gcc
>   Version: 4.4.3
>Status: UNCONFIRMED
>  Severity: normal
>  Priority: P3
> Component: c++
>AssignedTo: unassigned at gcc dot gnu dot org
>ReportedBy: alexandrfedorov at gmail dot com
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44399
>


-- 


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

[Bug tree-optimization/43688] ICE: in analyze_function, at ipa-reference.c:733 with -fipa-reference

[zsojka at seznam dot cz]

--- Comment #5 from zsojka at seznam dot cz  2010-06-03 14:03 ---
This stopped crashing sometimes between r158969 and r159387 (at x86_64-linux)


-- 


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

[Bug lto/41569] .../prev-gcc/xgcc used for the install step of the lto-plugin

[rguenth at gcc dot gnu dot org]

--- Comment #17 from rguenth at gcc dot gnu dot org  2010-06-03 14:14 
---
We bootstrap it again and it now seems to install fine.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug lto/41584] WHOPR doesn't grok empty units

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2010-06-03 14:22 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug lto/41584] WHOPR doesn't grok empty units

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2010-06-03 14:23 ---
Subject: Bug 41584

Author: rguenth
Date: Thu Jun  3 14:22:46 2010
New Revision: 160223

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160223
Log:
2010-06-03  Richard Guenther  

PR lto/41584
* gcc.dg/lto/20100603-1_0.c: New testcase.
* gcc.dg/lto/20100603-2_0.c: Likewise.
* gcc.dg/lto/20100603-3_0.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/lto/20100603-1_0.c
trunk/gcc/testsuite/gcc.dg/lto/20100603-2_0.c
trunk/gcc/testsuite/gcc.dg/lto/20100603-3_0.c
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/44396] x86_64 linking problems with gcc4.4.1 on Snow Leopard

[christine dot mecklenborg at gmail dot com]

--- Comment #2 from christine dot mecklenborg at gmail dot com  2010-06-03 
14:33 ---
(In reply to comment #1)
> >gcc/ld is trying to link as i386
> 
> Well the option -arch x86_64 does not exist for the FSF GCC; it is -m64.  I
> think the issue is that your makefile is built for Apple's GCC and not for the
> generic GCC.  Can you change the makefile to use -m64 instead?
> 

That did the trick.  Thank you so much!


-- 

christine dot mecklenborg at gmail dot com changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[dominiq at lps dot ens dot fr]

--- Comment #33 from dominiq at lps dot ens dot fr  2010-06-03 14:52 ---
On x86_64-apple-darwin10.3.0 the patch in comment #26 applied on top of r160219
cause 

=== libjava Summary for unix/-m64 ===

# of expected passes2459
# of unexpected failures62
# of untested testcases 55


-- 


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

[Bug c++/44400] New: GCC allows declaring a function having the name of the class using a typedef

[schaub-johannes at web dot de]

This code is accepted by GCC and compiles

typedef void F();
struct X { F X; };

Not valid according to 9.2/13bullet2. It seems that GCC thinks that "F X;" is a
data-member (declaring data-members with the name of the class is valid, as
long as there are no user declared constructors).


-- 
   Summary: GCC allows declaring a function having the name of the
class using a typedef
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schaub-johannes at web dot de
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug tree-optimization/43688] ICE: in analyze_function, at ipa-reference.c:733 with -fipa-reference

[hjl at gcc dot gnu dot org]

--- Comment #6 from hjl at gcc dot gnu dot org  2010-06-03 14:53 ---
Subject: Bug 43688

Author: hjl
Date: Thu Jun  3 14:53:06 2010
New Revision: 160224

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160224
Log:
Add a testcasef for PR tree-optimization/43688.

2010-06-03  H.J. Lu  

PR tree-optimization/43688
* gfortran.dg/pr43688.f90: New.

Added:
trunk/gcc/testsuite/gfortran.dg/pr43688.f90
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug tree-optimization/43688] ICE: in analyze_function, at ipa-reference.c:733 with -fipa-reference

[hjl dot tools at gmail dot com]

--- Comment #7 from hjl dot tools at gmail dot com  2010-06-03 14:55 ---
Fixed by revision 159343:

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


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

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


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

[Bug c++/44401] New: GCC does not correctly hide injected class name

[schaub-johannes at web dot de]

This code is valid, but GCC rejects it:

struct X { int X; };
int X::*p = &X::X;

// error: taking address of constructor 'X::X'

GCC apparently seems to think that X::X looks up to the injected class name,
and thus (by 3.4.3.1/1a) would name the constructor. But the name of the
non-static data member should hide the injected class name.


-- 
   Summary: GCC does not correctly hide injected class name
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schaub-johannes at web dot de
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[iains at gcc dot gnu dot org]

--- Comment #34 from iains at gcc dot gnu dot org  2010-06-03 15:03 ---
(In reply to comment #33)
> On x86_64-apple-darwin10.3.0 the patch in comment #26 applied on top of 
> r160219
> cause 
> 
> === libjava Summary for unix/-m64 ===
> 
> # of expected passes2459
> # of unexpected failures62
> # of untested testcases 55

hm.  grep of:
 tls, THREAD_LOCAL_P,  TLS_MODEL and __thread in gcc/java/* returns "".
(I had done that before, but just checked again).


-- 


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

[Bug c++/41921] Cross language don't work with typedef unnamed structs

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2010-06-03 15:03 ---
This is fixed.  I have a testcase + testsuite patch.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c++/44402] New: GCC does not accept friend function declarations using a typedef for function type.

[schaub-johannes at web dot de]

This code is valid, but rejected by GCC:

struct A { void f(); }; 
typedef void F(); 
struct B { friend F A::f; };

// error: type 'A' is not derived from type 'B'


-- 
   Summary: GCC does not accept friend function declarations using a
typedef for function type.
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schaub-johannes at web dot de
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug lto/42453] Assertion `syms' failed in lto-plugin

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2010-06-03 15:07 ---
The assert has been removed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.1


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

[Bug driver/41844] lto1: warning: unknown register name: line-length-none

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-06-03 15:08 ---
*** Bug 42675 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu dot
   ||org


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

[Bug lto/42675] lto1 rejects -fdump-core option of gfortran

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-06-03 15:08 ---
Similar to PR41844.

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


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug lto/43038] DECL_PRESERVE_P static globals not completely preserved with -flto

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2010-06-03 15:13 ---
Re-confirmed on trunk.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2010-04-23 16:14:36 |2010-06-03 15:13:52
   date||


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

[Bug lto/43038] DECL_PRESERVE_P static globals not completely preserved with -flto

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2010-06-03 15:14 ---
Ah, it does not work because we mangle foobar to foobar.1234, not because
we eliminate it.


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[dominiq at lps dot ens dot fr]

--- Comment #35 from dominiq at lps dot ens dot fr  2010-06-03 15:21 ---
Extracted from x86_64-apple-darwin10.3.0/libjava/testsuite/libjava.log:

...
set_ld_library_path_env_vars:
ld_library_path=.:/opt/gcc/build_w/x86_64-apple-darwin10.3.0/./libjava/.libs
invoke: /opt/gcc/build_w/x86_64-apple-darwin10.3.0/./libjava/gij -jar
/opt/gcc/work/libjava/testsuite/libjava.jar/TestClosureGC.jar
Setting LD_LIBRARY_PATH to
.:/opt/gcc/build_w/x86_64-apple-darwin10.3.0/./libjava/.libs:.:/opt/gcc/build_w/x86_64-apple-darwin10.3.0/./libjava/.libs
Exception in thread "main" java.lang.NullPointerException
   at TestClosureGC.main(TestClosureGC.java:108)
FAIL: /opt/gcc/work/libjava/testsuite/libjava.jar/TestClosureGC.jar execution -
gij test
UNTESTED: /opt/gcc/work/libjava/testsuite/libjava.jar/TestClosureGC.jar output
- gij test
...

Note the failures occur only with -m64, not with -m32.


-- 


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

[Bug lto/43157] Segmentation fault in aggregate_value_p, asm aliases do not work

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-06-03 15:24 ---
Re-confirmed on trunk.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu dot
   ||org
   Last reconfirmed|2010-02-24 10:50:09 |2010-06-03 15:24:20
   date||
Summary|Segmentation fault in   |Segmentation fault in
   |aggregate_value_p   |aggregate_value_p, asm
   ||aliases do not work


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

[Bug lto/43208] lto1: error: invalid conversion in return statement

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-06-03 15:26 ---
Reconfirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2010-04-23 16:24:03 |2010-06-03 15:26:59
   date||


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

[Bug lto/43372] lto ICE in strip_extension with linker plugin

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-06-03 15:28 ---
Fixed for 4.6.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug lto/43467] LTO error "bytecode stream: trying to read 0 bytes after the end of the input buffer"

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-06-03 15:31 ---
Cary - why does lto-plugin get invoked when gold has errors?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ccoutant at gcc dot gnu dot
   ||org


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

[Bug c++/44401] Doesn't correctly hide injected class name

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-06-03 15:32 ---
There was a defect report in the C++ standard about X::X; I cannot remember
what happens with a member variable being named the same as the class name
though.


-- 


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

[Bug tree-optimization/44403] New: vectorization does not maintain 'restrict' qualifier

[roy dot 1rosen at gmail dot com]

For the following function:

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

the following is generated in the .optimized file:

xxx (short int * restrict a, short int * restrict b)
{
  vector(2) short int * vect_p.27;
  vector(2) short int vect_var_.26;
  vector(2) short int * vect_p.22;
  int andmask.21;
  int orptrs1.20;
  int addr2int1.19;
  vector(2) short int * vect_p.18;
  int addr2int0.15;
  vector(2) short int * vect_p.14;
  short int D.1998;
  short int * restrict D.1997;
  short int * restrict D.1996;

:
  vect_p.14_18 = (vector(2) short int *) b_9(D);
  addr2int0.15_23 = (int) vect_p.14_18;
  vect_p.18_24 = (vector(2) short int *) a_5(D);
  addr2int1.19_25 = (int) vect_p.18_24;
  orptrs1.20_26 = addr2int0.15_23 | addr2int1.19_25;
  andmask.21_27 = orptrs1.20_26 & 3;
  if (andmask.21_27 == 0)
goto ;
  else
goto ;

:
  vect_var_.26_6 = *vect_p.14_18;
  *vect_p.18_24 = vect_var_.26_6;
  vect_p.22_11 = vect_p.14_18 + 4;
  vect_p.27_12 = vect_p.18_24 + 4;
  vect_var_.26_56 = *vect_p.22_11;
  *vect_p.27_12 = vect_var_.26_56;
  vect_p.22_58 = vect_p.22_11 + 4;
  vect_p.27_59 = vect_p.27_12 + 4;
  vect_var_.26_65 = *vect_p.22_58;
  *vect_p.27_59 = vect_var_.26_65;
  vect_p.22_67 = vect_p.22_58 + 4;
  vect_p.27_68 = vect_p.27_59 + 4;
  vect_var_.26_44 = *vect_p.22_67;
  *vect_p.27_68 = vect_var_.26_44;
  goto ;

:
  D.1998_77 = *b_9(D);
  *a_5(D) = D.1998_77;
  D.1996_86 = a_5(D) + 2;
  D.1997_87 = b_9(D) + 2;
  D.1998_88 = *D.1997_87;
  *D.1996_86 = D.1998_88;
  D.1996_97 = a_5(D) + 4;
  D.1997_98 = b_9(D) + 4;
  D.1998_99 = *D.1997_98;
  *D.1996_97 = D.1998_99;
  D.1996_108 = a_5(D) + 6;
  D.1997_109 = b_9(D) + 6;
  D.1998_110 = *D.1997_109;
  *D.1996_108 = D.1998_110;
  D.1996_119 = a_5(D) + 8;
  D.1997_120 = b_9(D) + 8;
  D.1998_121 = *D.1997_120;
  *D.1996_119 = D.1998_121;
  D.1996_130 = a_5(D) + 10;
  D.1997_131 = b_9(D) + 10;
  D.1998_132 = *D.1997_131;
  *D.1996_130 = D.1998_132;
  D.1996_141 = a_5(D) + 12;
  D.1997_142 = b_9(D) + 12;
  D.1998_143 = *D.1997_142;
  *D.1996_141 = D.1998_143;
  D.1996_34 = a_5(D) + 14;
  D.1997_35 = b_9(D) + 14;
  D.1998_36 = *D.1997_35;
  *D.1996_34 = D.1998_36;

:
  return;

} 

You may notice that the vect variables don't have the restrict qualifier.

Using built-in specs.
COLLECT_GCC=./xgcc
Target: i386-elf-linux
Configured with: ../gcc-4.6-20100529/configure --target=i386-elf-linux
--enable-languages=c
Thread model: posix
gcc version 4.6.0 20100529 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-save-temps' '-v' '-O3' '-fno-ivopts' '-mtune=i386'
'-march=i386'
 cc1 -E -quiet -v -iprefix
/home/swproj/sw/users/eyalhar/i386-46/gcc/../lib/gcc/i386-elf-linux/4.6.0/
./a.c -mtune=i386 -march=i386 -fno-ivopts -O3 -fpch-preprocess -o a.i
ignoring nonexistent directory
"/home/swproj/sw/users/eyalhar/i386-46/gcc/../lib/gcc/i386-elf-linux/4.6.0/include"
ignoring nonexistent directory
"/home/swproj/sw/users/eyalhar/i386-46/gcc/../lib/gcc/i386-elf-linux/4.6.0/include-fixed"
ignoring nonexistent directory
"/home/swproj/sw/users/eyalhar/i386-46/gcc/../lib/gcc/i386-elf-linux/4.6.0/../../../../i386-elf-linux/sys-include"
ignoring nonexistent directory
"/home/swproj/sw/users/eyalhar/i386-46/gcc/../lib/gcc/i386-elf-linux/4.6.0/../../../../i386-elf-linux/include"
ignoring nonexistent directory
"/home/swproj/sw/users/eyalhar/i386-46/gcc/../lib/gcc/../../lib/gcc/i386-elf-linux/4.6.0/include"
ignoring nonexistent directory
"/home/swproj/sw/users/eyalhar/i386-46/gcc/../lib/gcc/../../lib/gcc/i386-elf-linux/4.6.0/include-fixed"
ignoring nonexistent directory
"/home/swproj/sw/users/eyalhar/i386-46/gcc/../lib/gcc/../../lib/gcc/i386-elf-linux/4.6.0/../../../../i386-elf-linux/sys-include"
ignoring nonexistent directory
"/home/swproj/sw/users/eyalhar/i386-46/gcc/../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='-save-temps' '-v' '-O3' '-fno-ivopts' '-mtune=i386'
'-march=i386'
 cc1 -fpreprocessed a.i -quiet -dumpbase a.c -mtune=i386 -march=i386 -auxbase a
-O3 -version -fno-ivopts -o a.s
GNU C (GCC) version 4.6.0 20100529 (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 20100529 (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: b29c4bb89017c75caf92d2ab060612f6
COLLECT_GCC_OPTIONS='-save-temps' '-v' '-O3' '-fno-ivopts' '-mtune=i386'
'-march=i386'
 as -V -Qy --32 -o a.o a.s
GNU assembler version 2.17.50.0.6-9.el5 (x86_64-redhat-linux) using BFD version
2.17.50.0.6-9

[Bug tree-optimization/44403] vectorization does not maintain 'restrict' qualifier

[roy dot 1rosen at gmail dot com]

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


-- 


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

[Bug tree-optimization/44403] vectorization does not maintain 'restrict' qualifier

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-06-03 16:03 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||missed-optimization
   Last reconfirmed|-00-00 00:00:00 |2010-06-03 16:03:01
   date||


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

[Bug c++/41921] Cross language don't work with typedef unnamed structs

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2010-06-03 16:08 
---
Subject: Bug 41921

Author: rguenth
Date: Thu Jun  3 16:08:10 2010
New Revision: 160226

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160226
Log:
2010-06-03  Richard Guenther  

PR lto/41921
* lib/lto.exp: Always load gcc.exp.
(lto-obj): For C source files invoke gcc_target_compile.
* g++.dg/lto/20100603-1_0.C: New testcase.
* g++.dg/lto/20100603-1_1.c: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/lto/20100603-1_0.C
trunk/gcc/testsuite/g++.dg/lto/20100603-1_1.c
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[iains at gcc dot gnu dot org]

--- Comment #36 from iains at gcc dot gnu dot org  2010-06-03 16:08 ---
(In reply to comment #35)
> Extracted from x86_64-apple-darwin10.3.0/libjava/testsuite/libjava.log:
> 
> ...
> set_ld_library_path_env_vars:
> ld_library_path=.:/opt/gcc/build_w/x86_64-apple-darwin10.3.0/./libjava/.libs
> invoke: /opt/gcc/build_w/x86_64-apple-darwin10.3.0/./libjava/gij -jar
> /opt/gcc/work/libjava/testsuite/libjava.jar/TestClosureGC.jar
> Setting LD_LIBRARY_PATH to
> .:/opt/gcc/build_w/x86_64-apple-darwin10.3.0/./libjava/.libs:.:/opt/gcc/build_w/x86_64-apple-darwin10.3.0/./libjava/.libs
> Exception in thread "main" java.lang.NullPointerException
>at TestClosureGC.main(TestClosureGC.java:108)
> FAIL: /opt/gcc/work/libjava/testsuite/libjava.jar/TestClosureGC.jar execution 
> -
> gij test
> UNTESTED: /opt/gcc/work/libjava/testsuite/libjava.jar/TestClosureGC.jar output
> - gij test
> ...
> 
> Note the failures occur only with -m64, not with -m32.

OK, libjava uses __thread so I need to investigate what's happening there;

However, java is not using the emutls facility from its FE (AFAICT).


-- 


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

[Bug c++/41921] Cross language don't work with typedef unnamed structs

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2010-06-03 16:09 
---
Subject: Bug 41921

Author: rguenth
Date: Thu Jun  3 16:08:49 2010
New Revision: 160227

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160227
Log:
2010-06-03  Richard Guenther  

PR lto/41921
* lib/lto.exp: Always load gcc.exp.
(lto-obj): For C source files invoke gcc_target_compile.
* g++.dg/lto/20100603-1_0.C: New testcase.
* g++.dg/lto/20100603-1_1.c: Likewise.

Modified:
trunk/gcc/testsuite/lib/lto.exp


-- 


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

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

[iains at gcc dot gnu dot org]

--- Comment #67 from iains at gcc dot gnu dot org  2010-06-03 16:12 ---
I am puzzled by this apparent fail when the tests that depend on the variables
being distinct are all passing.
So, I think I've got a hunch; 

If the spawned thread finishes before pthread_create () returns, then the
allocation for the thread's version of 'a' will have been released.

There is nothing to stop malloc from allocating the same block to the main
thread version of 'a' when it is asked for.

I would be reluctant to draw too many conclusions from current trunk since the
emutls has a "work-around" fix in it - but putting a usleep (1000) into the
x86_64 spawned thread works.  

=== 

On darwin9 ppc/i686 with the patch @ comment #26 of PR44132 applied: 

using this driver to do uninstalled tests:
---
#!/bin/sh
i=0
while [ $(( $i < 100 )) ]
do
  i=`expr $i + 1`
  r=`DYLD_LIBRARY_PATH=./gcc ./tls.ex`
  if [ $? != 0 ]
  then
printf "%7d : %s\n" $((i)) "$r"
  fi
done
-
and this version of the test fragment:
-
/* { dg-do run }  */
/* { dg-require-effective-target tls  }  */

#include 
extern int printf (char *,...);
extern int usleep (long);
__thread int a = 5 ; 
static int *a_in_other_thread;

static void *
thread_func (void *arg)
{
/*  usleep (1000);*/
  a_in_other_thread = &a;
  a += 5 ;
  *((int *) arg) = a ;
  return (void *)0;
}

int
main ()
{
  pthread_t thread;
  void *thread_retval;
  int *a_in_main_thread;
  int thrd_arg;

  a_in_main_thread = &a;

  if (pthread_create (&thread, (pthread_attr_t *)0, thread_func, &thrd_arg))
return 0;

  if (pthread_join (thread, &thread_retval))
return 0;

  if (a != 5 || thrd_arg != 10 || (a_in_other_thread == a_in_main_thread))
  {
 printf ("FAIL: a = %d thrd_a = %d address = 0x%0x\n", 
a, thrd_arg, a_in_main_thread);
 return 1 ;
  }
  return 0;
}


this has been running for 2hrs w/out a fail so far on both ppc and i686 d9.. 


-- 


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

[Bug c++/44294] [4.6 regression] FAIL: g++.dg/abi/bitfield12.C

[hjl at gcc dot gnu dot org]

--- Comment #5 from hjl at gcc dot gnu dot org  2010-06-03 16:36 ---
Subject: Bug 44294

Author: hjl
Date: Thu Jun  3 16:36:22 2010
New Revision: 160229

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160229
Log:
Check MAX_FIXED_MODE_SIZE on bit-field in C++.

gcc/ada/

2010-06-03  H.J. Lu  

PR c++/44294
* gcc-interface/decl.c (MAX_FIXED_MODE_SIZE): Removed.

gcc/cp/

2010-06-03  H.J. Lu  

PR c++/44294
* class.c (layout_class_type): Check MAX_FIXED_MODE_SIZE on
bit-field.

gcc/

2010-06-03  H.J. Lu  

PR c++/44294
* defaults.h (MAX_FIXED_MODE_SIZE): New.

* stor-layout.c (MAX_FIXED_MODE_SIZE): Removed.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/decl.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c
trunk/gcc/defaults.h
trunk/gcc/stor-layout.c


-- 


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

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

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2010-06-03 16:40 
---
Let's CC Jason...


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org


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

[Bug c++/44401] Doesn't correctly hide injected class name

[schaub-johannes at web dot de]

--- Comment #2 from schaub-johannes at web dot de  2010-06-03 16:45 ---
The Standard allows this at 9.2/13a ("In addition, if class T has a
user-declared constructor (12.1), every nonstatic data member of class T shall
have a name different from T."). In our case we don't have a user declared
constructor. 

Now we have an object name, and a class-name. The object name should hide the
class name according to 3.3.7/2. You can access the class name by using an
elaborated type specifier "class X::X" (which is not replaced by a constructor
reference either) or if you name it in a base-specifier "struct Y : X::X { };". 

C++0x adds using declarations as one further context looking up the the
*constructor* specifically (not by way of injected class names). Thus the
following names the constructors of X (but inherits no constructors):

struct Y : X { using X::X; };

It does not name the data-member "X", because the mapping from "X::X" is done
by syntactical means by the second bullet of 3.4.3.1/2. The same mapping makes
the following work in C++0x:

struct Y : X { using identity::type::type; };

This shows it doesn't use the injected class name of "X" for looking up
constructors. Now, the following is valid in C++03 and C++0x:

struct Y : X { using identity::type::X; };

In C++03 this is a normal using declaration that redeclares the member name to
be public in Y and which resolves to the data member. In C++0x,
3.4.3.1/1bullet4 (see DR #400) makes the lookup yield both the injected class
name and the data member (personally i always thought that a lookup can only
yield multiple declarations if all the declarations are function names, but i'm
always surprised again). 

Anyway, if in C++0x it yields both the injected class name and the data member,
should this be the *final* result, or is that result still subject of 3.4.3.1/2
making it name only the constructor? I think this is important to clarify,
since it determines the validity of the following:

struct A { private: int A; };
struct B : A { public: using A::A; };
void f() { B b; b.A; };

If "using A::A;" names the injected class name and the data member of A, this
code seems to be valid, because "A" is public as a member of B. However if we
are subjectof 3.4.3.1/2, we will have "using A::A" name the constructors of A
and thus be a no-op declaration (no constructors are inherited in this case.
And since the data member lookup result was discared, no member name is
redeclared).

Any ideas? Are there issue reports about it, or am i just missing something?


-- 


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

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

[jakub at gcc dot gnu dot org]

--- Comment #68 from jakub at gcc dot gnu dot org  2010-06-03 16:58 ---
That makes sense, so all we need to do in config/tls.m4 is probably:
1) move a_in_main_thread variable to file scope, and neither a_in_main_thread
nor a_in_other_thread should be static
2) move a_in_main_thread = &a; before pthread_create
That should be IMHO all that is needed, the compiler can't then move
a_in_main_thread assignment after pthread_create.  Or to be really sure make
a_in_main_thread and a_in_other_thread volatile too.


-- 


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

[Bug c++/44401] Doesn't correctly hide injected class name

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2010-06-03 17:00 
---
Jason certainly followed these developments, I remember, let's CC him.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org


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

[Bug rtl-optimization/44404] New: auto-inc-dec generates an invalid assembly instruction

[kazu at gcc dot gnu dot org]

Consider:

char buf[128];

extern void bar (int a, const char *p);
extern char *strcpy (char *, const char *);

void
foo (int a)
{
  if (a)
bar (0, buf);
  strcpy (buf, "0123456789abcdefghijklmnopqrstuvwxyz");
  bar (0, buf);
}

Compile this testcase with arm-none-linux-gnueabi-4.4.

strcpy above is inlined and unrolled like so:

ldmia   r4!, {r0, r1, r2, r3}
stmia   ip!, {r0, r1, r2, r3}
ldmia   r4!, {r0, r1, r2, r3}
stmia   ip!, {r0, r1, r2, r3}
ldmia   r4, {r0, r1}
str r0, [ip], #4
mov r1, ip
strbr1, [r1], #-36

Notice that the last instruction looks strange.  R1 immediately after
the last ldmia contains the last character, namely the null
terminator, but that gets destroyed in "mov r1, ip".  Then strb
attempts to write r1 to the memory location pointed to by r1, which
doesn't make sense.

The last instruction comes from auto-inc-dec.c.

I've got a patch in testing.


-- 
   Summary: auto-inc-dec generates an invalid assembly instruction
   Product: gcc
   Version: 4.4.4
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: kazu at gcc dot gnu dot org
ReportedBy: kazu at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-none-linux-gnueabi


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

[Bug rtl-optimization/44404] auto-inc-dec generates an invalid assembly instruction

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-06-03 17:27 ---
Looks related to PR 20972.


-- 


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

[Bug bootstrap/44405] New: --enable-build-with-cxx bootstrap fails on i686-pc-linux-gnu (Fedora13)

[amylaar at gcc dot gnu dot org]

I am trying to build mainline GCC (revision 160215) configured
with -enable-build-with-cxx .

I get the following error during bootstrap:

/user/inria/fsf/bldxx-20100603/./prev-gcc/g++
-B/user/inria/fsf/bldxx-20100603/./prev-gcc/
-B/user/inria/cxx/i686-pc-linux-gnu/bin/ -nostdinc++
-I/user/inria/fsf/bldxx-20100603/prev-i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu
-I/user/inria/fsf/bldxx-20100603/prev-i686-pc-linux-gnu/libstdc++-v3/include
-I/user/inria/fsf/gcc/libstdc++-v3/libsupc++
-L/user/inria/fsf/bldxx-20100603/prev-i686-pc-linux-gnu/libstdc++-v3/src/.libs
-c  -g -O2 -fomit-frame-pointer -gtoggle -DIN_GCC   -W -Wall -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common 
-DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/.
-I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include 
-I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/bid
-I../libdecnumber  -DCLOOG_PPL_BACKEND  -I/usr/include/libelf 
../../gcc/gcc/simplify-rtx.c -o simplify-rtx.o
/user/inria/fsf/bldxx-20100603/./prev-gcc/g++
-B/user/inria/fsf/bldxx-20100603/./prev-gcc/
-B/user/inria/cxx/i686-pc-linux-gnu/bin/ -nostdinc++
-I/user/inria/fsf/bldxx-20100603/prev-i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu
-I/user/inria/fsf/bldxx-20100603/prev-i686-pc-linux-gnu/libstdc++-v3/include
-I/user/inria/fsf/gcc/libstdc++-v3/libsupc++
-L/user/inria/fsf/bldxx-20100603/prev-i686-pc-linux-gnu/libstdc++-v3/src/.libs
-c  -g -O2 -fomit-frame-pointer -gtoggle -DIN_GCC   -W -Wall -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common 
-DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/.
-I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include 
-I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/bid
-I../libdecnumber  -DCLOOG_PPL_BACKEND  -I/usr/include/libelf 
../../gcc/gcc/sparseset.c -o sparseset.o
../../gcc/gcc/simplify-rtx.c: In function ‘rtx_def*
simplify_immed_subreg(machine_mode, rtx, machine_mode, unsigned int)’:
../../gcc/gcc/simplify-rtx.c:4878:11: error: variable ‘ibyte’ set but not used
[-Werror=unused-but-set-variable]
../../gcc/gcc/simplify-rtx.c:4982:16: error: variable ‘ibyte’ set but not used
[-Werror=unused-but-set-variable]
../../gcc/gcc/simplify-rtx.c:5027:11: error: variable ‘ibyte’ set but not used
[-Werror=unused-but-set-variable]
/user/inria/fsf/bldxx-20100603/./prev-gcc/g++
-B/user/inria/fsf/bldxx-20100603/./prev-gcc/
-B/user/inria/cxx/i686-pc-linux-gnu/bin/ -nostdinc++
-I/user/inria/fsf/bldxx-20100603/prev-i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu
-I/user/inria/fsf/bldxx-20100603/prev-i686-pc-linux-gnu/libstdc++-v3/include
-I/user/inria/fsf/gcc/libstdc++-v3/libsupc++
-L/user/inria/fsf/bldxx-20100603/prev-i686-pc-linux-gnu/libstdc++-v3/src/.libs
-c  -g -O2 -fomit-frame-pointer -gtoggle -DIN_GCC   -W -Wall -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common 
-DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/.
-I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include 
-I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/bid
-I../libdecnumber  -DCLOOG_PPL_BACKEND  -I/usr/include/libelf 
../../gcc/gcc/sreal.c -o sreal.o
cc1plus: all warnings being treated as errors

make[3]: *** [simplify-rtx.o] Error 1
make[3]: *** Waiting for unfinished jobs
rm gcj-dbtool.pod jcf-dump.pod jv-convert.pod grmic.pod gcov.pod gcj.pod
gc-analyze.pod gfdl.pod cpp.pod gij.pod gcc.pod gfortran.pod fsf-funding.pod
make[3]: Leaving directory `/user/inria/fsf/bldxx-20100603/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/user/inria/fsf/bldxx-20100603'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/user/inria/fsf/bldxx-20100603'
make: *** [bootstrap] Error 2


-- 
   Summary: --enable-build-with-cxx bootstrap fails on i686-pc-
linux-gnu (Fedora13)
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: build
  Severity: blocker
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux-gnu


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

[Bug bootstrap/44405] --enable-build-with-cxx bootstrap fails on i686-pc-linux-gnu (Fedora13)

[amylaar at gcc dot gnu dot org]

--- Comment #1 from amylaar at gcc dot gnu dot org  2010-06-03 17:59 ---
I'm currently testing if the patch for PR 44361 helps for this failure too.


-- 


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

[Bug c++/44362] Bogus set-but-not-used warning

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-06-03 18:01 ---
*** Bug 44405 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||amylaar at gcc dot gnu dot
   ||org


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

[Bug bootstrap/44405] --enable-build-with-cxx bootstrap fails on i686-pc-linux-gnu (Fedora13)

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-06-03 18:01 ---


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


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug rtl-optimization/44404] auto-inc-dec generates an invalid assembly instruction

[kazu at gcc dot gnu dot org]

--- Comment #2 from kazu at gcc dot gnu dot org  2010-06-03 18:18 ---
Andrew,

auto-inc-dec.c was introduced on Jul 2, 2006, and PR 20972 was filed
on April 12, 2005, so I'd think that PR 20972 is due to something
else.  They do both involve the same assembler message though.


-- 


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

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

[howarth at nitro dot med dot uc dot edu]

--- Comment #69 from howarth at nitro dot med dot uc dot edu  2010-06-03 
18:20 ---
So the tls tests in the generated configure should be changed as follows?

--- gcc-4.5.0/libgomp/configure.orig2010-06-03 13:05:23.0 -0400
+++ gcc-4.5.0/libgomp/configure 2010-06-03 13:41:14.0 -0400
@@ -15379,7 +15379,8 @@
 /* end confdefs.h.  */
 #include 
__thread int a;
-   static int *a_in_other_thread;
+   int *a_in_other_thread;
+   int *a_in_main_thread;
static void *
thread_func (void *arg)
{
@@ -15391,11 +15392,10 @@
 {
 pthread_t thread;
void *thread_retval;
-   int *a_in_main_thread;
+   a_in_main_thread = &a;
if (pthread_create (&thread, (pthread_attr_t *)0,
thread_func, (void *)0))
  return 0;
-   a_in_main_thread = &a;
if (pthread_join (thread, &thread_retval))
  return 0;
return (a_in_other_thread == a_in_main_thread);


-- 


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

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

[dominiq at lps dot ens dot fr]

--- Comment #70 from dominiq at lps dot ens dot fr  2010-06-03 18:23 ---
(In reply to comment #68)
> That makes sense, so all we need to do in config/tls.m4 is probably:
> 1) move a_in_main_thread variable to file scope, and neither a_in_main_thread
> nor a_in_other_thread should be static
> 2) move a_in_main_thread = &a; before pthread_create
> That should be IMHO all that is needed, the compiler can't then move
> a_in_main_thread assignment after pthread_create.  Or to be really sure make
> a_in_main_thread and a_in_other_thread volatile too.

Does this code follow these instructions?

#include 
 __thread int a;
 int *a_in_main_thread;
 int *a_in_other_thread;
 static void *
 thread_func (void *arg)
 {
   a_in_other_thread = &a;
   return (void *)0;
 }
int
main ()
{
pthread_t thread;
 void *thread_retval;
 a_in_main_thread = &a;
 if (pthread_create (&thread, (pthread_attr_t *)0,
 thread_func, (void *)0))
   return 0;
 if (pthread_join (thread, &thread_retval))
   return 0;
 return (a_in_other_thread == a_in_main_thread);
  ;
  return 0;
}

I have compiled it with -O2 -g -pthread and ran it 1 times on a loaded
system without failure.


-- 


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

[Bug rtl-optimization/44404] auto-inc-dec generates an invalid assembly instruction

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2010-06-03 18:25 ---
(In reply to comment #2)
> auto-inc-dec.c was introduced on Jul 2, 2006, and PR 20972 was filed
> on April 12, 2005, so I'd think that PR 20972 is due to something
> else.  They do both involve the same assembler message though.

Yes but if you read that PR you will notice that auto-inc-dec.c included some
of the same issues as flow did.


-- 


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

[Bug lto/43467] LTO error "bytecode stream: trying to read 0 bytes after the end of the input buffer"

[ccoutant at gcc dot gnu dot org]

--- Comment #4 from ccoutant at gcc dot gnu dot org  2010-06-03 18:29 
---
> Cary - why does lto-plugin get invoked when gold has errors?

Gold doesn't stop on these kinds of errors -- it proceeds to the end of the
link to try to diagnose as many errors as possible. I'm not sure why a
multiple-definition error would cause this problem in lto1, though. Nothing
should be preventing the plugin from generating valid IR files, unless the
presence of the duplicate definition is causing a different problem inside
either the plugin itself or lto1.


-- 


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

[Bug c++/44401] [4.5/4.6 regression] Doesn't correctly hide injected class name

[jason at gcc dot gnu dot org]

--- Comment #4 from jason at gcc dot gnu dot org  2010-06-03 18:55 ---
The "naming the constructor" stuff is DR 147, but I agree that this testcase
should be accepted since lookup doesn't find the injected-class-name.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-06-03 18:55:26
   date||
Summary|Doesn't correctly hide  |[4.5/4.6 regression] Doesn't
   |injected class name |correctly hide injected
   ||class name


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

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

[jakub at gcc dot gnu dot org]

--- Comment #71 from jakub at gcc dot gnu dot org  2010-06-03 19:02 ---
Yes.


-- 


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

[Bug c++/44406] New: wrong code generation with -ftree-sra

[torbenh at users dot sourceforge dot net]

attached code crashes, when compiled with -ftree-sra
works fine with 4.4.2

its probably an incarnation of PR44258


-- 
   Summary: wrong code generation with -ftree-sra
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: torbenh at users dot sourceforge dot net
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


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

[Bug c++/44406] wrong code generation with -ftree-sra

[torbenh at users dot sourceforge dot net]

--- Comment #1 from torbenh at users dot sourceforge dot net  2010-06-03 
19:08 ---
Created an attachment (id=20819)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20819&action=view)
code that crashes when compiled


-- 


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

[Bug c++/44406] wrong code generation with -ftree-sra

[torbenh at users dot sourceforge dot net]

--- Comment #2 from torbenh at users dot sourceforge dot net  2010-06-03 
19:10 ---
Created an attachment (id=20820)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20820&action=view)
preprocessed signals_test.cc


-- 


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

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

[torbenh at users dot sourceforge dot net]

--- Comment #5 from torbenh at users dot sourceforge dot net  2010-06-03 
19:15 ---
(In reply to comment #4)
> Unfortunately the preprocessed source from comment #1 seems to be
> damaged, I get loads of errors like "error: stray '\336' in program."
> Can you please re-upload it?  Thanks.
> 

have a look at PR44406... i believe its the same thing.


-- 


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

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

[Kyle dot D dot Moffett at boeing dot com]

--- Comment #3 from Kyle dot D dot Moffett at boeing dot com  2010-06-03 
19:26 ---
(In reply to comment #0)
> So after looking at the code I saw now the following:
> 1c24 <__floatdidf>:
> 1c6c:   11 23 1a 2c evmergehi r9,r3,r3
> 
> This function is touching the complete 64bit r9 register
> The code which calls it:
> 
> 1a40:   91 21 00 20 stw r9,32(r1)
> 1a44:   4e 80 04 21 bctrl   # tell function which in turn calls
> floatdidf
> 
> 1a7c:   81 21 00 20 lwz r9,32(r1)
> 1a80:   38 60 00 00 li  r3,0
> 1a84:   7e 33 8b 78 mr  r19,r17 
> 1a88:   12 49 92 e1 efdsub  r18,r9,r18
> 1a8c:   10 80 92 fa efdctsiz r4,r18
> 1a90:   12 49 4a 17 evmrr18,r9  
> 
> So we just save the lower 32bit of r9 before calling the function and the 
> upper
> 32bit are overwritten by efdsub.

Ok, here's the e500 ABI user guide:
  http://www.freescale.com/files/32bit/doc/ref_manual/E500ABIUG.pdf

According to that guide, we have the following usage of GPRs:
  Dedicated: r1 r2 r13
  Nonvolatile: r14-r31
  Volatile: r0 r3-r12

Then:
  Before a function changes the value in the upper word of any nonvolatile
general register, rn, it shall save the 64-bit value in rn in the 64-bit
general register save area 8*(32-n) bytes below the CR save area (plus any
required padding).  The 64-bit general save area shall have 8-byte alignment.

And:
  Before a function changes the value in the lower word of any nonvolatile
general register, rn, that has not already been saved in the 64-bit general
register save area, it shall save the value in the lower word of rn in the word
in the 32-bit general register save area 4*(32-n) bytes before the back chain
word of the previous frame.

So clearly the caller's assembly is wrong; it should be saving all 64-bits of
r9 (volatile gpr) first.

Cheers,
Kyle Moffett


-- 


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

[Bug tree-optimization/44403] vectorization does not maintain 'restrict' qualifier

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-06-03 19:39 ---
Created an attachment (id=20821)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20821&action=view)
patch

Mine.


-- 

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


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

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

[iains at gcc dot gnu dot org]

--- Comment #72 from iains at gcc dot gnu dot org  2010-06-03 20:06 ---
Created an attachment (id=20822)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20822&action=view)
config patch for test

 config/tls.m4 - modified as per Jakub's suggestion
 */configure regenerated as necessary.

see how it works for you - I'm bootstrapping x86_64 with this at the moment.


-- 


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

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

[Kyle dot D dot Moffett at boeing dot com]

--- Comment #4 from Kyle dot D dot Moffett at boeing dot com  2010-06-03 
20:09 ---
Ok, I have a trivial 19-line testcase that triggers the bug on my native Debian
GCC 4.4.4-2+powerpcspe1 (with PR44169 fix) with -O0 and -O3.  The compiler was
built with: --with-cpu=8548 --enable-e500_double --with-long-double-128
  In order to make it work on -O3 I had to split the "double z", "void
problem()" and "int main()" into 3 separate files to prevent GCC from inlining
everything.

Compiled with:
  gcc -Wall -Wextra -Werror -ggdb3 -O0 -o testall testall.c
Output (the two "main: a" lines should read the same):
  main: a = 78.463000
  problem: a = 39.231500
  main: a = 39.231476

Or with:
  gcc -Wall -Wextra -Werror -ggdb3 -O3 -o test.o -c test.c
  gcc -Wall -Wextra -Werror -ggdb3 -O3 -o test2.o -c test2.c
  gcc -Wall -Wextra -Werror -ggdb3 -O3 -o test3.o -c test3.c
  gcc -Wall -Wextra -Werror -ggdb3 -O3 -o test test.o test2.o test3.o
Output:  (again, "main" lines should be identical)
  main: a = 78.463000
  problem: a = 39.231500
  main: a = 78.462952

As you might imagine, a bug this bad triggers testsuite failures in MPFR, GMP,
PostgreSQL, lapack, and basically everything else with a comprehensive
floating-point test-suite.

Cheers,
Kyle Moffett


-- 


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

[Bug c/44407] New: int = int / unsigned int yields unexpected result

[okingsmith at nuvation dot com]

I have seen the following code produce an unexpected result on two different
gcc compilers.  I compile the following code

#include 

int main()
{
int a, d1, r1, r2;
unsigned int d2;

a = -10;
d1 = 2;
d2 = 3;

r1 = a / d1;
r2 = a / d2;

printf( "r1 = %d\tr2 = %d\n", r1, r2 );

return 0;
}

using

gcc -Wall sample_code.c 

I do not receive any warning messages.  When I run the code I get

% ./a.out 
r1 = -5 r2 = 1431655762

I think it would be nice to get a warning message on the second division.

Below is an example of one compiler showing the problem


Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/gcc/gcc-5659~1/src/configure --disable-checking
--enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib
--build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10-
--host=x86_64-apple-darwin10 --target=i686-apple-darwin10
--with-gxx-include-dir=/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5659)


-- 
   Summary: int = int / unsigned int yields unexpected result
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: okingsmith at nuvation dot com


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

[Bug lto/44408] New: FAIL: gcc.dg/lto/20100603-2 c_lto_20100603-2_0.o-c_lto_20100603-2_0.o

[hjl dot tools at gmail dot com]

On Linux/ia32, revision 160229 gave:

FAIL: gcc.dg/lto/20100603-2 c_lto_20100603-2_0.o-c_lto_20100603-2_0.o link, -O0
-fwhopr (internal compiler error)
FAIL: gcc.dg/lto/20100603-2 c_lto_20100603-2_0.o-c_lto_20100603-2_0.o link, -O2
-fwhopr (internal compiler error)
FAIL: gcc.dg/lto/20100603-3 c_lto_20100603-3_0.o-c_lto_20100603-3_0.o link, -O0
-fwhopr (internal compiler error)
FAIL: gcc.dg/lto/20100603-3 c_lto_20100603-3_0.o-c_lto_20100603-3_0.o link, -O2
-fwhopr (internal compiler error)


-- 
   Summary: FAIL: gcc.dg/lto/20100603-2 c_lto_20100603-2_0.o-
c_lto_20100603-2_0.o
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

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

[gcc at breakpoint dot cc]

--- Comment #5 from gcc at breakpoint dot cc  2010-06-03 20:17 ---
>So clearly the caller's assembly is wrong; it should be saving all 64-bits of
>r9 (volatile gpr) first.

Yes, that it what I've been pointing out. There is an optimization in the stack
code which uses 32bit stores/loads if no double types are used.
I looks to me like the functions branch and register saves are done by the RTL
and it does not know about the 64bit GPRs here. This is only a guess, I'm not a
gcc guy.


-- 


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

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

[Kyle dot D dot Moffett at boeing dot com]

--- Comment #6 from Kyle dot D dot Moffett at boeing dot com  2010-06-03 
20:21 ---
Created an attachment (id=20823)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20823&action=view)
Combined trivial testcase (For -O0)


-- 


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

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

[Kyle dot D dot Moffett at boeing dot com]

--- Comment #7 from Kyle dot D dot Moffett at boeing dot com  2010-06-03 
20:22 ---
Created an attachment (id=20824)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20824&action=view)
Multipart trivial testcase (For -O3)


-- 


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

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

[Kyle dot D dot Moffett at boeing dot com]

--- Comment #8 from Kyle dot D dot Moffett at boeing dot com  2010-06-03 
20:22 ---
Created an attachment (id=20825)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20825&action=view)
Multipart trivial testcase (For -O3) part 2


-- 


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

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

[Kyle dot D dot Moffett at boeing dot com]

--- Comment #9 from Kyle dot D dot Moffett at boeing dot com  2010-06-03 
20:22 ---
Created an attachment (id=20826)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20826&action=view)
Multipart trivial testcase (For -O3) part 3


-- 


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