Re: Deprecating -fgnu-tm support for GCC 14 and removing it for GCC 15
On Mon, Dec 18, 2023 at 3:04 AM Richard Biener via Gcc wrote: > On Mon, Dec 18, 2023 at 2:35 AM Andrew Pinski via Gcc > wrote: > > > > On Sun, Dec 17, 2023 at 1:20 PM Eric Gallager > wrote: > > > > > > On Sat, Dec 16, 2023 at 3:16 PM Andrew Pinski via Gcc > wrote: > > > > > > > > -fgnu-tm support has not been improved since GCC 5 or earlier. It is > > > > not even supported with LTO. Does it make sense to deprecate the > > > > support for GCC 14 and remove it in GCC 15? > > > > > > > > Thanks, > > > > Andrew Pinski > > > > > > Personally, since GCC is in stage 3 now, I would push that schedule > > > back a release and move deprecation to GCC 15, and then only remove it > > > for GCC 16 if no one objects, but then again I don't actually use > > > -fgnu-tm myself, so I wouldn't be too upset if the faster schedule is > > > chosen instead. > > > > Considering -fgnu-tm has been broken for LTO ever since LTO was > > introduced, and broken with -fsanitize=undefined and broken with many > > code that might use internal functions (known since 2015), I suspect > > nobody is using this option in production nor even trying it out. If > > this was stage1, I might even just recommend removing the support. But > > deprecating it during stage 3 seems like a fair compromise. > > Btw, I'm OK with deprecating it for GCC 14. Can you please propose a > patch for changes.html and add a diagnostic message when -fgnu-tm is used > (disabled with -Wno-deprecated)? > Deprecation makes sense to me. But keep in mind that transactional memory is still the subject of research and standardization efforts, though the current proposal (wg21.link/n4923) is significantly simpler than the earlier TS that GCC implemented. I don't know how much of the current implementation would carry over, but I'd be cautious about tearing everything out just yet. Jason
Expected warning maybe-uninitialized does not appear using g++13.2.0?
Hello, I unintentionally stumbled upon some strange behaviour that
occurred due to a typo.
I reproduced the behaviour where an object (std::string in my case) can
be passed to a function by reference, uninitialized, WITHOUT a compiler
warning.
Changing the code to pass the object by value DOES emit the warning.
I don't think the compiled code is incorrect, it segfaults presumably
due to uninitialized members.
I understand there may seldom be a reason to use uninitialized objects,
so "don't do that," but as I said this was unintentional and it seems
that it should have generated a warning, which have saved some
head-scratching.
Code to reproduce:
#include
std::string f(std::string &s) {
s.append("x");
return s;
}
int main() {
std::string a = f(a);
}
Compile and run (no warning):
$ g++ -o uninit_obj uninit_obj.cpp -std=c++23 -Wall -Wpedantic -Wextra
&& ./uninit_obj
Segmentation fault (core dumped)
No difference whether using -O0 (or 1 2 3)
If I change the function to pass by value, std::string f(std::string s),
and rerun, I get the expected compiler warning:
$ g++ -o uninit_obj uninit_obj.cpp -std=c++23 -Wall -Wpedantic -Wextra
&& ./uninit_obj
uninit_obj.cpp: In function 'int main()':
uninit_obj.cpp:7:22: warning: 'a' may be used uninitialized
[-Wmaybe-uninitialized]
7 | std::string a = f(a);
[...]
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
Aborted (core dumped)
Output from g++ -v:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/gcc13/libexec/gcc/x86_64-pc-linux-gnu/13.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-13.2.0/configure --disable-multilib
--enable-languages=c,c++ --prefix=/usr/local/gcc13 --program-suffix=-13
--enable-libstdcxx-backtrace=yes
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.2.0 (GCC)
Thanks
Re: Question about creating global varaiable during IPA PASS.
Hi Thomas!
Thanks for your reply. That's exactly what I'm missing. When I add
varpool_node::finalize_decl() to my code, everything works fine!
Thomas Schwinge 于2023年12月16日周六 01:15写道：
>
> Hi Hanke!
>
> On 2023-12-13T17:04:57+0800, Hanke Zhang via Gcc wrote:
> > Hi, I'm trying to create a global variable in my own PASS which
> > located at the LATE_IPA_PASSES. (I'm using GCC 10.3.0.)
>
> I can't comment on IPA aspects, or whether something was different on
> oldish GCC 10 (why using that one, by the way?), and I've not actually
> verified what you're doing here:
>
> > And after creating it, I added the attributes like the following.
> >
> > // 1. create the var
> > tree new_name = get_identifier (xx);
> > tree new_type = build_pointer_type (xx);
> > tree new_var = build_decl (UNKNOWN_LOCATION, VAR_DECL, new_name, new_type);
> > add_attributes (new_var);
> >
> > static void
> > add_attributes (tree var)
> > {
> > DECL_ARTIFICIAL (var) = 1;
> > DECL_EXTERNAL (var) = 0;
> > TREE_STATIC (var) = 1;
> > TREE_PUBLIC (var) = 1;
> > TREE_USED (var) = 1;
> > DECL_CONTEXT (var) = NULL_TREE;
> > TREE_THIS_VOLATILE (var) = 0;
> > TREE_ADDRESSABLE (var) = 0;
> > TREE_READONLY (var) = 0;
> > if (is_global_var (var))
> > set_decl_tls_model (var, TLS_MODEL_NONE);
> > }
> >
> > But when I try to compile some example files with -flto, error occurs.
> >
> > /usr/bin/ld: xxx.ltrans0.ltrans.o: in function `xxx':
> > xxx.c: undefined reference to `glob_var'
> > xxx.c: undefined reference to `glob_var'
> > xxx.c: undefined reference to `glob_var'
> >
> > Here `glob_var' is the global varaiable created in my PASS.
> >
> > I would like to ask, am I using some attributes incorrectly?
>
> ..., but are you maybe simply missing to
> 'varpool_node::add (var);' or 'varpool_node::finalize_decl (var);' or
> something like that? See other uses of those, and description in
> 'gcc/cgraph.h', 'struct [...] varpool_node':
>
> /* Add the variable DECL to the varpool.
> Unlike finalize_decl function is intended to be used
> by middle end and allows insertion of new variable at arbitrary point
> of compilation. */
> static void add (tree decl);
>
> /* Mark DECL as finalized. By finalizing the declaration, frontend
> instruct
> the middle end to output the variable to asm file, if needed or
> externally
> visible. */
> static void finalize_decl (tree decl);
>
> If that's not it, we'll have to look in more detail.
>
>
> Grüße
> Thomas
