[Bug middle-end/36106] #pragma omp atomic issues with floating point types

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2008-05-07 07:28 ---
Subject: Bug 36106

Author: jakub
Date: Wed May  7 07:28:14 2008
New Revision: 135027

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135027
Log:
PR middle-end/36106
* omp-low.c (expand_omp_atomic_pipeline): Load value using the
integral type rather than floating point, then VIEW_CONVERT_EXPR
to the floating point type.

* testsuite/libgomp.c/atomic-5.c: New test.
* testsuite/libgomp.c/atomic-6.c: New test.
* testsuite/libgomp.c/autopar-1.c: New test.

Added:
trunk/libgomp/testsuite/libgomp.c/atomic-5.c
trunk/libgomp/testsuite/libgomp.c/atomic-6.c
trunk/libgomp/testsuite/libgomp.c/autopar-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/omp-low.c
trunk/libgomp/ChangeLog


-- 


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

[Bug middle-end/36137] gcc can't do math

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2008-05-07 07:41 ---
Subject: Bug 36137

Author: jakub
Date: Wed May  7 07:40:01 2008
New Revision: 135028

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135028
Log:
PR middle-end/36137
* fold-const.c (fold_binary): Use STRIP_SIGN_NOPS instead of
STRIP_NOPS on arguments even for MIN_EXPR and MAX_EXPR.

* gcc.c-torture/execute/20080506-1.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/20080506-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/36013] [4.1/4.3/4.4 Regression] Wrong code involving restricted pointers to non-restricted pointers

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2008-05-07 07:46 ---
Subject: Bug 36013

Author: jakub
Date: Wed May  7 07:45:17 2008
New Revision: 135029

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135029
Log:
PR middle-end/36013
* gimplify.c (find_single_pointer_decl_1): Don't look through
indirections.
(find_single_pointer_decl): Adjust comments.

* gcc.c-torture/execute/20080506-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/20080506-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/36129] [4.4 Regression] ICE with -fprofile-use

[jv244 at cam dot ac dot uk]

-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


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

[Bug middle-end/36106] #pragma omp atomic issues with floating point types

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2008-05-07 07:56 ---
Subject: Bug 36106

Author: jakub
Date: Wed May  7 07:55:21 2008
New Revision: 135030

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135030
Log:
PR middle-end/36106
* omp-low.c (expand_omp_atomic_pipeline): Load value using the
integral type rather than floating point, then VIEW_CONVERT_EXPR
to the floating point type.

* testsuite/libgomp.c/atomic-5.c: New test.
* testsuite/libgomp.c/atomic-6.c: New test.
* testsuite/libgomp.c/autopar-1.c: New test.

Added:
branches/gcc-4_3-branch/libgomp/testsuite/libgomp.c/atomic-5.c
branches/gcc-4_3-branch/libgomp/testsuite/libgomp.c/atomic-6.c
branches/gcc-4_3-branch/libgomp/testsuite/libgomp.c/autopar-1.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/omp-low.c
branches/gcc-4_3-branch/libgomp/ChangeLog


-- 


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

[Bug middle-end/36137] gcc can't do math

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2008-05-07 07:59 ---
Subject: Bug 36137

Author: jakub
Date: Wed May  7 07:58:33 2008
New Revision: 135031

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135031
Log:
PR middle-end/36137
* fold-const.c (fold_binary): Use STRIP_SIGN_NOPS instead of
STRIP_NOPS on arguments even for MIN_EXPR and MAX_EXPR.

* gcc.c-torture/execute/20080506-1.c: New test.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/execute/20080506-1.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/fold-const.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/36013] [4.1/4.3/4.4 Regression] Wrong code involving restricted pointers to non-restricted pointers

[jakub at gcc dot gnu dot org]

--- Comment #9 from jakub at gcc dot gnu dot org  2008-05-07 08:01 ---
Subject: Bug 36013

Author: jakub
Date: Wed May  7 08:00:36 2008
New Revision: 135032

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135032
Log:
PR middle-end/36013
* gimplify.c (find_single_pointer_decl_1): Don't look through
indirections.
(find_single_pointer_decl): Adjust comments.

* gcc.c-torture/execute/20080506-2.c: New test.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/execute/20080506-2.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/gimplify.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/36106] #pragma omp atomic issues with floating point types

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2008-05-07 08:05 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/36137] gcc can't do math

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2008-05-07 08:06 ---
Fixed in 4.3 and on the trunk.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/36013] [4.1/4.3/4.4 Regression] Wrong code involving restricted pointers to non-restricted pointers

[jakub at gcc dot gnu dot org]

--- Comment #10 from jakub at gcc dot gnu dot org  2008-05-07 08:07 ---
Committed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/36013] [4.1/4.3/4.4 Regression] Wrong code involving restricted pointers to non-restricted pointers

[rguenther at suse dot de]

--- Comment #11 from rguenther at suse dot de  2008-05-07 08:21 ---
Subject: Re:  [4.1/4.3/4.4 Regression] Wrong code
 involving restricted pointers to non-restricted pointers

On Tue, 6 May 2008, jakub at gcc dot gnu dot org wrote:

> --- Comment #6 from jakub at gcc dot gnu dot org  2008-05-06 22:56 ---
> Created an attachment (id=15588)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15588&action=view)
>  --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15588&action=view)
> gcc44-pr36013.patch
> 
> Patch I've bootstrapped/regtested on x86_64-linux.  Will you check this in, or
> should I mail it to gcc-patches?
> 
> I've played with testcases like:
> 
> int
> foo (int *__restrict p, int *__restrict q)
> {
>   int *r, *s, t;
>   *p = 1;
>   *q = 2;
>   p[6] = 3;
>   q[6] = 4;
>   for (r = p, s = q, t = 0; r < p + 64; r++, s++)
> {
>   *r = 7;
>   *s = 88;
>   t += *r;
> }
>   return t;
> }
> 
> and here neither tree nor RTL aliasing is ATM able to optimize the subsequent
> read from *r out - while the accesses before the loop use different alias sets
> (3 resp. 4), in the loop everything uses alias set 2, but that isn't a
> regression introduced with this patch, so probably DECL_BASED_ON_RESTRICT_P
> stuff needs more work, but that is unrelated to this bug.

The patch/rfc I posted two days ago optimizes the above case on the tree
level.  I will make sure something like that goes into 4.4.

Richard.


-- 


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

[Bug debug/36037] [4.4 regression] segfault in gt_ggc_mx_dw_loc_descr_struct

[jv244 at cam dot ac dot uk]

--- Comment #1 from jv244 at cam dot ac dot uk  2008-05-07 08:45 ---
here things appear to work ? What are the numbers you have for '--param
ggc-min-expand=30 --param ggc-min-heapsize=4096' ?

> gfortran -c -O2 -g -fmem-report all.f90
Memory still allocated at the end of the compilation process
Size   AllocatedUsedOverhead
8   4096  16 120
1613M   1668k304k
128 4044k675k 55k
256 4068k   3349k 55k
512  252M227M   3541k
1024  16k   6144 224
2048  28k 16k392
4096 684k684k   9576
8192  32k 32k224
16384 32k 32k112
32768 32k 32k 56
65536128k128k112
131072512k512k224
262144768k768k168
524288   2048k   2048k224
1048576   3072k   3072k168
4194304   4096k   4096k 56
8388608   8192k   8192k 56
192  115M101M   1613k
160   79M 64M   1109k
144   11M   6162k158k
96   132M 71M   1861k
48   150M 80M   2403k
208   38M 35M533k
6431M   1683k499k
32   103M   9308k   1866k
80   278M 54M   3900k
Total   1234M678M 17M

String pool
entries 1324233
identifiers 1324233 (100.00%)
slots   2097152
bytes   14M (1384k overhead)
table size  16M
coll/search 0.5910
ins/search  0.0865
avg. entry  11.43 bytes (+/- 4.53)
longest entry   68

??? tree nodes created

(No per-node statistics)
Type hash: size 131071, 71937 elements, 1.616711 collisions
DECL_DEBUG_EXPR  hash: size 65521, 22 elements, 0.439186 collisions
DECL_VALUE_EXPR  hash: size 1021, 19 elements, 0.00 collisions


-- 


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

[Bug fortran/36167] New: internal compiler error: in gfc_conv_descriptor_dimension, at fortran/trans-array.c:242

[fmuldoo at me dot lsu dot edu]

[EMAIL PROTECTED] temp]# gfortran -c  -O0 gfortran-error-1.f90
!gfortran-error-1.f90: In function \u2018write_out_particles\u2019:
!gfortran-error-1.f90:21: internal compiler error: in
gfc_conv_descriptor_dimension, at fortran/trans-array.c:242
!Please submit a full bug report,
!with preprocessed source if appropriate.
!See  for instructions.
[EMAIL PROTECTED] temp]# gfortran --version
!GNU Fortran (GCC) 4.4.0 20080302 (experimental) [trunk revision 132813]
!Copyright (C) 2007 Free Software Foundation, Inc.

!GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
!You may redistribute copies of GNU Fortran
!under the terms of the GNU General Public License.
!For more information about these matters, see the file named COPYING

[EMAIL PROTECTED] temp]# uname -a
!Linux localhost.localdomain 2.6.23.12-52.fc7 #1 SMP Tue Dec 18 21:18:02 EST
2007 i686 i686 i386 GNU/Linux
[EMAIL PROTECTED] temp]# rpm -q glibc
!glibc-2.6-4


-- 
   Summary: internal compiler error: in
gfc_conv_descriptor_dimension, at fortran/trans-
array.c:242
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fmuldoo at me dot lsu dot edu


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

[Bug fortran/36167] internal compiler error: in gfc_conv_descriptor_dimension, at fortran/trans-array.c:242

[fmuldoo at me dot lsu dot edu]

--- Comment #1 from fmuldoo at me dot lsu dot edu  2008-05-07 09:32 ---
Created an attachment (id=15589)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15589&action=view)
Very small code example


-- 


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

[Bug c++/36168] Incorrect (and strange) warnings with -Wuninitialized

[martin at mpa-garching dot mpg dot de]

--- Comment #1 from martin at mpa-garching dot mpg dot de  2008-05-07 09:35 
---
Created an attachment (id=15590)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15590&action=view)
a (not really reduced) test case


-- 


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

[Bug c++/36168] Incorrect (and strange) warnings with -Wuninitialized

[martin at mpa-garching dot mpg dot de]

--- Comment #6 from martin at mpa-garching dot mpg dot de  2008-05-07 09:57 
---
OK. Thanks for the clarification!


-- 


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

[Bug c++/36168] Incorrect (and strange) warnings with -Wuninitialized

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2008-05-07 09:54 ---
(In reply to comment #4)
> Is this also expected behavior?

Most likely because SRA choses not to scalarize the aggregate.  Aka the
optimizators are choosing different choses based on the code.   Nothing new.

-- Pinski


-- 


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

[Bug c++/36168] Incorrect (and strange) warnings with -Wuninitialized

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-05-07 09:43 ---
This is a normal issue with the unitialized warnings.  See PR 5035.  Basically
to get this warning correct for this case, you need conditional PHIs which we
don't have currently.  And I don't know of any compiler that does.  

Basically the code looks like:

if (a)
 set b
for(...)
  for(...)
if (a)
  use b

Unswitching the loops will help somewhat as then you can then jump thread.

Thanks,
Andrew Pinski


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||24639
  nThis||
   Severity|normal  |enhancement
   Keywords|diagnostic  |
  Known to fail|4.2.3 4.4.0 |


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

[Bug c++/36168] Incorrect (and strange) warnings with -Wuninitialized

[martin at mpa-garching dot mpg dot de]

--- Comment #4 from martin at mpa-garching dot mpg dot de  2008-05-07 09:51 
---
It would be completely fine by me, if g++ simply emitted bogus warnings in a
consistent way. But the syntax is still confusing, and what seems quite
disconcerting to me is the fact that _both_ warnings disappear if I comment the
line 37214 (lpic[x][y].g = q.g;). Is this also expected behaviour?


-- 


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

[Bug c++/36168] Incorrect (and strange) warnings with -Wuninitialized

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2008-05-07 09:51 ---
Also you may as well manually unswitch the loops as they don't do anything
except some multiplication if that bool is true.  That is better to write the
code as:
   if (a_eq_e)
return;
  e=p[m].e;
 
q=COLOUR8(e.r/(a.r+grayabsorb),e.g/(a.g+grayabsorb),e.b/(a.b+grayabsorb));
  float64 radsq = rfacr*rfacr;
  float64 prefac1 = -0.5/(r*r*sigma0*sigma0);
  float64 prefac2 = -0.5*bfak/p[m].ro;
{
for (int x=minx; xhttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=36168

[Bug c++/36168] New: Incorrect (and strange) warnings with -Wuninitialized

[martin at mpa-garching dot mpg dot de]

When compiling the attached testcase with current mainline, bogus warnings are
emitted:

/scratch/martin/splotch>g++ -v -O -Wuninitialized bug.ii
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /scratch/martin/gcc/configure
--prefix=/afs/mpa/data/martin/ugcc --with-mpfr-include=/usr/include
--with-mpfr-lib=/usr/lib --with-gmp-include=/usr/include
--with-gmp-lib=/usr/lib --enable-languages=c++,fortran
--enable-checking=release
Thread model: posix
gcc version 4.4.0 20080507 (experimental) [trunk revision 135032] (GCC) 
COLLECT_GCC_OPTIONS='-v' '-O' '-Wuninitialized' '-shared-libgcc'
'-mtune=generic'
 /afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/4.4.0/cc1plus
-fpreprocessed bug.ii -quiet -dumpbase bug.ii -mtune=generic -auxbase bug -O
-Wuninitialized -version -o /tmp/ccSh8Ooh.s
GNU C++ (GCC) version 4.4.0 20080507 (experimental) [trunk revision 135032]
(i686-pc-linux-gnu)
compiled by GNU C version 4.4.0 20080507 (experimental) [trunk revision
135032], GMP version 4.2.1, MPFR version 2.3.1.
warning: GMP header version 4.2.1 differs from library version 4.2.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: d49e4fa2e0d6ffd2b8e9abb2dcc5530c
In file included from splotch/splotch.cc:37,
 from fullsplotch.cc:5:
./splotch/splotchutils.h: In member function 'void
splotch_renderer::render(const std::vector
>&, arr2&, bool, double)':
./splotch/splotchutils.h:132: warning: 'q.COLOUR8::r' may be used uninitialized
in this function
./splotch/splotchutils.h:132: warning: 'q.COLOUR8::g' may be used uninitialized
in this function
COLLECT_GCC_OPTIONS='-v' '-O' '-Wuninitialized' '-shared-libgcc'
'-mtune=generic'
 as -V -Qy -o /tmp/ccPwUfT2.o /tmp/ccSh8Ooh.s
GNU assembler version 2.18 (i686-pc-linux-gnu) using BFD version (GNU Binutils)
2.18
COMPILER_PATH=/afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/4.4.0/:/afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/4.4.0/:/afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/:/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.4.0/:/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/:/usr/libexec/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/
LIBRARY_PATH=/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.4.0/:/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-O' '-Wuninitialized' '-shared-libgcc'
'-mtune=generic'
 /afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/4.4.0/collect2
--eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o
/usr/lib/crti.o
/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.4.0/crtbegin.o
-L/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.4.0
-L/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.4.0/../../..
/tmp/ccPwUfT2.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.4.0/crtend.o
/usr/lib/crtn.o

There are several funny things happening here:
 - in principle the compiler is able to detect that "q" will not be used
uninitialized; if I remove pieces of code somewhere completely different in the
testcase, the warning dieappears
 - the syntax "'q.COLOUR8::r' may be used uninitialized in this function" is
unexpected; typically the warnings look different
 - whether the warning is printed or not depends very sensitively on the
surrounding code, so it's very hard to produce a small testcase. I have the
feeling that it is only emitted if the processed function exceeds a certain
complexity; but this is just a guess.

I have observed this behaviour in older versions, back to (at least) 4.2, but
did not open a PR about it before, since I wasn't able to provide a good
testcase. I hope the attached one is not completely useless ...


-- 
   Summary: Incorrect (and strange) warnings with -Wuninitialized
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martin at mpa-garching dot mpg dot de
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug c/31983] Add option to gcc to display specific language manual section reference for error/warning encountered.

[manu at gcc dot gnu dot org]

--- Comment #7 from manu at gcc dot gnu dot org  2008-05-07 10:06 ---
(In reply to comment #6)
> Colorization of a message is part of the message. It should obviously be done
> whereever the message is constructed. (IDE has nothing to do with this.) With
> your argument, the compiler should not do text messages (or any localization
> thereof) either, but rather return some code that an external program
> formats/localizes and presents to the user in a suitable way.

Actually, that doesn't sound too bad. It will probably help to embed GCC in
IDEs and other customizations. But I digress...

Adding color output (ala ls --color) or the proposal in this bug (gcc as a
lecturer in programming) show a critical misunderstanding: Assuming that GCC
developers are bored and have nothing to do. There are many many features that
GCC developers themselves would like to see implemented and they are not
because of lack of time. Therefore, people coming up with random half-backed
ideas, which they do not intend to fully specify, much less implement, is
hopeless.

Honestly, GCC is free software. Anyone can implement whatever they want. We
gave you our reasons why we think this is a bad idea. Prove us wrong by writing
the code (or finding someone to write it for you). If it is indeed a good idea,
distributions and users will pick it up and that will show that developers
should change their minds and include it in the original source code.


-- 


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

[Bug c++/36168] Incorrect (and strange) warnings with -Wuninitialized

[manu at gcc dot gnu dot org]

--- Comment #7 from manu at gcc dot gnu dot org  2008-05-07 10:12 ---
This would be more consistent if uninitialized warnings would work in VOPs.

Anyway, I think we should keep this open as an interesting testcase.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-05-07 10:12:31
   date||


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

[Bug debug/36037] [4.4 regression] segfault in gt_ggc_mx_dw_loc_descr_struct

[fxcoudert at gcc dot gnu dot org]

--- Comment #2 from fxcoudert at gcc dot gnu dot org  2008-05-07 10:17 
---
OK, well, it was 100% reproducible two weeks ago, but I can't see it happening
anymore on trunk. Closing.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


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

[Bug c++/36122] Arm EABI C++ optimiser handles bit fields incorrectly

[john dot spelis at 3dlabs dot com]

--- Comment #2 from john dot spelis at 3dlabs dot com  2008-05-07 11:14 
---
Subject: Re:  Arm EABI C++ optimiser handles bit fields
 incorrectly


Thanks pinskia. I ported the 4.3.0 compilers and that's a 
confirmed fix to the issue.

Best Regards


On 5 May 2008, pinskia at gcc dot gnu dot org wrote:

> 
> 
> --- Comment #1 from pinskia at gcc dot gnu dot org  2008-05-05 04:50 
> ---
> This is most likely a dup of bug 33887 and has been fixed for GCC 4.3.0.
> 
> 
> -- 
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36122
> 
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
> 


-- 


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

[Bug c++/36159] C++ compiler should issue a warning with missing new operator

[joseph at codesourcery dot com]

--- Comment #6 from joseph at codesourcery dot com  2008-05-07 11:25 ---
Subject: Re:  C++ compiler should issue a warning with  missing
 new operator

On Wed, 7 May 2008, pinskia at gcc dot gnu dot org wrote:

> aligned memory.  PPC LV2 returns 16byte aligned memory.  PPC Linux should be
> returning 16byte aligned memory for the 128bit long double but from what I
> remember or last heard does not.

There is a patch for that glibc bug 
, but the glibc 
maintainers have not reviewed it.


-- 


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

[Bug c/31983] Add option to gcc to display specific language manual section reference for error/warning encountered.

[esigra at gmail dot com]

--- Comment #8 from esigra at gmail dot com  2008-05-07 13:08 ---
(In reply to comment #7)
> Adding color output (ala ls --color) or the proposal in this bug (gcc as a
> lecturer in programming) show a critical misunderstanding: Assuming that GCC
> developers are bored and have nothing to do. There are many many features that
> GCC developers themselves would like to see implemented and they are not
> because of lack of time. Therefore, people coming up with random half-backed
> ideas, which they do not intend to fully specify, much less implement, is
> hopeless.

Sorry, you got it totally wrong! When someone suggests a feature that he thinks
would be useful, he does definitely not imply that the current developers are
bored and have nothing to do.

The critical misunderstanding here is that some GCC developers think that a
feature request is something that they are obliged to implement within a
certain time and the only way to get rid of that obligation is to dismiss any
idea, that they do not have time to implement right now, as invalid.

We are developers too for various projects and we get feature requests all the
time. Many of the ideas that we get are useful but there is no way that we can
implement them all within the foreseeable future. Still we do not rush to
dismiss ideas as invalid. And we certainly do not misconceieve it as
implications that we are bored or do not have any ideas of our own.

I think the criterion for closing feature requests as invalid should be
modified from "we do not have time to implement this feature any time soon" to
"there is no way that this feature would be useful". This is how most projects
handle it and what reporters interpret it as.


-- 


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

[Bug target/35714] x86 poor code with pmaddwd

[uros at gcc dot gnu dot org]

--- Comment #4 from uros at gcc dot gnu dot org  2008-05-07 13:12 ---
Subject: Bug 35714

Author: uros
Date: Wed May  7 13:12:02 2008
New Revision: 135041

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135041
Log:
PR target/35714
* config/i386/mmx.md (mmx_subv2sf3): New expander.
(*mmx_subv2sf3): Rename from mmx_subv2sf3 insn pattern.
(*mmx_eqv2sf3): Rename from mmx_eqv2sf3 insn pattern.
(mmx_eqv2sf3): New expander.  Use ix86_fixup_binary_operands_no_copy
to handle nonimmediate operands.
(*mmx_paddwd): Rename from mmx_paddwd insn pattern.
(mmx_paddwd): New expander.  Use ix86_fixup_binary_operands_no_copy
to handle nonimmediate operands.
(*mmx_pmulhrwv4hi3): Rename from mmx_pmulhrwv4hi3 insn pattern.
(mmx_pmulhrwv4hi3): New expander.  Use
ix86_fixup_binary_operands_no_copy to handle nonimmediate operands.
(*sse2_umulv1siv1di3): Rename from sse2_umulv1siv1di3 insn pattern.
(sse2_umulv1siv1di3): New expander.  Use
ix86_fixup_binary_operands_no_copy to handle nonimmediate operands.
(*mmx_eq3): Rename from mmx_eq3 insn pattern.
(mmx_eq3): New expander.  Use
ix86_fixup_binary_operands_no_copy to handle nonimmediate operands.
(*mmx_uavgv8qi3): Rename from mmx_uavgv8qi3 insn pattern.
(mmx_uavgv8qi3): New expander.  Use
ix86_fixup_binary_operands_no_copy to handle nonimmediate operands.
(*mmx_uavgv4hi3): Rename from mmx_uavgv4hi3 insn pattern.
(mmx_uavgv4hi3): New expander.  Use
ix86_fixup_binary_operands_no_copy to handle nonimmediate operands.

* config/i386/sse.md
(*sse_movhlps): Rename from sse_movhlps insn pattern.
(sse_movhlps): New expander.  Use ix86_fixup_binary_operands
to handle nonimmediate operands.
(*sse_movlhps): Rename from sse_movlhps insn pattern.
(sse_movlhps): New expander.  Use ix86_fixup_binary_operands
to handle nonimmediate operands.
(*sse_loadhps): Rename from sse_loadhps insn pattern.
(sse_loadhps): New expander.  Use ix86_fixup_binary_operands
to handle nonimmediate operands.
(*sse_loadlps): Rename from sse_loadlps insn pattern.
(sse_loadlps): New expander.  Use ix86_fixup_binary_operands
to handle nonimmediate operands.
(*sse2_unpckhpd): Rename from sse2_unpckhpd insn pattern.
(sse2_unpckhpd): New expander.  Use
ix86_fixup_binary_operands_no_copy to handle nonimmediate operands.
(*sse2_unpcklpd): Rename from sse2_unpcklpd insn pattern.
(sse2_unpcklpd): New expander.  Use
ix86_fixup_binary_operands_no_copy to handle nonimmediate operands.
(*sse_loadhpd): Rename from sse_loadhpd insn pattern.
(sse_loadhpd): New expander.  Use ix86_fixup_binary_operands
to handle nonimmediate operands.
(*sse_loadlpd): Rename from sse_loadlpd insn pattern.
(sse_loadlpd): New expander.  Use ix86_fixup_binary_operands
to handle nonimmediate operands.
(*sse2_3): Rename from
sse2_3 insn pattern.
(sse2_3): New expander.  Use
ix86_fixup_binary_operands_no_copy to handle nonimmediate operands.
(*sse2_umulv2siv2di3): Rename from sse2_umulv2siv2di3 insn pattern.
(sse2_umulv2siv2di3): New expander.  Use
ix86_fixup_binary_operands_no_copy to handle nonimmediate operands.
(*sse4_1_mulv2siv2di3): Rename from sse4_1_mulv2siv2di3 insn pattern.
(sse4_1_mulv2siv2di3): New expander.  Use
ix86_fixup_binary_operands_no_copy to handle nonimmediate operands.
(*sse2_pmaddwd): Rename from sse2_pmaddwd insn pattern.
(sse2_pmaddwd): New expander.  Use
ix86_fixup_binary_operands_no_copy to handle nonimmediate operands.
(*sse2_eq3): Rename from sse2_eq3 insn pattern.
(sse2_eq3): New expander.  Use
ix86_fixup_binary_operands_no_copy to handle nonimmediate operands.
(*sse4_1_eqv2di3): Rename from sse4_1_eqv2di3 insn pattern.
(sse4_1_eqv2di3): New expander.  Use
ix86_fixup_binary_operands_no_copy to handle nonimmediate operands.
(*sse2_uavgv16qi3): Rename from sse2_uavgv16qi3 insn pattern.
(sse2_uavgv16qi3): New expander.  Use
ix86_fixup_binary_operands_no_copy to handle nonimmediate operands.
(*sse2_uavgv16qi3): Rename from sse2_uavgv16qi3 insn pattern.
(sse2_uavgv16qi3): New expander.  Use
ix86_fixup_binary_operands_no_copy to handle nonimmediate operands.
(*sse2_uavgv8hi3): Rename from sse2_uavgv8hi3 insn pattern.
(sse2_uavgv8hi3): New expander.  Use
ix86_fixup_binary_operands_no_copy to handle nonimmediate operands.
(*ssse3_pmulhrswv8hi3): Rename from ssse3_pmulhrswv8hi3 insn pattern.
(ssse3_pmulhrswv8hi3): New expander.  Use
ix86_fixup_binary_operands_no_copy to handle nonimmediate opera

[Bug target/35714] x86 poor code with pmaddwd

[ubizjak at gmail dot com]

--- Comment #5 from ubizjak at gmail dot com  2008-05-07 13:33 ---
The problem with memory operands has been fixed by the patch, so we generate
optimal one insn sequence for both functions in:

--cut here--
#include 

extern __m128i a;

__m128i madd (__m128i b)
{
  return _mm_madd_epi16(a, b);
}

__m128i madd_swapped (__m128i b)
{
return _mm_madd_epi16(b, a);
}
--cut here--

Original testcase passes immediate operand to expanders. Since immediates don't
satisfy insn operand constraints, we move them to the register. Since there is
no direct imm->reg load insn for V4SF, they are first pushed to memory and then
loaded to register.

To solve this problem, we should push immediates to the memory in case insn
supports memory operands. Alternatively, we can perhaps find original memory
location (if available) and pass this location to the expander.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ubizjak at gmail dot com
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-05-07 13:33:55
   date||


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

[Bug ada/16087] Legal program rejected, RM 7.3(13)

[sam at gcc dot gnu dot org]

-- 

sam at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |sam at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-06-14 21:03:20 |2008-05-07 14:03:04
   date||


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

[Bug fortran/36167] ICE in gfc_conv_descriptor_dimension, at fortran/trans-array.c:242

[burnus at gcc dot gnu dot org]

-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
  Known to fail||4.1.2 4.2.1 4.3.0 4.4.0
   Last reconfirmed|-00-00 00:00:00 |2008-05-07 14:07:21
   date||
Summary|internal compiler error: in |ICE in
   |gfc_conv_descriptor_dimensio|gfc_conv_descriptor_dimensio
   |n, at fortran/trans-|n, at fortran/trans-
   |array.c:242 |array.c:242


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

[Bug ada/34354] Bug box in save_gnu_tree, at ada/utils.c:176, in legal Ada 2005 program

[sam at gcc dot gnu dot org]

--- Comment #2 from sam at gcc dot gnu dot org  2008-05-07 14:07 ---
This appears to be fixed in GCC 4.3.2 and in SVN trunk.


-- 

sam at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug bootstrap/36169] New: [4.4 Regression] gcc/fortran/simplify.c:3956: internal compiler error: in gen_reg_rtx, at emit-rtl.c:868

[dominiq at lps dot ens dot fr]

Gcc revision 135041 failed to bootstrap at:

...
/opt/gcc/i686-darwin/./prev-gcc/xgcc -B/opt/gcc/i686-darwin/./prev-gcc/
-B/opt/gcc/gcc4.4w/i686-apple-darwin9/bin/ -c  -g -O2 -fomit-frame-pointer
-DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros 
-Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H -I. -Ifortran
-I../../gcc-4.4-work/gcc -I../../gcc-4.4-work/gcc/fortran
-I../../gcc-4.4-work/gcc/../include -I./../intl
-I../../gcc-4.4-work/gcc/../libcpp/include -I/sw/include 
-I../../gcc-4.4-work/gcc/../libdecnumber
-I../../gcc-4.4-work/gcc/../libdecnumber/dpd -I../libdecnumber 
../../gcc-4.4-work/gcc/fortran/simplify.c -o fortran/simplify.o
../../gcc-4.4-work/gcc/fortran/simplify.c: In function
'gfc_simplify_set_exponent':
../../gcc-4.4-work/gcc/fortran/simplify.c:3956: internal compiler error: in
gen_reg_rtx, at emit-rtl.c:868
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [fortran/simplify.o] Error 1
make[3]: *** Waiting for unfinished jobs
rm gcj-dbtool.pod fsf-funding.pod jcf-dump.pod jv-convert.pod grmic.pod
gcov.pod gcj.pod gc-analyze.pod gfdl.pod cpp.pod gij.pod gfortran.pod gcc.pod
make[2]: *** [all-stage2-gcc] Error 2
make[1]: *** [stage2-bubble] Error 2
make: *** [all] Error 2

Last successful bootstrap at rev. 135023, last successful update rev. 135039.


-- 
   Summary: [4.4 Regression] gcc/fortran/simplify.c:3956: internal
compiler error: in gen_reg_rtx, at emit-rtl.c:868
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
 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=36169

[Bug ada/36171] New: Missing documentation for Relative_Deadline pragma

[sam at gcc dot gnu dot org]

A new "Relative_Deadline" pragma has been introduced in commit 134010 and is
lacking documentation.

Assigning to the committer.


-- 
   Summary: Missing documentation for Relative_Deadline pragma
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: charlet at gcc dot gnu dot org
ReportedBy: sam at gcc dot gnu dot org


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

[Bug ada/36171] Missing documentation for Relative_Deadline pragma

[sam at gcc dot gnu dot org]

--- Comment #2 from sam at gcc dot gnu dot org  2008-05-07 15:10 ---
Oh, right, I've never used it before and missed it in the RM :)


-- 


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

[Bug ada/36171] Missing documentation for Relative_Deadline pragma

[charlet at gcc dot gnu dot org]

--- Comment #1 from charlet at gcc dot gnu dot org  2008-05-07 15:07 ---
Sorry, but this is a standard Ada 2005 pragma, documented in the Ada RM.

Arno


-- 

charlet at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/36170] New: enum variable operation behaviour and -O2

[john dot spelis at 3dlabs dot com]

The following program shows a case where
the 4.3.0 C++ compiler omits a check on an ENUM
variable when compiled with -O2 but keeps it when
-O is used ?

Targets where this occurs; at least x86, arm-*-linux-*


 optEnum = (Options::Id::Type) getopt_long( ... ) ;

 if( optEnum == -1 )/* This test skipped with -O2 but not -O */
  break;

 switch( optEnum ) {
:
 }

 The workaround for this "bug" is explicitly set
 an enum value of -1

  i.e.

  enum Type {
eHelp = 'h',
::
Dummy = -1  /* fixes issue */
}

 Some people say this is an interpretation of the C++ Spec
 but why does the program behaviour change so radically
 with/without the optimiser and without any warnings ?


 This behviour is reproducible with the attached program on
 an x86 build of 4.3.0

 E.g.

./configure --enable-languages=c,c++ --prefix=/tmp/gcc


g++ -O -o m m.cxx
./m   -> program runs and exit's

g++ -O2 -o m m.cxx
./m   -> program prints -1 forever


=
m.cxx
=

#include 
#include 
#include 
#include 

typedef unsigned long uint32_t ;
typedef unsigned char uint8_t ;

#define ANSI_BOLD ""
#define ANSI_RED ""
#define ANSI_RESET ""
#define HAVE_GETOPT 1


class Background {
public:
enum Type {
eMandel = 0,
eGrid,
eFlat,
eGouraud,
};
};

class Options {
public:
Options( void ) {
memset( this, 0x00, sizeof(*this) );

bailOut= 4;
maxIteration   = 240;
size[0]= 64;
size[1]= 32;
surfSize[0]= size[0];
surfSize[1]= size[1];
offset[0]  = 0;
offset[1]  = 0;
coordX[0]  = -2;
coordX[1]  =  2;
coordY[0]  = -2;
coordY[1]  =  2;
bRandomColours = true;

background = Background::eMandel;

#if USE_HARDWARE
bUseTCSET  = true;
#endif
}

boolbAnimate;
boolbUseGUI;
boolbSetMode;
boolbListModes;
boolbDumpImage;
boolbUseTCSET;
boolbWantClears;
boolbRandomColours;
boolbFixedAspect;
boolbFullScreen;
boolbSingleBuffer;
uint32_tmodeX, modeY;
uint32_tvidDevice;
uint32_tvidRotate;
uint32_tbailOut;
uint32_tmaxIteration;
uint32_tloopCount;
uint32_tsize[2];
uint32_tsurfSize[2];
uint32_toffset[2];
float   coordX[2];
float   coordY[2];
Background::Typebackground;
boolbStall;
uint32_tbenchmarkMode;
};

boolgVerbose= false;
boolgVeryVerbose= false;
boolgAbortNow   = false;


bool processArgs( int argc, char *const argv[], Options &opts )
{
#if HAVE_GETOPT
class Options {
public:
class Id {
public:
enum Type {
eHelp = 'h',
eHelpL = 1,
eSize,
eCoords,
eCoordSet,
eClearFirst,
eBail,
eMaxIt,
eColourMap,
eAnimate,
eSetMode,
eLoop,
eFullScreen,
eListModes,
eOffset,
eAspect,
eDemo,
eNoSync,
eVidDevice,
eNoTCSET,
eGUI,
eDumpImage,
eBackground,
eRotate,
eVerbose,
eStall,
eBench,
#if 0   /* set to '1' as workaround */
eDummy = -1
#endif
};
};

class Args {
public:
enum Type {
eNone,
eReq,
eOpt,
};
};

const char  *name;
Options::Args::Type  args;
Id::Typeid;
const char  *help;
};
Options::Id::Type optEnum;
int optIndex;
uint32_ti;
boolbSuccess = true;

static Options options[] = {
{ "help",Options::Args::eNone, Options::Id::eHelp, 
 "Show this help message" },
{ "size",Options::Args::eReq,  Options::Id::eSize, 
 "Size of rendered image" },
{ "coords", 

[Bug bootstrap/36169] [4.4 Regression] gcc/fortran/simplify.c:3956: internal compiler error: in gen_reg_rtx, at emit-rtl.c:868

[ubizjak at gmail dot com]

--- Comment #1 from ubizjak at gmail dot com  2008-05-07 16:39 ---
Hm... strange, because my patch changed x86 target specific MMX and SSE vector
builtins only. I don't see any __builtin_X usage in gfc_simplify_set_exponent
that would trigger codepaths that were changed.

Can you do a backtrace of the failure?


-- 


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

[Bug tree-optimization/36100] [4.4 Regression] always_inline attribute is broken at -O0

[hp at gcc dot gnu dot org]

--- Comment #11 from hp at gcc dot gnu dot org  2008-05-07 16:55 ---
This is not resolved.  I still see
FAIL: g++.dg/tree-ssa/pr19637.C scan-tree-dump-times dom1 "return 1;" 3
for cris-elf and it's been a few days.
I'm reopening this PR to properly track progress.


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug tree-optimization/36100] [4.4 Regression] always_inline attribute is broken at -O0

[hp at gcc dot gnu dot org]

--- Comment #12 from hp at gcc dot gnu dot org  2008-05-07 17:02 ---
(In reply to comment #11)
> This is not resolved.  I still see
> FAIL: g++.dg/tree-ssa/pr19637.C scan-tree-dump-times dom1 "return 1;" 3

Oops, different PR, sorry for the noise.


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/36169] [4.4 Regression] gcc/fortran/simplify.c:3956: internal compiler error: in gen_reg_rtx, at emit-rtl.c:868

[dominiq at lps dot ens dot fr]

--- Comment #2 from dominiq at lps dot ens dot fr  2008-05-07 17:06 ---
> Can you do a backtrace of the failure?

I tried, but my knowledge of gdb is too limited. I get the error, but backtrace
gives "no stack".


-- 


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

[Bug middle-end/36143] [4.4 Regression]: FAIL: g++.dg/tree-ssa/pr19637.C

[hp at gcc dot gnu dot org]

--- Comment #7 from hp at gcc dot gnu dot org  2008-05-07 17:08 ---
Also seen on cris-elf with the revision as mentioned and still there as late as
r135041.  Pinskia, are you going to revert it, fix it or should we xfail the
test?


-- 


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

[Bug c/36172] New: ice for legal code with -O3

[dcb314 at hotmail dot com]

I just tried to compile the Suse Linux package
fontconfig-2.4.2-83 with the GNU C compiler  
version 4.4 snapshot 20080502

The compiler said

fccharset.c:1174: internal compiler error: in compare_values_warnv, at
tree-vrp.c:892
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Preprocessed source code attached. Flag -O3 required.


-- 
   Summary: ice for legal code with -O3
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
  GCC host triplet: x86_64-suse-linux


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

[Bug c/36172] ice for legal code with -O3

[dcb314 at hotmail dot com]

--- Comment #1 from dcb314 at hotmail dot com  2008-05-07 17:10 ---
Created an attachment (id=15591)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15591&action=view)
C source code


-- 


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

[Bug middle-end/36143] [4.4 Regression]: FAIL: g++.dg/tree-ssa/pr19637.C

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2008-05-07 17:21 ---
Fix it:
[andrew-pinskis-computer:local/gcc/gcc] apinski% svn diff
Index: tree-ssa-forwprop.c
===
--- tree-ssa-forwprop.c (revision 135021)
+++ tree-ssa-forwprop.c (working copy)
@@ -132,6 +132,16 @@ along with GCC; see the file COPYING3.  
  res = VIEW_CONVERT_EXPR(type2var)

Or
+ ptr = (type1*)&type2var;
+ *ptr = res
+
+   Will get turned into (if type1 and type2 are the same size
+   and neither have volatile on them and is not a scalar):
+VIEW_CONVERT_EXPR(type2var) = res
+  FIXME: The last constraint is not needed if DECL_GIMPLE_REG_P is expended
+  to all types
+
+   Or

  ptr = &x[0];
  ptr2 = ptr + ;
@@ -573,6 +583,7 @@ forward_propagate_addr_expr_1 (tree name
 {
   tree lhs, rhs, array_ref;
   tree *rhsp, *lhsp;
+  bool in_reference_lhs = false;

   gcc_assert (TREE_CODE (def_rhs) == ADDR_EXPR);

@@ -602,7 +613,10 @@ forward_propagate_addr_expr_1 (tree name
  ADDR_EXPR will not appear on the LHS.  */
   lhsp = &GIMPLE_STMT_OPERAND (use_stmt, 0);
   while (handled_component_p (*lhsp))
-lhsp = &TREE_OPERAND (*lhsp, 0);
+{
+  lhsp = &TREE_OPERAND (*lhsp, 0);
+  in_reference_lhs = true;
+}
   lhs = *lhsp;

   /* Now see if the LHS node is an INDIRECT_REF using NAME.  If so, 
@@ -617,6 +631,43 @@ forward_propagate_addr_expr_1 (tree name
TREE_TYPE (TREE_OPERAND (def_rhs, 0
 {
   *lhsp = unshare_expr (TREE_OPERAND (def_rhs, 0));
+  lhs = *lhsp;
+  fold_stmt_inplace (use_stmt);
+  tidy_after_forward_propagate_addr (use_stmt);
+
+  /* Continue propagating into the RHS if this was not the only use.  */
+  if (single_use_p)
+   return true;
+}
+
+  /* Now see if the LHS node is an INDIRECT_REF using NAME.  If so, 
+ propagate the ADDR_EXPR into the use of NAME and try to
+ create a VCE for the result.  */
+  if (TREE_CODE (lhs) == INDIRECT_REF
+  && TREE_OPERAND (lhs, 0) == name
+  && TYPE_SIZE (TREE_TYPE (lhs))
+  && TYPE_SIZE (TREE_TYPE (TREE_OPERAND (def_rhs, 0)))
+  /* Function decls should not be used for VCE either as it could be
+ a function descriptor that we want and not the actual function code. 
*/
+  && TREE_CODE (TREE_OPERAND (def_rhs, 0)) != FUNCTION_DECL
+  /* We should not convert volatile loads to non volatile loads. */
+  && !TYPE_VOLATILE (TREE_TYPE (lhs))
+  && !TYPE_VOLATILE (TREE_TYPE (TREE_OPERAND (def_rhs, 0))) 
+  && operand_equal_p (TYPE_SIZE (TREE_TYPE (lhs)),
+ TYPE_SIZE (TREE_TYPE (TREE_OPERAND (def_rhs, 0))), 0)
+  /* Check for aggregate types so we don't end up with a SSA_NAME inside
+ a VIEW_CONVERT_EXPR on the lhs. 
+FIXME: this can go away when DECL_GIMPLE_REG_P is extended for all
+scalar types.  */
+  && (AGGREGATE_TYPE_P (TREE_TYPE (TREE_OPERAND (def_rhs, 0)))
+ || TREE_CODE (TREE_TYPE (TREE_OPERAND (def_rhs, 0))) == VECTOR_TYPE
+ || TREE_CODE (TREE_TYPE (TREE_OPERAND (def_rhs, 0))) ==
COMPLEX_TYPE))
+{
+  tree new_lhs = unshare_expr (TREE_OPERAND (def_rhs, 0));
+  /* Use build1 here as we not produce a right hand side so we need to
keep
+ around the VCE.  */
+  new_lhs = build1 (VIEW_CONVERT_EXPR, TREE_TYPE (lhs), new_lhs);
+  *lhsp = new_lhs;
   fold_stmt_inplace (use_stmt);
   tidy_after_forward_propagate_addr (use_stmt);

@@ -673,9 +724,10 @@ forward_propagate_addr_expr_1 (tree name
   if (TREE_CODE (new_rhs) != VIEW_CONVERT_EXPR)
{
  block_stmt_iterator bsi = bsi_for_stmt (use_stmt);
- new_rhs = force_gimple_operand_bsi (&bsi, new_rhs, true, NULL, true,
BSI_SAME_STMT);
- /* As we change the deference to a SSA_NAME, we need to return false
to make sure that
-the statement does not get removed.  */
+ new_rhs = force_gimple_operand_bsi (&bsi, new_rhs, true, NULL, true,
+ BSI_SAME_STMT);
+ /* As we change the deference to a SSA_NAME, we need to return false
+to make sure that the statement does not get removed.  */
  res = false;
}
   *rhsp = new_rhs;


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c++/36170] enum variable operation behaviour and -O2

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-05-07 17:23 ---
And C++ standard says if the value is out of range of the enum, the behavior is
undefined so this is not a bug.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug tree-optimization/36127] bad choice of loop IVs above -Os on x86

[astrange at ithinksw dot com]

--- Comment #4 from astrange at ithinksw dot com  2008-05-07 17:36 ---
Created an attachment (id=15592)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15592&action=view)
minimal source


-- 


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[gnu_andrew at member dot fsf dot org]

--- Comment #20 from gnu_andrew at member dot fsf dot org  2008-05-07 17:54 
---
Created an attachment (id=15593)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15593&action=view)
Move towards a CPStringBuilder-using code base


-- 


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[gnu_andrew at member dot fsf dot org]

--- Comment #21 from gnu_andrew at member dot fsf dot org  2008-05-07 17:55 
---
Created an attachment (id=15594)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15594&action=view)
Move towards a CPStringBuilder-using code base


-- 


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[gnu_andrew at member dot fsf dot org]

--- Comment #22 from gnu_andrew at member dot fsf dot org  2008-05-07 17:56 
---
Created an attachment (id=15595)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15595&action=view)
Move towards a CPStringBuilder-using code base


-- 


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[gnu_andrew at member dot fsf dot org]

--- Comment #23 from gnu_andrew at member dot fsf dot org  2008-05-07 17:56 
---
Created an attachment (id=15596)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15596&action=view)
Move towards a CPStringBuilder-using code base


-- 


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[gnu_andrew at member dot fsf dot org]

--- Comment #24 from gnu_andrew at member dot fsf dot org  2008-05-07 17:57 
---
Created an attachment (id=15597)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15597&action=view)
Move towards a CPStringBuilder-using code base


-- 


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[gnu_andrew at member dot fsf dot org]

--- Comment #25 from gnu_andrew at member dot fsf dot org  2008-05-07 17:57 
---
Created an attachment (id=15598)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15598&action=view)
Move towards a CPStringBuilder-using code base


-- 


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[gnu_andrew at member dot fsf dot org]

--- Comment #26 from gnu_andrew at member dot fsf dot org  2008-05-07 17:58 
---
Created an attachment (id=15599)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15599&action=view)
Move towards a CPStringBuilder-using code base


-- 


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[gnu_andrew at member dot fsf dot org]

--- Comment #27 from gnu_andrew at member dot fsf dot org  2008-05-07 17:58 
---
Created an attachment (id=15600)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15600&action=view)
Move towards a CPStringBuilder-using code base


-- 


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[ddaney at avtrex dot com]

--- Comment #28 from ddaney at avtrex dot com  2008-05-07 17:59 ---
Subject: Re:  We should to use StringBuilder instead
 of StringBuffer where appropriate.

gnu_andrew at member dot fsf dot org wrote:
> --- Comment #25 from gnu_andrew at member dot fsf dot org  2008-05-07 
> 17:57 ---
> Created an attachment (id=15598)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15598&action=view)
>  --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15598&action=view)
> Move towards a CPStringBuilder-using code base
> 
> 
I don't think it is strictly speaking necessary to attach all of these 
patches.

David Daney


-- 


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[gnu_andrew at member dot fsf dot org]

--- Comment #29 from gnu_andrew at member dot fsf dot org  2008-05-07 18:01 
---
Created an attachment (id=15601)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15601&action=view)
Move towards a CPStringBuilder-using code base


-- 


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[gnu_andrew at member dot fsf dot org]

--- Comment #30 from gnu_andrew at member dot fsf dot org  2008-05-07 18:02 
---
Created an attachment (id=15602)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15602&action=view)
Move towards a CPStringBuilder-using code base


-- 


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[gnu_andrew at member dot fsf dot org]

--- Comment #31 from gnu_andrew at member dot fsf dot org  2008-05-07 18:02 
---
Created an attachment (id=15603)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15603&action=view)
Move towards a CPStringBuilder-using code base


-- 


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[gnu_andrew at member dot fsf dot org]

--- Comment #32 from gnu_andrew at member dot fsf dot org  2008-05-07 18:03 
---
Created an attachment (id=15604)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15604&action=view)
Move towards a CPStringBuilder-using code base


-- 


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

[Bug ada/35576] Ada HW Interrupt Task Enhancement

[joel at gcc dot gnu dot org]

--- Comment #6 from joel at gcc dot gnu dot org  2008-05-07 18:03 ---
Tested against this GCC using gcc-ada-hwint-20080421.diff and patch in 
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01581.html 

sparc-rtems4.9-gcc (GCC) 4.4.0 20080502 (experimental) [trunk revision 134885]


-- 


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[gnu_andrew at member dot fsf dot org]

--- Comment #33 from gnu_andrew at member dot fsf dot org  2008-05-07 18:04 
---
Created an attachment (id=15605)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15605&action=view)
Move towards a CPStringBuilder-using code base


-- 


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[gnu_andrew at member dot fsf dot org]

--- Comment #34 from gnu_andrew at member dot fsf dot org  2008-05-07 18:04 
---
Created an attachment (id=15606)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15606&action=view)
Move towards a CPStringBuilder-using code base


-- 


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[gnu_andrew at member dot fsf dot org]

--- Comment #35 from gnu_andrew at member dot fsf dot org  2008-05-07 18:07 
---
Created an attachment (id=15607)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15607&action=view)
Move towards a CPStringBuilder-using code base


-- 


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[gnu_andrew at member dot fsf dot org]

--- Comment #36 from gnu_andrew at member dot fsf dot org  2008-05-07 18:07 
---
Created an attachment (id=15608)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15608&action=view)
Move towards a CPStringBuilder-using code base


-- 


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[gnu_andrew at member dot fsf dot org]

--- Comment #37 from gnu_andrew at member dot fsf dot org  2008-05-07 18:08 
---
Created an attachment (id=15609)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15609&action=view)
Move towards a CPStringBuilder-using code base


-- 


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

[Bug bootstrap/36169] [4.4 Regression] gcc/fortran/simplify.c:3956: internal compiler error: in gen_reg_rtx, at emit-rtl.c:868

[ubizjak at gmail dot com]

--- Comment #3 from ubizjak at gmail dot com  2008-05-07 18:08 ---
Created an attachment (id=15610)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15610&action=view)
P

Can you try attached patch that fixes some patterns only at expand time? 


-- 


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[gnu_andrew at member dot fsf dot org]

--- Comment #38 from gnu_andrew at member dot fsf dot org  2008-05-07 18:08 
---
Created an attachment (id=15611)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15611&action=view)
Change tools to use StringBuilder


-- 


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

[Bug ada/35576] Ada HW Interrupt Task Enhancement

[joel at gcc dot gnu dot org]

--- Comment #7 from joel at gcc dot gnu dot org  2008-05-07 18:08 ---
Created an attachment (id=15612)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15612&action=view)
hwint patch for gcc 4.3 branch

This has been tested against sparc-rtems4.9 for interrupt functionality.  ACATS
results reported for mips, i386, powerpc, and sparc.


-- 


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[gnu_andrew at member dot fsf dot org]

--- Comment #39 from gnu_andrew at member dot fsf dot org  2008-05-07 18:10 
---
All appropriate changes made.  Closing this bug.


-- 

gnu_andrew at member dot fsf dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/36173] New: abi breakage, stdio_filebuf routines missing

[mrs at apple dot com]

A few routines seem to have disappeared from 4.0.0 to 4.2.1:

_ZN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEE2fdEv;
_ZN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEE4fileEv;
   
_ZN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEEC1EP7__sFILESt13_Ios_Openmodem;
_ZN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEEC1EiSt13_Ios_Openmodem;
_ZN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEEC1Ev;
   
_ZN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEEC2EP7__sFILESt13_Ios_Openmodem;
_ZN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEEC2EiSt13_Ios_Openmodem;
_ZN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEEC2Ev;
_ZN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEED0Ev;
_ZN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEED1Ev;
_ZN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEED2Ev;
_ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEE2fdEv;
_ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEE4fileEv;
   
_ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEEC1EP7__sFILESt13_Ios_Openmodem;
_ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEEC1EiSt13_Ios_Openmodem;
_ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEEC1Ev;
   
_ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEEC2EP7__sFILESt13_Ios_Openmodem;
_ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEEC2EiSt13_Ios_Openmodem;
_ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEEC2Ev;
_ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEED0Ev;
_ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEED1Ev;
_ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEED2Ev;
_ZTVN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEEE;
_ZTVN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEEE;

Adding these back to libstdc++-v3/config/abi/pre/gnu.ver seems to make it
better.


-- 
   Summary: abi breakage, stdio_filebuf routines missing
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com
GCC target triplet: powerpc-apple-darwin9


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

[Bug bootstrap/36169] [4.4 Regression] gcc/fortran/simplify.c:3956: internal compiler error: in gen_reg_rtx, at emit-rtl.c:868

[ubizjak at gmail dot com]

--- Comment #4 from ubizjak at gmail dot com  2008-05-07 18:32 ---
I see the problem:

define_insn_and_split "*fixuns_trunc_1" is a post-reload splitter that
calls  ix86_split_convert_uns_si_sse after reload. There we have:

 gen_sse2_loadlpd (value, CONST0_RTX (V2DFmode), input)

and this calls sse2_loadlpd expander that wants to fixup its operands by
forcing something in a register.

Posted patch will fix the failure.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ubizjak at gmail dot com
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-05-07 18:32:07
   date||


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

[Bug c++/36170] enum variable operation behaviour and -O2

[john dot spelis at 3dlabs dot com]

--- Comment #2 from john dot spelis at 3dlabs dot com  2008-05-07 18:38 
---
Subject: Re:  enum variable operation behaviour and -O2


Thanks for ending that issue.
Best Regards


On 7 May 2008, pinskia at gcc dot gnu dot org wrote:

> 
> 
> --- Comment #1 from pinskia at gcc dot gnu dot org  2008-05-07 17:23 
> ---
> And C++ standard says if the value is out of range of the enum, the behavior 
> is
> undefined so this is not a bug.
> 
> 
> -- 
> 
> pinskia at gcc dot gnu dot org changed:
> 
>What|Removed |Added
> 
>  Status|UNCONFIRMED |RESOLVED
>  Resolution||INVALID
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36170
> 
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
> 


-- 


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

[Bug target/36174] New: [4.4 Regression]: Failed to boostrap

[hjl dot tools at gmail dot com]

Gcc 4.4 revision 135043 failed to bootstrap on Linux/ia32 when
configured with

-enable-clocale=gnu --with-system-zlib --enable-checking=assert
--with-demangler-in-ld --enable-shared --enable-threads=posix --enable-haifa
--prefix=/usr/gcc-4.4 --with-local-prefix=/usr/local

I got
libtool: compile:  /export/build/gnu/gcc/build-x86_64-linux/gcc/gcj
-B/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/libjava/
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -fomit-frame-pointer
-fclasspath=
-fbootclasspath=/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath/lib
--encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2
-fsource-filename=/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/libjava/classpath/lib/classes
-fjni -findirect-dispatch -fno-indirect-classes -c
@gnu-java-awt-peer-swing.list  -fPIC -o .libs/gnu-java-awt-peer-swing.o
gnu/java/awt/peer/gtk/FreetypeGlyphVector.java: In class
'gnu.java.awt.peer.gtk.FreetypeGlyphVector':
gnu/java/awt/peer/gtk/FreetypeGlyphVector.java: In method
'gnu.java.awt.peer.gtk.FreetypeGlyphVector.setupGlyphMetrics()':
In file included from gnu/java/awt/peer/gtk/GtkClipboardNotifier.java:88,
 from gnu/java/awt/peer/gtk/GtkTextAreaPeer.java:221,
 from gnu/java/awt/peer/gtk/GtkChoicePeer.java:141,
 from gnu/java/awt/peer/gtk/GtkVolatileImage.java:203,
 from
/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath/gnu/java/awt/peer/gtk/GdkPixbufDecoder.java:429,
 from :63:
gnu/java/awt/peer/gtk/FreetypeGlyphVector.java:440: internal compiler error: in
gen_reg_rtx, at emit-rtl.c:868
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[5]: *** [gnu-java-awt-peer-gtk.lo] Error 1
make[5]: *** Waiting for unfinished jobs

Revision 135037 is OK. Linux/ia32 and Linux/ia64 are fine. I think revision
135041

http://gcc.gnu.org/ml/gcc-patches/2008-05/msg00410.html

may be the cause.


-- 
   Summary: [4.4 Regression]: Failed to boostrap
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug target/36174] [4.4 Regression]: Failed to boostrap

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2008-05-07 19:01 ---
I have verified that revision 135041 is the cause. x86 backend
calls gen_reg_rtx to generate pseudo register after reload is
completed.


-- 


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

[Bug bootstrap/36169] [4.4 Regression] gcc/fortran/simplify.c:3956: internal compiler error: in gen_reg_rtx, at emit-rtl.c:868

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2008-05-07 19:04 ---
This may be related to PR 36174.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

OtherBugsDependingO||36174
  nThis||


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

[Bug target/36174] [4.4 Regression]: Failed to boostrap

[andreast at gcc dot gnu dot org]

--- Comment #2 from andreast at gcc dot gnu dot org  2008-05-07 19:09 
---
I see a similar ICE on x86_64-darwin: jni.cc:812 ICE in gen_reg_rtx, at
emit-rtl.c:868


-- 

andreast at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||andreast at gcc dot gnu dot
   ||org


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

[Bug target/36174] [4.4 Regression]: Failed to boostrap

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2008-05-07 19:11 ---
I am testing the patch on PR 36169 now.


-- 


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

[Bug bootstrap/36169] [4.4 Regression] gcc/fortran/simplify.c:3956: internal compiler error: in gen_reg_rtx, at emit-rtl.c:868

[ubizjak at gmail dot com]

--- Comment #6 from ubizjak at gmail dot com  2008-05-07 19:11 ---
Should be fixed now.

Sorry for the breakage, I didn't notice one postreload usage of loadlpd.


-- 


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

[Bug libstdc++/36173] abi breakage, stdio_filebuf routines missing

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-05-07 19:24 ---
Please confirm this on the top of the 4.2 branch.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||ABI


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

[Bug libstdc++/36164] abi breakage, stdio_sync_filebuf routines missing

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-05-07 19:27 ---
Please confirm with current 4.2 branch head.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||ABI


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

[Bug c++/36149] -O2 optimization generates wrong code

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2008-05-07 19:29 
---
Note that gcc 4.1 is known to have some wrong-code bugs regarding aliasing.


-- 


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

[Bug middle-end/36137] gcc can't do math

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.2.3
  Known to work||4.3.1
   Target Milestone|--- |4.3.1


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

[Bug target/36136] GCC creates suboptimal ASM : constant work registers are set up inside work loops and not outside of the loop

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-05-07 19:32 ---
It would have been nice to check at least gcc 4.3 (or better current trunk).


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement


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

[Bug target/36135] GCC creates suboptimal ASM : suboptimal Adressing-Modes used

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-05-07 19:33 ---
It would have been nice to check at least gcc 4.3 (or better current trunk).


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||missed-optimization


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

[Bug target/36134] GCC creates suboptimal ASM : usage of ADDA.L where LEA could be used

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-05-07 19:33 ---
It would have been nice to check at least gcc 4.3 (or better current trunk).


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement


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

[Bug target/36133] GCC creates suboptimal ASM : Code includes unneeded TST instructions

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-05-07 19:33 ---
It would have been nice to check at least gcc 4.3 (or better current trunk).


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement


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

[Bug c++/36128] [4.4 regression] ICE with invalid argument for builtin

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-05-07 19:35 ---
Mine.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-05-05 06:39:48 |2008-05-07 19:35:40
   date||


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

[Bug middle-end/36124] conditional loop becomes infinite loop in -O2 (gcc 4.2 -> 4.3 regression)

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2008-05-07 19:42 ---
decrementing a NULL pointer invokes undefined behavior, incrementing not.


-- 

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

[Bug c++/36122] Arm EABI C++ optimiser handles bit fields incorrectly

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-05-07 19:43 ---


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


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/33887] [4.1/4.2 Regression] Reference to bitfield gets wrong value when optimizing

[rguenth at gcc dot gnu dot org]

--- Comment #44 from rguenth at gcc dot gnu dot org  2008-05-07 19:43 
---
*** Bug 36122 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||john dot spelis at 3dlabs
   ||dot com


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

[Bug tree-optimization/35501] Wrong value returned from const int

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-05-07 19:45 ---
Right.  I believe there was even some ELF reasoning here... Micha?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org, matz at gcc dot gnu dot
   ||org


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

[Bug bootstrap/36169] [4.4 Regression] gcc/fortran/simplify.c:3956: internal compiler error: in gen_reg_rtx, at emit-rtl.c:868

[dominiq at lps dot ens dot fr]

--- Comment #7 from dominiq at lps dot ens dot fr  2008-05-07 19:54 ---
> Should be fixed now.

I am now at stage 3, so it seems fixed.


-- 


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

[Bug middle-end/36154] internal compiler error: in get_constraint_for_component_ref, at tree-ssa-structalias.c:2727

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-05-07 19:56 ---
Reducing.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org


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

[Bug middle-end/36172] ice for legal code with -O3

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-05-07 19:58 ---
This worked with 20080325.


-- 


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

[Bug middle-end/36172] [4.4 Regression] ice for legal code with -O3

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|ice for legal code with -O3 |[4.4 Regression] ice for
   ||legal code with -O3
   Target Milestone|--- |4.4.0


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

[Bug middle-end/36172] [4.4 Regression] ice for legal code with -O3

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2008-05-07 20:00 ---
  gcc_assert (POINTER_TYPE_P (TREE_TYPE (val1))
  == POINTER_TYPE_P (TREE_TYPE (val2)));

:)


-- 


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

[Bug middle-end/36154] [4.3 Regression] internal compiler error: in get_constraint_for_component_ref, at tree-ssa-structalias.c:2727

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-05-07 20:04 ---
Reduced testcase, fails at -O:

struct eth_test_pkt {
  unsigned short len;
  unsigned short ctr;
  unsigned char packet[];
} __attribute__ ((packed));
struct eth_test_pkt pkt_unaligned = { .packet = { 0xFC } };
int cmd_unaligned(const void *p)
{
  return memcmp(p, pkt_unaligned.packet, 1);
}


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|x86_64-unknown-linux-gnu|
   GCC host triplet|x86_64-unknown-linux-gnu|
 GCC target triplet|powerpc-eabispe |
   Keywords||ice-on-valid-code
  Known to fail||4.3.0
  Known to work||4.2.3 4.4.0
   Last reconfirmed|-00-00 00:00:00 |2008-05-07 20:04:30
   date||
Summary|internal compiler error: in |[4.3 Regression] internal
   |get_constraint_for_component|compiler error: in
   |_ref, at tree-ssa-  |get_constraint_for_component
   |structalias.c:2727  |_ref, at tree-ssa-
   ||structalias.c:2727
   Target Milestone|--- |4.3.1


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

[Bug middle-end/36154] [4.3 Regression] internal compiler error: in get_constraint_for_component_ref, at tree-ssa-structalias.c:2727

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-05-07 20:07 ---
We don't generate _any_ fields for packet, but the memcmp is folded to

:
  p.0_2 = (const unsigned char * {ref-all}) p_1(D);
  D.1186_3 = *p.0_2;
  D.1187_4 = (int) D.1186_3;
  D.1188_5 = (const unsigned char * {ref-all}) &pkt_unaligned.packet;
  D.1189_6 = *D.1188_5;
  D.1190_7 = (int) D.1189_6;
  D.1184_8 = D.1187_4 - D.1190_7;
  return D.1184_8;

taking the address of the missing field.  This has gone "latent" on the
trunk by not generating subvariables for PTA anymore.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-05-07 20:04:30 |2008-05-07 20:07:19
   date||


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

[Bug middle-end/36172] [4.4 Regression] ice for legal code with -O3

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-05-07 20:08 ---
Reducing.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org


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