[Bug c++/31268] Non-deterministic bug producing a run-time infinite loop
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-03-26 09:46 --- Seems to work for me on x86_64 with -m32. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31268
[Bug c/31361] New: SSE2 generation bug with shifts
Following code results in output 0 0 0 0 with -O1 and higher. -O0 is OK and gives output ff ff ff ff. gcc-3.4.6 produces correct output even with -O3. -- Summary: SSE2 generation bug with shifts Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: prakash at punnoor dot de GCC build triplet: x86_64 GCC host triplet: x86_64 GCC target triplet: x86_64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31361
[Bug c/31361] SSE2 generation bug with shifts
--- Comment #1 from prakash at punnoor dot de 2007-03-26 09:54 --- Created an attachment (id=13287) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13287&action=view) triggers bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31361
[Bug other/31359] 4.2 branch still generates abort for function casting
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-26 10:13 --- openssl is a weird beast of macro hell ;) (enough reason to fix it...) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31359
[Bug rtl-optimization/31360] [4.3 Regression] rtl loop invariant is broken
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-26 10:14 --- I guess the cost of loading zero is cheaper then? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
[Bug tree-optimization/31358] IV-OPTs produces a weird MEM_REF
--- Comment #1 from rakdver at gcc dot gnu dot org 2007-03-26 10:17 ---
(In reply to comment #0)
> For:
> int *f(int *a, int b, int c)
> {
> int i;
> a --;
> *a = 1;
> for (i = 0;i (a[i]) = 0;
> return a;
> }
> CUT
> I get in the final_cleanup:
> MEM[index: ivtmp.35, offset: 4294967292] = 0;
>
>
> And I noticed that ivtmp.29 is of type "long unsigned int" which seems wrong
> as
> it is actually the pointer.
no, this is OK (whether it is a good design choice is another thing, I will
think about that).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31358
[Bug libfortran/31299] Use getpwuid(geteuid()) instead of getlogin() for GETLOG()
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2007-03-26 10:33 --- Below is a patch to use geteuid() and getpwuid(). One minor thing is that linking with glibc now warns at compile time for static linking: ../../../../trunk/libgfortran/intrinsics/getlog.c:97: warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking I find this warning a bit annoying, as it's not clear for users where it comes from. Anyway, the patch itself is: Index: intrinsics/getlog.c === --- intrinsics/getlog.c (revision 123093) +++ intrinsics/getlog.c (working copy) @@ -37,8 +37,13 @@ #ifdef HAVE_UNISTD_H #include #endif +#ifdef HAVE_SYS_TYPES_H +#include +#endif +#ifdef HAVE_PWD_H +#include +#endif - /* Windows32 version */ #if defined __MINGW32__ && !defined HAVE_GETLOGIN #define WIN32_LEAN_AND_MEAN @@ -66,7 +71,18 @@ process. CHARACTER(len=*), INTENT(OUT) :: LOGIN */ -#ifdef HAVE_GETLOGIN +#if (defined(HAVE_GETPWUID) && defined(HAVE_GETEUID)) || defined(HAVE_GETLOGIN) + +#if defined(HAVE_GETPWUID) && defined(HAVE_GETEUID) +# define GETLOG (getpwuid(geteuid())->pw_name) +#else +# ifdef HAVE_GETLOGIN +# define GETLOG (getlogin()) +# else +# error "How on earth did we get here?" +# endif +#endif + void PREFIX(getlog) (char *, gfc_charlen_type); export_proto_np(PREFIX(getlog)); @@ -78,7 +94,7 @@ memset (login, ' ', login_len); /* Blank the string. */ - p = getlogin (); + p = GETLOG; if (p == NULL) return; Index: configure.ac === --- configure.ac(revision 123094) +++ configure.ac(working copy) @@ -164,7 +164,7 @@ AC_HAVE_HEADERS(stdlib.h stdio.h string.h stddef.h math.h unistd.h signal.h) AC_CHECK_HEADERS(time.h sys/params.h sys/time.h sys/times.h sys/resource.h) AC_CHECK_HEADERS(sys/types.h sys/stat.h sys/wait.h floatingpoint.h ieeefp.h) -AC_CHECK_HEADERS(fenv.h fptrap.h float.h execinfo.h) +AC_CHECK_HEADERS(fenv.h fptrap.h float.h execinfo.h pwd.h) AC_CHECK_HEADER([complex.h],[AC_DEFINE([HAVE_COMPLEX_H], [1], [complex.h exists])]) GCC_HEADER_STDINT(gstdint.h) @@ -177,7 +177,7 @@ AC_CHECK_FUNCS(chdir strerror getlogin gethostname kill link symlink perror) AC_CHECK_FUNCS(sleep time ttyname signal alarm ctime clock access fork execl) AC_CHECK_FUNCS(wait setmode execvp pipe dup2 close fdopen strcasestr getrlimit) -AC_CHECK_FUNCS(gettimeofday) +AC_CHECK_FUNCS(gettimeofday getpwuid) # Check for glibc backtrace functions AC_CHECK_FUNCS(backtrace backtrace_symbols) @@ -190,6 +190,7 @@ AC_CHECK_LIB([c],[getpid],[AC_DEFINE([HAVE_GETPID],[1],[libc includes getpid])]) AC_CHECK_LIB([c],[getppid],[AC_DEFINE([HAVE_GETPPID],[1],[libc includes getppid])]) AC_CHECK_LIB([c],[getuid],[AC_DEFINE([HAVE_GETUID],[1],[libc includes getuid])]) +AC_CHECK_LIB([c],[geteuid],[AC_DEFINE([HAVE_GETEUID],[1],[libc includes geteuid])]) # Check for C99 (and other IEEE) math functions # ??? This list seems awful long. Is there a better way to test for these? -- 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=31299
[Bug c/31361] SSE2 generation bug with shifts
--- Comment #2 from prakash at punnoor dot de 2007-03-26 10:53 --- Uhm, looking at the docs again, I am not so sure whether I understood the shift instructions correctly. It seems I cannot shift the (in this case) 32 bit portions individually? Rather the second operand to psrld has to be seen as a 128bit value instead of 4 32bit values? Then my code is buggy. But anyway I am still wondering why -O0 and -O1 are giving different results though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31361
[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)
--- Comment #12 from pault at gcc dot gnu dot org 2007-03-26 11:37 --- (In reply to comment #11) > (In reply to comment #10) > Do you have any idea what I cold do to turn this into an array? > All the "interesting" gfc_conv_intrinsic_* functions have the > "if (se->ss)" statement on top. I'll put my thinking cap on. To first order, you have to follow the same route as array_transfer. I'll come back to you. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067
[Bug target/31344] [4.3 regression] Bootstrap failure to compile decLibrary.c
-- fxcoudert 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-03-26 11:55:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31344
[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)
--- Comment #13 from pault at gcc dot gnu dot org 2007-03-26 12:43 ---
(In reply to comment #11)
> (In reply to comment #10)
Thomas,
It does not look too bad:
Look at the tail end of array_transfer -
gfc_trans_create_temp_array (&se->pre, &se->post, se->loop,
info, mold_type, false, true, false);
/* Cast the pointer to the result. */
tmp = gfc_conv_descriptor_data_get (info->descriptor);
Will produce a temporary array of the right dimension, together with its
descriptor.
For minmaxloc, mold_type will have to be replaced by the TREE_TYPE of the
result (gfc_array_index_type, I suppose? or else, you will have to use
gfc_typenode_for_spec (&expr->ts);, I think). tmp will now be a pointer to your
result array. This needs to appear fairly early on in minmaxloc, so that the
array can be set to zero to initialize it and so that the location can be
tranferred to it. The standard checks will have to be made that ss->loop
exists etc.. - just check some of the other array valued in-line intrinsics.
Having done this, you will need to replace the line (~2049), folowing "remember
where we are", with a loop over the n dimensions (note, we do not have to
restrict ourselves to one dimension:) ).
Something like:
/* Remember where we are. */
for (n = 0; n < loop.dimen; n++)
{
pos = build_fold_indirect_ref (gfc_conv_array_data info->descriptor));
pos = gfc_build_array_ref (pos, build_int_cst (gfc_array_index_type, n))
gfc_add_modify_expr (&ifblock, pos, loop.loopvar[n]);
}
should bang the position into the result array, which is transferred at the end
with
se->expr = info->descriptor;
Good luck
Cheers
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067
[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF
--- Comment #32 from jv244 at cam dot ac dot uk 2007-03-26 13:15 --- > Unfortunately I don't > have the SPEC test case to see to try to weed this out. have a look a comment #24 the sources are actually available -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
[Bug c++/31300] undetected class name clash
--- Comment #8 from thierry dot galas at med dot ge dot com 2007-03-26 13:56 --- Subject: Re: undetected class name clash Thanks for the explanation, I agree that it is hard to detect for a compiler to detect ODL violation, especially if we want to exclude from ODL local classes outside anonymous namespace, but I guess it could be possible at link time, as it is already the case for C symbols. There is already patent about this : http://www.freepatentsonline.com/6149318.html I understand that this is not an easy task, but if we are not able to do this we are dealing with a situation poorer than in C after telling to people, C++ is great, thanks to name mangling, we have safe linkage, then we are not able to detect double definitions, that are tricky to detect especially on large projects where they are likely to occur. Thanks, Thierry bangerth at dealii dot org wrote: > --- Comment #7 from bangerth at dealii dot org 2007-03-23 02:13 --- > (In reply to comment #4) > >> I agree , sure it is invalid ,(no mine at the root) but a diagnostic >> would be nice >> > > It is very hard for a compiler to detect this because it only sees that there > is a class 'T'. The compiler would need to know whether the declaration > came from a header file that both .cc files include or was truly meant to > be a local class. > > W. > > > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31300
[Bug other/31359] 4.2 branch still generates abort for function casting
--- Comment #3 from dirtyepic at gentoo dot org 2007-03-26 14:27 --- All true. But this report is not about openssl, it's about GCC purposely going out of it's way to break undefined code for no good reason. It does silently crash, for all intents and purposes. I'm not saying that's not a valid action for undefined code, just that it was decided that was a Bad Thing and would be changed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31359
[Bug c/31362] New: gcc should not inline functions with 'section' attribute
gcc should never inline functions which have a 'section' attribute set
on them.
If the section is placed at a specific location in memory via a linker
script, then the function will not be placed into its correct address,
and the resultant executable is incorrect.
gcc 4.1.1 will inline static function at -O1 and -O2, but not -O0 and
-O3; this can be seen by compiling the attached test program at
various optimization levels.
static int __attribute__((section(".special_section")))
special_function_0(void)
{
return 0;
}
int __attribute__((section(".special_section")))
special_function_1(void)
{
return 0;
}
int main(void)
{
special_function_0();
special_function_1();
return 0;
}
--
Summary: gcc should not inline functions with 'section' attribute
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: thutt at vmware dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31362
[Bug c/31362] gcc should not inline functions with 'section' attribute
--- Comment #1 from thutt at vmware dot com 2007-03-26 15:08 --- Created an attachment (id=13288) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13288&action=view) Simple Script which will build the original C source Simple Script which will build the original C source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31362
[Bug c/31362] gcc should not inline functions with 'section' attribute
--- Comment #2 from thutt at vmware dot com 2007-03-26 15:09 --- Created an attachment (id=13289) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13289&action=view) original source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31362
[Bug c/31362] gcc should not inline functions with 'section' attribute
--- Comment #3 from thutt at vmware dot com 2007-03-26 15:09 --- Created an attachment (id=13290) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13290&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31362
[Bug other/31363] New: long long optimization problem
gcc version 4.0.4
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/var/tmp
compiling with "-O" on input:
void
foo(unsigned long long c)
{
if (c & 0x8000)
puts("bug");
}
int
main(void)
{
foo(0x1ULL);
return 0;
}
produces "bug". Without "-O", it does not.
--
Summary: long long optimization problem
Product: gcc
Version: 4.0.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gr at collax dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31363
[Bug c++/31300] undetected class name clash
--- Comment #9 from bangerth at dealii dot org 2007-03-26 15:17 --- (In reply to comment #8) > but I guess it could be possible at link time, as it is already the case > for C symbols. We also don't do that in C: if you have two functions of the same name defined in two different .c files and link the result together, there is no guarantee which one is going to be called unless you marked the functions as static. > There is already patent about this : > http://www.freepatentsonline.com/6149318.html As always in free software, you're welcome to implement those suggestions in gcc and contribute the results back to the project. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31300
[Bug c/31362] gcc should not inline functions with 'section' attribute
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-03-26 15:11 --- If it is incorrect to inline a function you should specify that with __attribute__((noinline)), I don't see why in general inlining a function which out of line copy is in a special section is wrong. -- 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=31362
[Bug c/31362] gcc should not inline functions with 'section' attribute
--- Comment #5 from thutt at vmware dot com 2007-03-26 15:40 --- I'm going to argue that comment #4 is incorrect. 1. This new behavior is a regression from previous versions of gcc. 2. The 4.1.1 compiler gets it right at -O0 and -O3. Previous versions of gcc which we've been using also get this right at all optimization levels. 3. The function is 'static', not '__attribute__((inline))'. The use of static doesn't implicitly give the optimizer permission to inline the function, it only declares the linkage to be 'internal'. However, if the compiler determines that the function meets certain criteria, such as being static and not having its address taken, then it *can* inline it. These 'certain criteria' should be expanded to include changing the section of a function; if it's not in the default text section, it shouldn't be inlined. (Of course, this shouldn't impact gcc's internal garbage collection mechanism of changing function & data sections). In the actual implementation from which this test case was derived, the function *must* reside at a specific location in memory, but due to the inlining, it does not. This causes failures in the application. -- thutt at vmware dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31362
[Bug c/31362] gcc should not inline functions with 'section' attribute
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-03-26 15:47 --- In the actual implementation from which this test case was derived, the function *must* reside at a specific location in memory, but due to the inlining, it does not. This causes failures in the application. You should tell the compiler this. This is exactly what we have the noinline and the always_inline (for the opposite case) attributes for. Note that 'inline' is a mere hint to the compiler, the compiler is free to inline functions not marked as such if it is possible and looks profitable. You could for example put a function in section .text.hot but of course still want inlining if possible. The behavior is not a regression really, as it is not documented that the section attribute prevents inlining. Overloading the section attribute with this additional restriction does not look right. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31362
[Bug c/31362] gcc should not inline functions with 'section' attribute
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-03-26 15:51 --- Note that for your testcase even if you specify the noinline attribute the function calls will be optimized away as the function calls do not have side-effects. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31362
[Bug c/31362] gcc should not inline functions with 'section' attribute
--- Comment #8 from thutt at vmware dot com 2007-03-26 15:57 --- Furthermore, 4. By placing the code in a different section, I'm instructing the the compiler to *not* put it in '.text'. By inlining it, it places it in '.text' despite my instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31362
[Bug c/31362] gcc should not inline functions with 'section' attribute
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-03-26 16:28 --- We inline static functions used once (special_function_0 in your testcase) starting with the tree inliner which appeared in 3.4.0. So the "bug" is present in all releases starting from 3.4.0 and still present in mainline. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||3.4.0 4.3.0 Known to work||3.3.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31362
[Bug fortran/20851] dummy argument may not appear in specification expression in elemental procedure
--- Comment #2 from tobi at gcc dot gnu dot org 2007-03-26 16:43 --- This is one of the additional constraints given in 12.7.1 of the F95 standard: A dummy argument, or a subobject thereof, shall not appear in aspecification-expr except as the argument to one of the intrinsic functions BIT_SIZE, KIND, LEN, or the numeric inquiry functions (13.11.8). The functions in 13.11.8 are: DIGITS, EPSILON, HUGE, MAXEXPONENT, MINEXPONENT, PRECISION, RADIX, RANGE, TINY. -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20851
[Bug other/31363] long long optimization problem
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-26 16:43 --- Works for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31363
[Bug target/31364] New: [4.3 Regression] ICE in extract_insn, at recog.c:2119 during bootstrap
I get the following ICE during bootstrap on powerpc with current SVN (revision
123217):
(sid)227:[EMAIL PROTECTED]: ..build/powerpc-linux-gnu/64]
/home/tbm/build/gcc-snapshot-20070326/build/./gcc/xgcc
-B/home/tbm/build/gcc-snapshot-20070326/build/./gcc/
-B/usr/lib/gcc-snapshot/powerpc-linux-gnu/bin/
-B/usr/lib/gcc-snapshot/powerpc-linux-gnu/lib/ -isystem
/usr/lib/gcc-snapshot/powerpc-linux-gnu/include -isystem
/usr/lib/gcc-snapshot/powerpc-linux-gnu/sys-include -g -fkeep-inline-functions
-DIN_GCC-isystem ./include -fPIC -I. -I. -I../.././gcc
-I../../../src/libgcc -I../../../src/libgcc/. -I../../../src/libgcc/../gcc
-I../../../src/libgcc/../include -I../../../src/libgcc/../libdecnumber/dpd
-I../../../src/libgcc/../libdecnumber -I../../libdecnumber -o _subvsi3.o
-DL_subvsi3 -c ../../../src/libgcc/../gcc/libgcc2.c
../../../src/libgcc/../gcc/libgcc2.c: In function '__subvsi3':
../../../src/libgcc/../gcc/libgcc2.c:131: error: unrecognizable insn:
(call_insn 42 40 43 7 ../../../src/libgcc/../gcc/libgcc2.c:128 (parallel [
(call (mem:SI (symbol_ref:SI ("abort") [flags 0x41] ) [0 S4 A8])
(const_int 0 [0x0]))
(use (const_int 0 [0x0]))
(clobber (scratch:SI))
]) -1 (nil)
(expr_list:REG_NORETURN (const_int 0 [0x0])
(expr_list:REG_EH_REGION (const_int 0 [0x0])
(nil)))
(expr_list:REG_DEP_TRUE (use (reg:SI 30 30))
(nil)))
../../../src/libgcc/../gcc/libgcc2.c:131: internal compiler error: in
extract_insn, at recog.c:2119
Please submit a full bug report,
--
Summary: [4.3 Regression] ICE in extract_insn, at recog.c:2119
during bootstrap
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com
GCC target triplet: powerpc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31364
[Bug middle-end/28071] [4.1 regression] A file that can not be compiled in reasonable time/space
--- Comment #62 from bonzini at gnu dot org 2007-03-26 16:50 --- dataflow branch cannot complete this at -O3 -fno-tree-pre -fno-tree-fre -- bonzini at gnu dot org changed: What|Removed |Added CC||zadeck at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug rtl-optimization/31360] [4.3 Regression] rtl loop invariant is broken
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-26 16:51 --- > I guess the cost of loading zero is cheaper then? Cheaper than loading 0xDEADBEEF but not cheap enough not to pull out of the loop. All the "easy" (one instruction) constants are not pulled out. Really I think rtl loop invariant should pull everything it can pull out of the loop and then let the RA "fix" up the loop when it runs out of registers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
[Bug target/31364] [4.3 Regression] ICE in extract_insn, at recog.c:2119 during bootstrap
--- Comment #1 from tbm at cyrius dot com 2007-03-26 16:51 ---
Reduced testcase, you need -fPIC:
struct _pthread_fastlock
{
}
pthread_mutexattr_t;
extern void abort (void) __attribute__ ((__nothrow__))
__attribute__ ((__noreturn__));
typedef int SItype __attribute__ ((mode (SI)));
__subvsi3 (SItype a, SItype b)
{
abort ();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31364
[Bug target/31364] [4.3 Regression] ICE in extract_insn, at recog.c:2119 during bootstrap
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31364
[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF
--- Comment #33 from spark at gcc dot gnu dot org 2007-03-26 16:54 --- (In reply to comment #31) > Here is a new patch. I need someone to test on SPEC. It is very simple. > > Index: transfer.c > === > *** transfer.c (revision 123205) > --- transfer.c (working copy) > *** next_record_r (st_parameter_dt *dtp) > *** 2228,2234 > break; > } > > ! if (dtp->u.p.current_unit->flags.access == ACCESS_SEQUENTIAL) > test_endfile (dtp->u.p.current_unit); > } > > --- 2228,2235 > break; > } > > ! if (dtp->u.p.current_unit->flags.access == ACCESS_SEQUENTIAL > ! && !dtp->u.p.namelist_mode) > test_endfile (dtp->u.p.current_unit); > } This patch doesn't break 200.sixtrack (when added on top of the Jerry's previous patch above). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
[Bug target/31364] [4.3 Regression] ICE in extract_insn, at recog.c:2119 during bootstrap
--- Comment #2 from tbm at cyrius dot com 2007-03-26 16:55 ---
Further reduced (-fPIC):
__subvsi3 ()
{
abort ();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31364
[Bug c/31362] gcc should not inline functions with 'section' attribute
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-03-26 16:58 --- And now there is already an option to stop this inlining static functions called once. http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-finline_002dfunctions_002dcalled_002donce-507 -- 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=31362
[Bug c/31362] gcc should not inline functions with 'section' attribute
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-03-26 17:02 --- 4.1.2 also inlines the other one, so that won't help. Still noinline will. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31362
[Bug java/31365] New: private methods given vtable slots
Right now gcj will make a vtable slot for a non-static private method. We speculate that this is done for CNI. However, there's no point to a private method having a vtable slot, since private methods are never inherited. Ideally both gcj and g++ would emit calls to private methods directly (not via the vtable). This may mean that private methods will have to check for this==null, or perhaps their callers will (the latter may be preferable since most calls will be on 'this', and thus the check can be removed). link.cc already omits private methods from the constructed vtables. -- Summary: private methods given vtable slots Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tromey at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31365
[Bug other/31359] 4.2 branch still generates abort for function casting
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-26 17:18 --- > It does silently crash, for all intents and purposes. No, it is not silent at all, it warns loudly (you cannot turn off the warning except by using -w). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31359
[Bug fortran/31366] New: When the last record written to a direct access file is shorter than the record length of the file, gfortran truncates the record
When the last record written to a direct access file is shorter than the record length of the file, gfortran truncates the record. The following test program produces a file whose length is 1 when it should be 10. PROGRAM test OPEN (76, FILE="test.txt", ACCESS="DIRECT", STATUS="NEW", RECL=10) WRITE(76, REC=1) "1" END PROGRAM test -- Summary: When the last record written to a direct access file is shorter than the record length of the file, gfortran truncates the record Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michael dot a dot richmond at nasa dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31366
[Bug tree-optimization/31358] IV-OPTs produces a weird MEM_REF
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-26 17:35 --- Even if this MEM is ok, we still get bad results as we have *(a+b-4) inside the loop now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31358
[Bug c/31362] gcc should not inline functions with 'section' attribute
--- Comment #12 from thutt at vmware dot com 2007-03-26 17:46 --- I respectfully submit that I think you guys are missing the point. The problem isn't that the compiler is inlining functions which are called once, the problem is that the compiler is inlining a function which I told it not to put into the '.text' section. I fully understand that there are many ways to make gcc *not* inline the function (noinline attribute, not static, call more than once, take it's address), and I've already done that. If I tell gcc to place code or data into another section, then it should do that -- always. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31362
[Bug tree-optimization/31345] [4.3 Regression] ICE in set_value_range, at tree-vrp.c:269
--- Comment #4 from ian at airs dot com 2007-03-26 17:57 --- I'm continuing to look into the best way to avoid the compiler crash. I want to note that this code is being clobbered by undefined signed overflow. Computing (19780211 + [-128,127]) * 43321879 is always going to overflow, so VRP is converting that into hash = INT_MAX. That is almost certainly not what is intended. This is independent of my -Wstrict-overflow work, although my -Wstrict-overflow work is indeed causing the compiler crash. -- ian at airs dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ian at airs dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-03-25 12:37:51 |2007-03-26 17:57:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31345
[Bug rtl-optimization/31360] [4.3 Regression] rtl loop invariant is broken
--- Comment #4 from rakdver at atrey dot karlin dot mff dot cuni dot cz 2007-03-26 18:00 --- Subject: Re: [4.3 Regression] rtl loop invariant is broken > > I guess the cost of loading zero is cheaper then? > > Cheaper than loading 0xDEADBEEF but not cheap enough not to pull out of the > loop. All the "easy" (one instruction) constants are not pulled out. > > Really I think rtl loop invariant should pull everything it can pull out of > the > loop and then let the RA "fix" up the loop when it runs out of registers. I would agree, if we had RA capable of that (which I am not quite sure whether we do or not, although this seems simple enough), or better, RA doing better job under high register pressure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
[Bug c++/31268] Non-deterministic bug producing a run-time infinite loop
--- Comment #10 from sylvain dot pion at sophia dot inria dot fr 2007-03-26 18:03 --- Let me mention that this is against 4.2. The trunk works well for me. I tried several times during March (including today), and the bug is still here. Note that varrying the conditions slightly (even removing an innocent unused typedef) makes it work, so I'm not surprised that testing on x86_64 or powerpc makes it also work. It sounds like usage of uninitialized memory or some bad non-deterministic bug of this kind, although a quick test with valgrind did not show anything. Here are more details about my configuration: Fedora Core 5 on x86, compiler built with: > .../g++ -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /proj/geometrica/home/GCC/gcc-4_2-branch/configure --disable-shared --disable-nls --enable-languages=c++ --prefix=/proj/geometrica/home/GCC/Linux-fc5-4.2 Thread model: posix gcc version 4.2.0 20070324 (prerelease) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31268
[Bug rtl-optimization/31360] [4.3 Regression] rtl loop invariant is broken
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-03-26 18:09 --- > I would agree, if we had RA capable of that (which I am not quite sure > whether we do or not, although this seems simple enough), or better, > RA doing better job under high register pressure. Then how do you explain why loop.c pulled this out of the loop but the new rtl loop invariant does not? I don't see why we should care about register pressure except inside the RA. Every other compiler does it that way, plus they work better than GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
[Bug c/31362] gcc should not inline functions with 'section' attribute
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-03-26 18:10 --- Why do you think sections are special? GCC does not know if a section is special or not and it really should not know. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31362
[Bug rtl-optimization/31360] [4.3 Regression] rtl loop invariant is broken
--- Comment #6 from rakdver at atrey dot karlin dot mff dot cuni dot cz 2007-03-26 18:18 --- Subject: Re: [4.3 Regression] rtl loop invariant is broken > > I would agree, if we had RA capable of that (which I am not quite sure > > whether we do or not, although this seems simple enough), or better, > > RA doing better job under high register pressure. > > Then how do you explain why loop.c pulled this out of the loop but the new rtl > loop invariant does not? I don't see why we should care about register > pressure except inside the RA. Every other compiler does it that way, plus > they work better than GCC. some citation (on both claims)? Of course, it is straightforward to remove the register pressure checks from the optimizers, so if you want, you can experiment with that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
[Bug tree-optimization/31345] [4.3 Regression] ICE in set_value_range, at tree-vrp.c:269
--- Comment #5 from ian at airs dot com 2007-03-26 18:27 ---
I'm testing this patch.
Index: tree-vrp.c
===
--- tree-vrp.c (revision 123218)
+++ tree-vrp.c (working copy)
@@ -1982,10 +1982,18 @@ extract_range_from_binary_expr (value_ra
return;
}
+ /* We punt if:
+ 1) [-INF, +INF]
+ 2) [-INF, +-INF(OVF)]
+ 3) [+-INF(OVF), +INF]
+ 4) [+-INF(OVF), +-INF(OVF)]
+ We learn nothing when we have INF and INF(OVF) on both sides.
+ Note that we do accept [-INF, -INF] and [+INF, +INF] without
+ overflow. */
if ((min == TYPE_MIN_VALUE (TREE_TYPE (min))
- || is_negative_overflow_infinity (min))
+ || is_overflow_infinity (min))
&& (max == TYPE_MAX_VALUE (TREE_TYPE (max))
- || is_positive_overflow_infinity (max)))
+ || is_overflow_infinity (max)))
{
set_value_range_to_varying (vr);
return;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31345
[Bug target/31344] [4.3 regression] Bootstrap failure to compile decLibrary.c
--- Comment #9 from hjl at lucon dot org 2007-03-26 18:37 --- Any tuning target doesn't set x86_accumulate_outgoing_args will fail. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31344
[Bug c/31362] gcc should not inline functions with 'section' attribute
--- Comment #14 from thutt at vmware dot com 2007-03-26 18:54 ---
> Why do you think sections are special?
> GCC does not know if a section is special or not and it really should not
> know.
I don't necessarily think that sections are 'special', but since gcc
has the capability to change the section, it seems like it ought to
follow instructions.
If that's not convincing enough, let me quote from the gcc 'info' page
about function attributes:
`section ("SECTION-NAME")'
Normally, the compiler places the code it generates in the
`text' section. Sometimes, however, you need additional
sections, or you need certain particular functions to appear
in special sections. The `section' attribute specifies that
a function lives in a particular section. For example, the
declaration:
extern void foobar (void) __attribute__ ((section ("bar")));
puts the function `foobar' in the `bar' section.
Some file formats do not support arbitrary sections so the
`section' attribute is not available on all platforms. If
you need to map the entire contents of a module to a
particular section, consider using the facilities of the
linker instead.
I don't think that I can be more clear than this text -- placing an
__attribute__(section ("bar")) will place the attributed function into
the 'bar' section.
By inlining the function, it's *not* placing it into the 'bar'
section.
There are many reasons why a function might need to be placed into a
special section but those reasons are really moot since the
documentation of the compiler states exactly what the section attribute
is supposed to do.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31362
[Bug target/31363] long long optimization problem
--- Comment #2 from gr at collax dot com 2007-03-26 19:03 --- (In reply to comment #1) > Works for me. Hm. Just to be completely sure, my source archive gcc-4.0.4.tar.bz2 has md5sum 8970debbc55bea85ee80961d733080f0, as two other copies fetched from different mirrors. I compiled it on two different i386 Linux distributions, getting the same result in both cases. The generated assembler code in question is foo: pushl %ebp movl%esp, %ebp subl$8, %esp movl8(%ebp), %eax movl12(%ebp), %edx andl$-2147483648, %eax movl%edx, %ecx orl %eax, %ecx je .L4 movl$.LC0, (%esp) callputs .L4: leave ret If I understand this correctly, the upper half of the long long, in %edx, remains unaltered but is ORed into the value that is finally tested. What conditions could have lead to different results here? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31363
[Bug target/31363] long long optimization problem
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-26 19:09 --- I could reproduce this with "4.0.4 20060622" but it works on the trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31363
[Bug target/31361] SSE2 generation bug with shifts
--- Comment #3 from rth at gcc dot gnu dot org 2007-03-26 19:14 --- Confirmed. We've modeled the instruction incorrectly; it takes the shift count from the entire 128-bit xmm register, not the low 32 or 8 bits. -- rth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Component|c |target Ever Confirmed|0 |1 GCC build triplet|x86_64 | GCC host triplet|x86_64 | GCC target triplet|x86_64 |i386-* Last reconfirmed|-00-00 00:00:00 |2007-03-26 19:14:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31361
[Bug libgcj/30999] support for GCC4.0's fvisibility option in JNIEXPORT macro
--- Comment #2 from tromey at gcc dot gnu dot org 2007-03-26 19:27 --- This seems reasonable to me. Could you write a ChangeLog entry and submit the patch to [EMAIL PROTECTED] -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-26 19:27:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30999
[Bug target/31344] [4.3] dfp isn't properly supported on x86
--- Comment #10 from hjl at lucon dot org 2007-03-26 19:30 --- I think dfp should be disabled by default on x86. We are missing patterns for "movsd", "movdd", and maybe "movtd". -- hjl at lucon dot org changed: What|Removed |Added Summary|[4.3 regression] Bootstrap |[4.3] dfp isn't properly |failure to compile |supported on x86 |decLibrary.c| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31344
[Bug c++/31367] New: Should not warn about use of deprecated type in deprecated struct
When a deprecated type is used in a struct which is itself deprecated, we
should not warn. That would be consistent with the current behaviour of not
warning about applying a deprecated type to a deprecated variable.
Test case:
typedef __attribute__((deprecated)) int foo;
typedef __attribute__((deprecated)) struct bar {
foo baz;
} bop;
With current mainline this gives
foo.cc:3: warning: foo is deprecated
It should not give any warning.
--
Summary: Should not warn about use of deprecated type in
deprecated struct
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31367
[Bug target/31344] [4.3 regression] Bootstrap failure to compile decLibrary.c
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-03-26 19:39 --- The ICE is still a bug which needs to be fixed Plus this is still a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3] dfp isn't properly|[4.3 regression] Bootstrap |supported on x86|failure to compile ||decLibrary.c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31344
[Bug c/31367] Should not warn about use of deprecated type in deprecated struct
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-26 19:42 --- Confirmed, the C front-end also gives the warning. [EMAIL PROTECTED]:~$ ~/x86-local-fsf/bin/gcc t.c -S t.c:4: warning: 'foo' is deprecated -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c++ |c Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2007-03-26 19:42:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31367
[Bug target/31344] [4.2/4.3]: DFP isn't properly supported on x86
--- Comment #12 from hjl at lucon dot org 2007-03-26 19:56 --- (In reply to comment #11) > The ICE is still a bug which needs to be fixed Plus this is still a > regression. > Failing to compile this code isn't a regression since the same code always fails with gcc 4.2 and 4.3 when DFP is enabled. The difference is DFP was disabled by default before. That is why people didn't see it. Now DFP is enabled by default on x86 and people start seeing it. -- hjl at lucon dot org changed: What|Removed |Added Summary|[4.3 regression] Bootstrap |[4.2/4.3]: DFP isn't |failure to compile |properly supported on x86 |decLibrary.c| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31344
[Bug target/31344] [4.3 Regression]: DFP isn't properly supported on x86
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-03-26 20:04 --- The build failure is still a regression, no matter which you look at it. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.2/4.3]: DFP isn't |[4.3 Regression]: DFP isn't |properly supported on x86 |properly supported on x86 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31344
[Bug c/31362] gcc should not inline functions with 'section' attribute
--- Comment #15 from eweddington at cso dot atmel dot com 2007-03-26 20:22 --- FWIW, I agree with the OP. This will place a burden on users who work with embedded systems such as the AVR. Special sections are sometimes needed in the AVR to place code into a special bootloader area that gets relocated at link time to a user defined address. Many times there is only a single function call to the bootloader code. As the problem is described, there is a potential that the bootloader call would be inlined, hence no longer properly in the section that has to be relocated to a special address. Now the burden will be left to the end user to figure out that they need to add noinline to work around a too aggressive, and too stupid inliner. -- eweddington at cso dot atmel dot com changed: What|Removed |Added CC||eweddington at cso dot atmel ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31362
[Bug target/31344] [4.3 Regression]: DFP isn't properly supported on x86
--- Comment #14 from hjl at lucon dot org 2007-03-26 20:41 ---
This isn't a real patch. But it seems to work on the testcase.
--- i386.md.dfp 2007-03-24 12:21:45.0 -0700
+++ i386.md 2007-03-26 12:30:21.0 -0700
@@ -1850,6 +1850,59 @@
""
"ix86_expand_move (DImode, operands); DONE;")
+(define_expand "movsd"
+ [(set (match_operand:SD 0 "nonimmediate_operand" "")
+ (match_operand:SD 1 "general_operand" ""))]
+ ""
+ "ix86_expand_move (SDmode, operands); DONE;")
+
+(define_insn "*pushsd2"
+ [(set (match_operand:SD 0 "push_operand" "=<")
+ (match_operand:SD 1 "general_no_elim_operand" "ri*m"))]
+ "!TARGET_64BIT"
+ "push{l}\t%1"
+ [(set_attr "type" "push")
+ (set_attr "mode" "SI")])
+
+;; For 64BIT abi we always round up to 8 bytes.
+(define_insn "*pushsd2_rex64"
+ [(set (match_operand:SD 0 "push_operand" "=X")
+ (match_operand:SD 1 "nonmemory_no_elim_operand" "ri"))]
+ "TARGET_64BIT"
+ "push{q}\t%q1"
+ [(set_attr "type" "push")
+ (set_attr "mode" "SI")])
+
+(define_expand "movdd"
+ [(set (match_operand:DD 0 "nonimmediate_operand" "")
+ (match_operand:DD 1 "general_operand" ""))]
+ ""
+ "ix86_expand_move (DDmode, operands); DONE;")
+
+(define_insn "*pushdd"
+ [(set (match_operand:DD 0 "push_operand" "=<")
+ (match_operand:DD 1 "general_no_elim_operand" "riF*m"))]
+ "!TARGET_64BIT"
+ "#")
+
+(define_insn "*pushdd2_rex64"
+ [(set (match_operand:DD 0 "push_operand" "=<,!<")
+ (match_operand:DD 1 "general_no_elim_operand" "re*m,n"))]
+ "TARGET_64BIT"
+ "@
+ push{q}\t%1
+ #"
+ [(set_attr "type" "push,multi")
+ (set_attr "mode" "DI")])
+
+(define_split
+ [(set (match_operand:DD 0 "push_operand" "")
+(match_operand:DD 1 "general_operand" ""))]
+ "!TARGET_64BIT && reload_completed
+ && (! MMX_REG_P (operands[1]) && !SSE_REG_P (operands[1]))"
+ [(const_int 0)]
+ "ix86_split_long_move (operands); DONE;")
+
(define_insn "*pushdi"
[(set (match_operand:DI 0 "push_operand" "=<")
(match_operand:DI 1 "general_no_elim_operand" "riF*m"))]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31344
[Bug c++/31330] small template-use example crashes g++ w/internal error
--- Comment #2 from bangerth at dealii dot org 2007-03-26 20:44 --- Yes, indeed. *** This bug has been marked as a duplicate of 27102 *** -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31330
[Bug c++/27102] [4.0/4.1 regression] ICE with invalid class name in function template
--- Comment #17 from bangerth at dealii dot org 2007-03-26 20:44 --- *** Bug 31330 has been marked as a duplicate of this bug. *** -- bangerth at dealii dot org changed: What|Removed |Added CC||ilya at broad dot mit dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27102
[Bug c++/31323] typename A::B * p; in template definition, with curiously recurring template inheritance
--- Comment #3 from bangerth at dealii dot org 2007-03-26 20:46 ---
(In reply to comment #2)
> well, priv is a pointer..
What I really meant was a typedef:
template struct Base {
typedef typename T::X X;
};
struct A : Base
{
typedef int X;
};
But still, what part of the standard makes you think that this should be
valid code?
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31323
[Bug c++/31328] Temporary object incorrectly parsed as confilcint declaration
--- Comment #5 from bangerth at dealii dot org 2007-03-26 20:48 --- Yup, Andrew is right. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31328
[Bug testsuite/25241] DejaGNU does not distinguish between errors and warnings
--- Comment #42 from manu at gcc dot gnu dot org 2007-03-26 20:48 --- Created an attachment (id=13291) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13291&action=view) version 2 of fixtestsuite script This new version of the script makes more automatic fixes. -- manu at gcc dot gnu dot org changed: What|Removed |Added Attachment #13271|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25241
[Bug c/31362] gcc should not inline functions with 'section' attribute
--- Comment #16 from pinskia at gcc dot gnu dot org 2007-03-26 21:21 --- You supposed to mark all functions which you don't want inlined as noinline. that is what the noinline attribute is there for. The inliner is just too smart that is all. If you want a dumber inliner fine, but don't complain to us when the inliner is not as good any more. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31362
[Bug c/31367] Should not warn about use of deprecated type in deprecated struct
--- Comment #2 from david at luyer dot net 2007-03-26 21:27 ---
Two other related cases which generate warnings. I'm not sure
which is the correct syntax to mark a field deprecated, but
both are currently generating warnings, and marking a field
which uses a deprecated type as deprecated would be another
case which should not generate a warning.
=
typedef __attribute__((deprecated)) int foo;
typedef struct bar {
foo __attribute__((deprecated)) baz;
} bop;
=
typedef __attribute__((deprecated)) int foo;
typedef struct bar {
__attribute__((deprecated)) foo baz;
} bop;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31367
[Bug c/31348] Error in compilation
--- Comment #3 from dj at redhat dot com 2007-03-26 21:36 --- 30972 is Windows, this is DJGPP - different operating systems. Are you using the stock 2.03 files, or the 2.04 (beta) files? There are known incompatibilities in XP and Vista that require the 2.04 builds of the GNU tools, so if you're still using 2.03 (current), please replace them with the 2.04 (beta) versions, and try again. If 2.04 solves it, then this is not a gcc bug. -- dj at redhat dot com changed: What|Removed |Added CC||dj at redhat dot com Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31348
[Bug c++/31323] typename A::B * p; in template definition, with curiously recurring template inheritance
--- Comment #4 from mesti_mudam at yahoo dot com 2007-03-26 21:49 --- ive no idea which part of the standard should imply/allow this. if one replaces "typename T::privIC * priv" with "T * priv", its valid and it compiles. I thought T::privC is equally accessible & 'incomplete' as T itself when instantiating the template. what i want is: class A : public Base class B : public Base etc. all having the same interface, and all of them's private implementation class is called privC. so either in A, B, etc. or later i'll define class A::privC, class B::privC, etc. maybe we should add this to the standard :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31323
[Bug libstdc++/31368] New: basic_string and unsigned short leads to memory fault
Main application dynamically loads shared library and uses function from
library to fill out string. If basic_string or basic_string are
used then no problem observed. In case of basic_string
application aborts (MALLOC_CHECK_=2) with message
*** glibc detected *** free(): invalid pointer: 0x005015c0 ***
Aborted
gdb shows stack trace:
#0 0x003a79d2e2ed in raise () from /lib64/tls/libc.so.6
#1 0x003a79d2fa3e in abort () from /lib64/tls/libc.so.6
#2 0x003a79d62db1 in __libc_message () from /lib64/tls/libc.so.6
#3 0x003a79d6888e in _int_free () from /lib64/tls/libc.so.6
#4 0x003a79d68bd6 in free () from /lib64/tls/libc.so.6
#5 0x003a7ceae19e in operator delete () from /usr/lib64/libstdc++.so.6
#6 0x002a95579665 in __gnu_cxx::new_allocator::deallocate () from
./libloader.so
#7 0x002a9557954b in std::basic_string, std::allocator
>::_Rep::_M_destroy () from ./libloader.so
#8 0x002a9557908c in std::basic_string, std::allocator
>::_Rep::_M_dispose () from ./libloader.so
#9 0x002a95578e3e in std::basic_string, std::allocator >::reserve ()
from ./libloader.so
#10 0x002a95578cef in std::basic_string, std::allocator >::append ()
from ./libloader.so
#11 0x002a95578c63 in std::basic_string, std::allocator >::append ()
from ./libloader.so
#12 0x002a95578c38 in read_string () from ./libloader.so
#13 0x00400860 in main ()
The "workaround" is to add reserve(1) before passing string to function. In
this case there is no abort.
Why the behavior is different? Where is the problem?
Source code:
main.cpp
//-
#include
#include
#include "loader.h"
typedef void *pfLoader(std::ustring&);
int main(int argc, char* argv[])
{
void * libHandle = dlopen("libloader.so", RTLD_NOW|RTLD_GLOBAL);
pfLoader* pF = (pfLoader*)dlsym(libHandle, "read_string");
std::ustring s;
// s.reserve(1); // uncomment this line to prevent abort
pF(s);
return 0;
}
//-
loader.h
//-
#ifndef _LOADER_INCLUDED_
#define _LOADER_INCLUDED_
typedef unsigned short USHORT;
namespace std
{
typedef std::basic_string,
std::allocator > ustring;
}
extern "C" void read_string(std::ustring& sValue);
#endif // _RUNNER_INCLUDED_
//-
loader.cpp
//-
#include
#include "loader.h"
const USHORT _sV [] = {'T','e','s','t','\0'};
void read_string(std::ustring& sValue)
{
sValue.append(_sV);
}
//-
Build commands:
main: g++ -o main -I. -ldl main.cpp
lib: g++ -Wl,-E -fPIC -I. -shared -o libloader.so loader.cpp
Version infos:
OS:
Red Hat Enterprise Linux AS release 4 (Nahant Update 3)
Kernel \r on an \m
g++:
Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.5/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk --host=x86_64-redhat-linux
Thread model: posix
gcc version 3.4.5 20051201 (Red Hat 3.4.5-2)
glibc: 3.4
--
Summary: basic_string and unsigned short leads to memory fault
Product: gcc
Version: 3.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gregoryk at edifecs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31368
[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF
--- Comment #34 from jvdelisle at gcc dot gnu dot org 2007-03-26 21:55 --- Regarding comment 24 and 32. I have that downloaded and tried to compile and there are duplications of subroutines and multiple main programs. As I get time, I intend to get it sorted out and add it to my testing here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
[Bug libstdc++/25956] Memory error when dynamic linking STL specializations
--- Comment #2 from pcarlini at suse dot de 2007-03-26 22:08 --- The message to the libstdc++ list: http://gcc.gnu.org/ml/libstdc++/2006-01/msg00155.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25956
[Bug libstdc++/31368] basic_string and unsigned short leads to memory fault
--- Comment #1 from pcarlini at suse dot de 2007-03-26 22:10 --- Seems the same as libstdc++/25956. Can you try whether instantiating the string class at global scope works for you too: http://gcc.gnu.org/ml/libstdc++/2006-01/msg00162.html ??? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31368
[Bug rtl-optimization/31360] [4.2/4.3 Regression] rtl loop invariant is broken
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-03-26 22:11 --- Plus I just tested the 4.2 branch and it is broken there also, G. Sorry for finding this late in the release cycle but I guess nobody really looked at the code quality after loop.c was turned off and rtl loop invariant motion was turned on. -- pinskia 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-03-26 22:11:48 date|| Summary|[4.3 Regression] rtl loop |[4.2/4.3 Regression] rtl |invariant is broken |loop invariant is broken Target Milestone|4.3.0 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
[Bug rtl-optimization/31360] [4.2/4.3 Regression] rtl loop invariant is broken
--- Comment #8 from steven at gcc dot gnu dot org 2007-03-26 22:13 --- Re. comment #5 Andrew, stop spreading nonsense. Other compilers do take register pressure into account. In fact, they do so much better than GCC usually does. (In GCC you can't do it well because instructions are selected too late, so you don't know per-class register pressure). So your stupid and annoying crusade to litter every bug with an "let RA fix it" remark shoud stop, thank you very much. -- steven at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
[Bug rtl-optimization/31360] [4.2/4.3 Regression] rtl loop invariant is broken
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-03-26 22:17 --- This is still a 4.2 regression. 4.2 produces: .L2: li 0,100 stwx 0,9,3 addi 9,9,4 bdnz .L2 blr While 4.1 produces: .L2: stwx 0,9,3 addi 9,9,4 bdnz .L2 -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.3.0 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
[Bug fortran/31366] When the last record written to a direct access file is shorter than the record length of the file, gfortran truncates the record
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-03-26 22:18 --- Adding Thomas to cc. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-26 22:18:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31366
[Bug tree-optimization/31358] IV-OPTs produces a weird MEM_REF
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-26 22:27 --- 3.2.3 produced: .L6: slwi 0,9,2 add 9,9,5 cmpw 0,9,4 stwx 11,3,0 bgelr- 0 b .L6 While 4.1.0 and above produces: .L4: add 9,9,5 stw 10,-4(3) add 3,3,11 subf 0,5,9 cmpw 7,4,0 bgt 7,.L4 If we change "int *" to "char *" and set c to be 2, we get even worse code gen. 3.2.3: .L9: stbx 11,3,9 addi 9,9,2 bdnz .L9 blr 4.1.0: .L4: add 9,3,11 addi 11,11,2 cmpw 7,4,11 stb 0,-1(9) bgt 7,.L4 What happened to bdnz and we are now doing *(r9+r3-1) = r0 inside the loop? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.1.0 4.2.0 4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31358
[Bug libstdc++/31368] basic_string and unsigned short leads to memory fault
--- Comment #2 from gregoryk at edifecs dot com 2007-03-26 22:28 --- Though the problem from bug 25956 looks same the instantiating didn't help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31368
[Bug rtl-optimization/31360] [4.2/4.3 Regression] rtl loop invariant is broken
--- Comment #10 from steven at gcc dot gnu dot org 2007-03-26 22:33 ---
Just a small heuristics problem. This could be fixed by giving insns to move
with comp_cost - size_cost == 0 in gain_for_invariant a small gain anyway. Or
maybe comp_cost should overrule size_cost.
Just as a demonstration of how trivial this is, consider this hack:
Index: loop-invariant.c
===
--- loop-invariant.c(revision 123222)
+++ loop-invariant.c(working copy)
@@ -1101,8 +1101,10 @@ find_invariants_to_move (void)
}
new_regs = 0;
+
+ /* Find instructions to move. Nothing gained is nothing lost. */
while (best_gain_for_invariant (&inv, ®s_needed,
- new_regs, regs_used, n_inv_uses) > 0)
+ new_regs, regs_used, n_inv_uses) >= 0)
{
set_move_mark (inv->invno);
new_regs += regs_needed;
Looks to me like a small heuristics tweak and some benchmarking would get this
one out of the way with only a small effort.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.0 |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
[Bug rtl-optimization/31360] [4.2/4.3 Regression] rtl loop invariant is broken
--- Comment #11 from steven at gcc dot gnu dot org 2007-03-26 22:36 --- And of course the hack doesn't actually work :-) But it's still just a heuristics tweak what we need here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
[Bug rtl-optimization/31360] [4.2/4.3 Regression] rtl loop invariant is broken
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.3.0 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
[Bug rtl-optimization/31360] [4.2/4.3 Regression] rtl loop invariant is broken
--- Comment #12 from steven at gcc dot gnu dot org 2007-03-26 22:43 --- Zdenek, what is the size heuristic for anyway? For powerpc, the current heuristic tells the compiler not to move any simple moves: 1) An invariant with a gain of 0 will not be moved. 2) gain = comp_cost - size_cost 3) comp_cost of a simple move is 4 4) all powerpc instructions have a size_cost of 4 (At least, the insns that map to a single machine insns have a size_cost of 4.) So we tell the compiler never to move simple moves for powerpc :-( -- steven at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
[Bug tree-optimization/31345] [4.3 Regression] ICE in set_value_range, at tree-vrp.c:269
--- Comment #6 from ian at gcc dot gnu dot org 2007-03-26 22:43 --- Subject: Bug 31345 Author: ian Date: Mon Mar 26 22:43:30 2007 New Revision: 123237 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123237 Log: ./: PR tree-optimization/31345 * tree-vrp.c (extract_range_from_binary_expr): Turn ranges like [+INF, +INF(OVF)] into VARYING. testsuite/: PR tree-optimization/31345 * gcc.c-torture/compile/pr31345-1.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr31345-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31345
[Bug rtl-optimization/31360] [4.2/4.3 Regression] rtl loop invariant is broken
-- steven at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.3.0 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
[Bug libstdc++/31368] basic_string and unsigned short leads to memory fault
--- Comment #3 from pcarlini at suse dot de 2007-03-26 22:52 --- Ok, but before we take any further action we badly need a better reproduce: on any up to date x86 and x86-64 linux machine I tried, your testcase segfault immediately both for unsigned short and for char (and the workaround doesn't work) -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31368
[Bug c++/30500] pragma GCC system_header vs templates
--- Comment #3 from paolo at gcc dot gnu dot org 2007-03-26 22:55 --- Subject: Bug 30500 Author: paolo Date: Mon Mar 26 22:55:03 2007 New Revision: 123238 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123238 Log: 2007-03-26 Paolo Carlini <[EMAIL PROTECTED]> PR c++/30500 * pt.c (instantiate_decl): Set in_system_header. 2007-03-26 Paolo Carlini <[EMAIL PROTECTED]> PR c++/30500 * g++.dg/warn/pragma-system_header1.C: New test. * g++.dg/warn/pragma-system_header2.C: New test. * g++.dg/warn/pragma-system_header1.h. New. * g++.dg/warn/pragma-system_header2.h. New. Added: trunk/gcc/testsuite/g++.dg/warn/pragma-system_header1.C trunk/gcc/testsuite/g++.dg/warn/pragma-system_header1.h trunk/gcc/testsuite/g++.dg/warn/pragma-system_header2.C trunk/gcc/testsuite/g++.dg/warn/pragma-system_header2.h Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30500
[Bug c++/30500] pragma GCC system_header vs templates
--- Comment #4 from paolo at gcc dot gnu dot org 2007-03-26 22:55 --- Subject: Bug 30500 Author: paolo Date: Mon Mar 26 22:55:19 2007 New Revision: 123239 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123239 Log: 2007-03-26 Paolo Carlini <[EMAIL PROTECTED]> PR c++/30500 * pt.c (instantiate_decl): Set in_system_header. 2007-03-26 Paolo Carlini <[EMAIL PROTECTED]> PR c++/30500 * g++.dg/warn/pragma-system_header1.C: New test. * g++.dg/warn/pragma-system_header2.C: New test. * g++.dg/warn/pragma-system_header1.h. New. * g++.dg/warn/pragma-system_header2.h. New. Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30500
[Bug c++/30500] pragma GCC system_header vs templates
--- Comment #5 from pcarlini at suse dot de 2007-03-26 22:56 --- Fixed for 4.3.0. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30500
[Bug rtl-optimization/31360] [4.2/4.3 Regression] rtl loop invariant is broken
--- Comment #13 from rakdver at atrey dot karlin dot mff dot cuni dot cz 2007-03-26 23:05 --- Subject: Re: [4.2/4.3 Regression] rtl loop invariant is broken > Zdenek, what is the size heuristic for anyway? For powerpc, the current > heuristic tells the compiler not to move any simple moves: > > 1) An invariant with a gain of 0 will not be moved. > 2) gain = comp_cost - size_cost > 3) comp_cost of a simple move is 4 > 4) all powerpc instructions have a size_cost of 4 > > (At least, the insns that map to a single machine insns have a size_cost of > 4.) size_cost and global_cost_for_size are somewhat missnamed. The purpose of global_cost_for_size is to estimate the effect of register pressure, and it currently works this way: 1) if the number of used registers is significantly smaller than the number of available registers, then the cost for each newly used register is target_small_cost (which probably turns out to be 4 on ppc) 2) if the number of used registers approaches the number of available registers, the cost for a newly used register increases more significantly (by target_pres_cost and later by target_spill_cost). The purpose of 1) should have been to prevent optimizations that do not gain anything and increase register pressure, but apparently this does not work quite well. Two possible solutions are decreasing target_small_cost (maybe setting it fixed to one), or even removing the penalty for increasing number of used registers in the case 1) completely. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
[Bug libstdc++/31368] basic_string and unsigned short leads to memory fault
--- Comment #4 from gregoryk at edifecs dot com 2007-03-26 23:13 --- Ok. Can I help you somehow? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31368
[Bug libstdc++/31368] basic_string and unsigned short leads to memory fault
--- Comment #5 from pcarlini at suse dot de 2007-03-26 23:24 --- Yes, as I said, we need a better reproducer, that is a testcase that on most of the current x86-linux or x86-64-linux machines behaves as you are reporting: if you want to help you should look for a recent machine (e.g., glibc2.4 / 2.5, system compiler gcc 4.1.x) and refine your testcase to behave as you expect. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31368
[Bug c/31367] Should not warn about use of deprecated type in deprecated struct
--- Comment #3 from spark at gcc dot gnu dot org 2007-03-27 00:56 ---
# cat -n t.c
1 typedef __attribute__((deprecated)) int foo;
2 typedef
3 struct
4 __attribute__((deprecated))
5 bar1
6 {
7foo baz;
8 }
9 bop1;
10
11 typedef
12 __attribute__((deprecated))
13 struct
14 bar2
15 {
16foo baz;
17 } bop2;
18
19 typedef
20 struct
21 bar3
22 {
23foo baz;
24 }
25 __attribute__((deprecated))
26 bop3;
27
28 typedef
29 struct
30 bar4
31 {
32foo baz;
33 }
34 bop4
35 __attribute__((deprecated));
# ~/local/pkg/4.1/bin/gcc -c t.c
t.c:7: warning: 'foo' is deprecated
t.c:9: warning: 'bar1' is deprecated (declared at t.c:6)
t.c:16: warning: 'foo' is deprecated
t.c:23: warning: 'foo' is deprecated
t.c:26: warning: 'bar3' is deprecated (declared at t.c:22)
t.c:32: warning: 'foo' is deprecated
#
I'm not sure what to make of this,
but there seems to be some subtleties regarding
which declaration the attribute applies to.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31367
[Bug target/31361] SSE2 generation bug with shifts
--- Comment #4 from rth at gcc dot gnu dot org 2007-03-27 01:30 --- Subject: Bug 31361 Author: rth Date: Tue Mar 27 01:30:32 2007 New Revision: 123250 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123250 Log: PR target/31361 * config/i386/i386.c (IX86_BUILTIN_PSLLDQ128, IX86_BUILTIN_PSLLW128, IX86_BUILTIN_PSLLD128, IX86_BUILTIN_PSLLQ128, IX86_BUILTIN_PSRAW128, IX86_BUILTIN_PSRAD128, IX86_BUILTIN_PSRLW128, IX86_BUILTIN_PSRLD128, IX86_BUILTIN_PSRLQ128): New. (ix86_init_mmx_sse_builtins): Add them. (ix86_expand_builtin): Expand them. * config/i386/sse.md (ashr3, lshr3, ashl3): Make operand 2 be TImode. * config/i386/emmintrin.h (_mm_slli_epi64, _mm_srai_epi16, _mm_srai_epi32, _mm_srli_epi16, _mm_srli_epi32, _mm_srli_epi64): Mark __B const. (_mm_srli_si128, _mm_srli_si128): Fix disabled inline versions. (_mm_sll_epi16, _mm_sll_epi32, _mm_sll_epi64, _mm_sra_epi16, _mm_sra_epi32, _mm_srl_epi16, _mm_srl_epi32, _mm_srl_epi64): Use new two-vector shift builtins. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/emmintrin.h trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/sse.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31361
[Bug target/31361] SSE2 generation bug with shifts
--- Comment #5 from rth at gcc dot gnu dot org 2007-03-27 01:37 --- You can shift the 32-bit portions individually. But your test case will now result in 0,0,0,0 for all optimization levels, since the shift count is taken from the entire xmm register. In this case, since there is an 8 in each of the 4 32-bit portions, the shift count is extremely large. Fixed. -- rth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31361
[Bug other/31359] 4.2 branch still generates abort for function casting
--- Comment #5 from dirtyepic at gentoo dot org 2007-03-27 01:49 --- I was referring to what the user gets to experience at runtime. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31359
[Bug java/29528] [ecj] update gcjh documentation
--- Comment #1 from tromey at gcc dot gnu dot org 2007-03-27 02:44 --- Fix checked in. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 Version|4.2.0 |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29528
