[Bug tree-optimization/28798] remove_phi_node attempts removal of a phi node resized by resize_phi_node

[pinskia at gmail dot com]

--- Comment #5 from pinskia at gmail dot com  2006-08-23 15:16 ---
Subject: Re:  remove_phi_node attempts removal
of a phi node resized by resize_phi_node

On Wed, 2006-08-23 at 13:40 +, hosking at cs dot purdue dot edu
wrote:
 
 --- Comment #4 from hosking at cs dot purdue dot edu  2006-08-23 13:40 
 ---
 Here is a stack trace showing call to resize_phi_node from execute_pre.

Do you have a testcase or is this with a modified compiler?

-- Pinski


-- 


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

[Bug c/29186] optimzation breaks floating point exception flag reading

[pinskia at gmail dot com]

--- Comment #11 from pinskia at gmail dot com  2006-09-24 00:34 ---
Subject: Re:  optimzation breaks floating point exception flag
reading

On Sat, 2006-09-23 at 23:02 +, joseph at codesourcery dot com wrote:
 In that case you have a bug that is not a duplicate of the lack of 
 FENV_ACCESS pragma support.  The relevant semantics are meant to be 
 supported by these command line options.

This is a TER bug then and I really doubt it can be fixed easy.

-- Pinski


-- 


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

[Bug c++/29455] Issues with -Wchar-subscripts

[pinskia at gmail dot com]

--- Comment #4 from pinskia at gmail dot com  2006-10-14 18:08 ---
Subject: Re:  Issues with -Wchar-subscripts

On Sat, 2006-10-14 at 17:52 +, h dot b dot furuseth at usit dot uio
dot no wrote:
  Also you forgot one thing '%' does not have to match up with the ANSI
  character set so it could be negative in signed char which means char
  (which could default to signed char) would be different.
 
 No.  In a conforming C implementation, the character *which C interprets
 as '%'* must have a positive value.  Maybe you are thinking of the
 opposite case:  What its glyph _looks like_ on some display device is out
 of scope for the C standard.

But at this point, we are talking about C++ where 'a' is of type char.
I have to look at what the C++ standard says about this.

-- Pinski


-- 


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

[Bug c++/29469] [DR 224] error: non-template 'pair' used as template

[pinskia at gmail dot com]

--- Comment #6 from pinskia at gmail dot com  2006-10-14 18:26 ---
Subject: Re:  [DR 224] error: non-template 'pair' used as
template

On Sat, 2006-10-14 at 18:25 +, pinskia at gcc dot gnu dot org wrote:
 
 --- Comment #5 from pinskia at gcc dot gnu dot org  2006-10-14 18:25 
 ---
 DR 224 says this is invalid code 

Sorry valid code.

-- Pinski


-- 


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

[Bug c++/2316] g++ fails to overload on language linkage

[pinskia at gmail dot com]

--- Comment #14 from pinskia at gmail dot com  2006-10-15 03:29 ---
Subject: Re:  g++ fails to overload on language linkage

On Sun, 2006-10-15 at 03:24 +, gcc-bugzilla at kayari dot org wrote:
 
 --- Comment #13 from gcc-bugzilla at kayari dot org  2006-10-15 03:24 
 ---
 If this ever gets fixed (which I hope it does) then maybe it should depend on
 -std=c++98 so this continues to work by default, or it will break a lot of 
 code
 that incorrectly passes extern C++ functions to e.g. pthread_create and
 sigaction.  That's a lot of code.
The problem is -std=c++98 vs no options should not produce different
code which can happen as shown in this bug already, that we have wrong
code.

-- Pinski


-- 


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

[Bug middle-end/29478] [4.2 Regression] optmization generates warning for casts

[pinskia at gmail dot com]

--- Comment #8 from pinskia at gmail dot com  2006-10-23 21:37 ---
Subject: Re:  [4.2 Regression] optmization generates warning for casts

On 23 Oct 2006 17:30:22 -, amylaar at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
 I think it is wrong that we are optimizing the expression before converting
 it to the required type.
 Moreover, why is it right to drop NOP_EXPRESSIONS there?  If for some reason
 the compiler finds it needs to put the initializer in a temporary variable,
 and uses the type of the value for that variable, we'll get an alias set
 problem.

Hmm, This is one of the language hooks which really need to go away
for LTO as I understand it.  Also I the real problem comes from the
inliner or the gimplifier (I am betting the gimplifier) removing the
cast as it is useless in our type system.


-- 


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

[Bug middle-end/28915] [4.1 regression] ICE: tree check: expected class 'constant', have 'declaration' (var_decl) in build_vector, at tree.c:973

[pinskia at gmail dot com]

--- Comment #25 from pinskia at gmail dot com  2006-11-14 10:02 ---
Subject: Re:  [4.1 regression] ICE: tree check:
expected class 'constant', have 'declaration' (var_decl) in
build_vector,
at tree.c:973

On Tue, 2006-11-14 at 09:29 +, jakub at gcc dot gnu dot org wrote:
 
 --- Comment #24 from jakub at gcc dot gnu dot org  2006-11-14 09:29 
 ---
 This change breaks bootstrap on x86_64-linux and i386-linux:

This is now PR 29825 and it is an x86 back-end issue about not accepting
the instruction which is valid as far as I can tell as the following asm
instruction is valid:
movl %eax, [EMAIL PROTECTED]

-- Pinski


-- 


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

[Bug debug/28099] loses type in debug info

[pinskia at gmail dot com]

--- Comment #3 from pinskia at gmail dot com  2006-06-24 01:48 ---
Subject: Re:  loses type in debug info


On Jun 23, 2006, at 12:57 PM, Ilya N. Golubev wrote:


 Next time please don't paste the preprocessed source in gccbug or  
 in the
 comments section in bugzilla.

 Please reverse the request to do so in http://gcc.gnu.org/bugs.html
 and update it and its copies included in releases.  In that update
 please also suggest another way to be specific in report.  AFAIK,
 unless was able to perform (generally, very tedious) experimentation
 and figure a short test program, it is the only way to be specific.

You should upload them via the attachment form.


-- Pinski


-- 


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

[Bug middle-end/28075] [4.1 Regression] inliner introduces unnecessary type conversions

[pinskia at gmail dot com]

--- Comment #10 from pinskia at gmail dot com  2006-06-26 16:02 ---
Subject: Re:  [4.1 Regression] inliner introduces unnecessary type conversions


On Jun 26, 2006, at 6:45 AM, danglin at gcc dot gnu dot org wrote:



 --- Comment #7 from danglin at gcc dot gnu dot org  2006-06-26  
 13:45 ---
 This test is still failing on hppa64-hp-hpux11.11.

Yes the test has a simple problem of also matching the type even  
without the (),
I have a fix but I have not applied it yet.

-- Pinski


-- 


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

[Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared

[pinskia at gmail dot com]

--- Comment #3 from pinskia at gmail dot com  2006-07-15 14:56 ---
Subject: Re:  [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC'
undeclared


On Jul 15, 2006, at 10:45 PM, ams at gnu dot org wrote:

 Because the rules in config.gcc say so:

And that is not why, but that is what is causing linux.h being included?
Again why is Linux.h being included?

-- Pinski


-- 


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

[Bug target/29967] wrong code generated with -O2 on sh4-linux

[pinskia at gmail dot com]

--- Comment #3 from pinskia at gmail dot com  2006-11-24 06:32 ---
Subject: Re:  wrong code generated with -O2 on sh4-linux

On Fri, 2006-11-24 at 06:20 +, sugioka at itonet dot co dot jp
wrote:
 
 --- Comment #2 from sugioka at itonet dot co dot jp  2006-11-24 06:20 
 ---
 This code is reduced from gcc/java/expr.c(add_type_assertion).
 jc1 is really miscompiled on sh4-linux, so bootstrapping
 libgcj fails with segmentation fault in jc1.
 
 Should gcc/java/expr.c be fixed ?

Yes it should.

A warning is hard here unless we change the warning to be based on the
flow. 

Thanks,
Andrew Pinski


-- 


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

[Bug target/29990] Linking fails because __ZdlPv can't be a weak definition

[pinskia at gmail dot com]

--- Comment #3 from pinskia at gmail dot com  2006-11-27 04:51 ---
Subject: Re:  Linking fails because __ZdlPv can't be a
weak definition

On Mon, 2006-11-27 at 04:49 +, pinskia at gcc dot gnu dot org wrote:
 
 --- Comment #2 from pinskia at gcc dot gnu dot org  2006-11-27 04:49 
 ---
 I don't think you can use -flat_namespace with dynamic libraries and 
 libstdc++.

Also I don't think this is a GCC issue.  I think it is an user issue,
and it is harder to reproduce without full sources.

-- Pinski


-- 


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

[Bug c++/14329] [tree-ssa] badly formatted warnings for SRA replacements used uninitialized

[pinskia at gmail dot com]

--- Comment #16 from pinskia at gmail dot com  2006-11-27 05:51 ---
Subject: Re:  [tree-ssa] badly formatted warnings for SRA
replacements used uninitialized

On Mon, 2006-11-27 at 05:46 +, pinskia at gcc dot gnu dot org wrote:
 That fixed most of the failures but there are still some ICEs that need to be
 fixed.

I have a fix for those ICEs, it is just checking for DECL_P.

-- Pinski


-- 


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

[Bug tree-optimization/29922] [4.3 Regression] [Linux] ICE in insert_into_preds_of_block

[pinskia at gmail dot com]

--- Comment #12 from pinskia at gmail dot com  2006-11-27 17:23 ---
Subject: Re:  [4.3 Regression] [Linux] ICE in
insert_into_preds_of_block

On Mon, 2006-11-27 at 08:06 +, pinskia at gcc dot gnu dot org wrote:
 
 --- Comment #11 from pinskia at gcc dot gnu dot org  2006-11-27 08:06 
 ---
 Here is the patch which fixes the PHI issue but I don't know if it will always
 fix the PRE issue but I think it will as the PRE issue is always with VOPs:

I am hiding a PRE bug but there is no reason for these PHIs to be there
anyways as far as I can tell so I am still going to submit my patch for
the PHIs but will keep this bug opened.

Thanks,
Andrew Pinski


-- 


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

[Bug tree-optimization/30016] [4.0/4.1/4.2/4.3 Regression] internal compiler error: in convert_move, at expr.c:362

[pinskia at gmail dot com]

--- Comment #4 from pinskia at gmail dot com  2006-11-30 18:10 ---
Subject: Re:  [4.0/4.1/4.2/4.3 Regression]
internal compiler error: in convert_move, at expr.c:362

On Thu, 2006-11-30 at 15:55 +, dimock at csail dot mit dot edu
wrote:

 
 (2a) [portability and performance] The standard way of handling the vector
 extensions in gcc is to make a union of the vector and an array of the same
 size so that the vector can be loaded or unloaded without making use of
 machine-specific (non-portable) intrinsics or builtins.  I noticed that in my
 machine-generated code which used unions everywhere, that gcc was able to
 better optimize code if I took out unions where they were not needed (removing
 unused unions produced different .s files on -mcpu=G4 on a PowerPC, and the
 code with unions removed ran faster.  Performance not checked on pentium/SSE
 since my real target is PPE/SPE.) 

The best portability (and better for performance) way is to make a
temporary variable.  Though unions are not that good for performance.
For SPU, you can use spu_extract/spu_insert to get better performance.

Thanks,
Andrew Pinski
a SPU maintainer (and a Cell guy in gneral)


-- 


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

[Bug c++/30033] ICE on valid with --std=c++0x (static_assert)

[pinskia at gmail dot com]

--- Comment #6 from pinskia at gmail dot com  2006-12-01 18:19 ---
Subject: Re:  ICE on valid with --std=c++0x (static_assert)

On Fri, 2006-12-01 at 11:37 +, pedro dot lamarao at mndfck dot org
wrote:

 Must someone present this to gcc-patches or will you do it yourself?
I am going to do it but during this weekend.

-- Pinski


-- 


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

[Bug c/26542] bogus diagnostic with -pedantic?: format '%p'; expects type 'void*', but argument 2 has type 'A*'

[pinskia at gmail dot com]

--- Comment #8 from pinskia at gmail dot com  2006-12-08 18:17 ---
Subject: Re:  bogus diagnostic with -pedantic?: format '%p';
expects type 'void*', but argument 2 has type 'A*'

On Fri, 2006-12-08 at 11:07 +, vz-gcc at zeitlins dot org wrote:
 Just for my personal education, could you please tell which target(s)
 pass
 char * differently from void * in this context? 

A made up target (at least for now). :)


-- Pinski


-- 


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

[Bug tree-optimization/30126] [4.3 Regression] ICE genautomata.c:6060

[pinskia at gmail dot com]

--- Comment #7 from pinskia at gmail dot com  2006-12-10 01:25 ---
Subject: Re:  [4.3 Regression] ICE
genautomata.c:6060

On Sun, 2006-12-10 at 01:19 +, amacleod at redhat dot com wrote:
 
 --- Comment #6 from amacleod at redhat dot com  2006-12-10 01:19 ---
 Fail in make bootstrap on FC6.
 Starting on r119634 through at least r119668. 
 
 The TER patch pinskia mentions didn't go in until revision 119657 If my notes
 are correct (they could be wrong)... so that couldn't cause a problem in
 r119634
 
 I will take a peek when I get a chance to see if it was me however.

Sorry about that, I miss read what Ben wrote, I thought he had mentioned
it worked with r119634 but no longer with r119668.

Sorry again,
Andrew Pinski


-- 


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

[Bug tree-optimization/30194] [4.3 Regression] gcc.dg/pr19633-1.c fails on the mainline

[pinskia at gmail dot com]

--- Comment #4 from pinskia at gmail dot com  2006-12-13 16:37 ---
Subject: Re:  [4.3 Regression]
gcc.dg/pr19633-1.c fails on the mainline

On Wed, 2006-12-13 at 14:12 +, dnovillo at gcc dot gnu dot org
wrote:
 Works for me with @119760 (mem-ssa) on all arches (x86, x86_64, ia64
 and
 ppc64). 

So, this is about the mainline and not about the mem-ssa branch.  I
don't see why you are looking at the mem-ssa branch's results except to
say something changed on the mainline to expose this issue.

-- Pinski


-- 


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

[Bug libstdc++/30280] SIGSEGV on operator==(valarraybool, bool)

[pinskia at gmail dot com]

--- Comment #9 from pinskia at gmail dot com  2006-12-23 18:50 ---
Subject: Re:  SIGSEGV on operator==(valarraybool,
bool)

On Sat, 2006-12-23 at 11:17 +, gdr at integrable-solutions dot net
wrote:
 
 I don't remember I ever used this funky __builtin_expect.  
 valarray is improving everyday :-(


You most likely did not but assert did :).

-- Pinski


-- 


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

[Bug c++/30348] '#define false FALSE' undefines '#define FALSE false'

[pinskia at gmail dot com]

--- Comment #4 from pinskia at gmail dot com  2007-01-01 23:37 ---
Subject: Re:  '#define false FALSE' undefines '#define FALSE
false'

On Mon, 2007-01-01 at 22:43 +, h8_spam at sonic dot net wrote:
 Right, but since true and false are keywords, I would expect the
 #define true
 TRUE and false FALSE to be no-ops.


How?  Preprocessing happens before tokenazation happens.

-- Pinski


-- 


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

[Bug middle-end/30349] gcc/libssp/ssp.c:177: ICE: in cgraph_expand_all_functions, at cgraphunit.c:1220

[pinskia at gmail dot com]

--- Comment #1 from pinskia at gmail dot com  2007-01-02 01:12 ---
Subject: Re:   New: gcc/libssp/ssp.c:177: ICE: in
cgraph_expand_all_functions, at cgraphunit.c:1220

This should have been fixed by:

2007-01-01  Jan Hubicka  [EMAIL PROTECTED]
   Andrew Pinski  [EMAIL PROTECTED]

   * cgraphunit.c (cgraph_optimize): Call cgraph_add_new_functions
   before starting IPA passes.

-- Pinski


-- 


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

[Bug c/30477] Integer Overflow detection code optimised away, -fwrapv broken

[pinskia at gmail dot com]

--- Comment #4 from pinskia at gmail dot com  2007-01-16 03:04 ---
Subject: Re:  Integer Overflow detection code optimised away,
-fwrapv broken

On Tue, 2007-01-16 at 02:33 +, tg at mirbsd dot org wrote:
 The real shame is an
 attitude of we won't fix it, either use -O0, or upgrade to current
 versions of gcc, which, by the way, are poorly supported and do not
 compile existing¹ programmes correctly at all? 

If you consider 4.0.x a current version of GCC, you must be joking, it
was released on April 20, 2005 almost 2 years ago.


 I specifically did *not* open the bug report against gcc4.
Right but 3.4.x is no longer maintained.  This is like any other project
where old versions are no longer maintained.  Ask for an example Mozilla
to fix a bug in a release branch who's first release was almost three
years ago (FireFox 1.0.x for an example)?  Do you support a release
branch product for three years since you are a person who supports an
OS.  I doubt that you do.  I know of only one project who supports an
release branch for longer debian (5 years or so) and the developers of
debian actually contribute to GCC also and they are able to figure out
what patches they need to backport.  

So how long do you support a release branch of your OS?


 I know of at least qemu
Then fix qemu; x86 has not many registers so it is very easy to get into
a case where inline-asm breaks.



  Also why should we support older GCC when we can barrely support the
  current ones?
As for this comment, I was more talking about the bugs which are minor
or don't effect major targets or even bugs which are not even
regressions.

 Especially you as the author of code in question
I did not write this code, I just know of it.


 Besides,
upgrading gcc involves upgrading g++ which is a PITA, despite it
being an improvement of adhering to the language specification
this BREAKS EXISTING CODE. Not everyone can afford this.

And we get request from users for fixing g++ to adhere to the language
standard;  I can name a few bugs which were not filed by a GCC developer
but would break existing code (and ones which were fixed did that).
So it is a trade off, break existing code or go by the standard.  We
decided it is better to go by the standard and hope people's code is
actually standards based code.  This is the problem with C/C++ right now
is that people don't write standards based code, unlike say Ada, Fortran
(which most do or with very well known extensions) and Java (which is
not officially standardized but there is a specification).  C/C++ are
being taught as if it is not a standardized language and there is not a
specification for it and people don't use specs as a reference.



Thanks,
Andrew Pinski


-- 


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

[Bug fortran/29410] [4.2 only] bug with TRANSFER() and -O2

[pinskia at gmail dot com]

--- Comment #11 from pinskia at gmail dot com  2007-01-22 01:08 ---
Subject: Re:  [4.2 only] bug with TRANSFER() and -O2

On Sun, 2007-01-14 at 11:19 +, pault at gcc dot gnu dot org wrote:
 
 Were you going to apply this to 4.2, together with revision 119211, or
 will you
 close them as fixed on 4.3? 

I am going to test it for 4.2 once I finish testing an objective-C
patch.

-- Pinski


-- 


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

[Bug middle-end/29719] newlib targets ICEs in expand_builtin_int_roundingfn

[pinskia at gmail dot com]

--- Comment #8 from pinskia at gmail dot com  2007-01-28 19:04 ---
Subject: Re:  newlib targets ICEs in
expand_builtin_int_roundingfn

On Wed, 2007-01-24 at 14:22 +, rguenth at gcc dot gnu dot org wrote:
 
 --- Comment #7 from rguenth at gcc dot gnu dot org  2007-01-24 14:22 
 ---
 I'm no longer working on this, but this is a general problem we have with
 builtin functions used internally.  There's currently no way to prevent
 direct usage.

And I think the ICE is a regression at that, I just don't have time to
prove it.

-- Pinski


-- 


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

[Bug tree-optimization/31090] Revision 121302 causes 30% performance regression

[pinskia at gmail dot com]

--- Comment #8 from pinskia at gmail dot com  2007-03-09 23:05 ---
Subject: Re:  Revision 121302 causes 30% performance regression

On 9 Mar 2007 23:00:55 -, rguenth at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:

  Other than that, more precise alias information
 can cause more register pressure, too.

Fix the register allocator instead of complaining about this issue.  I
am sorry but if people want a compiler which works for x86, they just
need to fix the RA.  Now I could care less about x86.

-- Pinski


-- 


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

[Bug middle-end/31249] pseudo-optimzation with sincos/cexpi

[pinskia at gmail dot com]

--- Comment #6 from pinskia at gmail dot com  2007-03-19 17:52 ---
Subject: Re:  pseudo-optimzation with sincos/cexpi

On 19 Mar 2007 12:43:49 -, dominiq at lps dot ens dot fr
[EMAIL PROTECTED] wrote:

 Since sin() and cos() are non trivial functions, I am very surprised
 that a wrong API makes a 50% difference.

Well Here is how it can make a 50% difference (at least on the Cell,
the 970 has less of a restriction and only the dispatch group is
rejected).  Modern PowerPC processors like not to store stuff to the
stack and then load it again with in a number of cycles (cell is
around 50 cycles while the 970 is just within a dispatch group).
Transfering between the integer register set and the floating point
register set can only be done via memory so you will get a LHS or a
LRU reject (depending on what processor you are on).  This can either
cause a 50 cycle delay or reject of the dispatch group (the later can
cause multiple rejects).  The number of cycles used up by this issue
can add up with both sides of the function having this hazard.

Thanks,
Andrew Pinski


-- 


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

[Bug tree-optimization/31136] [4.2 Regression] FRE ignores bit-field truncation (C and C++ front-end don't produce bit-field truncation

[pinskia at gmail dot com]

--- Comment #8 from pinskia at gmail dot com  2007-03-23 07:57 ---
Subject: Re:  [4.2 Regression] FRE ignores bit-field truncation (C and C++
front-end don't produce bit-field truncation

On 23 Mar 2007 05:01:00 -, spark at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
 The problematic STRIP_SIGN_NOPS() call is from fold_unary()
 which is called from try_combine_conversion() in tree-ssa-pre.c.

 STRIP_SIGN_NOPS() is called with the expression:

No, STRIP_SIGN_NOPS is correct, just fold_unary is incorrect in its
folding.  It should have called fold_convert on the expression if the
types are different and it is a constant.

-- Pinski


-- 


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

[Bug tree-optimization/31136] [4.2 Regression] FRE ignores bit-field truncation (C and C++ front-end don't produce bit-field truncation

[pinskia at gmail dot com]

--- Comment #9 from pinskia at gmail dot com  2007-03-23 08:01 ---
Subject: Re:  [4.2 Regression] FRE ignores bit-field truncation (C and C++
front-end don't produce bit-field truncation

On 3/23/07, Andrew Pinski [EMAIL PROTECTED] wrote:
 On 23 Mar 2007 05:01:00 -, spark at gcc dot gnu dot org
 [EMAIL PROTECTED] wrote:
  The problematic STRIP_SIGN_NOPS() call is from fold_unary()
  which is called from try_combine_conversion() in tree-ssa-pre.c.
 
  STRIP_SIGN_NOPS() is called with the expression:

 No, STRIP_SIGN_NOPS is correct, just fold_unary is incorrect in its
 folding.  It should have called fold_convert on the expression if the
 types are different and it is a constant.

Ok, the real issue is that we call fold with
NOP_EXPRNOP_EXPRINTEGER_CST instead of just NOP_EXPRINTEGER_CST
so you have to figure out where we should fold the first NOP_EXPR
instead of that patch.

-- Pinski


-- 


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

[Bug tree-optimization/31862] Loop IM and other optimizations harmful for -fopenmp

[pinskia at gmail dot com]

--- Comment #6 from pinskia at gmail dot com  2007-05-08 15:59 ---
Subject: Re:  Loop IM and other optimizations harmful for -fopenmp

On 8 May 2007 14:44:16 -, dnovillo at acm dot org
[EMAIL PROTECTED] wrote:
 The original code did not have a race condition.  The compiler
 transformations introduced a race-condition.  This *is*  a compiler
 bug.

Actually the original code has a race condition, if another thread is
reading from var and then acting on that and writting back.  This is
why threading programming is considered hard.


-- 


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

[Bug tree-optimization/31862] Loop IM and other optimizations harmful for -fopenmp

[pinskia at gmail dot com]

--- Comment #8 from pinskia at gmail dot com  2007-05-08 19:45 ---
Subject: Re:  Loop IM and other optimizations harmful for -fopenmp

On 8 May 2007 18:08:26 -, jakub at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:


 --- Comment #7 from jakub at gcc dot gnu dot org  2007-05-08 19:08 ---
 This really is not specific to OpenMP, I believe the following is valid
 threaded program:

This is not a valid program.  You have to introduce mutexes to get it
to be a valid program with threads.  This is a common misunderstanding
of thread programming.


-- 


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

[Bug c++/58772] __attribute__((aligned(16))) and nested classes cause -ftree-vectorize to generate segfaulting code

[pinskia at gmail dot com]

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

--- Comment #6 from pinskia at gmail dot com pinskia at gmail dot com ---
Sent from my iPad

 On Oct 21, 2013, at 2:35 AM, burnus at gcc dot gnu.org 
 gcc-bugzi...@gcc.gnu.org wrote:
 
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58772
 
 Tobias Burnus burnus at gcc dot gnu.org changed:
 
   What|Removed |Added
 
 CC||burnus at gcc dot gnu.org
 
 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org ---
 (In reply to Richard Biener from comment #3)
 The syntax would be
  ::posix_memalign (act, 16, sizeof (Actor));
 
 Or
  #include mm_malloc.h
  ...
  act = _mm_malloc, sizeof (Actor), 16);
 which is supposed to be a bit more portable. (mm_malloc.h ships with GCC since
 4.0, if I recall correctly.)


Less portable as that only works on x86 while posix_memalign works on all posix
targets.

[Bug bootstrap/54304] linking stage picks up system mpfr instead of in-tree version

[pinskia at gmail dot com]

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

--- Comment #1 from pinskia at gmail dot com pinskia at gmail dot com 
2012-08-17 19:13:50 UTC ---
This is a darwin only issue.
On Aug 17, 2012 12:07 PM, tobi at gcc dot gnu.org 
gcc-bugzi...@gcc.gnu.org wrote:

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

  Bug #: 54304
Summary: linking stage picks up system mpfr instead of in-tree
 version
 Classification: Unclassified
Product: gcc
Version: 4.8.0
 Status: UNCONFIRMED
   Severity: normal
   Priority: P3
  Component: bootstrap
 AssignedTo: unassig...@gcc.gnu.org
 ReportedBy: t...@gcc.gnu.org


 This is an old bug, I found mention of it all over the internet, and also
 on
 the gcc mailing list http://gcc.gnu.org/ml/gcc-help/2011-04/msg00126.html
 .

 What happens is that with an in-tree gmp, mpfr, mpc (I used
 contrib/download_prerequisites) the linking stage picks up the system
 libraries
 instead of the in-tree versions.  This causes a problem when the system
 libmpfr
  3.0.0 and the in-tree version is = 3.0.0 and vice versa, because
 mpfr_get_z_exp was renamed to mpfr_get_z_2exp between the two (hidden
 behind a
 macro).  The error I'm seeing with today's tree is:

 /Users/tobi/src/gcc/build/./prev-gcc/g++
 -B/Users/tobi/src/gcc/build/./prev-gcc/
 -B/usr/local/x86_64-apple-darwin11.4.0/bin/ -nostdinc++

 -B/Users/tobi/src/gcc/build/prev-x86_64-apple-darwin11.4.0/libstdc++-v3/src/.libs

 -B/Users/tobi/src/gcc/build/prev-x86_64-apple-darwin11.4.0/libstdc++-v3/libsupc++/.libs

 -I/Users/tobi/src/gcc/build/prev-x86_64-apple-darwin11.4.0/libstdc++-v3/include/x86_64-apple-darwin11.4.0

 -I/Users/tobi/src/gcc/build/prev-x86_64-apple-darwin11.4.0/libstdc++-v3/include
 -I/Users/tobi/src/gcc/libstdc++-v3/libsupc++

 -L/Users/tobi/src/gcc/build/prev-x86_64-apple-darwin11.4.0/libstdc++-v3/src/.libs

 -L/Users/tobi/src/gcc/build/prev-x86_64-apple-darwin11.4.0/libstdc++-v3/libsupc++/.libs
   -g -O2 -mdynamic-no-pic -gtoggle -DIN_GCC   -fno-exceptions -fno-rtti -W
 -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
 -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
 -Werror
 -fno-common  -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -Wl,-no_pie
 -o
 f951 \
 fortran/arith.o fortran/array.o fortran/bbt.o
 fortran/check.o
 fortran/class.o fortran/constructor.o fortran/cpp.o fortran/data.o
 fortran/decl.o fortran/dump-parse-tree.o fortran/error.o fortran/expr.o
 fortran/interface.o fortran/intrinsic.o fortran/io.o fortran/iresolve.o
 fortran/match.o fortran/matchexp.o fortran/misc.o fortran/module.o
 fortran/openmp.o fortran/options.o fortran/parse.o fortran/primary.o
 fortran/resolve.o fortran/scanner.o fortran/simplify.o fortran/st.o
 fortran/symbol.o fortran/target-memory.o darwin-f.o fortran/convert.o
 fortran/dependency.o fortran/f95-lang.o fortran/trans.o
 fortran/trans-array.o
 fortran/trans-common.o fortran/trans-const.o fortran/trans-decl.o
 fortran/trans-expr.o fortran/trans-intrinsic.o fortran/trans-io.o
 fortran/trans-openmp.o fortran/trans-stmt.o fortran/trans-types.o
 fortran/frontend-passes.o libbackend.a main.o tree-browser.o
 libcommon-target.a
 libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a
 ../libcpp/libcpp.a -lintl -L/opt/local/lib -liconv
  ../libiberty/libiberty.a
 ../libdecnumber/libdecnumber.a  attribs.o
 -L/Users/tobi/src/gcc/build/./gmp/.libs
 -L/Users/tobi/src/gcc/build/./mpfr/.libs
 -L/Users/tobi/src/gcc/build/./mpc/src/.libs -lmpc -lmpfr -lgmp   -L../zlib
 -lz
 Undefined symbols for architecture x86_64:
   _mpfr_get_z_exp, referenced from:
   gfc_mpfr_to_mpz(__mpz_struct*, __mpfr_struct*, locus*) in arith.o
 ld: symbol(s) not found for architecture x86_64
 collect2: error: ld returned 1 exit status
 make[3]: *** [f951] Error 1
 make[2]: *** [all-stage2-gcc] Error 2
 make[1]: *** [stage2-bubble] Error 2
 make: *** [all] Error 2

 (I mentioned this in the aftermath to PR54292)

 Cheers

[Bug ipa/58279] Interanl compiler error while pgo compilation at ipa-inline.c:902

[pinskia at gmail dot com]

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

--- Comment #3 from pinskia at gmail dot com pinskia at gmail dot com ---
I have a fix which I hope to share in the next few weeks.

Sent from my iPad

On Aug 30, 2013, at 3:31 AM, evstupac at gmail dot com
gcc-bugzi...@gcc.gnu.org wrote:

 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58279
 
 --- Comment #2 from Stupachenko Evgeny evstupac at gmail dot com ---
 I can't share CoreMark sources.
 However, you can get them at www.coremark.org when accept the license.
 
 The error caused by edge-count of new edges which is grater than max_count:
 (line 902)
 gcc_assert (max_count = edge-count);
 
 The new edge is generated in case of indirect inline:
 
 (line 1517)
 if (flag_indirect_inlining)
  new_indirect_edges.create (8);
 
 and does not participate in max_count calculation, but refers to it when 
 adding
 to a heap:
 
 (lines 1724 and 1761)
 if (flag_indirect_inlining)
  add_new_edges_to_heap (edge_heap, new_indirect_edges);
 
 Updating max_count with new_edges counts resolves the ICE.

[Bug c/58454] Potentially wrong(or at least weird/inconsistent) code generation with -O2 -fno-strict-overflow

[pinskia at gmail dot com]

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

--- Comment #1 from pinskia at gmail dot com pinskia at gmail dot com ---
All of these functions overflow the loop induction variable so only -fwrapv
will provide the behavior you want for all of the functions.  The inconsistent
behavior is due to the overflows happening for induction variables.  If it was
not an induction variable then -fno-strict-overflow would have
worked..-fno-strict-overflow is only defined to work for non loop variables.

Thanks,
Andrew

On Sep 17, 2013, at 6:28 PM, mednafen at gmail dot com
gcc-bugzi...@gcc.gnu.org wrote:

 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58454
 
Bug ID: 58454
   Summary: Potentially wrong(or at least weird/inconsistent) code
generation with -O2 -fno-strict-overflow
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mednafen at gmail dot com
 
 Created attachment 30844
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30844action=edit
 Testcase program.
 
 Working:
 XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -Wall -O0 -o halt halt.c 
 XXX@willow:~/halt$ ./halt 
 IMm3: 
 IMm2: ***
 IMm1: **
 IM: *
 
 
 :
 XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -Wall -O2 -o halt halt.c 
 XXX@willow:~/halt$ ./halt 
 IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3:
 IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: 
 IMm3:
 IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: 
 IMm3:
 IMm3: Aborted
 
 
 Working:
 XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -Wall -O2
 -fno-aggressive-loop-optimizations -o halt halt.c
 XXX@willow:~/halt$ ./halt 
 IMm3:
 Aborted
 
 
 Broken:
 XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -Wall -O2 -fno-strict-overflow
 -o halt halt.c 
 XXX@willow:~/halt$ ./halt 
 IMm3: 
 IMm2: ***
 IMm1:
 *Aborted
 
 
 Broken:
 XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -Wall -O2
 -fno-aggressive-loop-optimizations -fno-strict-overflow -o halt halt.c 
 XXX@willow:~/halt$ ./halt 
 IMm3: 
 IMm2: ***
 IMm1:
 *Aborted
 
 
 Working:
 XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -Wall -O2 -fno-strict-overflow
 -fno-tree-vrp -o halt halt.c
 XXX@willow:~/halt$ ./halt
 IMm3: 
 IMm2: ***
 IMm1: **
 IM: *
 
 
 Working:
 XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -Wall -O2 -fno-strict-overflow
 -fwrapv -o halt halt.c
 XXX@willow:~/halt$ ./halt 
 IMm3: 
 IMm2: ***
 IMm1: **
 IM: *
 
 
 XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -v
 Using built-in specs.
 COLLECT_GCC=/usr/local/gcc-4.8.1/bin/gcc
 COLLECT_LTO_WRAPPER=/usr/local/gcc-4.8.1/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper
 Target: x86_64-unknown-linux-gnu
 Configured with: ../gcc-4.8.1/configure --prefix=/usr/local/gcc-4.8.1
 Thread model: posix
 gcc version 4.8.1 (GCC)

[Bug tree-optimization/60533] [4.8/4.9 regression] Error introduced by cunrolli pass at -O3

[pinskia at gmail dot com]

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

--- Comment #10 from pinskia at gmail dot com pinskia at gmail dot com ---
 On Mar 15, 2014, at 7:59 PM, wschmidt at gcc dot gnu.org 
 gcc-bugzi...@gcc.gnu.org wrote:
 
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60533
 
 --- Comment #7 from Bill Schmidt wschmidt at gcc dot gnu.org ---
 The problem is actually introduced much earlier, during the cunrolli (complete
 unroll inner) pass.  I'm attaching dumps from 055t.copyrename2 and
 056t.cunrolli to show what happens.  Prior to unrolling, we have a loop formed
 by blocks 47,19,20,...,46, with the original call to makeUnion at the end of
 block 45.  The unroller decides that this loop will be executed exactly 3 
 times
 and unrolls it completely.  (It's not clear to me on what basis this decision
 is made in the first place; it doesn't seem justified on the surface.)

What is the type of bc?  That access to bc in bb 46 looks like to be the cause. 

What is the original code look like, do we have an out of bounds access here or
just a miscombining to create one?

Thanks,
Andrew


 
 In any case, the third copy of the loop comprises blocks 74 through 101, with
 the call to makeUnion duplicated at the end of block 100.  The unroller then
 inserts a __builtin_unreachable at the end of block 101 for some reason.  This
 survives until the rewrite into RTL, at which point it is converted to the
 barrier that causes the bad block reordering.

[Bug bootstrap/38693] gcc 4.4.0 20090101 - gcc/config/i386/sol2-10.h uses USE_GAS which is undefined

[pinskia at gmail dot com]

--- Comment #5 from pinskia at gmail dot com  2009-01-06 03:32 ---
Subject: Re:  gcc 4.4.0 20090101 - gcc/config/i386/sol2-10.h uses USE_GAS
which is undefined


On Jan 5, 2009, at 7:01 PM, rob1weld at aol dot com gcc-bugzi...@gcc.gnu.org 
  wrote:



 --- Comment #4 from rob1weld at aol dot com  2009-01-06 03:01  
 ---
 (In reply to comment #3)
 And this is documented in the installation documentation.
 (Confusion may also result if the compiler finds the GNU assembler  
 but has not
 been configured with --with-gnu-as.)

 http://gcc.gnu.org/install/configure.html


 # ../gcc_trunk/configure --help | grep with-gnu-as


It is an option for the gcc subdirctory configure and not the toplevel  
configure.


 Since --with-gnu-as is removed from the help I though you were  
 trying to
 encourage automatic detection (and thus the testing of same) so I  
 left off
 -with-gnu-as thinking that since configure chose it's as it  
 ought to
 know which one it picked ...


 -- 


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



-- 


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

[Bug c++/38759] Incorrect warning/error when compiling with a typedef'ed ptr return type

[pinskia at gmail dot com]

--- Comment #1 from pinskia at gmail dot com  2009-01-07 21:15 ---
Subject: Re:   New: Incorrect warning/error when compiling with a typedef'ed
ptr return type



On Jan 7, 2009, at 12:44 PM, gnu at bluedreamer dot com
gcc-bugzi...@gcc.gnu.org 
  wrote:

 When a pointer to type is typedef'ed to a new type gcc incorrectly  
 warns about
 const modifier if new typedef is used in function return type.

 gcc info:
 dluadrianc:/home/adrianc gcc -v
 Using built-in specs.
 Target: i686-pc-linux-gnu
 Configured with: ../gcc-4.3.1/configure --prefix=/usr --enable- 
 languages=c,c++
 --enable-shared --enable-threads=posix
 Thread model: posix
 gcc version 4.3.1 (GCC)

 Command line:g++ -save-temps -Wall -ansi -Wextra -pedantic -Werror  
 const.cc
 Error message:
 cc1plus: warnings being treated as errors
 const.cc:10: error: type qualifiers ignored on function return type

 Code
 # 1 const.cc
 # 1 built-in
 # 1 command-line
 # 1 const.cc
 class Foo { };

 const Foo *func1()
 {
   return 0;
 }

 typedef Foo* Bar;

 const Bar func2()

The const here is applying to the pointer type and not what the  
pointer points to so the warning is correct.


 {
   return 0;
 }

 int main(int , char *[])
 {
   func1();
   func2();

   return 0;
 }


 -- 
   Summary: Incorrect warning/error when compiling with a  
 typedef'ed
ptr return type
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gnu at bluedreamer dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
 GCC target triplet: i686-pc-linux-gnu


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



-- 


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

[Bug c++/38761] %s substituted with regular word can't be properly translated

[pinskia at gmail dot com]

--- Comment #1 from pinskia at gmail dot com  2009-01-07 21:39 ---
Subject: Re:   New: %s substituted with regular word can't be properly
translated

Well template here might be consider the keyword template.  So we  
either have template argument or just argument. Translating template  
might cause more confusion.

Sent from my iPhone

On Jan 7, 2009, at 1:34 PM, goeran at uddeborg dot se
gcc-bugzi...@gcc.gnu.org 
  wrote:

 In gcc/cp/parser.c there is this code in  
 cp_parser_parameter_declaration

error (%H%sparameter pack %qD cannot have a default  
 argument,
   declarator_token_start-location,
   kind, id_declarator-u.id.unqualified_name);
  else
error (%H%sparameter pack cannot have a default argument,
   declarator_token_start-location, kind);

 where kind has previously been assigned either the empty string or  
 the word
 template followed by a space.  There is no way to translate the word
 template.  For this to work in all languages, I suspect the two  
 messages
 needs to be split up in four complete messages, with and without  
 template,
 rather than composed from pieces like this.


 -- 
   Summary: %s substituted with regular word can't be properly
translated
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: goeran at uddeborg dot se


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



-- 


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

[Bug other/38768] man page: -fschedule-insns documentation

[pinskia at gmail dot com]

--- Comment #2 from pinskia at gmail dot com  2009-01-08 18:27 ---
Subject: Re:  man page: -fschedule-insns documentation



On Jan 8, 2009, at 9:44 AM, tim at klingt dot org gcc-bugzi...@gcc.gnu.org 
  wrote:



 --- Comment #1 from tim at klingt dot org  2009-01-08 17:44  
 ---
 Created an attachment (id=17057)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17057action=view)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17057action=view)
 proposed patch


This patch is incorrect as -fschedule-insns is enabled at -O2 and  
above for most targets except for x86.




 -- 


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



-- 


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

[Bug c++/38764] bogus 'changes meaning' error?

[pinskia at gmail dot com]

--- Comment #3 from pinskia at gmail dot com  2009-01-08 19:16 ---
Subject: Re:   New: bogus 'changes meaning' error?


On Jan 8, 2009, at 4:22 AM, pluto at agmk dot net gcc-bugzi...@gcc.gnu.org 
  wrote:

 following code snipet is reducted testcase from external application.
 g++ and comeau online accept/reject source differently.

 template  class T 
 struct A
 {
 };
 template  class U 
 struct B
 {
 #if 1
typedef A float  A; // -- accepted by comeau but...
// g++: error: declaration of typedef struct Afloat BU::A
// g++: error: changes meaning of A from struct Afloat
 #else
typedef ::A float  A; // -- accepted by g++ but...
// comeau: class member typedef may not be redeclared
// typedef ::A float  A;
//  ^
 #endif
 };

GCC is correct.  This code is invalid but the standard says for this  
case no diagnostic is required so both compilers are correct according  
to the standard. Just that edg could be enchened to error about this  
case.





 -- 
   Summary: bogus 'changes meaning' error?
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net


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



-- 


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

[Bug bootstrap/35211] Dist tarball is missing (Bison-generated) java/parse-scan.c

[pinskia at gmail dot com]

--- Comment #4 from pinskia at gmail dot com  2009-01-11 00:11 ---
Subject: Re:  Dist tarball is missing (Bison-generated) java/parse-scan.c



On Jan 10, 2009, at 3:59 PM, rob1weld at aol dot com
gcc-bugzi...@gcc.gnu.org 
  wrote:



 --- Comment #3 from rob1weld at aol dot com  2009-01-10 23:59  
 ---
 (In reply to comment #1)
 Is this still true in newer GCC releases?  Also this was removed in  
 4.3 and
 above.
 Yes, on trunk. Searching for dupe before starting a new Bug Report,  
 came here.

 We might close this Bug with a comment on the Prerequisites page  
 that you
 _might_ need bison in the event that you (or a Makefile, broken or  
 otherwise)
 modify a `.y' file.


 This webpage does not mention the program bison:

 Prerequisites for GCC
 http://gcc.gnu.org/install/prerequisites.html



We only require yacc (bison is a yacc) when compiling GCC from the svn  
or from the snapshots. Plus most os's already contain a yacc.


 # prev-gcc/xgcc -v
 Using built-in specs.
 Target: i386-pc-solaris2.11
 Configured with: ../gcc_trunk/configure
 --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared
 --disable-static --enable-decimal-float --with-long-double-128 -- 
 enable-nls
 --with-included-gettext --enable-gather-detailed-mem-stats --with- 
 stabs
 --enable-debug -enable-largefile --enable-symvers --without-system- 
 zlib
 --enable-gtk-cairo --enable-qt-peer --enable-xmlj --enable-gconf-peer
 --enable-gjdoc --enable-java-awt=gtk,xlib,qt,x --enable-gc-debug
 --enable-libgcj-multifile --enable-libgcj-debug --enable-objc-gc
 --enable-libstdcxx-debug --enable-stage1-checking --enable- 
 checking=release
 --without-system-libunwind --with-gnu-as --with-as=/usr/local/bin/as
 --with-gnu-ld --with-ld=/usr/local/bin/ld
 Thread model: posix
 gcc version 4.4.0 20090109 (experimental) (GCC)


 # gmake
 ...
 gmake[3]: Leaving directory `/usr/share/src/gcc_build/libiberty'
 gmake[3]: Entering directory `/usr/share/src/gcc_build/intl'
 rm -f stamp-h1
 /bin/sh ./config.status config.h
 config.status: creating config.h
 config.status: config.h is unchanged
 test -f config.h || (rm -f stamp-h1  gmake stamp-h1)
 cp ../../gcc_trunk/intl/libgnuintl.h libintl.h
 /usr/share/src/gcc_build/./prev-gcc/xgcc ...
 ...
 /usr/share/src/gcc_build/./prev-gcc/xgcc -B/usr/share/src/ 
 gcc_build/./prev-gcc/
 -B/usr/local/i386-pc-solaris2.11/bin/ -c -fexceptions -g -O2 - 
 fprofile-use
 -DHAVE_CONFIG_H  -I. -I../../gcc_trunk/intl ../../gcc_trunk/intl/ 
 ngettext.c
 ../../gcc_trunk/intl/ngettext.c: In function ‘libintl_ngettext’:
 ../../gcc_trunk/intl/ngettext.c:63: note: file
 /usr/share/src/gcc_build/intl/ngettext.gcda not found, execution  
 counts
 estimated
 bison -y --name-prefix=__gettext --output plural.c
 ../../gcc_trunk/intl/plural.y
 rm -f plural.h
 /usr/share/src/gcc_build/./prev-gcc/xgcc -B/usr/share/src/ 
 gcc_build/./prev-gcc/
 -B/usr/local/i386-pc-solaris2.11/bin/ -c -fexceptions -g -O2 - 
 fprofile-use
 -DHAVE_CONFIG_H  -I. -I../../gcc_trunk/intl plural.c
 ...


 I did not modify a `.y' file or play with this part of the code. The  
 reason
 that I require bison is either:

 1. I 'hit it' with my configure option combination and found an  
 untried path.
 2. Typing make distclean removed a file (I did not see that happen).
 3. Something is broken and bison was not really needed.
 4. The Prerequisites for GCC is incorrect, we do need bison.

 Rob


 -- 


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



-- 


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

[Bug fortran/38823] Diagnose and treat (-2.0)**2.0 properly

[pinskia at gmail dot com]

--- Comment #1 from pinskia at gmail dot com  2009-01-13 11:28 ---
Subject: Re:   New: Diagnose and treat (-2.0)**2.0 properly

On Jan 13, 2009, at 3:08 AM, burnus at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org 
  wrote:

 Found at:
 http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/0f1d7da66fa015c2

  print *, (-2.0)**2.0
  end
 is invalid. gfortran should print a diagnostic for -std=f95/f2003/ 
 f2008 as NAG
 f95 does:
  Error: Negative floating-point value raised to a real power

 Fortran 2003 in the second sentence of the second paragraph of 7.1.8
 Evaluation of Operations:

  Raising a negative-valued primary of type real to a real power is
   prohibitted.

 The question is whether one needs to reject it completely or only with
 -std=f95. Steve (see thread) thinks the constant folding gets it wrong
 (- gives 4.0).

 Current results:
 - Runtime and compile time evaluation (ifort, gfortran, g95):
  -2.0**2.0 = 4.0
  -2.0**1.9 = NaN
 - Mathematica:
  -2^2 = 4, -2.0^2.0 = -4.0
  2.0^1.9 = -3.73213

-2.0^1.9 will be a complex number.  Maybe we can define it as taking  
the real part. I don't know if that is better than generating a nan  
here.

Thanks,
Andrew Pinski





 -- 
   Summary: Diagnose and treat (-2.0)**2.0 properly
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: diagnostic
  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=38823



-- 


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

[Bug java/38827] gcj emitting incorrect code

[pinskia at gmail dot com]

--- Comment #1 from pinskia at gmail dot com  2009-01-13 19:22 ---
Subject: Re:   New: gcj emitting incorrect code



On Jan 13, 2009, at 8:03 AM, tschwinge at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org 
  wrote:

 I originally found this problem when trying to compile a Java  
 package written
 by the Universität Stuttgart's institute IKR.  I was using Debian's  
 gcj
 package, version 4.3.2-2, but can likewise reproduce this using SVN  
 trunk, as
 well as Debian's 4.2.4-4 package.

 I completely reduced the test case to the following:

public class Bug_Class
{
}

public interface Bug_Interface
{
}

public class Bug
{
public X extends Bug_Class  Bug_Interface Bug(X x)
{
set(x);
}

public void set(Bug_Interface x)
{
}
}

 Directly compiling this will fail as follows:

$ ~/GCC/trunk.build.64.install/bin/gcj -c Bug.java
Bug.java: In class 'Bug':
Bug.java: In constructor '(Bug_Class)':
In file included from built-in:3:
Bug.java:3: error: verification failed at PC=9: incompatible type  
 on stack

 gcj is able to emit a class file, but that one is considered non- 
 verifying by
 the BCEL verifier:

This sounds like a bug in the eclispe source to bytecode compiler  
which gcj uses now.






[...]
Pass 3b, method number 0 ['public void init(Bug_Class arg1)
 [Signature(E:LBug_Class;:LBug_Interface;(TE;)V)]']:
VERIFIED_REJECTED
Constraint violated in method 'public void init(Bug_Class arg1)
 [Signature(E:LBug_Class;:LBug_Interface;(TE;)V)]':
Instruction INVOKEVIRTUAL constraint violated: Expecting a  
 'Bug_Interface'
 but found a 'Bug_Class' on the stack (which is not assignment  
 compatible).
InstructionHandle:6: invokevirtual[182](3) 13
[...]

 What Sun's javac does differently (as per class-file disassembly  
 inspection) is
 emitting a checkcast against class Bug_Interface before calling  
 invokevirtual.


 -- 
   Summary: gcj emitting incorrect code
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tschwinge at gcc dot gnu dot org


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



-- 


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

[Bug middle-end/38856] loop iv detection failure

[pinskia at gmail dot com]

--- Comment #6 from pinskia at gmail dot com  2009-01-16 11:46 ---
Subject: Re:  loop iv detection failure



Sent from my iPhone

On Jan 16, 2009, at 1:57 AM, rguenth at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org 
  wrote:



 --- Comment #5 from rguenth at gcc dot gnu dot org  2009-01-16  
 09:57 ---
 I think this boils down to the usual POINTER_PLUS fallout.

It failed in 4.1 also so nope :).




 -- 


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



-- 


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

[Bug tree-optimization/38835] field-insensitive PTA causes libstdc++ miscompiles

[pinskia at gmail dot com]

--- Comment #5 from pinskia at gmail dot com  2009-01-16 18:33 ---
Subject: Re:  field-insensitive PTA causes libstdc++ miscompiles

On Fri, Jan 16, 2009 at 10:30 AM, rguenth at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org wrote:

 (void *)((intptr_t)iptr + (intptr_t)p - (intptr_t)iptr)

 ==

 (void *)(intptr_t)p

 which is guaranteed by the std

No that is not guaranteed because of:
If the result cannot be represented in the integer type, the behavior
is undefined. The result need not be in the range of values of any
integer
type.

:).


-- 


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

[Bug tree-optimization/38835] [4.4 Regression] field-insensitive PTA causes libstdc++ miscompiles

[pinskia at gmail dot com]

--- Comment #8 from pinskia at gmail dot com  2009-01-16 18:44 ---
Subject: Re:  field-insensitive PTA causes libstdc++ miscompiles

On Fri, Jan 16, 2009 at 10:37 AM, rguenth at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org wrote:


 --- Comment #6 from rguenth at gcc dot gnu dot org  2009-01-16 18:37 
 ---
 Guaranteed by 7.18.1.4.



These types are optional.

:)


-- 


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

[Bug middle-end/38932] ICE in set_value_range, at tree-vrp.c:398

[pinskia at gmail dot com]

--- Comment #5 from pinskia at gmail dot com  2009-01-22 09:17 ---
Subject: Re:  ICE in set_value_range, at tree-vrp.c:398



Sent from my iPhone

On Jan 22, 2009, at 1:00 AM, bonzini at gnu dot org gcc-bugzi...@gcc.gnu.org 
  wrote:



 --- Comment #4 from bonzini at gnu dot org  2009-01-22 09:00  
 ---
 In PRE there is a fold_convert_const_int_from_int call simplifying  
 (signed
 char) 249  to -7, but setting the TREE_OVERFLOW flag in the  
 meanwhile.  I
 don't think it makes sense to set the overflow flag on a NOP:

Yes but changing that right now opens lots of bags of worms.  It has  
been tried before.  The simple way to fix this is in pre unset  
TREE_OVERFLOW because at this point in the IR it does not matter.  I  
hope someone would change vrp to do the correct thing but I guess that  
won't happen any time soon.


Thanks,
Andrew Pinski



   * `The result of, or the signal raised by, converting an integer  
 to a
 signed integer type when the value cannot be represented in an
 object of that type (C90 6.2.1.2, C99 6.3.1.3).'

 For conversion to a type of width N, the value is reduced modulo
 2^N to be within range of the type; no signal is raised.

 (Integers implementation, from the gcc manual).


 -- 

 bonzini at gnu dot org changed:

   What|Removed |Added
 --- 
 --- 
 --
 CC||rguenth at gcc dot  
 gnu dot
   ||org


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



-- 


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

[Bug target/38941] CX isn't preserved with shift

[pinskia at gmail dot com]

--- Comment #1 from pinskia at gmail dot com  2009-01-23 04:24 ---
Subject: Re:   New: CX isn't preserved with shift



Sent from my iPhone

On Jan 22, 2009, at 5:54 PM, hjl dot tools at gmail dot com
gcc-bugzi...@gcc.gnu.org 
  wrote:

 On x86, CX is used for shift. If CX is used for a variable, it
 may not be preserved with shift:

 [...@gnu-9 reg-1]$ cat r.c
 extern void abort (void);

 void
 foo (int x)
 {
  if (x != 8)
abort ();
 }

 void
 bar (int g)
 {
register int x __asm__(ecx);
x = 5;
foo (1  g);

I think this code is undefined as the register variable is not used in  
an inline-asm.


if (x != 5)
  abort ();
 }

 int
 main ()
 {
  bar (3);
  return 0;
 }
 [...@gnu-9 reg-1]$ make r0
 /export/build/gnu/gcc/build-i686-linux/gcc/xgcc
 -B/export/build/gnu/gcc/build-i686-linux/gcc/ -m32 -O0 r.c -o r0
 [...@gnu-9 reg-1]$ ./r0
 Aborted
 [...@gnu-9 reg-1]$


 -- 
   Summary: CX isn't preserved with shift
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ra
  Severity: normal
  Priority: P3
 Component: target
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=38941



-- 


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

[Bug target/38941] CX isn't preserved with shift

[pinskia at gmail dot com]

--- Comment #3 from pinskia at gmail dot com  2009-01-23 04:39 ---
Subject: Re:  CX isn't preserved with shift



Sent from my iPhone

On Jan 22, 2009, at 8:34 PM, hjl dot tools at gmail dot com
gcc-bugzi...@gcc.gnu.org 
  wrote:



 --- Comment #2 from hjl dot tools at gmail dot com  2009-01-23  
 04:34 ---
 How about this one:

 ---
 extern void abort (void);

 void
 foo (int x)
 {
  if (x != 8)
abort ();
 }

 void
 bar (int g)
 {
register int x __asm__(ecx);
register int y __asm__(eax);
x = 5;
foo (1  g);
asm (mov %1, %0: =r (y): r (x));
Again still undefined because there is still inbetween the assignment  
and the inline-asm.


if (x != 5)
  abort ();
if (y != 5)
  abort ();
 }

 int
 main ()
 {
  bar (3);
  return 0;
 }
 ---


 -- 

 hjl dot tools at gmail dot com changed:

   What|Removed |Added
 --- 
 --- 
 --
Summary|CX isn't preserved with |CX isn't preserved  
 with
   |shift   |shift


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



-- 


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

[Bug c/38961] if () block not true but a command in it is still in effect

[pinskia at gmail dot com]

--- Comment #7 from pinskia at gmail dot com  2009-01-24 22:33 ---
Subject: Re:  if () block not true but a command in it is still in effect



Sent from my iPhone

On Jan 24, 2009, at 2:24 PM, jellegeerts at gmail dot com
gcc-bugzi...@gcc.gnu.org 
  wrote:



 --- Comment #6 from jellegeerts at gmail dot com  2009-01-24  
 22:24 ---
 Seems reasonable, though I'd vote for -Wall to include -Winit-self.

 I actually discovered this because of a bug I found in lxpanel. Now  
 of course
 it's the fault of those developers not to use -Winit-self, but seen  
 the other
 options that -Wall enables, it seems reasonable to also enable - 
 Winit-self.

Except -Winit-self is there because we decided a long time ago initing  
the variable by itself is a way to disable the uninitization warning.   
In fact before 3.4 there was no way to get this warning (oh I added  
this option:) ).

Thanks,
Andrew Pinsky






 -- 


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



-- 


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

[Bug web/38973] Missing feature documentation

[pinskia at gmail dot com]

--- Comment #1 from pinskia at gmail dot com  2009-01-26 11:12 ---
Subject: Re:   New: Missing feature documentation



Sent from my iPhone

On Jan 26, 2009, at 2:35 AM, piotr dot wyderski at gmail dot com
gcc-bugzi...@gcc.gnu.org 
  wrote:

 The website

 http://gcc.gnu.org/projects/cxx0x.html

 claims that the New character types N2249
 C++0x extension is not supported by any
 version of GCC. But GCC 4.4.0 supports the
 u8, u and U string prefixes. :-)

Well 4.4 has not been released yet so ...






 -- 
   Summary: Missing feature documentation
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: web
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: piotr dot wyderski at gmail dot com
  GCC host triplet: GCC-4.4.0, Cygwin, Windows XP


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



-- 


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

[Bug tree-optimization/38984] [4.2/4.3/4.4 Regression] NULL pointers always considered distinct by PTA, even with -fno-delete-null-pointer-checks

[pinskia at gmail dot com]

--- Comment #4 from pinskia at gmail dot com  2009-01-27 11:08 ---
Subject: Re:  [4.2/4.3/4.4 Regression] NULL pointers always considered distinct
by PTA, even with -fno-delete-null-pointer-checks



Sent from my iPhone

On Jan 27, 2009, at 3:02 AM, bonzini at gnu dot org gcc-bugzi...@gcc.gnu.org 
  wrote:



 --- Comment #1 from bonzini at gnu dot org  2009-01-27 11:02  
 ---
 This simple patch is not enough:

 Index: tree-ssa-structalias.c
 ===
 --- tree-ssa-structalias.c  (revision 142960)
 +++ tree-ssa-structalias.c  (working copy)
 @@ -3030,8 +3030,14 @@ get_constraint_for_1 (tree t, VEC (ce_s,
  happens below, since it will fall into the default case. The only
  case we know something about an integer treated like a pointer is
  when it is the NULL pointer, and then we just say it points to
 - NULL.  */
 -  if (TREE_CODE (t) == INTEGER_CST
 + NULL.
 +
 + Do not do that if -fno-delete-null-pointer-checks though,  
 because
 + in that case *NULL does not fail, so it _should_ alias  
 *anything.
 + It is not worth adding a new option or renaming the existing  
 one,
 + since this case is relatively obscure.  */
 +  if (flag_delete_null_pointer_checks
 +   TREE_CODE (t) == INTEGER_CST
integer_zerop (t))
 {
   temp.var = nothing_id;

 We get:

 ANYTHING = ANYTHING
 ESCAPED = *ESCAPED
 NONLOCAL = ESCAPED
 INTEGER = ANYTHING
 derefaddrtmp.8 = NONLOCAL
 *ESCAPED = derefaddrtmp.8
 p = NONLOCAL

 ...

 NULL = { }
 ANYTHING = { ANYTHING }
 READONLY = { READONLY }
 ESCAPED = { }
 NONLOCAL = { ESCAPED }
 CALLUSED = { }
 INTEGER = { ANYTHING }
 derefaddrtmp.7 = { ESCAPED }
 derefaddrtmp.8 = { NONLOCAL }
 p = same as derefaddrtmp.8

 ...

 Updating SSA information for statement a_2 = *p_1(D);

 Updating SSA information for statement D.1236_4 = *p_1(D);

 ...

 VUSE operands 2  8b
 VDEF operands 0  0b

 ...

  # VUSE SMT.9D.1248_6(D) { SMT.9D.1248 }
  aD.1233_2 = *pD.1230_1(D);
  *0B ={v} 5;
  # VUSE SMT.9D.1248_6(D) { SMT.9D.1248 }
  D.1236_4 = *pD.1230_1(D);
  D.1235_5 = D.1236_4 == aD.1233_2;
  return D.1235_5;

 Note there is no vdef, so FRE comes and removes the second load.

If that patch is not enough and the above is happening we are going to  
have issues wit volatiles also.





 -- 

 bonzini at gnu dot org changed:

   What|Removed |Added
 --- 
 --- 
 --
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-01-27 11:02:25
   date||


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



-- 


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

[Bug tree-optimization/38985] [4.2/4.3/4.4 Regression] missing constraints for pointers accessed directly via their address

[pinskia at gmail dot com]

--- Comment #1 from pinskia at gmail dot com  2009-01-27 11:27 ---
Subject: Re:   New: [4.2/4.3/4.4 Regression] missing constraints for pointers
accessed directly via their address



Sent from my iPhone

On Jan 27, 2009, at 3:15 AM, bonzini at gnu dot org gcc-bugzi...@gcc.gnu.org 
  wrote:

 This testcase fails:

 /* { dg-do compile } */
 /* { dg-options -O2 -fdump-tree-optimized } */

 int f(int *p)
 {
  int a = *p;
  int *q = (int *)0xDEADBEE0;
  *q = 5;
  return *p == a;
 }

 /* { dg-final { scan-tree-dump-times  = \\\*p 2 optimized } } */
 /* { dg-final { scan-tree-dump-not return 1 optimized } } */
 /* { dg-final { cleanup-tree-dump optimized } } */


 Unlike PR38984 it does not require -fno-delete-null-pointer-checks.

Volatile addresses also don't have vops on them.  As I mentioned in  
the other bug.  So this is also a bug for volatiles.




 -- 
   Summary: [4.2/4.3/4.4 Regression] missing constraints for
pointers accessed directly via their address
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
 OtherBugsDependingO 38984
 nThis:


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



-- 


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

[Bug middle-end/39015] [4.3 regression] wrong code building libgsf

[pinskia at gmail dot com]

--- Comment #8 from pinskia at gmail dot com  2009-01-29 17:53 ---
Subject: Re:  [4.3 regression] wrong code building libgsf



Sent from my iPhone

On Jan 29, 2009, at 2:01 AM, rguenth at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org 
  wrote:



 --- Comment #3 from rguenth at gcc dot gnu dot org  2009-01-29  
 10:01 ---
 The best option would be to revert that patch on the branch.

Except it alone could not cause wrong code.  Some other pass is  
causing it.  And then again with a testcase it is hard to figure out  
what is going wrong.  That patch just disables one small optimization  
in one case.




 -- 

 rguenth at gcc dot gnu dot org changed:

   What|Removed |Added
 --- 
 --- 
 --
 CC||sje at gcc dot gnu  
 dot org,
   ||rguenth at gcc dot  
 gnu dot
   ||org
   Priority|P3  |P1
   Target Milestone|--- |4.3.4


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



-- 


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

[Bug c/39036] Decimal floating-point exception flags done wrong

[pinskia at gmail dot com]

--- Comment #1 from pinskia at gmail dot com  2009-01-30 02:41 ---
Subject: Re:   New: Decimal floating-point exception flags done wrong



Sent from my iPhone

On Jan 29, 2009, at 6:00 PM, tydeman at tybor dot com
gcc-bugzi...@gcc.gnu.org 
  wrote:

 Using gcc 4.3.2-7 on Intel Pentium 4 running Linux Fedora Core 10 and
 -std=gnu99

There were some dfp fixes on the trunk relating to fp exceptions so  
you should try the trunk before reporting any more bugs.



 /* DFP TR 24732 == WG14 / N1176, N1312 */
 #define __STDC_WANT_DEC_FP__ /* Tell implementation that we want  
 Decimal FP */
 #pragma STDC FENV_ACCESS ON /* will be testing FP exception  
 flags */

 #include stdio.h  /* printf() */
 #include fenv.h   /* fetestexcept(), FE_* */
 #include float.h  /* DEC*_MIN, DEC*_MAX */


 int main(void){
  _Decimal64 d10;
  int before;
  int after;

  before = feclearexcept( FE_ALL_EXCEPT );
  d10 = 1.0DD;
  d10 /= 3.0DD;
  after = fetestexcept( FE_ALL_EXCEPT );
  if( FE_INEXACT  after ){
printf(Inexact raised as expected\n);
  }else{
printf(Inexact wrong; after=%i\n, after);
  }

  before = feclearexcept( FE_ALL_EXCEPT );
  d10 = DEC64_MIN;
  d10 *= d10;
  after = fetestexcept( FE_ALL_EXCEPT );
  if( FE_UNDERFLOW  after ){
printf(Underflow raised as expected\n);
  }else{
printf(Underflow wrong; after=%i\n, after);
  }

  before = feclearexcept( FE_ALL_EXCEPT );
  d10 = DEC64_MAX;
  d10 *= d10;
  after = fetestexcept( FE_ALL_EXCEPT );
  if( FE_OVERFLOW  after ){
printf(Overflow raised as expected\n);
  }else{
printf(Overflow wrong; after=%i\n, after);
  }

  before = feclearexcept( FE_ALL_EXCEPT );
  d10 = DEC64_MIN;
  d10 /= (d10-d10);
  after = fetestexcept( FE_ALL_EXCEPT );
  if( FE_DIVBYZERO  after ){
printf(Divbyzero raised as expected\n);
  }else{
printf(Divbyzero wrong; after=%i\n, after);
  }

  before = feclearexcept( FE_ALL_EXCEPT );
  d10 = 0.0e-15DD;
  d10 /= d10;
  after = fetestexcept( FE_ALL_EXCEPT );
  if( FE_INVALID  after ){
printf(Invalid raised as expected\n);
  }else{
printf(Invalid wrong; after=%i\n, after);
  }

  printf(%2i = FE_INEXACT\n, FE_INEXACT);
  printf(%2i = FE_UNDERFLOW\n, FE_UNDERFLOW);
  printf(%2i = FE_OVERFLOW\n, FE_OVERFLOW);
  printf(%2i = FE_DIVBYZERO\n, FE_DIVBYZERO);
  printf(%2i = FE_INVALID\n, FE_INVALID);

  return 0;
 }

 gets:

 Inexact wrong; after=0
 Underflow wrong; after=0
 Overflow wrong; after=32
 Divbyzero wrong; after=0
 Invalid wrong; after=0
 32 = FE_INEXACT
 16 = FE_UNDERFLOW
 8 = FE_OVERFLOW
 4 = FE_DIVBYZERO
 1 = FE_INVALID


 -- 
   Summary: Decimal floating-point exception flags done wrong
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tydeman at tybor dot com
  GCC host triplet: 4.3.2
 GCC target triplet: 4.3.2


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



-- 


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

[Bug libfortran/39083] stage 3 libgfortran build fails

[pinskia at gmail dot com]

--- Comment #2 from pinskia at gmail dot com  2009-02-03 04:35 ---
Subject: Re:  stage 3 libgfortran build fails



Sent from my iPhone

On Feb 2, 2009, at 8:33 PM, tony_eckert at umsl dot edu
gcc-bugzi...@gcc.gnu.org 
  wrote:



 --- Comment #1 from tony_eckert at umsl dot edu  2009-02-03  
 04:33 ---
 appears similar to bug 37865, but without --enable-intermodule.
 Only departure from defaults is --prefix

Are you building in the source tree?




 -- 


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



-- 


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

[Bug c++/36607] [4.3/4.4 Regression] Incorrect type diagnostic on substracting casted char pointers

[pinskia at gmail dot com]

--- Comment #8 from pinskia at gmail dot com  2009-02-03 15:44 ---
Subject: Re:  [4.3/4.4 Regression] Incorrect type diagnostic on substracting
casted char pointers



Sent from my iPhone

On Feb 3, 2009, at 5:56 AM, bonzini at gnu dot org gcc-bugzi...@gcc.gnu.org 
  wrote:



 --- Comment #7 from bonzini at gnu dot org  2009-02-03 13:56  
 ---
 ping?

The patch was just approved last night and I will be applying it when  
I get into work today.




 -- 

 bonzini at gnu dot org changed:

   What|Removed |Added
 --- 
 --- 
 --
 CC||bonzini at gnu dot org


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



-- 


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

[Bug target/39226] [4.4 Regression] gcc_assert (verify_initial_elim_offsets ()); ICE

[pinskia at gmail dot com]

--- Comment #1 from pinskia at gmail dot com  2009-02-18 10:30 ---
Subject: Re:   New: [4.4 Regression] gcc_assert (verify_initial_elim_offsets
()); ICE

This is mostly likely due to my no micro code patch. I see what causes  
it tommorow.

Sent from my iPhone

On Feb 17, 2009, at 11:55 PM, jakub at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org 
  wrote:

 /* { dg-do compile } */
 /* { dg-options -O2 } */
 /* { dg-options -O2 -mtune=cell -mminimal-toc { target { powerpc*- 
 *-*  lp64
 } } } */

 struct A
 {
  char *a;
  unsigned int b : 1;
  unsigned int c : 31;
 };

 struct B
 {
  struct A *d;
 };

 void
 foo (struct B *x, unsigned long y)
 {
  if (x-d[y].c)
return;
  if (x-d[y].b)
x-d[y].a = 0;
 }

 ICEs with -m64 -O2 -mtune=cell -mminimal-toc, as elimination offsets  
 change.


 -- 
   Summary: [4.4 Regression] gcc_assert  
 (verify_initial_elim_offsets
()); ICE
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
 GCC target triplet: powerpc64-linux


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



-- 


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

[Bug middle-end/39298] Optimize away only set but not used variable

[pinskia at gmail dot com]

--- Comment #6 from pinskia at gmail dot com  2009-02-25 13:37 ---
Subject: Re:  Optimize away only set but not used variable



Sent from my iPhone

On Feb 25, 2009, at 1:43 AM, rguenth at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org 
  wrote:



 --- Comment #1 from rguenth at gcc dot gnu dot org  2009-02-25  
 09:43 ---
 Is there a reason the Fortran frontend gives function local  
 variables static
 storage duration?


Yes, it is larger than the threshhold. Remember fortran has no  
recursive functions except for the ones which marked as such.

 a ()
 {
  struct __st_parameter_dt dt_parm.1;
  static integer(kind=4) options.0[8] = {68, 255, 0, 0, 0, 1, 0, 1};
  static complex(kind=4) foo[2147483647];

 bb 2:
  _gfortran_set_options (8, options.0);
  foo[9] = __complex__ (1.0e+0, 0.0);


 -- 

 rguenth at gcc dot gnu dot org changed:

   What|Removed |Added
 --- 
 --- 
 --
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-02-25 09:43:40
   date||


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



-- 


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

[Bug middle-end/39333] gcc 4.3.3 miscompiles when -finline-small-functions is used

[pinskia at gmail dot com]

--- Comment #17 from pinskia at gmail dot com  2009-03-07 04:35 ---
Subject: Re:  gcc 4.3.3 miscompiles when -finline-small-functions is used



Sent from my iPhone

On Mar 6, 2009, at 8:30 PM, galtgendo at o2 dot pl gcc-bugzi...@gcc.gnu.org 
  wrote:



 --- Comment #16 from galtgendo at o2 dot pl  2009-03-07 04:30  
 ---
 OK, I've done a little test and I'd like to know,
 if it's results actually mean anything:
 I've compiled freeciv with CFLAGS=-O2 -finline-functions
 -fno-guess-branch-probability and it did not crash.

 Does the above confirm that the problem lies in -fguess-branch- 
 probability ?

Not really because that option only generates information used by  
other optimazations.




 -- 


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



-- 


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

[Bug other/39400] Dist tarball missing file gengtype-lex.c

[pinskia at gmail dot com]

--- Comment #2 from pinskia at gmail dot com  2009-03-08 21:56 ---
Subject: Re:   New: Dist tarball missing file gengtype-lex.c



Sent from my iPhone

On Mar 8, 2009, at 1:28 PM, skunk at iskunk dot org gcc-bugzi...@gcc.gnu.org 
  wrote:

 Bootstrapping gcc-4.4-20090306(.tar.bz2) on Tru64 fails with

This is a snapshot so it does not have all of generated files that a  
release will have. So this bug is invalid.



 flex  -ogengtype-lex.c /tmp/gcc-4.4-20090306/gcc/gengtype-lex.l
 flex: unknown flag 'o'
 gmake[3]: [gengtype-lex.c] Error 1 (ignored)
 cc -std1 -c  -g -DIN_GCC-DHAVE_CONFIG_H -DGENERATOR_FILE -I. - 
 Ibuild
 -I/usr/home/cport/tmp/gcc-4.4-20090306/gcc
 -I/usr/home/cport/tmp/gcc-4.4-20090306/gcc/build
 -I/usr/home/cport/tmp/gcc-4.4-20090306/gcc/../include
 -I/usr/home/cport/tmp/gcc-4.4-20090306/gcc/../libcpp/include
 -I/tg/freeport/arch/tru64/include -I/tg/freeport/arch/tru64/include
 -I/usr/home/cport/tmp/gcc-4.4-20090306/gcc/../libdecnumber
 -I/usr/home/cport/tmp/gcc-4.4-20090306/gcc/../libdecnumber/dpd
 -I../libdecnumber-o build/gengtype-lex.o gengtype-lex.c
 cc: Severe: No such file or directory
 ... file is 'gengtype-lex.c'
 gmake[3]: *** [build/gengtype-lex.o] Error 1
 gmake[3]: Leaving directory `/mnt/scratch/build/gcc-build/gcc'
 gmake[2]: *** [all-stage1-gcc] Error 2
 gmake[2]: Leaving directory `/mnt/scratch/build/gcc-build'
 gmake[1]: *** [stage1-bubble] Error 2
 gmake[1]: Leaving directory `/mnt/scratch/build/gcc-build'
 gmake: *** [bootstrap] Error 2

 gengtype-lex.c should not have to be generated, obviously.

 P.S.: Here we also see an issue where the system's ancient version  
 of flex (I
 don't even know the version number, as it doesn't have an option to  
 print it)
 doesn't work the way that the makefile expects. Should I file a  
 separate bug,
 for the configure script to check beforehand whether flex supports  
 the -o
 option?


 -- 
   Summary: Dist tarball missing file gengtype-lex.c
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: skunk at iskunk dot org
 GCC build triplet: alphaev56-dec-osf4.0g
  GCC host triplet: alphaev56-dec-osf4.0g
 GCC target triplet: alphaev56-dec-osf4.0g


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



-- 


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

[Bug c/39403] Excessive optimization issue

[pinskia at gmail dot com]

--- Comment #2 from pinskia at gmail dot com  2009-03-09 15:57 ---
Subject: Re:  Excessive optimization issue



Sent from my iPhone

On Mar 9, 2009, at 8:36 AM, rguenth at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org 
  wrote:



 --- Comment #1 from rguenth at gcc dot gnu dot org  2009-03-09  
 15:36 ---
 You need to specify that the registers are clobbered by the asm.   
 The only
 way to do that is to use output constraints (+D, +c, etc.) on  
 proper
 temporaries.

  int lent = len;
  char *dstt = dst;
  char *srct = src;
  __asm__ __volatile__(
   cld\n\t
   rep movsb
   : +c (lent), +D(dstt), +S(src)
  );
 Otherwise GCC thinks the registers still hold the original value.

Oh and mark this inline-ask as clobbering memory.




 -- 

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



-- 


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

[Bug c++/39407] Parse error in stack when user declares template-name c

[pinskia at gmail dot com]

--- Comment #9 from pinskia at gmail dot com  2009-03-09 15:59 ---
Subject: Re:  Parse error in stack when user declares template-name  c



Sent from my iPhone

On Mar 9, 2009, at 8:40 AM, rguenth at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org 
  wrote:



 --- Comment #7 from rguenth at gcc dot gnu dot org  2009-03-09  
 15:40 ---
 I think this is more likely a C++ frontend issue.  At least I cannot  
 believe
 this behavior is mandated by the std ;)

 Jason?

There is a dup of this bug somewhere also.





 -- 

 rguenth at gcc dot gnu dot org changed:

   What|Removed |Added
 --- 
 --- 
 --
 CC||jason at redhat dot  
 com
  Component|libstdc++   |c++
   Keywords||rejects-valid


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



-- 


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

[Bug driver/39439] The Driver hides undefined reference messages from shared libs (but not object files) in linker phase

[pinskia at gmail dot com]

--- Comment #1 from pinskia at gmail dot com  2009-03-12 04:42 ---
Subject: Re:   New: The Driver hides undefined reference messages from shared
libs (but not object files) in linker phase



Sent from my iPhone

On Mar 11, 2009, at 9:27 PM, rob1weld at aol dot com
gcc-bugzi...@gcc.gnu.org 
  wrote:

 The Driver hides undefined reference messages from shared libs but
 not from object files. This seems inconsistent and is not helpful.


Why do you think the driver is doing instead of the linker?

 When compiling 'ppl' using the Trunk I'm getting a terse message
 about undefined reference to `typeinfo for int'. This is not
 particularly useful since the words are common (can't grep for
 them) and there is no line number info explaining the location of
 the code that causes this issue.

 This page may suggest a reason this error occurs:
 http://stackoverflow.com/questions/307352/g-undefined-reference-to-typeinfo


 I'm calling this an RFE since I desire an increase in verbosity
 but there are no doubt arguments favoring this being a Bug.


 # gcc -v
 Using built-in specs.
 Target: i386-pc-solaris2.11
 Configured with: ../gcc_trunk/configure --prefix=/usr/local/gcc4
 --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared
 --disable-static --enable-multilib --enable-decimal-float
 --with-long-double-128 --with-included-gettext --disable-stage1- 
 checking
 --enable-checking=release --with-tune=k8 --with-cpu=k8 --with-arch=k8
 --with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld
 --with-ld=/usr/local/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/ 
 local
 --without-ppl
 Thread model: posix
 gcc version 4.4.0 20090309 (experimental) [trunk revision 144720]  
 (GCC)


 # gmake
 ...
 gmake[4]: Entering directory `/usr/share/src/ppl-build/demos/ 
 ppl_lpsol'
 gcc -DHAVE_CONFIG_H -I. -I../../../ppl/demos/ppl_lpsol -I../..
 -I../../interfaces/C  -I/usr/local/include -pedantic -std=gnu89 - 
 Werror -g -O3
 -fomit-frame-pointer -march=k8 -frounding-math  -W -Wall -MT  
 ppl_lpsol.o -MD
 -MP -MF .deps/ppl_lpsol.Tpo -c -o ppl_lpsol.o
 ../../../ppl/demos/ppl_lpsol/ppl_lpsol.c
 mv -f .deps/ppl_lpsol.Tpo .deps/ppl_lpsol.Po
 /bin/sh ../../libtool --tag=CXX   --mode=link g++  -g -O3 -fomit- 
 frame-pointer
 -march=k8 -frounding-math  -W -Wall   -o ppl_lpsol ppl_lpsol.o  
 dummy.o -lglpk
 ../../interfaces/C/libppl_c.la -lm -L/usr/local/lib -lgmpxx -L/usr/ 
 local/lib
 -lgmp -R/usr/local/lib -R/usr/local/lib
 libtool: link: g++ -g -O3 -fomit-frame-pointer -march=k8 -frounding- 
 math -W
 -Wall -o .libs/ppl_lpsol ppl_lpsol.o dummy.o  /usr/local/lib/ 
 libglpk.so -lz
 ../../interfaces/C/.libs/libppl_c.so -L/usr/local/lib
 /usr/share/src/ppl-build/src/.libs/libppl.so /usr/local/lib/libstdc+ 
 +.so
 /usr/local/lib/libgmpxx.so /usr/local/gcc4/lib/libstdc++.so -lm
 /usr/local/lib/libgmp.so -Wl,-rpath -Wl,/usr/local/lib -Wl,-rpath
 -Wl,/usr/local/gcc4/lib
 ../../interfaces/C/.libs/libppl_c.so: undefined reference to  
 `typeinfo for int'
 collect2: ld returned 1 exit status
 gmake[4]: *** [ppl_lpsol] Error 1
 gmake[4]: Leaving directory `/usr/share/src/ppl-build/demos/ppl_lpsol'


 If I run that using -v I get this collect command:

 /usr/local/gcc4/libexec/gcc/i386-pc-solaris2.11/4.4.0/collect2 -V -m  
 elf_i386
 -Y P,/usr/ccs/lib:/usr/lib -Qy -o .libs/ppl_lpsol /usr/lib/crt1.o
 /usr/lib/crti.o /usr/lib/values-Xa.o
 /usr/local/gcc4/lib/gcc/i386-pc-solaris2.11/4.4.0/crtbegin.o -L/usr/ 
 local/lib
 -L/usr/local/gcc4/lib/gcc/i386-pc-solaris2.11/4.4.0
 -L/usr/local/gcc4/lib/gcc/i386-pc-solaris2.11/4.4.0/../../..  
 ppl_lpsol.o
 dummy.o --verbose /usr/local/lib/libglpk.so -lz
 ../../interfaces/C/.libs/libppl_c.so
 /usr/share/src/ppl-build/src/.libs/libppl.so /usr/local/lib/libstdc+ 
 +.so
 /usr/local/lib/libgmpxx.so /usr/local/gcc4/lib/libstdc++.so
 /usr/local/lib/libgmp.so -rpath /usr/local/lib -rpath /usr/local/ 
 gcc4/lib
 -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
 /usr/local/gcc4/lib/gcc/i386-pc-solaris2.11/4.4.0/crtend.o /usr/lib/ 
 crtn.o


 If I run that then I get this simple and useless output:

 ../../interfaces/C/.libs/libppl_c.so: undefined reference to  
 `typeinfo for int'
 collect2: ld returned 1 exit status


 If I run that exact same command but make a simple alteration:
 - ... -lz ../../interfaces/C/.libs/libppl_c.so
 + ... -lz ../../interfaces/C/.libs/*.o

 I can use the Object files that were used to create the Shared Library
 instead of using the Shared Library. This is useful (due to this
 Bug or needed RFE) since the error messages printed are by _far_ more
 useful, see:

 # /usr/local/gcc4/libexec/gcc/i386-pc-solaris2.11/4.4.0/collect2 -V - 
 m elf_i386
 -Y P,/usr/ccs/lib:/usr/lib -Qy -o .libs/ppl_lpsol /usr/lib/crt1.o
 /usr/lib/crti.o /usr/lib/values-Xa.o
 /usr/local/gcc4/lib/gcc/i386-pc-solaris2.11/4.4.0/crtbegin.o -L/usr/ 
 local/lib
 -L/usr/local/gcc4/lib/gcc/i386-pc-solaris2.11/4.4.0
 -L/usr/local/gcc4/lib/gcc/i386-pc-solaris2.11/4.4.0/../../..  
 ppl_lpsol.o
 dummy.o /usr/local

[Bug middle-end/39460] strange aliasing warnings compiling pymol under gcc 4.4

[pinskia at gmail dot com]

--- Comment #4 from pinskia at gmail dot com  2009-03-14 06:03 ---
Subject: Re:   New: strange aliasing warnings compiling pymol under gcc 4.4



Sent from my iPhone

On Mar 13, 2009, at 9:11 PM, howarth at nitro dot med dot uc dot edu  
gcc-bugzi...@gcc.gnu.org wrote:

 There are a number of aliasing warnings coming out of tree-ssa- 
 structalias.c
 when compiling code in pymol which uses their endianswap.h header at  
 -O3 -Wall.
 The warnings are of the form...

 In file included from gromacsplugin.cpp:34:
 endianswap.h: In function ‘int put_trx_real(md_file*, float)’:
 endianswap.h:117: warning: dereferencing pointer ‘N’ does break  
 strict-aliasing
 rules
 endianswap.h:115: note: initialized from here
 endianswap.h: In function ‘int trx_real(md_file*, float*)’:
 endianswap.h:143: warning: dereferencing pointer ‘N’ does break  
 strict-aliasing
 rules
 endianswap.h:135: warning: dereferencing pointer ‘N’ does break  
 strict-aliasing
 rules
 endianswap.h:128: note: initialized from here
 endianswap.h:144: warning: dereferencing pointer ‘anonymous’  
 does break
 strict-aliasing rules
 endianswap.h:139: warning: dereferencing pointer ‘anonymous’  
 does break
 strict-aliasing rules
 endianswap.h:139: note: initialized from here
 endianswap.h: In function ‘int write_trr_timestep(void*, const
 molfile_timestep_t*)’:
 endianswap.h:117: warning: dereferencing pointer ‘N’ does break  
 strict-aliasing
 rules
 endianswap.h:115: note: initialized from here
 endianswap.h:117: warning: dereferencing pointer ‘N’ does break  
 strict-aliasing
 rules
 endianswap.h:115: note: initialized from here

 and don't occur under gcc 4.3. I am wondering if these are valid  
 warnings or a
 bug in gcc 4.4? I am attaching the preprocessed source for  
 gromacsplugin.ii.
 The weird part is that just compiling the contents of endianswap.h  
 doesn't
 trigger the warnings. Also many files in pymol use this header and  
 the errors
 appear rather randomly among them. Also I have never seen the 'does  
 break'
 warning from tree-ssa-structalias.c, but only the 'will break'  
 warning from
 c-common.c.

Inling causes warning to show up. The warning is correct though as the  
access is via a short but the original type is float.




 -- 
   Summary: strange aliasing warnings compiling pymol under  
 gcc 4.4
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: howarth at nitro dot med dot uc dot edu
 GCC build triplet: i686-apple-darwin9
  GCC host triplet: i686-apple-darwin9
 GCC target triplet: i686-apple-darwin9


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



-- 


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

[Bug driver/39439] The Driver hides undefined reference messages from shared libs (but not object files) in linker phase

[pinskia at gmail dot com]

--- Comment #3 from pinskia at gmail dot com  2009-03-14 06:14 ---
Subject: Re:  The Driver hides undefined reference messages from shared libs
(but not object files) in linker phase



Sent from my iPhone

On Mar 13, 2009, at 8:54 PM, rob1weld at aol dot com
gcc-bugzi...@gcc.gnu.org 
  wrote:



 --- Comment #2 from rob1weld at aol dot com  2009-03-14 03:54  
 ---
 (In reply to comment #1)
 Subject: Re:   New: The Driver hides undefined reference messages  
 from
 shared libs (but not object files) in linker phase
 Sent from my iPhone
 Hurray for Phones with large screens.


 On Mar 11, 2009, at 9:27 PM, rob1weld at aol dot com
 gcc-bugzi...@gcc.gnu.org wrote:
 The Driver hides undefined reference messages from shared libs but
 not from object files. This seems inconsistent and is not helpful.


 Why do you think the driver is doing instead of the linker?


 The linker, upon 'discovering' the problem, simply prints:
 ../../interfaces/C/.libs/libppl_c.so: undefined reference to  
 `typeinfo for int'
 collect2: ld returned 1 exit status

The linker is suppressing the undefined reference in the first place  
when creating the .so. I think this is a bug in ppl's make file and  
not gcc.





 By using the Objects, instead of the Shared Library, I force it to
 make the discovery early and report ALL the details instead of trying
 to unmangle the C++, resulting in this more verbose message:

 ../../interfaces/C/.libs/ppl_c__BD_Shape_mpq_class.o: In function
 `sgnParma_Polyhedra_Library::Checked_Number__gmp_expr__mpz_struct  
 [1],
 __mpz_struct [1], Parma_Polyhedra_Library::Extended_Number_Policy  
 ':
 /usr/share/src/ppl-build/interfaces/C/../../src/ppl.hh:11187:  
 undefined
 reference to `typeinfo for int'


 My ld is:
 # ld --version
 GNU ld (GNU Binutils) 2.19.1


 I'm building with -g and the Shared Library is not stripped:

 # file /usr/share/src/ppl-build/interfaces/C/.libs/libppl_c.so
 /usr/share/src/ppl-build/interfaces/C/.libs/libppl_c.so:ELF  
 32-bit LSB
 dynamic lib 80386 Version 1, dynamically linked, not stripped


 I say it is the Driver and not xgcc / gcc, or ld since
 if the Driver took the _ridiculous_ step of noticing the Linker
 error and re-running the compile (using the objects used to create the
 Shared Library) the the Driver could produce the more verbose
 output that I RFE'd in favour of. Notice I mentioned that actually
 implementing that behavior by re-running the compiler is not  
 efficient.


 Using -g needs to pass _more_ info to the Linker, to be included
 in the Shared Libraries produced, so that if there is a Linker
 error then 'ld' can reference the source code where the error
 was caused and display it.

 The way we are producing Shared Libraries gives us very terse
 error messages that seem as though the Shared Library were
 stripped (when they are not).


 Is there a problem with the manner in which the PPL source
 is written ? I'm not very fluent in C++.

 Rob


 -- 


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



-- 


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

[Bug libfortran/39467] [4.4 regression] __iso_c_binding_c_f_procpoin...@gfortran_1.0 missing in libgfortran

[pinskia at gmail dot com]

--- Comment #2 from pinskia at gmail dot com  2009-03-15 21:15 ---
Subject: Re:   New: [4.4 regression]
__iso_c_binding_c_f_procpoin...@gfortran_1.0 missing in libgfortran



Sent from my iPhone

On Mar 15, 2009, at 2:02 PM, doko at ubuntu dot com gcc-bugzi...@gcc.gnu.org 
  wrote:

 The shared library libgfortran.so.3 in 4.3.x has the
 __iso_c_binding_c_f_procpoin...@gfortran_1.0 symbol exported. This  
 symbol is
 missing in 4.4.0 20090315.

I think this symbol was never used (from the fortran front-end) so  
removing is ok. Also I think there is a duplicated bug about this  
already.




 -- 
   Summary: [4.4 regression]
__iso_c_binding_c_f_procpoin...@gfortran_1.0  
 missing in
libgfortran
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: doko at ubuntu dot com
 GCC target triplet: i486-linux-gnu


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



-- 


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

[Bug tree-optimization/39455] [4.3/4.4 Regression] ICE : in compare_values_warnv, at tree-vrp.c:1073

[pinskia at gmail dot com]

--- Comment #8 from pinskia at gmail dot com  2009-03-16 08:28 ---
Subject: Re:  [4.3/4.4 Regression] ICE : in compare_values_warnv, at
tree-vrp.c:1073



Sent from my iPhone

On Mar 16, 2009, at 1:15 AM, jakub at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org 
  wrote:



 --- Comment #7 from jakub at gcc dot gnu dot org  2009-03-16  
 08:15 ---
 Reduced testcase:

 /* { dg-do compile } */
 /* { dg-options -O2 -fprefetch-loop-arrays } */

 void
 foo (char *x, unsigned long y, unsigned char *z)
 {
  unsigned int c[256], *d;

  for (d = c + 1; d  c + 256; ++d)
*d += d[-1];
  x[--c[z[y]]] = 0;

Hmm. Could this be the char-- bug? Where the front-end/gimplifier does  
not promote that to int?

Thanks,
Andrew Pinski


 }


 -- 


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



-- 


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

[Bug c/39493] [Mips] No space for arguments when implicitely calling __get_tls_addr

[pinskia at gmail dot com]

--- Comment #3 from pinskia at gmail dot com  2009-03-18 14:22 ---
Subject: Re:   New: [Mips] No space for arguments when implicitely calling
__get_tls_addr



Sent from my iPhone

On Mar 18, 2009, at 7:05 AM, joel dot porquet at gmail dot com
gcc-bugzi...@gcc.gnu.org 
  wrote:

 Mips ABI specifies to let the space for 4 arguments in stack when  
 calling a
 function. This is not respected when accessing tls variable with a  
 dynamic
 model: gcc implicitely calls __get_tls_addr without making rooms for  
 the
 arguments. The top of the stack is then likely to be erase.

__get_tls_addr is a special function and does not have to follow that  
part of the ABI but a different part which should be documented about  
tls and dynamic tls.


 Here is an example:

 - test.c:

 extern void* __get_tls_addr(void*);
 extern __thread int a;
 void func(void)
 {
a++;
 }

 Compiled and linked with:

 mipsel-unknown-elf-gcc -fpic -mshared -nostdinc -nostdlib -fno- 
 builtin -mips2
 -EL -mabicalls -G0 -c -o test.o test.c
 mipsel-unknown-elf-ld -shared test.o -o test.so

 Result in assembly:

 5ffe0390 func:
 5ffe0390:   3c1c0001lui gp,0x1
 5ffe0394:   279c9090addiu   gp,gp,-28528
 5ffe0398:   0399e021addugp,gp,t9
 5ffe039c:   27bdffe8addiu   sp,sp,-24
 5ffe03a0:   afbf0014sw  ra,20(sp)
 5ffe03a4:   afbe0010sw  s8,16(sp)
 5ffe03a8:   afbcsw  s0,12(sp)
 5ffe03ac:   03a0f021moves8,sp
 5ffe03b0:   afbcsw  gp,0(sp)
 5ffe03b4:   8f99802clw  t9,-32724(gp)
 5ffe03b8:   27848030addiu   a0,gp,-32720
 5ffe03bc:   0320f809jalrt9
 5ffe03c0:   nop
 5ffe03c4:   8fdclw  gp,0(s8)
 5ffe03c8:   8c42lw  v0,0(v0)
 ...

 We can see than $gp is saved directly at the top of the stack  
 0($sp), and is
 likely to be erase in the callee function.

 A temporarily workaround is to insert a real function call in the  
 same function
 which uses a tls variable.
 Example:

 extern void* __get_tls_addr(void*);
 extern __thread int a;
 static inline void fake(void){}
 void func(void)
 {
fake();
a++;
 }

 This result is then:
 5ffe0390 func:
 5ffe0390:   3c1c0001lui gp,0x1
 5ffe0394:   279c90c0addiu   gp,gp,-28480
 5ffe0398:   0399e021addugp,gp,t9
 5ffe039c:   27bdffd8addiu   sp,sp,-40
 5ffe03a0:   afbf0024sw  ra,36(sp)
 5ffe03a4:   afbe0020sw  s8,32(sp)
 5ffe03a8:   afb0001csw  s0,28(sp)
 5ffe03ac:   03a0f021moves8,sp
 5ffe03b0:   afbc0010sw  gp,16(sp)
 5ffe03b4:   8f828018lw  v0,-32744(gp)
 5ffe03b8:   24590418addiu   t9,v0,1048
 5ffe03bc:   0320f809jalrt9
 5ffe03c0:   nop
 5ffe03c4:   8fdc0010lw  gp,16(s8)
 ...

 We can now see that $gp is stored at 16($sp), which gives the  
 required spare
 space for the 4 arguments in stack.


 -- 
   Summary: [Mips] No space for arguments when implicitely  
 calling
__get_tls_addr
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel dot porquet at gmail dot com
  GCC host triplet: i486-linux-gnu
 GCC target triplet: mipsel-unknown-elf


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



-- 


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

[Bug c/39504] Incorrect code at -O2 and -O3

[pinskia at gmail dot com]

--- Comment #4 from pinskia at gmail dot com  2009-03-19 16:01 ---
Subject: Re:   New: Incorrect code at -O2 and -O3



Sent from my iPhone

On Mar 19, 2009, at 8:38 AM, jk500500 at yahoo dot com
gcc-bugzi...@gcc.gnu.org 
  wrote:

 The attached test program -- which I extracted and simplified from the
 '176.gcc'
 SPEC2000 benchmark -- is compiled incorrectly at -O2 and -O3.   The  
 code is
 correct at -O1 and -O0.

 The bad code I am reporting here is produced by a MIPS gcc-4.3.3
 cross-compiler.
 However, I see the same problem with an in-house port of gcc-4.3.3  
 to an
 in-house-developed CPU, so I believe the problem is generic to GCC and
 not specific to the MIPS version.

 I am attaching the complete testcase (a self-contained C file), but  
 the
 problem is specifically with this C code:

 rtx
 rtx_alloc (enum rtx_code jsk_code_arg) {
rtx rt;
struct obstack *ob = rtl_obstack;
int length;
_obstack_newchunk(ob);
rt = (rtx)ob-object_base;
length = (sizeof (struct rtx_def) - sizeof (rtunion) - 1) /  
 sizeof (int);
for (; length = 0; length--) {
((int *) rt)[length] = 0;
}

This is undefined code. The code in spec is known to violate C90/C99/C+ 
+98 aliasing rules.



 #ifdef WORKAROUND
/* If enabled, will fix the issue */
__asm__ __volatile__ ( sll r0,r0,0 );
 #endif

rt-jsk_code_val = jsk_code_arg;
return rt;
 }


 The rt-jsk_code_val = jsk_code_arg assignment is incorrectly  
 dropped
 from the generated code.  As the comment in the C code indicates, if I
 insert a volatile asm statement between the zero'ing of the *rt struct
 and the jsk_code_val assignment, correct code results at all  
 optimization
 levels.

 At -O2, the MIPS assembly code is below.  There is a 'sw' (store 32- 
 bit word)
 instruction near the end that results in the jsk_code_val field being
 set to zero rather than to the value of jsk_code_arg.

 rtx_alloc:
.frame  $sp,16,$31  # vars= 0, regs= 3/0, args=  
 0, gp= 0
.mask   0x8003,-4
.fmask  0x,0
.setnoreorder
.setnomacro

addiu   $sp,$sp,-16
sw  $16,4($sp)
lui $16,%hi(rtl_obstack)
addiu   $4,$16,%lo(rtl_obstack)
addiu   $16,$16,%lo(rtl_obstack)
sw  $31,12($sp)
jal _obstack_newchunk
sw  $17,8($sp)

lw  $2,8($16)
lw  $31,12($sp)
lw  $17,8($sp)
lw  $16,4($sp)
sw  $0,4($2)
sw  $0,0($2)   --- Writes 'jsk_code_val' to zero
j   $31
addiu   $sp,$sp,16



 With the WORKAROUND define enabled, the code becomes as shown  
 below.  Now
 there is the correct 'sh' (store 16-bit halfword) instruction to set
 jsk_code_arg to the value of jsk_code_val.

 rtx_alloc:
.frame  $sp,16,$31  # vars= 0, regs= 3/0, args=  
 0, gp= 0
.mask   0x8003,-4
.fmask  0x,0
addiu   $sp,$sp,-16
sw  $16,4($sp)
lui $16,%hi(rtl_obstack)
sw  $17,8($sp)
move$17,$4
addiu   $4,$16,%lo(rtl_obstack)
sw  $31,12($sp)
.setnoreorder
.setnomacro
jal _obstack_newchunk
addiu   $16,$16,%lo(rtl_obstack)
.setmacro
.setreorder

lw  $2,8($16)
sw  $0,4($2)
sw  $0,0($2)
 #APP
 # 78 ./gcc0.c 1
sll r0,r0,0
 # 0  2
 #NO_APP
lw  $31,12($sp)
sh  $17,0($2)- sets jsk_code_val to  
 jsk_code_arg
lw  $16,4($sp)
lw  $17,8($sp)
.setnoreorder
.setnomacro
j   $31
addiu   $sp,$sp,16


 -- 
   Summary: Incorrect code at -O2 and -O3
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jk500500 at yahoo dot com
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
 GCC target triplet: mipsisa32-unknown-elf


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



-- 


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

[Bug target/30315] optimize unsigned-add overflow test on x86 to use cpu flags from addl

[pinskia at gmail dot com]

--- Comment #3 from pinskia at gmail dot com  2007-06-06 09:10 ---
Subject: Re:  optimize unsigned-add overflow test on x86 to use cpu flags from
addl

 And BTW - wrapping is undefined operation.

One for signed integers for unsigned it is actually defined as
wrapping and the reporter used unsigned integers here.

Thanks,
Andrew Pinski


-- 


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

[Bug tree-optimization/32309] Unnecessary conversion from short to unsigend short breaks vectorization

[pinskia at gmail dot com]

--- Comment #6 from pinskia at gmail dot com  2007-06-12 17:56 ---
Subject: Re:  Unnecessary conversion from short to unsigend short breaks
vectorization

On 12 Jun 2007 17:53:19 -, gangren at google dot com
[EMAIL PROTECTED] wrote:

 I'm aware of integral promotion. But not quite understand why we can optimize
 (short)((int)short_var + (int)short_var) to (short)((unsigned short)short_var 
 +
 (unsigned short)short_var), but not to (short)((short)short_var +
 (short)short_var)? Is it because unsigned short has different overflow
 handling?

Yes, signed short has undefined overflow, while unsigned is defined as
wrapping.

--Pinski


-- 


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

[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code

[pinskia at gmail dot com]

--- Comment #14 from pinskia at gmail dot com  2007-06-14 00:52 ---
Subject: Re:  [4.2 Regression] Incorrect stack sharing causing removal of live
code

On 14 Jun 2007 00:46:28 -, dougkwan at google dot com
[EMAIL PROTECTED] wrote:
 Yes, I saw the code there yesterday and I was wondering if the block
 scope got fixed up somehow.

It can't because the debugging information will be messed up.

-- Pinski


-- 


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

[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code

[pinskia at gmail dot com]

--- Comment #18 from pinskia at gmail dot com  2007-06-14 01:14 ---
Subject: Re:  [4.2 Regression] Incorrect stack sharing causing removal of live
code

On 14 Jun 2007 01:09:16 -, dougkwan at google dot com
[EMAIL PROTECTED] wrote:
 Unless the compiler can prove that f() does not save the pointer to c
 and use it later, it cannot share a stack slot for c  c1. This is
 true regardless of any block scoping in the source. Yeah, it looks
 like accessing c outside of the first block was undefined but I was
 told me that GIMPLE promote c  c1 all the function scope.

Yes but I don't think GIMPLE does that, it might promote register
based ones but not addressable ones (as mentioned before).

Really if we change the stack sharing, we are going to cause a large
number of regressions, I already have some regressions between 4.0 and
4.1 due to stack sharing changes with two large structs not being in
the same slot even though we can put them there with one having an
offset.
And yes I still need to file that bug.

-- Pinski


-- 


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

[Bug libstdc++/32261] Thread race segfault in std::string::append with -O and -s

[pinskia at gmail dot com]

--- Comment #7 from pinskia at gmail dot com  2007-06-14 02:56 ---
Subject: Re:  Thread race segfault in std::string::append with -O and -s

 bug 21334 seems to deal with multiple threads accessing the same shared object
 at the same time.  However, the sample code provided here involves separate
 private objects so there should not be any such issues.  If it is not possible
 to assume that separate threads can access unrelated STL objects at the same
 time, then this would imply that all STL operations (regardless of the object)
 must be serialized!

The empty string is the same object really.

-- Pinski


-- 


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

[Bug fortran/32140] [4.3 Regression] Miscompilation with -O1

[pinskia at gmail dot com]

--- Comment #12 from pinskia at gmail dot com  2007-06-15 15:22 ---
Subject: Re:  [4.3 Regression] Miscompilation with -O1

On 15 Jun 2007 15:12:02 -, fxcoudert at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
 When (and if) I get some time after my PhD defence (next monday), I'll try to
 look into it; after all, I am interested in cp2k myself, even though it 
 doesn't
 yet work for what I need it to do ;-)

note this might get cleared up with pointer_plus.
I have not tried it there yet but i will be posting a patch and committing
soon.

--Pinski


-- 


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

[Bug fortran/32140] [4.3 Regression] Miscompilation with -O1

[pinskia at gmail dot com]

--- Comment #21 from pinskia at gmail dot com  2007-06-20 13:22 ---
Subject: Re:  [4.3 Regression] Miscompilation with -O1

 did this fix test OK ? Since it fixes the CP2K issue, I would hope that it
 could be posted for review soon.

I can't get to testing this patch fully until Friday evening (PST) at
the earliest.  Sorry about that.  My machine was crashing and then I
left for Japan on Monday and won't get access to a machine until
Friday at the earliest with all the meetings in Japan.

-- Pinski


-- 


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

[Bug target/32441] ICE in expand_expr_real_1, at expr.c:7109

[pinskia at gmail dot com]

--- Comment #5 from pinskia at gmail dot com  2007-06-21 13:47 ---
Subject: Re:  ICE in expand_expr_real_1, at expr.c:7109

 You shouldn't introduce calls to langhooks.  Why not use mode_for_size?

I was just copying code from fold-const.c. I have the mode already, I
need an integer tree type that matches that mode.  So really
mode_for_size will not give me any more information.


-- Pinski


-- 


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

[Bug tree-optimization/32461] [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700

[pinskia at gmail dot com]

--- Comment #17 from pinskia at gmail dot com  2007-06-24 10:27 ---
Subject: Re:  [4.3 Regression] Segmentation fault in
build_classic_dist_vector_1() at tree-data-ref.c:2700

On 6/24/07, Sebastian Pop [EMAIL PROTECTED] wrote:
 On 6/24/07, Sebastian Pop [EMAIL PROTECTED] wrote:
  So this just looks like we want to improve operand_equal_p, and not
  touch the folder this time.  Probably we can implement one more flag
  for stripping nop conversions of operands.
 

 Actually I think that the test in operand_equal_p is too strong for
 our case where the expression under the nops is just an SSA_NAME.

 Would a patch like the following one be acceptable?  I've put this
 patch to bootstrap and test with --enable-checking=yes,fold,rtl.

I think you just made oep_can_strip_nops too lose. I think you just
need to strip the NOPs off the call to operand_equal_p when doing a +
~a (and ~a + a) folding.  Or maybe use op1/op0 instead.  I don't think
it is safe to strip NOPs even for SSA_NAMES in operand_equal_p.

Thanks,
Andrew Pinski


-- 


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

[Bug tree-optimization/32461] [4.3 Regression] Segmentation fault in build_classic_dist_vector_1() at tree-data-ref.c:2700

[pinskia at gmail dot com]

--- Comment #18 from pinskia at gmail dot com  2007-06-24 10:33 ---
Subject: Re:  [4.3 Regression] Segmentation fault in
build_classic_dist_vector_1() at tree-data-ref.c:2700

On 6/24/07, Eric Botcazou [EMAIL PROTECTED] wrote:
 Why are the operands of different type at that point?

Because there is a STRIP_NOPS in fold_binary and then we look at
BIT_NOT_EXPR's operand which is a NOP_EXPR.  Maybe we should fold
~(int)unsigned_var into (int)~unsigned_var and that would fix the
issue all the time.

As an aside note, I see we might have a type issue with BIT_NOT_EXPR:

  else if (TREE_CODE (arg0) == BIT_NOT_EXPR)
return TREE_OPERAND (arg0, 0);

if we have ~(int)~unsigned_int, we will get the incorrect type returned.

Thanks,
Andrew Pinski


-- 


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

[Bug fortran/32393] gfortran - incorrect run time results

[pinskia at gmail dot com]

--- Comment #28 from pinskia at gmail dot com  2007-06-24 11:12 ---
Subject: Re:  gfortran - incorrect run time results

On 24 Jun 2007 10:51:42 -, dominiq at lps dot ens dot fr
[EMAIL PROTECTED] wrote:

 (1)  when compiled with 4.1, g95 gives ICE on derived type I/O when compiled
 with -O (at least on Mac OSX 10.3.9):


 [karma] bug/ice_g95_4.1% g95 -O type_1_red.f90
 type_1_red.f90:3: internal compiler error: Bus error
 Please submit a full bug report,
 with preprocessed source if appropriate.
 See http://www.g95.org or mail [EMAIL PROTECTED] for instructions.

So what is the backtrace inside the middle-end?  If possible (and
knowing) give the output of the tree dumps (-fdump-tree-all).  If Andy
is blaming us, he might as well report real bugs instead of just
saying it is our bug.  I would say if Andy does not want even to
report any bugs about the middle-end going wrong (or right, see
below), I would strongly recommend you stay away from g95.

 (2) I have an infinite loop with the following code and -O3:

 ! { dg-do run }
 ! Program to check corner cases for DO statements.

Try with -fwarpv, I bet this is really a bug in g95's IR.  Can you
provide me (us) with the tree dumps?

 A long time ago, I have reported the problem to Andy who is blaming the gcc
 middle-end, so if someone working in this area have an idea ...!

Some cases are our fault, others are g95's fault and Andy might not
want to say it is his fault if the middle-end optimizes away stuff
based on undefined code (which I bet is happening in the last case).

Thanks,
Andrew Pinski


-- 


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

[Bug fortran/32393] gfortran - incorrect run time results

[pinskia at gmail dot com]

--- Comment #30 from pinskia at gmail dot com  2007-06-24 19:37 ---
Subject: Re:  gfortran - incorrect run time results

On 24 Jun 2007 19:28:45 -, dominiq at lps dot ens dot fr
[EMAIL PROTECTED] wrote:
 --- Comment #29 from dominiq at lps dot ens dot fr  2007-06-24 19:28 
 ---
 Try with -fwarpv, I bet this is really a bug in g95's IR.

 -fwarpv is not recognized by g95.

How can it not be recognize by g95  It is a generic GCC option
that has been with GCC since at least 3.4.0.  Guess it is time for g95
issues to be ignored then if it removes common options.


-- Pinski


-- 


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

[Bug fortran/32439] hard-coded memory limit ? f951: out of memory with '-O1 -fbounds-check'

[pinskia at gmail dot com]

--- Comment #4 from pinskia at gmail dot com  2007-06-26 15:20 ---
Subject: Re:  hard-coded memory limit ? f951: out of memory with '-O1
-fbounds-check'

On 26 Jun 2007 14:59:27 -, jv244 at cam dot ac dot uk
[EMAIL PROTECTED] wrote:
 f951: out of memory allocating 4064 bytes after a total of 1148219392 bytes

Ignore the second number, it just is total count of memory allocated
via xmalloc and not the amount of memory used at the time of the
crash.  Why we print it out I have no idea, it is not very useful any
more really.

-- Pinski


-- 


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

[Bug middle-end/32492] [4.3 Regression] attribute always_inline - sorry, unimplemented: recursive inlining

[pinskia at gmail dot com]

--- Comment #13 from pinskia at gmail dot com  2007-06-26 21:59 ---
Subject: Re:  [4.3 Regression] attribute always_inline - sorry, unimplemented:
recursive inlining

On 26 Jun 2007 21:55:34 -, rguenther at suse dot de
[EMAIL PROTECTED] wrote:
 I have a hard time deciding if 3.4 or 4.1 is better:

 3.4:

 f:
 pushl   %ebp
 movl%esp, %ebp
 movl8(%ebp), %edx
 movzbl  12(%ebp), %eax
 testl   %edx, %edx
 je  .L2
 movb$1, %al
 .L2:
 movsbl  %al,%eax
 unconditional movsbl.
 movl%eax, 8(%ebp)
 popl%ebp
 jmp g

 4.1 (same as 4.2):

 f:
 pushl   %ebp
 movl$1, %edx
 movl%esp, %ebp
 movl8(%ebp), %ecx
 movzbl  12(%ebp), %eax
 testl   %ecx, %ecx
 je  .L7
 movl%edx, 8(%ebp)
 popl%ebp
 jmp g
 .p2align 4,,7
 .L7:
 movsbl  %al,%edx
// --- condtional movsbl
 movl%edx, 8(%ebp)
 popl%ebp
 jmp g

It is easier to see the diference between 3.4 and the trunk where we
don't duplicate the tail call to g.

Thanks,
Andrew Pinski


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[pinskia at gmail dot com]

--- Comment #120 from pinskia at gmail dot com  2007-06-27 09:37 ---
Subject: Re:  [meta-bugs] ICEs with CP2K

On 27 Jun 2007 08:24:46 -, jv244 at cam dot ac dot uk
[EMAIL PROTECTED] wrote:
 # BUG
 FCFLAGS  = -O3 -ffast-math -ftree-vectorize -march=native
So -ffast-math with vectorizer changes the results.

I bet this is due to reduction which is done for -ffast-math with
-ftree-vectorize.  Which case it might not be a bug.  Yes 3 out of 130
is actually huge but if the values are huge to begin with, it might be
the case this is just a percussion issue.

-- Pinski


-- 


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

[Bug middle-end/32399] [4.3 Regression] ICE in build2_stat, at tree.c:3074

[pinskia at gmail dot com]

--- Comment #8 from pinskia at gmail dot com  2007-06-27 15:41 ---
Subject: Re:  [4.3 Regression] ICE in build2_stat, at tree.c:3074

On 27 Jun 2007 15:37:26 -, falk at debian dot org
[EMAIL PROTECTED] wrote:


 --- Comment #7 from falk at debian dot org  2007-06-27 15:37 ---
 This makes bootstrap fail on alphaev68-linux:

This is a different bug, related to the alpha backend was not fix up
for pointer plus.
Please file seperately.

Thanks,
Andrew Pinski


-- 


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

[Bug target/32450] -pg seemingly causes miscompilation

[pinskia at gmail dot com]

--- Comment #19 from pinskia at gmail dot com  2007-07-04 20:07 ---
Subject: Re:  -pg seemingly causes miscompilation

On 4 Jul 2007 19:17:22 -, jv244 at cam dot ac dot uk
[EMAIL PROTECTED] wrote:
 b.s:

 .LCFI15:
 cmpl$9, __cp_log_handling_MOD_stack_pointer(%rip)
 callmcount
 movq%rdi, %rbx
 jle .L21

This is obviosuly wrong as the call will most likely clobber the flags
register.

-- Pinski


-- 


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

[Bug tree-optimization/32032] [4.3 Regression] Inliner not setting has_volatile_ops

[pinskia at gmail dot com]

--- Comment #5 from pinskia at gmail dot com  2007-07-08 10:11 ---
Subject: Re:  [4.3 Regression] Inliner not setting has_volatile_ops

 --- Comment #4 from jakub at gcc dot gnu dot org  2007-07-04 12:31 ---
 This doesn't ICE any longer on the trunk.

But that does not mean the bug is still there.  PRE/VN was changed
(which exposed the ICE) but the inliner was not.  Really we should
verify this in the verify_tree_cfg so we catch this early on and not
depend on PRE ICEing.

-- Pinski


-- 


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

[Bug target/32462] [4.3 regression] Linking libgcj.so fails on Solaris 10/x86

[pinskia at gmail dot com]

--- Comment #13 from pinskia at gmail dot com  2007-07-12 15:47 ---
Subject: Re:  [4.3 regression] Linking libgcj.so fails on Solaris 10/x86

On 12 Jul 2007 14:15:06 -, ro at techfak dot uni-bielefeld dot de
[EMAIL PROTECTED] wrote:
  static void
 -hide (tree decl)
 -{
 +hide (tree decl ATTRIBUTE_UNUSED)
 +{
 +#ifdef HAVE_GAS_HIDDEN
DECL_VISIBILITY (decl) = VISIBILITY_HIDDEN;
DECL_VISIBILITY_SPECIFIED (decl) = 1;
 +#endif
  }


This is way too conservative,  see PR 26989 for the reasons why?

Thanks,
Andrew Pinski


-- 


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

[Bug libstdc++/28125] Cannot build cross compiler for Solaris: configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES

[pinskia at gmail dot com]

--- Comment #20 from pinskia at gmail dot com  2007-07-17 05:19 ---
Subject: Re:  Cannot build cross compiler for Solaris: configure: error: Link
tests are not allowed after GCC_NO_EXECUTABLES

On 17 Jul 2007 05:15:47 -, cnstar9988 at gmail dot com
[EMAIL PROTECTED] wrote:


 --- Comment #18 from cnstar9988 at gmail dot com  2007-07-17 05:15 ---
 (In reply to comment #17)
  Did you copy all of the libraries including the 64bit ones?
 hp 11.11(pa8800), supports both 32 and 64bit.

That comment was not for you, it was the reporter for this specific bug.

-- Pinski


-- 


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

[Bug libgomp/32789] Profiling not possible with -fopenmp

[pinskia at gmail dot com]

--- Comment #5 from pinskia at gmail dot com  2007-07-17 10:26 ---
Subject: Re:  Profiling not possible with -fopenmp

On 17 Jul 2007 10:24:12 -, jensseidel at users dot sf dot net
[EMAIL PROTECTED] wrote:
 An Open MPI related discussion about atomic operations happened
 the last days, because architecture specific assembler code failed again
 for some exotic platforms.

And that is the reason why GCC added atomic builtins when openmp came
in also.  There are manuals for a reason :).

-- Pinski


-- 


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

[Bug middle-end/32791] missed optimization after inline functions with multiple return statements

[pinskia at gmail dot com]

--- Comment #4 from pinskia at gmail dot com  2007-07-19 17:56 ---
Subject: Re:  missed optimization after inline functions with multiple return
statements

On 19 Jul 2007 17:52:14 -, manuelle at ee dot ethz dot ch
[EMAIL PROTECTED] wrote:
 your testcase from bug 32810 does the right thing on x86.

Yes I know it works overall but the tree level optimizer does not do it,

-- Pinski


-- 


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

[Bug target/25413] wrong alignment or incorrect address computation in vectorized code on Pentium 4 SSE

[pinskia at gmail dot com]

--- Comment #20 from pinskia at gmail dot com  2007-07-25 09:12 ---
Subject: Re:  wrong alignment or incorrect address computation in vectorized
code on Pentium 4 SSE

On 25 Jul 2007 08:40:09 -, dorit at gcc dot gnu dot org
[EMAIL PROTECTED] wrote
 In the meantime, would you please try this patch?:

Of course after my patch for PR 16660, the patch here should be
changed to just return true always.

Thanks,
Andrew Pinski


-- 


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

[Bug middle-end/32887] warning for memset with zero size

[pinskia at gmail dot com]

--- Comment #14 from pinskia at gmail dot com  2007-07-26 16:51 ---
Subject: Re:  warning for memset with zero size

On 26 Jul 2007 13:57:41 -, manu at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:

 I think that is a sensible feature request, am I missing something Andrew?

memset with a zero size is valid code.

Thanks,
Andrew Pinski


-- 


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

[Bug target/32951] missed memcpy - movdqa optimization.

[pinskia at gmail dot com]

--- Comment #3 from pinskia at gmail dot com  2007-08-06 12:43 ---
Subject: Re:  missed memcpy - movdqa optimization.

On 6 Aug 2007 12:42:18 -, pluto at agmk dot net
[EMAIL PROTECTED] wrote:
 moreover i'm wondering why gcc uses movdqa for unaligned loads?

Because __m128i is assumed to be aligned.

-- Pinski


-- 


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

[Bug libfortran/32784] [win32] Using 'con' as assigned file generates Fortran runtime error: File 'con' does not exist

[pinskia at gmail dot com]

--- Comment #26 from pinskia at gmail dot com  2007-08-12 23:07 ---
Subject: Re:  [win32] Using 'con' as assigned file generates Fortran runtime
error: File 'con' does not exist

On 12 Aug 2007 22:45:07 -, steven dot chapel at sbcglobal dot net
[EMAIL PROTECTED] wrote:
 The code above works with gcc 3.4.5.

Which means it worked in g77 and not in gfortran (which is new for
4.0.0).  Now we have this weird thing about how gfortran is a new
front-end and g77 was removed.  So this could go either as a
regression or really a new feature.  Also why does this program use
con anyways, shouldn't it just use the default units which are
connected to stdio/stdout anyways as they might not be connected to
the console anyways?

Thanks,
Andrew Pinski


-- 


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

[Bug target/33115] -march=native is not supported under x86 darwin

[pinskia at gmail dot com]

--- Comment #2 from pinskia at gmail dot com  2007-08-19 21:39 ---
Subject: Re:  -march=native is not supported under x86 darwin

On 19 Aug 2007 21:12:22 -, dje at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
 x86 darwin should be able to re-use the implementation from
 rs6000/driver-rs6000.c because the kernel interfaces to query the information
 are the same.

Well and i386/driver-i386.c uses inline-asm so it should able to use that also.
EXTRA_GCC_OBJS =driver-i386.o darwin-driver.o
We are able to compile driver-i386.c but just not use it.

The problem is that CC1_SPEC does not use %(cc1_cpu).

Thanks,
Andrew Pinski


-- 


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

[Bug testsuite/33153] FAIL: gcc.dg/pr32912-[12].c (test for excess errors)

[pinskia at gmail dot com]

--- Comment #3 from pinskia at gmail dot com  2007-08-22 23:42 ---
Subject: Re:  FAIL: gcc.dg/pr32912-[12].c (test for excess errors)

On 22 Aug 2007 23:39:50 -, dave at hiauly1 dot hia dot nrc dot ca
[EMAIL PROTECTED] wrote:

 Right.  Would it be ok to make this declaration static?  That
 will avoid the warning.

I think in this case, yes.

Thanks,
Andrew Pinski


-- 


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

[Bug tree-optimization/34416] Tree optimization pipeline needs re-tuning

[pinskia at gmail dot com]

--- Comment #1 from pinskia at gmail dot com  2007-12-10 12:04 ---
Subject: Re:  New: Tree optimization pipeline needs re-tuning

On 10 Dec 2007 10:07:09 -, rguenth at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
  - run DCE after vectorization, the IL is completely hosed for
tree based costs otherwise (affects unrolling costs)

This is already done:
  NEXT_PASS (pass_vectorize);
{
  struct tree_opt_pass **p = pass_vectorize.sub;
  NEXT_PASS (pass_lower_vector_ssa);
  NEXT_PASS (pass_dce_loop);
}

Thanks,
Andrew Pinski


-- 


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