--
ubizjak at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34249
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-16 07:23 ---
The error message is strange, but an error is not necessarily wrong. Other
compilers show the following messages:
NAG f95 shows the error:
Error: line 29: Argument T (no. 1) of C_U_TO_T is OUT or INOUT but is not a
--- Comment #5 from burnus at gcc dot gnu dot org 2008-01-16 07:13 ---
Fixed on the trunk (4.3.0).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from burnus at gcc dot gnu dot org 2008-01-16 07:12 ---
Subject: Bug 34796
Author: burnus
Date: Wed Jan 16 07:12:00 2008
New Revision: 131566
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131566
Log:
2008-01-16 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot
|dot org
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-01-16 05:32
---
I am not making a decision here yet. I will keep this PR open until I fix
another minor issue I have found.
I would like to comment that to do what you want to do here without any
ambiguity your code should be u
--- Comment #33 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-16
02:33 ---
Subject: Re: wo_prof_two_strs.c:56: internal compiler error: in
find_new_var_of_type, at ipa-struct-reorg.c:605
> I gave it another push. The following is a patch solving inconsistency of the
> data struc
--- Comment #21 from gustavodn at gmail dot com 2008-01-16 01:52 ---
(In reply to comment #20)
> Anyway, if you really want to believe that printf("%s\n",s) and puts(s) should
> not have the same effect for defined behaviour, then we will have to agree to
> disagree.
That's confused, wh
--- Comment #46 from bergner at gcc dot gnu dot org 2008-01-16 01:51
---
This is fixed on mainline and we're not going to backport it to 4.2, so I'm
changing the target milestone.
--
bergner at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-01-16 01:48
---
I will investigate this further. This has come up before in other previous
reports.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34795
--- Comment #2 from kendrick dot killian at colostate dot edu 2008-01-16
00:50 ---
Subject: Re: inquire statement , direct= specifier incorrectly returns YES
There is a three part definition of correct answer that mirrors
arguments in the formatted/unformatted thread. Noting that the
--- Comment #3 from gin at mo dot msk dot ru 2008-01-16 00:49 ---
Subject: Re: wrong code for dereferencing type-punned pointer
> obviously violating c aliasing rules here.
Certainly. Was quite explicit about that:
That is,
`-fno-strict-aliasing' no longer disables optimizations
--- Comment #22 from peeterj at ca dot ibm dot com 2008-01-16 00:04 ---
re: Fixed on the mainline. I'm not sure we want to put this on the other
branches.
Not knowing the gcc code in question, I can't comment on how much potential
regression risk this fix will introduce. Assuming it's
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-15 23:02 ---
I don't think you can disable these types. If your target does not support
them, something is wrong.
How is char defined for your target? sizeof(char) needs to be 1 to be
complaint to C.
--
pinskia at gcc do
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-15 23:03 ---
Flixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIR
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-01-15 22:47 ---
unsigned char *extptr;
((aliasing_u) &extptr)->p = c;
Well you are obviously violating c aliasing rules here. the warning does not
happen is a different issue.
--
pinskia at gcc dot gnu dot org chang
Building c++ fails with:
...
/opt/gcc/i686-darwin/./prev-gcc/xgcc -B/opt/gcc/i686-darwin/./prev-gcc/
-B/opt/gcc/gcc4.3w/i686-apple-darwin9/bin/ -c -g -O2 -fomit-frame-pointer
-DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wmissing-format-attr
The test program gives the message:
c_tests_cg0018.f:28.20:
TLA1L(NFV1) = UDA1R
1
Error: Can't convert TYPE(seq) to TYPE(unseq) at (1)
Where NFV1 is an integer scalar array.
I believe the error is incorrect. This is from the SHAPE95 test suite.
This test was contentious
--- Comment #20 from manu at gcc dot gnu dot org 2008-01-15 21:49 ---
(In reply to comment #19)
> (In reply to comment #17)
> > This will be fixed yesterday if printf("%s\n", s) were equivalent to
> > puts(s) in
> > glibc.
>
> [+] The standard requires them to be equivalent? Per standa
I am currently having fun porting code to the NEC SX-6 vector processor.
The native compiler on that platform (as well as NEC's cross compiler)
does not support INTEGER*1.
It would be useful to have a flag to mimic this behavior by disabling
the above mentioned types for declarations, along with t
--- Comment #1 from gin at mo dot msk dot ru 2008-01-15 21:41 ---
Created an attachment (id=14944)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14944&action=view)
preprocessed code in question
Instead of `extptr', uninitialized value is passed to
`handle_out_external'.
--
ht
No simpler C code is (yet) known to hit this. On request will
describe actual package where similar code occurs.
In the attached preprocessed code, incorrect arg 3, `%rdx', is passed
to `handle_out_external'. Code expects this value, `extlen', to be
the same as value that is returned from `__bui
--- Comment #5 from tkoenig at gcc dot gnu dot org 2008-01-15 21:24 ---
Fixed on trunk.
Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-01-15 21:22 ---
Subject: Bug 34671
Author: tkoenig
Date: Tue Jan 15 21:22:07 2008
New Revision: 131553
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131553
Log:
2008-01-15 Thomas Koenig <[EMAIL PROTECTED]>
PR li
gcc-3.x gives this information but gcc-4.2 does not.
In the shell snippit below, the unknown symbol name should be
embedded in the gcc-4.2 error lines as it is done in gcc-3.4.
$ gcc-3.4 foo.f
undeclared_variable(index)=0.0
^
Invalid declaration of ... 'undeclare
--- Comment #19 from gustavodn at gmail dot com 2008-01-15 21:08 ---
(In reply to comment #17)
> This will be fixed yesterday if printf("%s\n", s) were equivalent to puts(s)
> in
> glibc.
[+] The standard requires them to be equivalent? Per standard, they can't be
equivalent if both ar
--- Comment #7 from dgregor at gcc dot gnu dot org 2008-01-15 20:59 ---
Fixed in mainline
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #6 from dgregor at gcc dot gnu dot org 2008-01-15 20:57 ---
Subject: Bug 34399
Author: dgregor
Date: Tue Jan 15 20:56:55 2008
New Revision: 131552
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131552
Log:
2008-01-15 Douglas Gregor <[EMAIL PROTECTED]>
PR c
--- Comment #1 from dick dot hendrickson at gmail dot com 2008-01-15 20:49
---
Another example in executable code
MODULE s_TESTS
IMPLICIT CHARACTER (P)
CONTAINS
subroutine simple (u,j1)
optional :: j1
if (present (j1)) stop
end subroutine
--- Comment #18 from manu at gcc dot gnu dot org 2008-01-15 20:48 ---
There is an explanation for the optimisation, a potential fix [*] and there is
a workaround.
[*] http://sourceware.org/bugzilla/show_bug.cgi?id=5618
--
manu at gcc dot gnu dot org changed:
What|Rem
This should have already been reported, but I cannot find any trace of it.
gcc.dg/Warray-bounds.c fails on all the platforms I have looked at:
FAIL: gcc.dg/Warray-bounds.c (test for warnings, line 59)
FAIL: gcc.dg/Warray-bounds.c (test for warnings, line 65)
FAIL: gcc.dg/Warray-bounds.c (test
--- Comment #14 from tbptbp at gmail dot com 2008-01-15 20:07 ---
I keep bumping into this issue and i'd really appreciate a clue about how to
workaround for the time being.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34774
--- Comment #32 from dominiq at lps dot ens dot fr 2008-01-15 20:03 ---
With the patches in comments #11 and 31, the error disappears in 32 bit mode on
Intel Darwin9 (as with #11 alone), now appears in 64 bit mode with the other
errors already reported:
FAIL: gcc.dg/struct/wo_prof_globa
--- Comment #3 from burnus at gcc dot gnu dot org 2008-01-15 19:30 ---
*** Bug 34788 has been marked as a duplicate of this bug. ***
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-15 19:30 ---
Confirmed. Your bugreport was there even before mine, but since my contains a
link to the patch I mark yours as duplicate.
Thanks for finding the bug.
> This diagnostic is (a) misleading - b is NOT an assumed-shape
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-01-15 19:19 ---
(In reply to comment #5)
> This is an ice-on-valid, so it should probably be a P2.
Well it is both depending on -std= settings.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-15 19:12 ---
| correct output (produced by g77)
| default open drct=NO opened= T access=SEQUENTIAL
| Sequent open drct=NO opened= T access=SEQUENTIAL
| direct open drct=YES opened= T access=DIRECT
How do you know which
--- Comment #17 from manu at gcc dot gnu dot org 2008-01-15 18:51 ---
This will be fixed yesterday if printf("%s\n", s) were equivalent to puts(s) in
glibc.
Also there is a way to disable the optimization: "-fno-builtin-printf".
People that don't rely on undefined behaviour don't deser
--- Comment #5 from dgregor at gcc dot gnu dot org 2008-01-15 18:50 ---
Subject: Bug 34751
Author: dgregor
Date: Tue Jan 15 18:49:47 2008
New Revision: 131548
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131548
Log:
2008-01-15 Douglas Gregor <[EMAIL PROTECTED]>
PR c
--- Comment #4 from dgregor at gcc dot gnu dot org 2008-01-15 18:50 ---
Fixed in mainline
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #9 from alexandre dot nunes at gmail dot com 2008-01-15 18:12
---
(In reply to comment #8)
> Fixed on the trunk.
>
For anyone else wondering, this is still reproductible on vanilla gcc 4.2.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28755
--- Comment #6 from dgregor at gcc dot gnu dot org 2008-01-15 18:09 ---
Fixed in mainline
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #5 from dgregor at gcc dot gnu dot org 2008-01-15 18:09 ---
Fixed in mainline
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #5 from dgregor at gcc dot gnu dot org 2008-01-15 18:09 ---
Fixed in mainline
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #4 from dgregor at gcc dot gnu dot org 2008-01-15 18:08 ---
Subject: Bug 34102
Author: dgregor
Date: Tue Jan 15 18:08:00 2008
New Revision: 131547
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131547
Log:
2008-01-15 Douglas Gregor <[EMAIL PROTECTED]>
PR c
--- Comment #5 from dgregor at gcc dot gnu dot org 2008-01-15 18:08 ---
Subject: Bug 34103
Author: dgregor
Date: Tue Jan 15 18:08:00 2008
New Revision: 131547
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131547
Log:
2008-01-15 Douglas Gregor <[EMAIL PROTECTED]>
PR c
--- Comment #9 from dgregor at gcc dot gnu dot org 2008-01-15 18:08 ---
Subject: Bug 34051
Author: dgregor
Date: Tue Jan 15 18:08:00 2008
New Revision: 131547
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131547
Log:
2008-01-15 Douglas Gregor <[EMAIL PROTECTED]>
PR c
--- Comment #4 from dgregor at gcc dot gnu dot org 2008-01-15 18:08 ---
Subject: Bug 34055
Author: dgregor
Date: Tue Jan 15 18:08:00 2008
New Revision: 131547
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131547
Log:
2008-01-15 Douglas Gregor <[EMAIL PROTECTED]>
PR c
--- Comment #8 from dgregor at gcc dot gnu dot org 2008-01-15 18:08 ---
Fixed in mainline
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #6 from dgregor at gcc dot gnu dot org 2008-01-15 18:05 ---
Fixed on mainline
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #16 from alexandre dot nunes at gmail dot com 2008-01-15 18:03
---
vanilla gcc 4.2.2 seems to compile this testcase ok (all five symbols are
emmited and externally visible, no warnings)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28744
--- Comment #2 from burnus at gcc dot gnu dot org 2008-01-15 18:00 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00656.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34796
--- Comment #5 from dgregor at gcc dot gnu dot org 2008-01-15 18:00 ---
Subject: Bug 34314
Author: dgregor
Date: Tue Jan 15 17:59:44 2008
New Revision: 131546
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131546
Log:
2008-01-15 Douglas Gregor <[EMAIL PROTECTED]>
PR c+
--- Comment #5 from alexandre dot nunes at gmail dot com 2008-01-15 17:58
---
(In reply to comment #4)
> won't fix in GCC-4.0.x. Adjusting milestone.
>
For anyone interested, I think this is fixed for at least gcc 4.2.2; I couldn't
reproduce it.
--
alexandre dot nunes at gmail do
--- Comment #7 from alexandre dot nunes at gmail dot com 2008-01-15 17:55
---
(In reply to comment #6)
> This seems to work as of gcc 4.2.2 (vanilla), using the original commands to
> reproduce. Anyone denies/confirms this?
>
... and please see bug 34800 .
--
http://gcc.gnu.org/b
$ cat pqp.c
typedef union {
struct
{
unsigned char d;
};
unsigned char a, b;
} test_type;
extern test_type whatever;
$ gcc -c pqp.c
$ gcc --combine -c pqp.c pqp.c
pqp.c:9: error: conflicting types for whatever
pqp.c:9: error: previous declaration of whatever was here
T
--- Comment #6 from alexandre dot nunes at gmail dot com 2008-01-15 17:40
---
This seems to work as of gcc 4.2.2 (vanilla), using the original commands to
reproduce. Anyone denies/confirms this?
--
alexandre dot nunes at gmail dot com changed:
What|Removed
--- Comment #16 from gustavodn at gmail dot com 2008-01-15 17:20 ---
"Glibc being Linux being the world" is not really relevant, IMHO. What is
relevant is printf() (or any function) is, fundamentally, implemented by
library, not by compiler, so compiler should not prevent library from de
--- Comment #4 from dgregor at gcc dot gnu dot org 2008-01-15 16:59 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00650.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34103
--- Comment #3 from dgregor at gcc dot gnu dot org 2008-01-15 16:59 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00650.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34102
--- Comment #3 from dgregor at gcc dot gnu dot org 2008-01-15 16:59 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00650.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34055
--- Comment #35 from manu at gcc dot gnu dot org 2008-01-15 16:44 ---
(In reply to comment #33)
> Yes, this is what I understand. I think we need a new flag specifying
> if in the source the 'inline' keyword was used and solely use that for
> inline warning purposes. (That is, I would
--- Comment #5 from dgregor at gcc dot gnu dot org 2008-01-15 16:40 ---
This is an ice-on-valid, so it should probably be a P2.
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
-
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--- Comment #7 from dgregor at gcc dot gnu dot org 2008-01-15 16:10 ---
Subject: Bug 33964
Author: dgregor
Date: Tue Jan 15 16:09:28 2008
New Revision: 131544
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131544
Log:
2008-01-15 Douglas Gregor <[EMAIL PROTECTED]>
PR c+
--- Comment #6 from dgregor at gcc dot gnu dot org 2008-01-15 16:09 ---
Fixed on mainline
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #9 from dgregor at gcc dot gnu dot org 2008-01-15 16:07 ---
Fixed in mainline
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #8 from dgregor at gcc dot gnu dot org 2008-01-15 16:07 ---
Subject: Bug 34052
Author: dgregor
Date: Tue Jan 15 16:06:48 2008
New Revision: 131543
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131543
Log:
2008-01-15 Douglas Gregor <[EMAIL PROTECTED]>
PR c+
--- Comment #34 from hubicka at ucw dot cz 2008-01-15 15:59 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] -Winline does not respect
-fno-default-inline
> Yes, this is what I understand. I think we need a new flag specifying
> if in the source the 'inline' keyword was used and solely u
--- Comment #33 from rguenther at suse dot de 2008-01-15 15:54 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] -Winline
does not respect -fno-default-inline
On Tue, 15 Jan 2008, hubicka at gcc dot gnu dot org wrote:
> --- Comment #32 from hubicka at gcc dot gnu dot org 2008-01-15
--- Comment #32 from hubicka at gcc dot gnu dot org 2008-01-15 15:47
---
I am bit confused by logic of code here. Middle end now ingore DECL_INLINE
consistently, it is still arround since it affect some instantiation decisions
in C++ FE. Does fno-default-inline work? I think only way
--- Comment #3 from aph at gcc dot gnu dot org 2008-01-15 15:32 ---
*** Bug 32484 has been marked as a duplicate of this bug. ***
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from aph at gcc dot gnu dot org 2008-01-15 15:32 ---
*** This bug has been marked as a duplicate of 33639 ***
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from aph at gcc dot gnu dot org 2008-01-15 15:32 ---
.
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
Status|RESOLVED
In the example below gcc reports an assertion failure, when warnings are
switched on.
> gcc -c -gnatwa status.ads
fails, while
> gcc -c status.ads
is working.
The snapshot 4.3.0 20070921 is correctly warning 'no component clause given for
"C" declared at line 12' while later snapshots (e.g. 4.
--- Comment #31 from rguenth at gcc dot gnu dot org 2008-01-15 15:22
---
Created an attachment (id=14943)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14943&action=view)
other approach to supress the warnings
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18071
--- Comment #14 from burnus at gcc dot gnu dot org 2008-01-15 15:21 ---
Check that the renamed imported operator is not imported again, see PR 33541.
If I recall correctly, this part is missing for the patch in PR 33541
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31298
--- Comment #30 from rguenth at gcc dot gnu dot org 2008-01-15 15:21
---
I suggest to tag the DECL with TREE_NO_WARNING if -fno-default-inline is set
and
check this.
On the trunk the functions are inlined anyway, because we inline small
functions by default (and the functions are pure
--- Comment #3 from aph at gcc dot gnu dot org 2008-01-15 15:13 ---
Fixed in trunk.
Tested:
zorro:~ $ ~/gcc/trunk/install/bin/gcj -shared -Wl,-Bsymbolic -fPIC
-findirect-dispatch -fjni -g0 -O0 -mtune=nocona -march=nocona -pipe -w
-save-temps -o libjunit.jar.so junit.jar
gcj: warning: -
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|enhancement |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33699
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-15 15:01 ---
I think the frontend should reject identifiers in declarations that touch
the __builtin_ namespace.
The regression status is dubious (it probably 'regressed' at the point
the builtin was introduced).
--
rguenth
--- Comment #2 from debian-gcc at lists dot debian dot org 2008-01-15
14:54 ---
confirmed.
Matthias
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32484
--- Comment #6 from rguenther at suse dot de 2008-01-15 14:54 ---
Subject: Re: warning: 'areg' may be used uninitialized
in this function
On Tue, 15 Jan 2008, j at uriah dot heep dot sax dot de wrote:
> --- Comment #5 from j at uriah dot heep dot sax dot de 2008-01-15 14:38
> -
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-01-15 14:44 ---
Reduced testcase:
int f(char *device)
{
return device == ((char *)0 + ~0UL);
}
for building the POINTER_PLUS_EXPR we convert the unsigned offset to
sizetype which causes the double-int (-1, 0) to sign-extend to (
--- Comment #5 from j at uriah dot heep dot sax dot de 2008-01-15 14:38
---
(In reply to comment #4)
> Oh, indeed - it also needs PR30317 fixed. (the attached patches therein
> probably no longer apply)
I applied the second of the attached patches there. It applies cleanly,
but stil
--- Comment #31 from olga at gcc dot gnu dot org 2008-01-15 14:11 ---
I gave it another push. The following is a patch solving inconsistency of the
data structures in struct reorg, and releasing comparison with 0. Please try it
together with the Richard's patch. It should give extra XPAS
--- Comment #25 from rguenth at gcc dot gnu dot org 2008-01-15 14:05
---
Unassigning. I like to have help from somebody knowing how to debug the
libjava failures. The only bitfields are defined in jvmti.h.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-15 14:04 ---
>From the Fortran 2003 standard ("12.4.1.2 Actual arguments associated with
dummy data objects")
"If the actual argument is scalar, the corresponding dummy argument shall be
scalar unless the actual argument is of ty
--- Comment #4 from rguenther at suse dot de 2008-01-15 13:27 ---
Subject: Re: warning: 'areg' may be used uninitialized
in this function
On Tue, 15 Jan 2008, j at uriah dot heep dot sax dot de wrote:
> --- Comment #3 from j at uriah dot heep dot sax dot de 2008-01-15 12:54
> -
--- Comment #24 from rguenth at gcc dot gnu dot org 2008-01-15 13:23
---
So the issue is that for
void foo(unsigned int) (i)
{
i.0;
:
i.0 = () i;
sv.f2 = i.0;
if ((unsigned int) i.0 != 0)
we neither emit code for the narrowing nor for the widening, but only
for the bitfield
--- Comment #2 from singler at gcc dot gnu dot org 2008-01-15 13:20 ---
There are two general options to fix this bug:
1. Introduce a global variable, to be compiled into libstdc++.a and
libstdc++.so.
2. Do the "template trick", i. e. pseudo-parametrize Settings as
template class, to lea
--- Comment #1 from singler at gcc dot gnu dot org 2008-01-15 13:15 ---
First of all, we should get rid of these many static variables in the Settings
class, and replace them by usual member variables. Then, there should be one
static/global instance of this Settings class.
The question
In settings.h, the Settings class (containing only static variables) is
encapsulated in an anonymous namespace. This makes the linker think of a
distinct class for each compilation unit. As as result, settings changed in one
.cpp file won't affect code from another .cpp file, although they should h
--- Comment #6 from singler at gcc dot gnu dot org 2008-01-15 13:05 ---
No further objections.
--
singler at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from j at uriah dot heep dot sax dot de 2008-01-15 12:54
---
(In reply to comment #2)
> The fix for PR14495 will likely fix this (by removing the default case again).
Alas, no, it doesn't. I applied that patch (and the one it depends one
mentioned in the article), rebu
1 - 100 of 119 matches
Mail list logo
