[Bug c++/30331] New: a const member function can call a non_const member function without const_cast
//const_test.cpp
struct A
{
A(unsigned int n)
{
aa=n;
}
void const_fun() const
{
static_cast(*this).fun(); //ok
// fun(); //err
}
void fun()
{
}
unsigned int aa;
};
int main()
{
const A a(56);
a.const_fun();
}
// g++ const_test.cpp
// ./a.out
//we should forbid call non_const member function in a const member function
without an explicit const_cast ,isn't it?
--
Summary: a const member function can call a non_const member
function without const_cast
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hongleij at 126 dot com
GCC host triplet: all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30331
[Bug tree-optimization/29925] Wrong code with -ftree-vectorize
--- Comment #8 from jean-marc dot valin at usherbrooke dot ca 2006-12-30 06:42 --- Shouldn't the priority of this bug be increased considering that it produces wrong code on valid input and the affected package (Speex) is included in most Linux distributions (fortunately most of these don't enable -ftree-vectorize by default I think)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29925
[Bug debug/8354] Incorrect DWARF-2/3 emitted for const + array
--- Comment #11 from gary at intrepid dot com 2006-12-30 06:34 --- I looked into fixing GCC's DWARF 2 generation for types that are qualified (for example, "const" and "volatile", and in the case of UPC, "shared", "strict", and "relaxed") in order to ensure that GDB has an accurate understanding of when a particular object's type is qualified: http://sourceware.org/ml/gdb/2006-11/msg00185.html http://sourceware.org/ml/gdb/2006-12/msg00133.html http://sourceware.org/ml/gdb/2006-12/msg00177.html In the latter e-mail reply, copied below, I sketched out three possible ways to fix the DWARF 2 information that GCC presently generates for qualified types. It would be great if someone familiar with the GCC front-end reviews my analysis, and either corrects it, or improves upon the suggested approaches. Additionally, I'm a bit unsure on what the "correct" DWARF 2 information should look like in all cases. For example should the members/fields of a struct/union that is C-V qualified also be individually qualified? One commercial compiler that I tried did not do this. Alternatively, would all the possible DWARF 2 type qualifier representation issues best be handled within GDB? This would move the problem from GCC back to GDB, and at the same time improve upon inter-operability. --- copy of http://sourceware.org/ml/gdb/2006-12/msg00177.html --- Jim Blandy wrote: > > "Gary Funck" <[EMAIL PROTECTED]> writes: > > The main difficulty is that GCC doesn't create new qualified > > types for declarations. Rather, it sets TREE_READONLY() > > and TREE_THIS_VOLATILE() in the DECL node for declarations > > such as: > > > >volatile int A[10]; > > Ugh. That's a shame. Can't dwarf2out.c fix things up as it builds > the tree of struct die_structs from the GCC 'tree' type tree? In theory, it should be possible. I worked on this a bit, but I think to do it right, this fix will require contribution/direction from someone more conversant in the GCC front-end, and more knowledgeable about how the other language front-ends use both the DWARF 2 generation routines, and the extent to which they depend upon the type information remaining in its current form. Three approaches to fixing the front end to create appropriate DWARF 2 information come to mind: (1) Change the GCC front-end, so that when it creates type information and associates the type information with a declaration that it fully qualifies the type definition, in a way that preserves language semantics, yet also ensures that the correct DWARF 2 information is generated for qualified types. (2) Create the fully qualified type definition in dwarf2out.c (probably in routines that handle DECL items such as gen_formal_parameter_die(), gen_variable_die() and gen_field_die()). There are two likely sub-approaches: (i) keep this fully qualified type definition on the side, parallel to the existing type definition structure, or (ii) smash the new fully qualified type into the DECL node's TREE_TYPE() value. Keeping a parallel definition may be difficult because various parts of dwarfout.c may need to refer back to the DECL node's type value, and all places that do this will have to be found and fixed. Cross-type references and typedef's create another set of problems. Rewriting the declaration's type value is the most straightforward, but runs the risk of violating various assumptions made by the language front-ends, and will require a rather elaborate "deep copy" mechanism to make sure the fix up is done correctly. (3) Run a final pass over the internal DWARF tree built within dwarfout.c to fix up the type qualifiers, basically propagating the const_ and volatile_ qualifiers down to lower levels as required. This is probably doable, but will slow down DWARF generation for all compilations, even if most compilations seldom use "const" and "volatile" (and other qualifiers, such as UPC's "shared", "strict", and "relaxed"). In this case, it seems that dwarf2out.c is fixing representation issues that more correctly should be solved in the front-end. Given the tradeoffs, choice (1) above, where the type description is fully qualified at the time the type is bound to the DECL item, seems more correct, but may impact the correct operation of the various language front-ends and therefore will require more care and more study. Choice (2) is perhaps a bad compromise, and choice (3) is likely workable, but kludgy. -- gary at intrepid dot com changed: What|Removed |Added CC||gary at intrepid dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8354
[Bug driver/30330] -Wdeprecated is not documented
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-30 00:55 --- Confirmed, I thought I saw this somewhere else too but I cannot find it right now. -- 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 |2006-12-30 00:55:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30330
[Bug boehm-gc/30327] The make script periodically thinks my 7450 is an 8540
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-12-30 00:22 --- (In reply to comment #2) The real problem behind this has already been fixed on the mainline. It was an automake issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30327
[Bug boehm-gc/30327] The make script periodically thinks my 7450 is an 8540
--- Comment #2 from trog24 at comcast dot net 2006-12-29 23:41 --- I was able to make and install via --disable-multilib as suggested by pinskia which reduces the problem to minor since a work around exists; however, the multilib should be disabled automatically if gcc is not being installed as a cross compiler. I thank you for the assistance. -- trog24 at comcast dot net changed: What|Removed |Added Severity|major |minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30327
[Bug driver/30330] New: -Wdeprecated is not documented
There is one mention of -Wdeprecated in the manual, but it is not documented anywhere. -- Summary: -Wdeprecated is not documented Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver 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=30330
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #25 from dberlin at gcc dot gnu dot org 2006-12-29 20:28
---
So the solution for 4.3 here, from what i understand, seems pretty easy at the
tree level, no matter what reading we wish to give this.
If we add a placement_new_expr, and not try to revisit our interpretation of
the standard, we can just DTRT and fix placement new. This would be best for
optimizations, and IMHO, for users.
Otherwise, we are at the point in 4.3 (In the past month this has changed, it's
not really possible to backport this stuff to 4.2 very easily) where we have
two types of variables from an aliasing perspective:
SSA variables
Global/static variables
For both, we know if they are *actually* dereferenced (and not just escaping to
a call, and thus "possibly dereferenced").
SSA variables never escape, and all casting will have been done in a statement
that leads to the SSA variable. The SSA variable will only appear on the LHS
once The only time they are currently pruned using TBAA information is at the
dereference site (IE b_3 = *foo_5). This seems right to me, as it should have
the correct dynamic type at this point, and anywhere else we prune using TBAA
info without an explicit dereference is a bug. Under the reading that stores
with different types are legal and start new object lifetimes, we would have to
change the pruning to only prune at *load* dereference sites.
Under this reading, we would never be able to reorder stores based on TBAA
because they are never illegal under the reading that they start new object
lifetimes.
For globals/statics ("bare variables"), we currently will prune even if they
are only "maybe-dereferenced". I think this is a bug under our current
interpretation, and we should fix it.
Because bare variables may appear on the LHS multiple times, we have a couple
options, depending on the readings.
Note that any of these require IPA and in the case of true globals,
whole-program mode, in order to *ever be able to reorder a store/load based on
TBAA*.
We could gather the types that occur, and prune at load dereference sites
assuming it is one of these, *if the variable does not escape the module*.
Most statics do escape through library calls that we could add attributes to,
but don't escape otherwise.
So without attributing, you will lose roughly 90-100% of TBAA enabled
store/load reordering of globals and statics.
With attributing, you will probably lose 10-20% of TBAA enabled *load*
reordering for statics, 100% of TBAA enabled reordering for globals (unless you
promote them), and 100% of TBAA enabled store reordering.
We could disable TBAA entirely for globals and statics, and you will just lose
100% everywhere :)
TBAA accounts for about 7-25% of alias disambiguations in the real world for C
and C++ (combined). This is according to both papers published by Intel about
ICC, papers published by MS about VC, papers published by IBM about XLC, and
testing of Google's codebase with and without -fno-strict-aliasing (with the
caveat that we know our codebase is not entirely strict aliasing safe)
That said, it is wildly variant from program to program as to how effective it
is, and pretty unpredictable just from staring at code.
I'll leave the decision about what we want to do up to someone else, i'm just
explaining the aliasing options we have.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug middle-end/7651] Define -Wextra strictly in terms of other warning flags
--- Comment #15 from patchapp at dberlin dot org 2006-12-29 19:30 --- Subject: Bug number PR7651 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01842.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7651
[Bug fortran/25392] ICEs with -ff2c
--- Comment #11 from tobi at gcc dot gnu dot org 2006-12-29 18:56 --- Fixed in 4.2 and trunk. -- tobi at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25392
[Bug fortran/25392] ICEs with -ff2c
--- Comment #10 from tobi at gcc dot gnu dot org 2006-12-29 18:54 --- Subject: Bug 25392 Author: tobi Date: Fri Dec 29 18:54:41 2006 New Revision: 120274 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120274 Log: Backport from trunk: fortran/ PR fortran/25392 * trans-stmt.c (gfc_trans_return): Fix comment formatting. * trans-types.c (gfc_sym_type): Don't return early for functions. Remove special handling for -ff2c. (gfc_get_function_type): Add special handling for -ff2c. * trans-decl.c (gfc_create_function_decl): Fix comment formatting. (gfc_get_fake_result_decl): Make sure we get the right type for functions. (gfc_generate_function_code): Convert type of result variable to type of function. testsuite/ PR fortran/25392 * gfortran.dg/f2c_8.f90: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/f2c_8.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/trans-decl.c branches/gcc-4_2-branch/gcc/fortran/trans-stmt.c branches/gcc-4_2-branch/gcc/fortran/trans-types.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25392
[Bug middle-end/30286] [4.1 Regression] Segfault with -O2 -ftrapv
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||12/msg01838.html Status|NEW |ASSIGNED Last reconfirmed|2006-12-24 04:41:47 |2006-12-29 18:45:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30286
[Bug middle-end/7651] Define -Wextra strictly in terms of other warning flags
--- Comment #14 from patchapp at dberlin dot org 2006-12-29 18:35 --- Subject: Bug number PR7651 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01837.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7651
[Bug bootstrap/29544] [4.2 Regression] Not building with checking in stage1
--- Comment #9 from bonzini at gnu dot org 2006-12-29 17:47 --- committed -- bonzini at gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29544
[Bug bootstrap/29544] [4.2 Regression] Not building with checking in stage1
--- Comment #8 from bonzini at gnu dot org 2006-12-29 17:47 --- Subject: Bug 29544 Author: bonzini Date: Fri Dec 29 17:47:06 2006 New Revision: 120272 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120272 Log: 2006-12-29 Paolo Bonzini <[EMAIL PROTECTED]> PR bootstrap/29544 * Makefile.def (flags_to_pass): Add STAGE1_CHECKING. (bootstrap_stage): Add STAGE1_CHECKING to stage1 configure flags, move here comment from Makefile.tpl. * Makefile.tpl: Move some definitions higher in the file. (STAGE1_CHECKING): New. * configure.in: Add --enable-stage1-checking. Disable --enable-werror on release branches. gcc: 2006-12-29 Paolo Bonzini <[EMAIL PROTECTED]> PR bootstrap/29544 * gcc/Makefile.in (STAGE1_CHECKING): Rename to... (STAGE1_CHECKING_CFLAGS): ... this. Modified: branches/gcc-4_2-branch/ChangeLog branches/gcc-4_2-branch/Makefile.def branches/gcc-4_2-branch/Makefile.in branches/gcc-4_2-branch/Makefile.tpl branches/gcc-4_2-branch/configure branches/gcc-4_2-branch/configure.in branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29544
[Bug c++/16625] Discarded Linkonce sections in .rodata
--- Comment #33 from pfaff at mcmaster dot ca 2006-12-29 17:40 --- While trying to build some C++ code with g++-3.3.6 we encountered error messages similar to those mentioned in earlier comments in this discussion: `xxx' referenced in section `.rodata' of somefile.o: defined in discarded section `.gnu.linkonce.t._zzz' of something.o Searching for solutions to this error message led us to this gcc-bugzilla bug #16625 discussion. We were able to eliminate these error messages and successfuly compile our code with g++-3.3.6 by using the '-frepo' option in our g++ compiles. I understand that this may not be the ultimate solution to the bug(s) being discussed here, but since we ended up here when searching for this particular error message, I'm adding this comment in case it helps other people. -- pfaff at mcmaster dot ca changed: What|Removed |Added CC||pfaff at mcmaster dot ca http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16625
[Bug preprocessor/28227] valid #ifdef rejected
--- Comment #2 from patchapp at dberlin dot org 2006-12-29 17:35 --- Subject: Bug number PR preprocessor/28227 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01835.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28227
[Bug fortran/23060] %VAL, %REF and %DESCR constructs not implemented
--- Comment #12 from patchapp at dberlin dot org 2006-12-29 17:25 --- Subject: Bug number PR23060 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01834.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23060
[Bug bootstrap/28472] -B$(build_tooldir)/bin/
--- Comment #7 from gin at mo dot msk dot ru 2006-12-29 14:35 ---
Subject: Re: -B$(build_tooldir)/bin/
> Can you give the output of the original confgure which should show you which
> ld/as GCC is going to use?
No. Version 4 just does not build on that system at all (or this
requires essentially reimplementing the support of the system in gcc).
So the question must be about the same older one that I already wrote
about. It does not report that - unlike 4.0.2, 4.1.1.
That is, in it `gcc/config.log' says nothing about that. Re- ran
`gcc/configure' with the same options as `config.status --r' would do
(created another directory for that). Neither it said anything about
that. It would not even report is the linker it found gnu one or not.
> By default the toplevel configure looks into PREFIX/${TARGET} for ld/as.
Looks like `xgcc' of old version actually does that. Even without
that `-B' option, but with `ld' in that directory existing, it
outputs:
PREFIX/lib/gcc-lib/i586-pc-sco3.2v5.0.4/3.0.3/../../../../i586-pc-sco3.2v5.0.4/bin/ld:
unrecognized option '-YP,/usr/ccs/lib:/lib:/usr/lib'
PREFIX/lib/gcc-lib/i586-pc-sco3.2v5.0.4/3.0.3/../../../../i586-pc-sco3.2v5.0.4/bin/ld:
use the --help option for usage information
collect2: ld returned 1 exit status
That is, looked for `ld' in in directory based on its own installation
one. This is equivalent of `-B$(build_tooldir)/bin/', and does
exactly the same harm.
The worst is that could not have foreseen that by documentation. This
directory was even missing in in `--with-as'
description in that version of `gcc/doc/install.texi'. That file
would mention only
@[EMAIL PROTECTED]/lib/gcc-lib/@var{target}/@var{version}} and
.
> use --with-ld/--with-as.
It is a workaround at best (will try it for 3.0.3). Programs
installed even in the same PREFIX are not necessarily intended for
gcc. Certainly options passed to program must match the type of
program configuration chose. The very use of gnu ld on non- gnu
system when neither `--with-ld' nor `--with-gnu-ld' are specified is
at least suspicious and should issue warning.
The lack of a standard way to figure which `as', `ld' are used is also
bug, and already fixed in 4.
> No, I still say you are incorrect.
Thus partly agree with that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28472
[Bug libstdc++/30226] FAIL: abi_check
-- pcarlini at suse dot de changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30226
[Bug libstdc++/30226] FAIL: abi_check
--- Comment #3 from pcarlini at suse dot de 2006-12-29 12:53 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30226
[Bug libstdc++/30226] FAIL: abi_check
--- Comment #2 from paolo at gcc dot gnu dot org 2006-12-29 12:52 --- Subject: Bug 30226 Author: paolo Date: Fri Dec 29 12:52:14 2006 New Revision: 120261 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120261 Log: 2006-12-29 Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/30226 * config/abi/pre/gnu.ver: Do not export ctype::widen. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/abi/pre/gnu.ver -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30226
[Bug fortran/24325] ICE in gfc_get_function_type
--- Comment #4 from pault at gcc dot gnu dot org 2006-12-29 12:16 --- I just submitted the patch. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-07-19 09:07:02 |2006-12-29 12:16:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24325
[Bug fortran/24325] ICE in gfc_get_function_type
--- Comment #3 from patchapp at dberlin dot org 2006-12-29 12:00 --- Subject: Bug number PR24325 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01813.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24325
[Bug libfortran/30162] I/O with named pipes does not work
--- Comment #6 from tkoenig at gcc dot gnu dot org 2006-12-29 09:51 --- (In reply to comment #5) > I will work at it. Thanks, I'll be happy to assist with discussions and review. (Those who can, fix; those who can't, review :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162
[Bug fortran/30321] program crash for SUM applied to zero-size array
--- Comment #3 from tkoenig at gcc dot gnu dot org 2006-12-29 09:50 --- I'll do this. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-12-28 21:20:56 |2006-12-29 09:50:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30321
[Bug fortran/30321] program crash for SUM applied to zero-size array
--- Comment #2 from toon at moene dot indiv dot nluug dot nl 2006-12-29 09:03 --- *** Bug 30320 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30321
[Bug fortran/30320] program crash for SUM applied to zero-size array
--- Comment #1 from toon at moene dot indiv dot nluug dot nl 2006-12-29 09:03 --- *** This bug has been marked as a duplicate of 30321 *** -- toon at moene dot indiv dot nluug dot nl changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30320
[Bug middle-end/30143] [4.2 only] OpenMP can produce invalid gimple
--- Comment #10 from jakub at gcc dot gnu dot org 2006-12-29 08:43 --- 4.2 version of the patch at http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01504.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30143
[Bug preprocessor/29612] [4.0 Regression] gcc --save-temps does not give "multi-character character constant" error
--- Comment #5 from jakub at gcc dot gnu dot org 2006-12-29 08:25 --- Fixed in 4.3/4.2/4.1. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.0.4 4.1.2 4.2.0 4.3.0 |4.0.4 4.1.1 Known to work|3.4.0 |3.4.0 4.1.2 4.2.0 4.3.0 Summary|[4.0/4.1/4.2/4.3 Regression]|[4.0 Regression] gcc --save- |gcc --save-temps does not |temps does not give "multi- |give "multi-character |character character |character constant" error |constant" error http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29612
[Bug preprocessor/29612] [4.0/4.1/4.2/4.3 Regression] gcc --save-temps does not give "multi-character character constant" error
--- Comment #4 from jakub at gcc dot gnu dot org 2006-12-29 08:17 --- Subject: Bug 29612 Author: jakub Date: Fri Dec 29 08:17:43 2006 New Revision: 120259 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120259 Log: PR preprocessor/29612 * directives.c (do_linemarker): Set pfile->buffer->sysp always, not only when new_sysp is non-zero. * gcc.dg/cpp/pr29612-1.c: New test. * gcc.dg/cpp/pr29612-2.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/cpp/pr29612-1.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/cpp/pr29612-2.c Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/libcpp/ChangeLog branches/gcc-4_1-branch/libcpp/directives.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29612
[Bug preprocessor/29612] [4.0/4.1/4.2/4.3 Regression] gcc --save-temps does not give "multi-character character constant" error
--- Comment #3 from jakub at gcc dot gnu dot org 2006-12-29 08:16 --- Subject: Bug 29612 Author: jakub Date: Fri Dec 29 08:16:32 2006 New Revision: 120258 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120258 Log: PR preprocessor/29612 * directives.c (do_linemarker): Set pfile->buffer->sysp always, not only when new_sysp is non-zero. * gcc.dg/cpp/pr29612-1.c: New test. * gcc.dg/cpp/pr29612-2.c: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/cpp/pr29612-1.c branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/cpp/pr29612-2.c Modified: branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/libcpp/ChangeLog branches/gcc-4_2-branch/libcpp/directives.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29612
[Bug preprocessor/29612] [4.0/4.1/4.2/4.3 Regression] gcc --save-temps does not give "multi-character character constant" error
--- Comment #2 from jakub at gcc dot gnu dot org 2006-12-29 08:15 --- Subject: Bug 29612 Author: jakub Date: Fri Dec 29 08:15:08 2006 New Revision: 120257 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120257 Log: PR preprocessor/29612 * directives.c (do_linemarker): Set pfile->buffer->sysp always, not only when new_sysp is non-zero. * gcc.dg/cpp/pr29612-1.c: New test. * gcc.dg/cpp/pr29612-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/cpp/pr29612-1.c trunk/gcc/testsuite/gcc.dg/cpp/pr29612-2.c Modified: trunk/gcc/testsuite/ChangeLog trunk/libcpp/ChangeLog trunk/libcpp/directives.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29612
