[Bug c++/34238] [4.3 regression] static data member used, but not defined error on member definition
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34238
[Bug tree-optimization/34247] [4.3 Regression] ICE in omp_add_variable, at gimplify.c:4677
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34247
[Bug testsuite/34253] Lots of failures in gcc.dg/vect
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2007-11-28 08:31 --- I see on my computer a lot of failures in the testsuite gcc.dg/vect. See http://gcc.gnu.org/ml/gcc-testresults/2007-11/msg01474.html The failures are there since Sepember 2007. But the other testresults don't show these failures. Right, that's why I'd suggest to investigate on your side first. Is your tree correctly synchronized? Do you use a recent DejaGNU version? Etc. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34253
[Bug c++/34258] New: g++ inlined destructors incorrectly throw exception out of clean-up handler
without g++ FE inlining, ct.C (attached in the following)correctly called
my_terminate when an exception was thrown in a destructor called in a clean-up
exception handler. However, after FE inlining, this exception was propagate out
of the clean-up exception handler and reached the catch(...) block in the outer
caller function.
This bug seems to exist in g++ versions 3.4.3 up to 4.2.
-bash-3.00$ /import/dr3/s10/gcc-4.2/bin/g++ ct.C
-bash-3.00$ ./a.out
throw 1
throw 2
ABC::~ABC()
PASS: my_terminate
-bash-3.00$ /import/dr3/s10/gcc-4.2/bin/g++ ct.C -O
-bash-3.00$ ./a.out
throw 1
throw 2
ABC::~ABC()
ERROR: should not catch ...
-bash-3.00$ /import/dr3/s10/gcc-4.2/bin/g++ ct.C -O -DNO_FE_INLINE
-bash-3.00$ ./a.out
throw 1
throw 2
ABC::~ABC()
PASS: my_terminate
-bash-3.00$ /import/dr3/s10/gcc-4.2/bin/g++ -v
Using built-in specs.
Target: sparc-sun-solaris2.10
Configured with: /import/dr2/starlex/1/gcc-4.2-20070228/configure
--prefix=/import/dr3/s10/gcc-4.2 --enable-languages=c,c++,fortran
--enable-rpath --with-mpfr=/import/dr3/s10/gcc-4.2
--with-gmp=/import/dr3/s10/gcc-4.2
Thread model: posix
gcc version 4.2.0 20070228 (prerelease)
-bash-3.00$ cat ct.C
// mimic ctype.C
// a constructor calls other functions
// its base class constructor can throw exception
// handler of that case should be allowed to unwind_resume?
#include stdlib.h
#include stdio.h
#include exception
struct ABC
{
// ABC();
~ABC();
};
extern C void f2();
struct BASE
{
ABC tmp;
// BASE();
#if !defined(NO_FE_INLINE)
inline ~BASE() { f2(); }
#else
~BASE();
#endif
};
#if defined(NO_FE_INLINE)
BASE::~BASE() { f2(); }
#endif
struct CHILD: public BASE
{
#if defined(__GNUC__) !defined(NO_FE_INLINE)
CHILD() __attribute__((noinline));
#else
CHILD();
#endif
// ~CHILD();
};
extern C void f1();
CHILD::CHILD()
{
f1();
}
extern C void f1()
{
printf(throw 1\n); fflush(stdout);
throw 1;
}
extern C void f2()
{
printf(throw 2\n); fflush(stdout);
throw 2;
}
void my_terminate()
{
printf(PASS: my_terminate\n);
exit(0);
}
int main()
{
std::set_terminate(my_terminate);
try {
CHILD tmp;
printf(ERROR: should not be here ...\n);
fflush(stdout);
} catch (...) {
printf(ERROR: should not catch ...\n);
fflush(stdout);
}
return 0;
}
ABC::~ABC()
{
printf(ABC::~ABC()\n);
fflush(stdout);
}
--
Summary: g++ inlined destructors incorrectly throw exception out
of clean-up handler
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hailijuan at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34258
[Bug target/30572] [4.3 Regression] target libraries links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib
--- Comment #12 from ek dot kato at gmail dot com 2007-11-28 09:19 --- Hi, I encountered this problem today, as I would like to use latest gfortran on Mac OS X 10.4.11. Anyway here is the crude workaround to avoid the install name problem. It just install libgcc_s.*.dylib with slibdir defiend, and then move them to the $(gcc_objdir) later. Index: libgcc/Makefile.in === --- libgcc/Makefile.in (revision 130489) +++ libgcc/Makefile.in (working copy) @@ -100,8 +100,13 @@ # in-tree libraries, and DejaGNU) know about the layout # of the build tree, for now. $(MAKE) install DESTDIR=$(gcc_objdir) \ - slibdir= libsubdir= MULTIOSDIR=$(MULTIDIR) + slibdir=$(slibdir) libsubdir= MULTIOSDIR=$(MULTIDIR) + objdir=$(gcc_objdir)/$(slibdir); \ + if test -d $$objdir; then \ + mv -f $$objdir/libgcc_s.* $(gcc_objdir)/; \ + fi; \ + .PHONY: all-multi all-multi: # If this is the top-level multilib, build all the other -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30572
[Bug bootstrap/34259] New: Compile gcc 3.4.6 on tru64 unix v5.1b problem with yacc syntax
Hello, I try to compile gcc on a tru64 unix v5.1b. I have this message : yacc --name-prefix=__gettext --output plural.c /usr/local/gcc/src/gcc-3.4.6/intl /plural.y usage: yacc -svdlt [-b prefix] [-p sym_prefix] [-P path] [-N num] file *** Exit 1 Stop. *** Exit 1 Stop. What is the procedure to solve this problem ? Thanks, Philippe Vereecke -- Summary: Compile gcc 3.4.6 on tru64 unix v5.1b problem with yacc syntax Product: gcc Version: 3.4.6 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: philippe dot vereecke at siih5962 dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34259
[Bug bootstrap/34259] Compile gcc 3.4.6 on tru64 unix v5.1b problem with yacc syntax
--- Comment #1 from philippe dot vereecke at siih5962 dot fr 2007-11-28 09:32 --- yacc --name-prefix=__gettext --output plural.c /usr/local/gcc/src/gcc-3.4.6/intl /plural.y usage: yacc -svdlt [-b prefix] [-p sym_prefix] [-P path] [-N num] file *** Exit 1 Stop. *** Exit 1 Stop. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34259
[Bug c++/34258] g++ inlined destructors incorrectly throw exception out of clean-up handler
--- Comment #1 from hailijuan at gmail dot com 2007-11-28 09:17 --- Created an attachment (id=14652) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14652action=view) to address the bug in g++ exception handler -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34258
Errors issued while building GCC
Hello, I am newly assigned to GNU CC work. I am using Win-xp-sp2 and Cygwin to build GCC. I have successfully installed the 'binutils', but while building GCC below errors are being issued: --cut-- ../.././gcc/config/mips/mips.md:3318:5: missing terminating character ../.././gcc/config/mips/mips.md:3319: error: stray '\' in program ../.././gcc/config/mips/mips.md:3319: error: syntax error before n ../.././gcc/config/mips/mips.md:3321: error: stray '\' in program ../.././gcc/config/mips/mips.md:407: error: initializer element is not constant ../.././gcc/config/mips/mips.md:407: error: (near initialization for `insn_conditions[205]') make[1]: *** [build/insn-conditions.o] Error 1 make[1]: Leaving directory `/home/gcc/host-i686-pc-cygwin/gcc' make: *** [all-gcc] Error 2 --cut-- I am using below procedure to build GCC: 1. Configure the GCC by giving the following command in the directory where GCC package is placed. $ ./configure --target='mipsisa32-elf' --enable-languages=c,c++ -- prefix=GCC-installation-location GCC-installation-location is the path where GCC package is to be installed. I am using /usr/local/bin for this. 2. Build the GCC package by $ make all-gcc 3. Install the GCC package by: $ make install-gcc Please help me in rectifying these issues. Thanks and Regards Ankur Gupta Software Engineer ACME Technologies Pvt. Ltd... Noida, India
[Bug bootstrap/34255] scope-blocks-on-a-diet patch diverges -g from non-g output code
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-11-28 10:14 --- Confirmed. The mentioned patch has been applied to the trunk already. The patch not only causes -g divergence, it also accidentally drops subblocks that need to be kept around for the sake of generating debug information for them. This is certainly bad and needs to be (is already) fixed. http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01745.html regresses the property that code output with -g must be the same as that without -g. make bootstrap-debug demonstrates that several files miscompare after this patch, and don't if the patch is reversed. This causes memory-usage regressions for non-debug builds, for example for tramp3d-v4 at -O2 -Dleafify=flatten which (peak) memory-usage grows from 807MB to 1248MB. (Worse if you also add -fopenmp, less worse if you drop -Dleafify=flatten) The following two patches http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00523.html http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00524.html probably address the latter problem in a more efficient way. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-28 10:14:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34255
[Bug fortran/34247] [4.3 Regression] ICE in omp_add_variable, at gimplify.c:4677
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-28 10:17:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34247
[Bug fortran/34260] present returns wrong value of optional variables
--- Comment #1 from terry at chem dot gu dot se 2007-11-28 10:33 --- gfortran behaves correctly with an explicit INTERFACE, but that should not be required (as far as I know) Explicit interfaces are required for procedures with optional arguments. SUB is still external to MAIN, so is defined implicitly in MAIN. As far as I can see it's not legal. I don't know what ifort's doing. Shouldn't this error be detected by the compiler at some stage of the compilation? Or rather: Having the compiler detect this and raise an error would be a nice feature. -- terry at chem dot gu dot se changed: What|Removed |Added CC||terry at chem dot gu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34260
[Bug c/34261] New: Directed rounding doesn't work on MacOS X
I research in interval arithmetic. I bought a MacBook Pro in Spring 07 (
MacBookPro2,2; Intel Core 2 Duo 2.33 GHz; Mac OS X 10.4.11 (8S2167), Darwin
8.11.1).
Within MATLAB (Version 7.4.0.287 (R2007a) Jan 2007) I wanted to use Rump's
interval library INTLAB. On startup, INTLAB detected the needed changing of
rounding-mode wasn't working, and I couldn't fix it.
So I tried a simple C program to check this with gcc as follows
/*roundtest.cpp*/
#include iostream
#include fenv.h
using namespace std;
int main(int argc, char* argv[]) {
int flag;
double x, y;
double z0, z1, z2, z3;
x = atof(argv[1]);
y = atof(argv[2]);
flag = fesetround(0); // round toward 0
fprintf(stdout, fesetround(0) returned %i\n, flag);
fprintf(stdout, Then fegetround() returned %i\n, fegetround());
z0 = x/y;
flag = fesetround(1); // round to nearest
fprintf(stdout, fesetround(1) returned %i\n, flag);
fprintf(stdout, Then fegetround() returned %i\n, fegetround());
z1 = x/y;
flag = fesetround(2); // round toward +oo
fprintf(stdout, fesetround(2) returned %i\n, flag);
fprintf(stdout, Then fegetround() returned %i\n, fegetround());
z2 = x/y;
flag = fesetround(3); // round toward -oo
fprintf(stdout, fesetround(3) returned %i\n, flag);
fprintf(stdout, Then fegetround() returned %i\n, fegetround());
z3 = x/y;
fesetround(1); // round to nearest
fprintf(stdout, z0=%20.18f, z1=%20.18f, z2-z1=%g, z1-z3=%g\n,
z0, z1, z2-z1, z1-z3);
return 0;
}
/*--*/
I compiled with this (I am a C++ beginner, for some reason gcc compiles but
can't link):
johnpryce 49$ g++ -frounding-math -Wall roundtest.cpp -o roundtest
Then I ran with this, for instance
johnpryce 54$roundtest 1 3
fesetround(0) returned 0
Then fegetround() returned 0
fesetround(1) returned 1
Then fegetround() returned 0
fesetround(2) returned 1
Then fegetround() returned 0
fesetround(3) returned 1
Then fegetround() returned 0
z0=0.15, z1=0.15, z2-z1=0, z1-z3=0
With correct rounding, z2 and z3 MUST be different, and z1 equals one of them.
But the fesetround/fegetround output seems to show
(a) Rounding mode can't be changed
(b) It is always toward zero (i.e. oldfashioned IBM360 style chopping) if this
output is to be believed. This violates the IEEE754 standard, which of course
mandates rounding to nearest as the default.
Actually I think rounding to nearest is what DOES happen - big number-crunching
calculations seem too accurate to be consistent with chopping - so the
fesetround/fegetround functions must be wrong.
--
Summary: Directed rounding doesn't work on MacOS X
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: j dot d dot pryce at ntlworld dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34261
[Bug bootstrap/34255] scope-blocks-on-a-diet patch diverges -g from non-g output code
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-11-28 12:15 --- The two patches reduce the boostrap-debug failures that re-appear with reverting the part that fixes http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01745.html regresses the property that code output with -g must be the same as that without -g. make bootstrap-debug demonstrates that several files miscompare after this patch, and don't if the patch is reversed. to ./lcm.o differs ./cfghooks.o differs ./postreload.o differs ./cfgloopmanip.o differs from several dozen miscompares. My bet is that this is because we process the unexpanded_vars list in non-UID order at expansion time. I'm testing a patch that sorts them after UID before expanding (we could also keep a bitmap now with the first patch, but that would be more work now). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34255
[Bug fortran/34262] New: MVBITS does not work for arrays
hades [TEST] cat bug-mvbits.f90 program main implicit none integer :: a( 1 ), b( 1 ) integer :: x, y a = 1 b = 0 x = 1 y = 0 call mvbits (a, 0, 1, b, 1) call mvbits (x, 0, 1, y, 1) write (*, *) 'a: ', a write (*, *) 'x: ', x write (*, *) write (*, *) 'b: ', b write (*, *) 'y: ', y write (*, *) if ( all (b == y) ) then write (*, *) 'GOOD: b == y' else write (*, *) 'BAD: b /= y' end if end program main hades [TEST] ./a.out a:1 x:1 b:0 y:2 BAD: b /= y hades [TEST] gfortran --version GNU Fortran (GCC) 4.2.1 (Ubuntu 4.2.1-5ubuntu4) Copyright (C) 2007 Free Software Foundation, Inc. It does not work for MacOS PowerPC either, same output. The version I used ton my Mac was: epsilon [TEST] gfortran --version GNU Fortran (GCC) 4.3.0 20071017 (experimental) [trunk revision 129405] Copyright (C) 2007 Free Software Foundation, Inc. -- Summary: MVBITS does not work for arrays Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: phl at kth dot se GCC build triplet: ? GCC host triplet: ? GCC target triplet: ? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34262
[Bug rtl-optimization/34263] New: missed optimization: cleanup loop latch (SMS)
Consider the following testcase compiled on SPU, r130287:
#define M 1000
void
foo (int *X, int *Y, int size, int n)
{
int i, j;
int acum;
for (i = 0; i M; i++)
{
acum = 0;
for (j = 0; j n; j++)
{
acum += (X[j] * X[j + i]);
}
Y[i] = acum;
}
}
The following is the description of the problem, taken from SMS wiki page
http://gcc.gnu.org/wiki/SwingModuloScheduling:
SMS currently works only on single-basic-block loops. There are cases in which
out-of-SSA inserts a copy stmt on the back-edge, resulting in a non-empty latch
block. This usually happens to vectorized loops that have misaligned accesses
(in which we use the value loaded in the previous iteration, combined with the
value loaded in the current iteration, and extract the desired elements from
these two vectors).
So, the vectorized loop in this example is not SMSed because of the non-empty
latch while the scalar version of the loop is SMSed.
[taken from the sms dump file, here is the details of the vectorized loop:]
;; Loop 2
;; header 4, latch 3
;; depth 2, outer 1
;; nodes: 4 3
...
the latch of the loop contains the following:
;; Pred edge 4 [50.0%]
(code_label 93 374 76 3 3 [1 uses])
(note 76 93 77 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(insn 77 76 78 3 y.c:5 (set (reg:V4SI 215 [ vect_var_.35 ])
(reg:V4SI 203 [ vect_var_.100 ])) 7 {_movv4si} (expr_list:REG_DEAD
(reg:V4SI 203 [ vect_var_.100 ])
(nil)))
(insn 78 77 180 3 y.c:5 (set (reg:V4SI 212 [ vect_var_.56 ])
(reg:V4SI 202 [ vect_var_.101 ])) 7 {_movv4si} (expr_list:REG_DEAD
(reg:V4SI 202 [ vect_var_.101 ])
(nil)))
;; End of basic block 3 - ( 4)
--
Summary: missed optimization: cleanup loop latch (SMS)
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eres at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34263
[Bug target/34256] mmx and movd/movq on x86_64
--- Comment #2 from ubizjak at gmail dot com 2007-11-28 12:45 --- Created an attachment (id=14653) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14653action=view) Patch to adjust mmx move instructions It looks that mmx move instructions need some tuning. Attached patch fixes your problems and generates (-march=core2): foo: .LFB4: movqx(%rip), %mm0 paddd y(%rip), %mm0 movd%mm0, %rax ret Since these RA adjustments are very fragile, this patch is not appropriate for stage3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34256
[Bug target/34256] mmx and movd/movq on x86_64
--- Comment #3 from ubizjak at gmail dot com 2007-11-28 12:46 --- Confirmed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||patch Last reconfirmed|-00-00 00:00:00 |2007-11-28 12:46:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34256
[Bug tree-optimization/34140] [4.3 Regression] ICE in is_hidden_global_store, at tree-ssa-sink.c:207
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||11/msg01548.html Status|NEW |ASSIGNED Last reconfirmed|2007-11-18 14:44:14 |2007-11-28 13:06:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34140
[Bug testsuite/34253] Lots of failures in gcc.dg/vect
--- Comment #3 from andreasmeier80 at gmx dot de 2007-11-28 13:17 --- Today I have checked out trunk newly. So my tree is fine. The failures are also there. I will send the new testresults shortly. I'm using Suse 10.1. The version of dejagnu is 1.4.4. I see only unusual errors in gcc.dg/vect. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34253
[Bug tree-optimization/34005] [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME object)
--- Comment #12 from jakub at gcc dot gnu dot org 2007-11-28 13:20 --- So, shouldn't the expression_without_side_effects_p routine just be renamed to expression_could_trap_p, otherwise it will be confused again and again with !TREE_SIDE_EFFECTS on the expr? The gimplify_cond_expr new hunk then could be + if (gimplify_ctxp-allow_rhs_cond_expr + /* If either branch has side effects or could trap, it can't be + evaluated unconditionally. */ +!TREE_SIDE_EFFECTS (TREE_OPERAND (*expr_p, 1)) +!expression_could_trap_p (TREE_OPERAND (*expr_p, 1)) +!TREE_SIDE_EFFECTS (TREE_OPERAND (*expr_p, 2)) +!expression_could_trap_p (TREE_OPERAND (*expr_p, 2))) + return gimplify_pure_cond_expr (expr_p, pre_p); This would allow side effects on condition of the COND_EXPR, and at least to me would be less confusing (and given that Diego raised that question first, I'm probably not alone). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34005
[Bug fortran/34260] present returns wrong value of optional variables
--- Comment #2 from vahtras at kth dot se 2007-11-28 13:22 --- Subject: Re: present returns wrong value of optional variables On Wed, 2007-11-28 at 10:33 +, terry at chem dot gu dot se wrote: Shouldn't this error be detected by the compiler at some stage of the compilation? Or rather: Having the compiler detect this and raise an error would be a nice feature. OK, thanks. I realize the difficulty here when routines are complied separately, but perhaps a warning might be possible at the linking stage... Olav -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34260
[Bug target/34250] ICE in find_constant_pool_ref
--- Comment #3 from uweigand at gcc dot gnu dot org 2007-11-28 13:36 --- Hi Michael, the problem is that there is an implicit assumption throughout the code that you can have at most one pool constant per instruction. For example, the pool size / splitting heuristics assume that. I think with your patch as is, you can find examples where it will attempt to add 2 constants to the current pool chunk even though it only has room for 1 left. This could probably be fixed by reworking some of the heuristics (e.g. check *first* how many constants an insn will require, and start up a new pool early if required). But that can be a bit tricky ... What fundamentally cannot be fixed is the extreme case where the single instruction uses so many constants that they don't fit into a pool chunk even by themselves. We can only reload the base register to point to a different chunk once before every insn. Can you elaborate why this occurs in normal code (without inline asm)? -- uweigand at gcc dot gnu dot org changed: What|Removed |Added CC||uweigand at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34250
[Bug tree-optimization/34005] [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME object)
--- Comment #13 from rakdver at kam dot mff dot cuni dot cz 2007-11-28 13:45 --- Subject: Re: [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME object) --- Comment #12 from jakub at gcc dot gnu dot org 2007-11-28 13:20 --- So, shouldn't the expression_without_side_effects_p routine just be renamed to expression_could_trap_p, otherwise it will be confused again and again with !TREE_SIDE_EFFECTS on the expr? The gimplify_cond_expr new hunk then could be + if (gimplify_ctxp-allow_rhs_cond_expr + /* If either branch has side effects or could trap, it can't be + evaluated unconditionally. */ +!TREE_SIDE_EFFECTS (TREE_OPERAND (*expr_p, 1)) +!expression_could_trap_p (TREE_OPERAND (*expr_p, 1)) +!TREE_SIDE_EFFECTS (TREE_OPERAND (*expr_p, 2)) +!expression_could_trap_p (TREE_OPERAND (*expr_p, 2))) + return gimplify_pure_cond_expr (expr_p, pre_p); This would allow side effects on condition of the COND_EXPR, and at least to me would be less confusing (and given that Diego raised that question first, I'm probably not alone). that would be fine with me (it would be safer than changing the semantics of TREE_SIDE_EFFECTS). I guess it is up to Diego, I am willing to do it either way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34005
[Bug fortran/34260] Give warning if procedure with implicit interface is called with different arguments
--- Comment #3 from burnus at gcc dot gnu dot org 2007-11-28 13:54 --- If no explicit interface is known, the following produces is almost all cases invalid code: CALL SUB(A,I) CALL SUB(A) Other compilers detect this such as NAG f95: Error: line 5: Different number of arguments from the first call of SUB or g95: Warning (154): Inconsistent number of arguments in reference to 'sub' at (1) and (2) OK, thanks. I realize the difficulty here when routines are complied separately Currently, gfortran does not do in-file consistency checks. Though this is planned. It won't help for if they are compiled separately. but perhaps a warning might be possible at the linking stage... No, the linking is done by the linker and not the compiler and it has not such knowledge. It only sees whether a symbol (sub_) can be resolved or not. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Severity|blocker |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu | Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2007-11-28 13:54:16 date|| Summary|present returns wrong value |Give warning if procedure |of optional variables |with implicit interface is ||called with different ||arguments http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34260
[Bug fortran/34262] MVBITS does not work for arrays
--- Comment #1 from burnus at gcc dot gnu dot org 2007-11-28 14:09 --- For a scalars x and y: _gfortran_mvbits_i4 (x, C.860, C.861, y, C.862); for an arrays a and b: _gfortran_mvbits_i4 (parm.2, C.872, C.873, parm.3, C.875); It actually does not surprise me that this does not work if one replaces the integer variable by a struct array1_integer(kind=4). -- burnus at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||32834 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2007-11-28 14:09:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34262
[Bug target/34115] atomic builtins not supported on i686?
--- Comment #9 from scovich at gmail dot com 2007-11-28 14:20 --- (In reply to comment #8) (In reply to comment #7) Too bad they aren't defined for any machine I've tried so far... The explanation is very simple: the new macros are implemented only in mainline (would be 4.3.0). Any chance of backporting? (I know, probably not) The only question left is whether the compiler is supposed to emit a warning when it doesn't support the intrinsics (like the docs say) or whether the user should just be ready for linker errors. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34115
[Bug fortran/34262] MVBITS does not work for arrays
--- Comment #2 from burnus at gcc dot gnu dot org 2007-11-28 14:20 --- The following fixes it, but I need to check for unwanted side effects: Index: intrinsic.c === --- intrinsic.c (revision 130489) +++ intrinsic.c (working copy) @@ -104,6 +104,7 @@ gfc_get_intrinsic_sub_symbol (const char gfc_symbol *sym; gfc_get_symbol (name, gfc_intrinsic_namespace, sym); + sym-attr.elemental = 1; sym-attr.always_explicit = 1; sym-attr.subroutine = 1; sym-attr.flavor = FL_PROCEDURE; -- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED GCC build triplet|? | GCC host triplet|? | GCC target triplet|? | Last reconfirmed|2007-11-28 14:09:34 |2007-11-28 14:20:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34262
[Bug preprocessor/32868] Don't warn about redefinitions of __STDC_FORMAT_MACROS
--- Comment #2 from ian at airs dot com 2007-11-28 14:29 --- The C99 standard specifically calls out __STDC_FORMAT_MACROS as a macro which may be defined before including inttypes.h. Therefore, I believe that warning about this definition is a bug for both C and C++. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32868
[Bug c++/34264] New: Pointer to template method of a class A, does not work in template context for that class A
I cannot compile the following simple program with the 3.2.3 g++ compiler.
#include iostream
#include typeinfo
using namespace std;
class A
{
public:
template typename Type
void method(void)
{
cout hello typeid(int).name() endl;
}
};
template class ClassA, typename Type
void run(void)
{
typedef void (ClassA::*pMethod)(void);
pMethod p = ClassA::methodType; // line 23, error message
A a;
(a.*p)();
}
int main(void)
{
runA, int();
return 0;
}
I get the error message:
[EMAIL PROTECTED] % /usr/bin/g++ test.cpp
test.cpp: In function `void run()':
test.cpp:23: syntax error before `' token
While on the SOLARIS, Windows or on Linux with the Portland Compiler this is no
problem to compile.
A pointer to a template method of a non-template class is no problem, since
this works for line 23:
pMethod p = A::methodType; // line 23, error message
However templatizing this to ClassA is now suddenly a problem.
Your help will be most appreciated.
--
Summary: Pointer to template method of a class A, does not work
in template context for that class A
Product: gcc
Version: 3.2.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Erik dot Bouts at Shell dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34264
[Bug testsuite/34253] Lots of failures in gcc.dg/vect
--- Comment #4 from andreasmeier80 at gmx dot de 2007-11-28 14:12 --- The new results are at http://gcc.gnu.org/ml/gcc-testresults/2007-11/msg01515.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34253
[Bug bootstrap/34205] iwmmxt type/size error
--- Comment #9 from aldot at gcc dot gnu dot org 2007-11-28 14:47 --- If the requested bitfield is larger than the type that was previously tried for enum, then you have to widen the type to fulfill that constaint. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34205
[Bug tree-optimization/34265] New: Missed optimizations
I have had a closer look to the optimization of the polyhedron test induct.f90. 3/4 of the runtime is spent in the subroutine 'mutual_ind_quad_cir_coil' and 1/4 in 'mutual_ind_quad_rec_coil'. The two subroutines contain two main loops with the following structure: do i = 1, 2*m ... do j = 1, 9 ... do k = 1, 9 q_vector(1) = 0.5_longreal * a * (x2gauss(k) + 1.0_longreal) q_vector(2) = 0.5_longreal * b1 * (y2gauss(k) - 1.0_longreal) q_vector(3) = 0.0_longreal ! ! rotate quad vector into the global coordinate system ! rot_q_vector(1) = dot_product(rotate_quad(1,:),q_vector(:)) rot_q_vector(2) = dot_product(rotate_quad(2,:),q_vector(:)) rot_q_vector(3) = dot_product(rotate_quad(3,:),q_vector(:)) ! ! compute and add in quadrature term ! numerator = w1gauss(j) * w2gauss(k) * dot_product(coil_current_vec,current_vector) denominator = sqrt(dot_product(rot_c_vector-rot_q_vector, rot_c_vector-rot_q_vector)) l12_lower = l12_lower + numerator/denominator end do end do end do where the six first lines of code in the k loop do not depend on i nor j and can be computed in a 'do k = 1, 9' loop outside the main loop by replacing the length-three vector 'rot_q_vector' by a nine by three array. The original code induct.f90 gives the following timing (all with -O3 -ffast-math -funroll-loops): 93.227u 0.094s 1:33.32 99.9%0+0k 0+0io 0pf+0w and output: ... Maximum wand/quad abs rel mutual inductance = 5.95379428444656467E-002 Minimum resq coil/quad abs rel mutual inductance =0. Maximum resq coil/quad abs rel mutual inductance = 9.63995250242061230E-002 ... Unrolling bye hand 'numerator' and 'denominator' gives (see http://gcc.gnu.org/ml/fortran/2007-11/msg00231.html): 65.563u 0.092s 1:05.66 99.9%0+0k 0+0io 0pf+0w Looking at the assembly I can see that for the original code the inner loops in k are not unrolled, as guessed by Paul Thomas (only the implied vector loops being unrolled). QUESTION 1: Should the frontend do the unrolling for small vectors itself? or should the middleend be more aggressive for nested loops with small known iterations? Moving the invariants on i and j in the k loops outside the main loops gives: 80.313u 0.074s 1:20.39 99.9%0+0k 0+1io 0pf+0w Combining the two hand optimizations gives: 35.925u 0.040s 0:35.97 99.9%0+0k 0+0io 0pf+0w (without -ffast-math the timing is 59.263u 0.067s 0:59.33 99.9%0+0k 0+1io 0pf+0w) but the results change to: Maximum wand/quad abs rel mutual inductance = 5.95379428444656675E-002 Minimum resq coil/quad abs rel mutual inductance =0. Maximum resq coil/quad abs rel mutual inductance = 9.63995250242059842E-002 ( Maximum wand/quad abs rel mutual inductance = 5.95379428444659520E-002 Minimum resq coil/quad abs rel mutual inductance =0. Maximum resq coil/quad abs rel mutual inductance = 9.63995250242060675E-002 without -ffast-math). The attached file gives the differences between the original code and the three variants. This is to be compared to further optimizations (indu.v2.f90) leading to: 35.376u 0.062s 0:35.44 99.9%0+0k 0+1io 0pf+0w or after merging the two loops (indu.v3.f90) to: 34.452u 0.041s 0:34.49 100.0% 0+0k 0+0io 0pf+0w I have counted the number of sqrt() in the assembly code and found 9 of them in the slow codes while I only found 5 (10 for indu.v3.f90) of them for the fast codes. I checked that this was not due to common subexpressions I may have missed. Looking more closely to the assemby I saw that he slow codes used 'sqrtsd' while the fast ones used 'sqrtpd' along with several other packed operations. Now 65.66*5/9=36.48 explaining most of the speedup. Note that 5=9/2+1, i.e., four packed computations followed by a scalar one. Owing to the same structure in the two loops, the two scalar computations could be merged in a packed one, but it is missed by the optimizer. I have tried without success to trigger this vectorization by making some variables vectors in k. QUESTION 2: Why the optimizer is able to vectorize in some cases and not in others? Can the frontend help to vectorize? -- Summary: Missed optimizations Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization 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=34265
[Bug target/34250] ICE in find_constant_pool_ref
--- Comment #4 from matz at gcc dot gnu dot org 2007-11-28 15:28 --- What I meant with normal code is by using inline asms. As it stands it's impossible to write inline asm instructions having more than one literal pool operand. I consider this normal use of the capabilities GCC gives you. However with one of our internal patches (which enforces arguments live) we use inline asms internally, which then happens to hit this problem fairly easily. That's how we triggered this and why I investigated there. For reference, our hacky approach to enforce liveness of arguments is by using them as operands of an inline asm, which we insert as first instruction in every function. When those are inlined and arguments seen as constant (e.g. function names, __func__) it quickly happens that there are more than one constant pool ref in one inline asm. But I see what you are saying regarding the possibility of overflowing the pool inside one instruction. Will the compiler ICE in that situation or will it silently generate wrong code? If the former I'm willing to accept that risk for now, after all split constant pools are relatively new anyway, IIRC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34250
[Bug tree-optimization/34265] Missed optimizations
--- Comment #1 from dominiq at lps dot ens dot fr 2007-11-28 15:30 --- Created an attachment (id=14654) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14654action=view) Diffs between the original file and the simplest variants In induct.v1.f90 'nominator' and 'denominator' are unrolled by hand. In induct.v2.f90 the invariants are moved outside the mail loop and induct.v3.f90 combines the two. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34265
[Bug target/34250] ICE in find_constant_pool_ref
--- Comment #6 from matz at gcc dot gnu dot org 2007-11-28 15:59 --- Yes, that would be a viable workaround. Perhaps even correct, given that GCC can handle only MAX_RECOG_OPERANDS, which is only 30 at a minimum. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34250
[Bug tree-optimization/34244] [4.3 Regression] VRP/SCEV miscompiles Firefox
--- Comment #7 from rakdver at kam dot mff dot cuni dot cz 2007-11-28 16:05 --- Subject: Re: [4.3 Regression] VRP/SCEV miscompiles Firefox --- Comment #6 from rguenth at gcc dot gnu dot org 2007-11-28 15:47 --- We could clear the SCEV cache for an SSA_NAME we set a new value range (in set_value_range and set_value_range_to_varying), but I see that SCEV also caches loop-nb_iterations which we probably would need to clear unconditionally (for all loops). yes, the simplest solution is to call scev_reset somewhere (either in set_value_range, or in adjust_range_with_scev). However, I fear the compile time impact would be too large (# of iterations analysis is fairly time consuming, and not caching the results used to cause us to spend 10% or more in it). More feasible solution seems to be to determine the number of iterations for all loops before the start of VRP, and to remember the values. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34244
[Bug tree-optimization/34265] Missed optimizations
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-11-28 16:06 --- GCC doesn't have a facility to split the inner loop and move it out of the outer loops by introducing a array temporary. As for completely unrolling, this only happens for innermost loops(?) and you can tune the heuristics with --param max-completely-peeled-insns=N (defaults to 400) and --param max-completely-peel-times (defaults to 16). Use -funroll-loops to enable this. Note that complete unrolling happens too late to help LIM or vectorization. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34265
[Bug tree-optimization/34244] [4.3 Regression] VRP/SCEV miscompiles Firefox
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-11-28 15:47 --- We could clear the SCEV cache for an SSA_NAME we set a new value range (in set_value_range and set_value_range_to_varying), but I see that SCEV also caches loop-nb_iterations which we probably would need to clear unconditionally (for all loops). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34244
[Bug tree-optimization/34244] [4.3 Regression] VRP/SCEV miscompiles Firefox
--- Comment #8 from rguenther at suse dot de 2007-11-28 16:13 --- Subject: Re: [4.3 Regression] VRP/SCEV miscompiles Firefox On Wed, 28 Nov 2007, rakdver at kam dot mff dot cuni dot cz wrote: --- Comment #6 from rguenth at gcc dot gnu dot org 2007-11-28 15:47 --- We could clear the SCEV cache for an SSA_NAME we set a new value range (in set_value_range and set_value_range_to_varying), but I see that SCEV also caches loop-nb_iterations which we probably would need to clear unconditionally (for all loops). yes, the simplest solution is to call scev_reset somewhere (either in set_value_range, or in adjust_range_with_scev). However, I fear the compile time impact would be too large (# of iterations analysis is fairly time consuming, and not caching the results used to cause us to spend 10% or more in it). More feasible solution seems to be to determine the number of iterations for all loops before the start of VRP, and to remember the values. Or not use tree_expr_nonnegative_p from inside tree-ssa-loop-niter.c which is where the bad feedback comes from. But yes, computing the number of iterations in advance should fix this as well and is probably best. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34244
[Bug tree-optimization/34265] Missed optimizations
--- Comment #3 from dominiq at lps dot ens dot fr 2007-11-28 16:14 --- Note that complete unrolling happens too late to help LIM or vectorization. Could this be translated as a YES to my first question: the fortran frontend should unroll computations for short vectors? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34265
[Bug target/34250] ICE in find_constant_pool_ref
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-11-28 15:41 --- We could generate multiple asms instead, one for each parameter... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34250
[Bug tree-optimization/34265] Missed optimizations
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-11-28 16:17 --- I would in principle say no - we can instead improve the middle-end here. But it may pay off to not generate a loop for short vectors in case the resulting IL is smaller for example. Of course it would duplicate logic in the frontend if that is not already available, so from a middle-end point of view we should fix it there instead (the same problems happen for C and C++). See PR34223. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||34223 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34265
[Bug preprocessor/32868] Don't warn about redefinitions of __STDC_FORMAT_MACROS
--- Comment #3 from tromey at gcc dot gnu dot org 2007-11-28 16:26 --- Testing a patch. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-07-26 21:33:20 |2007-11-28 16:26:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32868
[Bug middle-end/31529] ICE in cgraph_expand_function with IMA
--- Comment #2 from aldot at gcc dot gnu dot org 2007-11-28 16:28 --- Can still be observed on trunk. Reducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31529
[Bug tree-optimization/34265] Missed optimizations
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-11-28 16:33 --- Created an attachment (id=14655) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14655action=view) patch for early complete unrolling of inner loops For example with a patch like this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34265
[Bug bootstrap/34205] iwmmxt type/size error
--- Comment #10 from raj dot khem at gmail dot com 2007-11-28 16:40 --- (In reply to comment #9) If the requested bitfield is larger than the type that was previously tried for enum, then you have to widen the type to fulfill that constaint. is there a reference for this in the standards? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34205
[Bug target/34261] Directed rounding doesn't work on MacOS X
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-28 17:08 --- I doubt that this is a gcc bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34261
[Bug c++/34264] Pointer to template method of a class A, does not work in template context for that class A
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-28 17:11 --- Try: pMethod p = ClassA::templete methodType; // line 23, error message -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34264
[Bug target/34250] ICE in find_constant_pool_ref
--- Comment #7 from uweigand at gcc dot gnu dot org 2007-11-28 17:11 --- (In reply to comment #4) For reference, our hacky approach to enforce liveness of arguments is by using them as operands of an inline asm, which we insert as first instruction in every function. When those are inlined and arguments seen as constant (e.g. function names, __func__) it quickly happens that there are more than one constant pool ref in one inline asm. I'm not sure I see what the point of this is ... But I see what you are saying regarding the possibility of overflowing the pool inside one instruction. Will the compiler ICE in that situation or will it silently generate wrong code? If the former I'm willing to accept that risk for now, after all split constant pools are relatively new anyway, IIRC. Not really, they've always been required on s390. (Note that on s390x, and even on s390 with -march=z900 or higher, split constant pool are no longer necessary.) I expect that what will happen when the pool overflows is that you get a linker error because the 12-bit relocation in the displacement field overflows. (But maybe this is only a warning, I'm not completely sure this hasn't changed across different linker versions ...) Note that if I understand your usage correctly, this should in fact never occur as you do not generate any code that actually references those literal pool entries. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34250
[Bug target/19923] [4.0/4.1/4.2/4.3 Regression] openssl is slower when compiled with gcc 4.0 than 3.3
--- Comment #42 from dsh at gcc dot gnu dot org 2007-11-28 17:19 --- Created an attachment (id=14656) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14656action=view) Benchmarks I ran the benchmarks for the minimal testcase (using Dan Kegel's script) on a Core 2 Duo, AMD Dual Core Opteron, and a Pentium 3 using GCC 2.95.3, 3.4.3, 4.0.1, and 4.3.0 from svn. I'm still looking for a Pentium 4 to test on. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19923
[Bug middle-end/24548] [4.0/4.1 Regression] __builtin_constant_p not resolved with -O2
--- Comment #5 from manu at gcc dot gnu dot org 2007-11-28 17:32 --- Dave, could you check this with a recent release? -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24548
[Bug c/25702] feature request: generate a warning for sizeof on a pointer
--- Comment #4 from manu at gcc dot gnu dot org 2007-11-28 17:34 --- So what the BSD people said about this? Did they agree with your assessment? How many of those 26 likely bugs were considered real bugs by them? It really seems too noisy and with no clear way to avoid or workaround an invalid warning. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25702
[Bug bootstrap/34205] iwmmxt type/size error
--- Comment #11 from aldot at gcc dot gnu dot org 2007-11-28 17:44 ---
The standard (6.7.2.2, 4) talks about the note in #7.
I read this as for this input:
8---
enum e {ee};
struct s { __extension__ enum e baz:16; };
8---
The smallest type that can represent enum e has to be able to hold a bitfield
of 16, i.e.:
8---
enum e {__GCC_CONSTRAINT_ee=SHRT_MAX};
struct s { __extension__ enum e baz /*now implied :16*/; };
8---
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34205
[Bug rtl-optimization/3507] appalling optimisation with sub/cmp on multiple targets
--- Comment #9 from rask at gcc dot gnu dot org 2007-11-28 18:01 --- Created an attachment (id=14657) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14657action=view) Patch v2 to enhance cse.c This patch also handles unsigned comparisons and thus optimizes the original testcase too. Before: foo: movl4(%esp), %edx # 2 *movsi_1/1 [length = 4] movl8(%esp), %eax # 3 *movsi_1/1 [length = 4] movl%edx, %ecx # 35*movsi_1/1 [length = 2] subl%eax, %ecx # 7 *subsi_1/1 [length = 2] cmpl%eax, %edx # 8 *cmpsi_1_insn/1 [length = 2] jae .L2 # 9 *jcc_1 [length = 2] addl$100, %ecx # 11*addsi_1/1 [length = 3] .L2: movl%ecx, %eax # 18*movsi_1/1 [length = 2] ret # 38return_internal [length = 1] After: foo: movl4(%esp), %eax # 2 *movsi_1/1 [length = 4] subl8(%esp), %eax # 8 *subsi3_cc_overflow/2 [length = 4] jae .L2 # 9 *jcc_1 [length = 2] addl$100, %eax # 11*addsi_1/1 [length = 3] .L2: rep # 39return_internal_long[length = 1] ret I was going to abandon this patch, but maybe it deserves a second chance. :-) -- rask at gcc dot gnu dot org changed: What|Removed |Added Attachment #14647|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3507
[Bug fortran/34230] Expressions of parameters evaluated with too high precision
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-11-28 18:03 --- I consider this a bug. I have to check, but I think that the IEEE rules are clear, even though they are not mandatory until we introduce the corresponding standard modules. The calculation of y does overflow, and while we can debate on what the behaviour of -fno-range-check should be, I think there is a strong case for doing the same thing that a) other compilers do, b) IEEE mandates, c) is what would happen if it occurred at runtime. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34230
[Bug target/19923] [4.0/4.1/4.2/4.3 Regression] openssl is slower when compiled with gcc 4.0 than 3.3
--- Comment #43 from dank at kegel dot com 2007-11-28 18:01 --- Of the results posted above, the only interesting one that is still slower than gcc-2.95 is a pentium 3 with -fPIC. (Happily, gcc-4.3 is an improvement there, but it's still worse than 2.95.) Oddly, this one does better with athlon-xp tuning. /proc/cpuinfo info pic? tune [t_34/t_295, t_401/t_295, t_43/t_295] cpu family 6,model 11, Intel(R) Pentium(R) III CPU - S 1266MHz, -fPIC tune=pentium3 [1.37, 1.72, 1.20] cpu family 6,model 11, Intel(R) Pentium(R) III CPU - S 1266MHz, -fPIC tune=athlon-xp [2.16, 2.49, 1.10] I'm not sure how important Pentium III performance is anymore. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19923
[Bug bootstrap/34205] enum type/size error
--- Comment #12 from aldot at gcc dot gnu dot org 2007-11-28 18:28 --- Not target specific, adjusting accordingly. Observed everywhere with -fshort-enums -- aldot at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|arm-linux-*gnueabi | GCC host triplet|i386-linux-gnu | GCC target triplet|arm-linux-*gnueabi | Keywords||rejects-valid Summary|iwmmxt type/size error |enum type/size error http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34205
[Bug tree-optimization/34265] Missed optimizations
--- Comment #6 from dominiq at lps dot ens dot fr 2007-11-28 18:18 --- Subject: Re: Missed optimizations For example with a patch like this. You also need --- ../_gcc_clean/gcc/tree-flow.h 2007-11-16 16:17:46.0 +0100 +++ ../gcc-4.3-work/gcc/tree-flow.h 2007-11-28 18:56:42.0 +0100 @@ -980,7 +980,7 @@ void tree_ssa_lim (void); unsigned int tree_ssa_unswitch_loops (void); unsigned int canonicalize_induction_variables (void); -unsigned int tree_unroll_loops_completely (bool); +unsigned int tree_unroll_loops_completely (bool, bool); unsigned int tree_ssa_prefetch_arrays (void); unsigned int remove_empty_loops (void); void tree_ssa_iv_optimize (void); Still building. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34265
[Bug preprocessor/20770] Using -M -MT ... -MF ... with -g3 generates preprocess line to stdout
--- Comment #3 from tromey at gcc dot gnu dot org 2007-11-28 18:21 --- Can you reproduce this with anything newer than 3.4? The 3.x release series is closed. I couldn't reproduce with 4.1. So, barring new information, I think this is fixed. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20770
[Bug bootstrap/34205] enum type/size error
--- Comment #13 from pbrook at gcc dot gnu dot org 2007-11-28 19:05 --- The short answer is don't do that. -mabi=iwmmxt selects a bare-metal (short-enum) AAPCS variant with iWMMXt calling conventions. As such it is incompatible with the Linux EABI supplement (http://www.codesourcery.com/gnu_toolchains/arm/arm_gnu_linux_abi.pdf) which requires long-enums. If you want iwmmxt calling conventions on linux you'll have to define and add a new ABI variant. In theory gcc should probably be fixed to support short-enum host systems. In practice all vaguely interesting host systems use long enums, and other bits of a linux system will explode if built with -fshort-enums, so I'm closing this as WONTFIX. -- pbrook at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34205
[Bug fortran/34230] Expressions of parameters evaluated with too high precision
--- Comment #7 from kargl at gcc dot gnu dot org 2007-11-28 19:06 --- (In reply to comment #6) I consider this a bug. I have to check, but I think that the IEEE rules are clear, even though they are not mandatory until we introduce the corresponding standard modules. The calculation of y does overflow, and while we can debate on what the behaviour of -fno-range-check should be, I think there is a strong case for doing the same thing that a) other compilers do, b) IEEE mandates, c) is what would happen if it occurred at runtime. a) Do other compilers have an equivalent to -fno-range-check? b) The Fortran 95 standard is silent with respect to IEEE-754, and the Fortran 2003 standard only considers IEEE-754 through the explicit use of an intrinsic module. c) Are you suggesting that -ffpe-trap=invalid,overflow,zero should be the default runtime behavior (to match gfortran's default -frange-check behavior)? If you want to be pedantic, this code is invalid real, parameter :: y = exp(log(huge(y))+20) because (See 13.14) A program is prohibited from invoking an intrinsic procedure under circumstances where a value to be returned in a subroutine argument or function result is outside the range of values representable by objects of the specified type and type parameters. unless you're claiming +Inf is in the range of values representable by a real (in which case, you can against remove range checking). If +Inf is a representable value, you need to go fix the IO subsystem to read +Inf (and NaN). character(len=60) str real inf, nan integer, parameter :: i = 2139095040, j = 2141192192 inf = transfer(i,inf) ! Legal, but non-portable nan = transfer(j,nan) ! Legal, but non-portable write(str, *) inf, nan inf = 0 nan = 0 read(str, *) inf, nan print *, inf, nan end troutmask:sgk[246] ./z At line 9 of file a.f90 Fortran runtime error: Bad real number in item 1 of list input You'll also need to fix modules to properly handle +Inf and NaN. module except real, parameter :: inf = 1./0., nan = 0./0. end module program a use except print *, inf, nan end program a troutmask:sgk[251] gfc -o z -fno-range-check a.f90 troutmask:sgk[252] ./z 0.00 0.00 -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC|kargl at gcc dot gnu dot org|sgk at troutmask dot apl dot ||washington dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34230
[Bug pch/33829] HOST_HOOKS_GT_PCH_GET_ADDRESS is missing from the documentation index
--- Comment #1 from tromey at gcc dot gnu dot org 2007-11-28 19:06 --- Confirmed. I didn't see any instances of @findex or @vindex in hostconfig.texi. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-28 19:06:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33829
[Bug preprocessor/33473] GCC does not correctly generate dependencies for precompiled headers
--- Comment #4 from tromey at gcc dot gnu dot org 2007-11-28 19:07 --- *** This bug has been marked as a duplicate of 14933 *** -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33473
[Bug pch/14933] missing pre-compiled header depends with -MD
--- Comment #8 from tromey at gcc dot gnu dot org 2007-11-28 19:07 --- *** Bug 33473 has been marked as a duplicate of this bug. *** -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||rswan at signetic dot ca http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14933
[Bug tree-optimization/34265] Missed optimizations
--- Comment #7 from dominiq at lps dot ens dot fr 2007-11-28 18:48 --- Subject: Re: Missed optimizations With your patch the runtime went from 93.670u 0.103s 1:33.85 99.9%0+0k 0+0io 32pf+0w to 38.741u 0.038s 0:38.85 99.7%0+0k 0+1io 32pf+0w Pretty impressive! Note that with gfortran 4.2.2 the timing is 72.451u 0.046s 1:12.59 99.8%0+0k 1+0io 33pf+0w I'll run the full polyhedron suite. Thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34265
[Bug c/34266] New: ICE
/*
% uname -a
Linux lepidus 2.4.21-sgi302r24 #1 SMP Fri Oct 22 22:43:12 PDT 2004 ia64 ia64
ia64 GNU/Linux
% gcc -v
Using built-in specs.
Target: ia64-unknown-linux-gnu
Configured with: /usr/local/gcc-4.2.2/src/gcc-4.2.2/configure
--enable-languages=c,c++,fortran --with-gnu-as
--with-as=/usr/local/binutils-2.17/ia64-Linux-gcc-4.1.1/bin/as --with-gnu-ld
--with-ld=/usr/local/binutils-2.17/ia64-Linux-gcc-4.1.1/bin/ld
--with-gmp=/usr/local/gmp-4.2.1/ia64-Linux-gcc-4.2.0
--with-mpfr=/usr/local/mpfr-2.2.1/ia64-Linux-gmp-4.2.1-gcc-4.2.0
--prefix=/usr/local/gcc-4.2.2/ia64-Linux
Thread model: posix
gcc version 4.2.2
%
% gcc -funroll-loops -O2 -c foo.c// gives ICE
%
% gcc -funroll-loops -O1 -c foo.c// compiles successfully
% gcc -O2 -c foo.c // compiles successfully
%
% gcc-4.3-20071123 -funroll-loops -O2 -c foo.c
// compiles successfully
*/
/*
from GNU gmp longlong.h
*/
#define umul_ppmm(ph, pl, m0, m1) \
__asm__ (xma.hu %0 = %2, %3, f0\n\txma.l %1 = %2, %3, f0 \
: =f (ph), =f (pl)\
: f (m0), f (m1))
/* cut down from sage-2.8.14/flint-0.9-r1075.p1/ZmodF_mul.c */
inline
void bar(long* out, long a)
{
umul_ppmm(*out, *out, a, a);
*out += a * a;
}
void foo(long* out, long* in, long len)
{
int i; for (i = 0; i len; i++)
bar(out, in[i]);
}
--
Summary: ICE
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kate01123 at gmail dot com
GCC build triplet: ia64-unknown-linux-gnu
GCC host triplet: ia64-unknown-linux-gnu
GCC target triplet: ia64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34266
[Bug fortran/34230] Expressions of parameters evaluated with too high precision
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-11-28 19:23 --- (In reply to comment #7) a) Do other compilers have an equivalent to -fno-range-check? Most compilers have a behaviour similar to -fno-range-check by default, only warning about range problems (Intel, Sun, g95 and Portland). On the example of this testcase, all report x and y as infinities. b) The Fortran 95 standard is silent with respect to IEEE-754, and the Fortran 2003 standard only considers IEEE-754 through the explicit use of an intrinsic module. As I said: our current behaviour is standard-conforming, and -fno-range-check is asking to drop some of the standard constraints. What we do then is outside the scope of the standard, so we need to do something reasonable, and probably follow a principle of least surprise. c) Are you suggesting that -ffpe-trap=invalid,overflow,zero should be the default runtime behavior (to match gfortran's default -frange-check behavior)? I am not, and don't see where I would imply such a thing. Trapping is widely different: it means throwing a FPE signal on certain floating-point exceptions. If you want to be pedantic, this code is invalid real, parameter :: y = exp(log(huge(y))+20) I do agree. That's what -fno-range-check is about: compile invalid code in cases where the community is not expecting bugs. In the end, I hope we win and noone writes invalid code. For now... well, lots of people and existing codes rely on such practice. unless you're claiming +Inf is in the range of values representable by a real No, I'm not. That would be stretching a bit far! If +Inf is a representable value, you need to go fix the IO subsystem to read +Inf (and NaN). Well, I happen to think that this would be a nice thing to do at some point. That's an extension to the standard, of course, but that would be, IMHO, a interesting one. You'll also need to fix modules to properly handle +Inf and NaN. I wasn't aware of that one, but it is understandable. I think that it would indeed be nice to change that behaviour. To sum up my point of view: -fno-range-check is about accepting code which is, strictly speaking, invalid. It is thus an extension and we should be guided by a) what other compilers do, b) consistency, c) least surprise. Moreover, I don't think changing that behaviour would hurt maintainability much (but I might be wrong; we'll know when someone starts working on it). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34230
[Bug fortran/34230] Expressions of parameters evaluated with too high precision
--- Comment #9 from burnus at gcc dot gnu dot org 2007-11-28 19:35 --- If +Inf is a representable value, you need to go fix the IO subsystem to read +Inf (and NaN). I just checked: - NAG f95, g95, ifort and sunf95 accept (case insensitive and with optional +/- prefix) NAN and INF, Infinity. (infini is for instance rejected.) - openf95, gfortran and g77 reject it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34230
[Bug fortran/34247] [4.3 Regression] ICE in omp_add_variable, at gimplify.c:4677
--- Comment #4 from jakub at gcc dot gnu dot org 2007-11-28 19:45 --- 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=34247
[Bug target/32406] [4.3 Regression] MIPS: FAIL in nestfunc-6.c at -O3
--- Comment #11 from rsandifo at gcc dot gnu dot org 2007-11-28 19:49 --- Patch applied. Thanks to David for the testing and Mark for the review. -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32406
[Bug tree-optimization/34140] [4.3 Regression] ICE in is_hidden_global_store, at tree-ssa-sink.c:207
--- Comment #8 from jakub at gcc dot gnu dot org 2007-11-28 19:49 --- 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=34140
[Bug target/32406] [4.3 Regression] MIPS: FAIL in nestfunc-6.c at -O3
--- Comment #10 from rsandifo at gcc dot gnu dot org 2007-11-28 19:46 --- Subject: Bug 32406 Author: rsandifo Date: Wed Nov 28 19:46:03 2007 New Revision: 130493 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130493 Log: gcc/ PR target/32406 * builtins.c (expand_builtin_nonlocal_goto): Also emit a use of GP register, if valid and fixed. Revert: 2007-06-21 David Daney [EMAIL PROTECTED] PR target/32406 * config/mips/mips.md (define_constants): Rename UNSPEC_EH_RECEIVER to UNSPEC_NONLOCAL_GOTO_RECEIVER globally. (exception_receiver): Renamed to ... (nonlocal_goto_receiver): ... this. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/config/mips/mips.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32406
[Bug c/25702] feature request: generate a warning for sizeof on a pointer
--- Comment #5 from meklund at cisco dot com 2007-11-28 19:43 --- Subject: Re: feature request: generate a warning for sizeof on a pointer Hi Manu, This is in regards to your Comments for the gcc feature enhancement request, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25702. On Wed, Nov 28, 2007 at 05:34:35PM -, manu at gcc dot gnu dot org wrote: --- Comment #4 from manu at gcc dot gnu dot org 2007-11-28 17:34 --- So what the BSD people said about this? Did they agree with your assessment? How many of those 26 likely bugs were considered real bugs by them? When I contacted Matt Dillon, he said all of them except two were definitely bugs. The other two were not in the Dragonfly code base, so he didn't comment on those. The 24 definite bugs have been corrected in Dragonfly. Paul Vixie corrected the bind bugs in the BIND8 sources and said thought this check would be a great compiler feature. I don't know if the bugs have been fixed in FreeBSD. I contacted [EMAIL PROTECTED] to make sure there were no security problems cause by these bugs and got no response. I didn't pursue the matter further after that. It really seems too noisy and with no clear way to avoid or workaround an invalid warning. This should be implemented in such a way that 'sizeof(ptr)' gets warning, but 'sizeof(char *)' doesn't. --mark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25702
[Bug fortran/34247] [4.3 Regression] ICE in omp_add_variable, at gimplify.c:4677
--- Comment #3 from jakub at gcc dot gnu dot org 2007-11-28 19:43 --- Subject: Bug 34247 Author: jakub Date: Wed Nov 28 19:43:03 2007 New Revision: 130492 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130492 Log: * trans-expr.c (gfc_trans_string_copy): Convert both dest and src to void *. PR fortran/34247 * trans-openmp.c (gfc_omp_privatize_by_reference): For REFERENCE_TYPE pass by reference only PARM_DECLs or non-artificial decls. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-openmp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34247
[Bug tree-optimization/34140] [4.3 Regression] ICE in is_hidden_global_store, at tree-ssa-sink.c:207
--- Comment #7 from jakub at gcc dot gnu dot org 2007-11-28 19:48 --- Subject: Bug 34140 Author: jakub Date: Wed Nov 28 19:48:19 2007 New Revision: 130494 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130494 Log: PR tree-optimization/34140 * tree-if-conv.c (if_convertible_phi_p): Fail if BB other than loop-header has virtual phi nodes. * gcc.c-torture/compile/20071128-1.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/20071128-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-if-conv.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34140
[Bug fortran/34230] Expressions of parameters evaluated with too high precision
--- Comment #10 from sgk at troutmask dot apl dot washington dot edu 2007-11-28 20:08 --- Subject: Re: Expressions of parameters evaluated with too high precision On Wed, Nov 28, 2007 at 07:23:57PM -, fxcoudert at gcc dot gnu dot org wrote: To sum up my point of view: -fno-range-check is about accepting code which is, strictly speaking, invalid. It is thus an extension and we should be guided by a) what other compilers do, b) consistency, c) least surprise. Moreover, I don't think changing that behaviour would hurt maintainability much (but I might be wrong; we'll know when someone starts working on it). I have a patch that does what people seem to want. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34230
[Bug ada/15803] Illegal program not detected, RM 8.3(19)
--- Comment #2 from sam at gcc dot gnu dot org 2007-11-28 20:43 --- Subject: Bug 15803 Author: sam Date: Wed Nov 28 20:43:25 2007 New Revision: 130495 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130495 Log: gcc/ada/ PR ada/15803 * par-ch3.adb (P_Variant_Part): Signal an error when anything other than an identifier is used after case in a variant_part. gcc/testsuite/ PR ada/15803 * gnat.dg/specs/variant_part.ads: New test. Added: trunk/gcc/testsuite/gnat.dg/specs/variant_part.ads Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/par-ch3.adb trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15803
[Bug target/17317] [3.3 Regression] Match Constraints for *movdf_insn fails
--- Comment #14 from sam at gcc dot gnu dot org 2007-11-28 20:45 --- Subject: Bug 17317 Author: sam Date: Wed Nov 28 20:44:58 2007 New Revision: 130496 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130496 Log: gcc/ada/ PR ada/17317 * par-ch4.adb (Is_Parameterless_Attribute): New map. (P_Name, Scan_Apostrophe block): Parse left parenthesis following attribute name or not depending on the new map. * sem-attr.adb (Analyze_Attribute): Parameterless attributes returning a string or a type will not be called with improper arguments. * sem-attr.ads (Attribute_Class_Array): Move to snames.ads. * snames.ads (Attribute_Class_Array): Moved from sem-attr.ads. gcc/testsuite/ PR ada/17317 * gnat.dg/specs/attribute_parsing.ads: New test. Added: trunk/gcc/testsuite/gnat.dg/specs/attribute_parsing.ads Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/par-ch4.adb trunk/gcc/ada/sem_attr.adb trunk/gcc/ada/sem_attr.ads trunk/gcc/ada/snames.ads trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17317
[Bug ada/32792] Assert_Failure sinfo.adb:1730
--- Comment #2 from sam at gcc dot gnu dot org 2007-11-28 20:46 --- Subject: Bug 32792 Author: sam Date: Wed Nov 28 20:46:18 2007 New Revision: 130497 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130497 Log: gcc/ada/ PR ada/32792 * sem_attr.adb (Analyze_Attribute, Attribute_Integer_Value clause): Signal an error when attribute argument is a fixed-point value of an unknown type. gcc/testsuite/ PR ada/32792 * gnat.dg/specs/integer_value.ads: New test. Added: trunk/gcc/testsuite/gnat.dg/specs/integer_value.ads Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/sem_attr.adb trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32792
[Bug ada/22559] Bug box, Program_Error at sinput.adb:404, derived fixed-point type
--- Comment #1 from sam at gcc dot gnu dot org 2007-11-28 20:48 --- Subject: Bug 22559 Author: sam Date: Wed Nov 28 20:48:10 2007 New Revision: 130498 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130498 Log: gcc/ada/ PR ada/22559 * sem_ch3.adb (Build_Derived_Numeric_Type): Do not set RM_Size on a derived ordinary fixed point type. * sem_ch13.adb (Analyze_Attribute_Definition_Clause): Recompute RM_Size when a Small clause is found. gcc/testsuite/ PR ada/22559 * gnat.dg/specs/delta_small.ads: New test. Added: trunk/gcc/testsuite/gnat.dg/specs/delta_small.ads Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/sem_ch13.adb trunk/gcc/ada/sem_ch3.adb trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22559
[Bug ada/32792] Assert_Failure sinfo.adb:1730
-- 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|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-28 20:49:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32792
[Bug ada/15803] Illegal program not detected, RM 8.3(19)
--- Comment #3 from sam at gcc dot gnu dot org 2007-11-28 20:50 --- Fixed in SVN trunk -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15803
[Bug bootstrap/25438] [4.2/4.3 Regression] make: *** No rule to make target `bubblestrap'. Stop.
--- Comment #8 from aldot at gcc dot gnu dot org 2007-11-28 20:50 --- A toplevel 'make' does what 'make bubblestrap' did before. See also: http://gcc.gnu.org/ml/gcc/2005-12/msg00435.html http://gcc.gnu.org/ml/fortran/2005-12/msg00338.html If install.texi from the 4_2-branch mentions this this could be considered fixed, perhaps. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25438
[Bug target/17317] [3.3 Regression] Match Constraints for *movdf_insn fails
--- Comment #15 from sam at gcc dot gnu dot org 2007-11-28 20:51 --- Forget message, wrong # in ChangeLogs, will fix them -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17317
[Bug ada/22559] Bug box, Program_Error at sinput.adb:404, derived fixed-point type
-- 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|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-28 20:52:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22559
[Bug ada/22559] Bug box, Program_Error at sinput.adb:404, derived fixed-point type
--- Comment #2 from sam at gcc dot gnu dot org 2007-11-28 20:52 --- Fixed in SVN trunk -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22559
[Bug c++/34267] New: [4.3 regression] ICE applying __decltype to name of template class
The following invalid code snippet triggers an ICE on mainline:
==
templateint struct A
{
__decltype(A);
};
==
bug.cc:3: internal compiler error: in type_dependent_expression_p, at
cp/pt.c:15697
Please submit a full bug report, [etc.]
--
Summary: [4.3 regression] ICE applying __decltype to name of
template class
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34267
[Bug c++/34267] [4.3 regression] ICE applying __decltype to name of template class
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34267
[Bug ada/17318] Put_Line (X'Img (Index)), index ignored
-- 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 20:43:36 |2007-11-28 20:53:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17318
[Bug ada/17318] Put_Line (X'Img (Index)), index ignored
--- Comment #2 from sam at gcc dot gnu dot org 2007-11-28 20:55 --- Fixed in SVN trunk -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17318
[Bug c/31128] __builtin_stack_restore/__builtin_stack_save should not be exposed to the user
--- Comment #11 from sabre at nondot dot org 2007-11-28 20:57 --- Please don't disable these. There are a variety of compilers that optionally or only generate C code, particularly for the functional languages. This is useful functionality for these compilers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31128
[Bug c++/34268] New: [4.3 regression] ICE applying __decltype to destructor
The following invalid code snippet triggers an ICE on mainline:
==
struct A
{
__decltype(~A);
};
==
bug.cc:3: internal compiler error: in lookup_member, at cp/search.c:1206
Please submit a full bug report,
--
Summary: [4.3 regression] ICE applying __decltype to destructor
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34268
[Bug c++/34268] [4.3 regression] ICE applying __decltype to destructor
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34268
[Bug c++/34269] New: [4.3 regression] Incomplete __decltype expressions accepted
The following invalid code snippets are wrongly accepted on mainline:
=
void foo() { __decltype; }
=
=
void foo() { __decltype(; }
=
--
Summary: [4.3 regression] Incomplete __decltype expressions
accepted
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: accepts-invalid, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34269
[Bug c++/34269] [4.3 regression] Incomplete __decltype expressions accepted
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34269
[Bug tree-optimization/34265] Missed optimizations
--- Comment #8 from jb at gcc dot gnu dot org 2007-11-28 20:48 --- The vectorization of dot products is covered by PR31738, I suppose -- jb at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||31738 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34265
[Bug ada/32792] Assert_Failure sinfo.adb:1730
--- Comment #3 from sam at gcc dot gnu dot org 2007-11-28 20:49 --- Fixed in SVN trunk -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32792
[Bug c++/34270] New: [4.3 regression] ICE applying __decltype to ternary expression
The following valid code snippet triggers a segfault on mainline:
=
templateint void foo()
{
__decltype(0 ?: 0) x;
}
=
bug.cc: In function 'void foo()':
bug.cc:3: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
--
Summary: [4.3 regression] ICE applying __decltype to ternary
expression
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34270
[Bug c++/34270] [4.3 regression] ICE applying __decltype to ternary expression
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34270
