[Bug fortran/27452] gfortran support for non-standard sind,cosd and friends intrinsics
--- Comment #1 from kargl at gcc dot gnu dot org 2006-05-06 06:14 --- Why? Is it that difficult to write a module to provide sind and friends? -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27452
[Bug fortran/27452] gfortran support for non-standard sind,cosd and friends intrinsics
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-06 06:22 --- In fact it is easy to divide by 90° and multiply by pi. -- 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=27452
[Bug fortran/27452] gfortran support for non-standard sind,cosd and friends intrinsics
--- Comment #3 from deji_aking at yahoo dot ca 2006-05-06 06:32 --- (In reply to comment #2) In fact it is easy to divide by 90° and multiply by pi. You just proved my point, one would want to divide by 180 and multiply by pi ;). Having sind and co safeguard against such silly mistake. fair enough, i'll continue using my self-made functions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27452
[Bug target/16322] C99 complex math functions not implemented for irix6.5
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-05-06 06:55 --- Any reason to keep this open? gfortran doesn't have a problem with irix6.5 any more, as far as I know. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16322
[Bug fortran/17298] gfortran ICE: Not Implemented: Scalarization of non-elemental intrinsic: __transfer1
--- Comment #24 from paulthomas2 at wanadoo dot fr 2006-05-06 08:02 --- Subject: Re: gfortran ICE: Not Implemented: Scalarization of non-elemental intrinsic: __transfer1 I'm unfamiliar with Bugzilla, so if I annoy anyone, apologies. You made a serious comment... you won't upset anyone! This routine is a puzzle, or else I have completely misunderstood it. The TRANSFER is obviously spurious, as it merely allows the sort of renaming that used to be possible with the deprecated EQUIVALENCE statement, were it to be allowed for parameters. This is the nub of it; like equivalence, which is still supported in gfortran, transfer effects a bitwise mapping from source to destination. But, why not dcabs1 = abs(real(z)) + abs(aimag(z)) relying on proper precision selection (or, supply d prefixes). ... whereas real and aimag do kind conversion, if it is necessary. Of course, in general the TRANSFER function should work. Best wishes, RNMcLean somewhere by yahoo.com In my opinion, real and aimag are better because they are likely to be more efficient; transfer is looking (as I well know!) to do the general case and needs to calculate source/destination sizes, whether or not they are packed and so on. Best regards Paul Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17298
[Bug gcov/profile/27453] New: gcov opens files with O_RDWR
[forwarded from http://bugs.debian.org/365123] gcov opens it's data files *.gcda and *.gcno with O_RDWR. This fails if these files were created by another user, and the current user only has read access to those files. -- Summary: gcov opens files with O_RDWR Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: gcov/profile AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: debian-gcc at lists dot debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27453
[Bug testsuite/27376] treelang testsuite fails on cygwin
--- Comment #1 from christian dot joensson at gmail dot com 2006-05-06 10:30 --- hmm, must be the EXEEXT thing -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27376
[Bug gcov/profile/27453] gcov opens files with O_RDWR
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-05-06 10:43 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Severity|minor |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-06 10:43:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27453
[Bug target/25743] crosscompiler fails to build ada-rts for target platform.
--- Comment #5 from christian dot joensson at gmail dot com 2006-05-06 10:58 --- There may be connections with this PR to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20035 especially the http://gcc.gnu.org/bugzilla/attachment.cgi?id=8217 which I would suggest be named sparc64 instead of sparcv9... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25743
[Bug c/27301] [4.0/4.1/4.2 Regression] ICE on convoluted inline asm with m (statement expression and vla)
--- Comment #4 from enrico dot scholz at informatik dot tu-chemnitz dot de
2006-05-06 11:00 ---
fwiw (I reported the issue in the RH bugzilla, which was then forwarded by
Jakub):
I toke this syntax out of the gcc documentation: info gcc - g Extended Asm
| As an example, if you access ten bytes of a string, you can use a memory
input
| like:
|
| {m( ({ struct { char x[10]; } *p = (void *)ptr ; *p; }) )}.
--
enrico dot scholz at informatik dot tu-chemnitz dot de changed:
What|Removed |Added
CC||enrico dot scholz at
||informatik dot tu-chemnitz
||dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27301
[Bug libgcj/10353] [4.0/4.1/4.2 regression] Java testsuite failures
--- Comment #26 from christian dot joensson at gmail dot com 2006-05-06 11:30 --- For sparc/sparc64 linux, the status for 4.2 20060503, from here, http://gcc.gnu.org/ml/gcc-testresults/2006-05/msg00223.html, is this: === libjava tests === Running target unix/-m64 FAIL: Array_3 execution - source compiled test FAIL: Array_3 execution - gij test FAIL: Array_3 execution - bytecode-native test FAIL: Array_3 execution - gij test FAIL: Array_3 -findirect-dispatch execution - bytecode-native test FAIL: Array_3 -O3 execution - source compiled test FAIL: Array_3 execution - gij test FAIL: Array_3 -O3 execution - bytecode-native test FAIL: Array_3 execution - gij test FAIL: Array_3 -O3 -findirect-dispatch execution - bytecode-native test FAIL: Final execution - gij test FAIL: Final execution - gij test FAIL: Final execution - gij test FAIL: Final execution - gij test FAIL: Invoke_1 execution - source compiled test FAIL: Invoke_1 execution - gij test FAIL: Invoke_1 execution - bytecode-native test FAIL: Invoke_1 execution - gij test FAIL: Invoke_1 -findirect-dispatch execution - bytecode-native test FAIL: Invoke_1 -O3 execution - source compiled test FAIL: Invoke_1 execution - gij test FAIL: Invoke_1 -O3 execution - bytecode-native test FAIL: Invoke_1 execution - gij test FAIL: Invoke_1 -O3 -findirect-dispatch execution - bytecode-native test FAIL: PR218 execution - gij test FAIL: PR218 execution - gij test FAIL: PR218 execution - gij test FAIL: PR218 execution - gij test XPASS: PR26858 execution - source compiled test XPASS: PR26858 output - source compiled test XPASS: PR26858 execution - bytecode-native test XPASS: PR26858 output - bytecode-native test XPASS: PR26858 -findirect-dispatch execution - bytecode-native test XPASS: PR26858 -findirect-dispatch output - bytecode-native test XPASS: PR26858 -O3 execution - source compiled test XPASS: PR26858 -O3 output - source compiled test XPASS: PR26858 -O3 execution - bytecode-native test XPASS: PR26858 -O3 output - bytecode-native test XPASS: PR26858 -O3 -findirect-dispatch execution - bytecode-native test XPASS: PR26858 -O3 -findirect-dispatch output - bytecode-native test FAIL: assign -findirect-dispatch execution - bytecode-native test FAIL: assign -O3 -findirect-dispatch execution - bytecode-native test FAIL: pr83 execution - gij test FAIL: pr83 execution - gij test FAIL: pr83 -findirect-dispatch execution - bytecode-native test FAIL: pr83 execution - gij test FAIL: pr83 execution - gij test FAIL: pr83 -O3 -findirect-dispatch execution - bytecode-native test FAIL: stringconst2 -findirect-dispatch output - bytecode-native test FAIL: stringconst2 -O3 -findirect-dispatch output - bytecode-native test === libjava Summary for unix/-m64 === # of expected passes6697 # of unexpected failures38 # of unexpected successes 12 # of expected failures 16 # of untested testcases 48 Running target unix XPASS: PR26858 execution - source compiled test XPASS: PR26858 output - source compiled test XPASS: PR26858 execution - bytecode-native test XPASS: PR26858 output - bytecode-native test XPASS: PR26858 -findirect-dispatch execution - bytecode-native test XPASS: PR26858 -findirect-dispatch output - bytecode-native test XPASS: PR26858 -O3 execution - source compiled test XPASS: PR26858 -O3 output - source compiled test XPASS: PR26858 -O3 execution - bytecode-native test XPASS: PR26858 -O3 output - bytecode-native test XPASS: PR26858 -O3 -findirect-dispatch execution - bytecode-native test XPASS: PR26858 -O3 -findirect-dispatch output - bytecode-native test FAIL: assign -findirect-dispatch execution - bytecode-native test FAIL: assign -O3 -findirect-dispatch execution - bytecode-native test FAIL: stringconst2 -findirect-dispatch output - bytecode-native test FAIL: stringconst2 -O3 -findirect-dispatch output - bytecode-native test === libjava Summary for unix === # of expected passes6765 # of unexpected failures4 # of unexpected successes 12 # of expected failures 16 # of untested testcases 14 === libjava Summary === # of expected passes13462 # of unexpected failures42 # of unexpected successes 24 # of expected failures 32 # of untested testcases 62 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10353
[Bug target/25743] crosscompiler fails to build ada-rts for target platform.
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2006-05-06 11:42 --- Patches should be posted to [EMAIL PROTECTED] -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-06 11:42:59 date|| Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25743
[Bug libgcj/10353] [4.0/4.1/4.2 regression] Java testsuite failures
--- Comment #27 from ebotcazou at gcc dot gnu dot org 2006-05-06 11:46 --- For sparc/sparc64 linux, the status for 4.2 20060503, from here, http://gcc.gnu.org/ml/gcc-testresults/2006-05/msg00223.html, is this: Thanks, but this PR is for Solaris so avoid posting results for Linux here, there are some important differences as far as libjava is concerned. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10353
[Bug other/16513] Libiberty doesn't honor the multi-os-directory settings
--- Comment #3 from christian dot joensson at gmail dot com 2006-05-06 12:07 --- what's the status of this one? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16513
[Bug c++/17347] C++ FE produces invalid CONSTRUCTOR trees for vtables
--- Comment #4 from christian dot joensson at gmail dot com 2006-05-06 12:08 --- what's the status of this one? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17347
[Bug other/16513] Libiberty doesn't honor the multi-os-directory settings
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2006-05-06 12:14 --- what's the status of this one? Unchanged according to my testing: [EMAIL PROTECTED]:~/svn/gcc/gcc uname -a Linux linux 2.6.8-24-default #1 Wed Oct 6 09:16:23 UTC 2004 x86_64 x86_64 x86_64 GNU/Linux [EMAIL PROTECTED]:~/svn/gcc/gcc ls -al ~/install/gcc/lib/32/libiberty.a -rw-r--r-- 1 eric users 590738 2006-05-03 16:06 /home/eric/install/gcc/lib/32/libiberty.a -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2005-03-21 02:49:52 |2006-05-06 12:14:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16513
[Bug fortran/27452] gfortran support for non-standard sind,cosd and friends intrinsics
--- Comment #4 from sgk at troutmask dot apl dot washington dot edu 2006-05-06 13:38 --- Subject: Re: gfortran support for non-standard sind,cosd and friends intrinsics On Sat, May 06, 2006 at 06:32:01AM -, deji_aking at yahoo dot ca wrote: --- Comment #3 from deji_aking at yahoo dot ca 2006-05-06 06:32 --- (In reply to comment #2) In fact it is easy to divide by 90° and multiply by pi. You just proved my point, one would want to divide by 180 and multiply by pi ;). Having sind and co safeguard against such silly mistake. fair enough, i'll continue using my self-made functions. Which is faster? Multiplying and dividing by a literal constant directly in your code or a function call to do the trivial work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27452
[Bug middle-end/27302] Fold does not fold (i j) == (j i) to 1
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-05-06 13:52 --- Working on a patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-04-25 18:31:38 |2006-05-06 13:52:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27302
[Bug c++/27456] New: Compiler allows function not returning value to be used
The following program compiles without error:
#include iostream
#include string
std::string f() {} main(){ std::string s(f()); return EXIT_SUCCESS; }
The function f() does not return a value, string s is filled with random areas
of memory. The program segfaults. gcc -v output from my machine (I tested
this on a few others):
[EMAIL PROTECTED] ~/temp $ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure : (reconfigured) ../configure
--with-gcc-version-trigger=/root/gcc/gcc-4.0.0/gcc/version.c
--enable-languages=c,c++,java,objc --no-create --no-recursion
Thread model: posix
gcc version 4.0.0
--
Summary: Compiler allows function not returning value to be used
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aftli at optonline dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27456
[Bug c++/27456] Compiler allows function not returning value to be used
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-05-06 14:57 --- It says warning: control reaches end of non-void function, also the code is not invalid, but undefined, thus you get a segfault. -- 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=27456
[Bug fortran/27457] New: ICE in match_case_eos()
$ cat ICE_match_case_eos_1.f
! { dg-do compile }
! { dg-options -std=gnu }
! PR fortran
implicit none
integer(kind=1) :: i
real :: r(3)
select case (i)
case (129) r(4) = 0
end select
end
(gdb) set args ICE_match_case_eos_1.f -ffixed-form -quiet -dumpbase
ICE_match_case_eos_1.f -mtune=generic -auxbase ICE_match_case_eos_1
-version -I /opt/gcc-4.2/bin/../lib/gcc/i686-linux-gnu/4.2.0/finclude -o
/tmp/ccO1JXYy.s
(gdb) run
Starting program: /opt/gcc-4.2/lib/gcc/i686-linux-gnu/4.2.0/f951
ICE_match_case_eos_1.f -ffixed-form -quiet -dumpbase
ICE_match_case_eos_1.f -mtune=generic -auxbase ICE_match_case_eos_1
-version -I /opt/gcc-4.2/bin/../lib/gcc/i686-linux-gnu/4.2.0/finclude -o
/tmp/ccO1JXYy.s
GNU F95 version 4.2.0 20060424 (experimental) (i686-linux-gnu)
compiled by GNU C version 4.2.0 20060424 (experimental).
GGC heuristics: --param ggc-min-expand=94 --param
ggc-min-heapsize=121309
Program received signal SIGSEGV, Segmentation fault.
0x08077988 in match_case_eos () at
../../../src/gcc-4.2/gcc/fortran/match.c:3033
3033../../../src/gcc-4.2/gcc/fortran/match.c: No such file or
directory.
in ../../../src/gcc-4.2/gcc/fortran/match.c
(gdb) bt
#0 0x08077988 in match_case_eos () at
../../../src/gcc-4.2/gcc/fortran/match.c:3033
#1 0x0807896c in gfc_match_case () at
../../../src/gcc-4.2/gcc/fortran/match.c:3119
#2 0x080830da in match_word (str=0x0, subr=0x80787a0 gfc_match_case,
old_locus=0xbfc33a88) at ../../../src/gcc-4.2/gcc/fortran/parse.c:65
#3 0x08083c7a in decode_statement () at
../../../src/gcc-4.2/gcc/fortran/parse.c:192
#4 0x08083ff8 in next_statement () at
../../../src/gcc-4.2/gcc/fortran/parse.c:476
#5 0x08085290 in parse_executable (st=value optimized out) at
../../../src/gcc-4.2/gcc/fortran/parse.c:2116
#6 0x08086177 in parse_progunit (st=ST_ARITHMETIC_IF) at
../../../src/gcc-4.2/gcc/fortran/parse.c:2866
#7 0x08086621 in gfc_parse_file () at
../../../src/gcc-4.2/gcc/fortran/parse.c:3182
#8 0x080a5e3d in gfc_be_parse_file (set_yydebug=0) at
../../../src/gcc-4.2/gcc/fortran/f95-lang.c:301
#9 0x082fb06a in toplev_main (argc=14, argv=0xbfc33ca4) at
../../../src/gcc-4.2/gcc/toplev.c:999
#10 0x080ce736 in main (argc=Cannot access memory at address 0x0
) at ../../../src/gcc-4.2/gcc/main.c:35
--
Summary: ICE in match_case_eos()
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aldot at gcc dot gnu dot org
BugsThisDependsOn: 19292
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27457
[Bug fortran/27457] ICE in match_case_eos()
--- Comment #1 from tobi at gcc dot gnu dot org 2006-05-06 16:01 --- Mine. I'm currently testing a patch -- tobi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-06 16:01:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27457
[Bug fortran/27457] ICE in match_case_eos()
--- Comment #2 from aldot at gcc dot gnu dot org 2006-05-06 16:02 --- Known to work: g77-3.4 Known to fail: gfortran = 4.0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27457
[Bug fortran/27452] gfortran support for non-standard sind,cosd and friends intrinsics
--- Comment #5 from deji_aking at yahoo dot ca 2006-05-06 16:24 --- (In reply to comment #4) Which is faster? Multiplying and dividing by a literal constant directly in your code or a function call to do the trivial work. Really, I don't know enough about compiler technology to ba able to tell. Having had to deal with an empirical formulas made of a bunch of trig. functions (in degrees), i found it much convenient to just use sin_d(angle) instead of multiplying and diving by literal constants in each and all terms. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27452
[Bug fortran/27452] gfortran support for non-standard sind,cosd and friends intrinsics
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-05-06 16:29 --- I should note that sind sounds to me sin taking a double precision agrument at least when I read the summary and not the first comment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27452
[Bug c++/27456] Compiler allows function not returning value to be used
--- Comment #2 from aftli at optonline dot net 2006-05-06 16:50 --- Subject: Re: Compiler allows function not returning value to be used You're right, it does give a warning if you use -Wall. But on the default warning level, the program has two major errors, which should not be considered warnings. It has a non-void function, which is used, not returning a value, and a void function (main()) returning a value. Every other compiler I've used spits out error messages for these problems. This is a big problem, not a INVALID concern. Also, did you notice the void function rguenth at gcc dot gnu dot org wrote: --- Comment #1 from rguenth at gcc dot gnu dot org 2006-05-06 14:57 --- It says warning: control reaches end of non-void function, also the code is not invalid, but undefined, thus you get a segfault. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27456
[Bug c++/27456] Compiler allows function not returning value to be used
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-05-06 17:11 --- main returns an int with your declaration. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27456
[Bug tree-optimization/27151] [4.1/4.2 Regression] ICE with -ftree-vectorize with mixed types
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-05-06 17:38 --- Subject: Bug 27151 Author: rguenth Date: Sat May 6 17:37:53 2006 New Revision: 113580 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113580 Log: 2006-05-06 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/27151 * tree-vect-transform.c (vectorizable_condition): Punt on values that have a different type than the condition. * gcc.dg/vect/pr27151.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/vect/pr27151.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-transform.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27151
[Bug tree-optimization/27151] [4.1/4.2 Regression] ICE with -ftree-vectorize with mixed types
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-05-06 17:41 --- Subject: Bug 27151 Author: rguenth Date: Sat May 6 17:41:48 2006 New Revision: 113581 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113581 Log: 2006-05-06 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/27151 * tree-vect-transform.c (vectorizable_condition): Punt on values that have a different type than the condition. * gcc.dg/vect/pr27151.c: New testcase. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/vect/pr27151.c - copied unchanged from r113580, trunk/gcc/testsuite/gcc.dg/vect/pr27151.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/tree-vect-transform.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27151
[Bug tree-optimization/27151] [4.1/4.2 Regression] ICE with -ftree-vectorize with mixed types
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-05-06 17:42 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27151
[Bug tree-optimization/27460] New: Does not vectorize statements with mixed type COND_EXPRs
See testsuite/gcc.dg/vect/pr27151.c:
float vs_data[75];
void vis_clear_data ()
{
int vis_type, i;
for (i = 0; i 75; i++)
{
vs_data[i] = (vis_type == 1);
}
}
the loop is not vectorized because the COND_EXPRs condition has a different
type than the COND_EXPRs true/false results.
See also http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00255.html for
more analysis on this problem.
--
Summary: Does not vectorize statements with mixed type COND_EXPRs
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
OtherBugsDependingO 27151
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27460
[Bug c++/27427] [4.0/4.1/4.2 regression] ICE with invalid template parameter
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-05-06 20:40 --- Subject: Bug 27427 Author: reichelt Date: Sat May 6 20:40:23 2006 New Revision: 113582 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113582 Log: PR c++/27427 * pt.c (convert_nontype_argument): Return early on invalid arguments. * g++.dg/template/incomplete2.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/incomplete2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27427
[Bug c++/27427] [4.0/4.1/4.2 regression] ICE with invalid template parameter
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-05-06 20:43 --- Subject: Bug 27427 Author: reichelt Date: Sat May 6 20:43:07 2006 New Revision: 113583 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113583 Log: PR c++/27427 * pt.c (convert_nontype_argument): Return early on invalid arguments. * g++.dg/template/incomplete2.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/incomplete2.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/pt.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27427
[Bug c++/27427] [4.0/4.1/4.2 regression] ICE with invalid template parameter
--- Comment #6 from reichelt at gcc dot gnu dot org 2006-05-06 20:46 --- Subject: Bug 27427 Author: reichelt Date: Sat May 6 20:45:59 2006 New Revision: 113584 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113584 Log: PR c++/27427 * pt.c (convert_nontype_argument): Return early on invalid arguments. * g++.dg/template/incomplete2.C: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/template/incomplete2.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/pt.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27427
[Bug c++/27427] [4.0/4.1/4.2 regression] ICE with invalid template parameter
--- Comment #7 from reichelt at gcc dot gnu dot org 2006-05-06 20:48 --- Fixed on mainline, 4.1 branch, and 4.0 branch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27427
[Bug c/27462] New: ICE tree-check in c-common.c:1086
extracted from WINE: gcc -O2 -c locale.i locale.i: In function 'f': locale.i:3: internal compiler error: tree check: expected class 'constant', have 'binary' (bit_and_expr) in convert_and_check, at c-common.c:1086 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: ICE tree-check in c-common.c:1086 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: marcus at jet dot franken dot de GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27462
[Bug c/27462] ICE tree-check in c-common.c:1086
--- Comment #1 from marcus at jet dot franken dot de 2006-05-06 20:55 --- Created an attachment (id=11393) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11393action=view) locale.i gcc -O2 -c locale.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27462
[Bug c/25802] VM types of external and internal linkage variables not diagnosed
--- Comment #2 from mrs at apple dot com 2006-05-06 21:24 --- I have a fix for this, will post. -- mrs at apple dot com changed: What|Removed |Added CC||mrs at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25802
[Bug c++/27464] New: unsuitable aliasing rule warning
Enter the following program and compile with -Wall -fstrict-aliasing
int main(int argc,char **argv)
{
float f = 0.5;
return reinterpret_castint (f);
}
g++ will return the following warning message:
warning: dereferencing type-punned pointer will break strict-aliasing rules
However, this warning message is confusing at best since no pointer handling
is involved here. And then, this program cannot exhibit pointer-aliasing
breakage since the variable f and the return code cannot interpret the same
variable as two different types - the re-interpretation of the floating point
value as integer-bit pattern is copied before any aliasing problems could
possibly enter the scene.
Interestingly, g++ explicitly allows the re-interpretation of bit patterns of a
specific type thru the union trick, i.e.
union {
float i;
int o;
} u;
then assigning the input value to u.i and reading the bit-pattern back from
u.o.
However, the former reinterpret_cast is only implementation-defined (as the
implementation defines the bit-pattern transition from float and its re-inter-
pretation as int) whereas the latter union cast is undefined behaivour:
A compiler is free to re-organize the access patterns by moving the assignment
to u.i *behind* the read-back from u.o. Thus, the first method is clearly
preferable when this kind of type-reinterpretation is apropriate at all, and
thus should be allowed to pass without a warning. The latter is only defined
because g++ took the freedom to allow it and to avoid the instruction
re-ordering.
--
Summary: unsuitable aliasing rule warning
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: thor at math dot tu-berlin dot de
GCC build triplet: i486-pc-linux-gnu
GCC host triplet: i486-pc-linux-gnu
GCC target triplet: i486-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27464
[Bug c++/27465] New: ICE on dependent const folding
Performing constant calculations depending on template parameters causes an
internal compiler error. Compile the code below with g++ -c foo.cpp to
reproduce.
template class T struct A {
static const unsigned a = (sizeof(T[3])-sizeof(T[2]));
unsigned foo(unsigned b) { return a*b; }
};
I do not get the ICE when compiling the code with my distribution compiler
(Ubuntu Dapper gcc 4.0.3), only with my self-compiled 4.0.3 that has checking
enabled. I only noticed this by accident when I build a checking compiler to
hunt a different gcc bug.
My configuration options as shown by g++ -v (mostly copied from the
distribution compiler):
../configure --enable-languages=c,c++ --prefix=/home/tneumann/gcc4
--enable-shared --with-system-zlib --without-included-gettext
--enable-threads=posix --enable-nls --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --disable-werror --enable-checking --disable-multilib
x86_64-linux-gnu
--
Summary: ICE on dependent const folding
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tneumann at pi3 dot informatik dot uni-mannheim dot de
GCC host triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27465
[Bug c/27462] ICE tree-check in c-common.c:1086
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-07 02:54 --- *** This bug has been marked as a duplicate of 27273 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27462
[Bug c/27273] [4.2 regression] tree check fail for legal code when convert returns a constant from an expression that was not constant
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-07 02:54 --- *** Bug 27462 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||marcus at jet dot franken ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27273
[Bug c++/27464] unsuitable aliasing rule warning
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-07 02:56 --- You are wrong that pointers is not involved. References are really just pointers. And it is not implemention defined as it still violates C++ aliasing rules. -- 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=27464
[Bug c++/27465] [4.0 only] ICE on dependent const folding
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-07 03:11 --- This was fixed for sure by PR 23357. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||23357 Summary|ICE on dependent const |[4.0 only] ICE on dependent |folding |const folding Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27465
[Bug target/27421] [4.0/4.1/4.2 regression] ICE with invalid array in struct
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-07 03:13:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27421
[Bug tree-optimization/27460] Does not vectorize statements with mixed type COND_EXPRs
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-07 03:23 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-07 03:23:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27460
[Bug libobjc/27466] New: RFE: Support for libobjc equivalent of std::set_unexpected
libobjc's exception implementation doesn't support a user-supplied default uncaught exception handler, and this would be a very handy feature to have. With the equivalent of std:set_unexpected, one could implement the NSSetUncaughtExceptionHandler() Foundation API. -- Summary: RFE: Support for libobjc equivalent of std::set_unexpected Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libobjc AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: landonf at opendarwin dot org GCC build triplet: i486-linux-gnu GCC host triplet: i486-linux-gnu GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27466
[Bug fortran/24813] ICE with scalarization LEN of character types
--- Comment #7 from pault at gcc dot gnu dot org 2006-05-07 05:46 --- Subject: Bug 24813 Author: pault Date: Sun May 7 05:46:26 2006 New Revision: 113594 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113594 Log: 2006-05-07 Paul Thomas [EMAIL PROTECTED] PR fortran/24813 * trans-array.c (get_array_ctor_strlen): Remove static attribute. * trans.h: Add prototype for get_array_ctor_strlen. * trans-intrinsic.c (gfc_conv_intrinsic_len): Switch on EXPR_ARRAY and call get_array_ctor_strlen. 2006-05-07 Paul Thomas [EMAIL PROTECTED] PR fortran/24813 * gfortran.dg/char_cons_len_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/char_cons_len.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24813
