[Bug other/21431] gcc.4.0.0 instalation fails while making all

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-07 06:43 --- *** This bug has been marked as a duplicate of 17383 *** -- What|Removed |Added

[Bug bootstrap/17383] [4.0 Regression] Building in src dir fails

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-07 06:43 --- *** Bug 21431 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug fortran/21434] blanket save after other save statements triggers error

--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-07 06:22 --- Related to 19425. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21434

[Bug middle-end/14840] [tree-ssa] fold tree_code_type[CST] and tree_code_length[CST] in GCC itself

--- Additional Comments From kazu at cs dot umass dot edu 2005-05-07 05:14 --- In *.final_cleanup of cc1-i files with --enable-checking, I see 1308 occurrences of tree_code_type[CST] 979 occurrences of tree_code_length[CST] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14840

[Bug tree-optimization/14841] [tree-ssa] const_array[CST] is not folded

--- Additional Comments From schlie at comcast dot net 2005-05-07 05:12 --- (In reply to comment #17) > I've extended Steven's patch to handle nested aggregates > (i.e. any combination of ARRAY_REF and COMPONENT_REF). Does it also work with terminating static const char "strings" which

[Bug fortran/21435] gfortran fails to open nonexisting file with status scratch

--- Additional Comments From kargl at gcc dot gnu dot org 2005-05-07 05:05 --- I believe the code is invoking processor (ie compiler) defined behavior. The standard states "If the STATUS= specifier has the value SCRATCH, the FILE= specifier shall be absent." This isn't a constraint, so

[Bug tree-optimization/15838] "Inline" value of static struct

--- Additional Comments From kazu at cs dot umass dot edu 2005-05-07 04:48 --- My patch for PR14841 also works for this case. -- What|Removed |Added AssignedTo|dnov

[Bug fortran/21432] gfortran does not support printing of namelists

--- Additional Comments From joe at confucius dot gnacademy dot org 2005-05-07 04:19 --- No problem. First things first :-) :-) :-) In case you are wondering the bug reports I've been submitting come from trying to compile a 2 line iron core collapse supernova simulation. It's the

[Bug fortran/21435] New: gfortran fails to open nonexisting file with status scratch

Not sure what the standard says but the difference should probably be at least release noted. [EMAIL PROTECTED] ~]$ ifort -o testf test.f [EMAIL PROTECTED] ~]$ ./testf well done [EMAIL PROTECTED] ~]$ gfortran -o testf test.f [EMAIL PROTECTED] ~]$ ./testf 3 STOP io-err 91 [EMAIL PROTE

[Bug fortran/21432] gfortran does not support printing of namelists

--- Additional Comments From kargl at gcc dot gnu dot org 2005-05-07 04:02 --- Thanks for cutting it down! The code is nonstandard according to both the NAG compiler and Lahey's web base source code checker. Lahey will compile the code if one does not ask for strict conformance to the

[Bug fortran/21434] New: blanket save after other save statements triggers error

Including a blanket save after other state statements triggers error in gfortran. It doesn't in Intel Fortran. This could be annoying when you have a subroutine with includes to common blocks. [EMAIL PROTECTED] ~]$ cat test1.F subroutine net implicit real*8(a-h,o-z) save/k

[Bug bootstrap/21403] Canadian cross build fails.

--- Additional Comments From green at redhat dot com 2005-05-07 03:52 --- I've posted a patch. http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00555.html -- What|Removed |Added --

[Bug fortran/21432] gfortran does not support printing of namelists

--- Additional Comments From joe at confucius dot gnacademy dot org 2005-05-07 03:45 --- Created an attachment (id=8834) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8834&action=view) better file -- What|Removed |Added ---

[Bug fortran/21432] gfortran does not support printing of namelists

--- Additional Comments From joe at confucius dot gnacademy dot org 2005-05-07 03:43 --- Sorry for the spew. The code is generated by a preprocessor and I didn't realize how large it would end up. The bug is that gfortran apparently does not support printing of namelists. I don't kn

[Bug fortran/21409] Attached fortran 95 code generates error

--- Additional Comments From kargl at gcc dot gnu dot org 2005-05-07 03:33 --- (In reply to comment #2) > > But note I get a warning with ICC: > fortcom: Warning: t.f, line 8: All active combinations of index-names are not used within the variable > being defined (i.e., leftside) of th

[Bug middle-end/21433] New: The COMPONENT_REF case of expand_expr_real_1 is probably wrong

We have the following coverage for the COMPONENT_REF case. -: 6997:case COMPONENT_REF: -: 6998: /* If the operand is a CONSTRUCTOR, we can just extract the -: 6999: appropriate field if it is present. */ 75549: 7000: if (TREE_CODE (TREE_OPERAND (

[Bug fortran/21432] Another code sample that gfortran dies on

--- Additional Comments From kargl at gcc dot gnu dot org 2005-05-07 03:26 --- No offense intended, but a 1085 line source file is fairly useless to us. In particular, NAG's F95 compiler can't compile this code. In addition, a single print statement without additional context (such as

[Bug tree-optimization/14841] [tree-ssa] const_array[CST] is not folded

--- Additional Comments From kazu at cs dot umass dot edu 2005-05-07 03:08 --- I've extended Steven's patch to handle nested aggregates (i.e. any combination of ARRAY_REF and COMPONENT_REF). -- What|Removed |Added ---

[Bug fortran/21432] Another code sample that gfortran dies on

--- Additional Comments From joe at confucius dot gnacademy dot org 2005-05-07 01:54 --- Created an attachment (id=8833) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8833&action=view) code sample that breaks gfortran code sample that breaks gfortran -- http://gcc.gnu.org/bugz

[Bug fortran/21432] New: Another code sample that gfortran dies on

This also works on ifort gfortran -c -O3 -g input.F -o input.o In file input.F:694 if(iprcor.ne.0) print cor 1 -- Summary: Another code sample that gfortran dies on Product: gcc Version: 4.0.0 Status: UNCONFIRMED

[Bug other/21431] New: gcc.4.0.0 instalation fails while making all

gcc-4.0.0 configures aparently OK from the directory the tarball was unzipped, but fails during "make all". The error message is: updating cache ./config.cache configure: creating ./config.status config.status: creating Makefile config.status: executing default-1 commands ./config.status: line 910

RE: Problem with use of anonymous types

Hmmm... I just read through the bug reports you cited. Sounds to me like this is still somewhat of an open issue, as to whether the compiler should issue an error in these cases or simply silently discard any templated function as a possible match for an operation involving an unnamed type. As wa

[Bug target/21412] [PowerPC] ICE loading TLS address

--- Additional Comments From rth at gcc dot gnu dot org 2005-05-07 00:54 --- Testing fixes. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc

[Bug target/18655] Incorrect data in .debug_frame section for PowerPC

--- Additional Comments From amodra at bigpond dot net dot au 2005-05-07 00:33 --- http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00551.html -- What|Removed |Added K

[Bug target/18655] Incorrect data in .debug_frame section for PowerPC

-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-

Re: Problem with use of anonymous types

On May 6, 2005, at 8:09 PM, Julian Cummings wrote: People are reporting trouble compiling blitz with gcc-4.0.0, and the compiler errors are resulting from the use of unnamed enums. A simple code illustrates the problem: struct nullType {}; template inline T operator+(const T& a, nullType) {

Problem with use of anonymous types

People are reporting trouble compiling blitz with gcc-4.0.0, and the compiler errors are resulting from the use of unnamed enums. A simple code illustrates the problem: struct nullType {}; template inline T operator+(const T& a, nullType) { return a; } enum named { namedA = 1, namedB = 2 }

[Bug middle-end/21430] New: Quadratic behavior with constant initializers

Consider: #define B1(C,D) \ B0(C##0,D##0) B0(C##1,D##0) B0(C##2,D##0) B0(C##3,D##0) B0(C##4,D##0) \ B0(C##5,D##0) B0(C##6,D##0) B0(C##7,D##0) B0(C##8,D##0) B0(C##9,D##0) #define B2(C,D)

[Bug target/18655] Incorrect data in .debug_frame section for PowerPC

-- What|Removed |Added GCC target triplet||powerpc-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18655

[Bug java/20309] gcjh needs a -force option

-- What|Removed |Added Target Milestone|4.1.0 |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20309

[Bug java/20309] gcjh needs a -force option

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-06 22:53 --- Subject: Bug 20309 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-06 22:53:38 Modified files: gcc/java : Change

[Bug fortran/17917] gfortran ICE on "equivalence"

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-06 22:49 --- *** Bug 21429 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug fortran/21429] Internal compiler error when trying to compile the HDF5 libs

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-06 22:49 --- *** This bug has been marked as a duplicate of 17917 *** -- What|Removed |Added

[Bug libffi/21285] gij fails to handle NullPointerException exception

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-06 22:47 --- CCing RTH since he is the alpha maintainer. Confirmed. -- What|Removed |Added

[Bug c++/21427] [3.4/4.0 only] Failure in make_thunk, cp/method.c:145 when compiling with multiply-inherited members

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-06 22:43 --- Further reduced: struct B1 { virtual void f(void); }; struct B2 { virtual B2 &g() = 0; }; struct I : B1, private B2 { I &g(); }; struct D : I { }; This works on the mainline. -- What

[Bug middle-end/21285] gij fails to handle NullPointerException exception

--- Additional Comments From tsv at solvo dot ru 2005-05-06 22:39 --- Created an attachment (id=8832) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8832&action=view) Fixes call frame size mismatch in ".frame" and ".eh_frame" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21285

[Bug fortran/21429] New: Internal compiler error when trying to compile the HDF5 libs

Hi, I'm using the gfortran version from the 4.0.0-3mdk package ; here are the complete instructions I did before compiling the HDF5 libs (I followed the advices from [1]): wget ftp://ftp.ncsa.uiuc.edu/HDF/HDF5/current/src/hdf5-1.6.4.tar.gz tar xzf hdf5-1.6.4.tar.gz cd hdf5-1.6.4/ F9X=gfo

[Bug middle-end/21285] gij fails to handle NullPointerException exception

--- Additional Comments From tsv at solvo dot ru 2005-05-06 22:36 --- Ok, I think I did find the problem. The unwind logic could not unwind deeper than "ffi_closure_osf" function defined in libffi/src/alpha/osf.S (gdb showed call stack like corrupted). I checked number of bytes reserved f

[Bug c++/21427] Failure in make_thunk, cp/method.c:145 when compiling with multiply-inherited members

--- Additional Comments From bangerth at dealii dot org 2005-05-06 22:33 --- That's an interesting case involving covariant return types: - class B1 { public: virtual void foo(); }; class B2 { public: virtual B2 & bar() = 0; }; class I :

[Bug fortran/21148] Can't open module file (case not taken into account)

--- Additional Comments From nicolas dot girard at nerim dot net 2005-05-06 22:29 --- Please ignore this report. At the time of writing it, I didn't know much about .mod and .o files Sorry for the trouble. -- What|Removed |Added -

[Bug c++/21413] bogus diagnostic from unidentified template

--- Additional Comments From bangerth at dealii dot org 2005-05-06 22:21 --- I think that's a good question. We've had this before in some other PR. The problem is that because the template parameter is explicitly specialized, rather than deduced, SFINAE doesn't apply and the compiler

[Bug java/21428] [3.4/4.0/4.1 Regression] bogus warning: unused parameter 'this'

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-06 21:22 --- Lets mark this as a regression then. -- What|Removed |Added Keywords|

[Bug java/21428] bogus warning: unused parameter 'this'

--- Additional Comments From mark at gcc dot gnu dot org 2005-05-06 21:13 --- This also happens with 4.0 and 3.4, but 3.3 doesn't show any warning. -- What|Removed |Added

[Bug tree-optimization/19401] Trivial loop not unrolled

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-06 21:11 --- Subject: Bug 19401 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-06 21:11:29 Modified files: gcc: ChangeLog tree-flow.h tree-ssa-loop-i

[Bug c++/21427] Failure in make_thunk, cp/method.c:145 when compiling with multiply-inherited members

--- Additional Comments From lord dot dimwit at gmail dot com 2005-05-06 21:10 --- Also happens in 4.0.0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21427

[Bug java/21428] New: bogus warning: unused parameter 'this'

[EMAIL PROTECTED]:~/pikkuohjelmat/java/TESTIT$ echo 'class foo {}' > foo.java [EMAIL PROTECTED]:~/pikkuohjelmat/java/TESTIT$ gcj -v -O2 -Wall -W -c foo.java Using built-in specs. Reading specs from /home/kalle/stow/gcc/i686-pc-linux-gnu/bin/../lib/gcc/i686-pc-linux-gnu/4.1.0/../../../libgcj.spec re

[Bug c++/21427] Failure in make_thunk, cp/method.c:145 when compiling with multiply-inherited members

--- Additional Comments From lord dot dimwit at gmail dot com 2005-05-06 20:58 --- Created an attachment (id=8831) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8831&action=view) Complete preprocessed source for the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21427

[Bug c++/21427] New: Failure in make_thunk, cp/method.c:145 when compiling with multiply-inherited members

Complete command line: g++ -fPIC -c -o objs/MallocIO.o -pedantic -ansi -g -DDEBUG -Wall -Wno-multichar -Iheaders -Iheaders/support -Iheaders/kernel libbe/MallocIO.cpp Error: In file included from libbe/MallocIO.cpp:15: headers/support/MallocIO.h:24: internal compiler error: in make_thunk, at cp/me

[Bug rtl-optimization/21254] [4.0/4.1 regression] Incorrect code with -funroll-loops for multiple targets with same code

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-06 20:24 --- Subject: Bug 21254 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-06 20:24:01 Modified files: gcc: ChangeLog loop-iv.c loop-unroll.c L

[Bug c++/21426] anonymous enums vs. templates

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-06 20:16 --- The code is invalid, see PR 19404 and PR 20589 *** This bug has been marked as a duplicate of 19404 *** -- What|Removed |Added --

[Bug c++/19404] [4.0 Regression] anonymous types and templates and rejecting valid code

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-06 20:16 --- *** Bug 21426 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug c++/21426] New: anonymous enums vs. templates

If one instance of an overloaded function or operator is generic, I cannot supply a member of an anonymous enum to that function or operator, even if I wouldn't be calling the generic instance anyway. As an example of the problem, attempting to compile the simplified code class S; template S

[Bug target/21389] optimized code seg faults due to double load on sparcV9

--- Additional Comments From drew dot johnson at andrew dot com 2005-05-06 19:47 --- Subject: RE: optimized code seg faults due to double load on sparcV9 Then what is the point of the -munaligned-doubles flag? Is this simply ignored? I understand your point about malloc, but what if

[Bug target/21329] [4.0/4.1 Regression] optimize i386 block copy

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-06 19:31 --- Subject: Bug 21329 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-06 19:31:17 Modified files: gcc: ChangeLog gcc/config/i386: i

[Bug target/21389] optimized code seg faults due to double load on sparcV9

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-06 19:07 --- (In reply to comment #4) > Subject: RE: optimized code seg faults due to double load on sparcV9 > > I don't think so. Malloc does not guarantee anything but mod-4 > alignment. You have to use memalign to

[Bug target/21389] optimized code seg faults due to double load on sparcV9

--- Additional Comments From drew dot johnson at andrew dot com 2005-05-06 19:04 --- Subject: RE: optimized code seg faults due to double load on sparcV9 I don't think so. Malloc does not guarantee anything but mod-4 alignment. You have to use memalign to get something better (at lea

[Bug target/21389] optimized code seg faults due to double load on sparcV9

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-06 18:54 --- I think you violating alignment rules in C: x = tptr[1].f3; p = (char *)tptr; p += 4; tptr = (test1 *)p; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21389

[Bug target/21389] optimized code seg faults due to double load on sparcV9

--- Additional Comments From drew dot johnson at andrew dot com 2005-05-06 18:53 --- (In reply to comment #0) > When -O3 or higher is used, the optimizer utilizes the lddf sparc instruction > to load doubles into registers. This can generate a bus-error/seg-fault at > runtime if the

[Bug c++/21425] New: typeof with parens rejected

one might argue that this isn't a bug because it isn't in std but it looks inconsistent, so I let you decide: int a; // ok int (b); // ok typeof(a) c; // ok typeof(a) (d) // error -- Summary: typeof with parens rejected Product: gcc Version: 4.0.0

[Bug target/21389] optimized code seg faults due to double load on sparcV9

-- What|Removed |Added Attachment #8820|compile with -O3 or higher, |compile with -O1 or higher, description|and execution generates seg-|and execution generates seg-

[Bug target/21325] [4.0 Regression] libjava should be re-enabled for ppc-darwin

--- Additional Comments From andreast at gcc dot gnu dot org 2005-05-06 18:33 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED

[Bug target/21325] [4.0 Regression] libjava should be re-enabled for ppc-darwin

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-06 18:27 --- Subject: Bug 21325 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-06 18:27:45 Modified files: . : Change

[Bug rtl-optimization/21424] Infinite memory allocation when -O3 is used

-20050506-2.3.2/arm-unknown-linux-gnu/gcc-csl-arm-20050506-glibc-2.3.2/bin/arm-unknown-linux-gnu-gcc -c -O3 test.c test.c: In function `f': test.c:14: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. Send email to [EMAIL PROTECTED

[Bug rtl-optimization/21424] New: Infinite memory allocation when -O3 is used

Compiling the following testcase with -O3 gcc tries to allocate an infinite memory (and freezes the system for some time). void f(int type){ int tmp; for(tmp = 0; tmp < 2; tmp++){ switch(type) { case 0: s1(); break; case 1: s2(); bre

[Bug fortran/21409] Attached fortran 95 code generates error

--- Additional Comments From eedelman at acclab dot helsinki dot fi 2005-05-06 16:59 --- (In reply to comment #2) > Reduced testcase (I tried not to reduce it too much): > subroutine difq3 (jmax, ngmax, ams) > implicit none > integer*4 :: jmax, ngmax > real*8, di

[Bug tree-optimization/21380] [4.0 Regression] ICE compiling with -O

--- Additional Comments From law at redhat dot com 2005-05-06 16:44 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolu

[Bug tree-optimization/21380] [4.0 Regression] ICE compiling with -O

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-06 16:44 --- Subject: Bug 21380 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-06 16:43:58 Modified files: gcc: ChangeLog tree-ssa-threadupdate.c

Fixed: Double backslashes in fixincl header (__FD_ZERO macro)

On Friday 06 May 2005 09:01 am, Joseph S. Myers wrote: > On Fri, 6 May 2005, Bruce Korb wrote: > > > That is, indeed, very bizarre. I opened that file and the lines that > > are supposed to be continued with backslashes ended with: \\\n\ > > which is correct. After you extract it, you have: \\

[Bug c++/21386] Inconsistent diagnostics for taking address of rvalue

--- Additional Comments From benh at bwsint dot com 2005-05-06 16:10 --- (In reply to comment #2) > Note ICC causes the same thing in terms of error vs warning. That'll be because ICC emulates gcc behaviour... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21386

[Bug c++/21386] Inconsistent diagnostics for taking address of rvalue

--- Additional Comments From benh at bwsint dot com 2005-05-06 16:04 --- (In reply to comment #1) > (In reply to comment #0) > > The first error message is also odd; "non-lvalue" is C terminology that is > > rarely used in relation to C++. > > That is wrong because the standard actually

Re: Double backslashes in fixincl header (__FD_ZERO macro)

On Fri, 6 May 2005, Bruce Korb wrote: > That is, indeed, very bizarre. I opened that file and the lines that > are supposed to be continued with backslashes ended with: \\\n\ > which is correct. After you extract it, you have: \n\ > which is not correct. I am at a loss as to what to sugge

[Bug web/21423] New: http://gcc.gnu.org/java/status.html needs updating

http://gcc.gnu.org/java/status.html needs updating. It refers to gcj 3.2, which is a bit stale. -- Summary: http://gcc.gnu.org/java/status.html needs updating Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: minor Priority:

[Bug c/21419] [4.0/4.1 Regression] Accepts writting to const via asm

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-06 14:57 --- (In reply to comment #1) > This also happens with the C++ front-end too. Which I filed as PR 21422 as I think it is a related issue but not fully the same bug. -- http://gcc.gnu.org/bugzilla/show_bug.cg

[Bug c++/21422] [4.0/4.1 Regression] Accepts writting to const via asm

-- What|Removed |Added Known to fail||4.0.0 4.1.0 Known to work||3.4.0 3.3.3 Target Milestone|---

[Bug c/21419] [4.0/4.1 Regression] Accepts writting to const via asm

-- What|Removed |Added Known to fail||4.0.0 4.1.0 Known to work||3.4.0 3.3.3 http://gcc.gnu.org/bugzilla/show_bug.

[Bug c++/21422] New: [4.0/4.1 Regression] Accepts writting to const via asm

Like PR 21419 but for C++: void sigaddset(const int set) { __asm__("" : "=m"(set) ); } -- Summary: [4.0/4.1 Regression] Accepts writting to const via asm Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: accepts-invalid, diagn

[Bug c/21420] New: [3.4/4.0/4.1 Regression]

The following code in 3.4.0 and above does not warn/error our about assignment of read only location: static inline void sigaddset(const int set, int i) { __asm__("" : "=r"(set) ); } THis is just like 21419 but this time a "static inline" function instead. -- Summary: [3.4/4.

[Bug c++/21421] [3.4/4.0/4.1 Regression] Accepts writting to const via asm

-- What|Removed |Added Known to fail||3.4.0 3.0.4 3.3.3 4.0.0 ||4.1.0 Known to work|

[Bug c++/21421] New: [3.4/4.0/4.1 Regression] Accepts writting to const via asm

Just like PR 21420 but this is for C++ and is a regression from 2.95.3 and not from 3.3.3. static inline void sigaddset(const int set, int i) { __asm__("" : "=r"(set) ); } -- Summary: [3.4/4.0/4.1 Regression] Accepts writting to const via asm Pro

[Bug java/21418] Order of source files matters when compiling

--- Additional Comments From mark at gcc dot gnu dot org 2005-05-06 14:50 --- > I thought I saw something like this before. You are probably refering to bug #17845 which was recently closed since it couldn't be reproduced (because I added a workaround to GNU Classpath). I cannot say wit

[Bug c/21420] [3.4/4.0/4.1 Regression] Accepts writting to const via asm

-- What|Removed |Added Known to fail||4.0.0 3.4.0 4.0.0 Known to work||3.3.3 Target Milestone|---

[Bug c/21419] [4.0/4.1 Regression] Accepts writting to const via asm

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-06 14:48 --- This also happens with the C++ front-end too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21419

[Bug inline-asm/21396] inline asm doesn't compile with -O2 optimization

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-06 14:47 --- Fixed for 4.0.0 and above. -- What|Removed |Added Status|UNCONFIRMED

[Bug c/21419] [4.0/4.1 Regression] Accepts writting to const via asm

-- What|Removed |Added Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21419

[Bug c/21420] [3.4/4.0/4.1 Regression] Accepts writting to const via asm

-- What|Removed |Added Summary|[3.4/4.0/4.1 Regression]|[3.4/4.0/4.1 Regression] ||Accepts writting to const

[Bug c/21419] New: [4.0/4.1 Regression] Accepts writting to const via asm

The following code is accepted now in 4.0.0 and above but should not be: void sigaddset(const int set) { __asm__("" : "=m"(set) ); } -- Summary: [4.0/4.1 Regression] Accepts writting to const via asm Product: gcc Version: 4.0.0 Status: UNCONFIR

[Bug java/21418] Order of source files matters when compiling

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-06 14:31 --- I thought I saw something like this before. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21418

[Bug java/21418] New: Order of source files matters when compiling

We occasionally get bug reports against GNU Classpath about strange compilation errors. Kalle Olavi Niemitalo finally tracked it down. The order in which gcj -C is given source files to compile. The smallest example given was: gcj --bootclasspath '' --classpath .:vm/reference -C -d /tmp/obj java/i

[Bug target/21416] wrong code for __builtin_isless, __builtin_islessequal

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-06 14:21 --- Confirmed, see also . -- What|Removed |Added

[Bug target/21416] wrong code for __builtin_isless, __builtin_islessequal

-- What|Removed |Added GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21416

[Bug target/19087] Overflowed address in dwarf debug line information

--- Additional Comments From bjoern dot m dot haase at web dot de 2005-05-06 14:12 --- Hi Torleif, I have just had a look at PR19885 and I am having one additional question: IIUC, the lable references, that eventually cause the overflow problems refer to memory in form of "byte" add

[Bug tree-optimization/21417] Missed jump threading opportunity on trees

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-06 14:12 --- Confirmed, there is a load PRE missing also which looks like is causing the jump threader not to be able to do this jump. -- What|Removed |Added -

[Bug c++/21413] bogus diagnostic from unidentified template

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-06 14:07 --- Here is the reduced testcase: template struct a { typedef typename TT::value_type value_type; }; template void foo(int); template typename a::value_type foo(const C&); int main() { int s; foo(s)

[Bug middle-end/19721] [meta-bug] optimizations that CSE still catches

-- Bug 19721 depends on bug 19791, which changed state. Bug 19791 Summary: [tcb] A constant not fully propagated http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19791 What|Old Value |New Value

[Bug tree-optimization/19791] [tcb] A constant not fully propagated

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-06 14:02 --- Fixed by the new jump threader. -- What|Removed |Added Status|NEW

[Bug target/17994] avr-gcc does not output a dwarf2 .debug_frame section

--- Additional Comments From bjoern dot m dot haase at web dot de 2005-05-06 13:59 --- Hi, I have been reviewing PR19885 and come to the following conclusions: 1.) As expected, Torleif is right: I can confirm that the problem exists, 2.) it should, however, probably be called rat

[Bug tree-optimization/21417] Missed jump threading opportunity on trees

-- What|Removed |Added Component|middle-end |tree-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21417

[Bug middle-end/21417] Missed jump threading opportunity on trees

-- What|Removed |Added CC||kazu at cs dot umass dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21417

[Bug fortran/20971] gfortran - internal compiler error on bad program -fdefault-integer-8

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-06 13:52 --- *** Bug 21415 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug fortran/21415] internal compiler error in gfortran -fdefault-integer-8

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-06 13:52 --- *** This bug has been marked as a duplicate of 20971 *** -- What|Removed |Added

  1   2   >